Может ли таблица доказательств SOC 2 подтвердить действия агента?

Действия агента создают аудиторскую проблему, которую обычные журналы приложения не решают. Журнал сервисной учетной записи может показать, что учетные данные вызвали endpoint. Но обычно он не показывает, имел ли конкретный процесс агента полномочия в тот момент, одобрил ли действие человек, были ли полномочия позже отозваны и совпадает ли запись, переданная аудитору, с той, что была создана изначально.

Полный пакет доказательств SOC 2 должен помогать восстановить решение, а не просто показывать временную шкалу. Для каждого значимого действия аудитор должен иметь возможность пройти путь от исполнителя и его полномочий к вызову, результату и целостности сохраненной записи. Если какая-либо связь зависит от памяти администратора или вручную отредактированной таблицы, контроль слабее, чем кажется на первый взгляд.

Sallyport построен вокруг этой цепочки: агент получает результаты действий, а учетные данные остаются в локальном зашифрованном хранилище; приложение записывает запуск агента и каждый отдельный вызов. Такая архитектура полезна только тогда, когда вы превращаете записи в проверяемые доказательства, а не относитесь к журналу как к декорации для соответствия требованиям.

Контроль должен позволять восстановить решение

Критерии Trust Services Criteria AICPA 2017 не являются меню со скриншотами. Общие критерии безопасности требуют, чтобы руководство устанавливало и применяло средства контроля, ограничивающие логический доступ, отслеживающие работу системы, реагирующие на выявленные проблемы и управляющие изменениями. Аудитор проверяет описанный вами контроль, его генеральную совокупность и то, работал ли он в течение периода проверки.

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

Сначала сформулируйте риск, затем запрос на доказательства. Практическое описание риска может выглядеть так:

Неодобренный или ранее одобренный процесс агента мог вызвать внешний API или выполнить SSH-команду с использованием корпоративных учетных данных, что привело бы к несанкционированному доступу или несанкционированному изменению операционной среды.

Контроль должен отвечать на этот риск простыми словами. Доказательства должны отвечать на пять более узких вопросов:

1. Какой процесс попытался выполнить действие?
2. Какими полномочиями он обладал в тот момент?
3. Кто, если кто-то, предоставил эти полномочия?
4. Какое именно внешнее действие последовало?
5. Можно ли обнаружить попытку переписать историю?

Команды часто смешивают эти вопросы. Они называют список разрешенных назначений контролем одобрения, успешный ответ API записью авторизации, а экспорт журнала неизменяемым только потому, что экспорт доступен в режиме чтения. Каждое из этих утверждений описывает разные вещи.

Ограничение назначения определяет, куда процесс может обращаться. Запись авторизации показывает, кто разрешил процессу действовать. Запись вызова подтверждает, что именно процесс пытался сделать и что произошло. Проверка целостности отвечает на вопрос, изменялась ли сохраненная последовательность. Разделяйте эти утверждения в описании системы и таблице доказательств. Аудитору не нужны модные формулировки. Ему нужен владелец контроля, который может сделать ограниченное утверждение и предоставить подтверждающую запись.

Таблица доказательств SOC 2, которую может проверить аудитор

Используйте одну таблицу доказательств как рабочее соглашение между разработчиками, специалистами по безопасности и аудитором. Не превращайте ее в список функций продукта. В каждой строке указывайте риск, действие контроля, генеральную совокупность, метод проверки и сигнал сбоя.

Ссылки на критерии - это отправная точка, а не обещание полного покрытия. Итоговое сопоставление определяют описание услуги, оценка рисков, границы системы и мнение аудитора. В частности, не относите каждую запись агента к CC8.1. Примеры и рекомендации AICPA рассматривают управление изменениями как контроль изменений прикладных программ и связанной технологии. Вызов, который редактирует учетную запись клиента, отправляет ответ службы поддержки или перезапускает удаленный процесс, является операционным действием. Он становится доказательством управления изменениями только тогда, когда входит в одобренное и протестированное изменение самой системы.

Таблица также предотвращает распространенную ошибку недели аудита: сбор идеального артефакта за один день. Проверка типа 2 выясняет, работали ли заявленные средства контроля эффективно на протяжении всего периода. Столбец с генеральной совокупностью - не бюрократия. Он показывает, какую полную совокупность вы должны уметь предоставить до того, как из нее будет взята выборка.

Одобрение сессии подтверждает полномочия процесса, а не управление идентификацией

Одобрение каждой сессии подтверждает, что конкретный запуск агента получил разрешение использовать шлюз действий. Оно не доказывает, что компания правильно управляла доступом сотрудников, корректно создала учетную запись в поставщике удостоверений или проверила роль облачного администратора. Для этого нужны отдельные средства контроля и записи.

Полезное утверждение здесь уже. Первый защищенный вызов нового процесса получает решение об одобрении до того, как сессия может начать работу. В записи должны сохраняться идентификатор сессии, идентификатор процесса, полномочия подписи кода, если они доступны, время решения, идентификатор одобрившего и состояние завершения. В Sallyport карточка одобрения начинается с полномочий подписи кода процесса. Благодаря этому человек принимает решение об исполняемом файле, который действительно запросил доступ, а не о расплывчатой метке, предоставленной агентом.

Это важное различие. Агент может назвать себя как угодно в запросе, заголовке терминала или аргументе процесса. Контроль, одобряющий самостоятельно сообщенное имя, легко обойти. Контроль, показывающий полномочия подписи кода, дает проверяющему устойчивый атрибут для оценки. Это не отменяет необходимости доверять подписанному программному обеспечению, но честно обозначает границу доверия.

Для проверки одобрения сессии попросите аудитора выбрать выборку из генеральной совокупности сессий, а затем проследить каждую запись в обоих направлениях:

• Начните с одобрения сессии и найдите первый последовавший защищенный вызов.
• Начните с записи активности и найдите сессию, которая ее авторизовала.
• Убедитесь, что время вызова находится после одобрения и до выхода из сессии или ее отзыва.
• Убедитесь, что отклоненные сессии не выполняли успешных защищенных вызовов.
• Убедитесь, что запись сессии достаточно точно идентифицирует процесс для заявленного контроля.

Не полагайтесь на скриншот диалога одобрения. Скриншоты полезны для документирования проектирования контроля, но не являются доказательством генеральной совокупности. Запись должна сохраняться после закрытия диалога, находиться по идентификатору и связываться с записью активности без того, чтобы человек решал, какая строка выглядит подходящей.

Также не утверждайте, что одобрение сессии реализует принцип минимальных полномочий, если это не так. Решение по сессии может определить, разрешено ли процессу действовать вообще. Минимальные полномочия зависят от доступных после одобрения учетных данных, назначения, операций и разрешений. Если один одобренный агент может использовать учетные данные с неограниченными правами в рабочей среде, одобрение является воротами, а не уменьшением области доступа. Так и описывайте его.

Одобрение каждого вызова подходит для действий, которые нельзя безопасно объединить

Контроль с одобрением каждого вызова дает другую гарантию, чем одобрение сессии. Он требует нового решения человека в момент, когда должно произойти использование конкретных учетных данных. Применяйте его там, где риск связан с отдельным вызовом, а не только с разрешением процессу агента начать работу.

Подходящие примеры - учетные данные рабочей среды, позволяющие изменить права доступа, удалить данные, изменить платежную информацию, опубликовать развертывание или выполнить команды на особо чувствительном узле. Цель не в том, чтобы сделать каждое действие агента неудобным. Она в том, чтобы поставить проверку на границе транзакции, где отдельное неправильное действие действительно опасно.

Доказательства должны связывать одобрение с одним использованием. Надежная запись активности содержит как минимум:

• уникальный идентификатор вызова и связанный с ним идентификатор сессии;
• ссылку на защищенные учетные данные без размещения их секретного значения в записи;
• канал, назначение, операцию и временную метку;
• состояние решения и данные об одобрившем для вызова, которому требовалось одобрение;
• результат, включая отклоненный, неудачный или завершенный вызов.

Не принимайте запись одобрения, которая просто находится где-то рядом с последующим действием. Близость по времени не создает связи. Если проверяющий одобрил вызов A, а агент выполнил вызов B с теми же учетными данными, доказательства должны показывать, требовалось ли для B отдельное одобрение и было ли оно получено.

Здесь команды часто впадают в другую крайность. Они ставят человека перед обычными операциями чтения, после чего проверяющие бездумно одобряют поток почти одинаковых карточек. Записи по-прежнему создаются, но проверка становится формальностью. Оставьте одобрение каждого вызова для узкого набора учетных данных или действий, которые этого заслуживают. Для обычной работы используйте одобрение сессии, а область действия учетных данных уменьшайте отдельно.

Проверяющему нужен достаточный контекст для принятия решения. Для HTTP-действия это обычно метод, назначение, идентификатор учетных данных и безопасное описание эффекта запроса. Для SSH нужны идентификатор узла и команда либо ограниченное описание команды. Никогда не включайте сам секрет в данные одобрения только ради более подробных доказательств. Секрет, раскрытый проверяющему через карточку одобрения, все равно остается раскрытым.

Отзыв должен создавать отказ, который можно продемонстрировать

