लाभ:
- प्रमाणीकरण र प्राधिकरणलाई अलग गर्ने र RBAC/ABAC सँग न्यूनतम प्राधिकरण लागू गर्ने क्षमता
- प्रयोगकर्ता सन्दर्भमा मोडेल चलाएर मिश्रित प्रोक्सी जोखिमबाट बच्नको लागि क्षमता
- गोप्य व्यवस्थापन प्रणालीसँग API कुञ्जीहरू भण्डारण र घुमाउने क्षमता
एआई प्रणालीमा हुने आक्रमणहरूको एउटा महत्त्वपूर्ण भाग मोडेललाई "ठक" गरेर होइन, तर चोरी भएको एपीआई कुञ्जी वा अतिअधिकृत खाताबाट सुरु हुन्छ। सुरक्षाको यो तह शास्त्रीय सूचना सुरक्षाबाट आउँछ, तर AI को सन्दर्भमा नयाँ जोखिमहरू थप्छ: एक मोडेलले अरू कसैको तर्फबाट सवारीलाई कल गर्छ, सेवा खाताले सबै डेटा पहुँच गर्छ, GitHub मा कुञ्जी लीक हुन्छ। यस एकाईमा, हामी प्रमाणीकरण, प्राधिकरण (RBAC/ABAC), न्यूनतम प्राधिकरण र गोप्य व्यवस्थापनको साथ AI प्रणालीमा पहुँच कसरी सीमित गर्ने भनेर सिक्नेछौं।
प्रमाणीकरण र प्राधिकरण बीचको भिन्नता
दुई सर्तहरू अक्सर भ्रमित हुन्छन्:
- प्रमाणीकरण: "तिमी को हौ?" - प्रमाणित गर्दै कि प्रयोगकर्ता/सेवा वास्तवमा तिनीहरूले दाबी गर्ने व्यक्ति हो (पासवर्ड, टोकन, प्रमाणपत्र, MFA)।
- प्राधिकरण: "तपाईं के गर्न सक्नुहुन्छ?" - प्रमाणित पक्षले कुन स्रोत/कार्यमा पहुँच गर्न सक्छ भनेर निर्धारण गर्नुहोस्।
एआई प्रणालीहरूमा महत्वपूर्ण सूक्ष्मता यो हो: जब मोडेलले प्रयोगकर्ताको तर्फबाट काम गरिरहेको छ, के त्यो प्रयोगकर्ताको अख्तियार वा व्यापक सेवा खातासँग काम गरिरहेको छ? पछिल्लो खतरनाक छ - किनभने इंजेक्शन द्वारा ठगिएको मोडेलले सेवा खातामा पूर्ण पहुँच प्राप्त गर्दछ।
सावधानी: "कन्फ्युज्ड डिप्टी" समस्या: कम-अधिकार प्रयोगकर्ताले अप्रत्यक्ष रूपमा डेटा पहुँच गर्दछ जुन उसले उच्च-अधिकार मोडेल आउटसोर्सिङ गरेर पहुँच गर्न सक्दैन। मोडेल सधैं प्रयोगकर्ताको अख्तियारको सन्दर्भमा काम गर्नुपर्छ, आफ्नो व्यापक अधिकार होइन।
RBAC र ABAC
- RBAC (भूमिकामा आधारित पहुँच नियन्त्रण): पहुँच प्रयोगकर्ताको भूमिकामा निर्भर गर्दछ। "समर्थन विशेषज्ञ" भूमिकाले ग्राहक नोटहरू पढ्न सक्छ, तर तिनीहरूलाई मेटाउन सक्दैन। सरल र सामान्य।
- ABAC (विशेषता-आधारित पहुँच नियन्त्रण): पहुँच विशेषताहरूमा निर्भर गर्दछ: प्रयोगकर्ताको विभाग, डेटाको गोपनीयता लेबल, दिनको समय, अनुरोध आएको नेटवर्क। थप फाइन-ट्यून तर थप जटिल।
धेरै संस्थाहरू RBAC बाट सुरु हुन्छ र संवेदनशील डेटाको लागि ABAC मा गहिरो हुन्छ। AI को लागि थम्बको नियम: मोडेलले अनुरोध गर्ने प्रयोगकर्ताको भूमिका/विशेषताहरूको आधारमा उसले कल गर्ने हरेक एजेन्ट र पहुँच गर्ने प्रत्येक डेटा फिल्टर गर्नुपर्छ।
चरण-दर-चरण: न्यूनतम अधिकार प्रयोग गर्दै
- सूची लिनुहोस्। मोडेलले कुन उपकरणलाई कल गर्छ, कुन डाटा पहुँच गर्छ? ती सबै सूचीबद्ध गर्नुहोस्।
- प्रत्येक पहुँच औचित्य गर्नुहोस्। "के यो सहायकलाई साँच्चै मेटाउने अधिकार चाहिन्छ?" अन्यथा, यसलाई हटाउनुहोस्।
- पढ्ने मात्र पूर्वनिर्धारित। मोडेल पूर्वनिर्धारित रूपमा पढ्न सक्षम हुनुपर्छ; छुट्टै, संकीर्ण-स्कोप टोकन लेख्न/मेटाउन आवश्यक छ।
- प्रयोगकर्ता सन्दर्भ सार्नुहोस्। सेवा खातामा नभई प्रयोगकर्ताको अख्तियारमा गाडी कल गर्नुहोस्।
- अल्पकालीन प्रमाण। लामो समय टिक्ने कुञ्जीहरूको सट्टा अल्पकालीन, स्वत: नवीकरण टोकनहरू प्रयोग गर्नुहोस्।
गोप्य व्यवस्थापन
गोप्य प्रमाणहरू हुन् जुन गोप्य रहनुपर्छ, जस्तै API कुञ्जी, पासवर्ड, टोकन, वा प्रमाणपत्र। एआई परियोजनाहरूमा सबैभन्दा सामान्य दुर्घटना भनेको मोडेल प्रदायकको एपीआई कुञ्जी कोडमा इम्बेड गरिएको हो र संस्करण नियन्त्रण (गिट) मा लीक हुन्छ।
सही आवेदन:
- कोडमा कुञ्जीहरू कहिल्यै इम्बेड नगर्नुहोस्; वातावरण चर वा गोप्य व्यवस्थापन प्रणाली प्रयोग गर्नुहोस् (कुञ्जीहरू इन्क्रिप्टेड र पहुँच नियन्त्रण गर्ने सेवा)।
- परिक्रमा: नियमित अन्तरालहरूमा कुञ्जीहरू नवीकरण गर्नुहोस् (जस्तै प्रत्येक 90 दिनमा); यदि चुहावट शंकास्पद छ भने, तुरुन्तै रद्द गर्नुहोस्।
- स्कोप घटाउने: प्रत्येक स्विचमा आवश्यक सेवा र आवश्यक प्राधिकरण मात्र हुन्छ।
- लेखापरीक्षण: कुञ्जी कसले, कहिले, कहाँ प्रयोग गर्यो लगाउनुहोस्।
चार प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू
पहुँच समीक्षा नियन्त्रण प्रम्प्ट:
तलको उपकरण सूचीमा प्रत्येक उपकरणको लागि, मूल्याङ्कन गर्नुहोस्: - के यो सहायकको काम गर्न यो उपकरण आवश्यक छ? (हो/होइन) - यो पढ्ने मात्र हो वा लेख्न/मेटाउने? - के यो उपकरण प्रयोगकर्ताको अख्तियार वा सेवा खातासँग बोलाइन्छ? अनावश्यक वा अत्यधिक अधिकृतहरूलाई "हटाउनुहोस्/REDACT" को रूपमा चिन्ह लगाउनुहोस्।<tools>{{ tool_list }}</tools>
गोप्य चुहावट स्क्यानिङ प्रम्प्ट:
निम्न कोड स्निपेटमा हार्डकोड गरिएको गोप्य हुन सक्ने कुनै पनि कुरा फेला पार्नुहोस्: API कुञ्जी, पासवर्ड, टोकन, जडान स्ट्रिङ, निजी कुञ्जी। पङ्क्ति दिनुहोस् र प्रत्येकको लागि टाइप गर्नुहोस्। प्रतिक्रियामा मान प्रतिलिपि गर्नुहोस्; मास्क (पहिलो 4 वर्ण + ***)।<code>{{ स्रोत }}</code>
न्यूनतम प्राधिकरण निर्णय नियम:
जब नयाँ उपकरण/पहुँच अनुरोध आउँछ, सोध्नुहोस्: १। यो पहुँच बिना कार्य गर्न सकिन्छ? -> यदि हो भने: अस्वीकार गर्नुहोस्2। के पढ्ने मात्र पर्याप्त छ? -> यदि हो भने: लेख्न अनुमति दिनुहोस्3। के दायरा एउटै स्रोतमा सीमित गर्न सकिन्छ? -> यदि हो: darat पूर्वनिर्धारित जवाफ "होइन" हो; पहुँच कारणले प्राप्त हुन्छ।
परिक्रमा क्यालेन्डर रिमाइन्डर:
प्रत्येक गोप्यको लागि, रेकर्ड: मालिक, सिर्जना मिति, म्याद समाप्ति, दायरा। ९० दिन नाघेको वा ३० दिनसम्म प्रयोग नगरिएको कुनै पनि कुञ्जीलाई "ROTATION/CANCELLATION CANDIDATE" को रूपमा रिपोर्ट गर्नुहोस्।
कमजोर प्रम्प्ट / बलियो प्रम्प्ट
गरीब दृष्टिकोण
बलियो दृष्टिकोण
मोडेलले एकल सेवा खाताको साथ सबै डेटा पहुँच गर्दछ
मोडेलले अनुरोध गर्ने प्रयोगकर्ताको अधिकारसँग पहुँच गर्दछ
API कुञ्जी कोडमा इम्बेड गरिएको छ, यो कहिल्यै परिवर्तन हुँदैन
कुञ्जी गोप्य प्रबन्धकमा रोटेशन, 90 दिन
सहायकलाई व्यापक "केही गर्नुहोस्" अधिकार
पढ्ने मात्र पूर्वनिर्धारित, संकीर्ण लेख्नुहोस्
पहुँचहरू कहिल्यै समीक्षा गरिँदैन
नियमित पहुँच समीक्षा र खारेज
तीन मिनी केसहरू
केस १ - लीक गरिएको मिश्रित प्रोक्सी डाटा। एक इन-हाउस सहायकले सबै कर्मचारी रेकर्डहरूमा पहुँच भएको सेवा खातासँग काम गरिरहेको थियो। एक इन्टर्न प्रयोगकर्ताले डेटा पहुँच गर्यो जुन उसले सामान्यतया "कार्यकारी तलब तालिका संक्षेप गर्नुहोस्" भन्दै देख्दैन; किनभने मोडेलले यसको आफ्नै व्यापक अधिकारको सन्दर्भमा प्रश्न उठायो, प्रयोगकर्ताको होइन। एक पटक प्रयोगकर्ता सन्दर्भ सार्नको लागि समायोजन गरिसकेपछि, इन्टर्नले रेकर्डिङहरू तान्न सक्षम भयो जुन केवल उसले देख्न सक्छ।
केस २ — लीक गरिएको कुञ्जी, २ हप्तामा १९०,००० TL बिल। एक विकासकर्ताले सहायक लिपिमा मोडेल API कुञ्जी इम्बेड गर्यो र यसलाई सार्वजनिक भण्डारमा पुश गर्यो। एउटा बोटले 40 मिनेटमा चाबी फेला पार्यो र यसलाई दुई हप्तासम्म प्रयोग गर्यो; बिल 190,000 TL पुग्यो। जब कुञ्जी गोप्य प्रबन्धकमा सारियो, रोटेशनमा जडान गरियो, र भण्डार स्क्यानिङ थपियो, घटना पुन: दोहोरिएन।
केस 3 - पढ्ने-मात्र पूर्वनिर्धारित अवरोध रोकियो। एक DevOps सहायकले प्रोम्प्ट इंजेक्शन मार्फत "उत्पादन डाटाबेस रिसेट गर्नुहोस्" आदेश प्राप्त गर्यो। यद्यपि, सहायकलाई केवल पढ्ने-मात्र टोकन दिइएको थियो; लेख्न/मेटाउने छुट्टै स्वीकृत प्रवाहमा थियो। आदेशलाई प्राधिकरण त्रुटिको साथ अस्वीकार गरियो र घटनालाई अलार्मको रूपमा लगाइएको थियो; त्यहाँ कुनै डाटा हानि थिएन।
सुझाव: नयाँ पहुँच अनुरोधको लागि आफ्नो पूर्वनिर्धारित जवाफ "होइन" बनाउनुहोस्। पहुँच औचित्य मार्फत प्राप्त भएको कुरा हो; सबैलाई फराकिलो दिने र त्यसपछि काट्ने काम लगभग कहिले पनि हुँदैन र जोखिम जम्मा हुन्छ।
सामान्य गल्तीहरू
- ठूलो सेवा खाताको साथ मोडेल चलाउँदै र प्रयोगकर्ता सन्दर्भ (मिश्रित प्रोक्सी) गुमाउँदै।
- कोडमा API कुञ्जी इम्बेड गर्दै र संस्करण नियन्त्रणमा लीक गर्दै।
- कुञ्जीहरू पटक्कै घुमाउँदैन ("काम गर्दै, छुनुहोस्")।
- सहायकलाई पूर्वनिर्धारित रूपमा लेख्ने/मेटाउने अनुमति दिँदै।
- एक पटक पहुँच प्रदान गर्ने र यसलाई कहिल्यै पुनर्विचार नगर्ने।
- प्राधिकरणको साथ प्रमाणीकरणलाई भ्रमित गर्दै र "उनी लग इन छ, उसले सबै कुरा पहुँच गर्न सक्छ" भनी मान्दै।
संक्षेपमा
- प्रमाणीकरण "तपाई को हुनुहुन्छ" को प्रश्न हो, प्राधिकरण "तपाई के गर्न सक्नुहुन्छ" को प्रश्न हो; AI मा, दुबै प्रयोगकर्ताको सन्दर्भमा काम गर्नुपर्छ।
- मोडेलले अनुरोध गर्ने प्रयोगकर्ताको अख्तियारसँग काम गर्नुपर्छ, यसको आफ्नै बृहत् अधिकारसँग होइन (मिश्रित एजेन्सीको जोखिमलाई बेवास्ता गर्दै)।
- RBAC बाट सुरु गर्नुहोस्, संवेदनशील डेटामा ABAC सँग गहिरो बनाउनुहोस्; न्यूनतम अधिकारलाई पूर्वनिर्धारित बनाउनुहोस्।
- कोडमा गोप्य कुराहरू नदिनुहोस्; यसलाई गोप्य प्रबन्धकमा भण्डार गर्नुहोस्, यसलाई साँघुरो पार्नुहोस् र यसलाई नियमित रोटेशनमा राख्नुहोस्।
- पढ्ने-मात्र पूर्वनिर्धारित र साँघुरो लेखनले इंजेक्शनको प्रभावलाई धेरै सीमित गर्दछ।
आवेदन कार्य
तपाइँको AI सहायकले पहुँच गर्ने सबै उपकरण र डेटा सूचीबद्ध गर्नुहोस्। प्रत्येकको लागि तीनवटा प्रश्नहरूको जवाफ दिनुहोस्: (१) के यो साँच्चै आवश्यक छ? (२) पढ्न मात्र पुग्छ? (3) के यो प्रयोगकर्ता सन्दर्भमा चल्छ? त्यसपछि सबै हार्ड-कोड गरिएका गोप्यहरू खोज्नुहोस् (माथिको स्क्यान प्रम्प्ट मार्फत) र तपाईंले फेला पार्नुहुने प्रत्येक कुञ्जीको लागि रोटेशन योजना लेख्नुहोस्। कम्तिमा एउटा अनावश्यक प्राधिकरण हटाउनुहोस्।
चेकलिस्ट
- [] मोडेल अनुरोध गर्ने प्रयोगकर्ताको अधिकार सन्दर्भमा चल्छ।
- [] उपकरण र डेटा पहुँच न्यूनतम विशेषाधिकारको सिद्धान्तमा संकुचित गरिएको छ।
- [] लेख्नुहोस्/मेट्नुहोस् पढ्ने-मात्र, प्रमाणीकृत र संकीर्णबाट अलग छ।
- [] कोडमा कुनै गोप्य दफन गरिएको छैन; गोप्य प्रबन्धकमा राखिएको छ।
- [ ] त्यहाँ कुञ्जीहरूको लागि घुमाउने तालिका र रद्द गर्ने प्रक्रिया छ।
- [] पहुँचहरू नियमित रूपमा समीक्षा गरिन्छ।