AWS shared security responsibility model

AWS and cloud in general have evolved considerably from the time when security in cloud was seen as an impediment to moving your data, applications, and workload to cloud to today when security in cloud is one of the major reasons organizations are moving from data centers to cloud. More and more executives, decision makers, and key stakeholders are vouching that security in cloud is further ahead, and more reliable and economical than security in on-premise data centers. These executives and decision makers are from multiple geographies, and various industries with stringent security requirements and regulatory compliance such as Department of Defense, Banking, Health Care, Payment Card Industry, and so on, and belong to all levels such as CIO, CTO, CEO, CISO, System Administrators, Project Managers, Developers, Security Analysts, and so on.

As a result, cloud adoption rate has been rapidly increasing for the past few years across the globe and across industries. This trend is led by large enterprises where security plays a pivotal role in deciding if an enterprise should move to the cloud or not. AWS provides fully integrated and unified security solutions for its cloud services that enables its customers to migrate their workloads to cloud. Let us look at some predictions for the exponential growth of Cloud Computing by industry leaders:

• Gartner says that by 2020, a corporate no-cloud policy will be as rare as the no-internet policy today.
• Global Cloud Index (GCI) forecasts that cloud will account for 92% of the data center by 2020, meaning 92% of all data and computing resources will be using cloud by 2020.
• International Data Corporation (IDC) says that today's cloud first strategy is already moving the towards cloud.

AWS is architected to be one of the most flexible and secure cloud environments. It removes most of the security burdens that are traditionally associated with IT infrastructure. AWS ensures complete customer privacy and segregation of customer resources and has scores of built-in security features. Moreover, every customer benefits from the security processes, global infrastructure and network architecture put in place by AWS to comply with stringent security and compliance requirements by thousands of customers across the globe from scores of industries.

As more and more organizations move towards cloud, security in cloud has been more of a paradigm shift for many. Even though for the most part, security that is provided in cloud has most of the same functionalities as security in traditional IT, such as protecting information from theft, data leakage, and deletion.

However, security in the cloud is in fact slightly different to security in an on-premises data center. When you move servers, data and workload to AWS cloud, responsibilities are shared between you and AWS for securing your data and workload. AWS is responsible for securing the underlying infrastructure that supports the cloud through its global network of regions, availability zones, edge locations, end points, and so on, and customers are responsible for anything they put on the cloud such as their data, their application, or anything that they connect to the cloud such as the servers in their data centers. They are also responsible for providing access to their virtual network and resources in cloud, this model is known as AWS shared security responsibility model.

The following figure depicts this model:

Figure 1 - AWS shared security responsibility model

In order to master AWS Security, it is imperative for us to identify and understand AWS' share of security responsibilities as well as our share of security responsibilities before we start implementing them. AWS offers a host of different services that can be distributed in three broad categories: infrastructure, container, and abstracted services. Each of these categories has its own security ownership model based on how end users interact with it and how the functionality is accessed:

• Infrastructure Services: This category includes compute services such as Amazon Elastic Cloud Compute (EC2) and associated services, such as Amazon Elastic Block Store (EBS), Elastic Load Balancing, and Amazon Virtual Private Cloud (VPC). These services let you design and build your own secure and private network on cloud with infrastructure similar to your on-premises solutions. This network in AWS cloud is also compatible and can be integrated with your on-premises network. You control the operating system, configure the firewall rules and operate any identity management system that provides access to the user layer of the virtualization stack.

• Container Services: There are certain AWS services that run on separate Amazon EC2 or other infrastructure instances but at times you don’t manage the operating system or the platform layer. AWS offers these services in a managed services model for these application containers. You are responsible for configuring firewall rules, allowing access to your users and systems for these services using AWS Identity and Access Management (IAM) among other things. These services include AWS Elastic Beanstalk, Amazon Elastic Map Reduce (EMR) and Amazon Relational Database Services (RDS).

• Abstracted Services: These are AWS services that abstract the platform or management layer. These are messaging, email, NoSQL database, and storage services on which you can build and operate cloud applications. These services are accessed through endpoints by using AWS APIs. AWS manages the underlying service components or the operating system on which they reside. You share the underlying infrastructure that AWS provides for these abstracted services. These services provide a multi-tenant platform which isolates your data from other users. These services are integrated with AWS IAM for secure access and usage. These services include Simple Queue Service, Amazon DynamoDB, SNS, Amazon Simple Storage Service (S3), and so on.

Let us look at these 3 categories in detail along with their shared security responsibility models:

Shared responsibility model for infrastructure services

AWS global infrastructure powers AWS infrastructure services such as Amazon EC2, Amazon VPC and Amazon Elastic Block Storage (EBS). These are regional services; that is, they operate within the region where they have been launched. They have different durability and availability objectives. However, it is possible to build systems exceeding availability objectives of individual services from AWS. AWS provides multiple options to use various resilient components in multiple availability zones inside a region to design highly available systems.

The following figure shows this model:

Figure 2 - Shared responsibility model for infrastructure services

