SaaS RAG सुरक्षा: tenant retrieval और ग्राहक डेटा अलग रखें

Authorization-aware search, अलग vector data, भरोसेमंद metadata, source citations और leakage tests से SaaS RAG को सुरक्षित बनाएं।

इस मार्गदर्शिका में

Multi-tenant RAG system को सुरक्षित कैसे रखें?

सुरक्षित SaaS retrieval-augmented generation (RAG) में search से पहले उपयोगकर्ता की पहुंच जांची जाती है, verified scope के साथ retrieval होता है, और model context भेजने से पहले मिले हर chunk की फिर से जांच होती है। Vector filter या tenant label सीमा लागू करने में मदद करता है, लेकिन application authorization का विकल्प नहीं है। Retrieved text को untrusted मानें: उसमें निजी डेटा, पुरानी permissions या model को दिए गए दुर्भावनापूर्ण निर्देश हो सकते हैं।

Retrieval scope को authenticated membership से तय करें

Trusted server code में caller, सक्रिय organization, role और अनुमत records पहचानें। Search filter उसी authorization result से बनाएं। Browser से आए tenant ID, document ACL, user group या filter expression पर भरोसा करके पहुंच न बढ़ाएं। अगर tenant और permission प्रमाणित न हों, तो search और generation शुरू ही न करें।

इस बिंदु के स्रोत: Connect to SharePoint data sources with access control listsAWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकनाOWASP Cheat Sheet: authorization

Retrieval पर access लागू करें और हर chunk दोबारा जांचें

Vector query या authorized retrieval layer में tenant और document permissions लगाएं। फिर model context बनाने से पहले हर result का tenant, document status और मौजूदा ACL जांचें। AWS की Bedrock integrations में metadata filtering और identity आधारित ACL के खास उदाहरण हैं; हर store की क्षमता अलग हो सकती है। Generation के बाद जांच करना देर से होगा, क्योंकि model सामग्री पहले ही देख चुका होगा।

इस बिंदु के स्रोत: Connect to SharePoint data sources with access control listsMetadata filtering for knowledge basesSet up a knowledge base with a security configuration

Data-store की सीमा जोखिम के मुताबिक चुनें

अलग indexes या collections, tenant namespaces और साझा index के server-side metadata filters की तुलना करें। Admin blast radius, noisy-neighbor प्रभाव, encryption और keys, backup और deletion, संचालन की जटिलता तथा provider के आश्वासन देखें। Namespace अतिरिक्त सुरक्षा दे सकता है, पर broad service credentials होने पर store स्वयं सीमा लागू न करे तो cross-tenant पहुंच संभव रह सकती है।

इस बिंदु के स्रोत: LLM08:2025 Vector and Embedding WeaknessesSet up a knowledge base with a security configurationAWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षण

Tenant-safe RAG access समीक्षा
Caller और सत्यापित tenant	Document permission का स्रोत	Index/filter सीमा	Generation से पहले जांच	Leakage test का मालिक
Private file के बारे में पूछता tenant member
स्वीकृत पहुंच वाला support user
Access हटने के बाद पूर्व member

SaaS team RAG documents को ingest और update कैसे करे?

भरोसेमंद provenance और permission metadata जोड़ें

हर chunk के साथ स्थिर document ID, tenant ID, source, version, ingestion का समय, classification और retrieval के लिए आवश्यक permission reference रखें। Ingestion के समय metadata validate करें और tenant ownership गायब या विरोधाभासी हो तो document अस्वीकार करें। Filename या user-editable tag से ACL का अनुमान न लगाएं; source system की permissions को नियंत्रित और reviewed प्रक्रिया से map करें।

इस बिंदु के स्रोत: LLM08:2025 Vector and Embedding WeaknessesMetadata filtering for knowledge bases

Permission change, deletion और re-indexing साथ-साथ करें

ACL बदलना, tenant transfer, document deletion या user offboarding हर derived chunk, cached answer और embedding के लिए security event होना चाहिए। ऐसी reconciliation job रखें जो stale copies खोजे और सुरक्षित retry करे; बदलाव अधूरे हों तो content को अस्थायी रूप से unavailable करें। Product की बताई retention rules के अनुसार replicas, backups और downstream indexes में deletion और revocation की जांच करें।

