AWS Security
Last updated
Last updated
The shared responsibility model divides into customer responsibilities, commonly referred to as security in the cloud and AWS responsibilities, commonly referred to as security of the cloud.
Responsibility division can be summarized as in below diagram.
You can think of this model as being similar to the division of responsibilities between a homeowner and a homebuilder. The builder (AWS) is responsible for constructing your house and ensuring that it is solidly built. As the homeowner (the customer), it is your responsibility to secure everything in the house by ensuring that the doors are closed and locked.
Customers are responsible for the security of everything that they create and put in the AWS Cloud.
When using AWS services, you, the customer, maintain complete control over your content. You are responsible for managing security requirements for your content, including which content you choose to store on AWS, which AWS services you use, and who has access to that content. You also control how access rights are granted, managed, and revoked.
The security steps that you take will depend on factors such as the services that you use, the complexity of your systems, and your company’s specific operational and security needs. Steps include selecting, configuring, and patching the operating systems that will run on Amazon EC2 instances, configuring security groups, and managing user accounts.
AWS is responsible for security of the cloud.
AWS operates, manages, and controls the components at all layers of infrastructure. This includes areas such as the host operating system, the virtualization layer, and even the physical security of the data centers from which services operate.
AWS is responsible for protecting the global infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure includes AWS Regions, Availability Zones, and edge locations.
AWS manages the security of the cloud, specifically the physical infrastructure that hosts your resources, which include:
Physical security of data centers
Hardware and software infrastructure
Network infrastructure
Virtualization infrastructure
Although you cannot visit AWS data centers to see this protection firsthand, AWS provides several reports from third-party auditors. These auditors have verified its compliance with a variety of computer security standards and regulations.
More about it here.
AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely.
It offers authentication and authorization as a service.
IAM gives you the flexibility to configure access based on your company’s specific operational and security needs. You do this by using a combination of IAM features:
IAM users, groups, and roles
IAM policies
Multi-factor authentication
When you first create an AWS account, you begin with an identity known as the root user.
The root user is accessed by signing in with the email address and password that you used to create your AWS account. It has complete access to all the AWS services and resources in the account.
An IAM user is an identity that you create in AWS. It represents the person or application that interacts with AWS services and resources. It consists of a name and credentials.
When a IAM user is created, by default it has no permissions associated with it, not even login permission. All the required permissions should be allocated explicitly to that account. By default, all actions are denied and should be allowed explicitly.
An IAM policy is a document (json) that allows or denies permissions to AWS services and resources.
The permissions are granted or denied by associating an IAM user with IAM policy.
IAM policies enable you to customize users’ levels of access to resources. For example, you can allow users to access all of the Amazon S3 buckets within your AWS account, or only a specific bucket.
Users get access to only what they need and nothing more. This is called Principle of least privilege.
Principle of Least privilege: A user is granted access only to what they need.
Example of IAM Policy
In the above example, the IAM policy is allowing specific actions within Amazon S3: ListObject and GetObject. The policy also mentions a specific bucket ID: awsdoc-example-bucket. When this policy is attached to an IAM user, it will allow the user to view a list of the objects in the awsdoc-example-bucket bucket and also access them.
An IAM group is a collection of IAM users. When you assign an IAM policy to a group, all users in the group are granted permissions specified by the policy.
Assigning IAM policies at the group level also makes it easier to adjust permissions when an employee transfers to a different job. Its just a matter of removing from one group and adding to another.
An IAM role is an identity that you can assume to gain temporary access to permissions.
Consider an example of the coffee shop,
An employee rotates to different workstations throughout the day. Depending on the staffing of the coffee shop, this employee might perform several duties: work at the cash register, update the inventory system, process online orders, and so on.
When the employee needs to switch to a different task, they give up their access to one workstation and gain access to the next workstation. The employee can easily switch between workstations, but at any given point in time, they can have access to only a single workstation. This same concept exists in AWS with IAM roles.
Before an IAM user, application, or service can assume an IAM role, they must be granted permissions to switch to the role. When someone assumes an IAM role, they abandon all previous permissions that they had under a previous role and assume the permissions of the new role.
You can enable MFA for the root user and IAM users.
As a best practice, enable MFA for the root user and all IAM users in your account. By doing this, you can keep your AWS account safe from unauthorized access.
This service acts as central location to manage multiple AWS accounts.
If your company has multiple AWS accounts. You can use AWS Organizations to consolidate and manage multiple AWS accounts within a central location.
When you create an organization, AWS Organizations automatically creates a root, which is the parent container for all the accounts in your organization.
It provides conslidated billing for all member accounts, which lead to discounts.
It allows hierarchical groupings of accounts to meet security, compliance and budgetory needs. This allows to group accounts as organizational units (OU).
In AWS Organizations, you can centrally control permissions for the accounts in your organization by using service control policies (SCPs).
SCPs enable you to place restrictions on the AWS services, resources, and individual API actions that users and roles in each account can access.
You can apply SCPs to the organization root, an individual member account, or an OU.
An SCP affects all IAM users, groups, and roles within an account, including the AWS account root user.
You can apply IAM policies to IAM users, groups, or roles. You cannot apply an IAM policy to the AWS account root user.
Read about attaching and detaching SCPs here.
In AWS Organizations, you can group accounts into organizational units (OUs) to make it easier to manage accounts with similar business or security requirements.
When you apply a policy to an OU, all the accounts in the OU automatically inherit the permissions specified in the policy.
By organizing separate accounts into OUs, you can more easily isolate workloads or applications that have specific security requirements. For instance, if your company has accounts that can access only the AWS services that meet certain regulatory requirements, you can put these accounts into one OU. Then, you can attach a policy to the OU that blocks access to all other AWS services that do not meet the regulatory requirements.
Depending on the company’s industry, you may need to uphold specific standards. An audit or inspection will ensure that the company has met those standards.
AWS Artifact is a service that provides on-demand access to AWS security and compliance reports and select online agreements. AWS Artifact consists of two main sections: AWS Artifact Agreements and AWS Artifact Reports.
Suppose that your company needs to sign an agreement with AWS regarding your use of certain types of information throughout AWS services. You can do this through AWS Artifact Agreements.
In AWS Artifact Agreements, you can review, accept, and manage agreements for an individual account and for all your accounts in AWS Organizations. Different types of agreements are offered to address the needs of customers who are subject to specific regulations, such as the Health Insurance Portability and Accountability Act (HIPAA).
Suppose that a member of the company’s development team is building an application and needs more information about their responsibility for complying with certain regulatory standards. You can advise them to access this information in AWS Artifact Reports.
AWS Artifact Reports provide compliance reports from third-party auditors. These auditors have tested and verified that AWS is compliant with a variety of global, regional, and industry-specific security standards and regulations. AWS Artifact Reports remains up to date with the latest reports released. You can provide the AWS audit artifacts to your auditors or regulators as evidence of AWS security controls.
Contains resources to help you learn more about AWS compliance.
Additionally, the Customer Compliance Center includes an auditor learning path. This learning path is designed for individuals in auditing, compliance, and legal roles who want to learn more about how their internal operations can demonstrate compliance using the AWS Cloud.
You can also access compliance whitepapers and documentation on topics such as:
AWS answers to key compliance questions
An overview of AWS risk and compliance
An auditing security checklist
