Obsah
Description of shared services, functional units and thematic areas of public administration of the Czech Republic
This chapter looks at the shared services, functional units and thematic areas of public administration of the Czech Republic "from above" and provides both definitions of key concepts and elements of the architecture of the VS and an overview of central shared eGovernment services available for use in local architectures of authorities. The basic pillars and future directions of eGovernment development can be covered by the key shared services, functional units or thematic areas described below. Through them, central shared eGovernment services as well as shared agency services are provided, which are summarised in architectural vision of eGovernment. The shared services, functional units and thematic areas described in this section are obligatory to be taken into account in the information concept of the authority and in the architecture of the authority on the basis of Law 365/2000 Coll. and Information concept of the CR according to Methods of use of shared services, functional units and thematic areas by authorities.
Thematic areas
-
- e.g. for agencies under delegated competence Trade Register, Population Register, Drivers Register and Motor Vehicle Register, Technical Infrastructure Information System, etc.
- Shared agenda IS for the autonomous competence of territorial self-governments * Shared operational information systems
- e.g. Civil Service Information System, Integrated Treasury Information System, National Electronic Tool, MS2014+, etc.
- Shared statistical, analytical and reporting systems * for example Business Intelligence * eGovernment Cloud * National Data Centers * Public Administration Communication Infrastructure- KIVS/CMS
Public Administration Agenda Model
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and the architecture of the office is described in Architecture of the office in the context of public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices.
Popis Agendového modelu veřejné správy
Agendový model je základem byznys architektury veřejné správy a základem řízení výkonu digitálních služeb veřejné správy. Všechny agendy veřejné správy jsou zapsány spolu s legislativním ukotvením v Registru práv a povinností včetně definice OVM v agendách působících. V souladu s touto registrací pak OVM musejí vykonávat svoje činnosti a poskytovat svoje služby. Registr práv a povinností dále definuje údaje v agendách vedené a pravidla pro jejich využívání jinými agendami resp. agendovými informačními systémy tyto agendy podporujícími.
Agendový model výkonu veřejné správy
Základ agendového modelu výkonu veřejné správy byl vytvořen při implementaci základních registrů ve veřejné správě. Agendový model definuje působnost a činnosti OVS v jednotlivých agendách – souhrn všech činností ve všech agendách, ve kterých OVS působí, definuje působnost OVS. Orgány veřejné správy mají veškeré své veřejnoprávní činnosti definovány popsáním působnosti v jednotlivých agendách.
Agendy veřejné správy
Agendy veřejné správy jsou nejen právní rámce pro fungování orgánů veřejné moci, ale i základní rámce pro realizaci procesů jako činností a pro evidenci a spravování a využívání údajů v rámci principu propojeného datového fondu.
Existuje následující obecný rozpad toho, co je evidováno k agendě v RPP a co to obecně znamená:
Agenda je soubor činností definovaných zákonem, či zákony (příklad je agenda občanských průkazů, státní sociální podpory, evidence řidičů apod.)
- Ohlašovatelem je OVM, který je gestorem dané právní úpravy a má tedy povinnost agendu a údaje o ní zapsat do Registru práv a povinností. Součástí ohlášení jsou:
- Referenční údaje o agendě
- název agendy a její číselný kód, které jsou součástí číselníku agend,
- čísla a názvy právních předpisů a označení jejich ustanovení, na jejichž základě orgán veřejné moci vykonává svoji působnost, nebo na jehož základě je soukromoprávní uživatel údajů oprávněn k využívání údajů ze základních registrů nebo agendových informačních systémů,
- výčet a popis činností, které mají být vykonávány v agendě,
- výčty činnostních rolí,
- výčet a popis úkonů orgánů veřejné moci vykonávaných v rámci agendy na žádost subjektu, který není orgánem veřejné moci, identifikátor úkonu, vymezení subjektu, který může podat žádost, a forma úkonu,
- výčet orgánů veřejné moci a soukromoprávních uživatelů údajů, kteří agendu vykonávají, nebo jejich kategorie,
- název ohlašovatele agendy a jeho identifikátor orgánu veřejné moci,
- výčet orgánů veřejné moci, které byly pro výkon agendy zaregistrovány, a jejich identifikátor orgánu veřejné moci,
- výčet údajů vedených nebo vytvářených podle jiného právního předpisu v rámci agendy; to neplatí pro zpravodajské služby,
- výčet údajů vedených v základních registrech zpřístupněných prostřednictvím informačního systému základních registrů pro výkon agendy a rozsah oprávnění k přístupu k těmto údajům,
- výčet údajů vedených v jiných agendových informačních systémech zpřístupněných prostřednictvím referenčního rozhraní pro výkon dané agendy a rozsah oprávnění k přístupu k těmto údajům,
- číslo a název právního předpisu a označení jeho ustanovení, na jehož základě je orgán veřejné moci nebo soukromoprávní uživatel údajů oprávněn využívat údaje ze základních registrů nebo z agendových informačních systémů anebo je zapisovat,
- adresa pracoviště orgánu veřejné moci, které vykonává úkon podle písmene d), vyjádřená referenční vazbou (kódu územního prvku) na referenční údaj v registru územní identifikace, nebo údaj o převedení výkonu úkonu podle písmene d) na jiný orgán veřejné moci.
- Definice agendových činností a činnostních rolí: V rámci ohlášení ohlašovatel provede dekompozici legislativy a sestaví strom agendových činností (tedy postupu agendy a interakcí zejména z pohledu veřejné správy) a stanoví, jaké činnostní role budou jednotlivé činnosti vykonávat.
- Působnost v agendě: Je stanovena působnost jednotlivých orgánů veřejné moci (třeba konkrétní ministerstvo, či souhrnné skupiny jako jsou obce, krajské úřady apod.) a u nich jsou stanoveny činnostní role pro výkon jednotlivých činností. Působnost stanovuje/ohlašuje ohlašovatel a daný orgán veřejné moci se přihlašuje k této působnosti a k jejímu rozsahu, vše v rámci agendových informačních systémů v RPP.
- Adresy pracovišť OVM, kde jsou vykonávány činnosti agendy: Vytváří faktickou mapu výkonu dané agendy v území a každý OVM, který vykonává působnost je povinen ke svým činnostem přiřadit skutečnou adresu výkonu (nikoliv sídlo OVM).
- Agendové informační systémy: Jsou stanoveny agendové informační systémy, které orgány veřejné moci vykonávající působnost v dané agendě k této působnosti používají, těmto systémům jsou pak stanovena i oprávnění využívat služby základních registrů, a tedy využívat referenční údaje a údaje z jiných agendových informačních systémů prostřednictvím eGon Service Bus / Informačního systému sdílené služby. RPP je metainformačním systémem definujícím datový model veřejné správy, oprávnění a pravidla pro ukládání, využívání a zveřejnování údajů.
- Výměna (poskytování a využívání údajů) v agendě: Ohlašovatel stanoví, kdo a které údaje smí z agendy využívat anebo je naopak agendě ze svých AIS poskytuje.
- Údaje v agendě: Jsou ohlášeny všechny propojované a vedené údaje, včetně jejich kontextů a včetně technických údajů o nich.
- Úkony na žádost: Součástí agendy je i seznam a forma úkonů na žádost a určení toho, kdo smí takovou žádost podat
- Formuláře: součástí povinností ohlášení agendy je i předání elektronických formulářů či odkazů na ně ministerstvu vnitra.
Klíčové role OVS v agendovém modelu
Existují následující klíčové role, o kterých se hovoří i jinde v rámci architektonických dokumentů:
| Klíčové role OVS v agendovém modelu veřejné správy | Role | Popis/význam hlavní činnosti |
|---|---|---|
| Ohlašovatel agendy | OVM, který je zodpovědný za legislativní rámec agendy, a tedy určuje i základní parametry jejího výkonu | Je gestorem právních předpisů; koordinuje výkon agendy; metodicky řídí výkon agendy; ohlašuje agendu v RPP a její podrobnosti; stanovuje působnost OVM; poskytuje buď centralizovaný AIS, nebo podmínky a standardy pro decentralizované řešení; ohlašuje a spravuje údaje v RPP, včetně údajů v rejstřících OVM a SPUU; v případě centralizovaného AIS poskytuje údaje přes referenční rozhraní ISVS |
| Orgán veřejné moci působící v agendě | OVM, který působí v dané agendě. To znamená, že vykonává fakticky nějakou činnost v rámci dané agendy a k tomu využívá buď centrálně poskytnutý AIS, nebo svůj vlastní | Přihlašuje se k působnosti; vykonává jemu svěřené činnosti úředníky v jejich činnostních rolích; zapisuje do RPP údaje o své působnosti; využívá centralizovaný AIS nebo spravuje vlastní; eviduje a spravuje údaje v agendě; vykonává případně funkce editora údajů |
| Soukromoprávní uživatel údajů | Subjekt, který má na základě zákona oprávnění k přístupu k údajům v základních registrech či AISech a přistupuje k nim prostřednictvím AIS spravovaného k tomu určeným OVM | Využívá údaje podle oprávnění |
| Správce centralizovaného AIS pro výkon agendy | OVM, který na základě zákona spravuje centralizovaný AIS a poskytuje ho OVM působícím v agendě | Spravuje centralizovaný AIS; zpřístupňuje AIS uživatelům působících OVM; realizuje využívání referenčních údajů ze základních registrů do centralizovaného AIS; poskytuje podporu uživatelům; řeší integrační vazby AIS na další systémy |
| Správce vlastního AIS, pokud není k dispozici centralizovaný AIS | Jednotlivé OVM, které pro podporu agendy využívají svůj vlastní agendový IS, protože není k dispozici sdílené centralizované řešení | Spravuje svůj vlastní AIS; zapisuje údaje o svém AIS do RPP; řeší vazby na základní registry; řeší vazby na další ISVS; řeší vazby na další svoje informační systémy; spravuje a udržuje datový fond ve svém AISu |
| Orgán veřejné moci spravující AIS pro přístup soukromoprávních uživatelů | OVM, který na základě zákona vytváří a provozuje AIS, jehož prostřednictvím mohou soukromoprávní uživatelé přistupovat k údajům ze základních registrů či jiných AISů | Spravuje AIS pro SPÚ; zpřístupňuje funkce AISu soukromoprávním uživatelům; realizuje dohled nad oprávněním k využívání údajů; poskytuje soukromoprávním uživatelům údaje; zajišťuje realizaci reklamací údajů od SPÚ k editorům údajů |
Pohled na ohlašovatele a vykonavatele agendy
Pravidla Agendového modelu veřejné správy
Základní povinnosti ohlašovatele agendy
Ohlašovatel agendy je podle zákona č. 111/2009 Sb., o základních registrech zodpovědný za řádné ohlášení agendy a za aktualizace agendy, a především za správnost a pravdivost údajů uvedených v agendě. Zjistí-li kdokoliv nesoulad reality s údaji, měl by to jako u dalších referenčních údajů ohlásit ohlašovateli, a ten musí agendu upravit do souladu se skutečností. To se netýká jen základních informací, ale i všech dalších referenčních a nereferenčních údajů, jako jsou činnosti, působnosti OVM, údaje v agendě, agendové informační systémy apod.
Základními povinnostmi ohlašovatele jsou:
- Tam, kde je gestorem legislativy, dodržovat veškeré principy pro legislativu, včetně zásad Digitálně přívětivé legislativy
- Ohlásit agendu
- Ohlásit každou její změnu
- Ohlásit působnost všech OVM a definovat výkon jim svěřených činností
- Zajistit využívání údajů ze základních registrů a související oprávnění pro jejich využívání pro podporu výkonu agendy
- Ohlásit agendové informační systémy, které spravuje a které jsou poskytovány OVM působícím v agendě
- Ohlásit údaje v agendě vedených, čerpaných i poskytovaných
- K centralizovaným agendovým informační systémům vydávat provozní řád
- Metodicky řídit výkon agendy u OVM, který v agendě působí
- Spravovat, tzn. ohlašovat a udržovat aktuální, údaje v rejstříku OVM/SPUU. U SPUU se jedná o všechny subjekty, které jsou povinné dle právních předpisů spadající do agendy, jejichž je OVM ohlašovatel. Ohlašovat může ustanovit jiné OVM, které bude tyto úkony činit.
Základní povinnosti OVM působícího v agendě
V rámci agendy veřejné správy mohou veřejnoprávní činnosti vykonávat pouze ty orgány veřejné moci, které jsou v rámci ohlášení agendy vyznačeny jako orgány veřejné moci vykonávající působnost, a to v rámci konkrétních činností. To znamená, že po aplikaci principu referenčních údajů v Registru práv a povinností lze konstatovat, že pokud v rámci dané agendy vykonává veřejnoprávní činnost orgán veřejné moci, který nemá vyznačenou působnost, jedná se o porušení zákona a ohlašovatel agendy musí neprodleně toto napravit. To se týká nejen samotného seznamu působících orgánů veřejné moci, ale také přiřazení jejich činností. Výkon činnosti je byznysovou vazbou a odborně jej nazýváme "činnostní rolí".
Základními povinnostmi orgánů veřejné moci působících v agendě tedy jsou:
- Vykonávat činnosti dle ohlášení agendy
- Pokud OVM zjistí nesoulad skutečnosti a údajů v ohlášení agendy, je povinen požadovat po ohlašovateli nápravu.
- Pokud sám spravuje agendový informační systém pro výkon agendy (není poskytován centrálně), ohlásit tento systém do RPP jako ISVS.
- Pokud existuje centralizovaný agendový informační systém, tak tento využívat.
- Přistupovat k údajům v základních registrech a dalších ISVS výhradně na základě oprávnění ohlášeného v agendě.
- Spravovat jen ty údaje, které jsou ohlášeny v dané agendě.
- Pokud zjistí nesoulad referenčních údajů v jednotlivých základních registrech se skutečností, zahájit proces reklamace u příslušného editora.
Identifying Public Administration Clients
The description of the architecture of the authority and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its architecture layers.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Linked Data Pool
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How individual offices use shared services, functional units and thematic areas
Public Data Fund
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Entity Records
The description of the architecture of the authority and the public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Spatial Data and Services over Spatial Data
The description of the architecture of the authority and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Full electronic submission
The description of the architecture of the office and the public administration of the Czech Republic by each architecture layer and the incorporation of the requirements into the information concept and the architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Information Systems Integration
The description of the architecture of the office and the public administration of the Czech Republic by individual layers of architecture and the incorporation of requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its layers of architecture.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Public administration and private data user portals
The description of the architecture of the authority and the public administration of the Czech Republic by individual layers of architecture and the incorporation of requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Popis Portálů veřejné správy a soukromoprávních uživatelů údajů
Portál je vnímán jako celý funkční celek obsahující Front-end (logika zobrazující chování směrem ke klientovi) i Back-end (logika realizující chování systému a vnitřní i vnější integraci) realizující všechny typy služeb dle Informační koncepce ČR - Informační, Interaktivní a Transakční. Z tohoto mimo jiné vyplývá, že portál je informačním systémem veřejné správy.
- V oblasti informačních služeb poskytuje uživatelům přehled a veřejně dostupné informace z oblasti, kterou portál obsahuje včetně popisu životních situací.
- V informační části není potřeba řešit identifikaci, autentizaci a autorizaci uživatele.
- V oblasti interakčních služeb poskytuje uživatelům personifikované údaje s využitím vícero informačních kanálů, zpětnou vazbu mezi jeho konáním, a to včetně historie.
- Interakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele.
- V oblasti transakčních služeb poskytuje uživatelům podání všech typů, včetně provedení platby nebo rezervace termínu pro prezenční jednání, získání potvrzení a doručení rozhodnutí úřadu.
- Transakční služby vyžadují identifikaci, autentizaci a autorizaci uživatele.
Portály tedy nemohou být samostatné a nepropojené aplikace, ale naopak musí se jednat o prostředek, který je integrován s informačními systémy v úřadu. Především s elektronickou spisovou službou, s agendovými informačními systémy, ale třeba i s ekonomickými systémy tam, kde se jejich prostřednictvím shromažďují údaje o výplatách či o poplatcích podle jednotlivých klientů. V případě poskytování všech 3 typů služeb se jedná o tzv. integrované on-line služby veřejné správy dle Informační koncepce ČR.
Portál má sloužit klientovi k získání informací, jako prostředek pro publikování otevřených dat, statistik a veřejných výstupů, pro elektronická podání a komunikaci klienta s úřadem. Portál musí též sloužit i držitelům zaručené elektronické identifikace jako prostředek pro získání jejich údajů, pro různé notifikace, ale třeba i pro interaktivní podání žádostí, či podání žádostí o výpisy. Klientovi musí poskytnout též tzv. profil neboli personifikovanou část, kde si portál drží základní údaje o klientovi, které zná úřad nebo které klient sdělit sám ze své vůle.
Celkové chování a interakce Portálu vůči občanům i úředníkům se nazývá User Experience (UX). Do UX patří nejen grafická podoba, ale také jazyk (forma, odbornost, …), způsob interakce, komunikační kanály, obdobné způsoby identifikace uživatelů atd. Pro snadné používání občanem je nutné, aby každý portál používal jednotné, centrálně defikované UX. Zjednodušeně řečeno jde o obdobu chování a interakce, jakou má popsaný Portál občana.
Centrální (federující) portály
Centrálními (federujícími) portály jsou myšleny portály, které sdružují informace z dílčích portálů, zprostředkovávají interakci s portály nižší úrovně – federovanými portály (agendové a území). Na rozdíl od portálů nižší úrovně je centrálních (federujících) portálů spočetně méně a slouží především klientům pro snadné vyřízení jeho potřeb na jenom místě. V současné době jsou takovýmito portály pouze Portál veřejné správy a Portál občana (PO a PVS).
Portálem občana je myšlena transakční část Portálu veřejné správy, kde klient/občan může skrze samoobslužné služby pod svou zaručenou elektronickou identitou činit podání vůči veřejné správě a využívat její služby. Více je v samostatném funkčním celku
Agendový portál
Agendovým portálem je myšlen portál poskytující služby logicky centralizovaného systému či systémů pro jiné orgány veřejné správy a klienty veřejné správy. Typicky jde tedy o portál správce agendy, ve kterém lze řešit služby agendy bez ohledu na místní příslušnost. Platí, že služby pro klienta musí být součástí federace a jejich služby přístupné v centrálních (federujících) portálech.
Portál území
Portálem území je myšlen portál poskytující služby, které spadají pod určité území ČR, typicky kraj, obec, město, městská část, souhrnně možno označit za samosprávy. Portál území může obsahovat kromě samosprávních služeb jako např. správa místních poplatků, i služby přenesené, avšak neměla by nastat situace, kdy je služba přenesené působnosti vytvořena jen pro portál území. Je zodpovědnost věcného správce, aby vytvořil centrální prostředí pro vyřizování služeb přenesené působnosti, které portál území využije, ale nevytváří. Platí, že služby pro klienta musí být součástí federace a jejich služby přístupné v centrálních (federujících) portálech.
Portál soukromoprávního uživatele údajů
V případě portálu soukromoprávního uživatele údajů (také jako SPUÚ) se jedná o situaci, kdy vlastník portálu není orgán veřejné moci, ale dle své povahy je podřízen zákonu 111/2009 Sb. Může se jednat o portály poskytovatelů zdravotních služeb, soukromých pojišťoven, bank, státních podniků, apod. Takovéto portály poskytují služby, které mohou být federovány do Portálu občana, avšak pouze za předpokladu, že SPUÚ je ohlášen v rejstříku a má povinnost elektronicky ověřovat totožnost klienta.
Pohledy na portály veřejné správy
Obyčejný portál
Obyčejným portálem se v tomto smyslu myslí všechny druhy portálů dle jejich zaměření, jak je uvedeno výše, avšak tento diagram zobrazuje práci s daty. Obyčejný portál se chová jako jednotné rozhraní sloužící pro vyřízení služby, avšak její faktické vyřízení probíhá v agendovém informačním systému. Portál si obstarává veškeré údaje a další informace, které klientovi poskytuje, prostřednictvím agendového informačního systému a veškeré dokumenty, které při vyřizování služby vzniknou se musí dostat do spisové služby.
Portál jako Agendový informační systém
Portálem jako Agendovým informačním systémem se v tomto smyslu myslí všechny druhy portálů dle jejich zaměření, jak je uvedeno výše, avšak tento diagram zobrazuje práci s daty. Portál jako Agendový informační systém se chová jako samostatný agendový informační systém, tedy kromě samotného rozhraní pro příjem a vyřízení služby obsahuje i veškerou logiku a podporuje procesy pro její vyřízení. Portál si obstarává veškeré údaje a další informace, které klientovi poskytuje, prostřednictvím přímého napojení na informační systém základních registrů, eGSB/ISSS nebo AIS, které spravuje stejný správce jako portál. Nadále platí, že veškeré dokumenty, které při vyřizování služby vzniknou se musí dostat do spisové služby.
Pravidla Portálů veřejné správy a soukromoprávních uživatelů údajů
Úřad musí při provozování portálu zavést a změnit současné procesy orientované především na osobní kontakt s klientem. Současné portály již musí disponovat funkcionalitou propojení se zaručenou identitou dle zákona 250/2017 Sb. a musí se umět přizpůsobit situaci, kdy klient veřejné správy bude komunikovat pouze elektronicky. Začíná se tedy samotným uživatelsky přívětivým prostředím, které musí být v souladu s grafickým manuálem MVČR. Dále je potřeba formulářový engine, který umožní nejen předvyplnit veškeré státu již známé údaje z propojeného datového fondu a elektronické identity poskytnuté národní identitní autoritou. V neposlední řadě je potřeba zajistit předávání všech podání učiněné v portálu do agendových informačních systémů, ve kterých se dle agendy podání řeší a zároveň do spisové služby úřadu.
Portál podporuje samoobslužného klienta, který obsahuje jak přenesenou, tak samosprávnou působnost a obsahuje popis životních situací, ve kterých se řeší mandáty v elektronické komunikaci. Pokud portál vykonává a podporuje agendu veřejné správy dle registru práv a povinností, musí se chovat jako jakýkoliv jiný agendový informační systém a pracovat dle definice agendy.
Při předávání podání z portálu je tak potřeba mít zajištěnou funkcionalitu, která z podání vytvoří "lidsky čitelné" a "strojově čitelné" informace v rámci jednoho dokumentu, typicky formátu PDF/A3 a vyšší. Tento „kontejnerový“ formát pak slouží jak pro plnění požadavku „čitelnosti“ tak i pro zajištění požadavku na automatizované zpracování dat (vložené XML s údaji pro automatizované zpracování). Dokument musí být dále pak opatřen náležitostmi dle zákona č. 297/2016 Sb., typicky elektronickým podpisem nebo elektronickou pečetí a časovým razítkem. Lidsky čitelný formát, typicky PDF, jde do spisové služby pro evidenci a strojově čitelný formát jde od agendového systému. Při provozu portálu nezáleží na technologiích, ani infrastruktuře. Není tedy preferované ani On Premise řešení, ani cloudové řešení, vše záleží na potřebách daného úřadu a možnostech, které technologie dokáží nabídnout. Je vždy potřeba myslet na rozložení zátěže, například:
- daňové přiznání z příjmu fyzických osob se podává 1x ročně a ačkoliv se nejedná o jeden rozhodný moment (celková doba je 6 měsíců) a je možné podávat i dodatečná daňová přiznání, není nutné klást na infrastrukturu stejné nároky po dobu celého roku, nebo
- žádosti o různé dotace (například tzv. "kotlíkové") se podávají do určitého data, dá se předpokládat jisté vytížení od okamžiku spuštění až do ukončení, kdy budou vysoké nároky na infrastrukturu (se vzrůstajícím trendem) a po uplynutí termínu, kdy budou minimální.
Každé řešení však musí podporovat přístup k centrálním službám eGovernmentu a dalším službám veřejné správy skrze zabezpečenou infrastrukturu Referenčního rozhraní veřejné správy. Níže uvedená pravidla pro centrální, agendové i místní portály jsou výtažkem ze studií zabývajícími se pravidly a federací portálů Boston Consulting Group - Gov.cz a NAKIT + PwC - Zpracování pravidel pro federaci portálů veřejné správy a definování cílového stavu.
Centrální (federující) portály
- Centrální (federující) portály musí být schopny zpřístupnit informace a služby všech portálů, které splní požadavky kladené federací
- Centrální (federující) portály si kromě uživatelského profilu neuchovávají žádné informace o subjektu práva – identifikovaném a autentizovaném uživateli
Pravidla pro Portál občana a Portál veřejné správy jsou popsána v samostatném funkčním celku.
Agendový portál
Agendovým portálem je myšlen portál poskytující služby logicky centralizovaného systému či systémů pro jiné orgány veřejné správy a klienty veřejné správy. Typicky jde tedy o portál správce agendy, ve kterém lze řešit služby agendy bez ohledu na místní příslušnost.
Takový portál musí splnit několik podmínek:
- Musí být registrovaný jako informační systém veřejné správy v rejstříku informačních systémů veřejné správy
- Spravuje ho orgán veřejné správy, který vykonává jednu nebo více agend dle seznamu agend veřejné správy
- Musí být součástí federace portálů veřejné správy a poskytovat informace a služby do centrálních (federujících) portálů jako je např. Portálu občana
- Musí být součástí federace národního identitního schématu, tedy využívat služby Národní identitní autority a jeho správce musí být ohlášen jako kvalifikovaný poskytovatel služeb
- Musí k identifikovanému a autentizovanému uživateli být schopen propojit údaje své agendy a údaje z propojeného datového fondu a veřejného datového fondu
- Musí využívat datovou základnu katalogu služeb a životních situací, jaká je v RPP
- Musí být v souladu s grafickým manuálem MVČR
- Musí být schopen poskytnout identifikovanému a autentizovanému uživateli možnost udělit mandát/oprávnění k zastupování pro jednotlivé služby, propsat do mandátního registru a nastavené mandáty zobrazovat, přijímat a rušit.
- Musí umožnit učinit podání (učinit úkon) ke službě z katalogu služeb VS pomocí následujících kanálů:
- Přímého podání na portále identifikovaným a autentizovaným uživatelem pomocí NIA
- Elektronicky podepsaným dokumentem ve formě uznávaného podpisu
- Musí být schopen poskytnout náhled na jednotlivá podání vůči úkonům a služeb identifikovanému a autentizovanému uživateli a to jak tomu, který podání učinil, tak tomu, který je k tomu zmocněn
- Musí být schopen poskytnout úhradu poplatku pomocí platební brány
- Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód
- Musí splňovat bezpečnostní požadavky dle minimálního bezpečnostního standardu
- Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím cloud computingu, atd.)
- Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb KIVS/CMS.
Postup činností práce s klientem, jeho identifikací a výběrem služeb
- Po zvolení služby klientem, OVS zajistí překlad identity (BSI-AIFO agendy vybrané služby) pomocí eGON služeb ISZR
- OVS se doptá na oprávněné údaje pro potřeby služby dle oprávnění vybrané agendy
- OVS dá klientovi vybrat, do jaké role chce obsadit dle agendy, ve které je služba poskytována (tzv. mandát)
- Po dokončení služby si OVS nepamatuje AIFO ani jiné údaje použité pro službu, pokud to nevyžaduje samotná agenda
- OVS si pamatuje BSI pro klientský profil na portále
Portál území
Portálem území je myšlen portál poskytující služby, které spadají pod určité území ČR, typicky kraj, obec, město, městská část, souhrnně možno označit za samosprávy. Portál území může obsahovat kromě samosprávních služeb jako např. správa místních poplatků, i služby přenesené, avšak neměla by nastat situace, kdy je služba přenesené působnosti vytvořena jen pro portál území. Je zodpovědnost věcného správce, aby vytvořil centrální prostředí pro vyřizování služeb přenesené působnosti, které portál území využije, ale nevytváří.
Takový portál musí splnit několik podmínek:
- Musí být pro každou samosprávu jeden. Je na něm dostupné vše, v čem má samospráva působnost, tedy včetně přenesené působnosti.
- Musí být registrovaný jako informační systém veřejné správy v systému o informačních systémech veřejné správy
- Musí být součástí federace portálů veřejné správy a poskytovat informace a služby do centrálních (federujících) portálů jako je např. Portálu občana
- Musí být součástí federace národního identitního schématu, tedy využívat služby Národní identitní autority a jeho správce musí být ohlášen jako kvalifikovaný poskytovatel služeb
- Musí k identifikovanému a autentizovanému uživateli být schopen propojit údaje své agendy a údaje z propojeného datového fondu a veřejného datového fondu
- Musí využívat datovou základnu katalogu služeb a životních situací, jaká je v RPP
- Musí být v souladu s grafickým manuálem MVČR
- Musí být schopen poskytnout identifikovanému a autentizovanému uživateli možnost udělit mandát/oprávnění k zastupování pro jednotlivé služby, propsat do mandátního registru a nastavené mandáty zobrazovat, přijímat a rušit.
- Musí umožnit učinit podání (učinit úkon) ke službě z katalogu služeb VS pomocí následujících kanálů:
- Přímého podání na portále identifikovaným a autentizovaným uživatelem pomocí NIA
- Elektronicky podepsaným dokumentem ve formě uznávaného podpisu
- Musí být schopen poskytnout náhled na jednotlivá podání vůči úkonům a služeb identifikovanému a autentizovanému uživateli a to jak tomu, který podání učinil, tak tomu, který je k tomu zmocněn
- Musí být schopen poskytnout úhradu poplatku pomocí platební brány
- Veškeré funkcionality, které se vyvinuly na míru, musí být poskytnuty jako otevřený zdrojový kód
- Musí splňovat bezpečnostní požadavky dle minimálního bezpečnostního standardu
- Musí být připraven zvládnout provozní zátěž ve špičkách zájmu o využití jednotlivých služeb (např. pomocí asynchronní architektury, využitím cloud computingu, atd.)
- Pokud portál přímo čerpá nebo poskytuje služby informačním systémům veřejné správy jiných správců, je toto propojení realizováno výhradně prostřednictvím služeb KIVS/CMS.
Příklad postupu činností v portálu území ve vztahu ke klientovi:
- Po zvolení služby klientem, OVS zajistí překlad identity (BSI-AIFO agendy vybrané služby) pomocí eGON služeb ISZR
- OVS se doptá na oprávněné údaje pro potřeby služby
- OVS rozlišuje mezi samostatnou a přenesenou působností
- Samostatná působnost je soubor více agend, nelze celou samostatnou působnost konat jako jednu agendu
- OVS dá klientovi vybrat, do jaké role chce obsadit dle agendy, ve které je služba poskytována (tzv. mandát)
- Po dokončení služby si OVS nepamatuje AIFO ani jiné údaje použité pro službu, pokud to nevyžaduje samotná agenda
- OVS si pamatuje BSI pro klientský profil na portále
Portál soukromoprávního uživatele údajů
V případě portálu soukromoprávního uživatele údajů (také jako SPUÚ) se jedná o situaci, kdy vlastník portálu není orgán veřejné moci, ale dle své povahy je podřízen zákonu 111/2009 Sb. SPUÚ je podnikající fyzická osoba nebo právnická osoba, která není orgánem veřejné moci a je podle jiného právního předpisu oprávněna využívat údaje ze základního registru nebo z agendového informačního systému Může se jednat o portály poskytovatelů zdravotních služeb, soukromých pojišťoven, bank, státních podniků, apod. Takový portál a jeho vlastník musí splnit několik podmínek:
- Musí mít zřízenou datovou schránku pro komunikaci s veřejnou správou
- Právnické osoby mají datovou schránku zřízenou ze zákona
- Zřídit datovou schránku je možné dle informací na webu České pošty
- Datová schránka se může obsluhovat skrze webové rozhraní na adrese www.mojedatovaschranka.cz nebo mít funkcionality integrovány do vnitřních systémů organizace. Nejčastěji se jedná o elektronickou spisovou službu.
- Musí být ohlášen v rejstříku SPUÚ v registru práv a povinností. Zde je možnost kontroly https://rpp-ais.egon.gov.cz/AISP/verejne/katalog-spuu.
- Ohlášení do rejstříku SPUÚ probíhá pomocí agendového informačního systému působnostního viz https://rpp-ais.egon.gov.cz/AISP/. Do tohoto systému má přistup každý ohlašovatel agendy.
- Pokud tedy existuje agenda, v rámci které je SPUÚ oprávněn čerpat údaje ze základních registrů nebo z agendového informačního systému, je třeba kontaktovat správce agendy a požadovat zavedení do rejstříku SPUÚ.
- Pokud není soukromoprávní uživatel údajů ohlášen v AISP a správce agendy, ani jiné OVM, jej ohlásit nechce, může SPUÚ kontaktovat správce Registru práv a povinností (posta@mvcr.cz) se žádostí o ohlášení do rejstříku SPUÚ s těmito údaji (Název organizace, adresa organizace, IČO, DIČ, zákon a paragraf opravňující k přístupu do základních registrů nebo agendovému informačnímu systému, kontaktní osoba)
- Musí být ohlášen jako kvalifikovaný poskytovatel služeb online služeb (dále též Service Provider). Více také zde https://www.eidentita.cz/Home/Ovm. Ohlášení může proběhnout automatizovaně skrze formulář, pokud to umožňuje typ zřízení datové schránky (typ 10, 14, 15, 16). Pokud žadatel tento typ nemá, je nutné kontaktovat Správu základních registrů skrze datovou schránku napřímo s požadavkem obsahujíc všechny údaje, jako v případě automatizovaného způsobu:
- IČO subjektu
- Název kvalifikovaného poskytovatele (SeP)
- Popis kvalifikovaného poskytovatele
- URL adresa odkazující na úvodní webové stránky
- URL adresa pro odeslání požadavků
- Adresa pro příjem vydaného tokenu (URL)
- URL adresa, na kterou bude uživatel přesměrován při odhlášení z Vašeho webu
- Načtení certifikátu
- Adresa pro načtení veřejné části šifrovacího certifikátu z metadat (URL). Touto veřejnou částí budou šifrována data v tokenu
- Logo kvalifikovaného poskytovatele
- Musí umět přijímat a zpracovávat data pomocí standardů SAML2 nebo WS-Federation
Postup činností práce s klientem, jeho identifikací a výběrem služeb
- Portál SPUU nemusí být ISVS
- Klienti se připojující přes NIA jsou identifikováni pomocí BSI do doby, než si klient zvolí veřejnoprávní službu
- Pro potřeby doptání se dalších údajů, musí využít ISVS (možno i jiného OVS vykonávající danou agendu), kterému předá BSI uživatele. Předávání údajů mezi SPUU a OVS musí být legislativně podchyceno
- SPUU dá klientovi vybrat, do jaké role chce obsadit
- Po dokončení služby si SPUU nepamatuje údaje použité pro službu, pokud to nevyžaduje specifické zmocnění
- SPUU si pamatuje BSI pro klientský profil na portále
- Soukromoprávní služby se řídí vlastními specifickými pravidly!
Přístupnost informací
The description of the architecture of the office and public administration of the Czech Republic by individual layers of architecture and the incorporation of requirements into the information concept and architecture of the office is described in Architecture of the office in the context of public administration and its layers of architecture.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
e-invoicing
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Citizen and Public Portal
The description of the architecture of the office and public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
National Identity Authority
The description of the architecture of the authority and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its architecture layers.
Rules for individual shared services, functional units and thematic areas are described in How individual offices use shared services, functional units and thematic areas
Popis Národní identitní autority
Národní identitní autorita vytváří federativní systém zajišťující orgánům veřejné správy státem garantované služby identifikace a autentizace, který se skládá z následujících komponent:
- Národní bod pro identifikaci a autentizaci jako centrální bod federativního systému, který zajišťuje komunikaci a registraci účastníků federace. Tato komponenta zajišťuje současně vždy jednoznačné ztotožnění osoby, která prokazuje svoji totožnost s využitím autentizačních prostředků (prostředků pro elektronickou identifikaci). Je definován v zákoně č. 250/2017 Sb. jakožto informační systém veřejné správy podporující proces elektronické identifikace a autentizace prostřednictvím kvalifikovaného systému elektronické identifikace. Zajišťuje orgánům veřejné správy státem garantované služby identifikace a autentizace včetně federace údajů o subjektu práva ze základních registrů a možnost předávání přihlašovací identity dle principy Single Sign-On.
- Kvalifikovaný správce, který vydává jednoznačně identifikovaným fyzickým osobám prostředky pro vzdálenou autentizaci (prokázání totožnosti) a provádí veškeré činnosti spojené se správou těchto prostředků a prokazováním totožnosti fyzické osoby, tj. spravuje kvalifikovaný systém elektronické identifikace.
- Kvalifikovaný poskytovatel online služeb, který připojuje k Národnímu bodu online služby, ke kterým je vyžadováno přihlášení prostředky vydanými kvalifikovanými správci.
- Základní registry, které poskytují jednoznačnou identifikaci osoby a zajištění vazeb této osoby vůči referenčním údajům o osobě.
- Národní uzel eIDAS, který je samostatnou součástí Národního bodu a zajišťuje přijímání vzdáleného prokázání totožnosti z ohlášených systémů dle nařízení eIDAS a předávání vzdálené identifikace a autentizace z České republiky ostatním státům EU. Ostatní státy EU musí akceptovat české identity od 13.9.2020, kdy vypršela roční lhůta pro zavedení akceptace ohlášeného prostředku elektronického občanského průkazu.
Pro osoby uvedené v ROB přihlašující se prostředky pro elektronickou identifikaci vydanými v ČR nebo přihlašující se identitou v rámci eIDAS z členských států EU nemusí OVS řešit přihlašovací identity pro své klienty samo.
- V současném stavu ROB (stav As-Is) tedy pouze pro občany ČR a cizince s trvalým/přechodným pobytem (cizinec musí být evidován v ROB).
- V budoucím stavu (stav To-Be) pro občany ČR, cizince s trvalým/přechodným pobytem a jiné fyzické osoby (EjFO), které mají k ČR právní či majetkový vztah (zahraniční vlastník nemovitosti, zahraniční lékař, zahraniční student, apod.).
Ačkoliv nyní poskytuje NIA své služby pouze jako "Front-end" řešení za pomoci SAML tokenů, je plánováno i poskytování služeb jako "Back-end" pro využití překladů identity a identifikátorů za pomoci eGON služeb.
Seznam poskytovatelů identity (Identity Provider; IdP)
| Název identitního prostředku | Typ prostředku | úroveň záruky prostředku (LoA) | Popis | URL | Použití pro mezinárodní ověření identity v eIDAS |
|---|---|---|---|---|---|
| eObčanka | Elektronický občanský průkaz s aktivovanou částí elektronické identifikace | Vysoká (nejvyšší možná dle eIDAS) | Přihlášení prostřednictvím nového občanského průkazu vydaného po 1. 7. 2018, který obsahuje čip a jeho elektronická funkcionalita byla aktivována. Pro přihlášení tímto občanským průkazem je zapotřebí čtečka dokladů a nainstalovaný příslušný software. | https://info.identitaobcana.cz | ANO - eObčanka je zatím jako jediný prostředek ohlášen dle eIDAS pro potřeby mezinárodní identifikace a autentizace. Její použití je pro ostatní státy v rámci eIDAS povinné k použití od září 2020. |
| Mobilní klíč eGovernmentu | Mobilní aplikace s funkcí ověřování QR kódů | Značná | Mobilní klíč eGovermentu představuje využití přihlašování bez potřeby zadávání dalších ověřovacích kódů. Po jeho instalaci a aktivaci Vám bude umožněno přihlašování ke službám využívajícím elektronickou identifikaci prostřednictvím Národního bodu. Aby vše fungovalo, je nutné mít nainstalovanou aplikaci mobilního klíče na svém mobilním zařízení. Aplikace mobilního klíče je shodná se stávající aplikací mobilního klíče ISDS. Pokud již vlastníte tuto aplikaci pro přihlašování k datovým schránkám, aktualizací této aplikace získáte i možnost využít ji i pro přihlašování ke službám prostřednictvím Národního bodu. Tento prostředek nevyžaduje od uživatele zadávat při jeho použití žádné hodnoty, stačí pouze vyfotit QR kód mobilním zařízením, anebo jej nechat přečíst z obrazovky téhož mobilního zařízení. Mobilní klíč má dále jednu mimořádnou vlastnost, kterou ostatní prostředky nemohou nabídnout. Díky svému propojení s jádrem systému Národního bodu (NIA) dovoluje zapnout notifikaci přihlášení i jakýmkoliv jiným prostředkem téhož uživatele. To je výrazný bezpečnostní prvek, který dovoluje uživateli být v reálném čase informován o tom, že případně někdo jiný nějaký jeho prostředek zneužil a přihlásil se jím. | https://info.identitaobcana.cz/mep/ | NE |
| NIA ID | Jméno + heslo + sms. Klasické přihlašování pomocí druhého faktoru. | Značná | Přihlášení prostřednictvím uživatelského jména a hesla, které jste zadali při založení Vašeho identifikačního prostředku na portálu národního bodu. Přihlášení dokončíte zadáním ověřovacího kódu, který Vám bude zaslán ve formě SMS na Vaše telefonní číslo. | https://info.identitaobcana.cz/ups/ | NE |
| První certifikační autorita, a.s. | Čipová karta Starcos s identifikačním certifikátem | Vysoká (nejvyšší možná dle eIDAS) | Přihlášení prostřednictvím čipové karty Starcos společnosti První certifikační autorita, a.s., která byla použita pro generování a uložení privátního klíče identitního komerčního certifikátu. Pro přihlášení budete potřebovat čtečku čipových karet (pokud není integrována do PC/NTB) a nainstalovaný ovládací software SecureStore (ke stažení z www.ica.cz). | https://www.ica.cz/ica-identity-provider | NE |
| MojeID - úroveň "značná" | Přihlašovací údaje do účtu MojeID spárovaný s prostředkem FIDO | Značná | Přihlášení prostřednictvím účtu mojeID. Pro přihlášení je potřeba zabezpečit účet bezpečnostním klíčem (tokenem) certifikovaným od FIDO Alliance alespoň na úroveň L1, a to buď fyzickým (USB, NFC, Bluetooth), anebo systémovým (Windows Hello, Android v. 7 a vyšší). Dále je nutné mít účet mojeID aktivován pro přístup ke službám veřejné správy a jednorázově ověřit svou totožnost (již existujícím prostředkem nebo návštěvou Czech POINTu). Službu mojeID provozuje CZ.NIC, správce domény .CZ. | https://www.mojeid.cz/ | NE |
| MojeID - úroveň "vysoká" | Přihlašovací údaje do účtu MojeID spárovaný s prostředkem FIDO | Vysoká | Přihlášení prostřednictvím účtu mojeID. Pro přihlášení je potřeba zabezpečit účet bezpečnostním klíčem (tokenem) certifikovaným od FIDO Alliance alespoň na úroveň L1, a to fyzickým USB, NFC. Dále je nutné mít účet mojeID aktivován pro přístup ke službám veřejné správy a jednorázově ověřit svou totožnost (již existujícím prostředkem nebo návštěvou Czech POINTu). Službu mojeID provozuje CZ.NIC, správce domény .CZ. | https://www.mojeid.cz/ | NE |
| IIG - International ID Gateway | Výběr z možných identitních prostředků, které jsou ohlášené jinými členskými státy EU v rámci eIDAS uzlů | nízká až vysoká dle daného prostředku | Aktuálně je možné v rámci eIDAS uzlů vybírat z prostředků, které jsou zveřejnyny na stránkác eIDAS https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS | NE | |
| Bankovní identita | Identita poskytovaná Československou obchodní bankou, a. s. | Značná | https://www.csob.cz/portal/csob/csob-identita | Ne | |
| Identita poskytovaná Českou spořitelnou, a. s. | Značná | https://www.csas.cz/cs/o-nas/bezpecnost-ochrana-dat/bankovni-identita | Ne | ||
| Identita poskytovaná Bankou CREDITAS a.s | Značná | https://www.creditas.cz/ | Ne | ||
| Identita poskytovaná Komerční bankou, a. s. | Značná | https://www.kb.cz/cs/podpora/bankovnictvi-a-nastroje/kb-bankovni-identita | Ne | ||
| Identita poskytovaná Air Bankou, a. s. | Značná | https://www.airbank.cz/produkty/bankovni-identita/ | Ne | ||
| Identita poskytovaná Fio Bankou, a. s. | Značná | https://www.fio.cz/bankovni-sluzby/bankovni-identita | Ne | ||
| Identita poskytovaná MONETA Money Bank, a. s. | Značná | https://www.moneta.cz/otevrene-bankovnictvi/bankovni-identita | Ne | ||
| Identita poskytovaná Raiffeisenbank, a.s. | Značná | https://www.rb.cz/informacni-servis/pro-media/tiskove-zpravy/tiskove-zpravy-2021/tiskove-zpravy-202109/01092021-bankovni-identita | Ne | ||
| Identita poskytovaná UniCredit Bank Czech Republic and Slovakia, a.s. | Značná | https://www.unicreditbank.cz/cs/obcane/bankID.html | Ne |
Statistiky využití identitních prostředků
Data jsou informativní a platná k datu 1.8.2024
Celkové statistiky identitních prostředků
| Celkem ID prostředků | 16 255 473 |
| Počet profilů alespoň s jedním aktivním prostředkem | 6 685 202 |
| Celkový počet unikátních přihlášení | 3 532 312 |
| Konverze - procentuální zastoupení těch, kdo se skutečně přihlásili z těch, kdo se přihlásit mohli | 52.84 % |
Statistika za jednotlivé poskytovatele služeb
Seznam poskytovatelů služeb (Service Provider; SeP)
Poskytovatelů služeb je již více než 50 a v přípravě jsou další. Konečný počet je v řádu stovek. Aktuální seznam je dostupný zde https://info.identitaobcana.cz/sep/.
Podobně jako jsou jiné státy v rámci eIDAS povinni přijímat české ohlášené prostředky identity (eObčanka), jsou čeští poskytovatelé služeb povinni akceptovat identitu ohlášenou jiným státem v rámci eIDAS. Povinnost umožnit přihlášení pomocí IIG - International Identity Gateway je všem poskytovatelům služeb zapnuta od 30.6.2020. Současné znění nařízení eIDAS, povinuje členské státy, které oznámily systém elektronické identifikace, aby zajistily jedinečnou identifikaci osoby.
Nicméně je vhodné na tomto místě upozornit, že pomocí údajů obdržených na základě využití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace, nemusí být vždy možné udělat jednoznačný „identity matching“ – tj. jednoznačné ztotožnění osoby, která se přihlašuje pomocí „zahraničního“ prostředku pro elektronickou identifikaci s údaji, které vede poskytovatel online služeb. Pro účely „identity matchingu“ by pak mohl posloužit také údaj(či údaje), který by musel zadat sám uživatel. Nejlépe samozřejmě údaj, který by měl být znám ze své podstaty pouze samotnému uživateli. Výše uvedené vychází z předpokladu spolehnutí se na základní osobní údaje obdržené na základě využití prostředku pro elektronickou identifikaci a na údaj (či údaje), které doplní sám uživatel. Seznam dostupných atributů u jednotlivých ohlášených systému elektronické identifikace je k dispozici na: https://ec.europa.eu/digital-building-blocks/sites/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS.
Atributy vydávané poskytovatelům služeb (Service Providerům; SeP)
Následující atributy jsou NIA vydávány tzv. kvalifikovaným poskytovatelům služby. Problematika je popsána také v části Portály veřejné správy a soukromoprávních uživatelů údajů. Tučně označené atributy odpovídají standardu eIDAS, ostatní atributy sice standardu neodpovídají, kvalifikovaný poskytovatel služby má ale možnost při komunikaci v rámci ČR o jejich vydání zažádat.
| Atribut/Element | Název atributu | Popis |
|---|---|---|
| Příjmení | CurrentFamilyName | Referenční údaj – Příjmení fyzické osoby. Viz eIDAS reference. |
| Jméno | CurrentGivenName | Referenční údaj – Jméno, případně jména fyzické osoby. Viz eIDAS reference. |
| Datum narození | DateOfBirth | Referenční údaj – Datum narození fyzické osoby. Viz eIDAS reference. |
| Místo narození | PlaceOfBirth | Referenční údaj – Místo narození fyzické osoby. Viz eIDAS reference. |
| Země narození | CountryCodeOfBirth | Referenční údaj – Země narození fyzické osoby, předávána v kódu podle standardu ISO 3166-3. |
| Adresa pobytu | CurrentAddress | Referenční údaj – Adresa pobytu fyzické osoby, je předávána zakódovaná pomocí BASE64. Obsahuje (pokud je uvedeno v ROB) název ulice (Thoroughfare), název pošty (PostName), PSČ (PostCode), název obce, případně doplněnou o část obce (CvaddressArea) a číslo domovní/číslo orientační (LocatorDesignator). Atribut vychází z ISA Core Vocabulary a tam je také uveden podrobnější popis atributu. |
| Emailová adresa uvedená na Portálu NIA (přihlášení na identitaobcana.cz) v sekci „Vaše údaje“. | ||
| Je starší než X | IsAgeOver | Výpočet je starší než X podle referenčního údaje Datum narození. |
| Věk | Age | Výpočet věku podle referenčního údaje Datum narození. |
| Telefon | PhoneNumber | Telefonní číslo uvedeno na identitaobcana.cz v sekci „Vaše údaje“. |
| Adresa pobytu (předávaná v podobě RÚIAN kódů) | TRadresaID | Referenční údaj – Adresa pobytu fyzické osoby je předávána v kódech podle RUIAN. Obsahuje (pokud je uvedeno v ROB) kódy pro okres, obec, část obce, ulici, PSČ, stavební objekt, adresní místo, číslo domovní a orientační. |
| Level of Assurance (LoA) | LoA | Stupeň (úroveň) jistoty nebo zajištění. Viz eIDAS reference. |
| Pseudonym | PersonIdentifier | Identifikátor fyzické osoby. |
| Typ dokladu | IdType | Druh elektronicky čitelného dokladu. |
| Číslo dokladu | IdNumber | Číslo elektronicky čitelného dokladu. |
Při použití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace se množina osobních údajů (v případě fyzických osob) skládá minimálně z následujících údajů:
- příjmení,
- jméno,
- datum narození a
- unikátního identifikátoru (pseudonymu).
Seznam dostupných atributů u jednotlivých ohlášených systému elektronické identifikace je k dispozici na: https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+available+attributes+of+pre-notified+and+notified+eID+schemes.
Při použití prostředku pro elektronickou identifikaci vydaného v rámci „zahraničního“ oznámeného systému elektronické identifikace nicméně není možné využít služby základních registrů E226 eidentitaCtiAifo pro překlad pseudonymu na AIFO dané agendy.
Pseudonym - bezvýznamový směrový identifikátor
Pseudonym při použití prostředku pro elektronickou identifikaci vydaného v ČR, neboli bezvýznamový identifikátor fyzické osoby, který se od NIA předává je pro každého kvalifikovaného poskytovatele služby, je jedinečný a neměnný. Neslouží jako veřejný identifikátor, ale jako identifikátor technický. Pokud by došlo na situaci, kdy se pseudonym pro fyzickou osobu změní, bude úřad o této skutečnosti informován prostřednictvím informačního systému základních registrů, protože se mu změní i agendový identifikátor fyzické osoby. Soukromoprávní uživatel údajů o této změně nebude notifikován, protože nemůže být napojen na základní registry nepřímo, avšak tuto službu mu může zprostředkovat jeho nadřízený úřad.
Pokud však chce mít kvalifikovaný poskytovatel služby jistotu o aktuálnosti pseudonymu, musí postupovat dle pravidel propojeného datového fondu, tzn. mít ztotožněn svůj datový kmen a odebírat notifikace z informačního systému základních registrů.
Nevizuální přihlašování z mobilních aplikací
Principem tzv. nevizuálního přihlašování je uspořádání, kdy konkrétní instance aplikace daného uživatele byla jednorázově zaregistrována v Národním bodu (NIA), prostřednictvím klasického vizuálního přihlášení. Pro běžné použití této aplikace pak stačí ověření uživatele při vstupu do této mobilní aplikace (typicky otisk prstu, fotografie obličeje, nebo PIN). Jakmile se uživatel dostane do mobilní aplikace a ta zjistí, že od posledního přihlášení k NIA uběhla více než určitá doba (vývojářům aplikace je doporučeno dodržovat hodnotu 24 hodin), provede aplikace automatické přihlášení daného uživatele k NIA a to způsobem, který nevyžaduje žádnou jeho interakci. Tímto způsobem se mobilní aplikace dozví o možné změně údajů daného uživatele, ke které mezitím v ROB mohlo dojít, například změna příjemní atp. Uživatel má dále možnost vyhledat si v konfiguraci NIA seznam, zobrazující které mobilní aplikace má připojené v režimu nevizuálního přihlašování a z jakého zařízení. V případě potřeby (například ztráty svého mobilního telefonu) je pak možno v tomto seznamu konkrétní aplikaci odpojit. Aby se tento fakt mobilní aplikace dozvěděla a uvedla sama sebe do nezaregistrovaného stavu, je mobilní aplikace povinna v pravidelných intervalech volat příslušnou službu. Doporučená hodnota periodicity tohoto volání je vývojářům mobilní aplikace doporučena v úrovni 60 minut.
NIA poskytuje soubor rozhraní, které mají za cíl umožnit poskytovatelům služeb (SeP) vytvoření takových vlastních mobilních aplikací a vlastních backendových API, které dohromady budou umět ověřit identitu občana prostřednictvím volání webových služeb, tedy nevizuálně bez interakce občana.
Původně generická Mobilní aplikace bude muset být uživatelem nejprve registrována k užívání a následně bude umožňovat opakované přihlašování k NIA nevizuálním způsobem. Mobilní aplikace bude předávat informaci o provedeném přihlášení do API poskytovatele služeb, které následně z NIA získá JSON Web Token s detaily o přihlášeném uživateli. Fakt registrace bude opakovaně kontrolován na NIA prostřednictvím procesů mobilní aplikace a API, aby uživatel mohl např. při ztrátě zařízení možnosti nevizuálního přihlašování zabránit.
Cílem funkcionality není, aby mobilní aplikace poskytovatele služeb byla na úrovni poskytovatele identity (není to Identity provider). Není ji tedy možné používat pro přihlašování k portálům a jiným službám ostatních poskytovatelů služeb.
Více viz popis na stránkách SZR ČR.
Pravidla pro Národní identitní autoritu
Zásadním požadavkem bezpečnosti a transparentnosti pro informační systémy veřejné správy je požadavek na jednotnou elektronickou identifikaci externích uživatelů. Pro každou operaci je nutná znalost osoby, která tuto operaci provádí zvláště z hlediska nepopiratelné zodpovědnosti osoby. Externí uživatelé (klienti) informačních systémů veřejné správy musí být jednoznačně identifikováni zvláště z důvodů ochrany osobních údajů a dále z procesního hlediska, jak předpokládá správní řád (jednoznačné prokázání totožnosti účastníků řízení).
Úloha správy přístupů se pro každý informační systém veřejné správy skládá z následujících kroků:
- Identifikace – jednoznačné a nepopiratelné určení fyzické osoby, která přistupuje k informačnímu systému veřejné správy
- Autentizace – prokázání, že přistupující osoba je tou osobou, za kterou se vydává. Autentizace probíhá předložením autentizačních prostředků (například uživatelské jméno a heslo, autentizační certifikát), které osobě přidělil správce informačního systému
- Autorizace – na základě údajů o identifikované a autentizované osobě a dalších údajů o této osobě (například zařazení na pracovní pozici) zařazení osoby do odpovídající role a z toho vyplývající vyhodnocení oprávnění na úkony a data v rámci informačního systému.
NAP v této oblasti vyžaduje naplnění následujících principů pro všechny informační systémy veřejné správy:
- Každý úřad, který poskytuje své služby elektronicky, potřebuje svého klienta ověřit (ztotožnit) s využitím kvalifikovaného systému elektronické identifikace, jehož služby jsou poskytovány Národní identitní autoritě. Ověření totožnosti vyžaduje právní předpis nebo výkon působnosti.
- Pro využití Národní identitní autority se musí organizace stát tzv. kvalifikovaným poskytovatelem služeb (Service provider; SeP), dle postupu popsaném níže.
- Každý úřad musí akceptovat nejen identitu českého občana, ale kteréhokoliv občana Evropské Unie dle eIDAS.
- Jakýkoliv nový identitní prostor musí být budován tak, aby byl federovaný v rámci Národní identitní autority.
- Před tvorbou nového identitního prostoru je potřeba si prvně udělat analýzu, zda nepostačuje některý z federovaných identitních prostředků v rámci Národní identitní autority.
- Prostředky pro identifikaci a autentizaci jsou vždy vydány bezpečnou a jednoznačnou cestou identifikované osobě tak, aby byla zajištěna minimální úroveň důvěry. O vydání prostředků existuje trvalý záznam spolu s údaji, jak byla ověřena identita osoby.
- Osoba, jíž byly prostředky vydány, zachází s prostředkem s náležitou péčí tak , aby nedošlo k jeho zneužití či odcizení.
- Osoba, jíž byly prostředky vydány, nese nedílnou zodpovědnost za všechny úkony, které byly v informačním systému provedeny při použití těchto prostředků.
- Věcný správce agend, které jsou vykonávány v rámci informačního systému, zodpovídá za obsazení osob do rolí (technicky vykonává technický správce informačního systému, vždy však na základě podkladů věcných správců). Tuto svoji zodpovědnost může delegovat v rámci organizační struktury na více zodpovědných osob.
Postup ohlášení kvalifikovaného poskytovatele služby (Service provider; SeP)
Následující kroky popisují jednotlivé části procesu, který je naznačen níže, na základě ověření přes ISDS. Aktuálně je registrace organizace prostřednictvím portálu národního bodu přístupná pouze pro orgány veřejné moci, ostatní subjekty musí provést registraci přímo u Správy základních registrů (viz krok 8). Kompletní příručka je dostupná zde.
- Uživatel jako zástupce organizace požaduje po portálu národního bodu, který je Service Providerem, službu umožňující registraci dané organizace. Tato registrace umožní fungování dané organizace v NIA a vytváření jednotlivých Service Providerů.
- Portál národního bodu kontaktuje Národní identitní autoritu, která ověření zprostředkovává, s požadavkem na ověření dané osoby (uživatele).
- Pro ověření uživatele pro registraci organizace či konfigurací jednotlivých Service Providerů je jako Identity Provider určen Informační systém datových schránek (ISDS). Národní identitní autorita provede přesměrování na přihlášení prostřednictvím datových schránek.
- Uživatel provede ověření vlastní osoby přihlášením k datovým schránkám. Aby mohl uživatel registrovat organizaci na portálu národního bodu, musí být přihlášen prostřednictvím ISDS (v definované roli a typem schránky OVM). V případě, že organizace není OVM, je potřeba provést registraci u Správy základních registrů.
- V případě, kdy je uživatel úspěšně ověřen, Informační systém datových schránek předá Národní identitní autoritě jako výsledek ověření autentizační token obsahující IČO a název subjektu, roli přihlašovaného uživatele a další atributy.
- Národní identitní autorita provede sběr atributů v Informačním systému základních registrů (ISZR) na jehož základě následně provede kontrolu existence IČO.
- Národní identitní autorita předává portálu národního bodu potřebné atributy z Informačního systému základních registrů a atributy přijaté v autentizačním tokenu z Informačního systému datových schránek, které jsou nutné ke zpracování formuláře pro registraci.
- Na základě úspěšného splnění předchozích kroků umožní portál národního bodu uživateli službu registrace organizace (SeP) a zobrazí mu vyplněný formulář pro registraci. Toto platí pouze pro organizace, které jsou OVM. Není-li organizace OVM, jsou místo registračního formuláře zobrazeny podrobné informace o tom, jakým způsobem provést registraci přímo u Správy základních registrů.
- Uživatel potvrdí správnost údajů a provedení registrace organizace (SeP).
- Portál národního bodu zpracuje přijatý požadavek na registraci a po úspěšném zaregistrování umožní uživateli provést konfiguraci jednotlivých Service Providerů spadající pod danou organizaci (seznam konfigurací kvalifikovaných poskytovatelů).
- Uživatel provede konfiguraci Service Providera zahrnující následující údaje:
- IČO subjektu
- Název kvalifikovaného poskytovatele
- Popis kvalifikovaného poskytovatele
- URL adresa odkazující na úvodní webové stránky kvalifikovaného poskytovatele
- URL adresa pro odeslání požadavků
- Adresa pro příjem vydaného tokenu
- URL adresa, na kterou bude uživatel přesměrován při odhlášení z Vašeho webu
- Načtení certifikátu
- Adresa pro načtení veřejné části šifrovacího certifikátu z metadat
- Zpřístupnění autentizace prostřednictvím brány eIDAS
- Logo kvalifikovaného poskytovatele
Příklad pro poskytovatele zdravotních služeb
Poskytovatel zdravotních služeb není orgán veřejné moci, a proto je třeba zajistit kromě výše uvedeného postupu i následující kroky:
- Požádat Ministerstvo zdravotnictví o zavedení do registru práv a povinností jako SPUÚ dle povinností vyplývající ze zákonů č. 250/2017 Sb. a č. 372/2011 Sb., ideálně pod agendou A1086
- Na adrese https://www.identitaobcana.cz/Home/Ovm se přihlásit jako oprávněný uživatel datovou schránkou poskytovatele zdravotních služeb
- Nově by se mělo nabídnout ruční zadání údajů s dalším postupem
- Pokud se neobjeví, postupovat dle obecných bodů výše – poslání datové zprávy obsahující potřebné údaje (URL, logo….)
- Upravit si svůj profil na https://www.identitaobcana.cz/Home/Ovm pro přístup jiných osob (IT oddělení např.) a správu svého profilu, konfigurovat pro Portál pacienta poskytovatele zdravotních služeb.
Podmínky pro nevizuální přihlašování
Přihlašování z mobilních aplikací je založeno na následujících předpokladech:
Poskytovatel služby musí
- vytvořit svoji mobilní aplikaci
- vytvořit svoje API
- zabezpečit komunikace mezi svým API a mobilní aplikaci
- provést registraci svého API a mobilní aplikace v NIA
- definovat a zaregistrovat sadu atributů, které budou obsahem JWT (JSON Web Token)
- zajistit komunikaci mezi API a NIA pro vyzvedávání JWT
NIA poskytuje
- rozhraní pro interaktivní přihlášení
- rozhraní pro registraci mobilní aplikace
- rozhraní pro přihlášení mobilní aplikace
- rozhraní pro API, které si z NIA vyzvedne JWT
Uživatel
- musí mít platný a funkční profil NIA a musí mít k dispozici, alespoň jeden platný přihlašovací prostředek, např. mobilní klíč eGovernmentu anebo bankovní identitu,
- nainstaluje si mobilní aplikaci od poskytovatele služby,
- po prvním spuštění aplikace provede interaktivní přihlášení přes NIA, které zajistí registraci aplikace v NIA,
- podle potřeby bude opakovat interaktivní přihlášení z aplikace, pokud z nějakého důvodu bude registrace v NIA zrušena/zneplatněna (změna konfigurace SePa anebo každých 6 měsíců).
Po registraci mobilní aplikace může provést přihlášení k NIA. Výsledkem přihlášení je tzv. access token, který mobilní aplikace předá komponentě (API) poskytovatele služeb. Tato komponenta (API) následně zavolá definované rozhraní NIA, kde předá access token a své přihlašovací údaje. Na základě tohoto volání NAI provede vydání JWT.
Pravidla určení úrovně záruky pro poskytované služby (LoA)
Každý poskytovatel služby si sám určuje, jakou úroveň záruky (LoA) po uživateli vyžaduje1)), pokud neexistuje právní předpis, který by výslovně stanovoval úroveň záruky. Ideální stav je, že toto určení je provedeno pro každou jednotlivou službu, která se na portále poskytuje. Protože se však typicky uživatel předem nehlásí k jedné jednotlivé službě, ale k portálu jakožto agregaci více služeb, má poskytovatel služeb následující možnost:
- Nastaví úroveň záruky podle nejčastěji využívaných služeb nebo dle nejčetnější úrovně záruky u nabízených služeb. Tato možnost zajistí, že uživateli bude po autentizaci dostupná většina služeb a zároveň se po uživateli nepožaduje prostředek s vysokou úrovní záruky. Pokud však uživatel chce využít služby s vyšší úrovní záruky, než použil při původní autentizaci, měl by být uživatel vyzván k autentizaci prostředkem s vyšší úrovní záruky.
- Nenastaví žádnou vstupní úroveň záruky. Tato možnost zajistí, že se uživatel autentizuje na daný portál jakýmkoliv identitním prostředkem NIA a až následně se při výběru služby uživatelem kontroluje, zda je pro ni splněna minimální úroveň záruky. Pokud není, měl by být uživatel vyzván k autentizaci prostředkem s vyšší úrovní záruky.
- Potřebnou úroveň záruky nastaví podle nejpřísnější služby. Tato možnost zajistí, že uživatel bude moci vždy využít všechny služby, které jsou na portále dostupné k vyřízení. Nevýhodou je, že se po uživateli může vyžadovat zbytečně vysoká úroveň záruky, kterou nemusí disponovat prostředky, které vlastní.
Pro jakoukoliv zvolenou variantu z pohledu poskytovatele služeb však platí několik povinností:
- Požadovaná úroveň záruky u jednotlivých služeb odpovídá informacím uvedených v katalogu služeb a v případném právním předpise, který výslovně stanovuje úroveň záruky.
- Uživateli autentizovaném s nižší úrovní záruky se neskrývá nabídka služeb vyžadující vyšší úroveň záruky.
Podstatné otázky a odpovědi na využívání NIA
Otázky týkající se Centrálního registru životního prostředí
Otázky týkající se přihlašování uživatelů do systémů Centrální registr životního prostředí, potažmo Integrovaného systému ohlašovacích povinností. Předání proběhlo přípisy Ministerstva životního prostředí:
- ze dne 19. ledna 2024, sp. zn. ZN/MZP/2024/280/6, odpověď DIA byla poskytnuta pod sp. zn. DIA- 2188-2/OPL-2024
- ze dne 21. listopadu 2023, sp. zn. MZP/2023/110/787, odpověď DIA byla poskytnuta pod sp. zn. DIA- 16244-2/OHA-2023
Žádám o doložení právního předpisu nebo o doložení faktu, že výkon působnosti vyžaduje prokázání totožnosti fyzické osoby. Zákon č. 250/2017 Sb., §2 říká, že pokud je nutné prokázání totožnosti, lze to pouze prostřednictvím kvalifikovaného systému. Neříká však, že ISPOP má právo vyžadovat identifikaci fyzické osoby. Roční hlášení je prováděno za právnickou osobu, nikoli za fyzickou.
Jak je vysvětleno výše, pokud agendový zákon neomezí způsob činit podání, je nutné se řídit obecnou úpravou podání uvedenou ve správním řádu, která je pro elektronické podání upravena zejména v ZoPDS a dalších speciálních předpisech. Informační systém veřejné správy je pouze jednou z možností, jak činit podání vůči orgánu veřejné správy. Pokud je agendovým zákonem stanoveno, že se podání vůči orgánu veřejné správy činí prostřednictvím informačního systému veřejné správy dle § 4 odst. (1) písm. d) ZoPDS, je nutné, aby se fyzická osoba, která za povinný subjekt jedná, přihlásila do informačního systému veřejné správy prostřednictvím identity občana, jak ostatně vyplývá také z § 2 ZoEI. V takovém případě pak není nutné podání ani podepisovat, jelikož se uplatní fikce podpisu dle § 8 zákona č. 365/2000 Sb., o informačních systémech veřejné správy.
Identitu občana nemám a nebudu si ji zřizovat, takovou povinnost jako občan nemám, jak se mám nadále přihlašovat?
V případě, kdy agendový zákon omezí způsob činit podání vůči orgánu veřejné správy pouze na elektronickou podobu (a agendový zákona nijak blíže neurčuje závaznou podobu úkonu a jeho podání), je možné úkon činit nejen za použití informačního systému, ale dále též např. prostřednictvím datové schránky či sítě elektronických komunikací za použití uznávaného elektronického podpisu dle §4 odst. (1) ZoPDS. Fyzická osoba jednající jménem PO není povinna si pořizovat identitu občana. Identita občana, resp. elektronická identifikace, je obecně pouze jednou z možností, jak učinit podání vůči orgánům veřejné moci.
Nebudu identitu občana využívat v rámci plnění pracovních povinností. Z jakého důvodu by řadoví zaměstnanci měli používat svoji Identitu občana pro plnění zákonných povinností svého zaměstnavatele? Proč není dostačující současný způsob přihlašování do systémů CRŽP? Proč je zásadní znát totožnost ohlašovatele/zaměstnance právnické osoby při takových úkonech jako je ohlášení produkce odpadů?
Využití identity občana je pouze jednou z možností, jak činit úkony vůči orgánům veřejné správy. Zajištění potřebných nástrojů pro plnění povinností povinného subjektu vyplývajících z agendových zákonů by mělo být primárně povinností konkrétního subjektu, na který plnění zákonných povinností dopadá. Pokud zaměstnanci povinného subjektu odmítají využívat či si pořídit identitu občana, měl by jim subjekt, za který mají jednat, umožnit užití datové schránky či zprostředkovat vydání certifikátu pro uznávaný elektronický podpis.
Pokud si propojím Identitu občana ke svému účtu v ISPOP, jak to pak funguje ohledně pokut atp.? Nemůže se stát, že firma bude po mě vymáhat zaplacení pokuty nebo nějakého poplatku, kterou obdrží, na základě podaného hlášení, když tam teď bude moje identita? Předtím to byl účet firemní a bral jsem to jako hlášení za firmu, teď to bude hlášení s mojí identitou.
Odpovědnost fyzické osoby (FO) za digitální úkony činěné v zastoupení právnické osoby (PO) je shodná, jako v případě úkonů činěných v listinné, nedigitální formě. Pokud FO činí úkon vůči orgánu veřejné moci svým jménem, ale v zastoupení a při plnění povinnosti stanovené PO, tak její odpovědnost za toto právní jednání není neomezená, ale odvíjí se od právního titulu, kterým je FO oprávněna za PO jednat. Ať už se jedná například o jednatele uvedeného v Obchodním rejstříku, zaměstnance pověřeného k určitým úkolům nebo zmocněnce na základě plné moci, odvíjí se odpovědnost této FO od konkrétního právního titulu a způsobené škody.
Do SEPNO ohlašuji automatizovaně ze SW přes účet, který jsme si zřídili jako systémový (tzn. pro komunikaci systém-systém), vztahuje se povinnost i na tyto účty? Lze i nadále využívat přihlašování přes Jméno + Heslo + 2. faktor?
Není-li nutné prokazovat totožnost, tak není povinnost využívat identitu občana. Komunikace mezi systémy nevyžaduje prokazování totožnosti, ovšem když je potřeba například zřídit danou komunikaci (vystavení či evidence systémového certifikátu) je nutné tuto službu obsloužit s prokázanou totožností, a tedy i využitím identity občana.
Jakým způsobem je zajištěna bezpečnost úniku dat z identity občana, může zaměstnavatel přikázat zaměstnancům, ať poskytnou svoje osobní údaje? Nedojde tím k porušení zákona GDPR?
Při přihlášení do informačního systému veřejné správy za použití identity občana uživatele přesměruje na Národní bod pro identifikaci a autentizaci (NIA), kde jsou popsány předávané osobní údaje, způsob jejich předání, důvod jejich zpracování, a osoba je vyzvána k udělení trvalého nebo jednorázového souhlasu s jejich zpracováním. Toto řešení je v souladu s právními předpisy upravujícími zpracování osobních údajů. Více informací k této věci konec konců uvádí i MŽP v dokumentu k CRŽP dostupném na tomto odkazu.
Dle jakého konkrétního ustanovení právního předpisu je dovozována povinnost užívat Identity občana, popř. Bankovní identitu k přihlašování do systému ISPOP?
Pokud jde o předmětné ustanovení § 2 zákona č. 250/2017 Sb., o elektronické identifikaci, platí, že „Vyžaduje-li právní předpis nebo výkon působnosti prokázání totožnosti, lze umožnit prokázání totožnosti s využitím elektronické identifikace pouze prostřednictvím kvalifikovaného systému elektronické identifikace (dále jen „kvalifikovaný systém“).“ Elektronickou identifikací se podle čl. 3 odst. 1 Nařízení Evropského parlamentu a Rady č. 910/2014, o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES (nařízen eIDAS) rozumí mj. postup používání osobních identifikačních údajů v elektronické podobě, které jedinečně identifikují fyzickou osobu zastupující právnickou osobu.
Ministerstvo životního prostředí, jak sám uvádíte, je správcem obou zmíněných informačních systémů veřejné správy, správa zmíněných informačních systémů je tedy součástí výkonu jeho působnosti. Ke správě informačních systémů veřejné správy nepochybně patří též řízení přístupu k informačním systémům, které probíhá mj. požadavkem na prokázání totožnosti osob, které k těmto informačním systémům přistupují. Prokázání totožnosti je tedy vyžadováno v rámci výkonu působnosti Ministerstva životního prostředí jakožto orgánu veřejné moci a není nutné, aby bylo uvedeno v právním předpisu explicitně. Postup zjišťování totožnosti v rámci přístupu ke zmíněným informačním systémům odpovídá výše uvedené definici elektronické identifikace uvedené v nařízen eIDAS, toto nařízení zároveň počítá s tím, že svou totožnost prokazuje fyzická osoba mj. při zastupování právnické osoby.
Shrnuji, že pokud požadavek na prokázání totožnosti vyplývá z výkonu působnosti a je činěn s využitím elektronické identifikace, lze jej umožnit pouze prostřednictvím kvalifikovaného systému elektronické identifikace (označovaný též jako NIA, identita občana, atd.), nikoliv jiným způsobem, jak uvádí závěrečná část výše zmíněného zákonného ustanovení.
S ohledem na uvedené považuje Digitální a informační agentura postup Ministerstva životního prostředí za souladný s právní předpisy upravujícími elektronickou identifikaci.
Z jakého důvodu není při přihlašování zaměstnance postupováno stejně jako v případě přihlašování úřední osoby, když se vždy rovněž jedná de facto o zaměstnance?
Pokud jde o jednání při zastupování právnické osoby, je vhodné zmínit, že pokud jde fyzické prokazování totožnosti při jednání za právnickou osobu, je používání fyzických dokladů, které nepochybně nejsou vydány jen pro jednání za právnickou osobu, naprosto běžné. Např. pokud jednatel společnosti s ručením omezeným nebo jiný její zástupce jedná vůči orgánu veřejné moci za tuto společnost osobně nebo činí za tuto společnost písemné právní jednání vyžadující úředně ověřený podpis, prokáže vůči orgánu veřejné moci svou totožnost občanským průkazem nebo např. cestovním pasem, nikoliv dokladem vydaným jen pro kontext zastupování právnické osoby. Digitální a informační agentura neshledává používání kvalifikovaných prostředků elektronické identifikace v těchto situacích od používání fyzických dokladů totožnosti zásadně odlišným. V této souvislosti lze pro úplnost poukázat na to, že je rovněž běžné, že osoby, které nejsou statutárními orgány právnické osoby, ale jde o zmocněné zaměstnance či jiné zmocněné osoby, sdělují v rámci svého zastupování právnické osoby řadu osobních údajů, které se následně objevují např. ve sbírce listin obchodního rejstříku, např. datum narození nebo adresu trvalého pobytu takového zmocněnce.
Pokud jde o autentizaci, tedy o spojení totožnosti určité fyzické osoby s jejím oprávněním jednat za právnickou osobu, a s rozsahem tohoto oprávnění, je toto záležitostí nastavení předmětných informačních systémů a legislativy je upravující. Lze v tomto směru odkázat na analogii např. s nastavením přihlašování k informačnímu systému datových schránek, kdy relevantní právní úprava odlišuje osoby mající primární oprávnění přihlašovat se do datové schránky, tj. v případě právnické osoby její statutární orgán nebo členy statutárního orgánu (srov. § 8 odst. 3 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů) od osob majících odvozené oprávnění přihlašovat se do datové schránky, tj. tzv. pověřených osob (srov. § 8 odst. 6 písm. b) zákona o elektronických úkonech a autorizované konverzi dokumentů). Rovněž právní úprava přihlašování k informačním systémům v působnosti orgánů Finanční správy rozlišuje mezi primárně oprávněnými přihlašujícími se osobami a odvozeně oprávněnými přihlašujícími se osobami (zde např. daňový poradce). Používání kvalifikovaných prostředků elektronické identifikace tedy nebrání společnosti ORLEN Unipetrol RPA s.r.o., aby oprávnění k přístupu k předmětným informačním systémům udělovala a odnímala sama.
Pokud jde o vyjádření pověřence pro ochranu osobních údajů Ministerstva životního prostředí, k tomu uvádíme, že přechod z tzv. proprietární (tj. jen pro konkrétní informační systém vytvořené) elektronické identifikace je procesem postupným a nelze tedy vyloučit, že proprietární identifikace je k přístupu k některým informačním systémům stále využívána do doby zavedení přístupu výlučně prostřednictvím kvalifikovaného systému elektronické identifikace. Vyjádření pověřence pro ochranu osobních údajů Ministerstva životního prostředí je tedy vyjádřením popisu praktické implementace již účinné právní úpravy, nikoliv popis právní úpravy účinné v budoucnu.
Pokud jde o důvody, proč není postupováno stejně jako v případě úřední osoby, platí, že autentizační informační systém (JIP/KAAS) podle § 56a zákona č. 111/2009 Sb., o základních registrech, je zřízen pro ztotožnění fyzických osob, které vykonávají činnosti v agendách jako tzv. nositelé rolí. Cílem je nejen řádná autentizace těchto fyzických osob, ale též vedení řádných záznamů o využívání údajů obsažených v informačních systémech veřejné správy, a to až na úroveň konkrétní fyzické osoby, která údaje využila. Na rozdíl od elektronické identifikace určuje konkrétní fyzické osoby jakožto nositelé rolí přímo orgán veřejné moci, tyto údaje se zapisují do základního registru práv a povinností. S ohledem na výše uvedené je JIP/KAAS určen pro ztotožnění úředníků, kteří jménem orgánu veřejné moci jednají, tj. pro státní zaměstnance, zaměstnance nebo jiné osoby v podobném vztahu k orgánu. Pro úplnost dodávám, že právnická osoba nemůže být nositelem role.
Jakým způsobem se bude postupovat, pokud nastane technická porucha na straně provozovatele systému Identity občana popř. Bankovní identity a systém bude nedostupný a proto nebude možno ověřit ohlašovatele a přihlásit se zejména do systému SEPNO, kde je nutno v krátkých časových intervalech provádět ohlášení? Zákon o odpadech řeší v §79 odst. 3 pouze náhradní postup ohlašování přepravy nebezpečných odpadů při přerušení provozu ISPOP. Nedostupnost systému Identity občana popř. Bankovní identity není nikde řešena, Toto ve svém důsledku znemožní odvoz nebezpečných odpadů a způsobí provozovatelům zvýšenou administrativní i finanční zátěž.
Právní úprava postupu pro případy technických poruch není ve vztahu k elektronické identifikaci zavedena, je nicméně vhodné doplnit, že právní úprava postupu pro případy technických poruch není zavedena ve valné většině případů ani např. ve vztahu např. k technické poruše informačních systémů veřejné správy nebo datových schránek a není mi známo, že by úprava postupu pro případy technických poruch byla zavedena ve vztahu k technické poruše dosud používaných identifikačních nástrojů vůči informačním systémům zmíněným v přípisu. Právní úprava počítá s tím, že tyto nástroje budou dostupné. V případě potřeby je možné využít zmírňujících institutů podle příslušných právních předpisů, v tomto doporučujeme konzultaci s Ministerstvem životního prostředí. Upozorňuje, že v případě využití prostředku elektronické identifikace, jejichž vydavatelem je banka (tzv. bankovní identita nebo bankID), může nastat technická porucha též na straně konkrétní vydávající banky.
Jak bude řešeno neohlášení ve smyslu odmítání požadovaného přihlášení za právnickou osobu prostřednictvím individuálních možností fyzické osoby dle výše uvedených argumentací?
V tomto doporučujeme konzultaci s Ministerstvem životního prostředí.
Reference interface
The description of the architecture of the authority and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its architecture layers.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Public administration one-stop shop
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Document Management System
The description of the architecture of the office and the public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its layers of architecture.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Legislative-Systems-and-Services
The description of the architecture of the office and the public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Electronic acts and delivery
The description of the architecture of the office and the public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its layers of architecture.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Unified Identity Space of Public Administration
The description of the architecture of the office and public administration of the Czech Republic by each layer of architecture and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Unified Service Channels and Officials' User Interfaces
The description of the architecture of the office and the public administration of the Czech Republic by each architecture layer and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
INSPIRE Shared Services
The description of the architecture of the authority and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual authorities
Popis Sdílených služeb INSPIRE
Evropská směrnice INSPIRE ukládá členským státům povinnost zajistit zpřístupnění prostorových dat a souvisejících síťových služeb, které náleží k 34 tématům 3 příloh Směrnice INSPIRE. V České republice se tak děje prostřednictvím Národního geoportálu INSPIRE (gesce Ministerstva životního prostředí), jehož součástí je centrální metadatový katalog, který obsahuje metadata prostorových dat, síťových služeb a z nich vytvořených mapových kompozic. Národní geoportál INSPIRE zpřístupňuje prostorová data a služby nad prostorovými daty i pro národní účely, pro potřeby veřejné správy a ostatních subjektů (veřejnost, soukromé firmy) České republiky.
Směrnice INSPIRE zavádí jednotné závazné standardy formou nařízení a doporučujících i technických prováděcích pokynů, které jednotlivá nařízení doplňují. Východiskem pro nařízení a pokyny jsou celosvětově platné ISO normy řady 19 1XX nebo dokumenty známé jako standardy OGC (Open Geospatial Consorcium), INSPIRE však zavádí některé další specifikace. Technické prováděcí pokyny týkající se služeb nad prostorovými daty jsou publikovány na http://inspire.ec.europa.eu/index.cfm/pageid/761. Infrastruktura INSPIRE disponuje obdobným výčtem typů služeb jako infrastruktura národní, v rámci INSPIRE jsou však služby nad prostorovými daty přesně pojmenovány a specifikovány. Jedná se o služby vyhledávácí (služby, které umožňují vyhledání a zpřístupnění metadat), prohlížecí, stahovací (online nebo formou předpřipravených datových sad), transformační služby a služby umožňující spuštění služeb nad prostorovými daty. Tyto služby jsou pak v rámci infrastruktury INSPIRE rozděleny na harmonizované (nad INSPIRE datovými sadami), interoperabilní (zpřístupňující data v geodetickém referenčním systému ETRS89) a vyhledatelné (popsané metadaty). Uvedené služby nemusí zajišťovat každý poskytovatel sám, pro zajištění povinnosti vůči Směrnici INSPIRE lze využít i nástrojů Národního geoportálu INSPIRE. Vzhledem k rozdílným termínům pro soulad služeb a interoperabilitu prostorových dat zobrazují, s výjimkou ČÚZK, všechny přístupné prohlížecí služby data neharmonizovaná (nekonformní). ČÚZK, jako ústřední správní úřad zeměměřictví a katastru nemovitostí České republiky odpovídající za geodetické systémy závazné na území státu, provozuje i službu transformační umožňující transformaci souřadnic ze systému S-JTSK do ETRS89 s využitím zpřesněných transformačních klíčů.
Zákon 123/1998 Sb. povinuje poskytovatele zpřístupňováním prostorových dat na základě licenčních smluv. Související nařízení Komise (EUS) č. 268/2010 pak určuje termín pro doručení dat a služeb vyžádaných orgány a institucemi EU (20 dní od podání žádosti). Prováděcí pokyny k tomuto nařízení doporučují pro zrychlení komunikace využít pro INSPIRE data a služby dva typy licenčních smluv a to smlouvu základní (pro data bezplatná s účelem užití, ke kterému byl primárně vytvořen i INSPIRE) a specifickou (kde již může být požadována úhrada, účely užití mohou být rozšířeny atd.)
Pravidla pro Sdílené služby INSPIRE
Stručný přehled povinností pro naplnění technických požadavků INSPIRE (detailně viz Strategie implementace INSIRE):
- vytvořit, zpřístupňovat a aktualizovat metadata dat a služeb INSPIRE (v souladu s nařízením (ES) č. 1205/2008); Metadata musí být zpřístupněna na Národní geoportál INSPIRE buď pomocí služby vytvořené nad katalogem každého poskytovatele nebo uložením metadat do katalogu geoportálu. Metadaty je možné popsat i aplikace využívající prostorová data.
- zpřístupňovat vyhledávací a prohlížecí síťové služby (v souladu s nařízením (ES) č. 976/2009); Požaduje se vytvořit vyhledávací službu, která umožní vyhledat služby na základě specifikovaných vyhledávacích kritérií, a prohlížecí službu, která umožní datové sady zobrazit.
- vytvořit a aktualizovat nově vytvořené nebo rozsáhle rekonstruované datové sady; Požaduje se publikovat prostorová data ve formátu GML dle datových specifikací maximálně do 6 měsíců od počátku jejich platnosti v produkčních databázích, sledovat jejich kvalitu a informace o ní zpřístupnit v metadatech.
- zpřístupňovat stahovací a transformační síťové služby (mít je v souladu s nařízením (ES) č. 976/2009); Požaduje se umožnit stahování INSPIRE datových sad on-line (WFS) nebo tzv. předpřipravených datových sad off-line způsobem. Transformační služby musí umožňovat transformovat datové sady neharmonizovaných dat ve formátu GML do požadovaného geodetického referenčního systému. Je požadováno zajistit kvalitu služby a popsat ji v metadatech;
- poskytovat přístup k datovým sadám a službám orgánům a subjektům Evropské unie (v souladu s nařízením (EU) č. 268/2010); Požaduje se poskytovat datové sady nebo služby orgánům a subjektům Evropské unie do 20 dnů od doručení žádosti s možností využití standardizované licence.
- mít interoperabilní a harmonizované služby prostorových dat v souladu s nařízením (EU) č. 1089/2010; mít v souladu s novelizovaným nařízením (ES) č. 976/2009 služby umožňující spuštění služeb založených na prostorových datech; Požaduje zpřístupnit informace o kvalitě služeb a doplnit ke službám další operace zajišťující interoperabilitu (do října 2020).
Při implementaci technických požadavků Směrnice INSPIRE je nutné náročnosti jednotlivých činností poskytovatelů dat dále rozlišit podle role ve vztahu k tvorbě, správě a rozvoji infrastruktury INSPIRE. Zapojení všech dotčených subjektů do infrastruktury INSPIRE předpokládá jejich rozdělení do různých rolí ve vztahu k prostorovým datům, službám založených na prostorových datech, anebo aplikacím, které jsou nad daty nebo službami vytvořeny. Je samozřejmostí, že jeden poskytovatel může vystupovat ve více rolích:
- Povinný subjekt (definován v § 2 písm. b) zákona č. 123/1998 Sb.)
- Jiný poskytovatel (definován v § 11a odst. 3 zákona č. 123/1998 Sb.)
- Gestor národní datové sady INSPIRE – povinný subjekt odpovědný za konsolidaci a publikaci výsledné národní datové sady INSPIRE, pokud je jediným poskytovatelem pro dané téma příloh Směrnice INSPIRE. V opačném případě koordinuje spolugestory přispívající svými prostorovými daty do obsahu národní datové sady INSPIRE (přesně a úplně definován ve Strategii implementace INSPIRE)
- Spolugestor národní datové sady INSPIRE - Jeden či více povinných subjektů k danému tématu příloh Směrnice INSPIRE, který odpovídá za harmonizaci příslušné části NDSI (přesně a úplně definován ve Strategii implementace INSPIRE)
Tabulka uvádí základní přehled oblastí, které jsou pro jednotlivé role závazné:
Shared Agenda IS in Delegated Responsibilities
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Rules for the use of shared services, functional units and thematic areas by individual offices
Shared Agenda IS for the independent competence of local governments
The description of the architecture of the authority and the public administration of the Czech Republic by individual layers of architecture and the incorporation of the requirements into the information concept and architecture of the authority is described in Architecture of the authority in the context of the public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Shared Operational Information Systems
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Shared Statistical, Analytical and Reporting Systems
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
Rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
eGovernment Cloud
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices
Popis eGovernment cloudu
Základním cílem projektu eGovernment Cloud (dále také jako "eGC"), je zvýšení efektivity, rozsahu poskytovaných služeb, kvality a bezpečnosti a zároveň snížení nákladů provozu informačních systémů a aplikací veřejné správy, a to využíváním sdílených ICT služeb na úrovni infrastruktury, výpočetních platforem a standardizovatelných aplikací. Tím dochází k naplnění strategie 3E při současném zvýšení kvality a bezpečnosti při pořizování a provozu informačních systémů veřejné správy využíváním sdílených cloudových služeb eGC. Dalším cílem projektu eGC je v maximální míře usnadnit jednotlivým správcům ISVS architektonické, bezpečnostní, nákupní a projektové procesy využíváním služeb eGC.
Informační koncepce ČR zohledňuje základní cíle a koncepty eGC, stanovené usnesením Vlády ČR ve Strategickém rámci Národního cloud computingu (UV 1050/2016) a rozpracovávané v rámci projektu Příprava vybudování eGovernment cloudu, jehož výstupy byly schváleny v listopadu 2018 vládou ČR (UV 749/2018).
Služby eGC zahrnují tři hlavní kategorie cloudových služeb: IaaS (Infrastructure as a Service – služby na úrovni datových center, sítí a HW), PaaS (Platform as a Service – služby na úrovni standardních SW platforem, jako jsou databáze, webové servery) a SaaS (Software as a Service – kompletní funkcionalita standardních nebo standardizovatelných aplikací poskytovaná jako služba, např. e-mail, ekonomický systém, spisová služba apod.).
Služby eGC jsou poskytovány komerční částí eGC (KeGC - služby provozované komerčními subjekty s využitím jejich vlastních datových center a komunikační infrastruktury) a státní částí (SeGC – služby provozované v datových centrech a na HW a SW platformách v majetku státu a provozované organizacemi řízenými státem – poskytovatelem státního cloud computingu).
Součástí vybudování eGC je i konsolidace datových center a HW platforem, čímž se rozumí postupný přesun provozu většiny informačních systémů a aplikací veřejné správy z datových center jednotlivých institucí do vybraných datových center státu (státní část eGC), resp. do datových center ověřených komerčních subjektů (komerční část eGC). Konsolidovaná infrastruktura a HW/SW platformy budou poskytovány formou IaaS a PaaS služeb eGC. Vybudování těchto služeb zahrnuje mj.:
- definici minimálních standardů pro poskytování IaaS a PaaS služeb pro státní a komerční část eGC,
- sjednocení provozního prostředí informačních systémů a aplikací provozovaných ve státní části eGC na několik vybraných platforem,
- zajištění potřebné bezpečnosti, spolehlivosti, škálovatelnosti a jednotnosti provozu ICT služeb.
Součástí vybudování eGC je dále postupná definice standardů pro vybrané softwarové aplikace podporující stejnou agendu či podpůrný a administrativní proces. Standardizované aplikační služby budou poskytovány formou SaaS služeb eGC. Využití standardizovaných aplikací přispěje ke standardizaci pracovních postupů (byznys procesů) ve veřejné správě.
Vybudování eGC umožní organizacím veřejné správy, aby se více soustředily na svoje klíčové procesy místo podpůrných procesů typu zajištění provozu informačních systémů a aplikací. Organizace však musí i nadále být schopny definovat svoje požadavky na ICT služby a integrovat je do svých klíčových procesů.
Jedním ze základních pravidel pro využití služeb SeGC nebo KeGC je zajištění požadované úrovně bezpečnosti eGC služeb v závislost na bezpečnostní úrovni informačního systému veřejné správy, pro který jsou služby eGC využívány. Tato bezpečnostní úroveň se odvozuje od bezpečnostních dopadů daného IS. Zařazení poptávaného cloud computingu do bezpečnostní úrovně provádí orgán veřejné moci podle vyhlášky č. 315/2021 Sb., o bezpečnostních úrovních pro využívání cloud computingu orgány veřejné moci. SeGC zajistí nejvyšší kritickou úroveň bezpečnosti a je určen pro provoz služeb eGC nejvyšší bezpečnostní úrovně (automaticky to jsou informační nebo komunikační systémy, které jsou kritickou informační infrastrukturou podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti). KeGC je určen pro provoz služeb eGC ostatních bezpečnostních úrovní a v maximální míře umožňuje využití tržních mechanismů pro zajištění optimálních cen.
U moderně navržených ISVS pro provoz v cloudu lze provést dekomponování, což vede ke zvýšení efektivnosti využívání prostředků při vývoji a provozování těchto informačních systémů. Dekompozice zároveň umožňuje hybridní provoz s využitím služeb cloud computingu různé bezpečnostní úrovně (dále jen „BÚ“).
Druhým rozhodujícím kritériem pro využití služeb eGC je kalkulace a porovnání nákladů vlastnictví (TCO) jednotlivých IS v modelu provozu on-premise (na vlastní infrastruktuře) a s využitím služeb eGC. Ke stanovení ekonomické náročnosti je dostupný Kalkulátor nákladů ISVS provozovaného v cloud; včetně uživatelské příručky.
Každý úřad si také musí být vědom toho, že financování cloudových služeb se liší od provozu vlastního řešení. Při provozu a nákupu vlastních technologií jde o tzv. CAPEX, tedy kapitálové výdaje, a pořízené věci zůstávají v majetku úřadu. Naopak nákup cloudových služeb je tzv. OPEX, tedy provozní výdaje, kdy úřadu v majetku nic nezůstává a platí si pouze službu. S tímto odlišným způsobem financování je třeba počítat při tvorbě rozpočtu a jeho čerpání, protože při využívání cloudových služeb pro celou infrastrukturu úřadu se razantně zvýší provozní výdaje a sníží investiční.
Oblast cloud computingu je od 1. 8. 2020 regulována příslušnými ustanoveními zákona č. 365/2000 Sb., o informačních systémech veřejné správy, kde v Hlavě VI zákona je zaveden mechanismus zápisu poptávek a nabídek cloud computingu do katalogu cloud computingu a zavedena povinnost orgánů veřejné správy využívat pouze takový cloud computing, který byl na základě splnění podmínek uvedených v zákoně zapsán Digitální a informační agenturou do katalogu cloud computingu.
Na webových stránkách Digitální a informační agentury je dostupný Metodický návod pro zápis poptávky a nabídky cloud computingu do katalogu cloud computingu.
Poskytovatelé služeb eGC musí splňovat zákonem určené podmínky, které zahrnují zejména oblast bezpečnosti poskytovaných služeb a jejich provozních parametrů, ale také důvěryhodnosti poskytovatele. Splnění podmínek ověřuje Digitální a informační agentura ve spolupráci s Národním úřadem pro kybernetickou a informační bezpečnost a dalšími složkami státu. Požadavky, které musí splnit poskytovatel cloud computingu, aby byla jeho nabídka zapsána do katalogu cloud computingu, stanovuje vyhláška č. 316/2021 Sb., o některých požadavcích pro zápis do katalogu cloud computingu.
Rozsah údajů vedených v katalogu cloud computingu o poptávkách, nabídkách a využívaném cloud computingu specifikuje vyhláška č. 433/2020 Sb., o údajích vedených v katalogu cloud computingu.
Řídící orgán eGovernment Cloudu (také jako ŘOeGC) koordinuje budování a rozvoj eGC, rozvíjí a udržuje metodické postupy pro eGC, kontroluje a řídí soutěžní mechanismus KeGC a nabídku služeb SeGC.
V současné době je umísťování IS orgánů veřejné správy do eGC (využívání služeb eGC) zcela dobrovolné, přičemž se uplatňuje princip mandatory-compare. Podle § 5 odst. 2 písm. j) a k) zákona č. 365/2000 Sb., o informačních systémech veřejné správy, resp. vyhlášky č. 360/2023 Sb., o dlouhodobém řízení informačních systémů veřejné správy mají orgány veřejné správy povinnost zajistit si ekonomické zhodnocení výhodnosti provozu ISVS. Orgán veřejné správy musí provést kalkulaci TCO, takže umístění on-premise pro nově pořizované systémy nebo v rámci technického zhodnocení anebo rozvoje spravovaného informačního systému veřejné správy bude nadále možné pouze tehdy, pokud kalkulace TCO neprokáže, že je nákladově efektivnější než umístění do eGC.
Bezpečnostní pravidla pro orgány veřejné správy, která musí nastavit, pokud využívá cloud computingu jsou dána vyhláškou č. 190/2023 Sb., o bezpečnostních pravidlech pro orgány veřejné moci využívající služby poskytovatelů cloud computingu.
Co je a co není cloud dle zákona
Upřesnění definice služeb třídy SaaS aneb jaká aplikační řešení, která orgány veřejné správy využívají/poptávají, lze považovat za cloud computing ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy?
Aplikační řešení, která jsou cloud computing třídy SaaS ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy , musí splňovat současně tyto podmínky:
- slouží více správcům ISVS (orgány veřejné správy (dále jen „OVS“) v roli tenantů), kteří jej využívají k provozu vlastních ISVS, nebo jiným zákazníkům (mimo OVS) a zároveň
- jsou provozovány na sdílené platformě cloud computingu třídy IaaS, příp. PaaS
Podmínka 2) může být splněna jedním ze dvou způsobů:
- SaaS je provozován na službách IaaS/PaaS samostatně zapsaných do katalogu CC tímto nebo jiným poskytovatelem CC,
- SaaS je provozován na službách IaaS/PaaS téhož poskytovatele CC, který nabízí SaaS, ale služby IaaS/PaaS využívá pouze pro provoz daného SaaS. V tomto případě služby IaaS/PaaS se do katalogu CC samostatně nezapisují. Existence a účinnost bezpečnostních opatření, která jsou zajišťována jednotlivými vrstvami provozní infrastruktury a která jsou vyžadována pro službu SaaS v dané bezpečnostní úrovni, se ověřují na základě „Podkladů pro ověření SaaS“, které ve své žádosti o zápis služby do katalogu CC uvedl poskytovatel SaaS.
Tyto služby typu SaaS mohou být využívány pouze v souladu s Hlavou VI ZoISVS a mj. musí být celý „stack“ IaaS/PaaS/SaaS zapsán v Katalogu CC. Zároveň musí být zapsáni všichni poskytovatelé CC (ať už materiální poskytovatelé, distributoři nebo koncoví poskytovatelé).
Aplikační řešení, která nejsou CC ve smyslu ZoISVS (a nepovažujeme je za CC třídy SaaS), jsou taková, která
- slouží více správcům ISVS (OVS), ale jsou pro každého správce provozovány na nesdílené (dedikované) výpočetní infrastruktuře;
- slouží pouze pro jednoho správce ISVS (OVS), přičemž může jít o aplikaci umožňující vzdálený přístup přes Internet nebo přes vnitřní síť CMS/KIVS pro mnoho externích uživatelů (např. aplikace pro podání přihlášky na střední školu, nebo aplikace využívané jednotlivými uživateli z řad OVS/OVM, avšak s centrální správou uživatelských účtů a báze dat ze strany toho jednoho správce ISVS), i když je provozována na platformě CC třídy IaaS, příp. PaaS (tato platforma však podléhá povinnosti zápisu do katalogu CC).
Upozorňujeme, že je nutné vždy uvažovat o ISVS v rozsahu ZoISVS, tzn. ve vymezení uvedeném v § 1 ZoISVS (zejména s ohledem na výjimky v odst. (2), (3) a (4) § 1 ZoISVS).
Katalog cloud computingu
Katalog cloud computingu dle zákona o informačních systémech veřejné správy naleznete na webu Digitální a informační agentury.
Nástroj pro vyhledávání v katalogu cloud computingu naleznete přímo zde nebo na této stránce níže. Jedná se o vyhledávací nástroj nad katalogem cloud computingu (dále jen „CC“).
Zde zveřejněné služby CC splnily v rámci zápisu nabídek CC veškeré požadavky zákona č. 365/2000 Sb., o informačních systémech veřejné správy pro zápis do katalogu CC, a to v dané bezpečnostní úrovni.
V katalogu CC lze vyhledávat:
- konkrétní služby CC materiálních poskytovatelů tzn. nepřímý prodej služeb CC materiálních poskytovatelů a přímý prodej služeb CC od materiálních poskytovatelů (*)
- konkrétní služby CC přeprodejců tzn. přímý prodej služeb CC od přeprodejců 2)
Nástroj pro vyhledávání v katalogu cloud computingu
Pravidla eGovernment cloudu
Přístup správců ISVS k eGC
Každý správce centralizovaného poskytovaného agendového informačního systému by měl postupně činit při správě a rozvoji svých informačních systémů takové kroky, aby oddělil vrstvu platformy a technologií od vrstvy komunikační a aplikační vrstvy příslušných informačních systémů. To znamená, že by se svými postupnými kroky měl připravit na to, že od určité doby bude provozovat svoje centralizované agendové informační systémy v cloudu a měl by postupně omezovat svoji závislost na vlastních datových centrech a pouze jím provozovaných technologických platformách.
Provozování AIS OVM v eGC v souvislosti s komunikací pomocí CMS/KIVS
Umístění AIS OVM v eGC znamená, že eGC je jen jiná adresa daného OVM. Zde jsou dvě možnosti přístupu do CMS:
- Připojené do CMS/KIVS je OVM a AIS v eGC je přesměrován do CMS/KIVS přes OVM (př. Portál občana). Pro tento scénář je AIS v eGC brán jako interní AIS OVM, který se připojuje do CMS/KIVS přes připojení daného OVM
- Poskytovatel eGC má zřízenou KIVS linku do CMS. Skrze tuto KIVS linku si jednotlivá OVM mající ASIy v cloudu vytváří svá VPN do CMS. (př. (AISy Městských policií si sahají na Základní registry)
Publikování portálu OVM
Publikování portálu OVM je specifický případ publikování AIS OVM, kdy se v rámci provozu portálu v eGC umožňuje, aby byly služby portálu dostupné pro klienty, kteří nejsou OVM, prostřednictvím internetu přímo od poskytovatele eGC.
Portál je v případě provozu na vlastní infrastruktuře publikován výhradně prostřednictvím CMS službou CMS2-02 Zveřejnění aplikace a to do:
- Do sítě CMS/KIVS, služba CMS2-02-1 a/nebo
- Do sítě Internet, služba CMS2-02-2
V případě umístění portálu v eGC, je umožněna publikace portálu z eGC, kdy:
- eGC je rozšířeným IP prostorem CMS/KIVS a
- AIS OVM všech subjektů, kteří přispívají do portálu OVM v eGC, čerpají údaje o subjektu práva prostřednictvím referenčního rozhraní.
Klienti, kteří nejsou OVM, přistupují k portálu v otevřeném internetu přes HTTPS publikovaném přímo z eGC.
Povinnosti komerčních poskytovatelů služeb eGC
Konkrétní povinnosti stanoví zákon o informačních systémech veřejné správy a na základě tohoto zákona pak vydané vyhlášky ministerstva a NÚKIB. Řídící orgán eGovernment Cloudu pak na základě zákona a vyhlášek připravuje a vydává metodické pokyny. Již nyní však platí pravidla pro nutnost připojení skrze infrastrukturu CMS/KIVS a tím i respektování katalogového listu služby připojení přes IPSec
Určování nástrojů osobní produktivity jako ISVS
Orgány veřejné správy se musí při poskytování interaktivních nástrojů osobní produktivity úředníka využívající cloud computing rozhodnout, zda jde o informační systém veřejné správy (ISVS) nebo jeho část ve smyslu zákona č. 365/2000 Sb., o informačních systémech veřejné správy (ZoISVS), a mohou tak podléhat regulaci cloud computingu podle Hlavy VI tohoto zákona.
Dle § 2 odst. 1 písm. b) ZoISVS je: „informačním systémem veřejné správy funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správy nebo plnění jiných funkcí státu anebo dalších veřejnoprávních korporací …“
Informační činností dle § 2 odst. 1 písm. a) se myslí: „získávání a poskytování informací, reprezentace informací daty, shromažďování, vyhodnocování a ukládání dat na nosiče a uchovávání, vyhledávání, úprava nebo pozměňování dat, jejich předávání, šíření, zpřístupňování, výměna, třídění nebo kombinování, blokování a likvidace dat ukládaných na nosičích. Informační činnost je prováděna správci, provozovateli a uživateli informačních systémů veřejné správy prostřednictvím technických a programových prostředků“.
Z definice ISVS vyplývá, že cílevědomá, avšak ne-systematická, informační činnost pro účely výkonu veřejné správy nemusí spadat pod rozsah definice. Scénáře interaktivního využívání nástrojů s podporou cloud computingu (jako jsou např. interaktivní nástroje umělé inteligence, volně dostupné on-line mapy nebo jazykové překladače) nesplní podmínku systematické informační činnosti výkonu veřejné správy, pokud využívání určitého konkrétního nástroje k určitému informačnímu účelu není interně v rámci orgánu veřejné správy ustanoveno jako závazné. Jestliže se tedy úředník sám rozhoduje ad-hoc, který a jestli vůbec nějaký on-line nástroj pro daný účel využije, nenaplní se tento atribut definice ISVS.
Naopak se lze domnívat, že systematické využití např. tabulkového kalkulátoru (např. MS Excel) v malé obci pro evidenci poplatků za psy nebo za hrobová místa naplní znaky „cílevědomé a systematické informační činnosti pro účely výkonu veřejné správy“, a tento informační systém by tedy měl být označen a spravován jako ISVS. Za rozlišující kritérium výkladu pojmu „systematická informační činnost pro účely výkonu veřejné správy“ tedy považujeme jakýkoli interní předpis OVS, který zavazuje úředníky využívat vždy určitý konkrétní nástroj (informační systém nebo jeho část) pro zabezpečení určitého účelu výkonu veřejné správy.
Ač tedy nástroje osobní produktivity jednoznačně spadají do definice informační činnosti, je potřeba vždy vážit hledisko systematičnosti pro účel výkonu veřejné správy.
Dále ještě zohledníme metodické vodítko Co je a co není ISVS. V kapitole „Pomůcka pro určování ISVS“ jsou uvedeny dvě pomocné otázky k rozhodování OVS, zda se v konkrétním případě nějakého informačního systému má jednat o ISVS:
- Bylo by nefunkčností informačního systému bezprostředně narušeno nebo ohroženo plnění povinnosti vyplývající z kompetencí daného orgánu veřejné správy?
- Jsou v informačním systému uloženy údaje o vykonávané správní činnosti nebo údaje pro podporu výkonu u této činnosti?
Pokud jsou odpovědi na tyto otázky ANO, s největší pravděpodobností se v případě posuzovaného informačního systému jedná o ISVS.
Toto vodítko může potvrdit výše vyslovený názor, že tabulkový kalkulátor instalovaný byť jen na jednom notebooku v rámci malé obce, který je však jediným zavedeným nástrojem pro správu určitých agend (viz výše), splní obě podmínky a měl by být tedy spravován jako ISVS.
Naopak, ad-hoc využití interaktivních nástrojů dle shora uvedených příkladů (interaktivní nástroje umělé inteligence, volně dostupné on-line mapy, on-line jazykové překladače apod.) zpravidla nedá odpověď “ano” na tyto dvě otázky metodického vodítka, a v takovém případě se nekvalifikuje jako ISVS.
National Data Centres
The description of the architecture of the office and the public administration of the Czech Republic by individual layers of architecture and the incorporation of requirements into the information concept and architecture of the office is described in Architecture of the office in the context of public administration and its layers of architecture.
The rules for individual shared services, functional units and thematic areas are described in Methods of use of shared services, functional units and thematic areas by individual offices
Public Administration Communication Infrastructure
The description of the architecture of the office and the public administration of the Czech Republic by individual architecture layers and the incorporation of the requirements into the information concept and architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.
The rules for individual shared services, functional units and thematic areas are described in How shared services, functional units and thematic areas are used by individual offices