Minimální standard bezpečného webu: Povinné požadavky pro provoz v roce 2026

Úvod: Hranice mezi bezpečným a nebezpečným systémem Tento dokument stanovuje minimální požadavky, které musí splňovat webový systém, aby mohl být považován za bezpečný v kontextu roku 2026. Standard je určen pro firmy provozující webové aplikace, SaaS systémy a poskytovatele digitálních služeb. Nejedná se o doporučení, ale o technické minimum. Nesplnění kteréhokoliv bodu znamená, že systém představuje neřízené riziko a nelze jej deklarovat jako bezpečný. ## **1. Architektonické požadavky (MUST)** Základním pilířem je **strukturální oddělení důvěry**. - **Izolace vrstev:** Systém MUSÍ striktně oddělovat frontend, > aplikační logiku a datovou vrstvu. Tyto vrstvy nesmí sdílet přímé > přístupy ani běžet v jednom nekontrolovaném monolitickém > prostředí. - **Bariéra databáze:** Databáze NESMÍ být dostupná z veřejné sítě. > Frontend NESMÍ komunikovat přímo s databází; veškerý tok dat MUSÍ > probíhat přes řízenou aplikační mezivrstvu (API Gateway), která > provádí hloubkovou inspekci požadavků. - **Multi-tenant izolace:** Systém MUSÍ zajistit, aby data > jednotlivých klientů byla od sebe fyzicky nebo logicky izolována > tak, aby chyba v jednom uživatelském kontextu neumožnila přístup k > datům jiného klienta. ## **2. Řízení přístupů a identit (MUST)** - **Silná autentizace:** Systém MUSÍ implementovat vícefaktorové > ověřování (MFA) pro všechny administrativní i citlivé klientské > operace. - **Princip minimálních oprávnění:** Každý proces, uživatel i > mikroslužba MUSÍ mít přidělena pouze ta oprávnění, která jsou > nezbytně nutná pro daný úkol (Principle of Least Privilege). - **Nulová důvěra ve vstupy:** Žádný vstup z vnějšího prostředí > (formulář, API volání, upload) NESMÍ být považován za důvěryhodný. > Každý datový paket MUSÍ projít validací na úrovni typu, délky a > obsahu. ## **3. Ochrana dat a auditovatelnost (MUST)** - **Šifrování jako standard:** Všechna data MUSÍ být šifrována při > přenosu (TLS 1.3+) i při uložení (AES-256 nebo ekvivalent). - **Nepřetržitý audit:** Systém MUSÍ zaznamenávat každý přístup k > citlivým datům a každou změnu konfigurace. Logy MUSÍ být ukládány > mimo dosah samotné aplikace, aby byla zajištěna jejich integrita i > po případné kompromitaci systému. - **Testovaná kontinuita:** Zálohování MUSÍ probíhat automatizovaně a > pravidelně. Obnova dat MUSÍ být testována minimálně jednou za > kvartál. Záloha bez verifikace obnovy se považuje za neexistující. ## **4. Supply Chain a kontrola závislostí (MUST)** - **Software Bill of Materials (SBOM):** Poskytovatel MUSÍ udržovat > aktuální seznam všech použitých knihoven a jejich verzí. - **Integrita zdrojů:** Externí zdroje (JS, CSS z CDN) MUSÍ být > zajištěny pomocí *Subresource Integrity (SRI)*. Systém MUSÍ > implementovat striktní *Content Security Policy (CSP)* pro > zamezení XSS a neautorizovaného načítání cizího kódu. ## **5. Klasifikace nesouladu a důsledky** V roce 2026 se nesoulad se standardem neřeší „domluvou", ale klasifikací rizika, která přímo ovlivňuje pojistitelnost a certifikaci subjektu. ---------------------------------------------------------------------------- **Úroveň **Definice nesouladu** **Důsledek** rizika** -------------- ----------------------------- ------------------------------- **Kritické** Přímý přístup z frontendu k **Systém je nezpůsobilý k datům, absence MFA, chybějící provozu.** Okamžitá ztráta šifrování. certifikace „Prověřený provoz". **Vysoké** Neauditovatelné přístupy k Povinnost nápravy do 14 dnů pod datům, chybějící testy obnovy hrozbou pozastavení záloh. certifikace. **Střední** Neřízený technický dluh, Povinný plán refaktoringu s zastaralé (ale funkční) termínem do 90 dnů. knihovny bez CVE. ---------------------------------------------------------------------------- ## **6. Zero Trust: Provozní paradigma (MUST)** Systém MUSÍ fungovat na principu **předpokládaného průniku**. To znamená, že bezpečnostní mechanismy jsou navrženy tak, aby minimalizovaly „blast radius" (dosah exploze). Pokud je kompromitována jedna komponenta (např. marketingový widget), architektura MUSÍ zabránit šíření útoku do datového jádra. ## **Závěr: Bezpečnost je splnění podmínek, nikoliv deklarace** Bezpečnost webu v roce 2026 není otázkou marketingu nebo vágních slibů v patičce webu. Je to binární stav: buď systém splňuje architektonické, provozní a procesní požadavky tohoto standardu, nebo je nebezpečný. Neexistuje „částečně bezpečný systém". Existuje pouze systém, který splňuje standard a je schopen to v rámci auditu prokázat, nebo systém, který standard ignoruje a vědomě tak hazarduje s daty uživatelů a stabilitou digitálního prostředí. **Standard 2026 je jedinou cestou k budování měřitelné digitální důvěry.** *Tento dokument tvoří závěrečnou část metodiky Asociace kyberbezpečnosti ČR pro certifikaci „Prověřený provoz".*