159 lines
10 KiB
Markdown
159 lines
10 KiB
Markdown
# Toegangsbeleid Applicaties Humankind
|
||
|
||
Versie 0.1, 23 juni 2025
|
||
|
||
Richard Kranendonk
|
||
|
||
<u>Doel: bepalen van noodzakelijke en gewenste rechten in applicaties.</u>
|
||
|
||
Versie informatie
|
||
|
||
| **Datum** | **Versie** | **Wijziging** | **Akkoord** | **Datum** |
|
||
|-----------|------------|----------------|-------------|-----------|
|
||
| 10-6-23 | 0.1 | Eerste concept | | |
|
||
| | | | | |
|
||
| | | | | |
|
||
| | | | | |
|
||
|
||
|
||
# Documentbeheer
|
||
|
||
| **Beleidseigenaar** | Manager IM |
|
||
|----|----|
|
||
| **Documenteigenaar** | n.t.b. |
|
||
| **Herzieningscyclus** | Jaarlijks |
|
||
| **Volgende herzieningsdatum** | n.t.b. |
|
||
| **Classificatie** | <span class="mark">TLP:Green (Intern)</span> |
|
||
| **Status** | Concept |
|
||
|
||
# Doel
|
||
|
||
Binnen Humankind verwerken we grote hoeveelheden informatie in veel verschillende applicaties (bij een recente telling zaten we op ongeveer 85 applicaties). Dit document beschrijft wie toegang heeft tot welke applicaties en onder welke voorwaarden. Daarmee worden meerdere doelen gediend:
|
||
|
||
- het beschermen van gevoelige gegevens tegen ongeoorloofde toegang
|
||
|
||
- vermindering van het risico op fouten en willekeur door een consistent en gestandaardiseerd proces
|
||
|
||
- compliance met wet- en regelgeving (o.a. NIS 2, ISO 27001/NEN 7510, AVG)
|
||
|
||
- vergroting van de beheersbaarheid van toegangsverlening over een groot aantal applicaties.
|
||
|
||
# Noodzaak
|
||
|
||
Het is voor de afdeling Informatiemanagement praktisch onuitvoerbaar om het rechtenbeheer te voeren over alle applicaties die binnen Humankind gebruikt worden. Daarom is het beheer van rechten voor applicaties buiten de Microsoft omgeving gedelegeerd aan de Functioneel Beheerders. Vanuit het oogpunt van informatiebeveiliging is het verstandig als ze hiervoor duidelijke richtlijnen kunnen volgen, die beleidsmatig zijn vastgesteld.
|
||
|
||
# Toepassingsgebied
|
||
|
||
Dit beleid is van toepassing op alle applicaties die gebruikt worden binnen Humankind, m.n. de verschillende SaaS applicaties.
|
||
|
||
# Principes
|
||
|
||
De toegang tot vertrouwelijke informatie moet beperkt worden tot de mensen die de informatie nodig hebben voor het uitoefenen van hun functie binnen de organisatie. Dit is het **'need to know**' principe. De achterliggende gedachte is simpel: hoe meer mensen een 'geheim' weten, des te groter de kans dat het uitlekt.
|
||
|
||
Het is ook verstandig om mensen niet méér rechten te geven in applicaties dan nodig is. De integriteit van informatie loopt gevaar als rechten te breed gesteld zijn – denk aan het wijzigen van salarisgegevens, het goedkeuren van inkoopfacturen, of het toevoegen of verwijderen van gebruikers in een systeem. Dit is het **'least privilege**' principe.
|
||
|
||
Deze twee principes vormen de basis voor het toegangsbeleid van Humankind. Vanuit deze principes bouwen we een 'Rechtenmatrix', waarin is vastgelegd welke informatie toegankelijk moet zijn voor welke functies en rollen.
|
||
|
||
# Opbouwen van de rechtenmatrix
|
||
|
||
Bij het opbouwen van de rechtenmatrix gaan we uit van het Functieboek van Management en Organisatie, waarin per functie de taken, bevoegdheden en verantwoordelijkheden worden beschreven, en het Processenhuis uit het programma Beter Sturen, waarin per afdeling is vastgelegd welke processen er worden aangestuurd en uitgevoerd.
|
||
|
||
Het opbouwen gebeurt in de volgende stappen:
|
||
|
||
1. We bekijken per functie uit het Functieboek welke werkzaamheden bij die functie horen (het Processenhuis kan daarbij helpen)
|
||
2. We bepalen op basis van de werkzaamheden welke gegevens *minimaal* nodig zijn om ze uit te voeren ('need to know'), en uit welke applicaties die gegevens moeten komen
|
||
3. We bepalen welke rechten in ieder systeem *noodzakelijk* zijn, om het werk dat bij de functie hoort te kunnen uitvoeren (‘least privilege’).
|
||
4. We stemmen met de Functioneel Beheerders af hoe dit in de verschillende applicaties gestructureerd kan worden: hoe is de informatievoorziening opgedeeld in modules/schermen/rapportages, welke mogelijkheden zijn er om rechten te structureren in bijv. profielen, rollen en functies.
|
||
5. We werken de toegangsrechten uit in een zgn. BREAD-matrix (zie hieronder).
|
||
|
||
Deze werkzaamheden worden uitgevoerd door, of in opdracht van, de afdeling Informatievoorziening.
|
||
|
||
**Toelichting BREAD-matrix**
|
||
|
||
De BREAD-matrix is een hulpmiddel om de toekenning van rechten te structureren. BREAD[^1] is een acronym voor:
|
||
|
||
- **Browse**: overzichten bekijken, maar niet de details (denk aan personeelsoverzichten, maar niet de gegevens van individuen, vaak om privacy-redenen )
|
||
- **Read**: bekijken of inzien, ook van details
|
||
- **Edit**: wijzigen
|
||
- **Add**: invoeren of aanmaken
|
||
- **Delete**: verwijderen
|
||
|
||
Dit is een voorbeeld van een BREAD-matrix zoals die voor Humankind wordt opgezet:
|
||
|
||
| | **KidsVision** | | | **Mercash** | |
|
||
|----|----|----|----|----|----|
|
||
| | Medewerkers | Urenregistratie | Contactgegevens Ouders | Salarissen | Betalingsbestand |
|
||
| **Functie** | | | | | |
|
||
| Personeelsplanner | BR | \- | \- | \- | \- |
|
||
| Vestigingsmanager | B | BR | BRE | \- | \- |
|
||
| Pedagogisch medewerker | \- | READ | BR | \- | \- |
|
||
| Mdw Salarisadministratie | BR | BR | \- | BREAD | BREA |
|
||
| Hfd Salarisadministratie | B | B | \- | B | BREAD |
|
||
|
||
Soms zal een extra beperking worden toegevoegd, bijv.: 'Alleen voor zijn/haar locatie'.
|
||
|
||
Wat er boven de kolommen staat, kan ws. het best bepaald worden door de functioneel beheerders, omdat zij in detail weten hoe de applicatie is ingericht.
|
||
|
||
## Beheersrechten
|
||
|
||
De meeste applicaties voorzien in (soms verschillende niveaus van) beheersrechten: de mogelijkheid om systeemtabellen te wijzigingen, in te grijpen op rechtenprofielen, de opbouw en samenstelling van toegangsmenu’s, schermen en rapportages te wijzigen, etc.
|
||
|
||
Met de beheerders zal vastgesteld worden welke rechten als beheersrechten gekwalificeerd worden. Deze rechten moeten duidelijk herkenbaar zijn in de matrix.
|
||
|
||
# Toepassing
|
||
|
||
De rechtenmatrix wordt gebruikt bij het toekennen, wijzigingen en ontnemen van gebruikersrechten door de verschillende beheerders.
|
||
|
||
Dit gebeurt in de volgende gevallen:
|
||
|
||
1. **Indiensttreding nieuwe medewerker**: de beheerder koppelt het gebruikersaccount aan het overeenkomstige rechtenprofiel in de applicatie.
|
||
|
||
2. **Wijziging van functie**: de beheerder koppelt de beheerder koppelt in de applicatie het gebruikersaccount aan het rechtenprofiel dat overeenkomt met de nieuwe functie, en ontkoppelt het rechtenprofiel van de vorige functie.
|
||
|
||
3. **Uitdiensttreding medewerker:** de beheerder ontkoppelt alle rechten van de vertrekkende medewerker.
|
||
|
||
Het toekennen en ontnemen van rechten wordt door de beheerder op datum geregistreerd, met vermelding van het betreffende gebruikersaccount en een beschrijving van de wijziging.
|
||
|
||
Belangrijk is dat toegekende rechten één op één af te leiden zijn uit de functie die de medewerker in de organisatie vervult, zoals aangegeven in de matrix. Vanuit het oogpunt van informatiebeveiliging en compliance is het niet wenselijk om de toegangsrechten te laten bepalen door een hiërarchisch leidinggevende. Bij dringende noodzaak om toch af te wijken van de matrix, moet dit geregistreerd en gemeld worden door de beheerder, zodat de afdeling Informatiemanagement de afwijking kan beoordelen.
|
||
|
||
*Alternatief:*
|
||
|
||
*De opdracht tot toekenning en/of ontnemen van van rechten wordt aan de beheerder verstrekt door de afdeling Informatiemanagement, op aangeven van de afdeling Ontwikkeling en Organisatie. Zo ontstaat een heldere scheiding van verantwoordelijkheden t.o.v. ‘de lijn’.*
|
||
|
||
## Toekenning van beheersrechten
|
||
|
||
In de opbouw van de matrix is vastgesteld welke rechten kwalificeren als beheersrechten – dit is duidelijk herkenbaar in de matrix.
|
||
|
||
Wijzigingen in de toekenning van beheersrechten worden door de beheerder geregistreerd en gemeld aan de afdeling Informatiemanagement (vier-ogen-principe).
|
||
|
||
## Wijziging informatievoorziening binnen een applicatie
|
||
|
||
Gebruikers met voldoende rechten kunnen vaak de structuur van de informatievoorziening binnen een applicatie wijzigen. Denk aan wijzigingen in de opbouw en samenstelling van schermen, rapportages en toegangsmenu’s, en de inhoud van rechtenprofielen. Dit kan een verschuiving tot gevolg hebben in de toegang tot informatie binnen een bepaalde functie.
|
||
|
||
De beheerder moet er alert op zijn dat medewerkers hierdoor geen toegang krijgen tot gegevens die volgens de matrix niet bij zijn/haar functie horen. Is dat (mogelijk) wel het geval, dan zal de beheerder dit melden aan de afdeling Informatievoorziening. De verdere afhandeling is beschreven in de paragraaf Onderhoud van de rechtenmatrix.
|
||
|
||
## Review
|
||
|
||
De aan gebruikersaccounts per applicatie toegekende rechten worden door de afdeling Informatiemanagement periodiek gecontroleerd. Vanwege het aantal medewerkers moet nog bekeken worden hoe dit praktisch kan worden vormgegeven. Te denken valt aan het nemen van steekproeven, het controleren in maandelijkse batches, en het uitzonderen van controle op de toegangsverlening aan pedagogisch medewerkers (m.u.v. een geautomatiseerde controle van rechten t.o.v. de Active Directory, bijvoorbeeld).
|
||
|
||
# Onderhoud van de rechtenmatrix
|
||
|
||
Er zijn verschillende redenen om de inhoud van de rechtenmatrix (op onderdelen) ter herzien, bijv.:
|
||
|
||
- Wijzigingen in het Functiehuis: nieuwe functies worden toegevoegd, of de inhoud van bestaande functies wijzigt
|
||
|
||
- Wijzigingen in het Processenhuis
|
||
|
||
- Afwijkingen van de matrix (zie de paragraaf Toepassing)
|
||
|
||
- Wijzigingen in het applicatielandschap
|
||
|
||
- Nieuwe functionaliteit in een applicatie
|
||
|
||
- Wijzigingen in de rechtenstructuur van een applicatie
|
||
|
||
Als deze veranderingen zich voordoen, worden deze gemeld bij de afdeling Informatiemanagement. Deze brengen vervolgens, in overleg met de beheerders, de consequenties van deze veranderingen in kaart, en doen een voorstel tot wijziging van de rechtenmatrix aan de Manager Informatievoorziening. Hierbij moet een logische en eenduidige relatie met het Functiehuis in acht worden genomen.
|
||
|
||
Wijzigingen in de matrix die betrekking hebben op beheersrechten moeten goedgekeurd worden door de Manager Bedrijfsvoering.
|
||
|
||
[^1]: De BREAD-matrix is een variant op de bekendere CRUD-matrix (Create, Read, Update, Delete), maar met termen die dichter bij de gebruiker liggen.
|