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:

• 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.

2.2 Project Topology

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

2.2.1 Droplet Inventory (As Provisioned)

⚠ Region nonconformance — see §2.3. Tracked as Build Register remediation item.

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 — no droplet, database, volume, or network resource is a member of both projects. Dev and Prod reside on separate VPC networks (Chapter 3) with no peering; a Dev compromise cannot traverse to Prod.
• 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 existing 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; 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 Prod 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: a NYC1 droplet cannot join the NYC2 Prod VPC, which would leave its traffic to other Prod services on public networking, contrary to INF-01 (network isolation). Remediation: rebuild the wiki droplet in NYC2 via snapshot restore before VPC enrollment and firewall configuration (Chapter 3). Sequencing matters — rebuilding after DNS, TLS, and proxy configuration would force rework of all three.

Managed-service availability. NYC2 predates some of DigitalOcean's newer 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.

2.5 Server Users and Host Access

Host-level access follows INF-04:

• Named user accounts per individual; no shared accounts, no direct root login. SSH key authentication only — password authentication disabled at the SSH daemon.
• Privilege elevation via sudo, logged. Server user creation is a tracked Build Register item; the authoritative user list is maintained in the IaC repository so that host access is reviewable and reproducible (Chapter 10).
• Administrative access paths and their IdP enforcement are specified in Chapter 9.