64. Compliance a audit v provozním prostředí (přehled)

Úvod a kontext

"Compliance" (soulad s předpisy) zní vzdáleně od každodenní práce
DevOps inženýra, ale ve skutečnosti se jí dotýká přímo: kdo smí mít
přístup k produkčnímu serveru, jak dlouho se uchovávají logy, jestli
jsou zálohy šifrované, jak se schvalují změny v produkci. Firmy
v regulovaných odvětvích (finance, zdravotnictví, veřejná správa)
musí prokázat auditorovi, že tato pravidla skutečně dodržují — a
DevOps infrastruktura je často místo, kde se to buď prokáže snadno
(díky automatizaci), nebo se stane noční můrou (bez ní).

Teorie

Co je compliance v kontextu provozu

Compliance znamená prokazatelný soulad s externími požadavky —
zákonnými (např. GDPR pro ochranu osobních údajů v EU), odvětvovými
standardy (PCI DSS pro zpracování platebních karet, HIPAA pro
zdravotnická data v USA) nebo interními firemními politikami.
Společný jmenovatel z pohledu provozu je téměř vždy podobný:

• kdo má přístup k čemu (access control),
• jak se změny schvalují a zaznamenávají (change management),
• jak dlouho a jak bezpečně se uchovávají data a logy (retention),
• jak rychle se reaguje na incident a jak se dokumentuje (incident
  response).

Auditní stopa (audit trail)

Základní stavební kámen compliance je auditní stopa — nezvratný,
časově orazítkovaný záznam toho, kdo co udělal. V DevOps kontextu to
zahrnuje: historii Gitu (kdo změnil jaký kód a kdy), historii
Terraform/Ansible spuštění (kdo změnil jakou infrastrukturu),
přístupové logy k produkčním systémům (kdo se přihlásil přes SSH,
kdo četl které tajemství z Vaultu — viz předchozí lekce), a logy
CI/CD pipeline (kdo schválil jaké nasazení). Auditní logy by měly
být nezměnitelné (immutable) — pokud by je mohl mazat nebo
upravovat i administrátor, ztrácí smysl jako důkaz.

Jak DevOps praktiky usnadňují compliance

Paradoxně, dobře zavedené DevOps praktiky auditovatelnost výrazně
zjednodušují oproti tradičnímu ručnímu provozu:

• Infrastructure as Code (viz modul 10) — celá infrastruktura je
  verzovaná v Gitu. Auditor se nemusí ptát "jak víte, že firewall je
  nastavený správně", stačí ukázat Terraform kód a historii commitů.
• Pull requesty jako schvalovací proces — požadavek na "žádná
  změna v produkci bez schválení druhou osobou" se přirozeně naplní
  povinným code review před mergem, bez nutnosti dalšího procesu.
• CI/CD pipeline log — každé nasazení má automatický, nesmazatelný
  záznam kdy, kdo (přes commit autora) a co bylo nasazeno.
• Immutable infrastruktura (kontejnery, znovu-vytvářené VM místo
  ručních úprav) — eliminuje otázku "kdo se ručně přihlásil na
  produkční server a co tam změnil", protože se tam nikdo ručně
  nepřihlašuje.

Rizika a časté chyby

• Sdílené účty — pokud víc lidí používá jeden root SSH klíč
  nebo jeden admin účet do cloudu, auditní stopa ztrácí smysl,
  protože nejde určit, kdo konkrétní akci provedl. Řešení: každý
  člověk (a každá služba) má vlastní identitu, sdílené účty se
  neschvalují.
• Ruční zásahy mimo IaC — pokud se občas "jen rychle" opraví
  něco ručně přímo na produkčním serveru mimo Terraform/Ansible,
  vzniká rozdíl mezi deklarovaným a skutečným stavem (tzv. drift) a
  auditní stopa je neúplná.
• Přílišná retence citlivých dat — GDPR a podobné rámce naopak
  vyžadují data nedržet déle, než je nutné; "čím víc logů, tím
  líp" není vždy správně, pokud logy obsahují osobní údaje.
• Nastavení bez odůvodnění — auditor se často neptá jen "je to
  nastavené správně", ale "proč je to nastavené takto" — dokumentace
  rozhodnutí (viz pozdější lekce o runbookách a dokumentaci) je
  součástí compliance stejně jako technické nastavení.

Praktický příklad

Ukázka, jak auditní požadavek "každá změna produkční infrastruktury
musí být schválena druhou osobou a zaznamenána" vypadá jako
technické pravidlo v GitHub repozitáři s Terraform kódem — pravidlo
ochrany větve (branch protection), které nejde obejít ani
administrátorem:

# Nastavení branch protection pro větev "main" (přes GitHub API/Terraform)
resource "github_branch_protection" "produkce" {
  repository_id  = github_repository.infrastruktura.node_id
  pattern        = "main"

  required_pull_request_reviews {
    required_approving_review_count = 1
    require_code_owner_reviews      = true
  }

  required_status_checks {
    strict   = true
    contexts = ["terraform-plan", "tfsec-scan"]
  }

  enforce_admins = true   # pravidlo platí i pro administrátory repozitáře
}

Příklad strukturovaného auditního záznamu o přístupu k tajemství
z Vaultu (viz předchozí lekce), který se odesílá do centralizovaného,
nezměnitelného logovacího úložiště:

{
  "timestamp": "2026-03-14T09:12:03Z",
  "type": "secret_read",
  "actor": "svc-objednavky-ci",
  "path": "secret/data/aplikace/databaze",
  "client_ip": "10.4.2.17",
  "result": "success"
}

Takový záznam odpovídá na typickou auditní otázku "kdo a kdy četl
přístupové údaje k produkční databázi" bez nutnosti kohokoliv
zpětně vyslýchat.

Shrnutí

Compliance v provozu znamená prokazatelný soulad s externími
požadavky přes auditní stopu — nezvratný záznam kdo, co a kdy
udělal. DevOps praktiky jako Infrastructure as Code, povinné pull
requesty a immutable infrastruktura auditovatelnost přirozeně
usnadňují, protože stav infrastruktury a historie změn jsou už
z principu verzované a zaznamenané. Časté chyby jsou sdílené účty,
ruční zásahy mimo IaC a nadměrná retence citlivých dat. Cíl není
"projít audit jednorázově", ale mít infrastrukturu nastavenou tak,
aby byla auditovatelná průběžně, bez zvláštní přípravy.

Kontrolní otázky

1. Proč jsou sdílené účty (např. jeden společný root přístup)
   problémem z hlediska auditní stopy?
2. Jak konkrétně pomáhá Infrastructure as Code prokázat auditorovi
   správnou konfiguraci infrastruktury?
3. Co znamená "drift" mezi deklarovaným a skutečným stavem
   infrastruktury a proč ho ruční zásahy způsobují?
4. Mini cvičení: vyjmenujte tři technické kontroly (např. branch
   protection, MFA, immutable logy), kterými byste jako DevOps
   inženýr naplnili požadavek "žádná změna produkce bez schválení a
   záznamu", aniž byste museli spoléhat na to, že to lidé budou
   dodržovat dobrovolně.