अनुमति-सूचित वैश्विक खोज डिज़ाइन बिना डेटा लीक के

क्यों वैश्विक खोज डेटा लीक कर सकती है

वैश्विक खोज आम तौर पर एक ही सर्च बॉक्स का मतलब रखती है जो पूरे ऐप को स्कैन करता है: ग्राहक, टिकट, चालान, दस्तावेज़, उपयोगकर्ता और जो कुछ भी लोग इस्तेमाल करते हैं। यह अक्सर ऑटोकम्पलीट और एक त्वरित रिजल्ट पेज को चलाता है ताकि उपयोगकर्ता सीधे रिकॉर्ड पर जा सकें।

लीक तब होती है जब खोज कुछ ऐसा लौटाती है जिसे उपयोगकर्ता जानने के अधिकार में नहीं है कि वह मौजूद है। भले ही वे रिकॉर्ड नहीं खोल सकें, एक लाइन—जैसे शीर्षक, किसी का नाम, टैग, या हाइलाइट किया हुआ स्निपेट—संवेदनशील जानकारी उजागर कर सकता है।

खोज "केवल-पढ़ने" जैसा लगती है, इसलिए टीमें इसे कम आंकती हैं। लेकिन यह रिजल्ट टाइटल और प्रीव्यू, ऑटोकम्पलीट सुझाव, रिजल्ट टोटल, "Customers (5)" जैसे फ़ेसैट्स, और यहां तक कि समय अंतर के जरिए भी डेटा उजागर कर सकती है (कुछ शब्दों पर तेज़, कुछ पर धीमा)।

यह आमतौर पर शुरुआत में नहीं दिखता। पहले, टीमें तब सर्च जारी कर देती हैं जब केवल एक रोल होता है या टेस्ट डेटाबेस में सब कुछ दिखता है। जैसे-जैसे प्रोडक्ट बढ़ता है, आप रोल जोड़ते हैं (सपोर्ट बनाम सेल्स, मैनेजर बनाम एजेंट) और फीचर जैसे साझा इनबॉक्स, निजी नोट्स, सीमित ग्राहक, और "केवल मेरे खाते" आते हैं। अगर सर्च अभी भी पुराने अनुमान पर निर्भर रहती है, तो यह क्रॉस-टीम या क्रॉस-कस्टमर संकेत दिखाने लगती है।

एक सामान्य विफलता मोड यह है कि स्पीड के लिए "सब कुछ" इंडेक्स कर लिया जाता है, और फिर ऐप में सर्च क्वेरी के बाद फ़िल्टर करने की कोशिश की जाती है। यह बहुत देर हो चुकी बात है। सर्च इंजन पहले ही तय कर चुका होता है कि क्या मैच करता है, और प्रतिबंधित रिकॉर्ड सुझावों, काउंट्स, या आंशिक फ़ील्ड के माध्यम से प्रकट हो सकते हैं।

कल्पना कीजिए एक सपोर्ट एजेंट की जो केवल अपने असाइन किए गए ग्राहकों के टिकट देख सकता है। वे "Acme" टाइप करते हैं और ऑटोकम्पलीट दिखाता है "Acme - Legal escalation" या "Acme breach notification." भले ही क्लिक करने पर "access denied" आए, केवल टाइटल ही डेटा लीक है।

अनुमति-सूचित वैश्विक खोज का लक्ष्य कहना आसान है लेकिन लागू करना मुश्किल: तेज़, प्रासंगिक परिणाम लौटाएं जबकि वही एक्सेस नियम लागू करें जो आप हर रिकॉर्ड खोलते समय लागू करते हैं। हर क्वेरी को ऐसे व्यवहार करना चाहिए जैसे उपयोगकर्ता केवल अपने डेटा के हिस्से को ही देख सकता है, और UI को अतिरिक्त सुराग (जैसे काउंट्स) उस हिस्से के बाहर लीक करने से बचाना चाहिए।

आप क्या इंडेक्स कर रहे हैं और क्या सुरक्षित रखना है

वैश्विक खोज सरल लगती है क्योंकि उपयोगकर्ता शब्द टाइप करते हैं और उत्तर की उम्मीद करते हैं। पर पर्दे के पीछे, आप डेटा एक्सपोज़र के लिए एक नया सतह बना रहे हैं। किसी इंडेक्स या डेटाबेस फीचर को चुनने से पहले, दो बातों को स्पष्ट कर लें: आप किन वस्तुओं (entities) की खोज कर रहे हैं, और उन वस्तुओं के कौन से हिस्से संवेदनशील हैं जिन्हें सुरक्षित रखना जरूरी है।

