Authorisation & Access Control

User creates a file → User sets permissions → Owner controls access
Example: Linux file permissions (chmod, chown), Windows NTFS permissions
Weakness: Users may grant excessive access; no central policy enforcement
Strength: Flexible, easy to implement for small environments

Labels: Top Secret > Secret > Confidential > Unclassified
User has "Secret" clearance → Can access Secret and below
Cannot write down (write Secret data to Unclassified system)
Example: SELinux, AppArmor, government classified systems
Strength: Centralised, non-bypassable policy
Weakness: Complex to manage, requires strict labelling

Role: "Finance Manager"
  → Parent role: "Finance User" (inherits all Finance User permissions)
  → Has permissions: Approve invoices up to $50k, view P&L reports, approve expense reports
  → Cannot: Create vendor accounts, process payroll, modify GL codes

Implementation: Active Directory groups, Azure AD roles, AWS IAM roles

POLICY: "Managers can view employee salary data IF
  department matches AND time is business hours AND device is managed"

Attributes:
  User: role=manager, department=engineering
  Resource: type=salary_data, department=engineering
  Environment: time=14:30, day=Tuesday, device=COMPANY-LAPTOP-01
  → ACCESS GRANTED

  User: role=manager, department=engineering
  Resource: type=salary_data, department=engineering
  Environment: time=02:30, day=Saturday, device=COMPANY-LAPTOP-01
  → ACCESS DENIED (time condition not met)

POLICY: "Emergency responders can override normal access controls
  during declared incidents"

POLICY: "Contractors can access project resources only between 8AM-6PM
  and only from managed devices"

Global Admin
├── Security Admin
│   ├── SOC Analyst L3
│   ├── SOC Analyst L2
│   └── SOC Analyst L1
├── Network Admin
│   ├── Network Engineer
│   └── Network Technician
├── Application Admin
│   ├── DevOps Engineer
│   └── Developer
└── Helpdesk Admin
    ├── Senior Helpdesk
    └── Helpdesk L1

Anti-Pattern 1 — Role Explosion:
  Problem: Creating a unique role for every user (defeats purpose of RBAC)
  Solution: Use groups + ABAC for fine-grained control, keep roles coarse

Anti-Pattern 2 — Orphan Roles:
  Problem: Roles created for projects, never removed after project ends
  Solution: Time-bound roles with expiry, annual role review

Anti-Pattern 3 — Permission Creep:
  Problem: Employees accumulate permissions through role changes, never lose old ones
  Solution: Quarterly access certification, remove unused permissions (90+ days)

Anti-Pattern 4 — Fat Roles:
  Problem: "Everyone gets everything" role to avoid access requests
  Solution: Start with minimal permissions, JIT elevation for additional needs

# Good: Base role with minimal permissions
Base-Employee:
  permissions:
    - email: read/write
    - intranet: read
    - hr-portal: read own data only

# Better: Role with time-bound escalation
Finance-Auditor:
  inherits: [Base-Employee]
  permissions:
    - financial-system: read
    - audit-logs: read
  constraints:
    - duration: 90 days
    - requires: manager approval for renewal

Phase 1 — Audit existing privileged access:
  └─ List all users with privileged roles (Domain Admin, AWS Admin, Azure Admin)
  └─ Identify permanent privileged access that should be JIT
  └─ Discover privileged service accounts (non-human)

Phase 2 — Pilot JIT for critical roles:
  └─ Enable Azure AD PIM for Global Administrator role
  └─ Require MFA + justification for elevation
  └─ Set max elevation duration: 4 hours

Phase 3 — Expand to all privileged roles:
  └─ All admin roles use JIT (cloud, on-prem, applications)
  └─ Service accounts: use short-lived tokens (AWS STS, Azure Managed Identity)
  └─ Emergency break-glass: offline, audited, time-limited accounts

Phase 4 — Continuous verification:
  └─ Monitor: Any permanent privileged access is a finding
  └─ Certify: Monthly review of JIT activation requests
  └─ Automate: Remove users from privileged groups automatically

Filesystem ACLs:
  └─ Avoid recursive permissions where possible (set at root + inherit)
  └─ Use groups, not individual users (manage group membership, not ACLs)
  └─ Document ACL changes (who changed what, when, why)
  └─ Audit ACLs quarterly (find and remove excessive permissions)
  └─ Prefer RBAC over filesystem ACLs for shared resources

Network ACLs:
  └─ Default deny (whitelist model — allow specific, deny everything else)
  └─ Stateful firewalls are preferred over stateless ACLs
  └─ Review and remove unused rules (stale allow rules are security holes)
  └─ Order rules: most specific first, least specific last
  └─ Use change management for all network ACL modifications

// BAD: No server-side authorisation check
app.get('/api/user/:id', (req, res) => {
  const user = db.findUser(req.params.id);
  res.json(user);  // ❌ Any authenticated user can access any user's data
});

// GOOD: Server-side authorisation check
app.get('/api/user/:id', (req, res) => {
  const requestingUser = req.user;
  const targetUser = req.params.id;

  if (requestingUser.role !== 'admin' && requestingUser.id !== targetUser) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  const user = db.findUser(targetUser);
  res.json(user);  // ✅ Only admins or the user themselves can access
});

# BAD: Relying on UI hiding for access control
@app.route('/api/admin/users')
def admin_list_users():
    # ❌ No server-side role check!
    users = db.query("SELECT * FROM users")
    return jsonify(users)

# GOOD: Centralised authorisation decorator
@app.route('/api/admin/users')
@require_role('admin')  # ✅ Server-side check
def admin_list_users():
    users = db.query("SELECT * FROM users")
    return jsonify(users)

Centralised Authorisation (Recommended):
  └─ All API requests pass through an authorisation gateway
  └─ Policy Decision Point (PDP): Evaluates access policies
  └─ Policy Enforcement Point (PEP): Enforces the decision
  └─ Tools: OPA (Open Policy Agent), AuthzForce, AWS Verified Permissions

Decentralised Authorisation:
  └─ Each service implements its own authorisation checks
  └─ Consistent policy is harder to maintain
  └─ Suitable for: Small teams, simple applications
  └─ Risk: Inconsistent enforcement, gaps in coverage

Fine-Grained Authorisation (FGAC):
  └─ Row-level security in databases
  └─ Attribute-based policies
  └─ Example: "User can view orders they created OR orders assigned to their team"
  └─ Tools: PostgreSQL Row-Level Security, AWS Cedar