Best practices for IAM in cloud environements

Why is Access management in IAM so essential to secure your infra?

IAM is a cornerstone of a robust cybersecurity strategy, providing the means to manage, monitor, and control user access to critical resources. It plays a central role in safeguarding infrastructure, preventing unauthorized access, and ensuring security policies are consistently enforced.

Users (Dev, DevOps, …) working on your infra represent a significant attack surface as they can introduce vulnerabilities through different factors. Among them are human error, susceptibility to phishing, weak passwords, insider threats, unauthorized access, use of unsecured devices, lack of security awareness, unpatched software, and challenges associated with remote work.

To mitigate these risks, we will share with you in this article some of the most essential best practices regarding Identity and Access (IAM) management. The first part will focus on IAM rights and permissions, giving specific recommendations to achieve the least privilege principle.

How do you secure your Access management?

In short, you need to:

• Use Roles and Groups for IAM Configuration
• Manage IAM as Code
• Manage the use of service accounts management
• Apply the least privilege principle
• Prevent privilege escalation
• Implement Just-In-Time Access for Critical Assets

Here are more details on each best practice.

A second article focusing on IAM rights and permissions will follow it!

Use Roles and Groups for IAM Configuration

Our recommendation

Configure your IAM using roles and groups. The best practice is to create an IAM group for each type of persona in your organization, such as developers, SecOps, and DevOps engineers. Each of these groups will address authorization to assume a role dedicated to each of these personae.

Conversely, the trust policy on the dedicated role will allow principals only from the associated group to assume it. Both practices come together, and it’s not considered secure to address authorization directly in user groups, as well as not configuring assumed roles to specific individuals through roles. It is part of the IAM configuration errors to avoid.

Risks addressed by the recommendation

Using roles and groups ensures a more organized and manageable approach to permissions. This method helps avoid the risk of inconsistent grants, which can lead to potential security gaps. Furthermore, grouping users by roles makes auditing and managing permissions easier, reducing the chance of unauthorized access.

Manage IAM as Code

Our recommendation

Manage IAM permissions as code with tools such as Terraform is definitely a go-to. This means that IAM permissions should be defined and maintained in a layer of code accessible only by a restricted group, such as the SecOps team.

About the previous recommendation, it is practical as the list of users in user groups can be reused in the trust relationship of the associated role.

Risks addressed by the recommendation

Handling IAM permissions as code ensures that changes are version-controlled, documented, and subject to peer review processes. That mitigates the risk of accidental or malicious changes. Restricting access to this layer of code to a small, trusted group minimizes the risk of unauthorized changes and helps maintain a secure, well-documented permission structure.

Apply the least privilege principle

Our recommendation

Ensure that your IAM policies adhere to the principle of least privilege. This is important for all types of companies, from scale-ups to bigger companies.

Each user account should have the minimum permissions necessary to perform their job functions, and these permissions should be well-documented. This can be hard to implement and also to maintain, so it is important to evaluate the needs of each personae to achieve their tasks.

Risks addressed by the recommendation

Following the principle of least privilege is a pillar of security as it minimizes the impact of a compromised user account. Limiting permissions reduces the attack surface, making it more difficult for attackers to access critical systems or data. Proper documentation ensures that permissions are reviewed regularly, maintaining a secure environment.

Manage the use of service accounts

Our recommendation

If you have service accounts, they should also follow the principle of least privilege, have only the necessary permissions, and be well-documented. Service accounts should also not be shared between different services or applications. You should also avoid using default service accounts in favor of managed services (e.g., workload identity in GKE).

The service accounts management can also be eased by adhering to the no credentials principle. The best practice is to take advantage of the cloud by using IAM roles so that machines have rights to different resources.

Lastly, you can use a trust relationship in IAM roles if using the no credentials principle. For example, in AWS, if you use EKS, you can manage the use of roles by using a trust relationship, allowing only specific service accounts to be associated with a specific IAM role.

Risks addressed by the recommendation

By applying the least privilege principle to service accounts, you reduce the potential impact of a compromised service account. Not sharing accounts between services prevents lateral movement by attackers, and avoiding admin privileges reduces the risk of a complete system compromise.

Using managed services and custom accounts instead of the default ones ensures better security configurations and management. Also by reducing the number of resources using a specific role, you can more easily apply fine-grained permissions to service accounts.

Prevent privilege escalation

Our recommendation

User accounts should be unable to elevate their privileges using their IAM permissions. Implement automated tools to analyze and identify vulnerabilities to privilege escalation in user and technical accounts.

Risks addressed by the recommendation

Privilege escalation attacks are common and can be highly damaging. Preventing such attacks involves ensuring that no user has permissions that allow them to gain higher privileges than intended.

Automated tools help identify and mitigate potential vulnerabilities, ensuring that security is continuously maintained and that users cannot exploit IAM policies to gain unauthorized access.

Implement Just-In-Time access for critical assets

Our recommendation

Implement a Just-In-Time (JIT) access system for developers to connect to critical assets, such as production environments. Just-in-time implies that access to critical assets is temporary. This allows developers and other people who need specific access for their tasks to continue to work while ensuring security in your infrastructure.

This can be implemented with tools such as Azure PIM or the couple Vault and Boundary which is compatible with many types of infrastructures.

Risks addressed by the recommendation

JIT access reduces the risk of persistent privileged access exploitable if an account is compromised. By limiting access to critical assets to only when it is needed, you minimize the time during which these assets are exposed to potential threats.

Traceability and validation steps add additional layers of security ensuring that all access is monitored and verified.

By following these best practices, organizations can significantly enhance their IAM configurations, improving their overall security posture and reducing the risk of unauthorized access and potential security breaches.

Conclusion

By following the security best practices presented in this article, you can significantly reduce the risk of having a compromised identity and improve the overall security of your infrastructure accesses.

The next article will address the security best practices for IAM rights and permissions.