The term IAM is one of the common you hear in cloud-native environments. What does such a system do, though? And if you do know, how long did it take you to understand the full purpose? I will explain the main concepts behind this massive software family, having the busy engineer in mind. The fundamentals described here are vendor agnostic. Though most of my experience derives from AWS's implementation. What is IAM IAM stands for Identity Access Management. It is a complex system of entities (humans, applications, etc) that request access to a system, on the one hand. And also, there is a complex hierarchical set of rules, to grant or deny the requested access. Before we go any further, below are the main terms you will encounter. : Anything worth protecting. A storage service a virtual machine etc Resource : A set of rules which dictate "who can what" on which resource. And of course, who cannot Policy : Anything someone can do, inside the cloud environment. For example, creating a virtual machine Action : Well...a user :) User : A group of users, with the same permissions, applied Group : A user or an application requesting access Principal : A set of powers assigned to a principal. Usually for a limited amount of time. Role Why it is useful Its main usage roams in the realms of authentication, authorization, granular access, governance. Let's see what those things are: : We have verified who you are Authentication : We want to identify if you can perform the action you ask for. Usually, combined with Authentication but not necessary. Authorization : Each action that can happen in a resource, is controlled by permission. Having access to see the firewall rules doesn't mean you can change them. This is implemented with Granular access Role-Based Access Control : The actions you take to know what the f@ck is happening to your environment. Mostly from a budget, compliance, proper access scope. Governance Are you a company of 1-3 people? Then, setting up a full-blown IAM solution is overkill and a burden to maintain. But if you are more than that or you are planning to scale, then you should start considering it Problems from the lack of one I believe you can see the benefits of an IAM solution. Let's see what are some common problems organizations face in the absence of it. Hard to audit and administer access Have you heard of cases where an employee had more access than they should? And additionally, no one knew? This can be prevented with a properly set-up IAM solution. Setting up new hire accounts is a pain With a properly set-up IAM solution, this is a matter of a few clicks. Namely, set up the users, add them to the IAM groups their teams use. And that's all. But without it? You need to do all the permission settings from scratch. You might have a reference user to "copy from". But do we need all the permissions this reference user has? Do we want to have special handling for users that are less than 6 months in the company? Does the reference user have superuser permissions that should not accidentally be assigned to the new hire? Offboarding people Here you have problems of a similar nature to the "new hire case". But you also need to change the password to all the accounts they used. This can turn ugly very fast, not to mention the side effects it has on other team members. potentially For example, one will have to update all the password occurrences on every offboarding. In every script and application. What if you have a team change 2-3 times per month? How productive this will be? Commodity identity tasks need human intervention By commodity, I mean tasks like, resetting a password or re-enabling an account that was locked. The top-tier IAM solutions have a way to resolve such issues fast without much hassle. Best practices Below are some best practices I have derived. It is far from being a full list, it is only my personal experience. I have seen them in more than one team though, so they are probably good enough. No full access...EVER In a real-world scenario, you don’t want every user to have unlimited access to the account. Ideally, no one should have (apart from the account owner). If Jack is working on monitoring logs, they should have read access to that tool. They should not be able to restart a service. Or the accounting team should only view billing information. Knowing how the VM scalability rules are set is not gonna help anyone. Groups vs multiple users Prefer a single group to multiple users when you have a choice. The groups make administration exponentially easier. Roles vs multiple groups vs a new user When you have the choice, prefer assigning a role to a user, rather than creating a new user. For example, don't create an admin user and share the password between 10 people. Create an admin role and assign it to whoever needs it for a limited amount of time. Permissions should be frequently audited It is easy to make mistakes or perform malicious actions. At the very least, a company should audit that only the proper people have access and this is at the minimum level. You could also send an email to a certain team when a suspicious action happens. For example, assigning an Admin role to a new hire. Setup boundaries beforehand If the IAM solution allows it, add boundaries to your ecosystem. Copying from Amazon's documentation ( I know, I promised vendor-agnostic :) ) A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. In layman's terms, you can define the "maximum" permissions that can be assigned to anyone. For example, a user will at most be able to view the logs from the relevant tool and restart a service. If someone attempts to get a role to create a new virtual machine they will be disallowed. Conclusion Thank you for reading this far. I hoped you enjoyed the introduction to the IAM technologies. Any questions, please reach out. Also published here: https://perigk.github.io/post/iam-intro-wish-i-had/

Amazon

Meet the Writer: Hacker Noon's Contributor Periklis Gkolias, proud Jack-Of-All-Trades

Cybersecurity Lessons from the Netflix Series La Casa De Papel

Nominated for 2022 - HackerNoon Contributor of the Year - Authentication

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

An Essential Guide to IAM (Identity Access Management) in 2022

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

6 Not-so-obvious Tech Predictions

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

6 Not-so-obvious Tech Predictions

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps