What are Role Accounts?
Role accounts are accounts that are tied to a particular role in your organization (i.e. group of employees or an automated system) rather than an individual. They are often used to automate tasks and streamline data flows.
For instance, if your HR system needs to talk to the Payroll system, you might set up an ‘hr’ user in the Payroll system to automate credentialing. You can then check the logs to see when the ‘hr’ role account accesses the Payroll system, thus bringing greater visibility into access patterns. Additionally, you know that the traffic caused by ‘hr’ isn’t individual user traffic so you can filter it out when scanning for irregular login behaviors. This can both save time on your workflows and improve security.
However, there are some downsides. Issues arise when you start using role accounts improperly with systems that require an identity. Sharing a role account between multiple employees as a multi-use login for a vendor (e.g. ‘vendor-name@mystartup.com’), or using the ‘ubuntu’ user on a cloud hosted linux host, or using the ‘Administrator’ account on our Windows servers, would all be examples of using role accounts against best practices. These are all systems where using a unique identity is important and sharing a role account compromises security.
Some Role Account Examples
When you use a role account in these systems, you lose the ability separate traffic. Access logs become clouded and opaque.
As an example:
Your logs show that user ‘ubuntu’ logged in at 04:32:15 and executed the 'rm -rf *'/command. However, you have no visibility into which of your engineers actually executed the command because they were using a shared role account!
Another example:
All of your Account Reps log into your hosted CRM (Customer Relationship Manager) as ‘vendor-name@mystartup.com’ because it’s much cheaper to only have one account and allows for greater transparency among the team. However, you can’t see who did what, just that it was done.
These are just the administrative and accountability issues. The real danger from misuse of role accounts comes from weakened security. When you use these types of shared role accounts, credentials need to be rotated every time someone leaves the team and those new credentials need to be redistributed to everyone that needs access. This is a labor intensive and manual process that is prone to mistakes.
Common Pitfalls
You can mitigate problems with shared role accounts by using good hygiene and utilizing unique assets to access the role account, but ultimately you are still obfuscating identity. Setting up ‘ec2-user’ and ‘Administrator’ accounts to use unique keys or certificates that grant individual access to role accounts is better, but still only a partial solution.
Trusting your employees and coworkers is an important part of any security system. However, anytime you add someone to the team you’re adding multiple attack vectors on the resources that person has access to. When you are using role accounts, all of those vectors are concentrated on a single target. So an attacker now has multiple ways to attack the same set of credentials. Additionally, this limits your remediation options when an attack is successful. You can’t simply shut down the role account as you’d be shutting off access for the entire team.
Another issue arises when team members leave your organization. When your sales intern finishes their term and still has access to your entire CRM, it’s more than just taking their Rolodex with them, it’s taking everyone’s Rolodex with them. If your lead engineer leaves the team, they still have the private key for your ‘ubuntu’ user role account on their personal laptop. An if that ex-employee goes to work for a competitor, they can maintain ongoing access into your infrastructure undetected.
The Right Way Forward
All of these problems can be addressed by having specific identities for each person accessing your tools. Your logs will become clearer and your ability to know who does and doesn’t have access to systems will become well defined. Granting and revoking privileges becomes a simple task and is easily audit-able. Plus, your CEO and security team can sleep better at night knowing that no one outside the company is wreaking havoc in your systems.
Traditionally, you’d need a unique identity on every system you wanted to use to avoid the use of role accounts. Every host you wanted to log into and every vendor you wanted to access would need unique accounts for every employee. However, this just adds to the on/off-boarding workflow and can easily be forgotten. This is where Identity Management solutions come to the rescue. By having a central identity source that all other systems can integrate with, you can have permissions granted or revoked with one-click. With protocols like OAuth and SAML combined with tools like LDAP and AD, you can get comprehensive identity across multiple platforms. You can build it yourself or use vendor supplied solutions. Let the individuals on your team shine by giving everyone their own identity.
At Foxpass, we help you maintain best security and operational practices by making it easy to maintain separate user accounts. We even automate account creation and deletion by syncing with your identity provider (Google, Office365, Okta, OneLogin, or Bitium). We also offer temporary access features that automatically revoke access after a set period of time. Also, our cloud hosted servers free you from dealing with a DIY LDAP or RADIUS server.
What are you waiting for? Start a free 30 day trial today!
.png)
