Cloud Migration Security: The Decisions to Make Before the First Workload Moves
Most cloud weaknesses are decided, or left undecided, during the migration. The landing zone, identity, network, logging, data and backup decisions to make first, the risks specific to the migration itself, and when to assess.
Cloud Security
Most of the cloud weaknesses we find were not created by an attacker or a careless engineer. They were decided, or left undecided, during the migration: an account structure nobody planned, access keys created to get a workload moving, a temporary rule that became permanent, logs nobody switched on. Here are the security decisions to make before the first workload moves, and the risks specific to the migration itself.
In short. Build the landing zone before the workloads: account structure, identity federation, network design, central logging and guardrails. Decide where data and logs may live before choosing regions. Treat the migration period as its own risk, because it doubles your attack surface and creates broad temporary access. And assess the environment after the first wave, while the patterns are still cheap to change, rather than after the last.
What changes when you move
A lift-and-shift migration moves servers. It also moves the assumptions they were built on, and several of those assumptions do not hold in the cloud.
| On-premises assumption | Cloud reality |
|---|---|
| The network boundary keeps outsiders out | The management plane is an API reachable from anywhere with valid credentials. Identity is the boundary. |
| Creating infrastructure takes a ticket and a purchase order | Anyone with the right permissions can create a public database in seconds |
| Logs exist because servers write them | Control-plane and data-access logs must be switched on per service, and sent somewhere safe |
| Backups are separate from production | Snapshots in the same account can be deleted by the same compromised credential |
| The provider handles security | The provider secures the infrastructure; configuration, identity and data remain yours |
Shared responsibility depends on what you choose
AWS's description of the shared responsibility model is a useful anchor: AWS "is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud", while "customer responsibility will be determined by the AWS Cloud services that a customer selects". For virtual machines that means you patch and configure the guest operating system and everything on it. For managed services such as object storage, the provider runs the operating system and platform, and you remain responsible for your data, its encryption options, its classification and who can access it through identity policies. Azure and Google Cloud describe the same split.
The practical consequence for a migration: every workload you move as a virtual machine brings its patching and hardening obligations with it. Moving to managed services where you can removes whole categories of work, but never the configuration, identity and data responsibilities.
Decisions to make before the first workload
1 — Landing zone and account structure
Decide how accounts or subscriptions are organised and governed before anything lands in them. Microsoft's Cloud Adoption Framework describes an Azure landing zone as a platform landing zone, "the centralized foundation that establishes governance, security, and shared resources", plus workload landing zones where teams deploy "within the guardrails of the platform landing zone". AWS achieves the same with a multi-account structure under AWS Organizations. Separate production from non-production, and keep security tooling and logs in accounts workload teams cannot change.
2 — Identity
Federate cloud access with your existing identity provider, require phishing-resistant multi-factor authentication for administrators, avoid long-lived access keys, give people roles rather than standing permissions, and create a small number of break-glass accounts that are monitored and tested. Decide this first: retrofitting identity after hundreds of workloads are running is the hardest change in cloud security.
3 — Network
Plan private connectivity to on-premises, segmentation that reflects trust zones, and a rule that management ports are never open to the internet. Resist recreating a flat on-premises network in the cloud because it is familiar.
4 — Logging
Turn on control-plane audit logs in every account from day one, send them to a central log account with restricted access, and decide retention. In India, CERT-In's directions of April 2022 require logs of all ICT systems to be kept for a rolling 180 days within Indian jurisdiction, which affects where the log archive lives.
5 — Data and keys
Classify the data you are moving, decide who controls encryption keys, and confirm where each class of data and its backups may be stored before choosing regions. If you are regulated, check your regulator's expectations on location and outsourcing first.
6 — Backup and recovery
Keep backups in a separate account with deletion protection, so the credential that can damage production cannot also destroy the backups. Set recovery objectives with the business and test a restore. Our guide to business impact analysis and RTO/RPO covers how.
7 — Infrastructure as code
Build the landing zone and every workload through code from the start, scanned before it is applied. Retrofitting code onto a hand-built environment is slow and rarely complete. See infrastructure as code security.
Risks specific to the migration itself
The months of migration are riskier than the steady state on either side, and they rarely get their own risk assessment.
- Two environments at once. During a parallel run you have the attack surface of both, plus the connection between them. The connection is often more permissive than either side.
- Migration tooling with broad access. Replication agents, migration service accounts and data transfer tools need wide permissions. Give them a defined end date and remove them when the wave completes.
- Staging copies. Data exported to a staging bucket or share "just for the transfer" is a frequent source of exposure. Inventory every staging location and delete it at the end of the wave.
- Temporary rules. Firewall and security group rules opened to get a workload working tend to stay. Tag every temporary rule with an expiry and review them at each wave's close.
- Decommissioning. Old servers left running after cut-over stop being patched and monitored but stay on the network. Decommissioning is a security task, not housekeeping.
A wave-by-wave checklist
| Before the wave | During the wave | After the wave |
|---|---|---|
| Data classified and target region confirmed | Temporary access and rules tagged with an expiry | Temporary access, rules and staging copies removed |
| Workload landing zone created through code | Logging confirmed flowing to the central account | Configuration checked against the CIS benchmark for the provider |
| Identity roles defined for the workload team | Monitoring rules in place for the new workload | Restore tested from the cloud backup |
| Dependencies and data flows mapped | Change log of everything done by hand | Old servers decommissioned and removed from the network |
When to assess
Three points in a migration give the most value from an independent review.
- Before the first wave: an architecture review of the landing zone design, when changing it costs a meeting rather than a re-migration.
- After the first wave: a configuration assessment of the real environment against the CIS benchmark for your provider. The first wave sets the patterns every later wave copies, so mistakes found here are found once.
- After go-live: a cloud penetration test, which looks at the environment the way an attacker would, including the identity paths a configuration benchmark does not test.
If you are moving to more than one provider, each will have its own account model, identity system and logging. Decide early which guardrails must be consistent across all of them and how you will see all of them from one place.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is a landing zone?
The pre-built foundation that workloads are deployed into: account or subscription structure, identity, networking, logging and guardrails. Microsoft describes an Azure landing zone as a platform landing zone that provides governance, security and shared resources, plus workload landing zones where teams deploy within its guardrails.
QIs lift-and-shift less secure than re-architecting?
Not inherently, but it keeps more responsibility with you. A virtual machine still needs patching and hardening, and lift-and-shift tends to carry on-premises assumptions, such as a trusted internal network, into an environment where they do not hold. Moving to managed services where practical removes whole categories of work.
QWho is responsible for security in the cloud?
Both parties. The provider secures the infrastructure the services run on; you are responsible for what you configure on it, which varies with the services you choose. For virtual machines that includes the operating system; for managed services it still includes your data, encryption choices and access policies.
QWhat should be decided first in a cloud migration?
Identity and account structure. Both are very hard to change once workloads are running. Federate with your existing identity provider, avoid long-lived access keys, and separate production, non-production, security tooling and logs into different accounts or subscriptions.
QWhere must logs be kept for Indian organisations?
CERT-In's directions of 28 April 2022 require logs of all ICT systems to be kept securely for a rolling period of 180 days within Indian jurisdiction. Plan the location of your central log archive accordingly, and check whether your sector regulator requires more.
QWhat are the biggest risks during the migration itself?
Running two environments at once, migration tools with broad permissions, staging copies of data left behind, temporary firewall rules that become permanent, and old servers that are no longer patched or monitored but are still on the network.
QAre cloud snapshots a sufficient backup?
Not if they sit in the same account as production, because the credential that can damage production can usually delete them too. Keep backups in a separate account with deletion protection, and test restoring from them.
QWhen should a migrated environment be assessed?
Review the landing zone design before the first wave, assess the real configuration after the first wave against the CIS benchmark for your provider, and run a cloud penetration test after go-live. The first-wave assessment is the most valuable, because every later wave copies its patterns.
QWe are moving to more than one cloud. What changes?
Each provider has its own account model, identity system and logging. Decide early which guardrails must be consistent across all of them, how identity will be federated to each, and how logs from all of them reach one place your SOC can see.
Related reading
For the misconfigurations that most often follow a migration, see common cloud security misconfigurations and the top cloud security risks for CISOs. For a sector example, cloud security for fintechs and NBFCs in India. For building the environment as code from the start, infrastructure as code security.
About Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, assessing AWS, Azure and GCP environments against their CIS benchmarks through read-only access, and testing them the way an attacker would.
What we can do for you:
- Migration security. Cloud migration security from landing zone design review through each wave's close-out, including temporary access, staging copies and decommissioning.
- Architecture across providers. Multi-cloud architecture guidance on consistent guardrails, identity federation and central logging, and a cloud identity review of who can do what.
- Assessment and testing. A cloud security assessment after the first wave and cloud penetration testing after go-live, with every finding reproduced by hand and fixes delivered as code.
Sources
- AWS, Shared Responsibility Model.
- Microsoft, What is an Azure landing zone?, Cloud Adoption Framework.
- CERT-In, Directions under section 70B(6) of the IT Act, 28 April 2022.
Adayptus Consulting
Cloud Security, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, assessing AWS, Azure and GCP environments against their CIS benchmarks and testing them the way an attacker would.
