Say you’ve been hearing about and feeling the pressure to implement an Identity and Access Management (IAM) strategy for your organization. You may be wondering how IAM will serve you — and if the time and effort it takes to implement it will be worth it.
Guess what? You know more about IAM than you think. You’ve already implemented a rock-solid IAM strategy at home. For example, you may give a service person a temporary code to unlock your front door and enter to make repairs. You give your friends access to certain systems (your WiFi code) but not others (your thermostat). And you allow only those in your innermost circle to walk right in at any time and scour your fridge for leftovers.
In other words, you’ve established rules and boundaries for different folks and resources. Identity and Access Management in business does the same thing. And the larger you are, the more you need it to prevent costly internal and external data breaches. Even without the most basic IAM, things can go off the rails fast. Users who leave the company may have access to corporate assets, for example. And if credentials are not rotated often, compromised logins can fall into the hands of attackers.
What does an IAM do?
A strong IAM strategy lets you know at all times that your users are who they say they are, with up-to-date login credentials unique to each user, and the minimum permissions required to do their specific work — or the Principle of Least Privilege (PoLP).
Often, companies add tools to their network to shore up IAM. But consider that Amazon Web Services (AWS) lets you do everything right from your cloud instance. AWS Identity and Access Management empowers you to manage access to AWS services and resources securely.
IAM starts with the simple premise that you never want everyone having the same level of access to your stuff — at your home or your workplace. AWS IAM offers features like credential rotation and federated access, so you can start with the least access and give more as needed to users or resources. Using AWS cloudTrail, you can keep tabs on what is going on in your AWS environment.
To get started, you don’t have to reinvent the wheel.
AWS has built-in policies and tools you can apply to your AWS roles. Common ready-to-use AWS policy types include identity-based policies (ensuring users are who they say they are) and resource-based policies (determining who has access to each resource and what actions they can perform on it). As you get more advanced, you may implement permissions boundaries for a user or role that set the maximum permissions that the entity can have. Once your policies are in place, you can always expand or curtail them later to meet your needs.
Access Control Lists (ACL) are also your friend. Buckets and objects within AWS each have their own ACL, so you can get as granular as you want with each resource. For example, you may want one group of people to have access to one group of files or a single bucket, because they need those resources to perform their jobs. However, their jobs do not require them to have access to the rest of the resources. This may be an extra step for you to set up and maintain. But each time you implement granular controls like an ACL, you mitigate the risk of a data breach.
What if you want a more customized approach?
AWS Customer Managed Policies are policies you create in your AWS account. If that sounds overwhelming, don’t worry. AWS has a versioning rollback feature, which can store up to five previous versions of that policy. This way if issues arise, you can quickly revert changes to a working policy. You can also use inline policies to be associated with that identity and removed once that identity is deleted.
All these safeguards are meant to keep out unwanted “visitors.” But what about opening access to trusted partners who are not part of your internal team, like vendors, collaborators or clients? IAM roles to the rescue. From AWS IAM roles, you can grant these third-party friends access to your AWS resources without sharing your AWS security credentials. Instead, the third party can access your AWS resources by assuming a role that you create in your AWS account. The external ID can be any secret identifier that is known by you and the third party.
Just as IAM roles can open doors to guests, they can also close doors to unwanted outsiders. For example, you can use IAM roles to attach policies to provide users, groups and resources access to only what is needed — like preventing access to your company if the originating IP address is outside your company network. The bottom line is, you have the flexibility and control to set the rules and allow or deny access in just a few clicks.
If you’re contemplating an Identity and Access Management strategy for your organization but feel a little daunted, take a deep breath. You’ve got this. With AWS IAM, you can start with ready-to-use policies and work up from there. Moreover, my colleagues and I at TRUE are here to help. If you would like to learn more about getting started with a knowledgeable guide at your side, let’s visit.
