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

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.)

  1. 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:
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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ů.
  7. 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.
  8. Údaje v agendě: Jsou ohlášeny všechny propojované a vedené údaje, včetně jejich kontextů a včetně technických údajů o nich.
  9. Úkony na žádost: Součástí agendy je i seznam a forma úkonů na žádost a určení toho, kdo smí takovou žádost podat
  10. 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:

  1. 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
  2. žá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ů:
  • 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

  • Klienti se identifikují a autentizují s využitím služeb NIA a jsou v portále identifikováni pomocí BSI do doby, než si klient zvolí službu, která je poskytována agendou
  • 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ů:
  • 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:

  • Klienti se identifikují a autentizují s využitím služeb NIA a jsou v portále identifikováni pomocí BSI do doby, než si klient zvolí službu, která je poskytována agendou
  • 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:

  1. 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.
  2. 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)
  3. 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
  4. 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.czANO - 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íč eGovernmentuMobilní 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-providerNE
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í identitaIdentita 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.5.2024

Celkové statistiky identitních prostředků
Celkem ID prostředků 15 580 362
Počet profilů alespoň s jedním aktivním prostředkem6 601 443
Celkový počet unikátních přihlášení 3 353 499
Konverze - procentuální zastoupení těch, kdo se skutečně přihlásili z těch, kdo se přihlásit mohli 50.80 %
Statistika za jednotlivé poskytovatele služeb
URL portálu Název portálu Celkem přihlášení
http://adisdpr.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy_2 309
http://adisepo.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy 24097
http://adisspr.mfcr.cz/adistc Daňový portál - Elektronické služby Finanční správy_3 2353
http://sso.plzensky-kraj.cz http://sso.plzensky-kraj.cz 1
https://adisspr.mfcr.cz/auth MOJE daně – Elektronické služby Finanční správy 656280
https://agw.pardubickykraj.cz/authgateService Autentizační brána 1
https://aispms.justice.cz/cas Portál Probační a mediační služby - PP 5
https://aisportal.mpo.cz/AISCIPortal/NIA/overeni CzechInvest 538
https://aisportal.mpo.cz/aisportal/nia/overeni AIS MPO 74518
https://alpha.ezconvey.cz/AKVych/ProviderMetadata https://alpha.ezconvey.cz/AKVych/ProviderMetadata 3
https://api.dipsy.cz/v1/auth/nia-secure DiPSy 132010
https://api.vvz.nipez.cz/vvz-nia/ Věstník veřejných zakázek - Prod 4428
https://auth.mpsv.cz/ Jenda MPSV 324323
https://auth.projektovezamery.cz/auth/response/nia MMR 799
https://auth.vzp.cz Moje VZP 152635
https://authgate.kraj-jihocesky.gov.cz Jihočeký kraj - AuthGate 36
https://authgate.kr-vysocina.cz IDM Kraje Vysočina 1677
https://caas.szif.cz/cas/login?client_name=NIA Státní zemědělský intervenční fond 15
https://cak.cz.s6.abuco.cz/admin-moje-cak/ https://cak.cz.s6.abuco.cz/admin-moje-cak/ 12
https://card2.dev.cvut.cz/PrivateAccess CARD2 2
https://cas.cuni.cz/cas/sp/metadata Univerzita Karlova SDG CAS 1008
https://cas.mestouvaly.cz/simplesaml/module.php/clave/sp/metadata.php/clave/eidasSP/eidasSP Město Úvaly 220
https://cas.portalzp.cz/kms-cas PZP KMS NIA 1250
https://code.gov.cz/ code.gov.cz 3578
https://cportal.celnisprava.cz/cas cPortál Celní správy 45933
https://cro.slu.cz Centrální registr osob Slezské univerzity (CRO SU) 1
https://crv.mdcr.cz/ Registr silničních vozidel (RSV) 1
https://crz.policie.cz/WEB_CRZ_PRIHLASENI/Default.aspx Centrální registr zbraní 4190
https://ctu.gov.cz Český telekomunikační úřad - WWW 12
https://dataportal.eru.cz/ https://dataportal.eru.cz/ 198
https://dataportal.eru.gov.cz/ Datový portál ERÚ 1770
https://davkyuk.mpsv.cz/login/nia Dávky UK 260452
https://des.mpsv.cz/login Portál Dětské skupiny 1702
https://development.niatest.vfn.cz/ https://development.niatest.vfn.cz/ 1
https://dev-pacient.vfn.cz VFN DEV portál pacienta 11
https://dicr.cz/podani/zadost-dle-zakona-c-106-1999-sb 106 5
https://dmvs.cuzk.cz/cas ČÚZK - portál DMVS 2195
https://dotace.kr-karlovarsky.cz/gordic/ginis/app/RAP05/ Karlovarský kraj 1447
https://dotace.pardubickykraj.cz/portal Dotační portál Pk 1334
https://dotace-soc.pardubickykraj.cz/sp/shibboleth DOTACE-SOC Dotační portál 1
https://dpmkportal.mkcr.cz/NIA/overeni DPMK 6621
https://drazby.financnisprava.cz/nia_saml2/ drazby.financnisprava prod 1673
https://dron.caa.cz Registrace bezpilotních systémů 49209
https://dron.notia.cz Registrace bezpilotních systémů - test 54
https://dron.notia.cz/ Registrace bezpilotních systémů - test 1
https://dtm.jmk.cz/auth/realms/JMK DTM-JMK 53
https://dtm.kraj-lbc.cz/auth/realms/LBC DTM-LBC 32
https://dtm.kr-karlovarsky.cz/auth/realms/KVK DTM-KVK 14
https://dtm.zlinskykraj.cz/auth/realms/ZLK DTM-ZLK 134
https://dvbtform.ctu.cz/ Český telekomunikační úřad - DVBT Form 264
https://eagri.cz/ssl/app/eagriapp/OOS/Uvod.aspx Elektronický přenos dat s Odborem osiv a sadby ÚKZÚZ 11
https://eagri.cz/ssl/app/rmext/ Registr množitelských porostů 39
https://eagri.cz/ssl/app/rvext/ Registr vinic 23
https://eagritest.cz/ssl/app/rmext/ https://eagritest.cz/ssl/app/rmext/ 1
https://edoklady.gov.cz/auth eDoklady 409036
https://eforms.zpmvcr.cz/eforms/ekomunikace E-Komunikace ZP MV ČR 1
https://eforms.zpmvcr.cz/eforms/ekomunikace/niasaml E-Komunikace ZP MV ČR 23916
https://e-health-auth.bnzlin.cz/signin-e-identity Krajská nemocnice T. Bati, a. s. 13
https://e-health-auth.ftn.cz/signin-e-identity Fakultní Thomayerova nemocnice 16
https://e-health-auth.hospital-bn.cz/signin-e-identity Nemocnice Rudolfa a Stefanie Benešov, a.s., nemocnice Středočeského kraje 34
https://e-health-auth.msk.cz/signin-e-identity Portál pacienta Moravskoslezského kraje 3336
https://e-health-auth.nemocnicepribram.cz/signin-e-identity Oblastní nemocnice Příbram, .a.s. 119
https://e-health-auth.nudz.cz/signin-e-identity Portál pacienta 131
https://e-health-auth.pnvd.cz/signin-e-identity Psychiatrická nemocnice v Dobřanech 5
https://e-health-auth.uhkt.cz/signin-e-identity Ústav hematologie a krevní transfuze 6
https://e-health-auth.unbr.cz/signin-e-identity Úrazová nemocnice v Brně 45
https://elektronicky.trest.cz/gordic/ginis/app/rap05/ Město Třešť 45
https://elisportal.mpo.cz/elisportal/nia/overeni ELIS EPODATELNA 5
https://ems.mestys-svitavka.cz/Gordic/RAP05.test/ https://ems.mestys-svitavka.cz/Gordic/RAP05.test/ 1
https://ems.mestys-svitavka.cz/Gordic/RAP05/ Městys Svitávka 83
https://ems.mestys-svitavka.cz:8443/Gordic/RAP05/ https://ems.mestys-svitavka.cz:8443/Gordic/RAP05/ 1
https://epacient.fnkv.cz/ eHealth Portál Fakultní nemocnice Královské Vinohrady 5
https://epo.plzen.eu/irj/portal/anonymous/login Statutární město Plzeň 1445
https://eportal.archirepo.com/ https://eportal.archirepo.com/ 1
https://eportal.cssz.cz/ikr-cas ePortál ČSSZ 1015992
https://eportal.mo.gov.cz/auth/realms/eportal/broker/eidas-saml/endpoint ePortál Ministerstva obrany České republiky TEST 1
https://eportal.pardubice.eu/gordic/ginis/app/RAP05 eportal.pardubice.eu 1604
https://eportal.rumburk.cz/portal Město Rumburk 36
https://eportal.statistika.cz Centrální autentizační bod ČSÚ 9
https://ereg.ksrzis.cz/ Ústav zdravotnických informací a statistiky ČR 14317
https://esfcr.cz https://esfcr.cz 5
https://esluzby.ckrumlov.cz/portal/ Město Český Krumlov 157
https://eurad.mestock.cz/ Město Červený Kostelec 5
https://flexi.bucovice.cz/portal/ Město Bučovice 116
https://frs.gov.cz/api/ip/saml2/authenticate/nia https://frs.gov.cz/api/ip/saml2/authenticate/nia 1
https://ginis.mu-lostice.cz/Gordic/Ginis/App/RAP05/ Město Loštice 67
https://gordic.muchropyne.cz Chropyně 77
https://hades.uhk.cz/nia/ UHK eCŽV přihláška 5
https://hlksehealthportal.azurewebsites.net/home/home HLKS eHealth Portál TEST 4
https://iam.env.cz Ministerstvo životního prostředí 15431
https://identity.semily.cz:8184/ Portál občana 149
https://iiptp.metodickecentrum.cz Metodické centrum 259
https://iiptpt.metodickecentrum.cz Metodické centrum - test 10
https://insis.vse.cz/ VŠE Praha – studijní systém 557
https://is.cuni.cz/studium/index.php Univerzita Karlova SDG SIS 766
https://is.czu.cz/ ČZU v Praze - studijní systém 154
https://is.jamu.cz/ Janáčkova akademie múzických umění 5
https://is.mendelu.cz MENDELU Brno - Univerzitní informační systém 378
https://is.muni.cz/ Masarykova univerzita 11490
https://is.slu.cz Informační systém Slezské univerzity (IS SU) 5
https://is.vstecb.cz/ Vysoká škola technická a ekonomická v Českých Budějovicích 3
https://isdtm.olkraj.cz/auth/realms/OLK DTM - OLK 6
https://isdv.upv.cz/webapp/webapp.nia.niareg https://isdv.upv.cz/webapp/webapp.nia.niareg 3250
https://isdv.upv.gov.cz/webapp/webapp.nia.niareg Úřad průmyslového vlastnictví 2190
https://isdvakc.upv.cz/webapp/webapp.nia.niareg https://isdvakc.upv.cz/webapp/webapp.nia.niareg 10
https://isdvakc.upv.gov.cz/webapp/webapp.nia.niareg AKC - ÚPV 10
https://isdvtst.int.upv.cz/webapp/webapp.nia.niareg TST - ÚPV 7
https://iskp21.mssf.cz/ ISKP21+ 25745
https://iskp21.mssf.cz/sd/ ISKP21+ -údaje 20469
https://iskp21-ref.mssf.cz/ ISKP21+ Ref 12
https://iskp21-sandbox.mssf.cz/ https://iskp21-sandbox.mssf.cz/ 2
https://iskp21-test.mssf.cz/ ISKP21+ Test 403
https://iskp21-test.mssf.cz/sd/ ISKP21+ -test údaje 31
https://is-stag.osu.cz/nia/shibboleth is-stag.osu.cz 357
https://istp.mdcr.cz/Logon.aspx Informační systém technických prohlídek 7459
https://jaas.justice.cz/ Justiční autentizační a autorizační služba 25935
https://jaaspreauth.justice.cz/ Justiční autentizační a autorizační služba 1
https://jck.krajdtm.cz/auth/realms/JCK DTM-JCK 46
https://jenda.mpsv.cz/ https://jenda.mpsv.cz/ 584860
https://khk.krajdtm.cz/auth/realms/KHK DTM-KHK 26
https://kissos.pardubickykraj.cz/sp/shibboleth KISSOS Dotační portál 2
https://kko-nia.mkcr.bootiq-preview.eu/private KKO-TEST 3
https://klient.fnol.cz/ Fakultní nemocnice Olomouc – eHealth portál 108
https://kp.vozp.cz Vojenská zdravotní pojišťovna České republiky 14271
https://lektor.metodickecentrum.cz Metodické centrum (lektor) 171
https://lektort.metodickecentrum.cz Metodické centrum - test (lektor) 8
https://lime.sazka.cz/bank-business-card/saml/SSO SAZKA a.s. 8078
https://lime.uat.sazka.cz/bank-business-card/saml/SSO SAZKA a.s. UAT 2
https://login.cmi.cz/auth/realms/CMI_Portaly ČMI Portály 1
https://login.cuzk.cz/nia/ ČÚZK - přihlašovací portál 509180
https://login.vspj.cz IS VŠPJ 72
https://modurad.otevrenamesta.cz/mutabor/nia info.mutabor.cz 169
https://moje.cak.cz/admin-moje-cak/ ČAK 8
https://moje.test2.kdpcr.cz/ Moje KDP ČR - Test2 5
https://mojeid.cz/nia/client mojeID 13876
https://moje-kdp.dimov-pc.ldock.dev.feo.cz/ Moje KDP ČR - Dev/MD/PC 1
https://monitoringtrhu.ctu.cz/ Český telekomunikační úřad - ESD 2085
https://moodle.mssf.cz/auth/saml2/sp/metadata.php Moodle MS2021+ 2
https://moodle-test.mssf.cz/auth/saml2/sp/metadata.php Moodle MS2021+ Test 3
https://msk.krajdtm.cz/auth/realms/MSK DTM-MSK 48
https://mytocz.eu/selfcare/ Ředitelství silnic a dálnic ČR, Doručovací adresa: Čerčanská 12, CZ-14000 PRAHA 19736
https://nadmery.mdcr.cz IS NADR 851
https://nahlizeni.nsa.gov.cz/ Národní sportovní agentura 3
https://nahlizeni.uohs.cz/Gordic/Ginis/App/RAP05/ https://nahlizeni.uohs.cz/Gordic/Ginis/App/RAP05/ 381
https://nahlizeni.uohs.gov.cz/Gordic/Ginis/App/RAP05/ Úřad pro ochranu hospodářské soutěže 182
https://nahlizeni.uohs.gov.cz/Gordic/Ginis/App/RAP07/ Úřad pro ochranu hospodářské soutěže 4
https://ncp.nixzd.cz NÁRODNÍ KONTAKTNÍ BOD PRO PŘESHRANIČNÍ VÝMĚNU ZDRAVOTNÍ DOKUMENTACE 7
https://nia.eidentita.cz/sep1/secure/ https://nia.eidentita.cz/sep1/secure/ 81
https://nia.eidentita.cz/sep2/secure/ https://nia.eidentita.cz/sep2/secure/ 15
https://nia.eidentita.cz/sep3/secure/ https://nia.eidentita.cz/sep3/secure/ 133
https://nia.eidentita.cz/sep4/secure/ https://nia.eidentita.cz/sep4/secure/ 9
https://nia.eidentita.cz/sep5/ https://nia.eidentita.cz/sep5/ 10
https://nia.eidentita.cz/sep6/ https://nia.eidentita.cz/sep6/ 4
https://nia.identitaobcana.cz/sep1/secure/ SeP 1 32
https://nia.identitaobcana.cz/sep2/secure/ SeP 2 2
https://nia.identitaobcana.cz/sep3/secure/ SeP 3 24
https://nia.identitaobcana.cz/sep4/secure/ SeP 4 4
https://nia.identitaobcana.cz/sep5/ SeP 5 9
https://nia.sukl.cz/login Externí identity - NIA 1185
https://nia.upol.cz/ UPOL NIA API 166
https://niatest.scio.cz/ws-callback Scio 10
https://niatest.vfn.cz/ https://niatest.vfn.cz/ 6
https://nsaweb.ssw.cz/app Národní sportovní agentura 16
https://obcan.benesov-city.cz/ Město Benešov 1537
https://obcan.bilovec.cz/portal/ Město Bílovec 60
https://obcan.bilovicens.cz/obcan/ PO Bílovice nad Svitavou 146
https://obcan.bohumin.cz Portál občana Bohumín 760
https://obcan.bystricenp.cz/Gordic/Ginis/App/RAP05/ Město Bystřice nad Pernštejnem 101
https://obcan.jaromer-josefov.cz/obcan PO Jaroměř 41
https://obcan.kraliky.eu/obcan/ PO Králíky 44
https://obcan.kravare.cz/portal Portál Města Kravaře 75
https://obcan.litomerice.cz/obcan PO Litoměřice 840
https://obcan.mestolysa.cz/obcan LYSÁ NAD LABEM - PORTÁL OBČANA MĚSTA LYSÁ NAD LABEM 354
https://obcan.mesto-nymburk.cz/obcan/ PO Nymburk 367
https://obcan.mesto-uh.cz/portal/ Portál občana Uherské Hradiště 604
https://obcan.mnhradiste.cz/obcan MNICHOVO HRADIŠTĚ - PORTÁL OBČANA MĚSTA MNICHOVO HRADIŠTĚ 276
https://obcan.mubruntal.cz/portal/ BRUNTÁL - PORTÁL OBČANA MĚSTA BRUNTÁL 397
https://obcan.mupe.cz/obcan Město Pelhřimov 452
https://obcan.mutabor.cz/ Město Tábor 1397
https://obcan.novy-bor.cz/ PO Nový Bor 107
https://obcan.otrokovice.cz Identity 101
https://obcan.portal.gov.cz/auth Portál občana 1209672
https://obcan.rajecjestrebi.cz/Gordic/Ginis/App/RAP05/ Město Rájec-Jestřebí 83
https://obcan.ricany.cz/obcan PO Říčany 1030
https://obcan.suchdol.cz/obcan/ PO Suchdol na Lužnicí 11
https://obcan.zdarns.cz Portál občana 371
https://obcan.zidlochovice.cz/obcan/ Portál občana Města Židlochovice 77
https://obcan-stage.portal.gov.cz/auth Portál veřejné správy - Stage 281
https://ocko.uzis.cz/ Ústav zdravotnických informací a statistiky ČR 923860
https://oidc.kraslice.cz/id/ PO Kraslice 55
https://oidc.mag-ul.cz/id/ Statutární město Ústí nad Labem 687
https://oidc-tst.kraslice.cz/id/ https://oidc-tst.kraslice.cz/id/ 1
https://online.nkcr.cz/nia/login Notářská komora České republiky 179
https://onlinescitani.cz/#/ Sčítání lidu, domů a bytů 2021 94120
https://oslavice.cz/nia-formular OBEC OSLAVICE 18
https://osu.zpspraha.cz/id/ Osobní stránky uživatele ZPS 29331
https://pacient.erecept.sukl.cz/suklerp/Pacient https://pacient.erecept.sukl.cz/suklerp/Pacient 43332
https://pacient.erecept.sukl.cz/suklweb/Pacient/Home eRecept - pacientská aplikace 106950
https://pacient.nmbbrno.cz/ Nemocnice Milosrdných bratří, příspěvková organizace 12
https://pacient.vfn.cz Všeobecná fakultní nemocnice - rezervace léků 469
https://pak.krajdtm.cz/auth/realms/PAK DTM-PAK 43
https://pardubice.chytrejsiparking.cz Pardubice - parkovací systém 1877
https://parking.masterit.cz/pardubice Pardubice - parkovací systém 4
https://parkovani.jihlava.cz Statutární město Jihlava 1359
https://pavlinov.cz/nia-formular Obec Pavlínov 11
https://pct22007.b2clogin.com/pct22007.onmicrosoft.com/B2C_1A_TrustFrameworkBase https://pct22007.b2clogin.com/pct22007.onmicrosoft.com/B2C_1A_TrustFrameworkBase 1
https://pisek.mestopodpalcem.cz/api/sep/ MPP Písek 33
https://podatelna.msk.cz/rap05/ ePodatelna Moravskoslezského kraje 2988
https://portal.baska.cz Obec Baška 1
https://portal.baska.cz/ Obec Baška 36
https://portal.baska.cz/portal https://portal.baska.cz/portal 3
https://portal.bilina.cz Portál občana 379
https://portal.brusperk-mesto.cz/ Městský úřad Brušperk 2
https://portal.bystriceph.cz Město Bystřice pod Hostýnem 5
https://portal.caa.cz Portál úřadu pro civilní letectví 563
https://portal.chotebor.cz/portal/ CHOTĚBOŘ - PORTÁL OBČANA MĚSTA CHOTĚBOŘ 386
https://portal.chrustenice.cz/ Obec Chrustenice 58
https://portal.ckrumlov.cz/portal/ https://portal.ckrumlov.cz/portal/ 2
https://portal.cpzp.cz/app Česká průmyslová zdravotní pojišťovna 17719
https://portal.cvikov.cz/ Portál občana Cvikov 3
https://portal.dacice.cz/portal/ Město Dačice 262
https://portal.drnholec.eu/ OSP Městys Drnholec 19
https://portal.dron.caa.cz https://portal.dron.caa.cz 11883
https://portal.dron.notia.com https://portal.dron.notia.com 5
https://portal.fulnek.cz/portal/ Portál občana města Fulnek 203
https://portal.holesov.cz/portal HOLEŠOV - PORTÁL OBČANA MĚSTA HOLEŠOV 149
https://portal.homolka.cz/NiaLogin Nemocnice na Homolce 155
https://portal.horskelazne.cz/home/home HLKS eHealth Portál 7
https://portal.hosteradice.cz/ Osobní Portál Občana Hostěradice 28
https://portal.hukvaldy.eu/ Obec Hukvaldy 7
https://portal.hulin.cz/portal Město Hulín 149
https://portal.hustopece.cz Město Hustopeče 289
https://portal.jilove.cz/ Město Jílové u Prahy 105
https://portal.jirkov.cz/portal Město Jirkov 313
https://portal.kojetin.cz/portal/ Město Kojetín 92
https://portal.koprivnice.cz/portal Město Kopřivnice 500
https://portal.kozlovice.cz/ Obec Kozlovice 98
https://portal.letohrad.eu/portal/ Letohrad - Portál občana města Letohrad 761
https://portal.liberec.cz/id Statutární město Liberec 3699
https://portal.liberec.cz/id/ Statutární město Liberec 3
https://portal.libina.cz/ Obec Libina 37
https://portal.litovel.eu/ Město Litovel 179
https://portal.litvinov.cz/id/ Město Litvínov 593
https://portal.ludgerovice.cz/ Obec Ludgeřovice 34
https://portal.mbudejovice.cz/ Město Moravské Budějovice 218
https://portal.mesto-albrechtice.cz/ Město Albrechtice 48
https://portal.mestobystrice.cz/ Město Bystřice 333
https://portal.mestocernosice.cz/ MĚSTO ČERNOŠICE 1107
https://portal.mesto-domazlice.cz/portal Portál občana města Domažlice 7
https://portal.mesto-humpolec.cz/portal/ Město Humpolec 201
https://portal.mestokladno.cz/id/ Portál občana SMK 3362
https://portal.mesto-kunovice.cz/portal/ Město Kunovice 89
https://portal.mesto-podebrady.cz/obcan PO Poděbrady 270
https://portal.mesto-slavicin.cz/ Slavičín 13
https://portal.mesto-studenka.cz/ Město Studénka 373
https://portal.mesto-studenka.cz/rap05 Město Studénka 3
https://portal.mesto-vlasim.cz/portal/ Město Vlašim 12
https://portal.mestovsetin.cz/portal/ Město Vsetín 413
https://portal.mesto-zruc.cz/ Město Zruč nad Sázavou 24
https://portal.meucaslav.cz/portal/ Město Čáslav 103
https://portal.mezibori.cz/ OSP Portál Meziboří 5
https://portal.mmdecin.cz/portal/ statutární město Děčín 169
https://portal.mmhk.cz HRADEC KRÁLOVÉ - PORTÁL OBČANA MĚSTA HRADEC KRÁLOVÉ 2698
https://portal.mmkv.cz/gordic/ginis/app/rap05/ Magistrát Města Karlovy Vary - Portál občana 745
https://portal.mnisek.cz/portal/ Město Mníšek pod Brdy 248
https://portal.msk.cz/ IDM Moravskoslezský kraj 222
https://portal.mu-bridlicna.cz/ Město Břidličná 36
https://portal.mucl.cz/portal/ Město Česká Lípa 644
https://portal.muhodonin.cz/Gordic/Ginis/App/RAP05/ Město Hodonín 401
https://portal.muhodonin.cz/rap05/ https://portal.muhodonin.cz/rap05/ 5
https://portal.mujicin.cz/ město Jičín 375
https://portal.mukolin.cz/portal/ Město Kolín 1575
https://portal.mukrnov.cz/portal/ Město Krnov 671
https://portal.mu-vk.cz/Gordic/Ginis/App/RAP05/ Město Valašské Klobouky 31
https://portal.muvrchlabi.cz:4433/portal/ Město Vrchlabí 496
https://portal.nemcl.cz Nemocnice s Poliklinikou Česká Lípa,a.s. – eHealth portál 3
https://portal.nemkyj.cz/ Nemocnice Kyjov, příspěvková organizace – eHealth portál – PROD 10
https://portal.novybydzov.cz/portal/ Město Nový Bydžov 150
https://portal.novyjicin.cz/portal/ Portál občana města Nový Jičín 255
https://portal.obec-ostravice.cz/ Obec Ostravice 111
https://portal.ochrance.cz/nia Portal Ochrance 1759
https://portal.olomouc.eu/id/ Statutární město Olomouc - Portál Olomoučana 5526
https://portal.opava-city.cz Portál občana města Opavy 4401
https://portal.palkovice.cz/ Obec Palkovice 214
https://portal.podborany.net:444/portal/ Portál občana Podobořany 69
https://portal.prestice-mesto.cz Město Přeštice 249
https://portal.pribor-mesto.cz/portal/ Město Příbor 260
https://portal.roudnicenl.cz/ Město Roudnice nad Labem 42
https://portal.ruda.cz/ Obec Ruda nad Moravou 45
https://portal.rychnov-city.cz/portal/ Město Rychnov nad Kněžnou 4
https://portal.rychvald.cz/portal Město Rychvald 344
https://portal.rymarov.cz/portal Město Rýmařov 183
https://portal.sfpi.cz Státní fond podpory investic 851
https://portal.slapanice.cz/portal/ Město Šlapanice 253
https://portal.slavkov.cz/portal/ Město Slavkov u Brna 112
https://portal.sternberk.eu Město Šternberk 117
https://portal.steti.cz/ Město Štětí - portál občana 202
https://portal.stramberk.cz/portal/ Portál občana města Štramberk 111
https://portal.svetlahora.cz/ Světlá Hora 7
https://portal.svitavy.cz/portal/ Město Svitavy - portál občana 223
https://portal.telc.eu/ Město Telč 174
https://portal.tesin.cz/portal Město Český Těšín 183
https://portal.trebic.cz/portal Město Třebíč 749
https://portal.trinecko.cz/portal Portál občana města Třince 195
https://portal.trutnov.cz/ Město Trutnov OSP 12
https://portal.uhostroh.cz Portál Uherský Ostroh 3
https://portal.ujep.cz/nia/shibboleth Univerzita Jana Evangelisty Purkyně v Ústí nad Labem 812
https://portal.upce.cz/nia/shibboleth IS/STAG 621
https://portal.varnsdorf.cz/ Portál občana Varnsdorf 23
https://portal.velkemezirici.cz/portal/ Město Velké Meziříčí 361
https://portal.veseli.cz/ Město Veselí nad Lužnicí 289
https://portal.vinarskyfond.cz Vinařský fond 154
https://portal.vratimov.cz Město Vratimov 44
https://portal.vrbnopp.cz/ Město Vrbno pod Pradědem 167
https://portal.zcu.cz/nia/shibboleth IS/STAG ZČU 367
https://portal.zlin.eu/obcan PO Zlín 727
https://portal.zpspraha.cz/id/ Zóny placeného stání - Praha 52784
https://portal1-test.wps.vsb.cz/cz.vsb.edison.edu.admission.web/nia Elektronická přihláška (test 2 - vývoj) 2
https://portal-auth.eambulance.cz/signin-e-identity eAmbulance 2990
https://portal-auth.krajprozdravi.cz/signin-e-identity Portál krajprozdravi 130
https://portal-auth.kzcr.eu/signin-e-identity Portál pacienta Ústeckého kraje 453
https://portal-auth.ncpeh.cz/signin-e-identity Portál NCPeH 460
https://portal-auth.nem-km.cz/signin-e-identity Kroměřížská nemocnice a.s. 20
https://portal-auth.nemocnice-vs.cz/signin-e-identity Vsetínská nemocnice a.s. 11
https://portal-auth.nemuh.cz/signin-e-identity Uherskohradišťská nemocnice a.s. 5
https://portal-auth.upmd.cz/signin-e-identity Ústav pro péči o matku a dítě 8
https://portal-auth.vfn.cz/signin-e-identity Všeobecná fakultní nemocnice v Praze - Portál pacienta 5
https://portal-auth-ppt.ncpeh.cz/signin-e-identity Portál NCPeH - PPT 376
https://portal-auth-test.nemocnice-vs.cz/signin-e-identity Vsetínská nemocnice a.s. 1
https://portal-caa.notia.com Portál úřadu pro civilní letectví - test 18
https://portaldopravy.cz/auth Portál Dopravy 333010
https://portaldron.caa.cz Portál provozovatele bezpilotních systémů 1878
https://portalmostecana.cz/portal/ Statutární město Most - Magistrát města Mostu 1393
https://portalobcana.cheb.cz/gordic/ginis/app/rap05/ Město Cheb - Portál občana 404
https://portalobcana.chomutov.cz/id/ Portál občana 2085
https://portalobcana.horovice.net/gordic/ginis/app/RAP05/ Město Hořovice - Portál občana 12
https://portalobcana.jihlava.cz/portal/ Statutární město Jihlava 1462
https://portalobcana.karvina.cz/portal/ Statutární město Karviná 1197
https://portalobcana.mestokralupy.cz/RAP05/ Město Kralupy nad Vltavou 276
https://portalobcana.meulovo.cz/id/ Portál občana Lovosice 2814
https://portalobcana.meuslany.cz/portal/ Portál občana Město Slaný 12
https://portalobcana.mikulov.cz/portal Mikulov - Portál občana města Mikulova 576
https://portal-obcana.morberoun.cz Moravský Beroun 52
https://portalobcana.muas.cz/portal/ Portál občana města Aš 403
https://portalobcana.muberoun.cz/id/ Portál občana města Beroun 470
https://portalobcana.mulouny.cz/ Město louny 81
https://portalobcana.muor.cz Město Orlová 734
https://portalobcana.muor.cz/ Město Orlová 1
https://portalobcana.muor.cz/portal https://portalobcana.muor.cz/portal 1
https://portalobcana.olomouc.eu/id Statutární město Olomouc 7
https://portalobcana.petrvald-mesto.cz/ Město Petřvald 26
https://portalobcana.praha13.cz ÚMČ Praha 13 336
https://portalobcana.praha3.cz/id/ Městská část Praha 3 4
https://portalobcana.praha5.cz MČ Praha 5 2165
https://portalobcana.pribram.eu/id/ Město Příbram 1463
https://portalobcana.ssgh.cz/ Střední škola gastronomická a hotelová s.r.o. 2
https://portalobcana.veseli-nad-moravou.cz/Gordic/Ginis/App/RAP05 město Veselí nad Moravou 2555
https://portalobcana.vodnany.eu/gordic/ginis/app/rap05/ Město Vodňany - Portál občana 6
https://portalpacienta.bulovka.cz/ eHealth Portál Fakultní nemocnice Bulovka 95
https://portalpacienta.fnhk.cz/ FAKULTNÍ NEMOCNICE HRADEC KRÁLOVÉ – PORTÁL PACIENTA 581
https://portal-pacienta.msk.cz/signin-e-identity https://portal-pacienta.msk.cz/signin-e-identity 1
https://portaltest.nacr.cz Národní archiv test 56
https://portal-test-auth.nem-km.cz/signin-e-identity Kroměřížská nemocnice a.s. 7
https://portal-test-auth.nemuh.cz/signin-e-identity Uherskohradišťská nemocnice a.s. (test) 5
https://portal-test-auth.vfn.cz/signin-e-identity Všeobecná fakultní nemocnice v Praze - TEST Portál pacienta 1
https://portal-ts-auth.eambulance.cz/signin-e-identity eAmbulance TS 25
https://posoh.brno.cz/gordic/ginis/app/rap05/ MMB Gordic POSOH 7987
https://prihlaska.amu.cz/apps/kos/prihlaska/ Přihláška ke studiu na Akademii múzických umění v Praze 44
https://prihlaska.amu.cz/apps/kos/prihlaska/wpr_stip_pg.main AMU - Žádosti o stipendium 5
https://prihlaska.cvut.cz/apps/kos/prihlaska/ Přihláška ČVUT 594
https://prihlaska.cvut.cz/apps/kos/prihlaska/wpr_stip_pg.main ČVUT - Žádosti o stipendium 5
https://prihlaska.utb.cz/muj-profil Univerzita Tomáše Bati ve Zlíně 110
https://prihlaska.vsb.cz/cz.vsb.edison.edu.admission.web/nia Elektronická přihláška 405
https://pristupy.sukl.cz/login Externí identity - Portál 12556
https://prod.frs.gov.cz/api/ip/saml2/authenticate/nia IP-PROD (FRS.GOV.CZ) 4
https://prod.portaldopravy.cz/auth https://prod.portaldopravy.cz/auth 9
https://prodpristupy8.iniba.eu/login Externí identity - Portál - Referenční 23
https://pssd.sporicidluhopisycr.cz/pssd-war/login DLUHOPIS REPUBLIKY 52650
https://psz.pardubickykraj.cz/Gordic/Ginis/App/RAP05/ GINIS Dotační portál 442
https://pz.kraj-jihocesky.gov.cz/gordic/ginis/app/rap05/ Jihočeký kraj - Portál občana 2879
https://rap.blansko.cz/gordic/ginis/app/rap05.test město Blansko - test 3
https://rap.blansko.cz/Gordic/Ginis/App/RAP05/ město Blansko 913
https://rap.olkraj.cz/gordic/ginis/app/RAP05/ RAP - OLK 166
https://rap.prostejov.eu Statutární město Prostějov 4
https://rap.prostejov.eu/ Statutární město Prostějov 1057
https://rap.sumperk.cz/ Šumperk 697
https://ref.api.vvz.nipez.cz/vvz-nia/ Věstník veřejných zakázek - ref 48
https://ref-login.cuzk.cz/nia/ ČÚZK - přihlašovací portál (REF - TEST) 8
https://registrace.mzcr.cz/detail Ministerstvo zdravotnictví 43542
https://registrace.mzcr.cz/Registration Ministerstvo zdravotnictví 4897
https://registrace.uzis.cz/detail https://registrace.uzis.cz/detail 2
https://rejstriksportu.cz/app Národní sportovní agentura 2995
https://rest-webauthenticationapplication.caais.gov.cz/ CAAIS 127
https://ros.caa.cz Žádost o ověření spolehlivosti 11080
https://ros.notia.cz Žádost o ověření spolehlivosti - test 8
https://samotestovani.uzis.cz/ Ústav zdravotnických informací a statistiky ČR 777
https://sd21.mssf.cz/ SD21+ 9142
https://sd21-ref.mssf.cz/ SD21+ Ref 5
https://sd21-sandbox.mssf.cz/ https://sd21-sandbox.mssf.cz/ 2
https://sd21-test.mssf.cz/ SD21+Test 121
https://sdg.cuni.cz/saml2/service-provider-metadata/NIA Univerzita Karlova SDG 5
https://sdg.vscht.cz/saml2/service-provider-metadata/NIA Vysoká škola chemicko-technologická v Praze - SDG 14
https://sdt.nipez.cz/csm_nen_external?id=homepage_nia CSD NIPEZ 13
https://sep.ustrcr.cz/ABS/Meta eBadatelna Archivu bezpečnostních složek 3430
https://sista.tacr.cz/idm/api/v1/nia/login TAČR SISTA 1397
https://skoleni-istp.mdcr.cz/Logon.aspx Informační systém technických prohlídek - ŠKOLÍCÍ 1243
https://sluzby.alis.cz/cejc Obec Čejč 16
https://sluzby.alis.cz/ckyne obec Čkyně 34
https://sluzby.alis.cz/hrusice Obec Hrusice 72
https://sluzby.alis.cz/kamenicky-senov Město Kamenický Šenov 303
https://sluzby.alis.cz/ledenice/ Městys Ledenice 2
https://sluzby.alis.cz/ludvikovice Obec Ludvíkovice 19
https://sluzby.alis.cz/mestobechyne Město Bechyně 325
https://sluzby.alis.cz/mestozliv Město Zliv 339
https://sluzby.alis.cz/mlade-buky Městys Mladé Buky 152
https://sluzby.alis.cz/mukarov Obec Mukařov 600
https://sluzby.alis.cz/obecdoubravice Obec Doubravice 14
https://sluzby.alis.cz/obechermanicky Obec Heřmaničky 62
https://sluzby.alis.cz/obecrimov Obec Římov 42
https://sluzby.alis.cz/obec-roudne Obec Roudné 50
https://sluzby.alis.cz/obecstarehodejovice Obec Staré Hodějovice 54
https://sluzby.alis.cz/rokytnice-nad-jizerou Město Rokytnice nad Jizerou 95
https://sluzby.alis.cz/ronov-nad-doubravou Město Ronov nad Doubravou 8
https://sluzby.alis.cz/rtyne Město Rtyně v Podkrkonoší 168
https://sluzby.alis.cz/sardice Obec Šardice 17
https://sluzby.alis.cz/usti usti 9
https://sluzby.alis.cz/zs-panskapole Svazková základní škola Panská pole 1
https://sluzby.alis.cz/zubri Město Zubří 12
https://sluzby.breclav.eu/portal/ Město Břeclav 98
https://sluzby.muznojmo.cz/Portal/ Znojmo - Portál občana města Znojma 1724
https://sportal.odolenavoda.cz/portal VERA portál občana sml2 419
https://sps.portaldopravy.cz/zadost-191/ Státní plavební správa 522
https://sps.test.portaldopravy.cz/zadost-191/ https://sps.test.portaldopravy.cz/zadost-191/ 6
https://ssl.boskovice.cz/Gordic/Ginis/App/RAP05/ Město Boskovice 366
https://sso.esfcr.cz/cas/login IS ESF 463
https://sso.plzensky-kraj.cz Plzeňský kraj 127
https://stag.tul.cz/nia/shibboleth stag.tul.cz 621
https://stag.uhk.cz/nia/shibboleth IS/STAG 298
https://stag.utb.cz/nia/shibboleth Univerzita Tomáše Bati ve Zlíně 3
https://stag-avu.zcu.cz/nia/shibboleth stag-avu.zcu.cz 25
https://stag-demo.uhk.cz/nia/shibboleth IS/STAG TEST 2
https://stag-demo.utb.cz/nia/shibboleth Univerzita Tomáše Bati ve Zlíně 1
https://stag-demo.zcu.cz/nia/shibboleth IS/STAG 5
https://stage.portaldopravy.cz/auth Portál Dopravy - STAGE 49
https://stagweb.vfu.cz/nia/shibboleth stagweb.vfu.cz 119
https://studium.vsb.cz/financovani/nia Žádost o financování studia 6
https://sujb.gov.cz/aplikace/ireg2/irp/am/#/private/vyber-aplikace sujb.gov.cz 91
https://testag.msk.cz/authgate/pages/user.xhtml Identitní brána MSK – vývoj 97
https://test-pacient.vfn.cz VFN TEST pacient 7
https://tnc.ssw.cz/nsa Národní sportovní agentura 40
https://tsm-eru-portal.datalite.cloud/ ERÚ test - portál 10
https://tsm-portal.eru.cz/ https://tsm-portal.eru.cz/ 24
https://tsm-portal-dev.eru.cz/ Datový portál ERÚ - DEV 10
https://udeska.olkraj.cz/Gordic/Ginis/App/RAP05.test/ RAP_test 7
https://udeska.olkraj.cz/Gordic/Ginis/App/RAP05/ Olomoucký kraj 1331
https://usk.krajdtm.cz/auth/realms/USK DTM-USK 29
https://utilityreport.eu/ UtilityReport 188
https://utilityreport.eu/PN/ UtilityReport - Plzeňský kraj 76
https://utilityreport.eu/VN/ UtilityReport 105
https://verejnost.cbusbs.cz/cas Český báňský úřad 237
https://verso.sukl.cz/shibboleth Verso 133
https://vns.doarmady.cz Virtuální Náborové Středisko 3224
https://vns.doarmady.cz/ Virtuální Náborové Středisko 2
https://vouchery.kreativnicesko.cz/private KKO 5410
https://vps2.rsts.cz/cibis-sale/eidas Raiffeisen stavební spořitelna 2
https://vtk-test.ozp.cz/vkol https://vtk-test.ozp.cz/vkol 6
https://vuapraha.cz/badatelna/api/prihlaseni/nia Ministerstvo obrany České republiky 792
https://vys.krajdtm.cz/auth/realms/VYS DTM-VYS 169
https://web.mpsv.cz/cas https://web.mpsv.cz/cas 237
https://webservices.sumperk.cz/webservices/zapis Zápis Šumperk 1
https://webservices.sumperk.cz/webservices/zapis/ Zápis Šumperk 1
https://wstag.jcu.cz/nia/shibboleth IS/STAG 766
https://wstag-test.jcu.cz/nia/shibboleth IS/STAG - test 1
https://www.1zdar.cz/nia-formular Základní škola Žďár nad Sázavou, Palachova 2189/35, příspěvková organizace 1
https://www.3zsvm.cz/nia-formular Základní škola Velké Meziříčí, Školní 2055, příspěvková organizace 2
https://www.ak-vych.cz AK Vych & Partners 2
https://www.chyne.cz/ucet Obec Chýně 450
https://www.ctu.cz https://www.ctu.cz 12
https://www.ctu.cz/ https://www.ctu.cz/ 16
https://www.czechpoint.cz/ JIP Czech POINT 8967
https://www.horniradslavice.cz/nia-formular Obec Horní Radslavice 7
https://www.kzmpribyslav.cz/mia-formular Město Přibyslav 4
https://www.martinice.eu/nia-formular Obec Martinice 9
https://www.mateda.cz Mateda, a.s. 7
https://www.mojedatovaschranka.cz/portal/ISDS/ Informační systém datových schránek 1146702
https://www.mpsv.cz/cas Klientský portál MPSV 395121
https://www.msbites.cz/nia-formular Mateřská škola Velká Bíteš, U Stadionu 538, příspěvková organizace 5
https://www.msbudisovtr.cz/nia-formular Mateřská škola Budišov 3
https://www.msmerin.cz/nia-formular Mateřská škola Měřín, příspěvková organizace 12
https://www.msostrovno.cz/nia-formular Mateřská škola Ostrov nad Oslavou, okres Žďár nad Sázavou, příspěvková organizace 6
https://www.nabidkamajetku.cz/Login.ashx Úřad pro zastupování státu ve věcech majetkových 6186
https://www.naevia.cz Naevia Estate s.r.o. 3
https://www.obecbabice.eu/nia-formular Obec Babice 2
https://www.obeccerna.cz/nia-formular Obec Černá 12
https://www.obec-dobravoda.cz/nia-formular Dobrá Voda 23
https://www.obecruda.eu/nia-formular Obec Ruda 7
https://www.obec-tasov.cz/nia-formular Obec Tasov 6
https://www.obec-uncin.cz/nia-formular Obec Unčín 7
https://www.obec-zablati.cz/nia-formular Obec Záblatí 1
https://www.orechov-ronov.cz/nia-formular Obec Ořechov 20
https://www.ozp.cz/auth/realms/ozp https://www.ozp.cz/auth/realms/ozp 9224
https://www.ozp.cz/prod2vtk/vkol ICIS Vitakarta 12465
https://www.paropisek.cz/appsep.php PaRo Písek 377
https://www.portalprazana.cz/auth Portál Pražana 32703
https://www.postsignum.cz/certifikatonline/ Česká pošta, s.p. 3401
https://www.radnoves.cz/nia-formular Obec Radňoves 1
https://www.rapotice.cz/nia-formular Obec Rapotice 7
https://www.rejstriksportu.cz/app https://www.rejstriksportu.cz/app 3
https://www.roklen.cz Roklen360 a.s. 12
https://www.rzp.cz/niaeis Ministerstvo průmyslu a obchodu 62217
https://www.skolaradostinno.cz/nia-formular Základní škola a Mateřská škola Radostín nad Oslavou, příspěvková organizace 5
https://www.skola-ruda.cz/nia-formular Základní škola a mateřská škola Ruda, příspěvková organizace 6
https://www.slavicky.cz/nia-formular Obec Slavičky 1
https://www.sujb.cz/aplikace/ireg2/irp/am/#/private/vyber-aplikace Portál elektronických podání SÚJB 107
https://www.svetlavm.cz/nia-formular Hotelová škola Světlá a Střední odborná škola řemesel Velké Meziříčí 16
https://www.uradfm.cz/portal Portál občana Frýdek-Místek 2791
https://www.uradfm.cz/portal/ Portál občana Frýdek-Místek 1
https://www.vidonin.cz/nia-formular Obec Vidonín 1
https://www.vlkov.cz/nia-formular Obec Vlkov 14
https://www.vut.cz IS VUT - ePřihláška 5
https://www.vut.cz/eprihlaska IS VUT - ePřihláška 185
https://www.zadnizhorec.cz/nia-formular Obec Zadní Zhořec 7
https://www.zdirec.cz/nia-formular Město Ždírec nad Doubravou 21
https://www.zsdolnihermanice.cz/nia-formular Základní škola a Mateřská škola Dolní Heřmanice, příspěvková organizace 2
https://www.zsmerin.cz/nia-formular ZŠ Měřín 13
https://www.zsmostiste.cz/nia-formular Základní škola a mateřská škola Velké Meziříčí, Mostiště 50, příspěvková organizace 7
https://www.zsoslavice.cz/nia-formular Základní škola Oslavice 4
https://www.zsostrovno.cz/nia-formular Základní škola Ostrov nad Oslavou, příspěvková organizace 1
https://www.zssokolovska.cz/nia-formular Základní škola Velké Meziříčí, Sokolovská 470/13 2
https://www.zsvaclav.cz/nia-formular Základní škola Třebíč, Horka-Domky, Václavské nám. 44/12 3
https://www.zusvm.cz/nia-formular Základní umělecká škola Velké Meziříčí, příspěvková organizace 16
https://www-test.ozp.cz/auth/realms/ozp https://www-test.ozp.cz/auth/realms/ozp 11
https://www-test.ozp.cz/vkol ICIS - VITAKARTA - TEST 5
https://zadosti.sfzp.cz/AISPortal/NIA/overeni Státní fond životního prostředí České republiky 245204
urn:mep:demoportal MEP Test Portal 1
urn:moris:adu ADU 2073
urn:moris:eidasproxyservice eIDAS ProxyService 7415
urn:moris:ocisteniidp NIA Overeni Meg 829
urn:moris:overovaciportal Ověřovací portál 4404
urn:moris:portal Portál Národního bodu (NIA Portál) 1068185
urn:moris:portal:mep:proofing Portál Národního bodu - Identity MEP proofing IDP 24350
urn:moris:portal4 Portál Národního bodu - Identity proofing IDP 129987

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/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+available+attributes+of+pre-notified+and+notified+eID+schemes.

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.
Email Email 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:

  1. 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.
  2. 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.
  3. Každý úřad musí akceptovat nejen identitu českého občana, ale kteréhokoliv občana Evropské Unie dle eIDAS.
  4. Jakýkoliv nový identitní prostor musí být budován tak, aby byl federovaný v rámci Národní identitní autority.
    1. 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.
  5. 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.
  6. 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í.
  7. 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ů.
  8. 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.

  1. 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ů.
  2. 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).
  3. 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.
  4. 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ů.
  5. 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.
  6. 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.
  7. 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.
  8. 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ů.
  9. Uživatel potvrdí správnost údajů a provedení registrace organizace (SeP).
  10. 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ů).
  11. 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:

  1. 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
  2. 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….)
  3. 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:

  1. 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.
  2. 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.
  3. 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í:

  1. 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.
  2. 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í:

  1. ze dne 19. ledna 2024, sp. zn. ZN/MZP/2024/280/6, odpověď DIA byla poskytnuta pod sp. zn. DIA- 2188-2/OPL-2024
  2. 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):

  1. 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.
  2. 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.
  3. 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.
  4. 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;
  5. 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.
  6. 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:

  1. 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ň
  2. 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:

  1. 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ů (*)
  2. 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:

  1. 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
  2. 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:

  1. Do sítě CMS/KIVS, služba CMS2-02-1 a/nebo
  2. 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:

  1. eGC je rozšířeným IP prostorem CMS/KIVS a
  2. CMS/KIVS a eGC jsou propojeny standardním způsobem dle podmínek připojení se k CMS/KIVS.
  3. 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

1)
Přehled prostředků s jejich úrovní záruky seznam_poskytovatelu_identity_identity_provideridp
2)
z těchto služeb CC si mohou orgány veřejné správy v souladu se ZoISVS vybírat, který CC lze využívat