Richtlijn beveiliging persoons- en IAA gegevens bij datacommunicatie voor DKD. Versie 1.0 Datum: 26 februari 2007

Transcriptie

1 Richtlijn beveiliging persoons- en IAA gegevens bij datacommunicatie voor DKD Versie 1.0 Datum: 26 februari 2007

2 Inhoudsopgave 1. INLEIDING ALGEMEEN DOELSTELLING DOCUMENT SCOPE BRONVERMELDING VERSIEGESCHIEDENIS GOEDKEURING EN ONDERHOUD IDENTIFICATIE, AUTHENTICATIE EN AUTORISATIE TOELICHTING BEGRIPPEN UITGANGSPUNTEN BEVEILIGING PERSOONS- EN IAA GEGEVENS EISEN BEVEILIGING PERSOONS- EN IAA GEGEVENS CLASSIFICERING PERSOONS- EN IAA GEGEVENS CLASSIFICERING PERSOONS- EN IAA GEGEVENS BEVEILIGING VAN PERSOONS- EN IAA GEGEVENS DIGITALE CERTIFICATEN UNIEKE IDENTITEIT MIDDELS DIGITAAL CERTIFICAAT INTERNE EN EXTERNE CERTIFICATEN OPLOSSINGEN BESCHRIJVING OPLOSSINGEN BINNEN DE TRUSTED NETWERKDOMEINEN VAN DE SUWINET PARTIJEN BESCHRIJVING OPLOSSINGEN VOOR GEGEVENSUITWISSELING MET EXTERNE PARTIJEN CONCLUSIE OPLOSSINGEN Pagina 2 van 16

3 1. Inleiding 1.1 Algemeen Binnen de keten van werk en inkomen vindt op grote schaal gegevensuitwisseling plaats. Wettelijke kaders vragen om zorgvuldige omgang en beveiliging van persoonsgegevens bij gegevensuitwisseling over netwerken. Voorkomen moet worden dat onbevoegde personen of processen toegang krijgen tot gegevens. Specifieke aandacht voor beveiliging wordt gevraagd vanuit de Wet Bescherming Persoonsgegevens en de Wet SUWI bij gegevensuitwisseling over netwerken. Bij datacommunicatie over netwerken moeten de zender en ontvanger zekerheid hebben over elkaars identiteit. Hiernaast mogen persoonsgegevens gedurende het gegevensuitwisselingsproces niet onbevoegd gelezen of gemuteerd worden. Regelmatig worden vanuit de verschillende deelprojecten binnen het DKD programma vraagstukken neergelegd bij de werkgroep beveiliging en privacy over hoe invulling moet worden gegeven aan bovengenoemde eisen. Geconstateerd is dat het huidige Suwinet-Normenkader en de Ketenarchitectuur geen heldere uitspraken doet over het identificatie, authenticatie en autorisatieproces van applicaties en (web)services bij gegevensuitwisseling en hiervoor oplossingen aandraagt. De Domeingroep Privacy & Beveiliging (DPB) heeft dan ook de werkgroep beveiliging en privacy van DKD gevraagd een Richtlijn te schrijven om in deze leemte te voorzien. De richtlijn moet een antwoord geven op de volgende vraagstukken: 1. Het vraagstuk van identificatie, authenticatie en autorisatie (IAA) van applicaties en (web)services bij gegevensuitwisseling over netwerken. 2. Het wel of niet versleuteld uitwisselen van persoonsgegevens over netwerken. De Wet Bescherming Persoonsgegevens geeft via de Handreiking Achtergrond Studies en Verkenningen 23 (AV-23) een methodiek aan voor het classificeren van persoonsgegevens waarvoor passende beveiligingsmaatregelen getroffen moeten worden bij gegevensuitwisseling over netwerken. AV-23 geeft echter alleen richtlijnen voor het classificeren van persoonsgegevens en de eisen voor versleuteling van persoonsgegevens. Binnen AV-23 worden echter ook eisen gesteld aan IAA gegevens bij berichtuitwisseling over netwerken. AV-23 gaat vervolgens niet in op de eisen voor beveiliging van de IAA gegevens zelf. In deze richtlijn wordt dan ook nader aandacht besteed aan de classificatie en beveiliging van de IAA gegevens en oplossingen voor het identificatie, authenticatie en autorisatievraagstuk bij gegevensuitwisseling over netwerken tussen applicaties en (web)services alsmede het wel of niet moeten versleutelen van de datalijnen. De richtlijn vormt hiermee een aanvulling en nadere uitwerking van de eisen met betrekking tot IAA gegevens van applicaties en (web)services binnen de Ketenarchitectuur en Normenkader voor Suwinet. Bij de volgende onderhoudsbeurt zal het Suwinet-Normenkader en de Ketenarchitectuur dan ook in lijn moeten worden gebracht met de uitgangspunten en oplossingsrichtingen in deze richtlijn. 1.2 Doelstelling document Het inventariseren van de (wettelijke) beveiligingseisen en het maken van een vertaalslag van de beveiligingseisen en uitgangspunten naar praktische oplossingen, welke de eigenaren van keten applicaties en (web)services kunnen implementeren bij gegevensuitwisseling voor het kunnen identificeren, authenticeren en autoriseren van applicaties en (web)services en het wel of niet moeten versleutelen van datalijnen. Pagina 3 van 16

