Adres verisi gizliliği, çoğu projede en son akla gelen başlıktır; oysa adres, bir kişiyi doğrudan işaret edebilen en güçlü veri türlerinden biridir. Bu yazıda adresin neden kişisel veri sayıldığını, test ortamına gerçek adres taşımanın yarattığı riskleri ve amaç sınırlaması, veri minimizasyonu ve saklama süresi ilkelerinin gündelik geliştirme işlerinde ne anlama geldiğini bulacaksınız.
Adres neden kişisel veri sayılır?
Bir adres, tek başına ya da başka birkaç bilgiyle birleştiğinde bir kişiyi doğrudan tanımlayabilir. Kapı numarası, sokak ve şehir; bir arada oturduğunuz yeri belirtir. Bu bilgi, o kişinin nerede olduğunu, ne zaman evde olabileceğini ve hangi hizmetlere eriştiğini gösterebilir.
Bu yüzden adres, alışveriş verisi ya da tercih verisiyle aynı kategoride değildir. Bir kişinin ilgi alanlarını bilmek ile nerede yaşadığını bilmek arasındaki fark, verinin kötüye kullanıldığında doğuracağı zararın büyüklüğünde görünür. Adres, fiziksel güvenliği doğrudan etkileyebilen bir bilgidir.
İkinci özellik, bir araya geldiği diğer alanlardır. Adres genellikle ad soyad ve telefon ile birlikte toplanır. Bu üçü birlikte, bir kişiyi tanımlamak için başka hiçbir veriye ihtiyaç bırakmaz. Tek başına zararsız görünen bir alan, bu birliktelik içinde çok daha hassas hale gelir.
Üçüncü özellik, değişmezliğidir. Parola değiştirilebilir, kart numarası yenilenebilir; ama adres ancak kişi taşındığında değişir ve eski adres yine geçmişe dönük bir bilgi olarak kalır. Bu yüzden adresin yanlış yere sızmasının etkisi uzun sürelidir.
Gerçek adresleri test ortamına kopyalamak neden risklidir?
Test ortamları, üretim ortamı kadar sıkı korunmaz. Erişim yetkileri daha geniştir, çünkü ekipteki herkesin veriye bakması gerekir. Yedekler daha uzun süre saklanır, çünkü test verisinin geçmiş sürümleriyle karşılaştırma yapılır. Bu koşullarda gerçek adres içeren bir kopya, korunması en zor yerde durur.
İkinci risk, kopyanın çoğalmasıdır. Bir geliştirici veriyi kendi bilgisayarına indirir, başka bir ekip bir rapor için dışa aktarır ve zamanla kaç kopyanın var olduğunu kimse bilemez. Veri ne kadar çoğalırsa, silinmesi ve denetlenmesi o kadar zorlaşır.
Üçüncü risk, amaç dışı kullanımdır. Test için alınan bir kopya, sonradan bir demo ortamında, bir sunumda ya da bir hata kaydının ekinde karşımıza çıkabilir. Her adımda ayrı bir karar alınmadığı için, veri asıl amacının çok dışına taşar.
Bu riskleri ve karşılıklarını şöyle özetleyebiliriz:
- erişim yetkileri: test ortamında daha geniştir, çünkü ekipteki herkesin veriye bakması gerekir
- yedekler: test verisinin geçmiş sürümleriyle karşılaştırma yapıldığı için daha uzun süre saklanır
- kopya çoğalması: kimin elinde kaç kopya olduğu zamanla belirsizleşir
- amaç dışı kullanım: test için alınan bir kopya demo, sunum ya da hata kaydı ekinde ortaya çıkabilir
- karşılığı: test ortamında gerçek adres yerine kurgusal veri kullanmak bu riskleri büyük ölçüde ortadan kaldırır
Bu risklerin hepsi tek bir kararla büyük ölçüde ortadan kalkar: test ortamında gerçek adres yerine kurgusal veri kullanmak. Kurgusal veri gerçek kişileri işaret etmez, bu yüzden sızması durumunda korunması gereken bir kişi yoktur.
Amaç sınırlaması ve veri minimizasyonu ne demek?
Amaç sınırlaması, toplanan verinin yalnızca belirtilen amaç için kullanılması anlamına gelir. Adres, siparişi teslim etmek için toplandıysa, aynı veriyi bir pazarlama kampanyası için kullanmak bu ilkeye aykırıdır. Veriyi ikinci bir amaç için kullanmak istiyorsanız, bunun için ayrı bir dayanak gerekir.
Veri minimizasyonu ise yalnızca gerçekten gereken alanları toplamaktır. Bir kargo gönderimi için ülke, şehir ve sokak yeterliyken doğum tarihini zorunlu tutmak gereksizdir. Her ek alan, verinin korunması gereken yüzeyini büyütür. Bu yüzden formu tasarlarken her alanın hangi işi çözdüğünü sorabilmek gerekir.
Bu iki ilke birlikte, formun şeklini de belirler. Alan eklemek kolaydır, ama alanı sonradan kaldırmak zordur; çünkü o alan bir yere bağlanmış olur. Bu yüzden ilk tasarımda ölçülü davranmak, sonradan yapılacak temizlikten çok daha ucuzdur.
Test verisi bu ilkelerin dışında değildir. Test amacıyla toplanan bir veri de bir amaca bağlıdır ve o amaç dışında kullanılmamalıdır. Kurgusal veri kullanmak, bu ilkeyi baştan uygulamanın en basit yoludur.
Saklama süresi ve maskeleme nasıl uygulanır?
Saklama süresi, verinin ne kadar tutulacağını ve sonunda ne olacağını tanımlar. Sipariş kaydı için adres, mevzuatın gerektirdiği süre boyunca saklanır. Bu süre dolduğunda veri silinmeli ya da geri döndürülemez biçimde anonim hale getirilmelidir. Süreyi belirsiz bırakmak, veriyi sonsuza kadar tutmak anlamına gelir.
Maskeleme, verinin bir bölümünü gizleyerek kullanılabilirliği korumaktır. Bir destek ekranında adresin yalnızca son bölümünü göstermek, hem kaydın doğrulanmasını sağlar hem de tüm bilgiyi açığa çıkarmaz. Maskelemenin kuralı, hangi alanın ne kadarının görüneceğinin önceden tanımlanmış olmasıdır.
Maskelemenin yetersiz kaldığı bir durum vardır: bir araya gelen parçalar. Ayrı ayrı gizlenen alanlar, birlikte kişiyi tanımlamaya yetebilir. Bu yüzden maskeleme kararını alan alan değil, kaydın bütünü üzerinden vermek gerekir.
Günlükler ve hata kayıtları da bu kapsamdadır. Bir sunucu günlüğüne tam adres yazmak, veriyi en az korunan ortama taşımak demektir. Günlükler genellikle uzun süre saklanır, geniş bir ekip tarafından okunur ve arama araçlarıyla taranır. Adresin buraya düşmemesi ayrı bir kontrol gerektirir.
Kurgusal veri hangi sınırlar içinde kullanılmalı?
Kurgusal veri, gerçek kişisel verinin yerine geçmek için üretilir; ama onun da bir kullanım sınırı vardır. Bu veri yalnızca yazılım testi, form demosu ve gizlilik koruması içindir. Gerçek bir gönderiyi yönlendirmek, bir hizmete erişim sağlamak ya da bir doğrulama adımını atlatmak için kullanılamaz.
Üretilen kayıtların gerçek bir konuta, binaya ya da alıcıya karşılık gelmediğini varsaymak gerekir. Bu varsayım, kaydın kullanım amacını doğrudan belirler. Adres satırı, kurgusal olduğu bilinen bir veriyi taşır; bu yüzden hiçbir teslimat senaryosunda gerçek bir muhatap bulmaz.
Bu sınırı ekibe anlatmanın en etkili yolu, veriyi işaretlemektir. Kaydın kurgusal olduğunu gösteren bir alan ya da tutarlı bir ön ek, verinin yanlış kullanılmasını büyük ölçüde engeller. İşaret, hem teknik bir önlem hem de bir ekip kuralıdır.
Geliştiriciler için: veri akışını tasarlamak
Gizlilik kararlarını kodun içine dağıtmak yerine, veri akışını tek bir yerde tanımlayın. Hangi veri nerede toplanıyor, nerede saklanıyor, kim erişebiliyor ve ne zaman siliniyor? Bu dört sorunun cevabı yazılı olduğunda, sonradan eklenen her yeni alan mevcut kurallarla karşılaştırılabilir.
Üretim verisini test ortamına taşımayı varsayılan yol olmaktan çıkarın. Bunun yerine kurgusal veri üretmeyi kolaylaştırın; bir komut ya da tek bir ekran, istediğiniz ülkeden ve istediğiniz senaryodan kayıt üretmelidir. Kolay yol hangisiyse ekip onu seçer; bu yüzden kurgusal veri yolunu üretimden kopyalamaktan daha kolay hale getirmek gerekir.
Günlük ve hata kayıtlarını yazarken alanları bilinçli seçin. Bir kaydın hangi alanlarının günlüğe yazılacağını açıkça belirtin; tüm istek gövdesini yazmak, kaçınılmaz olarak gereksiz veri toplar. Aynı kural, üçüncü taraf hata izleme araçları için de geçerlidir.
Silme işlemini test edin. Verinin süresi dolduğunda gerçekten silindiğini doğrulayan bir senaryo, gizlilik çalışmalarının en sık atlanan parçasıdır. Silme yalnızca ana kaydı değil, kopyaları, yedekleri ve türetilmiş kayıtları da kapsamalıdır.
Sonraki adımlar
Gizlilik çalışmasına en görünür yerden başlayın: test ve geliştirme ortamlarında gerçek adres bulunup bulunmadığını kontrol edin ve bulduğunuz kayıtları kurgusal veriyle değiştirin. Bu geçişi kolaylaştırmak için adres üretici sayfasından ülke bazında kurgusal kayıt üretebilir, kayıtların nasıl saklanacağını ise test verisinde adres kayıtları yazısından okuyabilirsiniz. Kurgusal veri ile gerçek veri arasındaki farkı daha geniş bir çerçevede görmek isterseniz çevrimiçi veri üreticileri ve kurgusal veri yazısı iyi bir devam niteliğindedir.