# Toegangsbeheer

Hoe toegang tot klantgegevens wordt beheerd.

## 1. Doel

Ervoor zorgen dat toegang tot productie-infrastructuur en klantgegevens strikt wordt beheerd, tijdgebonden en controleerbaar is, en alleen wordt verleend op basis van need-to-know.

## 2. Reikwijdte

Van toepassing op alle teamleden van Cortena, contractanten en derden die toegang tot productiesystemen nodig hebben, waaronder:

- Kubernetes-cluster (Rancher)
- Databases (MongoDB)
- Object storage (MinIO / S3)
- Monitoring- en waarschuwingssystemen (Grafana, Sentry)
- CI/CD-runners en secrets
- Interne API's en services

## 3. Kernprincipes

| Principe | Beschrijving |
| --- | --- |
| **Minimale rechten** | Toegang is beperkt tot het minimum dat voor de taak nodig is |
| **Just-in-time-toegang** | Geen permanente rechten · toegang wordt per verzoek verleend |
| **Dubbele goedkeuring** | Elk verzoek vereist goedkeuring van de CTO of CEO |
| **Tijdgebonden** | Alle toegang verloopt automatisch, standaard na 30 dagen |
| **Volledig controleerbaar** | Elk verzoek, elke goedkeuring en elke intrekking wordt vastgelegd in versiebeheer |

Directe toegang tot productiesystemen is niet toegestaan zonder dit proces te doorlopen.

## 4. Proces voor toegangsverzoeken

### 4.1 Verzoek indienen

Elk teamlid dat toegang tot productie nodig heeft, moet:

1. Een **Merge Request (MR)** aanmaken in de repository `infrastructure` of `ops`
2. In de beschrijving van de MR opnemen: naam en rol, benodigde asset(s), zakelijke onderbouwing, gewenste duur, maximaal 30 dagen, en toegangsbereik, bijvoorbeeld alleen-lezen of specifieke collecties

### 4.2 Goedkeuring

- De MR moet door de **CTO of CEO** worden goedgekeurd voordat toegang wordt verleend
- Er wordt geen toegang ingericht zonder expliciete schriftelijke goedkeuring
- De goedkeuring wordt vastgelegd in Git, waardoor een volledig controleerbaar auditspoor ontstaat

### 4.3 Inrichting

Na goedkeuring wordt de toegang automatisch ingericht via Ansible:

- De gebruiker wordt toegevoegd aan OpenVPN voor beveiligde toegang tot het interne netwerk
- De RBAC-rol wordt toegekend in Kubernetes met het vastgestelde bereik
- De vervaldatum wordt ingesteld in het toegangsregister

Het inrichten van toegang gebeurt altijd geautomatiseerd en met versiebeheer, nooit handmatig.

### 4.4 Monitoring

- Actieve sessies worden gemonitord via Grafana en OpenVPN-logs
- Verdachte activiteit leidt tot een interne beoordeling

### 4.5 Verloop en verlenging

- Alle toegang verloopt automatisch na de goedgekeurde periode
- Voor verlenging is een **nieuwe MR en nieuwe goedkeuring** nodig. Stilzwijgende verlengingen zijn niet toegestaan.
- Actieve toegangslijsten worden elk kwartaal door de CTO beoordeeld om ervoor te zorgen dat er geen verouderde rechten blijven bestaan

### 4.6 Intrekking

- Toegang kan onmiddellijk via Ansible worden ingetrokken als een beveiligingsrisico wordt vastgesteld
- Door intrekking wordt de gebruiker in één geautomatiseerde handeling uit alle systemen verwijderd
- Het volledige auditspoor blijft bewaard in Git

## 5. Voorbeeld van een toegangsverzoek

```
Toegangsverzoek: Mislukte synchronisatietaak onderzoeken

- Naam: [Naam engineer], [Rol]
- Asset: MongoDB (productie), Grafana
- Reden: Mislukte synchronisatietaak onderzoeken die in Sentry is gemeld (ticket #123)
- Duur: 7 dagen
- Bereik: Alleen-lezen toegang tot MongoDB-collecties · users en jobs

Goedkeuring gevraagd van CTO en CEO
```

## 6. Rollen en verantwoordelijkheden

| Rol | Verantwoordelijkheid |
| --- | --- |
| **CTO** | Stuurt het beleid voor toegangsbeheer aan, keurt verzoeken goed en houdt toezicht op de beveiliging van de infrastructuur |
| **CEO** | Mede-goedkeurder van toegangsverzoeken en verantwoordelijk voor gevolgen voor compliance |
| **Engineering** | Dient verzoeken in via MR, volgt het inrichtingsproces en meldt afwijkingen |

## 7. Contact

- Security / toegangsbeheer: [compliance@cortena.ai](mailto:compliance@cortena.ai)
- DPO / Privacy (GDPR): [dpo@cortena.ai](mailto:dpo@cortena.ai)