Beleid logische toegangsbeveiliging

Onderdeel van Beleidsset informatiebeveiliging op BIO 2.0, op maat gemaakt met contextvragen · Markdown-bron

Word nodig? Kies dit stuk in de generator en download het daar, zonder of met je eigen antwoorden.

In het kort. Regelt de toegang tot informatiesystemen, netwerken en gegevens: hoe accounts ontstaan en vervallen, hoe gebruikers zich aanmelden en wie welke rechten krijgt. Behandelt accounts, MFA, wachtwoorden, werken op afstand, periodieke beoordeling van rechten, beheeraccounts, toegang voor leveranciers, hoog gelabelde informatie en broncode.

Onderwerpen. 3. Identiteiten en accounts; 4. Authenticatie en MFA; 5. Wachtwoorden; 6. Toegang tot de vertrouwde zone en werken op afstand; 7. Toegangsrechten en periodieke beoordeling; 8. Accounts met bijzondere rechten; 9. Toegang voor leveranciers; 10. Informatie met een hoog vertrouwelijkheidslabel; 11. Broncode.

Zonder profiel: tekst die van een contextvraag afhangt, staat in een kader met de vraag erboven.

1. Doel en reikwijdte#

Dit beleid werkt het strategisch informatiebeveiligingsbeleid uit voor de toegang tot informatiesystemen, netwerken en gegevens. Het legt vast hoe accounts ontstaan en vervallen, hoe gebruikers zich aanmelden, wie welke rechten krijgt en hoe de organisatie dat controleert. Het gaat over de ISO-beheersmaatregelen 5.15 tot en met 5.18, 6.7, 8.2 tot en met 8.5 en 8.18.

Voor wie. Het beleid is primair bedoeld voor de afdeling die de identiteitsvoorziening beheert, voor systeemeigenaren en voor leidinggevenden die rechten aanvragen. De gedragsregels gelden voor iedereen met een account: medewerkers, inhuur, stagiairs, vrijwilligers en leveranciers.

Waarop. Alle accounts op systemen waarvan de organisatie eigenaar is, ook als een leverancier ze beheert of host: persoonlijke, gedeelde, technische en beheeraccounts, noodaccounts en accounts van leveranciers. Is het beheer van de identiteitsvoorziening of van een systeem uitbesteed, dan gelden de eisen uit dit beleid als minimumeis voor die partij. De organisatie legt dat vast in het contract en toetst de naleving met een onafhankelijke verklaring, zoals een ISO 27001-certificaat of een ISAE 3402- of ISAE 3000-rapport; het vastleggen loopt via het beleid informatiebeveiliging bij inkoop, het toetsen via het beleid contractbeheer.

Buiten dit beleid vallen de netwerkscheiding en de beheerinterfaces (beleid netwerkbeveiliging), de logging zelf (beleid logging en monitoring) en de vergrendeling van werkplekken (beleid IT-compliance).

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed» of «Volledig uitbesteed»

De organisatie beheert haar IT niet zelf. Waar dit beleid een eis stelt aan beheerders of aan het beheerproces, geldt die eis voor de beheerpartij via het contract. De toekenning van rechten aan eigen medewerkers blijft een besluit van de organisatie zelf.

2. Uitgangspunten#

1. Elke handeling op een systeem is herleidbaar tot één natuurlijke persoon. Accounts zijn persoonsgebonden; gedeelde accounts zijn een gemotiveerde uitzondering. #
2. Iemand krijgt alleen de rechten die nodig zijn voor de eigen taak, en niet langer dan nodig (need-to-know en least privilege). #
3. Rechten volgen een rol uit een autorisatiematrix. Losse rechten buiten een rol zijn een uitzondering met een einddatum. #
4. Beschikken, uitvoeren en controleren liggen niet bij dezelfde persoon. Beheerders hebben geen toegang tot de inhoud van de gegevens die ze beheren, tenzij de systeemeigenaar dat vastlegt en erop toeziet. #
5. Hoe zwaarder de rechten of hoe hoger het vertrouwelijkheidslabel van de informatie, hoe sterker de authenticatie en hoe vaker de controle. #
6. Termijnen en frequenties in dit beleid die niet uit een wet of uit de BIO 2.0 komen, zijn standaardwaarden. De organisatie past ze aan op haar eigen risicoafweging en legt de keuze vast bij de vaststelling van dit beleid. #