Building on the AWS secure global infrastructure, similar to your on-premises data centers, you will install, configure, and manage your operating systems and platforms in the AWS cloud. Once you have your platform, you will use it to install your applications and then you will store your data on that platform. You will configure the security of your data such as encryption in transit and at rest. You are responsible for managing how your applications and end users consume this data. If your business requires more layers of protection due to compliance or other regulatory requirements, you can always add it on top of those provided by AWS global infrastructure security layers.

These layers of protection might include securing data at rest by using encryption, or securing data in transit or by introducing additional layer of opacity between AWS services and your platform. This layer could includes secure time stamping, temporary security credentials, data encryption, software and passing digital signature in your API requests and so on.

AWS provides tools and technologies that can be used to protect your data at rest and in transit. We'll take a detailed look at these technologies in Chapter 4, Data Security in AWS.

When you launch a new Amazon Elastic Cloud Compute (EC2) instance from a standard Amazon Machine Image (AMI), you can access it using the secure remote system access protocols, such as Secure Shell (SSH) for a Linux instance or Windows Remote Desktop Protocol (RDP) for a Windows instance. To configure your EC2 instance as per your requirements and to access it, you are required to authenticate at the operating-system level. Once you have authenticated at the operating system level, you'll have secure remote access to the Amazon EC2 instance. You can then set up multiple methods to authenticate operating systems such as Microsoft Active Directory, X.509 certificate authentication, or local operating system accounts.

AWS provides Amazon EC2 key pairs that consist of two different keys, a public key and a private key. These RSA key pairs are the industry standard and used for authentication to access your EC2 instance. When you launch a new EC2 instance, you get an option to either create a new key pair or use an existing key pair. There is a third option available as well to proceed without a key pair, but that is not recommended for securing access to your EC2 instance. The following figure 3 shows the EC2 key pairs option while launching an EC2 instance. You can create as many as 5000 key pairs for your EC2 instances in your AWS account. EC2 key pairs are used only for accessing your EC2 instances and cannot be used to login to AWS Management Console or to use other AWS services. Moreover, users can use different key pairs to access different EC2 instances:

Figure 3 - AWS key pairs

You can either have AWS generate the EC2 key pairs for you, or you can generate your own Amazon EC2 key pairs using industry standard tools like OpenSSL. When you choose the first option, AWS provides you with both the public and private key of the RSA key pair when you launch the instance. You need to securely store the private key; if it is lost you can't restore it from AWS, and you will then have to generate a new key pair.

When you launch a new Linux EC2 instance using a standard AWS AMI, the public key of the Amazon EC2 key pair that is stored within AWS is appended to the initial operating system user’s ~/.ssh/authorized_keys file. You can use an SSH client to connect to this EC2 Linux instance by configuring the SSH client to use the EC2's username such as ec2-user and by using the private key for authorizing a user.

When you launch a new Windows EC2 instance using the ec2config service from a standard AWS AMI, the ec2config service sets a new random administrator password for this Windows instance and encrypts it using the corresponding Amazon EC2 key pair’s public key. You will use the private key to decrypt the default administrator's password. This password will be used for user authentication on the Windows instance.

Although AWS provides plenty of flexible and practical tools for managing Amazon EC2 keys and authentication for accessing EC2 instances, if you require higher security due to your business requirements or regulatory compliance, you can always implement other authentication mechanisms such as Lightweight Directory Access Protocol (LDAP) and disable the Amazon EC2 key pair authentication.

Shared responsibility model for container services

The AWS shared responsibility model is applicable to container services as well, such as Amazon EMR and Amazon RDS. For these services, AWS manages the operating system, underlying infrastructure, application platform, and foundation services. For example, Amazon RDS for Microsoft SQL server is a managed database service where AWS manages all the layers of the container including the Microsoft SQL server database platform. Even though AWS platform provides data backup and recovery tools for services such as Amazon RDS, it is your responsibility to plan, configure and use tools to prepare for your high availability (HA), fault tolerance (FT), business continuity and disaster recovery (BCDR) strategy.

You are responsible for securing your data, for providing access to your data and for configuring firewall rules to access these container services. Examples of firewall rules include RDS security groups for Amazon RDS and EC2 security groups for Amazon EMR.

The following figure shows this model for container services:

Figure 4 - Shared responsibility model for container services

Shared responsibility model for abstracted services

AWS offers abstracted services such as Amazon DynamoDB and Amazon Simple Queue Service, Amazon S3, and so on, where you can access endpoints of these services for storing, modifying and retrieving data. AWS is responsible for managing these services, that is, operating the infrastructure layer, installing and updating the operating system and managing platforms as well. These services are tightly integrated with IAM so you can decide who can access your data stored in these services.

You are also responsible for classifying your data and using service-specific tools for configuring permissions at the platform level for individual resources. By using IAM, you can also configure permissions based on role, user identity or user groups. Amazon S3 provides you with encryption of data at rest at the platform level, and, for data in transit, it provides HTTPS encapsulation through signing API requests.

The following figure shows this model for abstracted services:

Figure 5 - Shared responsibility model for abstracted services