Part one of this series gave an overview of security in the public cloud and an introduction to AWS services. In part two, we focused on network and storage, and the main security concerns and strategies to consider.

Now in part three, the last of the series, we will give an introduction to the topic of Identity and Access Management in the public cloud, using the AWS IAM service as an example. Also, we will explore some of the AWS services that are available to you out of the box which can be used to enhance your security practices.

Identity and Access Management

The AWS IAM service should be at the center of your cloud security strategy. It effectively describes Who can do What and Where. Aside from human users, IAM also enables you to define what a resource (e.g., machine) is allowed to do.

Users, Groups, & Roles

There are three entities in IAM meant to simplify management: Users, Groups, and Roles. While AWS IAM Users are typically humans, they can also be any entity that needs to interact with AWS APIs from a non-AWS environment. As mentioned above, IAM Users are a recommended alternative to account root credentials. AWS IAM Groups are logical collections of IAM Users. And AWS IAM Roles are entities that can be assumed by one or many AWS resources (e.g., an EC2 instance).

IAM Policies

IAM Users, Groups, and Roles can have one or more AWS IAM Policies associated with them to describe What they can do (and Where). There are three types of IAM Policies: Inline, Customer-Managed, and AWS-Managed (see Fig. 1).

• Inline policies are applied to a single entity (User, Group, or Role) and can’t be shared or reused.
• Customer-Managed policies can be attached/detached from multiple Users, Groups, or Roles, providing a high level of reusability without much extra complexity.
• AWS-Managed policies are readily available to be used in IAM and are fully managed and provided by AWS. The downside with these last is that they can’t be customized or edited, so, while useful, they make it hard to follow the principle of least privilege.

Fig.1 AWS IAM Entities and Types of Policies

In addition, there is the possibility to enable Multi-Factor Authentication and Account Password Policy for IAM Users to enhance security. Enterprises also traditionally integrate the IAM service with the existing company authentication method (e.g., Microsoft Active Directory). In this way, existing users can assume AWS IAM roles or leverage the AWS Security Token Service (STS) to request temporary and limited-privilege IAM credentials.

S3 Bucket Policies

While not technically part of the AWS IAM service, it is important to mention AWS S3 Bucket Policies. These are very similar to IAM policies, but they are exclusively applied to an S3 Bucket and therefore part of the AWS S3 service.

S3 Bucket Policies enable customers to control the level of access to the objects inside a specific S3 bucket (see Fig. 2), allowing the contents to be either public or private. When set to private, the customer will need to indicate what resources (e.g., EC2 instance) require privileges to the S3 bucket.

Fig.2 AWS S3 Buckets and Policies

Leverage Existing AWS Services for Enhanced Security Practices

When you go beyond the typical Infrastructure services (compute, storage, network), you will uncover a whole new world of possibilities. There are several AWS managed services that you can–and should–leverage to enhance your security practices without added operational burden.

One of three important steps when creating an AWS account (mentioned in part one of this series) was enabling the CloudTrail service. This gives you a log/audit trail of all API actions in your AWS account. To automatically analyze these logs, you can then use AWS GuardDuty, which provides intelligent threat detection and monitoring, plus several other AWS data sources such as VPC Flow Logs and DNS logs.

Another good service is AWS Config, which allows you to continuously monitor, audit, and evaluate the configurations of your AWS resources. It’s also a great option to assess the status of an account (since you can enable it at any point in time) and determine your overall compliance against your guidelines.

If you are running an Internet-facing web service in AWS, then a must-have is AWS Web Application Firewall (WAF). AWS WAF provides a protection layer against web attacks that goes beyond a typical firewall (Network ACLs and Security Groups). You can also implement AWS Shield to protect against DDoS attacks, with the option of two different flavors: Standard and Advanced. The Shield Standard comes at no extra cost beyond what you are paying for WAF (Web Application Firewall). The Shield Advanced has an additional cost but provides expanded protection of other AWS Services and comes with Premium Support from the AWS DDoS Response Team.

Note however that these services cannot, by themselves, provide full web security. Here’s more information on using AWS WAF and AWS Shield as part of a robust security posture.

Conclusion

As you might have noticed, Cloud Security is a vast topic with multiple ramifications. In this series of articles, we focused on AWS to give an overview of the public cloud along with the security aspects to be considered regardless of the cloud adoption maturity in your organization.

In part one, we covered some fundamentals of the public cloud, the responsibility for shift and split, and different strategies for account management. In part two, we then moved on to the critical elements of network and storage that must be considered to implement a solid security strategy. We have now ended with two vital topics in public cloud security: Identity and Access Management and managed AWS services that you can leverage to help your security practices.

As you go forward on your cloud journey, AWS services will definitely play a crucial role in your security capabilities. But it is important to remember foundational elements such as network (isolation and connectivity), storage (especially S3 Bucket Policies), and Identity Access Management, as these form the core part of your cloud security strategy.

This guest article is by Bruno Amaro Almeida.