Hlavní navigace

Jak EET vidí ajťák aneb Draze zaplacená vražda uživatelské přívětivosti

25. 5. 2016
Doba čtení: 10 minut

Sdílet

 Autor: McIek / Shutterstock.com
MF se vydalo cestou, která je sice o hodně dražší než alternativy, zato je pro poplatníky méně pohodlná. V souvislosti s vraždou UX, kterou se chystá spáchat, je ale slovo pohodlí zcela nemístné.

Dne 24.5.2016 v 11:00 uspořádalo ministerstvo financí tiskovou konferenci, kde referovalo o stavu přípravy elektronické evidence tržeb (EET) – viz K #EET chceme i účtenkovou loterii, a to od března 2017, uvedlo ministerstvo. Dovolím si konkurovat politikům a zkusím se podívat na stav přípravy EET z hlediska ajťáka, který chvilku zblízka a chvilku zdáli sleduje přípravu EET od samého začátku – od zveřejnění záměru. 

Nejsem osobou nezaujatou. Zblízka jsem se s EET setkal při zpracování a obhajobě nabídky pro SPCSS na dodávku systému v průběhu roku 2015. Zblízka se s EET setkávám jako rodinná IT podpora několika malých živnostníků, na které EET dopadne. A zblízka jsem se s EET setkal i v rámci přípravy nabídky na řešení centrálního pokladního systému pro celkem heterogenní síť prodejních míst. Z dálky sleduji kroky finanční správy a ministerstva financí.

Krátce z historie

Ajťácká historie EET se začala psát se studií BDO, kde nezanedbatelná část byla věnována technologické části řešení. Studie byla hodnocena mnohokrát. Jediné, co bych rád připomněl, je jedna pasáž, kde je zmiňováno využití IBM DataPower jako vstupního zařízení pro příjem evidovaných tržeb.

Po prezentaci informací tehdy ještě neveřejné studie na začátku roku 2015 se zdálo, že se nic neděje. Na pozadí však proběhlo výběrové řízení na dodavatele technologií, které bylo nakonec odsunuto na slepou kolej, a na začátku roku 2016 byla za dodavatele centrální části EET zvolena firma IBM, a to formou JŘBU, kterým se daňový systém ADIS rozšíří o podporu EET.

Aktuální stav

Finanční správa v poslední době podnikla následující kroky: došlo ke zveřejnění technické specifikace rozhraní EET (11.5.2016) a téměř současně (12.5.2016) byla vypsána již dříve avizovaná veřejná soutěž na dodavatele služeb certifikační autority a zároveň také soutěž na rozšíření infrastruktury ADIS.

Výše jsou shrnuta fakta. V dalších odstavcích si dovolím zaznamenat směs faktů a svých osobních názorů.

Technická specifikace rozhraní

Jak již bylo dlouho dopředu avizováno, je technická specifikace založena na kombinaci protokolu standardních webových služeb (SOAP1.1) s využitím podmnožiny celkem komplexního standardu WS-Security. Pomocí SOAP/HTTPS jsou transportovány požadavky na zaevidování tržby a v rámci SOAP response je vrácen FIK. Uvnitř SOAP zprávy jsou v nejúspornějším možném tvaru (z hlediska XML) přenášeny údaje o tržbě a dodatečné bezpečnostní kódy. Při tvorbě zprávy se bude programátor muset poprat s tím, aby správně naformátoval vstupy pro výpočet BKP, které se počítá tak, že se zřetězí vybrané údaje z datové zprávy a aplikuje se na ně elektronický podpis klíčem odpovídajícím certifikátu poplatníka s využitím algoritmu RSA. Ve specifikaci je pro přesné určení certifikátu použito reference na Java implementaci SHA256withRSA. Pro implementace na jiných platformách se může hodit odkaz na skutečný standard RSASSA-PKCS1-v1_5, který je pro účely EET kombinován s SHA256 hash funkcí. Jakmile bude mít vývojář BKP, už jen spočte SHA1 hash kódu PKP. Pak celou zprávu zabalí do SOAP obálky, vytvoří podpis těla zprávy pomocí XML Signature s exkluzivní kanonizací a podle základního profilu WS-Security opět s algoritmy RSA a SHA256, přibalí certifikát a může evidovat na rozhraní u finanční správy.

