Şirket Siber Saldırıya Uğradığında: KVKK Veri İhlali, Delil ve İlk Kararlar

Saat 09.17’de muhasebe sunucusu dosyaları açmamaya başladı. Ekranda fidye notu var; gece boyunca dışarıya yoğun trafik çıktığı görülüyor. Operasyon ekibi sistemleri ayağa kaldırmak, yönetim müşterilere açıklama yapmak, bilgi güvenliği ekibi ise ağ bağlantısını kesmek istiyor. Bu üç refleksin hiçbiri yanlış değil. Hata, her birini diğerinin dayandığı kanıtı yok ederek uygulamakta başlıyor. Sunucuyu hemen yeniden kurmak saldırganın izini silebilir; “müşteri verisi çalınmadı” açıklaması henüz incelenmemiş aktarım kayıtlarıyla çelişebilir; bütün ağı düşünmeden kapatmak ise hizmet sürekliliğini gereksiz yere durdurabilir.

Bir şirketin siber olayı aynı anda üç dosyadır: devam eden saldırıya karşı müdahale, kişisel veri etkisinin ve bildirim yükümlülüğünün değerlendirilmesi, suç ve zarar için delilin korunması. Sıra ve yetki önceden belirlenmemişse ilk saatler telefon konuşmalarıyla geçer. Oysa hangi kaydın ne zaman kaybolacağı, hangi sistemin güvenle yalıtılacağı ve hangi açıklamanın bugün yapılabileceği o sırada belirlenir. Bu yazı, şirket yöneticisinin, hukuk ekibinin ve teknik incelemeyi yapan uzmanın aynı olay çizelgesi üzerinde konuşabilmesi için hazırlanmıştır. Suç tipleri ve mağdurun başvuru yollarına ilişkin geniş çerçeve siber suçlar ve bilişim suçları rehberinde yer alır; burada şirketin ilk kararlarına odaklanıyoruz.

Önce olayın dört ayrı saatini kaydedin

“İhlal ne zaman oldu?” sorusunun tek bir cevabı olmayabilir. Saldırganın ilk yetkisiz oturumu pazartesi, verilerin dışarı aktarımı çarşamba, güvenlik alarmının görülmesi cuma, olayın veri sorumlusuna teyitli olarak bildirilmesi ise cumartesi gerçekleşmiş olabilir. Log kaydındaki UTC damgası ile şirketin Türkiye saatiyle tuttuğu çağrı kaydı birbirinden ayrılmalıdır. Olay çizelgesinde ilk eylem, ilk teknik belirti, kurumun öğrenmesi ve müdahale kararları farklı satırlardır. KVKK bildirim süresini ve delilin güvenilirliğini ancak böyle denetleyebilirsiniz.

İlk kayıtta yorumdan çok gözlem yer almalı: “09.17’de X sunucusundaki dosyalar açılamadı”, “09.23’te Y kullanıcısının hesabı devre dışı bırakıldı”, “09.42’de güvenlik duvarında Z hedefe çıkış görüldü”. “Saldırgan bütün müşteri verilerini aldı” gibi sonuç cümlesi, henüz karşılaştırılmamış bir trafik kaydından çıkmaz. Buna karşılık “kanıtlanmadı” ile “gerçekleşmedi” de eş anlamlı değildir. İnceleme ilerledikçe önceki kaydı silmek yerine yeni bulguyu ve kanaat değişikliğinin nedenini ekleyin.

Karar kaydı da teknik log kadar önemlidir. Etkilenen sunucunun kim tarafından hangi gerekçeyle ağdan ayrıldığı, olay anı belleğinin veya diskinin alınıp alınmadığı, şifre sıfırlamasının ne zaman yapıldığı, yedeğe dönme kararı ve bunun hangi veriyi değiştirebileceği kayda geçmelidir. Sonradan “neden o anda bildirmediniz?” veya “kanıt niçin yok?” sorusu sorulduğunda şirketin cevabı hatırlanan bir toplantıdan ibaret kalmamalıdır.

Siber olay ile KVKK bildirimine konu ihlal aynı eşik değildir

Sunucunun çalışmaması, zararlı yazılım uyarısı ya da sistemde bir açıklığın bulunması ciddi bir olaydır. Fakat 6698 sayılı Kanun’un 12/5 hükmü, bildirimi işlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâline bağlar. Verinin erişilemez olması, iş sürekliliği ve güvenlik bakımından önemli olsa da tek başına bu olgunun gerçekleştiğini söylemez. Öte yandan saldırganın “verileri aldık” notunun yalan olabileceği ihtimali, dışarı aktarım ve yetkisiz erişim izlerini araştırmadan bildirimi kapatmaya da gerekçe olmaz.

