Access Control Review

Policy and procedure for reviewing identity, permissions, and privileged access across the Cirius Group estate. This document satisfies COMP-012 and is the source of truth for the quarterly access review cadence.

Scope

Covers human and non-human identity across:

• Azure / Entra ID — PROD tenant d477c9f8 and DDE tenant ff1c5d68
• AWS — all organization accounts under the Cirius Group payer
• On-prem Active Directory — actdirap04-hosted domain controllers
• SaaS joiners — Microsoft 365, Arctic Wolf, Cortex XDR, Twingate, SecOps platform

Access Model

Cirius Group operates a three-layer access architecture: identity (who), authorization (what), and audit (observed). This document is concerned with the authorization layer, but any privileged grant must be traceable across all three.

Azure / Entra ID (PROD + DDE)

• RBAC at subscription, resource group, and resource scope. No classic co-admin assignments permitted.
• PIM (Privileged Identity Management) required for any role granting Owner, Contributor, or User Access Administrator on subscriptions and management groups.
• Break-glass accounts (18, see separate registry) are cloud-only, FIDO2-backed, and exempt from Conditional Access blocks. They are permanently unsuppressible in SIEM alerting.
• DDE tenant hosts pre-production and development workloads. Cross-tenant B2B is only permitted for named infrastructure service principals; no user guest invitations without Rory approval.

AWS

• IAM Identity Center (SSO) is the only authorized path for human access. Long-lived IAM users are prohibited outside of break-glass and named service accounts.
• Permission sets mapped to Entra groups. Production access uses a dedicated ProdAdmin permission set with session-scoped elevation.
• IAM roles for workload identity use OIDC federation where the source supports it (GitHub Actions, EKS service accounts).

On-prem Active Directory

• Tiered administration model (see permission tiers below). Domain Admin membership is break-glass only.
• LAPS (Windows LAPS) manages local administrator passwords on all domain-joined endpoints.
• Group Managed Service Accounts (gMSA) for service identities; no shared service account passwords.

Permission Tiers

Tiers are listed from highest to lowest sensitivity. Elevation between tiers requires an explicit ticket and named approver.

Tier	Identity Class	Example Principals	Approver	Review Cadence
0	Break-glass	18 registered accounts (cloud + on-prem)	Rory	Annual + on-use
1	Tier 1 Domain Admin	On-prem Enterprise / Domain Admin, Azure Global Admin, AWS Org root	Rory	Quarterly
2	Infrastructure service principals	Terraform runner, deployment automation, CI/CD	Rory	Quarterly
3	Tier 2 administrators	Server admins, Entra Role-scoped admins (Exchange, Intune)	Rory	Quarterly
4	Power users	Developers with read/write to non-prod, compliance reviewers	Manager	Semi-annual
5	Standard users	Day-to-day employee access, M365 licenses, standard SaaS	Manager	Annual

The ordering implies a strict access ladder:

1. Break-glass > Tier 1 domain admin
2. Tier 1 domain admin > infra service principals
3. Infra service principals > standard users

Privileged accounts in Tier 0 and Tier 1 must never be used for day-to-day work; day-to-day accounts must never receive Tier 0 or Tier 1 roles.

Quarterly Access Review Procedure

Runs the first week of each calendar quarter (January, April, July, October). Rory is the accountable reviewer; Kobe performs the mechanical data gathering.

Step 1 — Data collection (automated)

1. Export Entra role assignments for PROD and DDE tenants (PIM active + eligible).
2. Export AWS IAM Identity Center assignments and permission set memberships across all accounts.
3. Export on-prem AD privileged group memberships (Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, Print Operators, plus any delegated OU admins).
4. Export SaaS admin role memberships (M365 Global/Role, Arctic Wolf Concierge, Cortex XDR Superuser, Twingate Admin).
5. Snapshot break-glass registry and confirm 18 accounts match the permanent exception list.

Step 2 — Drift detection

Compare current quarter snapshot against prior quarter snapshot. Flag:

• New assignments since last review
• Accounts disabled or deleted that still carry role memberships
• Service principals with unused credentials older than 90 days
• PIM-eligible roles that were activated without an approved ticket
• Break-glass accounts with any non-emergency session activity

Step 3 — Manager attestation

Each tier owner reviews their in-tier population and attests or proposes changes. Rory attests Tiers 0-2 directly. Tier 3-5 attestations are collected via a Forms survey with named manager of record.

Step 4 — Remediation

Changes from Step 3 are executed under change control and recorded against this review cycle's ticket. Remediation window is two weeks from the end of the attestation period.

Step 5 — Evidence capture

The completed review cycle produces the following evidence artifacts, stored in the compliance evidence store:

• Snapshot CSVs for each identity source
• Drift report
• Manager attestation responses
• Remediation change tickets (linked)
• Rory sign-off memo

Current Known Privileged Accounts

The following are permanent fixtures of the access model. Any change to this list is itself a privileged operation and must be attested by Rory.

Tier 0 — Break-glass (18 accounts)

• Permanently unsuppressible in SIEM — any sign-in event generates a P1 alert.
• FIDO2 physical keys stored off-network in safe, with split-knowledge custody.
• Full registry maintained separately; referenced here for cross-linking only.

Tier 1 — Domain / Global Admin

• On-prem Domain Admins: named Rory account plus break-glass (Tier 0).
• Entra Global Administrators: Rory named account in PROD + DDE, plus break-glass.
• AWS Org root: break-glass only (MFA seed in safe).

Tier 2 — Infrastructure service principals

• Terraform runner (PROD): federated OIDC, no standing secret.
• Terraform runner (DDE): federated OIDC, no standing secret.
• GitHub Actions deployment SP (per repo, least-privilege per stack).
• Arctic Wolf MDR telemetry reader — least-privilege read on Activity Logs, Defender, and Sentinel workspaces.

Remediation for Over-Provisioned Access

When the quarterly review, a continuous audit tool, or an incident discovers over-provisioned access, the remediation path is:

1. Containment — if active risk, immediately revoke via PIM deactivation, SSO session revocation, and credential rotation as applicable.
2. Root cause — determine whether the over-provision was grant error, role creep, stale membership, or approval failure.
3. Correction — apply the minimum grant needed to perform the job function. Prefer PIM-eligible over standing membership; prefer role-scoped over tenant-scoped; prefer resource-scoped over subscription-scoped.
4. Control update — if the root cause indicates a systemic gap (for example, a missing automation check), file a follow-up story against the LPRIV or ADAUD project to close the gap.
5. Documentation — record the remediation outcome in the quarterly review evidence and reference it from the affected tier's attestation.

Over-provisioned access is not closed until both the grant has been corrected and the underlying control update (where applicable) has been tracked to completion.

Related Documents

• compliance/three-layer-access-architecture.md — architecture reference
• compliance/lpriv-evidence-mapping.md — least-privilege evidence mapping
• compliance/lpriv-secops-audit.md — SecOps audit findings
• compliance/hipaa-controls.md — HIPAA control crosswalk for identity
• compliance/annual-review-checklist.md — annual control review