5651 Log Yönetimi ve İnternet Loglama Çözümü

Bir apartmanın güvenlik kamerası kaydını düşünün: kimin ne zaman girip çıktığını gösteren bu kayıt, normal bir günde kimsenin ilgisini çekmez; ama bir olay yaşandığında yönetim için tek gerçek savunma aracına dönüşür. 5651 sayılı kanun, işletmenizin internet trafiği için aynı kaydı tutmanızı ister: kim, hangi cihazdan, ne zaman internete çıktı? Personeline, öğrencisine veya müşterisine internet erişimi sunan her işletme bu kaydı tutmakla, yani toplu kullanım sağlayıcısı olarak 5651’e uymakla yükümlüdür.

Bu uyumu kuran taraf biziz: mevcut altyapınızı çıkarıyor, merkezi ve değiştirilemez bir log arşivi kuruyor, saat senkronizasyonunu doğruluyor ve denetimde istenen kanıtı üretebilir hâle getiriyoruz. Aşağıda önce kimin yükümlü olduğunu ve hangi teknik şartların arandığını, sonra işi nasıl yürüttüğümüzü ve fiyatı neyin belirlediğini bulacaksınız. Bu sayfa Siber Güvenlik hizmetimizin yasal uyum koluna odaklanır; sunucu ve ağ cihazlarının genel sıkılaştırması için güvenlik sıkılaştırma (hardening) rehberimize göz atabilirsiniz.

Kimler Yükümlü?

İnternete kendi hattınızdan bağlandığınız ve bu bağlantıyı başka biriyle (çalışan, öğrenci, müşteri, misafir) paylaştığınız her durumda 5651 kapsamına girersiniz:

• Ofislerinde çalışanlarına internet veren şirketler
• Misafir Wi-Fi’ı sunan oteller, restoranlar, kafeler
• Öğrencilerine veya personeline internet sağlayan okullar ve üniversiteler
• Müşterilerine internet erişimi sunan AVM’ler, hastaneler ve benzer işletmeler

Buradaki ayrım genellikle karıştırılır: sizin İnternet Servis Sağlayıcınız (ISP) zaten kendi hattı üzerindeki trafiği loglar, ama bu kayıt sadece “işletmenize” kadar olan trafiği gösterir. Apartman benzetmesiyle söylersek, ISP’nin kaydı sitenin ana giriş kapısındaki kamerayla sınırlıdır; sitenin içindeki hangi dairenin (hangi çalışanın, hangi öğrencinin) o kapıdan çıktığını görmek isterseniz, bu iç kaydı tutmak size düşer. ISP’nin loglaması sizi bu yükümlülükten muaf tutmaz.

Kaydı üreten yer, misafir tarafında erişim katmanıdır: karşılama ekranı (captive portal), SMS ya da TC kimlik doğrulaması ve girişin kayda bağlanması. O katmanı misafir Wi-Fi ve hotspot kurulumu hizmetiyle kuruyoruz; bu sayfanın konusu ise o kaydın saklanması, değiştirilemezliği ve ibrazıdır.

Teknik Yükümlülükler: Ne, Ne Kadar ve Nasıl Saklanmalı?

Log Kayıt Kapsamı

Loglanması gereken bilgi, bir bağlantıyı geriye dönük olarak kesin biçimde tanımlayabilecek kadar detaylı olmalıdır: internet çıkışı yapan her cihazın iç IP adresi, bu adresin NAT (Ağ Adresi Çevirimi) üzerinden hangi dış IP ve porta eşlendiği, bağlantının başlangıç ve bitiş zamanı. Bu detay seviyesi olmadan, “bu dış IP’yi hangi cihaz kullandı?” sorusuna cevap verilemez; kayıt var görünür ama pratikte işe yaramaz.

