AWS security best practices begin with the AWS Shared Responsibility Model that dictates which security controls are AWS’s responsibility and which are yours.
Updated: September 2017 – Inclusion of additional models
Over my next several posts, I’ll be discussing AWS security best practices from different perspectives and covering different AWS services. The overall goal is to help you improve the security of your cloud environments. We’ll start with the AWS Shared Responsibility Model, which lies at the very foundation of AWS Security.
By the very nature of the phrase “AWS Shared Responsibility Model,” we can see that security implementation on the AWS Cloud is not the sole responsibility of any one player, but is shared between AWS and you, the customer.
The AWS Shared Responsibility Model dictates which security controls are AWS’s responsibility, and which are yours. In short, you decide how you want your resources to sit ‘in’ the cloud (in other words, how much access you choose to give to and from your resources), while AWS guarantees the global security ‘of’ the Cloud (i.e., the underlying network and hardware they provide to host and connect your resources).
We will briefly describe a number of configurable security elements later in this post, but first, we’re more interested in understanding our responsibilities rather than how to implement them.
In my experience, a solid understanding of the AWS Shared Responsibility Model makes it easier to build and maintain a highly secure and reliable environment. Without knowing where I needed to step in and take control of data security, I was never able to properly define just how secure my environment really was.
AWS treats security as a major priority…and so should you
Security is AWS’s number-one priority in every sense. It’s an area into which AWS pours huge capital and energy and devotes near-constant attention.
There’s a reason for this. After speaking with my business contacts in various sectors, it seems that security is still one of the main reasons corporations are reluctant to adopt a cloud presence. Overcoming this hesitation requires AWS to be at the very top of security excellence and governance.
Having served over a million customers in the past month alone, AWS’s most stringent security standards are already being used for audit purposes by the most security-sensitive customers around. Facing so many requirements, AWS is certified and compliant across a huge range of security standards, including PCI DSS, ISO, and SOC.
AWS Services are deployed and distributed in exactly the same way throughout their entire global infrastructure. This means a single user accessing a simple S3 bucket for document backups is covered by the same strict security standards as the largest and most demanding corporations.
AWS Shared Responsibility Models
To help provide a clear definition of the boundaries of responsibility, AWS has devised 3 main models, each representing where AWS and customer responsibilities start and end:
- Shared Responsibility Model for Infrastructure Services
- Shared Responsibility Model for Container Services
- Shared Responsibility Model for Abstract Services
By taking a look at each of these models, we will be able to clearly see the differences. Let’s start by looking at the first model, based on an infrastructure that includes services such as EC2. Then, we’ll look at how the level of responsibility shifts as we move into containers and abstract services.
For more information on the differences between container and abstract services within AWS, please see our course AWS Security Best Practices: Abstract and Container Services.
Shared Responsibility Model: Infrastructure Services
As we said, AWS is responsible for what is known as Security ‘of’ the cloud. This covers their global infrastructure elements including Regions, Availability Zones, and Edge Locations, and the foundations of their Compute, Storage, Database, and Network services.
AWS owns and controls access to their data centers where your customer data resides. This covers physical access to all hardware and networking components and any additional data center facilities including generators, uninterruptible power supply (UPS) systems, power distribution units (PDUs), computer room air conditioning (CRAC) units, and fire suppression systems. Some of the security compliance controls mentioned previously are based upon this physical access entry and control. Essentially, AWS is responsible for the components that make up the cloud, any data put ‘into’ the cloud then becomes your responsibility.
With the basic Cloud infrastructure secured and maintained by AWS, the responsibility for what goes into the cloud falls on you. This covers both client and server side encryption and network traffic protection, security of the operating system, network, and firewall configuration, followed by application security and identity and access management.
How much of this additional security you wish to implement is entirely your decision. What you choose may depend on the nature of your business or on existing controls that you may already have in place. I recommend tightening security as much as possible to minimize exposure to external threats that could compromise your environment. The important point to remember is that, while AWS provides many powerful security controls, how and when to apply them is not AWS’s responsibility.
Shared Responsibility Model: Container Services
Examples of AWS container services include:
- AWS Relational Database Service (RDS)
- AWS Elastic Map Reduce (EMR)
- AWS Elastic Beanstalk
Straight away, we can see that both Platform and Application management along with any operating system or system and network configuration has shifted to being the responsibility of AWS and is no longer down to us as the customer to manage. This is a huge difference from that of infrastructure-based services.
However, not all responsibility has shifted. You should note that firewall configuration remains the responsibility of the end user, which integrates at the platform and application management level. For example, RDS utilizes security groups, which you would be responsible for configuring and implementing.
Shared Responsibility Model: Abstract Services
Examples of abstract services include:
- Simple Storage Service (S3)
- Amazon Glacier
You will notice that even more responsibility has been shifted to AWS, specifically Network Traffic protection, which AWS will manage via the platform protecting all data in transit using AWS’s own network. You are also responsible for using IAM tools to apply the correct permissions both at the platform (such as S3 Bucket policies) and IAM user/group level.
As we progress through each of these models, it’s clear that the level of control and responsibility shifts more toward AWS than to the customer.
When you create your AWS Account, you will have an AWS Administrator account and credentials that will allow you to create other users, groups, and roles within the Identity & Access Management (IAM) Service. Right from the get-go, you are in control of who can access your resources, and it’s up to you to manage this access properly. IAM is a very powerful tool that you can use to create a very specific set of access permissions and private security keys for the resources you deploy. Within IAM, you can also implement Multi Factor Authentication, something I strongly recommend for ALL of the administrator accounts that you create, and especially the admin account.
To learn how to use IAM and understand all of its features, take a look at our course, AWS: Overview of AWS Identity & Access Management (IAM).
OS security patches
Once you launch an EC2 instance, the responsibility for properly applying the latest security patches to the operating system is yours as we can see from the infrastructure model. AWS will not notify you when a new patch is released for your EC2 instance OS; you must manage EC2 OS security.
Whether you’re running Windows or some flavor of Linux (like CentOS, Ubuntu, or SUSE), you must manage the operating system’s security settings. Do not assume that the latest AMIs (Amazon Machine Images) have the very latest security patches. Always check for updates, for example using “yum update” (or “aptitude safe-upgrade”) for Linux, and the Windows update program for Windows.
Security Groups and NACLs
To fully secure your instances, I can’t stress enough the importance of configuring your security groups as tightly as possible. Security groups act as an instance-level firewall with rules, filtering traffic into and out of your instance. They work at a protocol and port level, restricting source traffic at an IP and security group level. This allows you to grant access to your instances using specified protocols and port numbers, opening access from only a single IP address (x.x.x.x/32), from anywhere in the world (0.0.0.0/0) or from addresses in another, pre-configured security group.
For security within your Virtual Private Cloud (VPC) at the subnet/network level, you can implement Network Access Control Lists (NACLs). The NACL is similar to security groups in that it is comprised of rules, but it monitors traffic at the subnet level. It’s important to note that security groups are stateful, while the NACL is stateless. You must remember this when setting up your NACL, as it means you will need to specify rules for both inbound and outbound traffic. NACLs are associated with specific subnets, and so present a great way to help protect against DDOS attacks. Understanding these groups is crucial to controlling who or what can access the resources within your VPC.
Should you need greater security for your data when it’s at rest, you could implement client- or server-side encryption and traffic integrity and protection. For example, you can use 256-bit AES encryption methods with S3 buckets, or enable EBS encryption for your EC2 storage volumes.
This has been the first of a series of articles based on AWS Security and AWS security best practices. I hope this has provided a better understanding of what is expected from you (the customer) with regards to security, compared to what is supplied and managed by AWS. With this, you can now begin deploying a strong and effective security policy within your environment from the ground up.
With this first post from our security series, I hope you’re clear on the division of roles created by the AWS Shared Responsibility Model. Next, I will be covering security concepts related to Amazon’s Virtual Private Clouds, including the best practice use of security groups and how they should be used to achieve the highest instance security possible. I will also discuss the differences between dedicated and multi-tenant instances, and provide an overview of secret and public access keys when using API calls to access EC2 instances.
Got feedback? Please leave a comment below.
Top 5 AWS Salary Report Findings
At the speed the cloud tech space is developing, it can be hard to keep track of everything that’s happening within the AWS ecosystem. Advances in technology prompt smarter functionality and innovative new products, which in turn give rise to new job roles that have a ripple effect on t...
New on Cloud Academy: Red Hat, Agile, OWASP Labs, Amazon SageMaker Lab, Linux Command Line Lab, SQL, Git Labs, Scrum Master, Azure Architects Lab, and Much More
Happy New Year! We hope you're ready to kick your training in overdrive in 2020 because we have a ton of new content for you. Not only do we have a bunch of new courses, hands-on labs, and lab challenges on AWS, Azure, and Google Cloud, but we also have three new courses on Red Hat, th...
Cloud Academy’s Blog Digest: Azure Best Practices, 6 Reasons You Should Get AWS Certified, Google Cloud Certification Prep, and more
Happy Holidays from Cloud Academy We hope you have a wonderful holiday season filled with family, friends, and plenty of food. Here at Cloud Academy, we are thankful for our amazing customer like you. Since this time of year can be stressful, we’re sharing a few of our latest article...
Google Cloud Platform Certification: Preparation and Prerequisites
Google Cloud Platform (GCP) has evolved from being a niche player to a serious competitor to Amazon Web Services and Microsoft Azure. In 2019, research firm Gartner placed Google in the Leaders quadrant in its Magic Quadrant for Cloud Infrastructure as a Service for the second consecuti...
New Lab Challenges: Push Your Skills to the Next Level
Build hands-on experience using real accounts on AWS, Azure, Google Cloud Platform, and more Meaningful cloud skills require more than book knowledge. Hands-on experience is required to translate knowledge into real-world results. We see this time and time again in studies about how pe...
New on Cloud Academy: AWS Solution Architect Lab Challenge, Azure Hands-on Labs, Foundation Certificate in Cyber Security, and Much More
Now that Thanksgiving is over and the craziness of Black Friday has died down, it's now time for the busiest season of the year. Whether you're a last-minute shopper or you already have your shopping done, the holidays bring so much more excitement than any other time of year. Since our...
Understanding Enterprise Cloud Migration
What is enterprise cloud migration? Cloud migration is about moving your data, applications, and even infrastructure from your on-premises computers or infrastructure to a virtual pool of on-demand, shared resources that offer compute, storage, and network services at scale. Why d...
6 Reasons Why You Should Get an AWS Certification This Year
In the past decade, the rise of cloud computing has been undeniable. Businesses of all sizes are moving their infrastructure and applications to the cloud. This is partly because the cloud allows businesses and their employees to access important information from just about anywhere. ...
AWS Regions and Availability Zones: The Simplest Explanation You Will Ever Find Around
The basics of AWS Regions and Availability Zones We’re going to treat this article as a sort of AWS 101 — it’ll be a quick primer on AWS Regions and Availability Zones that will be useful for understanding the basics of how AWS infrastructure is organized. We’ll define each section,...
Application Load Balancer vs. Classic Load Balancer
What is an Elastic Load Balancer? This post covers basics of what an Elastic Load Balancer is, and two of its examples: Application Load Balancers and Classic Load Balancers. For additional information — including a comparison that explains Network Load Balancers — check out our post o...
Advantages and Disadvantages of Microservices Architecture
What are microservices? Let's start our discussion by setting a foundation of what microservices are. Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple Application Programming Interfaces (APIs). ...
Kubernetes Services: AWS vs. Azure vs. Google Cloud
Kubernetes is a popular open-source container orchestration platform that allows us to deploy and manage multi-container applications at scale. Businesses are rapidly adopting this revolutionary technology to modernize their applications. Cloud service providers — such as Amazon Web Ser...