Translations of this page:

How shared services, functional units and thematic areas are used by individual authorities

This chapter describes the use of shared services, functional units and thematic areas in their entirety (across the architecture), including rules, guidelines and good practices for embedding them in the information concept and architecture of the authority. This is a different approach to describing the requirements for the use of eGovernment systems and services than in Authority architecture in the context of public administration and its layers of architecture, where requirements are described through the different layers of the authority architecture.

functional_object

The composition of this chapter corresponds to the shared services, functional units and thematic areas from Description of shared services, functional units and thematic areas of public administration in the Czech Republic:

Thematic areas

Shared Services and functional_units

Rules for the 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 architecture of the office is described in Architecture of the office in the context of public administration and its architecture layers.

The description of centrally provided systems and their services, functional units and thematic areas within the public administration agenda model is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of the access to the VS agenda model will be described by the authority in its information concept.

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.

Public Administration Client Identification Rules

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 description of centrally provided systems and their services, functional units and thematic areas in the context of the identification of public administration clients is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of access to electronic identification of VS clients shall be described by the authority in its information concept.

.

Linked Data Rules

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.

A description of the centrally provided systems and their services, functional units and thematic areas within the linked data pool is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use and description to access the linked data pool shall be described by the authority in its information concept.

.

Interconnected Data Fund Description

The information provided here on the Interconnected Data Fund (PPDF) and all its subdomains (ISZR, eGSB/ISSS, etc.) is based on Global Linked Data Architecture, which is an annex to the NAP itself in extending knowledge base.

The Interconnected Data Fund (also referred to as PPDF) is a subject area consisting primarily of Basic Registry Information System and eGON Service Bus/Shared Service Information System, whose services are published through the Central Service Point. The PPDF and its systems/services are the physical representation of the public administration reference interface. The basic function of PPDF is to implement the principles of "Once-only" and "Data circulate, not people" into the common practice of public administration in the Czech Republic. PPDF is the primary source of valid and legally binding data for legal entities and for all OVMs and SPUUs in the exercise of their competences. Thus, the PPDF will lead to the replacement of manual interactions between authorities by automated data exchange between different Agenda Information Systems.

Agenda Information System is a term from Act 111/2009 Coll. and refers to such Public Administration Information Systems that are used for the execution of an agenda. Therefore, the PPDF texts contain both the terms Public Administration Information System and Agenda Information System. It also includes the term Private Data Use System, which is equal to the Agenda Information System, but has a different administrator than a traditional public authority.

The interconnection between the Agenda Information Systems and the basic registers is provided by Basic Registers Information System, the interconnection between the Agenda Information Systems and each other is provided by eGON Service Bus/Shared Services Information System. All links made within the PPDF are always linked to the basic registers by means of reference links to reference data on subjects of law (natural persons, legal persons and OVMs) and reference data on objects of law (territorial elements and rights and obligations). For the reference links of data on natural persons, the Agency Identifier of Natural Persons (AIFO) is used, for the reference links of legal persons the Person Identification Number (PIN), for the reference links of territorial elements their respective identifiers assigned by RUIAN. In addition to the development and support of the linked principles of data stem management and pseudonymisation, the main objective of the PPDF is the development of additional agenda sources of non-public data from key areas of public administration (transport, health, social services…) by a clearly defined guarantor and editor. There is a greater emphasis on interoperability between EU Member States and PPDF will be ready to provide services for cross-border data exchange. In the realities of 2020, about 3,500 information systems out of a total of about 7,000 are connected to PPDF services. In addition to connecting all public administration information systems, the basic objective of the PPDF is to ensure that the connection for the relevant ISVS is not only reader-type (draw data) but also publisher-type (provide their data). It is only when all relevant public administration information systems are drawing on and providing PPDF services that we can speak of a interconnected data fund.

The basic services of the PPDF for authorised PPDF readers are:

  • Identification (assignment of an identifier) of the subject/object of the right held in the AIS and thus support pseudonymisation
  • Issuing data on the subject/right object according to the required context within the scope of the authorisations held in the RPP for the relevant AIS-supported agenda
  • Notification of changes to reference and agency data for data held in AIS
  • Support for claiming erroneous data

View of the Interconnected Data Fund

Interconnected Data Fund Rules

Data, documents, outputs and extracts

Central to the proper use and understanding of the meaning of the Interconnected Data Fund is an understanding of the difference between Data Provision/Use, Document Provision/Use, Information System Outputs and Information System Extract.

Data Provision/Use

At the business layer, a public authority that carries out the exercise of public administration, operates in an agenda that it has duly reported in the RPP, is obliged to use for these purposes the current state-guaranteed data from the RoW and furthermore to publish and draw on agenda data via the eGon Service Bus / Shared Service Information System. A private law entity (also as a SPUU) may also, subject to the legal authorisation to exercise public administration and to act in a certain agenda announced by the OVM, draw data from the basic registers, but only via the OVM AIS or Czech POINT forms. In Act No. 111/2009 Coll. - Act on Basic Registers, a new global authorisation for drawing OVM data from the RR will be established, while the RPP serves as a source of information for the information system of the RR in controlling user access to data in individual registers and agency information systems. This means that whenever a given subject attempts to retrieve a certain data or even to change (edit) it, the system assesses whether the subject will be allowed to work with the data provided by the public administration on the basis of the legal authorisation. In the RPP as a meta-information system for public administration performance, the authorisations within the agendas for extracting data from the RoI are listed, but also all data published by the state and local government using the eGon Service Bus / Shared Service Information System across the public administration. An important factor at the business layer in the extraction of data from the RoW and also the publication and extraction of data within the individual OVM AIS is to have a properly reported agenda in the RPP, which is a prerequisite.

