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

AWS Identity and Access Management (IAM) is a web service that enables you to securely control access to AWS resources. It allows you to manage who is authenticated (signed in) and authorized (has permissions) to use resources.

Key Features:

• Centralized control: Manage users, groups, roles, and permissions from a single place.
• Granular permissions: Grant different levels of access to different users for different resources.
• Shared access: Allow other people to administer your AWS account without sharing credentials.
• Multi-Factor Authentication (MFA): Add an extra layer of security.
• Identity Federation: Allow users with existing credentials (corporate directory, Google, Facebook) to access resources.
• Free to use: IAM is offered at no additional charge.
• Global service: Not restricted to a specific region.

Importance:

• Enforces the principle of least privilege.
• Reduces the risk of unauthorized access.
• Enables audit and compliance tracking.
• Supports secure resource sharing within and across accounts.

The three primary IAM identities differ in their purpose and usage:

IAM Users:

• Represent a single person or application that interacts with AWS.
• Have permanent long-term credentials (username/password, access keys).
• Example: An employee John needing console access.

IAM Groups:

• A collection of IAM users sharing common permissions.
• Simplifies permission management — attach a policy to the group once.
• A user can belong to multiple groups; groups cannot be nested.
• Example: A Developers group with permissions to EC2 and S3.

IAM Roles:

• An identity with temporary credentials that can be assumed by users, applications, or AWS services.
• No permanent credentials; credentials rotate automatically.
• Example: An EC2 instance assuming a role to access an S3 bucket.

IAM Policies are JSON documents that define permissions — what actions are allowed or denied on which resources.

Policy Structure (Key Elements):

• Version: Policy language version (e.g., 2012-10-17).
• Statement: Container for the permission elements.
• Effect: Either Allow or Deny.
• Action: The specific operations (e.g., s3:GetObject).
• Resource: The ARN(s) the actions apply to.
• Condition (optional): Circumstances under which the policy applies.

