Securing Your AWS Resources

Lesson purpose

Every AWS role carries some security responsibility. This lesson answers three questions students will face on every deployment: who is allowed in (authentication), what they may do once inside (authorization), and how data stays private at rest and in transit. It closes with where to find proof of AWS compliance and which AWS services detect, investigate, and report security problems. It supports CLF-C02 Domain 2, objectives 2.2 (security, governance, and compliance concepts) and 2.3 (access management capabilities).

Learning objectives

• Explain why the root user must be locked down and what protecting it involves.
• Distinguish passwords, MFA, access keys, and SSH key pairs and when each is used.
• Create and justify an IAM password policy.
• Compare IAM users, groups, and roles, and apply the principle of least privilege.
• Describe federated access with SAML 2.0, Active Directory, and IAM Identity Center.
• Use the IAM credential report to audit account security.
• Explain how AWS KMS manages encryption keys and how server-side and client-side encryption differ.
• Use AWS Artifact to find compliance reports.
• Match AWS security services (Inspector, GuardDuty, Secrets Manager, Detective, Audit Manager, CloudHSM, RAM, Security Hub) to their jobs.

1. The IAM dashboard and the two big ideas

AWS Identity and Access Management (IAM) is the service that controls identities and permissions across an account. It is global, not tied to a Region, and there is no extra charge for it.

Frame the whole lesson around two words:

• Authentication — proving who you are (password, MFA code, access key, key pair).
• Authorization — what that proven identity is allowed to do (permissions attached through policies).

The IAM dashboard shows security recommendations, such as adding MFA to the root user and using IAM identities for daily work. Treat those recommendations as a checklist, not a warning to dismiss.

Check for understanding: A user logs in successfully but gets “Access Denied” when launching an EC2 instance. Did authentication or authorization fail? (Authorization — the login worked.)

2. Protecting the root user

The root user is the identity created with the AWS account, signed in with the account email address. It can do anything: launch resources in any Region, change billing, close the account. That unlimited power is exactly why it is dangerous for daily use. If root credentials leak, an attacker can steal or delete all data or run up huge charges (a common example is rogue cryptocurrency mining).

Best practice:

• Give the root user a long, random, unique password.
• Turn on MFA for the root user.
• Do not create access keys for the root user; delete any that exist.
• Use IAM identities for day-to-day administration and reserve root for the few tasks that truly require it (such as changing some account settings or closing the account).

3. Authentication methods

Different ways of working with AWS use different credentials. Students should be able to match each one.

Access method	Credential used
AWS Management Console (browser)	User name + password, ideally with MFA
AWS CLI, SDKs, programmatic API calls	Access key ID + secret access key
SSH into an EC2 Linux instance	Key pair (private key on the client)

Passwords and password policies

Strong passwords are long, random, and never reused. A password manager (1Password, Bitwarden, KeePass) is the practical way to manage them. For IAM users, set an account-wide password policy under IAM Account settings to enforce minimum length and character requirements.

Classroom walk-through (book Exercise 5.1):

1. In the IAM dashboard, open Account settings and edit the password policy; choose Custom.
2. Raise the minimum length (for example, from 8 to 10 or more).
3. Require at least one uppercase letter, one lowercase letter, one number, and one non-alphanumeric character.
4. Save changes.

Point out the book’s note: current security guidance (including NIST) questions forced periodic password changes, so an expiration period is usually not recommended unless a regulation requires it. Length and uniqueness matter more than frequent changes.

Multifactor authentication (MFA)

MFA adds a second factor: something you know (password) plus something you have (a device). Options include an authenticator app on a smartphone, a FIDO/U2F security key such as a YubiKey, or a hardware token. At sign-in, the user enters the password and then a short-lived code (usually six digits) or taps the security key. MFA is important for every user but critical for root.

Access keys

Programmatic and command-line access uses an access key ID and a secret access key. Create them from the Security credentials page (account menu, top right of the console).

• The secret access key is shown only once, at creation. Download it or copy it to a safe place then.
• Never share secret keys in plaintext, such as in email or chat, and never commit them to code repositories.
• The Security credentials page lists keys and lets you deactivate, activate, or delete them. Rotate keys regularly.
• AWS warns against creating root access keys, and you should follow that warning.

Modern note: AWS now steers people toward temporary credentials (IAM roles, IAM Identity Center, AWS CloudShell) instead of long-lived access keys whenever possible. Long-lived keys are the credential most often leaked.

SSH key pairs

Secure Shell (SSH) encrypts remote terminal sessions so commands and keystrokes cannot be read on the network. Encryption turns readable plaintext into unreadable ciphertext that only the holder of the correct key can decrypt.

When you launch an EC2 Linux instance, you choose an existing key pair or create one. AWS keeps the public key; you download the private key once. Key pairs can also be created from the EC2 dashboard under Key Pairs. On Linux and macOS, restrict the private key’s permissions before use, then connect:

chmod 400 keyname.pem
ssh -i keyname.pem ec2-user@<public_ip_address_of_instance>

• chmod 400 makes the private key readable only by its owner; SSH refuses keys with loose permissions.
• -i keyname.pem names the private key file (the identity).
• ec2-user is the default user on Amazon Linux; other images use different defaults (for example, ubuntu).
• The part after @ is the instance’s public IP address or DNS name.

Windows 10 and later include an SSH client, so the same command works from PowerShell.

4. Users, groups, and roles

The theme of the lesson is the principle of least privilege: give each identity only the permissions it needs for its job, and nothing more.

IAM users

An IAM user represents one person or application with long-term credentials. Book Exercise 5.2 walks through it:

1. In IAM, choose Users, then Create user; name the user (the book uses Steve).
2. Choose console access. The console will recommend IAM Identity Center; for this exercise choose to create an IAM user.
3. Set a custom password and leave require password reset checked so the user picks a new password at first sign-in.
4. Attach a policy directly — the book uses AmazonEC2FullAccess so Steve can create, launch, and terminate EC2 instances.
5. Optionally add a tag such as Unit = EC2-admin to keep track of users as the account grows.
6. Share the account-specific sign-in URL (it begins with the 12-digit account ID) with the user.

To replace root for daily administration, create an admin identity with the AdministratorAccess policy — powerful, but still safer than root because it can be limited, monitored, and removed.

IAM groups

Assigning permissions user by user becomes tedious and error-prone. A group holds permissions; users added to it inherit them. Change the group’s permissions once and every member is updated. Example groups: EC2-admins, S3-admins.

Book Exercise 5.3: create a group named S3-admins, add Steve, attach AmazonS3FullAccess, and create the group. Steve now has both EC2 and S3 permissions — his user policy plus his group policy.

Best practice for the classroom: attach permissions to groups, not individual users.

IAM roles

A role is a set of permissions that a trusted entity assumes temporarily. Unlike users and groups, roles are mostly used by applications and services rather than by people, and they provide temporary credentials instead of long-lived keys.

When you create a role, you first define the trusted entity — who may assume it:

• an AWS service (for example, an EC2 instance that needs to read from S3)
• an identity from a federated provider (Google, Amazon Cognito, a SAML provider)
• another AWS account

Then you attach the permissions policy describing what the role can do. Book example: users signed in to a mobile app with Google accounts assume a role that lets them read specific S3 data.

Key distinction to stress: an EC2 instance should get a role, never an access key stored on the server.

Identity	Who uses it	Credentials
User	One person or app	Long-term (password, access keys)
Group	Collection of users	None of its own; permission container
Role	Services, apps, federated or cross-account users	Temporary, issued when assumed

5. Federated access

Federation lets people sign in with an identity that already exists elsewhere rather than a separate IAM user.

