SaaS cache सुरक्षा: tenant data को दूसरे ग्राहकों तक पहुँचने से रोकें
Shared SaaS cache में tenant-scoped keys, authorization, सुरक्षित invalidation और cross-tenant tests से ग्राहक data सुरक्षित रखें।
इस मार्गदर्शिका में
SaaS cache से tenant data leak कैसे रोकें?
Application या distributed cache तभी सुरक्षित है जब key और cached value उस request की access सीमा बनाए रखें जिसने उसे बनाया था। हर private read से पहले caller की अनुमति जाँचें, key में authorized tenant और representation बदलने वाले inputs शामिल करें और अलग-अलग ग्राहकों से cache hits test करें। यह Redis जैसी application cache पर केंद्रित है; CDN edge cache की routing और response rules अलग होती हैं।
Customer data रखने वाली हर cache की सूची बनाएँ
In-process memoization, framework query या fragment cache, report results, session store और Redis entries शामिल करें। हर value के लिए sensitivity, उसे भरने वाला code, lifetime और data या permission बदलने पर invalidation तरीका लिखें। Database row policy पहले से cache की गई copy को अपने-आप सुरक्षित नहीं करती।
Key को server-verified tenant और identity से बनाएँ
Authentication और authorization के बाद तय stable tenant ID के साथ resource, permission scope, locale, filters और वे inputs जोड़ें जो response बदलते हैं। अकेले client से आए tenant parameter पर भरोसा न करें। Cache key में email, token या ऐसा personal data न रखें जो diagnostic logs में दिख सकता है।
Cache hit लौटाने से पहले अनुमति फिर जाँचें
सही key product authorization का विकल्प नहीं है। Private value लौटाने से पहले पुष्टि करें कि caller अब भी उसी tenant का सदस्य है और यह कार्रवाई कर सकता है; cache जीवित रहते role या membership बदल सकती है। यदि invalidation भरोसेमंद नहीं है तो छोटी expiry रखें या अत्यधिक sensitive data साझा cache में न रखें।
| Cache और data sensitivity | अनुमत key dimensions | Read/write permissions | Invalidation trigger | Cross-tenant test और owner |
|---|---|---|---|---|
| User profile या settings | ||||
| Tenant dashboard या report | ||||
| साझा public reference data |
Redis और दूसरी shared cache को कैसे सीमित करें?
Tenant key prefix को नामकरण समझें, isolation का प्रमाण नहीं
Tenant ID और resource type वाला prefix entries पहचानने और हटाने में मदद करता है, लेकिन व्यापक Redis credential वाला code दूसरे prefixes भी पढ़ सकता है। Redis ACL named users के commands और key patterns सीमित कर सकती हैं, जबकि पूरे database पर असर डालने वाले commands के अलग नियम हैं। निर्भर होने से पहले Redis version और managed service के व्यवहार की पुष्टि करें।
हर service को सीमित cache identity दें
जहाँ समर्थित हो, application और worker के credentials अलग रखें और केवल जरूरी commands व key patterns दें। Redis को trusted application network तक सीमित करें और उपलब्ध होने पर authenticated encrypted connection इस्तेमाल करें। Shared default account का broad access किसी एक consumer की गलती का असर बढ़ा सकता है।
साझा public values को private tenant results से अलग रखें
Public catalogue का shared key तभी ठीक है जब उसका value हर authorized caller के लिए समान हो। Tenant configuration, billing, permissions या customer records के लिए authorized tenant और जरूरत के अनुसार user scope शामिल करें। जाँचें कि tenant-specific key न मिलने पर system generic या किसी पिछले tenant का value तो नहीं देता।
Cache invalidation और tenant separation कैसे test करें?
दो tenants, अलग roles और बदले हुए request inputs से जाँचें
एक ही resource को tenant A और B, एक tenant के अलग roles और membership हटने के बाद request करें। Locale, filters, pagination और feature flags बदलें। Cache miss और hit दोनों में वही authorized representation मिलनी चाहिए।
Data, role और tenant lifecycle बदलने पर invalidation जाँचें
Update, delete, role change, सदस्यता हटाना, tenant suspend और offboarding के लिए नियम बनाएँ। Concurrent refresh और retries test करें ताकि पुराना response revocation के बाद key दोबारा न भर दे। Event invalidation में देरी हो तो सुरक्षित expiry रखें और read पर authorization फिर जाँचें।
Logs सुरक्षित रखें और cache stampede सीमित करें
Key template, hit/miss, pseudonymous tenant reference और latency दर्ज करें; पूरा record या credential नहीं। अनपेक्षित key growth, व्यापक commands और error spikes पर alert करें। Expiry पर अचानक बहुत सारे refresh requests से बचने के लिए जरूरत के अनुसार jitter, bounded refresh या request coalescing लागू करें।
SaaS cache सुरक्षा के आम सवाल
क्या Redis key में tenant ID जोड़ना पर्याप्त है?
नहीं। इससे key collision घट सकती है, पर हर read और write में server-verified tenant scope चाहिए। ACL, network restrictions, application authorization और tests अतिरिक्त सुरक्षा देते हैं; broad credential naming convention को पार कर सकता है।
क्या SaaS application private customer data cache कर सकती है?
हाँ, यदि authorization, key, expiry, invalidation, storage permissions और logs उस data के अनुरूप डिजाइन और test हों। जिस sensitive या तेजी से बदलते value को समय पर revoke या isolate नहीं कर सकते, उसे cache करने से बचें।
क्या CDN सुरक्षा application cache को भी cover करती है?
नहीं। CDN edge request और response cache करती है; Redis या application cache authentication के पीछे अलग objects रख सकती है। हर layer की key, access decision, lifetime और invalidation अलग जाँचें।
Cross-tenant cache leak कैसे test करें?
Tenant A से private value भरें और tenant B से वही route तथा object miss, hit, retry और invalidation के बाद माँगें। API, reports और background refresh सहित हर स्थिति में सुनिश्चित करें कि B को A का response न मिले।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .