Абмяжоўвайце паўнамоцтвы агента

Апішыце задачу перад наданнем доступу

Агенту, які чытае код, патрэбныя іншыя паўнамоцтвы, чым агенту, які разгортвае сэрвіс. Не давайце абодва наборы дазволаў толькі таму, што адзін прадукт падтрымлівае абодва дзеянні.

Вызначайце паўнамоцтвы праз тры часткі: дзеянне, рэсурс і ўмову. Для выдуманага выпраўлення справаздачы агент можа запісваць у адну галіну распрацоўкі функцыі, пакуль задача актыўная. Ён можа чытаць ухваленыя файлы рэпазіторыя. Ён не можа змяняць даныя production або правілы абароны рэпазіторыя.

Дакладны спосаб забеспячэння межаў залежыць ад інструмента. Калі токен не можа задаць абмежаванне галіны, выкарыстоўвайце дадатковыя сродкі кантролю рэпазіторыя або сэрвіс выканання. Сумленна дакументуйце астатнія паўнамоцтвы.

Забяспечвайце абмежаванне па-за мадэллю

Запыт да мадэлі не з’яўляецца сістэмай кантролю доступу. Кампанент выканання павінен звяраць запытанае дзеянне і мэтавы рэсурс з бягучымі дазволамі. Ён не павінен прымаць сцверджанне мадэлі, што ўхваленне ўжо існуе.

AWS рэкамендуе абмежаваныя дазволы і часовыя ўліковыя даныя для адпаведных рабочых нагрузак. OWASP ужывае падобны прынцып найменшых прывілеяў да агентаў і іх інструментаў. Гэтыя прынцыпы патрабуюць рэалізацыі ў фактычных сістэмах ідэнтычнасцей і выканання. Рэкамендацыі AWS IAM, рэкамендацыі OWASP для агентаў.

Выкарыстоўвайце кароткачасовыя ўліковыя даныя там, дзе гэта падтрымліваецца. Не трымайце ў асяроддзі не звязаныя з задачай сакрэты. Задача толькі для чытання рэпазіторыя не павінна атрымліваць у спадчыну пароль базы даных production з каманднай абалонкі распрацоўшчыка.

Прывязвайце ўхваленне да фактычнага дзеяння

Ухваленне падрыхтоўкі змены не азначае ўхвалення яе разгортвання. Рашэнне аб разгортванні павінна вызначаць артэфакт, мэтавае асяроддзе і адпаведныя ўмовы. Калі яны змяняюцца, папярэдняе рашэнне можа ўжо не дзейнічаць.

Разгледзім агента, які прапануе бяспечнае чытанне базы даных, а пасля ўхвалення выконвае іншы запыт. Карысны механізм ухвалення правярае аперацыю, якая сапраўды запускаецца. Агульнае паведамленне «працягвай» без вызначанага мэтавага рэсурсу можа схаваць гэтую розніцу.

Таксама аддзяляйце ідэнтычнасць ад магчымасцей. Запісвайце, які чалавек або рабочая нагрузка ініцыявалі запуск. Правярайце, што ідэнтычнасць ініцыятара ўсё яшчэ мае дазвол у момант дзеяння. Адкліканне доступу чалавека павінна мець выразна вызначаны ўплыў на працу ў чарзе.

Пратэстуйце адмову і перапыненне

Правярайце не толькі паспяховы сцэнарый. У ізаляваным тэставым асяроддзі паспрабуйце дзеянне па-за межамі дазволенага рэсурсу. Пацвердзіце, што сістэма выканання адхіляе яго. Вывучыце аўдытную падзею, не запісваючы ўліковых даных.

Затым пратэстуйце скасаванне або заканчэнне тэрміну дзеяння ўліковых даных. Вызначце, якая праца спыняецца адразу і якая аперацыя можа завяршыцца. Кнопка спынення не абавязкова адмяняе дзеянне, якое ўжо дасягнула іншай сістэмы.

Захоўвайце невялікі запіс дазволаў разам з задачай. Уключыце адказнага, ухвалены абсяг, фактычныя сродкі кантролю, тэст адмовы і тэрмін дзеяння. Гэта робіць пазнейшы перагляд дастаткова канкрэтным для паляпшэння працоўнага працэсу.