Доказательства управления изменениями, принимаемые аудиторами

В аудите SOC 2 Type II управление изменениями (CC8.1) — один из самых часто выборочно проверяемых средств контроля: аудитор выбирает изменения за весь период и просит подтвердить, что каждое из них было авторизовано, протестировано и одобрено до вывода в промышленную среду. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) и пункт 6.4 Имплементирующего регламента NIS2 требуют того же, только другими словами. Инженерные команды обычно выполняют работу; не хватает обычно именно доказательств.

Что проверяют аудиторы

Для выборки изменений они хотят видеть:

1. Изменение было запрошено и описано: тикет или pull request с указанием, что и зачем меняется.
2. Его проверил кто-то, кроме автора: разделение обязанностей.
3. Оно было протестировано до вывода в промышленную среду, с результатами.
4. Оно было одобрено до развёртывания.
5. Развернуто именно то, что было одобрено: непроверенный код не попадает в промышленную среду.
6. Совокупность полная: каждое изменение в промышленной среде прошло процесс, включая инфраструктуру и конфигурацию.

Доказательства, которые проходят проверку

• Защита основной ветки: основная ветка требует как минимум одного одобряющего ревью от человека, отличного от автора, и успешных проверок до слияния. Экспортируйте настройки и покажите, что они не менялись в течение периода.
• Развёртывание только через конвейер: развёртывания в промышленную среду выполняются только из защищённой ветки через CI/CD; инженеры не могут пушить напрямую.
• Связанные записи: каждое развёртывание связано с объединённым pull request, который связан со своим тикетом.
• Инфраструктура как код по тем же правилам, чтобы изменения инфраструктуры оставляли такой же след.
• Полный список изменений из инструмента развёртывания за период, из которого аудитор может выбирать выборку.

Экстренные изменения

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

Что приводит к провалу аудита

• Администраторы с прямым доступом к промышленной среде, которые иногда обходят конвейер.
• Самоодобренные pull request или ревью только ботами.
• Изменения конфигурации, внесённые в консоли без записи.
• Защита ветки, отключённая «временно» в течение периода.
• Отсутствие доказательств тестирования помимо «CI пройден» там, где изменение требовало большего.

Выборка: что аудитор сделает на практике

В SOC 2 Type II аудитор обычно запрашивает полную совокупность изменений в промышленной среде за период, выбирает выборку (размер зависит от совокупности и методологии аудитора) и просит показать для каждого выбранного изменения: запрос, ревью кем-то, кроме автора, результаты тестов, одобрение и то, что развёрнутое соответствует одобренному.

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

Страница SOC 2 CC8.1 показывает, как это требование соотносится с ISO 27001, PCI DSS и NIS2.

Один процесс для всех стандартов

В наших данных требования по управлению изменениями связаны между стандартами:

Процесс на основе pull request с защищёнными ветками и развёртыванием только через конвейер одновременно удовлетворяет требованиям SOC 2, ISO 27001, PCI DSS и NIS2. PCI DSS добавляет несколько дополнительных требований: разделение предпродуктивной и промышленной сред (6.5.3), исключение реальных данных счетов из тестовой среды (6.5.5) и подтверждение требований безопасности после значительных изменений (6.5.2).

См. тему Безопасная разработка для связанных требований и нашу статью повторное использование доказательств для SOC 2, ISO 27001 и PCI DSS.

Вопросы

Считаются ли pull request одобрением изменения для SOC 2?

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

Как обрабатывать экстренные изменения для аудита?

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