4 1.3 Scope De in dit document beschreven (wettelijke) kaders zijn bindend voor alle applicaties en (web)services binnen de keten van werk en inkomen en binnen het trusted netwerkdomein van de ketenpartijen. De handreiking beperkt zich enkel tot het kunnen identificeren, authenticeren en autoriseren van applicaties en (web)services bij gegevensuitwisseling. De proceseigenaren zullen hiernaast ook invulling moeten geven aan de overige beveiligingseisen uit het Suwinet-Normenkader. Voor identificatie, authenticatie en autorisatie van personen wordt verwezen naar de oplossing zoals operationeel voor Suwinet-Inkijk. 1.4 Bronvermelding Ketenarchitectuur versie 1.0 Verantwoordingsrichtlijn Suwinet versie 2.0 Tactisch Beleid B&P UWV Classificatiemodel versie 1.0 PSA Digitaal Klantdossier UWV 2006 versie 0.9 Achtergrond Studies en Verkenningen 23 (AV-23) van CBP Artikelen Webservices technologie van GvIB Vincent Alwicher Versiegeschiedenis Versie Datum Verschil met voorgaande versie januari 2007 Eerste versie structuur februari 2007 Aanpassing na review van werkgroep DKD Privacy en Beveiliging februari 2007 Definitieve versie 1.6 Goedkeuring en onderhoud Dit document is opgesteld door de werkgroep DKD Privacy en Beveiliging en binnen de Domeingroep Privacy en Beveiliging afgestemd met de CWI, UWV, SVB, CP/ICT, BKWI en IB. Het document is op xx-xx-2007 vastgesteld door het Algemeen Keten- Overleg (AKO). De Richtlijn beveiliging persoons- en IAA gegevens bij datacommunicatie is een nadere uitwerking van de identificatie, authenticatie en autorisatie eisen uit de Ketenarchitectuur en het Suwinet-Normenkader. Derhalve vindt goedkeuring van de Richtlijn beveiliging persoons- en IAA gegevens bij datacommunicatie plaats binnen de Domeingroep Privacy en Beveiliging (DPB). Onderhoud van dit document wordt gedaan door de Domeingroep Privacy en Beveiliging of door een andere partij in opdracht van de DPB. Pagina 4 van 16

5 2. Identificatie, authenticatie en autorisatie 2.1 Toelichting begrippen Identificatie is het kenbaar maken van de identiteit van een subject (een gebruiker, een apparaat of een proces) in de informatietechnologie. Authenticatie is vervolgens het, met een bepaalde mate van zekerheid, vaststellen dat de identiteit juist is en behoort bij het subject dat zich identificeert. De identiteit wordt gebruikt om de toegang van het subject tot een object te beheersen. Een object is bijvoorbeeld een computerbestand of een record in een database. Identificatie en authenticatie kan op verschillende manieren plaatsvinden zoals: Gebruik van een gebruikersnaam of user-id plus een wachtwoord in een inlogscherm; Gebruik van een user-id in combinatie met een vingerafdruk of een ander biometrisch kenmerk; Gebruik van een user-id in combinatie met een token (zoals een smartcard); Gebruik van een IP-nummer of MAC-adres in combinatie met een server certificaat. Vanuit de optiek van informatiebeveiliging is identificatie van een subject de eerste stap in het autorisatieproces. De tweede stap is authenticatie, het vaststellen van de juistheid van de opgegeven identiteit. De derde stap in dit proces is autorisatie, het vaststellen of het subject toegang tot het object mag verkrijgen. Als vierde stap kan worden genoemd het vaststellen of het subject namens een ander subject is gemachtigd taken uit te voeren en waarvoor dit andere subject autorisatie verleent. Het machtigen valt buiten de scope van dit document en in het vervolg van het document zal over identificatie, authenticatie en autorisatie worden gesproken als IAA gegevens. Om de identiteit op een zinvolle manier te gebruiken, is het noodzakelijk dat elke toegepaste identiteit uniek is. Doorgaans gebeurt dit door aan iedere gebruiker van een informatievoorziening en aan elk geautomatiseerd proces een unieke gebruikersnaam toe te kennen en hieraan een biologisch kenmerk te koppelen of te beveiligen met een (persoonlijk) wachtwoord dat de gebruiker dan ook geheim moet houden, of een digitaal certificaat. De identiteit wordt niet alleen gebruikt om de toegang te bepalen, maar ook om het gebruik ervan voor latere analyse vast te leggen in een audit-log bestand. 2.2 Uitgangspunten beveiliging persoons- en IAA gegevens De ontwikkelingen die samenhangen met informatie- en communicatietechnologie (ICT) beïnvloeden in steeds sterkere mate de bedrijfsvoering van organisaties in de publieke en private sector. Zo streven al deze organisaties ernaar om persoonsgegevens en bedrijfsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Zonder identificatie, authenticatie en autorisatie mag dan ook geen verwerking of inzage van persoonsgegevens of bedrijfsgegevens plaatsvinden. De eisen voor identificatie, authenticatie en autorisatie kunnen dan ook komen vanuit wettelijke kaders of bedrijfsinterne richtlijnen ter bescherming van de persoonsgegevens of bedrijfsgegevens. Persoonsgegevens De beveiliging van gegevens betreffende identificeerbare personen, persoonsgegevens, is een onderdeel van het recht op privacybescherming. Dit recht is verankerd in internationale verdragen, in Europese wetgeving, in de Grondwet en in nationale Pagina 5 van 16

