Operațiuni și configurații de audit de management al →

Configurații de audit

1) Scop și valoare

Configurațiile de audit asigură responsabilitatea dovedită și repetabilitatea schimbării: cine, când și ce sa schimbat; ceea ce este justificat; așa cum a fost testat; cum să se rostogolească înapoi. Acest lucru reduce riscul de incidente, scurgeri de secrete, neconcordanțe de conformitate și editări „ascunse” în prod.

• O singură sursă de adevăr (SoT) pentru configurații.
• Urmărirea completă a schimbării (end-to-end).
• Lansări previzibile și revenire rapidă.
• Politici de conformitate și securitate.

2) Domeniul de aplicare

Infrastructură: manifeste Terraform/Helm/Ansible/K8s, rețea ACL/WAF/CDN.
Configurații de aplicații: fișiere 'yaml/json/properties', steaguri de caracteristici, limite/cote.
Secrete și chei: seif/kms, certificate, jetoane, parole.
Conducte de date: scheme, transformări, orare ETL/stream.
Integrări: PSP/KYC/furnizori, webhook-uri, politici de retry/timeout.
Observabilitate: Reguli de alertă, tablouri de bord, SLO/SLA.

3) Principii

Config ca date: artefacte declarative, versionate, testabile.
Imutabilitatea și idempotența: reproductibilitatea mediului din cod.
Scheme și contracte: validare strictă (JSON-Schema/Protobuf), compatibilitate înapoi/înainte.
Minimizarea modificărilor manuale: modificări numai prin MR/PR.
Separarea îndatoririlor (SoD) și 4-eyes: author! = emploer; revizuirea obligatorie.
Atribuire și semnături: semnături ale comitetelor/eliberărilor, atestări ale artefactelor.

4) Arhitectura de audit

1. SCM (Git) ca SoT: toate configurațiile din depozit, ramura „principală” este protejată.

• Config Registry (director de configurații, posesiuni, SLA-uri, medii),
• Registrul schemei (versiunile schemei de configurare/eveniment),
• Policy Engine (OPA/Conftest) - set de verificări.
• 3. CI/CD-gates: format/schemă → verificare statică → verificări ale politicilor → scanare secretă → plan de schimbare a →.
• 4. Livrare: GitOps (ex. ArgoCD/Flux) cu detector de derivă și jurnale de audit aplicații.
• 5. Magazin de dovezi: un depozit de artefacte de audit (plan, jurnale, semnături, construiește, SBOM).
• 6. Jurnal de acțiune: jurnal invariabil (numai pentru adăugare) al evenimentelor 'CREATE/APPROVE/APPLY/ROLLBACK/ACCESS'.

5) Modelul datelor de audit (minim)

Сущности: 'ConfigItem (id, env, service, proprietar, schema_version, sensibilitate)'

События: 'modificare _ id, actor, acțiune, ts, diff_hash, motiv, aprobări []'

Артефакты: 'plan _ url, test_report_url, policy_report, semnătură, release_tag'

Conexiuni: RFC/bilet ↔ PR ↔ depla (sha) ↔ eliberarea înregistrării ↔ monitorizarea SLO.

6) Procesul de schimbare (end-to-end)

1. RFC/bilet → țintă, risc, backout.
2. PR/MR → linting, validare schematică, verificări de politici, scanare secretă.
3. Plan/previzualizare → dry-run/plan, diff de resurse, estimare cost/impact.
4. Aprobă (4-eyes/SoD, eticheta CAB cu risc ridicat).
5. Implementați (prin fereastră/calendar) → se aplică GitOps; drift alert activat.
6. Verificarea → fum/SLO-gardrails, confirmarea rezultatului.
7. Arhivarea probelor → depozitarea probelor; actualizarea dicționarului de configurare.

7) Politici și reguli (exemple)

SoD: Autorul PR nu deține în prod.
Limita de timp: Nici o producție în afara „congela”.
Domeniul de aplicare: schimbarea cheilor sensibile necesită 2 actualizări de la Securitate/Conformitate.
Secretele: interzise pentru a păstra în repo; calea seifului + referințele rolurilor de acces numai.
Plase: intrare cu '0. 0. 0. 0/0 'nu este permis fără o excepție temporară și TTL.
Alerte: este interzisă reducerea criticii P1 fără CAB.

8) Control secret

Stocare Vault/KMS, TTL-uri scurte, rotire automată.
Scanare secretă în CI (modele cheie, entropie ridicată).
Izolarea secretelor pe medii/roluri; privilegii minime necesare.
Criptarea „pe fir” și „în repaus”; jurnalele de audit închise de acces la secrete.

9) Instrumente (variabilă)

Lint/Schema: "yamllint'," jsonschema "," ajv "," cue ".
Politica: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (detectare drift, audit, RBAC).
Secrete: HashiCorp Vault, cloud KMS, manageri cert.
Scanere: trufflehog, gitleaks (secrete); OPA/Regula (reguli).
Raportare: jurnale de export în DWH/BI, legătură cu incidente și schimbarea sistemului.

