Certificate requests for hospitals

Presentatie over: "Certificate requests for hospitals"— Transcript van de presentatie:

1 Certificate requests for hospitals
UREG Certificate requests for hospitals NL sessie eHealth platform April 24th, 2014 Kris VAN AKEN Project Manager eHealth platform 1

2 Certificaatproces - Agenda
Basisdienst digitale certificaten : doel en eigenschappen Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heeft u nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG UMAN + aanvraag certificaat zorginstelling (ziekenhuis) Installatie, gebruik, lifecycle

3 Certificaatproces - Agenda
Basisdienst digitale certificaten : doel en eigenschappen Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heeft u nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG UMAN + aanvraag certificaat zorginstelling (ziekenhuis) Installatie, gebruik, lifecycle

4 Doel en functie basisdienst « eHealth Certificaten »
Functie van een digitaal certificaat Een certificaat is een digitaal bestand dat fungeert als een digitaal paspoort voor de eigenaar van dat bestand. Dit bestand wordt door een certificatieautoriteit (CA) uitgereikt en beheerd en certifieert het publieke deel van een sleutelpaar, waarvoor de eigenaar het private deel met een paswoord beschermt. Een certificaat dat door een certificatie authoriteit is uitgereikt is een elektronische bevestiging van identiteit en bevat informatie die gebruikt wordt om gegevens te beschermen of om een beveiligde netwerkverbinding te maken. Doel in eHealth context: Zekere identificatie en authenticatie van zorgverlener om veilige elektronische gegevensuitwisseling tussen systemen mogelijk te maken

5 Doel en functie basisdienst « eHealth Certificaten »
Functie in eHealth context Identificatie & authenticatie van actors in de Belgische gezondheidssector Voor toegang tot eHealth basisdiensten via system-to-system verbinding (en niet via webtoepassing); voor gebruik basisdiensten en DTW in de vorm van webservices Authenticatiecertificaat wordt uitgebreid met een eHealth encryptie-sleutel Software-integratoren (geen zorgverleners): Mogelijkheid om testcertificaten aan te vragen. Hiermee kunnen IT-medewerkers van software-integratoren die in de Belgische gezondheidssector actief zijn, de integratie van eHealth basisdiensten testen. eHealth Integrated User and Access Management Na authenticatie met eHealth certificaat kan UAM op basis van toegangsregels al dan niet gebruikers authoriseren tot specifieke deelprocessen en gegevens. Scheiding application access / data access Wanneer een zorgverlener toegang wenst tot bepaalde basisdiensten van het eHealth-platform door gebruik te maken van een system to system-verbinding en niet van een webtoepassing, moet hij over een eHealth-certificaat beschikken. De “systeem”partner wordt aan de hand van dit certificaat geïdentificeerd en geauthenticeerd terwijl de gebruiker (persoon) op basis van de eID of de burgertoken geïdentificeerd en geauthenticeerd wordt. Dit geldt zowel voor het gebruik van basisdiensten als voor het gebruik van diensten met toegevoegde waarde in de vorm van webservices. Voor software-integratoren (geen zorgverleners) bestaat daarnaast ook de mogelijkheid om testcertificaten aan te vragen. Hiermee kunnen IT-medewerkers van software-integratoren die in de Belgische gezondheidssector actief zijn, de integratie van onze basisdiensten testen.

6 Certificate Manager genereert tevens encryptiesleutels
De encryptiesleutels (ETK) worden op basis van het eHealth-certificaat gegenereerd. Het eHealth-certificaat wordt gebruikt telkens de webservices van het eHealth-platform worden aangeroepen. Om het certificaat te verkrijgen, stelt het eHealth-platform een interface ter beschikking.  Voor deze interface is een sterke authenticatie vereist (op basis van de eID van de aanvrager). Nadat de certificaataanvrager zijn certificaataanvraag automatisch heeft ingediend (ehcsr-bestand), ontvangt hij enkele dagen later, na validatie, het authenticatiecertificaat. Met dit eHealth-certificaat kan hij vervolgens via dezelfde interface het bijbehorende encryptiecertificaat (ETK) aanmaken, dat hij nodig zal hebben wanneer hij de basisdienst voor end-to-end vercijfering zal gebruiken.

7 Agenda Basisdienst Digitale certificaten : doel en eigenschappen
Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heb ik nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG UMAN + aanvraag certificaat zorginstelling (ziekenhuis) Installatie, gebruik, lifecycle

