Page Comparison

Excerpt

name	Inleiding

Toegangsbeveiliging omvat de maatregelen en richtlijnen op basis waarvan de identificatie, authenticatie en autorisatie van gebruikers tot informatie en bedrijfsmiddelen worden

Excerpt

name	Inleiding

Toegangsbeveiliging omvat de maatregelen en richtlijnen op basis waarvan de identificatie, authenticatie en autorisatie van gebruikers tot informatie en bedrijfsmiddelen worden bepaald.

Het beleid voor toegangsbeveiliging beschrijft de maatregelen die de organisatie moet nemen om ervoor te zorgen dat alleen bevoegde personen toegang hebben tot informatie en informatiesystemen.

DOELSTELLINGEN

Het beleid draagt bij tot de realisatie van volgende informatieveiligheidsdoelstellingen van de organisatie:

Filter by label (Content by label)

showLabels	false
showSpace	false
excerptType	rich content
cql	label = "doelstellingen" and label = "toegangsbeveiliging"

DREIGINGEN

Het beleid draagt bij om de volgende dreigingen te verminderen of te voorkomen:

Filter by label (Content by label)

showLabels	false
maxCheckbox	false
sort	title
showSpace	false
reverse	false
cql	label = "dreiging" and label = "toegangsbeveiliging"

Identificatie, authenticatie en autorisatie

Toegangsbeveiliging is een fundamenteel aspect van informatieveiligheid en wordt onderverdeeld in drie kernprocessen: identificatie, authenticatie en autorisatie. Deze processen werken samen om te verzekeren dat alleen bevoegde personen toegang krijgen tot informatie en informatiesystemen.

Identificatie: Dit is de eerste stap waarbij een fysieke persoon zichzelf kenbaar maakt aan een systeem door middel van een interactieve account. Een account moet gekoppeld zijn aan een fysieke persoon geïdentificeerd door een identiteit. Ook systemen kunnen zich aanmelden bij een ander systeem door middel van een niet-interactieve account. In dat geval moet geen identiteit gekoppeld worden aan de account. Via accounts kan men acties op een systeem ook volgen en controleren. Identiteiten worden beheerd via een proces van identiteitsbeheer, accounts worden beheerd via een proces van accountbeheer.

Authenticatie: Tijdens authenticatie wordt geverifieerd of de identiteit van de account legitiem is, gewoonlijk door het vragen om iets dat de persoon die de account gebruikt, weet (zoals een wachtwoord), iets dat de persoon heeft (zoals een smartcard of token), of iets dat de persoon is (zoals een vingerafdruk of een ander biometrisch kenmerk).

Autorisatie: Na identificatie en authenticatie bepaalt autorisatie welke rechten en privileges aan de geauthenticeerde account worden toegekend. Dit proces regelt de toegang tot verschillende resources binnen het systeem op basis van gebruikersrollen, beleidslijnen en regels.

Type accounts

Accounts variëren in soort en functie, elk met hun eigen beveiligingseisen. De volgende tabel biedt een overzicht van de diverse soorten accounts.

Interactieve accounts	Gebruikersaccounts	Standaard gebruikersaccounts: Interactieve accounts gebruikt door één enkele persoon om toegang te verkrijgen tot zijn/haar digitale werkplek, het bedrijfsnetwerk en meerdere toepassingen via SSO (Single Sign-On).
		Niet-standaard gebruikersaccounts: Interactieve accounts gebruikt door één enkele persoon om toegang te verkrijgen tot een specifieke toepassing als gebruiker.
		Gedeelde gebruikersaccounts: Interactieve gebruikersaccount die gedeeld wordt door meerdere personen om toegang te krijgen tot een specifieke toepassing.
		Gast accounts: Een gastaccount is een gedeeld maar zeer beperkt gebruikersaccount dat bedoeld is voor personen die geen regelmatige toegang tot een systeem hebben en geen medewerkers zijn. Gastaccounts hebben zeer beperkte privileges en beperkingen op systeemtoegang.
	Beheersaccounts	Superuser accounts: Deze accounts worden automatisch geïnstalleerd en hebben de hoogste rechten op een systeem. Voorbeelden zijn: Administrator (Windows), root (Linux/Unix), sa (SQL Server), sysadmin (Oracle Database), System Administrator (Oracle E-Business Suite), EC2 Instance Connect (AWS), SAP* (SAP ERP), etc. Met deze accounts kan men alle geprivilegieerde taken uitvoeren, zoals het wijzigen van systeembestanden, installeren of verwijderen van nieuwe software, starten en stoppen van services, onderhouden van accounts, toekennen van toegang tot bestanden, etc.
		BeheersaccountsPersoonlijke beheersaccounts (ook genaamd geprivilegieerde accounts): Interactieve accounts gebruikt door één enkele persoon voor het uitvoeren van bepaalde geprivilegieerde taken, zoals het wijzigen van systeembestanden, installeren of verwijderen van nieuwe software, starten en stoppen van services, onderhouden van accounts, toekennen van toegang tot bestanden, etc.
Niet-interactieve accounts	Technische accounts	Systeemaccounts: Systeemaccounts worden automatisch aangemaakt door het besturingssysteem of specifieke toepassingen voor processen en services op systeemniveau. Deze accounts worden intern door het systeem gebruikt en zijn niet bedoeld voor directe gebruikersinteractie.
		Serviceaccounts: Serviceaccounts worden gebruikt door services, toepassingen of processen om te communiceren met het besturingssysteem of andere services. Deze accounts hebben vaak specifieke machtigingen die zijn afgestemd op de behoeften van de service of toepassing die ze ondersteunen en worden intern door het systeem gebruikt en zijn niet bedoeld voor directe gebruikersinteractie.
	Andere	Anonieme accounts (Anonymus, Public): Sommige systemen ondersteunen anonieme accounts waarmee gebruikers toegang hebben tot bepaalde bronnen of services zonder expliciete verificatiegegevens te verstrekken. Deze accounts hebben doorgaans zeer beperkte bevoegdheden (bv enkel leesrechten), en worden gebruikt om algemene toegangsrechten toe te kennen voor elke gebruiker van het systeem.

Identificatie

Identiteitsbeheer

Voor het verlenen van toegang tot informatie en informatiesystemen voor een persoon moet een interactieve account worden aangemaakt, die moet gekoppeld wordt aan een geverifieerde persoon of fysieke identiteit. Hiertoe moet een organisatie een proces van identiteitsbeheer opzetten. Afhankelijk van de vertrouwelijkheid en integriteit van de informatie en informatiesystemen waarvoor toegang nodig is, wordt in het identificatieproces een onderscheid gemaakt tussen zwakke en sterke identificatie bij het creëren van een identiteit:

Zwakke identiteit: 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 gecertificeerde bron (bijvoorbeeld een e-mailadres of telefoonnummer);
Sterke identiteit: Validatie van de identiteit op basis van een door de Belgische federale overheid geregistreerde of gecertificeerde bron (bijvoorbeeld het rijksregisternummer).

Meer informatie: https://vlaamseoverheid.atlassian.net/wiki/spaces/ICR/pages/6425710555/5.1.2.+Aanvullende+informatie+over+de+maatregelen+IAM#5.1.2.1.-Identificatie-als-maatregel

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Volgend minimale validatie van de identiteit MOET worden toegepast bij het beheer van identiteiten:

Standaard gebruikersaccounts: sterke identiteit vereist;
Niet-standaard gebruikersaccounts:
- Voor een account die toegang geeft tot een systeem met data van Informatieklasse 1 (integriteit en vertrouwelijkheid): geen identiteit vereist.
- Voor een account die toegang geeft tot een systeem met data van Informatieklasse 2 (integriteit en vertrouwelijkheid): zwakke identiteit voldoende.
- Voor een account die toegang geeft tot een systeem met data van Informatieklasse 3 en hoger (integriteit en vertrouwelijkheid): sterke identiteit vereist.
Gedeelde gebruikersaccounts en gast accounts: geen identiteit vereist;
Superuser accounts: geen identiteit vereist (accounts worden automatisch aangemaakt bij opzet van een systeem);
Persoonlijk beheersaccounts: sterke identiteit vereist;
Niet-interactieve accounts: geen identiteit vereist.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor de registratie, het wijzigen en het verwijderen van identiteiten. Dit proces MOET voldoen aan volgende richtlijnen:

Identiteiten MOETEN worden geregistreerd in een centraal systeem;
Elke fysieke persoon die toegang nodig heeft tot een systeem MOET een unieke identiteit krijgen voor alle systemen;
Een fysieke persoon MAG slechts één enkele identiteit hebben;
Het beheer van identiteiten MOET gebeuren door geautoriseerde personen binnen of namens de organisatie;
Er MOET een periodieke controle worden uitgevoerd om na te gaan of een identiteit nog noodzakelijk is;
Het aanmaken, wijzigen of verwijderen van identiteiten MOET worden gelogd.

Accountbeheer

Standaard gebruikersaccounts

Standaard gebruikersaccounts zijn de interactieve accounts gebruikt door medewerkers om toegang te verkrijgen tot de digitale werkplek, het bedrijfsnetwerk en meerdere toepassingen via SSO (Single Sign-On). Een standaard gebruikersaccount is uniek voor een individu waardoor het de aansprakelijkheid en traceerbaarheid van acties mogelijk maakt en de beveiliging verbetert door gebruik te maken van persoonlijke authenticatiemethoden zoals wachtwoorden en multifactorauthenticatiezoals wachtwoorden en multifactorauthenticatie.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor het aanmaken, het wijzigen en het verwijderen van standaard gebruikersaccount. Dit proces MOET voldoen aan volgende richtlijnen:

Accounts MOETEN worden geregistreerd in een centraal systeem;
Het aanmaken, wijzigen of verwijderen van accounts MOET worden gelogd.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het creëren van standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

Accounts MOETEN Standaard gebruikersaccounts MOGEN ENKEL worden aangemaakt voor en toegewezen aan natuurlijke personen (individuen) die voor of namens de organisatie werken (intern personeel en contractanten) om dagelijkse taken uit te voeren;
Elke gebruiker MOET kunnen worden geïdentificeerd door een unieke identiteit, en dit MOET een sterke identiteit zijn;
Aan één en dezelfde medewerker MAG SLECHTS ÉÉN enkele account standaard gebruikersaccount worden toegekend;
Elke account standaard gebruikersaccount MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen,
Aan elke account standaard gebruikersaccount is een verantwoordelijke toegewezen verschillend van de gebruiker (bijvoorbeeld leidinggevende) als back-up.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De-activatie en verwijderen van standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

Bij einde dienstverband van een medewerker, MOET de account binnen de 24 uur worden gedeactiveerd (d.w.z onbeschikbaar gemaakt worden om te gebruiken);
Accounts die niet worden gebruikt MOETEN worden gedeactiveerd na 13 maanden inactiviteit;
Accounts die werden gedeactiveerd MOETEN permanent worden ingetrokken na 24 maanden inactiviteit;
Permanent ingetrokken gebruikersaccounts accounts MOGEN NIET opnieuw worden uitgegeven;
Er MOET een specifieke procedure worden voorzien om “urgente uitdiensttreding” te behandelen, waarbij een account ONMIDDELLIJK wordt gedeactiveerd;
Waar mogelijk MOET worden ingesteld dat accounts automatisch verlopen op een gedefinieerde datum:
- Wanneer tijdelijke toegang nodig is, MOETEN accounts onmiddellijk worden gedeactiveerd nadat de gebruiker de taak heeft voltooid waarvoor de toegang was verleend,
- Accounts toegewezen aan contractanten MOETEN worden ingesteld op basis van de vervaldatum van het contract;
- Accounts die aangemaakt worden op basis van ondertekende contracten voor een terugkerende taak MOETEN worden telkens geactiveerd voor de duur van hun geplande interventies en worden tussentijds gedeactiveerd.

Niet-standaard gebruikersaccounts

Een niet-standaard gebruikersaccount is een interactieve accounts gebruikt door een medewerker om toegang te verkrijgen tot een één bepaald specifiek systeem dat bovendien niet via het SSO-principe bereikbaar is met de standaard gebruikersaccount. Een niet-standaard gebruikersaccount is net zoals een standaard gebruikersaccount uniek voor een individuele gebruiker, waardoor het de aansprakelijkheid en traceerbaarheid van acties mogelijk maakt en de beveiliging verbetert door gebruik te maken van persoonlijke authenticatiemethoden zoals wachtwoorden en multifactorauthenticatie.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het creëren van niet-standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

Accounts MOETEN worden aangemaakt voor en toegewezen aan natuurlijke personen (individuen) die voor of namens de organisatie werken (intern personeel en contractanten) om dagelijkse taken uit te voeren;

Elke gebruiker MOET kunnen worden geïdentificeerd door een unieke identiteit, dit MOET een sterke identiteit zijn voor systemen die data bevatten met Informatieklasse 3 en hoger;

Aan één en dezelfde medewerker MAG SLECHTS ÉÉN enkele account worden toegekend per systeem;

Elke account MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen

Er MOET een formeel en gedocumenteerd proces zijn voor het aanmaken, het wijzigen en het verwijderen van niet-standaard gebruikersaccount. Dit proces MOET voldoen aan volgende richtlijnen:

Accounts MOETEN worden geregistreerd in een centraal systeem;
Het aanmaken, wijzigen of verwijderen van accounts MOET worden gelogd.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De-activatie en verwijderen Het creëren van niet-standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

Bij einde dienstverband van een medewerker, MOET de account binnen de 24 uur worden gedeactiveerd (d.w.z onbeschikbaar gemaakt worden om te gebruiken);
Accounts die niet worden gebruikt MOETEN worden gedeactiveerd na 13 maanden inactiviteit;
Accounts die werden gedeactiveerd MOETEN permanent worden ingetrokken na 24 maanden inactiviteit;
Permanent ingetrokken gebruikersaccounts MOGEN NIET opnieuw worden uitgegeven;

Gedeelde gebruikersaccount

Gedeelde gebruikersaccounts zijn interactieve gebruikersaccount die gedeeld wordt door meerdere personen om toegang te krijgen tot een specifiek systeem. Een gedeelde gebruikersaccount, die toegankelijk is voor meerdere individuen, bemoeilijkt de toewijzing van acties aan specifieke gebruikers en vergroot de beveiligingsrisico's door gedeelde wachtwoorden. Hoewel er functionele redenen kunnen zijn om een gedeelde account te gebruiken, wordt dit over het algemeen afgeraden

Accounts MOETEN worden aangemaakt voor en toegewezen aan natuurlijke personen (individuen) die voor of namens de organisatie werken (intern personeel en contractanten) om dagelijkse taken uit te voeren;
Elke gebruiker MOET kunnen worden geïdentificeerd door een unieke identiteit, dit MOET een sterke identiteit zijn voor systemen die data bevatten met Informatieklasse 3 en hoger;
Aan één en dezelfde medewerker MAG SLECHTS ÉÉN enkele account worden toegekend per systeem;
Elke account MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van gedeelde gebruikersaccounts MAG NIET, als dit in uitzonderlijke gevallen toch noodzakelijk is, MOET dit aan volgende voorwaarde voldoen:

Motivering voor de uitzondering MOET worden geregistreerd en MOET formeel worden goedgekeurd door een directielid;
Het gebruik van gedeelde gebruikersaccounts MOET worden gemonitord, inclusief de registratie van het tijdstip van toegang, de reden voor het gebruik van het gedeelde gebruikersaccount en de persoon het account gebruikt;
Gedeelde gebruikersaccounts MOGEN NIET gebruikt worden voor systeembeheer en andere kritieke functies.

Gast accounts

Een gastaccount is een gedeeld maar zeer beperkt gebruikersaccount dat bedoeld is voor personen die geen regelmatige toegang tot het systeem hebben en geen medewerkers zijn (bijvoorbeeld bezoekers op een kiosk-PC).

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van gast accounts MOET aan volgende voorwaarde voldoen:

Gebruik van een gast account MOET worden geregistreerd en MOET formeel worden goedgekeurd door een directielid;
Gast accounts MOGEN ENKEL leesrechten hebben op publieke data van Informatieklasse 1 en geen andere toegangsrechten.

Superuser accounts

Superuser accounts (ook genaamd build-in accounts) worden automatisch geïnstalleerd bij initiële set-up van een systeem en hebben de allerhoogste rechten op een systeem. Voorbeelden zijn: Administrator (Windows), root (Linux/Unix), sa (SQL Server), sysadmin (Oracle Database), System Administrator (Oracle E-Business Suite), EC2 Instance Connect (AWS), SAP* (SAP ERP), etc. Met deze accounts kan men alle geprivilegieerde taken uitvoeren, zoals het wijzigen van systeembestanden, installeren of verwijderen van nieuwe software, starten en stoppen van services, onderhouden van accounts, toekennen van toegang tot bestanden, etc

De-activatie en verwijderen van niet-standaard gebruikersaccounts MOET volgende richtlijnen in acht nemen:

Bij einde dienstverband van een medewerker, MOET de account binnen de 24 uur worden gedeactiveerd (d.w.z onbeschikbaar gemaakt worden om te gebruiken);
Accounts die niet worden gebruikt MOETEN worden gedeactiveerd na 13 maanden inactiviteit;
Accounts die werden gedeactiveerd MOETEN permanent worden ingetrokken na 24 maanden inactiviteit;
Permanent ingetrokken gebruikersaccounts MOGEN NIET opnieuw worden uitgegeven;

Gedeelde gebruikersaccount

Gedeelde gebruikersaccounts zijn interactieve gebruikersaccount die gedeeld wordt door meerdere personen om toegang te krijgen tot één bepaald specifiek systeem. Een gedeelde gebruikersaccount, die toegankelijk is voor meerdere individuen, bemoeilijkt de toewijzing van acties aan specifieke gebruikers en vergroot de beveiligingsrisico's door gedeelde wachtwoorden. Hoewel er functionele redenen kunnen zijn om een gedeelde account te gebruiken, wordt dit over het algemeen afgeraden.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van gedeelde gebruikersaccounts MAG NIET, als dit in uitzonderlijke gevallen toch noodzakelijk is, MOET dit aan volgende voorwaarde voldoen:

Motivering voor de uitzondering MOET worden geregistreerd en MOET formeel worden goedgekeurd door een directielid;
Het gebruik van gedeelde gebruikersaccounts MOET worden gemonitord, inclusief de registratie van het tijdstip van toegang, de reden voor het gebruik van het gedeelde gebruikersaccount en de persoon het account gebruikt;
Gedeelde gebruikersaccounts MOGEN NIET gebruikt worden voor systeembeheer en andere kritieke functies.

Gast accounts

Een gastaccount is een gedeeld maar zeer beperkt gebruikersaccount dat bedoeld is voor personen die geen regelmatige toegang tot het systeem hebben en geen medewerkers zijn (bijvoorbeeld bezoekers op een kiosk-PC).

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van superuser gast accounts MOET aan volgende voorwaarde voldoen:

Het initiële paswoord Gebruik van een superuser gast account MOET worden geregistreerd en MOET ONMIDDELLIJK worden veranderd bij de installatie van een systeem door een paswoord dat enkel gekend is door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats.
Superuser accounts MOGEN ENKEL worden gebruikt voor de initiële installatie van een systeem en bij noodgevallen;
Superuser accounts MOGEN NIET worden gebruikt voor de normale beheerstaken aan een systeem, hiervoor MOETEN beheersaccounts worden aangemaakt.

Beheersaccounts

Beheersaccounts zijn interactieve accounts gebruikt door medewerker voor het uitvoeren van bepaalde geprivilegieerde taken op een systeem

formeel worden goedgekeurd door een directielid;
Gast accounts MOGEN ENKEL leesrechten hebben op publieke data van Informatieklasse 1 en geen andere toegangsrechten.

Superuser accounts

Superuser accounts (ook soms genaamd built-in accounts) worden automatisch geïnstalleerd bij initiële set-up van een systeem en hebben de allerhoogste rechten op een systeem. Voorbeelden zijn: Administrator (Windows), root (Linux/Unix), sa (SQL Server), sysadmin (Oracle Database), System Administrator (Oracle E-Business Suite), EC2 Instance Connect (AWS), SAP* (SAP ERP), etc. Met deze accounts kan men alle geprivilegieerde taken uitvoeren, zoals het wijzigen van systeembestanden, installeren of verwijderen van nieuwe software, starten en stoppen van services, onderhouden van accounts, toekennen van toegang tot bestanden, etc. Een beheersaccount (ook genaamd geprivilegieerde account of account met privileges) is een type gebruikersaccount dat meer rechten en privileges heeft dan gewone gebruikersaccounts. Deze verhoogde privileges stellen de gebruiker in staat om kritieke administratieve taken uit te voeren, zoals het uitvoeren van onderhoudstaken die diepgaande toegang tot het systeem vereisen. Vanwege de verhoogde toegang die deze accounts bieden, worden ze als een significant beveiligingsrisico beschouwd indien ze niet goed worden beheerd en beschermdvan services, onderhouden van accounts, toekennen van toegang tot bestanden, etc.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Beheersaccounts MOETEN voldoen aan dezelfde implementatiemaatregelen als standaard gebruikersaccounts.

Een medewerker die beheerstaken uitvoert MOET een een beheersaccount gebruiken en niet zijn standaard gebruikers account. Een beheer account MOET gescheiden zijn van de standaard gebruikersaccount en alleen worden gebruikt wanneer de beheerstaken vereist zijn.

Een beheersaccount MAG worden afgeleid uit een superuser account (die alle privileges heeft), maar bij voorkeur worden beheersaccounts voor complexe systemen opgesplitst naargelang het type privileges, zoals bijvoorbeeld aparte beheersaccounts voor:

Het nemen van back-ups;
Het creëren van accounts en toekennen van toegangsrechten;
Het onderhouden van systeem software;
Etc.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor de creatie, het wijzigen en het verwijderen van beheersaccounts dat MOET voldoen aan volgende richtlijnen:

Een beheersaccount kan enkel worden aangevraagd door een leidinggevende en MOET expliciet worden goedgekeurd;

Een beheersaccount MOET worden toegewezen aan een individuele medewerker en MOET worden verstrekt met sterke identificatie;

Het gebruik van beheersaccounts MOET strikt individueel zijn en NOOIT gedeeld; indien meerdere medewerkers beheerstaken op een zelfde systeem dienen uit te voeren MOETEN zij elk een aparte beheersaccount gebruiken;

