Toevoeging van SSL certificaten voor *.ehealth.fgov.be
Deze communicatie is bestemd voor alle gebruikers van een eHealth-dienst in het domein « *.ehealth.fgov.be »
Welke acties worden er van u verwacht?
Voor alle applicaties die een connectie tot stand brengen met één of meerdere eHealth-diensten waarbij gebruik wordt gemaakt van de certificaatketen om de SSL-connectie te valideren, volstaat het dat u dit valideert (via de root of intermediaire CA).
Voor alle applicaties die een connectie tot stand brengen met één of meerdere eHealth-diensten waarbij gebruik wordt gemaakt van het finale certificaat om de SSL-connectie te valideren, dient u te valideren dat dit nieuwe finale certificaat is inbegrepen in de lijst van toegelaten certificaten.
Gekende applicaties om een validatie met een finaal certificaat te verrichten:
Als u gebruik maakt van een Shibboleth SP
Als u de metadata zo geconfigureerd hebt dat ze dagelijks gedownload worden, moet u niets doen.
Als u de metadata zo geconfigureerd hebt dat ze enkel lokaal bestaan, dan dient u manueel het metadata-bestand van onze IDP te downloaden en lokaal te installeren.
De nieuwe certificaten voor « *.ehealth.fgov.be » zijn opgenomen in het metadata-bestand (xml) van de IDP (Identity Provider) van eHealth die online beschikbaar is via:
Opgepast, het nieuwe certificaat is uitgegeven door een andere certificeringsautoriteit. Deze is niet meer Quovadis maar Sectigo. Als gevolg daarvan is de keten van vertrouwen (Certificate Chain of Trust) totaal verschillend.
Wanneer moet u deze acties uitvoeren?
Het nieuwe certificaat is reeds geactiveerd bij eHealth in acceptatie en in productie
U dient dus deze certificaten in parallel met de bestaande certificaten toe te voegen tegen ten laatste 11/02/2022.
Indien u deze acties niet tijdig uitvoert kan het zijn dat u geen beveiligde verbinding (https) meer tot stand kan brengen vanaf de voormelde datums, omdat uw systeem de nieuwe certificaten niet zal vertrouwen.
Acties nodig voor de eindgebruikers
Er zijn geen specifieke acties nodig voor de eindgebruikers
Helena ( wcag.label.externalLink)
is een platform aangeboden door het softwarebedrijf HealthConnect NV om een veilige communicatie mogelijk te maken tussen patiënten en zorgverleners.
Een patiënt die het Helena-platform wil gebruiken, dient zich te authentiseren, d.w.z. zich elektronisch identificeren en elektronisch bewijzen dat hij degene is die hij beweert te zijn. Die authenticatie kan geschieden met 3 middelen, die allen geïntegreerd zijn de in de Federal Authentication Service (FAS) ( wcag.label.externalLink)
van de FOD BOSA
Het Helena-authenticatiemiddel is een twee-factor-authenticatiemiddel ( wcag.label.externalLink)
, dat gebaseerd is op een combinatie van bezit van een apparaat (computer, smartphone, tablet) en van kennis (zelfgekozen pincode), waarmee een patiënt elektronisch zijn identiteit kan bewijzen en kan bewijzen dat hij degene is die hij beweert te zijn.
Het Helena-authenticatiemiddel wordt op de volgende wijze aangemaakt
een zorgverlener (de GMD ( wcag.label.externalLink)
-houder van de patiënt of een ziekenhuis waarmee de patiënt een therapeutische relatie heeft) gaat de identiteit na van de patiënt
de patiënt ontvangt van de zorgverlener een activatiecode die door Helena bij registratie wordt gegenereerd
de patiënt activeert zijn patiëntaccount binnen Helena met
Waarom is het Helena-authenticatiemiddel opgenomen in de FAS van de FOD BOSA ?
Voor een burger is het gemakkelijk om zich t.o.v. verschillende elektronische toepassingen te kunnen authentiseren met één authenticatiemiddel i.p.v. voor elke toepassing aparte authenticatiemiddelen te moeten gebruiken. Dat concept heet ‘single sign on’: zich éénmaal authentiseren en vervolgens kunnen gebruik maken van verschillende toepassingen zonder zich telkens opnieuw te moeten authentiseren.
Het veiligste authenticatiemiddel is de elektronische identiteitskaart (eID). Maar een aantal burgers beschikt niet over een eID, beschikt niet over een eID-lezer of beschikt niet over de nodige kennis om de software te installeren die nodig is om zich met de eID te kunnen authentiseren. Daarenboven kan de eID niet als authenticatiemiddel worden gebruikt wanneer de gebruiker zich wil authentiseren met een mobiel apparaat (tablet, smartphone).
Itsme is erkend als een betrouwbaar, algemeen bruikbaar authenticatiemiddel en het Helena authenticatiemiddel als een betrouwbaar authenticatiemiddel in de gezondheids- en sociale sector. Uiteraard in de mate dat ze (blijven) voldoen aan de vastgelegde minimale specificaties.
Daarenboven heeft het feit dat het Helena-authenticatiemiddel wordt beschouwd als een betrouwbaar single sign on authenticatiemiddel in de gezondheidssector als voordeel dat de burger die het gebruikt, met single sign on toegang kan hebben tot andere toepassingen of platformen dan het Helena-platform, zoals de resultatenservers van labo’s of de gegevensbank met geneesmiddelenvoorschriften. Indien dat niet het geval zou zijn, zouden artsen de neiging kunnen hebben om de onderzoeksresultaten of de geneesmiddelenvoorschriften te kopiëren naar het Helena-platform, dat dan ongewenst zou uitgroeien tot een centrale gegevensbank met gezondheidsinformatie over heel wat patiënten. Dat is niet gewenst.
Waar staat het Helena-authenticatiemiddel ingeschaald in de FAS van de FOD BOSA ?
Het Helena-authenticatiemiddel staat ingeschaald op niveau 350.
Het Helena-authenticatiemiddel biedt, als de specificaties vermeld in de beraadslaging nr. 19/210 van het Informatieveiligheidscomité (wcag.label.file wcag.label.externalLink)
correct zijn nageleefd, eenzelfde waarborg als de authenticatiemiddelen van niveau 400 die gebaseerd zijn op een TOTP ( wcag.label.externalLink)
. Omdat het Helena-authenticatiemiddel echter enkel gebruikt wordt in de gezondheids- en sociale sector, moet het kunnen onderscheiden worden van de andere authenticatiemiddelen van het niveau 400, die wel algemeen gebruikt kunnen worden. Daarom is het Helena-authenticatiemiddel ingeschaald op niveau 350.
Het feit dat dergelijke initialisering enkel kan gebeuren door de GMD ( wcag.label.externalLink)
-houder van de betrokkene of door een ziekenhuis waarmee de betrokkene een zorgrelatie heeft, moet worden gewaarborgd door de softwarecomponent van het Helena platform die wordt aangeroepen door het softwarepakket van de betrokken arts of ziekenhuis om de aanmaak van een Helena authenticatiemiddel te initialiseren.
Het feit dat het Helena-authenticatiemiddel kan worden gebruikt als authenticatiemiddel in de gezondheidssector is beslist door het Beheerscomité van het eHealth-platform. Het feit dat het Helena-authenticatiemiddel kan worden gebruikt als authenticatiemiddel in de sociale sector is beslist door het Beheerscomité van de Kruispuntbank van de Sociale Zekerheid. Deze beslissingen zijn weergegeven in het Gebruikersreglement (wcag.label.file wcag.label.externalLink)
van het eGezondheidsportaal en het portaal sociale zekerheid
Waarop heeft de klacht tegen het Helena-authenticatiemiddel, die is ingediend door Medispring, 5 artsen en een patiënt bij de Gegevensbeschermingsautoriteit, betrekking ?
De klacht heeft in wezen betrekking op het feit dat een Helena-authenticatiemiddel zou kunnen worden aangemaakt
door een andere zorgverstrekker dan de GMD ( wcag.label.externalLink)
-houder van de betrokkene of dan een ziekenhuis dat een therapeutische relatie heeft met de betrokkene en/of
zonder dat de identiteit van de betrokkene grondig wordt nagegaan
Indien dit het geval zou zijn, voldoet de wijze waarop het Helena-authenticatiemiddel wordt toegekend niet aan de specificaties vastgelegd door de beraadslaging van het Informatieveiligheidscomité.
Uiteraard is het naleven van de vereisten voor een degelijke identificatie van de betrokkene de verantwoordelijkheid van de GMD ( wcag.label.externalLink)
-houder of het ziekenhuis dat de aanmaak van het Helena-authenticatiemiddel initialiseert. Het feit dat dergelijke initialisering enkel kan gebeuren door de GMD ( wcag.label.externalLink)
-houder van de betrokkene of door een ziekenhuis waarmee de betrokkene een therapeutische relatie heeft, moet worden gewaarborgd door de softwarecomponent van het Helena-platform die wordt aangeroepen door het softwarepakket van de betrokken arts of ziekenhuis om de aanmaak van een Helena-authenticatiemiddel te initialiseren.
Voorstel van oplossing
Welke arts of ziekenhuis de aanmaak van een Helena authenticatiemiddel heeft geïnitialiseerd bevindt zich een logging bij het Helena platform. De softwarecomponent van het Helena platform die wordt aangeroepen door het softwarepakket van een arts of een ziekenhuis om de aanmaak van een Helena authenticatiemiddel te initialiseren, verifieert vóór de initialisering in de authentieke bronnen aan geboden via het eHealth-platform dat hetzij de arts de GMD ( wcag.label.externalLink)
-houder is van de betrokkene, hetzij een ziekenhuis is waarmee de betrokkene een zorgrelatie heeft. Dit wordt afgedwongen door de softwarecode en is niet parametriseerbaar.
Voor de bijna 800.000 burgers waarvoor in het verleden een Helena authenticatiemiddel is aangemaakt, wordt in de logging nagegaan of het Helena authenticatiemiddel is geïnitialiseerd door de arts die in de authentieke bron van de GMD ( wcag.label.externalLink)
-houders is gekend als de GMD ( wcag.label.externalLink)
-houder van de betrokkene. Indien dat niet het geval is, wordt het Helena authenticatiemiddel ongeldig gemaakt. In dat geval krijgt de burger de eerste keer dat hij/zij zich probeert te authentiseren met het Helena authenticatiemiddel de melding dat het Helena authenticatiemiddel vervallen is en hij/zij zich hetzij moet aanmelden met de eID of Itsme, hetzij de aanmaak van een nieuw Helena authenticatiemiddel moet laten initialiseren door zijn de GMD ( wcag.label.externalLink)
-houder of door een ziekenhuis waarmee hij/zij een zorgrelatie heeft
De GMD ( wcag.label.externalLink)
-houders en de ziekenhuizen die de aanmaak van een Helena authenticatiemiddel initialiseren, worden bij de aanmaak uitdrukkelijk gewezen op het feit dat ze de identiteit van de betrokkene degelijk moeten nagaan tijdens een fysiek contact en ze daarvoor aansprakelijk zijn.
Toelichting van het eHealth-platform omtrent de toepassing CovidScanBE
De vzw Charta 21 heeft onlangs een beroep in kort geding ingesteld tegen het eHealth-platform met het oog op de opschorting van de toepassing Covid Scan. Het lijkt dat een aantal aspecten van de werking van deze dienst verduidelijkt dienen te worden en derhalve acht het eHealth-platform het noodzakelijk om een aantal elementen toe te lichten.
Het is belangrijk erop te wijzen dat de ontwikkeling en implementatie van de Covid-certificaten, van de toepassing CovidSafeBE en van de toepassing CovidScanBE verricht worden in uitvoering van een gedetailleerd samenwerkingsakkoord dat goedgekeurd werd door alle Parlementen van het land. Ze zijn het resultaat van een nauwe samenwerking tussen de federale en regionale overheden, Sciensano en het eHealth-platform. Het agentschap Digitaal Vlaanderen is verantwoordelijk voor de uitbouw en het beheer van de oplossing.
De toepassing CovidSafeBE is bedoeld om mensen de mogelijkheid te geven in alle vrijheid deel te nemen aan sociale en culturele evenementen met inachtneming van de essentiële opvolgings- en voorzorgsmaatregelen in het kader van het beheer van de gezondheidscrisis. Oorspronkelijk was het niet de bedoeling om te voorzien in een integratie van de personen met een geldig vaccinatiecertificaat die besmet geraakten met Covid en dus de facto (tijdelijk) geen toegang kunnen krijgen tot een evenement. Deze situatie werd door de epidemiologen zoals Erika Vlieghe en Steven Van Gucht echter beschouwd als een belangrijke tekortkoming.
Daarom werd een publieke lijst opgesteld van certificaten die, om diverse redenen, (tijdelijk) geen toegang meer geven tot een evenement. Er wordt onderstreept dat deze lijst enkel de nummers bevat van de certificaten die tijdelijk of definitief geschorst werden. Deze lijst omvat zowel de nummers van de certificaten van personen die positief getest hebben op het coronavirus als de nummers van de certificaten die als ongeldig of onjuist worden beschouwd. Er kan geen enkele informatie omtrent de reden van de schorsing worden afgeleid, noch informatie over de identiteit van de houder van het certificaat.
De implementatie van een dergelijke lijst is een standaardmethode om de geldigheid van elektronische documenten te beheren. Zo bestaat er bijvoorbeeld een publieke lijst van geschorste elektronische identiteitskaarten of van geschorste bankkaarten.
Wat de klacht betreft die ingediend werd bij de Gegevensbeschermingsautoriteit (GBA) heeft het eHealth-platform op vrijdag 15 oktober 2021 de nodige antwoordelementen aan deze instelling verschaft voor het onderzoek van de klacht. De GBA zal de beweringen in alle onafhankelijkheid onderzoeken, waarbij er geen enkele interventie van het eHealth-platform is, buiten het meedelen van de technische antwoorden.
