Как одному человеку управлять развертыванием ИИ-агента по SOC 2

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

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

SOC 2 проверяет контроль, а не вашу оргструктуру

В SOC 2 нет правила, по которому для каждого выпуска программы нужны три сотрудника. Руководство описывает средства контроля, соответствующие применимым критериям Trust Services Criteria, после чего независимая аудиторская фирма с лицензией CPA оценивает эти средства. Численность команды влияет на риски и схему контроля, но сама по себе не служит критерием.

Вопрос определяют две части Trust Services Criteria от AICPA. В CC5.1 один из пунктов требует от руководства разделять несовместимые обязанности, а когда такое разделение непрактично, выбирать и разрабатывать альтернативные контрольные меры. Для небольшой компании особенно важна вторая часть. Она разрешает компенсирующую схему, но не позволяет руководству игнорировать конфликт полномочий.

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

Контроль AC-5 из специальной публикации NIST 800-53 дает более четкое определение разделения обязанностей: нужно определить обязанности, которые следует разделять, и задать права доступа, поддерживающие такое разделение. NIST также указывает цель: снизить риск злоупотребления со стороны человека с законными полномочиями. SOC 2 не относится к сертификации NIST, но эта формулировка выводит на правильный вопрос о схеме. Может ли один участник злоупотребить разрешенным доступом так, что другой человек или обязательный системный контроль не остановит и не обнаружит это?

Поэтому слово «соответствует» слишком грубо описывает процесс выпуска. Проверка SOC 2 Type I оценивает схему и внедрение контроля на определенную дату. Проверка Type II также оценивает его фактическую работу за период. Красивое правило защиты ветки, созданное за неделю до начала аудита, может подтвердить схему. Оно не докажет, что все выбранные для проверки производственные выпуски за предыдущие месяцы следовали этому правилу.

Автор, проверяющий и развертывающий означают полномочия

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

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

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

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

Примените к одному изменению следующую проверку ролей:

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

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

ИИ-агент не может независимо одобрить собственную работу

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

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

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

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

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

Одному человеку нужны обязательные компенсирующие меры

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

Как минимум обычный маршрут должен обладать следующими свойствами:

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

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

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

Опишите компенсацию в формулировке контроля. Фраза «все изменения программы проходят взаимную проверку» не соответствует действительности, когда единственный человек проверяет результат агента. Более точный вариант звучит так: «Руководство проверяет и одобряет производственные изменения; автоматические средства контроля требуют успешных тестов, связывают одобрение с неизменяемым артефактом, ограничивают обычное развертывание сервисом выпуска и сохраняют доказательства развертывания; независимый проверяющий ежемесячно изучает выпуски и исключения». Формулировка должна совпадать с реальной работой системы, включая периодичность.

Политика в виде программы должна связывать одобренный артефакт

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

Следующая политика Open Policy Agent показывает решение в исполняемом виде. Она ожидает запрос на развертывание с исходным и одобренным коммитами, состоянием тестов, дайджестами артефактов, идентификатором вызывающей стороны и аварийным состоянием. Подстройте названия полей под свою систему выпуска.

package release

default allow := false

allow if {
  input.caller == "ci-production"
  input.source.commit == input.approval.commit
  input.build.artifact_digest == input.deploy.artifact_digest
  input.checks.required == "passed"
  input.approval.actor != input.source.committer
  not input.emergency
}

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

allow if {
  input.caller == "ci-production"
  input.source.commit == input.approval.commit
  input.build.artifact_digest == input.deploy.artifact_digest
  input.checks.required == "passed"
  input.approval.actor_type == "human"
  input.source.committer_type == "agent"
  input.evidence_sink == "restricted"
  not input.emergency
}

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

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

Доказательства должны восстанавливать каждый выбранный выпуск

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

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

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

Запись доказательства должна быть больше похожа на транзакцию, чем на снимок экрана:

{"change":"CR-1842","risk":"high","commit":"8f2c1a7","author_type":"agent","approved_commit":"8f2c1a7","approver":"user-17","checks":"passed","artifact":"sha256:4b2...91e","deployer":"ci-production","environment":"production","exception":false}

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

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

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

Для аварийного доступа нужен отдельный контроль

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

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

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

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

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

Правдоподобный процесс все равно может не пройти проверку

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

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

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

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

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

Глубина одобрения должна соответствовать риску изменения

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

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

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

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

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

Approved commit: 8f2c1a7
Risk class: high
Behavior checked: account deletion preserves retained invoice records
Security effect: authorization remains account scoped
Rollback: restore prior service version; migration is additive
Evidence reviewed: integration run 7714; policy decision 194

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

Объем аудита также имеет значение. Если агент меняет только прототип за пределами описанной производственной системы, выпуск может не входить в совокупность изменений SOC 2. Как только агент получает возможность менять компоненты, поддерживающие охваченный аудитом сервис, название «эксперимент» уже ничего не исключает. Определяйте область по системам и последствиям, затем сверяйте это определение с реальностью рабочей среды.

Формулировка контроля должна выдержать придирчивое чтение

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

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

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

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

Team & AI Audit поможет проверить, даст ли уменьшенная команда с AI ожидаемое сокращение фонда оплаты труда до изменения структуры. Отдельно и явно оцените средства контроля SOC 2 в этой новой схеме, не выдавая одного человека и одну модель за двух независимых проверяющих.

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