Gizlilik kuralını bir kez entegre et, modül olarak ekle: Meta’nın PrivacyLib’i
PrivacyLib: Privacy Controls at the Data Access Boundary
Meta’da birçok gizlilik gereksinimi aynı soruya iner: bir verinin yalnızca izin verilen yerlere gittiğini kanıtlayabilir miyiz? Bu ölçekte elle yapılan denetimler, sistemler değiştikçe gerçeğin gerisinde kalıyor. Meta bunu altyapının içinde cevaplayan Privacy Aware Infrastructure (PAI) geliştirmiş; veri anlama, data lineage ve bilgi akışı kontrolü sağlayan Policy Zones daha önceki yazılarda anlatılmıştı. Bu yazı sürecin son aşamasını, veri akışlarını sürekli uygulama ve izleme işini yapan PrivacyLib’i anlatıyor: yüzlerce veri ve işleme sisteminin client’larının içinde, veriye erişilen noktada çalışan ortak bir kütüphane.
Önceki durum. Her gereksinim için, her sistemin client’ına ayrı bir enforcement entegrasyonu yazılıyordu. Yeni bir gereksinimi (örneğin purpose limitation ya da data flow discovery) tüm sistemlere yaymak aylar alabiliyordu. Her yeni gereksinimin aynı yeteneklere ihtiyacı vardı: geniş sistem kapsamı, aylar yerine haftalarda yayın, her veri erişiminde latency sorunu yaratmadan çalışma ve filoyu düşürmeden enforcement değişikliği yayma.
Çözüm: entegrasyon ile gereksinimi ayırmak. Her sistem PrivacyLib’e bir kez entegre ediliyor. Bir gereksinim veriye erişim noktasında karşılanabiliyorsa, o gereksinim zaten entegre olan tüm sistemlerin paylaştığı bir modül olarak yazılıyor. İki tür modül var: enforcing modüller bir erişimi engelleyebilir (Policy Zones purpose limitation’ı bu yolla uygular); observing modüller yalnızca erişimi kaydeder (Privacy Probes, veri akışlarını keşfetmek için runtime sinyallerini toplar). Internal AI agent’lar veriye yeni bir yoldan eriştiğinde bir Agent Observability modülü eklendi ve PrivacyLib’e zaten entegre olan sistemler bunu yeni bir entegrasyon işi olmadan aldı. Yazının cümlesi: her yeni gizlilik yeteneği bir proje değil bir modül olarak geliyor. Agent’ların veri erişim yolları önceden bilinmeyebileceğinden, desteklenen yollardaki tool call’lar agent bağlamını PrivacyLib’e taşıyor; bu bağlam her erişimi kendi session’ına bağlıyor, böylece modüller veri kullanımını gözlemleyip izin verilmeyen işlemleri engelleyebiliyor.
Ölçek ve mühendislik zorlukları. PrivacyLib yüzden fazla veri erişim kütüphanesi (key/value store’lardan AI özelliklerine kadar), production’da binlerce servis ve onların farklı kütüphane sürümleri, günde milyonlarca asset ve saniyede milyarlarca kontrol üzerinde çalışıyor. Üç sorun öne çıkıyor. Coverage: bir sistemin birden çok client kütüphanesi, eski entegrasyonları, doğrudan ağ çağrıları ve arkadaki depoya doğrudan erişimi olabilir; gereksinimin hangi yoldan gelinirse gelinsin tutması için hepsinin ele alınması gerekiyor. Scale: saniyede milyarlarca kontrolde, kontrol başına küçük bir maliyet bile tüm filoda ağır hâle geliyor; gereksinimler build zamanında en basit değerlendirilebilir biçimlerine derleniyor. Reliability: gizlilik mantığı kritik sistemlerin hot path’inde çalışıyor ve sistemlerin sahipleri kendi takvimlerinde yayın yapıyor; bir değişikliğin kendi başına test edilebilir ve geri alınabilir olması gerekiyor, çünkü fleet-wide rollback kurtarma yolu olamaz. Bu yüzden değişiklikler modül bazında simüle edilip yayılıyor.
Örnek: mesajlaşma metadata’sı. Messenger’ın backend’i, içeriği olmayan mesaj metadata’sını (örneğin iletim izleri) işleyen birçok servis içeriyor ve bunlar bir Logger kütüphanesiyle data warehouse tablolarına yazıyor. Kayıt yazılmadan önce Logger içindeki PrivacyLib entegrasyonu Policy Zones’u çağırıyor. İlginç bir tasarım kararı: verinin gizlilik annotation’ı (MESSAGING_TRAFFIC_METADATA) o tabloya yazan servislere değil, hedef tablonun konfigürasyonuna bağlanıyor. Çünkü bir hedefin birçok yazıcısı olabilir ve her servis annotation’ı ayrı bildirirse bildirimler birbirini tutmayabilir.
Öne çıkanlar
- Kuralı her sisteme tek tek kodlamak yerine, sistemi bir kez entegre edip kuralı modül olarak eklemek yeni gereksinimin maliyetini düşürür.
- Enforcing (engelleyen) ve observing (yalnızca kaydeden) modüller ayrı tutulursa, yeni bir kuralı önce gözlemleyip sonra zorlayabilirsin.
- Veriyi anlatan annotation’ı yazıcıya değil verinin hedefine bağla; tek doğruluk kaynağı olsun.
- Hot path’te çalışan kontrol, kendi başına test edilebilir ve geri alınabilir olmalı; toplu rollback kurtarma yolu değildir.
- Agent’ların erişim yolları önceden bilinmez; her tool call’a agent bağlamını (session) taşımak, erişimi izlenebilir kılar.
Neden önemli?
Gizlilik ve güvenlik kuralları genelde yazılımın dağınık yerlerine serpilir ve zamanla birbirinden ayrışır. Bu yazı, kuralı veriye erişim sınırında merkezî bir kütüphanede toplamanın hem kapsama hem hız hem de güvenilirlik sorunlarını nasıl çözdüğünü gösteriyor.
Pratikte
Küçük bir uygulamada aynı fikri şöyle uygularsın: veriye erişimi doğrudan repository çağrıları yerine tek bir ince katmandan geçir (Spring’de bir AccessPolicy servisi ya da bir interceptor). Hassas alanlara (kişisel veri, ödeme bilgisi) bir annotation koy (@Sensitive(purpose = ...)) ve kontrol bu tek katmanda yapılsın. Yeni bir kuralı önce yalnızca loglayan (observing) modda çalıştır, sonuçlara bak, sonra engelleyen (enforcing) moda al. Böylece yeni bir kuralın canlı trafiği sessizce bozmasını önlersin.
Sözlük
- purpose limitation
- Verinin yalnızca toplandığı amaç için kullanılabilmesi ilkesi.
- data lineage
- Bir verinin nereden geldiğini ve hangi sistemlerden geçtiğini izleyen kayıt.
- enforcing module
- Bir veri erişimini engelleyebilen kontrol modülü.
- observing module
- Erişimi engellemeden yalnızca kaydeden kontrol modülü.
- hot path
- Her istekte çalışan, gecikmeye doğrudan etki eden kod yolu.