Portun neden dış IP kadar önemli olduğu, çevirinin mekanizmasında yatıyor: tek bir dış adresin arkasında aynı anda binlerce bağlantı bulunabilir ve cihazları birbirinden ayıran tek şey o adresin yanına yazılan port numarasıdır. Bunu laboratuvarda ölçüp gösterdiğimiz yer NAT ve port çevirisi rehberimiz; portsuz tutulan bir kaydın neden hiçbir cihazı işaret etmediği orada çıktıyla görünüyor.

Saklama Süresi

Trafik bilgisi kayıtları en az 2 yıl saklanmalıdır (5651 sayılı kanunun resmi metninde bu sürenin yasal dayanağını görebilirsiniz). Bu, kamera kaydını bir haftada silen bir apartman yönetimi gibi davranmamak demektir: log sisteminizin eski kayıtları otomatik olarak silmesi değil, belirlenen süre boyunca güvenli bir arşive taşıması gerekir.

Storage kapasitesi planlamasında bu süre baştan hesaba katılmalıdır; aksi halde disk dolduğunda en eski (ve belki de en kritik) kayıtlar sessizce kaybolur. Arşivin ne kadar yer tutacağını ve mevcut diskinizin kaç ay yettiğini 5651 log kapasitesi hesaplama aracımızda çıkarabilirsiniz.

Güvenli ve Immutable Storage

Bir kaydın hukuki delil değeri taşıması için sonradan değiştirilemez (tamper-proof) olması gerekir. Bu genellikle her log bloğunun bir önceki blokla hash zinciriyle bağlanmasıyla sağlanır: zincirdeki herhangi bir kayıt en ufak şekilde oynanırsa, zincir kırılır ve bu kırılma anında tespit edilebilir. Kamera kaydının üzerine sonradan görüntü eklenip eklenmediğini anlayabilmek gibi düşünün; loglama sisteminizin bu garantiyi taşıyıp taşımadığını mutlaka sorgulayın.

Zaman Damgası: Kaydın Tarihini Üçüncü Tarafa Kanıtlamak

Hash zinciri kaydın kendi içinde tutarlı olduğunu gösterir, ama o kaydın belirtilen tarihte gerçekten var olduğunu kanıtlamaz. Bu ikisi sık karıştırılır ve aradaki fark denetim anında ortaya çıkar: zinciri siz üretiyorsanız, zincirin tamamını sonradan yeniden üretmediğinizi de yine sizin iddianıza dayanarak kabul etmek gerekir.

Bu boşluğu kapatan şey zaman damgasıdır: yetkili bir Elektronik Sertifika Hizmet Sağlayıcısının (TÜBİTAK Kamu SM, E-Güven, TürkTrust gibi) kaydın bütünlük değerini kendi imzasıyla mühürlemesi. Artık tarihi doğrulayan taraf siz değil, bağımsız bir kurumdur. Apartman kaydını mahalle muhtarına onaylatmak gibi düşünün: defter yine sizde durur, ama üzerindeki tarihi artık siz beyan etmiyorsunuz.

Loglama sisteminizi değerlendirirken bu soruyu net sorun: kayıtlar zaman damgalanıyor mu, damgayı hangi hizmet sağlayıcı veriyor? Cihazın kendi içinde attığı bir tarih etiketi ile nitelikli zaman damgası aynı şey değildir.

Yetkili Makama İbraz

Talep geldiğinde loglar eksiksiz, doğrulanabilir ve okunabilir biçimde sunulabilmelidir. Burada sık yapılan hata, logların var olması ama erişilebilir olmamasıdır: dağınık dosyalarda, farklı formatlarda veya kimsenin hatırlamadığı bir sunucuda duran kayıtlar, ibraz anında pratikte yok kayıtlar kadar sorunludur.

Saat Senkronizasyonu: Damganın Vurulduğu Saatin Doğru Olması

