10.2 Cloud Migration Security Architecture Lab

Migration Scenario: Fast Cloud Adoption Under Regulatory Pressure

A financial services firm wants to move a customer analytics platform from an aging data center to a public cloud provider. The business wants elastic capacity before the holiday season. Legal notes that the platform processes customer identifiers and transaction history. Engineering proposes a fast lift-and-shift using virtual machines, flat network connectivity, and existing administrator accounts. The board asks whether the cloud provider is now responsible for security.

The CISSP response begins with shared responsibility. The provider secures many facilities, hardware, and managed service layers, but the customer remains accountable for its data, identities, configurations, access decisions, logging choices, and governance. The exact split depends on service model. Infrastructure services leave more operating system and network configuration duties with the customer. Managed platform and software services shift some technical work to the provider but do not remove accountability for data protection and access governance.

The first architecture decision is classification and scope. The platform stores sensitive customer data, so the migration must identify data owners, regulatory obligations, retention rules, encryption requirements, cross-border restrictions, backup requirements, and logging needs. If data is not classified before migration, teams may copy it into unsuitable storage, analytics, or test environments. Cloud speed can magnify poor data governance.

The second decision is identity. Cloud consoles, pipelines, workloads, service accounts, administrators, and support roles need least privilege. Existing data center administrator groups should not be copied blindly into broad cloud roles. The organization should use federation, MFA for privileged access, conditional access, just-in-time elevation, separate administrative accounts, and review of cloud IAM policies. Non-human identities need ownership, rotation, and monitoring.

The third decision is network architecture. A flat virtual network that mirrors the old data center may expose management ports, databases, and internal services to unnecessary paths. Better design uses segmentation, private subnets, controlled ingress and egress, security groups, network access control lists where appropriate, private endpoints, routing review, and monitored connectivity to the remaining data center. Micro-segmentation can limit lateral movement, but it must be operationally manageable.

The fourth decision is encryption and key management. Encrypting data at rest is often easy to enable, but the management question is who controls the keys, where keys are stored, how rotation occurs, who can use keys, and how key access is logged. Customer-managed keys may improve control for sensitive workloads, but they add operational responsibility. If keys are lost or access is misconfigured, availability and confidentiality can both suffer.

Logging and monitoring should be designed before production use. Cloud control plane logs, identity logs, storage access logs, network flow logs, application logs, and key usage logs should flow to a monitored environment with retention aligned to investigation and compliance needs. Logs should be protected from alteration by the same administrators being monitored. Alerts should map to runbooks so the security operations team can respond.

Resilience must also be deliberate. Cloud does not automatically make an application highly available. The team must choose regions, availability zones, backup design, recovery point objectives, recovery time objectives, dependency mapping, and failover testing. A single-region deployment may still be appropriate for cost or compliance reasons, but the decision should be explicit. Critical services should have tested recovery procedures, not assumptions based on provider marketing.

Change control changes in cloud because infrastructure can be created through templates, pipelines, and APIs. That is an opportunity. Security guardrails can be embedded in policy-as-code, baseline templates, image standards, configuration scanning, and automated approval gates. It is also a risk because a single pipeline permission can change many resources quickly. Deployment roles should be separated from approval roles, and emergency changes should be logged and reviewed.

Vendor and contract governance remain important. The firm should review provider certifications, data processing terms, support access, breach notification terms, audit rights, subcontractors, data location, service level commitments, and exit assistance. Certifications do not prove the customer's configuration is secure. They are input evidence for third-party risk management and compliance mapping.

Cloud Migration Readiness Checklist

• Define the service model and shared responsibility matrix for each major component.
• Classify data, approve regions, and document regulatory and retention requirements.
• Replace broad administrator inheritance with least privilege cloud roles and MFA.
• Design segmentation, private access paths, controlled egress, and monitored management access.
• Implement encryption, key ownership, key access logging, and backup protection.
• Route cloud logs to security monitoring before production cutover.
• Test recovery, incident response, access revocation, and rollback procedures.
• Require architecture approval before handling production data.

A CISSP-level cloud decision is not anti-cloud or pro-cloud. It asks whether the new architecture meets business objectives with controls that are understood, owned, tested, and monitored. Migration speed is valuable, but speed without guardrails creates invisible risk. The security leader should help the business move quickly through reusable patterns, not uncontrolled exceptions.