एक entity कोई भी रिकॉर्ड है जिसे कोई जल्दी ढूंढना चाह सकता है। अधिकांश बिज़नेस ऐप्स में यह ग्राहक, सपोर्ट टिकट, चालान, ऑर्डर और फ़ाइलें (या फ़ाइल मेटाडेटा) शामिल हैं। इसमें लोग (उपयोगकर्ता, एजेंट), आंतरिक नोट्स, और सिस्टम ऑब्जेक्ट्स जैसे इंटीग्रेशन या API कीज़ भी हो सकते हैं। अगर इसका कोई नाम, ID, या स्थिति है जिसे कोई टाइप कर सकता है, तो वह अक्सर वैश्विक खोज में आता है।

प्रति-रिकॉर्ड नियम बनाम प्रति-टेबल नियम

Per-table नियम सीधे होते हैं: या तो आप पूरे टेबल तक पहुंच सकते हैं या नहीं। उदाहरण: केवल वित्त विभाग Invoices पेज खोल सकता है। यह सोचना आसान बनाता है, लेकिन तब असफल हो जाता है जब अलग-अलग लोगों को एक ही टेबल की अलग-पंक्तियाँ देखने की अनुमति होनी चाहिए।

Per-record नियम पंक्ति दर पंक्ति दृश्यता तय करते हैं। उदाहरण: एक सपोर्ट एजेंट अपने असाइन किए गए ग्राहकों के टिकट देख सकता है, जबकि एक मैनेजर अपने क्षेत्र के सभी टिकट देख सकता है। एक आम नियम टेनेंट ओनरशिप है: मल्टी-टेनेंट ऐप में, एक उपयोगकर्ता केवल उन रिकॉर्ड्स को देख सकता है जहाँ customer_id = their_customer_id।

यहीं पर सर्च आमतौर पर लीक करती है। अगर आपका इंडेक्स मैच लौटाता है इससे पहले कि आप रो-एक्सेस चेक करें, तो आप पहले ही किसी चीज़ के मौजूद होने को उजागर कर चुके हैं।

व्यवहार में "देखने की अनुमति" का मतलब

"देखने की अनुमति" शायद ही कभी केवल हाँ/नहीं स्विच होती है। यह अक्सर ओनरशिप (मेरे द्वारा बनाए गए, मुझ पर असाइन किए गए), सदस्यता (मेरी टीम, मेरा विभाग, मेरी भूमिका), स्कोप (मेरा क्षेत्र, बिज़नेस यूनिट, प्रोजेक्ट), रिकॉर्ड स्थिति (प्रकाशित, नॉन-आर्काइव्ड), और विशेष केस (VIP ग्राहक, कानूनी होल्ड, सीमित टैग) का संयोजन होती है।

पहले इन नियमों को सादा भाषा में लिखें। बाद में आप उन्हें डेटा मॉडल और सर्वर-साइड चेक में बदलेंगे।

रिजल्ट प्रीव्यू में क्या दिखाना सुरक्षित है तय करें

सर्च रिजल्ट अक्सर एक प्रीव्यू स्निपेट शामिल करते हैं, और स्निपेट्स संवेदनशील डेटा को लीक कर सकते हैं भले ही उपयोगकर्ता रिकॉर्ड नहीं खोल पाए।

एक सुरक्षित डिफ़ॉल्ट यही है कि एक्सेस कॉन्फ़र्म होने तक केवल न्यूनतम, गैर-संवेदनशील फ़ील्ड दिखाएँ: एक डिस्प्ले नाम या शीर्षक (कभी-कभी मास्क किया हुआ), एक छोटा पहचानकर्ता (जैसे ऑर्डर नंबर), एक उच्च-स्तरीय स्थिति (Open, Paid, Shipped), एक तारीख (बनाई गई या अपडेट की गई), और एक सामान्य एंटिटी लेबल (Ticket, Invoice)।

ठोस उदाहरण: अगर कोई "Acme merger" खोजता है और एक प्रतिबंधित टिकट मौजूद है, तो "Ticket: Acme merger draft - Legal" लौटाना पहले से ही लीक है। एक सुरक्षित परिणाम होगा "Ticket: Restricted" बिना स्निपेट के, या नीति के अनुसार बिल्कुल कोई परिणाम नहीं।

पहले से ये परिभाषाएँ सही होने से बाद के निर्णय सरल होते हैं: आप क्या इंडेक्स करेंगे, कैसे फ़िल्टर करेंगे, और आप क्या प्रकट करने के लिए तैयार हैं।

सुरक्षित, तेज़ सर्च के मूलभूत आवश्यकताएँ

लोग वैश्विक खोज तब इस्तेमाल करते हैं जब वे जल्दी में होते हैं। अगर यह एक सेकंड से ज्यादा लेती है, तो वे इस पर भरोसा करना बंद कर देते हैं और मैन्युअल फ़िल्टरिंग पर लौट जाते हैं। पर स्पीड ही काम नहीं है। एक तेज़ सर्च जो एक भी रिकॉर्ड टाइटल, ग्राहक नाम, या टिकट विषय लीक कर दे, वह न होने से भी बदतर है।

