BankID zajišťuje soukromému sektoru ověření uživatelů v online prostředí, a to prostřednictvím jejich bankovní identity. Tuto digitální identitu lze využít pro přihlašování do zákaznických portálů, ověření osobních údajů, k automatizovanému vyplnění formulářů a v brzké době i pro podepisování dokumentů zaručeným elektronickým podpisem. Uživatelů, kteří se tímto způsobem mohou identifikovat, bude v České republice přes šest milionů a počet transakcí může být v budoucnu až několik milionů denně. Technologicky se proto bude jednat o systém podobný karetním nebo bankovním řešením, kde je třeba dbát maximální důraz na bezpečnost, robustnost, škálovatelnost a dostupnost. Ale je možné takové řešení postavit za méně než rok?

Nejprve bylo potřeba vyřešit následující hlavní otázky:

• Na čem řešení stavět, když chceme maximálně využívat open-source?
• Kde provozovat infrastrukturu? Public cloud, private cloud nebo on-premise?
• Jaké máme možnosti škálování a jak zajistit další růst po infrastrukturní a aplikační stránce?

V dnešní záplavě názorů, různých virtualizací a rozmanitosti toolchainů, pomocí kterých lze provozovat aplikace, je značně náročné se orientovat a je nutné si na začátku stanovit alespoň základní omezení, která vymezí rámec finálnímu technologickému řešení.

My máme na technickou infrastrukturu následující hlavní omezení:

• infrastruktura musí podporovat 24x7 provoz s dostupností alespoň 99,9 %
• všechny infrastrukturní prvky a komponenty musí být redundantní, a to i mezi lokalitami
• bezodstávkový provoz aplikací
• velmi vysoká bezpečnost provozu a přístupu
• provoz infrastruktury musí být v rámci EU

Naším záměrem dále bylo outsourcovat samotný provoz infrastruktury a některých platformních služeb, proto jsme poptali partnery se zkušenostmi s provozem obdobné infrastruktury.

Podvozek (ne)dělá auto

Infrastruktura a navázané bezpečnostní služby jsou sice základem pro řešení, ale provozovat v dnešní době aplikace čistě na bare metal nebo vMware virtualizaci nedává smysl kvůli pracnosti, ani z pohledu bezpečnosti nebo spolehlivosti takového provozu. Takže jak vybrat správný podvozek? Opět platí, že na výběr je velké množství platforem, na kterých lze provozovat aplikace a které podporují různé frameworky. Není ale vždy zcela jednoduché definovat kritéria, na kterých pak bude možné „poskládat“ správný platformní stack. Měli jsme ovšem zjednodušenou situaci. Naším cílem je co možná nejvíce využívat open-source řešení. A to ne z důvodu ceny, ale kvůli možnosti rychlejších funkčních a bezpečnostních updatů, lepší dostupnosti nových funkcionalit a lepší dostupnosti IT zdrojů, které jsou schopni takový stack spravovat.

Naše aplikace byly vyvíjeny v Java a Kotlinu a jsou optimalizované pro nasazení v kontejnerech, tudíž pro samotný provoz byla platforma Kubernetes (K8s) v podstatě jediná rozumná a dostupná volba. Zvolili jsme čisté K8s bez OpenShift nadstavby. OpenShift nám kromě supportu nic nepřináší, naopak jistou flexibilitu bere. Navíc licenční model RedHatu není právě příznivý pro provoz OpenShiftu na virtualizovaných serverech. Pro DB je zvolen open-source standart PostgreSQL. Logovaní je rovněž realizováno centralizovaně v ELK stacku.

Potřebovali jsme vyřešit integraci na API GW a WAF prvek, který umožní nastavení bezpečnostních politik a řízení provozu. To vše v kombinaci s velmi dynamickým prostředím K8s, které dává flexibilitu pro škálování, nasazení a řízení workloadu. Nejlépe nám tyto funkcionality zajistilo řešení od společnosti BigIP – F5. Dále bylo nutné zajistit všechny požadavky na bezpečnost systému, to znamená i vysoké nároky na kryptografické operace. S ohledem na plánovaný další rozvoj služeb jsme volili nejvyšší řadu komerčních HSM od firmy Thales, které mají potřebné certifikace.

Být nebo nebýt cloud

Když máte dnes možnost stavět řešení na zelené louce, tak s velkou pravděpodobností zvolíte public cloud. Pokud nemáte specifické požadavky na bezpečnost, je to nejrychlejší a nejlevnější cesta. Ale když se staví bezpečnostní řešení, které má splňovat vysoké, ne-li nejvyšší nároky na bezpečnost provozu, je potřeba udělat i jinou rozvahu, než čas vs. peníze.

Nejdřív jsme vyřadili z úvah klasické on-premise řešení, jelikož naše prostředí není tak rozsáhlé nebo komplexní, abychom byli schopni absorbovat lidi, kteří by se starali výhradně o infrastrukturu jako takovou. Tudíž hlavní rozhodování bylo, zda jít cestou public cloudu (Azure, AWS, …) nebo privátního cloudu v rámci lokálních datacenter. Každé řešení má svoje výhody i nevýhody. V public cloudu můžete prakticky neomezeně škálovat výkon, využívat integrace s dalšími službami a šetřit náklady za provoz samostatných aplikací. Ale ne všechno je tak růžové. Velkým problémem pro nás byla maturita firewallových řešení, F5 řešení a HSM modulů. Tyto prvky mají proti svým hardwarovým protějškům stále omezení a nelze se ani spoléhat na optimalizace, které můžou být a jsou na míru šité pro konkrétní hardware.

U public cloudu je také nutné řešit umístění datacentra (pro eIDAS certifikaci je podmínka EU), sítě a konektivitu. Nejbližší region podporující dedikované hardwarové HSM moduly jsou Nord Europe od Microsoftu. V ČR je sice provozován edge uzel Azure, ale to nevyhovuje požadavkům na redundanci. Navíc dedikovaná linka jde minimálně přes celé Německo, musí být duální a nelze pominout ani cenu za rozumnou šířku pásma. Tím bylo potvrzeno, že public cloud je pro naše potřeby nevhodný. Softwarová omezení a obtížnější konektivita se vzdáleným datovým centrem převážily jeho výhody.

Privátní cloud v rámci datových center naopak může mít některé kritické prvky jako například hardwarové komponenty, specificky firewally, F5tky a HSM moduly. Také lze jednodušeji vyhovět požadavkům na síťový provoz. Lze sjednat dedikovaný provoz ze zabezpečených sítí v kanceláři do datacenter, segmentaci a řízení síťového provozu a dále jednodušeji řešit VPN připojení do datacentra. Nevýhody jsou zjevné - nižší flexibilita škálování výkonu a storage. Ale existují i nevýhody, které nejsou až tak patrné, jako např. vazby na proprietární technologie, které mohou zásadně ovlivnit možnosti hybridního provozu mezi privátním a public cloudem, exit strategii nebo vendor lock na konkrétní řešení. Na tato omezení je třeba myslet při uzavírání smlouvy s poskytovatelem privátního cloudu.

Takže vybráno máme, parametry a omezení známe, ale kdo nám to postaví a bude provozovat? Následovalo výběrové řízení mezi společnostmi, které jsou schopny naplnit naše požadavky a mají z obdobnými řešeními zkušenosti. Po zhodnocení všech kritérii jsme vybrali jako partnera T-Mobile a.s., protože nejlépe vyhověl ve všech parametrech a po tři čtvrtě roce spolupráce jsme s naší volbou spokojeni.

Jak to rozhýbat?

Máme podvozek, umístili jsme karoserii do privátního cloudu, takže teď přichází na řadu aplikace. Zajistit jejich správné umístění na platformy, postavit prostředí pro vývojáře a pro testery a správně nastavit workflow požadavků od vývoje až po produkci. To vše ideálně bezpečným a automatizovaným způsobem, jinak by celé snažení o automatizovanou platformu pro provoz vlastně nedávalo smysl.

Protože jsme se rozhodli mít řešení mimo public internet, nechtěli jsme otevírat prostředí ani cloudovým službám. První volbou z necloudových služeb byl GitLab – což je komplexní řešení pro CI/CD pipelines od Gitu až po Operations. Po vyzkoušení jsme u něj zůstali, nevyužíváme všechny jeho možnosti (projektový management a agilní řízení), pro nás je to primárně nástroj pro vývojáře a operations. Proces je designovaný jako hard-core DevOps. Vývojáři a testeři můžou na vývojové a testovací prostředí nasazovat dle svých potřeb, na Stage se nasazuje v pravidelném cyklu a slouží pro akceptaci změn Product Ownerem. Produkce je pak klasicky obsluhována lidmi v Operations.

