Multi-tenant yapıda PostgreSQL satır düzeyi güvenlik — gerçek güvenlik ağı

Netorigo yığını ve Consulting OS'in ikisi de multi-tenant SaaS'tır. Her sorgu tenantId filtresini içermek zorundadır. Çoğu şirket bunu uygulama katmanında çözer — bir middleware veya service katmanı filtreyi otomatik ekler. Bu, vakaların %80'inde işe yarar. Kalan %20'de biri unutur ve Acme müşterisi Beta'nın verisini görür. Bir GDPR ihlali, güveni yok eden, işi bitirebilecek bir olay.

RLS ne sağlar

PostgreSQL Row-Level Security veritabanı düzeyinde bir politikadır: ilgili tablodaki her SELECT, UPDATE, DELETE bir oturum değişkenine göre otomatik filtrelenir. Oturum değişkeni SET LOCAL app.tenant_id = "acme" ise, her sorguya otomatik olarak tenantId = "acme" eklenir. Bir mühendis WHERE koşulunu unutsa da fark etmez — PG motoru onu ekler.

Nasıl bağlıyoruz

• Tenant kapsamlı her tablo: ALTER TABLE ... ENABLE ROW LEVEL SECURITY
• CREATE POLICY tenant_isolation ON <tbl> USING (tenant_id = current_setting("app.tenant_id"))
• NestJS interceptor: her isteğin başında SET LOCAL app.tenant_id = <resolved tenant>
• Süper yönetici rolü BYPASSRLS kullanır — yalnızca denetim bağlamlarında
• Migration testleri: her yeni tablonun RLS'inin açık olduğu doğrulanır

Bedeli

RLS sorguları yaklaşık %5 yavaşlatır (planlayıcı daha fazla filtreyi birleştirir). Bu önemsiz. Asıl sorun: PG bağlantı havuzunun tenant başına sıfırlanması gerekir, aksi halde sonraki istek önceki tenant değişkenini devralır. Bunu, her bağlantıyı havuza SET LOCAL olmadan geri veren bir wrapper service ile çözüyoruz. Bunu unutursanız, sinsi bir hatanız olur.

Çoğu SaaS ekibi, ilk tenant'lar arası sızıntı yaşanana kadar RLS'i gereksiz görür. Bizde hiç yaşanmadı, çünkü 2. günden itibaren açıyoruz. Tavsiyemiz: isteğe bağlı bırakmayın. Sistem multi-tenant ise RLS ekstra güvenlik değil — temel bir gerekliliktir.