मुख्य नियम अपवाद के बिना है: प्रश्न समय पर अनुमतियाँ लागू करें, केवल UI में नहीं। एक पंक्ति छिपाना उसके फ़ेच होने के बाद बहुत देर हो चुकी बात है, क्योंकि सिस्टम ने पहले ही उन डेटा को छुआ है जिन्हें नहीं लौटाया जाना चाहिए था।

यह सब सर्च के आसपास की चीज़ों पर भी लागू होता है, केवल अंतिम रिजल्ट सूची पर नहीं। सुझाव, टॉप हिट्स, काउंट्स, और यहां तक कि "नो रिजल्ट" व्यवहार भी जानकारी लीक कर सकते हैं। ऑटोकम्पलीट जो किसी को नहीं खोलने योग्य "Acme Renewal Contract" दिखाता है वह लीक है। एक फ़ेसैट जो कहता है "12 matching invoices" लीक है अगर उपयोगकर्ता केवल 3 देख सकता है। यहां तक कि समय अंतर भी लीक कर सकता है अगर प्रतिबंधित मैच क्वेरी को धीमा कर दें।

एक सुरक्षित वैश्विक सर्च को चार चीज़ों की ज़रूरत है:

• शुद्धता (Correctness): हर लौटाया आइटम वर्तमान में इस उपयोगकर्ता और इस टेनेंट के लिए अनुमत होना चाहिए।
• गति (Speed): परिणाम, सुझाव और काउंट्स बड़े पैमाने पर भी लगातार तेज़ रहने चाहिए।
• संगति (Consistency): जब एक्सेस बदलती है (रोल अपडेट, टिकट रीअसाइन), सर्च व्यवहार जल्दी और पूर्वानुमेय रूप से बदलना चाहिए।
• ऑडिटेबिलिटी (Auditability): आप समझा सकें कि किसी आइटम को क्यों लौटाया गया, और जांच के लिए सर्च गतिविधि को लॉग कर सकें।

एक उपयोगी मानसिकता बदलाव: सर्च को एक और डेटा API के रूप में मानें, UI फीचर के रूप में नहीं। इसका मतलब है कि वही एक्सेस नियम जो आप सूची पेज पर लागू करते हैं, उन्हें इंडेक्स बिल्डिंग, क्वेरी निष्पादन, और हर संबंधित एंडपॉइंट (ऑटोकम्पलीट, हालिया खोजें, लोकप्रिय क्वेरीज) पर भी लागू होना चाहिए।

तीन सामान्य डिज़ाइन पैटर्न (और कब उपयोग करें)

एक सर्च बॉक्स बनाना आसान है। एक अनुमति-सूचित वैश्विक सर्च कठिन है क्योंकि इंडेक्स तुरंत परिणाम लौटाना चाहता है, जबकि आपका ऐप कभी भी उन रिकॉर्ड्स को उजागर नहीं कर सकता जिन्हें उपयोगकर्ता एक्सेस नहीं कर सकता, भले ही अप्रत्यक्ष रूप से।

नीचे तीन पैटर्न दिए गए हैं जो टीमें सबसे अधिक इस्तेमाल करती हैं। सही चुनाव इस बात पर निर्भर करता है कि आपकी एक्सेस नियम कितनी जटिल हैं और आप कितना जोखिम बर्दाश्त कर सकते हैं।

Approach A: केवल "सुरक्षित" फ़ील्ड इंडेक्स करें, फिर अनुमति जांच के बाद फ़ेच करें. आप इंडेक्स में एक न्यूनतम दस्तावेज़ स्टोर करते हैं, जैसे ID प्लस एक गैर-संवेदनशील लेबल जो किसी भी उस उपयोगकर्ता के लिए दिखाना सुरक्षित है जो सर्च UI तक पहुँचता है। जब उपयोगकर्ता किसी परिणाम पर क्लिक करता है, तो आपका ऐप प्राथमिक डेटाबेस से पूरा रिकॉर्ड लोड करता है और वहां वास्तविक अनुमति नियम लागू करता है।

यह लीक का जोखिम घटाता है, लेकिन इससे सर्च पतली लग सकती है क्योंकि उपयोगकर्ताओं को परिणामों में कम संदर्भ मिलता है। साथ ही यह सावधान UI वर्डिंग मांगता है ताकि एक "सुरक्षित" लेबल गलती से रहस्यों को उजागर न कर दे।

Approach B: इंडेक्स में अनुमति एट्रिब्यूट स्टोर करें और वहां फ़िल्टर करें. आप प्रत्येक इंडेक्स दस्तावेज़ में tenant_id, team_id, owner_id, role flags, या project_id जैसे फ़ील्ड शामिल करते हैं। हर क्वेरी वर्तमान उपयोगकर्ता के दायरे से मेल खाने वाले फ़िल्टर जोड़ती है।

यह तेज़, समृद्ध रिजल्ट और अच्छा ऑटोकम्पलीट देता है, लेकिन तब ही काम करता है जब एक्सेस नियम फ़िल्टर के रूप में व्यक्त किए जा सकते हैं। अगर अनुमति जटिल लॉजिक पर निर्भर हो (उदा., "assigned OR on-call this week OR part of an incident"), तो सही बनाए रखना कठिन हो जाता है।

Approach C: हाइब्रिड। इंडेक्स में मोटे फ़िल्टर, अंतिम सत्यापन डेटाबेस में. आप इंडेक्स में स्थिर, व्यापक एट्रिब्यूट (tenant, workspace, customer) द्वारा फ़िल्टर करते हैं, फिर प्रत्याशी IDs के छोटे सेट पर प्राथमिक डेटाबेस में पुनः-चेक करते हैं इससे पहले कि कुछ भी लौटाया जाए।

यह असल ऐप्स के लिए अक्सर सबसे सुरक्षित रास्ता है: इंडेक्स तेज रहता है, और डेटाबेस सत्यता का स्रोत बना रहता है।

पैटर्न चुनना

जब आप सबसे सरल सेटअप चाहते हैं और न्यूनतम स्निपेट स्वीकार कर सकते हैं तो A चुनें। जब आपके पास स्पष्ट, अधिकांशतः स्थिर स्कोप हों (मल्टी-टेनेंट, टीम-आधारित एक्सेस) और आपको बहुत तेज़ ऑटोकम्पलीट चाहिए तो B चुनें। जब आपके पास कई रोल, अपवाद, या रिकॉर्ड-विशिष्ट नियम हों जो अक्सर बदलते हों तो C चुनें। उच्च-जोखिम डेटा (HR, वित्त, मेडिकल) के लिए C पसंद करें क्योंकि "लगभग सही" स्वीकार्य नहीं है।

चरण-दर-चरण: ऐसा इंडेक्स डिज़ाइन करें जो एक्सेस नियमों का सम्मान करे

सबसे पहले उन एक्सेस नियमों को लिखें जैसे आप उन्हें किसी नए टीम सदस्य को समझा रहे हों। "एडमिन सबकुछ देख सकता है" तब ही लिखें जब वह सचमुच सच हो। कारण स्पष्ट लिखें: "सपोर्ट एजेंट अपने टेनेंट के टिकट देख सकते हैं। टीम लीड अपने ऑर्ग यूनिट के टिकट भी देख सकते हैं। केवल टिकट का मालिक और असाइन किए गए एजेंट निजी नोट्स देख सकते हैं।" अगर आप नहीं बता सकते कि किसी को रिकॉर्ड क्यों दिख रहा है, तो आप इसे सुरक्षित रूप से कोड करना मुश्किल पाएँगे।

फिर, एक स्थिर पहचानकर्ता चुनें और एक न्यूनतम सर्च डॉक्यूमेंट परिभाषित करें। इंडेक्स आपके डेटाबेस रो की पूरी प्रतिलिपि नहीं होना चाहिए। केवल वही रखें जो परिणाम सूची में खोजने और दिखाने के लिए जरूरी हो, जैसे शीर्षक, स्थिति, और शायद एक छोटा गैर-संवेदनशील स्निपेट। संवेदनशील फ़ील्ड्स को दूसरी फ़ेच के पीछे रखें जो अनुमतियाँ भी चेक करे।

फिर उन अनुमति संकेतों का निर्णय लें जिन्हें आप तेज़ी से फ़िल्टर कर सकते हैं। ये वे एट्रिब्यूट होते हैं जो एक्सेस को गेट करते हैं और हर इंडेक्स्ड दस्तावेज़ पर स्टोर किए जा सकते हैं, जैसे tenant_id, org_unit_id, और कुछ सीमित स्कोप फ्लैग्स। लक्ष्य यह है कि हर क्वेरी इंडेक्स में फ़िल्टर्स लागू कर सके इससे पहले कि परिणाम लौटे, जिसमें ऑटोकम्पलीट भी शामिल है।

एक व्यावहारिक वर्कफ़्लो इस प्रकार दिखता है:

1. प्रत्येक एंटिटी (टिकट, ग्राहक, चालान) के लिए दृश्यता नियम सादा भाषा में परिभाषित करें।
2. रिकॉर्ड_id के साथ एक सर्च डॉक्यूमेंट स्कीमा बनाएँ जिसमें केवल सुरक्षित, खोज करने योग्य फ़ील्ड हों।
3. हर दस्तावेज़ में फ़िल्टर करने योग्य अनुमति फ़ील्ड (tenant_id, org_unit_id, visibility_level) जोड़ें।
4. अपवादों को स्पष्ट ग्रांट्स के साथ संभालें: एक allowlist (user IDs) या साझा आइटम्स के लिए group IDs स्टोर करें।

