How Cloud Platform Provisioning Differs from Personal Productivity Enablement

Although they are similar conceptually, provisioning cloud platforms differs significantly from enabling personal productivity apps for corporate users. For one, platforms like AWS make use of “non-human” (aka service) accounts to perform privileged actions. Teams also often consist of contractors and external auditors and other outside members with a higher turnover rate, possibly leaving those accounts unused and abandoned.

Also, as I described in a previous post, account ownership can be complex, because one person could own more than one account on the platform or the team could even own and manage a single account. In fact, many companies are moving to an architecture where no human accounts exist on their AWS.

Traditional provisioning products were built for personal productivity apps, and so often don’t provide the extra metadata or flexibility required to track and manage these accounts. This is where Trustle comes in—Trustle provides several features that make it ideal for provisioning in cloud platform environments. Here are a few: 

• First, a bulk import feature to link accounts accurately and quickly. This is critical, because many of the accounts don’t have a corresponding account in the company’s identity provider, such as Okta or Azure AD—again, because they are either external users or service accounts.

• Next, the ability to handle complex relationships, including many-to-one and many-to-many accounts to owners.

• Distributed management of systems and access.

• Also, the ability to establish the type of account the user represents. Currently, Trustle offers four types: Customer, System, Contractor, and Employee. Here's an overview of the user types in Trustle and what use cases they fulfill.

  

  • Employee: A person who has a direct contractual relationship with the company. This person will be in the HR system and in an identity provider (IdP), and therefore the company has rich information and a tighter trust relationship. The use cases to easily identify approvers for access request (managers, for example), ensuring the organization can attest to access during audits, and setting up and managing systems and resources.
  • Contractor: People who don't have a direct relationship with the company likely won't be responsible for systems or access management, but they often require periodic access changes, so will need to use the catalog to request them. Because they roll of projects or even work with multiple companies simultaneously, it's important to ensure just-in-time and temporary access polices apply. It's also easier to ensure that reduced access to AWS services or GitHub repositories are held to a minimum to reduce risks. Looking into the root cause analysis of hackers gaining access to repos (such as the Okta and Slack incidents, and many more), the cause is invariably API keys or tokens being stolen. Trustle helps you see where these keys need rotation. This is even more critical for contractors, since they could leave a project but keys would remain active.
  • System: System (sometimes called service or non-human accounts) are used by services to operate applications effectively. They are usually scoped to an application and therefore don't cover a broad portion of of the attack surface, but they do have elevated access to the application compared to human users. The difficulty with these accounts is that their usage is high, so just-in-time and temporary access schemes aren't applicable. But you can place extra scruitiny on rotating keys and ensuring that the access pattern is appropriate for its job. Some platforms don't expire keys automatically or inform you about expiring keys, even when an expiration date is set. So, keeping track of systems separately makes a lot of sense. Trustle helps you manage these types of accounts separately from the others.
  • Customer: Customer accounts usally have very scoped access, mainly just to their account in the app itself. So, it's critical to identify if any of these accounts have or could elevate their own access. This would likely indicate the account was taken over by a hacker, but as long as the account is properly scoped, the severity of a breach will also be scoped.

Putting it all together, it's critical to have an overview of the whole organization and how all of these factors work together, historically as well as currently. Information about Trustle users permeates the platform, but Trustle also provides a succinct view for the Admins and Org Owners.