Toegangsbeheersing

Iedereen krijgt alleen de toegang die nodig is voor het werk.

Hoe het werkt

• Least privilege: toegangsrechten worden per applicatie op functieniveau bepaald. Stagiairs krijgen geen toegang tot vertrouwelijke klantdata.
• De applicatie-eigenaar kent rechten toe, wijzigt en trekt in.
• Google Workspace-SSO waar de dienst dat ondersteunt (o.a. Atlassian), anders een eigen account; MFA waar de dienst het ondersteunt (zie 5.16, 5.17).
• Productiesystemen zijn bereikbaar via gcloud proxy, kubectl en Google Cloud IAM; buiten vertrouwde netwerken via Cloudflare Zero Trust (zie 6.07, 8.20).
• Admin-accounts: GitHub-organisatiebeheer door de DevOps Lead, Google Workspace-beheer door de directie.

On- en offboarding

Accounts worden aangemaakt en gedeactiveerd via de checklists “Medewerker in dienst” en “Medewerker uit dienst” in Jira ISMS (zie 6.02, 6.05). De IB-coördinator verifieert bij uitdiensttreding dat alles is ingetrokken.

Periodieke controle

Jaarlijkse autorisatiereview van de autorisatiematrix door de IB-coördinator met de applicatie-eigenaren (controleprogramma C.07).

NEN7510 zorgspecifiek

• Z1 — Toegang tot patiëntgegevens: RBAC-framework voor zorgapplicaties
• Z3 — Noodtoegang (break-the-glass): noodprocedure voor toegang buiten reguliere autorisatie

Gaps

• De autorisatiematrix (applicatie, eigenaar, toegangsprocedure; voorheen OUD 04.02a/07.02) is nog niet overgenomen in het ISMS (ISMS-300).
• De jaarlijkse autorisatiereview is voor het laatst uitgevoerd in mei 2023 (ISMS-216); de volgende ronde loopt via C.07 (ISMS-268).

Bewijs

• Google Workspace-admin: SSO-koppelingen
• GCP-console: IAM-rollen per project
• On-/offboarding-checklists: Jira ISMS (ticket per medewerker)
• Autorisatiereview: Jira ISMS C.07 (laatste: ISMS-216, mei 2023)
• Autorisatiematrix: nog geen bewijs; zie Gaps.