साझा आइटम्स और अपवाद वही जगहें हैं जहाँ डिज़ाइन टूटते हैं। अगर कोई टिकट टीमों के बीच साझा हो सकता है, तो "बस एक बूलियन जोड़ दें" मत करें। स्पष्ट ग्रांट्स का उपयोग करें जिन्हें फ़िल्टर्स द्वारा चेक किया जा सके। अगर allowlist बड़ी है, तो व्यक्तिगत उपयोगकर्ताओं के बजाय ग्रुप-आधारित ग्रांट्स पसंद करें।

इंडेक्स को आश्चर्य रहित तरीके से सिंक में रखना

एक सुरक्षित सर्च अनुभव एक ऊबाऊ बात पर निर्भर करता है जो अच्छी तरह की गई हो: इंडेक्स को वास्तविकता को प्रतिबिंबित करना चाहिए। अगर एक रिकॉर्ड बनाया, बदला, हटाया गया, या उसकी अनुमतियाँ बदलीं, तो सर्च रिजल्ट्स को जल्दी और पूर्वानुमेय तरीके से फॉलो करना चाहिए।

बनाना, अपडेट, डिलीट के साथ बने रहें

इंडेक्सिंग को अपने डेटा लाइफसाइकल का हिस्सा मानें। एक उपयोगी मानसिक मॉडल है: जब भी सत्य का स्रोत बदलता है, आप एक इवेंट निकालें और इंडेक्सर उस पर प्रतिक्रिया करे।

सामान्य दृष्टिकोणों में डेटाबेस ट्रिगर्स, एप्लिकेशन इवेंट्स, या जॉब क्यू शामिल हैं। सबसे महत्वपूर्ण बात यह है कि इवेंट्स खोएँ नहीं। अगर आपका ऐप रिकॉर्ड सेव कर सकता है पर इंडेक्स करने में फेल हो सकता है, तो आप भ्रमित व्यवहार पाएँगे जैसे "मुझे पता है कि यह मौजूद है लेकिन सर्च इसे नहीं ढूँढती।"

अनुमति परिवर्तन इंडेक्स परिवर्तन हैं

कई लीक तब होते हैं जब सामग्री सही तरीके से अपडेट हो जाती है, पर एक्सेस मेटाडेटा नहीं। अनुमति परिवर्तन रोल अपडेट्स, टीम मूव्स, ओनरशिप ट्रांसफर, ग्राहक री-एसाइनमेंट, या टिकट मर्ज होने से आते हैं।

अनुमति परिवर्तन को फ़र्स्ट-क्लास इवेंट बनाएं। अगर आपकी अनुमति-सूचित सर्च tenant या team फ़िल्टर्स पर निर्भर है, तो सुनिश्चित करें कि इंडेक्स किए गए दस्तावेज़ उन फ़ील्ड्स को शामिल करें जिनकी ज़रूरत फ़िल्टर लागू करने के लिए है (tenant_id, team_id, owner_id, allowed_role_ids)। जब वे फ़ील्ड बदलें, तो रीइंडेक्स करें।

कठिन हिस्सा ब्लास्ट रेडियस है। एक रोल परिवर्तन हजारों रिकॉर्ड प्रभावित कर सकता है। प्रगति, रिट्राई, और暂停/रोकने का रास्ता रखने वाला एक बल्क रीइंडेक्स पथ योजना बनाएं।

संभाव्य संगति के लिए योजना बनाएं

अच्छे इवेंट्स के बावजूद, ऐसा एक विंडो होगा जहाँ सर्च डिले करेगा। निर्णय लें कि परिवर्तन के पहले कुछ सेकंड में उपयोगकर्ताओं को क्या दिखाना चाहिए।

दो नियम मदद करते हैं:

• देरी के बारे में सुसंगत रहें। अगर इंडेक्सिंग आमतौर पर 2–5 सेकंडों में खत्म होती है, तो जब यह मायने रखे तो उस अपेक्षा को सेट करें।
• लीक होने की तुलना में गायब होना प्राथमिकता दें। यह ज़्यादा सुरक्षित है कि नया ग्रांट किया गया रिकॉर्ड थोड़ा देर से दिखाई दे बजाय इसके कि नया रद्द किया गया रिकॉर्ड बार-बार दिखता रहे।

इंडेक्स स्टेल होने पर एक सुरक्षित फॉलबैक जोड़ें

सर्च खोज के लिए है, पर विवरण देखने पर लीक को रोकना ज़रूरी है। संवेदनशील फ़ील्ड दिखाने से पहले पढ़ने के समय पर एक दूसरा अनुमतियाँ चेक करें। अगर कोई परिणाम इंडेक्स स्टेल होने की वजह से स्लिप हो गया, तो विवरण पेज तब भी एक्सेस ब्लॉक कर दे।

एक अच्छा पैटर्न है: सर्च में न्यूनतम स्निपेट दिखाएँ, फिर उपयोगकर्ता रिकॉर्ड खोलने (या प्रीव्यू फैलाने) पर अनुमतियाँ पुनः-चेक करें। अगर चेक फेल हो, तो एक स्पष्ट संदेश दिखाएँ और अगले रिफ्रेश पर आइटम को रिज़ल्ट सेट से हटा दें।