Zadání zde jednoznačně vychází ze snahy maximalizovat úspory práce na straně centrálního systému využitím již v první studii zmiňovaných IBM Data Power zařízení, která ostatně finanční správa v soutěži z 12.5. poptává. A to bez ohledu na komplexitu zadání pro cílovou skupinu vývojářů specializovaných zařízení.

V lepším případě bude mít vývojář k dispozici knihovnu, která všechno zvládne. V horším případě… mu to nezávidím (500+ stran standardů pro XML Sig a souvisejících).

Se SHA256 si užijí spoustu radosti zejména vývojáři .NET/C# aplikací. Klíč pro RSA jde vygenerovat v několika různých crypto providerech, ale aby šel standardními funkcemi .NET frameworku využívat společně s funkcí SHA256… tady jsou Windows a framework velmi vybíravé, a to zejména ve spojení s WS security a XML podpisy.

Specifikace je sepsaná celkem jednoznačně z hlediska technologií. Ne zcela rozpracované jsou otázky chování rozhraní a lze očekávat problémy související s duplicitami při opakovaných odesíláních. Jedinou nápovědou specifikace je vyjádření, že jednoznačným identifikátorem tržby je PKP a tedy nepřímo sada dat použitá pro jeho výpočet.

Evidence tržeb rozhodně zvýší povědomí o aplikované kryptografii mezi běžnými, dosud netknutými vývojáři.

Celkově je specifikaci rozhraní možné považovat za silně nemoderní, postavenou na technologiích deset a více let starých. To by nemuselo být na závadu, kdyby zde ovšem neexistovaly technologie moderní, poskytující rovnocenné prostředky mnohem jednodušším způsobem (REST + Json Web Signature).

Certifikační autorita

Nejprve opět fakta. Certifikační autorita (CA) pro EET je nyní ve fázi běžící veřejné soutěže. Autorita je poptávána jako služba. Lze očekávat, že do časově velmi napjaté soutěže a ještě napjatějšího požadovaného harmonogramu dodání se pustí pouze subjekty, které již certifikační autoritou disponují. Rovněž bezpečnostní požadavky – jsou-li míněny vážně – není téměř možné v požadovaném termínu na zelené louce splnit. Jen dodávka EAL4+ HW modulů (HSM) se měří na týdny – a harmonogram požaduje dodávat službu od 1.9.2016. Míček je tedy zřejmě na straně uchazečů, kteří již mají vybudováno. Takovým uchazečům však finanční správa zkomplikovala situaci požadavky na poněkud neobvyklé doby platnosti certifikátu. 

Z hlediska harmonogramu je dodávání velmi napjaté. Podání nabídek je stanoveno na 27.5. Uzavření soutěže i při hladkém průběhu nelze očekávat dříve než koncem června. Na implementaci tedy bude dodavatel mít cca tři měsíce.

Celé zadání je opět vedeno snahou dodavatele centrálního řešení/zadavatele zjednodušit si práci s integrací mezi systémy EET a CA. Snaha je to zajisté pochopitelná, avšak staví do nezáviděníhodné situace budoucí uživatele – tedy všechny poplatníky.

V čem je zádrhel? Zadání na služby CA specifikuje jedno jediné integrační rozhraní. Toto integrační rozhraní slouží pro autentizaci poplatníka při vydání a správě certifikátu a je plně postaveno na proprietárním protokolu předávání autentizačních tokenů mezi dvěma webovými aplikacemi. Pro manuální obsluhu z webového rozhraní prohlížeče jde o metodu obvyklou. Bohužel již není myšleno na možnost automatizovaného vydání certifikátu. Všichni poplatníci tak budou muset vstoupit na daňový portál, přihlásit se údaji získanými datovou schránkou nebo návštěvou FÚ, následně projít procesem vytvoření žádosti o certifikát (portál by měl poskytnout prostředky) nebo importem žádosti o certifikát, odesláním žádosti, stažením vydaného certifikátu a jeho importem do cílového zařízení.