Het aantal beheersaccounts per systeem MOET tot een minimum beperkt worden;

De lijst met beheersaccounts per systeem MOET minstens jaarlijks worden herzien en niet gebruikte accounts MOETEN verwijderd worden;

Er MOET een actieve logging, opvolging en periodieke rapportering van de activiteiten die door een beheersaccount worden uitgevoerd, opgezet worden

Het gebruik van superuser accounts MOET aan volgende voorwaarde voldoen:

Het initiële paswoord van een superuser account MOET ONMIDDELLIJK worden veranderd bij de installatie van een systeem door een paswoord dat enkel gekend is door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats.
Superuser accounts MOGEN ENKEL worden gebruikt voor de initiële installatie van een systeem en bij noodgevallen;
Superuser accounts MOGEN NIET worden gebruikt voor de normale beheerstaken aan een systeem, hiervoor MOETEN andere persoonlijke beheersaccounts worden aangemaakt;
Het gebruik van superuser accounts MOET worden gemonitord, inclusief de registratie van het tijdstip van toegang, de reden voor het gebruik en de persoon het account gebruikt.

Persoonlijke beheersaccounts

Dit zijn interactieve accounts gebruikt door medewerker voor het uitvoeren van bepaalde geprivilegieerde taken op een systeem, zoals het wijzigen van systeembestanden, installeren of verwijderen van nieuwe software, starten en stoppen van services, onderhouden van accounts, toekennen van toegang tot bestanden, etc. Een persoonlijke beheersaccount (ook genaamd geprivilegieerde account of account met privileges) is een type gebruikersaccount dat meer rechten en privileges heeft dan gewone gebruikersaccounts. Deze verhoogde privileges stellen de gebruiker in staat om kritieke administratieve taken uit te voeren, zoals het uitvoeren van onderhoudstaken die diepgaande toegang tot het systeem vereisen. Vanwege de verhoogde toegang die deze accounts bieden, worden ze als een significant beveiligingsrisico beschouwd indien ze niet goed worden beheerd en beschermd.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Wanneer per uitzondering beheersaccounts dienen toegekend te worden aan niet-medewerkers zoals leveranciers (bijvoorbeeld omwille van onderhoudsactiviteiten) dan MOET dit bijkomend voldoen aan de volgende richtlijnen:

Accounts MOETEN worden telkens geactiveerd voor de duur van hun geplande interventies en worden tussentijds gedeactiveerd;
Elke gebruik MOET worden gelogd en nagekeken worden door een leidinggevende ONMIDDELLIJK na het gebruik.

Technische accounts

Technische accounts zijn niet-interactieve accounts zoals systeemaccounts en service accounts. Systeemaccounts worden automatisch aangemaakt door het besturingssysteem of specifieke toepassingen voor processen en services op systeemniveau. Deze accounts worden intern door het systeem gebruikt en zijn niet bedoeld voor directe gebruikersinteractie. Service accounts worden gebruikt door services, toepassingen of processen om te communiceren met het besturingssysteem of andere services. Deze accounts hebben vaak specifieke machtigingen die zijn afgestemd op de behoeften van de service of toepassing die ze ondersteunen en worden intern door het systeem gebruikt en zijn eveneens niet bedoeld voor directe gebruikersinteractie.

Technische accounts worden gebruikt voor het uitvoeren van geautomatiseerde taken, het beheren van applicatieservices, het faciliteren van communicatie tussen systemen, en voor specifieke onderhouds- en beheerfuncties binnen een IT-infrastructuur. In tegenstelling tot gebruikersaccounts zijn technische accounts niet gelinkt aan een geverifieerde persoon en kunnen ze niet worden gebruikt voor interactieve login met een systeem.

Technische accounts hebben vaak significante rechten nodig om hun taken uit te voeren en moeten daarom zorgvuldig worden beheerd om veiligheidsrisico's te minimaliseren

Persoonlijke beheersaccounts MOETEN voldoen aan dezelfde implementatiemaatregelen als standaard gebruikersaccounts.
Een medewerker die beheerstaken uitvoert MOET een een persoonlijke beheersaccount gebruiken en niet zijn standaard gebruikers account. Een beheer account MOET gescheiden zijn van de standaard gebruikersaccount en alleen worden gebruikt wanneer de beheerstaken vereist zijn.
Een beheersaccount MAG worden afgeleid uit een superuser account (die alle privileges heeft), maar bij voorkeur worden beheersaccounts voor complexe systemen opgesplitst naargelang het type privileges, zoals bijvoorbeeld aparte beheersaccounts voor:
Het nemen van back-ups;
Het creëren van accounts;
Het toekennen van toegangsrechten;
Het onderhouden van systeem software;
Etc.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formeel en goed gedocumenteerd proces bestaan zijn voor de creatie, het wijzigen en het verwijderen van technische accounts, dat MOET voldoen aan de volgende vereisten:

Het doel van elk technisch account, de verantwoordelijke persoon en de systemen of diensten die het account gebruikt MOETEN gedocumenteerd worden;
Elk technisch account MOET uniek zijn voor zijn specifieke functie;
Het paswoord van een technische account MAG ENKEL gekend zijn door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats;
Technische accounts die in productieomgevingen worden gebruikt MOETEN gescheiden worden van accounts in de ontwikkelings- en testomgevingen;
Standaard ingebouwde (built-in) accounts MOETEN, indien mogelijk, worden uitgeschakeld of hernoemd.
Technische accounts MOETEN de levenscyclus van de systemen of diensten die er gebruik van maken volgen en MOETEN worden verwijderd wanneer deze niet langer nodig zijn.

Authenticatie

Authenticatiemechanismen

Het authenticatiemechanisme is een proces of methode om de identiteit van een gebruiker of entiteit te verifiëren voordat toegang wordt verleend tot een systeem. Dit proces zorgt ervoor dat de persoon of het systeem daadwerkelijk is wie of wat het beweert te zijn. Authenticatiemechanismen kunnen variëren van eenvoudige wachtwoordcontroles tot meer complexe systemen zoals biometrische scans, hardware tokens, smartcards, digitale certificaten of multi-factor authenticatie (MFA) waarbij meerdere methoden gecombineerd worden voor een verhoogd beveiligingsniveau.

In het kader van de Europese eIDAS-verordening (Verordening (EU) nr. 910/2014), zijn er drie betrouwbaarheidsniveaus:

Lage mate van zekerheid (betrouwbaarheidsniveau laag):
- Basisverificatie en authenticatie;
- Meestal gebruikt voor diensten met een laag risico;
- Minimale vereisten voor identiteitsverificatie;
- Voorbeelden hiervan zijn toegang tot openbare informatie of eenvoudige online diensten.
Substantiële mate van zekerheid (betrouwbaarheidsniveau substantieel):
- Strengere verificatie en authenticatie;
- Geschikt voor diensten met een gemiddeld risico;
- Vereist een sterkere identiteitsverificatie;
- Gebruikt voor diensten zoals online bankieren of toegang tot gevoelige persoonlijke gegevens.
Hoge mate van zekerheid (betrouwbaarheidsniveau hoog):
- Hoogste niveau van verificatie en authenticatie;
- Gereserveerd voor diensten met een hoog risico;
- Rigoureuze identiteitsverificatie, vaak met face-to-face processen;
- Gebruikt voor kritieke diensten zoals het ondertekenen van juridisch bindende documenten of toegang tot vertrouwelijke overheidsdiensten.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Volgend minimaal authenticatieniveau MOET worden toegepast op basis van de eIDAS-schalen:

Hoog
- Alle externe toegang (komende van buiten de netwerkperimeter van Digitaal Vlaanderen)
- Alle interne toegang door beheersaccounts
- Alle interne toegang tot informatieklasse 5
Substantieel
- Alle interne toegang tot informatieklasse 3 en 4
Zwak
- Alle interne toegang tot informatieklasse 2
- Toegang door technische accounts, gedeelde accounts en andere gevallen niet beschreven hierboven, mits bijkomende maatregelen

Elk authenticatiemechanisme dat op zijn minst geen gebruik maakt van een unieke gebruikersaccount en wachtwoord MOET formeel worden goedgekeurd.

Voor Digitaal Vlaanderen zijn de beschikbare authenticatiemiddelen de volgende:

eIDAS schaal

Authenticatiemiddel

URN

Authenticatie niveau

CSAM level

Hoog

eID en aangesloten kaartlezer

urn:be:vlaanderen:authmech:eid

35

500

Hoog

Itsme

urn:be:vlaanderen:authmech:itsme

30

450

Hoog

Eidas High

urn:be:vlaanderen:authmech:eidashigh

30

450

Substantieel

FIDO Vlaanderen

urn:be:vlaanderen:authmech:fido

26

400

Substantieel

myID

urn:be:vlaanderen:authmech:myid

26

400

Substantieel

Beveiligingscode via mobiele app (OTP via app)

urn:be:vlaanderen:authmech:csamtotp

26

400

Substantieel

Beveiligingscode via SMS (OTP via sms)

urn:be:vlaanderen:authmech:csamsms

25

400

Substantieel

Beveiligingscode via e-mail (OTP via mail)

urn:be:vlaanderen:authmech:mailotp

21

400

Substantieel

Eidas Substantial

urn:be:vlaanderen:authmech:eidassubstantial

21

400

NVT

CBA (Certificate Based Authenticatie)

urn:be:vlaanderen:authmech:tlsclient

19

NVT

Alfa-windows-account

urn:be:vlaanderen:authmech:kerberos

12

NVT

LeerID

urn:be:vlaanderen:authmech:leerid

10

NVT

Gebruikersnaam/wachtwoord via CLDAP

urn:be:vlaanderen:authmech:password

10

NVT

Low

Gebruikersnaam/wachtwoord via CSAM

urn:be:vlaanderen:authmech:csampassword

5

200

Low

Unlinked Gebruikersnaam/wachtwoord via CSAM

urn:be:vlaanderen:authmech:csamselfreg

5

100

Single Sign-On

Single sign-on (afgekort SSO) stelt eindgebruikers in staat om eenmalig in te loggen waarna automatisch toegang wordt verschaft tot meerdere applicaties en resources in het netwerk. Een voorbeeld is dat een eindgebruiker inlogt op zijn werkstation met een standaard gebruikersaccount waarna achter de schermen met behulp van een Kerberos-protocol ook automatisch ingelogd kan worden op netwerkvoorzieningen en/of bedrijfstoepassingen binnen het netwerk. De eindgebruiker hoeft hierdoor niet iedere keer opnieuw in te loggen bij een toepassing, en het inlogscherm van een toepassing wordt niet langer getoond.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Single sign-on MOET verlopen via het standaard gebruikersaccount.

Single sign-on MAG worden toegepast voor toegang tot en met informatieklasse 3.

Voor toegang tot informatieklasse 4 MAG single sign-on ENKEL gebruikt worden binnen het interne netwerk.

Single sign-on MAG NIET gebruikt worden voor toegang tot informatieklasse 5.

Bijkomende vereiste voor technische accounts

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van technische accounts MOET voldoen aan volgende richtlijnen:

