Lesson A12.4
Cloud networking is not secure merely because a resource sits inside a private address range. Strong architecture explains which sources can reach which destinations, why the path exists, where trust changes, which identity is involved, and what evidence proves the intended exposure.
This lesson uses fictional diagrams, synthetic flow records, and safe network evidence only. It does not involve scanning, probing, enumerating, or testing any real cloud network.
Lesson Progress
High School Advanced • A12: Cloud Security Architecture • Lesson 4 of 10
Readiness Check
0/4 ready
Professional Hook
Imagine a fictional database is reachable only through private cloud networking. That is useful, but it does not answer who can connect, which workload identity is authorized, whether development can reach production, or whether a partner service can traverse the same path.
Network architecture should reduce unnecessary reachability while identity architecture decides which people and workloads are actually allowed to use the path.
Private reachability is a boundary control — not a replacement for identity.
Learning Objectives
Explain cloud network boundaries as trust and exposure decisions rather than simply lists of subnets, addresses, or firewall rules.
Distinguish public ingress, private service-to-service communication, administrative access, partner connectivity, and outbound egress by purpose, trust, and evidence.
Evaluate fictional network paths using source, destination, business purpose, identity context, allowed direction, exposure, monitoring, ownership, and change triggers.
Identify architecture risks such as unnecessary public exposure, broad internal trust, unrestricted egress, unclear administrative paths, stale partner connectivity, and undocumented cross-environment flows.
Build a Cloud Trust Boundary Map that becomes the fourth artifact in the A12 Cloud Security Architecture Assessment.
Trust Boundaries
Traffic crosses from the public internet into an approved public application entry point.
Architecture questions
Which service must be public? What business purpose requires exposure? Which component terminates public access? What protects downstream private services?
Evidence
Architecture diagram, approved exposure record, application entry-point configuration, monitoring coverage, owner, and change history.
A workload communicates with a database, storage service, or other protected data service.
Architecture questions
Which workload identity is allowed? Which data service is reachable? Is the path private? Is access narrower than general network reachability?
Evidence
Workload identity record, service connection architecture, resource authorization, private connectivity design, and logs.
One application or managed service calls another service inside the cloud architecture.
Architecture questions
Is the call required? Which service identity makes it? What action is allowed? Does the target need to accept traffic from an entire network or only a named service?
Evidence
Service dependency map, identity binding, connection policy, application logs, and ownership.
Privileged operators access configuration, management, support, or recovery functions.
Architecture questions
Where can administrative access originate? Is it separated from normal user traffic? Is privileged identity required? Is access monitored and time-bounded where appropriate?
Evidence
Privileged IAM record, approved management path, JIT record, audit logs, and access review.
An external organization, SaaS provider, vendor, or partner exchanges approved traffic or data with the cloud environment.
Architecture questions
What business purpose justifies the connection? Which direction is required? Which data fields or service endpoints are involved? Who owns the relationship and its termination?
Evidence
Integration architecture, sponsor, vendor record, connection scope, data-flow documentation, logs, and review date.
Development, test, staging, and production environments are separated so lower-trust environments do not casually reach production resources.
Architecture questions
Which flows cross environments? Why are they needed? Are production identities, data, and administrative paths isolated from lower environments?
Evidence
Environment architecture, identity matrix, data handling rules, approved exceptions, and change records.
A workload or user-controlled process sends traffic from the cloud environment to an external destination.
Architecture questions
Which workloads need outbound communication? To what service categories or named destinations? Is the purpose documented? What telemetry exists?
Evidence
Dependency inventory, egress policy, integration record, DNS or connection telemetry, and owner.
Traffic Classes
Source
General internet users or approved public clients.
Destination
Public application entry point only.
Trust model
Untrusted external source until the application authenticates and authorizes the user.
Design intent
Keep downstream application, storage, and database services private unless a business requirement says otherwise.
Source
Application components acting for authenticated users.
Destination
Approved internal services and data stores.
Trust model
Identity and authorization still matter even after traffic enters the cloud environment.
Design intent
Use workload identity and service-level authorization rather than relying on network location alone.
Source
Approved administrators using privileged identities.
Destination
Management interfaces or configuration services.
Trust model
High-impact path requiring stronger identity, approval, monitoring, and review.
Design intent
Separate management paths from public user traffic and ordinary workforce access.
Source
Approved vendor, SaaS, or partner system.
Destination
Specific integration endpoint or service.
Trust model
External but business-approved; still bounded by scope, identity, data minimization, and lifecycle.
Design intent
Do not treat partner traffic as equivalent to internal trusted traffic.
Source
Application or workload.
Destination
Approved external dependency such as notification, payment, or scheduling service.
Trust model
The workload initiates the connection, but external dependency risk and data-sharing scope still matter.
Design intent
Document business purpose, destination class, data exchanged, owner, and monitoring.
Source
Protected workload, backup service, or recovery operator.
Destination
Backup or recovery service.
Trust model
Sensitive because backup and restore paths often carry production-classified data.
Design intent
Keep access narrow, monitored, and tied to recovery ownership.
Segmentation
Purpose
Only the approved public entry point is internet-facing; application and data services remain private.
Security value
Reduces unnecessary exposure and makes the public trust boundary visible.
Caution
A private network tier is not automatically trusted; identity and service authorization still matter.
Purpose
Services are grouped or isolated by business function, sensitivity, or workload purpose.
Security value
Limits broad lateral reach and makes service dependencies easier to review.
Caution
Too many undocumented exceptions can defeat the design.
Purpose
Development, test, staging, and production have separate identity, data, and network expectations.
Security value
Reduces accidental cross-environment access and protects production trust boundaries.
Caution
Shared services and emergency exceptions need explicit review.
Purpose
Privileged configuration and administrative access follow a different path from user-facing traffic.
Security value
Makes high-impact access easier to authenticate, monitor, and review.
Caution
A separate path is useful only if privileged identities and approvals are also well-governed.
Purpose
External partner connectivity terminates at a specific integration service rather than gaining broad access to the internal environment.
Security value
Keeps external trust narrow and easier to remove when the relationship ends.
Caution
Integration scope, data minimization, and ownership still require evidence.
Purpose
Workloads have only the external connectivity needed for documented dependencies.
Security value
Makes external communication more explainable and reduces unnecessary destinations.
Caution
Restrictions should match real application dependencies and include a safe change process.
Architecture Principles
Internet exposure should follow explicit business purpose rather than convenience.
Review: Can every public endpoint explain why public access is necessary?
Being inside a private network should not automatically grant application or data access.
Review: Do services authenticate and authorize workloads even on private paths?
Boundaries between internet, partner, management, workload, data, and environment contexts should be explicit.
Review: Can the architecture show where trust assumptions change?
Inbound and outbound communication create different risks and ownership questions.
Review: Is the required direction documented for each flow?
A connection should exist because a business or technical dependency requires it.
Review: Can the owner explain why source A must communicate with destination B?
Segmentation is useful when it limits unnecessary communication between trust zones or services.
Review: Does the boundary actually reduce reach, privilege, or exposure?
Privileged management access should be separated, strongly authenticated, monitored, and reviewable.
Review: Can administrative access be distinguished from normal application traffic?
Old diagrams and stale connection inventories should not be treated as proof of current exposure.
Review: Are network records refreshed when services, identities, partners, or environments change?
Vocabulary
A point where the architecture changes its assumptions about identity, exposure, privilege, data sensitivity, ownership, or control.
Traffic entering a service, environment, or protected boundary.
Traffic leaving a service, environment, or protected boundary toward another destination.
Dividing systems or services into bounded communication zones so unnecessary reachability is reduced.
A service entry point intentionally reachable from the public internet.
A service path intended to be reachable only through approved private or internal connectivity.
Interfaces and services used to configure, administer, monitor, or control cloud resources.
The application or service path that carries normal workload or business data.
Communication between workloads or services inside a cloud or data-center environment.
Communication entering or leaving an environment, often between internal services and external users or systems.
A rule or design statement describing which sources may communicate with which destinations and under what conditions.
The documented reason traffic should travel between specific sources, destinations, or trust zones.
Fictional Network Flow Register
Source
Public Internet Users
Destination
Student Portal Public Entry
Purpose
Reach the public student-support application
Identity
Unauthenticated until application sign-in
Exposure
Public entry only
Data
Application requests
Owner
Application Platform Team
Monitoring
Entry-point request and application security logs
Architecture concern
Public exposure is required, but downstream services remain private.
Source
Student Portal Workload
Destination
Student Support Database
Purpose
Read and write approved application records
Identity
PortalDatabaseClient workload identity
Exposure
Private
Data
Restricted application records
Owner
Application + Data Platform
Monitoring
Database connection and audit telemetry
Architecture concern
Database should not accept general workforce or public network access.
Source
Student Portal Workload
Destination
Generated Report Storage
Purpose
Create approved reports
Identity
PortalReporting workload identity
Exposure
Private
Data
Sensitive generated reports
Owner
Reporting Team
Monitoring
Storage read/write telemetry
Architecture concern
Report storage has no public-read requirement.
Source
Privileged Platform Operators
Destination
Cloud Management Plane
Purpose
Perform approved platform administration
Identity
PlatformAdmin-JIT
Exposure
Restricted management path
Data
Configuration and administrative metadata
Owner
Platform Engineering
Monitoring
Privileged activation + administrative audit
Architecture concern
One emergency session is missing a linked post-use review.
Source
Notification Worker
Destination
External Notification Provider
Purpose
Send approved application notifications
Identity
Notification workload identity + provider integration
Exposure
External dependency
Data
Minimized notification fields
Owner
Notification Team
Monitoring
Application integration telemetry
Architecture concern
No other workload should inherit the same outbound dependency by default.
Source
Scheduling SaaS
Destination
Scheduling Integration Service
Purpose
Exchange approved appointment status
Identity
External integration identity
Exposure
Specific integration endpoint
Data
Minimized appointment fields
Owner
Integration Owner
Monitoring
Integration request and error telemetry
Architecture concern
Partner access review is due soon and must not expand into general application reachability.
Source
Development Environment
Destination
Production Reporting Storage
Purpose
Historical troubleshooting convenience
Identity
Legacy developer service identity
Exposure
Private but cross-environment
Data
Potentially sensitive report metadata
Owner
Unknown
Monitoring
Limited
Architecture concern
Current business need, owner, identity scope, and environment exception are not established.
Source
Backup Service
Destination
Recovery Repository
Purpose
Protect critical production data
Identity
Backup workload identity
Exposure
Private recovery path
Data
Restricted backup data
Owner
Recovery Owner
Monitoring
Backup and restore activity
Architecture concern
Restore operators should remain separate from ordinary application users.
Fake Dashboard
Fictional exposure and trust-boundary metrics
Documented network flows
8
Public, private, administrative, partner, outbound, recovery, and cross-environment paths
Public entry points
1
Only the approved student portal entry point is intended for public access
Private service flows
4
Database, report storage, recovery, and internal application paths
Blocked boundary gaps
1
Legacy development-to-production reporting path has no current owner
Fake SOC Alert
Source: Fictional Cloud Network Architecture Review • Time: 10:43
Boundary Evidence
| Claim | Evidence | Status |
|---|---|---|
| Only the approved application entry point is publicly exposed. | Current architecture diagram, exposure register, and application entry-point review align. | Confirmed |
| The production database accepts only the portal workload path. | Workload identity mapping, private service connection record, and database audit evidence align. | Confirmed |
| All cross-environment traffic is approved and owned. | NET-07 shows a legacy development-to-production flow with no current owner or exception record. | Blocked |
| Privileged management access has complete review evidence. | JIT activation exists, but one emergency session lacks linked post-use review. | Conditional |
| Outbound application dependencies are documented. | Notification and scheduling dependencies are documented; one analytics export dependency is under review. | Conditional |
| Partner traffic terminates at a narrow integration service. | Integration architecture and current request logs support the narrow endpoint design. | Confirmed |
Fake Log Panel
[08:12] NET-01 internet->portal-entry exposure=PUBLIC_REQUIRED status=CONFIRMED [08:39] NET-02 portal-workload->student-db path=PRIVATE identity=PortalDatabaseClient [09:01] NET-03 portal-workload->report-storage path=PRIVATE public_access=NO [09:27] NET-04 admin->management-plane JIT=YES post_review=PARTIAL status=CONDITIONAL [09:55] NET-05 notification-worker->provider egress=APPROVED purpose=NOTIFICATION [10:18] NET-06 scheduling-saas->integration-service partner_scope=NARROW review=8d [10:43] NET-07 dev->prod-reporting owner=UNKNOWN exception=NONE status=BLOCKED [11:02] NET-08 backup-service->recovery-repo path=PRIVATE status=CONFIRMED
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Network Anti-Patterns
Why it fails: Services grant broad access simply because traffic originates from an internal network.
Better approach: Use workload identity and service authorization even on private paths.
Why it fails: Downstream application and data services become directly exposed when only the front-door service requires public access.
Better approach: Keep public exposure at the approved entry point and preserve private downstream boundaries.
Why it fails: Workloads can communicate with destinations unrelated to documented business dependencies.
Better approach: Document required external dependencies and bound egress to meaningful service needs.
Why it fails: External vendors or SaaS systems receive broad internal trust because the business relationship is approved.
Better approach: Keep partner access narrow, identity-aware, monitored, and tied to a specific integration purpose.
Why it fails: Lower-environment identities and tools gain paths into production data or services.
Better approach: Preserve environment separation and require explicit, reviewed exceptions.
Why it fails: High-impact configuration paths are hard to distinguish, monitor, and review.
Better approach: Use separate privileged identity and management access patterns.
Why it fails: The picture shows arrows but nobody owns the dependencies or knows when they should be removed.
Better approach: Attach owner, purpose, evidence, review date, and change triggers to meaningful flows.
Why it fails: Services and integrations change while the architecture picture remains unchanged.
Better approach: Refresh the network map after meaningful deployment, identity, partner, or environment changes.
Ingress and Egress
Which service accepts the connection?
Is public exposure actually required?
Which identity or authentication step follows?
Which downstream services stay private?
What telemetry records the boundary crossing?
Which workload initiates the connection?
What business dependency requires it?
Which data leaves the environment?
Who owns the dependency?
How will the path be reviewed when the dependency changes?
Management Plane
Management actions can change identity, data access, network state, monitoring, deployments, and recovery configuration. That makes the management path materially different from ordinary application traffic.
Use named privileged identities with stronger authentication and narrow administrative roles.
Use time-bounded or just-in-time privilege where appropriate rather than broad standing authority.
Keep management access separate from public user entry points and ordinary application traffic.
Record privileged activation, configuration changes, approvals, and post-use review where required.
Production administration should not casually inherit lower-environment identities or access paths.
Every privileged path should have an accountable platform or service owner.
Scenario Decision Lab
A development environment still has a legacy path toward production reporting storage from an old troubleshooting workflow. No current owner or exception exists.
Scenario Decision Lab
A scheduling SaaS needs to exchange a minimized appointment-status dataset with one Northbridge integration service. The vendor does not need broad internal access.
Safe Fictional Lab
Use fictional services, users, workloads, partners, environments, and evidence only. Do not test or inspect any real cloud network.
Create at least twelve fictional network flows.
Include public ingress, private service-to-service traffic, administrative access, partner connectivity, outbound egress, recovery traffic, and an environment boundary.
Assign each flow a stable ID.
Record source and destination.
State business or technical purpose.
Identify direction.
Record human or workload identity context.
Classify public, private, partner, management, recovery, or cross-environment exposure.
Record the data or service category carried by the flow.
Assign an accountable owner.
Record monitoring or evidence coverage.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Retired.
Identify at least two unnecessary or overly broad paths.
Identify at least one outbound dependency.
Identify at least one administrative path.
Identify at least one partner boundary.
Define remediation or retirement decisions.
Add change triggers for new services, partners, public endpoints, identities, data flows, dependencies, or environment changes.
Lab boundary
This is a fictional architecture-mapping exercise. Do not scan, probe, enumerate, connect to, or alter any real cloud network, endpoint, address range, service, or account.
Analyze the Evidence
Advanced Challenge
A fictional organization currently allows its public application, internal services, administrative tools, development environment, analytics, and partner integration to communicate through one broad internal network with few documented boundaries.
Redesign the architecture conceptually. Do not write implementation commands or real network rules. Your goal is to make trust and ownership understandable.
Public application edge
Private application services
Protected data services
Management plane
Development and test environment
Production environment
Partner integration boundary
Outbound dependency boundary
Backup and recovery path
Workload identity requirements
Monitoring coverage
Owner for each zone
Exception process
Change triggers
A strong redesign explains why communication exists and how identity, data, management, partner, and environment boundaries reinforce one another.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the fourth artifact for your A12 Cloud Security Architecture Assessment: a fictional Cloud Trust Boundary Map with at least twelve communication flows. Include flow ID, source, destination, purpose, direction, identity context, exposure type, data or service category, accountable owner, monitoring evidence, status, risk concern, next action, and change trigger.
Confidence / Readiness Reflection
A12.5 moves into Cloud Logging and Monitoring Design. Before continuing, make sure you can explain which trust-boundary events should become visible evidence.
I can identify public, private, administrative, partner, outbound, and environment boundaries.
I can explain why private network location does not replace workload identity.
I can evaluate a network flow using purpose, direction, identity, exposure, owner, and evidence.
I can identify why unrestricted egress and cross-environment access create architecture risk.
I can connect network boundaries to storage, IAM, monitoring, and governance decisions.
Portfolio Build Guide
A reviewer should immediately understand which service initiates a flow and which service receives it.
Clearly distinguish internet, partner, management, workload, data, recovery, and environment boundaries.
Link each important service path to the human or workload identity responsible for the action.
Indicate whether a path carries public, internal, sensitive, restricted, administrative, or recovery data.
Every important path should have an accountable application, platform, data, integration, or recovery owner.
Connect network claims to current architecture records, identity mappings, logs, and reviews.
Cross-environment and legacy paths should never disappear inside a generic private-network label.
Make the map reusable in A12.5 monitoring, A12.7 resilience, A12.8 misconfiguration prevention, and A12.9 governance.
Key Takeaways
Lesson Safety Boundary
Do not scan, probe, enumerate, connect to, test, or modify real cloud networks, endpoints, address ranges, accounts, routes, security policies, private services, or production systems. All network records and evidence in this lesson are fictional and defensive.
Lesson Complete
You now have a cloud network architecture model for trust boundaries, public and private exposure, service communication, management access, partner connectivity, egress, environment separation, monitoring, ownership, and evidence. Next, A12.5 focuses on Cloud Logging and Monitoring Design.