IAM at Scale

Microservices are all the rage these days. Small contained applications hyperfocused to do one to two things. That’s it. Nothing more nothing less. An application is now composed of multiple highly orchestrated microservices working in concert to deliver a symphony of functionality. Heavy-handed, maybe but the point is made nonetheless. We’ve changed how we build applications. No longer monolithic tightly coupled behemoths which are slow to change and adapt, but intricate collections of microservices which work together and can adjust and improve continuously. The application is a now a living and breathing entity. So what does this mean for identity?

Last year we saw a pretty big trend that we could wrap up with one word. More. More apps, more data, more everything. We’ve waded our way into the deep end and realize that there is so much more we need to do with identity, and how critical it is to our security posture. Combine this with the love of microservices and serverless architecture, and we’ve got an IAM nightmare brewing. So how do we scale and stay ahead of the curve?

First, let’s break down the problem and make sure we understand it. What exactly is a microservice architecture? In a nutshell, it’s the process of taking one big task and breaking it down into one hundred well defined smaller tasks. Each task is scaled down to only do one, maybe two things and that’s it. If it needs to do more, it depends on another task. All the tasks coordinate to help solve the big problem. The beauty in the design is that each task can be updated independently of the others however they are run dependently to accomplish the end goal. Which means instead of one part of a monolithic application that needed to use a service account to extract data, you could have six different tasks that all need that same access. Or do they? If we apply our microservices architecture to access, then those six different tasks all need access but to do six separate activities, so in theory, there should be six different accounts each one to specifically handle the needs of that microservice. However, surely we aren’t’ going to start creating “micro accounts” for every single microservice. My answer…why not? It’s time to start looking at the concept of security in a completely different way, which in turn means we also need to start looking at identity differently.

Redefine Identity
Identity is no longer just a carbon-based life form. It’s no longer just employee, contractors, vendors it’s more. (Queue the GEICO commercial). We must define identity as any digital asset that needs access within our infrastructure. Whether that’s a Slack bot that interacts with Jira to create support tickets, or a contractor who needs to be able to view HR data for the next six months, or a microservice that needs to query a database for customer information, all of these are identities that each have their lifecycle and access needs. So it’s vital that we have clear visibility into the access of these identities and control of their lifecycle. We have to be able to quickly answer questions like: What credentials can the Customer Registration microservice access? When was the last time the Slack bot’s access was certified? Who approves access for the Slack bot?
Identity indeed must become a service, a queryable endpoint that any application can interact with and not only get answers to identity-related questions but also invoke identity-related actions.

Governance Everywhere
I won’t bang the governance drum again, by now I’m sure we all know the importance of it. Until now it’s been mostly centralized, and if we’re honest, passive. Time to change that. The polices and workflows that we’ve spent painstaking person-hours on developing that drive our identity processes need to be unleashed to the rest of the infrastructure. Freed from dungeons of monolithic IAM systems these processes should now be invoked by any method that’s monitoring for events, or in the flow of a users daily activity. For instance, we can trigger disable workflows from the MFA system when too many authentication attempts are tried, and we think this may be a compromised account. An alert from our SIEM system shows some unusual activity on a specific account, and we want to have someone review and sign off on the access the account has. The user modification service wants to add particular attributes to a user, and we want to make sure that the transaction is compliant with company policy.

Intelligent Access Request
Now that we’ve broadened our view of identity we must account for the fact that no every identity that needs access will submit an “Access Request.” As servers dynamically scale access will need to be provisioned. Based on risk factors and statistical analysis we can profile identities and automatically approve access within a specific threshold. Does this account request match the profile of its peers, approve. If not then route for approval.

Enhanced Visibility
We have to be able to understand the complete depth of an identity’s access. What does being in the “XEY234” group mean? The ability to show the relationships of access to identity and function is critical going forward. If we develop applications in fine-grained tasks, we should manage the access the same way. It’s no longer acceptable to operate at the coarse-grained level, because as we all know the devil is in the details. Both business and admin users need the ability to visually see the depth of an identity’s access so not just what entitlements the identity has, but what those entitlements do. What systems do they connect to? What actions can this identity take with that access?

The landscape for how we build applications is taking another major shift, and in doing so, we must shift with it. There’s never been a more opportune time to bring identity into the fold than right now. By building IAM systems that are easily integrated into the fabric of an application we can ease the pain of developers by having the information they need without having to develop it, increase the effectiveness of our deployments by increasing the reach of governance. It’s time IAM systems get a makeover and indeed become the center of security.