# Azure Security Review
# Classification: Confidential
# Date: 2026-06-09
# Reviewer: Claude Code (drafted); pending Founder approval
# Status: Draft

---

## 1. Vendor / Device Overview

| Field | Value |
|---|---|
| **Name** | Microsoft Azure (Microsoft Corporation) |
| **Website** | azure.microsoft.com · trust: servicetrust.microsoft.com |
| **Service / purpose** | Cloud platform hosting all CBB production infrastructure (IaC via Terraform — `cbb-infra`) |
| **CBB use case** | Hosts: VNet, IPsec gateway VM, Container Apps (DocuSeal), ACR, PostgreSQL Flexible Server, blob storage, Static Web Apps (4 sites), Key Vaults, Azure DNS (4 zones), Logic App. Subscription `735b4bb4-b179-4ed7-af87-2270bbbde658` ("Cold Bore Ballistics LLC"). |
| **Data tier(s) accessed** | Tier 2–3 — infrastructure secrets (Key Vault), DocuSeal database (signed-doc metadata), `.dope` blob uploads. **Tier-4 SPEC is in M365, not Azure.** |
| **Access type** | Entra ID identity; Terraform via OIDC service principal; az CLI; managed identities |
| **Proposed onboarding date** | Already in production — retrospective review |

---

## 2. Data Exposure Assessment

### 2.1 What CBB data will this vendor / device access?

As host/custodian, Azure holds:

- **Key Vault secrets** — `kv-cbb-shared-prod` (IPsec PSK, VM/DB passwords, SSH key, DocuSeal secrets, shared service creds) and `kv-scope-dope-prod` (ScopeDOPE app secrets)
- **PostgreSQL** — DocuSeal database (signed-document metadata; the signed PDFs themselves go to blob then OneDrive)
- **Blob storage** — `.dope` file uploads (ScopeDOPE), DocuSeal signed-PDF staging
- **Terraform state** — `stcbbtfstate` (infrastructure topology, may reference resource IDs)
- Static site content (public marketing sites — Tier 1)

### 2.2 Where will CBB data be stored by this vendor?

In the Azure subscription, primarily `northcentralus` (SWAs in `eastus2` — SWA not available in NC). Encrypted at rest and in transit. Key Vault uses platform-managed keys; network-restricted access (AzureServices bypass + operator IP + Container App outbound IP).

### 2.3 Is any Highly Confidential data (Tier 4) involved?

- [ ] Yes
- [x] **No** — the SPEC and trade-secret material live in M365 (Tier 4), not Azure. Azure holds infrastructure secrets (Tier 3) and operational data, but not the engine/DOPE-Blend methodology or SPEC text.

> **Note:** Key Vault secrets are Tier-3 sensitive. The IPsec PSK, DB passwords, and service credentials are the crown-jewels in Azure; their compromise enables lateral movement, so Key Vault network restriction + RBAC is the load-bearing control.

---

## 3. Vendor Security Posture (Software vendors only)

### 3.1 Compliance and certifications

| Standard | Certified? | Notes |
|---|---|---|
| SOC 2 Type II | Yes | Azure SOC 1/2/3 via Service Trust Portal |
| ISO 27001 | Yes | ISO/IEC 27001 (+ 27017, 27018, 27701, many more) |
| GDPR compliant | Yes | Microsoft DPA; EU Data Boundary options |
| CCPA / FedRAMP | Yes | FedRAMP High; CCPA via Microsoft DPA |

> Reviewer can download current Azure SOC 2 / ISO certificates from servicetrust.microsoft.com at approval.

### 3.2 Data processing agreement

- [x] Microsoft Products and Services DPA applies
- [ ] Not available

### 3.3 Breach history

No Azure-platform breach attributable to CBB's use known at drafting. (Microsoft identity incidents 2023–2024 reinforce the MFA/Conditional-Access hardening case — tracked under the M365 review.) Reviewer to re-assess at approval.

### 3.4 Security documentation

- [x] Service Trust Portal (servicetrust.microsoft.com)
- [x] SOC 2 / ISO / FedRAMP reports available
- [x] MSRC disclosure program; Microsoft Defender for Cloud available

### 3.5 Authentication and access control

- [x] MFA via Entra ID (Security Defaults — see M365 review)
- [x] Terraform authenticates via **OIDC service principal (no stored client secret)** — only the app ID is needed
- [x] Managed identities for service-to-service (DocuSeal → Key Vault, Logic App → Graph)
- [x] RBAC scoping (Contributor on `rg-cbb-prod`, `rg-cbb-tfstate`)

---

## 4. Hardware Security Assessment

**N/A** — cloud platform.

---

## 5. Integration Security

### 5.1 Credential management

- [x] All application/service secrets in Key Vault (`kv-cbb-shared-prod`, `kv-scope-dope-prod`) — never in code/config; Terraform reads them as data sources.
- [x] Terraform OIDC SP has no client secret (CLAUDE.md / cbb-infra bootstrap model).
- [x] Managed identities preferred over stored credentials where possible.
- [x] Key Vault network access restricted (AzureServices bypass + operator IP + Container App static outbound IP).
- [ ] **Open items (from cbb-infra notes):** GH OIDC SP not yet recreated; `github-token` placeholder in Terraform — confirm/close before relying on GHA apply.

### 5.2 Network exposure

- **Inbound:** IPsec gateway VM public IP `52.159.73.194` (site-to-site to UniFi `184.58.131.229`); PostgreSQL firewall allowlists Container App outbound IPs only; SWAs are public by design (marketing sites); `files.coldboreballisticsllc.com` is LAN-only (172.31.1.200).
- VNet-injected Container App environment; private DNS zone for PostgreSQL.
- Each public ingress point should be confirmed minimal and documented (it is, in the Architecture Reference).

### 5.3 Offboarding plan

Azure = the infrastructure estate; offboarding = subscription/resource transfer in an acquisition. Service boundary supports a clean ScopeDOPE carve-out: transfer `scopedope.tfstate` + resources tagged `project = scope-dope`; `shared` + `cbb` stay with CBB. Rotate all Key Vault secrets on any ownership change.

---

## 6. Risk Summary

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Key Vault secret compromise → lateral movement | L | H | Network-restricted KV; RBAC; managed identities; OIDC (no stored SP secret); rotation on ownership change |
| Public ingress (VM, SWAs, PostgreSQL fw) exploited | L | M | Minimal allowlists; IPsec PSK in KV; SWAs serve static content only; PG firewall to CA outbound IPs only |
| Open GH OIDC SP / `github-token` placeholder | M | M | Recreate GH OIDC SP and close the token placeholder before depending on GHA apply |
| Untagged/ungoverned resources outside policy scope | M | L | Tag policy scoped to `rg-cbb-prod`; **extend governance to `rg-cbb-tfstate` (see tfstate tagging change in this engagement)** |
| Platform-level incident | L | M | First-party SOC2/ISO/FedRAMP; Defender for Cloud available |

**Overall risk rating:** **Low–Medium** — strong IaC + secret-management posture; residual items are the open OIDC/token placeholder and governance-scope edges.

**Recommendation:** **Approve with conditions** — pending Founder sign-off.

**Conditions:**
1. Recreate the GH OIDC service principal and close the `github-token` placeholder before relying on GHA apply.
2. Extend tag governance to `rg-cbb-tfstate` (tracked as the tfstate-tagging change in this engagement).
3. Confirm each public ingress point (VM, PG firewall, SWAs) is minimal and documented in the Architecture Reference.
4. Confirm Key Vault secret-rotation procedure is documented (runbook) and tested.
5. Add Azure to the "CBB Risk Register" SharePoint List.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (`03_-_Confidential/`) |
| **Location** | `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/Azure/Azure_Security_Review.md` |
| **Cross-references** | `Azure_Architecture_Reference.md`; `Azure_Acquisition_Brief.md`; `Azure_Key_Vault_Architecture_Reference.md`; `M365_Security_Review.md`; "CBB Risk Register" SharePoint List |
| **Created** | 2026-06-09 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-09 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| DRAFT | 2026-06-09 | Claude Code | — | — | Initial draft. Posture verified via Microsoft Service Trust Portal (SOC 2, ISO 27001 family, FedRAMP, GDPR DPA). Documents OIDC-no-secret model, managed identities, KV network restriction; flags open GH OIDC SP / github-token placeholder and tfstate governance-scope gap. Recommends Approve with conditions. Version number to be assigned by Founder. |