Zaman damgası kaydın tarihini dışarıya kanıtlar; saat senkronizasyonu ise o tarihin en baştan doğru olmasını sağlar. İkisi birbirinin yerine geçmez: yanlış saatli bir cihazın ürettiği kayıt, kusursuz biçimde damgalansa bile yanlış saati mühürlemiş olur. Log sunucusu ile trafiği üreten cihazların saatleri senkronize değilse, aynı olayın farklı kayıtlarda farklı saatlerde görünmesi gibi bir tutarsızlık ortaya çıkar; bu da kayıtların güvenilirliğini doğrudan zedeler.

NTP yapılandırması bu yüzden gözden kaçırılmaması gereken teknik bir ön koşuldur. Burada sık yapılan hata, senkronizasyonu yalnızca sunucu tarafında düşünmektir: log üreten firewall, switch ve kamera kayıt cihazlarının hiçbiri domain üyesi değildir ve saatlerini kendiliğinden hiçbir yerden almazlar. Stratum hiyerarşisi, ağ genelinde tek saat kaynağı kurma ve hangi cihazın saatini nereden alacağı NTP ve saat senkronizasyonu rehberimizde ele alınmaktadır.

5651 Uyumlu Firewall Almak Yeterli mi?

Kısa cevap: bir cihazın “5651 uyumlu firewall” olarak satılması, kurumunuzun 5651 uyumlu olduğu anlamına gelmez. Piyasada 5651 loglama modülüyle gelen, kaydı zaman damgalayan cihazlar var ve tek lokasyonlu, küçük ölçekli bir işletmede bunlar işi görebilir. Ama uyumu belirleyen şey cihazın kutusundaki etiket değil, kaydın nereye aktığı, orada ne kadar kaldığı ve talep geldiğinde ibraz edilebilir olup olmadığıdır.

Apartman benzetmesine dönersek: kapıya kamera taktırmak ile kayıtları iki yıl boyunca saklayan bir arşiv odasına sahip olmak farklı şeylerdir. Kamera görünür, arşiv görünmez. Bu yüzden çoğu kurum kamerayı taktırdığı gün işin bittiğini düşünür.

Cihazın “5651 Modülü” Ne Kadarını Karşılar?

Bir firewall’un 5651 özelliği, çoğunlukla kaydın üretilmesini çözer: hangi iç IP’nin hangi dış IP ve porta çevrildiği, oturumun ne zaman başlayıp bittiği cihaz üzerinde doğru biçimde oluşturulur. Bu, işin gerçekten zor olmayan tarafıdır ve modern kurumsal firewall’ların çoğu bunu zaten yapar.

Asıl yük kaydın üretilmesinden sonra başlar: iki yıllık saklama, değiştirilemezlik, şifreleme, zaman damgası ve ibraz edilebilirlik. Cihaz üreticisinin “5651 uyumlu” ifadesi bu zincirin tamamını değil, genellikle ilk halkasını tarif eder. Satın alma görüşmesinde sorulacak doğru soru şudur: bu cihaz kaydı üretiyor mu, yoksa iki yıl boyunca saklayıp bana ibraz edilebilir biçimde geri veriyor mu?

Firewall Logunun Tek Başına Bıraktığı Boşluklar

Yerel diskte tutulan bir firewall logu, 5651 açısından dört noktada açık verir:

• Kapasite ve döngüsel yazma: Firewall logu genellikle cihazın kendi diskinde birkaç hafta veya ay tutulur; kapasite dolunca en eski kayıtların üzerine yazılır. İki yıllık saklama şartıyla doğrudan çelişen bir davranıştır ve sessizce işler, kimse uyarı almaz.
• Tek nüsha riski: Kayıt yalnızca cihazın üzerindeyse, cihaz arızalandığında veya donanım yenilendiğinde geçmiş de gider. Denetim anında “cihazı değiştirdik” bir savunma değildir.
• Dağınık kapsam: Misafir Wi-Fi’ı ayrı bir kontrolcüde, şubeler ayrı firewall’lardaysa her cihaz kendi adacığında kayıt tutar. Tek bir soruya (bu dış IP’yi dün saat kaçta hangi cihaz kullandı) cevap vermek için üç ayrı arayüze girmek gerekir.
• İbraz formatı: Talep geldiğinde istenen şey ekran görüntüsü değil, doğrulanabilir ve okunabilir bir kayıt setidir. Cihaz arayüzünden alınan filtrelenmiş bir liste bu niteliği taşımaz.

