Supabase ve PostgreSQL RLS ile Çok Şirketli Veri İzolasyonu

Giriş ve Mimari Yaklaşım

Çok şirketli (multi-tenant) yazılım mimarilerinde, farklı müşterilerin verilerinin aynı veritabanı içerisinde güvenli bir şekilde ayrılması kritik bir gereksinimdir. İşletmelerin verilerini korumak ve yasal uyumluluğu sağlamak amacıyla satır seviyesinde güvenlik mekanizmaları devreye alınır. Bu doğrultuda, Sunucu & Bulut Altyapısı kapsamında yönetilen Linux, Docker, Nginx, PostgreSQL ve Supabase self-hosting teknolojileri ile güvenli altyapılar kurgulanmaktadır.

PostgreSQL RLS Temelleri

PostgreSQL altyapısının sunduğu Row Level Security (Satır Düzeyinde Güvenlik - RLS), tablolar üzerindeki verilere erişimi satır bazında filtrelemenizi sağlar. Standart yetkilendirme yöntemleri genellikle tablo düzeyinde kalırken, RLS mekanizması sayesinde aynı tabloyi kullanan farklı tenant yapıları yalnızca kendi verilerini görebilir.

• Tablo seviyesinde güvenlik yerine satır bazlı filtreleme uygulanır.
• SQL sorguları otomatik olarak ilgili şirket filtresiyle çalıştırılır.
• Uygulama katmanındaki olası sızıntı riskleri veritabanı seviyesinde engellenir.

Supabase Üzerinde Tenant İzolasyonu Yapılandırması

Supabase ekosisteminde veri izolasyonu sağlamak için PostgreSQL yetenekleri uçtan uca kullanılır. Kimlik doğrulama süreçleri tamamlandıktan sonra, oturum açan kullanıcının ait olduğu şirket bilgisi veritabanı katmanına iletilir. Bu sayede her sorgu, ilgili kullanıcının yetkileri ve tenant bağlamı ile sınırlandırılır.

Politika Tanımlama Adımları

1. İlgili tabloda RLS özelliğinin aktif hale getirilmesi.
2. Kullanıcının şirket kimliğini doğrulayan PostgreSQL fonksiyonlarının yazılması.
3. SELECT, INSERT, UPDATE ve DELETE işlemleri için uygun politikaların (policies) oluşturulması.

Performans ve Güvenlik Değerlendirmesi

Çok şirketli sistemlerde RLS kullanımı, doğru indeksleme stratejileri ile desteklenmelidir. Şirket ID (tenant id) kolonları üzerinde uygun b-tree indekslerinin tanımlanması, güvenlik politikalarının sorgu performansına olumsuz etki etmesini engeller. Altyapı optimizasyonları ve veritabanı yönetim süreçleri, sistemin kararlılığını doğrudan etkiler.

Varsayımsal Senaryo ve Uygulama Örneği

Bu yaklaşımı somutlaştırmak için iki farklı şirketin (Şirket A ve Şirket B) aynı faturalandırma yazılımını kullandığı hipotetik bir senaryo ele alalım. faturalar tablosunda her kaydın sirket_id kolonu bulunur. Kullanıcılar Supabase üzerinden sisteme giriş yaptıklarında, JWT token içerisindeki app_metadata alanı üzerinden kendi şirket kimliklerini veritabanı oturumuna aktarırlar. Şirket A'nın finans yöneticisi sisteme bağlandığında, PostgreSQL üzerinde tanımlanan RLS politikası otomatik olarak devreye girer ve tüm SELECT sorgularına WHERE sirket_id = current_setting('request.jwt.claim.sirket_id', true) filtresini ekler. Bu sayede kullanıcı, arayüzde ne tür bir filtreleme yaparsa yapsın, fiziksel olarak Şirket B'ye ait bir faturayı sorgulasa bile veritabanı katmanı boş sonuç döndürür veya hata üretir. Bu durum, olası bir uygulama katmanı açığında dahi verilerin sızmasını önler. Ancak burada dikkat edilmesi gereken temel takas, veritabanı yükünün hafifçe artması ve her sorguda bağlam (context) set edilmesinin gerekliliğidir. Yanlış yapılandırılmış bir JWT yapısı, kullanıcıların hiç veriye ulaşamamasına veya yanlış tenant bağlamına girmesine neden olabilir. Bu tür hata senaryolarında, veritabanı logları ve Supabase hata yakalama mekanizmaları kullanılarak oturum bağlamı eksiklikleri anında tespit edilmeli ve kullanıcı güvenli bir şekilde çıkışa yönlendirilmelidir.

Detaylı Uygulama ve Güvenlik Kontrol Listesi

Çok şirketli bir Supabase ve PostgreSQL RLS projesini canlı ortama taşımadan önce eksiksiz uygulanması gereken adımlar şunlardır:

• RLS Etkinleştirme: Hassas verileri barındıran tüm tablolarda ALTER TABLE tablo_adi ENABLE ROW LEVEL SECURITY; komutunun çalıştırıldığından emin olunmalıdır.
• İndeksleme Stratejisi: Her tablodaki sirket_id kolonu üzerinde performans kayıplarını önlemek için B-tree indeksleri tanımlanmalı, sorgu planları (EXPLAIN ANALYZE) ile doğrulanmalıdır.
• Politika Kapsamı: Her işlem türü (SELECT, INSERT, UPDATE, DELETE) için ayrı ayrı politika yazılmalı, özellikle INSERT işlemlerinde WITH CHECK koşullarının unutulmadığı kontrol edilmelidir.
• JWT Entegrasyonu: Supabase auth servisinden gelen token yapısının, veritabanı fonksiyonları tarafından doğru okunduğu ve yetkisiz token'ların reddedildiği test edilmelidir.
• Hata Yönetimi ve İstisnalar: Tenant bağlamı bulunamadığında (örneğin anonim kullanıcılar veya eksik token durumlarında) sistemin çökmek yerine güvenli bir şekilde erişimi reddetmesi sağlanmalıdır.
• Altyapı Güvencesi: Sunucu & Bulut Altyapısı standartlarına uygun olarak Docker ve PostgreSQL container yapılandırmalarının güvenlik güncellemeleri düzenli olarak yapılmalıdır.

Kaynaklar

• Sunucu & Bulut Altyapısı — Cy Logic Software