Securely Migrating to the Cloud

Cloud migration is an ongoing trend. It’s estimated that by 2020, 83% of enterprise workloads will have moved into the cloud. There are numerous benefits for moving to the cloud: scalability of infrastructure, cost reduction, increased automation, and many more.

However, cloud migration can be a challenging process. A key issue is to maintain tight security both during the migration and in the post-migration environment. Ideally, once the migration is complete, the resulting cloud assets will have security that’s not only robust, but also highly automated.

In this article, we’ll discuss some important elements to consider before and during a migration, and several common problems to avoid, with an emphasis on security considerations.

Also, this article will describe strategies for secure cloud migration, regardless of the destination cloud platform. Later articles will discuss the specific tools to use, depending on the platform to which the migration is being done.

Migration: An Overview

Cloud migration involves moving your data and applications from an on-premise environment over to a cloud service provider: one that offers a virtual pool of on-demand compute, storage, and network services at scale. It starts with understanding the benefits of the new system, analyzing the existing system, planning the migration, and finally, migrating.

For an organization with a large number of legacy applications, the decision to migrate can be difficult. Cloud migration can seem very intimidating, with many unknowns. But cloud computing is now a mature industry, and there are many tools available to help with the migration process.

Five Steps to Cloud Migration

When beginning a migration, the most important thing is go slowly. Thorough and careful planning will make implementation straightforward.

Different organizations have taken different approaches for their migrations. Effective strategies tend to follow some variation of the following sequence:

1. Assess Opportunities
2. Determine Scope of Change
3. Map Dependencies and Plan
4. Create Infrastructure
5. Migrate and Validate

Stage 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? Later parts of the process will depend on the answers to these questions.

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. Later, you will also need to know how they interact and how they depend on one another.

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?

At the end of Stage 1, you should have a final list of the assets which will be migrated.

Stage 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.

At the end of Stage 2, each application will have a complete post-migration design.

Stage 3: Map Dependencies and Plan

Very few organizations attempt to move everything to the cloud at once. It is far more prudent to start by migrating only a few applications — perhaps only one — to minimize the impact of the inevitable challenges that will occur. Then, once this process has been completed successfully, larger groups of applications can be migrated more smoothly.

Therefore, 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. For example, at Reblaze we often see situations where customer applications or APIs are plagued by hostile bots that traditional on-premise security solutions cannot detect, whereas Reblaze’s advanced bot mitigation has no problem filtering them out from the traffic stream.

During Stage 3, security considerations should play a large role in your planning. Let’s talk about them now.

Overview: Security in the Cloud

Cloud security is poles apart from traditional security models. Thus, the toolsets and processes used for managing traditional on-premise environments are not wholly applicable to 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.

Also, since the cloud is different than a traditional on-premise environment, new toolsets are required: tools which can ingest the various event points, draw correlations, and raise the necessary threat notifications. Then, automated remediation for the triggered incidents can be performed.

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. (For more on this, see AWS WAF and AWS Shield: Are They Enough to Secure Your Environment?, and Google Cloud Armor: How to convert it into a full web security solution.)

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.

Enable Immediately

It is often said that security monitoring should be enabled after migration, but it should really be the other way around. Security for your infrastructure, applications, and other components should be enabled from day one of the migration process to ensure that there is no slippage before the actual go-live of the production environment. As discussed above, this requires choosing the right tools and services, as well as a security team that is continuously monitoring threats and updating the security alerts and landscape as the migration process continues.

In fact, you should consider enabling it even sooner — during the pre-migration planning. A cloud security platform such as Reblaze can scrub web traffic regardless of the environment (cloud or on-premise) for the protected applications.

Once you have decided to adopt a platform like this, it usually makes sense to start using it as soon as possible, especially for the applications that will not be significantly redesigned during the migration. The security platform can be fine-tuned for these applications now, rather than later. This eliminates the post-migration training period which otherwise would occur, and therefore accelerates the overall timeline. (More on this in the discussion of Stage 5 validation, below.)

Stage 3 completion:

When Stage 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.

Stage 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 Stage 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. Stage 4 is then merely an implementation of that plan.

Stage 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.

An important part of the validation process is verifying that your migrated applications are properly secured. An effective cloud security solution adapts itself to each API and application that it’s protecting; this requires the solution to train itself for each one, which takes some time. (Depending on the traffic volume, Reblaze generally can do this in a few days.)

Also, it’s usually desirable to fine-tune its accuracy, to drive the rate of false positives down to zero. Reblaze has a “report-only” mode for this purpose, which many customers use right after deployment. In this mode, Reblaze does not block any traffic; it merely reports on the incoming requests that it would have blocked in “active” mode. Fine-tuning and validation can then be done quickly and efficiently.

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 partners like Reblaze, who specialize in this.

In this article, we’ve discussed cloud migrations in general terms. When migrating to a specific public cloud platform, it’s also helpful to consider the platform-specific migration tools that each one provides. In later articles, we’ll discuss each platform and the tools that are available.