İçindekiler
Bir veri ihlali fark edildiği anda saat işlemeye başlar. Kişisel Verileri Koruma Kurulu'na yapılacak bildirimde, ihlalin hangi veriyi, kaç kişiyi ve hangi zaman aralığını etkilediği yazılmalıdır. Bu bilgilerin çoğu veritabanında durur ve tam o anda en zor bulunan bilgiler de bunlardır. Bu yazı ihlalin ilk günlerinde veritabanı ekibinden istenecek altı cevabı, her cevabın hangi kayıttan geldiğini ve bu kayıtların ihlalden önce neden kurulmuş olması gerektiğini anlatır.
Bu yazı hukuki görüş değildir; bildirim yükümlülüğünün kapsamı için hukuk ekibinize danışın.
72 Saat Neyi Kapsar
Kişisel Verileri Koruma Kurulu'nun 24.01.2019 tarihli ve 2019/10 sayılı kararına göre veri sorumlusu, ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirimde bulunur; etkilenen kişilere de makul en kısa sürede bildirim yapılır. Kurul'un ihlal bildirim formu ilk bildirim ile takip bildirimini ayırır: bütün bilgiler bu sürede toplanamıyorsa eldeki bilgiyle ilk bildirim yapılır, eksikler takip bildirimiyle tamamlanır. AB'de Genel Veri Koruma Tüzüğü'nün (GDPR) 33. maddesi de denetim makamına bildirim için aynı 72 saati öngörür.
Pratikte bu şu demektir: ilk bildirim, ekibin elindeki kayıtlardan kurulur. Kayıt yoksa bildirime "bilinmiyor" yazılır ve "bilinmiyor" cevabı en geniş varsayımı zorlar: bütün tablo, bütün kişiler, bütün dönem.
Veritabanı Tarafındaki Altı Soru
- Hangi veri? Hangi tablolar, hangi kolonlar okundu ya da dışarı çıktı?
- Kaç kişi? Kaç ayrı kişinin verisi etkilendi?
- Ne zaman? İlk erişim ne zaman oldu, son erişim ne zaman oldu?
- Hangi hesapla, nereden? Hangi oturum açma adı, hangi makine, hangi uygulama?
- Kopya var mı? Veri bir dosyaya ya da başka bir sisteme aktarıldı mı, aktarıldıysa nereye?
- Ne önlem alındı? Hesap kapatıldı mı, yetki geri alındı mı, parolalar değişti mi?
Her Sorunun Cevabı Nerede Durur
| Soru | Kayıt | Ön koşul |
|---|---|---|
| Hangi veri | SQL Server Audit'in hassas tablolardaki SELECT kayıtları (ifade metni dahil) ya da veritabanı etkinlik izleme (DAM) |
İhlalden önce açılmış olmalı |
| Kaç kişi | Kaydedilmiş sorgu metninin olay anına geri yüklenmiş kopyada yeniden çalıştırılması | Sorgu metni ve uygun yedek |
| Ne zaman | Audit, DAM ve oturum açma kayıtlarının zamanları | Saklama süresinin olayı kapsaması |
| Hangi hesap, nereden | Başarılı ve başarısız oturum açma kayıtları (SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP), istemci adresi, uygulama adı |
Sunucu düzeyinde denetim |
| Kopya var mı | Veri çıkarma yollarının kaydı: kim hangi sonucu, hangi dosyayla, kime verdi | Veri çıkarmanın kayıtlı bir yoldan yapılması |
| Ne önlem alındı | Yetki ve hesap değişikliklerinin kaydı (DATABASE_PERMISSION_CHANGE_GROUP, SERVER_PRINCIPAL_CHANGE_GROUP) |
Denetimde bu grupların açık olması |
Tablonun en zayıf satırı "kopya var mı" satırıdır. Veritabanı denetimi kimin hangi sorguyu çalıştırdığını söyler; sonucun bir Excel dosyasına mı kaydedildiğini, e-postayla mı gönderildiğini söylemez. Bu sorunun cevabı ancak veri çıkarma işi kayıtlı bir yoldan yapılıyorsa vardır.
Etkilenen Kişi Sayısı Nasıl Çıkarılır
Bildirimde istenen sayı satır sayısı değil, kişi sayısıdır. Doğru yol şudur: denetim kaydından yetkisiz sorgunun metnini alın, veritabanını olayın yaşandığı ana geri yükleyin (tam kurtarma modelinde zaman noktasına geri yükleme) ve aynı sorguyu bu kopyada kişi anahtarına göre sayın:
-- On a copy restored to the time of the event, never on production: SELECT COUNT(DISTINCT c.CustomerId) AS PeopleAffected FROM dbo.Customer AS c WHERE c.City = N'Izmir'; -- the WHERE clause copied from the audited statement
Olay anına geri yükleme önemlidir: bugünkü veriyle sayılan sonuç, olaydan sonra eklenen ya da silinen kişiler yüzünden yanlış olur. Sorgu metni yoksa yalnız erişilen tablonun toplam kişi sayısı verilebilir ve bu en geniş varsayımdır.
İhlalden Önce Kurulması Gerekenler
- Hassas kolon envanteri. Hangi tablolarda kişisel veri durduğu bilinmeden hangi tablonun denetleneceği seçilemez.
- Hassas tablolarda okuma denetimi. SQL Server Audit ile bu tablolarda
SELECTkaydı; dosyaların SIEM'e taşınması. Var olan bir sunucu denetimine (örnekte adıChangeTrail; kurulumu bu yazıda) şu belirtim eklenir:CREATE DATABASE AUDIT SPECIFICATION SensitiveReads FOR SERVER AUDIT ChangeTrail ADD (SELECT ON dbo.Customer BY public), ADD (SELECT ON dbo.CustomerAddress BY public) WITH (STATE = ON);
- Oturum açma ve yetki değişikliği denetimi sunucu düzeyinde.
- Saklama süresi. İhlaller çoğu zaman haftalar sonra fark edilir; birkaç günlük kayıt yetmez.
- Veri çıkarma için tek bir kayıtlı yol. "Şu sorguyu çalıştır, sonucu bana at" taleplerinin kayıtlı bir süreçten geçmesi.
- Bir prova. Altı soruyu, ihlal yokken, bir test senaryosuyla cevaplamayı deneyin ve kaç saat sürdüğünü ölçün.
SQL Change Guard beşinci maddeyi, yalnız kendi üzerinden açılan veri talepleri için karşılar. Bu taleplerde hangi sorgunun hangi sunucuda çalıştığı, hangi kolonların maskelendiği ve hangilerinin gerekçeyle açık gittiği, sonucun hangi adrese teslim edildiği, dosyanın özeti, dosyayı kimin hangi gerekçeyle indirdiği ve dosyanın ne zaman silindiği kayıttadır. "Query Result Activity" ve "Data Access and Export Log" raporları bunu dönem için tek listede verir. Ürün dışından, doğrudan bir veritabanı aracıyla yapılan okumayı ise ürün görmez; o yol için yukarıdaki denetim kayıtları gerekir.
Sık Sorulan Sorular
72 saat ne zaman başlar?
Veri sorumlusunun ihlali öğrendiği andan başlar, ihlalin gerçekleştiği andan değil. Bu yüzden "ne zaman öğrenildi" de kayda geçirilmelidir; ihlal olay kaydının ilk satırı budur.
Denetim kaydı yoksa ne yazılır?
Bilinmeyen alan bilinmiyor olarak yazılır ve etki en geniş haliyle varsayılır: erişilebilir bütün tablolar ve bütün kişiler. Kayıt sonradan bulunursa bildirim güncellenir. Kayıt uydurulmaz, tahmin kesin bilgi gibi sunulmaz.
Maskeli giden veri de ihlal sayılır mı?
Bu bir hukuki değerlendirmedir. Teknik tarafın görevi, hangi kolonun maskeli, hangisinin açık gittiğini kesin olarak gösterebilmektir; değerlendirme bu bilgiyle yapılır. Kolon bazında karar kaydı bu yüzden önemlidir.
Okuma denetimi her tabloda açılmalı mı?
Hayır. Her tabloda SELECT kaydı ciddi hacim üretir. Kişisel ve özel nitelikli kişisel veri içeren tablolarla sınırlayın; bu yüzden hassas kolon envanteri ilk adımdır.
Veri çıkış kaydını görün
Bir veri talebinin sorgusundan, kolon kararlarından ve teslim adresinden indirme kaydına kadar ihlal anında istenecek bilgilerin nasıl tek listede durduğunu gösterelim.
Demo Planlayın →