Editare

Governing Microsoft Entra service accounts

  • Articol

There are three types of service accounts in Microsoft Entra ID: managed identities, service principals, and user accounts employed as service accounts. When you create service accounts for automated use, they're granted permissions to access resources in Azure and Microsoft Entra ID. Resources can include Microsoft 365 services, software as a service (SaaS) applications, custom applications, databases, HR systems, and so on. Governing Microsoft Entra service account is managing creation, permissions, and lifecycle to ensure security and continuity.

Learn more:

Note

We do not recommend user accounts as service accounts because they are less secure. This includes on-premises service accounts synced to Microsoft Entra ID, because they aren't converted to service principals. Instead, we recommend managed identities, or service principals, and the use of Conditional Access.

Learn more: What is Conditional Access?

Plan your service account

Before creating a service account, or registering an application, document the service account key information. Use the information to monitor and govern the account. We recommend collecting the following data and tracking it in your centralized Configuration Management Database (CMDB).

Data Description Details
Owner User or group accountable for managing and monitoring the service account Grant the owner permissions to monitor the account and implement a way to mitigate issues. Issue mitigation is done by the owner, or by request to an IT team.
Purpose How the account is used Map the service account to a service, application, or script. Avoid creating multiuse service accounts.
Permissions (Scopes) Anticipated set of permissions Document the resources it accesses and permissions for those resources
CMDB Link Link to the accessed resources, and scripts in which the service account is used Document the resource and script owners to communicate the effects of change
Risk assessment Risk and business effect, if the account is compromised Use the information to narrow the scope of permissions and determine access to information
Period for review The cadence of service account reviews, by the owner Review communications and reviews. Document what happens if a review is performed after the scheduled review period.
Lifetime Anticipated maximum account lifetime Use this measurement to schedule communications to the owner, disable, and then delete the accounts. Set an expiration date for credentials that prevents them from rolling over automatically.
Name Standardized account name Create a naming convention for service accounts to search, sort, and filter them

Principle of least privileges

Grant the service account permissions needed to perform tasks, and no more. If a service account needs high-level permissions, for example a Global Administrator, evaluate why and try to reduce permissions.

We recommend the following practices for service account privileges.

Permissions

Get-MgDirectoryRoleMember, and filter for objectType "Service Principal", or use
Get-MgServicePrincipal | % { Get-MgServicePrincipalAppRoleAssignment -ObjectId $_ }

  • See, Introduction to permissions and consent to limit the functionality a service account can access on a resource
  • Service principals and managed identities can use Open Authorization (OAuth) 2.0 scopes in a delegated context impersonating a signed-on user, or as service account in the application context. In the application context, no one is signed in.
  • Confirm the scopes service accounts request for resources
  • Ensure you trust the application developer, or API, with the requested access

Duration

  • Limit service account credentials (client secret, certificate) to an anticipated usage period
  • Schedule periodic reviews of service account usage and purpose
    • Ensure reviews occur prior to account expiration

After you understand the purpose, scope, and permissions, create your service account, use the instructions in the following articles.

Use a managed identity when possible. If you can't use a managed identity, use a service principal. If you can't use a service principal, then use a Microsoft Entra user account.

Build a lifecycle process

A service account lifecycle starts with planning, and ends with permanent deletion. The following sections cover how you monitor, review permissions, determine continued account usage, and ultimately deprovision the account.

Monitor service accounts

Monitor your service accounts to ensure usage patterns are correct, and that the service account is used.

Collect and monitor service account sign-ins

Use one of the following monitoring methods:

Use the following screenshot to see service principal sign-ins.

Screenshot of service principal sign-ins.

Sign-in log details

Look for the following details in sign-in logs.

  • Service accounts not signed in to the tenant
  • Changes in sign-in service account patterns

We recommend you export Microsoft Entra sign-in logs, and then import them into a security information and event management (SIEM) tool, such as Microsoft Sentinel. Use the SIEM tool to build alerts and dashboards.

Review service account permissions

Regularly review service account permissions and accessed scopes to see whether they can be reduced or eliminated.

Recertify service account use

Establish a regular review process to ensure service accounts are regularly reviewed by owners, security team, or IT team.

The process includes:

  • Determine service account review cycle, and document it in your CMDB
  • Communications to owner, security team, IT team, before a review
  • Determine warning communications, and their timing, if the review is missed
  • Instructions if owners fail to review or respond
    • Disable, but don't delete, the account until the review is complete
  • Instructions to determine dependencies. Notify resource owners of effects

The review includes the owner and an IT partner, and they certify:

  • Account is necessary
  • Permissions to the account are adequate and necessary, or a change is requested
  • Access to the account, and its credentials, are controlled
  • Account credentials are accurate: credential type and lifetime
  • Account risk score hasn't changed since the previous recertification
  • Update the expected account lifetime, and the next recertification date

Deprovision service accounts

Deprovision service accounts under the following circumstances:

  • Account script or application is retired
  • Account script or application function is retired. For example, access to a resource.
  • Service account is replaced by another service account
  • Credentials expired, or the account is non-functional, and there aren't complaints

Deprovisioning includes the following tasks:

After the associated application or script is deprovisioned:

  • Sign-in logs in Microsoft Entra ID and resource access by the service account
    • If the account is active, determine how it's being used before continuing
  • For a managed service identity, disable service account sign-in, but don't remove it from the directory
  • Revoke service account role assignments and OAuth2 consent grants
  • After a defined period, and warning to owners, delete the service account from the directory

Next steps