RSVZ B2B

advertisement
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
Download
Random flashcards
fff

2 Cards Rick Jimenez

Test

2 Cards oauth2_google_0682e24b-4e3a-44be-9bca-59ad7a2e66a4

hoofdstuk 2 cellen

5 Cards oauth2_google_c110ae80-d7f3-4403-b521-4d3d8bb0f63c

Test

2 Cards peterdelang

Create flashcards