• SAML 2.0 (Security Assertion Markup Language) — a standard for passing sign-in information between an identity provider and AWS.
• Microsoft Active Directory — a common corporate directory.
• Single sign-on (SSO) — users sign in once and reach multiple systems, including AWS accounts and applications.
• AWS IAM Identity Center — the successor to AWS Single Sign-On and the AWS-recommended way to give workforce users access across one or many AWS accounts.
• AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) — a managed AD in AWS for workloads such as SharePoint, .NET, and SQL Server.

Why it matters: fewer passwords to manage, one place to disable a departing employee, and consistent access across accounts and apps.

6. The credential report

From the IAM dashboard, Credential report offers one action: download the report. The CSV file lists every IAM user with security details such as:

• when the password was last used
• whether MFA is enabled
• whether access keys are active
• when access keys were last used and last rotated

Download it regularly to find risks: users without MFA, keys that have not been rotated, or accounts nobody uses anymore.

Classroom question: The report shows a user with an active access key last used 400 days ago. What should you do? (Confirm it is not needed, then deactivate and delete it.)

7. Encryption and AWS KMS

Encryption should protect data wherever it is stored or moved, not only during SSH sessions. AWS integrates encryption into most services.

AWS Key Management Service (KMS)

KMS creates, stores, and controls the keys that encrypt data. When you encrypt a resource with KMS, it uses a key belonging to your account. You can create keys, set who may use them, and schedule deletion from the KMS console.

Terminology note: the book and deck call these customer master keys (CMKs). AWS now simply calls them KMS keys. Students may see both terms on practice questions; they mean the same thing.

Services that can encrypt with KMS keys include RDS, DynamoDB, EBS volumes (choose encryption when the volume is created), and S3. Once encrypted, the data is unreadable without the key; AWS decrypts it automatically only for authenticated, authorized requests.

Encryption at rest in S3 (server-side)

S3 can encrypt objects at the server:

• SSE-S3 — S3 manages the keys.
• SSE-KMS — keys are managed in KMS, adding control and audit logging.

Modern note: since January 2023, S3 encrypts all new objects with SSE-S3 by default, so data at rest in S3 is always encrypted unless a different method is chosen.

Protecting data before and during upload (client-side)

Server-side encryption protects data once it lands in S3. To protect data before it leaves your systems, use client-side encryption: encrypt the data locally, using a KMS key or a key you manage yourself, and upload the already-encrypted object. The same key is then used to decrypt it when it is downloaded.

Clarify a common mix-up: data moving over the network is also protected by TLS (HTTPS), which AWS endpoints use. Client-side encryption adds protection so that the data is never readable by anyone other than the key holder, even AWS.

Approach	Who encrypts	When
Server-side (SSE-S3, SSE-KMS)	AWS	After the object arrives
Client-side	You	Before the object is uploaded

8. Regulatory compliance with AWS Artifact

Before running credit card payments, health records, or government data on AWS, an organization must confirm AWS meets the applicable standards. AWS Artifact is the self-service portal for AWS compliance reports and agreements. Each document is called an artifact.

Examples students should recognize:

• FedRAMP — U.S. government cloud security authorization.
• Government of Canada (GC) Partner Package.
• APRA — Australian Prudential Regulation Authority security risk workbook.
• PCI DSS Attestation of Compliance and Responsibility Summary — for card payment data.
• SOC 1, SOC 2, SOC 3 — Service Organization Control reports.
• Sarbanes–Oxley (SOX)-related controls.

Connect to shared responsibility: Artifact proves AWS’s side of compliance. The customer still must configure and operate its own workloads compliantly.

9. Other AWS security and compliance services

AWS Compliance programs provide tools, controls, and documentation to help customers assess and maintain compliance. The following services appear frequently on the exam; teach them by the job each one does.

