Zavedení formátu EDI do datových schránek

Jednou z připravovaných novinek, která by se měla v informačním systému datových schránek brzy objevit, je podpora příloh ve formátu EDI. Píše o tom technologicky pojatý článek magazínu Computerworld, jehož autorem je Radek Smolík, bezpečnostní architekt Informačního systému datových schránek. Podle Smolíka je zavedení EDI jednou z možností, jak "rozšířit využívání systému datových schránek mezi komerčními subjekty", uvádí autor.

Proč formát EDI?

EDI stojí na celosvětově rozšířeném mezinárodním standardu EDIFACT a nejvíce se u nás používá pro elektronickou fakturaci. V praxi se v České republice vyskytuje především standard OSN/ECE, v souladu s doporučením UN/CEFACT jako UN/EDIFACT, a sektorové standardy – ODETTE, hojně používaný v automobilovém průmyslu, a EANCOM typický pro obchod, logistiku, dopravu a podobně. EDI se tak stalo reálně využívaným způsobem pro elektronickou výměnu standardizovaných a strukturovaných datových zpráv mezi komerčními subjekty. Vidíme ho například v bankovnictví, ale i v dalších, výše zmíněných sektorech. Bylo také podpořeno celou řadou českých technických norem.

S čím se v ISDS počítá?

Postupně vzniklo několik způsobů, jimiž je EDI komunikace realizována. Mezi hlavní dva patří výměna informací prostřednictvím VAN sítě (privátní Value Added Network) a s využitím standardů jako AS1, AS2, AS3, ebXML (obecně, prostřednictvím internetu). V případě varianty VAN se spoléhá na speciální sítě, často užívající proprietární protokoly, propojující celosvětovou síť globálních i lokálních VAN poskytovatelů. Tyto sítě jsou tradičním poskytovatelem EDI komunikace a byly kolébkou jejího rozvoje. Výhodou VAN je především to, že připojení k nim je technicky snadné a uživatel sítě nemusí budovat infrastrukturu na své straně. Uzavřené sítě obsahují také bezpečnostní řešení, a zprávy proto byly vyměňovány bez podpisů, šifrování a dalších prvků přidávaných jejich odesílateli.
Používání VAN však může být spojeno se značnými náklady. Proto se vyskytly i metody jako point-to-point konektivita, případně využívání veřejně dostupných služeb elektronické pošty, které však narážely na mnohá, často bezpečnostní úskalí.
 Tyto problémy začalo řešit zavedení zmíněných standardů jako AS1, AS2, AS3, které přinesly řadu bezpečnostních prvků. Jejich užívání rostlo, a přibývalo tak komerčních subjektů, které spolu komunikují pomocí EDI, aniž přitom užívají služeb VAN poskytovatelů. ISDS jim v tomto ohledu může poskytnout jistou alternativu. Ta spočívá v tom, že stát garantuje stejnou míru právní jistoty, jako by tomu bylo u zaručené listinné komunikace.
Datové schránky se přitom chovají jako naprogramovaný doručovatel a neomezují, naopak předpokládají užití standardních bezpečnostních prvků v přiložených EDI dokumentech. Rozeberme si jeden z možných příkladů, z něhož bude lépe zřejmé, jak taková komunikace může pracovat a jak může být zabezpečena.

Fungování v praxi

