PostgreSQL Row-Level Security Politikaları

Giriş ve niyet
PostgreSQL’in Row-Level Security (RLS) özelliği, tablolar üzerinde satır düzeyinde erişim kontrolü uygulamanıza olanak tanır. Geleneksel GRANT/REVOKE izinlerinin ötesinde, hangi satırların hangi kullanıcılar tarafından görülebileceğini belirleyen politikalar tanımlamanızı sağlar. Bu mekanizmayı doğru tasarlamak, minimum ayrıcalık prensibini güçlendirmek ve çok kullanıcılı uygulamalarda hatalı veri sızıntılarını önlemek açısından kritiktir.

Temel kavramlar ve kurulum adımları

• enable RLS on: RLS’i aktifleştirmek için tablo üzerinde ALTER TABLE … FORCE ROW LEVEL SECURITY komutu kullanılır. Bu adım, varsayılan olarak tüm satırları saklar ve politikalar eklenene kadar erişim engellidir.
• POLICY: Her bir politika, hangi kullanıcılar (veya roller) için hangi satırları görmeye/yetkilenmeye izin verir, hangi yük altında uygulanır (USING, WITH CHECK).
• USING ifadesi: SELECT fiili için hangi satırların görünür olduğunu belirler. Örneğin: USING (tenant_id = current_setting('myapp.tenant_id')::int).
• WITH CHECK ifadesi: INSERT/UPDATE sırasında hangi yeni satırların geçerli olduğunu belirtir. Örneğin: WITH CHECK (tenant_id = current_setting('myapp.tenant_id')::int).
• SECURITY DEFINER: Fonksiyonlar içinde çağrılan güvenlik bağlamını değiştirebilir; bu, karmaşık iş akışlarında dikkatli kullanılmalıdır.

Pratik örnekler ve iyi uygulamalar

• Çok kiracılı (multi-tenant) bir uygulamada her müşterinin kendi tenant_id’siyle sınırlı veri erişimi: RLS politikalarını hem SELECT hem de INSERT/UPDATE için net tanımlayın. Örneğin:
  USING (tenant_id = current_setting('myapp.tenant_id')::int)
  WITH CHECK (tenant_id = current_setting('myapp.tenant_id')::int).
• Roller arası ayrım: Yönetici rollerinin tüm veriye erişimi olması gerekiyorsa, özel bir policy ekleyin veya tabloya farklı bir görünüm üzerinden erişim sağlayın.
• Performans endişeleri: Kural sayısını minimumda tutun, özellikle büyük tablolar için composite indexlerle USING/WHERE ifadelerinin etkililiğini test edin.
• Güvenlik açısından denetim: Loglayın hangi politikaların hangi kullanıcı için tetiklendiğini ve yanlış konfigürasyonları tespit edin. Güçlü bir test seti kurun ve tüm rol/operasyon kombinasyonlarını kapsayın.

Uygulama tasarlarken dikkat edilmesi gereken noktalar

• Varsayılan davranışı belirleyin: RLS açık mı, yoksa kapanık mı? Genelde açık olan bir ortamda güvenlik politikaları yazılmalı ve güvenlik açığı riskine karşı test edilmelidir.
• Zorlayıcı politikalar: INSERT ve UPDATE için WITH CHECK ifadelerini her zaman düşünün; aksi halde kullanıcılar beklenmedik satırları değiştirebilir.
• Fonksiyonlar ve dinamik izinler: Kapsamlı testler ve güvenlikdenetimleri ile hangi kullanıcı bağlamının hangi değerleri taşıdığını netleştirin.

Sorular ve deneyim paylaşımı
RLS politikalarını hayata geçirirken karşılaştığınız en büyük zorluklar neler oldu? Belirli bir senaryoda (örneğin paylaşımlı veritabanında tenant izolasyonu) hangi yaklaşımı benimsediniz ve neden? Ayrıca performans sorunları yaşadıysanız hangi ölçümleri yaptınız ve hangi optimizasyonları uyguladınız?

Bu konudaki deneyimlerinizi, karşılaştığınız edge-case’leri ve hangi PostgreSQL sürümünde neyi kullandığınızı paylaşırsanız, herkes için faydalı olur. Ayrıca örnek politikalarınızı veya şemayı paylaşabilir misiniz?