அணுகல் கட்டுப்பாடு, அடையாளம் மற்றும் இரகசிய மேலாண்மை

ஆதாயங்கள்:

• அங்கீகாரம் மற்றும் அங்கீகாரத்தைப் பிரிக்கும் திறன் மற்றும் RBAC/ABAC உடன் குறைந்தபட்ச அங்கீகாரத்தைப் பயன்படுத்துதல்
• பயனர் சூழலில் மாதிரியை இயக்குவதன் மூலம் கலப்பு ப்ராக்ஸி அபாயத்தைத் தவிர்க்கும் திறன்
• இரகசிய மேலாண்மை அமைப்புடன் API விசைகளை சேமித்து சுழற்றும் திறன்

AI அமைப்பின் மீதான தாக்குதல்களின் குறிப்பிடத்தக்க பகுதியானது மாதிரியை "தந்திரம்" செய்வதில் தொடங்குவதில்லை, மாறாக திருடப்பட்ட API விசை அல்லது அதிக அங்கீகாரம் பெற்ற கணக்கு மூலம் தொடங்குகிறது. இந்த பாதுகாப்பு அடுக்கு கிளாசிக்கல் தகவல் பாதுகாப்பிலிருந்து வருகிறது, ஆனால் AI இன் சூழலில் புதிய அபாயங்களைச் சேர்க்கிறது: ஒரு மாடல் வேறொருவரின் சார்பாக சவாரிக்கு அழைப்பு விடுக்கிறது, ஒரு சேவை கணக்கு எல்லா தரவையும் அணுகுகிறது, GitHub இல் முக்கிய கசிவுகள். இந்த யூனிட்டில், அங்கீகாரம், அங்கீகாரம் (RBAC/ABAC), குறைந்தபட்ச அங்கீகாரம் மற்றும் ரகசிய மேலாண்மை ஆகியவற்றுடன் AI அமைப்புக்கான அணுகலை எவ்வாறு சுருக்குவது என்பதைக் கற்றுக்கொள்வோம்.

அங்கீகாரத்திற்கும் அங்கீகாரத்திற்கும் இடையே உள்ள வேறுபாடு

இரண்டு சொற்களும் பெரும்பாலும் குழப்பமடைகின்றன:

• அங்கீகாரம்: "நீங்கள் யார்?" — பயனர்/சேவை உண்மையில் தாங்கள் கூறுவது யார் என்பதை நிரூபிப்பது (கடவுச்சொல், டோக்கன், சான்றிதழ், MFA).
• அங்கீகாரம்: "நீங்கள் என்ன செய்ய முடியும்?" - அங்கீகரிக்கப்பட்ட தரப்பினர் எந்த ஆதாரம்/செயல்பாட்டை அணுகலாம் என்பதைத் தீர்மானிக்கவும்.

AI அமைப்புகளில் உள்ள முக்கியமான நுணுக்கம் இதுதான்: ஒரு பயனரின் சார்பாக மாடல் செயல்படும் போது, ​​அது அந்த பயனரின் அதிகாரத்துடன் செயல்படுகிறதா அல்லது பரந்த சேவைக் கணக்குடன் செயல்படுகிறதா? பிந்தையது ஆபத்தானது - ஏனெனில் ஊசி மூலம் ஏமாற்றப்பட்ட மாதிரி சேவைக் கணக்கிற்கான முழு அணுகலைப் பெறுகிறது.

எச்சரிக்கை: "குழப்பமான துணை" பிரச்சனை: குறைந்த அதிகாரம் கொண்ட பயனர், உயர் அதிகார மாதிரியை அவுட்சோர்சிங் செய்வதன் மூலம் அணுக முடியாத தரவை மறைமுகமாக அணுகுகிறார். மாதிரியானது எப்போதும் பயனரின் அதிகாரத்தின் சூழலில் செயல்பட வேண்டும், அவருடைய சொந்த பரந்த அதிகாரம் அல்ல.