3. Identiteiten en accounts#

1. [lijneigenaar logische toegang] richt één accountproces in, gekoppeld aan de personeelsadministratie en de registratie van inhuur: indiensttreding of start van een opdracht levert een account op, een functiewijziging past de rechten aan en vertrek blokkeert het account uiterlijk op de laatste werkdag. Elke stap staat in het ticketsysteem. [5.16.01] #
2. Een geblokkeerd account wordt na [termijn verwijderen accounts] verwijderd. Accounts van inhuur en stagiairs hebben een einddatum gelijk aan het einde van de opdracht. [5.16.01] #
3. De identiteitsvoorziening blokkeert automatisch elk account dat [termijn inactiviteit] niet is gebruikt. [5.16.01] #
4. De systeemeigenaar stelt per systeem een autorisatieprocedure en een autorisatiematrix op met de proceseigenaren en beoordeelt die jaarlijks. De CISO toetst de procedure voor vaststelling. Een mandaatregister legt vast wie rechten mag aanvragen en goedkeuren. [5.16.01] #
5. De proceseigenaar gebruikt een gedeeld account alleen als een persoonlijk account aantoonbaar niet kan. Hij motiveert dat schriftelijk, stemt het af met de CISO en wijst een leidinggevende aan die verantwoordelijk is voor gebruik en tijdig opzeggen. [5.16.02] #
6. Een gedeeld account krijgt een herkenbare naam, geen toegang van buiten en geen beheerrechten. [lijneigenaar logische toegang] loopt het register van gedeelde accounts jaarlijks door. [5.16.02] #
7. Een functionele postbus (op naam van een team, project of product) heeft een eigenaar en wordt geopend met persoonlijke accounts die rechten op de postbus krijgen. Niemand meldt zich met een gedeeld wachtwoord op de postbus zelf aan. [5.16.02] #
8. De beheerder schakelt standaardaccounts uit of hernoemt ze en geeft ze een nieuw wachtwoord voor ingebruikname. Een technisch account heeft een eigenaar, kan niet interactief aanmelden en staat in het register van accounts met bijzondere rechten. [5.16.02, 5.18.01] #

4. Authenticatie en MFA#

1. MFA is verplicht bij het aanmelden op de digitale werkomgeving, bij elk account op een voorziening die via internet bereikbaar is en bij elk account met beheerrechten. Waar de risicoanalyse van een systeem dat vraagt, geldt MFA ook voor andere accounts. [5.17.01] #
2. De voorkeur gaat naar wachtwoordloze authenticatie met een persoonsgebonden sleutel, zoals een passkey of een hardwaretoken met pincode; anders een wachtwoord met een tweede factor. Een sms-code is alleen toegestaan als er geen andere tweede factor beschikbaar is. [5.17.01] #
3. Waar het kan, loopt aanmelden via de centrale identiteitsvoorziening met SSO. Beheerders bereiken beheeromgevingen via een beveiligde tussenstap (jumpserver) waarop ook MFA geldt. [5.17.01] #
4. Kan een systeem geen MFA, dan stelt de systeemeigenaar met de CISO aanvullende maatregelen op, zoals toegang alleen vanaf beheerde apparaten. De proceseigenaar keurt ze goed; het systeem staat ermee in het risicoregister. [5.17.01] #
5. De servicedesk reikt inloggegevens, tokens en resets pas uit nadat de identiteit van de ontvanger is vastgesteld, en legt dat vast in het ticket. [5.17.01] #
6. De identiteitsvoorziening meldt ten minste: aanmelden vanaf een ongebruikelijke locatie of een onmogelijke reisafstand, en een piek in mislukte aanmeldingen. [bewaking aanmeldingen] beoordeelt elke melding en handelt haar zo nodig af als beveiligingsincident. [5.17.01] #
7. Na [aantal mislukte pogingen] mislukte aanmeldingen blokkeert het systeem het account tijdelijk. [5.17.03] #

