Advanced Identity in AWS | Overview.🔐

Advanced Identity in AWS - Overview.🔐

Scope:

• Intro
• Core Advanced Strategies,
• Governance and Automation,
• Policy Refinement,
• links to documentation,
• Identity Foundations,
• Core AWS Identity Services,
• Advanced Identity Patterns,
• Modern Best Practices,
• Emerging & Advanced Trends,
• KeyTakeAway.

Intro:

• Advanced identity management in AWS focuses on granular control, automation, and centralized governance to secure large-scale environments. 

Core Advanced Strategies

• Attribute-Based Access Control (ABAC): A strategy that defines permissions based on attributes, such as tags on users and resources. 
• Attribute-Based Access Control allows for dynamic scaling since twtech doesn't need to update individual policies when adding new resources.
• IAM Identity Center: Recommended for centralized management of human user access across multiple AWS accounts. 
• IAM Identity Center integrates with external providers like Okta, Microsoft Entra ID, and Google Workspace.
• Permissions Boundaries: A feature used to set the maximum permissions that an identity-based policy can grant. 
• Permissions Boundaries is essential for delegating policy creation to developers without allowing them to escalate their own privileges. 

Governance and Automation

• Service Control Policies (SCPs): Used within AWS Organizations to establish central security guardrails. 
• SCPs define the maximum available permissions for all accounts in an organization or organizational unit (OU).
• IAM Access Analyzer: Automates the process of identifying resources shared with external entities and helps generate least-privilege policies based on actual access activity.
• IAM Roles Anywhere: Enables workloads outside of AWS, such as on-premises servers or containers, to securely obtain temporary AWS credentials using digital certificates instead of long-term access keys. 

Policy Refinement

• Condition Keys: Advanced policies use global or service-specific condition keys to restrict access based on variables like source IP, request time, or whether MFA was used.
• Cross-Account Roles: Instead of creating duplicate users, twtech can use roles to delegate access across different AWS accounts, providing a unified audit trail and reducing credential sprawl.

links to documentation:

https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/

 https://docs.aws.amazon.com/managedservices/latest/userguide/sec-iam.html

1. Identity Foundations

AWS identity is built around:

•        Who,
•        what someone is (identities)
•        What someone can do (permissions).

• Principals: Can be users, roles, services, applications, or federated entities.
• Authentication: Verifying the identity (IAM, AWS SSO/Identity Center, federation).
• Authorization: What actions the principal is allowed to perform (IAM policies, SCPs, permission boundaries).

2. Core AWS Identity Services

💻 IAM (Identity and Access Management)

• IAM Users: Long-term credentials (not recommended for humans anymore).
• IAM Roles: Temporary, assumable identities for workloads, services, and federation.
• IAM Groups: Collections of users with shared policies.
• IAM Policies: JSON docs defining permissions; key types:
• Identity-based policies (attached to user, role, or group).
• Resource-based policies (e.g., S3 bucket policy, KMS key policy).
• Session policies (applied via STS AssumeRole).
• Permissions boundaries (limits the maximum permissions).
• Service control policies (SCPs) (organization-wide guardrails).

🌍 AWS Organizations + SCPs (Service control policies)

• Manage multi-account identity governance.
• SCPs restrict maximum allowed permissions, even if an IAM policy allows it.
• Examples: Deny * outside specific regions, enforce tagging policies, deny root access.

👤 AWS Identity Center (Successor to AWS SSO… single sign-on)

• Central hub for workforce identity.
• Integrates with IdPs (Okta, Azure AD, Ping, etc.) via SAML or OIDC.
• SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) are both open standard protocols used for implementing single sign-on (SSO) and federated authentication, allowing users to access multiple applications with one set of credentials.
• Provides role-based access into multiple AWS accounts.
• Assigns fine-grained permissions without IAM users.
• Supports MFA, SCIM provisioning, attribute-based access control (ABAC).

🌐 Amazon Cognito

• Customer identity (CIAM).
• Sign-up, sign-in, federation for apps.
• Works with OIDC, SAML, social IdPs (Google, Facebook, Apple).
• Provides JWTs for API authorization (with API Gateway, AppSync, etc.).

 AWS STS (Security Token Service)

• Issues temporary credentials for roles, federation, and cross-account access.
• Key APIs:
• AssumeRole (cross-account/service access).
• AssumeRoleWithSAML (federation).
• AssumeRoleWithWebIdentity (OIDC, Cognito, Kubernetes IRSA).
• GetFederationToken (temporary federated access).

3. Advanced Identity Patterns

🏛️ Federation & Workforce Identity

• Use external IdPs with SAML/OIDC to authenticate.
• AWS recommends Identity Center + external IdP over managing IAM users.
• Attribute-based access control (ABAC) can map IdP attributes (like department, role) into IAM session tags for fine-grained permissions.