डेटा लीक होने का कारण बनने वाली सामान्य गलतियाँ

भले ही आपकी "रिकॉर्ड खोलें" पेज लॉकडाउन हो, सर्च डेटा लीक कर सकती है। एक उपयोगकर्ता शायद कभी किसी परिणाम पर क्लिक भी न करे और फिर भी नाम, ग्राहक ID, या छिपे प्रोजेक्ट का आकार जान सकता है। अनुमति-सूचित वैश्विक सर्च को दस्तावेज़ों के साथ-साथ दस्तावेज़ों के संकेतों की भी रक्षा करनी चाहिए।

ऑटोकम्पलीट अक्सर लीक का स्रोत होता है। सुझाव अक्सर एक तेज़ प्रीफिक्स लुकअप द्वारा संचालित होते हैं जो पूर्ण अनुमति चेक छोड़ देता है। UI हानिरहित दिखती है, पर एक अक्षर टाइप करने भर से ग्राहक नाम या कर्मचारी का ईमेल उजागर हो सकता है। ऑटोकम्पलीट को वही एक्सेस फ़िल्टर चलाना चाहिए जो फुल सर्च पर चलता है, या इसे एक प्री-फ़िल्टर्ड सुझाव सेट (उदा., प्रति-टेनेंट और प्रति-रोल) से बनाना चाहिए।

फ़ेसैट काउंट्स और "About 1,243 results" बैनर एक और शांत लीक हैं। काउंट्स यह पुष्टि कर सकते हैं कि कुछ मौजूद है भले ही आप रिकॉर्ड्स छिपा रहे हों। अगर आप उन्हीं एक्सेस नियमों के तहत सुरक्षित रूप से काउंट नहीं कर सकते, तो कम जानकारी दिखाएँ या काउंट्स को हटा दें।

कैशिंग भी एक आम वजह है। उपयोगकर्ताओं, रोल्स, या टेनेंट्स के बीच साझा कैशेस "रिजल्ट घोस्ट्स" बना सकती हैं, जहाँ एक उपयोगकर्ता दूसरे के लिए बनाए गए परिणाम देख लेता है। यह एज कैशेस, एप्लिकेशन-लेवल कैशेस, और किसी सर्च सर्विस के अंदर मेमोरी कैशेस में हो सकता है।

जांच करने के लिए लीक ट्रैप्स:

• ऑटोकम्पलीट और हालिया खोजें वही नियम फ़िल्टर करें जो फुल सर्च करती है।
• फ़ेसैट काउंट्स और टोटल्स अनुमतियों के बाद ही कम्प्यूट किए जाएँ।
• कैश कीज़ में tenant ID और एक permission signature (role, team, user ID) शामिल हों।
• लॉग्स और एनालिटिक्स संवेदनशील डेटा के लिए कच्चे क्वेरीज या स्निपेट्स न स्टोर करें।

अंत में, ओवर-ब्रॉड फ़िल्टर्स से सावधान रहें। "केवल टेनेंट द्वारा फ़िल्टर" क्लासिक मल्टी-टेनेंट गलती है, पर यह एक ही टेनेंट के अंदर भी होता है: "विभाग द्वारा फ़िल्टर" जब एक्सेस रिकॉर्ड-दर-रिकॉर्ड हो। उदाहरण: एक सपोर्ट एजेंट "refund" खोजता है और पूरे टेनेंट में मिलते-जुलते परिणाम पाता है, जिनमें VIP खाते भी शामिल हैं जो केवल एक छोटे टीम को दिखने चाहिए थे। इसका समाधान सैद्धांतिक रूप से सरल है: हर क्वेरी पाथ (सर्च, ऑटोकम्पलीट, फ़ेसैट्स, एक्स्पोर्ट्स) में रो-स्तरीय नियम लागू करें, सिर्फ़ रिकॉर्ड व्यू में नहीं।

लोग भूल जाते हैं ऐसे प्राइवेसी और सुरक्षा विवरण

कई डिज़ाइनों में ध्यान "कौन क्या देख सकता है" पर होता है, पर लीक किनारों से भी होते हैं: खाली अवस्थाएँ, समय, और UI में छोटे सुराग। अनुमति-सूचित सर्च को तब भी सुरक्षित होना चाहिए जब यह कुछ भी न लौटाए।

एक आसान लीक पुष्टि द्वारा अनुपस्थिति है। अगर एक अनधिकृत उपयोगकर्ता किसी विशिष्ट ग्राहक नाम, टिकट ID, या ईमेल को खोजता है और उसे एक विशेष संदेश मिलता है जैसे "No access" या "You don't have permission," तो आपने रिकॉर्ड मौजूद होने की पुष्टि कर दी है। "कोई परिणाम नहीं" दोनों स्थितियों के लिए डिफ़ॉल्ट परिणाम होना चाहिए: "नहीं है" और "मौजूद है पर अनुमति नहीं है"। प्रतिक्रिया समय और वाक्यरचना सुसंगत रखें ताकि लोग गति के आधार पर अंदाज़ा न लगा सकें।

