PostgreSQL RLS से SaaS tenant data सुरक्षा
PostgreSQL Row-Level Security से tenant data सुरक्षित करें। Restricted database roles, transaction-scoped context, default-deny policies और isolation tests देखें।
इस मार्गदर्शिका में
SaaS में PostgreSQL Row-Level Security क्या है?
PostgreSQL Row-Level Security (RLS) policies तय करती हैं कि database role कौन-सी rows पढ़ या बदल सकता है। Multi-tenant SaaS में यह database के भीतर एक अतिरिक्त सुरक्षा-परत है: सामान्य query में tenant filter छूट जाए तो हर ग्राहक की rows अपने-आप उजागर नहीं होनी चाहिए। RLS, application authorization और table privileges का पूरक है, उनका विकल्प नहीं। RLS चालू हो और लागू policy किसी row को अनुमति न दे, तो सामान्य row access default-deny रहता है।
हर tenant-owned row में स्थिर tenant key रखें
अपरिवर्तनीय tenant ID चुनें और उसे parent तथा child records, files, jobs और audit events में रखें। जहाँ हर row का tenant होना जरूरी है, key को null न होने दें। Foreign keys या अन्य integrity rules से child record को दूसरे ग्राहक के parent से जुड़ने से रोकें। साझा reference data को अलग पहचानें।
Application के हर operation के लिए policy बनाएँ
SELECT policy दिखाई देने वाली rows नियंत्रित करती है, जबकि INSERT, UPDATE और DELETE के लिए लिखने वाले रास्तों की policies भी चाहिए। PostgreSQL में इन फैसलों के लिए USING और WITH CHECK expressions अलग काम कर सकते हैं। Create, read, update, delete, upsert, bulk operation और background job test करें; यह न मानें कि एक policy हर command संभाल लेगी।
Tenant context गायब हो तो request deny होनी चाहिए
सर्वर द्वारा सत्यापित session या job record से authorization के बाद active tenant सेट करें। केवल URL, form या SQL parameter में भेजी गई मनमानी tenant ID पर भरोसा न करें। Context न होने या गलत होने पर policy का व्यवहार तय करें और जाँचें कि वह default या shared tenant पर जाने के बजाय rows रोकती है।
| Table या data path | Tenant key और integrity rule | अनुमत database role | Read/write policy tests | Owner और review date |
|---|---|---|---|---|
| Customer records | ||||
| Child records और attachments | ||||
| Background job data |
SaaS team PostgreSQL RLS को सुरक्षित ढंग से कैसे सेट करे?
Application को सीमित role से चलाएँ, table owner से नहीं
PostgreSQL में table owner सामान्यतः RLS को bypass करता है। Superuser और BYPASSRLS role भी policies से बाहर होते हैं। Migration के लिए अलग owner रखें और application role को सीमित करें ताकि वह policies न बदल सके और privileged role न अपना सके। जहाँ उचित हो FORCE ROW LEVEL SECURITY पर विचार करें; यह superuser या BYPASSRLS को सीमित नहीं करता।
Tenant context उसी database transaction में सेट करें
Connection pool वाले application में transaction-local setting या जाँचे हुए समान तरीके से context सेट करें और transaction खत्म होने से पहले tenant queries चलाएँ। Pooled connection दोबारा इस्तेमाल हो सकती है, इसलिए session state बची रह सकती है। Rollback, exception, retry और connection reuse test करें ताकि अगली request पिछली tenant की context न पा ले।
Application authorization और database grants स्पष्ट रखें
RLS तभी जाँची जाती है जब सामान्य SQL privilege operation की अनुमति देता है। Application role को केवल आवश्यक tables और columns दें; administration और reporting roles अलग रखें। SECURITY DEFINER functions, views और privileged helpers की समीक्षा करें, क्योंकि अनजाने में वे tenant सीमा पार करने का रास्ता बना सकते हैं।
Tenant row policies को कैसे test और operate करें?
दो tenants और production वाला application role लेकर test करें
Tenant A और B का data बनाएँ। जाँचें कि A के लिए अधिकृत user हर route से B की rows पढ़ या बदल न सके। Test उसी database role से करें जो application इस्तेमाल करता है; owner या superuser policy bypass करके गलत भरोसा दे सकता है। Missing context के लिए भी negative tests रखें।
Integrity side channels और row से अलग operations भी जाँचें
PostgreSQL के अनुसार data integrity बनाए रखने के लिए referential-integrity checks row-security filtering को bypass करते हैं। Unique constraints, foreign keys, TRUNCATE, REFERENCES, exports और administrative queries की अलग समीक्षा करें। Error message से दूसरे tenant की ID या किसी सुरक्षित row के मौजूद होने का पता न चलने दें।
Migrations, backups और support काम को tenant-aware बनाएँ
Privileged रास्तों का स्पष्ट उद्देश्य लिखें और उनका उपयोग सीमित करें। Backup तथा restore में सभी अपेक्षित tenants का data शामिल है, यह जाँचें। PostgreSQL का row_security setting backup query से filtered rows छूटने के बजाय error देने में मदद कर सकता है। Migration और restore scripts को अलग environment में test करें और किसी नियंत्रित bypass का record रखें।
SaaS में PostgreSQL RLS के सवाल
क्या row-level security application authorization की जगह लेती है?
नहीं। Application को user authenticate करना, उसका tenant तय करना और मांगी गई कार्रवाई authorize करनी होगी। RLS database की अतिरिक्त सीमा है, जो query में tenant filter छूटने पर data exposure घटा सकती है।
क्या एक table पर RLS चालू करना tenant isolation के लिए पर्याप्त है?
नहीं। सभी tenant-owned tables और data paths की सूची बनाएँ। Policies, grants, views, functions, exports, jobs और shared storage जाँचें। बिना RLS वाला table या privileged code path बाकी डिजाइन को कमजोर कर सकता है।
क्या PostgreSQL table owner RLS को bypass कर सकता है?
आमतौर पर हाँ। Superuser और BYPASSRLS role भी policies bypass करते हैं। Runtime role को सीमित रखें और tests में प्रभावी role जाँचें। FORCE ROW LEVEL SECURITY table owner का सामान्य व्यवहार बदलता है, लेकिन superuser या BYPASSRLS privilege नहीं हटाता।
Query के tenant ID का सुरक्षित स्रोत क्या है?
सर्वर पर हुई identity और authorization जाँच। Tenant को सत्यापित session या विश्वसनीय job payload से निकालें, active transaction के लिए सेट करें और जाँचें कि गायब या forged context पर access बंद रहता है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .