Cloudbound? How to Secure Your Migration to AWS

I’ve always enjoyed hearing grand stories of moving workloads to the cloud. This allows sharing resources you no longer have to manage and you gain access to all the processing power needed to finish jobs in an efficient manner. The best part is that you pay only for what you use. This explains Amazon Web Services (AWS) Elastic Compute Cloud (EC2) success.  In simple terms, move workloads to the cloud and you’ll be happy!

Work Load + Cloud = Happy

This is awesome — yet, there is one question I often have. How will you secure this? Verizon’s 2016 Data Breach Investigations Report states 63% of data breaches involve compromised passwords.

Amazon knows this and has done a fine job of building a secure environment, but how will your users access it?

This pressing security question becomes many:

  • How do you manage access to your cloud IaaS?
  • Do you need to set up a new identity store for this cloud environment?
  • Do you need new skill-sets to support this?
  • With my data in the cloud, how can I reduce security risk?

As analysis paralysis sets in, you are no longer talking about running new workloads in the cloud.

You need security. Amazon recommends setting up AWS Identity and Access Management (IAM).

But there is a major downside to this approach: AWS requires setting up a new identity infrastructure. This is a duplicate of your current environment, adding time, cost, complexity and frustration.

Is there a better way?

There is a better way to simplify identity security and it is easier than you think.

AWS allows you to specify the identity store of your choosing. For the vast majority of organizations, Microsoft Active Directory is already implemented on-premises.

You likely can, or with relative ease, create admin and user roles for access control. Use of an existing Directory is low cost and does not introduce a new learning curve to overcome.

To put in place, all you have to do is create a VPC (virtual private cloud) within AWS to run a new Active Directory domain. Establish a one-way trust to your current on-premises active directory. This is secure and utilizes active directory to support your new AWS environment.

There is one final hurdle to overcome: Amazon’s EC2 is generally a Linux based environment. I’m recommending a Microsoft identity store  this sounds like mixing oil with water.

The final step is to install a third party agent that sits on the pluggable authentication module (PAM).

Centrify makes an agent that allows the Linux systems to authenticate against Active Directory.

This grants role based access and enforcement of least privilege for privileged accounts. Add session auditing when admins run elevated privileges. Provide multi-factor authentication, workflow for new user access and single sign-on to resources.

The primary security concern with a new AWS EC2 deployment is resolved. You are ready to put your workloads where you want them, when you want it, for as long as you want.

The best part, your move to the cloud is transparent and will look the same to your user population.

Learn more about how Centrify provides SSO and automated account provisioning to Amazon Web Service (AWS) here.