Example Policy:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mybucket/*"
}]
}

Types of Policies:

• Identity-based policies: Attached to users, groups, or roles.
• Resource-based policies: Attached to resources (e.g., S3 bucket policy).
• AWS Managed Policies: Created and managed by AWS.
• Customer Managed Policies: Created and managed by the customer.
• Inline Policies: Embedded directly into a single identity.
• Permission boundaries & SCPs: Set maximum permission limits.

Evaluation Rule: An explicit Deny always overrides any Allow.

Amazon Cognito is a service that provides authentication, authorization, and user management for web and mobile applications. It lets users sign in directly or through third-party identity providers.

Two Main Components:

1. User Pools:

• A user directory that handles sign-up and sign-in.
• Provides user profiles, MFA, and token-based authentication (JWT).
• Supports social sign-in (Google, Facebook, Apple) and SAML/OIDC providers.
• Returns tokens used to authenticate the user.

2. Identity Pools (Federated Identities):

• Provide temporary AWS credentials to access AWS services directly.
• Grant access to authenticated and unauthenticated (guest) users.
• Exchange identity tokens for IAM role-based credentials.

How it helps:

• Offloads user management (no need to build custom auth).
• Scales to millions of users.
• Secures APIs and AWS resources.
• Integrates with API Gateway and Lambda.

Flow: User signs in via User Pool → receives token → Identity Pool exchanges token for AWS credentials → user accesses AWS resources.

AWS Key Management Service (KMS):

• A managed service to create and control encryption keys used to encrypt data.
• Fully integrated with most AWS services (S3, EBS, RDS).
• Keys are stored in FIPS 140-2 validated hardware security modules (shared/multi-tenant).
• Supports Customer Master Keys (CMKs) — AWS managed, customer managed, or imported.
• Centralized key management, automatic key rotation, and audit via CloudTrail.

AWS CloudHSM:

• Provides dedicated, single-tenant hardware security modules (HSMs) in the cloud.
• You have full control over key generation and management.
• Meets stringent compliance requirements (FIPS 140-2 Level 3).
• Suitable for custom cryptographic applications.

Comparison:

AWS Secrets Manager is a service that helps you protect secrets needed to access applications, services, and IT resources, such as database credentials, API keys, and tokens.

Purpose:

• Securely store and retrieve secrets.
• Eliminate the need to hardcode credentials.

Key Features:

• Automatic rotation: Rotate secrets automatically on a schedule (e.g., RDS passwords) using Lambda.
• Encryption: Secrets are encrypted at rest using AWS KMS.
• Fine-grained access control: Via IAM policies.
• Auditing: Integration with CloudTrail.
• Programmatic retrieval: Applications fetch secrets at runtime via API.

Difference from hardcoding secrets:

• Hardcoded secrets are stored in plain text in source code — a major security risk if the repository is exposed.
• Secrets Manager keeps them encrypted, centralized, and rotatable, with full audit trails.
• No need to redeploy code when a secret changes.

Note: For simpler needs, SSM Parameter Store can also store secrets but lacks automatic rotation out of the box.

AWS Managed Microsoft AD (AWS Directory Service for Microsoft Active Directory):

• A fully managed Active Directory running actual Microsoft AD in the AWS Cloud.
• Enables you to use managed AD for directory-aware workloads (SQL Server, SharePoint).
• Supports trust relationships with on-premises AD.
• Handles patching, monitoring, backups, and replication automatically.

AWS Single Sign-On (now AWS IAM Identity Center):

• Enables users to sign in once and access multiple AWS accounts and applications.
• Centrally manages access across AWS Organizations.
• Integrates with existing identity sources (Microsoft AD, external IdPs).
• Supports SAML 2.0 for business applications.

How they simplify identity management:

• Single credential set across multiple accounts/apps reduces password fatigue.
• Centralized user provisioning and de-provisioning.
• Enforces consistent security policies and MFA.
• Reduces administrative overhead and improves the user experience.
• Enables integration between corporate directories and AWS resources.

AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. It records API calls and account activity across your AWS infrastructure.

Purpose:

• Tracks who did what, when, and from where in your AWS account.
• Logs actions taken via the console, SDKs, CLI, and other AWS services.

Key Benefits:

• Visibility: Complete record of user and resource activity.
• Security analysis: Detect unusual activity and unauthorized access.
• Compliance: Helps meet regulatory requirements (PCI, HIPAA).
• Troubleshooting: Identify changes that caused operational issues.
• Audit: Provides a verifiable event history.

What is recorded: Each event contains the identity of the caller, time of call, source IP, request parameters, and response elements.

Default behavior: CloudTrail is enabled by default and retains 90 days of management event history, viewable through Event History.

CloudTrail captures two main categories of events:

Management Events:

• Record control plane operations performed on resources.
• Examples: creating an EC2 instance (RunInstances), configuring security (AttachRolePolicy), setting up logging.
• Logged by default and free for the first copy.
• Also called control plane events.

Data Events:

• Record data plane operations — resource operations performed on or within a resource.
• Examples: S3 object-level activity (GetObject, PutObject), Lambda function invocations (Invoke).
• Not logged by default (high volume) and incur additional charges.
• Also called data plane events.

Comparison:

Insight events form a third category, detecting unusual activity patterns.

Event History:

• Provides a viewable, searchable record of the past 90 days of management events.
• Enabled by default; no configuration required.
• Useful for quick troubleshooting and investigation.

Trails:

• A configuration that enables delivery of CloudTrail events to an S3 bucket, CloudWatch Logs, or EventBridge.
• Allows long-term retention beyond 90 days.
• Can be applied to a single region or all regions (multi-region trail).
• Can capture management, data, and insight events.
• Supports organization-wide trails for AWS Organizations.

Log File Integrity Validation:

• A feature that lets you verify whether log files were modified, deleted, or unchanged after CloudTrail delivered them.
• Uses SHA-256 hashing and SHA-256 with RSA for digital signing.
• CloudTrail creates a digest file every hour, containing hashes of log files, signed with a private key.
• Validation is crucial for forensic and compliance purposes to establish non-repudiation.

Summary: Event History gives short-term visibility, Trails provide durable storage, and Log File Integrity Validation ensures the logs are tamper-evident.

Amazon CloudWatch is a monitoring and observability service for AWS resources and the applications you run on AWS. It collects metrics, logs, and events to provide a unified view of operational health.

Role and Functions:

• Metrics collection: Gathers performance data (CPU, memory, network) from AWS services.
• Logs: Centralizes and monitors log files from applications and resources.
• Alarms: Triggers notifications or automated actions on threshold breaches.
• Dashboards: Visualize metrics in customizable graphs.
• Events/EventBridge: Responds to state changes with automated actions.

Benefits:

• Real-time monitoring of resource utilization and performance.
• Automated responses (e.g., Auto Scaling based on CPU).
• Troubleshooting via logs and metrics correlation.
• Operational insights to optimize cost and performance.

Key use cases: Detecting anomalies, scaling resources automatically, setting up alerts, and maintaining application availability.

CloudWatch Metrics:

• A metric is a time-ordered set of data points representing a variable to monitor (e.g., CPUUtilization).
• Metrics are organized by namespaces (e.g., AWS/EC2) and identified by dimensions (name/value pairs like InstanceId).
• Each metric has a timestamp and optional unit.
• Metrics are retained based on resolution (high-resolution for 3 hours, then aggregated up to 15 months).

Standard vs Custom Metrics:

• Standard metrics: Automatically published by AWS services.
• Custom metrics: Published by your applications using the PutMetricData API — e.g., memory usage, business KPIs like orders per minute.

Graphing Metrics:

• CloudWatch lets you visualize metrics as graphs on dashboards.
• You can apply statistics such as Average, Sum, Minimum, Maximum, and SampleCount.
• Supports math expressions to combine multiple metrics.
• Enables comparison across time ranges and resources.

Example: Graph the Average CPUUtilization of an EC2 instance over the last 24 hours to spot usage trends.

CloudWatch Logs:

• A service to centralize, monitor, and store log data from applications, EC2 instances, Lambda, and other sources.
• Organized into Log Groups (collections) and Log Streams (sequence of events from one source).
• Supports retention policies, searching, and real-time monitoring.
• Logs can be collected via the CloudWatch Agent or SDK.

Metric Filters (Metric Match):

• A metric filter extracts data from log events and converts matching patterns into CloudWatch metrics.
• You define a filter pattern to match specific text (e.g., the word ERROR).
• Each match increments a metric value.

Converting Logs to Metrics (Steps):

1. Define a filter pattern (e.g., "ERROR").
2. The filter scans incoming log events.
3. When a match occurs, it publishes data to a custom metric.
4. Create a CloudWatch Alarm on that metric to trigger alerts.

Example: Count the number of 404 errors in web server logs and alarm if they exceed a threshold.

Benefit: Transforms unstructured logs into actionable, numeric metrics for alerting and dashboards.

CloudWatch Alarms watch a single metric or math expression over a specified time period and perform actions based on the metric's value relative to a threshold.

Alarm Components:

• Metric: The variable being monitored.
• Threshold: The value to compare against.
• Period & Evaluation periods: How often and over how many data points to evaluate.
• Comparison operator: e.g., GreaterThanThreshold.

Alarm States:

• OK: The metric is within the defined threshold.
• ALARM: The metric has breached the threshold.
• INSUFFICIENT_DATA: Not enough data to determine the state (e.g., alarm just started).

Possible Actions:

• Notification: Send a message to an Amazon SNS topic (email/SMS).
• Auto Scaling: Trigger scaling policies to add/remove instances.
• EC2 Actions: Stop, terminate, reboot, or recover an instance.
• Systems Manager actions.

Types:

• Metric alarms: Based on a single metric.
• Composite alarms: Based on the states of multiple alarms (using AND/OR logic) to reduce noise.

Example: Alarm when CPUUtilization > 80% for 5 minutes → notify via SNS and trigger Auto Scaling.

Amazon EventBridge (formerly CloudWatch Events) is a serverless event bus that makes it easy to connect applications using events from AWS services, SaaS applications, and custom apps.

Purpose:

• Enables event-driven, loosely coupled architectures.
• Routes events from sources to targets in near real-time.

Key Components:

• Event Bus: A pipeline that receives events (default, custom, or partner bus).
• Events: JSON objects describing a change in state.
• Rules: Match incoming events against patterns and route them to targets.
• Targets: Resources that process the event (Lambda, SQS, SNS, Step Functions, etc.).
• Event Pattern / Schedule: Rules can match patterns or trigger on a schedule (cron).

How it enables event-driven architecture:

• Decouples event producers from consumers.
• Allows multiple targets to react to a single event (fan-out).
• Supports scheduled tasks (replacing cron jobs).
• Integrates with 100+ AWS services and SaaS partners.

Example: When an EC2 instance changes state to terminated, EventBridge triggers a Lambda function to log the event and send a notification.

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. It continuously monitors and records resource configurations and allows you to automate evaluation against desired configurations.

Purpose:

• Provides a detailed view of resource configurations and how they change over time.
• Tracks relationships between resources.

How it helps:

• Configuration tracking: Records configuration changes continuously.
• Compliance auditing: Uses Config Rules to check if resources comply with policies (e.g., ensuring S3 buckets are not public).
• Change management: Tracks what changed, when, and by whom (combined with CloudTrail).
• Troubleshooting: Identify configurations that led to issues.
• Security analysis: Detect non-compliant or risky configurations.

Config Rules:

• Managed rules: Predefined by AWS.
• Custom rules: Defined using Lambda functions.

Example use case: Ensure all EBS volumes are encrypted; AWS Config flags any unencrypted volume as non-compliant and can trigger remediation.

Configuration Recorder:

• The component that records the configurations of supported resources in your account.
• Must be enabled for AWS Config to start tracking.
• You can configure it to record all resources or only specific resource types.
• Detects changes and generates configuration items.

Configuration Items (CI):

• A point-in-time snapshot of the attributes of a resource.
• Contains metadata, attributes, relationships, current configuration, and related events.
• Generated whenever a resource is created, modified, or deleted.
• Serves as the fundamental building block of AWS Config.

Configuration History:

• A collection of configuration items for a resource over a period of time.
• Shows how a resource's configuration changed over time.
• Delivered periodically to an S3 bucket.
• Useful for auditing, troubleshooting, and compliance.

Relationship: The Configuration Recorder generates Configuration Items whenever changes occur, and the accumulation of these items forms the Configuration History.

Configuration Snapshots:

• A complete picture of all the resource configurations recorded by AWS Config at a specific point in time.
• Can be delivered on-demand or on a schedule to an S3 bucket.
• Represents the entire state of recorded resources, not just changes.
• Useful for creating a baseline and for full-account audits.

Monitoring Changes:

• AWS Config continuously monitors and records changes to resource configurations.
• When a resource changes, Config:
  1. Detects the change.
  2. Creates a new Configuration Item.
  3. Evaluates it against Config Rules.
  4. Can notify via SNS/EventBridge.
• Enables tracking of configuration drift from compliant states.

Support for Operational Governance:

• Visibility: Know the exact state of resources at any time.
• Compliance: Continuously verify adherence to internal and regulatory policies.
• Security: Quickly detect unauthorized or risky changes.
• Audit trail: Combined with CloudTrail (who made the change) and Config (what changed), gives complete governance.
• Remediation: Trigger automated remediation when non-compliance is detected.

These three services serve distinct but complementary monitoring purposes:

AWS CloudTrail — "Who did what?"

• Records API calls and user activity (auditing).
• Focuses on actions performed in the account.
• Example: User X deleted an S3 bucket at 2 PM.

Amazon CloudWatch — "How is it performing?"

• Monitors performance metrics, logs, and health.
• Focuses on operational state and real-time monitoring.
• Example: CPU utilization reached 90%.

AWS Config — "What is the configuration state?"

• Records resource configurations and changes over time.
• Focuses on configuration and compliance.
• Example: This security group now allows unrestricted inbound traffic.

Comparison Table:

How they complement each other:

• CloudTrail tells you who made a change.
• AWS Config tells you what changed in configuration.
• CloudWatch tells you the impact on performance and triggers alerts.
• Together they provide complete governance, security, and operational visibility.

AWS provides several authentication and credential-management tools to secure access:

1. IAM (Identity and Access Management):

• Core service for managing users, groups, roles, and permissions.
• Supports MFA and access keys.

2. Amazon Cognito:

• Manages authentication for web/mobile app users.
• Provides user pools and identity pools for app-level sign-in.

3. AWS Managed Microsoft AD:

• Managed Active Directory for enterprise directory-aware workloads and trusts with on-premises AD.

4. AWS Single Sign-On (IAM Identity Center):

• Centralized single sign-on across multiple AWS accounts and applications.

5. AWS Key Management Service (KMS):

• Manages encryption keys for data protection.

6. AWS Secrets Manager:

• Securely stores and rotates secrets like credentials and API keys.

7. AWS CloudHSM:

• Dedicated hardware security modules for high-compliance key management.

How they work together:

• IAM controls access to AWS resources and services.
• Cognito/SSO/Managed AD handle user identity at the application and enterprise level.
• KMS, CloudHSM, and Secrets Manager protect the cryptographic material and credentials used in authentication.
• Combined, they implement a defense-in-depth security model following the principle of least privilege.