Alleen als: Hoe ziet je werkplek eruit? «Cloudwerkplek (bijvoorbeeld Microsoft 365)» of «Hybride: cloud naast een virtuele of lokale werkplek»

8. Op de cloudwerkplek dwingt de identiteitsvoorziening MFA af met regels voor voorwaardelijke toegang. Verouderde aanmeldprotocollen zonder MFA staan uit. [5.17.01] #

Alleen als: Hoe ziet je werkplek eruit? «On-premises»

9. Op de on-premises werkplek geldt MFA bij elke toegang van buiten het kantoornetwerk (VPN of remote desktop) en bij elk beheeraccount. Op kantoor loopt het primaire aanmelden met een pas of token. [5.17.01] #

5. Wachtwoorden#

1. Elke medewerker krijgt een wachtwoordmanager van de organisatie. Wachtwoorden voor werk staan niet in browsers op privéapparaten, in documenten of op papier. [5.17.02] #
2. De beheerder dwingt de eisen aan wachtwoorden technisch af in de identiteitsvoorziening en in elk systeem met een eigen accountbeheer: minimaal [minimale wachtwoordlengte], controle tegen lijsten van gelekte en veelgebruikte wachtwoorden en geen hergebruik van eerdere wachtwoorden. [5.17.03] #
3. Wachtwoorden verlopen niet periodiek. Bij een vermoeden van lekken vervangt de gebruiker het wachtwoord direct. [5.17.03] #

6. Toegang tot de vertrouwde zone en werken op afstand#

1. Toegang tot het interne netwerk en de interne systemen krijgt alleen apparatuur die de organisatie kent en heeft geauthenticeerd, of programmatuur in een afgeschermde omgeving zoals een virtuele werkplek of een beveiligde browser. Een onbekend of privéapparaat komt niet rechtstreeks in de vertrouwde zone. [5.15.01] #
2. Werken op afstand gebeurt alleen via de voorzieningen die de organisatie daarvoor biedt, met MFA. De medewerker opent informatie met het label vertrouwelijk of hoger op afstand alleen op een apparaat van de organisatie en werkt niet op een plek waar anderen kunnen meekijken. [lijneigenaar logische toegang] legt in de regeling thuiswerken vast welke apparatuur en werkplekken zijn toegestaan en beoordeelt die regeling jaarlijks. [6.07.01] #

Alleen als: Hoe ziet je werkplek eruit? «Cloudwerkplek (bijvoorbeeld Microsoft 365)» of «Hybride: cloud naast een virtuele of lokale werkplek»

3. In de cloudomgeving geldt een apparaat als geauthenticeerd als het in het apparaatbeheer staat en aan het nalevingsbeleid voldoet. Andere apparaten krijgen hooguit de webversie zonder downloaden. [5.15.01] #

Alleen als: Hoe ziet je werkplek eruit? «On-premises» of «Hybride: cloud naast een virtuele of lokale werkplek»

4. Op het interne netwerk krijgt een apparaat pas toegang na authenticatie met een apparaatcertificaat (netwerktoegangscontrole). Toegang van buiten loopt via een VPN of virtuele werkplek die ook het apparaat controleert. [5.15.01] #

7. Toegangsrechten en periodieke beoordeling#

