SaaS RBAC guide: roles, permissions और access-control checklist
Permission matrix, tenant boundary, least-privilege defaults और authorization tests की मदद से SaaS के लिए role-based access control बनाएँ।
इस मार्गदर्शिका में
SaaS में role-based access control क्या है?
Role-based access control (RBAC) permissions को ऐसे roles में समूहित करता है जो व्यक्ति को उसके काम के अनुसार दिए जाते हैं। इससे access समझाना और review करना आसान हो सकता है, लेकिन role अपने-आप यह साबित नहीं करता कि user हर record पर काम कर सकता है। हर request पर server को identity, tenant, resource ownership और action जाँचना चाहिए। OWASP हर request की authorization जाँच और deny-by-default नीति की सलाह देता है।
Roles बनाने से पहले काम और जिम्मेदारियाँ लिखें
पहले वे tasks लिखें जो customer या staff member को करने हैं—जैसे teammate invite करना, report देखना, billing setting बदलना या records export करना। Tasks को तभी समूहित करें जब उन्हीं लोगों को उसी वजह से उनकी जरूरत हो। Admin या Manager जैसे नाम पर्याप्त नहीं हैं; हर role के actions और data scope को साफ लिखें।
Scope सहित permission matrix बनाएँ
हर role के लिए लिखें कि वह किसी resource को create, read, update, delete, approve, export या administer कर सकता है या नहीं। साथ में scope जोड़ें—अपने records, assigned team, एक workspace या पूरा tenant। Resource boundary के बिना permission अनजाने में दूसरे customers के data तक पहुँच दे सकती है।
Customer roles और internal operator access अलग रखें
Customer के workspace administrator और आपकी support engineer team अलग trust boundaries में आते हैं। Internal operators के लिए अलग identity, सीमित tools और elevated access का दर्ज कारण या approval रखें। केवल support काम के कारण किसी को production के सभी data का स्थायी access न दें।
| Role | Resource और tenant scope | Allowed actions | Approval वाले sensitive actions | Owner / review date |
|---|---|---|---|---|
| Member | ||||
| Workspace administrator | ||||
| Support operator |
SaaS permissions को tenant-aware कैसे बनाएँ?
हर object request पर tenant boundary जाँचें
Signed-in identity और trusted server-side state से tenant तय करें। Requested record लौटाने या बदलने से पहले जाँचें कि वह उसी tenant का है। केवल browser या API caller से आए tenant ID, role name या object ID पर भरोसा न करें। दो test tenants के बीच direct-object requests भी जाँचें।
Least privilege अपनाएँ और default रूप से access रोकें
शुरुआत में access बंद रखें और role को केवल जरूरी actions दें। Unknown role, missing membership, expired invitation या policy lookup failure को denied मानें। ऐसे wildcard permissions से बचें जिनमें भविष्य के resource types अपने-आप शामिल हो जाएँ; संवेदनशील नई capability के लिए स्पष्ट policy change जरूरी रखें।
Role membership और permissions का अर्थ consistent रखें
लिखें कि एक user कई roles रख सकता है या नहीं और मिले-जुले permissions कैसे लागू होंगे। तय करें कि roles कौन दे सकता है, किन बदलावों में दोबारा authentication या approval चाहिए, और custom role built-in limits से आगे जा सकता है या नहीं। Access change लागू होने से पहले administrator को साफ preview दिखाएँ।
RBAC को कैसे test और review करें?
हर महत्वपूर्ण action के allowed और denied रास्ते test करें
हर permission के लिए सही user, permission-विहीन user, दूसरे tenant का user और unauthenticated request test करें। API, background job, export, file download और bulk operation भी शामिल करें; button छिपाना authorization control नहीं है। सबसे जोखिम वाले मामलों के automated tests बनाए रखें।
लोगों या जिम्मेदारियों के बदलने पर access review करें
किसी के workspace छोड़ने, role बदलने या temporary task पूरा होने पर access हटाएँ। Dormant accounts, owners, service identities और integrations भी समय-समय पर जाँचें। संक्षिप्त review में account, मौजूदा role, last use, business owner और renewal date वाली हर exception दर्ज होनी चाहिए।
Secrets को log किए बिना permission changes दर्ज करें
किसने role या policy बदली, किस account और tenant पर असर हुआ, समय और परिणाम क्या था—यह record करें। Log की पहुँच सीमित रखें और उसकी retention अवधि operational तथा legal जरूरत के आधार पर तय करें। Password, access token या अनावश्यक personal data event में न रखें।
SaaS RBAC से जुड़े सवाल
क्या RBAC दूसरे tenant का data दिखने से रोकने के लिए पर्याप्त है?
नहीं। RBAC बताता है कि role कौन-सा action कर सकता है; tenant isolation यह जाँचता है कि user किन customer resources तक पहुँच सकता है। Export, search, files और background work सहित हर request पर दोनों जाँच server में लागू करें।
शुरुआती SaaS product में कितने roles होने चाहिए?
कोई तय सही संख्या नहीं है। कुछ ऐसे roles से शुरू करें जिनकी जिम्मेदारियाँ अलग हों और जिनके actions तथा scope लिखे जा सकें। नया role तब जोड़ें जब किसी वास्तविक काम के लिए अलग boundary जरूरी हो, केवल हर job title के लिए नहीं।
क्या administrator को हर काम की अनुमति होनी चाहिए?
तभी जब product का threat model और customer की जरूरत इस scope को सही ठहराती हो। Billing, user management, data export और security settings को अलग रखने पर विचार करें, ताकि एक compromised account स्वतः हर महत्वपूर्ण action नियंत्रित न करे।
क्या frontend तय कर सकता है कि action authorized है?
Frontend बेहतर अनुभव के लिए controls छिपा या disable कर सकता है, लेकिन server को authorization स्वतंत्र रूप से लागू करनी होगी। Caller screen को bypass करके सीधे API request भेज सकता है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .