AC-03 Access Enforcement

Self-assessed, not audited

We hold no certification or authorization. The status below is our own assessment, kept as OSCAL in Git; it is not an auditor's finding. "Planned" means not built.

Control statement

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Guidance

Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection ( PE ) family.

Implementation

OpenBao SPIFFE JWT auth and policies (canary)

Access to secrets is enforced by OpenBao ACL policies attached to the JWT role: agent 15-2041.00 can read only secret/data/canary/agents/15-2041.00/*. Partial, manual: declared config, not checked live by the job.

Status: partial.

Evidence:

• https://github.com/zeta-reticuli-inc/talos-platform/blob/main/clusters/proxmox-canary/openbao/helmrelease.yaml
• https://github.com/zeta-reticuli-inc/agents/blob/main/deploy/base/openbao/agent-canary-15-2041.00.hcl

All controls. Source: OSCAL component definition reti-platform and NIST SP 800-53 Rev 5 (public domain).