Service	Job in one line
Amazon Inspector	Scans workloads for software vulnerabilities and unintended exposure, and recommends fixes.
Amazon GuardDuty	Continuously watches account activity and uses machine learning to detect threats such as compromised instances or unauthorized access.
AWS Secrets Manager	Stores and automatically rotates secrets such as database passwords and API keys.
Amazon Detective	Investigates the origin and impact of security findings after the fact, using collected log data and visualizations.
AWS Audit Manager	Automates evidence collection against prebuilt frameworks and produces audit-ready reports.
AWS CloudHSM	Provides dedicated hardware security modules for generating and storing your own cryptographic keys.
AWS Resource Access Manager (RAM)	Shares resources such as subnets, Transit Gateways, and Route 53 Resolver rules with other accounts in your organization.
AWS Security Hub	Collects findings from many security services into one dashboard and checks against best practices.

Useful contrasts:

• Inspector vs. GuardDuty — Inspector finds weaknesses before they are exploited; GuardDuty detects suspicious activity as it happens.
• GuardDuty vs. Detective — GuardDuty raises the alarm; Detective helps investigate what happened.
• KMS vs. CloudHSM — KMS is a managed, shared key service; CloudHSM gives you dedicated hardware you control.
• Secrets Manager vs. hard-coding — secrets belong in a managed store, never in source code.
• Security Hub is the “single pane of glass” that brings the others together.

Classroom application

Use a free-tier account (or the console demo) for a short, safe lab:

1. Sign in as root, confirm MFA is enabled, and check that no root access keys exist.
2. Set a custom password policy (Exercise 5.1).
3. Create an IAM user with console access and a required password reset (Exercise 5.2).
4. Create an S3-admins group, add the user, and attach an S3 policy (Exercise 5.3).
5. Sign in as the new user in a private browser window and test what they can and cannot do.
6. Download the credential report and identify one risk.
7. Clean up: remove the test user and group when finished.

Scenario prompts for discussion:

• A web app on EC2 must read files from S3. User, group, or role? (Role attached to the instance.)
• Ten new analysts need identical read-only access. (Create a group, attach the policy, add the users.)
• An auditor asks for AWS’s PCI DSS report. (AWS Artifact.)
• A database password is written in application code. (Move it to Secrets Manager.)
• The security team wants one dashboard of all findings. (Security Hub.)

Common misconceptions

• “Root is fine if the password is strong.” Root should also have MFA, no access keys, and should not be used for daily work.
• “Groups can be used to sign in.” Groups have no credentials; only users sign in and roles are assumed.
• “Roles are just another kind of user.” Roles are assumed temporarily and issue short-lived credentials; they are mainly for services, apps, and federated users.
• “Access keys are the normal way for EC2 to reach S3.” Attach a role instead; stored keys can be stolen.
• “If AWS is compliant, my application is compliant.” Artifact shows AWS’s compliance; the customer is still responsible for its own configuration.
• “Forcing password changes every 30 days makes accounts safer.” Current guidance favors long, unique passwords plus MFA over forced expiration.
• “Server-side encryption protects data before it reaches AWS.” It protects data after arrival; client-side encryption protects it before upload.
• “GuardDuty fixes problems.” GuardDuty detects; responding is up to you or automation you build.

Lesson summary

Lock down the root user with a strong password and MFA, no access keys, and minimal use. Enforce strong passwords with an IAM password policy and require MFA. Console access uses passwords, programmatic access uses an access key ID and secret access key, and EC2 Linux access uses an SSH key pair whose private key stays on the client. Apply least privilege by attaching permissions to groups and using roles for services, applications, and federated users. Federation through SAML 2.0, Active Directory, and IAM Identity Center brings existing identities into AWS. Audit users regularly with the credential report. KMS manages the keys that encrypt EBS, RDS, DynamoDB, and S3 data; server-side encryption protects data in AWS, while client-side encryption protects it before upload. AWS Artifact provides compliance reports, and services such as Inspector, GuardDuty, Secrets Manager, Detective, Audit Manager, CloudHSM, RAM, and Security Hub help detect, investigate, and prove security.