Компания проходит путь к SOC2/PCI DSS compliance для инфраструктуры, управляемой через IaC (Terraform) и Kubernetes. Спроектируйте, как встроить сбор доказательств (evidence) соответствия в повседневные процессы платформы, а не делать это разовым мероприятием перед аудитом?

Короткий ответ

Единого шаблона на все компании не существует: evidence нужно собирать автоматически и непрерывно как побочный продукт обычных процессов — IaC-ревью через pull request с обязательными проверками (policy-as-code), аудит-логи облака/кластера с длительным retention, автоматические отчёты сканирования уязвимостей и доступа — вместо того, чтобы готовить документы вручную непосредственно перед проверкой аудитором.

Как это работает подробнее

большинство требований SOC2/PCI DSS сводятся к демонстрации того, что контроль (например, «изменения инфраструктуры проходят ревью», «доступ к данным карт ограничен и логируется») применяется систематически, а не единожды. Если изменения инфраструктуры всегда проходят через Terraform + PR + required review + policy-as-code проверку (например, Checkov в CI), сам факт существования истории PR с approvals уже является непрерывным evidence для аудитора, без отдельной подготовки.

Сравнение

• Компромисс. полная автоматизация evidence-сбора (policy-as-code на каждый PR, централизованные неизменяемые аудит-логи, автоматические отчёты) требует значительных первоначальных инвестиций в платформенную инженерию и может замедлить скорость изменений инфраструктуры; более ручной подход с периодическими проверками перед аудитом дешевле в моменте, но несёт риск несоответствия между «как написано в политике» и «как происходит на практике», а также резко увеличивает нагрузку непосредственно перед аудитом. Баланс зависит от частоты аудитов, зрелости платформенной команды и требований конкретного стандарта/заказчика — универсального готового рецепта не существует.

Пример кода

security-example-468.txtКопировать

# Policy-as-code проверка в CI перед применением Terraform (Checkov)
resource "aws_s3_bucket" "cardholder_data" {
  bucket = "example-payments-archive"
  # Ожидается: policy-check должен провалиться, если отсутствует шифрование
}
resource "aws_s3_bucket_server_side_encryption_configuration" "cardholder_data" {
  bucket = aws_s3_bucket.cardholder_data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

Что использовать на практике

• Практика. выстраивают цепочку: IaC-изменения только через PR с обязательным approval и автоматической policy-проверкой (запрет публичных S3-бакетов, обязательное шифрование и т.д.) → все изменения кластера/облака логируются в аудит с длительным retention и защитой от изменения → результаты регулярного сканирования уязвимостей и access review сохраняются как артефакты с датами → эти источники собираются в единое evidence-хранилище для быстрой выгрузки аудитору.
• Проверка. Ожидаемое поведение: CI-шаг с checkov -d . --check CKV_AWS_19 (требование шифрования S3) должен провалить pull request, если блок шифрования отсутствует, и это провальное/успешное состояние проверки для каждого PR, сохранённое в истории CI, само становится evidence соответствия требованию шифрования данных при хранении для аудитора.

Подводные камни

• Ошибка. готовить документы и скрипты для аудита отдельно от реальных процессов, что создаёт риск несоответствия (audit theater) — зафиксированный в документе процесс отличается от того, что реально происходит в проде; не хранить историю достаточно долго (retention короче требуемого периода аудита); считать прохождение аудита разовым проектом, а не постоянной практикой, из-за чего контроль со временем деградирует между проверками.