RSVZ B2B

RSVZ B2B Security Policy Historiek wijzigingen Datum 29/08/2007

Omschrijving Initiële versie

Distributielijst Ontvanger

Eigenaar Document-ID Configuratie Versienummer Versie van Afgedrukt op Naam bestand

RSVZ/SIV (code en benaming)

B2B/29-08-2007/versie01 23/07/2017 08:52 23/07/2017 08:52

Wijziging uitgevoerd door RSVZ

RSVZ B2B

blz. 2 van 9

1.

SCOPE POLICY. ................................................................................................................................................ 3

2.

TOEPASSINGSGEBIED ................................................................................................................................... 5

3.

VOORWAARDEN.............................................................................................................................................. 5

4.

IMPLEMENTATIE POLICY. .......................................................................................................................... 7

5.

HANDHAVING, OPVOLGING EN HERZIENING ...................................................................................... 9

317585075

23/07/2017

1. Scope policy. Deze policy kadert in het veiligheidsbeleid van het netwerk van het RSVZ. Voor het gebruik van webservices in het kader van de ontwikkeling van toepassingen binnen het netwerk van het RSVZ wordt vereist dat de veiligheidsmaatregelen eigen aan het gebruik van dergelijke componenten duidelijk worden vastgelegd. Een webservice wordt gedefinieerd als een softwarecomponent die eenduidig zelfbeschreven functionaliteit aanbiedt en gedistribueerd aangeroepen wordt door middel van standaard-internettechnologie. De belangrijkste eigenschappen worden hieronder toegelicht: 

 

Webservices situeren zich hier in de context van integratie tussen toepassingen van het RSVZ en de sociale verzekeringsfondsen. De technologie biedt een manier om gedistribueerde toepassingen te laten communiceren met elkaar, op een standaardmanier. De communicatie tussen toepassingen steunt op standaarden. Die maken het mogelijk om berichten uit te wisselen tussen heterogene toepassingen, dit wil zeggen onafhankelijk van programmeertaal en platform. Webservices zijn elektronische diensten die ontwikkeld worden met het oog op hergebruik. Dankzij de standaarden kunnen webservices aangeroepen worden door s. Een inherent voordeel van webservices is dan ook dat ze slechts één maal ontwikkeld moeten worden en overal aangeroepen kunnen worden.

Standaarden zijn cruciaal opdat heterogene toepassingen elkaar zouden begrijpen”. Die communicatie kan tot stand komen dankzij drie mature basisstandaarden: 

 

XML: een manier om informatie op een eenduidige manier te beschrijven met behulp van markups of tags. In de informatie worden tags gezet die meer informatie geven over de data en dus semantiek toevoegen aan de data. Door het gebruik van data tags wordt de informatie zelfbeschrijvend en ook makkelijker te interpreteren in heterogene toepassingenomgevingen. SOAP (Simple Object Access Protocol): beschrijft het formaat van de XML-berichten die uitgewisseld worden tussen een cliënt en een webservice. WSDL (Web Services Description Language): beschrijft het formaat van de interface die als contract geldt tussen een cliënt en een webservice. Een WSDL-document beschrijft de operaties die de webservice aanbiedt met de input- en outputparameters, eventuele foutmeldingen en de locatie (URL) van de webservice.

Webservices zijn een belangrijke enabler van een Service-Oriented Architecture (SOA). Een webservice provider stelt een webservice ter beschikking. De webservice requester initieert de web service. Hij neemt het initiatief om de communicatie op te zetten naar de webservice provider. De informatie betreffende de web service wordt op de RSVZ website gepubliseerd. De informatie bevat een functionele beschrijving van de web service, de WSDL en het schema van het (de) de XML bericht(en) die in het web service scenario kunnen uitgewisseld worden tussen webservice provider en webservice requester. WSDL is de taal om Web Services te beschrijven. WSDL heeft 2 functies:  eenduidige (machine leesbare) beschrijving van de Web Service. Dit zal gebruikt worden als “contract” tussen het RSVZ en de organisaties die gebruik maken van de elektronische dienstverlening.  kan als input gebruikt worden voor een codegenerator binnen de ontwikkelingsomgeving die een deel van de voor de Web Service benodigde code genereert. Dit vereenvoudigt de integratie van de web service binnen een applicatie omgeving. In de praktijk is WSDL een design-time hulpmiddel wat het bouwen van interoperabele Web Services vereenvoudigt. WSDL is een “de facto” standaard.

RSVZ B2B

blz. 4 van 9

Een WSDL document bestaat uit de volgende onderdelen:  Types: Hier worden abstracte XML-structuren beschreven in XML Schema formaat.  Messages: Met de elementen en elementtypen uit de Types worden Messages samengesteld – dit zijn generieke berichten gedefinieerd in XML.  PortTypes: Een PortType is een logische “applicatiepoort” die een of meer Operations ondersteunt. Een Operation bestaat uit een of meer Inputs en Outputs. Deze Inputs en Outputs verwijzen naar de Messages die hierboven beschreven zijn. Een Message beschrijft dus de interne structuur van een of meer Inputs of Outputs.  Bindings: Een Binding verbindt een – logisch – PortType met een specifiek communicatie- of transportprotocol (vb SOAP over http) Alle Operations, Inputs en Outputs uit de Port Type worden toegewezen aan SOAP. Ook wordt aangegeven op welke wijze het SOAP bericht er uit dient te zien (document versus rpc ‘remote procedure call’, literal versus encoded). Het RSVZ zal gebruik maken van de "document/literal" stijl van gegevensuitwisseling, waarbij, de SOAP Body direct het topelement van een XML document bevat.  Services: Een Service bestaat uit een of meer fysieke Ports. Een Port verbindt een Binding met een locatie, normaal gesproken een URI waarmee de Port over het Internet aangeroepen kan worden.

De hierboven vermelde specificaties, met name SOAP & WSDL, zijn internationaal erkende standaarden die onderhouden worden door W3C (World Wide Web Consortium).. In deze inleiding werden de basisstandaarden kort hernomen. Om webservices krachtiger te maken, moet er naast de standaardconnectiviteit ook aandacht geschonken worden aan de nodige beveiliging en het ondersteunen van asynchrone communicatie, transacties en orchestratie.

317585075

23/07/2017

RSVZ B2B

blz. 5 van 9

2. Toepassingsgebied

Deze policy heeft betrekking op de ontwikkeling en het gebruik van webservices via het Extranet van de Sociale Zekerheid, het internet of een Leased Line verbinding ( vb Belgacom Bilan) , waarbij gebruik gemaakt wordt van het standaard internet transport protocol. De verbindingen tussen het RSVZ en de Sociale verzekeringsfondsen, via de RSVZ B2B infrastructuur, vallen onder het toepassingsgebied van deze policy.

3. Voorwaarden Behalve uitdrukkelijke afwijking toegestaan in het kader van een gerechtvaardigde en gedocumenteerde aanvraag aan de veiligheidconsulente van het RSVZ moeten bij de ontwikkeling en het gebruik van webservices de volgende voorwaarden worden nageleefd: 

Authentificatie: Bij het opzetten van een web service moet er een authenticatie procedure doorlopen worden. Aangezien de RSVZ B2B informatie diensten vertrouwelijke informatie ter beschikking stellen en communiceren met de Sociale verzekeringfondsen, wordt door het RSVZ hoge toegangsbeveiligingsvereisten vooropgesteld. Deze hoge eisen op vlak van toegangsbeveiliging worden ingevuld door sterkere maatregelen, nl. strong authentication of sterke authenticatie. Bij de normale authenticatie methode gebruikt men een code en een paswoord. De code en het paswoord is een gegeven die men kent/weet. Deze manier van authenticatie blijkt toch niet voldoende te zijn. Vaak worden wachtwoorden doorgegeven aan bijvoorbeeld collega’s of worden zelfs gekraakt. Men is dan ook niet zeker dat de persoon/systeem die inlogt, ook de persoon/systeem is die hij zegt dat hij is. De combinatie van naam en wachtwoord is dus maar een “zwak” bewijs van de identiteit van de gebruiker/systeem. Bij strong authenticatie wordt de authenticatie methode sterker gemaakt omdat men ook een token nodig heeft om zich te authenticeren. Deze token wordt aan een gebruikers/systeem gegeven. Men moet het in zijn bezit hebben om zich te authenticeren. Het gebruik van de persoonlijke token is beveiligd door een paswoord. Strong authenticatie is gebaseerd op iets dat men heeft (token) en iets dat men kent (paswoord). In de context van B2B en communicatie tussen systemen worden voor de strong authenticatie server certificaten gebruikt. Dit is een token die aan een systeem is toegewezen. Bij de authenticatie in de B2B communicatie zal gebruik gemaakt worden van certificaten.