RBAC மற்றும் ABAC

• RBAC (பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாடு): அணுகல் பயனரின் பங்கைப் பொறுத்தது. "ஆதரவு நிபுணர்" பாத்திரம் வாடிக்கையாளர் குறிப்புகளைப் படிக்க முடியும், ஆனால் அவற்றை நீக்க முடியாது. எளிய மற்றும் பொதுவான.
• ABAC (பண்பு அடிப்படையிலான அணுகல் கட்டுப்பாடு): அணுகல் பண்புகளைப் பொறுத்தது: பயனரின் துறை, தரவின் தனியுரிமை லேபிள், நாளின் நேரம், கோரிக்கை வரும் நெட்வொர்க். மிகவும் நேர்த்தியான ஆனால் மிகவும் சிக்கலானது.

பெரும்பாலான நிறுவனங்கள் RBAC உடன் தொடங்கி, முக்கியமான தரவுகளுக்காக ABAC க்கு ஆழப்படுத்துகின்றன. AIக்கான கட்டைவிரல் விதி: மாடல், அது அழைக்கும் ஒவ்வொரு முகவரையும், கோரிக்கை செய்யும் பயனரின் பங்கு/பண்புகளின் அடிப்படையில் அணுகும் ஒவ்வொரு தரவையும் வடிகட்ட வேண்டும்.

படிப்படியாக: குறைந்தபட்ச அதிகாரத்தைப் பயன்படுத்துதல்

1. சரக்குகளை எடுத்துக் கொள்ளுங்கள். மாதிரி என்ன கருவிகளை அழைக்கிறது, எந்த தரவை அணுகுகிறது? அவை அனைத்தையும் பட்டியலிடுங்கள்.
2. ஒவ்வொரு அணுகலை நியாயப்படுத்தவும். "இந்த உதவியாளருக்கு உண்மையில் நீக்க அதிகாரம் தேவையா?" இல்லையெனில், அதை அகற்றவும்.
3. படிக்க மட்டும் இயல்புநிலை. மாதிரியை இயல்பாகப் படிக்க முடியும்; தனித்தனி, குறுகிய-நோக்க டோக்கன் எழுத/நீக்க வேண்டும்.
4. பயனர் சூழலை நகர்த்தவும். சேவைக் கணக்கின் மூலம் அல்ல, பயனரின் அதிகாரத்துடன் வாகனத்தை அழைக்கவும்.
5. குறுகிய கால நற்சான்றிதழ். நீண்ட கால விசைகளுக்குப் பதிலாக குறுகிய கால, தானாக புதுப்பிக்கும் டோக்கன்களைப் பயன்படுத்தவும்.

இரகசிய மேலாண்மை

ரகசியம் என்பது API விசை, கடவுச்சொல், டோக்கன் அல்லது சான்றிதழ் போன்ற ரகசியமாக இருக்க வேண்டிய நற்சான்றிதழ்கள் ஆகும். AI திட்டங்களில் மிகவும் பொதுவான விபத்து, மாதிரி வழங்குநரின் API விசை குறியீட்டில் உட்பொதிக்கப்பட்டு, பதிப்புக் கட்டுப்பாட்டில் (Git) கசிவு ஆகும்.

சரியான விண்ணப்பம்:

• குறியீட்டில் விசைகளை உட்பொதிக்க வேண்டாம்; சூழல் மாறி அல்லது ரகசிய மேலாண்மை அமைப்பைப் பயன்படுத்தவும் (என்கிரிப்ட் செய்யப்பட்ட விசைகளைச் சேமித்து அணுகலைக் கட்டுப்படுத்தும் சேவை).
• சுழற்சி: வழக்கமான இடைவெளியில் விசைகளைப் புதுப்பிக்கவும் (எ.கா. ஒவ்வொரு 90 நாட்களுக்கும்); கசிவு சந்தேகம் இருந்தால், உடனடியாக ரத்து செய்யவும்.
• ஸ்கோப் குறைப்பு: ஒவ்வொரு சுவிட்சுக்கும் தேவையான சேவை மற்றும் தேவையான அங்கீகாரம் மட்டுமே உள்ளது.
• தணிக்கை: விசையை யார், எப்போது, ​​எங்கு பயன்படுத்தினார்கள் என்பதை பதிவு செய்யவும்.

நான்கு நகலெடுக்கக்கூடிய டெம்ப்ளேட்கள்

அணுகல் மறுஆய்வு கட்டுப்பாட்டு அறிவுறுத்தல்:

கீழே உள்ள கருவி பட்டியலில் உள்ள ஒவ்வொரு கருவிக்கும், மதிப்பீடு செய்யவும்:- இந்த உதவியாளரின் வேலையைச் செய்ய இந்தக் கருவி தேவையா? (ஆம்/இல்லை) - இது படிக்க மட்டும் உள்ளதா அல்லது எழுத/அழிக்க வேண்டுமா? - இந்தக் கருவி பயனரின் அதிகாரம் அல்லது சேவைக் கணக்குடன் அழைக்கப்படுகிறதா? தேவையில்லாத அல்லது அதிக அங்கீகாரம் பெற்றவற்றை "அகற்றுதல்/மீட்பு" எனக் குறிக்கவும்.<tools>{{ tool_list }}</tools>

இரகசிய கசிவு ஸ்கேனிங் வரியில்:

பின்வரும் குறியீடு துணுக்கில் ஹார்ட்கோட் செய்யப்பட்ட ரகசியமாக இருக்கும் எதையும் கண்டறியவும்: API விசை, கடவுச்சொல், டோக்கன், இணைப்பு சரம், தனிப்பட்ட விசை. ஒவ்வொன்றிற்கும் வரிசை மற்றும் வகையைக் கொடுங்கள். பிரதிபலிப்பு மதிப்பு;முகமூடி (முதல் 4 எழுத்துக்கள் + ***).<code>{{ source }}</code>

குறைந்தபட்ச அதிகார முடிவு விதி:

புதிய கருவி/அணுகல் கோரிக்கை வரும்போது, கேட்கவும்:1. இந்த அணுகல் இல்லாமல் பணியைச் செய்ய முடியுமா? -> ஆம் எனில்: REJECT2. படித்தால் மட்டும் போதுமா? -> ஆம் எனில்: GRANT எழுத அனுமதி3. நோக்கத்தை ஒரே ஆதாரமாகக் குறைக்க முடியுமா? -> ஆம் எனில்: darat இயல்புநிலை பதில் "இல்லை"; அணுகல் காரணத்தால் பெறப்படுகிறது.

சுழற்சி காலண்டர் நினைவூட்டல்:

ஒவ்வொரு ரகசியத்திற்கும், பதிவு: உரிமையாளர், உருவாக்கிய தேதி, காலாவதி, நோக்கம். 90 நாட்களைத் தாண்டிய அல்லது 30 நாட்களுக்குப் பயன்படுத்தப்படாத எந்த விசையையும் "சுழற்சி/ரத்துசெய்யும் வேட்பாளர்" எனப் புகாரளிக்கவும்.

பலவீனமான ப்ராம்ட் / ஸ்ட்ராங் ப்ராம்ட்

மோசமான அணுகுமுறை

வலுவான அணுகுமுறை

ஒரே சேவைக் கணக்கு மூலம் அனைத்து தரவையும் மாடல் அணுகுகிறது

கோரிக்கை செய்யும் பயனரின் அதிகாரத்துடன் மாதிரி அணுகுகிறது

API விசை குறியீட்டில் உட்பொதிக்கப்பட்டுள்ளது, அது மாறாது

முக்கிய ரகசிய மேலாளரில் சுழற்சி, 90 நாட்கள்

உதவியாளருக்கு பரந்த "எதையும் செய்" அதிகாரம்

படிக்க மட்டும் இயல்புநிலை, சுருக்கமாக எழுதவும்

அணுகல்கள் மதிப்பாய்வு செய்யப்படுவதில்லை

வழக்கமான அணுகல் மதிப்பாய்வு மற்றும் திரும்பப் பெறுதல்

மூன்று சிறிய வழக்குகள்

வழக்கு 1 - கசிந்த கலப்பு ப்ராக்ஸி தரவு. அனைத்து ஊழியர் பதிவுகளையும் அணுகக்கூடிய சேவைக் கணக்குடன் ஒரு உள் உதவியாளர் பணிபுரிந்தார். ஒரு பயிற்சிப் பயனர், "நிர்வாகச் சம்பள அட்டவணையைச் சுருக்கமாகக் கூறுங்கள்" என்று கூறுவதன் மூலம் அவர் சாதாரணமாகப் பார்க்காத தரவை அணுகினார்; ஏனெனில் மாடல் அதை அதன் சொந்த பரந்த அதிகாரத்தின் பின்னணியில் கேள்வி எழுப்பியது, பயனரின் அல்ல. பயனர் சூழலை நகர்த்துவதற்கு மாற்றியமைத்தவுடன், பயிற்சியாளரால் அவர் அல்லது அவள் மட்டுமே பார்க்கக்கூடிய பதிவுகளை இழுக்க முடிந்தது.

வழக்கு 2 — கசிந்த விசை, 2 வாரங்களில் 190,000 TL பில். ஒரு டெவலப்பர் மாதிரி API விசையை ஹெல்பர் ஸ்கிரிப்ட்டில் உட்பொதித்து, அதை பொது களஞ்சியத்திற்குத் தள்ளினார். ஒரு போட் 40 நிமிடங்களில் சாவியைக் கண்டுபிடித்து இரண்டு வாரங்களுக்குப் பயன்படுத்தியது; பில் 190,000 TL ஐ எட்டியது. ரகசிய மேலாளருக்கு விசை நகர்த்தப்பட்டு, சுழற்சியுடன் இணைக்கப்பட்டு, களஞ்சிய ஸ்கேனிங் சேர்க்கப்பட்டது, சம்பவம் மீண்டும் நிகழவில்லை.

வழக்கு 3 — படிக்க மட்டும் இயல்புநிலை குறுக்கீடு தடுக்கப்பட்டது. ஒரு DevOps உதவியாளர் உடனடி ஊசி மூலம் "உற்பத்தி தரவுத்தளத்தை மீட்டமை" கட்டளையைப் பெற்றார். இருப்பினும், உதவியாளருக்கு படிக்க மட்டுமே டோக்கன் வழங்கப்பட்டது; எழுதுதல்/அழித்தல் தனி அங்கீகரிக்கப்பட்ட ஓட்டத்தில் இருந்தது. அங்கீகார பிழையுடன் கட்டளை நிராகரிக்கப்பட்டது மற்றும் நிகழ்வு அலாரமாக பதிவு செய்யப்பட்டது; தரவு இழப்பு இல்லை.

உதவிக்குறிப்பு: புதிய அணுகல் கோரிக்கைக்கான உங்கள் இயல்புநிலைப் பதிலை "இல்லை" என அமைக்கவும். அணுகல் என்பது நியாயப்படுத்துவதன் மூலம் கிடைத்த ஒன்று; எல்லோருக்கும் பரந்த அளவில் கொடுத்து, பின்னர் குறைப்பது கிட்டத்தட்ட ஒருபோதும் செய்யப்படவில்லை, மேலும் ஆபத்து கூடுகிறது.

பொதுவான தவறுகள்

• ஒரு பெரிய சேவை கணக்குடன் மாதிரியை இயக்குதல் மற்றும் பயனர் சூழலை (கலப்பு ப்ராக்ஸி) இழக்கிறது.
• குறியீட்டில் API விசையை உட்பொதித்து, பதிப்புக் கட்டுப்பாட்டில் கசியவிடுவது.
• விசைகளை சுழற்றுவது இல்லை ("வேலை, தொடாதே").
• உதவியாளருக்கு இயல்பாக எழுத/நீக்க அனுமதிகளை வழங்குதல்.
• ஒரு முறை அணுகலை வழங்குதல் மற்றும் அதை மறுபரிசீலனை செய்யக்கூடாது.
• அங்கீகாரத்துடன் அங்கீகாரத்தை குழப்பி, "அவர் உள்நுழைந்துள்ளார், அவரால் அனைத்தையும் அணுக முடியும்" எனக் கருதுதல்.

சுருக்கமாக

• அங்கீகாரம் என்பது "நீங்கள் யார்" என்ற கேள்வி, அங்கீகாரம் என்பது "நீங்கள் என்ன செய்ய முடியும்" என்ற கேள்வி; AI இல், இரண்டும் பயனரின் சூழலில் செயல்பட வேண்டும்.
• மாதிரியானது, கோரிக்கை செய்யும் பயனரின் அதிகாரத்துடன் செயல்பட வேண்டும், அதன் சொந்த பரந்த அதிகாரத்துடன் அல்ல (கலப்பு ஏஜென்சியின் ஆபத்தைத் தவிர்க்கும்).
• RBAC உடன் தொடங்கவும், முக்கியமான தரவுகளில் ABAC உடன் ஆழப்படுத்தவும்; குறைந்தபட்ச அதிகாரத்தை இயல்புநிலையாக ஆக்குங்கள்.
• குறியீட்டில் ரகசியங்களைப் புதைக்காதீர்கள்; அதை ரகசிய மேலாளரிடம் சேமித்து, சுருக்கி, வழக்கமான சுழற்சியில் வைக்கவும்.
• படிக்க-மட்டும் இயல்புநிலை மற்றும் குறுகலான எழுத்து உட்செலுத்தலின் தாக்கத்தை பெரிதும் கட்டுப்படுத்துகிறது.

விண்ணப்ப பணி

உங்கள் AI உதவியாளர் அணுகும் அனைத்து கருவிகளையும் தரவையும் பட்டியலிடுங்கள். ஒவ்வொன்றிற்கும் மூன்று கேள்விகளுக்கு பதிலளிக்கவும்: (1) இது உண்மையில் அவசியமா? (2) படித்தால் மட்டும் போதுமா? (3) இது பயனர் சூழலில் இயங்குமா? பின்னர் அனைத்து கடின குறியிடப்பட்ட ரகசியங்களையும் (மேலே உள்ள ஸ்கேன் ப்ராம்ட் வழியாக) தேடுங்கள் மற்றும் நீங்கள் கண்டுபிடிக்கும் ஒவ்வொரு விசைக்கும் ஒரு சுழற்சி திட்டத்தை எழுதவும். குறைந்தபட்சம் ஒரு தேவையற்ற அங்கீகாரத்தை அகற்றவும்.

சரிபார்ப்பு பட்டியல்

• [ ] கோரிக்கை செய்யும் பயனரின் அதிகார சூழலில் மாதிரி இயங்குகிறது.
• [ ] கருவி மற்றும் தரவு அணுகல் குறைந்த பட்ச சலுகை என்ற கொள்கைக்கு சுருக்கப்பட்டுள்ளது.
• [ ] எழுதுதல்/அழித்தல் என்பது படிக்க-மட்டும் தனித்தனியானது, அங்கீகரிக்கப்பட்டது மற்றும் குறுகியது.
• [ ] எந்த ரகசியங்களும் குறியீட்டில் புதைக்கப்படவில்லை; இது ரகசிய மேலாளரில் வைக்கப்பட்டுள்ளது.
• [ ] விசைகளுக்கான சுழற்சி அட்டவணை மற்றும் ரத்துசெய்யும் நடைமுறை உள்ளது.
• [ ] அணுகல்கள் தொடர்ந்து மதிப்பாய்வு செய்யப்படுகின்றன.