Bu boşlukların dördü de aynı çözümle kapanır: firewall kaydı üretmeye devam eder, kayıt markadan bağımsız çalışan merkezi bir arşive akar. Cihazınızı değiştirmeniz gerekmez.

Tek Kutuya Yüklemek mi, Katmanları Ayırmak mı?

Kurumsal ölçekte tercih ettiğimiz mimari, güvenlik katmanı ile yasal arşiv katmanını ayırmaktır: tehdit önlemeyi işini iyi yapan bir kurumsal firewall’a, 5651 arşivini ise bu iş için tasarlanmış ayrı bir log platformuna bırakmak. Bu bir marka tercihi değil, üç somut nedene dayanan bir yapı kararı.

Birincisi, iki katmanın ömrü aynı değil. Bir firewall dört beş yılda bir yenilenir, kapasitesi büyür, modeli değişir. Kayıt ise iki yıl boyunca yaşamak zorundadır. İkisini aynı kutuya koyarsanız, donanım yenilemesi aynı zamanda bir arşiv taşıma projesine dönüşür; bu taşıma sırasında kaybedilen kayıtlar da denetim karşısında sizin sorununuz olur.

İkincisi, iki katman farklı uzmanlık ister. Tehdit önleme küresel ölçek işidir: cihazın değeri, dünya genelindeki saldırı verisinden beslenen imza ve istihbarat ağından gelir. 5651 uyumu ise tam tersine yerel bir uzmanlıktır: zaman damgasını hangi hizmet sağlayıcının vereceği, ibrazın hangi formatta isteneceği, sürenin nereden başlatılacağı Türkiye’ye özgü sorulardır. Bir üründen aynı anda her iki alanda da en iyi olmasını beklemek, ikisinde de ortalamaya razı olmak demektir.

Bu tabloya çoğu kurumun hiç hesaba katmadığı bir uzmanlık daha ekleniyor: log sunucusunun kendisi de yedeklenmelidir. 5651 log platformu bir yere kurulur ve o sunucu, iki yıllık kaydı taşıyan bir veri deposuna dönüşür. Arşiviniz değiştirilemez olabilir, zaman damgalı olabilir, ama tek bir disk arızası veya bir fidye yazılımı saldırısı o arşivi bütünüyle götürürse elinizde ibraz edecek bir şey kalmaz. Denetim karşısında “sunucumuz bozuldu” bir savunma değildir.

Yedekleme de kendi başına ayrı bir disiplindir: kaç nüsha tutulacağı, kopyalardan birinin fiziksel olarak başka bir yerde durup durmadığı, fidye yazılımının silemeyeceği biçimde değiştirilemez (immutable) olup olmadığı ve en kritiği, geri dönüşün gerçekten test edilip edilmediği. Test edilmemiş bir yedek, yedek sayılmaz. Konunun tamamını, 3-2-1-1-0 kuralı ve kurtarma süresi hedefleriyle birlikte kurumsal veri yedekleme ve felaket kurtarma rehberimizde ele alıyoruz; bu işi sanallaştırma altyapısının tamamında nasıl kurduğumuzu ise yedekleme sistemi kurulumu vaka çalışmamızda anlatıyoruz.

Üçüncüsü, tek satıcıya bağımlılık riski. Güvenliğiniz ve yasal uyumunuz aynı kutuya bağlıysa, o üründen memnun kalmadığınız gün ikisini birden değiştirmek zorunda kalırsınız. Apartman benzetmesiyle: binanın güvenlik şirketi ile kayıtların tutulduğu arşivin aynı firmaya ihale edilmesi zorunlu değildir, ayrı olması ikisini de sorgulayabilmenizi sağlar.

