Çok kiracılı mimari: şirket verisi nasıl ayrılır?

Bulut tabanlı bir intranet satın alırken sorulması gereken en teknik ama en önemli soru şudur: benim şirketimin verisi, başka bir şirketin verisinden nasıl ayrılıyor?

Cevap "elbette ayrı" olur ama nasıl ayrıldığı, güvenlik açısından çok farklı seviyeler anlamına gelir.

Üç yaygın model

1. Ayrı veritabanı. Her müşteri için ayrı bir veritabanı. En güçlü izolasyon, en yüksek işletme maliyeti. Yüzlerce müşteride yönetimi zorlaşır: her göç işlemi, her yedekleme ayrı yürütülür.

2. Ayrı şema. Tek veritabanı, müşteri başına ayrı şema. Orta yol; izolasyon iyi, yönetim daha kolay.

3. Paylaşımlı tablo. Tek veritabanı, tek tablo seti; her satırda bir kiracı kimliği. En yaygın model, en verimli kaynak kullanımı — ve doğru kurulmazsa en riskli olan.

Üçüncü model kötü değildir; SaaS dünyasının büyük kısmı böyle çalışır. Belirleyici olan, filtrelemenin nerede yapıldığıdır.

Kritik ayrım: filtre nerede?

Uygulama katmanında filtreleme. Kod her sorguya "ve kiracı kimliği şu olsun" koşulunu ekler. Çalışır — ta ki bir yerde unutulana kadar.

Bu yaklaşımın sorunu, güvenliğin her geliştiricinin her sorguda hatırlamasına bağlı olmasıdır. Yüzlerce sorgu içinde bir tanesinde koşul unutulursa, bir müşteri diğerinin verisini görür. Bu tür hatalar genellikle yıllar sonra ve kötü bir şekilde fark edilir.

Veritabanı katmanında filtreleme. İzolasyon veritabanının kendisine yazılır: satır seviyesi güvenlik politikaları, kullanıcının hangi satırları görebileceğini veritabanı seviyesinde belirler.

Bu modelde, koşulu koymayı unutan bir sorgu bile yanlış veri döndüremez — veritabanı zaten döndürmez. Güvenlik, insan dikkatine değil altyapıya bağlanmış olur.

Neden bu kadar önemli?

Çünkü ilk modelde hata sessizdir. Yanlış filtrelenmiş bir sorgu hata vermez, çökmez, uyarı üretmez; sadece fazladan veri döndürür. Test ortamında tek müşteri varsa fark edilmez bile.

İkinci modelde ise yanlış yazılmış bir sorgu, geliştirme aşamasında boş sonuç döndürerek kendini hemen belli eder.

Satın alırken sorulacak sorular

Bir platform değerlendirirken şunları sormak yerinde olur:

• Veri izolasyonu hangi katmanda sağlanıyor?
• İzolasyonun doğruluğu nasıl test ediliyor?
• Bir müşterinin verisi silindiğinde ne oluyor, yedeklerde ne kadar kalıyor?
• Yedekler şifreleniyor mu, nerede saklanıyor?
• Aktarım ve durağan hâlde şifreleme var mı?
• Bağımsız bir güvenlik denetimi ya da sızma testi yapıldı mı?

Cevapların ayrıntı düzeyi, satıcının konuya ne kadar hâkim olduğunu da gösterir.

Yetki modeli izolasyonun ikinci katmanı

Kiracılar arası izolasyon bir katmandır; kiracı içindeki yetkiler ikinci katmandır. Aynı şirket içinde bordro verisini herkes görmemeli, etik ihbarları yalnızca yetkili kişiler okuyabilmeli.

Bu ikinci katmanın da veritabanı seviyesinde uygulanması gerekir. Arayüzde bir alanı gizlemek bir güvenlik önlemi değildir: veri yine gönderilmiştir, yalnızca gösterilmemiştir.

Anonimlik gerektiren akışlarda kural daha da katıdır. Etik ihbar hattında kimliğin gizli kalması, arayüzün göstermemesiyle değil, kimliğin hiç kaydedilmemesiyle sağlanmalıdır. Bu tasarımı etik ihbar hattı kurulumu yazısında ele aldık.

Barındırma yeri

KVKK açısından verinin nerede işlendiği ve saklandığı ayrı bir sorudur. Yurt dışına aktarım yapılıyorsa, aktarımın hukuki dayanağının bulunması gerekir.

Bu, teknik izolasyondan bağımsız bir yükümlülüktür: veri mükemmel biçimde izole edilmiş olabilir ama aktarım şartları sağlanmamış olabilir. KVKK uyumlu intranet yazısında bu çerçeveyi anlattık.

Denetim kaydı

İzolasyonun üçüncü ayağı, kimin neye eriştiğinin kaydıdır. Yönetici işlemlerinin, yetki değişikliklerinin ve hassas veri erişimlerinin kayıt altında olması, hem denetim yükümlülüğü hem caydırıcılıktır.

Bu kaydın değiştirilemez olması ve yeterince uzun süre saklanması gerekir; aksi hâlde bir olay incelemesinde işe yaramaz.

İstemci tarafında filtreleme neden tehlikeli?

Bazı uygulamalarda izolasyon, tarayıcıda çalışan kodda yapılır: sunucudan gelen listeden kullanıcıya ait olmayan kayıtlar arayüzde elenir.

Bu bir güvenlik önlemi değildir. Veri tarayıcıya ulaşmıştır; geliştirici araçlarını açan ya da ağ trafiğine bakan herkes görebilir. Görünmeyen bir şey, gönderilmemiş bir şey demek değildir.

Aynı ilke arayüzde gizlenen düğmeler için de geçerlidir: bir işlemi başlatan düğmeyi gizlemek, o işlemin yapılamayacağı anlamına gelmez. Kısıt her zaman sunucuda ya da veritabanında olmalıdır.

Fonksiyon yetkileri gözden kaçar

Veritabanı fonksiyonları çoğu sistemde varsayılan olarak geniş yetkiyle açılır. Bir fonksiyonu belirli bir role açmak, onu diğerlerine kapatmaz — açıkça kapatmak gerekir.

Özellikle yüksek yetkiyle çalışan fonksiyonlarda bu kritik bir ayrıntıdır: böyle bir fonksiyon satır seviyesi güvenliği de atlar. Yanlışlıkla herkese açık bırakılmış tek bir yönetim fonksiyonu, bütün izolasyon tasarımını geçersiz kılabilir.

Bu yüzden yetki denetiminin düzenli yapılması ve yeni eklenen her fonksiyonun varsayılan yetkilerinin gözden geçirilmesi gerekir.

Silme ve saklama

Bir müşteri ayrıldığında verisine ne olacağı sözleşmede yazılı olmalıdır: ne kadar süre saklanacak, sonra silinecek mi, yedeklerden ne zaman düşecek?

KVKK açısından saklama süresinin bir sınırı olması gerekir; süresiz saklama savunulamaz. Öte yandan yedeklerin anında temizlenmesi teknik olarak mümkün olmayabilir; bu durumda sürenin şeffaf biçimde belirtilmesi doğru yaklaşımdır.

Ölçek ve komşu etkisi

Paylaşımlı altyapının bir başka riski, bir müşterinin yoğun kullanımının diğerlerini etkilemesidir. Ağır bir rapor sorgusu, aynı veritabanındaki bütün kiracıları yavaşlatabilir.

Bunun önüne geçmek için kaynak sınırlaması ve ağır işlerin ayrı çalıştırılması gerekir. Satın alma sürecinde performans taahhütlerinin sorulması, bu riskin nasıl yönetildiğini de ortaya çıkarır.