Trustle > the Sum of IGA Parts

Bring up a novel ideal to an engineer in your organization and the likely response will be, "cool, we could totally build that!" But start getting nuanced about how the solution should function, how it must integrate with existing infrastructure, and how deep the dependencies on non-dev teams runs and the enthusiasm wanes. Throw in a 5-year maintenance requirement and the idea totally dies. Yet, the market we live in is that kind of Frankenproduct and we’re all trying to keep the monster alive. A little Identity Governance (IGA) here, some Jira glue there, that PAM product we used once in our very own datacenter, spreadsheets, plus a few screen shots of log files for the auditors—and viola! We’re done! ... well, done-ish. Several critical problems remain when pursuing the kludgey approach.

First, existing identity and access management (IAM) products don't provide sufficient flexibility for or native integration with cloud platforms to manage access properly. For example, cloud platforms often have more service accounts than individual (or "human") accounts. Some customers even tell us they're working to remove all human accounts from their AWS orgs. These service accounts (which are used by apps and services, not employees) don't show up in Active Directory, they don't have a manager in an org chart, and they ideally don't rely on usernames and passwords for authentication. Dozens of service accounts may be owned by the team developing the app, so it creates the need for understanding access management in a multidimentional way, such as:

• Many-to-one: A number of people share a single account (such as the Root account, or Role access in AWS)
• One-to-Many: An individual is responsible for many service accounts, in addition to any personal accounts the person has on the platform
• Many-to-Many: A team manages a set of service accounts that their app requires
• Person-to-Role: A team member access AWS by assuming a role (that is, a shared account with fixed access controls)

Traditional provisioning, IdM, and GRC products aren't suitable for handling these types of access relationships. There are many more such examples. For contrast, here's a comparison of how the design center of traditional access management differs from access management for cloud platforms:

A second problem with splicing together access solutions is that the security profile of the assets in the cloud is extremely high—that is, cloud platforms house the most valuable and risk-sensitive resources in your organization. A single account on a cloud platform can potentially access a broad number of databases, code repositories, and other assets (as was demonstrated in the recent hack on Uber). Even cloud native solutions run into this problem by either treating all cloud-based services with a one-size-fits-all approach or by solving only a portion of the overall access use case. Managing access to cloud platforms such as AWS or Azure requires a much different approach than managing basic onboarding of users to productivity and communications apps such as Slack, Dropbox, Office 365, and GMail. And providing only monitoring, or only visibility, or only workflow management leaves significant integration and maintenance tasks to the customer.

A third problem with stitching together purpose-specific solutions is the need to continuously modernize your security practices, from a known baseline, for each platform. As mentioned above, in the case of AWS, best practices are moving speedily toward a Roles-based approach and removing as many "human users" (as AWS refers to them) from the platform. Such ongoing architectural and procedural changes to cloud platforms are impossible to keep up with when pursuing a custom in-house solution or amalgamating a cadre of cloud components.

It’s time for a clean slate. It’s time to take on the realities of today’s—and ideally anticipate tomorrow’s—delivery modes. It's Trustle's mission to provide solutions to teams that complete the entirety of access management use cases for cloud platforms.