Audit nie je fotka — je to audítor, ktorý sa medzi behmi sám učí
Cloud sa nezakladá „nebezpečne" — nebezpečným sa stáva postupne. Pribudne inštancia, otvorí sa port „len na skúšku", vznikne bucket, nasadí sa služba pod dlho neobmieňaným kľúčom. Rok–dva a máte 130 serverov, tisícky snapshotov a nikto nevie povedať, či je root chránený, či sú disky šifrované a či by ste vôbec spozorovali, že sa niekto dostal dnu. Spravili sme read-only bezpečnostný audit AWS účtu jednej strednej firmy — cez rolu len na čítanie, bez jedinej zmeny v účte — a našli sme presne tento tichý dlh: root bez MFA, 100 % diskov aj snapshotov nešifrovaných, detekciu hrozieb vypnutú vo všetkých regiónoch.
Lenže audit ako jednorazový PDF report zastará v deň dodania — o týždeň pridáte službu, AWS vydá novú funkciu, vyjde nové CVE. Preto sme nepostavili report, ale audítora, ktorý žije ďalej: pri každom behu meria deterministicky to isté, medzi behmi si sám rozširuje sadu pravidiel — a každé nové pravidlo si najprv dokáže, kým mu uverí.
Problém: diery, ktoré nevidno — a audit, ktorý zostarne skôr, než ho dočítate
Bezpečnostný dlh v cloude nie je jeden veľký prešľap. Je to súčet drobností, ktoré sa nikdy nezišli na jednu obrazovku — a stav, ktorý sa mení rýchlejšie, než ho stíhate kontrolovať. Náklad sa koncentruje do troch problémov.
1. Konfigurácia sa časom rozíde a nikto ju nevidí celú
Kto to má: každá firma, ktorej AWS účet rástol rýchlejšie než jej bezpečnostné postupy — root sa používa „len výnimočne" (a nemá MFA), východisková security group má roky otvorený SSH a Docker API do internetu na stovke sieťových rozhraní naraz, a šifrovanie diskov sa nikdy nezaplo, takže je nešifrovaných 100 % zväzkov aj snapshotov.
Každá z týchto vecí je sama o sebe „len nastavenie". Spolu sú to otvorené dvere: jedno uhádnuté root heslo = strata celého účtu; jeden kompromitovaný host = laterálny pohyb cez otvorené Docker API na desiatky ďalších. A pri firme v EÚ je nešifrovanie zároveň GDPR riziko (čl. 32).
Ako to riešime: audit prejde službu po službe naprieč všetkými regiónmi a zíde všetky tieto nastavenia na jedno miesto — nie „pocit", ale zoznam s dôkazom pri každom náleze.
2. Bez detekcie a logov neviete, či ste už neboli napadnutí
Kto to má: prevádzka, kde je GuardDuty (detekcia hrozieb) vypnutý vo všetkých regiónoch, chýbajú VPC flow logy aj access logy z load balancerov. Servery bežia, appky fungujú — ale keby dnes niekto ťažil krypto na vašich inštanciách alebo exfiltroval dáta, nedozviete sa to.
Toto je najzákernejšia časť: absencia problému vyzerá rovnako ako bezpečie. Kým sa nič nestane, nikomu nechýba niečo, čo nikdy nevidel.
Ako to riešime: audit explicitne overí, čo všetko by ste dokázali zachytiť — detekciu, sieťové aj aplikačné logy, pokrytie skenovania zraniteľností — a kde je slepé miesto, pomenuje ho ako nález s konkrétnou nápravou.
3. Jednorazový sken je nezoradená kopa — a zastará v deň dodania
Kto to má: ktokoľvek, kto niekedy pustil skener a dostal späť 200 „kritických" riadkov bez poradia — a o mesiac je aj tak neaktuálny, lebo účet aj AWS sa medzitým zmenili. Zoznam bez priorít je rovnako neužitočný ako žiadny; a report, ktorý sa neobnovuje, je len momentka minulosti.
Ako to riešime: každý nález dostane závažnosť aj námahu a zoradí sa podľa pomeru prínos/námaha (reverzibilné kroky prvé) — a audítor sa spúšťa opakovane, takže namiesto momentky máte živý stav, ktorý sa medzi behmi sám dopĺňa (viac nižšie).
Nápad: riadený read-only audit, ktorý sa učí
Problémy majú jednu príčinu: stav účtu nikto nevidí celý, naraz a priebežne. Riešením je riadený audítor — a platí preň to, čo pre každé naše riešenie: audit navrhuje; rozhodujete vy.
Ako prebehne jeden beh
- Len na čítanie — audit beží cez prístup read-only (SSO rola bez práva zápisu). Nič sa nevytvára, nemení, nemaže. Do obsahu dát (napr. objektov v S3) sa nevstupuje — čítajú sa iba metadáta a konfigurácia.
- Sken naprieč všetkými regiónmi — nielen ten, kde beží prevádzka. „Zabudnuté" zdroje v nepoužívaných regiónoch sú obľúbený úkryt útočníkov práve preto, že tam nikto nepozerá.
- Deterministická analýza — nálezy počíta obyčajný, opakovateľný kód voči CIS AWS Benchmark a AWS Foundational Security Best Practices. Rovnaké dáta → rovnaký výsledok, zakaždým. Žiadny model „na mieste nehádže".
- Závažnosť a poradie podľa dopadu — každý nález dostane závažnosť (🔴 kritické → 🔵 cleanup) a odhad námahy. Zoradenie je podľa prínos/námaha, nie podľa abecedy.
- Plán, nie zoznam chýb — ku každému nálezu konkrétne kroky (copy-paste príkazy), ✅ ako overiť a ⚠️ rollback. Reverzibilné kroky prvé.
- Lokálny dashboard — výstup je lokálny HTML dashboard, nič sa nepublikuje do cloudu. Prijaté riziká sa v ňom editujú priamo (ADR, viď nižšie).
- Re-sken a meranie — pri ďalšom behu sa porovná delta (nové/vyriešené) a klesajúci počet nálezov je merateľné KPI. A práve medzi behmi sa deje to najzaujímavejšie ⤵
Nie je to fotka — audítor sa medzi behmi sám učí
Toto je jadro. Audítor nie je zamrznutá sada kontrol: sám si rozširuje pravidlá. V naplánovanej kadencii (napr. raz za 30 dní, bez akéhokoľvek cronu) sa spustí objavovací agent, ktorý si cez aktuálnu oficiálnu dokumentáciu AWS nájde nové best practices relevantné pre váš účet a skúsi ich premeniť na nové kontroly. Ale — a toto je celé — nič si len tak nepridá.
AI píše dáta, nie kód
Kľúčové rozhodnutie, na ktorom stojí všetko ostatné: učiaci agent nikdy nepíše kód do jadra auditu. Píše len pravidlo ako dáta (deklaratívny zápis: „v tomto súbore sa pozri na toto pole, musí mať túto hodnotu"). Meranie zostáva ten istý deterministický, otestovaný kód.
Tým je „mozog" (objav novej best practice) oddelený od „meradla" (vyhodnotenie). Audit ostáva opakovateľný a testovateľný, aj keď ho rozširuje AI. To je rozdiel medzi „audit s AI" (znepokojivé) a audítorom, ktorý si každé pravidlo najprv dokáže (dôveryhodné).
Každé nové pravidlo sa najprv otestuje
Nové pravidlo príde na svet s dvomi testovacími vzorkami — jednou, ktorá musí zlyhať, a jednou, ktorá musí prejsť. Kým sa pravidlo pripustí, spustí sa test-brána: zlá vzorka musí naozaj spadnúť, dobrá musí prejsť, a celá testovacia sada musí ostať zelená. Až potom smie pravidlo dnu. Pri poslednom behu bola sada 17/17.
Radšej nič ako nesprávne pravidlo
Agent adversariálne preveruje sám seba — pri každom kandidátovi sa pýta: hovorí to dokumentácia naozaj? sedí kontrola na tvar našich dát? nemôže spôsobiť falošný „PASS"? Ak čokoľvek z toho zlyhá, kandidát letí preč.
V jednom reálnom učiacom behu agent zvážil 4 kandidátov a všetkých 4 disciplinovane zamietol so správnymi dôvodmi:
- kontrolu, ktorú už pokrýva existujúce CIS pravidlo (žiadny prínos),
- kontrolu, ktorá by na prázdnom zozname vrátila falošný „vyhovel" (false-pass),
- kontrolu splývajúcu s chybou zberu (false-positive),
- kontrolu nad nedôveryhodným surovým vstupom.
Výsledok toho behu: 0 pridaných pravidiel, 0 šumu — a to je správne správanie. Auditor, ktorý radšej nepridá nič, než by pridal nespoľahlivé pravidlo, je auditor, ktorému sa dá veriť.
Brány, ktoré platia aj bez človeka
Aj keď kandidát obstojí, musí prejsť troma bránami: povinná citácia autoritatívnej AWS dokumentácie (bez zdroja = zamietnuté), add-only (nikdy potichu nezmäkčí existujúce pravidlo ani závažnosť) a spomínaná test-brána. Každé pravidlo si tak nesie provenienciu — zdroj, doc URL, dátum.
Čo sa nedá bezpečne automatizovať → návrh pre človeka
Niekedy je reálna medzera, ktorú agent nevie bezpečne pridať sám (kontrola je mimo deklaratívneho zápisu alebo treba dozbierať nové dáta). Vtedy nič necommitne — zapíše návrh pre človeka. Presne to sa raz stalo: agent objavil, že skenovanie zraniteľností pre kontajnerové image a Lambdu je vypnuté, hoci účet ich používa — ale kontrola sa nezmestila do deklaratívneho zápisu. Napísal návrh; človek dozbieral chýbajúce dáta; a tá istá kontrola potom prešla tými istými bránami a odvtedy sa meria automaticky.
★ Toto je jediná časť, čo ostáva človeku: agent navrhne → človek rozšíri zber → pravidlo prejde strojovými bránami → audit ho odvtedy meria deterministicky.
Čo spustí nový pohľad
Audítor sa nepozerá znova „len tak podľa kalendára". Nový pohľad spúšťajú dve reálne zmeny:
- Pribudla služba vo vašom účte. Audítor si sám zistí, aké služby účet reálne používa, a porovná ich s tým, čo už kontroluje. Keď začnete používať niečo nové — povedzme Cognito alebo EKS — označí to ako nepokrytú službu a pri najbližšom učiacom behu k nej dohľadá best practices a navrhne kontrolu.
- AWS samo niečo zmenilo. Audítor sleduje AWS „What's New" a Security Bulletins (RSS, cez overené TLS), filtruje ich na vaše služby + bezpečnostné kľúčové slová a berie len to, čo je nové od minula. Tým sa „revízia raz za mesiac" mení na niečo sa zmenilo → pozri sa na to hneď. V baseline behu to z ~170 položiek vytiahlo desiatky relevantných — vrátane čerstvých CVE v službách, ktoré účet reálne používa (napr. HTTP/2 zraniteľnosť vo WAF, CVE v containerd pre ECS).
Rozhodnutia, ktoré si systém pamätá (ADR)
Nie každý nález je chyba na opravu — niektoré sú vedome prijaté riziká. Aby audítor takéto veci prestal alarmovať, ale nezabudol na ne, majú svoj záznam: ADR (Architecture/Accepted Decision Record). Zapíšete rozhodnutie — čo prijímate, prečo, kto to schválil, aké je kompenzačné opatrenie a dokedy to platí — priamo v dashboarde. Audítor to odvtedy neukazuje ako poplach… ale po uplynutí termínu revízie sa nález sám vynorí na opätovné posúdenie.
Vďaka tomu má systém tri čisté vrstvy dôvery:
| Vrstva | Kto ju drží | Príklad |
|---|---|---|
| Deterministické meranie | opakovateľný kód | root MFA, šifrovanie, otvorené porty, flow logy… |
| Úsudok o závažnosti | laditeľná politika | „verejný bucket s dátami = kritické" |
| Override (ADR) | človek, s termínom | „toto riziko vedome prijímame do Q4" |
Prečo read-only — a prečo sa tomu dá veriť
Audit nič v účte nemení. To nie je obmedzenie, to je vlastnosť: dostanete úplný obraz rizika bez toho, aby ste čokoľvek riskli. Príkazy na nápravu spúšťate vy (alebo my spoločne, s admin prístupom) až keď rozumiete dopadu — a robíme to reverzibilne najprv (kľúč sa najprv deaktivuje, maže sa až po overení, že nič nespadlo).
Je to tá istá zásada ako pri všetkých našich riešeniach: systém pripraví prácu; rozhodne a spustí človek. Pri bezpečnosti to platí dvojnásobne — nikto nechce „automatickú nápravu", čo o polnoci odreže SSH na produkcii. Preto aj samotné učenie smie iba pridávať kontroly, nikdy nič vypnúť.
Čo audit typicky nájde
Z reálneho auditu (anonymizované) — vzory, ktoré sa opakujú takmer v každom účte, čo dlho nikto neprešiel:
| Nález | Závažnosť | Typická náprava |
|---|---|---|
| Root účet bez MFA | 🔴 Kritické | Zapnúť MFA (FIDO2) / centralizovaný root prístup |
| Východisková security group otvára SSH a Docker API do internetu (~120 rozhraní) | 🟠 Vysoké | Odstrániť 0.0.0.0/0, prejsť na dedikované SG + SSM |
| 100 % diskov aj snapshotov nešifrovaných | 🟠 Vysoké | EBS encryption by default + migrácia existujúcich |
| Detekcia hrozieb (GuardDuty) vypnutá vo všetkých regiónoch | 🟠 Vysoké | Zapnúť org-wide cez delegated admin |
| Statické prístupové kľúče bez rotácie (18 z 23 starších než rok) | 🟠 Vysoké | Rotácia ≤ 90 dní; nahradiť rolami / OIDC |
| Verejne čitateľný S3 bucket + chýba account-level Block Public Access | 🟠 Vysoké | Zapnúť account BPA |
| 100+ kritických zraniteľností s dostupnou opravou | 🟠 Vysoké | Zaviesť Patch Manager cyklus |
| Skenovanie zraniteľností pre kontajnery/Lambdu vypnuté | 🟡 Stredné | Zapnúť enhanced scanning (nález z učenia) |
A rovnako dôležité: audit má byť vyvážený. Súčasťou výstupu je aj to, čo je nastavené dobre (centrálny CloudTrail s validáciou logov, uzamknuté buckety, silné TLS politiky, service účty s najmenšími privilégiami) — aby ste to nerozbili pri náprave.
Čo meriame
Bezpečnosť sa dá merať — a bez merania sa „zlepšenie" nedá dokázať:
| Čo meriame | Prečo na tom záleží |
|---|---|
| Otvorené kritické nálezy s dostupnou opravou | Reálne, hneď zneužiteľné riziko — číslo, ktoré má klesať |
| % šifrovaných diskov a snapshotov | Priama expozícia dát (a GDPR) |
| Pokrytie detekciou (GuardDuty / Inspector / flow logy) | Či by ste incident vôbec zachytili |
| Vek prístupových kľúčov | Čím starší kľúč, tým vyššia šanca úniku |
| Nepokryté služby v účte | Kde audit ešte nevidí — vstup pre ďalšie učenie |
| Nové pravidlá / relevantné AWS zmeny za obdobie | Že audítor rastie s vaším účtom aj s AWS |
Pre koho to dáva zmysel
Dáva to zmysel pre akúkoľvek firmu na AWS, ktorej účet už nejaký čas nikto systematicky neprešiel — najmä ak:
- účet rýchlo rástol a bezpečnostné postupy nestíhali,
- beží na viacerých účtoch / cez Control Tower a chýba centrálny prehľad,
- spracúva osobné alebo regulované dáta (GDPR, zákazníci, zdravotníctvo, energetika),
- nemá dedikovaný security tím, ktorý by to priebežne kontroloval,
- chce priebežný obraz rizika, čo sa neobnovuje raz za rok, ale rastie spolu s účtom.
Audit nič sám nemení. Prejde účet len na čítanie, nájde a doloží nálezy, zoradí ich podľa dopadu, medzi behmi si sám rozširuje pravidlá (a každé si najprv dokáže) a odovzdá vám živý plán nápravy — namiesto PDF, ktoré zastará v deň dodania.
Chcete vedieť, ako na tom je váš účet? Získajte bezplatnú diagnostiku — spravíme read-only sken vášho AWS účtu a ukážeme vám top nálezy, ich závažnosť a prioritizovaný plán nápravy. Nič nemeníme, nič neriskujete. Nezáväzne.