Операции и Управление → Аудит конфигураций

Аудит конфигураций

1) Цель и ценность

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

• Единый источник правды (SoT) для конфигов.
• Полная трассировка изменений (end-to-end).
• Предсказуемые релизы и быстрый откат.
• Соответствие регуляторным требованиям и политикам безопасности.

2) Область охвата

Инфраструктура: Terraform/Helm/Ansible/K8s манифесты, сетевые ACL/WAF/CDN.
Прикладные конфиги: файлы `yaml/json/properties`, фича-флаги, лимиты/квоты.
Секреты и ключи: vault/kms, сертификаты, токены, пароли.
Пайплайны данных: схемы, трансформации, расписания ETL/стримов.
Интеграции: PSP/KYC/провайдеры, вебхуки, retry/timeout политики.
Наблюдаемость: правила алертов, дашборды, SLO/SLA.

3) Принципы

Config as Data: декларативные, версионируемые, тестируемые артефакты.
Иммутабельность и идемпотентность: воспроизводимость среды из кода.
Схемы и контракты: строгая валидация (JSON-Schema/Protobuf), back/forward-совместимость.
Минимизация ручных правок: изменения только через MR/PR.
Разделение обязанностей (SoD) и 4-eyes: автор!= деплоер; обязательный ревью.
Атрибуция и подписи: подписи коммитов/релизов, attestations артефактов.

4) Архитектура аудита

1. SCM (Git) как SoT: все конфиги в репозитории, ветка `main` защищена.

• Config Registry (каталог конфигов, владения, SLA, окружения),
• Schema Registry (версии схем конфигов/ивентов),
• Policy Engine (OPA/Conftest) — набор проверок.
• 3. CI/CD-гейты: формат/схема → статическая проверка → policy checks → секрет-скан → dry-run → план изменений.
• 4. Delivery: GitOps (например, ArgoCD/Flux) с drift-детектором и audit-логами применений.
• 5. Evidence Store: хранилище артефактов аудита (план, логи, подписи, билды, SBOM).
• 6. Журнал действий: неизменяемый лог (append-only) событий `CREATE/APPROVE/APPLY/ROLLBACK/ACCESS`.

5) Модель данных аудита (минимум)

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

Связи: RFC/тикет ↔ PR ↔ деплой (sha) ↔ релиз-запись ↔ мониторинг SLO.

6) Процесс изменения (сквозной)

1. RFC/тикет → цель, риск, backout.
2. PR/MR → линтинг, схематическая валидация, policy-проверки, секрет-скан.
3. План/превью → dry-run/plan, дифф ресурсов, оценка стоимости/импакта.
4. Approve (4-eyes/SoD, метка CAB при высоком риске).
5. Deploy (по окну/календарю) → GitOps применяет; включен drift-алертинг.
6. Верификация → smoke/SLO-гардрейлы, подтверждение результата.
7. Архивация доказательств → evidence store; обновление словаря конфигов.

7) Политики и правила (примеры)

SoD: в прод не мержит автор PR.
Ограничение времени: прод-деплой вне «freeze» запрещен.
Scope: изменение чувствительных ключей требует 2х апруверов из Security/Compliance.
Секреты: запрещено хранить в репо; только ссылки на vault-путь + роль доступа.
Сети: ingress с `0.0.0.0/0` запрещен без временного исключения и TTL.
Алерты: запрещено снижать критичность P1 без CAB.

8) Контроль секретов

Хранение в Vault/KMS, короткие TTL, автоматическая ротация.
Secret scanning в CI (паттерны ключей, high-entropy).
Изоляция секретов по окружениям/ролям; минимально необходимые привилегии.
Шифрование «на проводе» и «в покое»; закрытые аудит-логи доступа к секретам.

9) Инструменты (вариативно)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
Secrets: HashiCorp Vault, cloud KMS, cert-менеджеры.
Сканеры: trufflehog, gitleaks (секреты); OPA/Regula (правила).
Отчетность: export журналов в DWH/BI, связка с инцидент- и change-системой.

10) Примеры правил и артефактов

JSON-Schema для конфигурации лимитов

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (rego) — запрет `0.0.0.0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA — SoD (прод не мержит автор)

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) — кто снижал критичность алертов за месяц

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Пример Git commit message (обязательные поля)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) Мониторинг и алертинг

Drift-детект: конфиг в кластере ≠ Git → P1/P2 сигнал + авто-ремедиация (reconcile).
High-risk change: изменение сетей/секретов/политик — уведомление в #security-ops.
Missing evidence: деплой без плана/подписи/отчетов — блок или алерт.
Expired assets: сроки действия сертификатов/ключей → pro-активные алерты.

12) Метрики и KPI

Audit Coverage % — доля конфигов под схемами/политиками/сканерами.
Drift MTTR — среднее время устранения дрейфа.
Policy Compliance % — проход политик на PR.
Secrets Leak MTTR — от утечки до отзыва/ротации.
Backout Rate — доля откатов конфиг-изменений.
Mean Change Size — средний дифф по строкам/ресурсам (меньше — лучше).

13) Отчетность и соответствие

Следы аудита: хранение ≥ 1–3 лет (по требованиям), неизменяемое хранилище.
Регуляторика: ISO 27001/27701, SOX-подобные SoD, GDPR (PII), отраслевые требования (iGaming: учет изменения расчетов GGR/NGR, лимитов, бонус-правил).
Ежемесячные отчеты: топ-изменений, нарушения политик, дрейф, истекающие сертификаты, статус ротаций.

14) Плейбуки

A. Обнаружен дрейф в проде

1. Заблокировать авто-деплой для затронутого сервиса.
2. Снять снапшот текущего состояния.
3. Сравнить с Git, инициировать `reconcile` или откат.
4. Создать инцидент P2, указать источник дрейфа (ручной kubectl/консоль).
5. Включить защиту: запрет прямых изменений (PSP/ABAC), уведомить владельцев.

B. Просрочен сертификат PSP

1. Переключить на резервный путь/PSP, понизить таймауты/ретраи.
2. Выпустить новый сертификат через PKI-процесс, обновить конфиг через Git.
3. Smoke-тест, вернуть трафик, закрыть инцидент, провести пост-мортем.

C. Секрет попал в PR

1. Отозвать ключ/токен, задействовать ротацию.
2. Переписать историю/удалить артефакт из кэшей, оформить RCA.
3. Добавить правило в secret-сканер, обучить команду.

15) Анти-паттерны

Ручные правки «на проде» без следа и отката.
Конфиги без схем и без валидации.
Секреты в Git/CI-переменных без KMS/Vault.
Монорепо с эквивалентом «глобального супер-права».
«Глухой» GitOps без drift-алертов и журналов применений.
Огромные PR «все и сразу» — нечеткая атрибуция и высокий риск.

16) Чек-листы

Перед merge

• Схема и линтеры пройдены
• Политики OPA/Conftest «зеленые»
• Secret-scan — «чисто»
• План/дифф приложен, риск оценен, backout готов
• 2 апрува (prod) и SoD соблюден

Перед deploy

• Окно релиза и календарь проверены
• Drift-мониторинг активен
• SLO-гардрейлы настроены, smoke-тесты готовы

Ежемесячно

• Ротация ключей/сертификатов по графику
• Инвентаризация владельцев и прав
• Ревью правил OPA/исключений (TTL)
• Тест инцидент-плейбуков (fire-drill)

17) Дизайн-советы

Дробите изменения на маленькие диффы; один PR — одна цель.
Обязательные шаблоны PR/коммитов с RFC/риском/откатом.
Для динамических конфигов используйте «центры конфигов» с аудитом и rollback.
Версионируйте схемы; запрещайте breaking без миграций.
Визуализируйте «карту конфигов»: что, где, кем управляется.

18) Интеграции с управлением изменениями и инцидентами

PR ↔ RFC ↔ календарь релизов ↔ инциденты/пост-мортемы.
Автопривязка метрик (SLO/бизнес) к релизам конфигов.
Авто-создание задач на удаление старых флагов/исключений (TTL).

19) Итог

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