SC.L2-3.13.5Public-access System Separation [CUI Data]
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
[a]
publicly accessible system components are identified; and[b]
subnetworks for publicly accessible system components are physically or logically separated from internal networks.
Public web and file-drop portal in a separate cloud account with no route home
Implementation
AO coverage. Addresses both Public-access System Separation objectives: identifying publicly accessible components and separating their subnetworks from internal networks.
Publicly accessible components identified [a]. The marketing CMS and its database, the careers portal, the customer file-drop portal and its object storage bucket, the outbound mail relay for marketing, and the guest wireless network. Each is listed in the asset inventory with a “public” data-flow classification, and anything newly exposed to the internet must be added before the DNS record is published.
Logical separation [b]. Public workloads run in their own cloud account with its own identity boundary, not in a subnet of the enclave environment. There is no VPC peering, no transit gateway attachment, and no VPN route between that account and the enclave; the route tables are the evidence. Inbound traffic terminates on a reverse proxy in a DMZ subnet; only the proxy can reach the application subnet, and the application subnet has no path to any internal address space.
File-drop data flow. Customers upload to the portal's storage bucket. A one-way pull job initiated from inside the enclave retrieves files, scans them, and writes them to the labeled store. The portal cannot initiate a connection inward, and no enclave credential is stored in the public account.
Guest wireless. The guest SSID is a distinct VLAN with an internet-only route, client isolation on, and no DNS resolution for internal zones. Corporate laptops stay on the enterprise SSID; a CUI device on guest Wi-Fi cannot reach enclave apps because it still has to satisfy device compliance through the IdP.
Maintenance. Quarterly route table and peering review for accidental attachments, plus an external scan of the public account's address ranges to confirm only the intended ports answer. New public services require a data-flow diagram in the change ticket.
Accepted gap. The marketing CMS shares an administrative SSO group with corporate identity for convenience. Compensating controls: those admins use phishing-resistant MFA, the CMS holds no CUI, and DLP blocks upload of labeled content to the CMS.
What the evidence looks like
- Asset inventory entries flagged as publicly accessible
- Route tables / peering configuration showing no path between the public account and the enclave
- Reverse proxy and DMZ subnet configuration
- Guest VLAN configuration with internet-only routing and client isolation
- Quarterly external scan output and peering review notes
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.