Retrieval context छोटा और traceable रखें

Task के लिए जरूरी सीमित authorized passages ही retrieve करें, context size पर सीमा लगाएं और chunk से source तक reference बनाए रखें। सुविधा के लिए पूरे tenant corpus को model में न भेजें। Answer बनाने में इस्तेमाल document versions दर्ज करें ताकि incident की जांच हो सके, पर सामान्य logs में पूरा संवेदनशील prompt या response अपने-आप न रखें।

इस बिंदु के स्रोत: OWASP Top 10 for LLM Applications 2025Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)OWASP Cheat Sheet: logging

RAG tenant isolation और retrieval quality का परीक्षण कैसे करें?

Cross-tenant retrieval के adversarial tests चलाएं

Tenant A और B के documents में अलग पहचान वाले canary phrases रखें। हर tenant से direct question, paraphrase, filters, hybrid search, reranking और fallback paths में खोज कराएं। सुनिश्चित करें कि दूसरे tenant का canary result, citation, snippet, log या answer में न आए। Anonymous caller, suspended tenant, revoked membership और गलत metadata भी शामिल करें।

इस बिंदु के स्रोत: AWS SaaS Lens: multi-tenant SaaS की विश्वसनीयता का परीक्षणLLM08:2025 Vector and Embedding Weaknesses

Injection और poisoned-source की अलग जांच करें

एक authorized document में निर्देश जैसे दिखने वाला text रखें और देखें कि model उसे source text की तरह उद्धृत करता है, या उसे secrets बताने अथवा tool चलाने का आदेश मानता है। Ingestion review, provenance और compromised document हटाने की प्रक्रिया भी जांचें। Search filtering उस result के अंदर के malicious instructions को निष्क्रिय नहीं करती, जिसे उपयोगकर्ता पढ़ सकता है।

इस बिंदु के स्रोत: LLM01:2025 Prompt InjectionLLM08:2025 Vector and Embedding Weaknesses

अनावश्यक content जमा किए बिना access decisions पर निगरानी रखें

Tenant-scoped retrieval counts, denied requests, गायब ACL metadata, stale-index देरी, असामान्य broad search और citation failures मापें। Opaque IDs और सीमित retention इस्तेमाल करें; reviewed incident workflow के बिना prompts और retrieved text को routine logs में न रखें। अगर filter हट जाए या retrieval service unscoped fallback पर जाए तो alert दें।

इस बिंदु के स्रोत: OWASP Cheat Sheet: loggingArtificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)Set up a knowledge base with a security configuration

Multi-tenant RAG सुरक्षा: अक्सर पूछे जाने वाले सवाल

क्या vector chunks में tenant_id डालने से data leak रुकता है?

नहीं। Application को verified identity और permissions से filter बनाना, retrieval में लागू करना, लौटे chunks validate करना और हर fallback तथा cache path जांचना होगा। Metadata तभी उपयोगी है जब untrusted caller उसे व्यापक न कर सके।

इस बिंदु के स्रोत: Metadata filtering for knowledge basesAWS SaaS Lens: अलग tenants के बीच अनधिकृत access रोकना

क्या हर customer के लिए अलग vector database जरूरी है?

हमेशा नहीं। अलग stores स्पष्ट isolation देते हैं, पर खर्च और संचालन बढ़ाते हैं। साझा store भी सही हो सकता है, यदि authorization filters, service identities, deletion व्यवहार और isolation tests data और threat model के लिए पर्याप्त मजबूत हों।

इस बिंदु के स्रोत: LLM08:2025 Vector and Embedding WeaknessesSet up a knowledge base with a security configuration

क्या model तय कर सकता है कि user document देख सकता है?

नहीं। Access का निर्णय trusted application authorization layer करे। Model उन्हीं सामग्री का सार दे सकता है जिसकी caller को पहले से अनुमति है; उसका generated reasoning या refusal access-control decision नहीं है।

इस बिंदु के स्रोत: Connect to SharePoint data sources with access control listsOWASP Cheat Sheet: authorization

क्या RAG prompt injection रोकता है?

नहीं। Retrieved content में indirect prompt injection हो सकता है। Permissions को prompt से बाहर लागू करें, source text को untrusted मानें, model की क्षमताएं सीमित करें और malicious documents की अलग जांच करें।