8 Criteria voor het verkrijgen van eHealth-certificaten
Elke zorgverlener kan als entiteit de eHealth-certificaten gebruiken die voor de zorgverleners worden uitgereikt. Het eHealth-authenticatiecertificaat certificeert de identiteit van hetzij natuurlijke personen, gekend in de authentieke bron “Kadaster van gezondheidsberoepen”, hetzij instellingen die actief zijn in de Belgische gezondheidssector. Het is de taak van de verantwoordelijke van de instelling om een certificaat aan te vragen. Deze persoon moet geregistreerd zijn in de statuten als wettelijk vertegenwoordiger van de organisatie.

9 Type certificaataanvragen eHealth Portal
Het eHealth-platform geeft voornamelijk twee soorten certificaten uit: De eHealth-certificaten waarbij wordt bevestigd dat een bepaalde partner een actor in de gezondheidszorg is. De eHealth-acceptatiecertificaten op basis waarvan een partner die informaticadiensten voor de sector van de gezondheidszorg levert (softwarehuizen die oplossingen voor de sector ontwikkelen) zijn oplossingen kan uittesten.  Op basis van deze tweede soort certificaten kunnen oplossingen worden ontwikkeld en in acceptatie worden genomen, maar het is niet mogelijk om toegang te krijgen tot de productieomgeving. Beide certificaattypes volgen de wereldwijde standaard voor PKI voor single sign-on Volgorde van de attributen (inhoud) wordt niet gegarandeerd (bepaald door de CA)

10 Agenda Basisdienst Digitale certificaten : doel en eigenschappen
Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heb ik nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG UMAN + aanvraag certificaat zorginstelling (ziekenhuis) Installatie, gebruik, lifecycle

11 Startpunt certificaataanvraag: eHealth Portal
Het eHealth-platform geeft voornamelijk twee soorten certificaten uit: De eHealth-certificaten waarbij wordt bevestigd dat een bepaalde partner een actor in de gezondheidszorg is. De eHealth-acceptatiecertificaten op basis waarvan een partner die informaticadiensten voor de sector van de gezondheidszorg levert (softwarehuizen die oplossingen voor de sector ontwikkelen) zijn oplossingen kan uittesten.  Op basis van deze tweede soort certificaten kunnen oplossingen worden ontwikkeld en in acceptatie worden genomen, maar het is niet mogelijk om toegang te krijgen tot de productieomgeving.

12 eHealth Portal : downloadsectie docu

13 Acceptatie - Stap 1

14 Acceptatie - Stap 1

15 Acceptatie - Stap 1 : testgeval registreren
Link tussen zorginstelling NIHII ( RIZIV, INAMI ) en certificaatverantwoordelijke SSIN ( INSZ, NISS ) Testgeval ziekenhuis

16 Acceptatie - Stap 2: Procuratie bevestiging

17 Procuratieformulier + testgeval aan eHealth

18 Procuratieformulier + testgeval aan eHealth bezorgen
UREG : Registratie van de testgevallen wordt in globo voor alle deelnemende ziekenhuizen voorbereid. Zodra registratie gebeurd is ontvangt u bevestiging en kunt u overgaan tot de certificaataanvraag zelf (stap 3)  Validatie eHealth

19 Acceptatie - Stap 3: Certificate Manager (ACC)

20 Acceptatie - Stap 3: Certificate Manager (ACC)

21 Aanvraagproces in een notendop
De aanvraagprocedure voor een eHealth-certificaat bestaat grosso modo uit 3 fases: In de eerste fase dient u de aanvraag in d.m.v. een applicatie beschikbaar op het eHealth portaal. Validatie van de aanvraag. Het eHealth-platform controleert of u wel degelijk bent wie u beweert te zijn. Automatisch indien testgeval geregistreerd is. Anders manueel (deze fase kan enkele dagen duren). Het eHealth-platform verwittigt u per over de goedkeuring van uw aanvraag. Nadat u de bevestiging ( ) heeft ontvangen, gebruikt u de applicatie om de aanvraag te vervolledigen Aanvraag eHealth certificaat 2. notificatie authenticatiecertificaat voorhanden 3. Vervollediging aanvraag eHealth certificaat 21 21

22 Wat heeft u nodig ? Om de aanvraag te kunnen doen, moet uw PC beschikken over Een eID lezer De nodige middleware om eID te kunnen gebruiken Een recente versie van Java U moet ook volgende zaken bij de hand houden Uw identiteitskaart en de bijhorende PIN code Het RIZIV nummer of het KBO nummer (i.e. ondernemingsnummer) dat overeenkomt met uw instelling, praktijk of apotheek. Indien u een probleem met de certificaat aanvraag ondervindt, gelieve het eHealth contactcenter te contacteren. De link naar dit contactcenter vindt u tevens in de certificaat aanvraag toepassing Telefonisch via of via het online formulier

23 Handleiding eHealth Certificate Manager
Toepassing loodst u door de stappen om de certificaataanvraag in te dienen. Handleiding online

24 Java webstart : lokale sleutelgeneratie
Dit proces wordt uitgevoerd met behulp van de eHealth Requestor utility. Dit is een Java webstart applicatie die Java versie 1.6 of hoger vereist. Het is vereist dat deze software lokaal draait omwille van de lokale sleutel generatie, belangrijk voor het waarborgen van de veiligheid van uw private sleutels. Dit soort van lokaal uitgevoerde proces is van belang omdat het de enige manier is dat eHealth kan garanderen dat uw private authenticatiesleutel veilig is en niet gecompromitteerd. U moet de private sleutel op uw lokale systeem genereren en moet u de private sleutel ten alle tijden veilig houden. Daarom is het belangrijk dat uw eigen systemen correct beveiligd zijn en als voldoende beschermd beschouwd kunnen worden voor het opslaan van persoonlijke sleutels voordat u start met dit proces.

25 Agenda Basisdienst Digitale certificaten : doel en eigenschappen
Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heb ik nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG Bevoegdheidsprincipe Acceptatie resp. Productie Productie : UMAN + aanvraag certificaat zorginstelling (ziekenhuis) Installatie, gebruik, lifecycle

26 Certificaat namens ziekenhuis
Proces dat een ziekenhuis moet doorlopen om een productiecertificaat te bekomen Wie uit het ziekenhuis kan een eHealth certificaat aanvragen Acceptatie resp. Productie

27 Wie kan namens ziekenhuis certificaat aanvragen Productieomgeving
Bestuurder (juridische bevoegdheid namens ziekenhuis) Mag het ziekenhuis rechtsgeldig vertegenwoordigen Kan een volmacht namens het ziekenhuis verlenen. Nodige stavingsstukken (statuten, beslissing raad van bestuur, ...) bijbrengen, die afdoende bevestigen dat de betrokkene rechtsgeldig een volmacht kan verlenen namens de instelling in kwestie. Gevolmachtigde Via een volmachtformulier (bestuurder aan gevolmachtigde) Te downloaden via eHealth portaal (support basisdienstentoegangsbeheercertificaten downloadsectie) Voorbeeld : De verwijzing naar op het internet gepubliceerde informatieve teksten mbt de functie van de betrokkene, is onvoldoende. Ook voor het UZLeuven dienen de nodige stavingsstukken te worden bijgebracht (zijnde de statuten, beslissing raad van bestuur, ...) die afdoende bevestigen dat de betrokkene rechtsgeldig een volmacht kan verlenen namens de instelling in kwestie. Overeenkomstig de statuten zoals ze werden overgemaakt, geldt het volgende: art. 32: De raad van bestuur is belast met het bestuur van de vereniging en is bevoegd om alle zaken te behandelen en beslissingen te nemen die door onderhavige statuten niet voorbehouden werden aan de algemene vergadering. De raad van bestuur heeft bijgevolg alle residuaire bevoegdheden. De raad van bestuur kan bepaalde bevoegdheden delegeren aan het dagelijks bestuur, volgens de modaliteiten bepaald in het huishoudelijk reglement, en mits voldaan wordt aan de wettelijke beschikkingen terzake, onder meer aan artikel 125 van de organieke wet betreffende Openbare Centra voor maatschappelijk welzijn. art. 39: De algemeen directeur is belast met het secreteriaat van de organen van de vereniging en met de uitvoering van hun beslissingen. Hij handelt overeenkomstig de bepalingen van de gecoördineerde wet op de ziekenhuizen. Het voorgaande is mijns inziens op zich onvoldoende om te besluiten of de algemeen directeur bevoegd is om het ziekenhuis rechtsgeldig te vertegenwoordigen om een volmacht namens het ziekenhuis te kunnen verlenen. Aan het ziekenhuis wordt gevraagd om de beslissing van de raad van bestuur bij te brengen waaruit blijkt dat de algemeen directeur effectief over dergelijke bevoegdheden beschikt. (Gelet op de zeer beperkte beschrijving van de bevoegdheden in de statuten, kan het niet anders dat in het verleden reeds op algemene wijze bepaalde bevoegdheden door de raad van bestuur aan de algemeen directeur werden gedelegeerd.)

