Operacje i → Konfiguracje audytu zarządzania

Konfiguracje audytu

1) Cel i wartość

Konfiguracje audytu zapewniają sprawdzoną rozliczalność i powtarzalność zmian: kto, kiedy i co się zmieniło; co jest uzasadnione; zgodnie z badaniami; jak się cofnąć. Zmniejsza to ryzyko incydentów, wycieków tajemnic, niespójności zgodności i „ukrytych” edycji w prod.

• Pojedyncze źródło prawdy (SoT) dla konfiguracji.
• Pełne śledzenie zmian (end-to-end).
• Przewidywalne wydania i szybki zwrot.
• Zgodność i polityka bezpieczeństwa.

2) Zakres stosowania

Infrastruktura: manifesty Terraform/Helm/Ansible/K8s, sieć ACL/WAF/CDN.
Konfiguracje aplikacji: pliki 'yaml/json/properties', flagi funkcji, limity/kwoty.
Sekrety i klucze: skarbiec/km, certyfikaty, żetony, hasła.
Rurociągi danych: schematy, przekształcenia, harmonogramy ETL/strumienia.
Integracje: PSP/KYC/dostawcy, haki internetowe, polityka retry/timeout.
Obserwowalność: Zasady ostrzegania, deski rozdzielcze, SLO/SLA.

3) Zasady

Config jako dane: deklaratywne, wersjonowane, sprawdzalne artefakty.
Niezmienność i idempotencja: odtwarzalność medium z kodu.
Programy i umowy: ścisła walidacja (JSON-Schema/Protobuf), kompatybilność powrotna/terminowa.
Minimalizacja ręcznych edycji: zmiany tylko przez MR/PR.
Rozdzielenie obowiązków (SoD) i 4-oczy: autor! = deployer; obowiązkowy przegląd.
Przypisanie i podpisy: podpisy popełnień/zwolnień, poświadczenia artefaktów.

4) Architektura audytu

1. SCM (Git) jako SoT: wszystkie konfiguracje w repozytorium, gałąź „główna” jest chroniona.

• Rejestr Config (katalog konfiguracji, dóbr, SLA, środowisk),
• Rejestr schematu (wersje schematu konfiguracji/zdarzenia),
• Silnik polityczny (OPA/Conftest) - zestaw kontroli.
• 3. CI/CD-gates: format/scheme → kontrola statyczna → sprawdzenie zasad → tajny skan → suchy-run → plan zmian.
• 4. Dostawa: GitOps (np. ArgoCD/Flux) z detektorem dryfu i dziennikami audytu aplikacji.
• 5. Sklep Dowodowy: repozytorium artefaktów audytu (plan, dzienniki, podpisy, budynki, SBOM).
• 6. Dziennik działania: niezmienny dziennik (tylko dodatek) zdarzeń 'CREATE/APPROVE/APPLY/ROLLBACK/ACCESS'.

5) Model danych audytowych (minimum)

Суноста: „ConfigItem (id,,, Usługa, Właściciel, schema_version, Wrażliwość)”

Состий: „change _ id, actor, action, ts, diff_hash, reason, approvals []”

Артевакта: "plan _ url, test_report_url, policy_report, podpis, release_tag'

Podłączenia: RFC/bilet na RFC

6) Proces zmiany (od końca do końca)

1. RFC/bilet → cel, ryzyko, wycofanie.
2. PR/MR → linking, zatwierdzanie schematów, kontrole polityki, tajne skanowanie.
3. Plan/podgląd → dry-run/plan, resource diff, cost/impact estimate.
4. Zatwierdzenie (4-eyes/SoD, etykieta CAB o wysokim ryzyku).
5. Wdrożenie (według okna/kalendarza) → Zastosowanie GitOps; Włączony alert dryfujący.
6. Weryfikacja → dym/SLO-szyny, potwierdzenie wyniku.
7. Archiwizacja dowodów → sklep dowodowy; aktualizacja słownika konfiguracyjnego.

7) Polityki i zasady (przykłady)

SoD: Autor PR nie trzyma w prod.
Termin: Brak produkcji poza „zamrożeniem”.
Zakres: Zmiana kluczy wrażliwych wymaga 2 aktualizacji z zabezpieczeń/zgodności.
Tajemnice: zabronione przechowywać w repo; ścieżka skarbca + tylko odniesienia do roli dostępu.
Sieci: ingress z '0. 0. 0. 0/0 "nie jest dozwolone bez tymczasowego wyjątku i TTL.
Alerts: zakazane jest zmniejszenie krytyczności P1 bez CAB.

8) Tajna kontrola

Skarbiec/pamięć KMS, krótkie TTL, automatyczna rotacja.
Tajne skanowanie w CI (wzorce kluczy, wysoka entropia).
izolacja tajemnic przez środowisko/role; minimalne niezbędne uprawnienia.
Szyfrowanie „na drucie” i „w spoczynku”; zamknięte dzienniki kontroli dostępu do tajemnic.

9) Narzędzia (zmienna)

Lint/Schema: „yamllint”, „jsonschema”, „ajv”, „cue”.
Polityka: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (wykrywanie dryfów, audyt, RBAC).
Sekrety: HashiCorp Vault, cloud KMS, cert managers.
Skanery: trufflehog, gitleaks (tajemnice); OPA/Regula (zasady).
Raportowanie: dzienniki eksportu do DWH/BI, link do systemu incydentów i zmian.