Odesílatel nejdříve vytvoří příslušnou zprávu a vloží do ní potřebné zabezpečovací prvky. Pracuje-li například s fakturou a užívá-li EANCOM GS1 pro Českou republiku, pak má k dispozici: * bezpečnostní záhlaví USH-M, které v segmentu 2 obsahuje časové údaje a údaje o komunikujících stranách a řeší neodmítnutelnost původu; * bezpečnostní algoritmus USA-M, který v segmentu 3 definuje hashování zprávy a kontrolu její integrity; v segmentu 4 pak číslo certifikátu, vlastníka certifikátu a certifikační autoritu garantující platnost i syntaxi certifikátu; v segmentu 5 jsou obsaženy údaje o algoritmu, který byl použit pro elektronický podpis; * bezpečnostní trailer UST-M v segmentu 6 umožňuje označit část zprávy, vůči které byl použit bezpečnostní mechanismus, a propojit výsledek autentizace s daným USH segmentem; * následoval by bezpečnostní result USR-M, který v segmentu 7 slouží pro identifikaci a obsahuje podpis zprávy pomocí tajného klíče (aplikace hashe na segmenty USH, USA, USC a celou zprávu počínaje BMG a konče jejím posledním segmentem), jakož i podpis k ověření algoritmu. Tyto segmenty umožní EDI fakturu odpovídající výše uvedené normě digitálně podepsat, a zajistit tak její autenticitu a integritu. Odesílající může použít i časové razítko (byť zatím nemá konverzní význam), případně ho může v podstatě se stejným efektem přidat na vstupu k celé datové zprávě i její příjemce. Následně je zapotřebí příslušnou EDI aplikací vytvořit soubor s příponou EDI, jehož MIME-type musí být TXT nebo XML (takový je současný záměr), a připojit ho k připravované datové zprávě (ať už Fillerem nebo jinou, odesílající aplikací).
 Jakmile bude zpráva přijata systémem datových schránek, bude provedeno její parsování na aplikačních serverech, kontrola struktury, antivirová kontrola, kontrola formátu a MIME-typu příloh i další předepsané úkony. V negativním případě bude odmítnuta a její odesílatel bude notifikován. V kladném případě bude uložena v systému a odkázána do schránky příjemce, který musí mít předem povolen příjem poštovních datových zpráv. Než k tomu však dojde, bude vybavena časovým razítkem a budou z ní vypočteny dva nezávislé digesty (používá se hashovací algoritmus SHA-256, jehož digest se zprávou cestuje a slouží spolu s dalšími prvky k ověřování integrity na straně příjemce, a také hashovací algoritmus SHA-512, jehož digest zůstává uložen v systému a užívá se pro kontrolní ověřování integrity ze strany správce ISDS). Při stahování takové zprávy jsou ze strany jejího příjemce využitelné dvě webové služby. V jednom případě je datová zpráva podepsána elektronickou značkou MV ČR, která osvědčuje její autenticitu (je nutné vnímat rozdíl mezi autenticitou celé zprávy i s obálkou a autenticitou EDI přílohy, kterou řeší výše popsané segmenty přiloženého dokumentu s EDI zprávou).
ISDS tak zaručí příjemci EDI zprávy její průkaznost a právní hodnotu nejenom na úrovni příloh (budou-li komunikujícími stranami použity bezpečnostní prvky, které jsou součástí formátu EDI zpráv), ale také na úrovni obálky a v ní obsažených metadat celé datové zprávy.
 Samozřejmě příjemce musí disponovat vlastním, vhodným programem, který mu umožní práci s EDI formátem (jak jeho vytváření, tak i jeho čtení, případně kontrolu integrity). ISDS to podpoří dalšími, nově zamýšlenými funkcemi. Jedna z nich bude sloužit k ověření integrity libovolné zprávy a má umožnit, aby si uživatel mohl ověřit, zda kterákoliv datová zpráva, kterou má lokálně uloženou a v systému již byla smazána, odpovídá přesně tomu stavu, v jakém mu byla ze systému doručena (a to s institucionální garancí ministerstva vnitra). Druhou funkcí, která je rovněž předmětem diskuzí o možném rozšíření systému, je náhled zprávy bez toho, aby k tomu byl nutný Filler (čili i z počítače, který nesplňuje současné technické předpoklady užívání ISDS), avšak také bez toho, aby si uživatel (při tomto způsobu) integritu zprávy ověřil.

***

Co ještě není dořešeno?

Zbývá i několik otevřených, především právních otázek. Mezi nimi je tou hlavní, vztahující se také k EDI komunikaci, otázka správného doručování zpráv mezi komerčními subjekty vůbec. Novela zákona 300/2008 Sb., která byla v loňském roce přijata, totiž do věci zanesla vliv některých ustanovení občanského zákoníku. Stanovisko Ministerstva vnitra ČR k němu (vyplývající například z dokumentu www.mvcr.cz/clanek/datoveschrankya-cinnost-spravnich-organu.aspx), podle něhož je dnes problém řešen povinným potvrzením příjmu ze strany příjemce, je v rozporu se stanovisky nezávislých právních expertů.