Access Control Policy
This policy describes how Bunker governs access to its systems and to the data entrusted by its customers. On the access-control dimension, it implements the principles of our information security policy and covers controls A.5.15 to A.5.18 and A.8.2, A.8.3, A.8.5 of the Statement of Applicability.
Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.
Purpose and scope
This policy applies to all access to ISMS components (the admin console, the API, the nuage CLI, the hosting infrastructure and internal tooling). It covers employees, contractors and automated systems.
Principles
- Least privilege by default: an account is granted only the rights strictly needed for its role; read-only access is the default.
- Need to know: access to information is conditioned on a legitimate need, reinforced by tenant isolation.
- Centralised identity: a single identity source, no scattered local accounts.
- Authority in the database, never in a token: administrative rights are authoritative server-side; they are never inferred from a token presented by the client.
- Traceable revocation: access is removed when a person leaves and is reviewed periodically.
Measures
| Area | Measure |
|---|---|
| Identities | Centralised single sign-on (SSO) through Keycloak, migrating to the sovereign IAM FerrisKey (A.5.16). |
| Authentication | OIDC / JWT as a confidential client (BFF architecture), encrypted httpOnly server-side session, anti-replay protection; MFA handled at the identity provider (A.5.17, A.8.5). |
| Authorisation | Fine-grained, relationship-based authorisation model (organisation → folder → project → instance), tested in continuous integration (A.5.18). |
| Privileges | RBAC read-only by default, administrative rights authoritative in the database (A.8.2). |
| Segmentation | Access restriction through network and logical isolation between tenants; need-to-know enforced technically (A.8.3). |
| Review | Centralised access control, least privilege and periodic access review (A.5.15). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy and the assignment of privileged roles.
- Each team lead validates access within their scope.
- Everyone with access protects their credentials and reports any abnormal access without delay to [email protected].
Status and roadmap
Access control, identity, authentication and authorisation measures are in place and operational (A.5.15–A.5.18, A.8.2, A.8.3, A.8.5). Two adjacent items remain in formalisation, source-code branch-protection settings (A.8.4, partial) and the traceable offboarding procedure that revokes access on departure (A.6.5, partial).
Review
This policy is reviewed at least once a year and whenever our identity and access mechanisms change significantly.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.5.15–18 and A.8.2–5)
- Authentication (how platform authentication works)
- Network Security Policy (the network isolation that underpins access segmentation)
- Information Security Policy (the ISMS framework this policy derives from)