The Security Pillar-1

Identity and Access Management
Your AWS credentials let you log into the AWS management console, manage services, view and edit resources, and so on. Security in AWS begins with the foundation of identity, which is managed by the Identity and Access Management (IAM) service. Because your AWS credentials are the keys to the kingdom, the first order of business is to protect them from accidental exposure and unauthorized use. The second step is to ensure that users have only the permissions they need, and no more.

Protecting AWS Credentials
With some exceptions, if anyone is to interact with your AWS resources, they must be authenticated using a set of credentials. An entity that can take an action on an AWS resource is called a principal. You’ll sometimes see a principal also referred to as an identity.
A principal can include the following:
■ The root user
■ An IAM user
■ An IAM role
The root user has unrestricted access to your AWS account, so it’s a best practice to avoid using it for routine administrative tasks. Instead, create an IAM user and attach the AdministratorAccess AWS managed policy. For a detailed guide on securing the root user and creating an administrative IAM user, refer to Exercise 6.1 in Chapter 6, “AWS Identity and Access Management.” Another crucial step in securing the root user is to enable multifactor authentication
(MFA). When you enable MFA, in addition to entering a username and password to log into the root account, you must also enter a one-time passcode. This one-time passcode is generated by a physical or virtual MFA device, which is just an application you can install on your smartphone. Use caution when enabling MFA on the root account, as losing your MFA device means being unable to log in as the root user! If this happens, you will need to contact AWS Support to get back in. For IAM users, you can choose to enforce a password policy to ensure that all IAM users with access to the AWS Management Console have a secure password. A password policy can require any or all of the following:
■ Password complexity requirements such as minimum length, the use of lower and uppercase, numbers, and nonalphanumeric characters
■ Password expiration
■ Preventing password reuse
■ Requiring an administrator to reset an expired password
When you create an IAM user, you can choose whether to give that user AWS Management Console access, programmatic access, or both. AWS Management Console access requires a username and password. You may optionally assign an MFA token that the user must possess to sign in. Programmatic access via the AWS API, command-line interface (CLI), or an SDK requires an access key ID and secret access key.

Fine-Grained Authorization
A fundamental concept in information security is the principle of least privilege. You should give IAM principals permissions to only the resources they need and no more. By following this principle, you limit the impact that compromised credentials or malicious users can have on your AWS resources. You achieve tight control over your IAM principals through the use of policies. IAM principals have no permissions by default. In other words, simply creating an IAM user or role doesn’t grant that principal any ability to do anything in your AWS account. IAM users and roles derive their permissions only from IAM policies. An IAM policy is effectively an ACL. You define the permissions a principal has by associating the principal with one or more policies. A policy contains one or more permission statements. Each permission statement consists of, at minimum, four elements. Effect The effect can be allow or deny. The effect controls whether to allow or deny an action on a resource. Action/Operation Each AWS service has a set of actions or operations that it can perform on its resources. For example, the EC2 service includes a RunInstances action that creates a new instance.
Resource An action may require you to specify one or more resources. For example, the EC2 RunInstances action requires an Amazon Machine Image (AMI) ID. By specifying a resource in a permission statement, you can restrict access on a per-resource basis. For example, you can specify an AMI ID so that the RunInstances operation can be performed using only the specified image. Condition You may specify conditions that must be met for the permission to be granted. For example, you can allow only users from a particular IP address to perform the specified action. You can also require multifactor authentication or impose time-based restrictions on when an action can be performed. Remember that an IAM group is not a principal. It’s not possible to perform actions
under the auspices of a group in the way that you would a role.

AWS Managed Policies
AWS provides hundreds of prepackaged policies called AWS managed policies. These cover a variety of permissions commonly required by common job roles, including network administrators, database administrators (DBAs), and security auditors. AWS updates these policies periodically to include new services.

Customer Managed Policies
A customer managed policy is a stand-alone policy that you create and can attach to principals in your AWS account. When you update a Customer Managed Policy, the changes immediately apply to all of the principals that the policy is attached to. Also, IAM doesn’t overwrite your existing policy but creates a new version and maintains the last five versions so you can revert if needed.

Inline Policies
An inline policy is a set of permissions that’s embedded in an IAM principal or group. Unlike AWS and customer managed policies that exist independently of any principals, an inline policy is a part of the principal itself. Inline policies are useful when you want to ensure a policy is not inadvertently attached to the wrong principal.

