[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AG8MVZES5MFDS9CG5GAWAZ":3,"skill-same:01M6AG8MVZES5MFDS9CG5GAWAZ":135},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":94,"commitSha":95,"skillDirectory":96,"forksCount":97,"repositoryHtmlUrl":98,"repositoryHomepageUrl":99,"ownerHtmlUrl":100,"ownerBlogUrl":101,"ownerDescription":102,"updatedAt":103,"install":104,"resources":117},"01M6AG8MVZES5MFDS9CG5GAWAZ","securing-aws-iam-permissions",null,"Hardens AWS IAM configurations to enforce least-privilege access, covering IAM policy scoping, permission boundaries, IAM Access Analyzer integration, and credential rotation strategies. Use when reducing the blast radius of compromised AWS identities, auditing overly permissive IAM policies, or setting up permission boundaries and Access Analyzer findings review across cloud accounts.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-aws-iam-permissions\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"aws","securing aws iam permissions","iam","permissions","change","identity","pr","authentication","cybersecurity","cloud-security","review","policy","least-privilege","t1003","t1078","initial-access","permission-boundaries","radius","api","security","2026-11-10 10:12:30",false,"---\nname: securing-aws-iam-permissions\ndescription: 'Hardens AWS IAM configurations to enforce least-privilege access, covering\n  IAM policy scoping, permission boundaries, IAM Access Analyzer integration, and credential\n  rotation strategies. Use when reducing the blast radius of compromised AWS identities,\n  auditing overly permissive IAM policies, or setting up permission boundaries and\n  Access Analyzer findings review across cloud accounts.\n\n  '\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- aws-iam\n- least-privilege\n- permission-boundaries\n- access-analyzer\n- cloud-identity\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n- T1003\nmitre_f3:\n  version: '1.1'\n  tactics:\n  - initial-access\n  - positioning\n  techniques:\n  - id: F1006.001\n    name: 'Account Takeover: Exposed API Key'\n    tactic: initial-access\n    source: f3\n  - id: F1006.002\n    name: 'Account Takeover: Exposed Login Credential'\n    tactic: initial-access\n    source: f3\n  - id: T1550.001\n    name: 'Use Alternate Authentication Material: Application Access Token'\n    tactic: initial-access\n    source: attack\n  - id: T1110.003\n    name: 'Brute Force: Password Spraying'\n    tactic: initial-access\n    source: attack\n  - id: F1005.004\n    name: 'Account Manipulation: Change Account Details'\n    tactic: positioning\n    source: f3\n---\n\n# Securing AWS IAM Permissions\n\n## When to Use\n\n- When onboarding new AWS accounts or workloads that require scoped IAM policies\n- When IAM Access Analyzer reports overly permissive policies or unused permissions\n- When preparing for a compliance audit requiring least privilege evidence (SOC 2, PCI-DSS)\n- When migrating from long-lived access keys to short-lived role-based credentials\n- When remediating findings from AWS Security Hub related to IAM misconfigurations\n\n**Do not use** for Azure AD or Google Cloud IAM configurations, application-level authorization logic, or federated identity provider setup (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- AWS account with administrative access or IAM:FullAccess permissions\n- AWS CLI v2 installed and configured with named profiles\n- AWS CloudTrail enabled for at least 90 days of API activity history\n- Familiarity with JSON-based IAM policy syntax and ARN resource notation\n\n## Workflow\n\n### Step 1: Inventory Existing IAM Entities and Policies\n\nGenerate a comprehensive inventory of all IAM users, roles, groups, and attached policies using the AWS CLI and IAM credential reports. Identify accounts with console access, programmatic access keys, and their last-used timestamps.\n\n```bash\n# Generate IAM credential report\naws iam generate-credential-report\naws iam get-credential-report --query 'Content' --output text | base64 -d > iam-report.csv\n\n# List all IAM roles and their attached policies\naws iam list-roles --query 'Roles[*].[RoleName,Arn,CreateDate]' --output table\n\n# Find users with access keys older than 90 days\naws iam list-users --query 'Users[*].UserName' --output text | while read user; do\n  aws iam list-access-keys --user-name \"$user\" \\\n    --query \"AccessKeyMetadata[?CreateDate\u003C='$(date -d '-90 days' +%Y-%m-%d)'].[UserName,AccessKeyId,Status,CreateDate]\" \\\n    --output table\ndone\n```\n\n### Step 2: Enable and Analyze IAM Access Analyzer Findings\n\nActivate IAM Access Analyzer at the organization or account level to identify resources shared externally and generate least-privilege policy recommendations based on CloudTrail activity.\n\n```bash\n# Create an Access Analyzer for the account\naws accessanalyzer create-analyzer \\\n  --analyzer-name account-analyzer \\\n  --type ACCOUNT\n\n# List active findings for external access\naws accessanalyzer list-findings \\\n  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer\u002Faccount-analyzer \\\n  --filter '{\"status\": {\"eq\": [\"ACTIVE\"]}}'\n\n# Generate a policy based on CloudTrail activity for a specific role\naws accessanalyzer start-policy-generation \\\n  --policy-generation-details '{\n    \"principalArn\": \"arn:aws:iam::123456789012:role\u002FAppRole\",\n    \"cloudTrailDetails\": {\n      \"trailArn\": \"arn:aws:cloudtrail:us-east-1:123456789012:trail\u002Fmanagement-trail\",\n      \"startTime\": \"2025-01-01T00:00:00Z\",\n      \"endTime\": \"2025-03-01T00:00:00Z\"\n    }\n  }'\n```\n\n### Step 3: Scope Policies to Specific Resources and Conditions\n\nReplace wildcard resource ARNs with specific resource identifiers. Add IAM policy conditions for MFA enforcement, source IP restrictions, and time-based access windows.\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowS3ReadSpecificBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::production-data-bucket\",\n        \"arn:aws:s3:::production-data-bucket\u002F*\"\n      ],\n      \"Condition\": {\n        \"Bool\": {\"aws:MultiFactorAuthPresent\": \"true\"},\n        \"IpAddress\": {\"aws:SourceIp\": \"10.0.0.0\u002F8\"},\n        \"DateGreaterThan\": {\"aws:CurrentTime\": \"2025-01-01T00:00:00Z\"}\n      }\n    }\n  ]\n}\n```\n\n### Step 4: Implement Permission Boundaries\n\nAttach permission boundaries to IAM roles and users to define the maximum scope of permissions an entity can receive, preventing privilege escalation even if an administrator attaches an overly permissive policy.\n\n```bash\n# Create a permission boundary policy\naws iam create-policy \\\n  --policy-name DeveloperPermissionBoundary \\\n  --policy-document file:\u002F\u002Fdeveloper-boundary.json\n\n# Attach the boundary to an IAM role\naws iam put-role-permissions-boundary \\\n  --role-name DeveloperRole \\\n  --permissions-boundary \"arn:aws:iam::123456789012:policy\u002FDeveloperPermissionBoundary\"\n```\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCommonServices\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:*\",\n        \"dynamodb:*\",\n        \"lambda:*\",\n        \"logs:*\",\n        \"cloudwatch:*\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"DenyIAMChanges\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\",\n        \"iam:DeleteUser\",\n        \"iam:CreateRole\",\n        \"iam:DeleteRole\",\n        \"iam:AttachRolePolicy\",\n        \"iam:PutRolePermissionsBoundary\"\n      ],\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\n### Step 5: Enforce MFA and Eliminate Long-Lived Credentials\n\nRequire MFA for all human users accessing the AWS console and CLI. Migrate workloads from IAM user access keys to IAM roles with temporary credentials via STS AssumeRole.\n\n```bash\n# Enforce MFA via SCP at the organization level\naws organizations create-policy \\\n  --name RequireMFA \\\n  --type SERVICE_CONTROL_POLICY \\\n  --content '{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n      {\n        \"Sid\": \"DenyAllExceptMFA\",\n        \"Effect\": \"Deny\",\n        \"NotAction\": [\n          \"iam:CreateVirtualMFADevice\",\n          \"iam:EnableMFADevice\",\n          \"iam:ListMFADevices\",\n          \"iam:ResyncMFADevice\",\n          \"sts:GetSessionToken\"\n        ],\n        \"Resource\": \"*\",\n        \"Condition\": {\n          \"BoolIfExists\": {\"aws:MultiFactorAuthPresent\": \"false\"}\n        }\n      }\n    ]\n  }'\n\n# Deactivate unused access keys\naws iam update-access-key --user-name old-user --access-key-id AKIAEXAMPLE --status Inactive\n```\n\n### Step 6: Automate Continuous IAM Monitoring\n\nDeploy AWS Config rules and Security Hub controls to continuously evaluate IAM posture. Set up EventBridge rules to alert on high-risk IAM changes such as new root access key creation or policy modifications.\n\n```bash\n# Enable AWS Config rule for IAM password policy\naws configservice put-config-rule \\\n  --config-rule '{\n    \"ConfigRuleName\": \"iam-password-policy\",\n    \"Source\": {\n      \"Owner\": \"AWS\",\n      \"SourceIdentifier\": \"IAM_PASSWORD_POLICY\"\n    },\n    \"InputParameters\": \"{\\\"RequireUppercaseCharacters\\\":\\\"true\\\",\\\"RequireLowercaseCharacters\\\":\\\"true\\\",\\\"RequireSymbols\\\":\\\"true\\\",\\\"RequireNumbers\\\":\\\"true\\\",\\\"MinimumPasswordLength\\\":\\\"14\\\",\\\"MaxPasswordAge\\\":\\\"90\\\"}\"\n  }'\n\n# EventBridge rule to detect root account usage\naws events put-rule \\\n  --name DetectRootUsage \\\n  --event-pattern '{\n    \"detail-type\": [\"AWS API Call via CloudTrail\"],\n    \"detail\": {\n      \"userIdentity\": {\"type\": [\"Root\"]}\n    }\n  }'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Least Privilege | Granting only the minimum permissions required for an identity to perform its function |\n| Permission Boundary | An advanced IAM feature that sets the maximum permissions an entity can have, regardless of attached policies |\n| IAM Access Analyzer | AWS service that uses automated reasoning to identify resources shared externally and generate least-privilege policies from CloudTrail activity |\n| Service Control Policy (SCP) | Organization-level policy that sets permission guardrails across all accounts in an AWS Organization |\n| Assume Role | STS operation that returns temporary security credentials for cross-account or service-to-service access |\n| Credential Report | AWS-generated CSV listing all IAM users, their access keys, MFA status, and last activity timestamps |\n| Policy Condition | Constraints in IAM policies that restrict when and how permissions apply, such as MFA requirements or IP ranges |\n| Identity Federation | Allowing external identity providers to grant temporary AWS access without creating IAM users |\n\n## Tools & Systems\n\n- **AWS IAM Access Analyzer**: Generates least-privilege policies from CloudTrail activity and identifies resources shared with external entities\n- **AWS Config**: Continuously evaluates IAM configuration compliance against managed and custom rules\n- **AWS Security Hub**: Aggregates IAM security findings from Access Analyzer, Config, and third-party tools into a unified dashboard\n- **IAM Policy Simulator**: Tests the effects of IAM policies before deployment by simulating API calls against policy evaluation logic\n- **Prowler**: Open-source AWS security assessment tool that runs over 300 checks including IAM best practices and CIS benchmark controls\n\n## Common Scenarios\n\n### Scenario: Developer Role Over-Provisioned with AdministratorAccess\n\n**Context**: A startup attached the AWS-managed AdministratorAccess policy to all developer roles for speed during early development. A security audit reveals 15 roles with full account access while developers only use S3, Lambda, and DynamoDB.\n\n**Approach**:\n1. Enable IAM Access Analyzer and generate policy recommendations based on 90 days of CloudTrail data for each role\n2. Create scoped policies allowing only the specific S3 buckets, Lambda functions, and DynamoDB tables each team accesses\n3. Attach a permission boundary denying IAM, Organizations, and billing actions\n4. Deploy the new policies in a parallel role with CloudTrail monitoring before replacing the original\n5. Remove AdministratorAccess and rotate all access keys\n\n**Pitfalls**: Replacing policies without a parallel testing period causes service disruptions. Forgetting to scope Lambda:InvokeFunction to specific function ARNs leaves lateral movement paths open.\n\n### Scenario: Rotating Compromised Access Keys Across Multiple Services\n\n**Context**: An access key is found in a public GitHub repository. The key belongs to an IAM user with S3 and EC2 permissions across three AWS accounts.\n\n**Approach**:\n1. Immediately deactivate the compromised key using `aws iam update-access-key --status Inactive`\n2. Review CloudTrail logs for all API calls made with the compromised key in the past 30 days\n3. Create a new access key for the user and update all dependent services and CI\u002FCD pipelines\n4. Delete the compromised key after confirming all services use the new credentials\n5. Migrate the workload to use IAM roles with STS temporary credentials to prevent future key exposure\n\n**Pitfalls**: Deleting the key before deactivating it prevents forensic analysis of which services relied on it. Failing to check all three accounts for unauthorized activity leaves potential backdoors undetected.\n\n## Output Format\n\n```\nIAM Security Assessment Report\n==============================\nAccount ID: 123456789012\nAssessment Date: 2025-02-23\nAnalyzer: IAM Access Analyzer + Prowler v4.3\n\nCRITICAL FINDINGS:\n[C-001] Root account has active access keys\n  - Resource: arn:aws:iam::123456789012:root\n  - Remediation: Delete root access keys, enable MFA on root\n  - CIS Benchmark: 1.4 (Ensure no root account access key exists)\n\n[C-002] IAM user 'deploy-bot' has AdministratorAccess with no MFA\n  - Resource: arn:aws:iam::123456789012:user\u002Fdeploy-bot\n  - Last Activity: 2025-02-20\n  - Remediation: Replace with IAM role, enforce MFA condition\n\nHIGH FINDINGS:\n[H-001] 3 IAM policies use wildcard Resource \"*\" with sensitive actions\n  - Policies: DevPolicy, CIPolicy, LegacyAdminPolicy\n  - Remediation: Scope resources to specific ARNs using Access Analyzer\n\n[H-002] 7 access keys older than 90 days detected\n  - Users: svc-backup, svc-monitoring, dev-alice, dev-bob, ...\n  - Remediation: Rotate keys, migrate to role-based access\n\nSUMMARY:\n  Total Findings: 14\n  Critical: 2 | High: 4 | Medium: 5 | Low: 3\n  Compliance Score: 62% (CIS AWS Foundations Benchmark v3.0)\n```\n","# Securing AWS IAM Permissions\n\n## When to Use\n\n- When onboarding new AWS accounts or workloads that require scoped IAM policies\n- When IAM Access Analyzer reports overly permissive policies or unused permissions\n- When preparing for a compliance audit requiring least privilege evidence (SOC 2, PCI-DSS)\n- When migrating from long-lived access keys to short-lived role-based credentials\n- When remediating findings from AWS Security Hub related to IAM misconfigurations\n\n**Do not use** for Azure AD or Google Cloud IAM configurations, application-level authorization logic, or federated identity provider setup (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- AWS account with administrative access or IAM:FullAccess permissions\n- AWS CLI v2 installed and configured with named profiles\n- AWS CloudTrail enabled for at least 90 days of API activity history\n- Familiarity with JSON-based IAM policy syntax and ARN resource notation\n\n## Workflow\n\n### Step 1: Inventory Existing IAM Entities and Policies\n\nGenerate a comprehensive inventory of all IAM users, roles, groups, and attached policies using the AWS CLI and IAM credential reports. Identify accounts with console access, programmatic access keys, and their last-used timestamps.\n\n```bash\n# Generate IAM credential report\naws iam generate-credential-report\naws iam get-credential-report --query 'Content' --output text | base64 -d > iam-report.csv\n\n# List all IAM roles and their attached policies\naws iam list-roles --query 'Roles[*].[RoleName,Arn,CreateDate]' --output table\n\n# Find users with access keys older than 90 days\naws iam list-users --query 'Users[*].UserName' --output text | while read user; do\n  aws iam list-access-keys --user-name \"$user\" \\\n    --query \"AccessKeyMetadata[?CreateDate\u003C='$(date -d '-90 days' +%Y-%m-%d)'].[UserName,AccessKeyId,Status,CreateDate]\" \\\n    --output table\ndone\n```\n\n### Step 2: Enable and Analyze IAM Access Analyzer Findings\n\nActivate IAM Access Analyzer at the organization or account level to identify resources shared externally and generate least-privilege policy recommendations based on CloudTrail activity.\n\n```bash\n# Create an Access Analyzer for the account\naws accessanalyzer create-analyzer \\\n  --analyzer-name account-analyzer \\\n  --type ACCOUNT\n\n# List active findings for external access\naws accessanalyzer list-findings \\\n  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer\u002Faccount-analyzer \\\n  --filter '{\"status\": {\"eq\": [\"ACTIVE\"]}}'\n\n# Generate a policy based on CloudTrail activity for a specific role\naws accessanalyzer start-policy-generation \\\n  --policy-generation-details '{\n    \"principalArn\": \"arn:aws:iam::123456789012:role\u002FAppRole\",\n    \"cloudTrailDetails\": {\n      \"trailArn\": \"arn:aws:cloudtrail:us-east-1:123456789012:trail\u002Fmanagement-trail\",\n      \"startTime\": \"2025-01-01T00:00:00Z\",\n      \"endTime\": \"2025-03-01T00:00:00Z\"\n    }\n  }'\n```\n\n### Step 3: Scope Policies to Specific Resources and Conditions\n\nReplace wildcard resource ARNs with specific resource identifiers. Add IAM policy conditions for MFA enforcement, source IP restrictions, and time-based access windows.\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowS3ReadSpecificBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:GetObject\",\n        \"s3:ListBucket\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::production-data-bucket\",\n        \"arn:aws:s3:::production-data-bucket\u002F*\"\n      ],\n      \"Condition\": {\n        \"Bool\": {\"aws:MultiFactorAuthPresent\": \"true\"},\n        \"IpAddress\": {\"aws:SourceIp\": \"10.0.0.0\u002F8\"},\n        \"DateGreaterThan\": {\"aws:CurrentTime\": \"2025-01-01T00:00:00Z\"}\n      }\n    }\n  ]\n}\n```\n\n### Step 4: Implement Permission Boundaries\n\nAttach permission boundaries to IAM roles and users to define the maximum scope of permissions an entity can receive, preventing privilege escalation even if an administrator attaches an overly permissive policy.\n\n```bash\n# Create a permission boundary policy\naws iam create-policy \\\n  --policy-name DeveloperPermissionBoundary \\\n  --policy-document file:\u002F\u002Fdeveloper-boundary.json\n\n# Attach the boundary to an IAM role\naws iam put-role-permissions-boundary \\\n  --role-name DeveloperRole \\\n  --permissions-boundary \"arn:aws:iam::123456789012:policy\u002FDeveloperPermissionBoundary\"\n```\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCommonServices\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:*\",\n        \"dynamodb:*\",\n        \"lambda:*\",\n        \"logs:*\",\n        \"cloudwatch:*\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"DenyIAMChanges\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\",\n        \"iam:DeleteUser\",\n        \"iam:CreateRole\",\n        \"iam:DeleteRole\",\n        \"iam:AttachRolePolicy\",\n        \"iam:PutRolePermissionsBoundary\"\n      ],\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\n### Step 5: Enforce MFA and Eliminate Long-Lived Credentials\n\nRequire MFA for all human users accessing the AWS console and CLI. Migrate workloads from IAM user access keys to IAM roles with temporary credentials via STS AssumeRole.\n\n```bash\n# Enforce MFA via SCP at the organization level\naws organizations create-policy \\\n  --name RequireMFA \\\n  --type SERVICE_CONTROL_POLICY \\\n  --content '{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n      {\n        \"Sid\": \"DenyAllExceptMFA\",\n        \"Effect\": \"Deny\",\n        \"NotAction\": [\n          \"iam:CreateVirtualMFADevice\",\n          \"iam:EnableMFADevice\",\n          \"iam:ListMFADevices\",\n          \"iam:ResyncMFADevice\",\n          \"sts:GetSessionToken\"\n        ],\n        \"Resource\": \"*\",\n        \"Condition\": {\n          \"BoolIfExists\": {\"aws:MultiFactorAuthPresent\": \"false\"}\n        }\n      }\n    ]\n  }'\n\n# Deactivate unused access keys\naws iam update-access-key --user-name old-user --access-key-id AKIAEXAMPLE --status Inactive\n```\n\n### Step 6: Automate Continuous IAM Monitoring\n\nDeploy AWS Config rules and Security Hub controls to continuously evaluate IAM posture. Set up EventBridge rules to alert on high-risk IAM changes such as new root access key creation or policy modifications.\n\n```bash\n# Enable AWS Config rule for IAM password policy\naws configservice put-config-rule \\\n  --config-rule '{\n    \"ConfigRuleName\": \"iam-password-policy\",\n    \"Source\": {\n      \"Owner\": \"AWS\",\n      \"SourceIdentifier\": \"IAM_PASSWORD_POLICY\"\n    },\n    \"InputParameters\": \"{\\\"RequireUppercaseCharacters\\\":\\\"true\\\",\\\"RequireLowercaseCharacters\\\":\\\"true\\\",\\\"RequireSymbols\\\":\\\"true\\\",\\\"RequireNumbers\\\":\\\"true\\\",\\\"MinimumPasswordLength\\\":\\\"14\\\",\\\"MaxPasswordAge\\\":\\\"90\\\"}\"\n  }'\n\n# EventBridge rule to detect root account usage\naws events put-rule \\\n  --name DetectRootUsage \\\n  --event-pattern '{\n    \"detail-type\": [\"AWS API Call via CloudTrail\"],\n    \"detail\": {\n      \"userIdentity\": {\"type\": [\"Root\"]}\n    }\n  }'\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Least Privilege | Granting only the minimum permissions required for an identity to perform its function |\n| Permission Boundary | An advanced IAM feature that sets the maximum permissions an entity can have, regardless of attached policies |\n| IAM Access Analyzer | AWS service that uses automated reasoning to identify resources shared externally and generate least-privilege policies from CloudTrail activity |\n| Service Control Policy (SCP) | Organization-level policy that sets permission guardrails across all accounts in an AWS Organization |\n| Assume Role | STS operation that returns temporary security credentials for cross-account or service-to-service access |\n| Credential Report | AWS-generated CSV listing all IAM users, their access keys, MFA status, and last activity timestamps |\n| Policy Condition | Constraints in IAM policies that restrict when and how permissions apply, such as MFA requirements or IP ranges |\n| Identity Federation | Allowing external identity providers to grant temporary AWS access without creating IAM users |\n\n## Tools & Systems\n\n- **AWS IAM Access Analyzer**: Generates least-privilege policies from CloudTrail activity and identifies resources shared with external entities\n- **AWS Config**: Continuously evaluates IAM configuration compliance against managed and custom rules\n- **AWS Security Hub**: Aggregates IAM security findings from Access Analyzer, Config, and third-party tools into a unified dashboard\n- **IAM Policy Simulator**: Tests the effects of IAM policies before deployment by simulating API calls against policy evaluation logic\n- **Prowler**: Open-source AWS security assessment tool that runs over 300 checks including IAM best practices and CIS benchmark controls\n\n## Common Scenarios\n\n### Scenario: Developer Role Over-Provisioned with AdministratorAccess\n\n**Context**: A startup attached the AWS-managed AdministratorAccess policy to all developer roles for speed during early development. A security audit reveals 15 roles with full account access while developers only use S3, Lambda, and DynamoDB.\n\n**Approach**:\n1. Enable IAM Access Analyzer and generate policy recommendations based on 90 days of CloudTrail data for each role\n2. Create scoped policies allowing only the specific S3 buckets, Lambda functions, and DynamoDB tables each team accesses\n3. Attach a permission boundary denying IAM, Organizations, and billing actions\n4. Deploy the new policies in a parallel role with CloudTrail monitoring before replacing the original\n5. Remove AdministratorAccess and rotate all access keys\n\n**Pitfalls**: Replacing policies without a parallel testing period causes service disruptions. Forgetting to scope Lambda:InvokeFunction to specific function ARNs leaves lateral movement paths open.\n\n### Scenario: Rotating Compromised Access Keys Across Multiple Services\n\n**Context**: An access key is found in a public GitHub repository. The key belongs to an IAM user with S3 and EC2 permissions across three AWS accounts.\n\n**Approach**:\n1. Immediately deactivate the compromised key using `aws iam update-access-key --status Inactive`\n2. Review CloudTrail logs for all API calls made with the compromised key in the past 30 days\n3. Create a new access key for the user and update all dependent services and CI\u002FCD pipelines\n4. Delete the compromised key after confirming all services use the new credentials\n5. Migrate the workload to use IAM roles with STS temporary credentials to prevent future key exposure\n\n**Pitfalls**: Deleting the key before deactivating it prevents forensic analysis of which services relied on it. Failing to check all three accounts for unauthorized activity leaves potential backdoors undetected.\n\n## Output Format\n\n```\nIAM Security Assessment Report\n==============================\nAccount ID: 123456789012\nAssessment Date: 2025-02-23\nAnalyzer: IAM Access Analyzer + Prowler v4.3\n\nCRITICAL FINDINGS:\n[C-001] Root account has active access keys\n  - Resource: arn:aws:iam::123456789012:root\n  - Remediation: Delete root access keys, enable MFA on root\n  - CIS Benchmark: 1.4 (Ensure no root account access key exists)\n\n[C-002] IAM user 'deploy-bot' has AdministratorAccess with no MFA\n  - Resource: arn:aws:iam::123456789012:user\u002Fdeploy-bot\n  - Last Activity: 2025-02-20\n  - Remediation: Replace with IAM role, enforce MFA condition\n\nHIGH FINDINGS:\n[H-001] 3 IAM policies use wildcard Resource \"*\" with sensitive actions\n  - Policies: DevPolicy, CIPolicy, LegacyAdminPolicy\n  - Remediation: Scope resources to specific ARNs using Access Analyzer\n\n[H-002] 7 access keys older than 90 days detected\n  - Users: svc-backup, svc-monitoring, dev-alice, dev-bob, ...\n  - Remediation: Rotate keys, migrate to role-based access\n\nSUMMARY:\n  Total Findings: 14\n  Critical: 2 | High: 4 | Medium: 5 | Low: 3\n  Compliance Score: 62% (CIS AWS Foundations Benchmark v3.0)\n```\n",{"name":5,"tags":54,"author":58,"domain":37,"license":15,"version":59,"mitre_f3":60,"nist_csf":82,"subdomain":38,"description":87,"mitre_attack":88},[55,41,45,56,57],"aws-iam","access-analyzer","cloud-identity","mahipal","1.0.0",{"tactics":61,"version":63,"techniques":64},[44,62],"positioning","1.1",[65,69,72,76,79],{"id":66,"name":67,"source":68,"tactic":44},"F1006.001","Account Takeover: Exposed API Key","f3",{"id":70,"name":71,"source":68,"tactic":44},"F1006.002","Account Takeover: Exposed Login Credential",{"id":73,"name":74,"source":75,"tactic":44},"T1550.001","Use Alternate Authentication Material: Application Access Token","attack",{"id":77,"name":78,"source":75,"tactic":44},"T1110.003","Brute Force: Password Spraying",{"id":80,"name":81,"source":68,"tactic":62},"F1005.004","Account Manipulation: Change Account Details",[83,84,85,86],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01","Hardens AWS IAM configurations to enforce least-privilege access, covering IAM policy scoping, permission boundaries, IAM Access Analyzer integration, and credential rotation strategies. Use when reducing the blast radius of compromised AWS identities, auditing overly permissive IAM policies, or setting up permission boundaries and Access Analyzer findings review across cloud accounts.\n",[89,90,91,92,93],"T1078.004","T1530","T1537","T1580","T1003","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fsecuring-aws-iam-permissions",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":105,"prompt":115,"zipAvailable":116},[106,109,112],{"tool":107,"command":108},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-aws-iam-permissions",{"tool":110,"command":111},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-aws-iam-permissions",{"tool":113,"command":114},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-aws-iam-permissions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-aws-iam-permissions\u002FSKILL.md",true,[118,123,129],{"path":119,"resourceType":119,"resourceTypeDesc":120,"sizeBytes":121,"sourceHtmlUrl":122},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-aws-iam-permissions\u002FLICENSE",{"path":124,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Fapi-reference.md","REFERENCE","参考文档",2325,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-aws-iam-permissions\u002Freferences\u002Fapi-reference.md",{"path":130,"resourceType":131,"resourceTypeDesc":132,"sizeBytes":133,"sourceHtmlUrl":134},"scripts\u002Fagent.py","SCRIPT","脚本",7710,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-aws-iam-permissions\u002Fscripts\u002Fagent.py",[136,160,183,210,236,262],{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":49},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[142],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[144,145,146,147,48,37,148,34,35,149,150,151,152,153,154,155,156,157,158,159],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":49},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[166],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[168,156,169,170,48,40,37,35,171,172,173,174,175,176,177,178,179,180,181,182],"boot","TPM","validating tpm measured boot attestation","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":193,"publishedAt":49},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[189,192],{"categoryNo":190,"categoryName":191,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[177,194,195,196,197,37,198,199,171,200,201,202,203,204,205,43,206,207,208,209],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":217,"publishedAt":49},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[216],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[218,219,220,37,221,222,223,224,225,226,227,228,229,230,231,232,174,233,234,235],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":243,"publishedAt":49},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[242],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[244,245,246,37,247,248,249,250,251,252,253,254,255,256,257,258,47,259,260,261],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","prioritization","ssvc","decision-tree",{"skillNo":263,"name":264,"nameZh":6,"description":265,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":266,"categories":267,"keywords":269,"publishedAt":49},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[268],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[48,270,37,271,272,273,274,275,276,277,278,43,279,206,280,281,282,283,284,285],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]