iam-audit

Name: iam-audit
Author: briiirussell

320stars36forks

How to install iam-audit?

briiirussell/cybersecurity-skills/iam-audit

$npx -y skills add briiirussell/cybersecurity-skills --skill iam-audit

Installs into the current project.

Summary

Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization (RBAC, ABAC, ReBAC), and federated identity. Use when the user mentions 'IAM,' 'ide

Files · 1

View on GitHub

SKILL.md

1	# IAM Audit — Identity & Access Management Review and Design
2
3	Cover the identity and access layer end-to-end: audit existing setup, design from scratch, plan migrations, and codify the patterns most teams get wrong. This is the consultant-style skill — not just "what's misconfigured" but "what should this look like."
4
5	Three modes — pick the one that matches the engagement:
6	- Audit — review what's already deployed, find privilege creep and gaps
7	- Design — greenfield IAM for a new project or new identity provider
8	- Migrate — consolidate multiple identity providers, federate access, move to SSO
9
10	Cross-references: `cloud-audit` for the cloud-provider audit (broader than IAM), `container-audit` for K8s RBAC and ServiceAccounts (orchestration-layer identity).
11
12	## Mode 1 — Audit existing IAM
13
14	### Cloud provider IAM
15
16	AWS:
17	- IAM users with console access — should be zero in mature setups (use SSO/Identity Center)
18	- IAM users with permanent access keys — every one is a credential rotation problem; replace with role assumption via SSO or IAM Roles Anywhere
19	- Permissions boundaries set on every role that can create roles (prevents privilege escalation via `iam:CreateRole` + `iam:AttachRolePolicy`)
20	- `AdministratorAccess` policy attachments — flag every one and justify
21	- Wildcard `Action: ""` or `Resource: ""` outside of break-glass roles
22	- Cross-account trust policies — `Principal: { AWS: "*" }` is open to the world; should be specific account IDs with optional `aws:PrincipalOrgID` condition
23	- IMDSv2 enforced — `MetadataOptions.HttpTokens: required` on every EC2 launch template
24	- Service-linked roles audited — they bypass normal restrictions
25	- Run: `aws accessanalyzer list-findings`, `aws iam generate-credential-report`, `aws iam get-account-authorization-details`
26
27	GCP:
28	- `roles/owner` and `roles/editor` are too broad — replace with custom roles or fine-grained `roles/*Admin`
29	- Service account keys downloaded (`projects.serviceAccounts.keys.create`) — should be zero; use Workload Identity Federation
30	- Service accounts with `iam.serviceAccountTokenCreator` on themselves = self-impersonation = privilege escalation
31	- Org-level vs project-level bindings — over-scoped bindings at the org level are silent privilege grants to every project
32	- `allUsers` / `allAuthenticatedUsers` bindings on any sensitive resource
33	- Run: `gcloud asset analyze-iam-policy`, `gcloud policy-intelligence query-activity`, Recommender API
34
35	Azure:
36	- `Owner` and `Contributor` role assignments at subscription/management-group scope
37	- Custom roles with `*` actions
38	- Conditional Access policies cover every sign-in surface (legacy auth, service principals, break-glass accounts excluded with explicit reason)
39	- Privileged Identity Management (PIM) used for all Global Admin / Privileged Role Admin / Application Admin roles
40	- Service principal credentials (client secrets) — should expire and rotate; check expiration dates
41	- Run: `az role assignment list --all`, Microsoft Graph `auditLogs/signIns`, Microsoft Entra recommendations
42
43	### Identity provider
44
45	Okta / Entra ID / Auth0 / Google Workspace:
46	- MFA enforced for 100% of users — no "MFA optional" cohort
47	- Phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) for admins; TOTP is the minimum for everyone
48	- Inactive accounts disabled after 30/60/90 days (pick a policy, enforce it)
49	- Lifecycle automation — joiner / mover / leaver flows are automated, not ticket-driven
50	- Group-based access — users get permissions via group membership, not direct assignment; group membership is the auditable surface
51	- Admin separation — privileged admin actions require a separate elevated account, not the day-to-day account
52	- App assignments — every SaaS app reviewed quarterly; orphaned apps (no longer used) removed
53	- Authentication policies — block legacy protocols (IMAP, POP, SMTP basic auth), enforce device compliance for high-trust apps
54	- Session lifetime appropriate to sensitivity (admin: short, end user: longer with refresh)
55	- Logs forwarded to SIEM — sign-ins, admin changes, MFA failures
56
57	### Application authorization
58
59	- Role definitions written down somewhere (not just in code) — `docs/roles.md` or equivalent
60	- "Admin" is not one role — usually 3-5: s

