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

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

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-тести готові

Щомісяця

• Ротація ключів/сертифікатів за графіком
• Інвентаризація власників і прав
• Рев'ю правил ОРА/винятків (TTL)
• Тест інцидент-плейбуків (fire-drill)

17) Дизайн-поради

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

18) Інтеграції з управлінням змінами та інцидентами

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

19) Підсумок

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