Unit 4: Authentication and Authorization — AWS (IAM); CloudTrail, CloudWatch, and AWS Config

I. Orientation: Identity, Governance, and the Shared Responsibility Model

Security in AWS splits between what AWS secures (the cloud itself) and what the customer secures (configuration, identity, data) — the shared responsibility model. This unit covers the customer side: proving who a principal is (authentication), deciding what it may do (authorization), protecting secrets, and recording what happened.

• Authentication vs authorization: Authentication confirms identity (login, access key); authorization grants permissions (policy evaluation). IAM handles both.
• Principal: Any entity making a request — an IAM user, role, federated identity, or AWS service.
• Least privilege: Grant only the permissions a task requires; the default is implicit deny.
• Global vs regional: IAM is global; CloudTrail, CloudWatch, and Config operate per-region (with options to aggregate).
• Governance triad: CloudTrail records API activity, CloudWatch monitors operational health, Config tracks resource configuration state.

II. AWS Identity and Access Management (IAM)

The service that controls authentication and authorization across all AWS resources.

A. Introduction to IAM

IAM is a free, global service that manages access to AWS resources with no additional charge.

• Function: Centrally defines principals and attaches permissions governing API calls to any AWS service.
• Request flow: A request carries the principal, action, resource, and context; IAM evaluates all applicable policies before allowing it.
• Root user: The account owner, created with the email at sign-up; holds unrestricted power and should be locked away with MFA and used only for rare tasks.

B. IAM Identities

Identities are the objects to which permissions attach.

• Categories: Users (permanent people/apps), groups (collections of users), and roles (temporary assumed identities).
• ARN: Every identity has an Amazon Resource Name, e.g. arn:aws:iam::123456789012:user/Dev.

C. IAM Policies

Policies are JSON documents listing permissions evaluated at request time.

• Core elements: Effect (Allow/Deny), Action, Resource, optional Condition.
• Evaluation rule: Explicit Deny always overrides any Allow; absence of an Allow is an implicit deny.
• Types: Identity-based (attached to users/groups/roles) and resource-based (attached to a resource, e.g. an S3 bucket policy, naming a Principal).

{ "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*" }

D. IAM Users

A user is a long-lived identity for one person or application.

• Credentials: Console password (for humans) and/or access key ID + secret access key (for programmatic/API use).
• MFA: Adds a one-time code on top of the password, strongly advised.
• Limit: 5,000 users per account — too few for scale, which is why federation/roles are preferred.

E. IAM Groups

A group bundles users so permissions are managed collectively.

• Mechanics: Attach policies to the group; every member inherits them (e.g. an Admins group with AdministratorAccess).
• Constraints: Groups cannot be nested and cannot be a principal in a policy; they only organise users.

F. IAM Roles

A role is an identity with policies but no permanent credentials, assumed temporarily.

• Temporary credentials: AWS STS issues short-lived keys when the role is assumed.
• Trust policy: A resource-based policy stating who may assume the role (a service, user, or external account).
• Use cases: EC2 instance profiles, cross-account access, and federated identity sign-in — avoids embedding static keys in code.

III. Authentication Tools

Services that extend sign-in beyond native IAM users.

A. Amazon Cognito

Provides authentication for web and mobile application end-users.

• User pools: A managed user directory handling sign-up, sign-in, and tokens (JWT).
• Identity pools: Exchange a verified identity for temporary AWS credentials to reach AWS resources.
• Federation: Accepts social (Google, Facebook) and SAML/OIDC providers.

B. AWS Managed Microsoft AD

A managed Microsoft Active Directory running in the AWS cloud.

• Basis: Actual Microsoft AD Domain Controllers, supporting group policies, trusts, and LDAP.
• Use: Lets Windows workloads and users authenticate as in an on-premises domain; can form a trust with existing on-prem AD.

C. AWS Single Sign-On (IAM Identity Center)

Central hub for one-time sign-in across multiple AWS accounts and apps.

• Permission sets: Reusable role definitions assigned to users per account.
• Integration: Works with AWS Organizations and external IdPs; a user picks an account/role from one portal.

IV. Data Protection Services

Managing encryption keys and secrets.

A. AWS Key Management Service (KMS)

Creates and controls cryptographic keys used to encrypt data.

• CMK/KMS keys: Keys never leave KMS unencrypted; access is governed by key policies plus IAM.
• Envelope encryption: A data key encrypts the data, and the KMS key encrypts the data key.
• Integration: Native encryption for S3, EBS, RDS, and more; every use is logged to CloudTrail.

B. AWS Secrets Manager

Stores, retrieves, and rotates application secrets.

• Secrets: Database passwords, API keys, tokens — retrieved via API, never hard-coded.
• Rotation: Automatic scheduled rotation via Lambda, e.g. rotating an RDS password without downtime.

C. AWS CloudHSM

A dedicated, single-tenant Hardware Security Module under customer control.

• Control: Customer manages keys inside FIPS 140-2 Level 3 validated hardware; AWS has no access.
• When used: Strict compliance needs that exceed KMS's multi-tenant model.

V. AWS CloudTrail

Records API activity for audit and governance.

A. Introduction

CloudTrail logs every API call made in an account — who, what, when, and from where.

• Record contents: Identity of caller, timestamp, source IP, request parameters, and response.
• Default: The last 90 days of management events are captured automatically.

B. Management Events

Operations performed on resources themselves (the control plane).

• Examples: RunInstances, CreateBucket, AttachRolePolicy.
• Default on: Logged free of charge for the 90-day history.

C. Data Events

High-volume operations on data within resources (the data plane).

• Examples: S3 GetObject/PutObject, Lambda Invoke.
• Opt-in: Disabled by default and charged, because volume is large.

D. Event History

A searchable, 90-day view of management events in the console.

• Filtering: By event name, user, resource type, or time.
• Limit: Only management events; retention beyond 90 days requires a trail.

E. Trails

A configuration that delivers events continuously to storage.

• Destination: An S3 bucket (and optionally CloudWatch Logs) for long-term retention.
• Scope: Can be multi-region and organisation-wide, capturing all accounts.

F. Log File Integrity Validation

Proves delivered log files were not altered or deleted.

• Mechanism: CloudTrail creates a hash (SHA-256) of each file and a signed digest file (SHA-256 with RSA).
• Verification: The CLI validate-logs command confirms tamper-free logs — essential for forensics.

VI. Amazon CloudWatch

Operational monitoring of metrics, logs, and events.

A. CloudWatch Metrics

Time-ordered numeric data about resource performance.

• Namespace/dimensions: Metrics are grouped (e.g. AWS/EC2) and keyed by dimensions like InstanceId.
• Default: EC2 reports metrics such as CPUUtilization every 5 minutes (1 minute with detailed monitoring).

B. Graphing Metrics

Visualising metric data on dashboards.

• Statistics: Plot Average, Sum, Minimum, Maximum, or percentiles over a chosen period.
• Dashboards: Combine graphs from multiple services into one customisable view.

C. Metric Math

Combines existing metrics into new computed series.

• Operations: Arithmetic and functions, e.g. SUM([m1,m2]) to total requests across instances.
• Use: Derive values like error rate from two raw metrics without extra instrumentation.

D. CloudWatch Logs

Centralised collection of log data from applications and services.

• Structure: Log groups contain log streams of event records.
• Features: Retention settings, metric filters that turn log patterns into metrics, and Logs Insights queries.

E. CloudWatch Alarms

Watch a metric and act when it crosses a threshold.

• States: OK, ALARM, INSUFFICIENT_DATA.
• Actions: Trigger SNS notifications, Auto Scaling, or EC2 actions — e.g. alarm when CPUUtilization > 80% for 5 minutes.

F. Amazon EventBridge

An event bus that routes events to targets in near real time.

• Rules: Match event patterns (or run on a schedule) and route to targets like Lambda or SNS.
• Sources: AWS services, custom applications, and SaaS partners; the evolution of CloudWatch Events.

VII. AWS Config

Tracks and audits resource configuration over time.

A. Configuration Recorder

The component that detects and records resource configuration changes.

• Function: Must be turned on per region; records supported resource types continuously.
• Scope: Can record all resources or a selected subset.

B. Configuration Items (CI)

A point-in-time snapshot of a single resource's state.

• Contents: Attributes, relationships to other resources, and related CloudTrail events.
• Trigger: A new CI is generated each time the resource changes.

C. Configuration History

The ordered collection of all CIs for a resource.

• Delivery: Written periodically to an S3 bucket.
• Use: Answers "what did this security group look like last Tuesday?"

D. Configuration Snapshots

A complete picture of all recorded resources at one instant.

• Function: On-demand or scheduled export of the whole account's state to S3.
• Use: Baseline comparison and compliance evidence.

E. Monitoring Changes

Continuous evaluation of resources against desired rules.

• Config rules: Managed or custom (Lambda-backed) checks mark resources COMPLIANT/NON_COMPLIANT, e.g. "every EBS volume is encrypted."
• Remediation: Automatic actions (via SSM Automation) and SNS alerts correct or flag drift as it occurs.