People who liked this also viewed

6 picks

Type

iam-audit

320stars36forks

View on GitHub

How to install iam-audit?

briiirussell/cybersecurity-skills/iam-audit

$npx -y skills add briiirussell/cybersecurity-skills --skill iam-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# IAM Audit — Identity & Access Management Review and Design
2
3	Cover the identity and access layer end-to-end: audit existing setup, design from scratch, plan migrations, and codify the patterns most teams get wrong. This is the consultant-style skill — not just "what's misconfigured" but "what should this look like."
4
5	Three modes — pick the one that matches the engagement:
6	- Audit — review what's already deployed, find privilege creep and gaps
7	- Design — greenfield IAM for a new project or new identity provider
8	- Migrate — consolidate multiple identity providers, federate access, move to SSO
9
10	Cross-references: `cloud-audit` for the cloud-provider audit (broader than IAM), `container-audit` for K8s RBAC and ServiceAccounts (orchestration-layer identity).
11
12	## Mode 1 — Audit existing IAM
13
14	### Cloud provider IAM
15
16	AWS:
17	- IAM users with console access — should be zero in mature setups (use SSO/Identity Center)
18	- IAM users with permanent access keys — every one is a credential rotation problem; replace with role assumption via SSO or IAM Roles Anywhere
19	- Permissions boundaries set on every role that can create roles (prevents privilege escalation via `iam:CreateRole` + `iam:AttachRolePolicy`)
20	- `AdministratorAccess` policy attachments — flag every one and justify
21	- Wildcard `Action: ""` or `Resource: ""` outside of break-glass roles
22	- Cross-account trust policies — `Principal: { AWS: "*" }` is open to the world; should be specific account IDs with optional `aws:PrincipalOrgID` condition
23	- IMDSv2 enforced — `MetadataOptions.HttpTokens: required` on every EC2 launch template
24	- Service-linked roles audited — they bypass normal restrictions
25	- Run: `aws accessanalyzer list-findings`, `aws iam generate-credential-report`, `aws iam get-account-authorization-details`
26
27	GCP:
28	- `roles/owner` and `roles/editor` are too broad — replace with custom roles or fine-grained `roles/*Admin`
29	- Service account keys downloaded (`projects.serviceAccounts.keys.create`) — should be zero; use Workload Identity Federation
30	- Service accounts with `iam.serviceAccountTokenCreator` on themselves = self-impersonation = privilege escalation
31	- Org-level vs project-level bindings — over-scoped bindings at the org level are silent privilege grants to every project
32	- `allUsers` / `allAuthenticatedUsers` bindings on any sensitive resource
33	- Run: `gcloud asset analyze-iam-policy`, `gcloud policy-intelligence query-activity`, Recommender API
34
35	Azure:
36	- `Owner` and `Contributor` role assignments at subscription/management-group scope
37	- Custom roles with `*` actions
38	- Conditional Access policies cover every sign-in surface (legacy auth, service principals, break-glass accounts excluded with explicit reason)
39	- Privileged Identity Management (PIM) used for all Global Admin / Privileged Role Admin / Application Admin roles
40	- Service principal credentials (client secrets) — should expire and rotate; check expiration dates
41	- Run: `az role assignment list --all`, Microsoft Graph `auditLogs/signIns`, Microsoft Entra recommendations
42
43	### Identity provider
44
45	Okta / Entra ID / Auth0 / Google Workspace:
46	- MFA enforced for 100% of users — no "MFA optional" cohort
47	- Phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) for admins; TOTP is the minimum for everyone
48	- Inactive accounts disabled after 30/60/90 days (pick a policy, enforce it)
49	- Lifecycle automation — joiner / mover / leaver flows are automated, not ticket-driven
50	- Group-based access — users get permissions via group membership, not direct assignment; group membership is the auditable surface
51	- Admin separation — privileged admin actions require a separate elevated account, not the day-to-day account
52	- App assignments — every SaaS app reviewed quarterly; orphaned apps (no longer used) removed
53	- Authentication policies — block legacy protocols (IMAP, POP, SMTP basic auth), enforce device compliance for high-trust apps
54	- Session lifetime appropriate to sensitivity (admin: short, end user: longer with refresh)
55	- Logs forwarded to SIEM — sign-ins, admin changes, MFA failures
56
57	### Application authorization
58
59	- Role definitions written down somewhere (not just in code) — `docs/roles.md` or equivalent
60	- "Admin" is not one role — usually 3-5: s

People who liked this also viewed

6 picks

Type