యాక్సెస్ నియంత్రణ, గుర్తింపు మరియు రహస్య నిర్వహణ

లాభాలు:

• ప్రామాణీకరణ మరియు అధికారాన్ని వేరు చేయగల సామర్థ్యం మరియు 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 కీ, పాస్‌వర్డ్, టోకెన్ లేదా సర్టిఫికేట్ వంటి రహస్యంగా ఉండే ఆధారాలు. మోడల్ ప్రొవైడర్ యొక్క API కీ కోడ్‌లో పొందుపరచబడి, వెర్షన్ కంట్రోల్ (Git)లోకి లీక్ అయినప్పుడు AI ప్రాజెక్ట్‌లలో అత్యంత సాధారణ ప్రమాదం.

సరైన అప్లికేషన్:

• కోడ్‌లో ఎప్పుడూ కీలను పొందుపరచవద్దు; ఎన్విరాన్మెంట్ వేరియబుల్ లేదా సీక్రెట్ మేనేజ్‌మెంట్ సిస్టమ్‌ని ఉపయోగించండి (కీలను ఎన్‌క్రిప్ట్ చేసిన మరియు యాక్సెస్‌ని కంట్రోల్ చేసే సర్వీస్).
• భ్రమణం: క్రమ వ్యవధిలో కీలను పునరుద్ధరించండి (ఉదా. ప్రతి 90 రోజులకు); లీక్ అనుమానం ఉంటే, వెంటనే రద్దు చేయండి.
• స్కోప్ తగ్గింపు: ప్రతి స్విచ్‌కు అవసరమైన సేవ మరియు అవసరమైన అధికారం మాత్రమే ఉంటుంది.
• ఆడిట్: కీని ఎవరు ఉపయోగించారు, ఎప్పుడు మరియు ఎక్కడ లాగ్ చేయండి.

నాలుగు కాపీ చేయగల టెంప్లేట్లు

యాక్సెస్ సమీక్ష నియంత్రణ ప్రాంప్ట్:

దిగువ సాధనాల జాబితాలోని ప్రతి సాధనం కోసం, మూల్యాంకనం చేయండి:- ఈ సహాయకుని పనిని నిర్వహించడానికి ఈ సాధనం అవసరమా? (అవును/కాదు) - ఇది చదవడానికి మాత్రమేనా లేదా వ్రాయడం/చెరిపివేస్తుందా? - ఈ సాధనం వినియోగదారు అధికారం లేదా సేవా ఖాతాతో పిలవబడుతుందా? అనవసరమైన లేదా అధికంగా అధీకృతమైన వాటిని "తొలగించు/రీడాక్ట్"గా గుర్తించండి.<tools>{{ tool_list }}</tools>

రహస్య లీక్ స్కానింగ్ ప్రాంప్ట్:

కింది కోడ్ స్నిప్పెట్‌లో హార్డ్‌కోడ్ రహస్యంగా ఉండే ఏదైనా కనుగొనండి: API కీ, పాస్‌వర్డ్, టోకెన్, కనెక్షన్ స్ట్రింగ్, ప్రైవేట్ కీ. ప్రతిదానికి వరుస మరియు టైప్ ఇవ్వండి. ప్రతిస్పందనగా కాపీ విలువ;మాస్క్ (మొదటి 4 అక్షరాలు + ***).<code>{{ మూలం }}</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) ఇది వినియోగదారు సందర్భంలో నడుస్తుందా? ఆపై అన్ని హార్డ్-కోడెడ్ రహస్యాల కోసం శోధించండి (పైన స్కాన్ ప్రాంప్ట్ ద్వారా) మరియు మీరు కనుగొనే ప్రతి కీకి భ్రమణ ప్రణాళికను వ్రాయండి. కనీసం ఒక అనవసరమైన అధికారాన్ని తీసివేయండి.

చెక్లిస్ట్

• [ ] అభ్యర్థన చేసే వినియోగదారు యొక్క అధికార సందర్భంలో మోడల్ నడుస్తుంది.
• [ ] సాధనం మరియు డేటా యాక్సెస్ కనీసం ప్రత్యేక హక్కు సూత్రానికి తగ్గించబడింది.
• [ ] వ్రాయడం/చెరిపివేయడం అనేది చదవడానికి మాత్రమే, ప్రామాణీకరించబడిన మరియు ఇరుకైన వాటి నుండి వేరుగా ఉంటుంది.
• [ ] ఏ రహస్యాలు కోడ్‌లో పాతిపెట్టబడవు; ఇది సీక్రెట్ మేనేజర్‌లో ఉంచబడింది.
• [ ] కీల కోసం భ్రమణ షెడ్యూల్ మరియు రద్దు విధానం ఉంది.
• [ ] యాక్సెస్‌లు క్రమం తప్పకుండా సమీక్షించబడతాయి.