Chapter 2 — Infrastructure Overview

2.1 DigitalOcean Account Structure

The Platform operates under a single dedicated DigitalOcean account owned by SBS (the "SBS Account"). A dedicated account — rather than a shared or Ledger Hub-owned account — keeps billing, resource ownership, and access control unambiguously with SBS and satisfies the tenant-separation intent of the IAM control family at the infrastructure root.

Account-level configuration:configuration (target):

• Account ownership — SBS-controlled email alias (not an individual mailbox), so ownership survives personnel changes. Execution owner: Nelson Santos (IT Director).
• Account MFA — phishing-resistant MFA enforced on the account root and on every team member, consistent with IAM-03. No shared credentials.
• Team access — DigitalOcean Teams with role-scoped membership. Ledger Hub Networks platform engineering joins as team members with the minimum role required for build activities; access is reviewed under IAM-06 and revocable by SBS without Ledger Hub involvement.
• API tokens — issued per-purpose (IaC pipeline, monitoring integrations), scoped read or write as required, stored exclusively in Vault (Chapter 8), rotated per the secrets lifecycle. No tokens in repositories, plaintext CI variables, or local files — per INF-02 and INF-03.
• Billing alerts — configured at account level so anomalous resource creation (a common compromise indicator) is surfaced to the account owner immediately.

Nonconformance — credential handling (CRITICAL). As of 2026-07-17 the operational changelog carried plaintext credentials: a shared root password stated to cover all project droplets, the GitHub account, the wiki admin account, and the Grafana admin account. All four credential sets are treated as compromised. Remediation (Build Register item 15): rotate all four immediately; migrate to Vault upon its deployment (Chapter 8) with interim storage in an approved password manager; strip the credentials section from the changelog and purge it from any version-control history; enforce distinct per-service credentials. No shared passwords are permitted for any host or service.

2.2 Project Topology

Resources are organized into two DigitalOcean Projects, providing hard organizational separation between environments:Projects:

2.2.1 Droplet Inventory (As Provisioned)Built, 2026-07-18)

⚠ RegionTwo nonconformanceinventory nonconformances: (a) sbs-wiki region (§2.3); (b) Dev-Gitlab-server exists outside the two-project inventory yet holds production DNS — see §2.3.2.2.

2.2.2 asNonconformance — Production DNS Target (CRITICAL)

The apex record sbsdash.com → 138.197.222.154 currently resolves to Dev-Gitlab-server, not to sbsdash-server-prod (107.170.72.145). The primary tenant domain therefore points at an uninventoried development host. Required action (Build Register remediationitem item.16), one of:

Until resolved, Dev-Gitlab-server is inside the security boundary of the engagement and subject to all INF-family controls.

2.2.3 Project Topology Rules governing the two-project topology:

• Promotion path — configurations are built and verified in Dev, then promoted to Prod exclusively through the infrastructure-as-code workflow (Chapter 10). No manual, console-driven resource creation in Prod; console access to Prod is break-glass only and logged.
• No shared resources (target) — no droplet, database, volume, or network resource is a member of both projects.environments, and Dev and Prod reside on separate VPC networks (Chapter 3) with no peering;peering. aAs Devbuilt, compromisethis cannotrule traverseis tonot Prod.met: Dev, Prod, and monitor droplets all share default-nyc2 (10.100.0.0/20). See §3.1 for the remediation decision.
• No production data in Dev — Dev operates on synthetic or sanitized data only. Tenant data, Compartment data, and audit-log content never leave the Prod boundary.
• Naming convention — new resources carry environment-prefixed names (dev- / prod-). The existingExisting droplet names (Dev-SBS-server, sbsdash-server-prod, monitor-servers, sbs-wiki) predate this convention and are grandfathered in the Build Register; renaming may occur at a maintenance window (DigitalOcean droplet renames are cosmetic and zero-downtime).

2.3 Region Selection

Primary region: NYC2 (New York). All compute resources deploy in NYC2, with one tracked exception.

Rationale:

• Latency to operating footprint — SBS headquarters is in Miami with operations concentrated on the U.S. East Coast and Puerto Rico. DigitalOcean operates no Florida datacenter;Rico; the New York regions are the lowest-latency full-service option for the Miami–New York–San Juan corridor.
• Data residency — all tenant data, Compartment data, and audit-log content remain within the continental United States.
• Single-region baseline — both Dev and Prodenvironments deploy in NYC2. Backup archives replicate to SFO3 for geographic redundancy under the disaster-recovery design (Chapter 14); no live workload runs outside NYC2.

Nonconformance — sbs-wiki (NYC1). The sbs-wiki droplet is provisioned in NYC1. DigitalOcean VPC networks are region-scoped: athe NYC1 wiki droplet cannot join theany NYC2 ProdVPC. VPC,As whichbuilt, wouldthe leavemonitor itsscrapes trafficthe wiki's node_exporter over the public internet, unencrypted, admitted by a ufw rule scoped to otherthe Prod services onmonitor's public networking,IP. contraryMetric tocontent INF-01is low-sensitivity (networkCPU/RAM/disk), isolation).so Remediation:this rebuildis an accepted interim state — but it is eliminated, not mitigated, by the wiki dropletrebuild ininto NYC2 via(Build snapshotRegister restoreitem, carried from prior revision). Sequencing: rebuild before VPC enrollment and firewall configurationstandardization (Chapter 3). Sequencing matters —; rebuilding after DNS, TLS, and DNS/TLS/proxy configurationwork would force rework of all three.

Managed-service availability. NYC2 predates some ofnewer DigitalOcean's newerDigitalOcean managed-service capacity. Availability of Managed Databases (PostgreSQL, MongoDB, Redis) in NYC2 is to be confirmed before Chapter 7 is finalized; the fallback design is self-hosted data services under Docker Compose on dedicated droplets within the Prod VPC.

Region choice is confirmed at Build Register sign-off; any change after full provisioning requires a Change Order given migration cost.

2.4 Environment Topology

The two environments are structurally identical and differ only in scale and data:

Toolchain versions are pinned identically across both environments (supply-chain controls, Chapter 11) so that Dev verification is meaningful for Prod promotion — version drift between environments is treated as a build defect. The current OS mix (24.04 vs 26.04) is a tracked instance of exactly this class of drift.

2.5 Server Users and Host Access

Host-levelTarget access(INF-04): follows INF-04:

As built (2026-07-17/18) — nonconformant:

Remediation (Build Register item 17): create per-person named users with individually generated keys; disable root SSH; replace blanket NOPASSWD with scoped sudo (or passworded sudo); retire or restrict sbsRoot to break-glass with vaulted credentials; capture the authorized-user list in IaC. Until complete, individual attribution of host actions is impossible, which also degrades MON-01 (unified audit trail).