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

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.

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.

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.

Implementatiemaatregel

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

• 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 standaard gebruikersaccount worden toegekend;

• Elke standaard gebruikersaccount MOET een unieke naam hebben en er MOETEN regels worden opgesteld om de naamgeving te bepalen,

• Aan elke standaard gebruikersaccount is een verantwoordelijke toegewezen verschillend van de gebruiker (bijvoorbeeld leidinggevende).

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 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.

Implementatiemaatregel

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.

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.

Implementatiemaatregel

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;

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.

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.

Implementatiemaatregel

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.

Implementatiemaatregel

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.

Implementatiemaatregel

Er MOET een formeel en gedocumenteerd proces zijn voor de creatie, het wijzigen en het verwijderen van 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.

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.

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 en 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.

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 4

• Laag

  • Alle interne toegang tot informatieklasse 2 en 3

  • 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.

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.

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.

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.

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.

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.

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.

Implementatiemaatregel

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.

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.

Implementatiemaatregel

Zowel succesvolle als mislukte inlogpogingen MOETEN geregistreerd worden.

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

Implementatiemaatregel

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.

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.

Implementatiemaatregel

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.

Implementatiemaatregel

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.

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.

Implementatiemaatregel

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

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;

• 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 Change en Release Management en de logs van het gebruik van de beheersaccount zelf

• Auditeerbaarheid is gebaseerd op volgende risicorapportering:

  • Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change);

  • Pre-approved changes en operationele activiteiten (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.

Het HOOG 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 geen permanente toegang tot het beheersaccount, de account wordt enkel vrijgegeven op basis van functionele noodzaak (bijvoorbeeld een interventie in kader van een incident);

• Permanente logging van het gebruik waarbij alle activiteiten worden geregistreerd (session recording) zodat de activiteiten in real-time en uitgesteld kunnen bekeken worden;

• 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 het gebruik van de beheersaccount zelf;

• Auditeerbaarheid is gebaseerd op volgende risicorapportering: 

  • Procescontrole: werd elke toegang correct afgedekt door een geregistreerde activiteit (change);

  • Pre-approved changes en operationele activiteiten (changes) zijn beperkt tot de reële functionele duurtijd van de activiteiten;

  • Periodieke risicorapportering dekt zowel de operationele processen als de informatie verwerkende configuratie.

Document status (Metadata)

Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister

status opties: