### Slide 1: ![Slide 1](slide_1.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 2: ![Slide 2](slide_2.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 3: ![Slide 3](slide_3.png) ::: Notes This slide sets the course scenario: students are administrators at Example Corp. tasked with standardizing access management, organizing accounts, and inventorying resources. Before covering the mechanics, ask students to think about what 'standardized access management' actually requires — different teams have different needs, and a uniform policy that ignores those differences creates its own operational problems. #### Instructor notes #### Student notes As different departments provision more AWS resources, the chief information officer (CIO) of your company wants to standardize access management, organize existing AWS accounts, and inventory AWS resources. Your manager would like you to design permissions templates for groups and roles in your team's AWS accounts. In addition, your manager would like a plan to best organize the company's numerous AWS accounts. Your manager also wants an inventory of all your company's current resources. ::: ### Slide 4: ![Slide 4](slide_4.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 5: ![Slide 5](slide_5.png) ::: Notes This module covers three distinct but related IAM concerns: identity management, permissions management, and best practices. Authentication answers who is making a request; authorization answers what they can do. These are separate concerns that must be designed together — getting authentication right without tightly scoping permissions leaves you with verified but over-privileged identities. #### Instructor notes #### Student notes This section is divided into the following subsections: * **Authentication** : Which is *identity management* * **Authorization** : Which is *permissions management* * **Best practices** ::: ### Slide 6: ![Slide 6](slide_6.png) ::: Notes IAM is the central control plane for AWS access, and its power comes with real complexity. Before covering features, ask students to think about what access control actually requires: who needs access, how do you verify identity, and how do you limit what authenticated users can do? IAM provides the mechanisms to answer these questions, but how you configure it determines whether your environment is actually secure or just authenticated. #### Instructor notes #### Student notes AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. Use IAM to control who is authenticated (signed-in) and authorized (has permissions) to use resources. Think of IAM as the tool to centrally manage access to launching, configuring, managing, and terminating your resources. You have granular control over access permissions based on resources. The control extends to determine exactly which API calls for each service you allow. For more information, see "What is IAM" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html. ::: ### Slide 7: ![Slide 7](slide_7.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 8: ![Slide 8](slide_8.png) ::: Notes A principal is any entity that can make requests to AWS, and the variety of principal types creates different risk profiles. IAM users carry long-term credentials that must be rotated and protected; roles provide short-lived credentials; federated users rely on the security posture of external identity providers. Each type involves different trust assumptions and a different blast radius if that trust is violated. #### Instructor notes #### Student notes A *principal* is an entity that can request an action or operation on an AWS resource. The most common type of principal is an IAM user. Other principal types include AWS services and identity providers. **Types of principals:** * IAM users: Internal identities with long-term credentials * Applications: Supported through programmatic access or by *assuming an IAM role* * AWS services: Such as Amazon EC2, Amazon Lambda, or other services * External identities: Through a SAML 2.0 provider or identity provider (IdP) **External identities with IdPs:** Federated users are external identities that do not have an AWS account. You grant them temporary security credentials to access your resources. An IdP allows you to manage identities from outside of AWS (such as with a login with Amazon, Apple, Google, or Facebook) and grant them permissions to use AWS resources. For more information, see the Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-terms. ::: ### Slide 9: ![Slide 9](slide_9.png) ::: Notes AWS supports multiple credential types because different interaction methods have different security requirements. Console users need passwords; programmatic callers need access keys; roles provide temporary credentials that expire automatically. Using the wrong credential type for a context creates unnecessary risk — ask students when they would specifically *not* want to use long-term access keys. #### Instructor notes #### Student notes You can use different types of *security credentials*, depending on how you interact with AWS. For example, to sign in to the AWS Management Console, you use a username and password. In contrast, to make programmatic calls to AWS API operations, you use access keys. The table summarizes the different types of AWS security credentials and when you might use each one. For more information about root user credentials, see the AWS Account Management API Reference Guide at https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html. ::: ### Slide 10: ![Slide 10](slide_10.png) ::: Notes IAM users represent identities within your account, but they come with long-term credentials that create management overhead. Every user whose credentials are not rotated, not removed when no longer needed, or not scoped to least privilege becomes a potential attack vector. AWS increasingly recommends roles over IAM users for most use cases — consider what your current IAM user model assumes about the people and applications using it. #### Instructor notes #### Student notes An IAM user is an entity that you create in AWS that provides a way to interact with AWS. Create IAM users to give individuals identities that they can use to sign in to the AWS Management Console and make requests to AWS services. **User credentials and permissions:** Newly created IAM users have no default credentials to authenticate themselves and access AWS resources. You must first assign *security credentials* to them for authentication. Then, attach permissions that authorize them to perform any AWS actions or to access any AWS resources. The credentials you create for IAM users are what they use to uniquely identify themselves to AWS. **IAM users for applications:** An IAM user is an identity with associated permissions. You might create an IAM user to represent an application that must make requests to AWS. An application might have its own identity and set of permissions in your AWS account, similar to how processes have their own identities and permissions in an operating system such as Windows or Linux. **Best practice:** AWS strongly recommends not using the root user credentials for day-to-day interactions with AWS. You can easily manage and audit IAM users for this purpose. For more information, see the Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_identity-management.html#intro-identity-first-time-access. ::: ### Slide 11: ![Slide 11](slide_11.png) ::: Notes Roles provide temporary credentials and eliminate the need to manage long-term secrets, but they introduce a different set of concerns. Who can assume a role, and what can they do once they have? Overly permissive trust policies — particularly those using wildcards in the principal element — can allow unintended privilege escalation. The benefits of roles over IAM users are significant, but only if the trust boundaries are correctly defined and regularly reviewed. #### Instructor notes #### Student notes You can create an IAM role in your account. It is an AWS identity with permissions policies that determine what the identity can and cannot do in AWS. Although similar to an IAM user, an IAM role is not associated with one person and does not have long-term credentials (password or access keys). Instead, when you assume a role, it provides temporary security credentials for your role session. **When to use an IAM role:** Roles are useful for delegating access to users, applications, or services that do not normally have access to your AWS resources: * **Grant users in your account access to resources they don't usually have** (cross-team access or special project access) * **Grant users in another account access to your resources** (cross-account delegation) * **Allow applications to use AWS resources without embedding credentials** (avoiding the need to rotate hard-coded keys) * **Grant federated users access** (users with identities defined outside of AWS, such as in your corporate directory or IdP) * **Enable third-party audits** (allow external parties to perform audits on your resources without long-term access) ::: ### Slide 12: ![Slide 12](slide_12.png) ::: Notes Federation lets you extend identity management beyond IAM by connecting to external identity providers — reducing the credential management burden, but introducing a dependency on the external IdP's security posture. If your corporate directory is compromised, federated access to AWS is also at risk. Consider where your actual identity perimeter sits when designing federation, and how you would respond if the IdP were unavailable or breached. #### Instructor notes #### Student notes **Federated users** : *Federated users* are users (or applications) who do not have AWS accounts. By assigning roles, you can grant them access to your AWS resources for a limited time. This is useful if you have non-AWS users whom you can authenticate with an external service. Examples of external services include Active Directory Federation Service (AD FS), OpenLDAP, and Open Directory. The temporary AWS credentials used with the roles provide identity federation between AWS and your non-AWS users in your corporate identity and authorization system. * **IdPs** : An identity provider (IdP) is an alternative to creating IAM users in your AWS account. By using an IdP, you can manage identities outside of AWS. This is useful if your company has its own identity system, such as a corporate user directory (for example, Active Directory). **Supported federation types:** AWS supports identity federation using SAML 2.0 or with OpenID Connect (OIDC). Using SAML, you can configure your AWS accounts to integrate with your IdP. When configured, your federated users are authenticated and authorized by your organization's IdP. **What you can do:** You can give these external identities, or federated users, permissions to use AWS resources in your account. Federated user access also supports access through AWS CLI or AWS APIs. For more information, see Enabling SAML for Your AWS Resources at https://aws.amazon.com/identity/saml. ::: ### Slide 13: ![Slide 13](slide_13.png) ::: Notes Authorization is distinct from authentication: a user can be perfectly verified yet should have no access to a given resource. The default-deny model in IAM means every permission must be explicitly granted, which is the right starting point — but it also means that managing authorization requires ongoing attention as users, roles, and resources change over time. #### Instructor notes #### Student notes *Authorization* determines which actions an IAM principal can perform in an AWS account. ::: ### Slide 14: ![Slide 14](slide_14.png) ::: Notes IAM's default-deny model means that every access must be explicitly granted — a sound security foundation, but one that requires discipline to maintain. Granting too much access is easy and creates risk; recovering from a breach caused by over-permissioned credentials is much harder. Starting minimal and expanding is more secure than starting broad and attempting to restrict later. #### Instructor notes #### Student notes By default, you must grant a new user or group permissions to use AWS services. **Principle of least privilege** : Grant users or groups permissions that follow the principle of least privilege or grant only the permissions required to perform a task. When you adhere to this *best practice*, you gain the following benefits: * Resources are more secure than starting with permissions that are too lenient and then trying to tighten them later. * You can start with a minimum set of permissions and grant additional permissions, as necessary. ::: ### Slide 15: ![Slide 15](slide_15.png) ::: Notes Groups simplify permissions by applying policies to users with similar roles, but they introduce a maintenance dependency: group membership must be kept accurate. A user in the wrong group has the wrong permissions, and groups that grow organically without regular review tend to accumulate members who have moved on to different responsibilities. Groups also cannot be nested, which limits how precisely they can model complex organizational structures. #### Instructor notes #### Student notes A group is a collection of IAM users. Instead of defining permissions for individual IAM users, it's more convenient to create groups that relate to job functions (administrators, developers, accounting, and so on). For example, you could have a group called Developers and give that group the types of permissions that developers typically need. Any user in that group automatically has the permissions that are assigned to the group. **Group management benefits:** If a new user joins your company and should have developer permissions, you can assign the appropriate permissions by adding the user to that group. Similarly, if a person changes jobs in your company, instead of editing that user's permissions, you can remove the individual from the earlier group and add them to the new group. **Characteristics of groups:** * A group can contain many users, and a user can belong to multiple groups * Groups cannot be nested; they can contain only users, not other groups * No default group exists that automatically includes all users in the AWS account (you must create it manually) * A group is not truly an identity in IAM because it cannot be identified as a principal in a permissions policy; it is simply a way to attach policies to multiple users at one time For more information, see "IAM User Groups" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html. ::: ### Slide 16: ![Slide 16](slide_16.png) ::: Notes Least-privilege permissions are the goal, but getting there requires iteration — you often don't know exactly what permissions a task requires until you test it. Starting too restrictive creates friction and breaks workflows; starting too permissive creates risk that accumulates over time. The discipline is in narrowing permissions after initial access is established, which requires tooling, review processes, and organizational commitment to actually do. #### Instructor notes #### Student notes When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks. **Consider both action and resource:** The task is a request to carry out actions or operations on a resource. When defining permissions, explicitly identify both: * **Action:** What operation the principal is allowed to perform (e.g., read, write, delete) * **Resource:** What resource(s) the action applies to (e.g., specific S3 bucket, EC2 instance) **Examples:** * The first example illustrates that a principal can be granted access to specific resources * The second example illustrates that a principal can be granted permissions to perform a specific action or operation **Progressive permission approach:** Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. ::: ### Slide 17: ![Slide 17](slide_17.png) ::: Notes This example illustrates how action and resource constraints combine in a single policy. Both elements matter: allowing an action on all resources (*) is very different from allowing it on a specific ARN, even if the action itself seems narrow. Ask students to consider what would change if the resource element used a wildcard — and whether they've seen policies like that in practice. #### Instructor notes #### Student notes When you create IAM policies, follow the standard security advice of granting *least privilege*, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks. The task is a request to carry out actions or operations on a resource. Consider both the action and the resource. This example illustrates a principal is granted permissions to perform a specific action and granted access to specific resources. ::: ### Slide 18: ![Slide 18](slide_18.png) ::: Notes AWS supports multiple policy types that interact in ways that aren't always obvious. Identity-based policies, resource-based policies, SCPs, and RCPs each apply at different scopes and function as grants or filters — and they can combine in ways that produce unexpected effective permissions. Understanding how these policy types interact is essential for designing access controls that actually behave as intended, not just as written. #### Instructor notes #### Student notes A policy is an entity in AWS that, when attached to an identity or resource, defines their permissions. AWS evaluates these policies when a principal, such as a user, makes a request. **Policy types** (listed in order of frequency): * **Identity-based policies:** Attach managed and inline policies to IAM identities (users, groups to which users belong, and roles) * **Resource-based policies:** Attach inline policies to resources. The most common examples are Amazon S3 bucket policies and IAM role trust policies * **Organizations SCPs:** Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU) * **Resource control policies (RCPs):** Centrally define the maximum available permissions for resources across your organization's member accounts. RCPs act as a permissions guardrail on resources, restricting what any identity (including those outside your organization) can do with those resources **Key difference - RCPs vs SCPs:** Unlike SCPs, which restrict IAM principal permissions, RCPs restrict access to resources themselves. RCPs do not grant permissions; you still use identity-based or resource-based policies to grant access. ::: ### Slide 19: ![Slide 19](slide_19.png) ::: Notes JSON policy documents define permissions through structured elements that work together in ways that require careful attention. The Effect, Action, and Resource elements interact — an 'Allow' on a specific action means little if the Resource element is a wildcard. Understanding how conditions modify evaluation, and how optional elements like Principal behave when included or omitted, matters because a subtle misunderstanding of ARN patterns or wildcards can silently create unintended access. #### Instructor notes #### Student notes A JSON policy document includes the following elements: * **Effect:** Use Allow or Deny to indicate whether the policy allows or denies access * **Principal:** (Required only in some circumstances) If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you want to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element; the principal is implied as that user or role * **Action:** Include a list of actions that the policy allows or denies * **Resource:** (Required only in some circumstances) If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, the resource to which the action applies is the resource to which the policy is attached * **Condition:** Specify the circumstances under which the policy grants permission For more information, see "Policies and Permissions in IAM" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html. ::: ### Slide 20: ![Slide 20](slide_20.png) ::: Notes Policy generators and Access Analyzer reduce the burden of policy authoring, but they don't replace judgment. A policy generated from observed activity captures what was used — not necessarily what should be allowed — and it requires human review before deployment. Tools help, but the decision about what access is appropriate remains a human responsibility that can't be automated away. #### Instructor notes #### Student notes You can use tools like *AWS Policy Generator* as an aid to craft IAM policies for the entities in your account. To access AWS Policy Generator, see https://awspolicygen.s3.amazonaws.com/policygen.html. The AWS Policy Generator process has three steps: 1. **Select the type of policy** : Your options include Amazon SQS queue policy, Amazon S3 bucket policy, VPC endpoint policy, IAM policy, and Amazon SNS topic policy. 2. **Add a statement** : A statement is a formal description of a single permission. The IAM policy requires Effect (Allow or Deny), AWS Service, Action, and Amazon Resource Name (ARN). 3. **Generate the policy** : You will find the Generate Policy button below the statements that you added. You can also use the *IAM Access Analyzer*. It reviews your account activity and generates a policy template containing the permissions a specific entity used during a specified date range. For more information, see "IAM Access Analyzer Policy Generation" at https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html. ::: ### Slide 21: ![Slide 21](slide_21.png) ::: Notes PassRole is an often-overlooked permission that governs which users can assign roles to AWS services. Without this constraint, a user could configure a service with a role that grants more permissions than the user themselves has — a classic privilege escalation path. Properly constraining PassRole is part of a complete IAM security model, not an optional refinement. #### Instructor notes #### Student notes To pass a role and its permissions to an AWS service, the user must have permissions to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. **Granting PassRole permission:** To allow the user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group. For more information, see "Granting a User Permissions to Pass a Role to an AWS Service" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html. ::: ### Slide 22: ![Slide 22](slide_22.png) ::: Notes Condition elements add context to policy decisions, allowing access to be scoped by time, IP address, MFA status, and other attributes. This example shows temporal constraints, which are useful for limiting access to a specific engagement window. Conditions can be combined, and the logical AND behavior between multiple keys can produce unexpected results — test carefully whenever combining multiple condition operators in the same policy statement. #### Instructor notes #### Student notes This example shows a policy that allows access to an action only within a specific date and time. This policy restricts access to actions that occur between April 1, 2025 and June 30, 2025 (UTC), inclusive. ::: ### Slide 23: ![Slide 23](slide_23.png) ::: Notes This example restricts access to specific IP ranges — a useful control for limiting access to known network locations, but one with real limitations. VPNs, NAT gateways, and AWS service-to-service calls can all affect the apparent source IP in ways that produce unexpected denials. The `aws:ViaAWSService` condition handles one common case, but the logic requires careful review to avoid blocking legitimate automated workflows. #### Instructor notes #### Student notes This example shows a policy that denies access to all AWS actions in the account when the request comes from principals outside of the specified IP range. The policy is useful when the IP addresses for your company are within the specified ranges. **Important considerations with negative conditions:** Be careful using negative conditions in the same policy statement as "Effect": "Deny". When you do, the actions specified in the policy statement are explicitly denied in all conditions except for the ones specified. Additionally, this policy includes multiple condition keys that result in a logical AND. All AWS actions are denied when the source IP address is not in the specified range AND when an AWS service does not make the call. **Using Boolean condition operators:** Use Boolean condition operators to construct condition elements that restrict access by comparing the condition key to true or false. Use the `aws:ViaAWSService` condition key to allow or deny access when any AWS service makes a request to another service. For more information about this example, see "AWS: Denies Access to AWS Based on the Source IP" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html. ::: ### Slide 24: ![Slide 24](slide_24.png) ::: Notes This example uses a naming prefix to constrain which roles can be passed to a service — a common governance pattern. However, naming conventions as security controls are only effective if role creation is also governed; if users can create roles with arbitrary names, the prefix restriction provides limited real protection. Consider how this pattern fits into a broader strategy for role lifecycle management. #### Instructor notes #### Student notes This example shows a policy that allows passing any IAM service role within `` that begins with "RDS-". AWS resources typically need explicit permission to interact with other AWS services. Create roles to assign permissions to resources. To assign roles to resources, users need explicit IAM:PassRole permissions. For more information about this example, review "IAM: Pass an IAM Role to a Specific AWS Service" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html. ::: ### Slide 25: ![Slide 25](slide_25.png) ::: Notes IAM's evaluation order — explicit deny first, then explicit allow, then implicit deny — is deterministic but often counterintuitive. A common mistake is assuming that an explicit allow somewhere overrides an explicit deny elsewhere; it does not. Understanding this evaluation logic is critical when combining identity-based and resource-based policies, where the interaction between policies can produce access decisions that don't match either policy in isolation. #### Instructor notes #### Student notes When determining whether permission is allowed, IAM first checks for an explicit denial policy. If one does not exist, it then checks for an explicit allow policy. If no explicit deny or explicit allow policy exists, IAM reverts to the default: implicit deny. An explicit deny overrides any allows. For more information, see "Policy Evaluation Logic" in the AWS Identity and Access Management User Guide at http://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_EvaluationLogic.html. ::: ### Slide 26: ![Slide 26](slide_26.png) ::: Notes IAM evaluates every request against all applicable policies in a defined order, and the request context — action, resource, principal, and account — determines which policies apply. Cross-account access introduces an additional requirement: both accounts must allow the action, which is a frequent source of access issues. Walking through this model helps students understand why a permission that 'should work' sometimes doesn't. #### Instructor notes #### Student notes Let's review how IAM grants access. **AWS resources and request components:** AWS is composed of collections of resources, such as IAM users and S3 buckets. When you use the AWS API, the AWS CLI, or the AWS Management Console to send a request to take an action, your request specifies: * **Action:** What operation you want to perform (e.g., running an instance, creating a role, creating an S3 bucket) * **Resource:** What resource(s) the action applies to * **Principal:** Who is making the request (group, user, or role) * **Principal account:** Which AWS account the principal belongs to * **Request information:** Any additional details needed to process the request **Authentication and authorization checks:** IAM then checks whether you (the principal) are authenticated (signed in) and authorized (have permission) to perform the specified action on the specified resource. During authorization, IAM checks all the policies attached to your user or role and the policies attached to the resource that you are trying to access. These checks are based on the context of your request. AWS authorizes the request only if each part of your request is allowed by the policies. By default, all requests are denied. An explicit allow overrides this default, and an explicit deny overrides any allows. **Identity-based policies compared to resource-based policies:** When you provide permissions using an identity-based policy in IAM, you provide permissions to access resources only within the same account. If you make a request in a different account, the resource in that account must have an attached resource-based policy that allows access from your account. Otherwise, you must assume a role within that account with the necessary permissions. For more information, see "Policy Evaluation Logic" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html. ::: ### Slide 27: ![Slide 27](slide_27.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 28: ![Slide 28](slide_28.png) ::: Notes AWS managed policies provide a quick starting point for common permission sets, but they're designed for broad applicability — not your specific environment. Using them as-is often grants more access than necessary. They're most useful for understanding what permissions a task requires or for getting started quickly; the path to least privilege means replacing them with narrower custom policies tailored to your actual use cases. #### Instructor notes #### Student notes Providing your employees with only the permissions they need requires time and detailed knowledge of IAM policies. Employees need time to learn which AWS services they want or need to use. Administrators need time to learn about and test IAM. **Getting started quickly:** To get started quickly, you can use AWS managed policies to give your employees the permissions they need. These policies are already available in your account and are maintained and updated by AWS. These managed policies are read-only. If a managed policy grants more access than your team needs, use it as a reference. **Refining toward least privilege:** Create a custom policy that grants only the permissions required for specific tasks. As you learn how your teams use AWS, review which permissions are used and which are not. Replace broad managed policies with narrower custom policies tailored to your environment. **Best practice:** Start here. Refine toward least privilege as you go. For more information, see "Get Started with AWS Managed Policies and Move toward Least-Privilege Permissions" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies. ::: ### Slide 29: ![Slide 29](slide_29.png) ::: Notes MFA significantly reduces credential compromise risk, but its strength depends on the factor type and how it's enforced. SMS-based MFA is more convenient but less secure than hardware tokens; software authenticators fall in between. More importantly, MFA protects console access — access keys used for programmatic calls bypass console MFA entirely. Ask students: if an attacker obtains an access key, how does MFA help? #### Instructor notes #### Student notes Password security can be compromised by social engineering or by malware such as a keystroke logger. To provide an additional level of account security, enable multi-factor authentication (MFA). With MFA, users must supply both a password and a one-time challenge or response token. **MFA token generation options:** * **Software:** Software applications, such as the AWS virtual MFA (Android) and Google Authenticator (iPhone and Android), can generate a token from a smartphone or tablet * **Hardware:** AWS supports hardware devices provided by third-party vendors, such as Gemalto or Yubico. Physical token generators provide an additional level of security over software devices because they are easier to secure against unauthorized use * **SMS message:** AWS supports SMS MFA, which is an easy-to-use option for MFA that works on all devices that can receive a text message. You do not need to download any applications or have a hardware device. This option provides more flexibility because you retain access to your AWS account, even if you change, upgrade, or lose your phone **MFA best practices:** You can synchronize your virtual or hardware token devices with your AWS or IAM account. Safeguard your MFA token generators. If you lose a physical token or delete a software generator (for example, as part of a device wipe), you must provide proof of identity to AWS before we disable MFA on your account. For more information, see "Multi-Factor Authentication (MFA) for IAM" on the AWS Products website at http://aws.amazon.com/iam/details/mfa. ::: ### Slide 30: ![Slide 30](slide_30.png) ::: Notes Regular credential rotation limits the exposure window if credentials are compromised without your knowledge, but rotation alone isn't sufficient — it must be paired with monitoring for unusual usage. Automated rotation is more reliable than manual processes, but it requires that applications handle credential changes gracefully. Consider: what happens to a running application when the access key it's using is rotated mid-operation? #### Instructor notes #### Student notes Change your own passwords and access keys regularly. Make sure that all IAM users in your account also change them. That way, if a password or access key is compromised without your knowledge, you limit how long the credentials can be used to access your resources. **Implementing password rotation policies:** You can apply a password policy to your account to require all your IAM users to rotate their passwords. You can also choose how often they must do so. **Monitoring access key rotation:** AWS Config has a managed rule that checks whether the active access keys are rotated within the number of days that you specify. AWS Config labels the access keys past the threshold as NON_COMPLIANT. For more information, review the following: "Access-Keys-Rotated" in the AWS Config Developer Guide at https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html. ::: ### Slide 31: ![Slide 31](slide_31.png) ::: Notes Visibility tools like the credential report and IAM Access Analyzer tell you who has access and how credentials are being used — but visibility only provides value if someone acts on the findings. Having the tooling without the review process and follow-up procedures leaves you with data you're not using. Consider: how often would your team actually review these reports, and who would act on findings? #### Instructor notes Two key resources for providing more visibility over IAM and access are the credential report and IAM Access Analyzer, located within the IAM console dashboard. ::: ### Slide 32: ![Slide 32](slide_32.png) ::: Notes Unused credentials represent attack surface that provides no benefit. IAM users with passwords they never use, access keys that haven't been rotated, and MFA devices that aren't configured are all unnecessary risk. Identifying and removing them is conceptually simple but organizationally difficult — it requires coordination and sometimes uncomfortable conversations about whether users still need the access they were originally granted. #### Instructor notes #### Student notes Remove IAM user credentials, such as passwords and access keys, that are not needed. **When to remove credentials:** * If you created an IAM user for an application that does not use the console, the IAM user does not need a password * If a user only uses the console, remove their access keys * Passwords and access keys that have not been used recently might be good candidates for removal **Using the credential report:** You can download a credential report that lists users in your account and the status of their various credentials, including passwords, access keys, and MFA devices. You can generate a credential report from the AWS Management Console, the AWS SDK and AWS CLI tools, or the IAM API. ::: ### Slide 33: ![Slide 33](slide_33.png) ::: Notes The credential report provides a snapshot of every user's credential state, but what's most interesting is often what hasn't happened — credentials that were created and never used, or keys that haven't been rotated in months. These patterns may indicate accounts created but never activated, or users who found alternative access paths. Regular review of this report surfaces access patterns that deserve investigation. #### Instructor notes #### Student notes Password_last_used: The date and time when the AWS account root user or IAM user's password was last used to sign in to an AWS website. AWS websites that capture a user's last sign-in time are the AWS Management Console, the AWS Discussion Forums, and the AWS Marketplace. Access_key_1_last_used_date: The date and time when the user's access key was most recently used to sign an AWS API request. For more information, see "Understanding the Report Format" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html#id_credentials_understanding_the_report_format. ::: ### Slide 34: ![Slide 34](slide_34.png) ::: Notes IAM Access Analyzer uses automated reasoning to identify resource policies that grant access to external principals — entities outside your account or organization. The key distinction is between intentional external access and unintended exposure: both look the same to the tool. The 24-hour analysis cycle means newly created policies may not be flagged immediately, so Access Analyzer works best as part of a regular review cadence rather than a real-time control. #### Instructor notes IAM Access Analyzer informs you which resources in your account you are sharing with external principals. It does this by using logic-based reasoning to analyze resource-based policies in your AWS environment. **How IAM Access Analyzer works:** * When you turn on IAM Access Analyzer, you create an analyzer for your account. Your account is the zone of trust for the analyzer * The analyzer monitors all the supported resources within your zone of trust. Any access to resources by principals that are within your zone of trust is considered trusted * IAM Access Analyzer analyzes the policies applied to all the supported resources in your account. After the first analysis, it analyzes these policies once every 24 hours * Supported resources include S3 buckets, AWS KMS keys, IAM roles, AWS Lambda functions and layers, and Amazon SQS queues **Finding external access:** When analyzing the policies, if IAM Access Analyzer identifies one that grants access to an external principal that isn't within your zone of trust, it generates a finding. Each finding includes details about the resource, the external entity that has access to it, and the permissions granted so that you can take appropriate action. **Technology behind IAM Access Analyzer:** IAM Access Analyzer is built on Zelkova, which translates IAM policies into equivalent logical statements and runs a suite of general-purpose and specialized logical solvers. IAM Access Analyzer applies Zelkova repeatedly to a policy with increasingly specific queries to characterize classes of behaviors that the policy allows. IAM Access Analyzer considers only certain IAM condition keys that external users cannot directly influence or that are otherwise impactful to authorization. For more information about Zelkova, see "How AWS Uses Automated Reasoning to Help You Achieve Security at Scale" in the AWS Security Blog at https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova. ::: ### Slide 35: ![Slide 35](slide_35.png) ::: Notes The policy simulator lets you test effective permissions before deploying changes — especially valuable for understanding how multiple overlapping policies interact. However, the simulator evaluates policies against the documented logic, not the full complexity of real-world request context. Condition keys that depend on runtime values, dynamic variables, or service-specific behaviors may not be fully reflected. Use simulation as a validation step, not a guarantee. #### Instructor notes #### Student notes With the IAM policy simulator, you can test and troubleshoot identity-based policies, IAM permissions boundaries, Organizations SCPs, and resource-based policies. A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. Here are some common things you can do with the policy simulator: Test policies attached to IAM users, groups, or roles. Test and troubleshoot the effect of permissions boundaries. Test policies that are attached to AWS resources. Test SCPs in Organizations. Test new policies. Test the policies with selected services, actions, and resources. Identify which specific statement in a policy results in allowing or denying access to a particular resource or action. Simulate real-world scenarios by providing context keys, such as IP address or date. Context keys represent the conditions under which a request is made. The simulator uses them to evaluate condition elements in your policies. For example, if your policy denies access unless MFA is present, you can simulate a request with and without MFA to verify the policy works as intended. You can access the IAM policy simulator using AWS CLI and AWS API. For more information, review "Testing IAM policies with the IAM policy simulator" in the AWS Identity and Access Management User Guide at https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html. ::: ### Slide 36: ![Slide 36](slide_36.png) ::: Notes This recap returns to the Example Corp. scenario and the specific questions posed at the start of the module. Connecting technical IAM concepts to business questions reinforces that access management isn't just a technical exercise — it serves organizational goals around security, compliance, and operational efficiency. The answers suggest approaches, but the real challenge is implementing them consistently as the account landscape grows and requirements change. #### Instructor notes #### Student notes Let's revisit the requests that your manager at Example Corp. has asked from you. **What are best practices to distribute desired permissions across a company?** You want to first create groups for the different job functions and apply the policies with the least privilege to carry out their tasks. Then, add the necessary IAM users to those groups. **How do you determine the level of access you grant?** When possible, use IAM roles to grant access to your resources. This lessens the burden of managing credentials. Use both resource-based policies and identity-based policies. ::: ### Slide 37: ![Slide 37](slide_37.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 38: ![Slide 38](slide_38.png) ::: Notes AWS resources are the entities you manage in the cloud, and each is uniquely identified by an ARN that encodes its account, region, service, and specific identifier. ARNs matter for IAM because they are the mechanism for specifying exactly which resources a policy applies to. The difference between a precise ARN and a wildcard in a policy can be the difference between a scoped permission and one that applies to all resources of that type in the account. #### Instructor notes #### Student notes An AWS resource is an entity you can work with in AWS. Examples of AWS resources include the following: * EC2 instance * Amazon Elastic Block Store (Amazon EBS) volume * Amazon Relational Database Service (Amazon RDS) * Security group * Amazon Virtual Private Cloud (Amazon VPC) Resources created in AWS are each uniquely identified with an ARN. ::: ### Slide 39: ![Slide 39](slide_39.png) ::: Notes An AWS account is both a security boundary and a billing boundary — resources in one account cannot access resources in another without explicit cross-account permissions. This isolation is a deliberate design choice, not a limitation. Multi-account architectures use this isolation intentionally to contain the blast radius of a compromise, separate production from development, and apply different governance policies to different workloads. #### Instructor notes #### Student notes An AWS account is a collection of resources that you provision and control. ::: ### Slide 40: ![Slide 40](slide_40.png) ::: Notes Organizations solves the management challenge of multiple accounts, but it introduces centralization that requires careful design. The account structure you create reflects organizational assumptions — about team boundaries, compliance requirements, and trust relationships — that may change over time. Consider how your OU hierarchy maps to your actual governance requirements, and how hard it would be to reorganize later if those requirements evolve. #### Instructor notes #### Student notes Many companies provision multiple AWS accounts, such as individual accounts for various business units or separate accounts for their development, test, and production environments. With AWS Organizations, an account management service, you can consolidate multiple AWS accounts into an organization you create and centrally manage. ::: ### Slide 41: ![Slide 41](slide_41.png) ::: Notes AWS Organizations provides powerful centralized management capabilities, but each feature involves trade-offs. SCPs restrict what accounts can do — and a poorly designed SCP applied at the root can break operations across the entire organization. Centralized billing improves visibility but requires governance over spending authority. Before enabling any Organizations feature, consider the impact of getting it wrong and how you would recover. #### Instructor notes #### Student notes An organization is an entity that you create to consolidate, centrally view, and manage all your AWS accounts. In AWS Organizations, you enable a feature set that determines the functionality of an organization. **AWS Organizations features:** * **Centrally manage policies across multiple AWS accounts:** Use the service to create groups of accounts. To make sure that the correct policies are applied across the account, attach policies to a group * **Group-based account management:** Using Organizations, you can create groups of AWS accounts and then apply different policies to each group * **Policy-based access to AWS services:** With Organizations, you can create SCPs that centrally control AWS service use across multiple AWS accounts. SCPs put bounds around the permissions that IAM policies can grant to entities in an account, such as IAM users and roles. Entities can use only the services allowed by both the SCP and the IAM policy for the account * **Automate AWS account creation and management:** Use Organizations APIs to create new accounts and add them to a group. The policies attached to the group are automatically applied to the new account * **Consolidate billing across multiple AWS accounts:** With Organizations, you can set up a single payment method for all the AWS accounts in your company through consolidated billing. With consolidated billing, you can examine a combined view of charges incurred by all your accounts * **API-level control of AWS services:** With Organizations, you can use SCPs to manage the use of AWS services at an API level * **Centrally enable auditing:** With Organizations, you can centrally enable auditing using AWS CloudTrail. CloudTrail is a web service that records activity made on your account and delivers log files ::: ### Slide 42: ![Slide 42](slide_42.png) ::: Notes The hierarchical structure of Organizations — root, OUs, and accounts — determines where policies apply and how broadly they affect the environment. Policies attached higher in the hierarchy affect more accounts, which provides efficiency but also amplifies the impact of mistakes. Ask students to think about how they would design an OU structure for Example Corp. and what trade-offs different approaches would involve. #### Instructor notes #### Student notes The diagram shows a basic organization that consists of six accounts that are organized into four OUs under the root. The first OU has two nested OUs. One of the nested OUs has two accounts, and the other has one account. The fourth OU has three accounts. The organization also has several policies that are attached to some of the OUs or directly to accounts. **Key terminology:** * **Management account or root:** The parent container for all the accounts for your organization. An organization has one account designated as the management account. The rest of the accounts that belong to an organization are called member accounts * **OU:** A container for accounts within a root. An OU also can contain other OUs * **Account:** A standard AWS account that contains your AWS resources. You can attach a policy to an account to apply controls to only that one account. An account can be a member of only one organization at a time * **SCP:** A policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are similar to IAM permissions policies except that they do not grant permissions. Instead, SCPs are filters that allow only the specified services and actions in affected accounts. SCP blocks any access that is not explicitly allowed or that is explicitly denied by the SCP. This applies even if a user has full administrator permissions with an IAM permissions policy. For example, if you assign an SCP that allows only database service access to your database account, any user, group, or role in that account is denied access to any other service's operations ::: ### Slide 43: ![Slide 43](slide_43.png) ::: Notes This SCP demonstrates how Organizations can prevent even administrators in member accounts from modifying a centrally managed IAM role — preserving a role the management account relies on for control. This illustrates a key security pattern: certain roles must be protected from account-level modification. The trade-off is that it reduces account administrators' autonomy, which requires organizational buy-in and clear documentation of why the restriction exists. #### Instructor notes #### Student notes Prevent IAM users and roles from making certain changes. This SCP restricts IAM users and roles from making changes to the specified IAM role that you created in all accounts in your organization. ::: ### Slide 44: ![Slide 44](slide_44.png) ::: Notes This SCP enforces MFA for a specific API action across all accounts in the organization. The benefit is consistent enforcement without relying on each account administrator. The challenge is that programmatic access performing this action must also satisfy the MFA requirement — which may not be straightforward for automated workflows. Consider: which actions in your environment are high-risk enough to warrant mandatory MFA? #### Instructor notes #### Student notes Require MFA to perform an API action. Use an SCP, such as the one in the example, to require that MFA is enabled before an IAM user or role can perform an action. In this example, the action is to stop an Amazon EC2 instance. ::: ### Slide 45: ![Slide 45](slide_45.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 46: ![Slide 46](slide_46.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 47: ![Slide 47](slide_47.png) ::: Notes #### Instructor notes #### Student notes :::