Multi-tenant SaaS search index सुरक्षा: filters, roles और tests
Server-side tenant filters, scoped search roles और results, facets तथा suggestions के tests से shared SaaS search index सुरक्षित रखें।
इस मार्गदर्शिका में
SaaS search index में tenants को कैसे अलग रखें?
User मूल record न खोल पाए तब भी search उसका title, snippet, count, autocomplete suggestion, facet या response timing उजागर कर सकता है। हर tenant के लिए अलग index या search service और application में लागू shared-index सीमा चुनें। हर query का tenant scope server पर जोड़ें और केवल मुख्य result list नहीं, response के सभी रास्ते test करें।
Index model और उसकी trust boundary लिखें
अलग index या cluster accidental query mixing घटा सकता है, पर provisioning, capacity, upgrade और recovery का काम बढ़ता है। Shared index कुशल है, लेकिन हर document और query में validated tenant boundary जरूरी है। तय करें कि कौन query, write, administer, snapshot और reindex कर सकता है; support तथा analytics tools भी शामिल करें।
Trusted ingestion में tenant identity जोड़ें
Tenant metadata authorized source record या event से लें, editable client field से नहीं। Bulk import, reindex, replay और backfill में फिर validate करें। Missing या conflicting tenant वाले document को shared default में index करने के बजाय रोकें या quarantine करें।
User-controlled search syntax के बाहर tenant filter लगाएँ
Authenticated server context से filter निकालकर user के permitted query के साथ जोड़ें। Client को filter हटाने या व्यापक करने का रास्ता न दें। Saved search, query template, dashboard link, autocomplete और administrative search APIs अलग-अलग जाँचें।
| Index और data class | Tenant source तथा mapping | Reader/writer/admin roles | Query surfaces और filters | Cross-tenant negative tests |
|---|---|---|---|---|
| Customer content | ||||
| Tenant analytics या audit index | ||||
| Shared public catalogue |
किन search permissions और result paths को सुरक्षित रखना है?
Search service roles को जरूरी index और actions तक सीमित करें
Query readers, ingestion writers, index managers और operators अलग रखें। Index patterns और cluster-wide permissions सीमित करें। Document या field-level controls पर निर्भर होने से पहले product version में उनका documented व्यवहार जाँचें। OpenSearch DLS reads filter करता है, writes नहीं; update और delete को index permissions से अलग रोकें।
Aggregations, facets, counts और errors भी test करें
Totals, facets, suggestions, highlights, exports और nested queries में filter लागू होना चाहिए। Result list सुरक्षित दिख सकती है जबकि count या aggregation दूसरे tenant की activity बता दे। दूसरे customer को document text, index name या query value दिखाने वाले errors न लौटाएँ।
Index snapshots और dashboards को customer data मानें
Snapshot, restore, dashboard sharing, saved objects, analytics और debugging console का access सीमित करें। Unrestricted query वाला support role application filter को पार कर सकता है। Cross-index patterns बनाने वालों का record रखें और snapshot पर source data जैसी retention तथा access policy लागू करें।
Index बदलावों के दौरान search isolation कैसे test करें?
दो tenants के positive और negative query cases test करें
Tenant A और B के मिलते-जुलते test documents index करें। Results, counts, facets, suggestions और downloads जाँचें। Empty filter, malformed context, saved search, timeout, partial response तथा admin endpoint भी आजमाएँ; production जैसी service identity और role mapping इस्तेमाल करें।
Reindexing, aliases और schema migration सुरक्षित करें
Alias या migration tenant-facing query को व्यापक index पर भेज सकता है या filter field हटा सकता है। Cutover से पहले mappings, role patterns, aliases, replicas और rollback जाँचें। Tenant के अनुसार record counts मिलाएँ और जरूरी metadata गायब होने पर switch रोकें।
पूरा document log किए बिना query और ingestion monitor करें
Tenant reference, index, actor, query class, result size, latency और policy outcome दर्ज करें; जरूरत के अनुसार raw search terms या document content redact करें। Tenant filter के बिना request, unexpected cross-index search, conflicting tenant वाले bulk write और count anomalies पर alert दें।
SaaS search index सुरक्षा के सवाल
क्या document-level security search writes भी सुरक्षित करता है?
OpenSearch के documented व्यवहार में DLS read operations filter करता है। Index, update और delete operations के लिए अलग index permissions चाहिए।
क्या हर tenant के लिए अलग index हमेशा सुरक्षित है?
यह query mixing घटा सकता है, लेकिन tenant selection, aliases, snapshots या operator permissions व्यापक हों तो अपने-आप सुरक्षित नहीं। पूरे data path और संचालन की जटिलता साथ परखें।
क्या UI में छिपा tenant filter search data अलग रख सकता है?
नहीं। Filter trusted server या search authorization layer में लगाएँ ताकि client उसे हटा न सके। UI filter presentation logic है; direct API call को सीमित नहीं करता।
क्या search count या suggestion दूसरे tenant का data बता सकते हैं?
हाँ। Count, facet, autocomplete, snippet, highlight और error message भी जानकारी उजागर कर सकते हैं। हर response field और API को अलग tenant identity से test करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .
- Document-level security
- Defining users and roles
- AWS SaaS Storage Strategies: SaaS डेटा विभाजन के मॉडल
- AWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना
- AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षण
- OWASP Cheat Sheet: authorization
- AWS SaaS Lens: tenant-aware operations और onboarding
- OWASP Cheat Sheet: logging