Takový návrh je zabijákem jakékoli uživatelské přívětivosti. Zde je opět vidět, že návrháři EET zamrzli v době před deseti lety. Samo využití certifikátů je z hlediska logiky věci absurdní. Certifikát jako doklad původu privátního klíče má sloužit dvěma komunikujícím stranám najít společný bod důvěry u třetí nestranné strany – certifikační autority. Použití certifikátů v EET je svého druhu autentizační onanie. Systém EET si ověří totožnost poplatníka, nechá si externí stranou certifikovat klíč, kterému následně má uvěřit zase pouze a jen systém EET a nikdo jiný. V současné době přitom existuje celá řada systémů, které využívají silnou asymetrickou kryptografii a obejdou se bez certifikátů (ssh, bitcoin, FIDO autentizace).

Rozumím použití certifikátu jako jednotné platformy pro kryptografii, kterou lze s výhodou použít s širokou paletou knihoven a existujícího SW. V takovém případě měl ale správce daně zjednodušit procesy. Že by to šlo, jsme si celkem důkladně prověřili při přípravě nabídky na centrální systém EET. V naší nabídce byl kladen důraz na možnost automatizace, na možnost kompletní správy prostředky poplatníka, resp. dodavatele zařízení. Všechny funkce administrativní web aplikace byly dostupné jak z webového prohlížeče, tak prostřednictvím API, jak je u moderních služeb obvyklé.

Scénář, kdy si poplatník koupí malé jednoduché zařízení evidenční pokladny s tiskárnou, naťuká do něj základní přístupové údaje získané od FÚ a zařízení se mu od té doby stará o zajištění komunikace s centrálou, automaticky vydává a obnovuje certifikáty – ať už přímo v zařízení nebo v centrálním systému poskytovatele zařízení, tak tento scénář je efektivně mrtev. Jistě je možné, že se programátorům podaří celou věc znásilnit a zautomatizovat, ale je to zcela zbytečná práce.

Ve spojení s nutností mít privátní klíč a certifikát vždy dostupný v době prodeje se zde vytváří celá řada možných zádrhelů, které souvisí s nemožností automatizovat správu certifikátů. Buď se při zavádění systému správci „ucertifikátují“, nebo nahrají do všech zařízení jeden certifikát a ohrozí tak bezpečnost.

Vůbec to neodpovídá aktuálnímu vývoji ve světě IT, kde před několika měsíci byla do ostrého provozu spuštěna služba pro vydávání obecně důvěryhodných serverových TLS/SSL certifikátů Let’s Encrypt, která umožňuje automatizovat bolestivé procesy správy certifikátů a redukuje je na prvotní nastavení trvající pár minut a následně již vše funguje automaticky. V našem světě se ale objevil systém, který nutí totální nonIT občany učit se pojmy typu privátní klíč, žádost o certifikát, certifikát, a čelit skutečnostem typu, že když si ten certifikát u syna na PC vygeneruji, a zkusím ho nahrát do té drahé pokladny (jak proboha, když tam není USB ani jiná podobná díra), ono to nejde, protože mi to říká, že tam nemám nějaký privátní klíč.

Každopádně finanční ředitelství se zavazuje odbavovat první úroveň podpory poplatníkům – nezbývá než doufat, že si alokuje dostatečné množství telefonních linek a trpělivých a proškolených operátorů.

Infrastruktura ADIS

Teď už jen stručně k poslednímu bodu. Finanční správa ve zřejmé souvislosti s EET poptává rozšíření infrastruktury ADIS o následující komponenty:

