In Identity and Access Management (‘IAM’), service accounts refer to the accounts that are not tied to any individual users and are typically used by applications, services or devices to interact with resources, execute scripts, cloud service API and perform specific tasks. These accounts should not generally be deleted.

For example, a service account has assigned with permission to read data from the ERP source system to IAM.

Like any user accounts, service accounts can be granted with specific entitlements or permissions to perform the designated task. This allows administrators to control and govern what the service account can or cannot access.

Challenges with service accounts

Managing service accounts is a significant challenge for many organizations due to several factors:

• The large number of unstructured service accounts, which are difficult to manage within a unified system.
• The continuous growth of such accounts, with no or limited control over the creation of unnecessary new accounts.
• Lack of insight on the purpose of such accounts and uncertainty about the potential impact on the system, leading organizations to keep these accounts active and unmanaged.
• Difficulty in identifying account owners, leading to challenges in conducting access reviews and transferring ownership.
• Concerns about the privileged access these accounts often possess, and the inability to effectively monitor their activities.

This blog will explore how to onboard service accounts as Identities in SailPoint IdentityIQ (‘IIQ’), effectively control and manage their access within an organization and ensuring minimal risk.

Onboarding service accounts

Most organizations manage and maintains service accounts in a single IT system (e.g., a dedicated AD or LDAP to manage all service accounts in the organization) or in individual IT systems (e.g., ERP specific service accounts in the ERP system). In either case, we can onboard the service accounts as Service Identities into IIQ. This is easier way to manage service accounts rather than managing it as accounts for Human Identities.

SailPoint has a large number of Out of The Box (‘OOTB’) connectors and also support the common generic protocol-based integrations. To onboard service accounts as Identities, identify the IT system(s) managing the service accounts in the organisation and onboard it into IIQ using the appropriate connector. The service accounts should be then aggregated with all available details and set up as a Service Identities in IIQ.

Note: Each service account should have ownership details. It will be helpful to map the service account ownership to a Human Identity in IAM to facilitate access request approval as well as access certification of the service account. The owner is usually also responsible for administrating the account and re-assign the ownership when the owner is leaving the organization or changing job roles).

Managing access for service accounts

Birthright Access

Similar to Human Identities, the birthright access assignment can be configured for the Service Identity to provide such service accounts with appropriate and timely access.

Access Request

Requesting access for Service Identities is no different than Human Identities. Once the Service Identity is ready in IIQ, access for such Service Identity can be requested using usual IIQ functionalities available for Human Identities. The service account owner is usually mapped as the Manager for the Service Identity and may be used for access request approval. The Manager settings in IIQ can also be used to control request authority and restrict others from creating requests.

Service Identity Governance

Risk Evaluation

The risk score highlights the critical access an account holds and helps determine whether the account should retain access. The risk scores for Service Identities can be assessed based on the access, along with the risk configurations at both the account and entitlement levels.

Access Review/ Certification

A differential certification campaign can be initiated for Service Identities to manage, restrict, and audit their access. The service account owner (i.e., the Manager) can periodically review the access and either approve or revoke it. Any access that is revoked can be automatically deprovisioned from the service account by IIQ.

The access review for service account should typically be performed more frequently than user accounts for human due to its sensitive nature.

Segregation of Duties

Just like Human Identities, Service Identities should also follow the organizational policies, for example related to Segregation of Duties (‘SoD’). A policy violation on the Service Identity highlights access to conflicting access. The action taken (Allow or Revoke) to resolve the violation can be audited, ensuring the account has the right access based on its business purpose.

Managing service account ownership

Service Identity ownership is important for access approval as well as certifying the entitlements. When the owner moves or leaves the organization, there is a risk that these service accounts may be left unmanaged. In IIQ, such situations can be easily addressed using change/ mover events, allowing the ownership to be transferred to another user and preventing the Service Identity from becoming orphaned.

Conclusion

Effective management of service accounts is crucial for maintaining compliance, security, and uninterrupted operations within an organization. With SailPoint IIQ, organizations dealing with service accounts can easily set up and configure Service Identities, ensuring that service account is always up to date, guaranteeing full ownership accountability and enabling appropriate access requests workflow. It also and supports regular access reviews to ensure service accounts have only the minimal and necessary access, while maintaining audit trails.

By implementing these service account management strategies, an organization can protect its critical systems, reduce vulnerabilities and risk exposure, and ensure that its systems remain secure and compliant.