We've been working with one of our Retail clients on building and defining a modern Identity and Access Management strategy. We spent a fair amount of time trying to find examples on the internet where other people faced similar challenges, or had a write-up on some of the things that they had delivered. However, we really couldn't find anything that gave some honest pain points. I'm sure there are examples out there, but I really couldn't find them! Most of the content we found were from case-studies, which all had a marketing spin on them.
Therefore, I thought why not write up some of our experiences. So here it is, my 'tale from the field'. Please let me know your thoughts, and how your IAM projects have gone. I always love to hear any challenges that you faced, or issues you overcame.
So settle down, grab a brew and enjoy our first 'Tales in the Field'.
How it all started
As I fired up my teams client and joined my first conference call on the project, I knew that the e-commerce and financial services client were already pushing to use the latest technology. Like any organisation, they had legacy infrastructure, outsourced contracts and a chunk of technical debt.. but they also had a leadership team who wanted to push the boundaries, and do things the right way.
This helped with setting the scene on what they wanted to achieve. The architecture and security team had already set out their stalls to deliver a zero-trust strategy. Over the past few years, they had made significant investments in their end user compute and connectivity strategy to move them to a'work from anywhere devices'. The biggest win in this space for them was the introduction of Entra joined and Intune managed devices. The pandemic had pushed them almost overnight to quickly re-architect how they delivered compute services to their users.
Networking had also seen shifts to the modern ways of connecting. Most applications were being presented externally using Entra application proxy, and where it wasn't possible, split tunneling was configured on their VPN client.
This was a great space to be in, so I knew I could build upon the recent successes, and drive some of the modern identity capabilities that were available within the Microsoft stack. They had made investments in Microsoft 365 E5, and were keen to get the most out of their EntraID P2 and Defender for Cloud Apps licenses.
Principles
As with any strategy, I always set out to agree a core set of principles that help set the scene for any decisions moving forward. Each of these set out to assist with the business and technology teams to come to the right decision when implementing and choosing an architecture. These principles can often conflict with each other, but that is by design. If you can justify the decision against them, then it fits.
With that in mind, the core principles that we came up with:
- All users will have a single identity - Not only does this make the lives of the users easier, it helps to manage the life cycle of a users access, and to determine what, where and when they accessed a particular resource.
- Context based authorisation - This isn't that new to be fair, but organisations often fall into the location based mentality when allowing access... Are the users in the office? Ok, cool, in they go! With the constant change in location, sprawl of SaaS applications and multiple devices, this is no longer suitable. Therefore, validating a users security posture in realtime ensures user authorisation is suitable for the application.
- Automation, automation and more automation - Moving to an automated delivery model would free up their teams to focus on what mattered. Passing access decisions to accountable business owners and automatically revoking access would save a tonne of time.
- Persona Led - Moving away from custom account types, and following a persona model that aligned to HR roles would simplify management and deployment of access. Once these job roles are understood, so would the changing of them.
- Product Ownership - The usual pattern within any organisation is usually one of siloed owners, with IT bearing the brunt of role based access. In this new model, product teams and department managers would be accountable for who had access to what, following a well defined governance model.
Once principles were agreed, it fed into the overall design and helped define the next steps. The key principle for me was around 'Personas', and how they can assist with defining repeatable access and require patterns that traverse the enterprise and applications. Building out a framework that set out standard, policies and patterns ensured that the application owners could manage who had access, while mapping to an org wide initiative that would grow and evolve as the business did.
Building Personas
The next part of this blog series will dig into the Persona definition and how it standardised user access across the organisation. Think of personas as a defined set of requirements that map to a consumer of the Identity and Access Management platform. This information will be used to define the licenses, which systems they have access to and the rules and regulations they must follow to remain compliant.
I'll cover the reasons why it is a good idea, tips and tricks on ways to capture the information and might even provide a tool or two to help you and the team get the data you need.
If you want to be notified when the next post is available (and any post for that matter), drop your details in the form below.