PostgreSQL RLS: SaaS Veri İzolasyonu Nasıl Test Edilir?

RLS’nin hangi sınırı koruduğunu yazın

RLS politikaları belirli satırların okunması veya değiştirilmesi için kurallar tanımlar. PostgreSQL’de tablo sahibi, süper kullanıcı ve BYPASSRLS gibi özel rollerin davranışı önemlidir; tablo sahibine politika uygulama seçenekleri de ayrıca bulunur. Bu istisnalar incelenmeden RLS etkinleştirme güvenlik kanıtı sayılmamalıdır. [1]

Uygulamanın veri tabanına hangi rolle bağlandığını kaydedin. Geliştirme ortamında geniş yetkiyle çalışan sorgunun üretimde de aynı şekilde çalışması istenmeyebilir. Politikanın gerçekten uygulandığı rol ile test yapılmalıdır.

Tenant bağlamının kaynağını doğrulayın

Müşteri kimliği tarayıcıdan geldi diye güvenilir kabul edilmemelidir. Kimliği doğrulanmış kullanıcının ilgili kuruluşa üyeliği uygulama katmanında değerlendirilmelidir. Ardından veri erişiminde kullanılacak bağlam güvenli biçimde oluşturulur. RLS, yanlış bağlamın doğruymuş gibi atanmasını otomatik olarak düzeltemez.

Bağlantı havuzu kullanılıyorsa bir müşterinin bağlamı sonraki müşterinin isteğine taşınmamalıdır. Bağlamın işlem kapsamına bağlanması, temizlenmesi ve eksik olduğunda güvenli davranması test edilmelidir. Hangi yöntem seçildiyse tüm sorgu yollarının aynı kurala uyduğu doğrulanmalıdır.

Örnek: A şirketinden sonra B şirketinin isteği geliyor

Varsayımsal bağlantı havuzunda aynı veri tabanı bağlantısı iki farklı müşterinin isteğini sırayla yürütüyor. İlk isteğin bağlamı temizlenmediyse ikinci istek yanlış satırları görebilir. Test, aynı bağlantının yeniden kullanıldığı koşulu özellikle oluşturmalıdır; iki ayrı bağlantıyla yapılan basit test problemi kaçırabilir.

Bu testler yetkili geliştirme ortamında sentetik verilerle yürütülmelidir. Canlı müşteri kayıtlarını gereksiz yere test verisine kopyalamayın.

Okuma ve yazma politikalarını ayrı inceleyin

Bir kullanıcı başka müşterinin satırını okuyamıyor olabilir ama kayıt oluştururken farklı müşteri kimliği yazabiliyor olabilir. Okuma filtresiyle yeni veya güncellenen satırın uygunluğunu denetleyen koşullar aynı ihtiyacı karşılamaz. PostgreSQL politikalarında USING ve WITH CHECK davranışları bu nedenle dikkatle değerlendirilmelidir. [1]

Test seti seçme, ekleme, güncelleme ve silmeyi kapsasın. Müşteri kimliğinin güncellemeyle değiştirilmesi ve başka kuruluşa ait kayıtla ilişki kurulması gibi durumlar ayrıca incelensin. İlişki kısıtları ve uygulama kuralları RLS ile birlikte tasarlanmalıdır.

Arka plan işlerini ve raporları unutmayın

Kuyruk çalışanları, toplu raporlar ve dışa aktarma işleri bazen farklı veri tabanı rolleri kullanır. Web uygulamasında doğru çalışan politika bu yollar için otomatik güvence değildir. Her işte müşteri bağlamı ve gerekli erişim kapsamı açık olmalıdır.

İşlem izolasyonu, eşzamanlı sorguların gördüğü veriyi etkileyebilir. [2] Özellikle uzun raporlar ve yetki değişimleri sırasında hangi davranışın beklendiğini yazın. Önbellek, arama indeksi ve dosya depolama gibi veri tabanı dışı katmanların da müşteri sınırını ayrıca koruması gerekir.

Performans testini güvenlik testinden ayırmayın

Politika koşullarının sorgu planlarına etkisi temsilî veriyle ölçülmelidir. Küçük geliştirme tablosunda hızlı çalışan sorgu büyük veri kümesinde farklı davranabilir. İndeks ve ilişki tasarımı gerçek sorgularla değerlendirilmelidir; performans için politikayı devre dışı bırakmak çözüm olarak kabul edilmemelidir.

Teslimde kullanılan roller, politikalar, bağlam yaşam döngüsü ve olumsuz erişim testleri bulunsun. “RLS kullanıyoruz” ifadesi yerine hangi veri yollarının hangi kanıtla sınandığı açıklansın. Bu çalışma bağımsız güvenlik sertifikasyonu yerine geçmez.

Sık sorulan sorular

### RLS uygulama yetkilendirmesini gereksiz kılar mı? Hayır. Kullanıcı üyeliği, işlem yetkisi, dosyalar ve diğer servisler ayrı kontrol gerektirir. RLS veri katmanında ek bir sınır sağlar.

Yönetici rolüyle test yapmak yeterli mi?

Hayır. Özel roller politikaları atlayabilir. Üretimde kullanılan sınırlı uygulama rolü ve gerçek bağlantı havuzu davranışıyla test yapılmalıdır.