Council Post: Open Source Holds The Key To Unlocking Multicloud Identity Gridlock
Head of Standards for Strata Identity, former Burton Group analyst and technology executive at Chase Manhattan Bank (now JPMorgan Chase).
When it comes to facing the challenges of multicloud identity management, it helps to think of a map of the world divided between north and south and between east and west. On the one hand, access is divided east/west-style among the major cloud platforms—Amazon Web Services, Google Cloud and Microsoft Azure. On the north/south vector, however, there are distinct technology segments or categories such as applications, platforms, data and network layers.
Since each cloud platform uses its own proprietary identity system, we need a universal-style standard to orchestrate consistent access policy, north to south and east to west.
For most organizations, standardizing on one cloud platform is not an option for several reasons. While enterprises are adopting multicloud environments to spread their risk, certain technologies in one platform may not be available in another. Meanwhile, a given platform may be more cost-effective to run certain kinds of workloads.
Businesses would benefit from a policy format independent of all of these proprietary identity and access management systems so they can enforce consistent policies and maintain proper governance.
Meanwhile, the differences in the north/south technology stack create further silos and incompatibilities. For example, databases vary in how they filter and mask data based on policy. Even though most are based on some form of the SQL standard, there’s much variation in one vendor’s implementation versus another. Additionally, many non-SQL data systems are in use like API-driven BigQuery.
This north/south and east/west split poses a three-dimensional challenge for organizations since they need to unify security controls across multiclouds. From a policy perspective, it requires a generic declarative model that can address the widest range of use cases across a variety of technologies and vendor systems. In essence, something that’s expressive in near-natural language—something almost human-readable, if you will.
Amid all of this fragmentation, a standard based on open-source code holds the most promise—especially since most systems today use publicly available APIs for policy management and configuration.
Here are three of the main functions that an open-source identity orchestration standard can perform: discover, translate and orchestrate.
• Discover a public API to connect with the target system. Luckily, there are a number of systems that publish APIs for this functionality. The “discover” process determines what resources are installed and what policies already exist for those resources.
• Translate the discovered access policies into a declarative policy format designed to cover as many of these use cases as possible.
• Orchestrate policy changes using the open-source protocol that can bidirectionally translate and push instructions into a format understood by the sender and target systems—regardless of the original policy format used by each system.
This type of open-source standard with a declarative policy can save time and cost. It makes it easier for administrators to run reports on which users have access, and it normalizes the differences in policy formats from all of the target systems into a single format.
It can also bring greater consistency in policies. If an enterprise has 10 different systems with different kinds of policies, an open-source standard creates a universal language to orchestrate policy changes. This also means less reliance on manual configuration and less chance for human error.
A standard that combines the open-source orchestration and publicly available APIs of cloud systems can immediately bring policy orchestration to any cloud platform without requiring changes to be made by the platform owner. There’s no need to wait for product managers to analyze a new policy specification and figure out when it’s going to fit into their product backlog. This was one of the reasons for the slow adoption of the SAML identity federation standard 20 years ago. Today, we can bring this new standard to cloud platforms from the outside, and that’s a huge difference.
One new industry initiative we’ve co-authored called Identity Query Language (IDQL) is attempting to remove the identity silos that exist in multicloud environments without forcing platform providers and enterprises to make changes to their code base or rewrite applications. While the project is in its early stages, there are steps that organizations can take to be prepared:
• Identify the critical gaps in your access management. For example, are there particular cloud providers or services that are more difficult for you to manage or report on? You should focus on the standardization of those components in your infrastructure.
• Compile an inventory of the different access policy models used today. This can help identify and prioritize which formats will be included in the first phase of implementation.
• Document the stakeholders. What departments within your organization should be involved in this project? It is likely that you will have representatives from security, audit, infrastructure, DevSecOps and possibly others.
• Get involved in shaping the future of the standard. Consider becoming a member of the working group to help advance the standardization effort.
A truly open-source identity standard is within our reach today thanks to the expanded use of REST-based APIs. For organizations struggling to manage multicloud identity systems, it might be worth investigating.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?