Het gebruik van een technische account dient bij voorkeur te gebeuren via een Privileged Access Management (PAM) oplossing;
Wachtwoorden dienen automatisch te worden gegenereerd via een PAM oplossing of wachtwoordbeheeroplossing;
Wachtwoorden moeten complex zijn, bestaande uit ten minste 50 karakters;
Na elk gebruik van een technisch account of ten minste jaarlijks moet automatisch een nieuw wachtwoord worden gegenereerd;
De uitzonderingen waarbij de wachtwoorden van technische accounts niet via een PAM oplossing worden beheerd (bijvoorbeeld in kader van disaster recovery procedures) moeten formeel worden goedgekeurd.

Veilige inlogprocedure

De inlogprocedure is de functionaliteit die wordt gebruikt om gebruikers interactieve toegang te geven tot systemen of applicaties, zoals het invoeren van een gebruikersnaam en wachtwoord.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Elke inlogprocedure MOET voldoen aan volgende minimale vereisten:

Inloggegevens enkel valideren als deze volledig zijn ingevoerd;
Het ingevoerde wachtwoord niet permanent weergeven wanneer het wordt ingevoerd (bv. sterretjes dienen te worden weergegeven wanneer een gebruiker een wachtwoord invoert);
Niet aangeven welk deel van de inloggevens (gebruikersnaam of wachtwoord) correct of onjuist is. Als een onjuist of onvolledig wachtwoord wordt ingevuld, dient in het feedback foutbericht, bv. vermeld te worden "gebruikersnaam of wachtwoord is ongeldig";
Geen legitieme gebruikersaccount weergeven totdat de inlogprocedure met succes is voltooid;
Geen helpberichten verstrekken tijdens de inlogprocedure die een niet-geautoriseerde gebruiker zouden helpen;
Het aantal mislukte inlogpogingen beperken tot maximaal 10;
Na 10 opeenvolgende mislukte inlogpogingen een wachttijd instellen van minimaal 30 minuten vooraleer een nieuwe inlogpoging kan worden ondernomen

Sessie -en schermvergrendeling

Sessievergrendeling en schermvergrendeling zijn beveiligingsfuncties die gebruikt worden om ongeautoriseerde toegang tot apparaten en applicaties te voorkomen. Sessievergrendeling houdt in dat een gebruikerssessie op een computer of applicatie automatisch wordt vergrendeld na een periode van inactiviteit of wanneer de gebruiker ervoor kiest om de sessie handmatig te vergrendelen. Tijdens een vergrendelde sessie blijft de gebruiker ingelogd, maar is toegang tot de sessie beperkt tot de gebruiker zich opnieuw authenticeert. Schermvergrendeling daarentegen betreft het vergrendelen van het scherm van een apparaat, zoals een computer, tablet of smartphone, waarbij de toegang tot de informatie op het scherm wordt geblokkeerd. Om toegang te herwinnen, is herauthenticatie vereist. Beide maatregelen zijn essentieel voor het beschermen van persoonlijke en professionele gegevens tegen onbevoegde toegang, vooral in situaties waar de gebruiker zijn werkplek tijdelijk verlaat.

persoonlijke beheersaccounts dat MOET voldoen aan volgende richtlijnen:

Een beheersaccount kan enkel worden aangevraagd door een leidinggevende en MOET expliciet worden goedgekeurd;
Een beheersaccount MOET worden toegewezen aan een individuele medewerker en MOET worden verstrekt met sterke identificatie;
Het gebruik van beheersaccounts MOET strikt individueel zijn en NOOIT gedeeld;
Indien meerdere medewerkers beheerstaken op een zelfde systeem dienen uit te voeren MOETEN zij elk een aparte beheersaccount gebruiken;
Het aantal beheersaccounts per systeem MOET tot een minimum beperkt worden;
De lijst met beheersaccounts per systeem MOET minstens jaarlijks worden herzien en niet gebruikte accounts MOETEN verwijderd worden;
Er MOET een actieve logging, opvolging en periodieke rapportering van de activiteiten die door een beheersaccount worden uitgevoerd, opgezet worden.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Wanneer per uitzondering beheersaccounts dienen toegekend te worden aan niet-medewerkers zoals leveranciers (bijvoorbeeld omwille van onderhoudsactiviteiten) dan MOET dit bijkomend voldoen aan de volgende richtlijnen:

Accounts MOETEN worden telkens geactiveerd voor de duur van hun geplande interventies en worden tussentijds gedeactiveerd;
Elke gebruik MOET worden gelogd en nagekeken worden door een leidinggevende ONMIDDELLIJK na het gebruik.

Technische accounts

Technische accounts zijn niet-interactieve accounts zoals systeemaccounts en service accounts. Systeemaccounts worden automatisch aangemaakt door het besturingssysteem of specifieke toepassingen voor processen en services op systeemniveau. Deze accounts worden intern door het systeem gebruikt en zijn niet bedoeld voor directe gebruikersinteractie. Service accounts worden gebruikt door services, toepassingen of processen om te communiceren met het besturingssysteem of andere services. Deze accounts hebben vaak specifieke machtigingen die zijn afgestemd op de behoeften van de service of toepassing die ze ondersteunen en worden intern door het systeem gebruikt en zijn eveneens niet bedoeld voor directe gebruikersinteractie.

Technische accounts worden gebruikt voor het uitvoeren van geautomatiseerde taken, het beheren van applicatieservices, het faciliteren van communicatie tussen systemen, en voor specifieke onderhouds- en beheerfuncties binnen een IT-infrastructuur. In tegenstelling tot gebruikersaccounts zijn technische accounts niet gelinkt aan een geverifieerde persoon en kunnen ze niet worden gebruikt voor interactieve login met een systeem.

Technische accounts hebben vaak significante rechten nodig om hun taken uit te voeren en moeten daarom zorgvuldig worden beheerd om veiligheidsrisico's te minimaliseren.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formeel en goed gedocumenteerd proces bestaan voor de creatie, het wijzigen en het verwijderen van technische accounts, dat MOET voldoen aan de volgende vereisten:

Het doel van elk technisch account, de verantwoordelijke persoon en de systemen of diensten die het account gebruikt MOETEN gedocumenteerd worden;
Elk technisch account MOET uniek zijn voor zijn specifieke functie;
Het paswoord van een technische account MAG ENKEL gekend zijn door een zeer beperkt aantal verantwoordelijken; dit paswoord MOET bewaard worden op een veilige plaats;
Technische accounts die in productieomgevingen worden gebruikt MOETEN gescheiden worden van accounts in de ontwikkelings- en testomgevingen;
Standaard ingebouwde (built-in) accounts MOETEN, indien mogelijk, worden uitgeschakeld of hernoemd.
Technische accounts MOETEN de levenscyclus van de systemen of diensten die er gebruik van maken volgen en MOETEN worden verwijderd wanneer deze niet langer nodig zijn.

Authenticatie

Authenticatiemechanismen

Het authenticatiemechanisme is een proces of methode om de identiteit van een gebruiker of entiteit te verifiëren voordat toegang wordt verleend tot een systeem. Dit proces zorgt ervoor dat de persoon of het systeem daadwerkelijk is wie of wat het beweert te zijn. Authenticatiemechanismen kunnen variëren van eenvoudige wachtwoordcontroles tot meer complexe systemen zoals biometrische scans, hardware tokens, smartcards, digitale certificaten of multi-factor authenticatie (MFA) waarbij meerdere methoden gecombineerd worden voor een verhoogd beveiligingsniveau.

In het kader van de Europese eIDAS-verordening (Verordening (EU) nr. 910/2014), zijn er drie betrouwbaarheidsniveaus:

Lage mate van zekerheid (betrouwbaarheidsniveau laag):
- Basisverificatie en authenticatie;
- Meestal gebruikt voor diensten met een laag risico;
- Minimale vereisten voor identiteitsverificatie;
- Voorbeelden hiervan zijn toegang tot openbare informatie of eenvoudige online diensten.
Substantiële mate van zekerheid (betrouwbaarheidsniveau substantieel):
- Strengere verificatie en authenticatie;
- Geschikt voor diensten met een gemiddeld risico;
- Vereist een sterkere identiteitsverificatie;
- Gebruikt voor diensten zoals online bankieren of toegang tot gevoelige persoonlijke gegevens.
Hoge mate van zekerheid (betrouwbaarheidsniveau hoog):
- Hoogste niveau van verificatie en authenticatie;
- Gereserveerd voor diensten met een hoog risico;
- Rigoureuze identiteitsverificatie, vaak met face-to-face processen;
- Gebruikt voor kritieke diensten zoals het ondertekenen van juridisch bindende documenten of toegang tot vertrouwelijke overheidsdiensten.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Volgend minimaal authenticatieniveau MOET worden toegepast op basis van de eIDAS-schalen:

Hoog
- Alle externe toegang (komende van buiten de netwerkperimeter van Digitaal Vlaanderen)
- Alle interne toegang door beheersaccounts
- Alle interne toegang tot informatieklasse 5
Substantieel
- Alle interne toegang tot informatieklasse 3 en 4
Zwak
- Alle interne toegang tot informatieklasse 2
- Toegang door technische accounts, gedeelde accounts en andere gevallen niet beschreven hierboven, mits bijkomende maatregelen

Elk authenticatiemechanisme dat op zijn minst geen gebruik maakt van een unieke gebruikersaccount en wachtwoord MOET formeel worden goedgekeurd.

Voor Digitaal Vlaanderen zijn de beschikbare authenticatiemiddelen de volgende (zie ook Vlaamse overheid authenticatiemiddelen).

eIDAS schaal	Authenticatiemiddel	URN
Hoog	eID en aangesloten kaartlezer	urn:be:vlaanderen:authmech:eid
Hoog	Itsme	urn:be:vlaanderen:authmech:itsme
Hoog	Eidas High	urn:be:vlaanderen:authmech:eidashigh
Substantieel	FIDO Vlaanderen	urn:be:vlaanderen:authmech:fido
Substantieel	myID	urn:be:vlaanderen:authmech:myid
Substantieel	Beveiligingscode via mobiele app (OTP via app)	urn:be:vlaanderen:authmech:csamtotp
Substantieel	Beveiligingscode via SMS (OTP via sms)	urn:be:vlaanderen:authmech:csamsms
Substantieel	Beveiligingscode via e-mail (OTP via mail)	urn:be:vlaanderen:authmech:mailotp
Substantieel	Eidas Substantial	urn:be:vlaanderen:authmech:eidassubstantial
NVT	CBA (Certificate Based Authenticatie)	urn:be:vlaanderen:authmech:tlsclient
NVT	Alfa-windows-account	urn:be:vlaanderen:authmech:kerberos
NVT	LeerID	urn:be:vlaanderen:authmech:leerid
NVT	Gebruikersnaam/wachtwoord via CLDAP	urn:be:vlaanderen:authmech:password
Low	Gebruikersnaam/wachtwoord via CSAM	urn:be:vlaanderen:authmech:csampassword
Low	Unlinked Gebruikersnaam/wachtwoord via CSAM	urn:be:vlaanderen:authmech:csamselfreg

Single Sign-On

Single sign-on (afgekort SSO) stelt eindgebruikers in staat om eenmalig in te loggen waarna automatisch toegang wordt verschaft tot meerdere applicaties en resources in het netwerk. Een voorbeeld is dat een medewerker inlogt op zijn werkstation met de standaard gebruikersaccount waarna achter de schermen met behulp van een Kerberos-protocol ook automatisch ingelogd wordt op het bedrijfsnetwerk en op een bedrijfstoepassing zoals bijvoorbeeld Microsoft Dynamics binnen het netwerk zonder bijkomende authenticatie.

