Multi-tenant SaaS background job सुरक्षा: tenant scope, retry और isolation
Trusted job context, सीमित worker, idempotency, सुरक्षित retries और cross-tenant tests से asynchronous SaaS jobs को सही tenant तक सीमित रखें।
इस मार्गदर्शिका में
Multi-tenant SaaS में background jobs सुरक्षित कैसे करें?
Background job मूल web request के बाद चलती है और उसका code, credentials तथा execution समय अलग हो सकते हैं। Job में tenant और operation स्पष्ट रखें, context server-authorized request से बनाएँ और worker चलने पर resource का संबंध फिर सत्यापित करें। Retry को सुरक्षित बनाएँ और worker को अलग entry point मानकर test करें; controller की जाँच worker तक अपने-आप नहीं पहुँचती।
Job message में न्यूनतम और सत्यापित tenant context रखें
Tenant ID, operation, stable resource IDs, requester या service identity, trace ID और जरूरत पर idempotency key रखें। Queue message में client द्वारा भेजी tenant ID केवल copy होने से trusted नहीं बनती। Password, bearer token या बड़ा customer record message में न रखें; आवश्यक data authorized service path से लें।
Worker में ownership और permission फिर जाँचें
चलाते समय पुष्टि करें कि resource उसी tenant का है और operation अब भी policy के तहत allowed है। Queue में इंतजार के दौरान user का role या membership बदल सकता है। यदि requester के चले जाने के बाद भी durable job चलनी चाहिए, तो स्पष्ट service authorization policy रखें और मूल actor को audit के लिए सुरक्षित करें।
हर worker को जरूरी queue और data access ही दें
Producer, consumer और queue administrator अलग रखें। Worker को उसकी queue, tenant-aware data operations और जरूरी secrets तक सीमित करें। हर worker को सभी customer tables या dead-letter queues का broad access न दें; production identity को development से अलग रखें।
| Job और trigger | Trusted tenant तथा actor context | Worker role और data scope | Retry/idempotency नियम | Failure और audit owner |
|---|---|---|---|---|
| Tenant report generation | ||||
| Webhook या billing update | ||||
| Tenant deletion या migration |
Worker retry और tenant सीमा को कैसे संभालें?
Side effects को tenant-bound और idempotent बनाएँ
Timeout या acknowledgement खोने पर queue काम दोबारा deliver कर सकती है। Tenant और operation से जुड़ी स्थिर idempotency key रखें और unique constraint या atomic claim से completion दर्ज करें। Payment, notification या बाहरी update दोहराने से पहले पता करें कि पहला प्रयास सफल हुआ था या नहीं।
Retry में job का tenant या target बदलने न दें
मूल सत्यापित context रखें और हर प्रयास में resource IDs को उसी tenant से बाँधें। Mutable global state, reused connection या untrusted message attribute से scope दोबारा न बनाएँ। Tenant suspend, delete या migrate हो तो default context पर गिरने के बजाय स्पष्ट policy लागू करें।
Dead-letter message और replay को privileged operation मानें
Dead-letter queue में personal data और customer state बदलने वाला काम रह सकता है। Read और replay को सीमित करें, retention तथा encryption तय करें और dashboard में message body redact करें। Redrive से पहले कारण और tenant scope जाँचें तथा replay में बाहरी side effect दोहरने से रोकें।
Multi-tenant worker को कैसे चलाएँ और test करें?
गलत या missing tenant context के साथ handler सीधे test करें
Tenant A की valid job, tenant B का resource ID, खाली या forged tenant, revoked membership और duplicate message आजमाएँ। Invalid job deny हो, बाहरी side effect न हो और audit outcome स्पष्ट रहे। Scheduled jobs तथा admin replay भी शामिल करें।
Per-tenant quota और निष्पक्ष scheduling तय करें
एक noisy tenant shared queue भरकर पूरी capacity न ले। Job frequency, payload size, runtime और concurrency सीमित करें; job class या tenant cohort के अनुसार queue age देखें। जरूरी काम के लिए fair scheduling या isolation तय करें और दूसरे customer के identifier को dashboard में उजागर न करें।
Customer payload logs में copy किए बिना lifecycle trace करें
Job ID, tenant reference, actor, operation, attempt count, queue, समय और अंतिम status दर्ज करें। Raw body, token और sensitive output सामान्य logs से बाहर रखें। Producer, worker, cloud queue और downstream events correlate करें ताकि जाँचकर्ता को broad data access न देना पड़े।
SaaS background job सुरक्षा के सवाल
क्या web request की authorization asynchronous job के लिए पर्याप्त है?
नहीं। Worker अलग execution path है और बाद में अलग permissions से चल सकता है। Trusted context साथ भेजें, resource ownership फिर जाँचें और execution समय पर स्पष्ट policy लागू करें।
क्या queue message में tenant ID हो सकती है?
हाँ, यदि वह server-authorized निर्णय से बनी हो और worker उसे resource से मिलाकर validate करे। Message में tenant field context है, sender या operation के authorization का प्रमाण नहीं।
क्या background job केवल एक बार process होती है?
ऐसा न मानें। Delivery और retry queue तथा configuration पर निर्भर हैं; failure से redelivery हो सकती है। Side effects idempotent रखें और इस्तेमाल की जा रही queue की documented guarantees पढ़ें।
Dead-letter queue को कौन replay कर सकता है?
केवल नामित operator या सीमित recovery service, स्पष्ट उद्देश्य के साथ। कारण और tenant scope जाँचें, duplicate effects नियंत्रित करें और replay को किसने approve तथा execute किया, दर्ज करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .
- AWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना
- AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षण
- Amazon SQS Security Best Practices
- Access Management for Encrypted Amazon SQS Queues with Least Privilege Policies
- Access Control with Identity and Access Management in Pub/Sub
- Dead-Letter Topics in Pub/Sub
- OWASP Cheat Sheet: authorization
- OWASP Cheat Sheet: logging
- Stripe Billing: meter events से usage record करना
- Security Best Practices in AWS CloudTrail