प्रवेश नियंत्रण, ओळख आणि गुप्त व्यवस्थापन

नफा:

• प्रमाणीकरण आणि अधिकृतता वेगळे करण्याची आणि RBAC/ABAC सह किमान अधिकृतता लागू करण्याची क्षमता
• वापरकर्ता संदर्भात मॉडेल चालवून मिश्रित प्रॉक्सी जोखीम टाळण्याची क्षमता
• गुप्त व्यवस्थापन प्रणालीसह API की संचयित आणि फिरवण्याची क्षमता

एआय सिस्टमवरील हल्ल्यांचा एक महत्त्वाचा भाग मॉडेलला “फसवण्याने” सुरू होत नाही, तर चोरी केलेल्या API की किंवा अति-अधिकृत खात्याने सुरू होतो. सुरक्षिततेचा हा स्तर शास्त्रीय माहिती सुरक्षेतून येतो, परंतु AI च्या संदर्भात नवीन जोखीम जोडते: एक मॉडेल दुसऱ्याच्या वतीने राइड कॉल करते, सेवा खाते सर्व डेटा ऍक्सेस करते, GitHub वर की लीक होते. या युनिटमध्ये, आम्ही प्रमाणीकरण, अधिकृतता (RBAC/ABAC), किमान अधिकृतता आणि गुप्त व्यवस्थापनासह AI प्रणालीचा प्रवेश कसा कमी करायचा ते शिकू.

प्रमाणीकरण आणि अधिकृतता मधील फरक

दोन संज्ञा सहसा गोंधळात टाकतात:

• प्रमाणीकरण: "तुम्ही कोण आहात?" — वापरकर्ता/सेवा खरोखरच आहे हे सिद्ध करणे (पासवर्ड, टोकन, प्रमाणपत्र, MFA).
• अधिकृतता: "तुम्ही काय करू शकता?" — प्रमाणीकृत पक्ष कोणत्या संसाधन/कृतीत प्रवेश करू शकतो हे निर्धारित करा.

एआय सिस्टीममधील गंभीर सूक्ष्मता ही आहे: जेव्हा मॉडेल वापरकर्त्याच्या वतीने कार्य करत असते, तेव्हा ते त्या वापरकर्त्याच्या अधिकाराने किंवा विस्तृत सेवा खात्यासह कार्य करते? नंतरचे धोकादायक आहे — कारण इंजेक्शनद्वारे फसलेल्या मॉडेलला सेवा खात्यात पूर्ण प्रवेश मिळतो.

खबरदारी: "कन्फ्युज्ड डेप्युटी" ​​समस्या: कमी-अधिकृत वापरकर्ता अप्रत्यक्षपणे डेटा ऍक्सेस करतो जो तो उच्च-अधिकृत मॉडेल आउटसोर्सिंगद्वारे ऍक्सेस करू शकत नाही. मॉडेलने नेहमी वापरकर्त्याच्या अधिकाराच्या संदर्भात कार्य केले पाहिजे, त्याच्या स्वत: च्या व्यापक अधिकाराच्या नव्हे.

RBAC आणि ABAC

• RBAC (भूमिका-आधारित प्रवेश नियंत्रण): प्रवेश वापरकर्त्याच्या भूमिकेवर अवलंबून असतो. "समर्थन विशेषज्ञ" भूमिका ग्राहकांच्या नोट्स वाचू शकते, परंतु त्या हटवू शकत नाही. साधे आणि सामान्य.
• ABAC (विशेषता-आधारित प्रवेश नियंत्रण): प्रवेश गुणधर्मांवर अवलंबून असतो: वापरकर्त्याचा विभाग, डेटाचे गोपनीयता लेबल, दिवसाची वेळ, विनंती ज्या नेटवर्कवरून येते. अधिक सुरेख परंतु अधिक जटिल.

बऱ्याच संस्था RBAC ने सुरू करतात आणि संवेदनशील डेटासाठी ABAC पर्यंत खोलवर जातात. AI साठी अंगठ्याचा नियम: मॉडेलने कॉल केलेल्या प्रत्येक एजंटला आणि विनंती करणाऱ्या वापरकर्त्याच्या भूमिकेच्या/विशेषतेच्या आधारावर त्याने प्रवेश केलेला प्रत्येक डेटा फिल्टर केला पाहिजे.

स्टेप बाय स्टेप: किमान अधिकार वापरणे

1. यादी घ्या. मॉडेल कोणत्या साधनांवर कॉल करते, ते कोणत्या डेटामध्ये प्रवेश करते? त्या सर्वांची यादी करा.
2. प्रत्येक प्रवेशाचे समर्थन करा. "या सहाय्यकाला खरोखर हटविण्याचा अधिकार आवश्यक आहे का?" अन्यथा, ते काढून टाका.
3. केवळ-वाचनीय डीफॉल्ट. मॉडेल डीफॉल्टनुसार वाचण्यास सक्षम असावे; स्वतंत्र, अरुंद-स्कोप टोकन लिहा/हटवा आवश्यक आहे.
4. वापरकर्ता संदर्भ हलवा. वापरकर्त्याच्या अधिकाराने वाहन कॉल करा, सेवा खात्यासह नाही.
5. अल्पायुषी ओळखपत्र. दीर्घकालीन कींऐवजी अल्पायुषी, स्वयं-नूतनीकरण टोकन वापरा.

गुप्त व्यवस्थापन

एपीआय की, पासवर्ड, टोकन किंवा प्रमाणपत्र यासारखे गुप्त असणे आवश्यक असलेली क्रेडेन्शियल्स आहे. AI प्रकल्पांमध्ये सर्वात सामान्य अपघात म्हणजे जेव्हा मॉडेल प्रदात्याची API की कोडमध्ये एम्बेड केली जाते आणि आवृत्ती नियंत्रण (Git) मध्ये लीक होते.

योग्य अर्ज:

• कोडमध्ये की कधीही एम्बेड करू नका; पर्यावरण व्हेरिएबल किंवा गुप्त व्यवस्थापन प्रणाली वापरा (एक सेवा जी एनक्रिप्टेड की संग्रहित करते आणि प्रवेश नियंत्रित करते).
• रोटेशन: नियमित अंतराने की नूतनीकरण करा (उदा. दर 90 दिवसांनी); गळतीचा संशय असल्यास, त्वरित रद्द करा.
• व्याप्ती कमी करणे: प्रत्येक स्विचमध्ये फक्त आवश्यक सेवा आणि आवश्यक अधिकृतता असते.
• ऑडिट: किल्ली कोणी, केव्हा आणि कुठे वापरली याची नोंद करा.

चार कॉपी करण्यायोग्य टेम्पलेट्स

प्रवेश पुनरावलोकन नियंत्रण प्रॉम्प्ट:

खालील साधन सूचीमधील प्रत्येक साधनासाठी, मूल्यमापन करा:- या सहाय्यकाचे कार्य करण्यासाठी हे साधन आवश्यक आहे का? (होय/नाही) - हे केवळ वाचनीय आहे की लिहा/मिटवा? - हे साधन वापरकर्त्याच्या अधिकार किंवा सेवा खात्यासह कॉल केले जाते? अनावश्यक किंवा अत्याधिक अधिकृत "काढून टाका/रिडॅक्ट" म्हणून चिन्हांकित करा.<tools>{{ tool_list }}</tools>

गुप्त गळती स्कॅनिंग प्रॉम्प्ट:

खालील कोड स्निपेटमध्ये हार्डकोड केलेले रहस्य असू शकते असे काहीही शोधा: API की, पासवर्ड, टोकन, कनेक्शन स्ट्रिंग, खाजगी की. प्रत्येकासाठी पंक्ती द्या आणि टाइप करा. प्रतिसादात मूल्य कॉपी करा;मुखवटा (प्रथम 4 वर्ण + ***).<code>{{ स्त्रोत }}</code>

किमान अधिकार निर्णय नियम:

