Limitați autoritatea unui agent

Descrieți sarcina înainte de a acorda acces

Un agent care citește cod are nevoie de altă autoritate decât unul care instalează un serviciu în mediu. Nu acordați ambele seturi de permisiuni doar pentru că același produs acceptă ambele acțiuni.

Folosiți trei elemente pentru definirea autorității: o acțiune, o resursă și o condiție. Pentru o corecție fictivă a unui raport, agentul poate scrie pe un singur branch de funcționalitate cât timp sarcina este activă. Poate citi fișierele aprobate din depozitul de cod. Nu poate modifica datele din producție sau regulile de protecție a depozitului.

Aplicarea exactă a restricției depinde de instrument. Dacă un token nu poate exprima o restricție de branch, folosiți controale suplimentare ale depozitului de cod sau un serviciu de execuție. Documentați sincer autoritatea rămasă.

Impuneți limita în afara modelului

Un prompt nu este un sistem de control al accesului. Componenta de execuție trebuie să verifice acțiunea cerută și ținta în raport cu permisiunile actuale. Nu trebuie să accepte afirmația modelului că aprobarea există deja.

AWS recomandă permisiuni limitate și credențiale temporare pentru sarcinile de lucru potrivite. OWASP aplică agenților și instrumentelor lor un raționament similar privind privilegiile minime. Aceste principii trebuie implementate în sistemele efective de identitate și execuție. Ghidul AWS IAM, ghidul OWASP pentru agenți.

Folosiți credențiale cu durată scurtă unde sunt acceptate. Excludeți din mediu secretele fără legătură cu sarcina. O sarcină de citire a depozitului de cod nu trebuie să moștenească o parolă a bazei de date din producție din shell-ul dezvoltatorului.

Legați aprobarea de acțiunea efectivă

Aprobarea pregătirii unei modificări nu implică aprobarea instalării ei în mediu. Decizia de instalare trebuie să identifice artefactul, mediul țintă și condițiile relevante. Dacă acestea se schimbă, decizia anterioară poate să nu mai fie valabilă.

Luați în considerare un agent care propune o citire sigură din baza de date, apoi execută altă interogare după aprobare. Un mecanism util de aprobare verifică operațiunea care rulează efectiv. Un mesaj generic „continuați”, fără o țintă definită, poate ascunde diferența.

Separați și identitatea de capacitate. Notați persoana sau sarcina de lucru care a inițiat execuția. Verificați dacă identitatea inițiatoare încă are permisiune în momentul acțiunii. Eliminarea accesului unei persoane trebuie să aibă un efect explicit asupra lucrului aflat în coadă.

Testați un refuz și o întrerupere

Verificați mai mult decât calea reușită. Într-un mediu de testare izolat, încercați o acțiune în afara resursei permise. Confirmați că sistemul de execuție o respinge. Inspectați evenimentul de audit fără a înregistra credențiale.

Apoi testați anularea sau expirarea credențialelor. Stabiliți ce lucru se oprește imediat și ce operațiune se poate termina. Un buton de oprire nu inversează neapărat o acțiune care a ajuns deja în alt sistem.

Păstrați o consemnare scurtă a permisiunilor împreună cu sarcina. Includeți responsabilul, domeniul aprobat, controalele efective, testul de refuz și expirarea. Astfel, o verificare ulterioară este suficient de concretă pentru a îmbunătăți fluxul de lucru.