Least Privilege (Prinzip der minimalen Rechtevergabe)

Least Privilege is one of the fundamental security principles—and at the same time one of the most frequently violated. In practice, accounts accumulate permissions over the years, developers have production access, and service accounts run as domain administrators. This guide shows what true least privilege looks like.

Why Least Privilege Is So Important

A concrete attack scenario illustrates the difference:

Without Least Privilege: A phishing email reaches accountant Maria. Malware installs itself on her workstation. Since her account is a member of “Domain Users” and “IT Support” (someone added her for a ticket), the malware moves laterally using Maria’s permissions. It reaches the file server containing customer data, the test environment with admin access, and from there, the production environment.

With Least Privilege: The same phishing email reaches Maria. Malware installs itself on her workstation. Maria’s account only has access to the accounting share. The malware cannot proceed further. It remains an isolated incident without significant data loss.

Conclusion: Least privilege drastically limits the blast radius of an attack.

Common Least Privilege Violations

The following issues occur in almost every Active Directory environment:

1. Too many domain admins: In reality, there are 20 or more accounts in the “Domain Admins” group. There should be a maximum of 3–5 dedicated admin accounts—never standard user accounts.

2. Service accounts with Domain Admin: The statement “The SQL Server needs Domain Admin rights” is incorrect. SQL Server only needs the right to start and stop its service, as well as access to its own databases.

3. “Domain Admin for a ticket”: “I’ll give you admin rights for a moment so you can fix this yourself”—those rights are never revoked. This is the root of privilege creep.

4. Developer rights in production: “We sometimes need access to the production database for debugging” is not a valid argument for permanent production rights. The solution is dedicated read-only access, time-limited and fully logged.

5. Local Admin on Workstations: Having all users as local administrators means malware can install itself. The solution: Standard user accounts plus LAPS (Local Administrator Password Solution) for local admin passwords.

Implementation in Active Directory

# Who is in Domain Admins? (Audit)
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object {$_.objectClass -eq "user"} |
    Select-Object Name, SamAccountName, @{N="LastLogon";E={(Get-ADUser $_.SamAccountName -Properties LastLogonDate).LastLogonDate}} |
    Sort-Object LastLogon

# Find inactive Domain Admins
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties LastLogonDate, Enabled |
    Where-Object {$_.LastLogonDate -lt (Get-Date).AddDays(-90) -or !$_.Enabled} |
    Select-Object Name, LastLogonDate, Enabled

# Accounts in too many groups (Privilege Creep)
Get-ADUser -Filter * -Properties MemberOf |
    Select-Object Name, @{N="GroupCount";E={$_.MemberOf.Count}} |
    Sort-Object GroupCount -Descending |
    Where-Object {$_.GroupCount -gt 10}  # > 10 groups = warning sign

# Just-In-Time Admin via PAM (Entra ID)
# In Azure AD: Privileged Identity Management (PIM)
# Admins must activate roles → active only for a limited time
# All activations are logged and require approval

Least Privilege for Applications

Database Users

-- PostgreSQL: Read-only app account
CREATE USER appuser WITH PASSWORD '...';
GRANT CONNECT ON DATABASE myapp TO appuser;
GRANT USAGE ON SCHEMA public TO appuser;
GRANT SELECT ON customers, orders, products TO appuser;
-- NO INSERT/UPDATE/DELETE unless necessary!

-- Write-only for logs
CREATE USER logwriter WITH PASSWORD '...';
GRANT INSERT ON audit_log TO logwriter;
-- No SELECT (cannot read logs)

Cloud IAM (AWS)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
    }
  ]
}

No wildcards (*) for Actions or Resources—every permitted action is explicitly listed.

Kubernetes Service Accounts

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payment-processor-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get"]  # Read-only, no write/delete!
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
  resourceNames: ["payment-api-key"]  # ONLY specific secret!

Zero Standing Privileges (ZSP)

The Difference from Traditional Approaches

Traditional (Standing Privileges): The admin always has access to production—a constant attack surface. If the account is compromised, the attacker has immediate access to production.

Zero Standing Privileges: The admin has no permanent privileges. When access is needed, they submit a request that is approved and time-limited. Upon expiration, the privileges are automatically revoked.

Tools for ZSP

Microsoft Entra PIM (Privileged Identity Management): Activation of admin roles with time limits, subject to approval, and requiring MFA. All activations are fully logged.

CyberArk PAM (Privileged Access Manager): Session recording of all admin sessions and just-in-time credentials for Windows and Linux.

HashiCorp Vault: Dynamic Secrets generate database credentials on demand—they expire automatically after use. There is no longer a static database password that could be stolen.

AWS IAM Access Analyzer: Analyzes who can access what and identifies unusual or excessive permissions.

Least Privilege Roadmap

Short Term (1–4 Weeks)

• Reduce domain admins to a maximum of 5 accounts
• Remove local admin rights on workstations and set up LAPS
• Identify service accounts without domain admin rights
• Deactivate inactive accounts

Medium Term (1–3 Months)

• Implement Role-Based Access Control (RBAC)
• Privilege creep audit: review all group memberships
• Restrict application database accounts
• Conduct a cloud IAM audit: identify overly broad policies?

Long-term (3–12 months)

• Introduce a PAM solution for privileged access
• Implement just-in-time access for administrative tasks
• Use dynamic secrets for applications (HashiCorp Vault)
• Introduce regular access reviews (quarterly)
• Implement a zero-trust network architecture