Bij SSO hoeft de eindgebruiker niet iedere keer opnieuw in te loggen bij een toepassing, en het inlogscherm van een toepassing wordt niet langer getoond.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Single sign-on MOET verlopen via het standaard gebruikersaccount.

Single sign-on MAG worden toegepast voor toegang tot en met informatieklasse 3.

Voor toegang tot informatieklasse 4 MAG single sign-on ENKEL gebruikt worden binnen het interne netwerk.

Single sign-on MAG NIET gebruikt worden voor toegang tot informatieklasse 5.

Bijkomende vereiste voor technische accounts

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Sessie -en schermvergrendeling Het gebruik van technische accounts MOET voldoen aan volgende minimale vereisten:

Werkplekken worden geconfigureerd om sessies automatisch te vergrendelen na een periode van inactiviteit van maximum vijftien (15) minuten.
Systemen worden geconfigureerd om sessies automatisch te beëindigen na een periode van inactiviteit van maximum één (1) uur.

Wachtwoordbeleid

Het gebruik van een wachtwoord

De gebruiker is in eerste instantie zelf verantwoordelijk om op een veilige manier om te springen met inloggegevens. Een wachtwoord is een vaak terugkerend aspect in de verschillende authenticatiemechanismen (zie bovenstaande tabel)

richtlijnen:

Het gebruik van een technische account dient bij voorkeur te gebeuren via een Privileged Access Management (PAM) oplossing;
Wachtwoorden dienen automatisch te worden gegenereerd via een PAM oplossing of wachtwoordbeheeroplossing;
Wachtwoorden moeten complex zijn, bestaande uit ten minste 50 karakters;
Na elk gebruik van een technisch account of ten minste jaarlijks moet automatisch een nieuw wachtwoord worden gegenereerd;
De uitzonderingen waarbij de wachtwoorden van technische accounts niet via een PAM oplossing worden beheerd (bijvoorbeeld in kader van disaster recovery procedures) moeten formeel worden goedgekeurd.

Veilige inlogprocedure

De inlogprocedure is de functionaliteit die wordt gebruikt om gebruikers interactieve toegang te geven tot systemen of applicaties, zoals het invoeren van een gebruikersnaam en wachtwoord.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De organisatie MOET zorgen dat gebruikers bewust zijn van hun verantwoordelijkheden m.b.t. het veilig omspringen met inloggegevens, deze richtlijnen moeten volgende aspecten omvatten:

Een wachtwoord is altijd persoonlijk, het delen van een wachtwoord met iemand anders MAG NIET, tenzij voor gedeelde accounts via een veilige methode die formeel is goedgekeurd;
Wachtwoorden MOGEN NIET verspreid worden via het zelfde communicatiekanaal als de account;
Wachtwoorden MOGEN NIET worden opgeschreven, tenzij voor superuser accounts of technische accounts via een veilige methode die formeel is goedgekeurd;
Wachtwoorden MOGEN NIET worden opgeslagen in een geautomatiseerd aanmeldingssysteem (bijvoorbeeld macro of browser), tenzij via een door de organisatie gevalideerde oplossing;
Wachtwoorden MOETEN onmiddellijk worden gewijzigd als er aanwijzingen zijn dat deze gecompromitteerd kunnen zijn, in dat geval MOET ook een beveiligingsincident worden gemeld;
Wanneer een nieuw wachtwoord wordt gekozen, MOET dit verschillend zijn van de laatste drie wachtwoorden die werden gebruikt;
Het gebruiken van hetzelfde wachtwoord voor privé en zakelijke doeleinden is NIET TOEGESTAAN.

Complexiteitsregels voor wachtwoorden

De complexiteitsregels verhogen de mate van onvoorspelbaarheid of willekeurigheid die een wachtwoord bezit. Hoe hoger de complexiteit, hoe moeilijker het wachtwoord te raden of te kraken is door brute force-aanvallen of andere hacking-methoden. De complexiteit wordt beïnvloed door verschillende factoren, zoals de lengte van het wachtwoord en het gebruik van een mix van hoofdletters, kleine letters, cijfers en speciale tekens. Een wachtwoord met hoge complexiteit zal typisch een willekeurige reeks van deze karakters bevatten, zonder voorspelbare patronen of woorden

Elke inlogprocedure MOET voldoen aan volgende minimale vereisten:

Inloggegevens enkel valideren als deze volledig zijn ingevoerd;
Het ingevoerde wachtwoord niet permanent weergeven wanneer het wordt ingevoerd (bv. sterretjes dienen te worden weergegeven wanneer een gebruiker een wachtwoord invoert);
Niet aangeven welk deel van de inloggevens (gebruikersnaam of wachtwoord) correct of onjuist is. Als een onjuist of onvolledig wachtwoord wordt ingevuld, dient in het feedback foutbericht, bv. vermeld te worden "gebruikersnaam of wachtwoord is ongeldig";
Geen legitieme gebruikersaccount weergeven totdat de inlogprocedure met succes is voltooid;
Geen helpberichten verstrekken tijdens de inlogprocedure die een niet-geautoriseerde gebruiker zouden helpen;
Het aantal mislukte inlogpogingen beperken tot maximaal 10;
Na 10 opeenvolgende mislukte inlogpogingen een wachttijd instellen van minimaal 30 minuten vooraleer een nieuwe inlogpoging kan worden ondernomen

Sessie -en schermvergrendeling

Sessievergrendeling en schermvergrendeling zijn beveiligingsfuncties die gebruikt worden om ongeautoriseerde toegang tot apparaten en applicaties te voorkomen. Sessievergrendeling houdt in dat een gebruikerssessie op een computer of applicatie automatisch wordt vergrendeld na een periode van inactiviteit of wanneer de gebruiker ervoor kiest om de sessie handmatig te vergrendelen. Tijdens een vergrendelde sessie blijft de gebruiker ingelogd, maar is toegang tot de sessie beperkt tot de gebruiker zich opnieuw authenticeert. Schermvergrendeling daarentegen betreft het vergrendelen van het scherm van een apparaat, zoals een computer, tablet of smartphone, waarbij de toegang tot de informatie op het scherm wordt geblokkeerd. Om toegang te herwinnen, is herauthenticatie vereist. Beide maatregelen zijn essentieel voor het beschermen van persoonlijke en professionele gegevens tegen onbevoegde toegang, vooral in situaties waar de gebruiker zijn werkplek tijdelijk verlaat.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Sessie -en schermvergrendeling MOET voldoen aan volgende minimale vereisten:

Werkplekken worden geconfigureerd om sessies automatisch te vergrendelen na een periode van inactiviteit van maximum vijftien (15) minuten.
Systemen worden geconfigureerd om sessies automatisch te beëindigen na een periode van inactiviteit van maximum één (1) uur.

Wachtwoordbeleid

Het gebruik van een wachtwoord

De gebruiker is in eerste instantie zelf verantwoordelijk om op een veilige manier om te springen met inloggegevens. Een wachtwoord is een vaak terugkerend aspect in de verschillende authenticatiemechanismen (zie bovenstaande tabel).

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De volgende complexiteitsregels MOETEN worden in acht genomen en indien mogelijk technisch afgedwongen:

Wachtwoordlengte:
- Standaard en niet-standaard gebruikersaccount: ten minste 12 karakters;
- Beheersaccounts: ten minste 16 karakters;
- Superuser en technische accounts: ten minste 50 karakters;
Het wachtwoord MOET een combinatie zijn van de volgende type karakters:
- hoofdletters;
- kleine letters;
- cijfers;
- speciale karakters !\"#$%&'()*+-,./:;<=>?@[]\^`{}|~_;
Het wachtwoord MAG GEEN woordenboekwoord, dialectwoord of jargonwoord uit welke taal dan ook zijn, of één van deze woorden achterstevoren geschreven;
Wachtwoorden MOGEN NIET gebaseerd zijn op persoonsgegevens (bijvoorbeeld geboortedatum, adres, naam van familielid, enz.).

Indien het systeem niet kan worden geconfigureerd om bovenstaande complexiteitsregels technisch af te dwingen, MOET controle op een procesmatige manier gebeuren.

Beheer van wachtwoorden

Hierbij wordt verwezen naar de specifieke technologische hulpmiddelen en procedures die worden ingezet om wachtwoorden veilig te creëren, op te slaan, te beheren en te gebruiken. Deze maatregelen zijn bedoeld om de veiligheid en effectiviteit van wachtwoordgebruik te verhogen

_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De organisatie MOET zorgen dat gebruikers bewust zijn van hun verantwoordelijkheden m.b.t. het veilig omspringen met inloggegevens, deze richtlijnen moeten volgende aspecten omvatten:

Een wachtwoord is altijd persoonlijk, het delen van een wachtwoord met iemand anders MAG NIET, tenzij voor gedeelde accounts via een veilige methode die formeel is goedgekeurd;
Wachtwoorden MOGEN NIET verspreid worden via het zelfde communicatiekanaal als de account;
Wachtwoorden MOGEN NIET worden opgeschreven, tenzij voor superuser accounts of technische accounts via een veilige methode die formeel is goedgekeurd;
Wachtwoorden MOGEN NIET worden opgeslagen in een geautomatiseerd aanmeldingssysteem (bijvoorbeeld macro of browser), tenzij via een door de organisatie gevalideerde oplossing;
Wachtwoorden MOETEN onmiddellijk worden gewijzigd als er aanwijzingen zijn dat deze gecompromitteerd kunnen zijn, in dat geval MOET ook een beveiligingsincident worden gemeld;
Wanneer een nieuw wachtwoord wordt gekozen, MOET dit verschillend zijn van de laatste drie wachtwoorden die werden gebruikt;
Het gebruiken van hetzelfde wachtwoord voor privé en zakelijke doeleinden is NIET TOEGESTAAN.

Complexiteitsregels voor wachtwoorden

De complexiteitsregels verhogen de mate van onvoorspelbaarheid of willekeurigheid die een wachtwoord bezit. Hoe hoger de complexiteit, hoe moeilijker het wachtwoord te raden of te kraken is door brute force-aanvallen of andere hacking-methoden. De complexiteit wordt beïnvloed door verschillende factoren, zoals de lengte van het wachtwoord en het gebruik van een mix van hoofdletters, kleine letters, cijfers en speciale tekens. Een wachtwoord met hoge complexiteit zal typisch een willekeurige reeks van deze karakters bevatten, zonder voorspelbare patronen of woorden.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

De volgende complexiteitsregels MOETEN worden in acht genomen en indien mogelijk technisch afgedwongen:

Wachtwoordlengte:
- Standaard en niet-standaard gebruikersaccount: ten minste 12 karakters;
- Beheersaccounts: ten minste 16 karakters;

Het beheer van wachtwoorden MOET voldoen aan volgende minimale vereiste:

Systemen MOETEN wachtwoordvelden maskeren om het tonen van wachtwoorden tijdens inloggen te voorkomen;
Systemen MOETEN wachtwoorden bij opslag en verzending beschermen tegen openbaarmaking door het toepassen van passende cryptografische technieken (zie ook het beleid Cryptografie);
De opslag van wachtwoorden MOET gebruik maken van hashing en salting methodes;
Wachtwoorden MOETEN apart van de applicatiedata te worden bewaard.

Toekennen van een nieuw of gewijzigd wachtwoord

Een gestandaardiseerd proces zorgt voor een veilige overdracht van nieuwe of gewijzigde wachtwoorden aan de gebruiker, waardoor het risico op onderschepping door onbevoegden wordt geminimaliseerd

- Superuser en technische accounts: ten minste 50 karakters;
Het wachtwoord MOET een combinatie zijn van de volgende type karakters:
- hoofdletters;
- kleine letters;
- cijfers;
- speciale karakters !\"#$%&'()*+-,./:;<=>?@[]\^`{}|~_;
Het wachtwoord MAG GEEN woordenboekwoord, dialectwoord of jargonwoord uit welke taal dan ook zijn, of één van deze woorden achterstevoren geschreven;
Wachtwoorden MOGEN NIET gebaseerd zijn op persoonsgegevens (bijvoorbeeld geboortedatum, adres, naam van familielid, enz.).

Indien het systeem niet kan worden geconfigureerd om bovenstaande complexiteitsregels technisch af te dwingen, MOET controle op een procesmatige manier gebeuren.

Beheer van wachtwoorden

Hierbij wordt verwezen naar de specifieke technologische hulpmiddelen en procedures die worden ingezet om wachtwoorden veilig te creëren, op te slaan, te beheren en te gebruiken. Deze maatregelen zijn bedoeld om de veiligheid en effectiviteit van wachtwoordgebruik te verhogen.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het proces voor het toekennen van een nieuw of gewijzigd wachtwoord MOET volgende aspecten omvatten:

Alvorens initiële wachtwoorden uit te geven of een nieuw wachtwoord te verlenen voor systemen die geen self-service wachtwoord resetfunctionaliteit hebben, moeten een verificatie van de identiteit van de gebruiker worden uitgevoerd.
Bij het aanmaken van nieuwe gebruikersaccounts moeten de initiële wachtwoorden willekeurig worden ingesteld met behulp van een wachtwoordgenerator. Het initiële wachtwoord mag niet via hetzelfde kanaal gecommuniceerd worden als het kanaal dat wordt gebruikt voor het communiceren van de gebruikersaccount.
Het geresette wachtwoord moet aan de complexiteitsregels voldoen en mag niet hergebruikt worden.
Het tijdelijk of initieel toegekende wachtwoord van een gebruiker moet gewijzigd worden bij de eerste aanmelding op een systeem.

Autorisatie

Autorisatie verwijst naar de goedkeuring die een bevoegd persoon verleent voor het gebruik van een dienst of applicatie. Dit omvat twee belangrijke aspecten:

Basisprincipes

Een aantal basisprincipes dragen bij tot een robuuste en veilige autorisatiestructuur binnen de organisatie. Ze helpen niet alleen bij het beschermen tegen externe bedreigingen, maar verhogen ook de interne controle en verantwoording, wat essentieel is voor het behoud van de integriteit en vertrouwelijkheid van informatie en informatiesystemen.

Need to Know: Dit principe waarborgt dat toegang tot informatie en informatiesystemen beperkt blijft tot diegenen die deze toegang daadwerkelijk nodig hebben voor hun werk. Het vermindert het risico dat gevoelige informatie onnodig wordt blootgesteld en helpt bij het beschermen van vertrouwelijke of kritieke data tegen ongeoorloofde inzage of manipulatie.

Least Privilege: Het toekennen van enkel de minimale rechten die noodzakelijk zijn voor het uitvoeren van een taak vermindert het risico van schade door fouten, misbruik van rechten of cyberaanvallen. Dit principe beperkt de impact van een eventueel beveiligingsincident omdat gebruikers of systemen alleen toegang hebben tot wat strikt nodig is.

Scheiding van Taken: Deze aanpak voorkomt belangenconflicten en vermindert de kans op fraude of datalekken. Door kritieke taken over meerdere personen of groepen te verdelen, wordt het moeilijker voor één individu om ongepast gedrag uit te voeren zonder detectie. Dit helpt ook bij het creëren van een meer gecontroleerde en beveiligde operationele omgeving.

beheer van wachtwoorden MOET voldoen aan volgende minimale vereiste:

Systemen MOETEN wachtwoordvelden maskeren om het tonen van wachtwoorden tijdens inloggen te voorkomen;
Systemen MOETEN wachtwoorden bij opslag en verzending beschermen tegen openbaarmaking door het toepassen van passende cryptografische technieken (zie ook het beleid Cryptografie);
De opslag van wachtwoorden MOET gebruik maken van hashing en salting methodes;
Wachtwoorden MOETEN apart van de applicatiedata te worden bewaard.

Toekennen van een nieuw of gewijzigd wachtwoord

Een gestandaardiseerd proces zorgt voor een veilige overdracht van nieuwe of gewijzigde wachtwoorden aan de gebruiker, waardoor het risico op onderschepping door onbevoegden wordt geminimaliseerd.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het proces voor het toekennen van een nieuw of gewijzigd wachtwoord MOET volgende aspecten omvatten:

Alvorens initiële wachtwoorden uit te geven of een nieuw wachtwoord te verlenen voor systemen die geen self-service wachtwoord resetfunctionaliteit hebben, MOET een verificatie van de identiteit van de gebruiker worden uitgevoerd;
Bij het aanmaken van een nieuwe gebruikersaccount, MOET het initiële wachtwoord willekeurig worden ingesteld met behulp van een wachtwoordgenerator en MOET dit gecommuniceerd worden via een kanaal dat verschilt van het kanaal dat wordt gebruikt voor het communiceren van de gebruikersaccount;
Een gereset wachtwoord MOET aan de complexiteitsregels voldoen en mag niet hergebruikt worden;
Het tijdelijk of initieel toegekende wachtwoord van een gebruiker MOET gewijzigd worden bij de eerste aanmelding op een systeem;
Gebruikers MOETEN de mogelijkheid hebben om hun eigen wachtwoord te kiezen en te wijzigen.

Logging

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Bij het bepalen van de toegang van gebruikers of applicaties tot informatie en informatiesystemen MOETEN volgende basisprincipes worden toegepast:

Need to Know: Toegang tot gevoelige informatie of systemen moet beperkt blijven tot degenen die deze echt nodig hebben, en dit mogelijk slechts voor een bepaalde tijd. Het is aan de eigenaar van de informatie om te bepalen wie toegang moet hebben, zowel voor het lezen als het wijzigen van de informatie, en voor hoe lang deze toegang vereist is.
Least Privilege: Gebruikers, processen of applicaties dienen enkel over de minimale rechten te beschikken die noodzakelijk zijn voor het uitvoeren van hun specifieke taken of functies.
Scheiding van Taken: Taken zoals het aanmaken van gebruikersaccounts en het toewijzen van bevoegdheden moeten door verschillende individuen worden uitgevoerd om belangenconflicten en misbruik te voorkomen. In situaties waar scheiding van taken niet haalbaar is, moeten compenserende maatregelen zoals activiteitenmonitoring, evaluatie van audit trails en strikt managementtoezicht worden ingevoerd om de integriteit van het proces te waarborgen.

Rollen gebaseerde toegangscontrole (RBAC)

Role-Based Access Control (RBAC) is een methode voor toegangsbeheer die de toegang van gebruikers tot informatie en informatiesystemen regelt op basis van hun rol binnen de organisatie. In plaats van toegangsrechten toe te kennen aan individuele gebruikers, worden deze rechten gekoppeld aan rollen.

Door toegangsrechten aan rollen te koppelen, hoeft de beheerder niet voor elke gebruiker afzonderlijk toegangsrechten toe te kennen. Het vereenvoudigt het beheer en vermindert de kans op fouten. Daarnaast zorgt RBAC ervoor dat gebruikers alleen toegang hebben tot de informatie en middelen die ze nodig hebben voor hun werk. RBAC maakt het ook mogelijk om toegangsrechten snel en efficiënt aan te passen of in te trekken. Dit is essentieel voor goede controle en beheer van toegang binnen de organisatie, bijvoorbeeld wanneer gebruikers van rol wisselen of de organisatie verlaten

Zowel succesvolle als mislukte inlogpogingen MOETEN geregistreerd worden.

De logs van mislukte inlogpogingen MOETEN periodiek worden nagekeken op trends om inbraakpogingen te detecteren.

Autorisatie

Na identificatie en authenticatie bepaalt autorisatie welke rechten en privileges aan de geauthenticeerde account worden toegekend. Dit proces regelt de toegang tot verschillende resources binnen het systeem op basis van gebruikersrollen, beleidslijnen en regels.

Basisprincipes

Een aantal basisprincipes dragen bij tot een robuuste en veilige autorisatiestructuur binnen de organisatie. Ze helpen niet alleen bij het beschermen tegen externe bedreigingen, maar verhogen ook de interne controle en verantwoording, wat essentieel is voor het behoud van de integriteit en vertrouwelijkheid van informatie en informatiesystemen.

Need to know: Dit principe vermindert het risico dat gevoelige informatie onnodig wordt blootgesteld en helpt bij het beschermen van vertrouwelijke of kritieke data tegen ongeoorloofde inzage of manipulatie.
Least privilege: Dit principe beperkt de impact van een eventueel beveiligingsincident omdat gebruikers of systemen alleen toegang hebben tot wat strikt nodig is.
Scheiding van taken:Deze aanpak voorkomt belangenconflicten en vermindert de kans op fraude of datalekken. Door kritieke taken over meerdere personen of groepen te verdelen, wordt het moeilijker voor één individu om ongepast gedrag uit te voeren zonder detectie. Dit helpt ook bij het creëren van een meer gecontroleerde en beveiligde operationele omgeving.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Het gebruik van Role-Based Access Control (RBAC) is AANGEWEZEN waarbij:

Het verlenen, wijzigen of intrekken van toegangsrechten aan een gebruiker gebeurt op basis van de toegekende rollen.
Er een centraal en actueel overzicht dient te zijn van de relatie tussen gebruikers, rollen en toegangsrechten.
Het toekennen, wijzigen of intrekken van rollen aan een gebruiker gebeurt vanuit een centrale betrouwbare bron.

Verlenen en intrekken van bijkomende toegangsrechten

Het proces waarbij bijkomende toegangsrechten voor gebruikers worden toegekend of ingetrokken, gebaseerd op veranderende behoeften, rollen of verantwoordelijkheden.

Effectief beheer van het verlenen en intrekken van toegangsrechten helpt bij het handhaven van de beveiliging, het voorkomen van ongeautoriseerde toegang, en het verzekeren van de naleving van het 'least privilege'-principe binnen de organisatie.

Panel

panelIconId	9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon	:icon_beleidslijnen:
panelIconText	:icon_beleidslijnen:
bgColor	#F4F5F7

Implementatiemaatregel

Er MOET een formele aanvraagprocedure zijn voor het verlenen, wijzigen of intrekken van toegangsrechten.

Alle aanvragen MOETEN in een centraal systeem worden gelogd.

Volgende attributen MOETEN aanwezig zijn om een auditeerbaar proces te garanderen:

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

Validatie van toegangsrechten

