A reader recently asked, “What is IAM and why is it important?” This is a bit of a complex question, but we can definitely dive into some of the higher-level concepts and details to de-mystify Identity and Access Management (IAM).
IAM is simply the series of technologies that control who is allowed to access what on your corporate systems. The 
complexity comes about because – while the idea is simple – the actual implementation of IAM is one of the most complex operations that many companies will ever undertake. The reason is straight-forward, humans are not generally logical and orderly beings. Because of that, systems which enable humans to do their jobs also tend to be complicated and intertwined, meaning making sure only the right people have access to the right systems and data is often difficult at best. So, let’s have a look at the basic ideas behind IAM and what they do.
First, the Principle of Least Access is the starting ground for any IAM solution set. As its name would imply, this principle says that each user should be first given the absolute minimum amount of access to systems and applications, regardless of any other factor. When a user needs access to something more, they get it quickly and efficiently, but they only get the bare minimum access to that “something more” and no more than that. As an example, a new user needs access to things like file servers, email, and some applications. This access would be very specifically defined, giving them access to just the folders on the file server they require; for example. They get an email box, but don’t get access to shared mailboxes automatically. They get read-only access to applications, not full access. Then, based on the needs of the user and the approvals of management, the user can request and gain additional access as and when required. While this process can be cumbersome – especially when a user is first starting with an organization – it also avoids over-provisioning access that later must be pulled back. Provisioning and de-provisioning solutions can greatly aid with this process, allowing IT teams to quickly add and remove access as needed with a minimum of manual steps. Note that de-provisioning is as critical as provisioning. When an employee changes roles or leaves the organization, or when an application is reconfigured or replaced, access must also be updated to maintain the principle in action; ensuring users have the access they need but no more.
Second, one source of truth per organization. While it is very possible for every application and site to have their own identity data store, that is a recipe for disaster as a company grows and evolves. Instead, a single source of truth for identity – like Microsoft’s Active Directory or a similar solution – allows for much tighter and effective control over identity and access. Each application would then use that single source to confirm the identity of the person logging in and what they’re allowed to have access to. The most common form of this idea in organizations today is Single Sign-On (SSO) – where you go to log in to an application (like SalesForce) and see your browser re-direct to your company login page. SalesForce is checking with your company’s single source of identity truth, instead of keeping its own database of users within the app. This is a bit of an oversimplification, as the methods and technologies used to do SSO are complex, but the basic theory of using one source of truth to identify users is the goal.
Third, the concept of zero trust. Zero trust has become a bit of a buzzword in the cybersecurity industry of late, but the actual operational methodology is extremely valuable. Zero trust says that whenever a user, systems, application, etc. attempts to access anything; they/it must prove that they are who they are and must have been granted access for that specific operation. This means that even if the user had been logged into an application already, their identity would still be challenged if they attempted to access other areas of the application. A system talking to another system might have to pass an authentication challenge if it tried to access data in another database. This is significantly different than traditional access methods which say that a user who can use an application has all of their access rights “pre-cached” and ready to go. The reason for zero trust is that a user’s device (or a data system itself) could be used in a way that is not appropriate – either because the user is attempting to do something they shouldn’t on purpose or by accident, or because the device has been compromised by a threat actor. This could easily result in access to data and systems that shouldn’t be accessible, or where access has been removed, but that removal hasn’t yet filtered down to the application in question. In short, zero trust gets its name from the fact that a user – even a user who already logged into something – isn’t trusted as they move around applications and systems. They must pass identity checks (which often happen invisibly to the actual user) to gain access to additional resources.
Identity and Access Management attempts to implement all these theories and more, and so can be a complicated strategy for any organization to undertake. By giving users access to only what they require, forcing all applications and systems to use a single source of identity truth, and ensuring that access requests are dynamic and not static; organizations can begin to tame the beast that is IAM without keeping users and systems from effectively doing their jobs.