Module 3: Securing Access
Section 1: Security Principles: -
AWS shared responsibility model: -
Security is a Well-Architected Framework Pillar: -
Design principles for the security pillar: -
- Implement a strong identity foundation: Implement the principle of least privilege and
enforce separation of duties with appropriate authorization for each interaction with
your AWS resources.
- Protect data in transit and at rest: Classify your data into sensitivity levels, and use
mechanisms, such as encryption, tokenization, and access control, where appropriate.
Protecting data at rest
with client-side encryption
Protecting data at rest
with server-side encryption
- Apply security at all layers: Apply a defence-in-depth approach with multiple security
controls and apply it to all layers.
- Keep people away from data: Use mechanisms and tools to reduce or eliminate the
need for direct access or manual processing of data. This reduces the risk of
mishandling or modification and human error when handling sensitive data.
- Maintain traceability: Monitor, alert, and audit actions and changes to your
environment in real time. Integrate log and metric collection with systems to
automatically investigate and take action.
- Prepare for security events: Prepare for an incident by having incident management
and investigation policies and processes that align to your organizational requirements.
- Automate security best practices: Automated software-based security mechanisms
improve your ability to securely scale more rapidly and cost-effectively.
Section 2: Authenticating and Securing Access: -
Authentication and Authorization: -
AWS Identity and Access Management (IAM): -
IAM terminology: -
Using IAM to control access to AWS resources: -
IAM credentials for authentication: -
Best practices to secure access: -
- Follow the principle of least privilege: Assign users, groups, and roles with the
minimum necessary permissions to perform their tasks, and avoid providing
unnecessary permissions.
- Enable MFA: MFA adds an extra layer of security for your root user by requiring a code
that is generated by a hardware or software token during sign-in.
- Require human users to access AWS by using temporary credentials: Instead of
granting long-term credentials to users, use an identity to provide federated access to
AWS accounts by assuming IAM roles, which provide temporary credentials.
- Rotate access keys: for scenarios in which you need IAM users with programmatic
access and long-term credentials, use access key last used information to rotate and
remove access keys regularly.
- Use strong, complex passwords: Ensure that the root user and IAM users have strong,
unique passwords that follow AWS password policy guidelines.
- Secure local credentials: Secure access keys, passwords, and MFA tokens by storing
them in a secure password manager or hardware tokens.
- Use AWS Organizations: Use Organizations to consolidate multiple AWS accounts to
manage billing, access control, and resources centrally.
- Enable AWS CloudTrail: By enabling CloudTrail, you can have a record of all the actions
that are taken in an account, which makes it easier to identify possible security risks and
comply with auditing requirements.
- Protect the root user: When you first create an AWS account, you have a single sign-in
identity that has complete access to all AWS services and resources in the account.
This is the root user, and it’s important to minimize the risk of access through this
account given its power. Limit the use of the root user and monitor activity using
CloudTrail logs, AWS Trusted Advisor recommendations, and console sign-in events for
any suspicious activity related to your root user.
o Rather than using the root user to do day-to-day administrative tasks, create an
administrative user with permissions to perform most administrative tasks.
o Only use the root user to perform those tasks that cannot be performed by any
other user.
Steps to set up an admin user: -
Best practices: IAM users and groups: -
- To configure long-term access, a best practice is to attach IAM policies to IAM groups,
and then assign IAM users to these IAM groups. An IAM user who is a member of an IAM
group inherits the permissions that are attached to that group. You can also attach IAM
policies directly to an IAM user to further customize the access that is granted through
the group.
IAM roles: -
By using an IAM role, you can define a set of permissions for the resources that a user or service
needs to access. However, the permissions aren’t attached to an IAM user or group. Instead, the
permissions are attached to a role, and the user or service assumes the role. When a user
assumes a role, the user's prior permissions are temporarily forgotten.
- When you use IAM roles, you don’t need to grant long-term security credentials to each
entity that requires access to a resource.
Three Examples of using an IAM role: -
Section 3: Authorizing Users: -
IAM policies and permissions: -
Policy: is an object that defines permissions for the identity or resource that it’s associated
with.
Determining permissions at the time of request: -
When IAM determines whether an action is allowed, the service first checks for the existence of
any applicable explicit denial policy. If an explicit denial doesn’t exist, then IAM checks for any
applicable explicit allow policy. If an explicit deny or explicit allow policy doesn’t exist, IAM
reverts to the default and denies access. This process is referred to as an implicit deny. A user
will be permitted to take the action only if the requested action is not explicitly denied and is
explicitly allowed.
- By default, all requests are denied.
- An explicit allow overrides the default deny.
- An explicit deny overrides any explicit allow.
The order that the policies are evaluated in has no effect on the outcome of the evaluation. All
policies are evaluated, and the result is always that the request is either allowed or denied.
- Suppose that a conflict occurs (one policy allows an action and another policy denies
an action). Then, the most restrictive policy (that is, the policy that denies the action ) is
applied.
The IAM policy simulator is a helpful tool to test and troubleshoot IAM policies.
Identity-based and resource-based policies: -
Policies: Example 1: -
Policies: Example 2: -
Section 4: Parts of an IAM Policy: -
Example: resource-based policy: -
The example IAM policy on this slide allows access only to the following resources:
- The DynamoDB table course-notes.
- The S3 buckets course-notes-web and course-notes-mp3.
The explicit deny ("Effect":"Deny") element uses the NotResource element to ensure that users
cannot use any other DynamoDB or S3 actions or resources, except those that are specified in
the policy. This is the case even if permissions have been granted in another policy. An explicit
deny statement takes precedence over an allow statement.
Example: Identity-based policy: -
If this policy was attached to an IAM user, the user would be able to perform the following
actions:
- Create, delete, get, or update their own password by using IAM LoginProfile actions.
- Create, delete, list, or update their own access key by using IAM AccessKey actions.
- Create, delete, get, list, or update their own Secure Shell (SSH) keys by using IAM
SSHPublicKey actions.
Example: Cross-account, resource-based policy: -
In this scenario, account A created the resource-based policy. The policy grants account B
access to perform anyAmazon S3 API operation—which is indicated by the asterisk (*)—on the
S3 bucket named DOC-EXAMPLE-BUCKET in account A.
- This S3 bucket policy doesn’t specify any IAM users, groups, or roles. Instead, it
specifies account B (AWS account number 111122223333). Account B should create an
IAM user policy to allow a user in account B to access account A's bucket.
Activity: IAM policy analysis (1 of 3): -
Activity: IAM policy analysis (2 of 3): -
Activity: IAM policy analysis (3 of 3): -