संवेदनशील आंशिक मैच

ऑटोकम्पलीट और टाइप करते समय खोज_privacy सबसे अधिक लीक होती है। ईमेल, फोन नंबर, और सरकारी या ग्राहक ID पर आंशिक मैच अधिक प्रकट कर सकते हैं। पहले तय करें कि ये फ़ील्ड्स कैसे व्यवहार करें।

एक व्यावहारिक नियम सेट:

• उच्च-जोखिम फ़ील्ड्स (ईमेल, फोन, ID) के लिए सटीक मैच आवश्यक रखें।
• छिपे टेक्स्ट को उजागर करने वाले हाइलाइट किए गए स्निपेट दिखाने से बचें।
• संवेदनशील फ़ील्ड्स के लिए ऑटोकम्पलीट को पूरी तरह अक्षम करने पर विचार करें।

अगर एक भी अक्षर किसी को डेटा अनुमान लगाने में मदद करता है, तो उसे संवेदनशील मानें।

ऐसे अपराध नियंत्रण जो नए जोखिम न बनाएं

सर्च एंडपॉइंट्स एन्ुमरेशन अटैक्स के लिए आदर्श हैं: बहुत सारी क्वेरीज आज़माकर यह मैप करना कि क्या मौजूद है। रेट लिमिट्स और अनॉमली डिटेक्शन जोड़ें, पर जो आप स्टोर करते हैं उसके साथ सावधान रहें। कच्चे क्वेरीज वाले लॉग एक दूसरा डेटा लीक बन सकते हैं।

सरल रखें: प्रति उपयोगकर्ता, प्रति IP, और प्रति टेनेंट रेट लिमिट करें; काउंट्स, टाइमिंग, और मोटे पैटर्न (कच्चा क्वेरी टेक्स्ट नहीं) लॉग करें; फेर से जीतने वाले "near-miss" क्वेरीज पर अलर्ट करें (जैसे क्रमिक IDs); और बार-बार विफलताओं पर ब्लॉक या सत्यापन बढ़ाएँ।

अपनी एरर मैसेजेस उबाऊ रखें। "No results," "not allowed," और "invalid filters" के लिए एक ही संदेश और खाली अवस्था उपयोग करें। जितना कम आपकी सर्च UI कहेगी, उतना कम यह गलती से कुछ प्रकट कर सकती है।

उदाहरण: सपोर्ट टीम जो ग्राहकों के पार टिकट खोज रही है

एक सपोर्ट एजेंट, Maya, तीन ग्राहक अकाउंट्स को संभालने वाली टीम पर काम करती है। उसके ऐप हेडर में एक सर्च बॉक्स है। प्रोडक्ट में टिकट्स, संपर्क और कंपनियों पर एक वैश्विक इंडेक्स है, पर हर परिणाम को एक्सेस नियमों का पालन करना चाहिए।

Maya "Alic" टाइप करती है क्योंकि कॉलर ने कहा कि उनका नाम Alice है। ऑटोकम्पलीट कुछ सुझाव दिखाता है। वह "Alice Nguyen - Ticket: Password reset" पर क्लिक करती है। कुछ भी खोलने से पहले, ऐप उस रिकॉर्ड के लिए एक्सेस फिर से चेक करता है। अगर टिकट अभी भी उसकी टीम को असाइन है और उसकी भूमिका इसकी अनुमति देती है, तो वह टिकट पर पहुँच जाती है।

Maya को प्रत्येक चरण पर क्या दिखता है:

• सर्च बॉक्स: सुझाव तेज़ी से दिखाई देते हैं, पर केवल वे रिकॉर्ड जो वह अभी एक्सेस कर सकती हैं।
• रिजल्ट लिस्ट: टिकट का विषय, ग्राहक नाम, अंतिम अपडेट समय। कोई "you don't have access" प्लेसहोल्डर नहीं।
• टिकट विवरण: पूरा व्यू केवल एक सेकंड-सर्वर-साइड अनुमतियाँ चेक के बाद लोड होता है। अगर एक्सेस बदल गई है, तो ऐप "Ticket not found" दिखाता है ("forbidden" नहीं)।

अब तुलना करें Leo से, जो ट्रेनिंग में नया एजेंट है। उसकी भूमिका केवल उन टिकट्स को देख सकती है जो "Public to Support" के रूप में चिह्नित हों और केवल एक ग्राहक के लिए। Leo वही क्वेरी "Alic" टाइप करता है। वह कम सुझाव देखता है, और गायब सुझावों का कोई संकेत नहीं मिलता। कोई "5 results" काउंट भी नहीं जिससे अन्य मैच मौजूद हैं यह पता चले। UI बस वही दिखाती है जो वह खोल सकता है।