Örneğin fidye yazılımı yalnızca şirket içindeki üretim dosyalarını şifrelemiş ve kişisel veri içeren depoya erişmemiş olabilir. Başka bir olayda dosyalar şifrelenmeden önce müşteri tablosu dışarıya aktarılmıştır. Üçüncü olayda veri aktarım izi yoktur, ancak çalınmış yönetici hesabıyla hasta, çalışan veya müşteri kayıtları görüntülenmiştir. Her üç durumda teknik müdahale gerekir; KVKK 12/5 analizi ise erişilen veri, erişimi yapan kişi, işlemin hukuka uygunluğu ve elde edilmeyi gösteren bulgular üzerinden ayrı yapılır. Bildirim eşiğini yalnız dosyanın kopyalanıp kopyalanmadığına indirgemek de sağlıklı değildir; görüntüleme ve erişim kayıtlarının niteliği incelenmelidir.

İnceleme belirsizlikle başlayabilir. Bu yüzden olay ekibi bir “bildirime gerek yok” etiketi yerine hipotezleri ve bunların dayandığı kayıtları yazmalıdır: Etkilenen sistem hangi veri kümelerine bağlanıyordu? Saldırgan hesabının yetkileri neydi? Dosya okuma, dışa aktarma, sorgulama veya nesne depolama erişimi var mıydı? Ağ çıkışı hangi hedefe, hangi hacimde gerçekleşti? Şifreli trafik içeriği görülmüyorsa bunu açıklayabilecek uç nokta veya uygulama logu var mı? Log yokluğu, veri çıkmadığının kanıtı diye kullanılmamalıdır; yokluğun sebebi de raporlanmalıdır.

İlk müdahale: sistemi korurken olayın izini yaşatmak

Saldırı devam ediyorsa etkilenen hesabı devre dışı bırakmak, oturumları sonlandırmak, zararlı bağlantıyı kesmek ve temiz cihazdan kritik kimlik bilgilerini yenilemek geciktirilmez. Ancak “her şeyi kapatın” talimatı yerine etki alanı çizilir. Hangi sunucu ağdan yalıtıldı? Hangi hizmet üretimde kaldı? Hangi hesabın parolası değişince saldırganın hareketi kesildi? Bu kararları almak için adli incelemenin tamamını beklemek gerekmez; müdahale ile delil muhafazası birlikte planlanır.

Özellikle otomatik log rotasyonu, kısa süreli bulut kayıtları ve kamera görüntüleri için koruma talimatı erken verilmelidir. Bulut hizmetinde yalnız görünen panelin ekran görüntüsünü almak yetmez. Kimlik ve erişim yönetimi logları, API anahtarı oluşturma veya kullanma kayıtları, nesne indirme günlükleri, e-posta yönlendirme kuralları, ödeme talimatları ve dış bağlantı geçmişi olayın türüne göre istenir. Sağlayıcının hangi kaydı ne kadar süre tuttuğu bilinmiyorsa önce bunu sorun; “log vardı” varsayımı birkaç hafta sonra kanıtı geri getirmez.

Delil için tek bir klasöre rastgele dosya doldurmak yerine kaynağı korunan kopyalarla çalışan bir envanter tutulmalıdır:

Bir dosyanın hash değerini almak, korunan kopyanın sonradan değişip değişmediğinin denetlenmesine yardım eder. Fakat hash, içeriğin olaydan önce doğru olduğunu veya logdaki hesabı kimin kullandığını tek başına göstermez. Kopyayı kimin aldığı, yöntem, cihaz ve saklama zinciri yazılmalıdır. Acil müdahale sırasında canlı sistem üzerinde zorunlu değişiklik yapıldıysa bunu saklamak yerine işlem öncesi ve sonrası durumla birlikte açıklamak incelemenin güvenilirliğini artırır.

Veriyi kimin adına işliyordunuz?

