Achieving security and compliance in the AWS cloud.
When an AWS account is created, both the partner and AWS must consider various security and compliance factors. AWS refers to this as the Shared Responsibility Model. Below, we’ll review the purpose of this model and how best to navigate this important security foundation for well-architected, secure AWS workloads.
“Of” the cloud vs. “in” the cloud
The image below gives an overview of the ways in which AWS holds responsibility “of the cloud” and those that are the responsibility of the customer (or partner) “in the cloud.” Another way to consider these two components would be the physical aspects vs. the virtual aspects of the cloud. If it is a physical object — say, a server — then that is the responsibility of AWS because the partner does not have the ability to touch any physical AWS resources. If it is virtual, then responsibility could sit with the partner or AWS to protect and secure that resource. Of course, there will always be that odd exception to that rule if you are using certain services such as Outposts, but overall, the diagram below fits most use cases.
AWS’ responsibility
AWS’ responsibilities are composed of hardware and software. Starting with hardware — all the physical servers, networking cables, temperature control units, and other physical elements that make up a data center — all elements need to be secured. Protocols should be put in place to determine which employees are granted access to the data center, which can remove servers from racks, and which can decommission them.
The software layer sits on top of the physical layer, and if you have ever used AWS Managed Services such as RDS (Relational Database Service), they make sure that your Microsoft SQL RDS instance is patched, secured, and upgraded in the most timely and least impactful manner during maintenance windows.
Your security responsibility
There are some crucial concepts to keep in mind when considering your own responsibility in achieving cloud security. Encryption, or the act of converting information into secret codes that hide its true meaning, is a vital aspect of securing the data that is created, read, updated, or deleted. Data breaches often occur due to a lack of encryption for data at rest or in transit. It is your choice to add SSL certificated (HTTPS) traffic to network traffic and add encryption to the data services you are using in AWS, but an “encryption by default” mindset is recommended in order to manage your data more securely.
In addition, implementing robust access control, where the right access is granted to the right person, at the right time, can help you better secure your data. The concept of the root user, or the account owner that is created when the AWS account is set up, dictates this user should never be used for day-to-day activity, as they have the ability to close down an entire AWS account — a non-reversable and extremely damaging (reputationally and operationally) occurrence if it is not expected by your end customers.
It’s advisable to lock down the root credentials and attach multi-factor authentication (MFA), defined as requiring multiple steps to verify a user’s identity, to reduce rogue actors impersonating your credentials. When you are using the IAM (Identity and Access Management) service, which allows you to create users within the AWS account, you apply AWS policies to them. These policies govern what APIs that IAM entity can interact with. You could use the AWS managed policies or create your own ones. Pax8 encourages the Principle of Least Privilege approach to creating custom IAM policies, which you can learn more about in our AWS bootcamp February 21.
It’s also your responsibility to ensure the operating systems, frameworks, and applications that you install and use on AWS compute resources stay compliant and up to date to protect from CVEs (common vulnerabilities and exposures or known security flaws). AWS does provide a number of services to support you with these tasks, such as the AWS Patch Manager, which can automatically install the latest patches to operating systems during maintenance windows, and Amazon Inspector, which can identify vulnerabilities in your application code.
Security is a joint effort
There are many elements to the shared responsibility model from AWS, and it’s imperative to understand the components you are responsible for before any workload is designed or built. A recommended approach is to use the security pillar of AWS’ Well Architected Framework, which offers fantastic groundwork into best practices and recommendations for the design, delivery, and maintenance of secure AWS workloads.
Whether you’re just getting started with providing IaaS (infrastructure-as-a-service) services through AWS or looking to improve your AWS security, Pax8 has a team of experts that can help you achieve your goals. Get in touch to make your journey with AWS a success.
