Protect your AWS workloads from threats with our curated bundle of security best practices. Gain insights into S3 security, security group management, and more to ensure the confidentiality, integrity, and availability of your data.
The cloud saves you from many of the tasks you’d normally have to deal with in an on-premises setting. However, this is only partially true when it comes to security.
AWS explains that cloud providers handle the security of the cloud, meaning they keep the physical hardware, networks, and managed services secure. But it’s up to users to ensure security in the cloud, which means you are responsible for the security of your services. You’re allowed to run arbitrary code on the provider's hardware, but this freedom comes with responsibility.
Fortunately, cloud providers offer tools and services to help you with your cloud security tasks, like AWS Identity and Access Management (AWS IAM). This service comes with numerous features and is quite flexible. Unfortunately, this plethora of options can also make it hard to use. This post will review best practices to get the most out of AWS IAM.
AWS Identity and Access Management is the central service that manages all permissions for your AWS accounts and their resources. It comes with users, groups, and roles that let you assign permissions to various users and services.
With IAM security policies, you can define custom access rules, which function like any other pre-defined permission. You can also find all your permissions in one location and benefit from fine-grained access rules for your cloud resources. This way, you can secure all your workloads while adhering to your organization’s policies.
Still, the multitude of security-related AWS services makes it hard to decide which to use for your workload, so let’s look at some best practices to help guide your journey with AWS IAM.
Over the years, many best practices have emerged from developers’ daily use of IAM; below we cover the most crucial ones.
Apply the principle of least privilege
You might be tired of hearing about the principle of least privilege (POLP). Still, it is the foundation of cloud security and even security in general, and organizations should be primarily applying it to IAM.
Don’t just use broad permissions via admin or all-access policies for all your users and services because it’s convenient. Be certain you are granting solely the permissions required to complete a specific task. That means, no write permissions for users that won’t enter any data and no access to all resources of a particular type (e.g., all S3 buckets or all Lambda functions).
For example, the wildcards in the following policy statement are problematic because they allow all actions on all buckets:
Keep your IAM entities tidy. Delete users, groups, and roles that are no longer required. IAM will show you when an entity was last used, helping you decide if it’s time to remove it.
People leave companies, and services change. An organization can start out with one set of permissions, but when an employee leaves and another arrives, they can then add new permissions while forgetting to remove the old ones. This can open up holes in your security, so make sure to remove any permissions for users or services no longer employed.
To quickly delete a user, you can search for “delete user” in the AWS IAM search, as seen below in Figure 1:
In modern IT, many people work from home, and even if they still come to the office, at least the resources they’re using are remote in the cloud. Credentials are usually digital as well, meaning they can get stolen over the internet.
Mutli-factor authentication (MFA) solves this issue by requiring users to authenticate via multiple devices. If someone steals a password, they will still need the device with the MFA app to get access.
This might be more cumbersome for users, so make sure there are reasonable session lengths for logins, or consider only requiring MFA for critical actions.
Again, you can find this feature quickly by searching for “MFA” in the IAM search. When you select a user, you will see all their details, as well as a “Security credentials” tab where you’ll find MFA:
Use secure password policies and password rotation
Password policies are a good way to ensure people don’t just use short and simple phrases as passwords. Combine these rules with password rotation by giving a password a specific expiration date; this will help guarantee that even if it gets stolen, the thieves will have only a limited time to act since after a password is rotated, it becomes useless.
Again, reasonable policies and expiration times are crucial; otherwise, users may feel annoyed in their daily work routines.
You can find the password policy for IAM under account settings:
Choose groups over users
IAM allows for defining group permissions and adding users. However, providing each user with individual permissions can quickly become excessive, and tracking what each can do becomes difficult.
With groups, you can combine related permissions and alter them in one central place as needed.
One of the first things you should do after creating a new AWS account is to secure the root account. This is the administrator user of your AWS account, with access to billing and all other services.
Make sure root user credentials require a strong password and are MFA-enabled. Also, remove all access keys, don’t use a personal email for the account, and configure AWS account alternate contacts. Most importantly, don’t use the root account for everyday tasks; instead, create a new account with fewer permissions for this purpose.
Establish IAM policy conditions
You can set conditions for your IAM policies to limit their use, such as time restrictions, request limits, restricted IPs, restricted resources, and even MFA-based conditions.
Again, this is applied POLP: Grant minimal permissions for only the resources and time required to complete a task.
In the following example, the policy statement is only valid if the user has a temporary credential that was issued after a specific date:
When first starting out with AWS IAM, AWS-managed policies are a good option and come with reasonable defaults. You’ll also avoid racing into defining your own policies and simply ending up with broken ones.
Still, as your security requirements grow and you understand your workloads better, taking the time to learn how to properly implement customer-managed policies will give you a more fine-grained way to define your access rules.
You can create customer-managed policies in IAM by clicking on “Policies” under “Access management”:
Use inline policies to prevent shared permissions
If you want to prevent multiple assignments of policies with critical permissions, use inline policies. They are attached to one user and will get deleted automatically if the user gets deleted.
Since inline policies are created on a per-user basis, you will find them in the user details in IAM:
Use service control policies at the organizational level
If you’re using AWS Organizations, you can opt for service control policies (SCPs) that limit the maximum available permissions of every AWS account in your organization.
SCPs can be helpful if you want to prevent accounts from deleting logs or uploading unencrypted data to Amazon S3. They grant the account admins only a subset of permissions so they can manage their own users, groups, roles, and policies without accidentally using rules that would jeopardize compliance.
The SCPs are located in the AWS Organizations dashboard under Policies:
Go with IAM roles instead of access keys
Access keys are strings of secret text you get from a service provider to copy into your applications' environment variables to enable programmatic access to a service. However, access keys pose a security risk because they’re persistent, and as we learned above, password rotation is crucial.
IAM roles allow you to grant service permissions that you can manage and update via IAM in a central location without affecting each service when you need to make changes.
If access keys are required, use temporary credentials via the AWS Security Token Service (AWS STS) instead, as they’re disabled automatically after timing out. This service is only available via an API, so check out the docs if you want to issue credentials.
Combine ABAC and RBAC
Role-based access control (RBAC) is a good start. You group your permissions and then assign users to those groups instead of handing out policies individually. Nevertheless, when your permission requirements get more complex, you might end up with more of those groups than you have users.
Attribute-based access control (ABAC) is more flexible because it includes information from different sources that can be used to manage access. The sources can be the user account (e.g., user department, security clearance level), the resource in question (e.g. geographical location, memory size), or the environment (e.g., time of the day).
Using variables in policy statements enables the use of ABAC on AWS. The following example statement only allows users specified by the policy to read data from an S3 bucket with their AWS user ID:
If you don’t review your IAM configurations, things can go downhill without you even knowing about it. But beyond the actual monitoring, you have to understand the data in front of you and know what actions to take based on it. For this, you’ll need to integrate recurring internal and external audits into your process.
External audits can show you what to look for in your monitoring data, although these are expensive, so you probably only want to do them every month.
Supporting services and tools
Now that we’ve covered best practices, let’s examine the services and tools within AWS that support them.
AWS IAM Access Analyzer
IAM Access Analyzer lets you scan your IAM entities continuously to detect rules that permit external access and entities that are no longer being used.
AWS IAM Identity Center
IAM Identity Center is an IAM feature that allows you to manage single sign-on (SSO) for multiple AWS accounts managed by one organization.
AWS CloudTrail
AWS CloudTrail is a monitoring service that tracks access to your AWS accounts. It’s helpful for compliance, showing which user or service accessed (or tried to access) your cloud resources.
Identity federation
Identity federation enables you to use external identity providers with AWS Identity Center and IAM. These providers handle user authentication, and the user accounts they provide can be implemented inside IAM to manage resource authorization.
AWS Security Hub
Security Hub provides a central location for all your security alerts; it also lets you integrate external AWS security partner solutions. If AWS doesn’t support a security use case with its own services, the Security Hub is an easy way to enlist third-party solutions.
Amazon GuardDuty
GuardDuty leverages machine learning (ML) and integrated threat intelligence to uncover malicious activities in your AWS accounts. Every security approach is flawed, and the next best thing to prevention is remediation.
AWS Config
AWS Config lets you evaluate the compliance status of your AWS account, making it more of a prevention than a remediation service.
Terraform AWS Secure Baseline
This Terraform module is a third-party tool for setting up your AWS account. After you create an account, just run the module, and it will automatically apply many of the above-mentioned best practices.
How CIEM can help
Cloud Infrastructure Entitlement Management (CIEM) is an emerging solution that can significantly enhance the management and security of cloud environments like AWS, particularly when used in conjunction with AWS Identity and Access Management (IAM).
CIEM tools (like Wiz's CIEM solution) provide advanced capabilities to manage identities, access policies, and entitlements across cloud platforms. Here’s how CIEM can specifically help with the AWS IAM best practices discussed:
Automated Least Privilege Enforcement: CIEM solutions can automate the enforcement of the principle of least privilege by continuously analyzing permissions and usage patterns. They can recommend or automatically adjust permissions to ensure that every entity (users, services, etc.) has only the access necessary to perform its tasks, thereby minimizing the risk of over-privileged accounts.
Visualization and Analysis of Entitlements: CIEM tools provide detailed visualization of permissions across all cloud assets. This can help organizations understand and manage complex permissions structures, making it easier to adhere to secure access policies and detect misconfigurations or risky entitlements that could lead to security breaches.
Scalable Management Across Multiple Accounts: For organizations using AWS Organizations with multiple accounts, CIEM tools can manage identities and permissions across all accounts from a single pane of glass. This capability is vital for maintaining consistency in security policies and simplifies the governance of large cloud environments.
Generating remediation recommendations: CIEM can also provide granular recommendations that enable teams to follow step-by-step remediation actions to right-size access and revoke unused or excessive permissions.
Risk Assessment and Compliance Reporting: CIEM platforms can assess risks associated with entitlements and access patterns, providing reports that help meet compliance requirements for various standards and regulations. This is especially useful in environments where access needs to be tightly controlled and audited regularly.
Take Control of Your Cloud Entitlements
Learn why CISOs at the fastest growing companies secure their cloud environments with Wiz.
DAST, or dynamic application security testing, is a testing approach that involves testing an application for different runtime vulnerabilities that come up only when the application is fully functional.
Defense in depth (DiD)—also known as layered defense—is a cybersecurity strategy that aims to safeguard data, networks, systems, and IT assets by using multiple layers of security controls.
IAST (Interactive Application Security Testing) is a security testing method that monitors applications in real-time during runtime to detect vulnerabilities by analyzing code behavior and data flow in live environments.
Open-source software (OSS) software composition analysis (SCA) tools are specialized solutions designed to analyze an application's open-source components and dependencies.
With a CNAPP, your team is empowered to pick and choose solutions that best fit your security capability and cost requirements. This article reviews the best open-source CNAPP tools for 2024.