What is a shared account?
The simplest definition of a shared account is: a privileged account in an organization that multiple employees co-use. A shared account can be used for applications, services, impersonation, scheduled tasks, or common asset access. Organizations do not need to use shared accounts—it’s a choice based on their unique requirements and the potential fit for their IT environment
How to Leverage Shared Accounts to Improve IT Administration
Shared accounts can be leveraged within an environment to help support enterprise or application roles. When used properly, shared accounts can considerably reduce the overhead of management, entitlements, and compliance. However, to reap the benefits of shared accounts, while ensuring proper use and auditing, certain control mechanisms, namely privileged access management (PAM), must be in place.
When IT and security teams hear the term “Shared Accounts,” it tends to raise red flags. It may conjure up the notion of accounts that people have or own and for which they share the password with fellow co-workers on a yellow sticky, by email, or some type of messaging system. However, this is a misconception of what we are talking about with shared accounts. Instead, shared accounts should be thought of like any other privileged identity within an organization and treated like any other named privileged account.
Similar to how service accounts are treated, shared accounts should follow a common framework for provisioning, attestation, and fulfillment. The variance in this is that, instead of shared accounts being tied back to an individual user or identity as the owner, the privileged identity should be tied to a department, application team, or organization within an enterprise. These teams should have a common access model across the team for systems or assets they frequently access.
When shared accounts are used and their access rights apply to specific assets or applications for access, and those shared accounts are used in conjunction with a privileged password management solution, the administrative overhead is greatly reduced. This overhead reduction encompasses provisioning each individual user’s access, granting rights to that user’s privileged account, attesting each of the individuals’ account, and having an excessive security footprint by having multiple accounts for each user across assets or applications. Instead of having multiple, if not hundreds, of privileged accounts with privileged access rights to assets, you can replace that common access with one or more shared accounts, which can be leveraged for the exact same access. This reduces the overall access footprint by not having individual users with logon rights.
Leveraging a PAM Solution for Shared Accounts
A PAM solution can simplify the management, control, audit, entitlement, and compliance needs around the shared account. Then, by layering on a session-based only approach for shared account usage, you can achieve further control and improvements across these areas. A session-based only approach with shared accounts means shared accounts can only be used to log into assets they have rights to through a controlled session from the privileged access management solution. In this approach, the shared account rights should always remain static—in other words, the account should never gain or lose additional rights or access.
Applying static account rights helps simplify the attestation processes. The session-only based approach now pivots the common process of granting individual users access rights to assets, and instead, you now control which privileged users gain access to the shared account. This can be accomplished through localization on a PAM solution using local groups, or within directory services using a roles group that the solution can be bound to for users who need access to the shared account. Overall, the management now shifts to controlling who has access to the shared account versus who has access to several, if not hundreds, of assets.
The Risks & Challenges of Using Shared Accounts
Shared accounts don’t fit every use case. While leveraging shared accounts can effectively minimize administrative overhead, while also reducing the overall identity footprint related to access within an organization, they’re not always the right fit for an IT environment.
Shared accounts can require high levels of attention as a result of them being shared across teams, departments, or organizations. As people leave or move to different departments, a mature attestation process must be adhered to in order to ensure only the right people, within the right context, can access the account.
Shared accounts also contribute to auditing and forensics complexity. When multiple privileged users share the account and log into assets, the asset security logs reflect a common, shared username. Achieving a clean audit trail tying individual users to their actions requires an additional step. This is another critical use case for PAM solutions, which should be able to provide a clean audit trail for who checked out the account, along with full session activity details. Some organizations see this additional step as a hinderance when trying to perform analysis, while others find it a worthwhile tradeoff to benefit from the ease of administration when using shared accounts.
Many organizations simply won’t even consider using shared accounts because they fear a clean audit trail cannot be produced. Of course, some organizations may lack the mature identity management and PAM processes necessary to effectively and safely benefit from a shared account implementation.
Another concern with using shared accounts is that, in certain situations, password rotation timelines could be drastically increased as a result of multiple checkouts spanning beyond a typical checkout period. Therefore, it’s critical to control the concurrent checkouts of shared accounts to minimize that potential security risk. A prime example would be user A performs a session checkout of the shared account at 8 a.m. for 12 hours, user B performs a checkout at 4 p.m. for 12 hours, user C performs a checkout at 2 a.m. for 12 hours. Due to the series of checkouts that have overlapped each other with users A, B, and C within a 24 hours period, the password has remained in a checked-out state. As a result, the password cannot be rotated without causing a logon issue to one or more of the users, or by forcing one or more of the users to retrieve the updated password again if the password was reset. Instead, the password is not changed or rotated until the last person in the overlapping checkouts has canceled their request, or their request expires. As you can see, this can invoke concern around security practices. Ensuring you control the concurrent checkout state related to shared accounts should be examined closely in situations like these.
Best Practices for Successful Use of Shared Accounts
Shared accounts should be purpose-built and have a clearly defined role within an organization. They should be used for common access with application teams, departments, or other specific access roles within an organization. The amount of shared accounts can only be determined by the number of users requiring access to them and how frequently they will each need to use it. Each organization will be different depending on their administrative needs, team size, and frequency of use. Where it makes sense, multiple shared accounts can be provisioned with “like” access to share the load of usage.
Shared accounts can provide some impactful benefits to organizations looking to simplify their provisioning overhead and reduce their identity footprint on assets. However, shared accounts should only be used in conjunction with a PAM solution so that it can provide a means to control, secure, and audit the shared accounts, while also providing a reporting platform for entitlements and compliance.