Permissions Boundaries
When you attach a policy to a principal to grant that principal access, the policy is called a permissions policy. However, you can also use a policy to define permissions boundaries. Permissions boundaries let you limit the maximum permissions an IAM principal can be assigned. This can prevent you from accidentally giving a user too many permissions by inadvertently attaching the wrong permissions policy. You set permissions boundaries for a principal by selecting a managed policy that defines the maximum permissions for the principal. For example, you may create the following policy that allows all actions for the EC2
service and then attach that policy to an IAM user as a permissions boundary:

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“ec2:” ], “Resource”: ““
}
]
}

If you then attach to the user the AdministratorAccess policy—which grants full access
to all AWS services—the user will still only be able to perform actions in EC2. The permissions
boundary limits the user to performing only those actions laid out in the permissions
boundary policy. Complete Exercise 11.1 to create an IAM user whose permissions are limited
by a permissions boundary policy.

Roles
A role is an IAM principal that doesn’t have a password or access key. Like any other IAM principal, a role may have permissions policies and a permissions boundary associated with it. An IAM user or AWS resource can assume a role and inherit the permissions associated with that role. Roles are particularly useful for allowing applications running on EC2 instances to access AWS resources without having an access key. For example, if you’re running an application that requires access to DynamoDB, you can create a role that contains a permissions policy granting the appropriate access to DynamoDB. Such a permissions policy may look like this:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”, “Action”: [
“dynamodb:CreateTable”,
“dynamodb:PutItem”,
“dynamodb:ListTables”,
“dynamodb:DescribeTable”,
“dynamodb:DeleteItem”,
“dynamodb:GetItem”,
“dynamodb:Query”,
“dynamodb:UpdateItem”,
“dynamodb:UpdateTable”
],
“Resource”: “*”
}
]
}

Also read this topic: Introduction to Cloud Computing and AWS -1

Instance Profiles
Recall that in addition to containing permissions policies, a role also contains a trust policy that specifies which AWS resource may assume the role. Because the application that needs access to DynamoDB is running on an EC2 instance, the trust policy must grant EC2 permission to assume the role. Such a trust policy would look like this:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “ec2.amazonaws.com”
},
“Action”: “sts:AssumeRole”
}
]
}
A trust policy is an example of a resource-based policy.
When you create a role that grants EC2 access to assume it, IAM automatically creates an instance profile with the same name as the role. For example, suppose you used the previous permissions policy and trust policy documents to create a role named MyAppRole. IAM would automatically create an instance profile also named MyAppRole. You could then associate this instance profile with an EC2 instance, thereby granting the instance permission to assume the role.

To view the instance profile tied to this role, use the AWS CLI to issue the following command: aws iam list-instance-profiles-for-role –role-name MyAppRole You should see something like the following:
{
“InstanceProfiles”: [
{
“InstanceProfileId”: “AIPAJGKR6VR52WTHHXOR6”,
“Roles”: [
{
“AssumeRolePolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Action”: “sts:AssumeRole”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “ec2.amazonaws.com”
}
}
]
},
“RoleId”: “AROAIV2GSBS4E4HAEFTJA”,
“CreateDate”: “2018-10-13T03:20:46Z”,
“RoleName”: “MyAppRole”,
“Path”: “/”,
“Arn”: “arn:aws:iam::xxxxxxxxxxxx:role/MyAppRole”
}
],
“CreateDate”: “2018-10-13T03:20:46Z”,
“InstanceProfileName”: “MyAppRole”,
“Path”: “/”,
“Arn”: “arn:aws:iam::xxxxxxxxxxxx:instance-profile/MyAppRole”
}
]
}

By associating an instance with an instance profile, the instance is able to acquire temporary credentials—an access key, a secret key, and a session token—using the Security Token Service. The Security Token Service places the temporary credentials in the instance metadata and updates them about every six hours. To view the temporary credentials granted by a role named MyAppRole, you could theoretically browse to the following URL from
within the instance: http://169.254.169.254/latest/meta-data/iam/security-credentials/MyAppRole And you would see something like the following: {
“Code” : “Success”,
“LastUpdated” : “2018-10-14T20:47:19Z”,
“Type” : “AWS-HMAC”,
“AccessKeyId” : “ASIASJ6WQJMEE32SJ56C”,
“SecretAccessKey” : “vcAiY5Tps6U3pbr2TFjzwrrRe2ETXbi0T+mDr1Qi”,
“Token” :
“FQoGZXIvYXdzEBYaDLwVhhKEzhxBvNtRMyK3A7RpKrXELCv61rGatSWBi1Ehg3w9gOBww7jjy9mCAwTK7kA4S
IyhmyEXQR32McB4xWqjxM3/K4Ij9o5+7ALpegD5p5c0cO7BqGIb4Xb3vZcJiA0pMk7jWRb6afB8c+iAdP1PhRE
R8oJpAOmUHwC2NoT85tpUbAwPtJc4SCW9HmFvI3Hq5pBOo2c1gB75SdcmaYMR/Xl+HxkV/KM5tqyx64BypS4uA
ByW9BuoQ5GH+WKHBXOzIFuhVDpvKS2XXaoOOfz/dfdLo/t1n13KkhzXf43NFc4Lunqsd4Zo9o7yr2D+ezXNLPD
phRN3Itc9dxSaCZY7QE51fgdDUCPBPsQ17okukrcT5jI/R+rY3cL/bBxOQ4VUd47bUcASRxCag2xvDONMAqDpb
PX4j2Kbgs8avLqEFj4q4RkCOM28gETeqWxEE8XNZEfpXCupr1eeyfPul3BzcZmrTMu22ZvvySyzYJQVf9Yijpg
Wa9RcGBFQGKbWAgu5aWxdJvKjDCDjkupyhi2tnBRlRuRXgtXXN19NkDEiVus7rAnZLMRuBIIgbeWtT6BXSMMjt
HqZ6NpaagDwGHtNmvOv6AEondaO3gU=”,
“Expiration” : “2018-10-15T03:21:21Z”
}
Notice that the access key ID, secret access key, and session token are in plaintext. These credentials are what an application running on the instance would use to authenticate to the AWS API to perform operations. It is possible for a malicious user or malware to take these credentials and use them to grain unauthorized access. For example, a user may use the preceding credentials to attempt to enumerate resources using the AWS CLI, as follows:
[ec2-user@ip-172-31-88-201 ~]$ export AWS_ACCESS_KEY_ID=ASIASJ6WQJMEE32SJ56C
[ec2-user@ip-172-31-88-201 ~]$ export
AWS_SECRET_ACCESS_KEY=vcAiY5Tps6U3pbr2TFjzwrrRe2ETXbi0T+mDr1Qi
[ec2-user@ip-172-31-88-201 ~]$ export
AWS_SESSION_TOKEN=FQoGZXIvYXdzEBYaDLwVhhKEzhxBvNtRMyK3A7RpKrXELCv61rGatSWBi1Ehg3w9gOBw
w7jjy9mCAwTK7kA4SIyhmyEXQR32McB4xWqjxM3/K4Ij9o5+7ALpegD5p5c0cO7BqGIb4Xb3vZcJiA0pMk7jWR
b6afB8c+iAdP1PhRER8oJpAOmUHwC2NoT85tpUbAwPtJc4SCW9HmFvI3Hq5pBOo2c1gB75SdcmaYMR/Xl+HxkV
/KM5tqyx64BypS4uAByW9BuoQ5GH+WKHBXOzIFuhVDpvKS2XXaoOOfz/dfdLo/t1n13KkhzXf43NFc4Lunqsd4
Zo9o7yr2D+ezXNLPDphRN3Itc9dxSaCZY7QE51fgdDUCPBPsQ17okukrcT5jI/R+rY3cL/bBxOQ4VUd47bUcAS
RxCag2xvDONMAqDpbPX4j2Kbgs8avLqEFj4q4RkCOM28gETeqWxEE8XNZEfpXCupr1eeyfPul3BzcZmrTMu22Z
vvySyzYJQVf9YijpgWa9RcGBFQGKbWAgu5aWxdJvKjDCDjkupyhi2tnBRlRuRXgtXXN19NkDEiVus7rAnZLMRu
BIIgbeWtT6BXSMMjtHqZ6NpaagDwGHtNmvOv6AEondaO3gU=

The export commands set environment variables that the AWS CLI fetches the credentials from. The user may then attempt to list all DynamoDB tables, like so:
[ec2-user@ip-172-31-88-201 ~]$ aws dynamodb list-tables
{
“TableNames”: [
“MySecretTable”,
“Recipes”
]
}
Because the role grants the ListTables action, the credentials generated by the Security Token Service also grant that permission. However, if the user tries to use the same credentials to enumerate EC2 instances, the action fails.
[ec2-user@ip-172-31-88-201 ~]$ aws ec2 describe-instances
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation. Therefore, it’s imperative that you follow the principle of least privilege and don’t grant a role more permissions than it requires. As an additional precaution, you can disable the Security Token Service on a per-region basis from the Account Settings menu option in the IAM Dashboard. Later in the chapter, you’ll see how Amazon GuardDuty can help you identify when credentials such as these have been compromised.

Assuming a Role
You can create a role and allow any IAM user to assume it. The IAM user that assumes the role can be in the same account as the role or in a different account. When you assume a role, you have only the permissions granted to that role. The permissions of the IAM user you’re logged in as are not added to the permissions of the role you assume. For instance, if you are logged in as an IAM user with full access to all AWS services and then assume a role that has read-only access to the EC2 service, you will not have access to any other AWS services.

Enforcing Service-Level Protection
In addition to defining identity-based IAM policies to control access to resources, some AWS services allow you to define resource-based policies. For example, S3 offers optional bucket policies that control access to objects or entire buckets. The Key Management Service (KMS) requires you to define a key policy to specify the administrators and users of a key. SNS topics have resource policies to control who may publish messages or subscribe to a topic, as well as which delivery protocols they may use. Simple Queue Service (SQS) queues also use resource-based policies to control who can send to and receive messages
from a queue. Notice that users without AWS credentials tend to consume the AWS services that offer resource-based policies. For example, an end user of an application may receive an SNS notification via email, even though they don’t have an AWS account. An anonymous user on the Internet may download a publicly accessible object stored in an S3 bucket. Resourcebased policies give you control that you wouldn’t have with identity-based policies alone. As with identity-based policies, use the principle of least privilege when creating resourcebased policies.

Detective Controls
AWS offers a number of detective controls that can keep a record of the events that occur in your AWS environment, as well as alert you to security incidents or potential threats.

CloudTrail
It’s important to carefully think about what you want to log and how you’ll use the information contained in those logs. CloudTrail can log activities on your AWS account. But before configuring CloudTrail, you need to decide the scope of the logging, including whether to log any of the following:
■ Management events, data events, or both
■ Read-only events, write-only events, or both ■ All resources or just specific ones
■ All regions or just specific regions
■ Global services
You’ll also need to decide how many trails to create. You may decide to have one trail for read-only events and another for write-only events. Or you may choose to have a separate trail for each region. CloudTrail stores logs in S3, so you’ll want to set up bucket policies to control who can read and delete those logs. You may also consider setting up an additional trail just to log data events on the S3 bucket containing your CloudTrail management event logs. For additional security, when creating a trail, enable SSE-KMS encryption and log file integrity validation. You can optionally have CloudTrail generate a Simple Notification Service (SNS) notification when it delivers a log file to the S3 bucket. Note that it can take up to 15 minutes between the time an event occurs and when the CloudTrail creates the log file containing the event.

CloudWatch Logs
CloudWatch Logs can aggregate logs from multiple sources for easy storage and searching. The logs that CloudWatch can ingest from various AWS services include the following:
CloudTrail Logs To easily search and view CloudTrail logs, stream them to CloudWatch Logs. To set this up, refer to the steps in Exercise 7.3 in Chapter 7, “CloudTrail, CloudWatch, and AWS Config.”
VPC Flow Logs VPC flow logs include information about traffic ingressing or egressing a VPC. Flow logs include network interface, source and destination IP addresses, ports, protocols, and packet and byte counts. Flow logs do not include DHCP traffic or traffic to the Amazon DNS server. Follow the steps in Exercise 11.3 to configure VPC flow logging and deliver the logs to CloudWatch Logs.
RDS Logs RDS can stream logs from database engines including MariaDB, MySQL, Aurora with MySQL compatibility, and Oracle. Route 53 DNS Queries You can configure Route 53 to log DNS queries for a hosted zone and stream them to CloudWatch Logs.
Lambda You can add logging statements to Lambda code. Lambda automatically streams these log events to a log group derived from the name of the function, using the format /aws/lambda/.

Upcoming Training :- ISO27001 LA T. D.:-Coming soon.. ISO42001 LI T. D.:-16th,17th Nov 2024.

People also ask this Questions

Leave a Comment Cancel Reply