Protect Your Cloud by Leveraging AWS' Shared Responsibility Model

Protect Your Cloud by Leveraging AWS' Shared Responsibility Model

By Jose Neto

Let us start by talking about security of the cloud, and security in the cloud. “Security of the cloud” means securing all the cloud infrastructure and services. That is AWS’ responsibility. Elements like data centers and their hardware, edge locations, networking infrastructure, virtualization software, 24×7 monitoring and automation of controls are all up to AWS to secure. 

Securing workloads deployed in AWS are each client’s responsibility, and that is what “security in the cloud” refers to. That normally entails enabling encryption at rest for every service (when appropriate), private network and firewall configuration, operating system patching, management of identities and permissions in your AWS account, runtime and application management, and protecting your customer’s data. 

All this security-related customization is a good thing because it allows for great flexibility in defining a workload’s security level. For stringent applications, tight security measures can be applied. For applications intended to be public, loose security is in order. 

Products to Explore

There are a number of security products that can help in meeting “security in the cloud” goals. Here are a few basic examples worth considering.

Network firewalls

These will help you secure your EC2 machines and subnets. Read this for a brief discussion on firewalls, in-transit encryption and private network security. 

Encryption

At-rest data encryption is available for most AWS services. These services leverage KMS, the AWS module responsible for encryption and key management. Here’s a brief discussion on encryption and key management.

IAM

IAM stands for Identity and Access Management. This is the product that enables authentication and authorization to the various services of an AWS account. IAM defines identities such as users, groups and roles. Each of these identities is then given permissions according to a permissions policy. Users are given permanent credentials. These can be a username and a password for web access or access keys for command-line and SDK access. 

Roles are used for temporary access to AWS services, and therefore are given short-term credentials. Roles are also extensively used for an AWS service to access another AWS service, and come in really handy in this way. By using IAM it’s possible to exert granular control over who gets to access services and what they can do, and thus help maintain security in the cloud. 

Cognito and STS (Secure Token Service)

These are two products that can also assist you with security in the cloud by allowing you to implement an architecture known as identity federation. Identity federation is a system of trust between two parties for the purpose of authenticating users and conveying information needed to authorize their access to resources. It acknowledges and exploits the fact that many users already have digital identities, and allows these external identities to be used to access an AWS account. External identities can be established identities in enterprise systems, Active Directory being one of the most common. Or these identities can be web identities, such as Google's, Facebook’s or Twitter’s. 

In the enterprise case, there’s an additional, key reason to use existing identities: enterprise identities have to be able to access a number of enterprise systems and you want to keep a single identity for both the enterprise systems and the enterprises’ AWS account. In the case of web identities, the other big reason to use identity federation is because it means you don’t have to store identities. Storing customer’s identities means storing them securely and that can be a significant load. After all, for popular apps the number of identities to manage and maintain can be in the range of thousands to millions! 

CloudTrail

Monitoring is one of the tenets of security in the cloud and CloudTrail is a monitoring product. It gives you the ability to monitor and trace events in your AWS account. CloudTrail can be thought of as the ultimate monitoring and auditing tool — it logs every call to an AWS account’s API, be it from the web portal, command-line or SDK (in-app calls). CloudTrail is enabled by default, and its logs are encrypted and kept for 90 days.

Trusted Advisor

Trusted Advisor is a service that acts as a cloud expert. It will review your AWS set up and point out potential security problems. By helping in configuring your system according to best practices, it will help you close security gaps. The Trusted Advisor relies on a vast number of hours of collective AWS experience so it’s definitely worth checking out.

The Well-Architected Tool

The Well-Architected Tool also performs a comprehensive review of an AWS account. The difference being that its focus is on the 5 Pillars of the AWS Well-Architected Framework: 1. Operational excellence; 2. Security; 3. Reliability; 4. Performance Efficiency; 5. Cost Optimization. The Well-architected Tool will also augment your security in the cloud. There may be some overlap between the Trusted Advisor and the The Well-Architected Tool, but again worth checking out. 

AWS Config

This is a nifty and convenient product that is extra useful for regulated environments because it can help you both secure and maintain compliance in the cloud. The AWS Config is a hub, a centralized control panel in which you can inspect, monitor and control the configurations of all products in your AWS account. It provides a synopsis of all resources, configuration rules and compliance status. These rules can be managed by AWS or custom. The great thing about AWS Config is that it allows for automation of compliance — it will compare the current configurations against the rules, and you can opt for automated remediation actions or automated notifications. 

The Takeaway

Securing a cloud workload is a shared responsibility between the client and AWS. These tools allow you to achieve both  “security of the cloud” and “security in the cloud.”  If you missed the last installment in our series on AWS cloud security, read it here.

Reference: 

AWS Whitepaper: Introduction to AWS Security