The list of agendas maintained in the RPP is available at: https://rpp-ais.egon.gov.cz/gen/agendy-detail/

At the application layer, through the web services of the individual reference interfaces, which include the basic registers management information system, eGon Service Bus / Shared Services Information System, Czech POINT and the form-based agency information system FAIS, the institution is obliged to draw reference data from the RO by its AIS and to further provide and use the data via IeGon Service Bus / Shared Services Information System across the public administration. In addition, it is also possible to draw reference data from the CR via data repositories.

One of the rules of retrieving reference data by web services is to first identify your data trunk against the ZR and then log in to receive notifications of changes. Another option, but in extreme cases if the institution's data trunk is not very large, is to perform periodic updates of the entire data trunk to identify the subject of the RR in the exercise of public administration.

Another rule for the handling of personal data is pseudonymisation of data, which means storing the data using the technique of separating the agenda and identification data and linking them by means of an agenda identifier of natural persons (also referred to as AIFO), in order to meet the conditions of security and the various laws and regulations that arise from these circumstances. The retrieved AIFO must not under any circumstances leave the AIS that retrieved it from the ISZR services and must always use the ISZR services when transmitting it (for the purpose of transmitting information about the natural person). More information on how AIFO is used in the context of pseudonymisation is provided in here.

In terms of the technology layer, it is purely up to the individual institution what platform they choose within the internal workings of the authority to connect to in order to use the services of the Interconnected Data Fund, whereby access to the ZR can be via the ISZR directly via AIS or the communication bus.

At the communication layer, the institution is obliged to use the CMS in the exercise of public administration. The CMS is a system whose primary purpose is to provide a controlled and registered connection of information systems of public administration entities to services (applications) provided by information systems of other public administration entities with defined security and SLA parameters, i.e. access to eGovernment services. CMS can thus be called a private network for the performance of public administration on the territory of the state. CMS as a private network of public administration uses dedicated or leased network resources for secure interconnection of public administration officials (also referred to as OVS) working in public administration agencies with their remote agency information systems, for secure network interconnection of agency systems with each other and for secure access of individual OVS to the Internet.

Provision / Use of documents

Documents are transferred through a reference interface in relation to a subject or object of law via the eGON Service Bus / Shared Service Information System, or also via the data box information system. Documents are created by output from the public administration information system according to law no.365/2000 Coll..

Extracts from the public administration information system

An extract from the public administration information system is a document that is created from public and non-public records. An extract may take the form of a partial or full extract of all data held in the public administration information system.

  • Extraction from a public record: the extract is not intended for a specific person and all the information contained is public.
  • Extraction from non-public records: the extract is intended for a specific person who is the subject of a right or another authorised person and includes non-public information.

Extracts are created according to Law No. 365/2000 Coll.

Outputs from the public administration information system

An output from the public administration information system is an electronic document which is an extract from the public administration information system, but which is also secured in a way that ensures data integrity. That is to say, it is an extract from a public administration information system that is electronically sealed/signed and time-stamped by the issuing public administration information system.

There is also a special variant of the output from the public administration information system, the so-called verified output, which is created by a complete conversion of the output from the public administration information system from electronic to documentary form and contains the elements according to Act No.365/2000 Coll.. The certified output is therefore always in documentary form.

Public document

According to the Civil Code, a public document is a document issued by a public authority within the limits of its powers or a document declared a public document by law. If a fact is certified in a public deed, it establishes against everyone full proof of the origin of the deed from the authority or person who established it, of the time of the creation of the deed, and of the fact which the originator of the public deed certified to have occurred or been performed in his presence, until the contrary is proved. Where a public instrument records the manifestation of the will of a person in a legal act and is signed by the actor, it shall constitute full proof against anyone of such manifestation of will. This applies even if the signature of the actor has been substituted in the manner provided by law.

A public instrument is all:

  • listic extracts from the public administration information system,
  • outputs from the public administration information system,
  • verified outputs from the public administration information system.

Public Data Pool Rules

The description of the architecture of the office and the public administration of the CR 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 description of centrally provided systems and their services, functional units and thematic areas within the public data pool is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use of and description to access the public data pool shall be described by the authority in its information concept.

.

Entity Registration Rules

The description of the architecture of the authority and the public administration of the CR 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 description of centrally provided systems and their services, functional units and thematic areas within the public administration agenda model is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of the access to the VS agency model will be described by the authority in its information concept.

Rules for Spatial Data and Services over Spatial Data

The description of the architecture of the authority and the public administration of the CR 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 description of centrally provided systems and their services, functional units and thematic areas within the full electronic submission is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use and description to access spatial data and services over spatial data shall be described by the authority in its information concept.

.

Full Electronic Filing Rules

The description of the architecture of the office and the public administration of the CR by each layer of architecture and the incorporation of the requirements into the information design and architecture of the office is described in Architecture of the office in the context of the public administration and its layers of architecture.

A description of the centrally provided systems and their services, functional units and thematic areas within the context of full electronic submission is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use of and description to access full electronic filing will be described by the authority in its information concept.

Popis úplného elektronického podání

Úplné elektronické podání (také jako "ÚEP") je možné popsat tak, že klient/občan, ale i zástupce právnické osoby, má možnost vyřídit všechnu svou potřebnou agendu životní situace, prostřednictvím elektronické interakce samoobslužně kdykoli a odkudkoli či asistovaně z kteréhokoli univerzálního kontaktního místa VS, bez nutnosti osobní návštěvy na příslušných úřadech, a následně možnost mít přehled o stavu a vývoji všech svých řešených životních událostí.

Současně pojem ÚEP představuje pokročilou variantu elektronického podání (elektronické formy úkonu klienta, občana a/nebo organizace vůči veřejné správě ČR), která splňuje sadu požadovaných vlastností, daných primárně tzv. architektonickými principy eGovernmentu a dále vlastnosti předpokládané pro podání vůči veřejné správě právními předpisy, zejm. správním řádem a agendovými zákony.

Elektronické podání klienta vůči veřejné správě je považováno za úplné, pokud splňuje všechny architektonické principy eGovernmentu a další náležitosti, zejména pak:

  • Podporuje princip Digital by Default tím, že je navrženo jako vnitřně plně digitální (nikdy se nemusí tisknout nebo osobně řešit), s tím, že ale podporuje asistovanými formami i tzv. elektronicky handicapované.
  • Podporuje princip Whole-of-Government tím, že je dostupné rovnocenným způsobem ve všech elektronických kanálech eGovernmentu (samoobslužných i asistovaných), s upřednostněním univerzálních kontaktních míst (CzechPOINT a PO v PVS).
  • Podporuje princip Once only tím, že pro předvyplnění formuláře i pro navigaci a volbu služby jsou využity všechny údaje o klientovi, které veřejná správa má a ze zákona je v dané situaci smí použít.
  • Podporuje principy Interoperability by Default a Cross-border by default tím, že umožňuje elektronicky obsloužit všechny klienty, rezidenty ČR a EU, pro které je úkon relevantní, a to i vzdáleně ze zahraničí.
  • je po podání automatizovaně strojově zpracováno, převedeno do transakčního záznamu agendového informačního systému.
  • Podporuje princip Inclusion and Accessibility tím, že podporuje asistovanými formami i tzv. elektronicky (nebo jinak) handicapované.
  • Využívá Jednotný identitní prostor veřejné správy a Elektronickou identifikaci pro klienty veřejné správy .
  • Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.

Všechny obslužné kanály veřejné správy musí být cílově vzájemně integrovány tak, aby mezi nimi bylo možno libovolně přecházet i v průběhu vyřizování podání a aby všechny informace byly zachovány, přenášely se do nich (mezi nimi).

Pravidla úplného elektronického podání

Úřad musí respektovat všechny návazné funkční celky jako např. propojený datový fond, portály veřejné správy či komunikační infrastrukturu veřejné správy a procesně zajistit zpracování podání tak, aby probíhalo elektronicky po celou dobu jeho životního cyklu.

Úřad pro splnění požadavků kladených na úplné elektronické podání musí splnit svými obslužnými kanály (např. portál):

  • Využití Jednotného identitního prostor veřejné správy pro úřední osoby a Elektronickou identifikaci pro klienty veřejné správy.
  • Předvyplnění podání všemi státu známými údaji klientovi po prokázání elektronickou identitou. Zajištění tohoto požadavku se splní čerpáním údajů z Propojeného datového fondu.
  • Má služby svých agend v rámci ÚEP a jejich IT aplikace navrženy tak, aby služby bylo možno v obslužných kanálech kombinovat pro efektivním řešení životních událostí.
  • Umožňuje klientům učinit podání skrze různá elektronická rozhraní (webová stránka, formulář nebo asistovaná služba) a sledovat průběh vyřizování jejich podání skrze to samé rozhraní, přes které bylo podání realizované nebo jiné klientem určené.
  • Postupně všechna existující práva a povinnosti ze vztahu k VS budou doprovázena transakční službou (nejenom popisem návodu) v Portálu občana, a to v těch všech případech, kdy elektronická transakční služba bude proveditelná a bude odpovídat oprávněným zájmům klientů a současně i úřadů.
  • Elektronické podání formou ÚEP lze uskutečnit i papírově (off-line), tzn. půjde stáhnout předvyplněný formulář, ručně vyplnit, zaslat datovou schránkou nebo elektronicky podepsané doručit jakkoli jinak (i mailem, vložením do portálu), případně vložit do elektronické aplikace úřadu.
  • V případě menší četnosti podání stačí jeden z obou kanálů (on-line nebo off-line), musí však umožňovat dobrou (personalizovanou) navigaci ke službě a k jejímu předvyplnění.
  • Stejnou službu lze získat s pomocí služby úředníka na kterémkoli fyzickém kontaktním místě asistovanou formou. Pro typové a jednoduché podání pro řešení typových životních situací to takto bude možné na Univerzálních asistovaných kontaktních místech.
  • Zůstanou zachovány tradiční kanály pro příjem listinných podání osobně, diktátem do protokolu nebo poštou – úřední přepážky a podatelny. Jejich úkolem ale bude obdržené vstupy neprodleně plně digitalizovat, aby celé další následné zpracování bylo jednotně plně elektronické.
  • Nedílnou součástí řady podání je splnění finanční povinnosti (poplatku, daně). Platební brána tedy musí být součástí obslužného rozhraní. Pro agendy v samostatné působnosti je platební brána plně v zodpovědnosti koncového úřadu, pro agendy v přenesené působnosti musí o způsobu rozhodnout správce agendy.
  • Elektronické samoobslužné služby pro klienty/občany i pro právnické osoby musí být doplněny interaktivním podpůrným a poradenským kanálem (service-desk, call-me-back, apod.).
  • Podání nemusí vždy činit ta osoba, která je přihlášena elektronickou identitou, ale může se jednat o osobu zastupující jinou osobu. Úřad tedy musí zajisti správu mandátů.
  • Pro individuální přizpůsobení uživatelského rozhraní musí úřad využívat tzv. klientské profily. Každý jedinečný a jednoznačně identifikovaný klient má profil jenom jeden. V tomto profilu jsou uchovávány osobní i agendové údaje ve shodě se pravidly správy údajů Právní aspekty pro pseudonymizaci.
  • Podání zadané či zpracované v rámci řešení pro ÚeP musí být vždy přijímáno na podatelně a evidováno v systému eSSL nebo samostatné evidenci dokumentů v souladu se zákonem o archivnictví a spisové službě. Jejich přijetí musí být potvrzeno příslušnou odpovědní zprávou.

Information Systems Integration Rules

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 description of centrally provided systems and their services, functional units and thematic areas in the context of a full electronic submission is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use and description of the approach to information systems integration will be described by the authority in its information concept.

Rules for 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 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.

A description of centrally provided systems and their services, functional units and subject areas within public administration portals and private data users is described on a separate page here or within the Architecture of shared public administration services.

The use and description to access the VS and SPUU portals will be described by the authority in its information concept.

.

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!

Rules for Accessibility of Information

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 description of centrally provided systems and their services, functional units and thematic areas in the context of information accessibility is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of accessibility of information shall be described by the authority in its information concept.

.

Electronic Invoicing Rules

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 description of centrally provided systems and their services, functional units and thematic areas in the context of e-invoicing is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use of and description for access to electronic invoicing shall be described by the authority in its information concept.

Rules for the Citizen Portal and the Public Administration Portal

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.

A description of the centrally provided systems and their services, functional units and thematic areas within the citizen portal and the public administration portal is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use and description of the access to the citizen portal and the public administration portal shall be described by the authority in its information concept.

Popis Portálu občana a Portálu veřejné správy

Portálem občana je myšlena transakční část Portálu veřejné správy dostupná na adrese https://www.portal.gov.cz/, 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. Služby portálu občana přejímají veškeré služby CzechPOINT@home, který byl určen pro občany, kteří nechtějí pro výpis z rejstříku chodit na kontaktní místo Czech POINT a mají zřízenu vlastní datovou schránku fyzické osoby. Datová schránka žadatele slouží pro odeslání žádosti a pro doručení vystaveného výpisu z rejstříku nebo jiné odpovědi.

V případě Portálu občana, jakožto součásti Portálu veřejné správy, stojí občan jako samoobslužný uživatel „vně" veřejné správy a portál mu poskytuje jedno univerzální vstupní místo dovnitř. Z toho důvodu jsou všechny věcné (agendové) a do budoucna i místní portály se svými službami federalizovány „pod" tímto ústředním portálem. Federace je na různých úrovních, které https://www.portal.gov.cz/Portál občana podporuje:

  • Federace Single sing-on
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní idenitní autority. Na Portálu občana je zveřejněna jen informace (link), na které adrese na nachází federovaný portál.
  • Federace s poskytováním údajů
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní identitní autority. Na Portálu občana je zveřejněna interaktivní část, která aktivně poskytuje údaje ze své působnosti.
  • Federace s obsloužením služeb
    • Zajištění propojení pomocí jednotné elektronické identity, která je realizována systémem Národní identitní autority. Na Portálu občana je zveřejněna celá služba, včetně potřebných formulářů a logiky nutné k vyřízení.

Portál občana pro svou funkcionalitu využívá služby propojeného datového fondu, stejně tak služby národní identitní autority. Z pohledu propojeného datového fondu je Portál občana jedním ze čtenářských AIS, který má zmocnění dle agendy A344 zobrazovat subjektu práva jeho informace, které o něm vede veřejná správa. Portál občana v tomto musí zajistit, aby agenda, dle které se řídí byla neustále aktualizovaná dle toho, jak se budou postupně rozšiřovat služby a portály poskytující údaje. Technicky je Portál občana připojený jako čtenářský AIS na systém eGON Service Bus, skrze který čerpá údaje publikované agendami pomocí tzv. kontextů. V tomto musí Portál občana pouze pravidelně aktualizovat čerpaný seznam kontextů jiných agend. Z pohledu národní identitní autority je Portál občana poskytovatelem služeb čerpající zaručené služby identifikace a autentizace.

Pravidla Portálu občana a Portálu veřejné správy

Portál občana i portál veřejné správy jsou centrálně poskytované a provozované portály. Integrovat, či federovat služby úřadu lze přes vlastní řešení v podobě agendových portálů, portálů území či soukromoprávních uživatelů údajů. Integrace je celkem na 3 stupních:

  1. Proklik na vlastní řešení s využitím Single Sign-On. Obsahuje pouze vlastní prostor na portálu občana, kde úřad zveřejní svou informační dlaždici, skrze kterou se klient dostane, s využitím principu Single Sign-On a zapojení do národního identitního prostoru, na vlastní řešení
  2. Poskytování údajů do vlastního prostoru na portálu občana. Kromě možnosti prokliku na vlastní řešení zapojeného do národního identitního prostoru obsahuje i vždy aktuální údaje o klientovi poskytované skrze propojený datový fond
  3. Kompletní vyřešení služby veřejné správy na portálu občana pomocí formulářového řešení se všemi integracemi v bodech 1 a 2.

Přihlášení k portálu občana

Pro přístup na Portál občana je nutností přihlášení uživatele. Zvolený způsob přihlášení určuje i rozsah služeb, které jsou pro uživatele přístupné. Přihlašovací stránka Portálu občana je dostupná na adrese https://obcan.portal.gov.cz. Přihlášení je možné:

  • prostřednictvím kvalifikovaného systému elektronické identifikace (NIA) v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci, a to s využitím občanského průkazu s elektronickou částí (pouze průkazy vydávané od 1. 7. 2018, nevyžadována registrace) nebo s využitím identifikačního prostředku Jméno, heslo a SMS (nutná registrace), příp. s využitím dalších prostředků identifikace.
  • prostřednictvím autentizačního rozhraní Informačního systému datových schránek v souladu se zákonem č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů. Přihlášení je umožněno pouze těmto typům subjektů – držitelů datových schránek:
    • fyzická osoba (FO)
    • podnikající fyzická osoba (PFO)

Přitom lze využít pouze datové schránky zřízené na žádost, nikoli ze zákona, tedy nikoli ty zřizované automaticky advokátům, statutárním auditorům, daňovým poradcům nebo insolvenčním správcům. Všechny možnosti přihlášení jsou na sobě nezávislé, ale pro plné využití všech služeb Portálu občana je doporučeno použít elektronický občanský průkaz a dále mít připojenou datovou schránku. V obou případech se jedná o přístup se zaručenou identitou v souladu se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, jinými slovy o přístup do informačního systému veřejné správy nebo elektronické aplikace s využitím prostředku pro elektronickou identifikaci, při jehož vydání nebo v souvislosti s ním anebo v souvislosti s umožněním jeho využití byla totožnost osoby ověřena státním orgánem, orgánem územního samosprávného celku nebo orgánem veřejné moci, který není státním orgánem ani orgánem územního samosprávného celku, nebo který byl vydán v rámci kvalifikovaného systému elektronické identifikace.

Evidence údajů

Portál občana uchovává perzistentně typově takovéto informace:

  • BSI (bezvýznamové směrové identifikátory) – jde o celou sadu identifikátorů, které slouží ke komunikaci s okolními systémy (např. AIFO – ISZR, SePP – NIA atd.). Tyto identifikátory mají význam cizího klíče. Z jejich hodnoty (převážně jde o GUID) nelze přímo vyčíst žádné informace o uživateli. Tyto identifikátory neopouštějí perimetr PO jinak, než při komunikaci s dotčeným systémem.
  • Nastavení – jde o informace ovlivňující zobrazené informace na Portálu občana (např. zobrazení dlaždic, nastavení notifikací apod.). Z jejich hodnot nelze přímo vyčíst žádné informace o uživateli.
  • Dokumenty – jde o celou řadu „souborů“, které se vytvářejí v Portálu občana a nebo které si uživatel do PO nahrál. Jde například o tisknutelnou formu podání, archiv DZ apod. Tyto dokumenty se ukládají do speciální zabezpečené oblasti, která se „odemyká“ až při přihlášení uživatele. Tyto dokumenty mohou obsahovat i zvláštní kategorie osobních údajů (dříve jako citlivé údaje), ale z pohledu PO jsou „neviditelné“ (Portál občana neprovádí parsování těchto dokumentů).
  • Komunikační atributy – v současné době jde o e-mail a telefonní číslo. Komunikační atributy neopouštějí přímo perimetr Portálu občana, ale slouží pouze pro navázání komunikace Portálu občana s uživatelem, resp. zasílání notifikací. Portál občana uživatele notifikuje pouze v případě jeho žádosti ve specifických případech (nastavení).

Transientně přes Portál občana prochází mnoho uživatelských informací. Jejich šíře se nedá přesně specifikovat – záleží, s jakým AIS uživatel prostřednictví Portálu občana komunikuje. Nicméně tyto informace se neukládají (jde pouze o on-line náhledy na informace). Co se týče notifikací změn údajů v základních registrech, proces je spouštěn v definovaných časech (konfigurace Portálu občana), Portál občana zjišťuje na základních registrech změnu přihlášených AIFO. Pokud taková změna proběhla a uživatel si nastavil notifikaci, PO vytvoří zprávu (podle nastavení uživatele) a uloží ji do fronty seznamu zpráv.

Komunikace na úrovni frontend

Komunikací na úrovni frontend je míněno především sdílení společného prostoru kvalifikovaného systému elektronické identifikace (NIA). V tomto prostoru má uživatel možnost procházet přes jednotlivá portálová řešení a využívat tzv. principu „single sign-on“, tj. jednotného přihlášení sdíleného mezi všemi portály či aplikacemi. NIA se řídí ustanoveními zákona č. 250/2017 Sb., o elektronické identifikaci. V návaznosti na výše uvedené slouží tzv. statické dlaždice na Portálu občana pro přechod uživatele mezi Portálem občana a dalšími portály či aplikacemi bez potřeby další autentizace. Portál občany tedy z pohledu funkcionality statických dlaždic slouží jako rozcestník. V současné době si uživatel Portálu občana sám vybírá a aktivuje služby (v podání dlaždic) z katalogu. V dalších fázích rozvoje je uvažováno o nabízení relevantních dlaždic dle jejich obsahu a rolí, ve kterých uživatel bude vystupovat. Aktivní služby v podobě dlaždic jsou uživateli zobrazeny na dashboardu Portálu občana.

Komunikace na úrovni backend

Portál občana standardně napřímo komunikuje s jen omezeným množstvím systémů, a to centrálně sdílených služeb. Konkrétně jde o:

  • Informační systém základních registrů prostřednictvím svých vlastních nebo kompozitních služeb,
  • Informační systém datových schránek.

Pro komunikaci s ostatními systémy Portál občana výhradně využívá eGon Service Bus / Informační systém sdílené služby.

Komunikace prostřednictvím ISZR
  • Čtení ze Základních registrů (ROB, ROS):
    • přístup k údajům v základních registrech probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na přístup k Základním registrům.
  • Čtení přes kompozitní služby (AIS EO):
    • čtení přes kompozitní služby probíhá v agendové činnosti (RPP), kterou použije čtenář;
    • činnost musí mít oprávnění na čtení z AIS.
    • činnost musí mít oprávnění na čtení z ROB podle typu použité služby (ověření AIFO nebo referenčních údajů použitých pro vyhledávání).

Mezi napřímo volané služby patří např. E03 robCtiAifo (čtení referenčních údajů z registru ROB), E22 rosCtiPodleUdaju, E45 orgPrihlasAifo (zaevidování AIFO k notifikaci změn v ROB a ORG pro volající AIS), E98 iszrCtiSouborCiselniku, E106 rppVypisSeznamAgend, E153 iszrZpracujFormular, E181 robVypisSouhlasuPoskytnuti, E199 orgZjistiAis (zjištění kombinací AIFO / Agenda, ve kterých v ORG existuje AIFO odpovídající vstupnímu AIFO) nebo E226 eidentitaCtiAifo (převod bezvýznamového identifikátoru fyzické osoby na odpovídající AIFO AIS).

Komunikace prostřednictvím eGSB/ISSS

Pokud hovoříme o spolupráci přes back-end, je tím míněno napojení Portálu občana na publikační AIS a spolupracovat přes služby, které jsou vystaveny na eGSB/ISSS. Připojení publikačního AIS je z pohledu náročnosti poměrně složité a vyžaduje součinnost ze strany provozovatele eGSB/ISSS. Jeho vstupy jsou nezbytné zejména při definování kontextů (schémat datových zpráv), které jsou sice v kompetenci publikátora, ale pro zachování jednotného formátu přes všechny publikátory, je nutné schválení ze strany provozovatele eGSB/ISSS. Portál občana nekonzumuje veškerá data, která jsou publikována na eGSB/ISSS už i z toho důvodu, že ne vše je určeno pro uživatele – fyzickou osobu. Výběr toho, co a jak zobrazovat na Portálu občana, je tedy výsledkem konkrétní spolupráce gestora publikačního AIS a Portálu občana. Po shodě na rozsahu služeb postupují řešitelé Portálu občana v těchto krocích:

  1. vývoj pro čtení dat (čtenářská aplikace),
  2. oprávnění pro čtení a získání testovacích dat,
  3. testování čtení dat.

Po ověření dostupnosti eGSB/ISSS si Portál občana z katalogu služeb stáhne potřebné WSDL a XSD definice služeb a kontextů pro dostupné publikační AIS. Na základě těchto souborů unikátních pro každý publikační AIS a obecného popisu služeb eGSB/ISSS popsaných v dokumentu „Využití služeb eGSB/ISSS čtenářskými AIS“ si Portál občana vytvoří vlastní klientské rozhraní webových služeb pro čtení dat pomocí eGSB/ISSS.

Rules for the National Identity Authority

The description of the architecture of the authority and the 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 authority is described in Architecture of the authority in the context of the public administration and its layers of architecture.

A description of the centrally provided systems and their services, functional units and thematic areas within the National Identity Authority is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use of and description to access the National Identity Authority will be described by the authority in its information concept.

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á v konkrétním čase 30.3.2023

Celkem státních ID prostředků 1 518 591
Celkem nestátních ID prostředků 10 565 485
Celkem ID prostředků 12 084 076
Počet profilů alespoň s jedním aktivním prostředkem6 087 908
Celkový počet unikátních přihlášení 2 432 241
Konverze - procentuální zastoupení těch, kdo se skutečně přihlásili z těch, kdo se přihlásit mohli39.95% %
Identitní prostředek Popis počtuPočet
eObčanka (od 1.7.2018): Počet aktivovaných prostředků 669 250
Počet aktivních prostředků 553 811
Počet aktivních unikátních identit 553 778
Počet přihlášení 1 960 980
Unikátních přihlášení 62 446
NIA ID (dříve „Jméno, Heslo, SMS“) (od 1.7.2018):Počet aktivovaných prostředků 357 741
Počet aktivních prostředků 347 966
Počet aktivních unikátních identit 347 965
Počet přihlášení 8 176 219
Unikátních přihlášení 333 713
Mobilní klíč eGovernmentu (od 16.11.2020): Počet aktivovaných prostředků 506 208
Počet aktivních prostředků 468 963
Počet aktivních unikátních identit 372 402
Počet přihlášení 10 011 957
Unikátních přihlášení 381 271
Technicky IdP pro mobilni aplikace Počet aktivovaných prostředků 149 314
Počet aktivních prostředků 147 851
Počet aktivních unikátních identit 66 006
Počet přihlášení 501 624
Unikátních přihlášení 66 354
Bankovní identita Air Bank: Počet aktivovaných prostředků 1 513 739
Počet aktivních prostředků 1 274 839
Počet aktivních unikátních identit 729 574
Počet přihlášení 2 201 696
Unikátních přihlášení 214 223
Bankovní identita Banka CREDITAS - Pilot: Počet aktivovaných prostředků 56
Počet aktivních prostředků 47
Počet aktivních unikátních identit 47
Počet přihlášení 145
Unikátních přihlášení 26
Bankovní identita Česká spořitelna: Počet aktivovaných prostředků 3 096 849
Počet aktivních prostředků 2 322 191
Počet aktivních unikátních identit 2 320 468
Počet přihlášení 6 670 709
Unikátních přihlášení 634 986
Bankovní identita ČSOB Identita – plně ověřený přístup Počet aktivovaných prostředků 2 788 564
Počet aktivních prostředků 1 650 161
Počet aktivních unikátních identit 1 556 137
Počet přihlášení 4 337 035
Unikátních přihlášení 426 822
Bankovní identita ČSOB Identita – rychlý přístup Počet aktivovaných prostředků 1 716 823
Počet aktivních prostředků 1 600 447
Počet aktivních unikátních identit 1 514 433
Počet přihlášení 91 618
Unikátních přihlášení 36 979
Bankovní identita Fio banka: Počet aktivovaných prostředků 618 021
Počet aktivních prostředků 612 232
Počet aktivních unikátních identit 612 221
Počet přihlášení 393 833
Unikátních přihlášení 63 247
První certifikační autorita, karta Starcos: Počet aktivovaných prostředků 2 173
Počet aktivních prostředků 932
Počet aktivních unikátních identit 902
Počet přihlášení 170 349
Unikátních přihlášení 818
Bankovní identita Komerční banka: Počet aktivovaných prostředků 1 042 678
Počet aktivních prostředků 977 404
Počet aktivních unikátních identit 922 854
Počet přihlášení 3 681 846
Unikátních přihlášení 313 741
MojeID - úroveň "značná": Počet aktivovaných prostředků 111 848
Počet aktivních prostředků 86 851
Počet aktivních unikátních identit 72 631
Počet přihlášení 1 655 765
Unikátních přihlášení 73 290
MojeID - úroveň "vysoká": Počet aktivovaných prostředků 4 736
Počet aktivních prostředků 4 484
Počet aktivních unikátních identit 4 255
Počet přihlášení 43 335
Unikátních přihlášení 3 561
Bankovní identita MONETA Money Bank: Počet aktivovaných prostředků 1 107 892
Počet aktivních prostředků 979 848
Počet aktivních unikátních identit 650 671
Počet přihlášení 1 400 315
Unikátních přihlášení 159 679
Bankovní identita Raiffeisenbank: Počet aktivovaných prostředků 1 319 659
Počet aktivních prostředků 810 944
Počet aktivních unikátních identit 807 448
Počet přihlášení 1 201 408
Unikátních přihlášení 144 640
Bankovní identita UniCredit Bank: Počet aktivovaných prostředků 252 423
Počet aktivních prostředků 245 105
Počet aktivních unikátních identit 243 916
Počet přihlášení 40 078
Unikátních přihlášení 10 450

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