Vertrouwelijkheid: Tijdens de B2B communicatie dient het vertrouwelijk karakter van de informatie gegarandeerd te worden. Over het gebruikte communicatie pad dient de informatie beveiligd te worden zodat een derde partij niet in staat is deze informatie te lezen en te interpreteren.



Integriteit Tijdens de B2B communicatie dient de integriteit van de informatie gegarandeerd te worden. De informatie mag tijdens het transport niet gewijzigd kunnen worden, zonder dat dit gedetecteerd wordt.



Autorisatie en autorisatiebeheer:. Het RSVZ voorziet in de context van de B2B communicatie een gecentraliseerd beheersysteem waarin de autorisaties van de sociale verzekeringsfondsen tot de elektronische B2B diensten worden opgenomen.

317585075

23/07/2017

RSVZ B2B



blz. 6 van 9

Niet-verwerping : Niet verwerping is de bewijskracht dat men niet kan ontkennen iets gedaan te hebben. In de context van B2B geeft dit de bewijskracht dat men niet kan ontkennen het bericht verstuurd te hebben. Om de garantie te hebben van de “niet verwerping”, moet men gebruik maken van de elektronische handtekening. Het certificaat (token) dat gebruikt wordt bij de generatie van de elektronische handtekening is toegewezen aan een persoon ( = persoonlijk bezit) . Hij zal na de generatie van de electronische handtekening, ook niet kunnen ontkennen dat hij zijn (persoonlijke) token gebruikt heeft voor de generatie van de handtekening. De beslissing om een digitale handtekening te gebruiken voor de niet-verwerping, onder meer in de juridische dimensie ervan, moet het voorwerp uitmaken van een formeel proces bij elke door de toepassing betrokken partij.



Veiligheidslog, historiek en auditing: De traceerbaarheid van de B2B communicatie moet worden gegarandeerd zowel op het niveau van de Web Services Requester als op het niveau van Web Services Provider. Men moet de historiek van de auditlog kunnen consulteren. De berichten en gelogde informatie dienen 1 jaar bijgehouden te worden en consulteerbaar te zijn. De gelogde informatie dient 10 jaar bijgehouden te worden.

317585075

23/07/2017

RSVZ B2B

blz. 7 van 9

4. Implementatie Policy. Voor de toepassing van de hierboven beschreven policy zal het RSVZ volgende technologieën gebruiken/opleggen en principes toepassen bij de B2B communicatie, nl. het gebruik van 2WAY SSL en specificaties mbt de audit logging.

Authenticatie Wanneer een WS communicatie wordt opgezet zal er volgens de 2WAY SSL standaard een “handshaking” doorlopen worden waarbij een binnen de standaard vastgelegde string elektronisch wordt ondertekend met de private sleutel van de server. Deze elektronische handtekening wordt door de ontvangende partij gecontroleerd met de publieke sleutel van de versturende partij. Op deze wijze wordt tijdens de initialisatie van de WS communicatie sessie het “strong authenticatie” principe gevolgd. De B2B infrastructuur bij het RSVZ en ook de WS infrastructuur (software of componenten) werken op een vooraf vastgelegde server infrastructuur. Aan deze serverinfrastructuur zal een (server) certificaat toegekend worden. Voor de toekenning van de certificaten zal het RSVZ gebruik maken van Fedict als trusted party. Fedict zal de certificaten toekennen aan de verschillende partijen waarmee het RSVZ communiceert. Deze certificaten zullen enkel gebruikt worden voor de B2B communicatie tussen het RSVZ en het Sociaal verzekeringfonds. De sociale verzekeringsfondsen zullen de publieke sleutel doorgegeven aan het RSVZ voor de GO LIVE. Het RSVZ zal zijn publieke sleutel doorgegeven aan de sociale verzekeringsfondsen. Volgende attributen van het certificaat dienen ook uitgewisseld te worden tussen het RSVZ en de sociale verzekeringsfondsen :  Common Name  Organization  Organization Unit  Location  Country Het RSVZ voorziet een omgeving om deze informatie op een beveiligde manier te beheren. Deze omgeving is geïntegreerd met het B2B communicatie platform, aangezien deze omgeving gebruik dient te maken van deze informatie.

Vertrouwelijkheid Als transportprotocol zal HTTPS gebruikt worden. De informatie wordt geencrypteerd. De sleutel die gebruikt wordt om de informatie tijdens het transport te encrypteren wordt op een beveiligde manier tussen beide WS communicatie platformen afgestemd volgens het 2WAY SSL protocol.

Integriteit Het gebruik van SSL bij het transport garandeert de integriteit van de data.

