# Access control

How access to customer data is controlled.

## 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

| Principle | Description |
| --- | --- |
| **Least privilege** | Access is limited to the minimum required for the task |
| **Just-in-time access** | No standing permissions · access is granted per request |
| **Dual approval** | Every request requires sign-off from CTO or CEO |
| **Time-bound** | All access expires automatically (default: 30 days) |
| **Fully auditable** | Every 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

| Role | Responsibility |
| --- | --- |
| **CTO** | Leads access control policy, approves requests, oversees infrastructure security |
| **CEO** | Co-approver for access requests, owns compliance implications |
| **Engineering** | Submits requests via MR, follows provisioning process, reports anomalies |

## 7. Contact

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