6 wetgeving. In Nederland vormt de wet bescherming persoonsgegevens (WBP) het algemene kader. Het College Bescherming Persoonsgegevens (CBP) geeft via de handreiking Achtergrond Studies en Verkenningen 23 (AV-23) een methodiek voor het classificeren van persoonsgegevens waarvoor in verschillende toepassingsgebieden passende beveiligingsmaatregelen getroffen moeten worden. Niet geautoriseerde subjecten mogen dan ook - vanuit AV-23 - geen toegang kunnen verkrijgen tot persoonsgegevens binnen de objecten. Het is dus dat de (SUWI) ketenpartijen maatregelen en procedures hebben getroffen en geïmplementeerd om te voorkomen dat onbevoegde personen of processen toegang hebben tot bestanden met persoonsgegevens. Personen of processen krijgen toegang tot bestanden of programmatuur na een positief doorlopen identificatie, authenticatie en autorisatieproces. De identificatie, authenticatie en autorisatie bepalen in feite de effectiviteit van de door ketenpartijen getroffen procedures en geïmplementeerde maatregelen voor het beschermen van de privacygevoelige persoonsgegevens binnen bestanden. AV-23 geeft richtlijnen voor het classificeren van persoonsgegevens en stelt hiermee indirect ook eisen aan authenticatie- en autorisatie bij uitwisseling van deze persoonsgegevens over netwerken. Bedrijfsgegevens Bedrijfsgegevens zijn gegevens over het (verloop van het) bedrijfsproces voorkomend in informatiesystemen. Informatiesystemen en bijbehorende bedrijfsgegevens worden geclassificeerd op basis van hun eigenschappen, het belang van het informatiesysteem voor de keten van werk en inkomen en de frequentie van gebruik. Hiernaast vallen ook de beheer en loggegevens binnen informatiesystemen tot de bedrijfsgegevens welke geclassificeerd en beveiligd moeten worden. Binnen de processen van de ketenpartijen lopen de bedrijfsgegevens en persoonsgegevens vaak door elkaar heen. Voor de beveiliging van de bedrijfsgegevens worden vaak interne richtlijnen dan wel eisen gehanteerd door de ketenpartijen voor authenticatie en autorisatie bij uitwisseling van bedrijfsgegevens over netwerken. 2.3 Eisen beveiliging persoons- en IAA gegevens Uitgangspunt bij het gebruik en de beveiliging van persoons- en IAA gegevens is de vigerende wetgeving en het binnen de keten van werk en inkomen gehanteerde beveiligingsbeleid en Suwinet-Normenkader. Het gebruik en de beveiliging van de persoons- en IAA gegevens dient gebaseerd te worden op het Stelselontwerp-Suwinet, het Suwinet-Normenkader, de Wet Bescherming Persoonsgegevens (WBP), het Voorschrift Informatiebeveiliging Rijksdiensten met betrekking tot Bijzondere Informatie (VIR-BI), en de Handreiking Achtergrond Studies en Verkenningen (AV-23). Hieronder worden de belangrijkste beveiligingseisen uit deze genoemde kaders cursief weergegeven. Binnen de Suwiketen worden voornamelijk persoonsgegevens verwerkt. Het overgrote deel van de set van uitgewisselde gegevens binnen de Suwiketen valt in risicoklasse II (AV-23). Bij gegevensuitwisseling over netwerken mogen de persoonsgegevens niet onbevoegd kunnen worden gelezen (vertrouwelijkheid) en/of gewijzigd (integriteit). Binnen het trusted netwerkdomein van de ketenpartijen mogen persoonsgegevens geclassificeerd als risicoklasse II zonder versleuteling (van de datalijn) uitgewisseld worden. Versleuteling (van de datalijn) heeft echter wel de voorkeur en de Suwipartijen hebben besloten het gehele netwerkverkeer te zullen versleutelen. Pagina 6 van 16

7 Bij gegevensuitwisseling tussen ketenpartijen over de Suwinet-Infrastructuur is versleuteling van de datalijn wel een e voor persoonsgegevens geclassificeerd als risicoklasse II. Bij gegevensuitwisseling tussen ketenpartijen met externe partijen is versleuteling van de datalijn een e voor persoonsgegevens geclassificeerd als risicoklasse II. Het versleutelen van de persoonsgegevens (berichten) zelf bij de gegevensuitwisseling biedt in dit kader dezelfde waarborgen. Een aantal gegevens waaronder de medische gegevens en de gegevens van VIP s in de POLIS administratie van UWV vallen in risicoklasse III (AV-23). Bij gegevensuitwisseling van persoonsgegevens van risicoklasse III zowel binnen het trusted netwerkdomein van de ketenpartijen als over netwerken met externe partijen is minimaal versleuteling van de datalijnen een e. Het versleutelen van de persoonsgegevens (berichten) zelf bij de gegevensuitwisseling biedt in dit kader dezelfde waarborgen. Om te voorkomen dat persoonsgegevens onbevoegd kunnen worden gelezen (vertrouwelijkheid) en/of gewijzigd (integriteit) moeten niet alleen de persoonsgegevens zelf worden beveiligd maar ook die gegevens die de toegang tot persoonsgegevens verschaffen, te weten IAA gegevens. IAA gegevens moeten worden beveiligd om de vertrouwelijkheid en integriteit van persoonsgegevens en bedrijfsgegevens te kunnen waarborgen. AV-23 is een handreiking en in principe niet verplicht. Binnen de Suwiketen is het echter wel verplicht doordat Bijlage XIV bij de ministeriele Regeling SUWI mede op basis van AV23 is opgesteld. In AV-23 wordt onder meer dat bij datacommunicatie zowel de zender als de ontvanger van persoonsgegevens zich moeten verzekeren van elkaars identiteit en dat de authenticatie en autorisatiegegevens niet door onbevoegden kunnen worden onderschept of misbruikt. Dit leidt impliciet tot de eis dat deze gegevens versleuteld uitgewisseld moeten worden. IAA gegevens mogen niet onbevoegd kunnen worden gelezen (vertrouwelijkheid) en/of gewijzigd (integriteit). De mate waarin persoonsgegevens moeten zijn beveiligd is afhankelijk van de gevoeligheid van de betrokken gegevens. Vandaar dat gebruik wordt gemaakt van een indeling in risicoklassen. Het is daarom logisch te veronderstellen dat ook IAA gegevens zelf moeten worden ingedeeld in risicoklassen. IAA gegevens moeten worden geclassificeerd gebaseerd op de gevoeligheid van de persoonsgegevens of bedrijfsgegevens waarvoor ze de toegang regelen. Identificatie, authenticatie & autorisatie vindt plaats zowel binnen de keten van werk en inkomen als tussen de keten van werk en inkomen en de externe omgeving. Hierbij is mogelijk sprake van verschillen in de classificering in risicoklassen van deze gegevens. Bij verschillen in risicoklassen wordt de hoogste risicoklasse gehanteerd. Het gebruik en de beveiliging van IAA gegevens is mogelijk verschillend binnen en buiten de keten van werk en inkomen. Bij verschillen in de classificering moet de hoogste risicoklasse gehanteerd worden. Pagina 7 van 16

8 3. Classificering persoons- en IAA gegevens 3.1 Classificering persoons- en IAA gegevens Eerst wordt hieronder een toelichting gegeven van de classificering van persoonsgegevens en bedrijfsgegevens en op basis hiervan wordt vervolgens een classificering vastgesteld van IAA gegevens. Persoonsgegevens Classificering is noodzakelijk om vast te kunnen stellen wanneer welke beveiligingseisen gelden voor bepaalde persoonsgegevens. In AV-23 worden vier risicoklassen gehanteerd: Risicoklasse 0 Risicoklasse 1 Risicoklasse 2 Risicoklasse 3 publiek niveau basis niveau verhoogd risico hoog risico Binnen eerdere onderzoeken is vastgesteld dat in de keten van werk en inkomen persoonsgegevens en bedrijfsgegevens worden verwerkt van risicoklasse 2 en hoger. De in deze richtlijn beschreven eisen en maatregelen hebben dan ook betrekking op de beveiliging en verwerking van persoonsgegevens en bedrijfsgegevens van risicoklasse 2 en hoger. AV-23 geeft de volgende voorbeelden van persoonsgegevens in deze klassen 1 : Risicoklasse 2: gegevens over de persoonlijke economische situatie, kredietinformatie, schuldsaneringsinformatie; risicoklasse 3: opsporingsinformatie, DNA-databankgegevens, informatie waarop geheimhoudingsplicht rust (e.g. medische informatie). IAA gegevens Bij het vaststellen van eisen met betrekking tot het gebruik en de beveiliging van IAA gegevens wordt uitgegaan van de hierboven beschreven classificering van AV- 23. Op grond van een korte analyse wordt hieronder de risicoklasse van IAA gegevens bepaald. Identiteit en Authenticatiegegevens Wanneer de vertrouwelijkheid en/of integriteit van identiteit en authenticatiegegevens (bijvoorbeeld wachtwoorden of encryptiesleutels) wordt geschaad zijn alle onderliggende persoonsgegevens toegankelijk. Op grond hiervan moet worden geconcludeerd dat identiteit en authenticatiegegevens altijd moeten worden geclassificeerd als risicoklasse 3 (hoog risico). Autorisatiegegevens Wanneer de vertrouwelijkheid en integriteit van autorisatiegegevens kan worden geschaad, kan een geauthenticeerd systeem, applicatie of persoon mogelijk toegang krijgen tot persoonsgegevens waarvoor geen autorisatie is uitgegeven. Dit wordt ook wel elevation of rights genoemd. Op grond hiervan moet worden geconcludeerd dat de vertrouwelijkheid en integriteit van autorisatiegegevens moet worden geclassificeerd als risicoklasse 3 (hoog risico). 3.2 Beveiliging van persoons- en IAA gegevens AV-23 maakt onderscheid tussen communicatie via netwerken die volledig onder toezicht van de verantwoordelijke vallen en netwerken die geheel of gedeeltelijk als 1 AV-23, par 3.3, pag 28. Pagina 8 van 16

9 publiek netwerk kunnen worden aangemerkt. Afhankelijk van de risicoklasse worden voor communicatie over publieke netwerken zwaardere eisen gesteld. In AV-23 wordt alleen onderscheid gemaakt tussen interne en externe (publieke) netwerken wanneer het gaat om de communicatie van persoonsgegevens. Bij IAA gegevens wordt dit onderscheid niet gemaakt. Ongeacht de locatie moeten volgens AV-23 IAA gegevens altijd zijn beveiligd tegen onbevoegd lezen en/of wijzigen. Als we uitgaan van het feit dat het netwerkdomein van de ketenpartijen (i.e. netwerk, systemen en applicaties) alleen toegankelijk is voor geautoriseerde personen (trusted netwerk) en dat hun rekencentra alleen toegankelijk zijn voor geautoriseerde personen dan kan de volgende tabel worden opgesteld. Afhankelijk van de risicoklasse (RK) en de locatie van de gegevens dienen maatregelen te zijn genomen die onbevoegde inzage (Vertrouwelijkheid) en/of wijziging (Integriteit) tegengaan van persoons- en IAA gegevens bij datacommunicatie. Av-23 spreekt over de beveiliging van persoonsgegevens tegen onbevoegd lezen en/of muteren. Impliciet leiden deze beveiligingseisen tot versleuteling van de persoons- en IAA gegevens. Beveiliging tegen onbevoegd lezen (V) en/of wijzigen (I) Persoonsgegevens over datalijnen IAA gegevens over datalijnen RK2 V+I RK3 V+I RK3 V+I Binnen één rekencentrum Nee Nee Ja Binnen het trusted netwerkdomein van Nee Ja Ja één Suwinet partij (tussen verschillende rekencentra) Binnen het trusted domein tussen Suwinet Ja Ja Ja partijen (Suwinet) Suwinet partij(en) met externe partijen (DKD) Ja Ja Ja Beveiligingsmaatregelen Binnen en buiten de keten van werk en inkomen dienen IAA gegevens niet te kunnen worden gelezen en/of gewijzigd door onbevoegden. De te nemen maatregelen zijn met name afhankelijk van de kans dat de vertrouwelijkheid en integriteit van gegevens kunnen worden geschaad. Onbevoegd lezen van gegevens tijdens transport over het interne netwerk is tamelijk eenvoudig te realiseren omdat het aansluiten van een sniffer op het fysieke netwerk van een ketenpartner niet is te voorkomen. Het afluisteren van het externe netwerk is eveneens praktisch realiseerbaar. Hierdoor is de kans van optreden hoog zodat sterke maatregelen nodig zijn om de vertrouwelijkheid van gegevens tijdens transport te kunnen waarborgen. Onbevoegd wijzigen van gegevens tijdens transport over het interne en externe netwerk is tamelijk lastig te realiseren omdat hiervoor moet worden ingegrepen in lopende sessies (man in the middle). Hierdoor is de kans van optreden midden tot laag waardoor standaard maatregelen nodig zijn om de integriteit van gegevens tijdens transport te kunnen waarborgen. Onbevoegd lezen en wijzigen van gegevens tijdens verwerking of opslag door systemen, applicaties en personen is tamelijk lastig te realiseren omdat hiervoor fysieke of logische toegang nodig is tot systeemcomponenten (servers, databases etc). De kans van optreden is laag waardoor standaard maatregelen nodig zijn om de ver- Pagina 9 van 16

10 trouwelijkheid en integriteit van gegevens tijdens verwerking en opslag te kunnen waarborgen. Op grond hiervan kunnen de volgende maatregelen worden vastgesteld. Er zijn sterke maatregelen nodig om identiteit en authenticatiegegevens (user-id, wachtwoorden, encryptiesleutels, e.d.) tijdens transport te beveiligen tegen onbevoegd lezen. Hierbij moet worden gedacht aan bijvoorbeeld encryptie op basis van een sterk algoritme en sterke sleutels. Dit geldt zowel voor het interne netwerk als externe netwerk. Er zijn standaard maatregelen nodig om autorisatiegegevens (e.g. rolbeschrijvingen) tijdens transport te beveiligen tegen onbevoegd wijzigen. Hierbij moet worden gedacht aan het gebruik van standaard beschikbare autorisatiemechanismen die besturingssystemen bieden, of aan het verbieden van het koppelen van ongeoorloofde apparatuur aan de Suwinet-Infrastructuur. Er zijn standaard maatregelen nodig om IAA gegevens tijdens verwerking en opslag te beveiligen tegen onbevoegd lezen en wijzigen. Hierbij moet worden gedacht aan het gebruik van standaard beschikbare, authenticatie- en autorisatiemechanismen die besturingssystemen bieden, aan functiescheiding en dergelijke. Beveiligingsmaatregelen voor IAA gegevens bij datacommunicatie kan op twee manieren worden ingevuld namelijk via: beveiligde sessies binnen de uit te wisselen berichten zelf (beveiligde berichten) Een beveiligde sessie resulteert in een point-to-point beveiliging en beveiligde berichten resulteren in een (veiligere) end-to-end beveiliging. Beveiligde sessie; zendende en ontvangende objecten, zoals host-systemen of (web)services kunnen zich wederzijds (laten) identificeren, authenticeren en autoriseren zodat een beveiligd communicatiekanaal ontstaat op netwerk- of (web)servicesniveau. Dit is toepasbaar voor systemen of (web)services die direct en/of binnen het domein van de keten van werk en inkomen met elkaar communiceren en is hierdoor point-to-point. Beveiligde berichten; zendende en ontvangende subjecten zoals applicaties of eindgebruikers kunnen zich wederzijds (laten) identificeren, authenticeren en autoriseren zodat de authenticiteit van individuele berichten kan worden vastgesteld. Dit is toepasbaar voor applicaties en/of gebruikers die communiceren over meerdere tiers of in verschillende domeinen en is hierdoor end-to-end. Pagina 10 van 16

11 4. Digitale certificaten 4.1 Unieke identiteit middels digitaal certificaat Identificatie is het kenbaar maken van de identiteit van een subject (een gebruiker of een proces) in de informatietechnologie. De identiteit wordt gebruikt om de toegang van het subject tot een object te beheersen. Een object is bijvoorbeeld een computerbestand of een record in een database. Om de identiteit op een zinvolle manier te gebruiken, is het noodzakelijk dat elke toegepaste identiteit uniek is. Doorgaans gebeurt dat door aan iedere gebruiker van de informatievoorziening een unieke gebruikersnaam toe te kennen en aan deze identiteit een biologisch kenmerk te koppelen of te beveiligen met een wachtwoord (dat de gebruiker geheim moet houden) of een digitaal certificaat in het geval een proces, applicatie of webservice geauthenticeerd moet worden. Een digitaal certificaat is te vergelijken met een digitale identiteitskaart, waarop een beperkt aantal gegevens voorkomen met betrekking tot de houder van het certificaat (de identiteit van de houder, de publieke sleutel die verbonden is met de houder van het certificaat, de geldigheidsduur van het certificaat, de klasse van het certificaat). Een digitaal certificaat wordt uitgereikt door een Certificatie Autoriteit, die als een onafhankelijke partij optreedt. De twee partijen die een digitaal certificaat gebruiken moeten voldoende vertrouwen hebben in deze Certificatie Autoriteit en in de procedures die gevolgd worden om de identiteit van de gebruiker van het certificaat te garanderen. Een Digitaal Certificaat kan elektronisch worden voorgelegd om de identiteit te verifieren. Per soort toepassing kunnen andere type digitale certificaten worden gehanteerd al dan niet weer beveiligd met toegangscodes of wachtwoorden. Digitale Certificaten bieden VERTROUWEN en VEILIGHEID bij communicatie over netwerken. 4.2 Interne en externe certificaten Binnen de keten van werk en inkomen wil men gebruik gaan maken van digitale certificaten met als doel de vertrouwelijkheid, integriteit en authenticiteit van gegevens en berichten te kunnen waarborgen. Tevens kunnen certificaten gebruikt worden voor het vaststellen van de authenticiteit van systemen. Door inzet van SLL met digitale certificaten kunnen zendende en ontvangende subjecten, zoals systemen of webservices zich wederzijds (laten) authenticeren, waarbij ook een beveiligd communicatiekanaal ontstaat op netwerk- of webservices niveau. Dit is toepasbaar voor systemen of webservices die direct en/of binnen de keten van werk en inkomen met elkaar communiceren en is hierdoor een point-to-point beveiliging. Certificaten die worden gebruikt binnen en buiten de Suwiketen moeten zijn gebaseerd op (i.e. ondertekend door) een root Certificatie Autoriteit (CA). Suwinet partijen kunnen de keuze maken om gebruik te maken van een eigen rootcertificaat of van een publiek rootcertificaat (bijvoorbeeld Verisign). Het voordeel van een eigen rootcertificaat is dat in dit geval de kosten voor het produceren van certificaten relatief laag zijn. Dit is vooral interessant wanneer een groot aantal systemen binnen het domein van een Suwinet partij moeten worden voorzien van een SSL / IPSec certificaat. Voorwaarde hierbij is wel dat certificaten dan alleen intern worden gebruikt. Pagina 11 van 16

12 Wanneer certificaten buiten het netwerkdomein van een Suwinet partij moeten worden gebruikt zoals bijvoorbeeld het geval is bij het opzetten van SSL sessies met andere Suwinet partijen en voor certificaten waaraan hoge betrouwbaarheidseisen worden gesteld is gebruik van een eigen rootcertificaat minder realistisch. In dit geval kan beter worden gekozen voor een publiek beschikbaar rootcertificaat zoals Verisign dat wordt gegenereerd door een hierin gespecialiseerde organisatie. Pagina 12 van 16

13 5. Oplossingen 5.1 Beschrijving oplossingen binnen de trusted netwerkdomeinen van de Suwinet partijen Oplossingen binnen de trusted netwerk domeinen van de Suwinet partijen Beveiligde sessies Active Directory met Kerberos / IPsec Binnen de trusted netwerkdomeinen van de Suwinet partijen wordt bij voorkeur gebruik gemaakt van identificatie, authenticatie & autorisatie op basis van Active Directory met Kerberos. Doordat een koppeling mogelijk is met Active Directory kan Kerberos zowel de authenticatie als autorisatie ondersteunen. Authenticatie en autorisatiegegevens zijn door Kerberos beveiligd tegen onbevoegd lezen en wijzigen. Kerberos kan worden gecombineerd met IPSec waardoor tevens een beveiliging wordt gerealiseerd tegen onbevoegd lezen en wijzigen van persoonsgegevens (lees berichten) tijdens transport. IPSec Het is mogelijk IPSec toe te passen zonder gebruik te maken van het authenticatiemechanisme van Kerberos. Systemen authenticeren elkaar dan wederzijds op basis van een certificaat of shared key. Autorisatie volgt in dit geval impliciet na succesvolle authenticatie. IPSec beveiligt alle gegevens die worden verstuurd, dus zowel persoonsgegevens als eventuele (aanvullende) authenticatie- en autorisatiegegevens die in berichten zouden kunnen zijn opgenomen. SSL Wanneer het gebruik van Kerberos niet mogelijk is, bijvoorbeeld doordat een systeem geen Kerberos ondersteunt of omdat authenticatie moet plaatsvinden tussen twee rekencentra of over de domeingrens heen van een Suwinet partij is SSL/TLS een alternatief. SSL/TLS biedt alleen mogelijkheden voor (wederzijdse) authenticatie op basis van certificaten. Autorisatie wordt door SSL/TLS niet ondersteund. Ook hier volgt autorisatie impliciet na succesvolle authenticatie. SSL/TLS biedt point-to-point authenticatie. SSL/TLS beveiligt alle gegevens die binnen de sessie worden verstuurd, dus zowel persoonsgegevens als eventuele (aanvullende) authenticatie- en autorisatiegegevens die in berichten zouden kunnen zijn opgenomen. Het is van belang op te merken dat wanneer in backoffice-systemen veel SSL sessies moeten worden opgebouwd en afgebroken een negatieve invloed op performance kan ontstaan. Infomessaging Het Infomessaging protocol voorziet in een eigen authenticatie en autorisatiemechanisme. Dit mechanisme maakt gebruik van de onderliggende authenticatiefunctionaliteit van besturingssystemen en verstuurt autorisatiegegevens in het Infomessaging protocolbericht. Hierdoor zijn autorisatiegegevens tijdens transport af te luisteren (tenzij gebruik wordt gemaakt van onderliggende transportbeveiliging op basis van IPSec of SSL/TLS). Authenticatiegegevens worden gebruikt en beveiligd door het onderliggende besturingssysteem dit kan bijvoorbeeld Kerberos zijn. WS-Security Webservices is een op XML-gebaseerde technologie die een Service Oriented Architecture (SOA) mogelijk maakt. Het idee achter SOA is dat het voor organisaties mo- Pagina 13 van 16

14 gelijk moet zijn om op een eenvoudige en flexibele manier diensten en producten van derden af te nemen op een open netwerk. Webservice technologie maakt het makkelijker om data en business processen aan de buitenwereld beschikbaar te stellen. Zo kunnen in een ketenproces webservices worden ingezet waarbij ketenpartijen berichtelementen mogen lezen of ook muteren. Bij inzet van webservices binnen ketens moet invulling worden gegeven aan het doelbindingsprincipe en proportionaliteit. Dit leidt vooralsnog tot de eis dat niet alle ketenpartijen geautoriseerd zijn voor alle berichtelementen. Een ketenbericht kan bijvoorbeeld 300 gegevenselementen bevatten. Ketenpartijen mogen alleen de berichtelementen kunnen lezen of muteren waartoe ze geautoriseerd zijn. In een ketenproces met verschillende ketenpartijen vraagt de inzet van webservices dan ook om beveiliging van de afzonderlijke berichtelementen. Deze behoefte leidt tot de eis van end-to-end beveiliging (van zender naar ontvanger). SSL biedt point-to-point beveiliging en is dus niet altijd toereikend in de ketentoepassingen. Het eindpunt van beveiliging hoeft niet het eindpunt van het ketenproces met inzet van webservices te zijn. Bovendien focussen vrijwel alle authenticatie- en autorisatieprotocollen in de markt zich sterk op mens-machine interactie. In de webservices wereld is er veel meer machine-machine interactie. Dit stelt andere eisen aan hoe vertrouwensrelaties tussen Webservices worden vastgesteld en opgezet. Hiernaast vraagt het gemis van waarborgen voor vertrouwelijkheid en integriteit van berichtelementen na passage van de point-to-point beveiligingspunten om andere oplossingen dan SSL. W3C en OASIS zijn twee verschillende onafhankelijke standaardisatieconsortiums die werkgroepen hebben opgericht om in te spelen op boven genoemde behoefte en de standaardisatie van nieuwe Webservices Security protocollen te stroomlijnen. Een van de belangrijkste initiatieven is door Microsoft, IBM en Verisign geïntroduceerd namelijk: WS-Security. Het eigenaarschap van dit protocol is overgedragen aan de OASIS Security Joint Werkgroep. Het eerste belangrijke initiatief van OASIS is Security Assertions Markup Language (SAML). Dit is een op XML-gebaseerde modulair raamwerk dat Webservices in staat stelt om security gerelateerde gegevens uit te wisselen. De vertrouwelijkheid en integriteit van SAML assertions kunnen worden gegarandeerd door gebruik te maken van de basisbouwblokken XML Encryption en XML Signature. XML Signature biedt de mogelijkheid om over delen van een bericht verschillende handtekeningen te plaatsen met als doel de integriteit te waarborgen. Een groot voordeel hiervan is dat de authenticiteit van berichten wordt gegarandeerd tot aan de eindgebruiker, zelfs als berichten over meerdere servers binnen verschillende domeinen worden verstuurd. Hiermee wordt end-to-end beveiliging gerealiseerd. Of de afzender van een bericht is geautoriseerd een bericht te versturen of de ontvanger is geautoriseerd dit bericht te ontvangen moet elders worden opgelost. XML Signature biedt op zichzelf geen functionaliteit voor autorisatie. Een nadeel van het gebruik van XML Signature is dat deze functionaliteit moet worden ingebouwd in applicaties. Helaas moeten we vaststellen dat WS-Security momenteel nog een bewegend doel is. De meeste initiatieven zijn nog volop in ontwikkeling en fabrikanten en diverse consortiums werken hard aan standaardisatie. Op dit moment ontbreekt het dan ook nog aan robuuste interoperabele implementaties van de verschillende protocollen in producten. Vooralsnog wordt inzet van WS-Security binnen de keten van werk en inkomen niet aanbevolen. De ontwikkelingen rondom WS-Security zal echter nauw gevolgd moeten worden en bij het robuuster en interoperabeler worden van de WS- Security oplossing zal inzet heroverwogen moeten worden. Pagina 14 van 16