🔄 Cross-Account Access

• Use IAM roles with trust policies.
• Example: CI/CD pipeline in one account assumes a deployer role in another.
• Best practice: No shared IAM users across accounts.

🔖 Attribute-Based Access Control (ABAC)

• Use tags + session attributes instead of static role-permissions.
• Example: Condition: StringEquals: { "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}" }
• Allows dynamic, scalable permissions.

🛡️ Guardrails & Governance

• SCPs (limit account permissions).
• Permissions boundaries (limit delegated admins).
• Resource policies (restrict usage to VPC, IP range, account).
• IAM Access Analyzer (detects unintended public/3rd-party access).
• Policy validation tools (IAM Policy Simulator, Access Analyzer custom checks).

📦 Workload Identity (for Apps & Services)

• IRSA (IAM Roles for Service Accounts) in EKS: Pods assume IAM roles via OIDC federation.
• OIDC (OpenID Connect) federation is a mechanism that allows a service provider (Relying Party) to trust identities managed by an external identity provider (IdP). 
• Instead of creating new usernames and passwords, users use their existing accounts from providers like Google, Microsoft Entra ID, or Okta to access different applications or cloud services.
• IAM roles for Lambda: Least-privilege per function.
• IAM roles for EC2: Instance profiles.
• Service-linked roles: Predefined by AWS services.

🔐 Fine-Grained & Advanced Controls

• KMS Key policies + IAM for encryption governance.
• STS session policies for temporary restrictions.
• Conditional access: 
• aws:SourceIp, 
• aws:RequestTag, 
• aws:PrincipalTag, 
• aws:CalledVia.

4. Modern Best Practices

• No IAM users for workforce → Use Identity Center + external IdP.
• No long-lived credentials → Use roles + STS (temporary).
• ABAC over RBAC for scalable access.
• Multi-account strategy with AWS Organizations.
• Centralized governance → SCPs, Config, Control Tower.
• IAM Access Analyzer + CloudTrail for continuous monitoring.
• MFA enforced everywhere.
• Key rotation & least privilege at all times.

5. Emerging & Advanced Trends

• Identity-Centric Zero Trust in AWS: context-aware, attribute-based authorization.
• IAM Roles Anywhere: Extend IAM roles to on-prem workloads using X.509 certs.
• Service-to-service OIDC federation: Workloads in Kubernetes, GitHub Actions, and third parties assuming AWS roles directly.
• Delegated Administration: Using Organizations to allow controlled admin of IAM Identity Center or GuardDuty across accounts.
• Verified Access (VA): Secure remote workforce access to private apps with identity + device posture.

twtech-KeyTakeAway:

• AWS identity is shifting from: IAM users & static policies → to federation, temporary credentials, ABAC, and centralized governance.
• The key themes are: least privilege, automation, multi-account strategy, federation, and continuous monitoring.

CloudWatch vs CloudTrail vs Config | Overview.

CloudWatch vs CloudTrail vs Config - Overview.

Scope:

• Intro,
• Quick Comparison Table,
• How They Work Together,
• Amazon CloudWatch for Monitoring & Observability (deep dive),
• AWS CloudTrail for Auditing & Security Forensics (deep dive),
• AWS Config for Resource Compliance & Governance,
• How CloudWatch, CloudTrail & Config Work Together,
• Sample Workflow,
• Side-by-Side Comparison (deep dive),
• Rule of Thumb.

Intro:

• AWS offers these three services to provide full visibility into twtech cloud environment.
• But these three services each focus on a different layer of activity. 
• CloudWatch: Focuses on what is happening in terms of health and performance.
• CloudWatch monitors application logs and infrastructure metrics (like CPU or RAM) and triggers alarms when thresholds are crossed.
• CloudTrail: Focuses on who did what. 
• CloudTrail is an audit trail that logs every API call made in your account, capturing who made the request, from where, and when.
• Config: Focuses on how things are configured. 
• Config tracks the history of twtech resource settings and evaluates them against compliance rules to ensure they stay within twtech desired state. 

Quick Comparison Table 

Feature	CloudWatch	CloudTrail	Config
Primary Goal	Performance & Health	Auditing & Governance	Compliance & Security
Key Data	Metrics & Application Logs	API Activity & User Events	Resource History & Rules
Common Use	Setting alarms for high CPU	Seeing who deleted a database	Checking if S3 buckets are public
Perspective	Internal (Inside the resource)	External (API/Account level)	Structural (Configuration state)

How They Work Together

• These services are often used in tandem for a complete security posture. 
• Tandem means, frequently used together, in combination, or concurrently to achieve a more robust or functional result
• For example, if a security breach occurs: 

1. CloudTrail tells twtech which user account was used to change a security group.
2. Config shows twtech exactly what the security group rules were before and after that change.
3. CloudWatch identifies if there was a sudden spike in network traffic following the change. 

