We already know that some IT paradigms must be rethought when we look at the world of cloud security. Identity Access Management is one of these concepts.
When we think about cloud security, one of the main and most important points is to define and work correctly how we will manage Identities.
The concept of Identity Access Management in the cloud can be applied to a large set of things. But to be more efficient in describing this concept, let’s stick to just two – users and resources in the cloud.
Conceptually, security in a traditional way uses a lot of layered defense thinking (Defense-in-Depth) and at another time, this kind of protection was much stronger when we thought about network security.
Don’t get me wrong, I’m a guy who came from infrastructure security and I know that this kind of protection is still very important. But nowadays, where everything – or almost everything – migrates to the cloud, this is not enough anymore.
Nowadays we have a very wide range of offers when we think about services in the cloud, and that doesn’t stop growing. If you look at the two major service offerings – AWS and Azure – we have over 150 services on a wide range of topics.
To protect and manage a large number of services, users and resources the traditional ways needed to be re-evaluated. And so we came to the conclusion that in order to manage and control this vast amount we needed identity and access management (IAM).
In this article we’ll put some points that are today some of the most challenging for security teams.
What does IAM stand for?
First, before we move on to the points we want to present, we need to better understand what IAM stands for and what we can gain from this service.
For the purposes of this material we will be using the IAM offered by AWS as a basis. But it is important to note that we have similar services at almost every cloud provider on the market, such as Azure or Google.
We may have some points about the other services at times but our focus will be on AWS. Even though we are from different providers and as some different points all continue to have the same basic concept – managing users and access within a cloud structure in this case.
Conceptually the thinking about an IAM is quite simple. We need to manage in a granular and specific way the users, their accesses and permissions. There, that’s it !
But the concept is much easier than the fact!
In its article “Guide to Initiating and Running an Effective IAM Program.(ID: G00389672)”, Gartner points out that by 2021, companies without an effective IAM program will spend up to 40% more than companies that already have or work in an IAM program.
This was published in 2019, so those who are not yet working on the IAM program may be out of date.
The main point of any IAM system is a digital identity of each individual, or even resources. Thus, once the digital identity has been created, the entire access life cycle must be maintained, modified and monitored for each user.
The challenges when implementing IAM
Thus, we need to understand that the IAM is focused on granting access to company resources (assets). These resources (assets) must be the right ones for certain groups or individual users, thinking from the integration of the user’s systems to the system or resource until their permissions are revoked. All this in a time that is adequate to the company’s process.
Then, IAM systems allow administrators to keep the user and resource management process always aligned with the needs of the company’s policies and services.
Now that we understand what an IAM is, let’s talk a little bit about what we see as the most challenging aspects for security teams in implementing an IAM.
But if you want to dig a little deeper and better understand how the AWS model works, then perhaps this document will be a good reading.
SSO in an IAM process
It is not uncommon to find in companies authentication processes made by single sign-on mechanisms – the famous SSO(Single Sign-On). They are usually used to facilitate and improve the user experience when accessing their resources.
Besides bringing a better user experience, since you don’t have to log in to each of the resources you should use, this is also a very important tool for structure and security personnel. After all, it allows centralized management of a large number of users and services.
However, the big challenge here is mapping users and the possible various functions and profiles that each one can have in each service or even resource. Easily someone will make some mistakes!
This kind of scenario becomes even worse when we have to understand and comply with several privacy laws and even specific points about access in contracts, regulations and or internal policies.
So, the first point of much attention is: Have a mapping of your users, groups and permissions.
Many companies already have an established authentication structure and do not need to redo this procedure in cloud services. What needs to be done is an integration of this authentication process with the cloud IAM – a process called “federation”.
If your company is developing a mobile or web application, and you want to allow your users to authenticate with an existing service such as Google, Amazon, Facebook or other, you can use the “federation” concept again. Besides being easier for your users, it can be much more practical to manage your users.
Following the example of the mobile app, if your application needs to store some sort of data on an AWS service, this can only be done by validation using an AWS access key but this is by no means recommended.
What we recommend is that a temporary security credentials request mechanism be incorporated into the application. This allows access to still be granted but now in a more secure manner.
Permission
Those who are a little more experienced will remember that one of the main recommendations when implementing a server is never to use the root or administrator password for day-to-day tasks. The recommendation is to always have another user and password.
However, we have to think that users in complex structures have a large set of access and permissions attached to them. Just think about your development process: how many accesses and permissions do your users have?
Managing and maintaining this set of permissions and accesses is always correct is a real battle, which can be disastrous within a development process if not well structured.
A good concept is to have a structure based on groups and permissions. This can and will implement in your development process a segregation or separation of functions. This is one of several layers of security that you can implement.
There are many ways and services within cloud providers that can help in this task, what we want to put here is the “flea behind the ear” for those who go or already have a development framework that is or has integration with cloud services. After all, this issue requires more care.
Much of what we have seen about data and information leakage can be a means of S3 bucket services, for example, is for lack of a deeper understanding of how this service works. So it’s easy to deduce that a more complex system like IAM may have been used wrongly.
Some IAM security guidelines
IAM services are key parts within a cloud security framework. Development processes that use these frameworks as a basis should look more closely at this service.
The use of IAM in the application lifecycle can integrate an additional layer of security into the entire process.
So here are some tips that can help improve security with IAM.
Using groups
While there are individual controls for each user within the IAM, managing permissions for each can be a great challenge.
To do this, think about creating groups related to working functions (administrators, developers, testers, etc.) this will make it easier.
Then define the relevant permissions for each group. This is nothing more than what we are already used to when dealing with role segregation !
Once the groups are created, include your IAM users to these groups. This simple procedure can improve the security of your development process by ensuring that only the right people have certain permissions at certain times.
Limit Privileges
If we are talking about having more control over your users and how they can interact with your development process, we have to think about the privileges that each one can have.
In one of our articles, we talk about Security in your CI/CD pipeline, and IAM can fit perfectly into your strategy.
Here we don’t deal with anything out of the ordinary or new, keeping privileges under control has always been one of the most used security principles.
But for this to work properly, a first step is to determine the role and permission of each user or each group, and when there is no such mapping the task of permission and privilege becomes much more difficult.
If you already have this mapping it’s easy, create policies in your IAM that can only allow the permissions determined that way, you can control, for example, read and write permissions on components of your CI/CD process.
A good tip is: “start with a more restrictive access profile, and then improve the permissions”. Doing this is a lot easier than trying to eliminate permissions from a much wider set, you always forget something.
As we said at the beginning we will be using AWS as a model but other cloud platforms may have similar services.
If during your permission policy creation process you were in doubt as to whether or not a certain permission will be used, it is no problem for you to review the user’s usage history.
The idea is to understand whether or not the user uses the permission, and this can help further refine the permission policy. At AWS this can be done with AWS CloudTrail. This service can be used to validate usage as the logs of the service include detailed event information.
Use MFA
We know that passwords are still the most common barrier to user access control, but we also know that it is one of the mechanisms that suffer the most when we talk about security, some even point out that it is already an obsolete security mechanism.
But we can still use these mechanisms as long as we can help reinforce their security and one of the ways we can use them is to guarantee that our users will use means to validate their access in a more secure way.
It is possible within the IAM mechanism to enable the use of one second or multiple authentication factors, allowing the password security to be extended.
By enabling the MFA, the user has a device, or application, that can be used to generate an answer to an authentication challenge. And access is only granted if the credentials and challenge response are correct.
Think about enabling these mechanisms within your framework to ensure even more security for your development process.
CONTACT US TO LEARN MORE ABOUT OUR SERVICES
Conclusion
As we’ve seen so far, the IAM subject is very complex, full of details and can easily be left in the background, I can’t understand why, but believe me it is!
We need to understand that IAM, like any service or feature of a cloud or on-premise solution, must be understood and planned with the utmost care, because they are often the barrier between your data and the outside world.
Understand what you are using, what resources, how to use it and how to best configure it, if you do it right, you will hardly have any problems.
