Операциялар және басқару → Конфигурация аудиті

Конфигурация аудиті

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. SoT ретінде SCM (Git): репозиторийдегі барлық конфигалар, '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. Әрекеттер журналы: 'CREATE/APPROVE/APPLY/ROLLBACK/ACCESS' оқиғаларының өзгермейтін журналы (append-only).

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-alerting қосулы.
6. Верификация → smoke/SLO-гардрейл, нәтижені растау.
7. Дәлелдерді мұрағаттау → evidence store; теңшелімдер сөздігін жаңарту.

7) Саясат және ережелер (мысалдар)

SoD: PR авторы өнімді ұстамайды.
Уақытты шектеу: «freeze» тыс прод-депломен тыйым салынады.
Scope: сезімтал кілттерді өзгерту Security/Compliance бағдарламасынан 2 апруверді талап етеді.
Құпиялар: репода сақтауға тыйым салынады; vault жолына + қатынау рөліне сілтемелер ғана.
Желілер: ingress с '0. 0. 0. 0/0 'уақытша ерекшеліксіз және TTL тыйым салынған.
Алерталар: CAB-сыз P1 сындылығын төмендетуге тыйым салынады.

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 (ережелер).
Есеп беру: 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-detect: ≠ Git → кластерінде P1/P2 сигнал + авто-ремедиация (reconcile).
High-risk change: желілерді/құпияларды/саясатты өзгерту - -ops #security хабарлама.
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) Қарсы үлгілер

«Сынамада» ізсіз және кері қайтарусыз қолмен түзетулер.
Сызбасыз және валидациясыз конфигалар.
KMS/Vault жоқ Git/CI айнымалыларындағы құпиялар.
«Жаһандық супер-құқық» баламасымен Монорепо.
«Саңырау» GitOps drift-алертсіз және қолдану журналдарынсыз.
Орасан зор PR «бәрі бірден» - анық емес атрибуция және жоғары тәуекел.

16) Чек парақтары

merge алдында

• Сызба мен линтерлер өтті
• OPA/Conftest «жасыл» саясаты
• Secret-scan - «таза»
• Жоспар/дифф қоса берілген, тәуекел бағаланған, backout дайын
• 2 апрува (prod) және SoD сақталған

deploy алдында

• Шығару терезесі мен күнтізбесі тексерілді
• Drift-мониторинг белсенді
• SLO-гардрейл конфигурацияланған, smoke-тесттер дайын

Ай сайын

• Кесте бойынша кілттерді/сертификаттарды ротациялау
• Иелері мен құқықтарын түгендеу
• ОРА/алып тастау ережелерінің ревю (TTL)
• Playbook инцидент сынағы (fire-drill)

17) Дизайн-кеңестер

Өзгерістерді шағын диффаларға бөлшектеңіз; бір PR - бір мақсат.
RFC/тәуекелі/кері қайтуы бар міндетті PR/коммиттер үлгілері.
Динамикалық пішімдер үшін аудит және rollback бар «пішім орталықтарын» пайдаланыңыз.
Схемаларды нұсқалау; көші-қонсыз breaking жасауға тыйым салыңыз.
«Пішіндер картасын» визуализациялаңыз: не, қайда, кім басқарады.

18) Өзгерістер мен инциденттерді басқарумен интеграциялау

PR, RFC, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR, PR.
Параметрлерді автоматты байланыстыру (SLO/бизнес).
Ескі жалауларды/ерекшеліктерді (TTL) жою тапсырмаларын автоматты түрде жасау.

19) Қорытынды

Конфигурация аудиті - бұл «қағаз есептілік» емес, сенімділіктің операциялық тетігі: конфиги - деректер, өзгерістер - бақыланатын және тексерілетін, құпиялар - құлыпталған, ал бүкіл тарих - ашық және тексеруге жарамды. Осылайша тұрақты, комплаентті және болжамды платформа құрылады.