Use Case: Cleaning up unused and risky accounts on your cloud platforms
The first step in securing your cloud platforms is to catalog all existing accounts and prune any that are unused or too risky to maintain. Although the goal is simple enough, our customers have shown that it requires a methodical process with the team working together over several months to get it right. Deleting AWS service accounts could cause an infrequently running process to suddenly break; auditors may still need information about an account; and deleting a Google Workspace account could lead to loss of email or documents that belong to the company and need to be retained. Here are some guidelines for improving account hygiene in your cloud platforms.
Step 1: Discovery
Gaining visibility of all accounts in your systems can be a bit tricky for IT and security teams; that’s because the sources of these accounts are very distributed. For most organizations, only a portion of the accounts are known and managed through the identity provider (IdP), such as Okta or Google, and those teams also likely don’t have sufficient access to cloud management consoles like AWS IAM to discover unauthorized accounts. Teams working on cloud platforms often create and manage accounts, which may then be issued to contractors (who aren’t in the corporate directory) or the accounts could be used to run services and tests. If the teams haven’t been diligent about naming conventions, the names on these accounts will likely be arcane and inscrutable.
Another major obstacle to making sense of accounts on cloud platforms is that the accounts are often not just a simple 1-to-1 mapping with owners. That is to say, a single user may own dozens of accounts on a single platform and, conversely, a single account hay have dozens of users. Access to an account such as the Root user (of which there is only one) is often of necessity shared with a group.
<<Sabrina: Let's get an image of 1-to-many and many-to-one and shared here>>
Trustle connects to cloud platforms, builds a full list of accounts, and then identifies unused and risky accounts.
- NOTE: It’s a good idea to run a report once you first connect to a system, so you’ll have a baseline to compare against as you begin cleaning out unauthorized and unneeded accounts.
Step 2: Flag accounts that require review
Trustle includes a recommendation engine, and one of the first recommendations you’re likely to see after connecting a system is to Flag Accounts that we see as risky and needing review. Why do we do this? There are several reasons:
- Usage Data - One of the heuristics we use to identify abandoned accounts is simply the last activity on the account. However, in the process of researching what the account is used for or capturing any data held by the account, you may need to log into the account–even if only to reset the password. This mutates the usage data, so you won’t necessarily know whether it was a person researching the account or the account has suddenly sprung back into action.
- Teamwork - You may need to get others on your team to help you identify owners of accounts and document any findings or actions taken. Trustle makes it easy for team members to view these flagged accounts, capture notes and metadata, and assign cleanup tasks, especially for flagged accounts.
- Reporting - You can easily view, export, and report on flagged accounts.
Step 3: Find the owners and document what accounts are used for
Finding owners of unused accounts present several problems: the owner may have left the organization, it can be unclear which manager is responsible for the account currently; the account may have several owners; many accounts may have the same owner; access to the account may be shared across a team. All told, it will likely require learning a significant amount of oral tradition to figure out where the account originated and why, and who the current owner is or should be. Ideally, logs such as Cloud Trail date back far enough to give you information about the creation of the account.
As you discover information, regardless of the source, it’s a good idea to to document all your actions in Trustle. To do that, you’ll need to link the account to a user in Trustle, because that will be the way Trustle maintains the account's history, and aslo record any notes the investigation uncovers. One of the great features of Trustle, is that you can capture any any-to-any interactions while linking accounts to their owners.
<<screen shot of linking many to one / one-to-many>>
If the owner is still working with your organization, it’s also a good idea to link the account to the actual owner, even if you plan to delete the account. Trustle retains account history indefinitely, even after the account is removed, and the history will likely be required at a later time. You can also notate the account with justifiations for actions taken and capturing any disoveries made while investigating the account, effectively moving away from oral tradition an into documented history.
<<Sabrina: a mockup of the History page with fake names, dates, & comments>>
Step 4: Take actions to preserve anything that’s required
Before deleting an account of any type, it’s important to think through audit, legal, regulatory, and security obligations that may require you to preserve information related to or held by the account. There are several online guides to help you take appropriate action on Google Workspace, AWS, and any other cloud platform or service.
Also, it’s not always apparent which accounts are for humans and which are used for services, scripts, and tests–AWS is particularly notorious for this. Trustle enables you to capture that metadata and specify what the function of each account is. You should definitely record this, even if you plan to later delete the account.
Step 5: Deactivate or Delete the accounts
When you’re ready to deactivate or delete the account, it’s a good idea to record that in your companies ticketing system, such as Jira or ServiceNow. Trustle retains all of your team’s work, notes, and history, even after the account is deleted.
