„Důvěřuj, ale prověřuj" byl dlouho mantrou enterprise security. V roce 2026 to nestačí. Moderní bankovní infrastruktura pracuje s principem never trust, always verify — každý request, každý uživatel, každý microservice se autentizuje a autorizuje, bez ohledu na to, odkud přichází. Takhle jsme to implementovali pro klienta z českého bankovního sektoru.
Tradiční model síťové bezpečnosti stojí na jednoduchém předpokladu: všechno uvnitř firemní sítě je důvěryhodné, všechno venku je hrozba. Firewall na hranici, VPN pro vzdálený přístup, hotovo. Tento model měl smysl v době, kdy aplikace běžely na fyzických serverech v jednom datovém centru.
Dnes bankovní infrastruktura vypadá jinak. Microservices distribuované přes on-premise a cloud. Třetí strany napojené přes API podle PSD2. Zaměstnanci pracující odkudkoliv. Kontejnery, které žijí minuty. V tomto prostředí perimetr neexistuje — nebo přesněji, perimetr je všude.
Když nás oslovila česká bankovní instituce s požadavkem na redesign bezpečnostní architektury, hlavní driver nebyla jen bezpečnost. Byl to DORA (Digital Operational Resilience Act), který od ledna 2025 vyžaduje, aby finanční instituce prokázaly odolnost celého ICT stacku — včetně third-party providerů. A klasický perimetrový model tohle prostě nedokáže.
Zero Trust není produkt, který si koupíte. Je to architektonický přístup, který prostupuje celým stackem. Implementovali jsme ho na pěti principech.
Každý přístup se ověřuje na základě identity, zařízení, lokace, chování a dalšího kontextu. Žádné implicitní důvěry.
Každý uživatel a služba má jen minimální oprávnění nutná pro svou funkci. Just-in-time a just-enough access.
Návrh architektury předpokládá, že útočník je už uvnitř. Minimalizujeme blast radius segmentací a monitoringem.
Síť je rozdělena na izolované segmenty. Laterální pohyb útočníka je omezený, i když pronikne do jednoho segmentu.
Pátý princip, který se často opomíjí: continuous monitoring and validation. Autentizace není jednorázová událost. Session se průběžně revaliduje na základě risk score, které se mění v reálném čase podle chování uživatele a stavu jeho zařízení.
Jádrem celé implementace je přechod z network-based access control na identity-based access control. Není podstatné, z jaké sítě přicházíte. Podstatné je, kdo jste, jaké máte oprávnění a jaký je kontext vašeho požadavku.
┌─────────────────────────────────────────────────────────────────┐
│ ZERO TRUST ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────────┐ ┌───────────────────────┐ │
│ │ Client │───▶│ API Gateway │───▶│ Policy Decision │ │
│ │ (Browser, │ │ + WAF │ │ Point (PDP) │ │
│ │ Mobile) │ │ │ │ ┌─────────────────┐ │ │
│ └──────────┘ └──────┬───────┘ │ │ Identity Provider│ │ │
│ │ │ │ Risk Engine │ │ │
│ │ │ │ Policy Store │ │ │
│ ▼ │ └─────────────────┘ │ │
│ ┌──────────────────┐ └───────────┬───────────┘ │
│ │ SERVICE MESH │ │ │
│ │ (Istio/Envoy) │◀───────────────┘ │
│ │ │ │
│ │ ┌────┐ ┌────┐ │ ┌──────────────────────┐ │
│ │ │ Svc│◀▶│ Svc│ │───▶│ SIEM / SOC │ │
│ │ │ A │ │ B │ │ │ ┌────────────────┐ │ │
│ │ └──┬─┘ └──┬─┘ │ │ │ Log Aggregation│ │ │
│ │ │mTLS │mTLS│ │ │ Threat Detection│ │ │
│ │ ┌──┴─┐ ┌──┴─┐ │ │ │ Incident Resp. │ │ │
│ │ │ Svc│◀▶│ Svc│ │ │ └────────────────┘ │ │
│ │ │ C │ │ D │ │ └──────────────────────┘ │
│ │ └────┘ └────┘ │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Nasadili jsme centrální Identity Provider (IdP) postavený na OpenID Connect, který slouží jako single source of truth pro identitu uživatelů i služeb. Každý request nese JWT token s claims, které zahrnují nejen identitu, ale i kontext: typ zařízení, geo-lokaci, risk score a scope oprávnění.
Autorizační rozhodnutí provádí Policy Decision Point (PDP) v reálném čase. Políčky jsou definované v OPA (Open Policy Agent) a verze-kontrolované v Gitu — každá změna prochází code review a audit trailem. Žádná policy se nemění ad-hoc.
# OPA Policy — příklad autorizace pro platební API
package banking.payments
default allow = false
allow {
input.method == "POST"
input.path == "/api/v1/payments"
input.user.role == "payment_officer"
input.user.mfa_verified == true
input.risk_score < 0.7
input.amount <= input.user.approval_limit
}
# High-value transakce vyžadují dual approval
allow {
input.method == "POST"
input.path == "/api/v1/payments"
input.amount > input.user.approval_limit
input.dual_approval == true
input.approver.role == "senior_officer"
}
Veškerá komunikace mezi microservices probíhá přes mTLS (mutual TLS). Každý service má vlastní X.509 certifikát vydaný interní CA, rotovaný automaticky každých 24 hodin. Není to volitelné — service bez platného certifikátu jednoduše nemůže komunikovat s ostatními.
Jako service mesh jsme zvolili Istio s Envoy proxy. Envoy sidecar na každém podu zajišťuje mTLS terminaci, autorizaci na úrovni L7, rate limiting a telemetrii — transparentně, bez změn v aplikačním kódu. Pro vývojáře se nic nemění: volají HTTP endpointy jako dříve. Ale pod kapotou je každý call šifrovaný, autentizovaný a autorizovaný.
┌─────────────────────────────────────────────────┐
│ mTLS COMMUNICATION FLOW │
├─────────────────────────────────────────────────┤
│ │
│ Pod A Pod B │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ App │ │ App │ │
│ │ Container │──HTTP──▶ │ Container │ │
│ └──────┬──────┘ │ └──────▲───────┘ │
│ │ │ │ │
│ ┌──────▼──────┐ │ ┌──────┴───────┐ │
│ │ Envoy │──mTLS──┼─────▶│ Envoy │ │
│ │ Sidecar │ │ │ Sidecar │ │
│ │ │ │ │ │ │
│ │ ✓ Cert A │ │ │ ✓ Cert B │ │
│ │ ✓ AuthZ │ │ │ ✓ AuthZ │ │
│ │ ✓ Telemetry │ │ │ ✓ Telemetry │ │
│ └─────────────┘ │ └──────────────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ Istio │ │
│ │ Control │ │
│ │ Plane │ │
│ │ (istiod) │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Micro-segmentation je srdce Zero Trust. Místo plochých sítí, kde každý server vidí každý jiný, vytváříme izolované bezpečnostní zóny s explicitními pravidly pro komunikaci mezi nimi.
V bankovním prostředí jsme definovali tyto segmenty:
Pravidla mezi zónami jsou definována jako Kubernetes NetworkPolicies a Istio AuthorizationPolicies. Default je deny all — pokud pravidlo explicitně nepovoluje komunikaci, neprochází. Každé pravidlo má vlastníka, expiraci a musí projít security review.
Bezpečnostní architektura v bankovnictví nemůže existovat ve vakuu — musí odpovídat regulatorním požadavkům. Dvě klíčové regulace, které formovaly naši implementaci:
PSD2 vyžaduje Strong Customer Authentication (SCA) pro elektronické platby. To znamená minimálně dva ze tří faktorů: něco, co uživatel ví (heslo), má (telefon) a je (biometrie). V Zero Trust architektuře je SCA přirozeným rozšířením — multi-factor authentication není výjimka, je to standard pro každý přístup k citlivým datům.
Pro Open Banking API (přístup třetích stran k účetním datům) jsme implementovali OAuth 2.0 s PKCE a dynamic client registration. Každý TPP má vlastní identitu v IdP, vlastní rate limits a jeho přístup je omezený na scope definovaný consent uživatele. Vše logované, vše auditovatelné.
DORA přinesla od ledna 2025 povinnost ICT risk management frameworku, testování digitální odolnosti a reportingu incidentů. Zero Trust architektura na DORA odpovídá přirozeně:
Zero Trust bez monitoringu je jen marketing. Celá architektura generuje obrovské množství telemetrie — a ta musí být centrálně zpracovaná, korelovaná a vyhodnocovaná.
Implementovali jsme SIEM (Security Information and Event Management) stack postavený na Elastic Security s vlastními detection rules. Klíčové datové zdroje:
┌─────────────────────────────────────────────────────┐
│ MONITORING & SIEM STACK │
├─────────────────────────────────────────────────────┤
│ │
│ Data Sources Processing Output │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Envoy │────────▶│ │ │ Dashboards│ │
│ │ Logs │ │ Elastic │───▶│ (Kibana) │ │
│ ├──────────┤ │ Security │ ├──────────┤ │
│ │ IdP │────────▶│ │ │ Alerts │ │
│ │ Events │ │ ┌──────┐ │───▶│ (PagerD.)│ │
│ ├──────────┤ │ │Rules │ │ ├──────────┤ │
│ │ OPA │────────▶│ │ML │ │ │ SOAR │ │
│ │ Decisions│ │ │UEBA │ │───▶│ Playbooks│ │
│ ├──────────┤ │ └──────┘ │ ├──────────┤ │
│ │ K8s │────────▶│ │ │ Compliance│ │
│ │ Audit │ │ │───▶│ Reports │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────┘
Klíčovým prvkem je UEBA (User and Entity Behavior Analytics). ML modely vytvářejí baseline chování pro každého uživatele a službu. Anomálie — neobvyklý čas přístupu, atypický objem dat, přístup k neobvyklým resourcem — automaticky zvýší risk score a mohou triggerovat step-up autentizaci nebo blokaci.
Průměrný MTTD (Mean Time To Detect) jsme díky automatizaci snížili z hodin na minuty. MTTR (Mean Time To Respond) z hodin na desítky minut díky SOAR playbookům, které automatizují prvních 80 % incident response procesu.
Zero Trust implementace v bankovnictví není projekt na tři měsíce. Je to transformační program, který vyžaduje systematický přístup. Náš postup má čtyři fáze.
Důležitý aspekt: nepřepalujeme. Zero Trust se neimplementuje přes noc big-bang přístupem. Každá fáze přináší měřitelné zlepšení bezpečnostní posture a funguje i samostatně. Klient vidí hodnotu od prvního sprintu — ne až po roce práce.
Náš tým kombinuje specialisty na network security, identity management, Kubernetes a service mesh, a compliance. Nejsme jen konzultanti, kteří dodají PowerPoint — stavíme infrastrukturu, píšeme policies a provozujeme monitoring. A pak to předáme internímu týmu klienta se vším, co potřebují: dokumentací, runbooky a hands-on trainingem.
Zero Trust není stav, kterého jednou dosáhnete a máte hotovo. Je to kontinuální proces — neustálé vyhodnocování hrozeb, zpřísňování politik, testování odolnosti a adaptace na nové regulace.
Banky, které k tomu přistoupí jako k technologickému projektu s jasným koncem, budou zklamané. Ty, které Zero Trust adoptují jako operační filozofii — kde každý tým rozumí principům, každý deploy prochází security review a každý incident je příležitost ke zlepšení — budou mít infrastrukturu, která ustojí jak regulátory, tak skutečné útočníky.