Volbou vhodných nástrojů a postupů v kombinaci s masivní redundancí jednotlivých nasazení jsme aktuálně schopni nasazovat bez odstávek a dopadu na klienty. Navíc release na produkci probíhá většinou v pracovních hodinách. Výjimkou jsou samozřejmě breaking changes, kterých je ovšem naprosté minimum a týkají se spíše infrastruktury než aplikací. A i ty jsme obvykle schopni provést bez odstávky. Našim ultimátním cílem je provést kompletní nasazení prostředí za 15 minut, aniž by cokoliv postřehl klient nebo koncový uživatel.

Jak dostat pasažéry do auta?

Pro nalodění jsou klíčové autentizační služby a standardizované rozhraní pro připojení firem. U autentizačních služeb jsou aktuálně nejrozšířenější protokoly OpenID Connect a SAML2. Hledali jsme ovšem protokol, který nám v budoucnu umožní rozšířit naše služby více, než jen o předávání dat. I s tímto výhledem jsme volili OpenID Connect Protocol s eKYC rozšířením. A pro zavedení služby podepisování dokumentů zaručeným elektronickým podpisem (služba SIGN) postupně přidáme podporu FAPI standardu.

Vzhledem k technologické rozmanitosti na straně poskytovatelů bankovní identity se striktně držíme standardu a API specifikace tak, aby nebyly potřeba žádné specifické úpravy pro jednotlivé banky. Technicky tudíž umíme do řešení zapojit jakéhokoliv providera, který podporuje OIDC protokol, během několika dnů. Procesně je to samozřejmě složitější. Základní podmínkou pro připojení poskytovatele bankovní identity je, aby daná banka již měla registrované prostředky v NIA a měla požadovanou sadu osobních údajů dle AML zákona.

Obdobně jednoduchá je technická integrace pro poskytovatele služeb, tedy firmy využívající bankovní identitu pro své služby. Většina knihoven, které jsme otestovali, funguje out-of-box a je nutná pouze správná konfigurace parametrů. Mnohem větší výzvou pro firmy je úprava klientských procesů na plně digitální proces tak, aby výhody Bank ID využily maximálně, ať už z pohledu zjednodušení interních procesů nebo uživatelského komfortu.

Umožňujeme také testovací jízdy - poskytujeme pro vývojáře a klienty administrativní rozhraní Developerského Portálu, kde si mohou zájemci online zřídit účet a využívat pro testovací účely náš Sandbox. V případě, že mají následně zájem se stát klientem, mohou většinu úkonů vyřídit rovněž v portálu. Stejně tak je možné přes portál oslovit naši podporu, pokud byla nalezena chyba nebo potřebuje pomoci. Nastavení DevOpsu a vývoj aplikací pro nás zajišťuje softwarové studio Applifting, které má zkušenosti jak s agilním vývojem aplikací, tak u svých zákazníků pomáhá s DevOpsem a jeho nastavením.

Závěrem

Máme za sebou šest měsíců provozu, za tu dobu jsme připojili pět bank a téměř 40 firem. Při plném provozu jsme provedli 20 releasů bez odstávky, dopadů na klienty a incidentů a jsme připraveni na nasazování nových produktů, změny poplatkové logiky i skokový růst transakcí systému. Když se ohlédneme na začátek, asi bychom nevěřili, že se vše podaří vybudovat, aniž bychom museli slevit z našich očekávání. Máme flexibilní, zcela bezpečný a zároveň maximálně dostupný systém, který jsme navíc schopni plynule upgradovat v prakticky bezodstávkovém režimu. A to vše za méně než 12 měsíců, na což jsme opravdu hrdí.

Výběr modelu provozování infrastruktury, ať již nové nebo migrace stávající, by se neměl řídit aktuálními trendy a názory sociálních sítí. Jakkoliv public cloud, jeho principy a přednosti se mohou na první pohled zdát jako velmi lákavé a přitažlivé, nemusí to být vždy optimální volba stejně jako v našem případě. To ovšem nemusí nutně znamenat rezignaci na cloudové principy jako takové. Je k tomu zapotřebí jen mít vhodné partnery, kteří mají prokazatelné zkušenosti a umí podat pomocnou ruku, pokud sami tápete. Klíčové je precizní definování systémových a provozních požadavků a samozřejmě i výběr spolupracujících partnerů.

Filip Hladký Autor článku je IT architektem projektu BankID a odborníkem na solution architekturu v oblasti identity managementu. Podílel se také na projektech smartbankingu, smart klíče a kyberbezpečnosti.