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

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

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

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

Почему не все изменения равны

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

Пайплайн в регулируемой компании должен уметь различать это. Когда разработчик открывает pull request, изменение может автоматически попасть в staging. Утверждение там не нужно. Но когда то же самое изменение хочет перейти в production, пайплайн должен остановиться и запросить разрешение у нужного человека. Это может быть сотрудник отдела комплаенс, назначенный технический лид или кто-то из команды безопасности.

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

Следующая блок-схема иллюстрирует путь принятия решений от pull request до production, показывая, как уровень риска определяет шлюз утверждения и как аудиторские доказательства собираются автоматически.

Вот практический пример того, как можно настроить ручной шлюз утверждения в workflow GitHub Actions с правилами защиты окружения, которые определяют, кто может утверждать и какие доказательства собираются:

name: Deploy to Production

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Security scan
        run: make security-scan
      - name: Deploy
        run: make deploy

Чтобы обеспечить утверждение, настройте окружение production в настройках вашего репозитория с обязательными рецензентами (например, compliance-officer, security-lead) и включите опцию «Wait for approval» перед запуском задания. Журнал аудита автоматически записывает, кто утвердил, когда и какой коммит был развернут.

Что делает аудиторский след хорошим

Хороший аудиторский след — это не просто лог, в котором сказано: «Алиса нажала "Утвердить" в 15:42». Хороший аудиторский след фиксирует весь путь изменения: от первого коммита до деплоя в production. Он записывает:

• Какие коммиты были включены
• Кто написал каждый коммит
• Какие тесты запускались и прошли ли они
• Кто ревьюил код
• Кто утвердил деплой
• В какое время произошел деплой
• Успешен ли был деплой или завершился ошибкой

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

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

Баланс скорости и соответствия требованиям

Самая сложная часть — сохранить баланс. Слишком свободно — и регулятор выпишет предупреждение. Слишком жестко — и ваша команда замедлится до черепашьего шага. Инновации остановятся. Разработчики будут разочарованы.

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

Как пайплайн может автоматически определять риск? Есть несколько практических подходов:

• Правила на основе путей: Изменения в src/payment/ требуют двух утверждений. Изменения в src/docs/ не требуют ни одного.
• Правила на основе типов файлов: Изменения в SQL-миграциях требуют подписи сотрудника отдела комплаенс. Изменения в CSS-файлах — нет.
• Правила на основе зависимостей: Если изменение обновляет библиотеку, отвечающую за шифрование, пайплайн помечает его для проверки безопасности.
• Определение области: Если изменение затрагивает как frontend, так и слои базы данных, оно запускает более широкий процесс утверждения.

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

Практический чек-лист для утверждения на основе рисков

Если вы настраиваете пайплайн для регулируемой среды, вот краткий чек-лист для проработки:

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

Настоящая цель

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

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