बाद में, एक मैनेजर "Alice Nguyen - Password reset" को Maya की टीम से एक स्पेशलाइज़्ड एस्केलेशन टीम को रीअसाइन कर देता है। एक छोटे विंडो के भीतर (अक्सर सेकंड से कुछ मिनट, आपके सिंक तरीके पर निर्भर), Maya की सर्च वह टिकट वापस नहीं दिखाती। अगर उसके पास विवरण पेज खुला है और वह रिफ्रेश करती है, तो ऐप अनुमतियाँ फिर से चेक करता है और टिकट गायब हो जाता है।

यही व्यवहार आप चाहेंगे: तेज टाइपिंग और तेज परिणाम, बिना काउंट्स, स्निपेट्स, या स्टेल इंडेक्स एंट्रीज़ के जरिए कोई डेटा सेंट न लीक हो।

चेकलिस्ट और सुरक्षित रूप से लागू करने के अगले कदम

अनुमति-सूचित वैश्विक सर्च तब ही "पूर्ण" होती है जब ऊबाऊ किनारियाँ सुरक्षित हों। कई लीक ऐसे हिस्सों में होते हैं जो सुरक्षित दिखते हैं: ऑटोकम्पलीट, रिजल्ट काउंट्स, और एक्स्पोर्ट्स।

त्वरित सुरक्षा जांच

शिप करने से पहले, रियल डेटा के साथ इन जाँचों को करें, न कि सैंपल्स के साथ:

• ऑटोकम्पलीट: कभी भी वह टाइटल, नाम, या ID सुझाव न दें जिसे उपयोगकर्ता खोल नहीं सकता।
• काउंट्स और फ़ेसैट्स: अगर आप टोटल्स या समूहित काउंट्स दिखाते हैं, तो उन्हें अनुमतियों के बाद ही कम्प्यूट करें (या काउंट्स हटाएँ)।
• एक्स्पोर्ट्स और बल्क क्रियाएँ: "वर्तमान सर्च" को एक्सपोर्ट करने पर प्रत्येक पंक्ति के लिए एक्सेस फिर से चेक करें।
• सॉर्टिंग और हाइलाइटिंग: उन फ़ील्ड्स का उपयोग न करें जिनको उपयोगकर्ता देख पाने के अनुमति नहीं है।
• "Not found" बनाम "forbidden": संवेदनशील संस्थाओं के लिए दोनों के लिए एक जैसा प्रतिक्रिया आकार विचार करें ताकि उपयोगकर्ता अस्तित्व की पुष्टि न कर सके।

एक परीक्षण योजना जिसे आप चला सकते हैं

एक छोटा रोल मैट्रिक्स बनाएं (रोल्स x एंटिटीज़) और एक डेटासेट जिसमें जानबूझकर मुश्किल केस हों: साझा रिकॉर्ड, हाल ही में रद्द की गई पहुँच, और क्रॉस-टेनेंट मिलते-जुलते आइटम्स।

इसे तीन पास में टेस्ट करें: (1) रोल मैट्रिक्स टेस्ट, जहाँ आप सत्यापित करें कि अस्वीकृत रिकॉर्ड कभी भी रिजल्ट्स, सुझावों, काउंट्स, या एक्स्पोर्ट्स में नहीं दिखाई देते; (2) "टूटने की कोशिश" टेस्ट जहां आप IDs पेस्ट करते हैं, ईमेल या फोन से सर्च करते हैं, और आंशिक मैच आज़माते हैं जो कुछ भी लौटाना नहीं चाहिए; (3) समय और कैश टेस्ट जहाँ आप अनुमतियाँ बदलते हैं और पुष्टि करते हैं कि परिणाम बिना स्टेल सुझावों के जल्दी अपडेट होते हैं।

ऑपरेशनल रूप से, उस दिन के लिए योजना बनाएं जब सर्च रिजल्ट्स "गलत दिखें"। क्वेरी संदर्भ (उपयोगकर्ता, रोल, टेनेंट) और लागू किए गए अनुमति फ़िल्टर लॉग करें, पर कच्चे संवेदनशील क्वेरी स्ट्रिंग्स या स्निपेट्स स्टोर करने से बचें। सुरक्षित डिबगिंग के लिए, एक एडमिन-ओनली टूल बनाएं जो बता सके कि रिकॉर्ड क्यों मैच हुआ और क्यों उसे अनुमति दी गई।

यदि आप AppMaster (appmaster.io) पर बना रहे हैं, तो एक व्यावहारिक तरीका यह है कि सर्च को सर्वर-साइड फ्लो के रूप में रखें: Data Designer में एंटिटीज़ और रिलेशनों को मॉडल करें, Business Processes में एक्सेस नियम लागू करें, और उसी परमिशन चेक को ऑटोकम्पलीट, रिजल्ट लिस्ट, और एक्स्पोर्ट्स के लिए पुन: उपयोग करें ताकि केवल एक जगह सही हो।