Access_Control_Policy.md
May 24, 2026 Β· View on GitHub
π Hack23 AB β Access Control Policy
π‘οΈ Zero Trust Access Through Identity-Centric Security
π― Enterprise-Grade Access Control Demonstrating Cybersecurity Excellence
π Document Owner: CEO | π Version: 2.6 | π
Last Updated: 2026-01-25 (UTC)
π Review Cycle: Semi-Annual | β° Next Review: 2026-07-25
π― Purpose Statement
π’ Hack23 AB's access control policy demonstrates how π§ systematic identity management directly enables both security excellence and operational transparency. Our π zero-trust access approach serves as both operational necessity and π₯ client demonstration of our cybersecurity consulting methodologies.
This policy establishes mandatory access controls based on our π·οΈ Classification Framework and integrates with all systems documented in the π» Asset Register.
β π¨βπΌ James Pether SΓΆrling, CEO/Founder
π Access Control Architecture
π― Identity-Centric Design
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#1565C0',
'primaryTextColor': '#0d47a1',
'lineColor': '#1565C0',
'secondaryColor': '#4CAF50',
'tertiaryColor': '#FF9800'
}
}
}%%
flowchart TD
subgraph Core["π Core Identity"]
PRIMARY["Primary Identity Provider<br/>π MFA Enforced<br/>Central Authentication"]
end
subgraph CloudOrg["βοΈ Cloud Organization"]
IDC["Identity Center<br/>π SSO + MFA"]
MGMT["Multi-Account Management<br/>π‘οΈ Centralized Policies"]
ACCTS["Business Accounts<br/>π Federated Access"]
end
subgraph DevOps["π Development Platform"]
REPO["Repository Platform<br/>π MFA Required"]
ORG["Organization Access<br/>π‘οΈ Team Management"]
end
subgraph Business["π Business Services"]
CRITICAL["Critical Services<br/>π¦ Banking, π³ Payments, π Accounting"]
MARKETING["Marketing Tools<br/>π± Social, π΅ Content, π Analytics"]
SECURITY["Security Tools<br/>π‘οΈ Code Analysis, βοΈ Compliance"]
end
PRIMARY --> IDC
PRIMARY --> REPO
PRIMARY --> CRITICAL
PRIMARY --> MARKETING
IDC --> MGMT
IDC --> ACCTS
REPO --> ORG
REPO --> SECURITY
style Core fill:#1565C0
style CloudOrg fill:#4CAF50
style DevOps fill:#FF9800
style Business fill:#D32F2F
π Access Control Matrix
Integration with Classification Framework:
π‘οΈ Multi-Factor Authentication Strategy
π― MFA Implementation Matrix
| π Service Category | π Primary MFA | π‘οΈ Backup MFA | π± Methods Supported | β Status |
|---|---|---|---|---|
| Identity Provider | Hardware Security Key | TOTP + SMS | FIDO2, WebAuthn, Authenticator | β Active |
| Cloud Platform | Enforced via IdP | Hardware Token | FIDO2, WebAuthn, SMS | β Active |
| Development Platform | TOTP | SSH Certificate | Platform Mobile, TOTP | β Active |
| Banking Services | Provider-issued Token | Mobile App | Proprietary Hardware | β Active |
| Payment Processing | TOTP | Email Verification | Authenticator App | β Active |
| Social Platforms | Platform TOTP | Email Recovery | Native Apps | β Active |
π MFA Validation Flow
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#FF9800',
'primaryTextColor': '#F57C00',
'lineColor': '#ff9800',
'secondaryColor': '#4CAF50',
'tertiaryColor': '#1565C0'
}
}
}%%
sequenceDiagram
participant User as π€ User
participant IdP as π Identity Provider
participant MFA as π± MFA Service
participant Target as π― Target System
participant Monitor as π Monitoring
User->>IdP: 1. Username + Password
IdP->>MFA: 2. Request MFA Challenge
MFA->>User: 3. Send Challenge (TOTP/Push)
User->>MFA: 4. Provide MFA Response
MFA->>IdP: 5. Validate Response
alt MFA Success
IdP->>Target: 6. Issue Access Token
Target->>Monitor: 7. Log Successful Access
Target->>User: 8. Grant Access
else MFA Failure
IdP->>Monitor: 6. Log Failed Attempt
Monitor->>IdP: 7. Trigger Security Alert
IdP->>User: 8. Access Denied
end
Monitor->>Monitor: 9. Update Security Metrics
π― Role-Based Access Control
π Generic Permission Framework
Integration with cloud organization structure:
| π‘οΈ Permission Level | π Scope | π― Use Case | π Access Pattern | π Usage Frequency |
|---|---|---|---|---|
| Administrator | Critical Systems | Emergency operations, infrastructure | Break-glass only | Monthly |
| PowerUser | Core Systems | Development, testing | Regular operations | Daily |
| ReadOnly | All systems | Monitoring, compliance | Continuous access | Daily |
| ServiceManager | Specific Services | Service provisioning | Project deployment | Weekly |
| ServiceUser | Managed Services | Resource consumption | Standard usage | Weekly |
π Dynamic Access Pattern
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#7B1FA2',
'primaryTextColor': '#4A148C',
'lineColor': '#7B1FA2',
'secondaryColor': '#4CAF50',
'tertiaryColor': '#FFC107'
}
}
}%%
flowchart LR
subgraph Standard["π
Standard Access"]
READ["ReadOnly<br/>π Monitoring"]
POWER["PowerUser<br/>βοΈ Operations"]
end
subgraph Elevated["π΄ Elevated Access"]
ADMIN["Administrator<br/>π¨ Emergency"]
CATALOG["Service Manager<br/>π Provisioning"]
end
subgraph Controls["π‘οΈ Access Controls"]
TIME["Time-based<br/>β° Session Limits"]
JUST["Just-in-time<br/>π― Request-based"]
AUDIT["Continuous Audit<br/>π Monitoring"]
end
READ --> TIME
POWER --> TIME
ADMIN --> JUST
CATALOG --> JUST
TIME --> AUDIT
JUST --> AUDIT
style Standard fill:#4CAF50
style Elevated fill:#D32F2F
style Controls fill:#1565C0
π« Segregation of Duties
Role-based access control supports segregation of duties principles by enforcing separation between incompatible functions. See π« Segregation of Duties Policy for:
- Incompatible role pairs requiring separation
- Single-person organization compensating controls
- Temporal and tool-based separation mechanisms
- Audit trail and external validation requirements
Key access control aspects supporting SoD:
- Least Privilege: Default to minimum permissions required for role
- Time-Limited Elevation: Administrator access granted just-in-time with automatic expiration
- Audit Trail: All permission changes and elevated access logged in CloudTrail
- Quarterly Review: Access permissions reviewed against principle of least privilege
π Access Monitoring & Compliance
π Continuous Monitoring Dashboard
Based on business impact and security metrics:
| π― Metric | π Target | π Measurement | π¨ Alert Threshold | π Review Frequency |
|---|---|---|---|---|
| MFA Coverage | 100% | Active MFA methods | <100% | Real-time |
| Access Anomalies | <5/month | Unusual patterns | >10/month | Daily |
| Failed Login Rate | <1% | Failed vs successful | >5% | Hourly |
| Dormant Accounts | 0 | Unused >90 days | >0 | Weekly |
| Privilege Escalation | 0 unauthorized | Admin access grants | >0 | Real-time |
| Session Compliance | 100% | Timeout adherence | <95% | Daily |
π Access Audit Trail
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#1565C0',
'primaryTextColor': '#1565C0',
'lineColor': '#1565C0',
'secondaryColor': '#4CAF50',
'tertiaryColor': '#FFC107'
}
}
}%%
graph TD
subgraph Capture["π Event Capture"]
CLOUD_AUDIT["Cloud Platform Audit<br/>π API Calls & Access"]
DEV_AUDIT["Development Audit<br/>π Repository & Pipeline Access"]
IDENTITY_LOG["Identity Provider<br/>π§ Authentication Events"]
BUSINESS_LOG["Business Systems<br/>π³ Financial & Operations"]
end
subgraph Analysis["π§ͺ Analysis Engine"]
SIEM["Security Hub<br/>π‘οΈ Event Correlation"]
DETECT["Behavior Analysis<br/>π Anomaly Detection"]
COMPLIANCE["Compliance Monitor<br/>π Policy Validation"]
end
subgraph Response["π¨ Response Actions"]
ALERT["Real-time Alerts<br/>π± Security Notifications"]
BLOCK["Automatic Blocking<br/>π« Threat Response"]
REPORT["Compliance Reports<br/>π Evidence Generation"]
end
CLOUD_AUDIT --> SIEM
DEV_AUDIT --> SIEM
IDENTITY_LOG --> SIEM
BUSINESS_LOG --> SIEM
SIEM --> DETECT
SIEM --> COMPLIANCE
DETECT --> ALERT
DETECT --> BLOCK
COMPLIANCE --> REPORT
style Capture fill:#1565C0
style Analysis fill:#4CAF50
style Response fill:#D32F2F
π§ Access Control Implementation
π° Financial Systems Access
Business Impact Justification:
- High financial impact potential (daily revenue at risk)
- Regulatory compliance requirements (audit trails, segregation of duties)
- Operational dependency (cash flow, vendor payments, payroll)
Access Requirements:
| System Type | MFA Requirement | Session Timeout | Review Frequency | Backup Access |
|---|---|---|---|---|
| Banking Platform | Hardware token + SMS | 1 hour | Monthly | Mobile app backup |
| Accounting System | SSO + TOTP | 8 hours | Quarterly | Export procedures |
| Payment Gateway | Platform MFA | 4 hours | Monthly | Manual processing |
π§ Operations & Development Access
Business Impact Justification:
- Service delivery continuity requirements
- Development pipeline integrity
- Code and infrastructure security
Access Requirements:
| System Type | MFA Requirement | Session Timeout | Review Frequency | Emergency Access |
|---|---|---|---|---|
| Development Platform | TOTP + SSH keys | 8 hours | Quarterly | Local environment |
| Cloud Infrastructure | SSO + hardware token | 4 hours | Monthly | Break-glass procedures |
| CI/CD Pipeline | Platform MFA | 24 hours | Monthly | Manual deployment |
π’ Marketing & Communications Access
Business Impact Justification:
- Brand reputation management
- Customer communication continuity
- Content and campaign integrity
Access Requirements:
| System Type | MFA Requirement | Session Timeout | Review Frequency | Content Backup |
|---|---|---|---|---|
| Social Media Platforms | Platform MFA | 7 days | Semi-annual | Content archives |
| Content Generation Tools | Platform authentication | 30 days | Annual | Alternative services |
| Analytics Platforms | SSO integration | 24 hours | Quarterly | Export procedures |
π’ Single-Person Company Adaptation
Traditional Multi-Person Requirement
Industry best practice and NIST 800-53 guidance recommend separation of duties for access control administration:
- Access Provisioner: Administrator who grants/revokes access rights
- Access Reviewer: Independent security team member who validates access appropriateness
- Audit Function: Separate audit team reviewing access control compliance
Traditional separation provides:
- Independent validation of access decisions
- Detection of unauthorized access grants
- Prevention of insider threats through collusion resistance
- Compliance with segregation of duties requirements
Typical Process:
- User requests access (or access change)
- Manager/provisioner approves and grants access
- Separate security team conducts quarterly access review
- Independent auditor validates access control effectiveness annually
Hack23 AB Single-Person Adaptation
As CEO/Founder is the sole employee and performs all roles (access provisioner, reviewer, and user), traditional multi-person access review is not possible. Instead, Hack23 AB implements automated tool validation + external audit model:
π― CEO As Access Administrator
Roles Consolidated:
- Access Provisioner (grants/revokes all access)
- Access Reviewer (validates access appropriateness)
- Primary User (uses all systems for business operations)
Limitations of Single-Person Model:
- No independent human review of access decisions
- Self-review cannot detect own errors or excessive permissions
- Risk of "privilege creep" without external validation
π― Automated Access Analysis
AWS IAM Access Analyzer (Primary Compensating Control):
| Feature | Capability | Business Value | Validation Frequency |
|---|---|---|---|
| Unused Access Detection | Identifies credentials and permissions not used in 90+ days | Reduces attack surface, enforces least privilege | Real-time continuous |
| External Access Analysis | Detects resources shared outside AWS organization | Prevents unauthorized external access | Real-time continuous |
| Policy Validation | Validates IAM policies against AWS security best practices | Ensures secure policy configuration | On policy change |
| Access Preview | Simulates policy changes before implementation | Prevents unintended access grants | Pre-deployment |
GitHub Security Features (Development Platform):
- Organization Audit Log: Complete history of all access changes, permission grants
- Security Alerts: Notifications for suspicious access patterns or unauthorized changes
- Required Reviewers: Branch protection requires PR approval (self-review documented as accepted risk)
- Dependency Review: Automated analysis of third-party access via dependencies
π― External Validation Model
Annual External Auditor Review:
| Validation Activity | Auditor Scope | Frequency | Deliverable |
|---|---|---|---|
| Access Control Effectiveness | Review access grants, permissions, MFA compliance | Annual | Audit report with findings and recommendations |
| Least Privilege Validation | Verify users have minimum necessary permissions | Annual | Excessive permission identification |
| Segregation of Duties Assessment | Evaluate compensating controls for SoD violations | Annual | Control adequacy assessment |
| Compliance Verification | Validate ISO 27001/NIST CSF alignment | Annual | Compliance attestation |
Compensating Controls
| Control Type | Implementation | ISO 27001 Alignment | Effectiveness |
|---|---|---|---|
| π€ AWS IAM Access Analyzer | Continuous automated analysis of access permissions, unused access detection | A.5.18 - Access Rights Management | Provides independent (machine) validation superior to manual review |
| π Quarterly CEO Self-Review | CEO reviews all access grants, permissions, MFA status using IAM Access Analyzer findings | A.9.2.5 - Review of User Access Rights | Systematic review process with automated tool assistance |
| π External Annual Audit | Independent auditor validates access control effectiveness and least privilege compliance | A.5.18 - Access Rights Management | Independent human validation catches systematic issues |
| π Complete Audit Trail | AWS CloudTrail + GitHub Audit Log provide tamper-evident access change history | A.8.15 - Logging | Enables retrospective review and forensic investigation |
| β±οΈ Automated Alerts | Real-time notifications for suspicious access patterns, policy changes, external sharing | A.8.16 - Monitoring Activities | Immediate detection of access anomalies |
ISO 27001:2022 Compliance
This adaptation maintains control objectives of A.5.18 (Access Rights Management) and A.9.2.5 (Review of User Access Rights) by ensuring:
β
Access Rights Allocation: CEO manages all access with documented procedures
β
Regular Reviews: Quarterly CEO review + AWS IAM Access Analyzer continuous monitoring
β
Least Privilege: Automated unused access detection enforces minimum permissions
β
Access Right Removal: Systematic removal of unused credentials and permissions
β
Independent Validation: External auditor provides independent human review annually
Alignment with ISO 27001:2022 Guidance: Annex A.9.2.5 requires "regular reviews" of access rights but does not mandate separate reviewer. The standard allows for "automated tools" to support access reviews. Single-person operations achieve control objectives through automated analysis tools (IAM Access Analyzer) providing machine-based independence + external auditor validation rather than dedicated security team review.
Superiority of Automated Approach: AWS IAM Access Analyzer provides continuous real-time monitoring superior to quarterly human review. Machine analysis detects unused access, excessive permissions, and policy violations more consistently and comprehensively than manual review.
Risk Acceptance
Risk Description: Single-person access administration increases risk of self-review bias and excessive permissions compared to independent security team review. CEO may not detect own errors in access grants or recognize privilege creep.
See π Risk Register for current risk assessment, likelihood/impact scoring, and treatment status.
Compensating Controls Summary:
- Automated superiority: AWS IAM Access Analyzer continuous monitoring exceeds quarterly human review effectiveness
- Machine independence: Automated tool provides independent validation without human bias
- Limited scope: Single-user environment (CEO) has minimal access control complexity
- External validation: Annual auditor review provides independent human oversight
- Complete audit trail: CloudTrail + GitHub logs enable retrospective forensic review
Monitoring & Review:
- Real-Time: AWS IAM Access Analyzer findings reviewed immediately when triggered
- Quarterly: CEO comprehensive access review using IAM Access Analyzer findings dashboard
- Annual: External auditor validates access control effectiveness and compensating controls
π¨ Break-Glass Emergency Access Procedure
π Emergency Access Protocol
When normal access methods fail during critical incidents, the break-glass procedure provides documented emergency access:
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#D32F2F',
'primaryTextColor': '#b71c1c',
'lineColor': '#D32F2F',
'secondaryColor': '#FF9800',
'tertiaryColor': '#4CAF50'
}
}
}%%
flowchart TD
subgraph Trigger["π¨ Emergency Trigger"]
INCIDENT[Critical Incident<br/>Normal Access Failed]
ASSESS[Assess Urgency<br/>Business Impact]
end
subgraph BreakGlass["π Break-Glass Activation"]
ROOT[AWS Root Account<br/>Recovery Email Access]
BACKUP[Backup Authentication<br/>Recovery Codes]
HARDWARE[Hardware Token<br/>Physical Recovery]
end
subgraph Controls["π‘οΈ Compensating Controls"]
LOG[Immediate Logging<br/>Incident Documentation]
NOTIFY[Stakeholder Notification<br/>Within 1 Hour]
REVIEW[Post-Incident Review<br/>Within 24 Hours]
end
subgraph Restore["π Access Restoration"]
REVOKE[Revoke Emergency Access<br/>Immediately After Resolution]
ROTATE[Rotate All Credentials<br/>Used During Emergency]
AUDIT[Full Access Audit<br/>Within 48 Hours]
end
INCIDENT --> ASSESS
ASSESS --> ROOT
ASSESS --> BACKUP
ASSESS --> HARDWARE
ROOT --> LOG
BACKUP --> LOG
HARDWARE --> LOG
LOG --> NOTIFY
NOTIFY --> REVIEW
REVIEW --> REVOKE
REVOKE --> ROTATE
ROTATE --> AUDIT
style Trigger fill:#D32F2F
style BreakGlass fill:#FF9800
style Controls fill:#1565C0
style Restore fill:#4CAF50
π Break-Glass Credentials Storage
| Credential Type | Storage Location | Access Method | Recovery Time |
|---|---|---|---|
| AWS Root Account Recovery | CEO personal email (MFA-protected) | Email + phone recovery | <15 minutes |
| AWS Root MFA Backup Codes | Encrypted USB (fireproof safe) | Physical access required | <30 minutes |
| GitHub Personal Access Token | AWS Secrets Manager (backup: encrypted local) | CLI recovery | <10 minutes |
| Identity Provider Recovery | Backup email + SMS | Multi-channel recovery | <15 minutes |
| Banking Recovery Codes | Physical secure storage (bank safe deposit) | In-person retrieval | 4-24 hours |
π Break-Glass Usage Requirements
-
Pre-Activation Checklist:
- Confirm normal access methods exhausted
- Document business justification for emergency access
- Assess incident severity (Critical/High/Medium)
- Notify relevant stakeholders if time permits
-
During Emergency Access:
- Log all actions taken with timestamps
- Use minimum necessary permissions
- Complete only essential tasks for incident resolution
- Maintain communication with any affected parties
-
Post-Emergency Requirements:
- Revoke emergency credentials within 1 hour of resolution
- Rotate all credentials accessed during emergency
- Complete incident documentation within 24 hours
- Conduct root cause analysis for access failure
- Update procedures if systemic issue identified
π Account Lifecycle Management
π Account Provisioning Procedure
ISO 27001:2022 Controls: A.5.16 (Identity Management), A.5.17 (Authentication Information)
| Phase | Activities | Responsible | Timeline | Evidence |
|---|---|---|---|---|
| Request | Document access need, business justification | Requester (CEO) | Day 0 | Access request log |
| Approval | Verify business need, least privilege assessment | Approver (CEO) | Day 0 | Approval record |
| Provisioning | Create account, configure MFA, assign permissions | Administrator (CEO) | Day 0-1 | Account creation log |
| Validation | Verify access works correctly, confirm MFA active | User (CEO) | Day 1 | MFA enrollment confirmation |
| Documentation | Update Asset Register, access matrix | Administrator (CEO) | Day 1 | Asset Register entry |
| Review | Quarterly access appropriateness review | Administrator (CEO) | Quarterly | Review completion record |
| Termination | Remove access when no longer needed | Administrator (CEO) | As needed | Deprovisioning log |
π Access Request Log Template
For each new account or permission change:
Access Request Record
=====================
Request Date: YYYY-MM-DD
Request ID: AR-YYYY-NNN
Requester: [Name/Role]
System/Service: [Target system]
Access Level Requested: [Permission level]
Business Justification: [Why access is needed]
Approval Decision: [ ] Approved / [ ] Denied
Approved By: [CEO signature/date]
Provisioning Date: YYYY-MM-DD
MFA Configured: [ ] Yes / [ ] N/A
Next Review Date: YYYY-MM-DD
π Account Status Categories
| Status | Definition | Action Required | Review Frequency |
|---|---|---|---|
| Active | Account in regular use, MFA enabled | Standard monitoring | Quarterly |
| Dormant | No activity in 60+ days | Verify continued need | Within 30 days |
| Suspended | Temporarily disabled pending review | Investigate and resolve | Within 7 days |
| Terminated | Permanently deactivated | Archive audit logs | N/A |
| Service | Non-human automated account | Monitor for abuse | Monthly |
π€ Service Account Management
π Service Account Inventory
ISO 27001:2022 Control: A.5.18 (Access Rights)
| Service Account Type | Purpose | Permission Scope | Key Rotation | Monitoring |
|---|---|---|---|---|
| GitHub Actions | CI/CD pipeline automation | Repository secrets, deployments | 90 days (via AWS OIDC) | Workflow run logs |
| AWS IAM Roles | Service-to-service authentication | Least privilege per service | Automatic (STS) | CloudTrail |
| Maven Central | Artifact publishing | Publish to group ID | 365 days (GPG key) | Release logs |
| External API Keys | Third-party integrations | API-specific scope | 90-180 days | API usage logs |
π Service Account Security Requirements
- No Long-Lived Credentials: Prefer OIDC federation, IAM roles, or short-lived tokens
- Least Privilege: Grant minimum permissions for specific automation task
- No Shared Secrets: Each service/workflow gets unique credentials
- Rotation Schedule: Maximum 90 days for API keys, automatic for IAM roles
- Audit Logging: All service account actions logged to CloudTrail/audit system
- Alerting: Unusual activity triggers immediate notification
π Service Account Lifecycle
%%{
init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#4CAF50',
'primaryTextColor': '#2E7D32',
'lineColor': '#4CAF50',
'secondaryColor': '#1565C0',
'tertiaryColor': '#FF9800'
}
}
}%%
flowchart LR
subgraph Create["π Creation"]
REQ[Service Request<br/>Business Justification]
SCOPE[Define Scope<br/>Least Privilege]
PROV[Provision Account<br/>Configure Logging]
end
subgraph Maintain["π§ Maintenance"]
ROTATE[Key Rotation<br/>Scheduled/Automatic]
MONITOR[Usage Monitoring<br/>Anomaly Detection]
REVIEW[Quarterly Review<br/>Permission Audit]
end
subgraph Retire["ποΈ Retirement"]
DEPRECATE[Mark Deprecated<br/>30-Day Notice]
DISABLE[Disable Account<br/>Test Impact]
DELETE[Delete & Archive<br/>Retain Logs 7 Years]
end
REQ --> SCOPE --> PROV
PROV --> ROTATE --> MONITOR --> REVIEW
REVIEW --> DEPRECATE --> DISABLE --> DELETE
style Create fill:#4CAF50
style Maintain fill:#1565C0
style Retire fill:#D32F2F
π Privileged Access Management (PAM)
π Privileged Account Categories
ISO 27001:2022 Control: A.8.2 (Privileged Access Rights)
| Privilege Level | Access Scope | Use Cases | Session Controls | Monitoring Level |
|---|---|---|---|---|
| Root/Super Admin | Full system control | Break-glass only | 1 hour max, full logging | Real-time + alerts |
| Organization Admin | AWS Organization management | Account creation, SCPs | 4 hours max, CloudTrail | Real-time |
| Account Admin | Individual AWS account admin | Resource management | 4 hours max, CloudTrail | Continuous |
| Power User | Elevated development access | Testing, deployment | 8 hours max, standard logs | Daily review |
| Standard User | Normal operational access | Daily operations | 24 hours max, standard logs | Weekly review |
π Just-In-Time (JIT) Privileged Access
For elevated access beyond standard permissions:
-
Request Phase:
- Document specific task requiring elevated access
- Define minimum permissions needed
- Specify time window (maximum 4 hours)
-
Activation Phase:
- Enable temporary IAM role or permission set
- Start session recording (CloudTrail enhanced)
- Set automatic expiration timer
-
Execution Phase:
- Perform only documented activities
- Log all actions taken
- Complete task within time window
-
Deactivation Phase:
- Revoke elevated permissions (automatic or manual)
- Review session logs for anomalies
- Document completion and any issues
π Privileged Access Metrics
| Metric | Target | Alert Threshold | Response |
|---|---|---|---|
| Root Account Usage | 0 per month (except break-glass) | >1 per month | Immediate investigation |
| Admin Session Duration | <2 hours average | >4 hours | Review session purpose |
| Elevated Access Requests | <10 per month | >20 per month | Review access model |
| Failed Privileged Logins | 0 | >0 | Immediate investigation |
π Access Termination Checklist
ποΈ Account Deprovisioning Procedure
Trigger Events:
- Employee departure (N/A for single-person, but documented for future scaling)
- Role change requiring access modification
- System/service retirement
- Security incident requiring immediate access revocation
- Contract termination (for any future contractors)
β Access Termination Checklist
Immediate Actions (Within 1 Hour of Trigger):
- Disable primary identity provider account
- Revoke active sessions across all SSO-integrated systems
- Disable AWS IAM Identity Center access
- Revoke GitHub organization access
- Change shared credentials (if any exist)
Same-Day Actions (Within 24 Hours):
- Remove from email distribution lists
- Revoke access to financial systems (banking, accounting)
- Disable marketing platform access
- Revoke API keys and access tokens
- Remove from any collaboration tools
Follow-Up Actions (Within 7 Days):
- Audit all access logs for terminated account
- Verify no residual access permissions remain
- Transfer ownership of any shared resources
- Archive account audit history
- Update Asset Register to reflect deprovisioning
- Document termination in access control log
π Termination Verification
After access termination, verify complete removal:
| Verification Check | Method | Timeline | Evidence |
|---|---|---|---|
| No Active Sessions | Session management console | Immediate | Screenshot/log |
| No IAM Permissions | AWS IAM Access Analyzer | Within 24 hours | Analyzer report |
| No GitHub Access | Organization audit log | Within 24 hours | Audit export |
| No API Access | Attempt authentication | Within 48 hours | Failure confirmation |
| Access Log Review | CloudTrail/audit analysis | Within 7 days | Analysis report |
Access Control Performance Metrics
Single-Person Access Administration Effectiveness:
| Metric | Target | Current Performance | Status |
|---|---|---|---|
| MFA Coverage | 100% | 100% (all critical systems) | β Exceeds |
| Unused Access | 0 credentials unused >90 days | 0 (IAM Analyzer monitoring) | β On target |
| External Access | 0 unauthorized external shares | 0 (IAM Analyzer alerts) | β On target |
| Excessive Permissions | <5 findings per quarter | N/A (monitored continuously) | β Monitored |
| Access Review Completion | 100% quarterly | 100% (systematic process) | β Compliant |
| Annual Audit Pass Rate | 100% (no major findings) | Planned Q2 2026 | β³ Scheduled |
Business Value Demonstration: Single-person access control with automated tool validation demonstrates:
- π Competitive Advantage: Modern cloud-native access management showcasing automation expertise
- π€ Customer Trust: Automated continuous monitoring provides superior assurance vs manual quarterly review
- π° Cost Efficiency: IAM Access Analyzer + external audit = β¬2K/year vs dedicated security team β¬80K+/year
- π Operational Excellence: Real-time automated validation vs delayed quarterly human review
- π‘ Innovation Enablement: Streamlined access management enables rapid experimentation
- π‘οΈ Risk Reduction: Continuous machine monitoring detects issues faster than periodic human review
π Related Documents
π― Strategic & Governance
- π― Information Security Strategy - Strategic direction, AI-first operations, and access control strategy
- π Information Security Policy - Overall security framework and AI-First Operations Governance
- π·οΈ Classification Framework - Access control classifications
- π€ AI Policy - AI agent access governance and least-privilege requirements
π Access & Identity Policies
- π« Segregation of Duties Policy - Role separation and compensating controls
- π Cryptography Policy - Encryption and key management
- π Privacy Policy - Personal data access governance
π» Asset & Operations
- π» Asset Register - Complete identity and system inventory
- π Security Metrics - Access monitoring and KPIs
- π οΈ Secure Development Policy - Development access controls
π Continuity & Response
- π¨ Incident Response Plan - Access-related incident procedures
- π Business Continuity Plan - Access continuity procedures
- π€ Third Party Management - Supplier access management
π Document Control:
β
Approved by: James Pether SΓΆrling, CEO
π€ Distribution: Public
π·οΈ Classification:
π
Effective Date: 2026-01-25
β° Next Review: 2026-07-25
π― Framework Compliance: