In recent years the increased accessibility of cloud computing and services has led businesses across the globe to shift away from the traditional on-premise deployments. The Infrastracture-as-a-Service (IaaS)/Platform-as-a-Service (PaaS) offerings by the major cloud providers such as AWS, Google and Azure allows companies to modernize their applications while being able to leverage services that can scale on demand without the traditional administrative overhead. These environments offer companies scalabilty options which would have been hard to implement — especially for smaller organizations. Many organizations are using more than one cloud provider.
While the shift to the IaaS/PaaS model yields many advantages, thought and care must be considered as to how to maintain the integrity of identities especially when an organization is employing multiple cloud providers as described above. Providers such as Azure, Google Cloud and AWS have their own identity management systems which have been created with the objective of managing access in their environments. They control access to resources in their environments and employ a unique blend of entitlements needed to manage this access.
From a compliance perspective, it’s critical that businesses know who has access to what and why. Much of this access may be classified as being privileged making it even more sensitive. From a control and efficiency perspective, it’s important to be able to define consistent access and automate life cycle operations as much as we can. The traditional drivers for IAM apply here as well.
The OpenIAM approach
OpenIAM addresses the complex challenge of conserving accuracy of identity data across multiple cloud providers in numerous ways. At the core of our approach is a library of connectors which provides integration with the cloud provider. Combined with the IGA functionality in OpenIAM, customers will gain the following capabilities:
- Visibility into the access that users have across each cloud provider
- Automated joiner, mover, leaver processes
- Workflow-based request/approval via the Self-Service Portal
Once these connections are established, OpenIAM can model each cloud provider’s identity model within OpenIAM allowing customers to use familiar terminology in the OpenIAM portal. For example, AWS uses Roles and Policies. To represent these objects, OpenIAM uses custom entitlement types called AWS Roles and AWS Policies (they can be renamed to anything that you like). These entitlements can then be included in business role and business rule definitions which will in turn enable consistent access under the right conditions.
Joiner/mover/leaver example
Let’s walk through a JML use case in a multiple cloud environment. For example, let’s say an organization hires a DevOps Engineer. Once this new hire is in the HR system, OpenIAM will detect this addition and based on business rules related to his position, will automatically create access that is required. This may include creating accounts in the company’s AWS and Azure tenants along with a slew of entitlement memberships in each system. The business rules in this area enable the birth right access.
Assume that after a period of time, the DevOps engineer has been promoted to a new role and no longer needs to access these account services. In this case, OpenIAM will again evaluate the birthright rules and revoke the access that is no longer needed and provision the new access that is needed.
In this way, access that is no longer needed is revoked in a timely manner and the audit logs provide traceability into when and why these actions have occurred.
Privileged accounts
Since much of the access in a cloud provider may be considered privileged, OpenIAM provides options to administer these rights safely. First, if some privileged access is needed on a permanent basis, then OpenIAM provides the option to create a second “admin” account for the user. In this way, normal user access and admin access can be easily distinguished. However, there will be some access that is considered highly sensitive and in this case the request can be granted after it has been approved and even then only for a specific period of time. The admin will only be able to use this access for that limited span and after that access will be taken away.
Access certification
To offer compliance with activities such as SOC-2, OpenIAM provides access certification functionality. This functionality also supports the review of privileged access.
Summary
The transformation of the IT landscape brought about by the shift to the cloud has afforded organizations numerous benefits but has also added complexity to the management of identities across cloud providers. OpenIAM provides a set of tools to help improve both compliance and security across these identities. Further, OpenIAM has a long-term commitment to this use case. Version 5.0. of OpenIAM will include significant advances in cloud infrastructure and entitlement management (CIEM) to further simplify how access in the cloud can be proactively managed.