1. Een bevoegde leidinggevende vraagt rechten aan via het ticketsysteem; functioneel beheer toetst de aanvraag aan de autorisatiematrix en richt de rechten in. Het ticket toont aanvraag, goedkeuring en inrichting. [5.18.02, 8.03.02] #
2. Gebruikers zien en bewerken alleen de informatie die ze voor hun taak nodig hebben. Een systeem met het label vertrouwelijk of hoger beperkt de toegang tot de dossiers of zaken waar de gebruiker bij betrokken is, waar het systeem dat ondersteunt. [8.03.02] #
3. De systeemeigenaar beoordeelt jaarlijks alle uitgegeven rechten van zijn systeem, met een overzicht van functioneel beheer, en legt de uitkomst vast. Voor systemen met het label vertrouwelijk of hoger is dat elk halfjaar. Onjuiste rechten worden binnen [hersteltermijn rechten] ingetrokken. [5.18.02] #
4. Kan functiescheiding door een kleine bezetting niet, dan legt de systeemeigenaar vast wie welke rollen combineert en waarom, en controleert hij elk kwartaal de handelingen van die persoon in de logging. [5.18.02] #

Alleen als: Op welke landelijke voorzieningen ben je aangesloten? «DigiD» of «Suwinet» of «BRP (als bronhouder of afnemer)» of «BAG of andere basisregistraties» of «Andere ketens met eigen beveiligingseisen»

5. Voor elke aansluiting op een landelijke voorziening geldt aanvullend het normenkader van die voorziening. De systeemeigenaar toont de naleving van de autorisatie-eisen aan in de jaarlijkse verantwoording over de aansluiting. [5.18.02] #

Alleen als: Op welke landelijke voorzieningen ben je aangesloten? «Suwinet»

6. Toegang tot Suwinet-Inkijk verloopt per rol die aansluit op de taak (bijvoorbeeld werk en inkomen of schuldhulpverlening). De systeemeigenaar beoordeelt de Suwinet-autorisaties elk kwartaal en laat het gebruik steekproefsgewijs controleren op raadplegingen zonder dossier of zaak. [5.18.02, 8.03.02] #

Alleen als: Op welke landelijke voorzieningen ben je aangesloten? «BRP (als bronhouder of afnemer)»

7. Raadpleging en wijziging van de BRP gebeuren alleen met rechten per rol volgens de autorisatie van de organisatie als afnemer of bronhouder. De systeemeigenaar beoordeelt de rechten om persoonslijsten te wijzigen elk kwartaal. [5.18.02, 8.03.02] #

Alleen als: Op welke landelijke voorzieningen ben je aangesloten? «DigiD»

8. De systeemeigenaar beoordeelt elk kwartaal de beheerrechten op de webapplicaties en infrastructuur achter de DigiD-aansluiting, als voorbereiding op het DigiD-assessment. [8.02.01] #

