Securely Migrating to the Cloud

[vc_row][vc_column][vc_column_text]By 2020, 83% of enterprise workloads will have moved into the cloud. Cloud migration can be a challenging process. A key issue is security both during the migration and in the post-migration environment.

5 Steps to Cloud Migration

Effective migration strategies tend to follow some variation of the following sequence:

Assess Opportunities
Determine Scope of Change
Map Dependencies and Plan
Create Infrastructure
Migrate and Validate

Step 1: Assess Opportunities

The migration begins with documenting the business case for the migration. Why is your organization doing this migration? What specific benefits do you expect to achieve?

Next, assemble (or create) comprehensive architecture documents for the existing environment. You need a complete list of all the assets (applications and data) that currently exist.

For each application, decide if it will be migrated. Consider the scope and constraints of the migration: if this application moves to the cloud, what data stores will need to go with it? What other resources will it require? How much technical debt does it contain? Will the migration provide an opportunity to reduce or eliminate this debt?

Step 2: Determine Scope of Change

In Stage 2, you will iterate through the list of applications from Stage 1, and assess the desired post-migration design of each.

For each application, you should decide upon the appropriate scope of change for this application — the amount of architectural refactoring or redesign that occurs during the migration. There are four possible choices:

Rehost: Move an application to the cloud with no architectural changes. This is the fastest and simplest approach.
Replatform: Move an application with only a few changes for optimal cloud usage. For example, to eliminate the management of database instances, the application might use a cloud relational database service. Instead of needing a DNS server, it might use a cloud DNS service. And so on.
Repurchase: Replace a purchased/licensed application with one that is designed for the cloud.
Redesign: Modify an application to use service-oriented architectures. This is obviously the slowest, most invasive, and most expensive strategy, but it can produce many long-term benefits.

Step 3: Map Dependencies and Plan

In this phase, the primary goals are:

To map out and understand the dependencies among the applications that will migrate, so that…
The stages of the migration can be planned, including the order in which assets will be migrated, how progress will be tracked and managed, and how security will be maintained during and after the migration.

Migration order is not driven solely by technical dependencies. Other factors include business considerations and operational issues. For example, a particular application might be responsible for a large portion of current revenue. Often, it makes sense to migrate other applications first, so that unforeseen problems can be solved with applications that are not mission-critical.

On the other hand, there might be reasons to migrate a particular application sooner. Perhaps it is experiencing a problem that has been intractable on-premise, but will be possible to solve once the application is in-cloud. From now on, security considerations should play a large role in your planning.

Overview: Security in the Cloud

On-premise security is usually treated as a product, rather than as a process; the security team puts up a guardrail around the entire infrastructure, to protect the workloads (and the infrastructure itself) from various threats. There are a number of weaknesses here: the products do not scale, they lack features, and they do not adapt well to constantly evolving threat environments.

On the other hand, cloud security is more focused on a service-oriented architecture that includes security in all stages — from design to development to the operations process. It allows companies to leverage a SaaS approach, where the burden of scrubbing the malicious traffic can be moved to a cloud security provider.

Security Best Practices for Cloud Migration

Whether or not your organization has adopted DevSecOps, you should certainly embrace one of its core concepts and “bake security in” to your cloud migration and infrastructure. Your migration plan should have security controls built into it in order to avoid any unforeseen risks or unwelcome events. Here are some security best practices to put into place.

Plan the Governance

The migration plan should include the governance plan for the cloud environment and the entire migration process. It is essential to lay out an entire data migration plan that includes the starting point, passage points, and endpoint for the data. For each point, the migration team should have clear access controls, ensuring necessary team members have visibility.

Before the migration begins, appropriate guardrails should be created (and of course, subsequently maintained and monitored) around the new cloud resources and the assets they will soon contain. During the migration, only the necessary people should have access to the cloud environment. After the migration, the list of necessary people should be reevaluated, and permissions should be updated. Often, some or even all of the migration team will no longer need the same permissions as before, and thus they should not retain them.

Identify and Eliminate Control Gaps

When it comes to security, the mid-migration period is sometimes overlooked. Consider the passage points through which the data will travel: will the data stores be fully protected the entire time, to the most stringent standards to which your organization is liable? Most organizations today are subject to one or more sets of data privacy laws, along with some compliance standards, and possibly additional industry-specific regulations as well. During the migration, will the data be continuously protected in accordance with the applicable standards?

Select Tools and Services According to Post-Migration Needs

Some cloud platforms provide security tools and services for their customers. These can be useful in some ways, but they are limited in scope. On their own, they do not provide adequate security.

It might seem convenient to rely on these built-in tools “just for the migration,” with the intent of adopting a more comprehensive toolset later. However, this approach is flawed. First, it leaves significant gaps in your security posture during the migration.

Second, those gaps sometimes last for much longer than intended. Like all other complicated endeavors, cloud migrations often include unexpected problems and delays. And even when a migration is completed, there will always be other issues to work on — issues that seem more urgent than spending time and resources on changing a security posture which has not (yet) resulted in any problems.

It’s far better to assess your post-migration security needs now, during the planning process, so that you can adopt the necessary tools and services during the migration. This ensures robust security during and after the migration, and ultimately, is more cost-effective.

When Step 3 is complete, you should have a schedule which includes:

Every application and data store that will be migrated
The order in which each will be migrated
A timeline for each one
A list of required cloud resources, including security tools and services
And a schedule for resource deployment.

Step 4: Create Infrastructure

Before anything can migrate, it needs to have a place to which it will go. Cloud services and necessary resources (e.g., storage) must be deployed, secured, and verified before anything can be moved to the cloud.

If Step 3 was done correctly, then you already have a complete map of what infrastructure needs to be created, and the order in which to create everything.

Step 5: Migrate & Validate

This stage is where the actual migration occurs. Again, this is primarily an implementation of the plan created in Stage 3.

In a typical migration, you will probably go through this phase several times. It’s common to migrate one application (or one group of applications) at a time. Each should be migrated, validated, and operational before proceeding to the next.

The validation process will usually vary across applications. Those which are merely being rehosted require less validation and testing than those which were significantly redesigned or refactored for the cloud.

Conclusion

The cloud migration journey can be rewarding if the whole process — from planning to execution — is planned thoroughly, with adequate guardrails put around the plan to avoid any slippage from the desired state. Organizations should ensure that the plan is validated by cloud migration experts, or should leverage help from Advanced partners like Renova Cloud who specialize in this.

Source: Reblaze[/vc_column_text][/vc_column][/vc_row]