# Access Control Policy
# Cold Bore Ballistics LLC — Internal Reference
# Classification: Confidential

Subordinate to: `CBB_Information_Security_Policy.md` §8

---

## 1. Purpose and Scope

This policy governs how access to CBB systems, accounts, and data is granted, maintained, and revoked. It applies to all CBB accounts, all individuals accessing CBB systems, and all automated or AI-assisted tooling operating under CBB credentials.

---

## 2. Authentication Requirements

### 2.1 Multi-Factor Authentication

MFA is required for all CBB accounts without exception. This includes:

- M365 user accounts (`@coldboreballisticsllc.com`)
- Azure subscriptions and management planes
- Atlassian (Jira, Confluence)
- Slack workspace
- Twilio and SendGrid consoles
- Any vendor console with access to confidential data

MFA is enforced via Entra ID Security Defaults for all M365-federated services. For services not federated to Entra ID, MFA must be enabled in the service's own settings.

Entra ID Security Defaults block legacy authentication protocols (basic auth, SMTP auth without modern auth). This is intentional and must not be disabled.

### 2.2 Password Requirements

Passwords must:

- Be unique to each service — reuse across CBB services is prohibited
- Be stored in a password manager — plaintext storage is prohibited
- Never be shared via Slack, email, or any unencrypted channel

CBB does not mandate a specific minimum length or complexity beyond what Entra ID enforces by default, with the expectation that a password manager is used for all accounts.

---

## 3. Least Privilege

Every account, app registration, and service credential receives only the permissions required to perform its stated function. Access is never granted speculatively or "just in case."

When assigning roles:

- Prefer built-in roles with the minimum required permissions over custom roles
- Prefer scoped assignments (resource group, resource) over subscription-wide assignments where practical
- Document the justification for any assignment that grants Owner or Global Administrator privileges

App registrations follow `Entra_App_Registration_Policy.md` §4 (Scope Minimization).

---

## 4. Shared and Generic Accounts

Shared credentials are prohibited. Every individual accessing CBB systems must use a uniquely identified account. This applies to:

- Human operators
- Contractors
- AI-assisted tooling (each integration receives its own app registration or service credential)

Shared mailboxes in M365 are permitted for functional purposes (e.g., `support@coldboreballisticsllc.com`) but must not be used for interactive login. Access to shared mailboxes is delegated to named individual accounts.

---

## 5. Privileged Accounts

### 5.1 Global Administrator

The Global Administrator account (`jschwefel@coldboreballisticsllc.com`) is the primary administrative identity. It must:

- Have MFA enforced at all times
- Not be used as a day-to-day work account for non-administrative tasks where a lower-privilege account suffices

### 5.2 Break-Glass Account

The break-glass Global Administrator account (`admin@coldboreballistics.onmicrosoft.com`) is for emergency use only — specifically, situations where the primary Global Administrator account is inaccessible.

- It must never be used for routine administration
- Its credentials must be stored in Azure Key Vault and in a separate offline location
- Any use of the break-glass account must be logged and reviewed

### 5.3 Azure Owner Role

The Azure Owner role at subscription scope must be limited to accounts in `sg-azure-admin`. Assignment of Owner at subscription scope requires explicit approval from the Global Administrator and must be documented.

---

## 6. Onboarding

Before any new employee or contractor is granted access to CBB systems:

1. The Global Administrator must approve the access scope in writing.
2. The individual must acknowledge the `CBB_Information_Security_Policy.md` and all subordinate policies.
3. Accounts must be provisioned using `cbb-utils/M365/provision_user.ps1` for M365 accounts, which enforces group membership and shared mailbox access grants per the defined roles.
4. Access is provisioned to the minimum required for the individual's stated role. Additional access requires a separate approval.

---

## 7. Offboarding

Upon termination of any employment or contractor engagement, the following must be completed **within 24 hours**:

1. Disable the M365 account (do not delete — retain for audit purposes per the Purview retention policy).
2. Revoke all active sessions: **Entra admin center → Users → [user] → Revoke sessions**.
3. Remove the individual from all security groups and M365 Groups.
4. Rotate any credentials the individual had access to that are not covered by individual account isolation (e.g., any shared secrets that cannot be proven were not accessible).
5. Transfer ownership of any resources owned by the departing individual to the Global Administrator.
6. Document the offboarding date and actions taken.

For contractor offboardings involving app registrations or service accounts, follow the retirement procedure in `Entra_App_Registration_Policy.md` §10.

---

## 8. Access Reviews

All active access grants must be reviewed:

- Every 12 months
- Immediately following any security incident involving unauthorized access
- Immediately following any offboarding

The review must confirm that every active account and access grant reflects a current, active need. Access that cannot be justified must be revoked.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (03_-_Confidential/) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Security/Access_Control_Policy.md` |
| **Cross-references** | `CBB_Information_Security_Policy.md`; `Entra_App_Registration_Policy.md`; `M365_Architecture_Reference.md` |
| **Created** | 2026-06-07 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-07 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| 0.9 | 2026-06-07 | jschwefel | — | — | Initial release |
| DRAFT | 2026-06-09 | Claude Code | — | — | Removed non-standard `# Last Updated` header line (per TECHNICAL_DOCUMENTATION_GUIDE §7). No content changes. |
