Compliance Frameworks

Я регулярно вижу две крайности в отношении compliance. Первая — «compliance это бумажки для аудита, инженеров не касается»: команда узнаёт о SOC 2 за две недели до аудита, в панике собирает доказательства руками, проходит его и забывает до следующего года. Вторая — «у нас SOC 2 Type II, значит, у нас всё безопасно»: чек прошёл, контролы зелёные, а в это же время Capital One теряет данные 106 миллионов человек через неверно настроенный WAF — банк, живущий под непрерывным регуляторным надзором и всеми возможными аудитами. Compliance — это доказательство соответствия требованиям, заданным снаружи, а не безопасность сама по себе. Грамотный SRE использует compliance как драйвер для требований, которые команда закрывает и без всякого аудита (Access Control & IAM, Vulnerability Management, Backup & Restore, audit trail во всех системах), и автоматизирует сбор доказательств до уровня «непрерывно», а не «раз в год руками».

Что должен уметь

Главный навык на уровне L5 — разложить контролы на технические практики. SOC 2 CC6.1 («logical access controls») — это не «напишем документ с политикой», это модель IAM, принцип наименьших привилегий, журнал аудита и регулярный access review. PCI-DSS Requirement 8 — это MFA, политика паролей и управление сессиями. Когда compliance читается как обычная инженерная работа, которую команда делает и без аудитора, аудит проходит без героизма. Когда compliance трактуется как «отдельная работа поверх инженерии» — рождается compliance theater.

Знает, какие фреймворки compliance применяются к продукту команды (SOC 2 / PCI-DSS / HIPAA / FedRAMP / GDPR), и понимает, какие части кода и инфраструктуры попадают в область аудита.
Понимает разницу между регуляцией (закон: GDPR, HIPAA — обязательны, если применимы к вам) и фреймворком (стандарт сертификации: SOC 2, ISO 27001, PCI-DSS — формально добровольны, но их спрашивают клиенты).

Раскладывает компоненты системы по конкретным контролам: знает, какой из них закрывается каким техническим артефактом — модулем IaC, политикой IAM, runbook’ом, дашбордом.
Автоматизирует сбор доказательств: снимок состояния IAM, выгрузка дашборда со сроками патчинга, история изменений IaC, экспорт журнала аудита — по расписанию или по событию в GRC-платформу, а не руками накануне аудита.
Различает SOC 2 Type I (контролы спроектированы на момент аудита) и Type II (контролы реально работали от трёх месяцев до года); Type II требует доказательств за весь период, и это меняет всю механику сбора.

Проектирует систему контролов для команды или организации: выбор фреймворков по клиентскому спросу, границы области аудита, каталог контролов, матрица ответственных, ритм аудитов.
Внедряет compliance as code: политики через OPA, Sentinel или Cloud Custodian, автоматическое обнаружение дрейфа, непрерывная проверка контролов. «Контроль зелёный» означает «автоматическая проверка прошла за последние сутки», а не «документ с политикой написан год назад».
Работает с внешними аудиторами: границы аудита, запросы доказательств, разбор процессов, закрытие замечаний. Понимает, что аудитор может принять compensating control, то есть равноценную альтернативу, — это предмет переговоров, а не команда сверху.

L6+

Проектирует стратегию на уровне организации: какие сертификации нужны (SOC 2 Type II как база, ISO 27001 при работе с европейским enterprise, HITRUST в здравоохранении), модель наследования (аудит головной компании покрывает дочерние), бюджет на внешних аудиторов против собственных сил, отчётность перед советом директоров.
Использует compliance как рычаг для тех вложений в безопасность, которые без внешнего давления поддержки не получают — «PCI-DSS требует, иначе теряем merchant agreement» работает лучше, чем «это правильная security practice».

Материалы

Книги

Eric Schlesinger, Sloane Cohen — The SOC 2 Compliance Handbook (Self-published, 2023). Прикладная книга про SOC 2: границы аудита, доказательства, типовые грабли. Не академическая, читается за выходные.
Alan Calder — Nine Steps to Success: An ISO 27001:2022 Implementation Overview (ITGP, 4th ed., 2023). Канонический разбор внедрения ISO 27001, сжато и без воды.

Стандарты и регуляции

AICPA Trust Services Criteria (AICPA). Источник истины для SOC 2 — Security, Availability, Processing Integrity, Confidentiality, Privacy. Главный документ для команды комплаенса; инженеру полезен раздел Security.
ISO/IEC 27001:2022 (ISO, 2022). Стандарт платный, но список контролов (Annex A, 93 штуки) доступен публично и работает как чеклист.
PCI DSS (PCI SSC; v4.0 — март 2022, актуальная редакция v4.0.1 — июнь 2024). Если работаете с картами — обязательно. Стандарт жёстче и конкретнее SOC 2: прямые требования вместо «спроектируйте подходящие контролы».
NIST Cybersecurity Framework 2.0 (NIST, февраль 2024). Не сертификация, а рамка поверх остальных. В версии 2.0 функций стало шесть: к привычным Identify / Protect / Detect / Respond / Recover добавили Govern, и она стоит в центре — то есть NIST явно зафиксировал, что без ответа на вопрос «кто здесь принимает решения о рисках» остальные пять функций повисают в воздухе. Полезен как способ выстроить подход, даже если формальная сертификация не нужна.
FedRAMP Authorization (GSA). Для SaaS, который продаётся федеральным агентствам США. Порог входа высокий: уровни Low, Moderate и High на базе NIST SP 800-53. Не продаёте американскому государству — проходите мимо.
GDPR + California CCPA/CPRA. Это регуляции о приватности, а не фреймворки безопасности, но GDPR требует технических мер защиты (ст. 32) и потому пересекается с SOC 2 и ISO 27001.

Статьи и доклады

Krebs on Security — Capital One 2019 breach. Главный кейс про «SOC 2 compliant + breached». Полезно как иллюстрация для команды, которая считает, что прохождение аудита = безопасность.
OneTrust DataGuidance Comparison Tool. Удобная таблица для сравнения законов о приватности по юрисдикциям.
Cloud Security Alliance — Cloud Controls Matrix (CCM). Соответствие между облачными контролами безопасности и примерно двумя десятками фреймворков (SOC 2, ISO 27001, PCI-DSS, HIPAA, NIST 800-53 и другие). Сильно сокращает работу, когда фреймворков несколько.

Инструменты

GRC platforms (automated compliance): Vanta, Drata, Secureframe, Hyperproof, Sprinto, OneTrust (enterprise). По моим наблюдениям, Vanta и Drata доминируют в сегменте стартапов на первом SOC 2; OneTrust чаще берут крупные организации, у которых сложная картина с приватностью.
Cloud-native compliance: AWS Audit Manager, AWS Security Hub, Google Cloud Compliance Reports Manager, Microsoft Purview Compliance Manager. Полезны, если 90% инфраструктуры в одном облаке; для multi-cloud их не хватает.
Policy as code: Open Policy Agent (OPA) + Conftest, HashiCorp Sentinel, Cloud Custodian, Checkov, Kyverno. Непрерывная проверка на каждый PR с IaC; Checkov часто берут на старте за низкий порог входа.
Автоматический сбор доказательств: интеграции Vanta и Drata плюс свои скрипты (boto3, gcloud, kubectl — снимки в JSON, которые складываются в бакет с политикой хранения). По моим наблюдениям, разница между «комплаенс как каторга» и «комплаенс в фоне» лежит именно в этом слое.
Оценка рисков поставщиков: Whistic, SecurityScorecard, BitSight. Для управления риском со стороны подрядчиков (PCI-DSS req 12.8, SOC 2 CC9.2).

Best practices

Главный публичный кейс — Capital One 2019 breach (никакой CVE, просто неверно настроенный WAF). Данные 106 миллионов человек утекли через SSRF к сервису метаданных AWS. Речь про банк с полным набором регуляторных требований, внутренними аудитами безопасности и работающим vulnerability management — то есть про организацию, где формальная сторона была закрыта лучше, чем у большинства читателей этого листа. Не сработал контроль над дрейфом конфигурации в правилах WAF: одну неверную настройку на одном WAF не поймал ни один контроль аудита, потому что аудит проверял «WAF есть и настроен» на конкретную дату, а не «конфигурация WAF непрерывно соответствует политике». Урок для меня простой: соответствие не равно защищённости, аудит на дату не равен непрерывному контролю. Это второй по силе аргумент за compliance as code. Первый — что от аудита перестаёт болеть.

Отсюда три рабочих правила. Первое: compliance — драйвер требований, а не самостоятельная цель. Каждый control ложится на техническую практику, которая имеет смысл и без аудитора. Если контроль порождает работу исключительно ради аудита и больше нигде не всплывает, это compliance theater — либо драйвер слабый, либо технический эквивалент уже есть и контроль его дублирует. Раз в год область аудита полезно пересматривать целиком.

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

Третье: SOC 2 Type II — период, а не момент. Контроль работает весь период наблюдения, обычно от полугода до года. Access review, проведённый один раз накануне вместо ежеквартального по политике, превращается в замечание. Записанный ритм обязан совпадать с фактическим, иначе на выходе будет заключение с оговорками.

Фреймворки выбираются по клиентскому спросу, а не по принципу «чем больше, тем лучше». Я регулярно вижу стартапы, которые в первый год хотят разом SOC 2 Type II, ISO 27001, HIPAA и PCI-DSS «на будущее». Так не работает. Стоит это половины годового штата безопасности, а отдачи нет, потому что клиенты ничего из списка не просили. Сначала спрос — сделки застревают на вопросе «у вас есть SOC 2?», — и только потом сертификация. Исключение составляют регулируемые отрасли: в здравоохранении HIPAA нужен сразу, в платежах сразу нужен PCI-DSS.

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

Непрерывная проверка контролов лучше доказательств на дату. Политика OPA или Sentinel стоит в конвейере, каждый PR с IaC проверяется против правил, и на выходе копится непрерывный след «контроль действовал такого-то числа». Это не просто дешевле ручного сбора: дрейф ловится на следующем PR, а не через год. Тот же принцип, что в обнаружении дрейфа у GitOps, только применённый к политикам безопасности.

Замечания аудитора стоит читать внимательно, независимо от итогового заключения. Заключение с оговорками — не катастрофа: аудитор подсветил реальную проблему, которая однажды вырастет в инцидент. А чистое заключение без единого замечания чаще означает одно из двух: аудит был поверхностным или вы переплатили за compliance theater. Я читаю замечания не как «что закрыть до следующего аудита», а как «где дыра, которую мы сами не увидели».

Связанные листья

Vulnerability Management — сроки патчинга по severity прямо следуют из SOC 2 CC7.1, PCI-DSS Req 6 и ISO 27001 A.8.8. Комплаенс задаёт цифры, vulnerability management их выполняет.
Secrets Management — шифрование при хранении и передаче, управление ключами, контроль доступа — сквозные требования во всех фреймворках.
Threat Modeling — SOC 2 CC3.x / ISO 27001 A.5.7 требуют оценки рисков; модель угроз — самая операциональная её форма.
Access Control & IAM — SOC 2 CC6.x — большой блок про логический доступ; лист про IAM даёт техническую реализацию.
Supply Chain Security — управление риском поставщиков (SOC 2 CC9.2), оценка подрядчиков, SBOM как доказательство.
Backup & Restore — SOC 2 Availability category + ISO 27001 A.8.13 требуют проверенных резервных копий; RPO и RTO — обязательная часть доказательств.
Incident Response — SOC 2 CC7.3 и применимые breach-notification rules требуют явного маршрута уведомления. В GDPR ст. 33 отсчёт идёт с момента, когда контролёр узнал об утечке персональных данных, и есть исключение по уровню риска, — универсального таймера на любой инцидент там нет.
Change Governance — SOC 2 CC8.1 / ISO 27001 A.8.32 — процесс изменений с согласованием, тестированием и откатом.
GitOps — история git как журнал аудита; непрерывная сверка состояния как доказательство для CC6 (доступ) и CC8 (изменения).
Service Ownership — матрица ответственных за контролы ложится на владение сервисами; без явных владельцев большая часть контролов остаётся ничьей.
DR Policy & Stakeholders — SOC 2 Availability / PCI-DSS Req 12.10 / ISO 22301 требуют документированного плана восстановления с доказательствами того, что его проверяли. В регулируемых отраслях это обязательный артефакт аудита.

Открытые вопросы

HITRUST CSF пока висит без решения: отдельный лист под специфику здравоохранения или подсекция здесь? Мне кажется, подсекция, но уверенности нет. Похожая история с Continuous Controls Monitoring — рынок инструментов растёт быстро, и через год-два это, возможно, вырастет в самостоятельную практику. Ещё один сосед — change management под SOX и PCI (TBD), где каждое изменение тянет за собой формальное одобрение и доказательства; тема сейчас числится за L1 Change Management и с этим листом заметно пересекается.

С SOC 1 я глубоко не разбирался. Это другой класс аудита, про финансовую отчётность, и в SRE-командах он встречается редко. Если он у вас в области аудита, расскажите PR’ом, как с этим живётся.

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