Canlı veri test ortamında daha savunmasızdır
Canlı ortam genellikle daha sıkı korunur: erişim sınırlıdır, log tutulur, değişiklikler onaydan geçer. Test ortamı ise çoğu ekipte daha rahat kullanılır. Aynı canlı veri bu daha rahat ortama taşındığında risk büyür.
Bu yüzden “zaten şirket içi” düşüncesi yeterli değildir. Kişisel veri test ortamında da kişisel veridir. Hatta test ortamında daha fazla kişinin erişimi olduğu için risk daha görünür hale gelir.
- Test ortamına kopyalanan veri için amaç ve saklama süresi yazılmalıdır.
- Gerçek e-posta, telefon, kimlik numarası ve adres gibi alanlar maskelenmelidir.
- Maskeleme sonrası uygulama testleri çalışmaya devam etmelidir.
- Test ortamı erişimleri de denetlenmelidir.
Maskeleme, anonimleştirme ve pseudonymization aynı şey değildir
Maskeleme çoğu zaman verinin görünür kısmını değiştirir. Anonimleştirme ise kişiyi geri döndürülemez biçimde ayırt edilemez hale getirmeyi hedefler. Pseudonymization ise kimliği doğrudan göstermeyen ama ek bilgiyle eşleştirilebilen bir yaklaşımdır.
Hangi yöntemin yeterli olduğu hukuki ve teknik değerlendirme gerektirir. Veritabanı ekibinin görevi, alanları sınıflandırmak ve seçilen yöntemi tekrar edilebilir hale getirmektir.
Maskeleme kuralları deterministik olmalı mı?
Bazı testlerde aynı müşterinin farklı tablolarda aynı sahte kimlikle görünmesi gerekir. Bu durumda deterministik maskeleme yararlı olabilir: aynı input aynı maskelenmiş çıktıya döner. Ama bu yaklaşım yanlış uygulanırsa tekrar tanımlama riski doğurabilir.
Bazı alanlarda ise tamamen rastgele üretim daha güvenlidir. Örneğin telefon ve e-posta adreslerinin gerçek dünyaya gönderim yapmayacak şekilde değiştirilmesi önemlidir.
PostgreSQL maskeleme fikri
update users
set
email = concat('user+', id, '@example.test'),
phone = concat('+900000', lpad(id::text, 6, '0')),
full_name = concat('Test Kullanıcı ', id)
where environment_copy = true;Bu örnek basit fikri gösterir. Gerçek maskeleme kuralları veri sınıflandırmasına göre tasarlanmalıdır.
Yedekten test ortamı üretme akışı kontrollü olmalı
Sağlıklı akışta canlı yedek doğrudan geliştirici erişimine açılmaz. Önce izole bir alanda geri yüklenir, maskeleme kuralları çalışır, doğrulama sorguları geçer ve ancak sonra test ortamına taşınır.
Maskeleme sonrası kritik uygulama akışları da test edilmelidir. Çünkü bazen maskeleme e-posta formatını, telefon uzunluğunu, benzersiz indeksleri veya referans ilişkilerini bozabilir.
Test verisi üretim kontrol listesi
Canlı yedek seçildi: İzole restore hedefi açıldı: Maskeleme kuralları çalıştı: Kişisel veri alanları kontrol edildi: Benzersiz indeksler doğrulandı: Uygulama temel testleri geçti: Test ortamı erişimleri sınırlandı: Saklama süresi yazıldı: