Page Comparison

5.1.2.1. Identificatie als maatregel

5.1.2.1.1. Verwachtingen rond de kenmerken van de identificatiemaatregelen

Identificatieprocessen kunnen we opsplitsen in zwakke versus sterke identificatie. Beide hebben implicaties rond vertrouwelijkheid en integriteit.

Zwakke identificatie

Zwakke identificatie: Validatie van de identiteit van een fysiek persoon op basis van een identiteitsattribuut dat niet onder controle valt van een door de overheid geregistreerde of gecertifieerde bron:

• De gebruikte identiteit attributen komen voor het identificatie- of registratieproces van een al dan niet commerciële organisatie.

• De identiteit is niet geverifieerd via een door de Belgische federale overheid erkende procedure.

• De verificatieprocedure biedt minimale waarborg.

Opmerking: De Vlaamse overheid beschouwt elke bron als commercieel, ook als de gerelateerde dienst ‘gratis’ wordt aangeboden. 

• Identificatie gebeurt op basis van (Niet-gelimiteerde voorbeelden)

  • Een e-mailadres

  • Een telefoonnummer

  • Een (roep)naam

Bv: Sociale media, online winkelplatform, intekenen nieuwsbrief, ...

Opmerking: Hoewel er bij zwakke identificatie minder zekerheid is over de exacte identiteit van de gebruiker dan bij een sterke identificatie, spreken we hier wel degelijk over persoonsgegevens. Zwakke identificatie impliceert niet dat er minder controles nodig zijn om de vertrouwelijkheid en integriteit van deze persoonsgegevens te verzekeren. 

Sterke identificatie

Sterke identificatie: Identificatie op basis van een door de Belgische federale overheid geregistreerde of gecertifieerde bron (Identity provider).
De Vlaamse overheid gebruikt als Identity provider het identificatieproces van de Belgische federale overheid. Dit geeft aan dat (vandaag) enkel de Federale overheid een sterke validatie van een identiteit kan uitvoeren om te voldoen aan de kenmerken van een sterke identificatie.

De unieke identificatie labels van een identiteit (Fysiek persoon) zijn:

• Rijksregisternummer (Ook gekend als RRN)

• Rijksregister-BIS nummer (Ook gekend als BIS-Nummer) 

Opmerking: Binnen de Vlaamse overheid gebeurt de registratie van identiteiten voor fysieke personen, binnen onze access managementprocessen, steeds op basis van het RRN of BIS-Nummer.

Beperkingen voor buitenlandse identiteiten in gebruik bij de Vlaamse overheid Volgende situatie is van toepassing op alle individuen met een identiteit die de federale overheid erkent.

• De uitwisselbaarheid van identiteiten van buitenlandse individuen, ook binnen de EU is opgevangen door de registratie van het individu in het RijksRegister-BIS

• Dit bisnummer wordt overgenomen als unieke bron voor een identiteit binnen de Vlaamse overheid

Naar de toekomst toe zullen alle EU identity providers de mogelijkheid bieden om identiteiten én de validatie ervan onderling uit te wisselen. Deze integratie zal worden gerealiseerd door de Belgische federale overheid in Europese context (zie bronnen).

Erkende afgeleide bronnen voor sterke identificatie

Een aantal erkende afgeleide bronnen worden gebruikt binnen:

De Belgische federale overheid

• INSZ: Identificatienummer van de sociale zekerheid, gedefinieerd door het sectoraal comité van de sociale zekerheid.

• ItsMe® identificatie validatie

ItsMe® De veiligheid van het ItsMe®-platform en bijhorende toepassing werd beoordeeld op basis van een controle raamwerk welke FOD BOSA in het leven heeft geroepen, voor de evaluatie van identificatiemiddelen onder het Koninklijk besluit van 08/11/2017 tot
vaststelling van de voorwaarden, de procedure en de gevolgen van de erkenning van diensten voor elektronische identificatie voor overheidstoepassingen. Zie link naar de publicatie in het staatsblad.

De Vlaamse overheid

...

5.1.2.1. Account en account lifecycle

Accounts zijn toegangsmiddelen die gebruikers in staat stellen om toegang te krijgen tot systemen en diensten. Er zijn verschillende soorten accounts, afhankelijk van de rollen en privileges van de gebruikers.

5.1.2.1.1. Categorieën en types accounts

Elk van de onderstaande account categorieën en types zijn volledige gedocumenteerd in:

• Policy documenten (vb. gebruiks- en paswoord policies)

• Gebruikers documentatie

Account categorieën

• Gebruikersaccount(s) zijn accounts die gebruikt worden voor reguliere eindgebruikerstoegangen voor informatieverwerking tot en met [Klasse 4].
  Deze accounts zijn direct gerelateerd aan individuele gebruikers en zijn cruciaal voor de dagelijkse bedrijfsvoering.

• Geprivilegieerd(e) account(s) zijn accounts die de gebruiker (van het account) de mogelijkheid geeft om

• Informatie van [Klasse 5] (minimaal) in te kijken

• De beschikbaarheid en/of gedrag van de gegevensverwerking te beïnvloeden.

Deze accounts vereisen strikte beveiligingsmaatregelen en toezicht vanwege het risico op (zware) impact ingeval van misbruik.
Om misbruik van geprivilegieerde accounts te voorkomen, is het ook belangrijk om de taken goed te scheiden. Dit betekent dat niet één persoon volledige controle heeft over het toekennen, gebruiken en beheren van deze accounts. Daarnaast moeten de toegangsrechten die aan deze accounts worden toegekend ook voldoen aan de principes van functiescheiding, zodat geen enkele gebruiker te veel macht of toegang krijgt.

Account types

• Persoonlijk(e) account(s) zijn accounts met een rechtstreekse relatie tot één individu en omvatten

  • Reguliere gebruikersaccounts: voor alledaagse taken door individuele gebruikers binnen hun functieveriesten. Ingeval systeemonderhoud of andere kritische taken deel uitmaken van de dagelijks taken van deze gebruiker, dient hiervoor een apart gepriviligieerd gebruikersaccount aangemaakt te worden. Dergelijke toegangen mogen nooit aan een regulier gebruikersaccount toegekend worden.

  • Gepriviligieerde gebruikersaccounts (technische accounts/beheersaccounts): voor individuele gebruikers die administratieve toegang nodig hebben voor systeemonderhoud of kritische taken.

• Gedeeld(e) account(s) zijn accounts die door meerdere individuen kunnen worden gebruikt, maar deze zijn altijd gekoppeld aan (een) individu(en) via een specifieke rol, bv:

• Toepassingsbeheerder: verantwoordelijk voor het beheren en onderhouden van de toepassing waartoe het gedeelde account behoort.

• Toepassingsaccount(s) zijn accounts die gebruikt worden voor authenticatie tussen toepassingen onderling. Deze accounts zijn altijd gekoppeld aan een individuele beheerder, gewoonlijk een toepassingsbeheerder.

  • Deze accounts faciliteren communicatie en data-uitwisseling tussen systemen en zijn essentieel voor de operationele integriteit van applicaties.

• Systeemaccount(s) zijn accounts die deel uitmaken van de standaardinstallatie van het systeem en hebben specifieke functies voor het beheren van systeembronnen en het uitvoeren van processen die cruciaal zijn voor het functioneren van het besturingssysteem en geïnstalleerde applicaties.
  Deze accounts zijn ook gekend als built-in account(s)

5.1.2.1.2. Account status

Een account is actief wanneer het technisch de mogelijkheid biedt om gebruikt te worden als authenticatiemiddel. De criteria om een actief account te beschouwen zijn afhankelijk van de vorm waarin het account werd aangeleverd.

Een account is inactief wanneer het op basis van de criteria uitgesloten werd als actief account. Een account kan bvb tijdelijk geblokkeerd (disabled) of slechts gebruikt tijdens bepaalde uren (bvb kantooruren).

5.1.2.1.

...

De gegevens die we in het identificatieproces gebruiken, zijn persoonsgegevens en hebben altijd een bepaalde graad van vertrouwelijkheid, integriteit en beschikbaarheid, ongeacht of we zwakke of sterke identificatie gebruiken. Dit moet ervoor zorgen dat tijdens het identificatieproces er voldoende controles in gebruik zijn om beide kwaliteitskenmerken te borgen. Concreet betekent dat deze gegevens volgende klasse toebedeeld krijgen:

• Informatieklasse 3 voor Vertrouwelijkheid 

• Informatieklasse 4 voor Integriteit

• De informatieklasse voor Beschikbaarheid is gealigneerd met de classificatie van de toepassing waarvoor de identificatie dient. De maatregelen die je inricht moeten deze beschikbaarheid kunnen garanderen.

5.1.2.1.3. Integriteit van het identificatieproces

Toegangsniveaus binnen toepassingen, of infrastructuur

Bij het registreren van de identiteit van een gebruiker, houdt de beheerder rekening met de mogelijkheid dat de gebruiker normale gegevens (normale gebruiker) of zelfs systeemeigenschappen (beheerder) zal kunnen passen. Het gaat dus verder dan de vraag tot welke gegevens de gebruiker toegang zal hebben.

Je moet hiermee logica rekening houden in de opzet en toekenning van de rollen binnen de toepassing en haar beheer. Hierbij is het van belang dat de toegang die in de rollen vervat zit, altijd tweedelig is: de vertrouwelijkheids- en integriteitseisen gaan bepalen wie waartoe toegang zal kunnen krijgen.

Relatie van de kwaliteitskenmerken met zwakke, resp. sterke identificatie

Hoe hoger de informatieklasse, hoe hoger de nood tot een sterke identificatie. Dit geldt voor alle drie kwaliteitskenmerken:

• Hoe groter de impact van informatie die (onvrijwillig) publiek vrijkomt, hoe zekerder we moeten zijn dat enkel de meest noodzakelijke personen toegang hebben tot die informatie;

• Hoe groter de impact van foutieve informatie kan zijn, hoe zekerder we moeten zijn dat enkel de gemachtigde gebruikers ze kunnen wijzigen;

• Hoe groter de impact van de onbeschikbaarheid van een toepassing of proces, hoe zekerder we moeten zijn van een correcte toegangsverlening.

De exacte requirements hiervoor staan opgelijst in het Overzicht en integratie van de maatregelen. 

5.1.2.1.4. Integriteit van de gegevens betrokken in het identificatieproces

Beveiliging van de uitgewisselde data

Tijdens het identificatieproces, wisselen systemen heel wat data uit. Hierbij ook persoonsgegevens van de persoon die ze identificeren. Hierbij hou je ook rekening met de informatieklasse wat betreft integriteit. De controles die je hierbij zeker moet implementeren, staan beschreven in 1. Informatieclassificatieraamwerk (ICR) . 

Dit geldt heel specifiek ook voor gegevens die systemen uitwisselen om een persoon te identificeren. Dit is informatie van klasse 3 voor Vertrouwelijkheid en klasse 4 voor Integriteit, met alle noodzakelijke controles die hiermee gepaard gaan.

In de praktijk komt dit neer op het versleutelen van informatie. Meer details hierover vind je in op de pagina 3.1. Minimale maatregelen - Cryptografie . De exacte controles op het gebied van versleuteling staan beschreven op 3.1. Minimale maatregelen - Cryptografie. 

Beveiliging van de opgeslagen identiteiten

De personen die toegang kunnen krijgen tot een toepassing of een systeem, moet je ook ergens opslaan. De database waar deze informatie opgeslagen is, moet je adequaat beschermen. De informatie van welke identiteiten er bestaan en waartoe deze toegang hebben in een bepaalde toepassing, is informatie van klasse 3 voor Vertrouwelijkheid en klasse 4 voor Integriteit. De maatregelen die hierop van toepassing zijn, staan beschreven in het Organisatiedocument. Deze informatieklasse geldt voor zowel de Vertrouwelijkheid als de Integriteit. Hiermee moet je garanderen dat de gebruikerslijst vertrouwelijk en integer blijft. Dit helpt om eventuele cyberaanvallen tegen specifieke profielen of gebruikers tegen te gaan.

Alternatieve methodes

Je mag alternatieve methodes gebruiken om een persoon te identificeren. Je moet je er wel van vergewissen dat dit even veilig verloopt als de hierboven beschreven methodes.

Dit verifieer je met de verantwoordelijke voor Informatieveiligheid van je entiteit die dit overlegt met de CISO. Als er aan deze methodes (rest)risico’s verbonden zijn, moet het topmanagement deze ook in de mate van het mogelijke mitigeren of accepteren.

De normen waaraan je moet voldoen komen, zoals hierboven beschreven, overeen met klasse 3 voor vertrouwelijkheid en klasse 4 voor integriteit.  

5.1.2.1.5. Beschikbaarheid van de gegevens betrokken in het identificatieproces

Link met informatieklasse van de toepassing/het proces

De gegevens die gelinkt zijn aan het identificatieproces moeten even beschikbaar zijn als de toepassing of het proces waarvoor ze dienen. Om de toegang tot een toepassing te kunnen garanderen, moeten deze gegevens leesbaar en verwerkbaar zijn tijdens de operationele werking van de toepassing.

Hou hier ook zeker rekening met piekmomenten, zowel qua gebruik als qua tijdsgevoeligheid. Het Organisatiedocument.

Als je gebruik maakt van een identificatieproces onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.  

5.1.2.2. Authenticatie als maatregel

5.1.2.2.1. Van identiteit tot Account

Authenticatie is het deelproces waarbij een individu zijn identiteit bewijst.

Om dit te doen heb je in de eerste plaats een authentieke bron nodig, een gecontroleerd en betrouwbaar identiteitsregistratieproces dat toelaat de identiteit van een individu te registreren.

Identiteiten worden gecentraliseerd in het rijksregister en rijksregister-BIS van de Belgische federale overheid maar deze identiteiten zijn niet rechtstreeks bruikbaar als authenticatiemiddel. Een gebruiker kan niet simpelweg verwijzen naar dit registratieproces om zijn identiteit te bewijzen. Daarom krijgt het individu een ‘middel’, dat door iedereen en elke organisatie, op zich erkent wordt als identiteitsreferentie.

Identiteitsbewijzen (inclusief paspoorten, geboortebewijzen, …) 

De Belgische identiteitskaart (eID) is het referentiemiddel voor de burger.

Het is echter beperkt inzetbaar als authenticatie bij Interactieve identificatie tussen fysieke personen.

Toepassingen op basis van een authenticatie integratie met de federale CSAM-diensten.

Om de beperkingen in gebruik van ons identiteitsbewijs weg te werken gebruikt de Vlaamse overheid een toegangsbeheer systeem, dat toelaat om aangepaste authenticatie middelen aan een identiteit te koppelen, zodat de gebruiker op een aangepaste manier toegang kan krijgen tot applicaties en diensten. Dit authenticatiemiddel noemt men een account.

5.1.2.2.2. Vorm van het account

De vorm waaronder een account zich voordoet is volledig afhankelijk van de gebruikte technologie.

• Fysieke authenticatie vereist het gebruik van een fysiek middel. (Authenticatie tussen personen)

• Authenticatie naar een informatie verwerkingssysteem vereist een elektronisch middel.

Merk op: Sommige accountvormen zijn in staat om beide authenticatievereisten samen te brengen. Het Belgische eID ondersteunt zowel fysieke als elektronische authenticatievormen.

• Het aanmaken of ter beschikking stellen van een account gebeurt via het toegangsbeheer.

• Het gebruik (proces) van een account om zich kenbaar te maken (= identiteit van de persoon te bewijzen) heet authenticatie.

• Een account laat enkel toe een gebruiker te identificeren naar een toepassing of dienst. Het moet  echter uitgebreid worden met de toestemming om de toepassing of dienst op een bepaalde wijze te gebruiken (zie autorisatie)

• Een account kan verschillende vormen aannemen afhankelijk van de (technische) toepassing. 

Enkele voorbeelden:

...

De toegangsbadge (Account) voor de Vo gebouwen, laat toe om de gebruiker (het individu) te identificeren aan de toegangspoort (Authenticatie).

...

De referentie die de toegangspoort hiervoor gebruikt is een lijst van accounts in een database verbonden aan de toepassing: Toegangsbeheer gebouwen.

...

De Windows gebruiker ID (Account) laat toe om de gebruiker (het individu) te identificeren bij het aanloggen (Authenticatie) op je werkplek.

...

De referentie die je werkstation hiervoor gebruikt is een lijst van accounts in een database verbonden aan het werkstation.

...

Windows domain computers:

...

Active Directory: ALFA/GID

• Local host

• Windows stand-alone (Gelijkaardig voor andere systemen)

• Local host

...

Een applicatie gebruiker (Account) laat toe om de gebruiker (het individu) te identificeren bij het aanloggen (Authenticatie) op een toepassing.

...

3. Account lifecycle

Een lifecycle beschrijft alle processen, criteria en doelstellingen van het betrokken object, in dit geval het account object.

 Provisioning

Provisioning is het deelproces waarbij accounts en bijbehorende toegangsrechten, zoals sleutels, badges en alarmcodes, worden aangemaakt en verstrekt aan een geïdentificeerd individu (zie ook verder 2.2 Identificatie als maatregel). Dit proces is essentieel voor het beheren van zowel digitale als fysieke toegang tot systemen, informatiebronnen en beveiligde locaties binnen de organisatie. Het doel van provisioning is ervoor te zorgen dat alleen geautoriseerde personen toegang krijgen op basis van hun rol en verantwoordelijkheid.

Tijdens het provisioning-proces worden accounts en fysieke toegangsmiddelen verstrekt op basis van de behoefte van de gebruiker om toegang te krijgen tot specifieke diensten, systemen of fysieke ruimtes. Personen die geen toegang nodig hebben tot deze systemen of locaties mogen geen actief account of toegangsmiddel ontvangen.

Afhankelijk van de gevoeligheid van de informatie en de fysieke beveiligingsvereisten kan een account en/of fysieke toegang op verschillende manieren worden verstrekt:

• Actieve accounts: Voor directe toegang tot systemen of fysieke ruimtes. Dit is toegestaan voor informatie tot en met klasse 2 en voor niet-kritieke fysieke ruimtes.

• Inactieve accounts: Accounts en toegangsmiddelen worden aangemaakt, maar blijven geblokkeerd totdat verdere geautoriseerde activering plaatsvindt via een gedocumenteerd proces. Dit biedt extra controle voor informatie van hogere classificatie of voor toegang tot kritieke fysieke zones.

Fysieke toegangsmiddelen zoals sleutels en badges worden tijdens het provisioning-proces verstrekt aan gebruikers die toegang moeten hebben tot beveiligde ruimtes. Deze middelen zijn altijd persoonsgebonden en gekoppeld aan specifieke toegangsrechten binnen de organisatie. Het verstrekken van deze fysieke toegangsmiddelen moet op een veilige en gedocumenteerde manier gebeuren. Bij verlies of beschadiging moeten gebruikers dit direct melden en worden passende maatregelen genomen, zoals het deactiveren van badges of het wijzigen van sloten.

Bij het verstrekken van accounts en fysieke toegangsmiddelen moet er altijd een directe koppeling zijn met een fysieke persoon om de relatie tussen gebruiker en account/toegangsmiddel te waarborgen. De levering van verschillende authenticatiefactoren (zoals wachtwoorden, sleutels, of toegangspassen) moet zorgvuldig gescheiden en veilig aan de gebruiker worden overgedragen.

De-provisioning

De-provisioning is het deelproces waarbij toegangsrechten en toegangsmiddelen zoals accounts, sleutels, badges en alarmcodes systematisch worden ingetrokken of gedeactiveerd wanneer een gebruiker, leverancier of externe partij niet langer geautoriseerd is om deze te gebruiken. Dit voorkomt dat onbevoegde personen toegang blijven houden tot systemen en fysieke locaties nadat hun rechten zijn vervallen.

De-provisioning kan op verschillende manieren worden uitgevoerd, afhankelijk van het type toegangs- of authenticatiemiddel:

• Verwijderen: Het volledig verwijderen van een account, sleutel of badge uit het systeem of de infrastructuur.

• Deactiveren (blokkeren): Het tijdelijk uitschakelen van een account of toegangsmiddel, zodat het op een later moment opnieuw kan worden geactiveerd indien nodig.

• Revoke (intrekken): Het permanent ongeldig maken van een account, sleutel of badge, zodat deze nooit meer gebruikt kan worden.

Dit proces kan in meerdere stappen worden uitgevoerd, vooral als er een behoefte is aan gefaseerde toegang tijdens de account lifecycle. Een account of fysieke toegang kan tijdelijk worden gedeactiveerd voordat het definitief wordt verwijderd, afhankelijk van de noodzaak om het in de toekomst opnieuw te activeren. Indien regelgeving vereist dat accounts of toegangsmiddelen niet permanent verwijderd mogen worden, moet dit expliciet worden opgenomen in de procesdocumentatie.

Fysieke toegangsmiddelen, zoals sleutels en badges, moeten vóór het verlaten van de organisatie worden ingeleverd. Aangezien deze artefacten als fysieke identiteitsmiddelen dienen en direct gekoppeld zijn aan de identiteit van de gebruiker, vormen ze een veiligheidsrisico indien ze niet tijdig worden ingeleverd. Wanneer sleutels en badges niet worden teruggegeven, moeten deze middelen onmiddellijk worden gedeactiveerd, bijvoorbeeld door het slot te vervangen of de badge in het toegangscontrolesysteem te blokkeren.

Controlemaatregelen en monitoring

Een belangrijk onderdeel van het beheer van accounts en fysieke toegangsmiddelen is de regelmatige inventarisatie van alle bestaande accounts en bijbehorende toegangsmiddelen. Deze inventarisatie helpt bij het identificeren van inactieve of ongemotiveerde accounts en toegangsmiddelen, zodat ze tijdig kunnen worden gedeactiveerd of aangepast.

De volgende controlepunten zijn van toepassing:

• Slapend(e) account(s): Accounts en fysieke toegangsmiddelen die in de afgelopen 13 maanden niet zijn gebruikt, worden als slapend beschouwd en moeten worden geëvalueerd.

• Ongemotiveerd(e) account(s): Accounts of fysieke toegangsmiddelen die niet langer gekoppeld zijn aan een gevalideerde identiteit van een fysieke persoon.

• Inactief(ve) account(s): Accounts die technisch niet in staat zijn om deel te nemen aan een authenticatieproces.

• Ongecontroleerd(e) account(s): Accounts die niet voldoen aan de minimale technische vereisten van de paswoordpolicy of fysieke toegangsmiddelen waarvan het beheer niet correct is gedocumenteerd (bijvoorbeeld sleutels die niet geregistreerd zijn).

Sommige systemen kunnen ook gebruikmaken van technische identiteiten (zoals systeemaccounts). Binnen de IAM-context moeten deze accounts altijd gekoppeld zijn aan een fysieke persoon, bijvoorbeeld in de rol van een toepassingsbeheerder. Deze koppeling moet worden geregistreerd in de CMDB om volledige traceerbaarheid te waarborgen.

Logging en auditing

Alle stappen binnen het provisioning- en de-provisioning proces, inclusief het verstrekken, inleveren, of blokkeren van accounts en fysieke toegangsmiddelen, moeten worden gelogd volgens de minimale maatregelen zoals beschreven in het document “Vo Informatieclassificatie - Minimale maatregelen – SIEM”.

5.1.2.2. Identificatie als maatregel

Identificatie is het proces waarbij een individu of een systeem zichzelf kenbaar maakt aan een ander systeem of proces. Afhankelijk van het beveiligingsniveau van de toepassing of dienst waarvoor toegang wordt verleend, onderscheiden we zwakke en sterke identificatie. Beide hebben implicaties rond vertrouwelijkheid en integriteit.

5.1.2.2.1. Zwakke identificatie

Zwakke identificatie: Validatie van de identiteit van een fysiek persoon op basis van een identiteitsattribuut dat niet onder controle valt van een door de overheid geregistreerde of gecertifieerde bron.

Zwakke identificatie wordt gebruikt voor processen die geen hoog niveau van beveiliging vereisen. Deze identificatiemethode kan worden toegepast voor toegang tot informatie tot en met Klasse 2.

De gebruikte identiteit attributen komen voor het identificatie- of registratieproces van een al dan niet commerciële organisatie.

De gebruikte identiteit attributen komen voor het identificatie- of registratieproces van een al dan niet commerciële organisatie.

• De identiteit is niet geverifieerd via een door de Belgische federale overheid erkende procedure.

• De verificatieprocedure biedt minimale waarborg.

• Identificatie gebeurt op basis van (Niet-gelimiteerde voorbeelden)

  • een e-mailadres

  • Een telefoonnummer

  • Een (roep)naam
    Bv: Sociale media, online winkelplatform, intekenen nieuwsbrief, ...

Opmerking: De Vlaamse overheid beschouwt elke bron als commercieel, ook als de gerelateerde dienst ‘gratis’ wordt aangeboden. 

• Identificatie gebeurt op basis van (Niet-gelimiteerde voorbeelden)

  • Een e-mailadres

  • Een telefoonnummer

  • Een (roep)naam

Bv: Sociale media, online winkelplatform, intekenen nieuwsbrief, ...

Opmerking: Hoewel er bij zwakke identificatie minder zekerheid is over de exacte identiteit van de gebruiker dan bij een sterke identificatie, spreken we hier wel degelijk over persoonsgegevens. Zwakke identificatie impliceert niet dat er minder controles nodig zijn om de vertrouwelijkheid en integriteit van deze persoonsgegevens te verzekeren. 

5.1.2.2.2. Sterke identificatie

Sterke identificatie: Identificatie op basis van een door de Belgische federale overheid geregistreerde of gecertifieerde bron (Identity provider).

Sterke identificatie wordt vereist voor toepassingen en diensten die werken met gevoelige informatie (vanaf Klasse 3).
De Vlaamse overheid gebruikt als Identity provider het identificatieproces van de Belgische federale overheid. Dit geeft aan dat (vandaag) enkel de Federale overheid een sterke validatie van een identiteit kan uitvoeren om te voldoen aan de kenmerken van een sterke identificatie.

De unieke identificatie labels van een identiteit (Fysiek persoon) zijn:

• Rijksregisternummer (Ook gekend als RRN)

• Rijksregister-BIS nummer (Ook gekend als BIS-Nummer) 

  • De uitwisselbaarheid van identiteiten van buitenlandse individuen, ook binnen de EU is opgevangen door de registratie van het individu in het RijksRegister-BIS

  • Dit bisnummer wordt overgenomen als unieke bron voor een identiteit binnen de Vlaamse overheid

  • Naar de toekomst toe zullen alle EU identity providers de mogelijkheid bieden om identiteiten én de validatie ervan onderling uit te wisselen. Deze integratie zal worden gerealiseerd door de Belgische federale overheid in Europese context (zie bronnen).

Opmerking: Binnen de Vlaamse overheid gebeurt de registratie van identiteiten voor fysieke personen, binnen onze access managementprocessen, steeds op basis van het RRN of BIS-Nummer.

Erkende afgeleide bronnen voor sterke identificatie

Een aantal erkende afgeleide bronnen worden gebruikt binnen:

De Belgische federale overheid

• INSZ: Identificatienummer van de sociale zekerheid, gedefinieerd door het sectoraal comité van de sociale zekerheid.

• ItsMe® identificatie validatie

ItsMe® De veiligheid van het ItsMe®-platform en bijhorende toepassing werd beoordeeld op basis van een controle raamwerk welke FOD BOSA in het leven heeft geroepen, voor de evaluatie van identificatiemiddelen onder het Koninklijk besluit van 08/11/2017 tot
vaststelling van de voorwaarden, de procedure en de gevolgen van de erkenning van diensten voor elektronische identificatie voor overheidstoepassingen. Zie link naar de publicatie in het staatsblad.

