Best Practices – IAM Audit Checkpoints for Optimal Security on AWS
Introduction
As organizations leverage the cloud’s power, ensuring robust security measures becomes paramount. At the heart of this security framework is Identity and Access Management (IAM), a critical component in safeguarding digital assets and data.
This blog aims to delve into the core of AWS security by exploring the best practices associated with IAM, specifically focusing on audit checkpoints and compliance with minimum or no cost.
Section 1: Understanding IAM on AWS
IAM Fundamentals
IAM, or Identity and Access Management, is the bedrock of security in AWS, consisting of key components:
- Users: Individuals or systems interacting with AWS services, each with unique authentication credentials.
- Groups: Organizational units streamlining access management by applying policies to multiple users simultaneously.
- Roles: Permissions defined for making AWS service requests are not tied to specific users or groups but are assumed by trusted entities.
- Policies: JSON documents explicitly state permissions and dictate allowed or denied actions on AWS resources.
- Permissions: The crux of IAM, meticulously configured to adhere to the principle of least privilege, ensuring minimal access for necessary tasks.
IAM use cases
IAM facilitates secure access to AWS resources by allowing organizations to:
- Control Access: Define who can access AWS resources and what actions they can perform.
- Grant Permissions: Assign permissions to users, groups, or roles based on their responsibilities.
- Enable Multi-Factor Authentication (MFA): Add an extra layer of security by requiring users to provide two or more authentication factors.
- Manage Resource-Level Permissions: Fine-tune access controls at a granular level, ensuring precise authorization for specific resources.
Section 2: Best Practices for IAM on AWS
Principle of Least Privilege: Grant the minimum level of permissions necessary for users and processes to perform their tasks. This reduces the risk of accidental or intentional misuse of privileges.
Strong Password Policies: Enforce robust password policies to enhance authentication security. This includes setting password complexity requirements, expiration periods, and the use of multi-factor authentication (MFA).
Role-Based Access Control (RBAC): Leverage roles to define and manage permissions dynamically. Assign roles based on job responsibilities, allowing users to assume different roles as needed.
Regularly Rotate Credentials: Periodically rotate access keys, secret keys, and other credentials to limit the window of opportunity for potential security threats.
Continuous Monitoring: Implement continuous monitoring of IAM activities using AWS CloudTrail. Regularly review and analyze logs to detect and respond to suspicious or unauthorized actions.
Regular User Access Reviews: Conduct periodic user access reviews to ensure it aligns with current roles and responsibilities. Remove or adjust permissions for users who no longer require certain accesses.
MFA Configuration: Ensure Multi-Factor Authentication is enabled for all users, especially those with elevated privileges. This additional layer of security significantly reduces the risk of unauthorized access.
Logging and Monitoring: Regularly inspect AWS CloudTrail logs for IAM-related events. Set up alerts for suspicious activities and anomalies, allowing for swift responses to potential security incidents.
Password Policy Enforcement: Audit and enforce strong password policies, including complexity requirements and regular password rotations. This ensures a robust first line of defense against unauthorized access.
Section 3: Easy solutions to be implemented
Setup strong password policy – Standard IAM policies
This can be done as per the client’s needs and can be edited under the IAM section. Please refer to the screenshot below –
Below is an example of a strong password policy.
Password strength
- Require at least one uppercase letter from the Latin alphabet (A-Z)
- Require at least one lowercase letter from the Latin alphabet (a-z)
- Require at least one number
- Require at least one non-alphanumeric character
Other requirements
- Password expires in 90 days
- Allow users to change their password
- Prevent password reuse from the past 24 changes
Review group-level permissions review –
Step 1: Access the IAM Console
Navigate to the AWS Management Console, select IAM, and click on “Groups” in the left navigation pane.
Step 2: Review Group Permissions
Select the Group and choose the IAM group you want to review.
View Attached Policies:
Examine policies attached to the group to ensure they align with the principle of least privilege.
For Example:-
The group for ses has only the required permission set to it. In this case, it is a policy that allows us to send emails via SES.
Step 3: Adjust Permissions
Modify Policies: Edit policies for precise permissions based on the principle of least privilege.
Add or Remove Policies: Adjust policies as needed, considering custom policies for specific requirements. This Review can be done at the time of group creation as well as quarterly for all groups.
Credential management report –
Why is the Credential Management Report used?
Credential management is vital for maintaining the security of AWS resources. Compromised credentials can lead to unauthorized access and potential data breaches. With proper credential management, access to AWS resources can be tightly controlled, reducing the risk of security incidents. It enables smooth operations by ensuring that the right individuals have the appropriate level of access to AWS resources, thereby enhancing overall operational efficiency.
How to create a Credential Management Report?
Under the Access Reports section in IAM, we can find the Credential Report.
Click on Download Credentials Report.
A CSV file will be downloaded with all report findings; below is a screenshot for reference –
You can go through columns like mfa_active and password_enabled to check the exact type of access enabled for any particular user. We can also see the age of the access keys or passwords for the IAM users if we go through columns like password_last_changed or access_key_last_rotated columns.
Whichever users are non-compliant need to be highlighted, and if the access is no longer required, it must be removed effectively. It is recommended to do this activity monthly.
Access analyser reporting
We have already created an SOP for doing Access Analyser Audits. Please click here for the same – LINK
Please find the screenshot below for reference on where to access the Access Analyser for your audits.
A summary of the Access Analyser audit is as follows –
1. Go to the Access Analyser section, as mentioned in the screenshot.
2. You are required to audit 2 aspects – External Access (Recommended) and Unused Access (Unused access incurs a cost – this would need client approval before setup; for more details, refer to the SOP document shared above)
3. Take all active findings and export them. (The exported file will be a JSON file; you will need to convert it to CSV to work on it).
4. Below is a Python script to convert any JSON file to CSV.
import json import csv def json_to_csv(json_file, csv_file): with open(json_file, 'r') as jsonfile: data = json.load(jsonfile) with open(csv_file, 'w', newline='') as csvfile: csv_writer = csv.writer(csvfile) csv_writer.writerow(data[0].keys()) for row in data: csv_writer.writerow(row.values()) #00 JSON file path example_json_file = '123.json' # Change this accordingly #01 CSV file path example_csv_file = 'final.csv' # Change this accordingly # JSON to CSV json_to_csv(example_json_file, example_csv_file) print(f'Conversion complete. CSV file created at Desktop')
Please make changes in #00 and add the file name to it (file name of the JSON file you exported from AWS instead of 123.json)
Now Open the CSV select all cells, and create a filter. The CSV file will have a column named Resource Type.
This will help you filter the findings on the basis of resource type – IAM role, S3 bucket etc.
You can check details like public access ON or no, and also what exact access is enabled on the particular resource.
Once you filter using the resource type –
You can review the exact resource and its enabled access. Refer to the screenshot below –
Here, you need to establish 2 things –
1. In cases where you see that you are not following the least privilege policy, it is as per the use case for the client.
Such findings can be archived if they are required indefinitely. This way, these won’t be highlighted in future reports.
OR
You can list these as per use case and continue to add proper information about the use case in remarks while sharing the report externally.
2. In case there is a resource where the least privilege needs to be followed but is not being followed, please take corrective action to enforce the same.
Before any modification to any resource, please discuss internally (with the DevOps team) as well as corrective actions like deletion of the resource must not be done without both internal and external approvals.
The report then needs to be shared internally and, once reviewed, can be shared externally.Below is an example of an external email shared with the findings.
Conclusion: In simple terms, this guide about IAM on AWS is like a map for organizations that want to understand IAM security better, starting from the basics to practical solutions. Following the best practices and using simple IAM solutions helps organizations strengthen their AWS spaces against changing security issues. This ensures that their cloud system stays tough and secure.