Organize a cloud IAM team to secure software-defined assets

Getting started: How to build a cloud IAM team

To create a cloud IAM team, start with an existing internal IAM team if one exists. Ideally, teams should be built from existing internal groups that already understand the business and goals of the organization.

These teams are often focused primarily on directory services, such as Active Directory, federation and single sign-on (SSO), as well as provisioning and deprovisioning users. These are all critical elements of a cloud IAM strategy. However, additional IAM expertise is needed to adapt Windows and Unix privileges and permissions to cloud-based images and deployments, as well as configuring and managing cloud provider policy syntax and roles.

Cloud-focused IAM teams should include individuals with a variety of skills and disciplines. Among these are directory services configuration and management experience -- making domain administrators and architects prime candidates. In addition, experience building federation policies and integrating SSO with SAML and OAuth or OpenID methods is key. Cloud engineers with expertise in cloud provider IAM frameworks, including Google Cloud Platform (GCP) IAM, AWS IAM and Azure role-based access control, are also well-equipped for a cloud IAM team role.

If an internal IAM team does not exist, or if existing candidates do not have the expertise needed, a cloud-specific IAM team will require recruiting from outside the organization.

Cloud IAM team responsibilities

As most organizations implement a wide variety of SaaS applications, one of the first areas for cloud IAM teams to focus on is SSO and federation with internal directory stores. For existing internal SSO, integration with cloud applications may be simple to implement through SAML assertions to these cloud services. However, this requires end users to connect to a VPN on an on-premises environment first to access the SSO portal or services, which is less than ideal.

Today, most organizations are using identity as a service (IDaaS) providers, such as Okta, Ping Identity, Azure AD or OneLogin, to act as a central SSO and federation broker that is always available to users from anywhere in the world. This approach requires an internal identity source, such as Active Directory, to first be synchronized with the service provider. Next, the cloud IAM team should configure groups, role or privilege assignments, and specific attributes needed to access SaaS offerings. Increasingly, this IDaaS approach is being used to provision access to PaaS and IaaS environments, as well.

As identity relates to all cloud users within an enterprise environment, the cloud IAM team should expect to interface with almost every possible stakeholder group within an organization. Consider which departments are accessing sensitive applications and data, such as HR, finance and IT. The cloud IAM team will need to dedicate time to understand how to build and maintain a least-privilege model of cloud application and infrastructure access in those contexts. It's a good idea to develop a committee or stakeholder representative group that meets regularly to discuss the identity needs and requirements for applications and data access.

The most consistent and time-consuming activity that cloud IAM teams will need to engage in is defining and controlling privileges associated with cloud provider policies and roles. Most cloud service provider policies are relatively complex. Many organizations will accrue hundreds or thousands of unique policies that control how software objects and services in the cloud interact with each other.

While some cloud providers have released features to help identify flawed or risky policies -- for example, GCP Cloud Identity, AWS IAM Access Analyzer, and Azure Security Center and Privileged Identity Management -- significant effort will still be needed to tune and control these policies over time.