U žádné komponenty není popsána požadovaná minimální konfigurace, ale to by byla zbytečná práce, protože o výběrové řízení jde jen na oko. V podstatě se jedná o objednávku IBM proprietárního HW v hodnotě více než 100 milionů korun. K faktuře za JŘBÚ (50 milionů Kč) pro IBM tedy přibude ještě další tučná (100+ milionů Kč) fakturka od téže společnosti za HW rozšíření infrastruktury. A aby se do soutěže náhodou nezapletl ještě někdo další, jsou v kvalifikačních předpokladech požadovány “3 významné zakázky v rozsahu celkem 100 mil. Kč” v oblasti dodávek IBM HW.

Zajímavé je také časování odevzdání nabídek. Srovnejte – nabídka na dodání několika kusů HW za standardních podmínek, jejíž zpracování spočívá v určení míry slevy z ceníkové ceny a vyplnění tabulky jednotkovými cenami, má termín podání 29.6. – na zpracování je tedy cca 48 dnů. Nabídka na služby CA s nutností odhadnout netriviální implementační práce dodávané v šibeničních termínech se podává 27.5. – na zpracování je tedy 15 kalendářních dnů.

Závěrem

Jak jsem již uvedl na začátku článku, nejsem nestranným pozorovatelem. Jako takový si ale mohu dovolit pár srovnání. Alternativní řešení centrálního systému EET by mohlo vypadat následovně:

  • Cena za dodávku SW celého systému (portál poplatníka, rozhraní pro evidenci tržby, certifikační autorita, podpora pilotního provozu) by se mohla pohybovat (podloženo závaznou nabídkou) kolem 40 mil. Kč 
  • Cena za roční podporu 24×7 by mohla být cca 10 mil. Kč 
  • Subskripce komerčně podporovaných Open source komponent by v zamýšleném řešení vyšly na cca 6 mil. Kč/rok
  • HW bezpečnostní moduly HSM pro CA za cca 4 mil. Kč

Navrhované řešení by mohlo být koncipováno jako moderní architektura založená na mikroslužbách využívajících mimo jiné open source SW produktů Apache Cassandra (resp. Datastax Enterprise), Apache Kafka, Elasticsearch a jiných. Součástí dodávky by vzhledem k dopadu na širokou populaci mohlo/mělo být i začlenění streamu user experience s provedením UX testů na vybrané reprezentativní sadě budoucích uživatelů systému.

BRAND24

Provozováno by celé řešení mohlo být na následujícím komoditním HW:

  • ~20 komoditních PC serverů pro výpočetní část
  • ~50 komoditních PC serverů s úložnou raw kapacitou ~ 880TB na SATA (čistá kapacita 220TB) a cca 100TB na SSD, kde kapacita by umožnila udržovat posledních 5 let registrovaných dat s online dostupností s možností v budoucnu implementovat provádění pokročilé analytiky s využitím Hadoop/Spark nebo obdobných řešení
  • Hrubý odhad ceny komoditního HW bez dalších nákladů je cca 25 mil. Kč za servery včetně všech diskových kapacit

Cesta, kterou zvolila finanční správa, je pokračováním tvrdého a v dnešní době zcela zbytečného vendor-lock-in tak, jak ho známe z minulých dekád. Místo implementace zcela nového systému pro novou funkcionalitu, místo komoditních komponent s celou řadou soupeřících dodavatelů, místo využití vyspělých open source balíků doplněných o SW moduly na míru systému s plně dostupným zdrojovým kódem, se finanční správa rozhodla nadále investovat do zastaralého systému, kterému morální životnost skončila již před deseti lety. Takové rozhodnutí by se dalo pochopit, pokud by bylo méně nákladné. Bohužel prokazatelně se o méně nákladné řešení nejedná. Jak SW tak HW dosahují v podání IBM násobků této ceny.

Byl pro vás článek přínosný?

Autor článku

Autor je open [mind|source|data] positive IT Architekt idealista snažící se přežít v korporaci s touhou i po 20 letech v oboru tvořit systémy, které pomáhají nebo aspoň neprudí.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).