Autorisatie Het RSVZ zal aan de SVF’en “programma nummers” toekennen. Deze nummers identificeren de individuele toepassingsomgevingen binnen het SVF die de B2B berichten genereren. Het SVF zal dit programma nummer ook vermelden in de B2B berichten. Bij voorkeur zal het SVF ook het gebruikersnummer van de persoon binnen het SVF vermelden in het B2B bericht die verantwoordelijk was voor het aanmaken van het B2B bericht. Indien het gebruikersnummer niet wordt vermeld in de B2B berichten, is het de exclusieve verantwoordelijkheid van het SVF die een programmanummer gebruikt om voorzieningen te treffen waarmee te allen tijde kan geverifieerd worden welke persoon door middel van het programmanummer een bepaald gegeven via B2B heeft meegedeeld / opgevraagd Het RSVZ autorisatie beheer bevat per programmanummer welke B2B stromen de instelling mag gebruiken en welke SVF’n verantwoordelijk zijn voor welke dossiers (sociaal verzekerde) en daarbij ook gemachtigd zijn om in het kader van deze dossiers informatie uit te wisselen via het RSVZ netwerk. Het gebruikersnummer wordt enkel gelogged door het RSVZ om later eenvoudiger te kunnen traceren wie een bericht heeft ingegeven. 317585075

23/07/2017

RSVZ B2B

blz. 8 van 9

Niet-verwerping De juridische dimensie moet men zien bij functionele gegevensuitwisseling. Bijvoorbeeld in het 4de weg project waar er een juridische dimensie is ( = een wet) die zegt dat één bepaalde functioneel bericht elektronisch dient ondertekend te worden en deze handtekening ook een juridische waarde heeft. Deze beveiligingsbehoefte kan niet op transport niveau ingevuld worden maar moet op bericht niveau ingevuld worden. Hiervoor zijn twee standaarden van toepassing :  WS Security  XML signing Voor deze beveiliging worden ook geen server certificaten gebruikt, maar certificaten die gekoppeld zijn aan een rechtspersoon of een fysieke persoon. De wijze waarop zo’n beveiliging moet gerealiseerd worden moet steeds geanalyseerd worden in functie van de juridische dimensie die door de overheid wordt opgelegd.

Logging. Voor de aspecten m.b.t. veiligheidslog, historiek & auditing dient de WS communicatie omgevingen bij het RSVZ en de sociale verzekeringsfondsen de nodige informatie te loggen tijdens de communicatie. Volgende informatie dient gelogged te worden in productie en test omgevingen : Algemeen Timestamp

Tijdstip van ontvangst/verzenden van het bericht (datum uur min sec) On-line – Batch MQ-Series – WS – FTP – http

Communicatie type Transport type Bestemmeling ServerOrg Id ServerOrg MatrixId ServerOrg MatrixSubId ServerOrgUserId ServerOrgPgmId

KBO Nummer organisatie Identificatie van de sector in primair network Identificatie van de sector in secundair network Toegangcode gebruiker die bericht initieert Programma nummer van het systeem dat bericht initieert. Aanvraag en beheren van de programmanummers gebeuren onder toezicht van de veiligheidconsulente van het RSVZ. Deze nummers worden toegekend afhankelijk van het soort toepassing.

Verzender ClientOrg Id ClientOrg MatrixId ClientOrg MatrixSubId ClientOrgUserId ClientOrgPgmId

KBO Nummer organisatie Identificatie van de sector in primair network Identificatie van de sector in secundair network Toegangcode gebruiker die bericht initieert Programma nummer van het systeem dat bericht initieert

Bericht informatie MessageID MessageEnveloppe MessageTimeRequest MessageServideId MessageVersion CorrelationId Message

Unieke identificatie bericht Type enveloppe bericht : vb B2B SOAP Timestamp bericht Functioneel bericht type Versie van functioneel berichttype Bij een antwoord het ticket van de vraag Het bericht

Alle partijen (RSVZ & Sociale verzekeringsfondsen) dienen deze informatie (security logging) gedurende 10 jaar bij te houden . Het eerste jaar dient het SVF de logging op een snelle wijze ter beschikking te kunnen stellen bij vragen van het RSVZ ( binnen een termijn van enkele dagen). 317585075

23/07/2017

RSVZ B2B

blz. 9 van 9

5. Handhaving, opvolging en herziening

De handhaving, opvolging en herziening van deze POLICY behoren tot de verantwoordelijkheid van de dienst Informatieveiligheid van het RSVZ.

317585075

23/07/2017