जेव्हा नवीन साधन/प्रवेश विनंती येते, तेव्हा विचारा:1. या प्रवेशाशिवाय कार्य केले जाऊ शकते? -> होय असल्यास: REJECT2. केवळ वाचन पुरेसे आहे का? -> होय असल्यास: लिहिण्याची परवानगी द्या3. व्याप्ती एका स्रोतापर्यंत कमी करता येईल का? -> होय असल्यास: दारात डीफॉल्ट उत्तर "नाही" आहे; प्रवेश कारणाने मिळतो.

रोटेशन कॅलेंडर स्मरणपत्र:

प्रत्येक गुप्ततेसाठी, रेकॉर्ड: मालक, निर्मिती तारीख, कालबाह्यता, व्याप्ती. "रोटेशन/रद्द करणे उमेदवार" म्हणून 90 दिवसांपेक्षा जास्त किंवा 30 दिवसांपासून वापरल्या गेलेल्या कोणत्याही कीचा अहवाल द्या.

कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट

गरीब दृष्टीकोन

मजबूत दृष्टीकोन

मॉडेल एका सेवा खात्यासह सर्व डेटामध्ये प्रवेश करते

विनंती करणाऱ्या वापरकर्त्याच्या अधिकाराने मॉडेलमध्ये प्रवेश होतो

API की कोडमध्ये एम्बेड केलेली आहे, ती कधीही बदलत नाही

की गुप्त व्यवस्थापक मध्ये रोटेशन, 90 दिवस

सहाय्यकाला ब्रॉड "काहीही करा" अधिकार

केवळ-वाचनीय डीफॉल्ट, संकुचितपणे लिहा

प्रवेशांचे कधीही पुनरावलोकन केले जात नाही

नियमित प्रवेश पुनरावलोकन आणि निरस्तीकरण

तीन मिनी केसेस

केस 1 - लीक मिश्रित प्रॉक्सी डेटा. एक इन-हाऊस सहाय्यक एका सेवा खात्यासह काम करत होता ज्यात सर्व कर्मचाऱ्यांच्या रेकॉर्डमध्ये प्रवेश होता. एका इंटर्न वापरकर्त्याने "कार्यकारी वेतन सारणी सारांशित करा" असे सांगून सामान्यतः न दिसणारा डेटा ऍक्सेस केला; कारण मॉडेलने त्याच्या स्वतःच्या व्यापक अधिकाराच्या संदर्भात प्रश्न केला आहे, वापरकर्त्याच्या नाही. एकदा वापरकर्ता संदर्भ हलवण्याकरता समायोजित केल्यावर, इंटर्न फक्त तो किंवा ती पाहू शकणाऱ्या रेकॉर्डिंग्ज काढू शकला.

केस 2 — लीक की, 2 आठवड्यात 190,000 TL बिल. एका विकसकाने मॉडेल API की हेल्पर स्क्रिप्टमध्ये एम्बेड केली आणि ती सार्वजनिक भांडारात ढकलली. एका बॉटला 40 मिनिटांत किल्ली सापडली आणि ती दोन आठवडे वापरली; बिल 190,000 TL वर पोहोचले. जेव्हा की गुप्त व्यवस्थापकाकडे हलवली गेली, रोटेशनशी कनेक्ट केली गेली आणि रिपॉझिटरी स्कॅनिंग जोडली गेली, तेव्हा घटना पुन्हा घडली नाही.

केस 3 - केवळ-वाचनीय डीफॉल्ट व्यत्यय प्रतिबंधित. DevOps सहाय्यकाला प्रॉम्प्ट इंजेक्शनद्वारे "रीसेट प्रॉडक्शन डेटाबेस" कमांड प्राप्त झाली. मात्र, सहाय्यकाला केवळ वाचनीय टोकन देण्यात आले; लिहा/मिटवा वेगळ्या मंजूर प्रवाहात होता. अधिकृतता त्रुटीसह आदेश नाकारण्यात आला आणि इव्हेंट अलार्म म्हणून लॉग केला गेला; डेटा गमावला नाही.

