SERVICE ACCOUNTS

PURPOSE

SCOPE

POLICY BASIS

Examples of Service Accounts

• 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.

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. Examples include prohibiting console/terminal access, configuring a restricted shell, and enforcing network access restrictions.

Least Privilege

• The privileges of a Service Account must exist independent of the privileges of a human user.
• Each subject in a system should only be granted the privileges needed for the performance of authorized tasks, and not excessive or unrelated permissions.

Supported Monitoring Options

• The Security Operations Center (SOC) and Identity Portfolio recommend the following supported options for monitoring service uptime and functionality:
• Service can report to an API provided by the Monitoring team or service its status, including uptime and/or proper function. This is defined by the SOC as the canary page approach.
• The monitoring service can invoke a specific API provided by a service to be monitored that provides status, including uptime and/or proper function.
• The monitoring API should only allow configured access to reporting services and employ approved programmatic authentication approaches, such as OAuth 2.0.
• The service API should only allow the monitoring service access to the API and should employ approved programmatic authentication approaches, such as OAuth 2.0.

Note: To align with the least privilege security principle, when the monitoring service invokes a specific service API for monitoring information, create a separate client ID/secret or service account specifically to access the service API to gather monitoring information. The monitoring team or service should not reuse a single service account, such as the mondem service account, to access all services to gather status or other monitoring information.

GUIDELINES

1. Create a Service Account only when necessary to perform a specific function.
2. Assign every Service Account to one team responsible for its management.
3. Use a unique password that meets the password standard. Change vendor or default passwords immediately upon initial configuration.
4. Never hard-code passwords. Store passwords in the system's secret management mechanism.
5. Limit interactive login capabilities where the capability exists.
6. Grant only the privileges needed for the performance of authorized tasks. Avoid excessive or unrelated permissions.
7. For monitoring, create a separate client ID/secret or service account.

System or Application Owners
Ensure the Service Account can authenticate systems only as needed to access data, run processes, or perform actions on the other system. Comply with instructions from the Security Operations Center.

Security Operations Center
Manage breaches, compromises, or weaknesses and protect data or IT resources.

Monitoring Team or Service
Use configured access to reporting services, approved programmatic authentication approaches, and separate credentials created specifically to gather monitoring information.

COMPLIANCE & ENFORCEMENT

The Appropriate Use of Information Technology Resources Policy states:
The university reserves the right, in its sole discretion and for any reason or no reason, to immediately revoke authorization to access or use any or all IT Resources.

STANDARDS OWNERSHIP & REVIEW

IT Standards are developed by subject matter experts and approved by the Information Technology Committee, which consists of the CIO, the CISO, University Vice Presidents and other senior leaders.