Help
App openenPlan een gesprek
Aan de slagGidsenComplianceSupportApp openenPlan een gesprek

Access control

How access to customer data is controlled.

Engelse versie wordt getoond

1. Purpose

To ensure that access to production infrastructure and customer data is strictly controlled, time-bound, auditable, and granted only on a need-to-know basis.

2. Scope

Applies to all Cortena team members, contractors, and any third party requiring access to production systems, including:

  • Kubernetes cluster (Rancher)
  • Databases (MongoDB)
  • Object storage (MinIO / S3)
  • Monitoring and alerting systems (Grafana, Sentry)
  • CI/CD runners and secrets
  • Internal APIs and services

3. Core principles

PrincipleDescription
Least privilegeAccess is limited to the minimum required for the task
Just-in-time accessNo standing permissions · access is granted per request
Dual approvalEvery request requires sign-off from CTO or CEO
Time-boundAll access expires automatically (default: 30 days)
Fully auditableEvery request, approval, and revocation is logged in version control

No direct access to production systems is permitted without completing this process.

4. Access request process

4.1 Submit request

Any team member requiring production access must:

  1. Create a Merge Request (MR) in the infrastructure or ops repository
  2. Include in the MR description: name and role, asset(s) required, business justification, requested duration (maximum 30 days), and scope of access (for example read-only, specific collections)

4.2 Approval

  • The MR must be approved by the CTO or CEO before any access is granted
  • No access is provisioned without explicit written approval
  • Approval is recorded in Git, creating a fully auditable trail

4.3 Provisioning

Upon approval, access is provisioned automatically via Ansible:

  • User is added to OpenVPN (secure internal network access)
  • RBAC role is granted in Kubernetes with the defined scope
  • Expiry date is set in the access registry

Access provisioning is always automated and version-controlled, never manual.

4.4 Monitoring

  • Active sessions are monitored via Grafana and OpenVPN logs
  • Any anomalous activity triggers an internal review

4.5 Expiry and extension

  • All access expires automatically after the approved duration
  • Extensions require a new MR and re-approval. No silent renewals.
  • Active access lists are reviewed quarterly by the CTO to ensure no stale permissions remain

4.6 Revocation

  • Access can be revoked immediately via Ansible if a security risk is identified
  • Revocation removes the user from all systems in a single automated operation
  • The full audit trail is preserved in Git

5. Example access request

Access Request: Investigate Failed Sync Job

- Name: [Engineer Name], [Role]
- Asset: MongoDB (production), Grafana
- Reason: Investigate failed sync job reported in Sentry (ticket #123)
- Duration: 7 days
- Scope: Read-only access to MongoDB collections · users and jobs

Approval requested from CTO and CEO

6. Roles and responsibilities

RoleResponsibility
CTOLeads access control policy, approves requests, oversees infrastructure security
CEOCo-approver for access requests, owns compliance implications
EngineeringSubmits requests via MR, follows provisioning process, reports anomalies

7. Contact