10) Przykłady zasad i artefaktów

Schemat JSON dla konfiguracji limitów

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
}

Konftest/OPA (rego) - zaprzeczam '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"
}

Konftest/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) - który zmniejszył krytyczność wpisów w ciągu miesiąca

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 example (wymagane pola)

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) Monitorowanie i ostrzeganie

Detekcja dryfu: konfiguracja w klastrze P1/P2 Git → sygnał + auto-remediacja (reconcile).
Zmiana wysokiego ryzyka: zmiana sieci/tajemnic/zasad - powiadomienie w # security-ops.
Brakujące dowody: wdrożyć bez planu/podpisu/raportów - blok lub alert.
Wygasłe aktywa: okresy ważności certyfikatu/klucza → aktywne wpisy.

12) Wskaźniki i KPI

Zakres audytu% - udział konfiguracji w schematach/politykach/skanerach.
Drift MTTR to średni czas usuwania dryfu.
Zgodność z polityką% - Przekazywanie polityk do PR.
Sekrety Wyciek MTTR - od przecieku do wycofania/rotacji.
Backout Rate - odsetek wałków zmian konfiguracyjnych.
Średnia wielkość zmiany - średnia różnica na liniach/zasobach (mniejsza jest lepsza).

13) Sprawozdawczość i zgodność

Ślady audytu: przechowywanie ≥ 1-3 lata (zgodnie z wymaganiami), niezmienne przechowywanie.
Regulacja: ISO 27001/27701, SOX-like SoD, RODO (PII), wymagania branżowe (iGaming: rozliczanie zmian w obliczeniach GGR/NGR, limity, zasady premii).
Raporty miesięczne: najważniejsze zmiany, naruszenia zasad, dryfowanie, wygasające certyfikaty, stan rotacji.

14) Playbooks

A. Dryf wykryty w prod

1. Zablokuj automatyczny depozyt dla dotkniętej usługi.
2. Usuń migawkę aktualnego stanu.
3. Porównaj z Git, zainicjuj 'reconcile' lub rollback.
4. Utwórz incydent P2, określ źródło dryfu (ręczny kubectl/konsola).
5. Włącz ochronę: brak bezpośrednich zmian (PSP/ABAC), powiadom właścicieli.

B. Wygasł certyfikat PSP

1. Przełączyć na ścieżkę kopii zapasowej/PSP, obniżyć czas/przekaźniki.
2. Wystawić nowy certyfikat poprzez proces PKI, zaktualizować konfigurację przez Git.
3. Test dymu, ruch powrotny, zamknij wypadek, pośmiertnie.

C. Secret hit PR

1. Cofnij klucz/token, użyj rotacji.
2. Przepisz historię/usuń artefakt z pamięci podręcznej, wydaj RCA.
3. Dodaj regułę do tajnego skanera, trenuj polecenie.

15) Anty-wzory

Ręczne edycje „na sprzedaż” bez śladu i rolki.
Konfiguracje bez schematów i bez walidacji.
Sekrety w zmiennych Git/CI bez KMS/Vault.
Monorepos z odpowiednikiem „globalnej super-prawicy”.
Głuche gitopy bez wpisów dryfujących i dzienników aplikacji.
Ogromne PRs „wszystko na raz” - niejasne przypisanie i wysokie ryzyko.

16) Listy kontrolne

Przed połączeniem

• Przeszły diagram i liniowce
• OPA/Polityka Conftest są zielone
• Tajne skanowanie - „czyste”
• Załączony plan/różnica, ocena ryzyka, wycofanie gotowe
• 2 kwietnia (prod) i SoD met

Przed wdrożeniem

• Sprawdzone okno wydania i kalendarz
• Monitorowanie dryfu jest aktywne
• Szyny ogrodnicze SLO skonfigurowane, testy dymu gotowe

Miesięcznie

• Rotacja kluczy/certyfikatów w harmonogramie
• Spis właścicieli i prawa
• Przegląd OPA/zasad wykluczenia (TTL)
• Badanie wiertła przeciwpożarowego

17) Wskazówki dotyczące projektowania

Podzielić zmiany na małe dyfuzje; Jeden PR to jeden cel.
Obowiązkowe szablony PR/commit z RFC/risk/rollback.
W przypadku konfiguracji dynamicznych należy użyć „config centers” z audytem i rollback.
Werjonizacja obwodów; zakazać łamania bez migracji.
Wyobraź sobie „mapę konfiguracyjną”: co, gdzie, kto jest kontrolowany.

18) Integracja z zarządzaniem zmianami i incydentami

Kalendarz RFC

Automatyczne mierniki (SLO/biznes) do konfiguracji wersji.
Automatyczne tworzenie zadań do usuwania starych flag/wyjątków (TTL).

19) Najważniejsze

Konfiguracje audytu nie są „raportowaniem papierowym”, ale mechanizmem niezawodności operacyjnej: konfiguracje są danymi, zmiany są kontrolowane i weryfikowalne, sekrety są pod blokadą i kluczem, a cała historia jest przejrzysta i weryfikowalna. W ten sposób powstaje stabilna, zgodna z wymaganiami i przewidywalna platforma.