10) Exemple de reguli și artefacte

Schema JSON pentru configurarea limitelor

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) - neagă '0. 0. 0. 0/0 'в pătrundere

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) - care a redus criticalitatea alertelor într-o lună

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 comite exemplu de mesaj (câmpuri obligatorii)

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) Monitorizarea și alertarea

Drift-detectare: configurare într-un cluster ≠ Git → P1/P2 semnal + auto-remediere (reconciliere).
Schimbare de risc ridicat: schimbarea rețelelor/secretelor/politicilor - notificare în # security-ops.
Dovezi lipsă: implementați fără plan/semnătură/rapoarte - bloc sau alertă.
Active expirate: certificat/perioade de valabilitate cheie → alerte proactive.

12) Valori și KPI-uri

Acoperire de audit% - ponderea configurațiilor în cadrul schemelor/politicilor/scanerelor.
Drift MTTR este timpul mediu de derivă de compensare.
Politica de conformitate% - Trece politici la PR.
Secretele Scurgere MTTR - de la scurgere la rechemare/rotație.
Backout Rate - proporția de rollback de modificări de configurare.
Dimensiunea medie a schimbării - diferența medie pe linii/resurse (mai puțin este mai bine).

13) Raportarea și conformitatea

Urme de audit: stocare ≥ 1-3 ani (conform cerințelor), stocare neschimbabilă.
Reglementare: ISO 27001/27701, SOX-like SoD, GDPR (PII), cerințele industriei (iGaming: contabilizarea modificărilor în calculele GGR/NGR, limite, reguli bonus).
Rapoarte lunare: modificări de vârf, încălcări ale politicilor, derivă, certificate care expiră, stare de rotație.

14) Playbooks

A. Drift detectat în prod

1. Blocați auto-depozit pentru serviciul afectat.
2. Eliminați instantaneul stării curente.
3. Comparați cu Git, inițiați 'reconcilierea' sau rollback.
4. Creați incident P2, specificați sursa de derivă (manual kubectl/consolă).
5. Activați protecția: fără modificări directe (PSP/ABAC), anunțați proprietarii.

B. Certificatul PSP a expirat

1. Treceți la calea de rezervă/PSP, coborâți temporizările/retrasările.
2. Eliberați un nou certificat prin procesul PKI, actualizați configurarea prin Git.
3. Test de fum, retur de trafic, închide incidentul, post-mortem.

C. Secret lovit PR

1. Revocați tasta/token, utilizați rotația.
2. Rescrieți istoria/eliminați artefact din cache-uri, problema RCA.
3. Adăugați o regulă la scanerul secret, antrenați comanda.

15) Anti-modele

Editări manuale „la vânzare” fără urmă și rollback.
Configurații fără scheme și fără validare.
Secrete în variabilele Git/CI fără KMS/Vault.
Monorepos cu echivalentul „super-dreptei globale”.
"Surd' GitOps fără alerte derivă și jurnalele de aplicații.
PR-uri uriașe „toate deodată” - atribuire neclară și risc ridicat.

16) Liste de verificare

Înainte de fuziune

• Diagrama și linterele au trecut
• Politicile OPA/Conftest sunt verzi
• Scanare secretă - „curat”
• Plan/diff atașat, evaluarea riscurilor, backout gata
• 2 Aprilie (prod) și SoD s-au întâlnit

Înainte de implementare

• Eliberați fereastra și calendarul verificat
• Monitorizarea driftului este activă
• Gardrails SLO configurate, teste de fum gata

Lunar

• Rotirea cheilor/certificatelor în grafic
• Inventarul proprietarilor și al drepturilor
• OPA/Exclusion Rules Review (TTL)
• Încercare de foraj la incendiu

17) Sfaturi de proiectare

Împărțiți modificările în difuzoare mici; un PR este un singur scop.
Șabloane PR/comite obligatorii cu RFC/risc/rollback.
Pentru configurații dinamice, utilizați „centre de configurare” cu audit și rollback.
Versionize circuite; interzice ruperea fără migrații.
Vizualizați „harta de configurare”: ce, unde, cine este controlat.

18) Integrarea cu schimbarea și gestionarea incidentelor

PR ↔ RFC ↔ calendar de lansare ↔ incidente/post-mortems.
Măsurători automate (SLO/business) pentru configurarea versiunilor.
Creați automat sarcini pentru a șterge vechile steaguri/excepții (TTL).

19) Linia de jos

Configurațiile de audit nu sunt „raportarea pe hârtie”, ci un mecanism de fiabilitate operațională: configurațiile sunt date, modificările sunt controlate și verificabile, secretele sunt sub cheie, iar întreaga poveste este transparentă și verificabilă. Acesta este modul în care este construită o platformă stabilă, conformă și previzibilă.