Compliance a politiky

Sencai obsahuje vestavěný policy engine, který vyhodnocuje cloudové zdroje podle vámi definovaných pravidel. Porušení se promítají do compliance skóre a kontroly politik se spouští automaticky při každém provisioningu nebo aktualizaci cloudového zdroje.

Policy engine

Politiky jsou guardrail pravidla, která se vztahují na cloudové zdroje. Příklady:

„Všechny EC2 instance musí mít tag cost-center”
„Žádný S3 bucket nesmí být veřejně přístupný”
„VM v prostředí production musí běžet v EU regionu”

Politiky jsou definovány pomocí jednoduchého JSON DSL — nikoliv OPA/Rego ani Cedar. Výraz politiky je strom uzlů and / or s listovými podmínkami:

{
  "and": [
    { "field": "config.public_access", "op": "eq", "value": true },
    { "field": "config.region", "op": "neq", "value": "eu-central-1" }
  ]
}

Každý listový uzel má tvar:

{ "field": "config.public_access", "op": "eq", "value": true }

field — dot-path do payloadu zdroje odeslaného s požadavkem na provisioning/update (např. config.public_access)
op — jedno z eq, neq, contains, exists, not-exists, gt, lt
value — hodnota k porovnání (u exists / not-exists se vynechává)

Politiky vytváříte a spravujete na Cloud Instances → Policies (/gravity/policies). Tato stránka nabízí formulář pro název, závažnost, providera, typ zdroje a příznak aktivní politiky, plus textové pole pro samotný JSON DSL výraz — v současnosti neexistuje samostatný vizuální drag-and-drop builder; výraz se zapisuje přímo jako JSON.

Sencai dodává sadu vestavěných, platform-wide politik odpovídajících CIS (pouze pro čtení, uživatelé organizace je nemohou upravovat ani mazat) vedle vlastních politik, které si vytvoříte pro svou organizaci.

Způsoby vynucení

Každá politika má právě jednu hodnotu závažnosti, která zároveň slouží jako způsob vynucení — neexistuje samostatný krok „nastavit závažnost” oddělený od vynucení:

Závažnost	Chování
block	Splněná podmínka rovnou zamítne požadavek na provisioning/update — zdroj se nevytvoří ani nezmění a volající dostane chybu
warn	Požadavek projde, ale shoda se zaznamená jako varování v audit trail

Kdy se politiky vyhodnocují

Vyhodnocení politik je synchronní, nejde o periodický scan. Každý požadavek na provisioning nebo update odeslaný do cloud-connectoru se v okamžiku odeslání zkontroluje proti relevantním politikám (platform-wide + vlastní politiky organizace pro daného providera/typ zdroje):

Pokud shodu najde politika se závažností block, požadavek je okamžitě zamítnut a zdroj se nikdy nevytvoří/nezmění.
Pokud shodu najdou pouze politiky warn, požadavek projde a každá shoda se zaznamená do audit trail.
Pokud nedojde k žádné shodě, požadavek projde běžně.

Pro už provisionované zdroje neexistuje pevný interval opakovaného skenu vázaný na tento mechanismus — vyhodnocení probíhá v okamžiku požadavku.

Výraz politiky lze otestovat (dry-run) proti vzorovému payloadu zdroje ještě před uložením, abyste zjistili, co by odpovídalo.

Compliance skóre

Compliance skóre vaší organizace zobrazíte na Cloud Instances → Inventory → Compliance (/gravity/inventory/compliance).

Dashboard zobrazuje:

Celkové skóre organizace (0–100)
Rozpad podle cloud providera
Rozpad podle compliance frameworku (iso27001, nis2, soc2, gdpr)
Počet nálezů a počet kritických nálezů
Filtrovatelnou tabulku nálezů (podle závažnosti — block/warn — a podle providera), každý s postiženým zdrojem, politikou, která zapříčinila shodu, a mapovanými framework kontrolami

Skóre je prostá hodnota 0–100 spočítaná z toho, kolik vyhodnocených zdrojů splňuje aktivní politiky; neexistují oficiálně zdokumentovaná procentuální pásma (např. žádné pevné hranice typu „90–100 % = Compliant”) — berte číslo spíše jako relativní trendový ukazatel než jako certifikovaný stav compliance. Dashboard podporuje export nálezů do CSV a tiskovou verzi reportu přes print-to-PDF prohlížeče.

Tag governance

