How should I assign least-privilege access to a server?
Give each person and application only the permissions needed for its task. Separate routine work from administration and avoid shared administrator identities where individual access is supported. Least privilege applies to the customer account, server, database, deployment system and recovery tools.
Before you start
- An inventory of users, service accounts and the tasks each must perform.
Instructions
1. Map tasks to permissions
Distinguish viewing status, reading logs, deploying one application, managing billing and administering the operating system. Define the required resources and actions for each role. A person who needs to view one service should not automatically receive control of every server or customer account.
2. Use separate accountable identities
Create individual administrative access through the supported process and use dedicated application identities for automated work. Apply strong authentication appropriate to each system and protect emergency access. Review indirect privileges, such as access to a deployment secret or a container daemon that can affect the host.
3. Test and review the boundary
Verify that each role can perform its intended task and is denied unrelated tasks. Document exceptional access with an owner and expiry where supported. Recheck permissions when job duties, application architecture or support arrangements change, rather than allowing old privileges to accumulate.
Check the result
- Users and services can perform required actions while unrelated access is denied.
- Administrative operations can be attributed to an accountable identity.
Troubleshooting
- Removing a privilege breaks an application
- Identify the specific operation and account involved. Grant the narrow documented permission required rather than restoring unrestricted administrator access to every component.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.