Hangi firewall ailesinin kurumunuza uygun olduğu, kaç lokasyonun nasıl bağlanacağı ve yüksek erişilebilirlik ihtiyacınız ayrı bir karar başlığıdır; bunu kurumsal firewall kurulumu ve yönetimi rehberimizde ele alıyoruz. Oradaki kural seti disiplini ile buradaki loglama katmanı birbirini tamamlar: biri trafiğin geçip geçmeyeceğine karar verir, diğeri geçen trafiğin kaydını hukuken savunulabilir biçimde saklar.

Bir Kurumda 5651 Boşluğunu Nasıl Bulduk?

Yazar olarak, uzun süredir sistem ve ağ desteği verdiğimiz çok lokasyonlu büyük bir kuruma destek vermeye başlar başlamaz yaptığımız ilk incelemede bir şey dikkatimi çekti: kurumun 5651 kapsamındaki loglama yükümlülüğü hiç karşılanmıyordu. Birbirine bağlı onlarca lokasyonun hiçbirinde merkezi, değiştirilemez bir log arşivi yoktu; firewall’lar kendi yerel disklerinde birkaç haftalık kayıt tutup üzerine yazıyordu.

Asıl sorun, kurumun bunu fark etmemiş olması değildi; kimsenin bu konuyu net biçimde sorgulamamış olmasıydı. Böyle bir boşluk, bir olay yaşanana kadar tamamen görünmez kalır; olay yaşandığında ise artık çok geç olur. Benzer bir projeyi kısa sürede nasıl tamamladığımızı, hangi log toplama mimarisini kurduğumuzu 5651 uyum projesi vaka çalışmasında ayrıntılarıyla anlatıyoruz.

Loglama Yapılmazsa Ne Olur?

5651 kapsamındaki yükümlülüklerini yerine getirmeyen toplu kullanım sağlayıcıları idari yaptırımlarla karşılaşabilir. Ancak pratikte asıl risk cezadan önce gelir: kurumunuzun hattı üzerinden bir siber suç işlendiğinde ya da yasa dışı bir paylaşım yapıldığında, elinizde loglama yoksa “bunu kim yaptı” sorusuna cevap veremezsiniz ve şüphe doğrudan kurumunuzun tüzel kişiliği üzerinde kalır. Kamera kaydı olmayan bir sitede yaşanan bir olayda tüm site sakinlerinin şüpheli konumuna düşmesi gibi düşünün.

5651 Log Çözümümüz: Marka Bağımsız Toplama ve Arşiv

Sistem Kuşu olarak, mevcut altyapınıza entegre edilebilen otomatik log toplama ve arşivleme sistemleri kuruyoruz. Kullandığınız firewall veya yönlendirici markasından bağımsız çalışan merkezi bir log yönetim platformu tercih ediyoruz; böylece donanımınızı değiştirmeden, sadece trafiği doğru yere yönlendirerek uyumu sağlıyoruz.

Somut olarak şunları yapıyoruz:

• Mevcut altyapı analizi ve uyumluluk değerlendirmesi
• Merkezi log toplama sisteminin kurulumu ve yapılandırması
• Hash zincirlemeli, değiştirilemez log arşivleme
• NTP senkronizasyonunun doğrulanması
• Periyodik uyumluluk raporları
• Yasal talep durumunda log ibrazı için teknik destek

Bu toplama katmanının altında yatan protokol syslog’tur ve cihazlarınızın kayıtları oraya bu yolla akar. Protokolün nasıl çalıştığını, bir log satırının neyi taşıdığını ve hangi garantileri kendiliğinden vermediğini Syslog protokolü rehberimizde ele alıyoruz; oradaki sınırların üstüne kurulan zaman damgası ve değiştirilemezlik katmanı, bu sayfada anlattığımız uyumun kendisidir. Toplama tarafını kendiniz kurmak isterseniz, Ubuntu üzerinde adım adım nasıl yapıldığını syslog sunucusu kurulum rehberimizde gösteriyoruz.

