Toegangsbeheer

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

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

7. Contact

• Security / toegangsbeheer: compliance@cortena.ai
• DPO / Privacy (GDPR): dpo@cortena.ai