Wednesday, May 6, 2026

Cohort 3 | Project CloudIgnite Topics: Identity Management, IAM, Malware & Intrusion Detection Duration: ~3 hours

Key Takeaways

• SSO: log in once, access multiple services; central server issues tokens per service
• Federated users: external identity provider grants temporary access; no permanent AWS account needed
• JWT tokens: encoded user info; always set expiry; refresh tokens extend sessions automatically
• IAM: free, global service; Users, Groups (cannot nest), Roles (temporary delegated access), Policies (JSON)
• Policy evaluation: Explicit Deny > Explicit Allow > Implicit DenY
• Never store credentials inside EC2 — use IAM Roles instead
• Lab 279: Explored IAM users, groups, permissions — tested granular access control
• Malware types: virus, worm, bot, trojan, rootkit, spyware, adware, ransomware
• IDS: signature-based vs anomaly-based; GuardDuty is AWS's managed AI-powered threat detection

Table of Contents

1. Single Sign-On (SSO)
2. Federated Users & Identity Federation
3. JWT Tokens & Token Security
4. Amazon Cognito
5. AWS IAM – Identity and Access Management
6. IAM Policies
7. IAM Lab Summary (Lab 279)
8. Malware & Threats
9. Intrusion Detection Systems (IDS)
10. Amazon GuardDuty
11. Knowledge Check Answers
12. CLF-C02 Exam Relevance

1. Single Sign-On (SSO)

What it is: Log in once, access multiple services without logging in again.

Real-world example: Google ecosystem — log into Gmail once, and you can access YouTube, Google Drive, Google Docs, Play Store, etc. without re-authenticating.

How it works:

• A central authentication server issues a master identity (stored in a cookie/session).
• When you visit another service, your identity is used to request a service-specific token.
• Each service gets its own token — tokens are NOT shared across services.
• AWS SSO works the same way: one login, multiple AWS services, each generating its own access token.

Key point: SSO uses a central server to issue tokens, not shared credentials.

2. Federated Users & Identity Federation

What it is: An external user (not a native user of a system) who is granted access by leveraging a trusted third-party identity provider.

How it works:

• AWS trusts an external identity provider (e.g., Google, or your own website).
• The external provider authenticates the user and issues a short-lived, temporary access token.
• That token is used to access specific AWS resources — no permanent AWS account needed.

Real-world example:

You have videos in an S3 bucket. You want only paying subscribers on your website to view them. Instead of creating IAM accounts for thousands of users, you establish trust between your website and AWS. Your website authenticates users and generates a temporary token so they can access S3 — without ever having an AWS account.

Federated identity vs. OAuth:

• OAuth typically creates an account on the target website (e.g., "Sign in with Google" to create a Shopee account) → user becomes a permanent user.
• Federated user → gets temporary access only; no account is created in the target system.

Federated users are a form of SSO — authentication is handled by a trusted central/external authority.

3. JWT Tokens & Token Security

JWT (JSON Web Token): The most widely used token format for authentication today.

What's inside a JWT:

• Encoded (and encrypted) user information: user ID, email, name, etc.
• Backend server decrypts and reads the token to identify the user.
• Tokens are unique per user — not random strings.

Token lifecycle:

• After login (authentication), a token is issued.
• The token has an expiry date (e.g., 24 hours, 7 days).
• Refresh tokens automatically issue a new token before expiry — so you stay logged in without re-authenticating.
• Tokens should never be permanent — if stolen, a permanent token gives indefinite access.

Security risk:

If someone extracts your JWT from browser cookies/session storage, they can use it to access your account via code (Python, bash, etc.) — no password needed.

Best practice: Always set token expiry. Use refresh tokens. Never make tokens permanent.

4. Amazon Cognito

What it is: AWS-managed service for user authentication and authorization, designed for web and mobile applications.

Use case: Add sign-up/sign-in (username + password or email + password) to your app without building auth from scratch.

5. AWS IAM – Identity and Access Management

What it is: A free, global AWS service to centrally manage users, groups, roles, and permissions across AWS.

Key Concepts

Root Account Best Practices

• Do not use root for everyday tasks.
• Use root only to create the first admin IAM user.
• Use the admin IAM user to create all other users.
• Enable MFA on root account.

IAM is Global

• IAM is not region-specific — it applies across all AWS regions.
• Contrast with: EC2, VPC — these are regional services.

MFA (Multi-Factor Authentication)

• Adds an extra layer of security on top of username/password.
• Recommended especially for admin-level users.
• Authenticator apps are the most common MFA method.

IAM Groups

• Apply a policy once to a group → all users in the group inherit those permissions.
• One user can belong to multiple groups.
• Groups cannot be nested (a group cannot be a member of another group).
• Only users can be members of a group.

IAM Roles