De Vlaamse overheid

Deze van de federale overheid (zie boven)  VoID: Uniek identiteitslabel, toegepast op zowel RRN als BIS-Nummer identiteiten, binnen de access management processen bij de Vlaamse overheid.

Alternatieve methodes

Je mag alternatieve methodes gebruiken om een persoon te identificeren. Je moet je er wel van vergewissen dat dit even veilig verloopt als de hierboven beschreven methodes.

Dit verifieer je met de verantwoordelijke voor Informatieveiligheid van je entiteit die dit overlegt met de CISO. Als er aan deze methodes (rest)risico’s verbonden zijn, moet het topmanagement deze ook in de mate van het mogelijke mitigeren of accepteren.

5.1.2.2.3.

...

De betrouwbaarheid van een account is rechtstreeks afhankelijk van de kwaliteit van het gebruikte identiteitsbeheersproces. Men kan geen sterke authenticatie garanderen als men geen sterk identificatieproces gebruikt, dat in de eerste plaats de identiteit van de gebruiker, aan wie men een account toekent, kan garanderen.

Account lifecycle

Een lifecycle beschrijft alle processen, criteria en doelstellingen van het betrokken object, in dit geval het account object.

Aanmaak van accounts

• Het deelproces aanmaken van een account wordt bepaald op basis van de aanwezige motivatie van een individu om toegang te krijgen.

• Hieruit volgt dat personen die niet geacht worden toegang te hebben tot diensten of informatie geen beschikking mogen hebben tot een (actief) account dat de gebruiker potentieel de mogelijkheid biedt.

• Tal van toepassingen baseren zich op enkel geauthentiseerde accounts om toegang toe te staan. Het account heeft steeds een relatie met een identiteit van een fysiek persoon. Gebruik steeds, waar mogelijk een sterke identificatie van de fysieke persoon. Vanaf informatieverwerking [klasse 3] is het gebruik van een sterke identificatie verplicht. 

Een niet gemotiveerde toegang beschouwt men als niet geautoriseerde toegang. 

Categorieën, types en status van accounts

Elk van de onderstaande account categorieën en types zijn volledige gedocumenteerd in: Policy documenten (vb. gebruiks- en paswoord policies) Gebruikers documentatie.

Account categorieën

• Gebruikersaccount(s) zijn accounts die gebruikt worden voor reguliere eindgebruikerstoegangen voor informatieverwerking tot en met [Klasse 4].

• Geprivilegieerd(e) account(s) zijn accounts waaraan met potentieel geprivilegieerde toegangen worden verleend. Een geprivilegieerde toegang is een toegang die de gebruiker (van het account) de mogelijkheid geeft om Informatie van [Klasse 5] (minimaal) in te kijken.

• De beschikbaarheid en/of gedrag van de gegevensverwerking te beïnvloeden. 

Account types

• Persoonlijk(e) account(s) zijn accounts met een rechtstreekse relatie tot één individu.

  • Vb. Reguliere gebruikersaccounts

• Gedeeld(e) account(s) zijn accounts die gedeeld kunnen worden onder verschillende individuen. Deze accounts hebben ALTIJD een relatie tot een uniek individu via een rol: Toepassingsbeheerder.

• Toepassingsaccount(s) zijn accounts gebruikt worden als authenticatie voor toepassingen onderling. Deze accounts hebben ALTIJD een relatie tot een uniek individu via een rol: Toepassingsbeheerder.

• Systeemaccount(s) zijn accounts die deel uitmaken van het resultaat van installatie van het betrokken systeem. Deze accounts zijn ook gekend als built-in account(s)

Status van een account

• Een account is actief wanneer het technisch de mogelijkheid biedt om gebruikt te worden als authenticatiemiddel

• De criteria om een actief account te beschouwen zijn afhankelijk van de vorm waarin het account werd aangeleverd

• Een account is inactief wanneer het op basis van de criteria uitgesloten werd als actief account. Een account kan bvb tijdelijk geblokkeerd (disabled) of slechts gebruikt tijdens bepaalde uren (bvb kantooruren).

Controlemaatregel

• Inventarisatie van alle bestaande accounts, inclusief het type en bijhorende categorie met volgende indicatoren. Op basis hiervan kunnen bijkomende maatregelen worden ingevuld:

• Slapend(e) account(s): Het account is niet meer gemotiveerd indien het niet werd gebruikt in de laatste 13 maand. De status actief, of inactief heeft geen invloed op de status

• Ongemotiveerd(e) account(s): Het account is niet gekoppeld aan een gevalideerd identiteit van een fysiek persoon

• Systemen kunnen technisch gezien ook gebruikt worden als identiteiten. In IAM-context koppelen we accounts steeds aan een fysiek persoon

• Het is toegestaan koppeling te maken via een toepassing, waarachter onrechtstreeks gekoppeld een fysiek persoon, onder vorm van een ‘toepassingsbeheerder’. Deze koppeling kan dan geregistreerd worden via de CMDB

• Inactief(ve) account(s): De accounts zijn technisch niet in staat deel te nemen aan een authenticatie proces. Ongecontroleerd(e) account(s): Het account voldoet niet aan de minimale technische vereisten van de paswoordpolicy die werd toegekend aan de account categorie of –type:

• Leeftijd van het paswoord

  • Complexiteit van het paswoord

  • Omkeerbare encryptie van het paswoord

  • Geen paswoord

  • …

Provisioning

Provisioning is het deelproces dat wordt gebruikt voor alle activiteiten die leiden tot het verstrekken van een account aan een geïdentificeerd persoon. Afhankelijk van de implementatie van het proces worden accounts actief of inactief aangeleverd aan de rechtmatige persoon. Bij de aanlevering van inactieve accounts zorgt het provisioning proces voor een geautoriseerd en gedocumenteerd activatie (sub)proces.

• Provisioning van actieve accounts is toegelaten tot en met informatie [klasse 2]

• Account factoren worden gescheiden aangeleverd aan de rechtmatige gebruiker

De-provisioning

De-provisioning is het deelproces dat ervoor zorgt dat een account niet langer ter beschikking voor een eindgebruiker als bruikbaar authenticatiemiddel.

Afhankelijk van de vorm van het authenticatiemiddel en/of de-provisioning methodiek spreekt men van verwijderen, deactiveren (blokkeren), revoke (weigering), …

De-provisioning kan in een of meerdere stappen worden uitgevoerd. Gefaseerde de-provisioning processen wordt steeds ondersteund door geïdentificeerde behoeften aan het account lifecycle proces. 

Een account al dan niet tijdelijk deactiveren, vooraleer effectief te verwijderen is afhankelijk van de behoefte om dit account op een later tijdstip te heractiveren.

Indien accounts op basis van geïdentificeerde regelgeving niet effectief verwijderd mogen worden zal deze behoefte expliciet opgenomen zijn in de beschrijvende procesdocumentatie

...

Kwaliteitskenmerken van het identificatieproces

De gegevens die we in het identificatieproces gebruiken, zijn persoonsgegevens en hebben altijd een bepaalde graad van vertrouwelijkheid, integriteit en beschikbaarheid, ongeacht of we zwakke of sterke identificatie gebruiken. Dit moet ervoor zorgen dat tijdens het identificatieproces er voldoende controles in gebruik zijn om beide kwaliteitskenmerken te borgen. Concreet betekent dat deze gegevens volgende klasse toebedeeld krijgen:

• Informatieklasse 3 voor Vertrouwelijkheid 

• Informatieklasse 4 voor Integriteit

• De informatieklasse voor Beschikbaarheid is gealigneerd met de classificatie van de toepassing waarvoor de identificatie dient. De maatregelen die je inricht moeten deze beschikbaarheid kunnen garanderen.

Voor elk kenmerk dient de juiste mate van beveiliging voorzien te worden. Voor de identiteitskenmerken zoals hier beschreven dienen de minimale maatregelen rond cryptografie voor DAR, DIM en DIU in acht genomen te worden

Belangrijk hierbij is dat de controles per klasse gecombineerd werken. Staat een controle bij meerdere kwaliteitskenmerken beschreven, dan implementeer je de strengste van beide criteria. Bijvoorbeeld: je moet voor Vertrouwelijkheid 3 en voor Integriteit 4 data encrypteren, maar voor I4 moet je een zwaardere sleutel gebruiken dan voor C3. Dan moet je voor deze data de strengste sleutel van de twee gebruiken. Komt een controle maar in een van de twee categorieën voor, dan moet je die uiteraard ook nog steeds implementeren.

5.1.2.2.4. Integriteit van het identificatieproces

Toegangsniveaus binnen toepassingen, of infrastructuur

Bij het registreren van de identiteit van een gebruiker, houdt de beheerder rekening met de mogelijkheid dat de gebruiker normale gegevens (normale gebruiker) of zelfs systeemeigenschappen (beheerder) zal kunnen aanpassen. Het gaat dus verder dan de vraag tot welke gegevens de gebruiker toegang zal hebben.

Je moet hiermee rekening houden met de logica in de opzet en toekenning van de rollen binnen de toepassing en haar beheer. Hierbij is het van belang dat de toegang die in de rollen vervat zit, altijd tweeledig is: de vertrouwelijkheids- en integriteitseisen gaan bepalen wie waartoe toegang zal kunnen krijgen.

5.1.2.3. Authenticatie als maatregel

5.1.2.3.1. Van identiteit tot Account

Authenticatie is het waarbij een gebruiker zijn identiteit bewijst om toegang te krijgen tot een toepassing of systeem.

Om dit te doen heb je in de eerste plaats een authentieke bron nodig, een gecontroleerd en betrouwbaar identiteitsregistratieproces dat toelaat de identiteit van een individu te registreren.

Identiteiten worden gecentraliseerd in het rijksregister en rijksregister-BIS van de Belgische federale overheid maar deze identiteiten zijn niet rechtstreeks bruikbaar als authenticatiemiddel. Een gebruiker kan niet simpelweg verwijzen naar dit registratieproces om zijn identiteit te bewijzen. Daarom krijgt het individu een ‘middel’, dat door iedereen en elke organisatie, op zich erkent wordt als identiteitsreferentie.

Identiteitsbewijzen (inclusief paspoorten, geboortebewijzen, …) 

De Belgische identiteitskaart (eID) is het referentiemiddel voor de burger.

Het is echter beperkt inzetbaar als authenticatie bij Interactieve identificatie tussen fysieke personen.

Toepassingen op basis van een authenticatie integratie met de federale CSAM-diensten.

Om de beperkingen in gebruik van ons identiteitsbewijs weg te werken gebruikt de Vlaamse overheid een toegangsbeheer systeem, dat toelaat om aangepaste authenticatie middelen aan een identiteit te koppelen, zodat de gebruiker op een aangepaste manier toegang kan krijgen tot applicaties en diensten. Dit authenticatiemiddel noemt men een account.

5.1.2.3.2. Vorm van het account

De vorm waaronder een account zich voordoet is volledig afhankelijk van de gebruikte technologie.

• Fysieke authenticatie vereist het gebruik van een fysiek middel. (Authenticatie tussen personen)

• Authenticatie naar een informatie verwerkingssysteem vereist een elektronisch middel.

Merk op: Sommige accountvormen zijn in staat om beide authenticatievereisten samen te brengen. Het Belgische eID ondersteunt zowel fysieke als elektronische authenticatievormen.

• Het aanmaken of ter beschikking stellen van een account gebeurt via het toegangsbeheer.

• Het gebruik (proces) van een account om zich kenbaar te maken (= identiteit van de persoon te bewijzen) heet authenticatie.

• Een account laat enkel toe een gebruiker te identificeren naar een toepassing of dienst. Het moet  echter uitgebreid worden met de toestemming om de toepassing of dienst op een bepaalde wijze te gebruiken (zie autorisatie)

• Een account kan verschillende vormen aannemen afhankelijk van de (technische) toepassing. 

Enkele voorbeelden:

• De toegangsbadge (Account) voor de Vo gebouwen, laat toe om de gebruiker (het individu) te identificeren aan de toegangspoort (Authenticatie).

• De referentie die de toegangspoort hiervoor gebruikt is een lijst van accounts in een database verbonden aan de toepassing: Toegangsbeheer gebouwen.

• De Windows gebruiker ID (Account) laat toe om de gebruiker (het individu) te identificeren bij het aanloggen (Authenticatie) op je werkplek.

• De referentie die je werkstation hiervoor gebruikt is een lijst van accounts in een database verbonden aan het werkstation.

• Windows domain computers:

  • Active Directory: ALFA/GID

  • Local host

  • Windows stand-alone (Gelijkaardig voor andere systemen)

• Local host

  • Een applicatie gebruiker (Account) laat toe om de gebruiker (het individu) te identificeren bij het aanloggen (Authenticatie) op een toepassing.

  • De referentie die de toepassing gebruikt komt uit een centrale database (LDAP/cLDAP of ACM).

5.1.2.3.4. Betrouwbaarheid van het authenticatieproces

De maatregelen genomen in het account registratie proces worden verder uitgebreid met een aantal technische maatregelen die het dupliceren en oneigenlijk gebruik van een account moeten voorkomen. Men spreekt over de vertrouwelijkheidsgraden van de authenticatie.

eID.AS Authenticatie vertrouwelijkheidsgraden

Op Europees vlak werden een aantal afspraken gemaakt in verband met deze authenticatie vertrouwelijkheidsgraden. Op deze manier kunnen de authenticatieplatformen van de individuele

...

• eID.AS: EU-verordening voor elektronische identificatie tussen burgers, bedrijven en overheden

  • Deze standaard in is opgebouwd op basis van authenticatie vertrouwelijkheidsschalen

  • Zowel de Belgische federale overheid, als de Vlaamse overheid gebruiken deze uniforme schalen.

De eID.AS LoA4 schalen
Deze vertrouwelijkheidsgraden worden onderverdeeld in 3 eID.AS LoA schalen

...

Gelieve de brondocumentatie van FOD BOSA te gebruiken voor meer detailinformatie.  

(Multi)factor-authenticatie

Bij zowel de Belgische federale als bij de Vlaamse overheid ligt de focus op (multi)factor-authenticatie, terwijl we regelmatig ook geconfronteerd worden met terminologie zoals tweefactor-authenticatie en tweetraps-authenticatie. Ze worden gemakkelijk door elkaar gehaald gezien ze alle drie baseren op dezelfde beginselen. Maar de verschillen zitten hem in de details. Zoals reeds aangegeven ligt het identificatieproces aan de basis van een succesvolle implementatie van een betrouwbare authenticatie: Om toegang te verlenen tot een toepassing, dienst of netwerk, moet het achterliggende systeem weten dat de persoon die zich aanmeldt ook daadwerkelijk degene is die als wie hij zich voordoet.

...

• Iets wat je kent, een wachtwoord of pincode

• Iets wat je hebt, bijvoorbeeld een pinpas of smartcard

• Iets wat je bent, verwijzend naar biometrische gegevens, zoals je vingerafdruk

Single factor authenticatie

In zijn meest eenvoudige vorm gebruiken we éénfactor-authenticatie vrijwel elke dag onder vorm van een toegangsbadge tot onze gebouwen, maar ook onder een veiliger vorm: onze toegang tot het werkstation door gebruik te maken van een gebruikersID met bijhorend wachtwoord. Éénfactor-authenticatie verwijst naar de unieke wijze op basis van waarop de identiteit gevalideerd kan worden:

• Voor de validatie tot toegang voor een gebouw zal het toegangscontrole systeem de toegang enkel valideren op iets dat in het bezit is van de gebruiker Bij de toegang tot het werkstation door middel van een gebruiker ID en paswoord zal de controle enkel gevalideerd worden op basis van iets wat de gebruiker weet

...

Het probleem bij het gebruik van enkelvoudige factoren, is dat deze niet altijd voldoende garantie biedt om een identiteit te verifiëren. Als derden deze factor weten te misbruiken (het wachtwoord achterhalen of de badge ontvreemden), dan kan deze zich als de persoon, gekoppeld aan het authenticatiemiddel (account) voordoen en zich onrechtmatig toegang verlenen.voordoen en zich onrechtmatig toegang verlenen.

Standaardwachtwoorden (vooraf ingestelde, universele wachtwoorden die door fabrikanten of softwareleveranciers op alle apparaten of systemen worden ingesteld bij productie of installatie) vormen hierbij een belangrijk beveiligingsrisico omdat ze vaak eenvoudig te raden zijn en breed bekend bij cybercriminelen. Het is daarom essentieel om standaardwachtwoorden onmiddellijk te resetten bij de aanmaak van een nieuwe gebruiker

Bij de factorauthenticatie op basis van wat je bent (biometrische authenticatie) is misbruik minder evident, maar niet ondenkbaar. Bovendien is de beschikbare technologie niet altijd in staat om de identiteit gegarandeerd vast te stellen (misleiding gezichtsherkenning d.m.v. foto).

Om een betere garantie te geven bij het afschermen van informatie is het sterk geadviseerd om minimaal bijkomende maatregelen te nemen die het risico op misbruik kan verminderen. Bij sommige informatieklassen worden deze bijkomende maatregelen onvoldoende geacht en vraagt men expliciet om een identiteit te valideren op basis van meerdere factoren (bijkomende authenticatie maatregelen op basis van meerdere factoren).

Multifactor-authenticatie

...

Basisprincipe: Bij multifactor gaat men uit van meerdere authenticatiemiddelen.

5.1.2.

...

3.5. Integriteit van de gegevens betrokken in het authenticatieproces

Status van het account

De beheerder beheert de status van de bestaande gebruikers en maakt hiervoor gebruik van de hierboven beschreven categorieën. Dit belet niet enkel onrechtmatige toegang tot data (kwaliteitskenmerk vertrouwelijkheid), het verhindert ook onrechtmatige aanpassingen aan data
(kwaliteitskenmerk integriteit).

...

Tegelijkertijd is het nuttig om dit proces (automatisch) te linken aan het provisioning proces, om er zeker van te zijn dat de status van een account altijd de juiste is.

Beveiliging van het paswoord

Er zijn heel wat controles die je kunt toepassen op paswoorden. Hier focussen we op het uitwisselen van credentials bij het aanmelden, en de veilige opslag van de gebruikersnaam en het paswoord door de toepassing of het systeem. 

Bij het verzenden van credentials tijdens het aanmelden stuur je enkel de hash van het wachtwoord Bij het opslaan van het paswoord, is het belangrijk om ervoor te zorgen dat de toegang ertoe strikt afgezonderd is tot beheerders en dat zij enkel toegang krijgen tot gehashte wachtwoorden. Salting is een extra techniek die je toepast om nooit het reële paswoord kenbaar te maken.

Een alternatief hiervoor van de gebruikersnaam en het paswoord door de toepassing of het systeem. 

Bij het verzenden van credentials tijdens het aanmelden stuur je enkel de hash van het wachtwoord Bij het opslaan van het paswoord, is het belangrijk om ervoor te zorgen dat de toegang ertoe strikt afgezonderd is tot beheerders en dat zij enkel toegang krijgen tot gehashte wachtwoorden.

Salting is een cryptografische techniek waarbij een unieke, willekeurige waarde (de "salt") wordt toegevoegd aan een wachtwoord voordat het wordt gehasht. Dit zorgt ervoor dat zelfs als twee gebruikers hetzelfde wachtwoord hebben, de resulterende hashes verschillend zijn. De salt wordt samen met het gehashte wachtwoord opgeslagen in de database, zodat de authenticatieserver het originele wachtwoord met de juiste salt kan hashen bij het inlogproces.

Een alternatief is werken met federatie, waarbij je de identificatie en authenticatie aan een derde partij toevertrouwt. Dit wil vooral zeggen dat je de data die hiermee gepaard gaat niet zelf beheert. Als je dit doet, moet je er wel zeker van zijn dat die derde partij alle noodzakelijke controles in plaats heeft gezet om de data te beschermen. Dit dek je idealiter ook contractueel af.

...

Dit zijn slechts enkele voorbeelden van maatregelen die je kunt nemen om paswoorden te beveiligen. Je mag er uiteraard andere en meer nemen. Doe dit in overleg met de verantwoordelijke over Informatieveiligheid binnen je entiteit.

5.1.2.

...

3.6. Beschikbaarheid van de gegevens betrokken in het authenticatieproces

Status van account moet beschikbaar zijn

Hier is de link met de informatieklasse van de toepassing of het proces evenzeer belangrijk. De authenticatie moet kunnen gebeuren terwijl de toepassing functioneel is. Welke controles hiervoor kunnen gelden, staat beschreven in het Beleidsdocument Toegangsbeheer. Als je gebruik maakt van een authenticatieproces onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.