Het validatieproces controleert of de toegangsrechten van gebruikers in de organisatie juist zijn en passen bij hun rollen en verantwoordelijkheden
Toegang van accounts tot informatie en systemen MOET de volgende basisprincipes in acht nemen:
Need to know
Toegang MOET beperkt zijn tot diegenen die deze toegang daadwerkelijk nodig hebben voor het uitoefenen van hun bedrijfstaken, en dit mogelijk slechts voor een bepaalde tijd;
Least Privilege
Accounts MOGEN ENKEL over de minimale rechten beschikken die noodzakelijk zijn voor het uitvoeren van hun specifieke taken of functies.
Scheiding van Taken
Conflicterende taken MOETEN door verschillende individuen met verschillende accounts worden uitgevoerd om belangenconflicten en misbruik te voorkomen;
In situaties waar scheiding van taken niet haalbaar is, MOETEN compenserende maatregelen zoals monitoring, evaluatie van audit trails en strikt managementtoezicht worden ingevoerd om de integriteit van het proces te waarborgen.
Role-Based Access Control
Role-Based Access Control (RBAC) is een methode voor toegangsbeheer die de toegang van gebruikers tot informatie en informatiesystemen regelt op basis van hun takenpakket binnen de organisatie. In plaats van toegangsrechten toe te kennen aan individuele gebruikers, worden deze rechten gekoppeld aan rollen en wordt vervolgens een rol toegekend aan een gebruiker. Door toegangsrechten aan rollen te koppelen, hoeft de beheerder niet voor elke gebruiker afzonderlijk toegangsrechten toe te kennen. Het vereenvoudigt het beheer en vermindert de kans op fouten. Daarnaast zorgt RBAC ervoor dat gebruikers alleen toegang hebben tot de informatie en middelen die ze nodig hebben voor hun werk. RBAC maakt het ook mogelijk om toegangsrechten snel en efficiënt aan te passen of in te trekken. Dit is essentieel voor goede controle en beheer van toegang binnen de organisatie, bijvoorbeeld wanneer gebruikers van rol wisselen of de organisatie verlaten.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Het gebruik van Role-Based Access Control waarbij het verlenen, wijzigen of intrekken van toegangsrechten aan een gebruiker gebeurt op basis van de toegekende rollen, is AANGEWEZEN waarbij:
Er een duidelijke relatie is tussen het takenpakket van een medewerker en de bijhorende toegangsrechten;
Deze bijhorende toegangsrechten kunnen gegroepeerd worden in een rol in het systeem;
Er een centraal en actueel overzicht dient te zijn van de relatie tussen gebruikers, rollen en toegangsrechten;
Het toekennen, wijzigen of intrekken van rollen aan een gebruiker gebeurt vanuit een centrale betrouwbare bron.
Verlenen en intrekken van toegangsrechten
Effectief beheer van het verlenen en intrekken van toegangsrechten helpt bij het handhaven van de beveiliging, het voorkomen van ongeautoriseerde toegang, en het verzekeren van de naleving van de hierboven beschreven basisprincipes.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Toegangsrechten MOGEN pas worden verleend na het voltooien van een validatieprocedure.
Deze procedure MOET consequent het principe van scheiding van taken hanteren, waarbij zelf-autorisatie van een aanvraag niet is toegestaan.
De validatieprocedure MOET afhankelijk zijn naargelang de informatieklasse.
Informatieklasse 4: Validatie met goedkeuring van een door de organisatie geautoriseerd tweede persoon.
Voorbeeld: Lokale beheerder doet de registratie en deze wordt gevalideerd door de leidinggevende of de toepassingsbeheerder.
Informatieklasse 5: Validatie met goedkeuring van door twee door de organisatie geautoriseerde personen, waarvan minimaal één zonder hiërarchische of functionele relatie met de aanvrager.
Voorbeeld: Lokale beheerder doet de registratie en deze wordt gevalideerd door de leidinggevende of de toepassingsbeheerder, waarna de veiligheidscoördinator de finale validatie bevestigd.
Herzien van toegangsrechten
Het regelmatig herzien van toegewezen toegangsrechten is cruciaal om ervoor te zorgen dat gebruikers geen ongepaste of onnodige toegang krijgen of behouden tot informatie en informatiesystemen. Deze evaluatie helpt bij het identificeren en corrigeren van eventuele onjuistheden in de toegangsverlening. Het voorkomt ook dat gebruikers rechten behouden die niet langer relevant zijn vanwege veranderingen in hun functie, rol of projectbetrokkenheid
Voor elk systeem MOET er een formeel proces zijn waarbij toegangsrechten voor gebruikers worden toegekend of ingetrokken, gebaseerd op veranderende behoeften, taken of verantwoordelijkheden van medewerkers.
Er MOET een formele aanvraagprocedure zijn voor het verlenen, wijzigen of intrekken van toegangsrechten.
Alle aanvragen MOETEN in een centraal systeem worden gelogd.
De eigenaar van de informatie MOET valideren wie toegang nodig heeft, zowel voor het lezen als het wijzigen van de informatie, en voor hoe lang deze toegang vereist is.
Volgende attributen MOETEN gelogd worden om een auditeerbaar proces te garanderen:
Basis attributen van het verzoek tot toegang (datum, tijd, aanvrager, volgnummer, …);
De account van de medewerker die de toegang wenst te gebruiken;
Motivatie van het verzoek;
Basis attributen van de validatie van de toegang (datum, tijd, …);
Identiteit van de persoon (eigenaar van de informatie) die de validatie uitvoert;
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.
Validatie van toegangsrechten
Het validatieproces controleert of de toegangsrechten van gebruikers in de organisatie juist zijn en passen bij hun rollen en verantwoordelijkheden.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Rollen en de hieraan toegewezen machtigingen MOETEN jaarlijks worden herzien. (Soll)
De toegewezen rollen of bijkomende toegangsrechten MOETEN periodiek worden herzien naargelang de informatieklasse. (Ist)
Informatieklasse 1 en 2: minstens 1 keer per jaar
Informatieklasse 3 en 4: minstens 2 keer per jaar
Informatieklasse 5: minstens 4 keer per jaar
Panel
panelIconId atlassian-info
panelIcon :info:
bgColor #FFFFFF
Ist-Soll-model
Bij de herziening van toegangsrechten verwijst men vaak naar het Ist-Soll-model, dit is een concept waarbij de huidige toestand (Ist) van een proces, systeem of toepassing wordt vergeleken met de gewenste, toekomstige toestand (Soll). In de context van autorisatie en toegangsbeheer betekent dit:
Ist (Huidige Toestand): Dit vertegenwoordigt de actuele situatie van toegangsrechten binnen een systeem of toepassing. Het omvat welke gebruikers momenteel toegang hebben tot bepaalde informatie of informatiesystemen en hoe deze toegangsrechten zijn geconfigureerd.
De Ist-oefening dient regelmatig te worden uitgevoerd om tekortkomingen in de toegangsbeheerprocessen te identificeren en te corrigeren. Naarmate de informatieklasse van de te toepassing dient deze oefening frequenter te worden uitgevoerd.
Soll (Gewenste Toestand): Dit is de documentatie van de gewenste configuratie van toegangsrechten. Het biedt een overzicht van welke rollen toegang zouden moeten hebben tot welke functionaliteiten of welke stappen in een deelproces in de toepassing, of het systeem. De Soll-toestand weerspiegelt hoe toegangsrechten zouden moeten zijn ingericht om optimale beveiliging en efficiëntie te waarborgen.
De Soll-oefening dient grondig te worden uitgevoerd, omdat deze de basis vormt voor de Ist-oefening en het toegangsbeheerbeleid van je toepassing.
Door het Ist-Soll-model te gebruiken, kan de organisatie discrepanties tussen de huidige en gewenste toegangsrechten identificeren en de nodige aanpassingen maken.
Privileged Access Management
Beheer accounts
Toegangsrechten MOGEN pas worden verleend na het voltooien van een validatieprocedure.
Deze procedure MOET consequent de basisprincipes van need to know, least privileges en scheiding van taken hanteren, waarbij zelf-autorisatie van een aanvraag niet is toegestaan.
De validatieprocedure MOET, afhankelijk van de informatieklasse, de volgende regels volgen:
Informatieklasse 2 en 3: Registratie en validatie door een zelfde door de organisatie geautoriseerd persoon.
Voorbeeld: toepassingsbeheerder doet de registratie en validatie.
Informatieklasse 4: Validatie door een door de organisatie geautoriseerd tweede persoon.
Voorbeeld: toepassingsbeheerder doet de registratie en deze wordt gevalideerd door de leidinggevende van de toepassingsbeheerder.
Informatieklasse 5: Validatie door twee door de organisatie geautoriseerde personen, waarvan minimaal één zonder hiërarchische of functionele relatie met de anderen.
Voorbeeld: toepassingsbeheerder doet de registratie en deze wordt gevalideerd door de leidinggevende van de toepassingsbeheerder, waarna de veiligheidscoördinator de finale validatie bevestigd.
Herzien van toegangsrechten
Het regelmatig herzien van toegewezen toegangsrechten is cruciaal om ervoor te zorgen dat gebruikers geen ongepaste of onnodige toegang krijgen of behouden tot informatie en informatiesystemen. Deze evaluatie helpt bij het identificeren en corrigeren van eventuele onjuistheden in de toegangsverlening. Het voorkomt ook dat gebruikers rechten behouden die niet langer relevant zijn vanwege veranderingen in hun functie, rol of projectbetrokkenheid.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Rollen en de hieraan toegewezen machtigingen MOETEN jaarlijks worden herzien.
De rollen en/of toegangsrechten toegewezen aan accounts MOETEN periodiek worden herzien naargelang de informatieklasse:
Informatieklasse 2 en 3: elk jaar;
Informatieklasse 4: elke 6 maanden (half-jaarlijks);
Informatieklasse 5: elk kwartaal.
Privileged Account Management
Persoonlijke beheeraccounts (of geprivilegieerde accounts) zijn een belangrijk aandachtspunt in de beveiliging van de organisatie, omdat ze uitgebreide toegangsrechten bieden tot informatie en informatiesystemen. Deze accounts vormen een aantrekkelijk doelwit voor externe aanvallers en kwaadwillende insiders, die misbruik kunnen maken van deze rechten om informatie te stelen, systemen te saboteren of andere schadelijke activiteiten uit te voeren. Ook kunnen fouten gemaakt door gebruikers met beheertoegang onbedoeld ernstige problemen veroorzaken, zoals datalekken of systeemstoringen. Door de uitgebreide toegangsrechten van deze accounts is het risico op significante schade bij misbruik of fouten veel groter dan bij standaard gebruikersaccounts.
Omwille van deze redenen zijn voor beheeraccounts en geprivilegieerde toegangsrechten strikte het gebruik van persoonlijke beheeraccounts striktere maatregelen van toepassing dan op gewone gebruikersaccounts. We onderscheiden drie implementatieniveaus van toegangscontrole voor geprivilegieerde accounts (oftewel Privileged Account management (PAM)), die een toenemende mate van veiligheid en controle bieden, afhankelijk van het toepassingscriteria.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Volgende implementatieniveaus van PAM, die een toenemende mate van veiligheid en controle bieden, MOETEN worden gehanteerd, op basis van het toepassingsniveau.
Basis niveau
Toepassingscriteria:
Tot en met Informatieklasse 3 (Vertrouwelijkheid en Integriteit).
Niet geschikt voor persoonsgegevens.
Handmatige processen zijn mogelijk zonder afname van PAMaaS.
Implementatievereiste:
Toegangsbeheer
Sterke identificatie van de PAM-gebruiker.
Sterke authenticatie voor operationele activiteiten.
Elke toegang is geautoriseerd door de toegangsbeheerder met minstens jaarlijkse validatie van toegangsrechten door de toepassingseigenaar.
Permanente, gemonitorde toegang tot het beheer account waarmee gepriviligeerde toegangen worden verworven.
Change, configuratie en release management
Motivatie van de gebruiker om toegang te krijgen is niet verplicht. Er is geen verplichte integratie van change managementinformatie
Audit
Auditeerbaarheid is gebaseerd op documentatie en punctuele ad hoc audits van zowel de operationele processen als de informatie verwerkende configuraties.
Middelste niveau
Toepassingscriteria:
Tot en met Informatieklasse 4 (Vertrouwelijkheid en Integriteit).
Persoonsgegevens tot en met Informatieklasse 3 (Vertrouwelijkheid).
Automatisering van PAM is verplicht, afname van PAMaaS is optioneel.
Implementatievereiste:
Toegangsbeheer
Sterke identificatie van de PAM-gebruiker.
Sterke authenticatie voor operationele activiteiten.
Elke toegang is geautoriseerd door de toegangsbeheerder met minstens jaarlijkse validatie van toegangsrechten door de toepassingseigenaar.
Permanente, gemonitorde en gemotiveerde toegang tot het beheer account waarmee geprivilegieerde toegangen worden verworven.
Alle activiteiten tijdens de uitvoering van de geprivilegieerde toegang worden geregistreerd. Session recording, ook manueel, maakt dat
De volgende implementatieniveaus MOETEN worden toegepast op persoonlijke beheersaccounts naargelang de informatieklasse:
Beschikbaarheid Integriteit Vertrouwelijkheid
5 HOOG HOOG HOOG
4 MIDDEN MIDDEN HOOG
3 BASIS BASIS MIDDEN
2 BASIS BASIS BASIS
1 BASIS BASIS BASIS
Sommige van de aspecten van PAM in onderstaande tabel werden reeds eerder vermeld in bovenstaande paragrafen en worden hier herhaald ten einde een volledig overzicht te bieden.
Panel
panelIconId 9e6f15e6-c999-4552-9c6b-2582a2016b24
panelIcon :icon_beleidslijnen:
panelIconText :icon_beleidslijnen:
bgColor #F4F5F7
Implementatiemaatregel
Het BASIS implementatieniveau voor persoonlijke beheersaccounts MOET voldoen aan de volgende vereisten:
Sterke identificatie van de medewerker;
Sterke authenticatie bij gebruik;
Elke account is geregistreerd en gevalideerd door de toegangsbeheerder met minstens jaarlijkse her-validatie;
Er is permanente toegang tot het beheersaccount;
Permanente logging van het gebruik;
Motivatie voor gebruik is niet verplicht;
Auditeerbaarheid is door ad hoc audits.
Het MIDDEN implementatieniveau voor persoonlijke beheersaccounts MOET voldoen aan de volgende vereisten:
Sterke identificatie van de medewerker;
Sterke authenticatie bij gebruik;
Elke account is geregistreerd door de toegangsbeheerder met validatie door een door de organisatie geautoriseerd tweede persoon met minstens jaarlijkse her-validatie;
Er is permanente toegang tot het beheersaccount;
Permanente logging van het gebruik waarbij alle activiteiten worden geregistreerd (session recording) zodat de activiteiten in real-time en uitgesteld kunnen bekeken worden
.
Change, configuratie en release management
Er gebeurt een verplichte validatie van de motivatie van de gebruiker.
;
Verplichte motivatie en validatie via een Change en Release Management proces:
Er is geen dubbele controle van de toegang op voorhand noodzakelijk. Periodieke controle gebeurt ‘post-mortem’ op basis van correlatie van logs die voortkomen uit de processen Change en Release Management en de logs van PAM zelf. (in PAMaaS is dit een standaard rapportage)
Audit
van het gebruik van de beheersaccount zelf
Auditeerbaarheid is gebaseerd op volgende
risicorapportering
risicorapportering:
Toegangsbeheer
Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change);
Pre-approved changes en operationele activiteiten (
Changes
changes) met een maximale duurtijd tot één jaar zijn toegestaan voor operationele teams;
Periodieke risicorapportering dekt zowel de operationele processen als de informatie verwerkende configuratie
Alle activiteiten van de gebruiker van het PAM-proces worden geregistreerd. Dit is de implementatie van het controleprincipe op basis van manueel logboek registratie of geautomatiseerde session recording in combinatie met de log informatie
Hoogste niveau
Toepassingscriteria:
Tot en met Informatieklasse 5 (Vertrouwelijkheid en Integriteit).
Persoonsgegevens tot en met Informatieklasse 4 (Vertrouwelijkheid).
Implementatievereiste:
.
Het HOOG implementatieniveau voor persoonlijke beheersaccounts MOET voldoen aan de volgende vereisten:
Sterke identificatie van de
PAM-gebruiker.
medewerker;
Sterke authenticatie
voor operationele activiteiten.
bij gebruik;
Elke
toegang
account is
geautoriseerd
geregistreerd door de toegangsbeheerder met validatie door een door de organisatie geautoriseerd tweede persoon met minstens jaarlijkse her-validatie;
Er is geen permanente toegang tot het beheersaccount, de account wordt enkel vrijgegeven op basis van functionele noodzaak (
bvb. Interventie
bijvoorbeeld een interventie in kader van een incident)
.
Er is geen permanente toegang tot het account met privileged toegangen binnen de informatieverwerking.
Permanente, gemonitorde en gemotiveerde toegang tot het beheer account waarmee geprivilegieerde toegangen worden verworven.
Alle activiteiten tijdens de uitvoering van de geprivilegieerde toegang worden geregistreerd. Session recording, ook manueel, maakt dat
;
Permanente logging van het gebruik waarbij alle activiteiten worden geregistreerd (session recording) zodat de activiteiten in real-time en uitgesteld kunnen bekeken worden
.
Change, configuratie en release management
Er gebeurt een verplichte validatie van de motivatie van de gebruiker.
;
Verplichte motivatie en validatie via een Change en Release Management proces:
Er is geen dubbele controle van de toegang op voorhand noodzakelijk. Periodieke controle gebeurt ‘post-mortem’ op basis van correlatie van logs die voortkomen uit de processen Change en Release Management en de logs van PAM zelf. (In PAMaaS is dit een standaard rapportage)
Audit
het gebruik van de beheersaccount zelf;
Auditeerbaarheid is gebaseerd op volgende
risicorapportering
risicorapportering:
Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change);
Pre-approved changes en operationele activiteiten (
Changes
changes) zijn beperkt tot de reële functionele duurtijd van de activiteiten;
Periodieke risicorapportering dekt zowel de operationele processen als de informatie verwerkende configuratie
Alle activiteiten van de gebruiker van het PAM-proces worden geregistreerd
.
Dit is de implementatie van het 4EYES principe op basis van manueel logboek registratie of geautomatiseerde session recording in combinatie met de log informatie

Relatie van het beleid met andere richtlijnen en standaarden

Regelgeving en standaarden (L1)

ISO 27001:2022 (Annex A)

Page Properties Report

firstcolumn	Titel
headings	Beheersmaatregel
sortBy	Title
cql	label = "iso" and label = "toegangsbeveiliging" and space = currentSpace ( ) and ancestor = "6329502795"

Informatieveiligheidsstrategie van de Vlaamse overheid (L2)

Zie 5.1. Minimale maatregelen - Identity en Access Management (IAM) en 5.4. Minimale maatregelen - Priviliged Access Management (PAM) voor meer informatie.

Uitvoering van het beleid

Processen

Oplossingen

Gebruikersbeheer (IDM)

Toegangsbeheer (ACM)

Geprivilegieerd Toegangsbeheer (PAMaaS)

Titel

Auteur

Datum

Versie

Status

Opmerkingen

Toegangscontrole

Philippe Michiels

9/11/2020

0.1

Status

colour	Yellow
title	CONCEPT

Paswoord Policy

Philippe Michiels

21/07/2021

1.0

Status

colour	Green
title	GEVALIDEERD

Toegangsbeveiliging

Guido Calomme

23/05/2024

2.0

Status

colour	Yellow
title	CONCEPT

Page Properties

hidden	true
id	DS

Document status (Metadata)

Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister

Auteur

Guido Calomme

Status

Status

colour	Yellow
title	CONCEPT

Versie

2.0

status opties:

Status

colour	Yellow
title	CONCEPT

Status

colour	Blue
title	IN REVIEW

Status

colour	Purple
title	FINAAL CONCEPT

Status

colour	Green
title	GEVALIDEERD

Status

colour	Red
title	TE REVISEREN

status eveneens aanpassen bovenaan deze pagina

Page Comparison

Versions Compared

Old Version 39

New Version 40

Key

Inhoud

Doel

DOELSTELLINGEN

DREIGINGEN

Beleid

Identificatie, authenticatie en autorisatie

Type accounts

Identificatie

Identiteitsbeheer

Implementatiemaatregel

Implementatiemaatregel

Accountbeheer

Standaard gebruikersaccounts

Implementatiemaatregel

Implementatiemaatregel

Niet-standaard gebruikersaccounts

Implementatiemaatregel

Implementatiemaatregel

Gedeelde gebruikersaccount

Gast accounts

Implementatiemaatregel

Superuser accounts

Gedeelde gebruikersaccount

Implementatiemaatregel

Gast accounts

Implementatiemaatregel

Beheersaccounts

Superuser accounts

Implementatiemaatregel

Implementatiemaatregel

Persoonlijke beheersaccounts

Implementatiemaatregel

Technische accounts

Implementatiemaatregel

Authenticatie

Authenticatiemechanismen

Implementatiemaatregel

Single Sign-On

Implementatiemaatregel

Bijkomende vereiste voor technische accounts

Implementatiemaatregel

Veilige inlogprocedure

Implementatiemaatregel

Sessie -en schermvergrendeling

Implementatiemaatregel

Technische accounts

Implementatiemaatregel

Authenticatie

Authenticatiemechanismen

Implementatiemaatregel

Single Sign-On

Implementatiemaatregel

Bijkomende vereiste voor technische accounts

Implementatiemaatregel

Wachtwoordbeleid

Het gebruik van een wachtwoord

Veilige inlogprocedure

Implementatiemaatregel

Complexiteitsregels voor wachtwoorden

Sessie -en schermvergrendeling

Implementatiemaatregel

Wachtwoordbeleid

Het gebruik van een wachtwoord

Implementatiemaatregel

Beheer van wachtwoorden

Implementatiemaatregel

Complexiteitsregels voor wachtwoorden

Implementatiemaatregel

Toekennen van een nieuw of gewijzigd wachtwoord

Beheer van wachtwoorden

Implementatiemaatregel

Autorisatie

Basisprincipes

Toekennen van een nieuw of gewijzigd wachtwoord

Implementatiemaatregel