એકમ 4 / 11

ઍક્સેસ નિયંત્રણ, ઓળખ અને ગુપ્ત વ્યવસ્થાપન

નફો:

  • પ્રમાણીકરણ અને અધિકૃતતાને અલગ કરવાની ક્ષમતા અને 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>{{ સ્ત્રોત }}</code>

ન્યૂનતમ સત્તા નિર્ણય નિયમ:

જ્યારે નવું સાધન/ઍક્સેસ વિનંતી આવે, ત્યારે પૂછો:1. શું આ ઍક્સેસ વિના કાર્ય કરી શકાય છે? -> જો હા: REJECT2. શું ફક્ત વાંચવા માટે પૂરતું છે? -> જો હા: લખવાની પરવાનગી આપો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) શું તે વપરાશકર્તા સંદર્ભમાં ચાલે છે? પછી બધા હાર્ડ-કોડેડ રહસ્યો શોધો (ઉપરના સ્કેન પ્રોમ્પ્ટ દ્વારા) અને તમને મળેલી દરેક કી માટે રોટેશન પ્લાન લખો. ઓછામાં ઓછી એક બિનજરૂરી અધિકૃતતા દૂર કરો.

ચેકલિસ્ટ

  • [ ] મૉડલ વિનંતી કરનાર વપરાશકર્તાના સત્તા સંદર્ભમાં ચાલે છે.
  • ટૂલ અને ડેટા એક્સેસને ઓછામાં ઓછા વિશેષાધિકારના સિદ્ધાંત સુધી સંકુચિત કરવામાં આવી છે.
  • [ ] લખો/ભૂંસી નાખવું એ ફક્ત વાંચવા માટે, પ્રમાણિત અને સાંકડાથી અલગ છે.
  • [ ] કોડમાં કોઈ રહસ્યો દફનાવવામાં આવતા નથી; તેને સિક્રેટ મેનેજરમાં રાખવામાં આવે છે.
  • [ ] ચાવીઓ માટે પરિભ્રમણ શેડ્યૂલ અને રદ કરવાની પ્રક્રિયા છે.
  • [ ] ઍક્સેસની નિયમિત સમીક્ષા કરવામાં આવે છે.