Bu altyapı yalnızca 5651 için çalışmaz. ISO 27001 belgelendirme sürecindeki kurumlarda denetçinin istediği loglama ve saat senkronizasyonu kanıtları da aynı sistemden çıkar; standardın şartlarını ve denetim aşamalarını ISO 27001 belgesi rehberimizde ayrıntılarıyla anlatıyoruz.

Bu hizmetin sürekli tarafında dikkat edilmesi gereken bir nokta var: log akışının durması kimsenin şikâyet etmediği bir arızadır. Ekranda bir şey bozulmaz, kullanıcı aramaz; eksik olan, yasal talep geldiği gün fark edilir. Bu yüzden akışın kesilmesini kullanıcı sayısına göre değil aciliyete göre değerlendiriyoruz. Önem seviyelerini neye göre belirlediğimizi ve bu türden sessiz arızaların neden alt seviyeye düşmediğini destek sürecimizde yazdık.

5651 Loglama Fiyatını Ne Belirler, Sağlayıcı Nasıl Karşılaştırılır?

5651 loglama teklifleri arasındaki fark çoğu zaman fiyat kaleminde değil, fiyatın neyi kapsadığında saklıdır. Rakam vermiyoruz, çünkü aynı ifade tek ofisli bir işletme için de on lokasyonlu bir kurum için de kullanılıyor; ama bir teklifi okurken bakılacak başlıklar sabittir.

Fiyatı belirleyen dört şey:

• Günlük log hacmi ve lokasyon sayısı. İşin tabanı bu. Hacmi kullanıcı sayısı değil, trafiğin cinsi belirler: misafir Wi-Fi’ı yoğun bir otel, aynı kullanıcı sayısındaki bir ofisten kat kat fazla kayıt üretir. Firewall’unuzun oturum sayısından yola çıkan hesabı log kapasitesi aracımızda yapabilirsiniz.
• Saklama süresi ve arşiv katmanı. Yasal taban iki yıl. İki yıllık kaydın nerede duracağı (yerel disk, ayrı bir arşiv birimi, uzak kopya) hem donanım hem işletme kalemini değiştirir.
• Mevcut donanımla çalışılıp çalışılmayacağı. Bizim tercihimiz marka bağımsız bir toplama katmanı kurmak, yani donanımınızı değiştirmeden trafiği doğru yere yönlendirmek. Cihaz değişikliği isteyen bir çözüm, fiyat farkını lisansta değil satın almada üretir.
• Kurulum mu, süreklilik mi? Kurulum tek seferliktir. Periyodik uyum raporu, saklama süresinin denetlenmesi ve yasal talep anında log ibrazı desteği ise süreklilik ister ve ayrı fiyatlanır.

Bir sağlayıcıyı karşılaştırırken sorulacak beş soru ise fiyattan önce gelir, çünkü ucuz bir teklifin eksiği genelde bu beşinden birindedir:

1. Kayıtlar değiştirilemez mi, ve bunu neyle kanıtlıyorsunuz? “Yedekliyoruz” cevabı değiştirilemezlik değildir.
2. Zaman damgası nereden geliyor ve logu üreten cihazların saatleri neyle senkron? Firewall, switch ve kamera kayıt cihazı domain üyesi değildir; saatini kendiliğinden hiçbir yerden almaz.
3. İki yıllık saklama otomatik mi yönetiliyor, yoksa disk dolunca en eskinin üzerine mi yazılıyor?
4. Yasal bir talep geldiğinde ibraz kimin işi? Teknik destek kapsamda mı, ek kalem mi?
5. Sözleşme biterse arşiv kimde kalır? Veri sizin; çıkışta okunabilir biçimde teslim edilmesi baştan yazılmalı.

Bu beş sorunun cevabını yazılı isteyin. Denetim anında sorulan da tam olarak bunlar oluyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn