A011 Atharv Kapoor B. Tech. IT.

Sem-7th CC-Lab

Module 3 Summary
1. Module Introduction and Objectives
 Module objectives: Sets the learning goals, including understanding security principles in the
AWS Cloud, explaining IAM users, groups, and roles, and how IAM policies govern
permissions.
 Module overview: Describes the structure of the module, which includes core topics on
security principles, authentication, authorization, and working with IAM policies.
 Hands-on labs in this module: A practical lab included to let you experiment with IAM—
creating users, groups, policies, and signing in using IAM credentials to solidify concepts.
2. Security Principles
 AWS shared responsibility model:
Security ownership is split—AWS secures the physical infrastructure (data centers, networks,
hardware), while you, the customer, are responsible for securing your data, apps, OS,
network configs within AWS.
 Security is a Well-Architected Framework pillar:
Security is one of the five pillars of the AWS Well-Architected Framework, emphasizing
designing systems securely, with consistent monitoring and good practices.
 Design principles for the security pillar:
These include:
 Implement a strong identity foundation: Use IAM effectively to identify and
authenticate users.
 Protect data in transit and at rest: Use encryption like TLS while data moves and at
rest inside AWS storage services.
 Apply security at all layers: Defense in depth, including network firewalls, application
controls, and physical security.
 Keep people away from data: Use automated systems to minimize human access to
sensitive information.
 Maintain traceability: Use logging (CloudTrail) to track user activity and changes.
 Prepare for security events: Have incident response plans, regular audits.
 Automate security best practices: Use automation to reduce manual errors.
 Principle of least privilege:
Always assign minimal necessary permissions for users to accomplish their tasks, reducing
the attack surface.
 Use encryption:
 Protecting data at rest with client-side encryption: Customers encrypt data before
sending it to AWS.
 Protecting data at rest with server-side encryption: AWS services encrypt data after
receiving it, decrypting it as needed.
 Key takeaways:
AWS and customers share security; applying the principle of least privilege; encryption is
critical to protect data; layered security is vital.
3. Authenticating and Securing Access
 Authentication and authorization:
Authentication confirms who is making the request (identity validation), while authorization
decides what the requester is allowed to do (permissions).
 AWS Identity and Access Management (IAM) overview:
IAM is AWS’s service to manage access control, allowing you to create identities (users,
groups, roles) and control their permissions.
 A011 Atharv Kapoor B. Tech. IT. Sem-7th CC-Lab

 IAM terminology:
Definitions of key concepts like IAM resource (users, groups, roles), IAM entities (user and
roles), IAM identity (who can be authorized), and principal (who initiates a request).
 Using IAM to control access to AWS resources:
 IAM users: Represent people or apps.
 IAM groups: Collections of users for easier permission management.
 IAM roles: Provide temporary permissions.
 IAM policies: JSON documents that define permissions.
 IAM credentials for authentication:
Credentials vary by access method. Console sign-in requires username/password; CLI or API
needs access keys.
 Best practices to secure access:
Implement least privilege, use MFA, avoid root user usage, rotate keys, use temporary
credentials, enable logging and governance tools like CloudTrail and Organizations.
 Protecting the root user:
The root user has full control—set up MFA, use it only for necessary tasks, and create admin
IAM users for daily work.
 Best practices: IAM users and groups:
Attach policies to groups to simplify permission management; assign users to groups instead
of giving individual permissions.
 IAM roles:
Characteristics include temporary security credentials that can be assumed by users,
applications, or services; used for delegation, cross-account access, or EC2 instance
permissions.
 Common use cases of IAM roles:
Example scenarios—EC2 instances using roles to access S3; granting cross-account access;
mobile app access with temporary credentials.
 Key takeaways:
Always use IAM for fine-grained control, avoid root user, use groups and roles to organize
permissions properly.
4. Authorizing Users
 IAM policies and permissions:
Policies define permissions using JSON documents specifying what actions are allowed or
denied.
 Determining permissions at the time of request (policy evaluation logic):
When a request is made:
 Check for explicit deny — highest priority.
 Else, look for explicit allow.
 Otherwise, implicit deny applies.
 Identity-based and resource-based policies:
 Identity-based: Attach to a user, group, or role (who the identity is, what they can
do).
 Resource-based: Attach to AWS resources directly (who can access this resource).
 Policy examples and how permissions are resolved:
Several examples show how multiple policies interact. For example, if an identity allows
access but the resource-based policy denies it, the deny takes precedence.
 Key takeaways:
Understand the two policy types and evaluation priorities to correctly assign permissions and
maintain security.
5. Parts of an IAM Policy
 IAM policy document structure:
 A011 Atharv Kapoor B. Tech. IT. Sem-7th CC-Lab

 Version: Policy language version.

 Statement: One or more permission entries.
 Effect: Allow or Deny.
 Principal: Specifies the user or account (used mainly in resource-based policies).
 Action: AWS operations permitted or denied.
 Resource: The specific AWS resource ARN(s) to which the actions apply.
 Condition: Optional restrictions (e.g., IP address, MFA).
 Example resource-based policy:
Grants certain DynamoDB and S3 permissions to specific resources.
 Example identity-based policy:
Grants permissions related to IAM operations scoped to a user’s own resources.
 Example cross-account resource-based policy:
Allows an AWS account (different from the resource owner) to access resources.
 Activity: Examining IAM policies:
Practical exercises analyzing example policies with questions to deepen understanding.
 Key takeaways:
Policies are JSON docs defining permissions explicitly. Learning elements of a policy helps in
creating and auditing them effectively.
6. Guided Lab: Exploring AWS Identity and Access Management (IAM)
 Lab tasks:
 Create user identities and groups.
 Apply and experiment with various IAM policies.
 Use sign-in URLs specific to IAM users to access the AWS Console.
 Debrief/discussion:
 Where to access IAM in AWS.
 What happens when policies are updated.
 Best practices discovered from hands-on experience.
7. Module Wrap-up and Summary
 Module summary:
Recaps learning on AWS security principles, IAM user/group/role concepts, and IAM policy
permissions.
 Considerations for a sample use case (café scenario):
Application of principles to a real-world business example, illustrating security concerns and
appropriate AWS IAM solutions.
 Module knowledge check details:
Explains the online quiz format for reinforcing module knowledge.
 Sample exam question and discussion:
Reviews a practical scenario requiring access management in a VPC, highlighting correct IAM
approach—creating individual users, grouping, and attaching policies at the group level for
best security management.
Summary:
This module provides a comprehensive foundation on securing AWS resources by focusing heavily on
IAM (Identity and Access Management). It covers:
 The shared responsibility for security in the cloud.
 Core security principles like least privilege and encryption.
 The structure and use of IAM including users, groups, roles, and policies.
 The distinction between authentication (identity) and authorization (permissions).
 How to write, analyze, and evaluate IAM policies.
 Practical exercises to apply the theory in real AWS environments.