लाभ:
- प्रमाणीकरण और प्राधिकरण को अलग करने और आरबीएसी/एबीएसी के साथ न्यूनतम प्राधिकरण लागू करने की क्षमता
- उपयोगकर्ता संदर्भ में मॉडल चलाकर मिश्रित प्रॉक्सी जोखिम से बचने की क्षमता
- गुप्त प्रबंधन प्रणाली के साथ एपीआई कुंजियों को संग्रहीत और घुमाने की क्षमता
एआई सिस्टम पर हमलों का एक महत्वपूर्ण हिस्सा मॉडल को "धोखा देने" से नहीं, बल्कि चोरी हुई एपीआई कुंजी या अति-अधिकृत खाते से शुरू होता है। सुरक्षा की यह परत शास्त्रीय सूचना सुरक्षा से आती है, लेकिन एआई के संदर्भ में नए जोखिम जोड़ती है: एक मॉडल किसी और की ओर से सवारी को कॉल करता है, एक सेवा खाता सभी डेटा तक पहुंचता है, एक कुंजी GitHub पर लीक हो जाती है। इस इकाई में, हम सीखेंगे कि प्रमाणीकरण, प्राधिकरण (आरबीएसी/एबीएसी), न्यूनतम प्राधिकरण और गुप्त प्रबंधन के साथ एआई प्रणाली तक पहुंच को कैसे कम किया जाए।
प्रमाणीकरण और प्राधिकरण के बीच अंतर
दो शब्द अक्सर भ्रमित होते हैं:
- प्रमाणीकरण: "आप कौन हैं?" — यह साबित करना कि उपयोगकर्ता/सेवा वास्तव में वही है जिसके होने का वे दावा करते हैं (पासवर्ड, टोकन, प्रमाणपत्र, एमएफए)।
- प्राधिकरण: "आप क्या कर सकते हैं?" - निर्धारित करें कि प्रमाणित पक्ष किस संसाधन/कार्य तक पहुंच सकता है।
एआई सिस्टम में महत्वपूर्ण सूक्ष्मता यह है: जब मॉडल किसी उपयोगकर्ता की ओर से काम कर रहा है, तो क्या यह उस उपयोगकर्ता के अधिकार से या व्यापक सेवा खाते के साथ काम कर रहा है? उत्तरार्द्ध खतरनाक है - क्योंकि इंजेक्शन द्वारा धोखा दिया गया मॉडल सेवा खाते तक पूर्ण पहुंच प्राप्त करता है।
सावधानी: "भ्रमित डिप्टी" समस्या: एक कम-प्राधिकरण उपयोगकर्ता अप्रत्यक्ष रूप से उस डेटा तक पहुंच प्राप्त करता है जिसे वह उच्च-प्राधिकरण मॉडल को आउटसोर्स करके एक्सेस नहीं कर सकता है। मॉडल को हमेशा उपयोगकर्ता के अधिकार के संदर्भ में काम करना चाहिए, न कि उसके अपने व्यापक अधिकार के संदर्भ में।
आरबीएसी और एबीएसी
- आरबीएसी (रोल-बेस्ड एक्सेस कंट्रोल): एक्सेस उपयोगकर्ता की भूमिका पर निर्भर करता है। "सहायता विशेषज्ञ" की भूमिका ग्राहक नोट्स को पढ़ सकती है, लेकिन उन्हें हटा नहीं सकती। सरल और सामान्य.
- एबीएसी (विशेषता-आधारित पहुंच नियंत्रण): पहुंच विशेषताओं पर निर्भर करती है: उपयोगकर्ता का विभाग, डेटा का गोपनीयता लेबल, दिन का समय, नेटवर्क जहां से अनुरोध आता है। अधिक सुव्यवस्थित लेकिन अधिक जटिल।
अधिकांश संगठन आरबीएसी से शुरू करते हैं और संवेदनशील डेटा के लिए एबीएसी तक पहुंचते हैं। एआई के लिए सामान्य नियम: मॉडल को अनुरोध करने वाले उपयोगकर्ता की भूमिका/विशेषताओं के आधार पर कॉल करने वाले प्रत्येक एजेंट और उसके द्वारा एक्सेस किए गए प्रत्येक डेटा को फ़िल्टर करना चाहिए।
चरण दर चरण: न्यूनतम अधिकार का प्रयोग
- इन्वेंट्री ले लो. मॉडल किन टूल्स को कॉल करता है, किस डेटा तक पहुंचता है? उन सभी की सूची बनाएं.
- प्रत्येक पहुंच का औचित्य सिद्ध करें. "क्या इस सहायक को वास्तव में डिलीट अथॉरिटी की आवश्यकता है?" अन्यथा, इसे हटा दें.
- केवल पढ़ने योग्य डिफ़ॉल्ट. मॉडल को डिफ़ॉल्ट रूप से पढ़ने में सक्षम होना चाहिए; अलग, संकीर्ण दायरे वाले टोकन को लिखने/हटाने की आवश्यकता है।
- उपयोगकर्ता प्रसंग को स्थानांतरित करें. वाहन को उपयोगकर्ता के अधिकार से कॉल करें, सेवा खाते से नहीं।
- अल्पकालिक साख. लंबे समय तक चलने वाली कुंजियों के बजाय अल्पकालिक, स्वत: नवीनीकरण टोकन का उपयोग करें।
गुप्त प्रबंधन
रहस्य वह क्रेडेंशियल है जो गुप्त रहना चाहिए, जैसे एपीआई कुंजी, पासवर्ड, टोकन या प्रमाणपत्र। एआई परियोजनाओं में सबसे आम दुर्घटना तब होती है जब मॉडल प्रदाता की एपीआई कुंजी कोड में एम्बेडेड होती है और संस्करण नियंत्रण (गिट) में लीक हो जाती है।
सही आवेदन:
- कोड में कभी भी कुंजियाँ एम्बेड न करें; एक पर्यावरण चर या एक गुप्त प्रबंधन प्रणाली (एक सेवा जो एन्क्रिप्टेड कुंजी संग्रहीत करती है और पहुंच को नियंत्रित करती है) का उपयोग करें।
- रोटेशन: नियमित अंतराल पर कुंजियाँ नवीनीकृत करें (उदाहरण के लिए हर 90 दिन); यदि रिसाव का संदेह हो तो तुरंत रद्द करें।
- दायरे में कमी: प्रत्येक स्विच में केवल आवश्यक सेवा और आवश्यक प्राधिकरण होता है।
- ऑडिट: लॉग करें कि कुंजी का उपयोग किसने, कब और कहाँ किया।
चार प्रतिलिपि योग्य टेम्पलेट
पहुँच समीक्षा नियंत्रण संकेत:
नीचे दी गई टूल सूची में प्रत्येक टूल के लिए, मूल्यांकन करें:- क्या इस सहायक का कार्य करने के लिए इस टूल की आवश्यकता है? (हाँ/नहीं) - क्या यह केवल पढ़ने के लिए है या लिखने/मिटाने के लिए? - क्या यह टूल उपयोगकर्ता के अधिकार या सेवा खाते से कॉल किया जाता है? अनावश्यक या अत्यधिक अधिकृत लोगों को "निकालें/संशोधित करें" के रूप में चिह्नित करें।<टूल्स>{{ टूल_लिस्ट }}</टूल्स>
गुप्त रिसाव स्कैनिंग संकेत:
निम्नलिखित कोड स्निपेट में कुछ भी ढूंढें जो हार्डकोडेड रहस्य हो सकता है: एपीआई कुंजी, पासवर्ड, टोकन, कनेक्शन स्ट्रिंग, निजी कुंजी। प्रत्येक के लिए पंक्ति और प्रकार दें। प्रतिक्रिया में मान कॉपी करें;मास्क (पहले 4 अक्षर + ***).<कोड>{{ स्रोत }}</कोड>
न्यूनतम प्राधिकारी निर्णय नियम:
जब कोई नया टूल/एक्सेस अनुरोध आता है, तो पूछें:1. क्या इस पहुंच के बिना कार्य निष्पादित किया जा सकता है? -> यदि हाँ: REJECT2. क्या केवल पढ़ना ही पर्याप्त है? -> यदि हाँ: लिखने की अनुमति प्रदान करें3. क्या दायरा एक ही स्रोत तक सीमित किया जा सकता है? -> यदि हाँ: daratडिफ़ॉल्ट उत्तर "नहीं" है; पहुंच तर्क से प्राप्त होती है।
रोटेशन कैलेंडर अनुस्मारक:
प्रत्येक रहस्य के लिए, रिकॉर्ड करें: स्वामी, निर्माण तिथि, समाप्ति, दायरा। किसी भी कुंजी की रिपोर्ट करें जो 90 दिनों से अधिक हो गई है या 30 दिनों से उपयोग नहीं की गई है, उसे "रोटेशन/रद्दीकरण उम्मीदवार" के रूप में रिपोर्ट करें।
कमजोर संकेत/मजबूत संकेत
ख़राब दृष्टिकोण
मजबूत दृष्टिकोण
मॉडल एकल सेवा खाते से सभी डेटा तक पहुंचता है
मॉडल अनुरोध करने वाले उपयोगकर्ता के अधिकार के साथ पहुंचता है
एपीआई कुंजी कोड में अंतर्निहित है, यह कभी नहीं बदलती
मुख्य गुप्त प्रबंधक में रोटेशन, 90 दिन
सहायक को व्यापक "कुछ भी करने" का अधिकार
केवल पढ़ने के लिए डिफ़ॉल्ट, संकीर्ण रूप से लिखें
पहुंच की कभी समीक्षा नहीं की जाती
नियमित पहुंच की समीक्षा और निरसन
तीन मिनी मामले
केस 1 - मिश्रित प्रॉक्सी डेटा लीक। एक इन-हाउस सहायक एक सेवा खाते के साथ काम कर रहा था जिसकी सभी कर्मचारी रिकॉर्ड तक पहुंच थी। एक प्रशिक्षु उपयोगकर्ता ने "कार्यकारी वेतन तालिका को सारांशित करें" कहकर उस डेटा तक पहुंच प्राप्त की जिसे वह आम तौर पर नहीं देख पाता; क्योंकि मॉडल ने उपयोगकर्ता के नहीं, बल्कि अपने व्यापक अधिकार के संदर्भ में इस पर सवाल उठाया था। एक बार जब उपयोगकर्ता संदर्भ को स्थानांतरित करने के लिए समायोजित किया गया, तो प्रशिक्षु रिकॉर्डिंग खींचने में सक्षम था जिसे केवल वह देख सकता था।
केस 2 - लीक हुई चाबी, 2 सप्ताह में 190,000 टीएल बिल। एक डेवलपर ने मॉडल एपीआई कुंजी को एक सहायक स्क्रिप्ट में एम्बेड किया और इसे एक सार्वजनिक रिपॉजिटरी में धकेल दिया। एक बॉट ने 40 मिनट में कुंजी ढूंढ ली और दो सप्ताह तक इसका उपयोग किया; बिल 190,000 टीएल तक पहुंच गया। जब कुंजी को गुप्त प्रबंधक के पास ले जाया गया, रोटेशन से जोड़ा गया, और रिपॉजिटरी स्कैनिंग को जोड़ा गया, तो घटना दोबारा नहीं हुई।
केस 3 - केवल-पढ़ने के लिए डिफ़ॉल्ट व्यवधान को रोका गया। एक DevOps सहायक को शीघ्र इंजेक्शन के माध्यम से "रीसेट प्रोडक्शन डेटाबेस" कमांड प्राप्त हुआ। हालाँकि, सहायक को केवल रीड-ओनली टोकन दिया गया था; लिखना/मिटाना एक अलग स्वीकृत प्रवाह में था। आदेश को प्राधिकरण त्रुटि के साथ अस्वीकार कर दिया गया था और घटना को अलार्म के रूप में लॉग किया गया था; कोई डेटा हानि नहीं हुई.
टिप: नए एक्सेस अनुरोध के लिए "नहीं" को अपना डिफ़ॉल्ट उत्तर बनाएं। पहुँच एक ऐसी चीज़ है जो औचित्य के माध्यम से प्राप्त की जाती है; हर किसी को छूट देना और फिर कटौती करना लगभग कभी नहीं किया जाता है और जोखिम बढ़ जाता है।
सामान्य गलतियाँ
- एक बड़े सेवा खाते के साथ मॉडल चलाना और उपयोगकर्ता संदर्भ खोना (मिश्रित प्रॉक्सी)।
- कोड में एपीआई कुंजी को एम्बेड करना और इसे संस्करण नियंत्रण में लीक करना।
- कुंजियों को बिल्कुल न घुमाना ("काम करना, छूना नहीं")।
- सहायक को डिफ़ॉल्ट रूप से लिखने/हटाने की अनुमति देना।
- एक बार पहुंच प्रदान करना और उस पर कभी पुनर्विचार नहीं करना।
- प्राधिकरण के साथ प्रमाणीकरण को भ्रमित करना और यह मान लेना कि "वह लॉग इन है, वह सब कुछ एक्सेस कर सकता है"।
संक्षेप में
- प्रमाणीकरण "आप कौन हैं" का प्रश्न है, प्राधिकरण "आप क्या कर सकते हैं" का प्रश्न है; एआई में, दोनों को उपयोगकर्ता के संदर्भ में काम करना चाहिए।
- मॉडल को अनुरोध करने वाले उपयोगकर्ता के अधिकार के साथ काम करना चाहिए, न कि अपने स्वयं के व्यापक अधिकार के साथ (मिश्रित एजेंसी के जोखिम से बचना)।
- आरबीएसी से शुरू करें, संवेदनशील डेटा पर एबीएसी से गहराई तक जाएं; न्यूनतम प्राधिकार को डिफ़ॉल्ट बनाएं.
- रहस्यों को कोड में दफन न करें; इसे गुप्त प्रबंधक में संग्रहीत करें, इसे सीमित करें और इसे नियमित रोटेशन में डालें।
- केवल-पढ़ने के लिए डिफ़ॉल्ट और संकीर्ण लेखन इंजेक्शन के प्रभाव को बहुत सीमित कर देता है।
आवेदन कार्य
आपके AI सहायक द्वारा एक्सेस किए जाने वाले सभी टूल और डेटा की सूची बनाएं। प्रत्येक के लिए तीन प्रश्नों के उत्तर दें: (1) क्या यह वास्तव में आवश्यक है? (2) क्या केवल पढ़ना ही पर्याप्त है? (3) क्या यह उपयोगकर्ता के संदर्भ में चलता है? फिर सभी हार्ड-कोडित रहस्यों को खोजें (ऊपर स्कैन प्रॉम्प्ट के माध्यम से) और आपको मिलने वाली प्रत्येक कुंजी के लिए एक रोटेशन योजना लिखें। कम से कम एक अनावश्यक प्राधिकरण हटाएँ.
जांच सूची
- [ ] मॉडल अनुरोध करने वाले उपयोगकर्ता के प्राधिकरण संदर्भ में चलता है।
- [ ] टूल और डेटा एक्सेस को कम से कम विशेषाधिकार के सिद्धांत तक सीमित कर दिया गया है।
- [ ] लिखना/मिटाना केवल पढ़ने योग्य, प्रमाणित और संकीर्ण से अलग है।
- [ ] कोड में कोई रहस्य छिपा नहीं है; इसे सीक्रेट मैनेजर में रखा जाता है.
- [ ] चाबियों के लिए एक रोटेशन शेड्यूल और रद्दीकरण प्रक्रिया है।
- [ ] पहुंच की नियमित रूप से समीक्षा की जाती है।