Přeskočit obsah

Přehled zabezpečení

Bezpečnostní architektura MazeVault a strategie obrany do hloubky

Verze dokumentu: 1.0.0
Poslední aktualizace: 2026-10-28

1. Bezpečnostní architektura

MazeVault implementuje bezpečnostní strategii obrany do hloubky s více ochrannými vrstvami:

graph TB
    subgraph L1["Vrstva 1: Síť"]
        FW["🛡️ Firewall / NSG"]
        TLS["🔒 Vynucení TLS 1.2+"]
        WAF["🌐 Web Application Firewall"]
    end

    subgraph L2["Vrstva 2: Aplikace"]
        RL["⏱️ Omezení počtu požadavků"]
        CORS["🎯 Validace CORS"]
        CSRF["🛡️ Ochrana CSRF"]
        Input["✅ Validace vstupů"]
    end

    subgraph L3["Vrstva 3: Autentizace"]
        MFA["🔐 Vícefaktorové ověření"]
        SSO["🆔 SSO / SAML / OIDC"]
        SRP["🤝 Protokol SRP (API)"]
        JWT["🎫 Serverové relace / JWT"]
    end

    subgraph L4["Vrstva 4: Autorizace"]
        RBAC["👥 Přístup na základě rolí"]
        Project["📁 Izolace projektů"]
        Perm["🔑 Granulární oprávnění"]
    end

    subgraph L5["Vrstva 5: Data"]
        AES["🔐 Šifrování AES-256-GCM"]
        ZK["👁️‍🗨️ Šifrování na straně klienta (data v2)"]
        HSM["🏦 Ochrana klíčů HSM"]
        Audit["📝 Auditní logování"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    classDef network fill:#F5F5F5,stroke:#9E9E9E,stroke-width:2px,color:#424242
    classDef app fill:#EBF5FB,stroke:#2196F3,stroke-width:2px,color:#1565C0
    classDef auth fill:#FFF8E1,stroke:#FF9800,stroke-width:2px,color:#E65100
    classDef authz fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px,color:#2E7D32
    classDef data fill:#E8EAF6,stroke:#3F51B5,stroke-width:2px,color:#283593

    class FW,TLS,WAF network
    class RL,CORS,CSRF,Input app
    class MFA,SSO,SRP,JWT auth
    class RBAC,Project,Perm authz
    class AES,ZK,HSM,Audit data

2. Bezpečnostní principy

Princip Implementace
Zero Trust Veškerá komunikace je autentizována a šifrována; žádná implicitní důvěra mezi komponentami
Šifrování na straně klienta Názvy a hodnoty tajemství dat v2 lze šifrovat v prohlížeči klíčem odvozeným z lokálního hesla; zatím nejde o zero-knowledge (viz Šifrování)
Nejmenší oprávnění RBAC s granulárními oprávněními; uživatelé mají přístup pouze k tomu, co jejich role umožňuje
Obrana do hloubky Pět bezpečnostních vrstev — síť, aplikace, autentizace, autorizace, data
Bezpečné ve výchozím nastavení Všechny bezpečnostní funkce jsou ve výchozím stavu zapnuty; opt-out namísto opt-in
Auditování všeho Každý přístup k datům a jejich úprava jsou zaznamenány s plným kontextem uživatele

3. Zabezpečení přenosu

Konfigurace TLS

Parametr Hodnota
Minimální verze TLS 1.2
Preferovaná verze TLS 1.3
Validace certifikátu Povinná v produkci
HSTS Zapnuto (max-age=31536000, includeSubDomains)
Certificate Pinning Podporováno pro komunikaci agent-server

Bezpečnostní hlavičky

Každá odpověď webového rozhraní (stránky, statické soubory, runtime konfigurace) obsahuje následující bezpečnostní hlavičky:

Hlavička Hodnota
X-Content-Type-Options nosniff
X-Frame-Options SAMEORIGIN
Strict-Transport-Security max-age=31536000; includeSubDomains (nastavuje webová aplikace)
Referrer-Policy strict-origin-when-cross-origin
Permissions-Policy Zakazuje kameru, mikrofon, geolokaci, platby a USB; schránka zůstává dostupná
Cross-Origin-Opener-Policy same-origin
Cross-Origin-Resource-Policy same-origin
Content-Security-Policy Vynucovaná, sestavená pro každou odpověď; inline skripty aplikace jsou v script-src povoleny hashem sha256-
Cross-Origin-Embedder-Policy require-corp (vynucováno)

Hlavičky pocházejí ze samotné webové aplikace, takže jsou stejné za edge v Compose i za ingressem v Kubernetes; edge žádné nepřidává. Stránky /swagger servíruje API server a aplikační CSP nenesou. Statické soubory se poskytují jen pro vlastní origin, bez Access-Control-Allow-Origin. Požadavek na neexistující soubor vrací 404 místo stránky aplikace.

Odpovědi API mají Cache-Control: no-store, no-cache, must-revalidate a X-Content-Type-Options: nosniff; vlastní cache politiku nastavují jen veřejné zdroje jako CRL. API navíc uplatňuje izolaci zdrojů podle Fetch Metadata: požadavek prohlížeče z jiného webu odmítne s 403, pokud nejde o navigaci na nejvyšší úrovni (SSO callbacky, odkazy), POST se SAML assertion nebo o origin uvedený v CORS_ALLOWED_ORIGINS. Agenti, gatewaye, klienti SCEP/ACME/OCSP a CLI hlavičky Fetch Metadata neposílají, takže se jich to netýká.

4. Zabezpečení aplikace

Omezení frekvence požadavků (Rate Limiting)

Kategorie endpointu Limit Časové okno
Autentizace 10 požadavků 1 minuta
API (autentizované) 100 požadavků 1 minuta
OCSP 1000 požadavků 1 minuta
Health checks Neomezeno —

Validace vstupů

  • Všechny API vstupy jsou validovány proti JSON schématům
  • Prevence SQL injection prostřednictvím parametrizovaných dotazů
  • Prevence XSS prostřednictvím kódování výstupů a Content Security Policy
  • Prevence path traversal prostřednictvím sanitizace vstupů
  • Limity velikosti těla požadavku vynucené na úrovni vstupu

Politika CORS

  • Striktní povolení původu (whitelist) — žádné zástupné znaky v produkci
  • Režim credentials vyžaduje explicitní specifikaci původu
  • Cachování preflight požadavků pro výkon

Ochrana serveru webového rozhraní (BFF)

  • Prohlížeč má jen cookie __Host-session (Secure, HttpOnly, SameSite=Strict); skriptům není vystaven žádný token
  • Každý požadavek měnící stav musí nést Origin shodný s nastavenou adresou webového rozhraní, jinak 403
  • Předávají se jen cesty /api/v1/ a /api/v2/; trasy přihlášení a tokenů nejsou přes obecnou proxy dostupné a zakódovaná lomítka a dot segmenty se odmítají
  • Server ověřuje TLS certifikát backendu a kontrolu nikdy nevypíná
  • Těla požadavků, tokeny ani query stringy se nelogují

Ochrana proti CSRF

  • Webové rozhraní: kontrola origin a cookie relace se SameSite=Strict (viz výše)
  • Klienti API: vzor double-submit cookie
  • SameSite=Lax na CSRF a refresh token cookies
  • Ověřování vlastních hlaviček pro API požadavky

5. Souhrn zabezpečení dat

Kategorie dat Šifrování v klidu Šifrování při přenosu Řízení přístupu
Tajné hodnoty (Secrets) AES-256-GCM TLS 1.2+ RBAC + Projekt
Privátní klíče AES-256-GCM + HSM TLS 1.2+ RBAC + Projekt
Certifikáty Na úrovni databáze TLS 1.2+ RBAC + Projekt
Přihlašovací údaje uživatelů bcrypt/Argon2 hash TLS 1.2+ Vlastní + Admin
Tokeny relací U relací webu se ukládá jen hash TLS 1.2+ (Secure cookie) Vlastní
Auditní záznamy Na úrovni databáze TLS 1.2+ Pouze admin

6. Řízení zranitelností

Praxe Frekvence Popis
Skenování závislostí Průběžně Automatizované skenování všech závislostí na známé CVE
Skenování kontejnerů Při každém buildu Skenování Docker obrazů pomocí Trivy
Penetrační testování Ročně Bezpečnostní posouzení třetí stranou
Revize kódu Při každé změně Povinná revize pro všechny bezpečnostně relevantní změny
Bezpečnostní záplaty Dle potřeby Cílové vydání Poskytovatelem: kritické do 48 hodin, vysoká závažnost do 7 dnů (závazné lhůty viz SLA)

Související