15 5.2 Beschrijving oplossingen voor gegevensuitwisseling met externe partijen Binnen het OSI model bevindt zich onder de applicatielaag de transportlaag. De transportlaag verzorgt de uitwisseling van berichten. Ook in de transportlaag bestaan diverse mogelijkheden om informatie te beschermen. Het voordeel van het treffen van maatregelen in de transportlaag is dat de bovenliggende applicatie niet aangepast hoeft te worden. In het algemeen is het voldoende om alleen de configuratie van het platform aan te passen. Dit verklaart de voorkeur om bij externe verbindingen gebruik te maken van SSL/TLS met inzet van externe certificaten. Een ander voordeel van SSL/TLS is dat, naast de geboden functionaliteit voor authenticatie de persoonsgegevens (lees; berichten) tijdens transport zijn beveiligd tegen onbevoegd lezen en wijzigen (vertrouwelijkheid en integriteit). Voor gegevensuitwisseling met externe partijen is het op dit moment nog niet mogelijk gebruik te maken van de Active Directory (met Kerberos). Het gebruik van IPSec is over externe netwerken alleen mogelijk wanneer hiervoor extra technische voorzieningen zouden worden getroffen. Voor het gebruik van digitale handtekeningen in beveiligde berichten geldt hetzelfde als bij paragraaf Conclusie oplossingen Gegeven de uitgangspunten en eisen dat er zekerheid moet zijn over de identiteit van de zender en ontvanger van data en dat de IAA gegevens bij datacommunicatie beveiligd moeten worden tegen onbevoegd lezen en muteren, leidt dit impliciet tot de eis van versleuteling van de IAA gegevens. Versleutelde uitwisseling van de IAA gegevens kan plaatsvinden via versleutelde sessies of in versleutelde berichtelementen zoals WS-Security het mogelijk maakt. Hiernaast moet versleuteling van de persoonsgegevens (berichten) zelf of de datalijnen plaatsvinden afhankelijk van de classificatie van de persoonsgegevens en de gegevensuitwisseling binnen of buiten het netwerkdomein van de Suwinet partijen. Hieronder volgt nog een afweging van de beschikbare oplossingen binnen en buiten het netwerkdomein van een Suwinet partij voor invulling van bovenstaande beveiligingeisen met betrekking tot persoons- en IAA gegevens. De wijze waarop het gebruik en de beveiliging van IAA gegevens wordt geïmplementeerd hangt af van verschillende factoren. In de praktijk zal dit zich beperken tot de inzet van Active Directory (AD) met Kerberos waarbij de IAA gegevens versleuteld uitgewisseld worden of in de toepassing van SLL met certificaten binnen en buiten het netwerkdomein van de Suwinet partijen waarbij de IAA gegevens meeliften binnen de versleutelde sessie uitwisseling. Een bijkomstig voordeel van SSL implementaties met certificaten is dat het transportkanaal wordt versleuteld waarmee ook invulling wordt gegeven aan de eis van beveiliging van persoonsgegevens tegen onbevoegd lezen en muteren tijdens transport. Ook kan de combinatie Active Directory met IPsec ingezet worden. Active Directory met Kerberos vult dan de beveiligingseis in voor het versleuteld uitwisselen van de IAA gegevens en IPsec draagt zorg voor de e versleuteling van de datalijnen. Er moet altijd invulling worden gegeven aan de eis van het vaststellen van de identiteit van de zender en ontvanger en het versleuteld uitwisselen van de IAA gegevens. Indien alleen IPsec wordt ingezet voor het beveiligen van het transportkanaal waarover meerdere zenders en ontvangers communiceren, kan geen invulling worden gegeven aan de beveiligingseisen voor IAA. Er zijn immers meerdere zenders en ont- Pagina 15 van 16

16 vangers voorbij het beveiligde eindpunt. In dit geval geeft IPsec alleen invulling aan de eis van het versleutelen van het transportkanaal. Als we kijken naar WS-Security dan moeten we concluderen dat dit nog een bewegend doel is. Op dit moment ontbreekt het nog aan robuuste interoperabele implementaties van de verschillende protocollen in producten. Vooralsnog wordt inzet van WS-Security binnen de keten van werk en inkomen dan ook nog niet aanbevolen. De ontwikkelingen rondom WS-Security zal echter nauw gevolgd moeten worden en bij het robuuster en interoperabeler worden van de WS-Security oplossing zal inzet heroverwogen moeten worden. In de volgende tabel zijn de wettelijke eisen vertaald naar een praktische invulling. Beveiliging tegen onbevoegd lezen (V) en/of wijzigen (I) Binnen één rekencentrum Binnen het trusted netwerkdomein van één Suwinet partij (tussen verschillende rekencentra) Binnen het trusted domein tussen Suwinet partijen (Suwinet) Suwinet partij(en) met externe partijen (DKD) RK I-C E-C risicoklasse Interne certificaten Externe certificaten Uitwisseling Persoonsgegevens RK2 RK3 RK3 V+I V+I V+I Nee Nee Ja Versleuteling transportkanaal niet Versleuteling transportkanaal niet Nee Ja Ja Versleuteling transportkanaal Versleuteling transportkanaal niet maar heeft wel de voorkeur Oplossingen SSL met inzet I-C -SSL met inzet I-C Ipsec -Ipsec Ja Ja Ja Versleuteling transportkanaal Oplossingen SSL met inzet E-C Ipsec Versleuteling transportkanaal Oplossingen -SSL met inzet E-C -Ipsec Ja Ja Ja Versleuteling Versleuteling transportkanaal transportkanaal SSL met inzet E-C Oplossingen -SSL met inzet E-C Uitwisseling IAA gegevens Versleuteling IAA gegevens Oplossingen -Actieve Directory -SSL met I-C Versleuteling IAA gegevens Oplossingen -Actieve Directory -SSL met I-C Versleuteling IAA gegevens Oplossingen -Actieve Directory -SSL met I-C Versleuteling IAA gegevens Oplossingen -Actieve Directory -SSL met E-C Binnen één rekencentrum kan er van worden uitgegaan dat onbevoegde personen geen toegang hebben tot de zich in het rekencentrum bevindende objecten. Bij koppelingen tussen objecten binnen het rekencentrum kan dus worden volstaan met versleuteling van de IAA gegevens. De versleuteling van de persoonsgegevens (berichten) zelf of de versleuteling van de datalijnen is niet aan de orde. Pagina 16 van 16