Доказательство отзыва бесполезно, если оно фиксирует только событие в интерфейсе. Контроль работает тогда, когда полномочия прекращаются, а последующая попытка завершается отказом именно по этой причине.

Проведите этот тест до того, как его запросит аудитор. Запустите сессию, которой разрешено выполнить тестовое действие в среде, не предназначенной для производства. Подтвердите успешный вызов. Отзовите сессию, пока процесс продолжает работать. Затем попросите тот же процесс выполнить второй вызов. Сохраните четыре связанные записи: первый успешный вызов, событие отзыва, второй отклоненный вызов и состояние сессии.

Рабочий лист теста может выглядеть так:

Test ID: AGT-REV-01
Session ID: ____________________
First call ID and result: ____________________
Revocation time and actor: ____________________
Second call ID and denial result: ____________________
Reason shown for denial: ____________________
Reviewer and date: ____________________

Именно порядок событий образует контроль. Событие отзыва в 14:03, за которым следует успешный вызов в 14:07, означает либо сбой, либо проблему с часами, либо то, что идентификатор сессии не означает заявленного вами. Ни один из этих вариантов нельзя списать на объяснение «примерно так получилось».

Различайте обычный выход из сессии и явный отзыв. Выход завершает процесс, потому что он остановился. Отзыв прекращает полномочия, потому что проверяющий решил их отменить. Оба события должны блокировать последующие вызовы, но только отзыв показывает, что человек может завершить работающий запуск из-за возникших опасений. Разделяйте типы событий в таблице доказательств.

Этот контроль должен входить и в практику реагирования на инциденты. Если проверяющий видит подозрительную последовательность вызовов, он должен знать, кто может отозвать запуск, как быстро начнет действовать отказ и где событие появится в журнале. Письменной процедуры с формулировкой «отключить агента» недостаточно, если агент уже выполняет работу.

Офлайн-проверка тестирует историю после того, как приложение покинуло комнату

Журнал активности дает ответственность за действия. Независимо проверяемая хеш-цепочка позволяет выяснить, сохранилась ли целостность последовательности. Это связанные, но не взаимозаменяемые вещи.

Sallyport строит представления сессий и активности из одного зашифрованного аудиторского журнала, доступного только для записи. Офлайн-команда sp audit verify проверяет цепочку по шифротексту и не требует доступа к хранилищу. Это полезное доказательство: проверяющий может тестировать сохраненную историю, не заставляя систему, создавшую отчет, расшифровывать учетные данные или предоставлять доступ к хранилищу.

Не преувеличивайте, что именно это доказывает. Проверка хеш-цепочки может обнаружить пропущенную, переставленную или измененную запись в проверяемой области, в зависимости от устройства цепочки и сохраненных материалов. Она не доказывает, что приложение создало каждое событие, которое должно было существовать. Она также не доказывает точность источника времени, правильность решения одобрившего или фактическое выполнение внешним API заявленного действия. Это разные вопросы контроля.

Сохраняйте запись проверки для определенного диапазона. Для многих команд достаточно такого рабочего формата:

{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}

Не придумывайте успешный результат после неудачной проверки. Зафиксируйте сбой, сохраните материалы, определите, связан ли он с обработкой экспорта, хранением, дефектом программного обеспечения или предполагаемым изменением, и передайте его в процесс работы с инцидентами. Неудачная проверка целостности автоматически не означает утечку. Это событие, требующее расследования, потому что цепочка доказательств перестала быть надежной.

Проводите проверку по расписанию, соответствующему объему и риску действий агентов, а также перед подготовкой доказательств. Для небольшой среды может хватить ежемесячного задания. Команда, которая весь день позволяет агентам управлять рабочими системами, не должна ждать конца квартала, чтобы обнаружить проблему целостности. Важнее не частота сама по себе, а возможность показать, что проверки выполнялись регулярно и что на сбои реагировали.

Операционные действия и изменения системы требуют разных доказательств

Это граница, которую чаще всего размывают. Действие агента может что-то изменить. Но это еще не делает его контролируемым изменением системы по CC8.1.

Рассмотрим три примера. Агент меняет через API статус подписки клиента. Это бизнес-операция, которой нужны авторизация, отслеживаемость и, возможно, дополнительная проверка. Агент редактирует файл инфраструктуры в репозитории, pull request проходит проверку, тесты завершаются успешно, а конвейер развертывания применяет изменение. Это изменение системы. Агент выполняет SSH-команду, которая напрямую редактирует файл конфигурации в рабочей среде. Это операционное действие с повышенным риском и, вероятно, нарушение процесса изменений, если политика требует проверяемых развертываний.

Пакет доказательств должен показывать эти пути, а не заставлять проверяющего выводить их из текста. Добавьте к записи активности или анализу доказательств классификацию действия:

