Vastus pöördumisele

Estonian EESSI architecture Document history Version Date Author Comments 0.1 07.03.2017 Artur Novek First version 0.2 28.04.2017 Artur Novek Component view completed, needs components description, started deployment view and references to other documents 0.3 02.05.2017 Artur Novek Deployment view in testing and production environment 0.4 08.05.2017 Artur Novek Environments according to (unconfirmed) EC EESSI Deployment plan document 0.5 21.08.2017 Artur Novek Added Interfaces list, integration scenario selection, national routing option selection. Minor changes in other parts. 0.6 22.08.2017 Artur Novek Added EESSI National integration chapter based on required decisions in EESSI National Integration Guide. 0.9 04.10.2017 Artur Novek Added interfaces and features chapter, availability requirements chapter, created list of references, unified way of referring 1.0 25.10.2017 Artur Novek Incorporated feedback from review Contents Document history .................................................................................................................................... 1 Definitions and Abbreviations ................................................................................................................. 2 Introduction............................................................................................................................................. 2 System’s background............................................................................................................................... 3 EESSI National integration ....................................................................................................................... 3 Number of AP-s ................................................................................................................................... 3 AP Capacity .......................................................................................................................................... 3 AP Availability ...................................................................................................................................... 3 Virtualization ....................................................................................................................................... 4 International Data Model adoption .................................................................................................... 4 Routing strategy .................................................................................................................................. 4 Option 1: Basic Routing ................................................................................................................... 4 Option 2: LB/CI as a Proxy ............................................................................................................... 4  National applications integration ........................................................................................................ 5 Component view ..................................................................................................................................... 6 National secure communication platform X-road............................................................................... 7 Deployment view .................................................................................................................................... 8 General information about EESSI components deployment options and environments ................... 8 AP Capacity Types............................................................................................................................ 9 RINA High Performance – High Availability ................................................................................... 10 Deployment in Health Insurance Fund .............................................................................................. 11 Deployment in Unemployment Insurance Fund ............................................................................... 11 Deployment in TEHIK......................................................................................................................... 11 TEST environment in TEHIK ........................................................................................................... 11 ACCEPTANCE and PRODUCTION environments in TEHIK .............................................................. 12 Interfaces and features ......................................................................................................................... 14 AP interfaces...................................................................................................................................... 15 RINA interfaces .................................................................................................................................. 15 Common EESSI interfaces (used in AP and RINA) ............................................................................. 16 X-road interface................................................................................................................................. 16 References ............................................................................................................................................. 16 Definitions and Abbreviations EESSI Electronic Exchange of Social Security Information EU European Union EC European Commission MS Member State IR Institution Repository CSN Central Services Node AP Access Point NA National Application RINA Reference Implementation of National Application X-road X-road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. BUC EESSI Business Use Case Introduction Document describes Estonian national part of EESSI architecture. International EESSI architecture is described in EESSI Architecture Overview Document [1]. The following diagram depicts the overall system architecture: Figure 1 EESSI System Diagram System’s background EESSI is an IT system that will help social security bodies across the EU exchange information more rapidly and securely – as required by EU regulations on social security coordination. EC has created architecture for EESSI and according to architecture developed components for central parts and national bodies to make easier adoption of EESSI. For Access Point organizations, EC developed AP software based on Microsoft Biztalk and MS SQL Server [2] and for social security bodies EC developed java freeware components based RINA [3], which can act as National Application (NA) or as simpler interface for NA. EESSI National integration EC has created document EESSI – National Application Integration Guide [4], which helps Member States with EESSI national implementation. Guide introduces various decisions Member State has to make for EESSI implementation. In following chapters are described decisions made by Estonia. Number of AP-s Estonia has Single AP hosted by Health and Welfare Information Systems Centre (TEHIK) in all environments required from Member States. AP Capacity Estonia has in TESTING environment Low Capacity AP as recommended. Estonia has In ACCEPTANCE and PRODUCTION environment Regular Capacity AP. Calculation is given in chapter AP in PRODUCTION environment. AP Availability Estonia has in TESTING environment Low Availability AP as recommended. Estonia has In ACCEPTANCE and PRODUCTION environment High Availability AP. Virtualization Estonia uses virtualization in all environments for all AP and RINA components as recommended. International Data Model adoption Estonia will have full adoption of the International Data Model, as institutions will start with use of the RINA full stack. National Applications integrate gradually with EESSI through RINA’s CPI and NIE interfaces. Before the integration starts, National Data Model and workflow implemented in National Application is harmonised with International Data Model and workflow. Routing strategy Routing strategy is described in National Integration Guide. Routing options are defined in EC created document EESSI - Routing Options [5]. Estonian uses „Option 1: Basic Routing“, when more than on institution can handle the BUC, then „Option 2: LB/CI as a Proxy“. Option 1: Basic Routing The Basic Routing strategy principle is that the messages are delivered to the single endpoint for the addressed destination institution. The Basic Routing Scenario relies upon the fact that the MS can accurately describe each institutions competence in the Institution Repository (IR). Option 1 Basic Routing strategy principle is planned to use for use cases in sectors Legislation Applicable, Family Benefits, Pensions, Sickness and Unemployment. Option 2: LB/CI as a Proxy The ‘LB/CI as a Proxy strategy’ principle is that the messages are delivered to a single endpoint for a single addressed destination institution. This institution acts as a business proxy for other institutions (who remain hidden to other MS), and assumes responsibility for sending and receiving messages with the ‘hidden’ institution. From the International perspective, the case is handled entirely with the Case Owner and the Proxy LB/CI. Estonia is considering to use ‘LB/CI as a Proxy strategy’ principle in Miscellaneous, Horizontal and Recovery sector use cases having Social Insurance Board as proxy institution. Social Insurance Board needs to change their workflows and contracts with other institutions to follow this option. Preferred way would be to inform sender in other member state, that case is given over to other institution and this institution will continue handling the case. This option is not provided in EESSI routing options – all other options are based on automatic intelligent routing instead of clerks processing the content and forwarding the case to the right institution informing the sender in other member state of forwarding. National applications integration Estonia will start with use of the RINA full stack. National Applications integrate gradually with EESSI through RINA’s CPI and NIE interfaces. Component view Estonian organizations, their clerks and information systems participating in EESSI data exchange. cmp Estonian EESSI architecture EHK (Health Insurance Fund) TK (Unemployment Insurance Fund) SKA (Social Insurance Board) MTA (Tax and Customs Board) EHK clerk TK clerk SKA clerk MTA clerk EHK clerk: Web brow ser TK clerk: Web SKA clerk: Web MTA clerk: Web brow ser brow ser brow ser Health Insurance IS EHK RINA TK RINA SKAIS X-Road EE RINA w eb: Public internet TEHIK (Health and Welfare Information Systems Center) TEHIK EESSI AP domain TEHIK RINA domain EESSI AP Shared RINA TEHIK system services (National Access Services - NAS) Repository Identity and Antimalw are Archiv ing Message Audit Trail and Versioned Access solution monitoring Reporting media Management repository Testa NG EESSI Backbone Netw ork Repository sharing: Public internet Other Countries Central services EESSI AP CSN EESSI repositry and codebase Figure 2 Component diagram - Estonian EESSI architecture Maksu- ja Tolliamet - MTA (Tax and Customs Board) will use shared RINA deployed in TEHIK as there is very few cases per year. MTA doesn’t want to integrate EESSI BUC’s functionalities into their information systems’. Eesti Haigekassa – EHK (Health Insurance Fund) EHK RINA Health Insurance Fund will deploy separate RINA and use RINA’s user interface for EESSI BUC’s functionalities. Health Insurance IS Health Insurance Fund will gradually develop EESSI BUC’s support in Health Insurance IS and use RINA interfaces for EESSI connectivity. Töötukassa - TK (Unemployment Insurance Fund) TK RINA Unemployment Insurance Fund will deploy separate RINA and use RINA’s user interface for EESSI BUC-s. Sotsiaalkindlustusamet (SKA) (Social Insurance Board) will use shared RINA deployed in TEHIK. SKAIS Social Insurance Board will gradually develop EESSI BUC’s support in their information system SKAIS and use RINA interfaces for EESSI connectivity. Tervise ja Heaolu Infosüsteemide Keskus - Health and Welfare Information Systems Centre (TEHIK) EESSI AP TEHIK hosts national EESSI Access Point Shared RINA TEHIK hosts shared multitenant RINA used by MTA and SKA. System services TEHIK has already AP and RINA needed services like Identity and Access Management, Antimalware solution, etc. TEHIK will adjust them according to EESSI needs. Central services CSN EESSI Central Services Node EESSI repository and EESSI repository and codebase for new releases of EESSI software codebase Other countries EESSI AP EESSI Access Points in other EESSI participating countries National secure communication platform X-road [6] X-Road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. X-Road employs a versatile security solution: authentication, multilevel authorization, a high-level log processing system, encrypted and time-stamped data traffic. National legislation requires X-road communication between national information systems. EESSI communication in national network needs to be secured in two cases - RINA to AP and National Application to shared RINA communication.  cmp Secure communication needed TEHIK Social security body with RINA installation Access point Messaging interface Technical Messaging Interface (TMI) TMI is based on EESSI AP AS4 protocol RINA Technical Messaging RINA Interface Social security body connected to HWISC RINA (TMI) Shared RINA Case Processing Case Processing National Interface (CPI) Interface (CPI) Application CPI and NIE are based on REST/JSON National Information National Information Exchange Interface Exchange Interface (NIE) (NIE) Public internet Figure 3 Component diagram - secure communication needs X-road Protocol is SOAP based, not AS4 messaging profile as RINA to AP or REST/JSON as National Application to RINA communication. Estonia needs protocol adapters to send EESSI messages through X-road. cmp X-Road usage TEHIK Social security body with RINA installation Access point X-Road X-Road X-Road RINA National Security adapter Application X-Road AP Serv er (AS4) EESSI AP adapter (AS4) X-Road Social security body connected to shared RINA Security Serv er RINA Shared X-Road X-Road Security X-Road adapter National RINA adapter Serv er (REST/JSON) Application (REST/JSON) Figure 4 Component diagram - X-road adapters As a relaxation until the X-road adapters are ready, other secure communication mechanisms may be used - like VPN or client and server certificates based https. Deployment view General information about EESSI components deployment options and environments As proposed in European Commission’s document EESSI Deployment Plan for PRR International Domain [6] there will be three environments for EESSI components deployment:  TEST – this environment will be used to perform testing of the new versions (releases) of the EESSI Software, prior to moving to Acceptance and Production. No production data will be used in the TEST environment!  ACCEPTANCE – this environment will be used to perform the acceptance of the EESSI Software, before moving to Production. The ACCEPTANCE environment should have a similar configuration with PRODUCTION environment (same  technologies and setup), recommended HW/SW specifications, including High Availability. No production data will be used in the ACCEPTANCE environment!  PRODUCTION – this environment is used for production. Figure 5 Deployment Environments connected to TESTA The ACCEPTANCE and PRODUCTION environments should be similar (identical if possible) and should have a High Availability configuration. The TEST environment can use the single server configuration (no High Availability). AP high availability and capacity types referred in this document are defined in European Commission’s document EESSI Performance and High Availability Specification [2]. RINA high availability and performance configuration follows clustering options from European Commission’s document EESSI RINA Multi Tenancy, High Availability and High Performance - Specifications Document [3]. AP Capacity Types The following capacity types have been defined as a result of a survey answered by Member States in the Pilot Build 1 timeframe:   Very High Capacity AP is set to process 2500 cases a day.  High Capacity AP is set to process 1200 cases a day.  Regular Capacity AP is set to process 600 cases a day  Low Capacity AP is set to process 100 cases a day. Capacity Type No of BizTalk No of CPU cores for No of SQL Servers BizTalk Servers Servers Very High Capacity 2-6 8 2 High Capacity 2-4 6 2 Regular Capacity 2-3 4 2 Low Capacity 2 2 2 Low Capacity (No HA) 1 2 1 RINA High Performance – High Availability High availability and performance is achieved by configuring various components as clusters together with a specialized component named Load Balancer. Following components can be set up in cluster mode:  REST Node  BonitaBPM  HolodeckB2B  PostgreSQL  ElasticSearch There are two types of clustering:  Active-Active – cluster nodes are all active and spread the workload via a load balancer;  Active - Passive – the primary cluster node is active and the rest of the nodes are passive in standby, and in case of failure the primary node is replaced by one of the standby nodes; Figure 6 RINA clustering Deployment in Health Insurance Fund Health Insurance Fund will use EHK RINA in all environments in single node configuration. The High Availability of EHK RINA cannot be guaranteed and for receiving messages from AP, the EHK RINA will use pull configuration of AP Messaging Interface. Deployment in Unemployment Insurance Fund Unemployment Insurance Fund will use TK RINA in all environments in single node configuration. The High Availability of TK RINA cannot be guaranteed and for receiving messages from AP, the TK RINA will use pull configuration of AP Messaging Interface. Deployment in TEHIK TEHIK will use virtualized hardware for components’ deployment. TEST environment is for all components in single node configuration. ACCEPTANCE and PRODUCTION environments are in High Availability configuration, shared RINA will use pull configuration of AP Messaging Interface. TEST environment in TEHIK In TEST environment, the firewall is not used between different application layers. AP TEST environment For testing environment, we have chosen Low Capacity AP configuration. Low Capacity AP is set to process up to 100 cases a day. It does not include High Availability features. Figure 7 AP low capacity, no high availability It is the easiest configuration. The performance and availability is suitable for testing purpose. RINA TEST environment For RINA TEST environment, we have chosen single node configuration for shared RINA deployment, as there is no need for high availability or high performance during the testing of EESSI solution. Deployment view of TEST environment in TEHIK deployment TEST env ironment AP X-Road SQL Serv er X-Road Security Serv er SQL serv er X-Road Security Serv er Shared RINA Shared RINA Biztalk serv er X-Road adapter Biztalk serv er X-Road adapter Shared RINA Common services Activ e directory Antimalw are serv er Monitoring Activ e directory Antimalw are Zabbix solution Figure 8 Deployment view of TEST environment in TEHIK ACCEPTANCE and PRODUCTION environments in TEHIK As proposed by commission Estonia will create ACCEPTANCE and PRODUCTION environments as similar as possible. Only difference, in ACCEPTANCE environment we do not use real personal data and ACCEPTANCE environment may have lower availability requirements. Other requirements for ACCEPTANCE are the same as for PRODUCTION environment. In PRODUCTION environment, TEHIK uses firewall between application layers and load balancer device for clusters. There is standby failover site for disaster recovery. AP in PRODUCTION environment For calculation of PRODUCTION environment AP capacity, we have statistical data of year 2015. Cases count is - Pensions: 10 000 Applicable Legislation: 25 000 Family Benefits: 10 000 Sickness: 30 000 Unemployment: 5 000 Horizontal - Unknown Miscellaneous - Unknown Administrative – each case (message) creates one administrative message. We have to multiply case count by 2. In Total 80 000 cases per year, with administrative messages in total 160 000. The main processing happens on workdays. A year has 52 weeks and 5 workdays per week. 160 000 / (52 * 5) = 615 messages per day. To process this workload we have chosen to use Regular Capacity AP configuration. Regular Capacity AP is set to process up to 600 cases a day. It includes between 2 and 3 application servers in NLB and 2 SQL Servers in failover clustering. Figure 9 Low Capacity, with clustering and NLB RINA in PRODUCTION environment For PRODUCTION environment, we use following clustering of RINA components.  REST Node – Active–Active cluster  BonitaBPM – Active–Passive cluster  HolodeckB2B – Active-Active cluster   PostgreSQL – reuse existing Active-Passive cluster  ElasticSearch – Active-Active cluster without LB Deployment view of PRODUCTION environment deployment PRODUCTION env ironment Shared RINA X-Road AP RINA portal DMZ LB cluster X-road security server LB cluster AP application server LB cluster REST Node 1 REST Node 2 X-Road Security X-Road Security Biztalk Node 1 Biztalk Node 2 Node 1 Node 2 Bonita BPM failover cluster X-Road Security SQL Server failover cluster Node 3 Bonita BPM Bonita BPM SQL Activ e SQL Passiv e Activ e Node Passiv e Node Node Node X-road adapter server LB cluster Holodeck B2B LB cluster X-Road Adapter X-Road Adapter Node 1 Node 2 Common services Holodeck B2B Holodeck B2B DNS and Active Directory cluster Node 1 Node 2 DNS and AD DNS and AD Common devices Node 1 Node 2 «device» ElasticSearch cluster Firew all ElasticSearch ElasticSearch «device» PostgreSQL failover cluster Node1 Node2 Load balancer PostgreSQL PostgrSQL «device» Activ e Node Passiv e Node NAS Antimalw are Monitoring solution Figure 10 Deployment view of PRODUCTION environment in TEHIK Interfaces and features The interfaces and architecturally important features available in EESSI solution are defined in EESSI Architecture Overview Document [1], which has references to detailed documentation of every interface or feature. In current document, we name all EESSI interfaces and features and describe Estonian specific usage or configuration if there is any. We provide also reference to National X-Road protocol. AP interfaces AP Messaging Interface – In Estonia only RINA-s will be connected TO AP Messaging interface. For receiving RINA-s will use the pull mechanism. Communication between AP and RINA will be secured over X-Road and is described in current document’s chapter National secure communication platform X-road. EESSI AP Intelligent Routing – Estonian routing strategy decisions are described in current document’s chapter Routing strategy. Messaging Interface (used for Repository Synchronisation) – RINAs will use the pull mechanism. EESSI Message Monitoring Interface – no Estonian specifics. EESSI Audit Trail & Reporting Interface – no special National System for audit and reporting is planned. Estonia will use provided AP Message monitoring Repository AP User Audit Repository. Default nightly removal of logs has to be changed in AP configuration. AP Message Archiving Interface – AP Message archiving interface provides ability to store full messages to secure network FILE share and configure rules on specific messages for archiving. RINA interfaces RINA Business Messaging Interface (BMI) - National Applications should not use BMI. Preferred way to interact with RINA is CPI and NIE. RINA Technical Messaging Interface (TMI) – will be configured in pull mode to receive messages from AP. National Applications should not use TMI. Preferred way to interact with RINA is CPI and NIE. RINA Case Processing Interface (CPI) – National Applications should use CPI and NIE to interact with RINA. CPI should be used, when the process triggers outside of RINA in NA, for example in SKAIS. CPI supports functions like:  Search Management - to find cases based on sets of different parameters;  Case Management - covers all aspects of case management, including creation of case, creation of document, participant list, sending documents, running business process specific actions, listing cases, documents or actions and configuration of case manager.  Notification Management - provides case specific notifications. The notifications’ events have associated a type that could be error, warning or information.  A lot of other functions like alarms management, keystores management etc. RINA National Information Exchange Interface (NIE) – National Applications should use CPI and NIE to interact with RINA. NIE should be used, when process triggers in RINA. The RINA NIE is in charge to call the National Application for all the important events from the case or document lifecycle and provide the relevant information (for example the actual SED part of a document), but it is the Member State responsibility to implement the processing (for example store the SED along with other national useful information or give back an updated SED filled in with information that would be otherwise hard or cumbersome for a clerk to fill in manually). The main use cases of NIE interface are:  Configure Service;   Load from National Application;  Store to National Application. RINA National Identity and Access Management (IAM) Interface – LDAP - This interface provides a RESTful web service that allows the RINA portal or national systems to interact with the Identity and Access Management service that is one component part of the Case Management Services. The RINA National Identity and Access Management Integration Interface exposes a collection of services that enables the system to securely control access to RINA resources for internal or external users. It comprises four basic functions:  Configure IAM;  Authenticate User;  Synchronise RINA default repository with external repository;  Configure rules for process assignment. RINA offers an LDAP integration as a reference external identity provider implementation. Estonia will use LDAP integration. Common EESSI interfaces (used in AP and RINA) EESSI Antimalware Interface - The role of the antimalware interface within EESSI system consists to ensure that all SED and attachment(s) within EESSI messages are scanned by an antimalware at the Access Point (AP) and National Application (NA) in line with requirements and taking into account that antimalware tools will be fully provided, maintained and managed by the Member States. Solution is based on scanning folder where the messages will be available for the antimalware scans.  AP scan and route a message (mandatory)  NA scan and send a message (mandatory)  NA scan and receive a message (optional) In TEHIK deployment the same antimalware solution will be used for AP and shared RINA. EHK and TK will be responsible for integrating their antimalware solution with their RINA. X-road interface X-road’s latest version V6 message protocol 4.0 [7] is based on SOAP 1.1 format. The most effective way to transport EESSI AS4 or REST/JSON messages would be to use attachments allowed in X-Road message protocol. Attachments will not be stored in X-Road message logs. References [1] G. Onofrei, “EESSI Architecture Overview Document,” 31 03 2016. [Online]. Available: https://webgate.ec.europa.eu/CITnet/confluence/download/attachments/533890430/EESSI%20 - %20Architecture%20Overview%20Document%20v1.0.0.docx?version=1&modificationDate=145 9458796196&api=v2. [2] A. Stoian and T. Vanhoutte, “EESSI Performance and High Availability Specification,” 31 03 2016. [Online]. Available: https://webgate.ec.europa.eu/CITnet/confluence/download/attachments/533890430/EESSI%20 -%20AP%20Performance%20and%20High%20Availability%20Specification%20- %20v1.0.0.doc?version=1&modificationDate=1459453968681&api=v2. [3] B. D. Alexandru STANCIU, “EESSI RINA Multi Tenancy, High Availability and High Performance - Specifications Document,” 26 08 2016. [Online]. Available: https://webgate.ec.europa.eu/CITnet/confluence/download/attachments/533890430/EESSI%20 -%20RINA%20Multi%20Tenancy%20High%20Availability%20and%20High%20Performance%20- %20v1.0.1.docx?version=1&modificationDate=1474910531328&api=v2. [4] B. Musat, “EESSI – National Application Integration Guide,” 17 11 2016. [Online]. Available: https://wiki.sm.ee/download/attachments/8947940/EESSI%20- %20National%20Integration%20Guide%20v.06.docx?api=v2. [5] P. Cummings, “EESSI Routing Options,” 01 06 2016. [Online]. Available: https://webgate.ec.europa.eu/CITnet/confluence/download/attachments/533890430/EESSI%20 -%20Routing%20Options%20v1.0.1.doc?version=1&modificationDate=1465232038620&api=v2. [6] Information System Authority, “Data Exchange Layer X-Road,” 21 02 2017. [Online]. Available: https://www.ria.ee/en/x-road.html. [Accessed 25 10 2017]. [7] A. Stoian, R. Miguel, G. Costache, G. Onofrei, C. S. Dan Cimpean and A. Maaloul, “EESSI Deployment Plan for PRR International Domain,” 12 06 2017. [Online]. Available: https://webgate.ec.europa.eu/CITnet/confluence/display/EESSI/EESSI+PRR+Deployment+and+O perations+Documentation?preview=/670959998/676039822/17- 143enREV_Deployment%20Plan%20for%20PRR_v4.0.11_Annex%201_REV.pdf. [8] S. Annuk, I. Nõgisto, I. Kromonov, M. Freudenthal and K. Heero, “X-Road: Message Protocol v4.0,” 20 02 2017. [Online]. Available: http://x-road.eu/docs/6.9.5/pr-mess_x- road_message_protocol.html.