टीप: नवीन प्रवेश विनंतीसाठी तुमचे डीफॉल्ट उत्तर "नाही" बनवा. प्रवेश म्हणजे औचित्याने मिळवलेली गोष्ट; प्रत्येकाला विस्तृत देणे आणि नंतर कट करणे जवळजवळ कधीच केले जात नाही आणि जोखीम जमा होते.

सामान्य चुका

• मोठ्या सेवा खात्यासह मॉडेल चालवणे आणि वापरकर्ता संदर्भ गमावणे (मिश्र प्रॉक्सी).
• कोडमध्ये API की एम्बेड करणे आणि आवृत्ती नियंत्रणामध्ये लीक करणे.
• की अजिबात फिरवत नाही ("कार्यरत, स्पर्श करू नका").
• सहाय्यकाला बाय डीफॉल्ट लिहिणे/हटवण्याची परवानगी देणे.
• एकदा प्रवेश मंजूर करणे आणि त्याचा कधीही पुनर्विचार न करणे.
• अधिकृततेसह प्रमाणीकरण गोंधळात टाकणे आणि "त्याने लॉग इन केले आहे, तो सर्वकाही ऍक्सेस करू शकतो" असे गृहीत धरते.

सारांशात

• प्रमाणीकरण हा “तुम्ही कोण आहात” हा प्रश्न आहे, अधिकृतता हा “तुम्ही काय करू शकता” हा प्रश्न आहे; AI मध्ये, दोन्ही वापरकर्त्याच्या संदर्भात ऑपरेट करणे आवश्यक आहे.
• मॉडेलने विनंती करणाऱ्या वापरकर्त्याच्या अधिकाराने कार्य केले पाहिजे, स्वतःच्या व्यापक अधिकाराने (मिश्र एजन्सीचा धोका टाळून).
• RBAC सह प्रारंभ करा, संवेदनशील डेटावर ABAC सह सखोल करा; किमान अधिकार डीफॉल्ट बनवा.
• कोडमध्ये रहस्ये दफन करू नका; ते गुप्त व्यवस्थापकात संग्रहित करा, ते अरुंद करा आणि नियमित रोटेशनमध्ये ठेवा.
• केवळ-वाचनीय डीफॉल्ट आणि अरुंद लेखन इंजेक्शनचा प्रभाव मोठ्या प्रमाणात मर्यादित करतात.

अर्ज कार्य

तुमचा AI सहाय्यक प्रवेश करत असलेली सर्व साधने आणि डेटा सूचीबद्ध करा. प्रत्येकासाठी तीन प्रश्नांची उत्तरे द्या: (१) ते खरोखर आवश्यक आहे का? (२) फक्त वाचन पुरेसे आहे का? (3) ते वापरकर्ता संदर्भात चालते का? नंतर सर्व हार्ड-कोडेड रहस्ये शोधा (वरील स्कॅन प्रॉम्प्टद्वारे) आणि तुम्हाला सापडलेल्या प्रत्येक कीसाठी एक रोटेशन प्लॅन लिहा. किमान एक अनावश्यक अधिकृतता काढा.

चेकलिस्ट

• [ ] मॉडेल विनंती करणाऱ्या वापरकर्त्याच्या अधिकाराच्या संदर्भात चालते.
• साधन आणि डेटा ऍक्सेस कमीत कमी विशेषाधिकाराच्या तत्त्वापर्यंत कमी करण्यात आला आहे.
• [ ] लिहा/मिटवा हे केवळ-वाचनीय, प्रमाणीकृत आणि अरुंद पासून वेगळे आहे.
• [ ] कोडमध्ये कोणतीही रहस्ये दडलेली नाहीत; ते गुप्त व्यवस्थापकात ठेवले जाते.
• की साठी एक रोटेशन शेड्यूल आणि रद्द करण्याची प्रक्रिया आहे.
• प्रवेशांचे नियमितपणे पुनरावलोकन केले जाते.