A Comprehensive Guide to Cloud Security (Part 2): IAM and VPC

In the first part of our Cloud Security Guide, we focused on explaining in detail the concept of shared responsibility in public cloud environments. We also discussed the main differences between cloud and on-premise environments (data centers mainly) from the point of infrastructure and security.

Today, we’ll continue to look at the fundamental AWS services you have to use if you want to create a secure public environment on Amazon public cloud.

Identity and Access Management: Your First Stop on the AWS Journey

During the initial setup of your AWS account, you will need to provide personal or company details, as well as credit card info. The credit card info is mandatory, although Amazon offers a Free Tier to get you started without any costs. You will also be asked for the root account password.

A root account is your first account on AWS, with which you will perform the initial login. Of course, by the analogy with Linux systems, the root account has all the rights and can do “everything” in your environment. Hence, the best practice for the UNIX world applies to AWS as well-the usage of the root account is highly discouraged.

AWS recommends the root account be only used for the initial login and while setting up other users with access. Securing the root account will be your first measure in protecting your AWS account, and the entire process is managed by Identity and Access Management (IAM) service.

On the IAM’s home page, AWS placed an IAM Security Status section, which in a nutshell presents the initial IAM guidelines and a checklist for securing the environment. The use of 2-factor authentication (MFA) is encouraged not just on the root account, but on all accounts (regardless of the level of privileges). In addition, each of your employees should have a unique, dedicated account, as credentials sharing is not advised.

Also, if you have more than one user in need of certain level access (like the ability to read data from S3 buckets), you should organize users in groups and force specific IAM password policies for those users (similar to Microsoft Active Directory password policies, which are enabled by default). Also, for the programmatic/API access, you should regularly rotate access keys awarded to users.

This may sound too daunting, especially when all this information is presented in a single place. However, implementing these IAM rules is quite simple in practice.

You need to secure your root account, create as many users as required, add them to groups, rotate their passwords and keys, and assign least privileges to any entity needed (user or AWS service).

IAM Roles and Responsibilities

You may run into situations where a user or AWS entity such as EC2 or ECS/EKS services need several policies attached, but even in those cases, don’t be reluctant and assign more privileges just to be sure that the access is given straight away.

Instead, spend some time reading about IAM roles and policies and how they work, before giving any write permission to AWS entities.

This may be tiring at the beginning, but as your environment grows bigger, you’ll be amazed by the number of issues that can arise simply due to misconfigured IAM rights. For instance, the recent Capital One breach happened just because of the misconfigured IAM rights.

Besides creating and managing users, groups, policies and roles, IAM allows you to connect your identity provider to AWS, and use the existing user base you have in your on-premises environment, such as Microsoft Active Directory or linux LDAP domains.

This can be particularly useful in hybrid cloud scenarios, where companies already have an established and secure way to manage users and their privileges in existing environments, and they simply want to replicate those configurations to the cloud.

Another useful IAM feature that customers usually forget is Credentials Report, which provides you with a summary of details for all of your users and their IAM settings and credentials. Be sure to make the audit control of this report a part of your security checklist, and carry it out every couple of months.

Virtual Private Cloud = Your Network on AWS

Once you have defined a hierarchy for your IAM users and groups, and assigned adequate rights to them through IAM roles and policies, it’s time to start designing network blueprints. You should do this before actually deploying your workloads into AWS compute, storage or database services.

Importance of a Custom Virtual Private Cloud

Many AWS services don’t require a Virtual Private Cloud (VPC) configured (eg S3 or DynamoDB NoSQL database). Plus, AWS itself provides you with a default VPC as part of your account to help speed up the creation of your environment. However, it’s still highly recommended to define a custom VPC in the region where you will use AWS services.

The reason it’s important to create your own VPC is that if you decide to use the default one, it will automatically place all of your services in public subnets with Internet access, which is definitely not a good practice. So, the question is how to design your VPC and what to have in mind?

Designing Your Own VPC: Tips and Tricks

1. Choose an appropriate subnet mask and addressing scheme-VPCs can have a subnet mask from /16 to /28, and be sure not to overlap the address with your current on-premises network, because you might need to connect them in the future with site-to-site VPN connection or DirectConnect.
2. Always deploy public and private subnets in pairs. This means that for every private subnet where you will deploy your workloads (eg EC2 instances or ECS/EKS clusters) you will need an appropriate public subnet to accompany it, since in public subnet you will deploy Elastic Load Balancers (ELB) to route traffic to your instances or clusters. The difference between public and private subnets is that public ones have Internet Gateway (IGW) attached to them and can route Internet traffic to and from the subnet, while private can only route local VPC traffic.
3. Besides pairing public and private subnets, be sure to deploy same subnets in at least two availability zones, for high availability. This means that if you have 10.0.0.0/16 as your VPC, and 10.0.1.0/24 and 10.0.2.0/24 as public and private subnet in AZ1 of your region, you should create two more subnets in AZ2, as well as one public and one private, for example 10.0.3.0/24 and 10.0.4.0/24. With this setup, ELB can route traffic to two public subnets, 10.0.1.0/24 and 10.0.3.0/24, which will then pass traffic to their private counterparts.
4. By default, there are no firewall restrictions for local traffic between subnets inside a VPC, and not all subnets have restrictions on outbound traffic, and also to the Internet, so if this is against your internal policies, you can use Network ACLs (NACL) to further lock down routing in your VPC.
5. Enable VPC flow logs!

The design of VPC is not as easy and straightforward process as structuring IAM users, groups and roles, and Amazon has a reference page for most common VPC scenarios, so we highly recommend you check it out before implementing tips and tricks we advised in this section.

Summary

In the second part of our series on cloud security, we’ve tried to explain the two AWS services that companies need the most, IAM and VPC.

IAM is used to allow secure and granular access to their AWS to employees, while VPC is the main service when it comes to managing your private networking on Amazon’s public cloud.

All of this means that there should be no compromise or negligence when it comes to using these two services, and that’s why your first concern when migrating to the cloud is the proper configuration of IAM and VPC.

Once you’ve overcome all the caveats of IAM and VPC, you can continue to the next pillar of cloud security, compliance and auditing, which we’ll cover in detail in the next articles.

Originally published at https://jatheon.com on September 30, 2019.