# Еженедельная проверка безопасности агентов: практический процесс на 35 минут **Еженедельная проверка безопасности агентов** должна занимать меньше часа, приводить к небольшому числу решений и оставлять доказательства, которые можно изучить позже. Если вместо ответа на ясный вопрос она превращается в поиск по тысячам записей, такая проверка уже спроектирована неправильно. Я не раз видел, как команды совершают одну и ту же ошибку с автоматизированной работой: собирают записи активности, потому что понимают необходимость, а открывают их только после неприятного сюрприза. К тому времени полезный контекст уже исчез. Инженер, запустивший процесс, занят другой задачей, временные учетные данные удалены, и никто не может сказать, была ли странная команда обычным исправлением или первым признаком слишком широкой границы доступа. Еженедельная проверка решает более узкую задачу. Она помогает заметить постепенное расширение доступа, пока люди и задачи еще понятны. Заодно она заставляет различать две вещи, которые слишком часто смешивают: запись о том, что агенту разрешили действовать, не доказывает, что его действия имели смысл. ## Еженедельная проверка замечает изменения доступа до того, как они станут нормой Еженедельный ритм работает, потому что доступ агентов обычно меняется небольшими, легко забываемыми шагами. Кто-то добавляет токен, чтобы разблокировать тест. Задача по программированию постепенно превращается в изменение развертывания. Агент повторяет вызов API, пока не срабатывает запасной путь. Ни одно из этих событий само по себе не обязательно требует расследования. Но за несколько недель они могут создать схему доступа, которую никто намеренно не утверждал. Проверять каждое событие в реальном времени кажется безопаснее, однако большинство команд не может долго поддерживать нужное внимание. Проверяющие начинают одобрять или отклонять записи по знакомому шаблону. Они перестают спрашивать, почему агент, редактировавший документацию, подключался к производственному хосту. Это усталость от одобрений, замаскированная под безопасность. Квартальная проверка не работает по противоположной причине. За квартал накапливается слишком много запусков, измененных репозиториев и забытых деталей. В итоге вы считаете события, а не пытаетесь их понять. Выберите фиксированное еженедельное окно и каждый раз проверяйте предыдущие семь дней в одно и то же время. Подойдет момент, когда проверяющий может связаться с людьми, запускавшими необычные задания. Для одних команд удобна пятница после обеда, для других понедельник утром, особенно если нужно проверить автоматизацию выходных. Важнее не выбор дня, а постоянный график. Проверка должна отвечать на пять вопросов: - Какие новые процессы агентов получили полномочия? - Какие действия отличались от задачи или обычного назначения? - Какие ошибки указывают на сломанную интеграцию или проверку границ доступа? - Какие сессии отозвал человек и действительно ли отзыв остановил использование? - По каким учетным данным нужно принять решение владельцу до следующего использования? Не добавляйте шестой вопрос только потому, что его умеет показывать панель. Еженедельный процесс живет, пока у него узкий договор. Он умирает, когда превращается в обычное совещание по безопасности с журналами на одном из экранов. NIST SP 800-92, *Guide to Computer Security Log Management*, формулирует полезную мысль: организациям нужны определенные процессы анализа журналов, а не просто место для их хранения. Для агентов это особенно важно, поскольку они могут действовать быстро и многократно. Хранилище дает доказательства. Регулярная проверка дает этим доказательствам шанс изменить решение. ## Начинайте с новых сессий, а не отдельных вызовов Сначала проверяйте новые сессии, потому что именно в сессии начинаются полномочия. Нужно понять, какой процесс получил разрешение, какую идентичность предъявил, когда начался запуск и была ли у него правдоподобная цель. Проверка сессий не сводится к составлению списка. Нельзя просто увидеть знакомое имя разработчика и перейти дальше. Подписанная идентичность процесса сообщает кое-что о его происхождении, но не доказывает, что процесс запустили для разумной задачи. Считайте идентичность свидетельством происхождения, а не намерения. Для каждой новой сессии ответьте в заметке на такие вопросы: 1. Кто инициировал запуск или отвечает за него? 2. Какой репозиторий, тикет, задача обслуживания или расследование его оправдывает? 3. Какие классы учетных данных мог использовать запуск? 4. Завершилась ли сессия вместе с задачей? 5. Не появилась ли другая сессия, повторяющая ту же работу под другой идентичностью? Последний вопрос помогает обнаружить то, что команды часто пропускают. Инженер видит, что инструмент не сработал под ограниченной учетной записью, повторяет запуск через другой процесс агента и получает результат. В журнале могут быть две обычные сессии. Но смысл другой: первая граница сработала, а второй запуск мог обойти причину, по которой эта граница существовала. Отмечайте сессию для дальнейшей проверки, если у нее нет понятного владельца или ссылки на задачу, необычная длительность либо полномочия не связаны с заявленной работой. «Необычная длительность» не означает, что любой долгий запуск подозрителен. Большие рефакторинги и медленные наборы тестов могут идти долго. Но сессия, которая остается активной после исчезновения человеческого контекста, заслуживает внимания: забытые полномочия легко становятся устаревшими. Составьте небольшой список повторяющейся автоматизации по назначению, а не по расплывчатой метке вроде «доверенный». Например, запланированное обновление зависимостей может законно обращаться к реестру пакетов и открывать запросы на слияние. Такое описание можно проверить. «Доверенный бот программирования» не дает проверяющему ничего полезного. ## Необычной команде сначала нужен контекст, а не обвинение Необычная SSH-команда или HTTP-запрос являются поводом для проверки, а не приговором. Проверяющие ошибаются в обе стороны. Одни отбрасывают странные команды, потому что агент имел разрешение. Другие считают враждебной любую незнакомую команду. Обе реакции делают журнал менее полезным. Восстановите ожидаемый контекст по задаче. Запрос статуса развертывания в тестовой среде может подходить для расследования выпуска. Тот же запрос во время редактирования README без объяснения выглядит неуместно. Архивирование результатов сборки может быть обычным делом. Архивирование домашнего каталога, чтение истории оболочки или изменение удаленных файлов запуска требует более внимательной проверки. Для SSH сравнивайте команду с четырьмя границами: - С каким хостом должна работать задача. - Какая учетная запись и каталог ей нужны. - Какие изменения разрешены задачей. - Каковы ожидаемые последствия успешного выполнения команды. Последняя граница особенно важна. `git status` на сервере сборки почти ни на что не влияет. Команда, изменяющая описание сервиса, владельца файлов или создающая запланированное задание, меняет дальнейшее поведение системы. Для таких вызовов нужна конкретная ссылка на задачу и ответственный человек. HTTP-записи требуют такого же подхода, хотя подсказки будут другими. Смотрите на назначение, метод запроса, путь, класс ответа и объем запросов. Новый `GET` к ожидаемому сервису может быть обычным. Поток неудачных ответов авторизации, попытки обратиться к административным путям или запрос записи к сервису, не связанному с задачей, требуют объяснения. Не создавайте огромный список запрещенных строк и не называйте это проверкой. Агент может вызвать законный инструмент в неподходящем контексте, а безобидная команда может выглядеть тревожно без аргументов. Проверяющему нужно достаточно окружающих данных, чтобы понять, что агент пытался сделать. Полезный вывод выглядит так: «Сессия S-184 выполняла задачу обслуживания репозитория. Она использовала SSH на хосте развертывания и изменила конфигурацию сервиса. В записи задачи не было работы с развертыванием. Владелец сессии подтвердил, что команда была выбрана случайно. Мы отозвали сессию и восстановили прежнюю конфигурацию». Здесь есть факты, объяснение и выполненное действие. Слабый вывод выглядит так: «Обнаружена подозрительная команда». Такая фраза создает тревогу и оставляет следующему проверяющему необходимость восстанавливать все событие целиком. ## Неудачные вызовы показывают и поломки, и проверку границ Неудачные вызовы заслуживают отдельного прохода, потому что они несут другой сигнал, чем успешные действия. Успешная запись может изменить систему. Ошибка может показать, что агент попытался обратиться к тому, о чем вообще не должен был задумываться. Сначала отделите обычную неисправность интеграции от подозрительных повторений. Истекший токен, изменившийся путь API, тайм-аут сети или ограничение частоты со стороны поставщика вызывают ошибки во время обычной работы. Исправление может быть эксплуатационным, а не связанным с безопасностью. Зафиксируйте динамику ошибок, найдите владельца и устраните причину, пока агент не начал обходить сломанный маршрут. Затем ищите признаки, которые меняют трактовку: - Один и тот же отклоненный вызов многократно повторяется без полезной паузы или изменения задачи. - После отказа в авторизации агент пробует соседние пути. - После отказа запуск меняет назначение вместо того, чтобы сообщить об отказе. - Неудачный вызов направлен к хосту, сервису или учетной записи вне границ задачи. - Сразу после ошибки появляется успешное действие через более широкие учетные данные. Именно в последнем случае часто скрывается слабая конструкция учетных данных. Представьте, что агент пытается обновить развертывание с помощью узкого токена и получает ошибку авторизации. Затем он использует общий операционный токен и успешно выполняет действие. В журнале это может выглядеть как «восстановленная» задача. Проверка должна назвать это ошибкой области доступа. Узкий токен правильно отклонил запрос, а широкий скрыл несоответствие между задачей и разрешенным доступом. Не советуйте менять учетные данные каждый раз, когда API возвращает 401 или 403. Такой совет популярен, потому что кажется решительным, но он расточителен. Ротация не исправляет отсутствующую область доступа, неправильный адрес или постоянный выбор агентом неверного действия. Она может усложнить следующую проверку, заменив цепочку доказательств новым секретом с теми же неправильными правами. Вместо этого классифицируйте ошибку как один из четырех результатов: ожидаемая эксплуатационная ошибка, дефект конфигурации, нарушение границ задачи или возможное неправомерное использование учетных данных. В заметке укажите, почему выбрана категория. Если доказательств недостаточно, спросите владельца сессии, пока запуск еще свеж в памяти. ## Отзыв должен закрывать маршрут, вызвавший сомнения Отозванная сессия должна остановить активный процесс и лишить его предоставленных полномочий, но это не исправляет автоматически все связанные риски. Еженедельная проверка должна охватывать само событие отзыва и соседние маршруты доступа. Для каждой отозванной сессии зафиксируйте причину. Человек может отозвать ее, потому что задача завершилась, одобрение было случайным, идентичность процесса выглядела неправильно или запуск вел себя неожиданно. Эти причины требуют разных исправлений. Обычный отзыв после завершения задачи может не требовать дальнейших действий. Неожиданная идентичность процесса может потребовать проверки рабочей станции и способа запуска. Затем проверьте активность после отзыва. Любой вызов после отзыва требует объяснения. Причиной может быть ошибка во времени, отдельно авторизованный процесс или дефект связывания записей. Не исходите сразу из худшего, но и не отмахивайтесь от события. Смысл отзыва в том, чтобы граница полномочий была видимой. Проверьте и параллельные полномочия. Агент может потерять одну сессию, но продолжить работу через другой активный процесс, другие учетные данные, открытое SSH-соединение или отдельную учетную запись автоматизации. Не нужно доказывать отсутствие всех альтернативных маршрутов во всей компании. Достаточно понять, могла ли та же задача продолжиться по очевидному маршруту, который остался открыт. Записывайте отзыв простым языком: ```text Дата проверки: 2025-03-07 Сессия: [ссылка на сессию] Причина: SSH-команда вышла за границы утвержденной задачи обслуживания Действие: сессия отозвана Вызовы после отзыва: не обнаружены Связанные учетные данные: проверены, ротация не требуется Дальнейшее действие владельца: обновить инструкции запуска обслуживания ``` Используйте фактическую дату и ссылки. Шаблон важен, потому что заставляет указать, проверяли ли вы события после отзыва. Само слово «отозвана» описывает действие, а не результат. Не превращайте каждый отзыв в дисциплинарное событие. Если инженеры ожидают наказания за остановку запуска, они будут медлить, пока не докажут намерение. Отзыв нужен, чтобы быстро остановить неопределенное действие. Позже проверка установит, была ли причиной плохая инструкция, ошибочное одобрение, проблема конструкции учетных данных или нарушение. ## Ротация начинается с владельца и области доступа Учетные данные, которым пора пройти ротацию, должны появляться на еженедельной проверке как решения, ожидающие владельца, а не как список для паники. У токена есть срок ротации, владелец системы, заявленная цель и область доступа. Если чего-то не хватает, управлять им уже сложнее, чем нужно. Составьте небольшую очередь ротации из учетных данных, использованных в проверяемый период. Для каждого укажите владельца, сервис, назначение, следующую дату ротации и соответствие активности этой недели заявленной цели. Для начала не нужна сложная база данных. Надежная запись с именами владельцев полезнее впечатляющего реестра, который никто не обновляет. В первую очередь меняйте учетные данные, если выполняется одно из условий: - Истек обязательный срок ротации. - Владелец не может объяснить недавнее использование. - Учетные данные имеют больше прав, чем требует задача. - Их использовали после сомнения в доступе или события с неизвестным процессом. - Команда не может определить сервисную учетную запись или ответственного человека. Ротация без плана переключения приводит к ненужным сбоям. Перед заменой найдите запуски агентов, скрипты и интеграции, которые используют секрет. Выпустите замену с минимальной областью доступа, необходимой текущей задаче. Проверьте нужное действие. Переведите известных потребителей на новый секрет, затем отключите старый и убедитесь, что новые события его не используют. Не считайте отсутствие недавних событий доказательством того, что учетные данные не используются. Некоторые задания обслуживания запускаются раз в месяц или только во время инцидента. Перед удалением проверьте владельца и документированное назначение. Если нет ни того ни другого, отключите секрет в контролируемое время и наблюдайте за возникшей ошибкой. Часто это самый быстрый честный способ получить ответ. Важно различать две вещи: ротация сокращает полезный срок жизни секрета, а область доступа ограничивает его возможности. Команды часто пытаются компенсировать широкие права частой ротацией. Это не работает. Недавно выпущенные учетные данные с избыточным доступом все равно имеют избыточный доступ. ## Проверяйте доказательства до их интерпретации Надежность еженедельного вывода зависит от надежности записи. Скриншоты и строки, скопированные вручную, удобны, но плохо подходят как доказательства, если позже нужно выяснить, изменялись ли они. Sallyport записывает запуски агентов и отдельные вызовы в единый зашифрованный аудит с хеш-сцеплением, одновременно показывая их в отдельных журналах сессий и активности. Это разделение удобно: проверяющий может перейти от одобрения процесса к конкретным вызовам во время запуска и не смешивать два типа записей. Перед формальной проверкой или сохранением доказательств после тревожного события запустите доступную автономную проверку целостности: ```sh sp audit verify ``` Команда проверяет цепочку аудита по шифротексту и не требует ключа хранилища. Успешная проверка говорит, что цепочка цела согласно записанным хешам. Она не доказывает, что человек разумно одобрил действие, что назначение было правильным или что область доступа учетных данных была обоснованной. Целостность и оценка решения это разные задачи. Если проверка сообщает о проблеме, не считайте затронутую выгрузку окончательным доказательством. Сохраните файлы и точный результат команды, затем изучите состояние хранилища и приложения. Не «исправляйте» записи, чтобы отчет выглядел нормально. Сначала нужно понять, вызвана ли проблема повреждением, неполной копией или вмешательством. Для обычных еженедельных проверок сохраняйте результат проверки рядом с заметкой, если команде нужен убедительный след. Для экспериментов с низким риском можно выбрать более легкий процесс. Решение должно быть явным. Не стоит молча пропускать проверку именно в неделю, когда обнаружилось серьезное событие. ## Проверке нужен фиксированный ритм на 35 минут Короткая проверка работает, когда вы резервируете время для решений, а не обещаете «посмотреть журналы» после завершения остальных дел. Для команды с управляемым числом запусков агентов достаточно такого порядка. Увеличивайте время только тогда, когда этого действительно требуют объем или риск. 1. За пять минут проверьте аудит и задайте диапазон дат. Откройте предыдущую заметку, чтобы видеть нерешенные вопросы. 2. За десять минут проверьте новые сессии. Сопоставьте каждый незнакомый процесс или необычно долгий запуск с владельцем и задачей. 3. Еще десять минут уделите необычным успешным действиям и неудачным вызовам. Перед классификацией любого события изучите окружающий контекст. 4. За пять минут проверьте отозванные сессии. Посмотрите причину, активность после отзыва и очевидные параллельные полномочия. 5. Последние пять минут посвятите ротации учетных данных. Назначьте владельца и срок для каждого пункта, требующего действий. Ограничьте результат одной записью с тремя заголовками: выводы, решения и открытые владельцы. Вывод содержит наблюдаемый факт. Решение говорит, что вы сделаете. Открытый владелец называет человека, который должен завершить работу. Если смешивать эти категории, заметки заполняются расплывчатыми глаголами вроде «наблюдать» и «проверить». Подойдет такой краткий формат: ```text Период: [время начала] - [время окончания] Проверяющий: [имя] Проверка аудита: пройдена или требуется дальнейшая проверка Выводы - [ссылка на запись] [наблюдаемое событие и контекст] Решения - [выполненное действие и причина] Открытые владельцы - [человек] выполнит [конкретное действие] до [дата] ``` Отсутствие выводов не означает, что еженедельная проверка была бесполезной, но запишите, что именно вы проверили. Фраза «проблем нет» не показывает, изучали ли вы происхождение сессий, отзывы, ошибки и ротацию. Несколько конкретных строк создают основу для следующей недели. Не откладывайте проверку из-за отсутствия всех участников. Один информированный проверяющий может пройти по доказательствам и позже направить вопросы владельцам. Ожидание полной встречи превращает семидневный процесс в пробел длиной в шесть недель. ## Запись должна менять решения о доступе Проверка не состоялась, если она создала только отчет. Каждый повторяющийся вывод должен менять хотя бы одну из четырех вещей: инструкцию задачи, границу одобрения, область доступа учетных данных или саму автоматизацию. Повторяющиеся ошибки при обращении к ожидаемому адресу могут требовать исправления интеграции. Если агент постоянно выбирает работу с развертыванием во время проверки кода, ему нужны более узкие инструкции и отсутствие учетных данных для развертывания. Повторяющаяся неизвестная сессия может потребовать изменения способа запуска агента разработчиками. Регулярное использование широких учетных данных может оправдать разделение секретов по назначению. Sallyport может требовать одобрения нового процесса агента и отдельного одобрения каждого использования выбранных учетных данных. Второй контроль подходит для действий, которые человек должен оценивать при каждом запуске, вместо попытки выразить такое решение огромным набором правил. Не добавляйте одобрения повсюду. Если проверяющий каждую неделю видит один и тот же безобидный вызов и не может отличить его от рискованного, схема одобрений спроектирована плохо. Перенесите повторяющуюся работу с низким риском в ограниченные учетные данные, а одобрение каждого использования оставьте для действий с последствиями, требующими решения человека. Ведите короткий список повторяющихся выводов и состояния их исправления. Если одна категория появляется три проверки подряд, перестаньте считать ее отдельным наблюдением. Нужно изменить рабочую схему. Журнал уже показал, что текущая граница не соответствует работе. Первая хорошая проверка может оказаться немного неудобной: она обнаружит отсутствующие ссылки на задачи, безымянные учетные данные и неясную ответственность. Такой дискомфорт полезен. Запишите вопросы без ответа, назначьте владельцев и повторите процесс на следующей неделе. Цель не в безупречном журнале. Цель в среде агентов, где человек все еще может объяснить, кто действовал, почему, что произошло и какой доступ остается.