# Access Control

> When to activate: access control, RBAC, ABAC, least privilege, privileged access, access review, PAM, joiner mover leaver, MFA, IAM, zero trust

- Skill: `mattakushi432/access-control` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mattakushi432/access-control`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mattakushi432/access-control/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Mattakushi432 (https://skillmd.com/u/mattakushi432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mattakushi432/access-control

---


# Access Control

## RBAC vs ABAC

| | RBAC (Role-Based) | ABAC (Attribute-Based) |
|-|-------------------|------------------------|
| Access based on | User roles | Attributes (user, resource, environment) |
| Flexibility | Lower — roles must be predefined | Higher — dynamic, context-aware |
| Complexity | Lower to implement | Higher to implement and audit |
| Best for | Stable org structures, clear job functions | Dynamic environments, fine-grained control |
| Example | "Manager" role can approve expenses | User with dept=Finance AND clearance=High AND time=business-hours can view salary data |
| Standards | NIST RBAC model | XACML, ABAC NIST SP 800-162 |

### When to Use Each
- **RBAC**: Most enterprise systems — clear roles, predictable access patterns
- **ABAC**: Regulatory environments requiring context-sensitive access, multi-tenant SaaS, zero-trust architectures
- **Hybrid**: Use RBAC for coarse-grained access + ABAC for fine-grained attribute checks within a role

## Least Privilege Implementation

### Principles
1. Grant minimum permissions needed to perform the job function
2. Default deny — explicitly grant, never implicitly allow
3. Time-bound access — grant for duration needed, auto-expire
4. Just-in-time (JIT) access — provision on request, deprovision after use
5. Separation of duties — no single person controls a critical process end-to-end

### Least Privilege Audit Checklist
- [ ] All service accounts have documented purpose and minimum required permissions
- [ ] No shared accounts (each person has unique credentials)
- [ ] Admin accounts separate from standard user accounts
- [ ] Database accounts have only SELECT/INSERT/UPDATE needed — not DROP/TRUNCATE
- [ ] API keys scoped to specific endpoints / resources
- [ ] Cloud IAM roles follow principle of least privilege (no AdministratorAccess wildcard)
- [ ] Regular access entitlement review performed (at least semi-annually)

## Privileged Access Management (PAM)

### What PAM Covers
- Local administrator accounts on servers and workstations
- Domain administrator accounts
- Database superuser / DBA accounts
- Cloud root / owner accounts
- Network device admin credentials
- Application service accounts with elevated permissions

### PAM Controls
| Control | Description |
|---------|-------------|
| Credential vaulting | Store privileged credentials in encrypted vault (CyberArk, HashiCorp Vault) |
| Session recording | Record all privileged sessions for audit trail |
| Just-in-time access | Provision access for defined window; auto-revoke |
| Dual control | Require two people to authorize highly privileged actions |
| Credential rotation | Auto-rotate passwords after each use or on schedule |
| Alerting | Alert on unusual privileged access patterns |

### Break-Glass (Emergency Access) Procedure
```
1. Requestor documents emergency justification in ticket
2. Emergency credentials retrieved from sealed vault / break-glass account
3. All actions recorded (session recording active or screen capture required)
4. Credentials rotated immediately after emergency resolved
5. Post-incident review within 48 hours
6. Ticket closed with actions taken documented
```

## Joiner / Mover / Leaver (JML) Process

### Joiner (New Employee / Contractor)
| Step | Action | Timing |
|------|--------|--------|
| 1 | HR triggers provisioning workflow via HRIS | Day of hire |
| 2 | Base access provisioned per role profile | Before day 1 |
| 3 | MFA enrolled | Day 1 |
| 4 | Manager confirms access is correct | Within 5 business days |
| 5 | Role-specific systems granted on approval | As requested |

### Mover (Role Change / Transfer)
| Step | Action | Timing |
|------|--------|--------|
| 1 | HR triggers move event in HRIS | Day of transfer |
| 2 | Remove access no longer needed for old role | Within 24 hours |
| 3 | Grant access required for new role | Day of transfer |
| 4 | New manager confirms access is correct | Within 5 business days |

### Leaver (Termination)
| Step | Action | Timing |
|------|--------|--------|
| 1 | HR triggers termination event | Day of termination decision |
| 2 | Disable all accounts (AD, SaaS, VPN, cloud) | Immediately on last day or sooner for involuntary |
| 3 | Revoke all API keys and tokens | Same day |
| 4 | Recover company devices | Day of departure |
| 5 | Transfer data/handoff completed | Before departure |
| 6 | Confirm deprovisioning complete | Within 24 hours |
| 7 | Archive mailbox and data per retention policy | Within 7 days |

**Involuntary terminations**: Disable access before the employee is notified when risk warrants it.

## Access Review Cadence and Methodology

### Review Frequency by Risk Level
| System type | Review frequency |
|-------------|----------------|
| Production systems, privileged access | Quarterly |
| Standard business applications | Semi-annually |
| Low-risk / read-only systems | Annually |
| External / third-party access | Quarterly |

### Access Certification Process
1. Generate access report for each system
2. Distribute to access owners (managers of each user)
3. Owner certifies each access as: **Approve** / **Revoke** / **Modify**
4. Unanswered items escalated after 5 business days
5. Revocations executed within 5 business days of decision
6. Certification results archived for audit evidence

## MFA Enforcement Policies

### MFA Requirements
| Access type | MFA required? |
|-------------|--------------|
| VPN / remote access | Yes — mandatory |
| Admin / privileged access | Yes — mandatory |
| Cloud console (AWS/GCP/Azure) | Yes — mandatory |
| SaaS applications with sensitive data | Yes — mandatory |
| Internal corporate apps | Yes — recommended |
| Read-only internal tools | Risk-based |

### Acceptable MFA Methods (ranked by strength)
1. Hardware security key (FIDO2/WebAuthn) — strongest
2. TOTP authenticator app (Google Authenticator, Authy)
3. Push notification (Duo, Microsoft Authenticator)
4. SMS OTP — acceptable but weakest; avoid for high-privilege access

## Separation of Duties Matrix

| Function | Initiate | Approve | Execute | Review/Audit |
|----------|---------|---------|---------|-------------|
| Financial payment | Finance team | Finance manager | Treasury | Internal audit |
| Code deployment | Developer | Tech lead / peer | DevOps | Security |
| Access provisioning | Manager | IT Security | IT admin | Compliance |
| Vendor contract | Procurement | Legal + Finance | Procurement | Finance |
| Firewall rule change | Requestor | Security | Network admin | Security ops |

## IAM Audit Checklist

- [ ] No orphaned accounts (accounts with no active owner)
- [ ] All accounts tied to named individuals (no shared accounts)
- [ ] Inactive accounts disabled after 90 days inactivity
- [ ] All privileged accounts enrolled in PAM
- [ ] MFA enforced for all required access types
- [ ] Service account passwords meet complexity requirements and rotated
- [ ] Access review completed within required frequency
- [ ] Admin access requires secondary approval
- [ ] All deprovisioning completed within SLA
- [ ] Cloud IAM policies reviewed for wildcard permissions
- [ ] API keys inventoried with owners and expiry dates assigned