Alleen als: Verwerk je politiegegevens (boa's, opsporing, handhaving)? «Ja»

9. Politiegegevens (bijvoorbeeld van boa's) staan in een omgeving die alleen toegankelijk is voor medewerkers die de organisatie daartoe schriftelijk heeft geautoriseerd onder de Wpg. De autorisatie noemt per persoon het doel en de categorie gegevens. [8.03.01, 8.03.02] #
10. De systeemeigenaar beoordeelt de autorisaties voor politiegegevens elk halfjaar, en elke raadpleging wordt vastgelegd, zodat de periodieke Wpg-audit kan aantonen wie wat heeft ingezien. [5.18.02] #

8. Accounts met bijzondere rechten#

1. Een beheerder heeft een apart beheeraccount, zonder mail en internettoegang. [8.02.01] #
2. Beheerrechten worden waar het kan alleen voor de duur van een taak toegekend (just-in-time), met een aanvraag en een reden. Permanente rechten op het hoogste niveau (domein- of tenantbeheer) hebben ten hoogste [maximum aantal hoogste beheerders]. [8.02.01] #
3. [lijneigenaar logische toegang] houdt een register bij van accounts met bijzondere rechten: beheeraccounts, technische accounts, noodaccounts en accounts van leveranciers. De systeemeigenaar en de CISO beoordelen elk kwartaal opzet, bestaan en gebruik van die rechten en tekenen het verslag. [8.02.01] #
4. Het aanmaken van een account met bijzondere rechten en elke wijziging van zijn rechten levert automatisch een melding op. Een wijziging zonder goedgekeurde aanvraag is een beveiligingsincident. [5.18.01] #
5. Een noodaccount ligt in een kluis met vier-ogentoegang; elk gebruik levert een melding op die de CISO beoordeelt. [5.18.01] #
6. Systeemhulpmiddelen die beveiligingsmaatregelen kunnen omzeilen (beheerconsoles, scripttools, debuggers, tools voor het lezen van geheugen of register) staan alleen ter beschikking van bevoegde beheerders en alleen als hun taak dat vraagt. Op werkplekken van gebruikers zijn ze geblokkeerd. [8.18.01] #
7. Het gebruik van systeemhulpmiddelen wordt gelogd. De logging blijft ten minste zes maanden beschikbaar voor onderzoek. [8.18.02] #

Alleen als: Wie beheert je IT? «Eigen beheer»

8. De eigen IT-afdeling houdt het register van accounts met bijzondere rechten bij en richt de meldingen in. De beoordeling per kwartaal gebeurt door iemand buiten het beheerteam. [5.18.01, 8.02.01] #

Alleen als: Wie beheert je IT? «Regie: eigen organisatie stuurt, beheer is uitbesteed» of «Volledig uitbesteed»

9. De beheerpartij levert elk kwartaal een overzicht van alle accounts met bijzondere rechten op de systemen van de organisatie, met de wijzigingen. De organisatie beoordeelt dat overzicht; de beheerpartij meldt een niet goedgekeurde wijziging als beveiligingsincident binnen de termijn uit het contract. [5.18.01, 8.02.01] #
10. Het contract bepaalt dat de beheerpartij systeemhulpmiddelen alleen inzet voor de afgesproken dienstverlening en de logging daarvan zes maanden bewaart en op verzoek levert. [8.18.01, 8.18.02] #

9. Toegang voor leveranciers#

1. Een leverancier krijgt toegang tot het netwerk of een systeem pas na een risicoafweging door de systeemeigenaar: welke systemen, welke rechten, vanaf waar en voor hoe lang. Een leidinggevende van de organisatie is verantwoordelijk voor het account en zegt het op als het werk klaar is. [8.05.01] #
2. Een leveranciersaccount staat standaard uit en wordt per werkzaamheid geactiveerd, voor ten hoogste [maximale activeringsduur], altijd met MFA en via een afgeschermde beheeromgeving. [8.05.01] #
3. Het register van leveranciersaccounts laat zien wie toegang heeft, wie die heeft goedgekeurd en wanneer ze is geactiveerd en beëindigd. [8.05.01] #

10. Informatie met een hoog vertrouwelijkheidslabel#

1. Informatie met het label vertrouwelijk, strikt vertrouwelijk of geheim (beleid informatieclassificatie) staat in aparte systemen, databases of omgevingen die fysiek of logisch gescheiden zijn van de algemene werkomgeving, met een eigen autorisatie die de systeemeigenaar vaststelt. [8.03.01] #

Alleen als: In welke gevoelige domeinen verwerk je persoonsgegevens? «Sociaal domein» of «Jeugd» of «Gezondheid (WvGGZ, NTA 7516)»

2. Dossiers in het sociaal domein, over jeugd of over gezondheid staan in een zaak- of dossiersysteem met autorisatie per dossier of per team, niet op gedeelde netwerkschijven of in algemene teamsites. Inzage buiten de eigen caseload wordt gelogd en door de systeemeigenaar elk kwartaal steekproefsgewijs gecontroleerd. [8.03.01, 8.03.02] #

11. Broncode#

1. Toegang tot broncode, scripts en configuratiebestanden in een repository is beperkt tot de ontwikkelaars en beheerders die eraan werken; de eigenaar van de repository kent lees- en schrijfrechten apart toe en beoordeelt elk halfjaar wie toegang heeft. [8.04.01] #
2. Een wijziging op de hoofdtak komt er alleen in na review door een tweede persoon; de repository dwingt dat af en legt vast wie wat heeft goedgekeurd. Broncode van systemen met het label vertrouwelijk of hoger staat niet in een openbare repository. [8.04.01] #

12. Rollen en verantwoordelijkheden#

13. Naleving en controle#

Controleraamwerk. De naleving van dit beleid wordt met de volgende controles aangetoond. De uitkomst en het bewijs worden vastgelegd in [registratie van controles]; afwijkingen gaan als bevinding naar het risicoregister.

Afwijkingen. Afwijken van een eis kan alleen op basis van een gedocumenteerde risicoafweging. De systeemeigenaar dient het verzoek in bij de CISO, met de reden, de compenserende maatregelen en de looptijd. De afwijking geldt pas na acceptatie van het risico door [risico-eigenaar] en staat in het risicoregister; afwijkingen worden ten minste jaarlijks opnieuw beoordeeld.

Niet naleven. Het niet naleven van dit beleid wordt behandeld als beveiligingsincident en kan leiden tot het intrekken van toegangsrechten of tot maatregelen volgens de rechtspositieregeling of het contract.

14. Samenhang#

Dit beleid valt onder het strategisch informatiebeveiligingsbeleid. Het raakt het beleid screening, bewustzijn en opleiding (in- en uitdiensttreding), het beleid informatieclassificatie (labels), het beleid informatiebeveiliging bij inkoop en contractbeheer (beheerpartijen), het beleid logging en monitoring (aanmeldingen en beheerhandelingen), het beleid netwerkbeveiliging (beheerinterfaces), het beleid veilige softwareontwikkeling (repositories) en het beleid mobile device management (apparaten).

Bijlage A: BIO 2.0-maatregelen#

De maatregelen van dit domein (16, waarvan 14 overheidsmaatregelen), waar dit stuk ze invult en welke controle ze aantoont. Nummers volgens BIO2 v1.3 definitief - 9 januari 2026; de tekst van de maatregel staat bij het CIP. Waar de BIO 2.0 geen overheidsmaatregel kent, geldt de ISO 27002-beheersmaatregel.

Bijlage B: Afkortingen#

Nog in te vullen#

• lijneigenaar logische toegang: de manager die dit beleid uitvoert, bijvoorbeeld het hoofd IT of informatievoorziening
• termijn verwijderen accounts: bijvoorbeeld 90 dagen na blokkade
• termijn inactiviteit: bijvoorbeeld 60 dagen
• bewaking aanmeldingen: het SOC, de SOC-dienstverlener of de beheerder die de meldingen beoordeelt
• aantal mislukte pogingen: bijvoorbeeld 5
• minimale wachtwoordlengte: bijvoorbeeld 12 tekens voor gebruikers en 16 voor beheerders
• hersteltermijn rechten: bijvoorbeeld tien werkdagen
• maximum aantal hoogste beheerders: bijvoorbeeld drie benoemde personen plus een noodaccount
• maximale activeringsduur: bijvoorbeeld 14 dagen
• registratie van controles: het systeem waarin controles worden vastgelegd, bijvoorbeeld het ticketsysteem of het managementsysteem
• risico-eigenaar: de manager die restrisico's accepteert
• eigenaar van dit beleid: de manager die dit beleid uitvoert en laat naleven
• vaststeller: wie het beleid vaststelt, bijvoorbeeld de directie of het bestuur