CC8.1 требует от руководства авторизовать, проектировать, разрабатывать или настраивать, документировать, тестировать, одобрять и внедрять изменения инфраструктуры, данных, программного обеспечения и процедур. Журнал агента может дополнить эту историю, показав, что агент открыл pull request или вызвал действие, связанное с развертыванием. Он не заменяет проверку, результаты тестов и запись развертывания.

Это непопулярная мысль, потому что кажется, будто один аудиторский журнал должен отвечать на все вопросы. Он не может этого сделать. Сохраняйте след действий агента как запись делегированного действия. Инженерные записи изменений используйте как доказательство того, что изменения системы прошли обязательный путь. Объединяйте их только тогда, когда агент участвовал в этом пути.

Создавайте пакет доказательств на основе генеральной совокупности, а не папки со скриншотами

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

Затем подготовьте небольшой реестр доказательств со ссылками на неизменяемые или сохраненные исходные артефакты. Не загружайте кучу файлов с именами вроде final-final-audit. Используйте устойчивые идентификаторы, источник, период, владельца и примечание о том, что подтверждает артефакт.

Проверяющий может действовать так:

1. Получить совокупности сессий и активности за период, а также записи проверки целостности.
2. Сопоставить число идентификаторов сессий, указанных в записях активности, с совокупностью сессий, а затем изучить несопоставленные записи.
3. Выбрать образцы среди одобренных сессий, отклоненных попыток, чувствительных вызовов, отзывов и разных временных диапазонов.
4. Проследить каждый выбранный вызов назад к его авторизации и вперед к результату, а затем проверить запись проверки журнала, охватывающую соответствующий сохраненный диапазон.
5. Для изменений шлюза или связанных производственных средств контроля отдельно проследить соответствующие pull request, тест, одобрение и запись развертывания.

Такая последовательность быстро выявляет пробелы. Если у вызова нет сессии, связь с авторизацией не сработала. Если у сессии нет идентификатора процесса, невозможно проверить утверждение о процессе. Если после отзыва нет теста последующего отказа, известно лишь, что кто-то нажал кнопку. Если записи проверки охватывают архив, который нельзя воспроизвести, утверждение о целостности будет слабым.

Храните заметки проверяющего вместе с образцом. Короткая запись вроде «Call ID 54b сопоставлен с Session ID 12a; сессия одобрена сотрудником A; требуемое одобрение вызова присутствует; результат активности - completed; проверка диапазона аудита пройдена» полезнее десяти скриншотов. Она показывает следующему проверяющему, что именно тестировалось, и оставляет след при изменении контроля.

Доказательства теряют силу, если владельцы не могут объяснить исключения

Даже лучшая таблица доказательств не сработает, если никто не отвечает за обработку исключений. Действия агентов будут отклоняться. Запросы на одобрение будут истекать. Вызовы будут завершаться ошибками на удаленном endpoint. Сессии будут отозваны. Проверка может сообщить о проблеме. Эти результаты должны входить в генеральную совокупность, а команда должна знать, какие из них требуют действий.

Определите небольшой набор категорий исключений: несанкционированная попытка, отклоненное одобрение, сбой удаленного действия, попытка после отзыва, отсутствие связи между записями и сбой проверки. Для каждой назначьте владельца, периодичность проверки и ожидаемую запись. Не превращайте каждый отклоненный API-запрос в инцидент безопасности. Повторяющиеся отказы от неожиданного подписанного процесса, вероятно, требуют большего внимания, чем отказ инженера от собственной экспериментальной команды.

Полезная проверка состоит в том, может ли кто-то объяснить выбранное исключение без восстановления истории по сообщениям в чате. Запись активности должна указывать непосредственную причину. Запись сессии должна идентифицировать запуск. В последующей записи должно быть указано, приняла ли команда результат, исправила конфигурацию, отозвала доступ или начала работу с инцидентом.

Здесь же изменения контроля требуют дисциплины. Если вы меняете поведение одобрения, флаги учетных данных, поля журналирования или процедуру проверки сохраненных журналов, считайте это изменением среды контроля. Обновите описание контроля, протестируйте новое поведение и зафиксируйте развертывание через существующий инженерный процесс. Иначе таблица доказательств будет описывать систему прошлого квартала, тогда как агенты этого квартала работают иначе.

Не ждите, пока аудитор скажет, связаны ли доказательства. Выберите на этой неделе одну реальную сессию, проследите ее от авторизации до результата вызова, отзовите ее в безопасной среде и проверьте сохраненный диапазон аудита офлайн. Если команда не может выполнить это упражнение с уже доступными записями, исправьте путь доказательств до того, как начнете спорить о формулировках контроля.