NB:

• twtech can manage these further by using the AWS Management Console to set up a unified CloudWatch Dashboard or review AWS Config Rules for your environment.

Link to official documentation

https://docs.aws.amazon.com/config/latest/developerguide/log-api-calls.html

NB:

• CloudWatch, CloudTrail, and Config are three AWS services.
• They all deal with Monitoring/Observability,  Auditing/Ferensics, and Compliance/Governance (Governance-Risk-compliance), Rspectively.

1. Amazon CloudWatch for Monitoring & Observability

• Purpose: Real-time monitoring / Observability of performance, health, and operational metrics.
• Focus: How is my system performing right now?
• Data Types:

• Metrics (CPU, memory, disk, API latency, custom app metrics)
• Logs (application/system logs, VPC Flow Logs, Lambda logs)
• Alarms & Dashboards (trigger actions, visualizations)

• Key Features:

• Alarms (threshold-based alerts → SNS, Lambda, Auto Scaling)
• Logs (CloudWatch Logs Insights for querying)
• Metrics (native AWS + custom metrics)
• Events (CloudWatch Events/EventBridge → automation)

• Integrations:

• Auto Scaling (scale EC2/ECS on metrics)
• EventBridge (real-time automation)
• AWS Lambda (log/metric processing)

• Use Case:

• Detect high CPU usage → trigger auto scaling
• Monitor Lambda errors
• Central logging from multiple services

2. AWS CloudTrail for Auditing & Security Forensics (deep dive)

• Purpose: Record of API calls and account activity for compliance, auditing, / investigation.
• Focus: Who did what, when, and from where?
• Data Types:
• API calls (management events: CreateBucket, StopInstance)
• Data events (S3 object-level, Lambda invoke-level)
• Insights events (detect anomalies, unusual API activity)

• Key Features:

• Immutable audit log of all AWS API activity
• Delivered to S3 (long-term storage)
• Integration with CloudWatch Logs for real-time alerting
• CloudTrail Lake for querying historical activity

• Integrations:

• Security Hub & GuardDuty (threat detection)
• Athena (query CloudTrail logs)
• CloudWatch Events/EventBridge (real-time automation)

• Use Case:

• Who deleted my S3 bucket?
• Investigating root account login
• Compliance (PCI, HIPAA, SOC 2)

3. AWS Config for Resource Compliance & Governance

• Purpose: Tracks resource inventory, configuration history, and compliance evaluation.
• Focus: What does the environment look like, and is it compliant?
• Data Types:

• Configuration items (resource snapshots)
• Compliance state (evaluated against Config Rules)

• Key Features:

• Continuous resource monitoring
• Config Rules (AWS-managed or custom Lambda rules)
• Remediations (auto-fix non-compliance)
• Compliance dashboard

• Integrations:

• Security Hub (compliance aggregation)
• SNS/EventBridge (notify/remediate)
•  SSM (AWS Systems Manager) Automation (remediation)

• Use Case:

• Ensure all S3 buckets are encrypted
• Detect non-compliant IAM policies
• Maintain inventory for audit

 How CloudWatch, CloudTrail & Config Work Together

• CloudWatch → Detect operational issues (CPU spike, service errors).
• CloudTrail → Answer “who/what/when” (API-level history of actions taken).
• Config → Answer “is it compliant/secure” (tracks resource state & evaluates against rules).

Sample Workflow:

1. twtech-junior-Developer disables S3 bucket encryption (problem-created).
2. CloudTrail logs the API call (PutBucketEncryption → disabled).
3. Config detects non-compliant S3 bucket → marks rule as NON_COMPLIANT.
4. CloudWatch alarm may trigger if related metrics (e.g., access denied errors) spike.
5. EventBridge/Lambda → automatically re-enable encryption.

 Side-by-Side Comparison (deep dive)

Feature	CloudWatch ⏱️		CloudTrail 📜	Config 🛡️
Primary Use		Monitoring & metrics	Auditing API calls	Compliance & governance
Data Type		Metrics, logs, events	API events (mgmt & data)	Resource configs & compliance
Granularity		Performance metrics	API-level actions	Resource-level state
Storage		CloudWatch Logs, dashboards	S3 (logs), CloudTrail Lake	S3 (config snapshots)
Automation		Alarms → actions	Events → Lambda/SNS	Rules → remediation
Best For		Ops teams (monitoring)	Security/Audit teams	Compliance/GRC(Governance Risk compliance) teams

 

twtech-Rule of Thumb:

• Use CloudWatch → How is it performing? ( Monitoring & Observability)
• Use CloudTrail → Who did what? ( Auditing & Security Forensics)
• Use Config → Is it compliant? ( Resource Compliance & Governance)