Základní registry byly spuštěny 1. července a podle nejnovějšího vyjádření Ministerstva vnitra (zřejmě i v reakci na předchozí článek zde na Lupě) jsou prý jednotlivé základní registry naplněny všemi referenčními daty, stejně jako má být zcela naplněna a plně funkční i Matice rolí a oprávnění. Jelikož jde o hodně důležitá a citlivá data, podívejme se podrobněji na jejich zabezpečení.
Přesněji: podívejme se na to, co o bezpečnosti a bezpečnostních aspektech říkají veřejně dostupné materiály, zveřejněné samotným resortem vnitra, resp. Správou základních registrů. Což není to samé jako skutečně používaná bezpečnostní opatření, která mohou jít různě nad rámec toho, co je kde popisováno a zveřejněno. Ale stejně tak mohou jít i „pod“ tento rámec.
Certifikát musíte přijmout…
Začít musím věcí, která mne praštila do očí nejvíce. A to už podruhé. Poprvé v roce 2009, v souvislosti se spuštěním datových schránek, když se jejich server prezentoval uživatelům pomocí certifikátu, o jehož důvěryhodnosti jejich browsery neměly žádné informace. Česká pošta tehdy radila něco zcela nesprávného, co naznačovalo, že o problematice bezpečnosti nemá ani tušení:
Při pokusu o přihlášení do systému ISDS se může objevit varování, upozorňující na problém s bezpečnostním certifikátem stránky. Toto je způsobeno nepřítomností certifikátu ve standardní instalaci MS Windows či jiných operačních systémů. Upozornění je nutno ignorovat; vstup na stránku je zcela bezpečný, neboť používaný certifikát je vydán kvalifikovanou českou certifikační autoritou. Volbou přidání certifikátů k důvěryhodným certifikátům či pokračováním na stránku ISDS nevzniká žádné bezpečnostní riziko.
Jen pro upřesnění: problém je v tom, že tímto způsobem můžete udělit svou důvěru i podvrženému certifikátu. Správný postup vede přes instalaci certifikátů certifikačních autorit, které ale musíte získat dostatečně důvěryhodným způsobem – abyste měli jistotu, že jde skutečně o ty pravé certifikáty, a ne o nějaké podvržené.
A jak že je stejný problém řešen dnes, po třech letech, v kontextu základních registrů? Podívejte se sami, na následující ukázku z dokumentu „Doporučené postupy a nastavení internetového prohlížeče pro práci v aplikaci AIS RPP“ v jeho třetí verzi:
Certifikát je nutné přijmout, jinak nebude web považován za bezpečný. V případě, že certifikát odmítnete, pak se aplikace vůbec nespustí a automaticky ukončí.
Nejde přitom o žádný „izolovaný úlet“ toho, kdo předmětný dokument psal. Stejný návod totiž najdeme i na dalších místech. Například v nápovědě k editačnímu agendovému informačnímu systému Registru práv a povinností (který používají ti, kteří mají editovat obsah tohoto základního registru):
Při spuštění aplikace se mi zobrazí okno s dotazem, zda chci přijmout certifikát. Může se jednat o nebezpečný web? Mám certifikát přijmout?
Certifikát aplikace potvrzuje její totožnost. Certifikát je nutné přijmout, jinak nebude web považován za bezpečný. V případě, že certifikát odmítnete, pak se aplikace vůbec nespustí a automaticky ukončí.
Pokud chcete, aby se okno s výzvou při dalším spuštění aplikace již dále nezobrazovalo, pak je nutné si certifikát přidat mezi důvěryhodné servery.
K jakým důsledkům může vést to, když dáte na podobná doporučení a „odkliknete“ nějaký podvržený certifikát, názorně předvedla (jako varování) ještě v listopadu 2009 společnost 4Safety, zabývající se bezpečností: uživatele datových schránek nechala přesměrovat na podvodnou stránku, která ale byla díky „odkliknutému“ podvrženému certifikátu považována za důvěryhodnou. Pak už bylo hračkou získat přihlašovací údaje uživatele a následně vstoupit místo něj do jeho datové schránky. Podrobněji viz můj tehdejší článek, či tisková zpráva 4Safety.
Zde by se jednalo o přihlašovací údaje osoby, která má právo editovat obsah Registru práv a povinností, skrze příslušný agendový informační systém (RPP-AIS). K tomu je vhodné dodat, že takovéto osobě může stačit k přihlášení i jen jméno a heslo, a nemusí (byť může) využívat ještě certifikát nebo jednorázový přihlašovací kód.
Takže i zde by k získání přístupu útočníkovi stačilo pouze odposlechnout jméno a heslo, stejně jako v případě datových schránek.
Napojení AIS
Pojďme nyní k obecnějšímu pohledu na celou soustavu základních registrů a k tomu, jak komunikují se svým okolím. Přestavujme si je, v souladu s následujícím obrázkem, jako „černou skříňku“, uvnitř které jsou samotné čtyři základní registry a převodník ORG, jakoby „obalené“ informačním systémem základních registrů (ISZR). Vnitřek nechme stranou (protože není zvenku přístupný) a zaměřme se na vnější rozhraní ISZR (též: EGON rozhraní), přes které jsou na celou soustavu základní registrů napojovány jednotlivé agendové informační systémy (AISy) ve veřejné správě. Co všechno se dá o tomto rozhraní a jeho fungování zjistit?
První zajímavá věc je to, že původně mělo toto rozhraní „ústit“ pouze do KIVSu (Komunikační infrastruktury veřejné správy), jako určitého privátního prostředí, sloužícího pouze potřebám veřejné správy. Jinými slovy: pokud se nějaký agendový informační systém chtěl napojit na základní registry, musel být sám připojen do KIVSu. Takto to požadovala první verze dokumentu „Podmínky pro připojení agendových informačních systémů do ISZR“ z poloviny loňského roku.
Jenže s KIVSem se to vyvinulo „všelijak“, a tak další verze téhož dokumentu již připouští i napojení agendových informačních systémů na vnější rozhraní ISZR (EGON rozhraní) prostřednictvím veřejného Internetu. Zpočátku se sice objevují zmínky o nutnosti použití technologie IPSEC, kvůli zabezpečení, ale později už se připouští zabezpečení jen pomocí SSL, v kombinaci s pevnou IP adresou na straně AIS a použitím demilitarizované zóny (DMZ1) na straně ISZR.
Další požadavky na zabezpečení sítě na straně jednotlivých AIS (včetně požadavků na směrování, fungování DNS atd.) se objevují až ve verzi 1.4 dokumentu „Bezpečnostní požadavky na AIS pro připojení k produkčnímu prostředí Základních registrů“ (ve verzi 1.3 ještě uvedeny nebyly), ale mají pouze charakter doporučení:
SZR doporučuje, aby OVM realizoval i následující opatření:
3. Zajistit bezpečné síťové prostředí pro provoz AIS.
Bezpečné síťové prostředí pro provoz AIS by mělo zahrnovat bezpečný DNS, bezpečnou konfiguraci routingu, bezpečnost bran, proxy serverů a podobných zařízení.
Domnívám se, že když už se jedná o připojování z veřejného Internetu, mělo by jít spíše o samozřejmost a povinnost, než o něco pouze doporučeného.
SSL mezi AIS a ISZR
Konkrétní způsob komunikace mezi ISZR a jednotlivými AIS je detailněji popsán v dokumentu „Bezpečnostní požadavky na AIS pro připojení k produkčnímu prostředí Základních registrů“. Zde jsou uvedeny minimální požadavky na sadu přípustných parametrů (Cipher Suite) pro SSL spojení: SSLv3 nebo TLS, alespoň 128bitové symetrické šifrovací klíče, hashovací funkce SHA1 nebo funkce ze skupiny SHA2. To na dnešní dobu už nejsou úplně nejpřísnější požadavky, ale důvodem je zřejmě reálná podpora různě silného zabezpečení v jednotlivých AISech.
Zajímavá je také autentizace obou stran při SSL spojení: AIS musí být vybaven certifikátem, který mu vystaví certifikační autorita Správy základních registrů (CA SZR). Jak se ale lze dozvědět v dokumentu „Postup pro vytvoření žádosti o digitální certifikát pro ověřovací a produkční prostředí Základních registrů“, na straně ISZR se jeho předmět (CN) vůbec nekontroluje:
Při navazování spojení mezi ISZR a AIS se certifikát může použít jednak jako klientský (spojení navazuje AIS) a za druhé jako serverový (spojení navazuje ISZR při odpovědi na asynchronní dotaz v aktivním režimu). V certifikátu je v položce Použití klíče (key usage) hodnota: "Server Authentication“ + „Client Authentication“.
ISZR ani při jednom směru navazování komunikace s AIS identifikaci systému (Common Name) v certifikátu v současné době nekontroluje.
(…)
Aplikace ISZR hodnoty položek v certifikátu v současné době nekontroluje. Pro navázání spojení je rozhodující sériové číslo certifikátu, to, že certifikát byl vydán Certifikační autoritou SZR a je platný.
Možná to nebude až tak dočasné, protože ten samý dokument říká, že certifikát je možné použít jak z KIVSu, tak i z Internetu, a o žádné dočasnosti už nemluví:
AIS může stejný certifikát používat při komunikaci s ISZR přes KIVS i přes Internet. Důvodem je opět to, že ISZR jméno serveru v certifikátu nekontroluje.
Stejný dokument dokonce naznačuje, že by jeden a tentýž certifikát (a jemu odpovídající soukromý klíč) mohl být použit na více počítačích, na kterých běží stejný agendový informační systém:
Certifikát a privátní klíč nainstalujte na všechny počítače, které budou komunikovat s ISZR. Musí to být počítače, které jsou součástí AIS a splňují všechny bezpečnostní požadavky pro provoz AIS.
Ještě explicitněji to pak říká i dokument s názvem „Certifikáty a jejich použití“:
Správce AISu zajistí instalaci certifikátu na všechny servery AISu, které komunikují s ISZR. Jeden AIS a tedy i jeho certifikát může být nainstalován na více serverech a na jednom serveru může být více AISů a tedy i více certifikátů různých AISů. Podstatné je, aby správci všech AISů (tj. OVM) zajistili splnění požadovaných podmínek pro provoz AISů a aby AIS při každém volání eGON služby použil správný certifikát.
Možnost, případně nutnost použít stejný certifikát na více počítačích současně není příliš standardní. Navíc vylučuje umístění odpovídajícího soukromého klíče v nějakém bezpečnějším zařízení, ze kterého jej nelze exportovat. Což zvyšuje riziko případného zneužití, stejně jako samotná možnost „opakovaného využití“ téhož serverového certifikátu na různých serverech (které očividně ani nemusí být součástí nějakého clusteru).
Certifikační politika CA SZR
Fungování certifikační autority Správy základních registrů (CA SZR), která jednotlivých AISům vydává jejich serverové certifikáty, se pochopitelně musí řídit konkrétními pravidly, která najdete v příslušné certifikační politice. Jen pro přesnost je třeba dodat, že nejde o kvalifikovanou certifikační autoritu, protože nevydává kvalifikované certifikáty (ale jen certifikáty komerční). Proto se také na CA SZR a její certifikáty nevztahují požadavky, které zákon klade na kvalifikované certifikáty a kvalifikované autority. A tím pádem CA SZR není (a nemůže být) akreditovaná.
S tím vším souvisí i způsob zveřejnění certifikátů samotné CA SZR, které nemusí být ověřovány dozorovým orgánem (Ministerstvem vnitra ČR), tak jako certifikáty akreditovaných autorit. A tak se CA SZR ani nesnaží nějak zvýšit důvěru v jejich pravost. Najdete je „jen tak“ na webu Správy základních registrů (zde), bez jakýchkoli otisků či jiných údajů ohledně možnosti ověřit jejich pravost.
Zajímavý je také obsah certifikační politiky CA SZR. Z něj například vyplývá, že o vydání nového certifikátu lze požádat skrze datovou schránku. A stejně tak můžete požádat o zneplatnění již vydaného certifikátu: stačí poslat žádost z datové schránky a nemusíte již dokládat nic dalšího, znát jakékoli heslo apod. Což je hezká nahrávka na případné „šprýmy“: kdokoli, kdo má právo odeslat datovou zprávu z datové schránky příslušného subjektu, může takto dosáhnout zneplatnění certifikátu a tím zcela zablokovat komunikaci mezi příslušným AIS a základními registry (resp. ISZR).
Certifikační politika se ani nesnaží rozlišovat, zda žádost o zneplatnění poslala osoba oprávněná (což bývá statutární zástupce příslušného subjektu), nebo pouze osoba pověřená, což může být například nějaká sekretářka, která by správně měla mít explicitní pověření k danému úkonu. Případně administrátor, nebo obecně kdokoli, kdo může pracovat se spisovou službou a přes ni odesílat datové zprávy. Celkově přitom jde o jeden z konkrétních důsledků (podle mého názoru velmi nesprávné) představy o tom, že jistota o datové schránce, ze které bylo něco odesláno, dává jistotu i o tom, kdo tak učinil.
Se zneplatňováním certifikátů souvisí i skutečnost, že CA SZR nepodporuje protokol OCSP (Online Certificate Status Protocol) a informace o zneplatnění (revokaci) zveřejňuje pouze dávkově, pomocí seznamů CRL (Certificate Revocation List). Tím je fakticky znemožněno ověření platnosti certifikátu (včetně stavu jeho revokace) v reálném čase, protože je nutné čekat na vydání nového a dostatečně „čerstvého“ CRL seznamu. A sama certifikační politika konstatuje, že takováto kontrola stavu revokace je nutná:
Spoléhající strana je povinna ověřit, zda certifikát nebyl zneplatněn. Tato kontrola může proběhnout i automaticky, pokud je technicky taková kontrola možná nebo proveditelná. V případě, že toto ověření neproběhne a spoléhající se strana implicitně certifikátu (a tím platnosti elektronického podpisu) důvěřuje, není certifikační autorita odpovědná za případnou vzniknuvší škodu.
Jakpak to asi bude konkrétně naplněno, při reálné komunikaci mezi ISZR a jednotlivými AISy? Bude se čekat na zveřejnění nového CRL seznamu, nebo nebude?
Závěrem
Závěrem si neodpustím obecnější konstatování: zabezpečení „vnějšího okolí“ základních registrů (přístup jednotlivých AISů k ISZR) snad bylo navrženo rozumně a bezpečně. Ale pak, nejspíše z ryze praktických důvodů, začalo docházet k ústupkům a kompromisům: připojení i přes veřejný Internet, místo jen přes KIVS, používání stejných certifikátů (a soukromých klíčů) na různých serverech, nekontrolování některých položek certifikátů, možnost přihlašování pomocí jmen a hesel (bez vynucování silnější autentizace, pomocí certifikátů či jednorázových kódů), a v neposlední řadě i zcela zcestné rady a doporučení ohledně „odklikávání“ neznámých certifikátů.
Je výsledek stále ještě dostatečně bezpečný, vzhledem k tomu, jaká data a jaké služby jsou ve hře?
Tímto článkem bych rád podnítil širší diskusi k zabezpečení základních registrů a celého jejich okolí. A snad i vytvořil určitý veřejný tlak na řešení těch problémů, které zde jsou a již „jsou vidět“, či se teprve projeví. Ze všeho nejdříve na nápravu onoho ostudného „odklikávacího“ doporučení. Když jsem na něj upozornil standardní cestou, přes technickou podpisu Správy základních registrů (již 2.7.2012, hned jak jsem na problém narazil), nic se nestalo.
Případnou inspiraci ohledně toho, jak řešit problém s instalací certifikátů, lze už najít i na informačním webu datových schránek, které se v mezidobí již stihly poučit.
ČLÁNKY DO MAILU