• Provides temporary, delegated access — like borrowing a key card.
• No username/password stored — much safer.
• Common use case: An EC2 instance needs to access S3. Instead of storing credentials inside EC2 (bad practice), attach an IAM role that grants S3 access.
• Roles can also be used for federated users — external users assume a role to access AWS resources temporarily.

Analogy: A role is like wearing a hat. While wearing the system admin hat, you can access the server room. Take it off, and access is revoked.

6. IAM Policies

Format: Written in JSON.

Two types:

• Identity-based policy — attached to a user, group, or role. Defines what resources that identity can access.
• Resource-based policy — attached to a resource (e.g., S3 bucket). Defines who can access that resource.

Analogy: Identity policy = ID card that says you can enter. Resource policy = the security guard at the door who can still deny you.

Permission evaluation order (important!):

1. Check for explicit DENY → if found, deny immediately.
2. Check for explicit ALLOW → if found, allow.
3. Otherwise → implicit DENY (deny by default).

Explicit deny always wins, even if an allow also exists.

Policy Structure (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:*", "s3:*"],
      "Resource": ["arn:aws:dynamodb:...", "arn:aws:s3:::bucket-name"]
    },
    {
      "Effect": "Deny",
      "NotResource": ["arn:aws:dynamodb:...", "arn:aws:s3:::bucket-name"],
      "Action": "*"
    }
  ]
}

• Action: "*" — all actions
• Resource: "*" — all resources
• NotResource — apply this rule to everything except the listed resources (i.e., exclude from deny)

Best practice: Apply policies to groups, not individual users.

7. IAM Lab Summary (Lab 279)

Objective: Explore IAM users, groups, and permissions hands-on.

What was done:

Task 1 – Password Policy

• Set minimum password length to 10 characters.
• Required: uppercase, lowercase, number, special character.
• Password expiry: 90 days.

Task 2 – Explore Users & Groups

• 3 users: user-1, user-2, user-3
• 3 groups: S3Support, EC2Support, EC2Admin
• Reviewed JSON policies attached to each group:
  • S3Support → can view/list S3 objects only (no upload)
  • EC2Support → can view/describe EC2 instances (no start/stop)
  • EC2Admin → can start and stop EC2 instances

Task 3 – Assign Users to Groups

• user-1 → S3Support
• user-2 → EC2Support
• user-3 → EC2Admin

Task 4 – Test Permissions

• Logged in as each user via IAM sign-in URL (incognito window).
• user-1: Could view S3 bucket, could NOT upload (permission denied).
• user-2: Could view EC2, could NOT stop instance (not authorized).
• user-3: Could successfully stop EC2 instance.
• Demonstrated adding user-1 to EC2Admin group to show multi-group membership.

Key takeaway: IAM enables granular permission control — each user/group gets only the access they need (principle of least privilege).

8. Malware & Threats

Malware = Malicious software designed to harm systems — affects Confidentiality, Integrity, and Availability (CIA).

Types of Malware

Common Infection Methods

• Untrusted websites (drive-by downloads, deceptive buttons)
• Phishing emails with malicious links
• Infected removable devices (USB drives)
• Cracked/pirated software

Antivirus Software

• Scans for known patterns/signatures of malware.
• Not 100% effective against brand-new threats.
• Best practice: Regularly update virus definition files to detect new malware patterns.

9. Intrusion Detection Systems (IDS)

Two detection methods:

Two deployment types:

10. Amazon GuardDuty

What it is: AWS's AI-powered threat detection service — an anomaly-based IDS for your AWS account.

What it monitors:

• VPC Flow Logs
• DNS logs
• CloudTrail event logs

How it works:

• Continuously analyzes logs for unusual/suspicious activity.
• Raises findings with details: finding type, resource ID, last seen timestamp, count.
• You review findings and take action to remediate threats.

GuardDuty = managed, intelligent IDS for AWS. No infrastructure to manage.

11. Knowledge Check Answers

Identity Management KC

Detection KC

12. CLF-C02 Exam Relevance

The following topics from this lecture are directly relevant to the AWS Certified Cloud Practitioner (CLF-C02) exam:

✅ Domain 1 – Cloud Concepts

• (Minimal direct coverage in this lecture)

✅ Domain 2 – Security and Compliance (HIGH relevance — this is ~25% of the exam)

✅ Domain 3 – Cloud Technology & Services

📝 Exam Tips from this Lecture

• Never store credentials (access keys) inside EC2 instances — use IAM Roles instead. This is a classic exam scenario.
• Groups cannot contain other groups — only users. This distinction is tested.
• IAM Role vs. IAM User: Roles are temporary and assumed; users are permanent identities.
• GuardDuty uses VPC Flow Logs, DNS logs, and CloudTrail — not antivirus scan results.
• Know the AAA framework: Authentication, Authorization, Accounting.

Notes compiled from May 6, 2026 lecture transcript. Next lecture: AWS CloudTrail, AWS Config, Response, and a Firewall/Malware lab.