Logbestanden bijhouden

De logbestanden voor de gebeurde authenticaties moet beschikbaar zijn in lijn met de termijnen van het bijhouden van de operationele logs van de toepassing. De geldende legale termijn moet je hierbij ook respecteren. Deze zijn uiteraard sterk afhankelijk van de operationele context. De langste termijn is bepalend.  

5.1.2.

...

4. Autorisatie als maatregel

Toestemming tot gebruik van een dienst of applicatie door een bevoegd persoon noemt men autorisatie. Men maakt onderscheid tussen twee specifieke aspecten: 

• Toegangsbeheer (Het het proces) als organisatorische maatregel.

• Toegangscontrole (De de techniek) als technische maatregel.

5.1.2.

...

4.1. Toegangsbeheer als maatregel

Toegangsbeheer is een organisatorische maatregel die steunt op een toegangsbeleid (zie ook 4.8. Minimale maatregelen - Toegangsbeheer ). Dit proces legt uit, hoe en onder welke omstandigheden een individu toegang krijgt tot de organisatiemiddelen. Om dit te realiseren zijn er in de eerste plaats af te dwingen maatregelen nodig. Deze maatregelen zijn gekend als toegangsbeleidslijnen (access policies) en omschrijven onder welke omstandigheden een toegang gevalideerd kan worden op basis van de classificatie van de informatie waarop de validatie van toepassing is.

...

Attributen van het toegangsbeheer

Volgende attributen zijn aanwezig in het toegangsbeheer om een auditeerbaar proces te garanderen:

Beschikbare informatie bij de verwerking van een toegang

• Basis attributen van het verzoek tot toegang (Datum, tijd, aanvrager, volgnummer, …)

• Onderwerp, als referentie naar het individu die de toegang wenst te gebruiken.

• Motivatie van het verzoek

• Bevestiging van motivatie

• Basis attributen van de validatie van de toegang (Datum, tijd, …)

• Identiteit van de persoon die de goedkeuring(en) geeft.

• (Optioneel: bijkomende opmerkingen)

• Vervaldag van het toegangsrecht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing

• Periodiek herhaalde (her)validatie van een recht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing

Actoren(rollen) bij de verwerking van een toegang

• Onderwerp: Identiteit van het individu die toegang tot de verwerking wenst te gebruiken.

• Validator: Identiteit van een individu die de voorwaarden tot de gevraagde toegang bevestigen (valideren) tijdens het verwerkingsproces

• De verwerking van autorisaties voor zichzelf is hierbij uitgesloten

• De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie

• Hiërarchisch leidinggevende Functioneel leidinggevende Functioneel verantwoordelijke

• Toepassingsbeheerder

• Security Officer

• Toegangsbeheerder: Identiteit van het individu die de toegangsverzoeken operationeel verwerkt

• Elke erkende gebruiker van het toegangsbeheer proces

• Self-service baseert zich steeds op een sterke authenticatie

• Identiteit van een individu die het toegangsbeheerproces voor anderen administratief verwerken.

• De verwerking van toegangen voor zichzelf is hierbij uitgesloten

• De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie.

• Auditor: Identiteit van een individu die controle uitvoert op alle aspecten van het verwerkingsproces.

• Alle verwerkingsinformatie van het toegangsbeheer (audit trails) zijn beschikbaar en zijn enkel in te kijken door het individu

• De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie.

5.1.2.

...

4.2. Toegangscontrole als maatregel

Toegangscontrole is een set van technische maatregelen die steunen op de technische specificaties van de toegepaste technologie.
Bij het aanmelden aan een toepassing of dienst zal de identiteit (authenticatie) gevalideerd worden, waarbij de technische afhandeling van het validatieverzoek afhankelijk is van de gebruikte technologie. (Zie eID.AS) Afhankelijk van de gebruikte methode zal datzelfde authenticatieplatform bepalen welke autorisaties er aan het betrokken individu (op basis van zijn account of gekoppeld recht) worden toegekend.

...

• Voor de toegangen die toegestaan worden op basis van een centrale referentietabel (ook directory genoemd) gebruiken we het toegangsbeheer en zijn onderliggende processen en controles.

• Voor toepassingen die deze referentietabel gebruiken om autorisaties te valideren gebruiken een combinatie van volgende processen:

• Configuratie beheer (zie ook4.1. Minimale maatregelen - Asset- en configuratiebeheer ) garandeert een beveiligde systeem context voor de toepassing. Secure coding en safe source (software assurance) leveren een correcte basis voor een veilige ontsluiting en implementatie van de toepassing.

• Voor de toegangen die toegestaan worden op basis van een referentietabel die rechtstreeks gelinkt is aan het middel (ACL op de resource of asset) gebruiken we het proces configuratie beheer (niet in scope van dit document)

• Het is belangrijk te noteren dat toegangscontrolemaatregel in lijn moeten zijn met de toegangsbehoefte van de rol tot de verwerkte informatie. Hierbij houden we vast aan het least access privilege principe en scheiden we eindgebruikerstoegangen strikt van de beheerstoegangen.

5.1.2.

...

4.3. Integriteit van het authenticatieproces

Soll/Ist 6

Met Soll/Ist bedoelen we twee processen:

...

Een rol toekennen

Je gebruikt de Soll-matrix als leidraad en kent enkel een rol toe aan een geïdentificeerd persoon. Als blijkt dat een aanvraag tot toegang niet strookt met de bestaande Soll en de aanvraag gerechtvaardigd is, pas je de Soll aan en laat je hem opnieuw valideren door de toepassingseigenaar. Afhankelijk van de informatieklasse van de data, zowel qua Vertrouwelijkheid als qua Integriteit, moet de identificatie van de persoon strenger zijn. Dit staat beschreven in het hoofdstuk Identificatie als maatregel. 

5.1.2.

...

4.4. Integriteit van de gegevens betrokken in het authenticatieproces

Validatie

Het is belangrijk om in de hierboven beschreven processen voldoende controles te voorzien om de integriteit van de gebruikte gegevens te borgen. Dat gaat dan om:

...

Voor dat laatste kun je uiteraard teruggrijpen naar de Soll om te verifiëren of de gebruiker recht heeft op een bepaalde rol, en indien ja, dewelke.
Afhankelijk van de informatieklasse, ga je ook strenger moeten zijn. De details over welke controles wanneer nodig zijn staan beschreven in het Overzicht en integratie van de maatregelen. Belangrijk is daarbij te beseffen dat de strengste maatregel de bepalende is. Is je informatie Klasse 2 voor Vertrouwelijkheid en Klasse 4 voor Integriteit, dan moet je de controle implementeren voor Klasse 4.

5.1.2.

...

4.5. Beschikbaarheid van het autorisatieproces

Link met de informatieklasse

Het autorisatieproces om een gebruiker te autoriseren moet even beschikbaar zijn als de toepassing waartoe deze gebruiker zich wil laten autoriseren. Als je gebruik maakt van een autorisatiesysteem onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.