Mattakushi432 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
- Grant minimum permissions needed to perform the job function
- Default deny — explicitly grant, never implicitly allow
- Time-bound access — grant for duration needed, auto-expire
- Just-in-time (JIT) access — provision on request, deprovision after use
- 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
- Generate access report for each system
- Distribute to access owners (managers of each user)
- Owner certifies each access as: Approve / Revoke / Modify
- Unanswered items escalated after 5 business days
- Revocations executed within 5 business days of decision
- 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)
- Hardware security key (FIDO2/WebAuthn) — strongest
- TOTP authenticator app (Google Authenticator, Authy)
- Push notification (Duo, Microsoft Authenticator)
- 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