Audit není fotka — je to auditor, který se mezi běhy sám učí
Cloud se nezakládá „nebezpečně" — nebezpečným se stává postupně. Přibude instance, otevře se port „jen na zkoušku", vznikne bucket, nasadí se služba pod dlouho neobměňovaným klíčem. Rok–dva a máte 130 serverů, tisíce snapshotů a nikdo neumí říct, zda je root chráněný, zda jsou disky šifrované a zda byste vůbec zpozorovali, že se někdo dostal dovnitř. Udělali jsme read-only bezpečnostní audit AWS účtu jedné střední firmy — přes roli jen pro čtení, bez jediné změny v účtu — a našli jsme přesně tento tichý dluh: root bez MFA, 100 % disků i snapshotů nešifrovaných, detekci hrozeb vypnutou ve všech regionech.
Jenže audit jako jednorázový PDF report zastará v den dodání — za týden přidáte službu, AWS vydá novou funkci, vyjde nové CVE. Proto jsme nepostavili report, ale auditora, který žije dál: při každém běhu měří deterministicky totéž, mezi běhy si sám rozšiřuje sadu pravidel — a každé nové pravidlo si nejdřív dokáže, než mu uvěří.
Problém: díry, které není vidět — a audit, který zestárne dřív, než ho dočtete
Bezpečnostní dluh v cloudu není jeden velký přešlap. Je to součet drobností, které se nikdy nesešly na jedné obrazovce — a stav, který se mění rychleji, než ho stíháte kontrolovat. Náklad se koncentruje do tří problémů.
1. Konfigurace se časem rozejde a nikdo ji nevidí celou
Kdo to má: každá firma, jejíž AWS účet rostl rychleji než její bezpečnostní postupy — root se používá „jen výjimečně" (a nemá MFA), výchozí security group má roky otevřený SSH a Docker API do internetu na stovce síťových rozhraní najednou, a šifrování disků se nikdy nezaplo, takže je nešifrovaných 100 % svazků i snapshotů.
Každá z těch věcí je sama o sobě „jen nastavení". Dohromady jsou to otevřené dveře: jedno uhádnuté root heslo = ztráta celého účtu; jeden kompromitovaný host = laterální pohyb přes otevřené Docker API na desítky dalších. A pro firmu v EU je nešifrování zároveň GDPR riziko (čl. 32).
Jak to řešíme: audit projde službu po službě napříč všemi regiony a svede všechna tato nastavení na jedno místo — ne „pocit", ale seznam s důkazem u každého nálezu.
2. Bez detekce a logů nevíte, zda jste už nebyli napadeni
Kdo to má: provoz, kde je GuardDuty (detekce hrozeb) vypnutý ve všech regionech, chybí VPC flow logy i access logy z load balancerů. Servery běží, aplikace fungují — ale kdyby dnes někdo těžil krypto na vašich instancích nebo exfiltroval data, nedozvíte se to.
Tohle je nejzákeřnější část: absence problému vypadá stejně jako bezpečí. Dokud se nic nestane, nikomu nechybí něco, co nikdy neviděl.
Jak to řešíme: audit explicitně ověří, co všechno byste dokázali zachytit — detekci, síťové i aplikační logy, pokrytí skenování zranitelností — a kde je slepé místo, pojmenuje ho jako nález s konkrétní nápravou.
3. Jednorázový sken je nesetříděná hromada — a zastará v den dodání
Kdo to má: kdokoli, kdo někdy pustil skener a dostal zpět 200 „kritických" řádků bez pořadí — a za měsíc je stejně neaktuální, protože účet i AWS se mezitím posunuly. Seznam bez priorit je stejně neužitečný jako žádný; a report, který se neobnovuje, je jen momentka minulosti.
Jak to řešíme: každý nález dostane závažnost i náročnost a seřadí se podle poměru přínos/námaha (reverzibilní kroky první) — a auditor se spouští opakovaně, takže místo momentky máte živý stav, který se mezi běhy sám doplňuje (více níže).
Nápad: řízený read-only audit, který se učí
Problémy mají jednu příčinu: stav účtu nikdo nevidí celý, najednou a průběžně. Řešením je řízený auditor — a platí pro něj to, co pro každé naše řešení: audit navrhuje; rozhodujete vy.
Jak proběhne jeden běh
- Jen pro čtení — audit běží přes přístup read-only (SSO role bez práva zápisu). Nic se nevytváří, nemění, nemaže. Do obsahu dat (např. objektů v S3) se nevstupuje — čtou se jen metadata a konfigurace.
- Sken napříč všemi regiony — nejen ten, kde běží provoz. „Zapomenuté" zdroje v nepoužívaných regionech jsou oblíbený úkryt útočníků právě proto, že tam nikdo nekouká.
- Deterministická analýza — nálezy počítá obyčejný, opakovatelný kód vůči CIS AWS Benchmark a AWS Foundational Security Best Practices. Stejná data → stejný výsledek, pokaždé. Žádný model „na místě neimprovizuje".
- Závažnost a pořadí podle dopadu — každý nález dostane závažnost (🔴 kritické → 🔵 cleanup) a odhad námahy. Řazení je podle přínos/námaha, ne podle abecedy.
- Plán, ne seznam chyb — u každého nálezu konkrétní kroky (copy-paste příkazy), ✅ jak ověřit a ⚠️ rollback. Reverzibilní kroky první.
- Lokální dashboard — výstup je lokální HTML dashboard, nic se nepublikuje do cloudu. Přijatá rizika se v něm editují přímo (ADR, viz níže).
- Re-sken a měření — při dalším běhu se porovná delta (nové/vyřešené) a klesající počet nálezů je měřitelné KPI. A právě mezi běhy se děje to nejzajímavější ⤵
Není to fotka — auditor se mezi běhy sám učí
Tohle je jádro. Auditor není zamrzlá sada kontrol: sám si rozšiřuje pravidla. V naplánované kadenci (např. jednou za 30 dní, bez jakéhokoli cronu) se spustí objevovací agent, který si přes aktuální oficiální dokumentaci AWS najde nové best practices relevantní pro váš účet a zkusí je proměnit na nové kontroly. Ale — a v tom je celý vtip — nic si jen tak nepřidá.
AI píše data, ne kód
Klíčové rozhodnutí, na kterém stojí všechno ostatní: učící agent nikdy nepíše kód do jádra auditu. Píše jen pravidlo jako data (deklarativní zápis: „v tomto souboru se podívej na toto pole, musí mít tuto hodnotu"). Měření zůstává tentýž deterministický, otestovaný kód.
Tím je „mozek" (objev nové best practice) oddělen od „měřidla" (vyhodnocení). Audit zůstává opakovatelný a testovatelný, i když ho rozšiřuje AI. To je rozdíl mezi „auditem s AI" (znepokojivé) a auditorem, který si každé pravidlo nejdřív dokáže (důvěryhodné).
Každé nové pravidlo se nejdřív otestuje
Nové pravidlo přijde na svět se dvěma testovacími vzorky — jedním, který musí selhat, a jedním, který musí projít. Než se pravidlo připustí, spustí se test-brána: špatný vzorek musí opravdu spadnout, dobrý musí projít, a celá testovací sada musí zůstat zelená. Teprve pak smí pravidlo dovnitř. Při posledním běhu byla sada 17/17.
Raději nic než nesprávné pravidlo
Agent adversariálně prověřuje sám sebe — u každého kandidáta se ptá: říká to dokumentace opravdu? sedí kontrola na tvar našich dat? nemůže způsobit falešný „PASS"? Pokud cokoli z toho selže, kandidát letí pryč.
V jednom reálném učícím běhu agent zvážil 4 kandidáty a všechny 4 disciplinovaně zamítl se správnými důvody:
- kontrolu, kterou už pokrývá existující CIS pravidlo (žádný přínos),
- kontrolu, která by na prázdném seznamu vrátila falešné „vyhověl" (false-pass),
- kontrolu splývající s chybou sběru (false-positive),
- kontrolu nad nedůvěryhodným surovým vstupem.
Výsledek toho běhu: 0 přidaných pravidel, 0 šumu — a to je správné chování. Auditor, který raději nepřidá nic, než by přidal nespolehlivé pravidlo, je auditor, kterému se dá věřit.
Brány, které platí i bez člověka
I když kandidát obstojí, musí projít třemi bránami: povinná citace autoritativní AWS dokumentace (bez zdroje = zamítnuto), add-only (nikdy potichu nezměkčí existující pravidlo ani závažnost) a zmíněná test-brána. Každé pravidlo si tak nese proveniencí — zdroj, doc URL, datum.
Co nejde bezpečně zautomatizovat → návrh pro člověka
Někdy je reálná mezera, kterou agent neumí bezpečně přidat sám (kontrola je mimo deklarativní zápis nebo je třeba dosbírat nová data). Tehdy nic necommitne — napíše návrh pro člověka. Přesně to se jednou stalo: agent objevil, že skenování zranitelností pro kontejnerové image a Lambdu je vypnuté, ačkoli je účet používá — ale kontrola se nevešla do deklarativního zápisu. Napsal návrh; člověk dosbíral chybějící data; a tatáž kontrola pak prošla týmiž bránami a od té doby se měří automaticky.
★ Tohle je jediná část, co zůstává člověku: agent navrhne → člověk rozšíří sběr → pravidlo projde strojovými bránami → audit ho od té doby měří deterministicky.
Co spustí nový pohled
Auditor se nekouká znovu „jen protože to říká kalendář". Nový pohled spouštějí dvě reálné změny:
- Přibyla služba ve vašem účtu. Auditor si sám zjistí, jaké služby účet reálně používá, a porovná je s tím, co už kontroluje. Když začnete používat něco nového — třeba Cognito nebo EKS — označí to jako nepokrytou službu a při nejbližším učícím běhu k ní dohledá best practices a navrhne kontrolu.
- AWS samo něco změnilo. Auditor sleduje AWS „What's New" a Security Bulletins (RSS, přes ověřené TLS), filtruje je na vaše služby + bezpečnostní klíčová slova a bere jen to, co je nové od minula. Tím se „revize jednou za měsíc" mění na něco se změnilo → podívej se na to hned. V baseline běhu to z ~170 položek vytáhlo desítky relevantních — včetně čerstvých CVE ve službách, které účet reálně používá (např. HTTP/2 zranitelnost ve WAF, CVE v containerd pro ECS).
Rozhodnutí, která si systém pamatuje (ADR)
Ne každý nález je chyba k opravě — některé jsou vědomě přijatá rizika. Aby je auditor přestal alarmovat, ale nezapomněl na ně, mají svůj záznam: ADR (Architecture/Accepted Decision Record). Zapíšete rozhodnutí — co přijímáte, proč, kdo to schválil, jaké je kompenzační opatření a dokdy to platí — přímo v dashboardu. Auditor to od té doby neukazuje jako poplach… ale po uplynutí termínu revize se nález sám vynoří k opětovnému posouzení.
Díky tomu má systém tři čisté vrstvy důvěry:
| Vrstva | Kdo ji drží | Příklad |
|---|---|---|
| Deterministické měření | opakovatelný kód | root MFA, šifrování, otevřené porty, flow logy… |
| Úsudek o závažnosti | laditelná politika | „veřejný bucket s daty = kritické" |
| Override (ADR) | člověk, s termínem | „toto riziko vědomě přijímáme do Q4" |
Proč read-only — a proč se tomu dá věřit
Audit nic v účtu nemění. To není omezení, to je vlastnost: dostanete úplný obraz rizika, aniž byste cokoli riskli. Příkazy na nápravu spouštíte vy (nebo my společně, s admin přístupem) až když rozumíte dopadu — a děláme to reverzibilně nejdřív (klíč se nejdřív deaktivuje, maže se až po ověření, že nic nespadlo).
Je to tatáž zásada jako u všech našich řešení: systém připraví práci; rozhodne a spustí člověk. U bezpečnosti to platí dvojnásob — nikdo nechce „automatickou nápravu", co o půlnoci odřízne SSH na produkci. Proto i samotné učení smí jen přidávat kontroly, nikdy nic vypnout.
Co audit typicky najde
Z reálného auditu (anonymizované) — vzory, které se opakují téměř v každém účtu, co dlouho nikdo neprošel:
| Nález | Závažnost | Typická náprava |
|---|---|---|
| Root účet bez MFA | 🔴 Kritické | Zapnout MFA (FIDO2) / centralizovaný root přístup |
| Výchozí security group otevírá SSH a Docker API do internetu (~120 rozhraní) | 🟠 Vysoké | Odstranit 0.0.0.0/0, přejít na dedikované SG + SSM |
| 100 % disků i snapshotů nešifrovaných | 🟠 Vysoké | EBS encryption by default + migrace stávajících |
| Detekce hrozeb (GuardDuty) vypnutá ve všech regionech | 🟠 Vysoké | Zapnout org-wide přes delegated admin |
| Statické přístupové klíče bez rotace (18 z 23 starších než rok) | 🟠 Vysoké | Rotace ≤ 90 dní; nahradit rolemi / OIDC |
| Veřejně čitelný S3 bucket + chybí account-level Block Public Access | 🟠 Vysoké | Zapnout account BPA |
| 100+ kritických zranitelností s dostupnou opravou | 🟠 Vysoké | Zavést Patch Manager cyklus |
| Skenování zranitelností pro kontejnery/Lambdu vypnuté | 🟡 Střední | Zapnout enhanced scanning (nález z učení) |
A stejně důležité: audit má být vyvážený. Součástí výstupu je i to, co je nastaveno dobře (centrální CloudTrail s validací logů, uzamčené buckety, silné TLS politiky, service účty s nejmenšími oprávněními) — abyste to při nápravě nerozbili.
Co měříme
Bezpečnost se dá měřit — a bez měření se „zlepšení" nedá dokázat:
| Co měříme | Proč na tom záleží |
|---|---|
| Otevřené kritické nálezy s dostupnou opravou | Reálné, hned zneužitelné riziko — číslo, které má klesat |
| % šifrovaných disků a snapshotů | Přímá expozice dat (a GDPR) |
| Pokrytí detekcí (GuardDuty / Inspector / flow logy) | Zda byste incident vůbec zachytili |
| Věk přístupových klíčů | Čím starší klíč, tím vyšší šance úniku |
| Nepokryté služby v účtu | Kde audit ještě nevidí — vstup pro další učení |
| Nová pravidla / relevantní AWS změny za období | Že auditor roste s vaším účtem i s AWS |
Pro koho to dává smysl
Dává to smysl pro jakoukoli firmu na AWS, jejíž účet už nějakou dobu nikdo systematicky neprošel — zvlášť pokud:
- účet rychle rostl a bezpečnostní postupy nestíhaly,
- běží na více účtech / přes Control Tower a chybí centrální přehled,
- zpracovává osobní nebo regulovaná data (GDPR, zákazníci, zdravotnictví, energetika),
- nemá dedikovaný security tým, který by to průběžně kontroloval,
- chce průběžný obraz rizika — takový, co se neobnovuje jednou za rok, ale roste s účtem.
Audit nic sám nemění. Projde účet jen pro čtení, najde a doloží nálezy, seřadí je podle dopadu, mezi běhy si sám rozšiřuje pravidla (a každé si nejdřív dokáže) a předá vám živý plán nápravy — místo PDF, které zastará v den dodání.
Chcete vědět, jak na tom je váš účet? Získejte bezplatnou diagnostiku — uděláme read-only sken vašeho AWS účtu a ukážeme vám top nálezy, jejich závažnost a prioritizovaný plán nápravy. Nic neměníme, nic neriskujete. Nezávazně.