SERVICE ACCOUNT STANDARDS
Service Accounts generally have greater access to IT systems and resources and may pose a higher risk to the university. Follow these standards to minimize the overall risk of using these accounts.
One for One
Every Service Account is to be associated with one team who is responsible for the use and management of the account.
Unique Password
Service Accounts must use a different password from other accounts. Passwords must meet the criteria outlined in the password standard. Passwords should not be "hard-coded"; they should be stored in the system’s secret management mechanism.
Note: Change vendor or default passwords immediately upon initial configuration of the system.
Limit Login Options
Where the capability exists, limit interactive login capabilities (e.g., prohibit console/terminal access, configure restricted shell, enforce network access restrictions, etc.).
Least Privilege
The privileges of a service account must exist independent of the privileges of a human user (e.g., if your admin's permissions change, does your system still have the permissions it needs to function?).
See the Principle of Least Privilege below.
What is a Service Account?
A Service Account is a non-person account. This type of account is used by a system or application rather than by a person. The Service Account allows the system for which it was created to authenticate systems in order to access data, run processes, or perform actions on the other system.
Examples of Service Accounts
These include, but are not limited to:
-AWS roles/users
-Linux/Windows process users
-Database users
-API "OAuth" clients
-SAML integrations
-System SMTP accounts
-Humio tokens
Principle of Least Privilege
Each subject in a system should only be granted the privileges needed for the performance of authorized tasks, and not excessive or unrelated permissions. The application of this principle limits the damage that can result from accident, error or unauthorized use.