Multi-tenant SaaS feature flag सुरक्षा: context और rollout controls
Trusted evaluation context, अलग authorization, privacy-aware attributes, staged deployment और isolation tests से cross-tenant flag leak रोकें।
इस मार्गदर्शिका में
Multi-tenant SaaS में feature flags कैसे सुरक्षित करें?
Feature flag किसी user, tenant या rollout group के लिए application behavior बदलता है। Evaluation context authenticated server-side identity से बनाएँ, tenant सीमा स्पष्ट रखें और flag को release control मानें, authorization system नहीं। केवल button छिपाने वाला flag direct API call या दूसरे customer का data देखने से नहीं रोकता।
हर request के लिए trusted evaluation context बनाएँ
Verified membership data से stable tenant key शामिल करें और user-specific निर्णय हो तो stable user key भी दें। Browser को अपनी targeting attributes चुनने न दें। OpenFeature evaluation context को targeting data बताता और targeting key परिभाषित करता है; provider के merge rules देखें ताकि untrusted invocation value trusted tenant identity को overwrite न करे।
Feature availability और permission check अलग रखें
हर request और object पर server-side authorization लागू करें। User interface feature छिपाए तब भी API और job path अलग से access जाँचें। Rollout बदल सकता है कि customer क्या देखे, लेकिन वह role नहीं बढ़ा सकता, query व्यापक नहीं कर सकता और tenant data सीमा पार नहीं कर सकता।
Flag attributes में personal data कम से कम रखें
Rollout के लिए जरूरी attributes ही दें—जैसे opaque tenant cohort, plan tier या region। Raw email, नाम, sensitive trait और customer payload से बचें। Provider evaluation context प्राप्त या persist कर सकता है, इसलिए data भेजने से पहले handling और retention जाँचें।
| Flag और उद्देश्य | Trusted targeting context | Authorization control | Rollout/default/rollback | Cross-tenant test और owner |
|---|---|---|---|---|
| New report experience | ||||
| Tenant-specific integration | ||||
| Emergency kill switch |
Tenant flags और configuration को कैसे deploy करें?
Environment अलग रखें और बदलाव का अधिकार सीमित करें
Production flag, targeting rule, secret value और emergency override को केवल नामित roles तक सीमित करें। Development, staging और production context अलग रखें। Actor तथा कारण दर्ज करें और सुनिश्चित करें कि एक customer का administrator global flag या दूसरे tenant की rule नहीं बदल सकता।
Configuration validate करें और rollout चरणों में करें
Deployment से पहले flag values तथा allowed attributes का schema check करें। पहले test cohort पर rollout करें, error और performance signal देखें, फिर विस्तार करें। जहाँ समर्थित हो rollback condition रखें और पिछला सही version बचाएँ। AWS AppConfig staged deployment और CloudWatch alarm से rollback बताता है; हर provider की क्षमता अलग है।
Provider unavailable हो तो सुरक्षित default तय करें
Missing, malformed, stale या timed-out evaluation का व्यवहार लिखें। Access-sensitive operation के लिए allow/deny का स्रोत authorization ही रहे; optional product feature के लिए conservative default चुनें। Tenant-specific value को global process variable या बिना tenant/user dimensions की shared cache में न रखें।
SaaS team को कौन-से feature-flag isolation tests चलाने चाहिए?
अलग tenants और roles की concurrent requests चलाएँ
Tenant A और B, अलग plans, administrators और ordinary members के लिए एक ही flag evaluate करें। पुष्टि करें कि एक request दूसरी की context या cached value reuse नहीं करती। Production जैसे SDK lifecycle के साथ web request, background job और server-rendered page भी शामिल करें।
Target बदलने, fallback और provider outage की जाँच करें
Request चलते समय membership, plan और targeting बदलें। Provider timeout, stale cache, missing targeting key, malformed variant और rollback test करें। Customer workflow में behavior उचित रहे और failure access व्यापक न बनाए।
पुराने flag और configuration data की सफाई करें
हर temporary flag का owner और removal date रखें। Rollout के बाद पुराने rules हटाएँ ताकि पुरानी tenant exception नए customer पर लागू न हो। Evaluation logs में केवल जरूरी outcomes तथा opaque IDs रखें; बिना documented need के sensitive attributes या पूरी context न रखें।
SaaS feature flag सुरक्षा के सवाल
क्या feature flag API authorization की जगह ले सकता है?
नहीं। हर request और object पर server permission जाँचें। Feature UI में बंद दिखे तब भी client endpoint सीधे call कर सकता है।
Evaluation context में tenant की पहचान क्या हो?
Stable, server-verified tenant ID लें और user के भीतर targeting बदलनी हो तो user ID भी दें। SDK की precedence तथा merge rules अपनाएँ ताकि browser value trusted context को न बदले।
क्या feature flag target करने के लिए email देना चाहिए?
Raw email भेजने से बचें, जब तक provider और उद्देश्य को इसकी जरूरत तथा privacy review न हो। Opaque stable key या coarse cohort से कम personal data के साथ targeting हो सकती है।
पहले एक customer के लिए flag सुरक्षित रूप से कैसे जारी करें?
Trusted server context से उसी tenant को target करें, उसके role और data boundary test करें, rollout monitor करें और rollback तैयार रखें। Flag को authorization से अलग रखें और tenant-specific rule दूसरे customers को न दिखाएँ।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .
- Evaluation Context specification
- Deploying feature flags and configuration data in AWS AppConfig
- OWASP Cheat Sheet: authorization
- AWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना
- AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षण
- Digital Personal Data Protection Act, 2023
- AWS SaaS Lens: tenant-aware operations और onboarding
- OWASP Cheat Sheet: logging