Количество агентов ИИ растет быстрее, чем большинство организаций успевает отслеживать, не говоря уже об управлении ими. По прогнозам IDC, к 2028 году их число достигнет 1,3 миллиарда.
Каждая команда, внедряющая агента, также часто непреднамеренно создает новую учетную запись. Эта учетная запись может получать доступ к системам, перемещать данные и действовать от чьего-либо имени. Сейчас главная задача – взять ситуацию под контроль, прежде чем она станет неуправляемой, и первый шаг заключается в ответе на базовый вопрос: чья это зона ответственности?
Это юридический отдел, поскольку кто-то должен разработать правила обработки данных агентом? Это команда управления учетными записями, наблюдающая за ростом их числа, пока сотрудники развертывают агентов без подачи запросов на доступ? Или же это руководитель, команда которого создала агента, основываясь на теории, что тот, кто его сделал, должен нести ответственность?
Если четко указать на кого-то невозможно, честным ответом, скорее всего, будет «никто». Такая неоднозначность приводит к тому, что доступ не проверяется, разрешения остаются активными после выполнения своего предназначения, а агенты без ответственных продолжают функционировать.
По данным исследования Cloud Security Alliance, лишь 15% организаций имеют четко определенных ответственных за 76–100% своих агентов ИИ. В то же время в 34% организаций ответственность установлена только для 26–50% агентов. Эти результаты свидетельствуют о существенном разрыве между темпами внедрения агентов ИИ и способностью организаций обеспечить надлежащий контроль за ними. Подобные последствия возникают, когда позиция «кто-то должен за это отвечать» не трансформируется в четкое распределение: «эта конкретная должность отвечает за это, и вот как можно будет узнать, что эта функция больше не выполняется».
Закрепление статуса ответственного – это формальность. Фактическая ответственность – это рабочий процесс
Ответ на вопрос «за кем закреплен этот агент» не ограничивается только личностью. Это также процесс, который периодически проверяет доступ, отменяет его в случае потери целесообразности и фиксирует эти события. При отсутствии такого процесса статус ответственного превращается в фикцию: это лишь наименование без фактической подотчетности. Ответственность нельзя делегировать единоразово и оставить без присмотра. Она требует систематического подтверждения через рабочий процесс, действующий даже тогда, когда первоначальный ответственный не следит за ситуацией.
Последствия отсутствия такого механизма
Примером могут служить разработчики, которые запускают автономных агентов для написания кода на собственных конечных точках: отдел IT никогда не согласовывал использование этих инструментов и часто даже не видит их. Однако первой реакцией не должна быть их блокировка. Вместо этого необходимо разработать рабочий процесс, который будет соответствовать реальным условиям выполнения работы.
На практике это означает разовую авторизацию, привязанную к конкретному лицу, которая сочетается с регулярным циклом повторной аттестации. Начинать внедрение стоит с 30-дневного цикла повторного подтверждения. Этот период достаточно короткий, чтобы после завершения проекта доступ не сохранялся на протяжении целого квартала. Это требует от ответственного лица подтверждения того, что доступ до сих пор обоснован, вместо предположения, что разрешение прошлого квартала остается в силе.
Такой же подход применяется к управлению схемами распределения ответственности. В схеме указывается имя ответственного. Цикл проверяет, соответствует ли это имя действительности до сих пор, и отзывает доступ, если это не так.
Как Netwrix Identity Manager превращает назначенного ответственного в фактически подтвержденного
Netwrix Identity Manager – это решение для управления учетными записями и их администрирования, которое управляет non-human identities с 2018 года, задолго до того, как агенты ИИ стали проблемой. Оно применяет к агентам такую же модель сертификации и жизненного цикла, как и к сервисным и машинным учетным записям.
Identity Manager реализует это через автоматическую отмену доступа на основе сертификации. Доступ, предоставленный агенту ИИ, подлежит периодической сертификации по расписанию, точно так же, как и доступ пользователя-человека. Если проект завершился, ответственный покинул должность или доступ больше не является обоснованным, сертификатор не утвердит его повторно, а Identity Manager автоматически отзовет разрешение вместо того, чтобы оставлять его активным. Не имеет значения, закреплено ли имя за 100% агентов, если нет механизма, требующего повторной проверки этого имени. Непроверенный или заброшенный агент теряет доступ самостоятельно.
Закрепление ответственных за агентами ИИ
Сертификация разрешений с помощью запланированных кампаний
Итог
Каждый агент ИИ необходимо включить в программу управления учетными записями и закрепить за ним ответственного, который сможет проверять его доступ. После этого следует запланировать кампании по сертификации, которые будут требовать от этого ответственного проведения повторной сертификации с заданной периодичностью. В случаях, когда ответственному нужна дополнительная информация, стоит активировать функцию делегирования, чтобы он мог получать рекомендации от вовлеченных в процесс сотрудников, не снимая с себя ответственности.
Ответственный и в дальнейшем согласовывает права, а доступ все равно проверяется лицом, принимающим решение о его сохранении, исключая автоматическое продление.
Назначение ответственного решает вопрос лишь единоразово. Управление же обеспечивает непрерывный контроль, поэтому ответственность сохраняется еще долго после изменения организационной структуры.
