As born-in-the cloud organizations grow, natively managed Identity and Access Management (IAM) tools are becoming a growing concern. Although DevOps teams tend to bear the burden of cloud IAM provisioning, the operational challenges transcend functional silos. Even when SREs and infrastructure teams are closely aligned with security leaders, using native IAM tools to provision access with granular control is unsustainable. No one would contest the need for authorized personnel to get “Just Enough” access whenever they need it – “Just in Time” (aka JIT). Still, teams managing cloud-first deployments struggle to deliver effective access control at scale. While regulatory compliance requirements can act as a trigger for business continuity enablement, many companies are containing unacceptable levels of risk in the form of “cloud IAM debt”. The following list of cloud permissions management traps may sound familiar to DevOps leaders. Avoiding them is trickier than you might think!

1. Attempting to solve permissions management as an engineering challenge.
   In a perfect world, any authorized stakeholder could access just enough cloud resources to get the job done “just in time”. In practice, cloud Identity and Access Management  (IAM) policy configurations are not only complex, but a dynamic work in progress. When DevOps teams do attempt to provision just the right mix of AWS IAM configuration accounting for policy types, permission boundaries, and ACLs, the resulting homegrown solution rarely scales over time. Although DevOps and SRE teams own cloud IAM provisioning, risk management considerations define InfoSec governance.  Without clearly defined processes to determine how data governance guardrails can support IAM provisioning, such homegrown solutions cannot address the business challenge. 
2. Letting compliance data governance requirements define IAM management
   To support smooth operations, most DevOps teams tend to over-provision as a matter of course. As the business matures, this approach does not support risk management considerations (e.g. privileged access to and governance of regulated or otherwise sensitive customer data). Once compliance requirements enter the mix, productivity inevitably suffers.  Without dedicated security controls to address usage attribution, reviews, and approval processes, DevOps teams tend to lose control. 
3. Ignoring the need for an enterprise-wide user provisioning workflow
   The reality of JIT access requirements tends to be more dynamic than anyone can anticipate. The solution must therefore address the challenge holistically beyond the scope of any single functional team (SREs and DevOps vs infrastructure teams or InfoSec). Although addressing standard ad-hoc scenarios such as on-call personnel or “break glass” access certainly represent a good start, a more thorough analysis tends to uncover multiple use cases to address. Some situations will require a human approver’s meditation – especially when supporting access to PII data assets when absolutely necessary. Time-sensitive access scenarios such as “on-call” shifts are good candidates for unmediated automation.
4. Neglecting the impact of infrastructure teams
   When ongoing IAM provisioning policies do not address JIT access requirements, support ticket fatigue could overwhelm cloud infrastructure teams. As organizations increasingly rely on manual processes, it is imperative to identify opportunities to reduce backlog. Even a simple requirement to enable CLI access while supporting SSO connectivity can linger for long periods of time. Although tagging conventions can help to address the bigger picture, lack of collaborative planning across functional silos often prevents effective implementation of holistic enterprise-wide solutions
5. Tolerating standing privileges as a necessary evil
   Security teams are well aware of the benefits of enforcing a zero standing privilege (ZSP) operational model, which eliminates “always on” access and therefore reduces the attack surface dramatically. This straight-forward goal is tricky to achieve beyond the scope of security. Established DevOps success metrics and related priorities rarely address the discovery of standing privileges – let alone a structured operational model to eliminate them entirely. As a result, organizations have come to terms with standing privileges as an unavoidable security blind spot. Interestingly, the benefits of usage monitoring and attribution of identities to resources transcends risk management considerations.  By adopting a “shift left” approach of IAM provisioning, DevOps teams are discovering new opportunities to improve success metrics such as mean time to repair (MTTR). 

Getting cloud IAM provisioning right can only succeed by addressing the manual workflows that currently support multiple teams – namely DevOps, infrastructure, and security. The imperative to remove bottlenecks impacts the business as a whole, but also the success of established functional departments. Once priorities and goals are clearly aligned across departments, the solution is a natural next step. 

Learn how Apono empowers teams to improve performance without compromising on security!