Bir bulut sağlayıcısının, çağrı merkezi şirketinin veya dış yazılım ekibinin sisteminde olay çıkması, müşterisi olan şirketi kendiliğinden bildirim denkleminden çıkarmaz. KVKK’nın tanımına göre veri sorumlusu, kişisel verinin işleme amaçlarını ve vasıtalarını belirleyen kişidir; veri işleyen ise veri sorumlusunun verdiği yetkiye dayanarak onun adına işlem yapar. Aynı tedarikçi farklı faaliyetlerde farklı rol taşıyabilir. “Veri nerede duruyor?” sorusu tek başına rolü belirlemez; “işleme amacını ve yöntemini kim kararlaştırıyor?” sorusu da sorulmalıdır.

Kanun’un 12/2 maddesi, veri sorumlusunun kendi adına veri işleyenle güvenlik tedbirleri yönünden müşterek sorumluluğunu düzenler. Kurulun mağazacılık şirketi hakkında 2021/1021 sayılı karar özeti, verilerin veri işleyen sisteminden elde edildiği iddiasının veri sorumlusunun güvenlik yükümlülüğünü ortadan kaldırmadığını somut olayda vurgular. Bu karar her tedarikçiye aynı kusuru yükleyen bir kısa yol değildir; sözleşme, teknik yetki ve fiilî kontrol yine ayrı incelenir.

Kurulun 2019/10 sayılı kararına ilişkin resmî duyuru, veri işleyen nezdindeki kişisel veriler hukuka aykırı yollarla başkaları tarafından elde edildiğinde veri işleyenin veri sorumlusuna gecikmeksizin bildirim yapmasını ister. Bu nedenle tedarikçi sözleşmesinde “ihlal kesinleşince haber verilir” gibi ucu açık bir cümle, ilk saatlerde kimin kimi arayacağını çözemeyebilir. Hizmet sağlayıcının olay zamanı, etkilenen müşteri ortamları, veri kategorileri ve korunan kayıtlar için ulaşılabilir bir irtibatı olmalı; veri sorumlusu da kendi bildirim değerlendirmesini yapacak yetkili kişiyi önceden belirlemelidir.

Birden fazla müşteri aynı altyapıyı kullanıyorsa “tedarikçide ihlal oldu” duyurusu her müşteri için aynı sonucu doğurmaz. Bölümlendirme, erişim anahtarları ve loglar hangi müşterinin hangi veri setinin etkilenmiş olabileceğini gösterebilir. Ayrım yapılamıyorsa bu eksiklik, raporda açıkça yer alır. Tedarikçiden yalnız kısa bir güvence yazısı istemek yerine hangi teknik kayıtların bu güvenceyi desteklediği sorulur.

Kurula 72 saat: saat ne zaman işler, eksik bilgi nasıl verilir?

Kurulun 24 Ocak 2019 tarihli 2019/10 sayılı kararı, Kanun’daki “en kısa sürede” ifadesini Kurula bildirim bakımından, veri sorumlusunun ihlali öğrenmesinden itibaren gecikmeksizin ve en geç 72 saat olarak yorumlar. Bu, saldırının ilk gerçekleştiği andan otomatik başlayan bir kronometre değildir. Öte yandan kurumun önüne yeterli olgu gelmişken öğrenme tarihini iç onay toplantısına ertelemek de güvenli bir yöntem değildir. Alarmın teknik bir şüpheden hukuken değerlendirilebilir olguya ne zaman dönüştüğü, gelen mesajlar ve kurum içi iletimle birlikte kaydedilmelidir.

İlk 72 saatte kaç kişinin etkilendiği, saldırganın kimliği veya son kök neden henüz bilinmeyebilir. Aynı Kurul kararı, formdaki bilgilerin aynı anda sağlanamadığı hâllerde bunların gecikmeye mahal verilmeden aşamalı olarak verilmesini öngörür. Haklı gerekçeyle 72 saat içinde bildirim yapılamadıysa gecikme nedeni de bildirimle birlikte açıklanmalıdır. Olayı belirsiz gösterip hiçbir tespit yapmadan form göndermek kadar, her sayı kesinleşene kadar beklemek de sorun çıkarabilir. İlk bildirimde teyitli olgular, makul etki aralığı, bilinmeyenler ve devam eden araştırma açıkça ayrılır; sonraki bulgularla güncellenir.

Kurulun 2020/359 sayılı banka kararı özeti bu noktada somuttur. Banka, delillerin yetersizliği, hangi verinin paylaşıldığının net olmaması ve kurum içi değerlendirmeyi geç bildirime gerekçe göstermişti. Kurul, bilgilerin aşamalı verilebilmesi imkânını dikkate alarak bu nedenleri yeterli mazeret saymadı. Karar, her şüphede otomatik bildirim yapılması gerektiğini söylemez; fakat öğrenilmiş ihlali kesin liste çıkana kadar bekletmenin riskini gösterir. Aynı dosyada ilgili kişilerin tamamına ulaşmak için makul çaba meselesi de ayrıca değerlendirildi.

Kurul bildirimini kimin yapacağı belli olmalı; ilgili form, kişi sayısı ve veri kategorileri için geçici rakam kullanıldıysa bunun dayanağı kaydedilmelidir. KVKK’nın bildirim sayfası çevrimiçi forma ve kılavuza bağlantı verir. Teknik ekibin olay raporu, hukuki değerlendirmeye ham veri sağlar; son bildirim metninde işin özünü perdeleyen ürün adları yerine etkilenen veri ve kişiler anlaşılır biçimde anlatılır.

İlgili kişiye ve müşteriye ne söylemeli?

Kurula 72 saat kuralı, etkilenen kişilere “72 saat sonra” bildirim yapılacağı anlamına gelmez. 2019/10 sayılı kararda, etkilenen kişiler belirlendikten sonra makul olan en kısa sürede bildirim; iletişim adresine ulaşılabiliyorsa doğrudan, ulaşılamıyorsa şirketin internet sitesi gibi uygun yollar öngörülür. Kurulun 2019/271 sayılı kararı ise ilgili kişiye açık ve sade bildirimde en az olay zamanı, etkilenen kişisel veri kategorileri, olası sonuçlar, alınan veya önerilen önlemler ve ulaşılabilir irtibat bilgisinin bulunmasını ister.

Bir şirketin “hiçbir şeye gerek yok” cümlesi kadar “bütün verileriniz tehlikede” cümlesi de kanıtsızsa zararlıdır. İlk bilgi aktarımında doğrulanmış kapsam ile hâlen araştırılan kapsam ayrılmalı. Örneğin yalnız iletişim bilgileri kesin etkilenmişken sağlık bilgileri için erişim ihtimali araştırılıyorsa bu iki durumu eşit kesinlikte yazmayın. Şifre sıfırlama, sahte arama veya kimlik avı uyarısı gibi öneriler veri türüne ve gerçek riske göre verilmelidir. İlgili kişiden kurumsal bildirim bahanesiyle parola, tek kullanımlık kod veya kimlik belgesi istemek saldırganın ikinci dalgasına kapı açabilir.

Müşteri şirket, veri sorumlusu sıfatını taşıyorsa teknik tedarikçinin ona yaptığı olay bildirimi ilgili kişiye yapılan bildirimin yerine geçmez. Ayrıca ticari müşteri iletişimi, KVKK’daki ilgili kişi bildirimiyle aynı hedef kitleye gitmeyebilir. Bu yüzden kamuya açıklama, müşteri sözleşmesi gereği bildirim ve kişisel verisi etkilenen gerçek kişiye bildirim için ayrı alıcı listeleri tutulur; fakat üç metindeki olay tarihi ve kapsam tanımı birbirini çürütmemelidir. Basın metnine önce, veri sorumlusuna sonra haber vermek gibi bir sıralama güveni de delil takibini de bozar.

Ceza boyutu: TCK 244 ile kişisel veri suçu birbirinden nasıl ayrılır?

Şifreleme veya kayıt silme iddiasının sistem ve veri üzerindeki unsurları TCK 244 incelemesinde, logdan fail atfına geçişteki sınırlar ise IP adresi ve dijital delil yazısında ayrıntılandırılmıştır. Şirket olayında bu iki incelemeye veri sorumlusunun bildirim kararı da eklenir.

Şirketin dosyalarının şifrelenmesi, hizmetin kesintiye uğraması veya kaydın silinmesi bakımından TCK 244’teki sistemin işleyişini engelleme, bozma ve veriler üzerindeki seçimlik hareketler gündeme gelebilir. Dışarı aktarılan veri gerçek kişilere aitse TCK 136’daki kişisel verileri hukuka aykırı verme, yayma veya ele geçirme yönünden de ayrı soru doğabilir. Aynı saldırı dizisinin birden fazla normla ilişkilendirilebilmesi, her normun unsurlarının otomatik gerçekleştiği anlamına gelmez. Kim girdi, hangi veri üzerinde ne yaptı, hangi amaçla ve hangi delille bağlantı kuruluyor? Ceza dosyası bu fiilleri ayırmalıdır. Adalet Bakanlığının Türk Ceza Kanunu derlemesi 244 ve 136’nın ayrı koruma alanlarını gösterir.

Yargıtay 8. Ceza Dairesinin 29 Şubat 2024 tarihli, E.2022/4121 K.2024/2002 sayılı kararı, şirkete uzaktan erişilerek dosyaların şifrelenmesi ve şifrenin verilmesi karşılığında 250 avro değerinde sanal ödeme alınıp bu ödemenin sanığın telefonuna yönlendirilmesi olgularını içeren TCK 244/4 dosyasında temyiz incelemesidir. Mahkûmiyetin düzeltilerek onanması, fidye yazılımı olayında sisteme erişim, dosyaların etkilenmesi ve haksız çıkar ilişkisini somut delille anlatmanın önemini gösterir. Karar, her fidye notunda aynı fıkranın uygulanacağı veya kişisel veri ihlalinin mutlaka yaşandığı sonucunu vermez. Veri sızması iddiası varsa onun izi ayrı aranır. Bu ayrıntılı olgu farkları fidye yazılımı ve kripto fidye rehberinde ayrıca ele alınır.

Şikâyet için şirketin yalnız zarar tutarını söylemesi yeterli olmaz. Yetkisiz oturumun zaman aralığı, değişen dosya örnekleri, etkilenen işlev, saldırganın kullandığı hesap veya altyapı, fidye mesajının özgün hâli ve korunan teknik kayıtlar açıklanır. Failin kimliği henüz bilinmiyorsa IP adresini, kripto cüzdanını veya e-posta adresini gerçek kişi adı gibi sunmayın. Bunlar araştırma izidir. Servis sağlayıcıda bulunan kayıtların korunmasını ve usulünce teminini istemek, şirketin elindeki verilerle bağ kurmayı mümkün kılar. KVKK bildirimi ise ceza şikâyetinin yerini almaz; farklı amaç, muhatap ve ispat soruları vardır.

Olay kapandıktan sonra hangi kararlar dosyada kalmalı?

Sistem yeniden çalıştığında olay bitmiş görünür; oysa birkaç hafta sonra ikinci bir olay veya bir ilgili kişi başvurusu önceki kararları sınar. Kullanılan geçici hesapların kapatılması, yeniden verilen yetkiler, etkilenen yedeklerin durumu, müşterilere söylenenlerle son teknik bulgular arasındaki fark ve Kurula verilen ek bilgilerin tarihleri tek dosyada tutulmalıdır. Saldırganın hareketini engelleyen önlem ile kalıcı açığı kapatan önlem aynı şey olmayabilir. Giriş anahtarı değişti diye erişime izin veren yanlış yetki modeli düzelmiş sayılmaz.

Kurulun 2020/216 sayılı bilişim şirketi kararı özeti, çift faktörlü doğrulama, erişim sertifikaları ve logların zaman damgası gibi önlemlerin ihlalden sonra devreye alınmasını; ihlal öncesi güvenlik tedbirlerinin yeterliliği değerlendirmesinde dikkate aldı. Buradan her şirkete aynı ürün listesini kopyalamak çıkmaz. Öğrenilecek şey, olay öncesi kararların, uyarıların ve denetimin izlenebilir olmasıdır. Kurulun 2020/359 sayılı banka kararında da geç tespit ve geç bildirim ayrı sorunlar olarak tartışıldı. Bir olay raporu yalnız “hangi güvenlik aracı alınacak?” sorusuyla bitmemeli; alarmı kimin gördüğü, niçin geç yükselttiği ve hangi veri kümesinin görünmez kaldığıyla tamamlanmalıdır.

Son olay dosyası beş parçayı birbirine bağladığında değerli olur: ham kayıtların kaynağı, doğrulanmış zaman çizelgesi, kişisel veri etkisi ve bildirim kararı, ceza/özel hukuk için delil talepleri, düzeltici tedbirlerin uygulanma kaydı. Bunların biri değişirse diğerine etkisi yeniden yazılır. Örneğin sonradan yeni bir veri tabanı erişimi bulunması, etkilenen kişi listesini ve daha önceki açıklamayı güncellemeyi gerektirebilir. Şirketin güvenilirliği, ilk gün her ayrıntıyı bilmesinden değil; neyi bildiğini, neyi henüz bilmediğini ve yeni bulgu geldiğinde neyi değiştirdiğini gösterebilmesinden doğar.