Tag compliance sledujete na Cloud Instances → Inventory → Tags (/gravity/inventory/tags). Stránka zobrazuje cloudové zdroje s chybějícími povinnými tagy, a to na základě nepotvrzených drift-event záznamů (stejný mechanismus detekce driftu používaný jinde v inventáři, filtrovaný na nálezy vztahující se k tagům), nikoliv na základě samostatné obrazovky pro konfiguraci povinných tagů.

Z této stránky můžete vybrat jeden nebo více postižených zdrojů a odeslat chybějící hodnoty tagů hromadně; požadavek se odešle asynchronně do cloud-connectoru, který tagy aplikuje na příslušné cloudové zdroje a nahlásí výsledek zpět. Neexistuje samostatná úroveň autonomie specifická pro nápravu tagů nad rámec standardních požadavků na write přístup u vašich BYOC přihlašovacích údajů.

Samotná pravidla pro tagy jsou vyjádřena stejným JSON DSL cloud-policy jako výše — neexistuje samostatný content-type pro povinné tagy.

Klasifikace dat

Každý zdroj lze označit úrovní citlivosti (Public, Internal, Confidential, Restricted) přes tag data-classification. Vlastní politiky mohou toto pole referencovat (např. { "field": "tags.data-classification", "op": "eq", "value": "restricted" }) a vynucovat kontroly jako šifrování v klidu nebo blokování veřejných endpointů pro citlivé zdroje — jde o běžné výrazy politik, nikoliv o samostatný vestavěný klasifikační engine.

Doporučení right-sizing

Sencai monitoruje využití zdrojů a doporučuje optimalizace nákladů:

Nedostatečně využívané instance — využití CPU/RAM pod 20 % po dobu 14+ dní
Předimenzované databáze — nízký objem dotazů relativně k velikosti instance
Nečinné load balancery — žádný provoz po dobu 7+ dní
Nepřipojené úložiště — volumes nepřipojené k žádné instanci

Doporučení zobrazíte v FinOps → Right-sizing. Každé zobrazuje:

Aktuální zdroj a náklady
Navrhovanou alternativu a odhadované měsíční úspory
Jedno kliknutí „Přijmout doporučení” (při dostatečné úrovni autonomie se provede automaticky)

NIS2 důkazy

Sledování NIS2 gapů je v současnosti interní/admin nástroj, zatím ne self-service funkce dostupná uživatelům organizace. Záznamy NIS2 gap (nis2-gap) jsou obyčejné CRUD položky — požadavek, článek, annex, stav, cílové datum, vlastník a odkazy na důkazy — spravované platform administrátory; za těmito daty dnes nestojí žádný pipeline pro generování PDF/JSON reportu.

Pokud jako uživatel organizace potřebujete důkazy vztahující se k NIS2, bližší dostupnou funkcí je dashboard compliance skóre popsaný výše (Cloud Instances → Inventory → Compliance), který obsahuje rozpad skóre pro framework nis2 a exportovatelné nálezy. Pro formální NIS2 gap-analýzu a reporting kontaktujte svého Sencai account manažera — tento workflow zatím není dostupný v zákaznickém UI.

Upozornění na porušení politiky

Při shodě s politikou:

Pokud je politika block, odpovídající požadavek na provisioning/update selže a volající chybu uvidí okamžitě.
Pokud je politika warn, požadavek uspěje a shoda se zaznamená do audit trail.
Shody se promítnou do compliance skóre a tabulky nálezů na Cloud Instances → Inventory → Compliance.

Řešení problémů

Q: Politika blokuje legitimní zdroj

A: Přejděte na Cloud Instances → Policies, najděte vlastní politiku a buď upravte její závažnost z block na warn, nebo upravte JSON DSL výraz tak, aby podmínka pro daný zdroj už neplatila. Vestavěné platform-wide politiky uživatelé organizace upravovat nemohou.

Q: Compliance skóre je 0 pro nový typ zdroje

A: Pro tuto kombinaci typu zdroje a providera se aktuálně neuplatňuje žádná politika. Přidejte vlastní politiku na Cloud Instances → Policies, která ji pokrývá.

Q: Tag governance zobrazuje porušení pro zdroje, které nemohu upravit

A: Importované zdroje pouze pro čtení nemusí mít write oprávnění. Zkontrolujte BYOC přihlašovací údaje — pro úspěšnou hromadnou nápravu tagů na cloudovém provideru je potřeba write přístup.