28 Productieomgeving Online registratie via UMan
Registratie als certificate manager via eHealth User Management (UMAN) eHealth portal  Zorgverlener  Hoe krijgt u toegang tot eHP  Toegang krijgen Kies type instelling : Ziekenhuis : RSZ of RSZ/PPO VTE : Verantwoordelijke Toegang Entiteit Rechtskundige bevoegdheid via statuten van de zorginstelling (entiteit) VTE duidt lokale beheerder (LB) aan  LB2  LB3 LB krijgt automatisch de rol “Certificate Manager” in UMan Deze gevolmachtigde (lokale beheerder) namens het ziekenhuis zal nu bij de certificaataanvraag herkend worden al ‘certificaatbeheerder’ Opstarten eHealth Certificate Manager via eHealth portal Support  basisdiensten  Toegangsbeheer  eHealth certificaten Start “eHealth Certificate Manager” (Zorgverlener = productie-certificaat) Gebruik NIHII-HOSPITAL als identifiertype voor de zorginstelling

29 Productieomgeving ziekenhuizen - Stap 1
UMan namens ziekenhuis: registratie “certificaatbeheerder” (certificate manager) in UMan Reeds groot aantal ziekenhuizen hebben VTE in kader van eerste eHealth toepassing in UMan geregistreerd Het eHealth contactcenter kan u bevestigen of verantwoordelijke toegang entiteit (VTE) voor ziekenhuis in UMan gekend is Contactcenter : Vermeld naam + RIZIV nummer van het ziekenhuis

30 Productie Stap 2 : eHealth Certificate Manager

31 Samengevat: Certificaat namens ziekenhuis
ACCEPTATIE Registratie testcase 3 stappen PRODUCTIE Registratie VTE in UMan VTE  Lokale Beheerder voor de toepassing eHealth platform Certificate Manager Lokale beheerder lanceert aanvraag(toepassing)

32 Agenda Basisdienst Digitale certificaten : doel en eigenschappen
Functie van een digitaal certificaat Functie in eHealth context Type eHealth certificaten Criteria voor aanvraag van eHealth certificaat Onderscheid naar gebruik en omgeving (toepassing) Hoe verloopt het aanvraagproces Wat heb ik nodig om de certificaataanvraag te maken Online toepassing voor eHealth certifcaat aanvraag Concreet voor ziekenhuizen UREG UMAN + aanvraag certificaat zorginstelling ziekenhuis Installatie, gebruik, lifecycle

33 Lifecycle van een certificaat
Installatie Geen manipulaties met bestanden door gebruiker meer nodig (opzoeking bestand op PC, bestand per versturen, certificaatbestanden ontvangen per en deze opslaan op harde schijf) Certificaat wordt in achtergrond op PC geïnstalleerd Veiligheidsvoorschriften (supportpagina eHealth portaal) Levensduur Geldigheidsperiode: nominaal 1 jaar ACCEPTATIE 3 jaar PRODUCTIE + 3 maand renewalperiode Periode waarin vernieuwing toegelaten is: 3 maanden vóór vervaldatum Automatische herinneringen vanaf 3 maanden vóór vervaldatum Verantwoordelijkheid van de certificaathouder om certificaat te vernieuwen Vernieuwingsaanvraag  er wordt geen verlenging gedaan Belangrijk bij vernieuwing: Achterwaartse compatibiliteit voor encryptie wordt niet gewaarborgd. Doordat encryptie voor “data in transit” is, wordt bij de implementatie van hernieuwing van certificaten en ETK’s een nieuw certificaat en ETK geleverd zonder garantie dat oude berichten met een nieuwe ETK kunnen ontcijferd worden. When a Health Care actor is forced to perform any manipulations such as searching a file on his file system, sending a mail with an attachment, receiving files by mail and store them on his hard disk Lorsqu'un nouvel ETK est créé et activé, les nouveaux messages seront cryptés pour ce nouvel ETK, et donc déchiffrables avec la clé privée de ce nouvel ETK. Les anciens messages seront toujours décryptables à l'aide de la clé privée de l'ancien ETK, que l'utilisateur doit conserver. A lui simplement de sélectionner le bon p12 (keystore)

34 Ondersteuning eHealth portal (sectie support) eHealth contactcenter
Handleiding eHealth Certificate Manager UMAN eHealth contactcenter Tel. contactcenter : Maandag tot vrijdag van 07:00 tot 20:00 vb.: Status certificaat-aanvraag