Production'dan Veri Talepleri Nasıl Yönetilir?

Kurumların kişisel veri koruma yatırımlarının büyük kısmı dışarıdan gelen saldırıya karşı yapılır. Oysa çoğu veri, kapıdan izinle ve iyi niyetle çıkar: bir iş birimi müşteri listesi ister, biri sorguyu yazar, sonuç Excel olarak kaydedilir ve e-postayla gönderilir. Bu akışta kötü niyet yoktur ama kontrol de yoktur.

Neden En Geniş Sızıntı Kapısı Burası?

Üç nedeni var. Birincisi hacim: bu talepler günlük hayatın parçasıdır, haftada onlarca kez gelir. İkincisi görünmezlik: talep bir bilet sisteminde değil, mesajlaşma uygulamasında ya da koridorda başlar. Üçüncüsü sorumluluğun dağılması: talebi eden veriyi kendi bilgisayarına indirir, dosya oradan başka yerlere gider ve kimse dosyanın nerede olduğunu takip etmez.

Yedi Adımlı Süreç

1. Talep kaydı

Sorgu, gerekçe ve alıcı bilgisi tek bir kayıtta toplanır. Gerekçe alanı zorunlu olmalıdır çünkü denetimde "neden gerekliydi" sorusunun cevabı budur. Sorgunun metni de kayıtta durmalıdır; onaylanan sorgu ile çalıştırılan sorgu arasındaki fark denetimin en zayıf noktasıdır.

2. Otomatik inceleme

Sorgu çözümlenir ve hangi tablolara dokunduğu çıkarılır. Kritik olarak işaretlenmiş bir tabloya dokunan sorgu farklı bir onay yoluna girer. Bu adım metin arama ile değil cümle yapısı üzerinden yapılmalıdır; aksi halde bir alt sorgu ya da birleştirme kolayca gözden kaçar.

3. Politika tabanlı onay

Onay derinliği talebin içeriğine göre değişmelidir. Sıradan bir rapor sorgusu tek onayla ilerlerken, kritik tabloya dokunan veya maskesiz çıktı isteyen bir talep ikinci bir onay gerektirebilir. Sabit tek adımlı onay iki hatayı birden yapar: basit talepleri yavaşlatır, riskli talepleri hafife alır.

4. Hassas kolon tespiti

Tespit iki yoldan yapılmalıdır. Kolon adı üzerinden katalog eşleşmesi hızlıdır ve boş kolonları bile yakalar. İçerik taraması ise kataloğa girmemiş kolonları bulur. Yalnızca birine güvenmek boşluk bırakır: içerik taraması boş kolonu göremez, katalog ise adı tahmin edilemeyen kolonu kaçırır.

5. Maskeleme ve kararın kaydı

Maskeleme yapıldığı kadar yapılmadığı da kayda geçmelidir. "Bu kolon neden maskelenmedi" sorusuna cevap veremeyen bir sistem, denetimde maskeleme yaptığını da kanıtlayamaz. Kolon bazında karar ve gerekçe saklanmalıdır.

6. Şifreli teslim

Sonuç dosyası şifrelenmiş olarak teslim edilmeli ve alıcı adresi doğrulanmalıdır. İlk kez kullanılan bir alıcı adresine teslim, ayrı bir onay gerektirmelidir; yazım hatası ya da kasıtlı yönlendirme çoğu zaman burada yakalanır.

7. İndirme takibi

Dosyanın kim tarafından, ne zaman indirildiği kayıt altına alınmalıdır. Bu adım olmadığında süreç "teslim edildi" noktasında biter ve verinin gerçekten kime ulaştığı bilinmez.

Maskeleme Kararı Nasıl Verilir?

Maskelemenin en büyük düşmanı yanlış pozitiftir. Sipariş numarasını kart numarası sanan bir sistem kısa sürede güvenilirliğini kaybeder ve ekip kuralı kapatır. Bu yüzden desen eşleşmesi tek başına yeterli değildir; doğrulama algoritması gerekir.

Bir başka kritik nokta kolon takma adlarıdır. Sorguda kolona farklı bir ad verilirse yalnızca sonuç kolonunun adına bakan bir sistem kandırılabilir. Bunu engellemenin yolu, kolonun kaynağını talep kaydedilirken saklamak ve çalıştırma anında bu bilgiyi kullanmaktır.

Ekipten Gelecek Dört İtiraz

"Bu süreç işi yavaşlatır." Yavaşlatan şey süreç değil, her kararın bir kişiye sorulmasıdır. Politika kararı üstlendiğinde sıradan talepler daha da hızlanır çünkü kimseyi beklemez.

"Maskelenmiş veriyle iş yapamayız." Bazı analizler gerçek değer gerektirir, doğru. O yüzden maskesiz talep yasak değil, ek onaya bağlı olmalıdır. Fark şudur: istisna görünür olur ve sayısı ölçülebilir.

"Test ortamında zaten gerçek veri yok." Bu cümle çoğu kurumda doğru değildir. Doğruysa bile ortam bazında rejim tanımlayarak kanıtlanmalıdır: sunucu gevşetildiğinde gerekçe yazılmalı ve muaf ortamlar listelenmelidir.

"Zaten kimse kötü niyetli değil." Süreç kötü niyete karşı değil, kazalara ve unutulmuş dosyalara karşıdır. Yanlış adrese giden tek bir e-posta, iyi niyetli bir ekipte de olur.

Kontrol Listesi

Sık Sorulan Sorular

Veri talebini e-posta yerine bir süreçle yönetmek işi yavaşlatmaz mı?

İlk hafta biraz yavaşlatır, sonrasında hızlandırır. E-posta yolunda her talep sıfırdan tartışılır: hangi kolonlar, kim onaylayacak, nasıl teslim edilecek. Süreçte bu kararlar bir kez verilir ve tekrar eden talepler kendiliğinden akar. Asıl kazanç ise talebin kimde beklediğinin görünür olmasıdır.

Maskeleme kararını kim vermeli, veritabanı ekibi mi talep eden mi?

Hiçbiri tek başına vermemeli. Hangi kolonun hassas olduğu bir sınıflandırma kararıdır ve veri sahibine aittir; kararın bir kez verilip her talepte tekrar uygulanması gerekir. Talep eden yalnızca maskesiz veriye neden ihtiyacı olduğunu yazar, bu istisnayı onaylamak ayrı bir yetkidir.

Sonuç dosyasını e-postayla göndermek güvenli mi?

Dosya şifreli bir arşivde gidiyorsa ve parola aynı kanaldan gitmiyorsa makul bir çözümdür. Parolanın dosyayla aynı e-postada gitmesi şifrelemeyi anlamsız kılar. En sıkı yaklaşım dosyayı portalden indirtmek ve parolayı ayrı bir kanaldan vermektir; ikisi arasındaki seçim kurumun risk iştahına bağlıdır.