Разделение обязанностей SOC 2 в команде из двух инженеров

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

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

SOC 2 не требует определенного штата

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

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

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

Небольшая компания должна определить, какие сочетания полномочий создают неприемлемый риск. Обычно к ним относятся:

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

Два инженера могут проверять обычные изменения друг друга. Дробный CTO может отвечать за управление доступом, согласование критичных изменений и проверку исключений. CI/CD может выполнять повторяемые развертывания через служебную учетную запись. Такая схема разделяет решения и действия, хотя штат остается небольшим.

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

Сначала разделите полномочия, потом назначайте людей

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

В обычной SaaS-команде из двух инженеров рабочая схема может включать четыре роли:

• Оба инженера могут писать изменения приложения. Каждый может согласовать запрос на слияние другого инженера, но никто не может дать независимое согласование собственному последнему изменению.
• После согласования любой инженер может выполнить слияние в защищенную ветку и запустить рабочий процесс продакшена. Запуск процесса не равен выполнению произвольных команд в продакшене.
• Дробный CTO согласовывает изменения в критичных путях, привилегированный доступ и исключения. CTO также отвечает за периодическую проверку доступа людей и сервисов.
• Служебная учетная запись CI/CD выполняет развертывания и записывает события. Она запускает обязательные проверки, но не может согласовывать код или выдавать доступ людям.

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

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

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

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

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

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

К временным назначениям применяются те же правила. Если инженер B заменяет CTO во время отпуска, запишите начало, окончание, утвержденный объем полномочий и изменение доступа. Не оставляйте временную роль активной бессрочно. Ежеквартальная проверка не исправит временную выдачу прав администратора, которая незаметно стала постоянной.

Разделение должны обеспечивать защищенные процессы

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

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

У разных поставщиков репозитория настройки называются по-разному, но ожидаемое состояние остается тем же:

production_branch:
  direct_push: blocked
  required_approvals: 1
  last_pusher_may_approve: false
  dismiss_stale_approvals: true
  required_checks:
    - unit-tests
    - security-scan
  administrator_bypass: blocked
sensitive_paths:
  - "infra/**"
  - "db/migrations/**"
  - ".ci/production/**"
  - "src/auth/**"
  required_owner: fractional-cto

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

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

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

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

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

Ведите короткий реестр точек контроля с владельцем и способом проверки. Для репозитория проверяйте правила ветки и согласования. Для CI/CD проверяйте, кто может редактировать рабочие процессы и использовать учетные данные продакшена. В облаке проверяйте роли развертывания и администраторов консоли. Для журналирования проверяйте, что отправители событий не могут удалять сохраненные записи.

Изменения, созданные ИИ, проходят тот же путь. Claude Code, Codex или другой агент может подготовить ветку и тесты, но его результат относится к человеку или служебной учетной записи, которая его отправила. Учетная запись агента не должна превращаться в удобного второго «человека», который согласовывает работу по запросу того же инженера.

Развертывание требует отдельного контроля

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

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

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

Применяйте этот барьер выборочно. Практичная политика выглядит так:

1. Каждый релиз в продакшен требует проверенного запроса на слияние и успешных автоматических проверок.
2. Для критичных изменений также нужен дробный CTO как владелец кода или согласующий окружения.
3. Служебная учетная запись CI/CD развертывает согласованный артефакт и создает неизменяемую либо отдельно сохраненную запись.
4. Неудачное развертывание создает запись об инциденте или изменении, а не приводит к незадокументированному ручному исправлению.

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

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

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

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

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

CC6.1 направлен на ограничение логического доступа с помощью программных средств и правил. NIST AC-6 добавляет полезный принцип минимальных привилегий: пользователи и процессы получают только тот доступ, который нужен для их задач. Вместе они требуют проверять фактические разрешения, а не таблицу ожидаемых ролей.

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

Для каждой учетной записи фиксируйте:

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

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

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

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

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

Свидетельства должны возникать в рабочем процессе

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

Процедура оценки AC-5 из NIST SP 800-53A полезна, даже если компания не заявляет соответствие NIST. Она предлагает проверяющему изучить процедуры разделения, конфигурацию систем, права доступа, распределение обязанностей и записи аудита, а затем протестировать автоматические механизмы. Это более полезный список подготовки, чем фраза «покажите аудитору нашу политику».

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

{
  "control_id": "CHG-02",
  "period": "2026-Q2",
  "population_query": "production deployments from delivery API",
  "population_count": 47,
  "artifacts": [
    "branch-rule-export.json",
    "deployment-population.csv",
    "exception-register.csv"
  ],
  "owner": "fractional CTO",
  "reviewed_at": "2026-07-08"
}

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

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

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

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

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

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

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

Бумажная матрица бесполезна при обходе администратором

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поймите, когда двух инженеров уже недостаточно

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

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

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

До начала периода наблюдения SOC 2 проведите настольное учение: инженер A создает изменение, инженер B недоступен, а CTO находится вне рабочего времени. Проследите обычный релиз, критичный релиз, запрос привилегированного доступа и аварийный откат. У каждого действия должен быть уполномоченный исполнитель, технически обеспеченный путь, сохраненная запись и запасной вариант.

Я применяю ту же проверку от контроля до свидетельства в Team & AI Audit: определяю, кто способен принять каждое рискованное решение, смотрю, что обеспечивают инструменты, и оцениваю минимальное изменение, которое закрывает пробел. Полезный результат не сводится к более красивой матрице ответственности. Нужна система поставки, где два инженера могут работать быстро, не заставляя аудитора верить в невидимое переключение ролей.