- Что именно включает в себя управление идентификацией агентов ИИ?
- Почему традиционные системы управления идентификацией и доступом (IAM) не подходят для ИИ-агентов и нечеловеческих личностей.
- Проблемы с идентификацией агентов ИИ и то, как автономные агенты нарушают идентификацию в процессе производства.
- Цепочки делегирования, аутентификация и временные учетные данные.
- Применение принципов нулевого доверия и авторизации по принципу наименьших привилегий к идентификации агентов ИИ.
- Поведенческий анализ и обнаружение аномалий для обеспечения безопасности идентификации агентов.
Защита идентификационных данных для агентов ИИ: полное руководство
Обеспечение безопасности идентификации для агентов ИИ стало практическим требованием, поскольку автономное программное обеспечение начинает действовать от имени пользователей, сервисов и других агентов. В этом руководстве рассматривается, что означает идентификация агента, почему устаревшие системы управления идентификацией и доступом (IAM) неэффективны, как работают делегирование и учетные данные, а также как управлять идентификацией агентов ИИ в производственных масштабах.
- Основные выводы по вопросам безопасности идентификационных данных для агентов искусственного интеллекта
- Обеспечение безопасности идентификационных данных для агентов ИИ начинается с четкого ответа на вопрос о том, что такое идентификация агента ИИ: это проверяемая запись о том, кто создал агента, что он может делать, на чьих полномочия он действует и как долго эти полномочия сохраняются при регистрации, аутентификации, делегировании, использовании учетных данных и аудите.
- Человекоцентричный подход к управлению идентификацией и доступом (IAM) предполагает ограниченное количество пользователей, ежеквартальные проверки и поэтапные запросы, на которые может ответить человек, поэтому он не подходит для агентов ИИ и обеспечения безопасности идентификационных данных. Общие служебные учетные записи и долгосрочные административные токены разрушают атрибуцию, предоставляют избыточные разрешения и редко меняются после запуска агента.
- Наиболее распространенные уязвимости в идентификации агентов ИИ включают в себя теневых агентов, избыточное выделение ресурсов, разрастание учетных данных, «осиротевшие» учетные записи и злоупотребление привилегиями, вызванное подсказками. Безопасность автономных агентов отличается тем, что манипулируемый агент злоупотребляет законными разрешениями, поэтому жесткие ограничения радиуса поражения важнее, чем предотвращение кражи учетных данных.
- Практическая безопасность идентификации агентов основана на отслеживаемых цепочках делегирования, которые ограничивают полномочия, используют криптографическую машинную аутентификацию и временные учетные данные, ограниченные областью действия задачи, выдаваемые во время выполнения. Шаблоны нулевого доверия, такие как политика как код, повышение прав «точно в срок», ограничение доступа на уровне инструментов и контрольные точки подтверждения, обеспечивают соблюдение принципа минимальных привилегий.
- Поскольку агенты действуют в рамках предоставленных им прав доступа, обнаружение должно определять базовое поведение и сопоставлять телеметрию идентификации с сигналами облака, конечных устройств и сети, поскольку Open XDR Такие платформы, как Stellar Cyber, это делают. Управление жизненным циклом и поэтапное внедрение превращают безопасность идентификации агентов в подотчетный и подлежащий аудиту процесс.
Как искусственный интеллект и машинное обучение повышают кибербезопасность предприятия
Соединение всех точек в сложном ландшафте угроз
Испытайте безопасность на основе искусственного интеллекта в действии!
Откройте для себя передовой искусственный интеллект Stellar Cyber для мгновенного обнаружения угроз и реагирования на них. Запланируйте демонстрацию сегодня!
Что именно включает в себя управление идентификацией агентов ИИ?
Искусственный интеллект — это программное обеспечение, которое планирует, принимает решения и действует с минимальным участием человека. Оно вызывает API, запрашивает данные из баз данных, открывает заявки, перемещает деньги и вызывает других агентов. Каждое из этих действий требует наличия идентификатора, который можно аутентифицировать, авторизовать, зарегистрировать и отозвать.
Что такое идентификация агента ИИ?
Идентификатор агента — это проверяемое представление автономной рабочей нагрузки, включая информацию о том, кто её создал, что ей разрешено делать, на чьих полномочия она действует и как долго эти полномочия сохраняются. Он относится к более широкой категории нечеловеческих идентификаторов наряду с учетными записями служб, ключами API и машинными сертификатами, но с важным отличием: агенты сами принимают решения о том, какие действия предпринять.
Комплексная программа управления идентификацией агентов ИИ обычно охватывает следующие области:
- Регистрация и инвентаризация – каноническая запись о каждом агенте, его владельце, назначении и местоположении во время выполнения.
- Аутентификация – криптографическое доказательство того, что запрос действительно исходит от конкретного экземпляра агента.
- Авторизация – Ограниченные права доступа, которые точно описывают, к каким ресурсам и операциям может обращаться агент.
- Делегация – отслеживаемая цепочка, связывающая действия агента с человеком или системой, предоставившим полномочия.
- Жизненный цикл учетных данных – выпуск, ротация, истечение срока действия и аннулирование секретов и токенов.
- Мониторинг и аудит – Поведенческая телеметрия и неизменяемые журналы для каждого события идентификации.
Именно подход, при котором эти элементы рассматриваются как единая программа, а не как шесть разрозненных проектов, отличает работоспособную систему безопасности идентификации агентов от набора разрозненных ключей API. Платформы управления безопасностью, такие как Stellar Cyber, все чаще получают телеметрию идентификации из источников IAM, облачных сервисов и SaaS, чтобы можно было сопоставлять активность агентов с остальной средой, а не анализировать ее изолированно.
Почему традиционные системы управления идентификацией и доступом (IAM) не подходят для ИИ-агентов и нечеловеческих личностей.
Традиционные системы управления идентификацией и доступом были разработаны с учетом потребностей людей: ограниченное количество пользователей, предсказуемый график работы, периодические проверки доступа и система управления персоналом, которая сигнализирует о приеме на работу или увольнении. Агенты же нарушают почти все эти предположения.
Структурные несоответствия
| Предположение в системе управления идентификацией и доступом человека (Human IAM) | Реальность для агентов искусственного интеллекта |
|---|---|
| Идентификационные данные создаются и удаляются в рамках рабочих процессов приема на работу, перемещения и увольнения, осуществляемых отделом кадров. | Агенты создаются программным кодом, иногда тысячами в день, и могут существовать в течение нескольких секунд. |
| Аутентификация может осуществляться либо с помощью многофакторной аутентификации (MFA), либо путем обращения в службу поддержки. | В процессе выполнения программы ни один человек не присутствует для утверждения запроса на повышение уровня. |
| Проверка доступа проводится ежеквартально и рассматривается руководителями. | Возможно, потребуется изменять права доступа для каждой задачи, каждую минуту. |
| Одна идентичность соответствует одному действующему лицу. | Агент может действовать от имени множества разных пользователей, последовательно или одновременно. |
| Поведение подчиняется рабочему распорядку дня. | Работа ведется непрерывно, в больших объемах и с высокой скоростью, обеспечиваемой машинами. |
Ловушка общих учетных данных
Наиболее распространенный способ ускорения процесса развертывания агентов на ранних этапах — это предоставление агенту долгосрочной учетной записи службы или токена API администратора, поскольку это быстро и эффективно. Однако это единственное решение разрушает связь между агентами ИИ и безопасностью идентификации : агент наследует разрешения, значительно превосходящие требования его задачи, учетные данные редко меняются, а в журналах записывается учетная запись службы, а не агент или пользователь, который ее запустил. В случае возникновения проблем невозможно установить причину действия.
В многих корпоративных средах количество нечеловеческих личностей уже превышает количество человеческих, и агенты усугубляют этот дисбаланс. Любой контроль, зависящий от доступности человека для ответа, проверки или утверждения, не сможет масштабироваться для такой популяции.
Проблемы с идентификацией агентов ИИ и то, как автономные агенты нарушают идентификацию в процессе производства.
Большинство пробелов в идентификации агентов ИИ не являются чем-то экзотическим. Они возникают из-за обычного инженерного давления, совпадающего с моделью управления, которая никогда не предназначалась для автономных рабочих нагрузок.
Наиболее часто встречающиеся пробелы
- Теневые агенты. Команды создают агентов с помощью SaaS-платформ или внутренних фреймворков, не регистрируя их нигде. Служба безопасности не может защитить идентификационные данные, о существовании которых она не знает.
- Избыточное выделение ресурсов. Агенту предоставляется доступ на чтение и запись ко всему хранилищу данных, когда ему требуется доступ на чтение к трем таблицам.
- Распространение учетных данных. Ключи встраиваются в подсказки, файлы конфигурации, блокноты и образы контейнеров, а затем копируются между средами.
- Атрибуция утрачена. В нижестоящих системах для каждого действия агента используется один общий идентификатор, поэтому журналы аудита не могут ответить на вопрос, кто именно инициировал изменение.
- Осиротевшие личности. Прототипные агенты выводятся из эксплуатации, но их учетные данные и привязки ролей остаются активными неограниченно долго.
- Злоупотребление привилегиями, вызванное подсказками. Внедрение подсказок косвенно через полученные документы, электронные письма или веб-контент может направить агента на использование его законных прав доступа в целях злоумышленника.
Именно этот последний пробел отличает безопасность автономных агентов от традиционной безопасности рабочих нагрузок. Компрометированный скрипт делает то, что написано в его коде. Манипулируемый агент делает то, что написано в его инструкциях, а инструкции могут поступать из ненадежного источника во время выполнения. Сама идентификация никогда не крадется; она просто используется не по назначению в рамках предоставленной ей области действия. Именно поэтому границы разрешений должны быть достаточно строгими, чтобы даже полностью взломанный агент не мог причинить катастрофический ущерб.
Размышление о радиусе взрыва
Перед развертыванием агента команды должны уметь письменно ответить на один вопрос: если этот агент будет полностью под контролем противника в течение часа, каков будет наихудший исход? Ответ определяет, насколько узкими должны быть права доступа, потребуется ли одобрение со стороны человека и насколько агрессивно следует отслеживать поведение.
Цепочки делегирования, аутентификация и временные учетные данные.
Работа агента редко состоит из одного этапа. Пользователь запрашивает отчет у оркестратора, оркестратор связывается с агентом-исследователем, агент-исследователь запрашивает данные из хранилища данных и API системы обработки заявок. На каждом этапе необходимо сохранять исходные полномочия, а не повышать их.
Создание отслеживаемой цепочки делегирования
- Сохраните основной капитал. Идентификационные данные инициирующего человека или системы должны передаваться вместе с запросом, а не заменяться собственными данными агента.
- Пересекающиеся, но никогда не объединяющиеся разрешения. Фактический набор разрешений на любом этапе должен представлять собой пересечение прав пользователя и заявленной области полномочий агента, поэтому делегирование может лишь сузить полномочия.
- Привяжите задачу. Токены должны указывать на конкретную задачу или сессию, чтобы учетные данные, выданные для одной задачи, нельзя было использовать повторно для другой.
- Ограничьте глубину цепи. Установите ограничение на количество переходов между агентами и отклоняйте запросы, превышающие этот лимит.
Механизмы аутентификации, работающие для машин.
Надежная защита идентификации агентов зависит от криптографической аутентификации, а не от общих секретов. Практические варианты включают федерацию идентификации рабочих нагрузок, предлагаемую крупными облачными провайдерами, краткосрочные сертификаты, выдаваемые через сервисную сеть или систему идентификации в стиле SPIFFE, подписанные JWT с узкой аудиторией и сроком действия, а также аппаратные ключи, если это поддерживается средой выполнения. OAuth 2.0 и OpenID Connect остаются общей основой, расширенной шаблонами обмена токенами, позволяющими обменивать одни учетные данные на более узкие учетные данные для последующих операций.
Временные, ограниченные по объему учетные данные
| Учетные данные | Условный шаблон наследия | Шаблон цели для агентов |
|---|---|---|
| Вечного пользования | Месяцы или годы | Минуты, привязанные к продолжительности выполнения задачи. |
| Объем | Широкая роль или ключ администратора | Конкретные ресурсы и операции |
| Память | Конфигурационные файлы, переменные среды | Выпускается во время выполнения программы, хранится в памяти. |
| ревокация | Ручной режим, часто пропускается | Автоматическое истечение срока действия плюс центральный выключатель. |
| приписывание | Используется многими абонентами | Уникальный для каждого экземпляра агента и сессии. |
Применение принципов нулевого доверия и авторизации по принципу наименьших привилегий к идентификации агентов ИИ.
Принципы нулевого доверия легко применимы к агентам: необходимо явно проверять каждый запрос, предоставлять минимально необходимые привилегии и исходить из предположения, что рабочая нагрузка уже может быть скомпрометирована. Изменяется лишь скорость и требуемая детализация.
Шаблоны авторизации, которые стоит внедрить.
- Политика как код. Использование декларативного механизма политик для управления правами агента позволяет версионировать, проверять и тестировать правила, вместо того чтобы они были разбросаны по консолям IAM.
- Повышение высоты точно в срок. Агенты работают в режиме низкого базового уровня и запрашивают временное повышение уровня для выполнения конкретных операций, с автоматическим истечением срока действия запроса.
- Решения, основанные на атрибутах. Вместо того чтобы полагаться на статическую роль, следует одновременно оценивать идентификацию агента, инициирующего пользователя, классификацию данных, среду и время запроса.
- Ограничение доступа на уровне инструмента. В тех случаях, когда агенты используют системы вызова инструментов, необходимо обеспечивать авторизацию на уровне инструмента, чтобы несанкционированная функция не могла быть вызвана, даже если модель попытается это сделать.
- Контрольные точки с участием человека. Для необратимых или дорогостоящих действий, таких как платежи, развертывание в производственной среде или массовый экспорт данных, требуется явное одобрение.
Сегментация рабочей нагрузки агентов
Сегментация сети и данных по-прежнему имеет значение. Агенты, обрабатывающие недоверенный внешний контент, должны работать в другой зоне доверия, чем агенты с доступом на запись к финансовым системам. Контроль исходящего трафика ограничивает доступ агента к внешним конечным точкам, что ограничивает как утечку данных, так и каналы управления. Сочетание сегментации с ограниченными учетными данными означает, что у одного агента, подвергшегося манипуляциям, очень мало возможностей для работы.
При разработке политики следует также учитывать эффект накопления. Агент, запускающийся тысячу раз в день с небольшими правами доступа, все равно может оказывать значительное совокупное воздействие, поэтому ограничения скорости и пороговые значения объема должны устанавливаться на уровне авторизации, а не только на уровне мониторинга.
Поведенческий анализ и обнаружение аномалий для обеспечения безопасности идентификации агентов.
Превентивные меры контроля не смогут выявить все проблемы. Поскольку агенты действуют в рамках предоставленных им прав доступа, обнаружение должно быть сосредоточено на поведении, а не только на нарушениях политики. Именно здесь аналитика поведения пользователей и сущностей естественным образом распространяется на нечеловеческие личности.
Что следует установить в качестве исходного уровня
- Микс действий – какие API и инструменты агент обычно использует и в каких пропорциях.
- Объём и скорость – Типичное количество запросов за сессию и за час.
- Отпечаток данных – обычный объем и степень конфиденциальности записей, которые агент читает или записывает.
- Контрагенты – с какими сервисами, агентами и внешними доменами он обычно взаимодействует.
- Временные схемы – работает ли агент по расписанию, по запросу или непрерывно.
- Контекст делегирования – которые обычно запускают пользователи и системы.
Сигналы, на которые стоит обратить внимание
Внезапные запросы на повышение привилегий, первый доступ к хранилищу конфиденциальных данных, резкое изменение объема выходных данных, звонки на ранее не встречавшиеся конечные точки, повторяющиеся сбои авторизации с последующим успехом, а также использование учетных данных из неожиданной среды выполнения или региона — все это требует расследования. Поведение агентов часто более предсказуемо, чем поведение людей, что упрощает выявление статистических отклонений после установления надежного базового уровня.
Сопоставление данных телеметрии, отражающих идентификацию, с остальной частью окружающей среды.
Аномалия в использовании токенов агентом становится гораздо более значимой, если она сопровождается телеметрией конечных точек, сети, облака и электронной почты. Open XDR Платформы, включая Stellar Cyber, построены на основе этой модели корреляции, нормализуя сигналы от существующих поставщиков идентификации, облачных журналов и инструментов безопасности, чтобы аналитики видели единый связанный инцидент, а не поток разрозненных оповещений. Для групп безопасности, поддерживающих множество агентов, такая консолидация также дает AI SOC Агент Контекст, необходимый для расследования аномалий идентификации на конечных устройствах, в сети, облаке и данных об идентификации, помогает быстрее выявлять случаи неправомерного использования идентификационных данных.
Журналы аудита, управление и надзор на протяжении всего жизненного цикла агента.
Управление превращает идентификацию агентов из инженерной задачи в подотчетный бизнес-процесс. Оно также обеспечивает предоставление доказательств, которые все чаще запрашивают регулирующие органы, аудиторы и клиенты.
Что должно быть записано в журнале действий каждого агента
- Идентификатор агента и его экземпляр, включая версию базовой модели или кода.
- Инициирующий субъект и вся цепочка делегирования полномочий.
- Указан идентификатор учетных данных или токена, а также область его действия и срок действия.
- Конкретный инструмент, API или ресурс, который был вызван, и предоставленные параметры.
- Решение об авторизации, включая информацию о том, какая политика разрешила или отклонила запрос.
- Результат и любые возвращенные или измененные данные, включая классификацию по уровню конфиденциальности.
Журналы должны записываться в хранилище, которое сам агент не может изменить, храниться в соответствии с теми же стандартами, которые применяются к привилегированной деятельности человека, и синхронизироваться по времени, чтобы можно было восстановить цепочки между сервисами.
Контрольные точки управления жизненным циклом
| Стадия жизненного цикла | Контроль личности |
|---|---|
| Дизайн | Оценка радиуса взрыва, анализ классификации данных, указание ответственного лица. |
| Регистрация | Внесение записи в реестр агентов с указанием назначения, сферы деятельности и срока действия. |
| развертывание | Выдача учетных данных осуществляется через центрального посредника, политика привязана к рабочей нагрузке. |
| Эксплуатация | Непрерывный мониторинг поведения, ограничения скорости запросов, контрольные точки для действий высокого риска. |
| Изменить | Повторно проверяйте при изменении модели, инструментов или области действия разрешений. |
| Списание | Отзыв учетных данных, снятие привязки роли, закрытие инвентаризации, сохранение журнала событий. |
Внедрение программы идентификации агентов в 2026 году
Организациям редко выпадает возможность начать с чистого листа. Реалистичный путь — это поэтапное внедрение, начинающееся с повышения прозрачности и ужесточения контроля по мере роста числа агентов.
Поэтапное внедрение
- Обнаружить. Проведите инвентаризацию всех уже запущенных агентов, ботов и средств автоматизации. Запросите информацию в облачной системе управления идентификацией и доступом (IAM), менеджерах секретов, консолях администрирования SaaS и системах CI/CD, чтобы найти нечеловеческие идентификаторы, которыми никто не владеет.
- Классифицировать. Ранжируйте агентов по радиусу поражения: конфиденциальность данных, возможность записи, финансовые последствия и подверженность воздействию недоверенной информации.
- Назначить право собственности. Каждому агенту назначается ответственный человек, который отвечает за его работу и за его закрытие.
- Централизуйте выдачу документов. Все новые учетные данные агентов должны передаваться через единый брокер, который обеспечивает короткий срок действия и ограниченную область действия разрешений.
- Необходимо устранить наиболее проблемные участки. В первую очередь замените общие ключи администратора на агентах с высоким радиусом поражения, а затем переходите к следующим пунктам списка.
- Инструмент. Передавайте телеметрию, отслеживающую идентификацию, облачные данные и информацию о приложениях, на свою платформу обнаружения и создавайте базовые показатели для каждого агента.
- Автоматизировать ответ. Определите сценарии действий, которые приостанавливают действие учетных данных, помещают рабочую нагрузку в карантин или требуют подтверждения от человека, когда аномалии превышают пороговое значение. В контексте искусственного интеллекта SOCЭти рабочие процессы могут сочетать расследования, основанные на искусственном интеллекте, с автоматизированным реагированием, чтобы помочь группам безопасности управлять растущим числом автономных агентов.
- Проведите анализ и доработку. Выполняйте краткосрочные процедуры сертификации доступа для учетных записей агентов и удаляйте все, что не имеет текущего владельца или назначения.
Показатели, демонстрирующие прогресс
- Процент известных агентов в центральном реестре с назначенным владельцем.
- Доля учетных данных агентов с кратковременным сроком действия по сравнению со статическими и долгосрочными.
- Медианный срок действия учетных данных среди всех агентов.
- Количество оставшихся осиротевших или неиспользуемых нечеловеческих идентичностей.
- Среднее время, необходимое для аннулирования скомпрометированных учетных данных агента.
- Доля действий агентов высокого риска, прошедших через этап утверждения.
Типичные ошибки, чтобы избежать
Не создавайте отдельный стек идентификации исключительно для агентов; расширяйте уже существующий, иначе вам придётся поддерживать два источника достоверной информации. Не полагайтесь на ограничения на уровне подсказок в качестве контроля доступа, поскольку инструкции для модели являются скорее руководством, чем обязательным требованием. Не откладывайте ведение журналов до запуска, поскольку внедрение атрибуции в работающий парк агентов гораздо сложнее, чем её разработка. И не рассматривайте обнаружение как разовую процедуру, поскольку новые агенты постоянно появляются благодаря инструментам разработчиков и функциям SaaS.
Организации, которые успешно справляются с этим, — это те, которые с самого начала относятся к агентам как к первоклассным личностям, строго регламентируют полномочия и постоянно отслеживают их поведение. Сочетание дисциплинированного управления идентификацией агентов с коррелированным обнаружением и реагированием, будь то посредством... Open XDR Платформа Такие решения, как Stellar Cyber или аналогичные консолидированные аналитические системы, предоставляют командам безопасности реальный способ масштабирования контроля наряду с самими агентами.
Часто задаваемые вопросы об идентификации агентов ИИ в масштабе предприятия
Часто задаваемые вопросы от команд, занимающихся созданием или обеспечением безопасности больших популяций автономных агентов.
В: Можем ли мы просто повторно использовать существующие учетные записи служб для наших агентов ИИ?
Можно, но это самый простой способ, который впоследствии нанесет наибольший ущерб. Общая учетная запись службы предоставляет агенту гораздо больше доступа, чем требуется для выполнения его задачи, скрывает, какой агент или пользователь инициировал действие, и почти никогда не меняется. Вместо этого предоставьте каждому экземпляру агента собственную ограниченную по области, кратковременную идентификацию.
В: Чем отличается личность ИИ-агента от личности обычного нечеловеческого существа?
Учетные записи служб, ключи API и сертификаты машин выполняют фиксированные пути выполнения кода. Агент принимает решение о том, какие действия предпринять, во время выполнения, и на эти решения может влиять ненадежный контент, который он считывает. Такая автономность означает, что разрешения, контекст делегирования и мониторинг поведения имеют гораздо большее значение, чем для статической рабочей нагрузки.
В: Какой должна быть реальная продолжительность учетных данных агента?
Привязывайте время жизни учетных данных к задаче, а не к календарю. Для большинства интерактивных или кратковременных задач разумным целевым значением является количество минут, при этом учетные данные выдаются во время выполнения, хранятся в памяти и привязаны к конкретной сессии или задаче, чтобы их нельзя было воспроизвести где-либо еще. Предусмотрите централизованный механизм аварийного отключения для досрочного отзыва учетных данных.
В: Означает ли «быстрая инъекция» кражу личных данных агента?
Нет, и именно это создает трудности. Учетные данные никогда не похищаются. Агента убеждают использовать свои законные права доступа в чужих целях, поэтому ничто не выглядит как нарушение правил. Реалистичная защита заключается в ограничении области действия, контроле исходящего трафика, проверке необратимых действий и поведенческих базовых показателях.
В: Как найти агентов, о которых никто не сообщил службе безопасности?
Ищите учетные данные в местах их хранения: облачные системы управления идентификацией и доступом (IAM), менеджеры секретов, консоли администрирования SaaS, системы CI/CD и инструменты для разработчиков. Любое хранилище токенов без указанного владельца-человека может стать кандидатом. Рассматривайте это как повторяющуюся задачу, поскольку новые агенты постоянно появляются благодаря функциям платформы и внутренним механизмам.
В: Нужна ли нам отдельная платформа идентификации только для агентов?
Обычно нет, и создание такой системы создает два источника достоверной информации, которые необходимо поддерживать. Расширьте уже имеющийся у вас поставщик идентификации, брокер секретов и механизм политик, а затем добавьте компоненты, специфичные для агентов, такие как токены, привязанные к задачам, более короткие циклы сертификации и поведенческую аналитику, которая сопоставляет активность агентов с остальной частью вашей телеметрии безопасности.
В: С чего следует начать небольшой команде специалистов по безопасности?
Инвентаризация и право собственности. Вы не можете определять местоположение, отслеживать или удалять учетную запись, о существовании которой вы не знаете. После того, как у каждого агента будет назначен владелец и определен радиус поражения, замените общие административные ключи у агентов с самым высоким риском, а затем двигайтесь вниз по списку, централизуя выдачу учетных данных.