Rules for the 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.

A description of the centrally provided systems and their services, functional units and thematic areas within the National Identity Authority is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use of and description to access the Reference Interface shall be described by the authority in its information concept.

.

Rules for the Public Administration Universal Contact Point

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.

A description of the centrally provided systems and their services, functional units and thematic areas within the universal contact point is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use and description of access to the universal contact points will be described by the authority in its information concept.

Rules for the 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.

The description of centrally provided systems and their services, functional units and thematic areas within document management is described on a separate page here or within Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use and description of access to document management systems shall be described by the authority in its information concept.

.

Rules for Law and Legislation Related Systems and Services

The description of the architecture of the office and the public administration of the CR 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.

A description of the centrally provided systems and their services, functional units and thematic areas within the systems and services related to law and legislation is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description to access systems and services related to the legal order and legislation will be described by the authority in its information concept.

Rules for Electronic Acts and Service of Process

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 description of centrally provided systems and their services, functional units and thematic areas in the context of electronic actions and delivery is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use and description of access to electronic acts and delivery shall be described by the authority in its information concept.

.

Rules for the Unified Identity Space of Public Administration

The description of the architecture of the authority and the public administration of the CR by each layer 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 description of centrally provided systems and their services, functional units and thematic areas within the single identity space of public administration is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description to access the single identity space shall be described by the authority in its information concept.

Rules for 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 the architecture of the office is described in Architecture of the office in the context of the public administration and its architecture layers.

The description of centrally provided systems and their services, functional units and thematic areas within single service channels and civil servants' user interfaces is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description to access the unified service channels and AI officials will be described by the authority in its information concept.

Rules for INSPIRE Shared Services

The description of the architecture of the authority 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 authority is described in Architecture of the authority in the context of the public administration and its architecture layers.

The description of centrally provided systems and their services, functional units and thematic areas within the shared agency IS in the delegated competence is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use and description to access INSPIRE shared services shall be described by the authority in its information concept.

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é:

Rules for Shared Agency IS in Delegated Responsibilities

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 description of centrally provided systems and their services, functional units and subject areas within the shared agenda IS in the delegated competence is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use of and description for accessing shared agency IS for delegated responsibilities shall be described by the authority in its information concept.

Rules for 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.

A description of centrally provided systems and their services, functional units and subject areas within the shared agency IS for separate jurisdictions is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of the access to shared agency IS for separate competences shall be described by the authority in its information concept.

Rules for Shared Operational Information Systems

The description of the architecture of the office and the public administration of the CR 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 description of centrally provided systems and their services, functional units and thematic areas within the shared operational IS is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of access to shared operational IS shall be described by the authority in its information concept.

.

Rules for 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.

The description of centrally provided systems and their services, functional units and thematic areas within the Shared Statistical, Analytical and Reporting Systems is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use and description of access to shared statistical, analytical and reporting systems will be described by the authority in its information concept.

Popis Sdílených statistických, analytických a výkaznických systémů

Statistické, analytické a výkaznické systémy systémy (existující i plánované) budou zahrnuty po zpracování podkladů od věcných správců.

Pravidla Sdílených statistických, analytických a výkaznických systémů

NAP nestanovuje v této verzi pro tento funkční celek či tematickou oblast žádná pravidla.

eGovernment cloud rules

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 description of centrally provided systems and their services, functional units and thematic areas within the eGovernment Cloud is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration in the Czech Republic.

The use and description of access to the eGovernment Cloud will be described by the authority in its information concept.

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.

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.

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 není momentálně k dispozici z důvodu probíhajících prací na jeho aktualizaci. Děkujeme za pochopení.
{{url>https://app.powerbi.com/view?r=eyJrIjoiOTNiOGM3NzUtMzRhOC00NjUzLWI4MGYtZmZjMTY4MzQ2NjM0IiwidCI6IjFkYjQxZDZmLTFmMzctNDZkYi1iZDNlLWM0ODNhYmI4MTA1ZCIsImMiOjh9 100%,1000}}

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

National Data Centre Rules

The description of the architecture of the office and the 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 the public administration and its layers of architecture.

The description of centrally provided systems and their services, functional units and thematic areas within the national data centres is described on a separate page here or within the Description of shared services, functional units and thematic areas of the public administration of the Czech Republic.

The use of and description for access to national data centres will be described by the authority in its information concept.

.

Public Administration Communication Infrastructure Rules

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 description of centrally provided systems and their services, functional units and thematic areas within the communication infrastructure of public administration is described on a separate page here or within the Description of shared services, functional units and thematic areas of public administration of the Czech Republic.

The use of and description to access the public administration communication infrastructure shall be described by the authority in its information concept.

.

1)
Přehled prostředků s jejich úrovní záruky seznam_poskytovatelu_identity_identity_provideridp

Discussion

Enter your comment: