In today’s interconnected digital landscape, robust IAM (Identity and Access Management) practices are critical pillars of an organization’s cybersecurity strategy. IAM serves as the fortress guarding sensitive data, applications, and systems from unauthorized access or breaches. Implementing top-tier IAM practices ensures not only data protection but also compliance adherence and streamlined user access.
What is AWS IAM
AWS IAM is a service empowering AWS clients to securely and flexibly control access to AWS resources. IAM facilitates the creation and administration of AWS users and groups, offering precise, detailed permissions to these entities for accessing specific AWS resources.
Here are key IAM best practices that organizations should consider:
Multi-Factor Authentication (MFA)
Enforcing multi-factor authentication for IAM users is a very important step for overall account security.
Multi-factor authentication (MFA) enhances account security by necessitating a secondary factor, like a code from an authenticator app or a physical token, alongside the user’s password for authentication.
It’s also possible to mandate the use of MFA across your entire AWS account or organization by creating a dedicated Service Control Policy (SCP).
Strong Password Policies and Regular Rotation
Implement strong password policies, including complexity requirements (such as longer strings with mixes of case, numerals and symbols ) and periodic password/key rotations.
Securing Root Account
Upon initial creation of an AWS account, you are provided with a default set of credentials that grant full access to all AWS resources within your account. This set of credentials identifies as the AWS account root user.
It is strongly recommend not to access the AWS account root user unless you have a task that requires root user credentials such as:
Changing your account settings – This includes the account name, email address, root user password, and root user access keys. Other account settings, such as contact information, payment currency preference, and AWS Regions, don’t require root user credentials.
Restoring IAM user permissions – If the only IAM administrator accidentally revokes their own permissions, you can sign in as the root user to edit policies and restore those permissions.
Activating IAM access to the Billing and Cost Management console.
Viewing certain tax invoices – An IAM user with the aws-portal:ViewBilling permission can view and download VAT invoices from AWS Europe, but not AWS Inc. or Amazon Internet Services Private Limited (AISPL).
Closing your AWS account.
Configuring an Amazon S3 bucket to enable MFA (multi-factor authentication).
Editing or deleting an Amazon Simple Queue Service (Amazon SQS) resource policy that denies all principals.
Editing or deleting an Amazon Simple Storage Service (Amazon S3) bucket policy that denies all principals.
Signing up for AWS GovCloud (US).
Requesting AWS GovCloud (US) account root user access keys from AWS Support.
In the event that an AWS Key Management Service key becomes unmanageable, you can recover it by contacting AWS Support as the root user.
So if you are not doing one of the above, instead of accessing the root user, create an administrative user for everyday tasks. Some other best practices include:
Don’t create access keys for the root user
Use multi-person approval for root user sign-in wherever possible
Use a group email address for root user credentials
Monitor the access and usage of root account
Implement least-privilege permissions
The principle of least privilege in AWS revolves around granting users or systems the minimal permissions required to perform their necessary tasks or access specific resources. This practice aims to reduce the potential impact of security breaches or mistakes by limiting access to only what is essential.
Granular Permissions: Assign permissions at the most granular level possible, restricting access to specific actions, resources, or services.
Role-Based Access Control (RBAC): Implement RBAC principles, creating roles tailored to specific job functions or responsibilities with appropriate permissions.
Use IAM Access Analyzer to generate least-privilege policies based on access activity
Remove inactive/unused entities periodically
In your AWS account, there might be IAM users, roles, permissions, policies, or credentials that are no longer being used. IAM offers last accessed data to assist in pinpointing these unused users, roles, permissions, policies, and credentials, enabling their removal. This practice aids in minimizing the number of entities requiring monitoring.
Use IAM Access Analyzer
Regularly review and audit IAM configurations using tools like AWS IAM Access Analyzer. Check for unused users, roles, and policies and remove or adjust them as necessary.AWS Identity and Access Management Access Analyzer provides the following capabilities:
IAM Access Analyzer external access analyzers help identify resources in your organization and accounts that are shared with an external entity.
IAM Access Analyzer unused access analyzers help identify unused access in your organization and accounts.
IAM Access Analyzer validates IAM policies against policy grammar and AWS best practices.
IAM Access Analyzer custom policy checks help validate IAM policies against your specified security standards.
IAM Access Analyzer generates least privilege IAM policies based on access activity in your AWS CloudTrail logs.
Use IAM Policies
IAM policy conditions in AWS allow fine-grained control over when policies are applied. These conditions can be based on various factors like time, IP address, resource tags, or request parameters.
Use Conditions in IAM policies to restrict access
Date and Time: Policies can be set to be active only during specific dates or times, ensuring access is restricted to particular periods.
Temporary Tokens: Conditions can be applied to restrict actions based on the temporary nature of IAM credentials.
IP Address: Policies can enforce actions only if the request originates from specific IP ranges or addresses.
VPC Endpoints: Controls can be placed on actions performed within Virtual Private Cloud (VPC) endpoints.
Request Parameters: Policies can evaluate conditions based on request parameters such as tags, resource names, or user agents.
Encryption Context: Conditions can be set based on encryption context for specific cryptographic operations.
Resource Tags: Policies can evaluate tags assigned to resources, allowing or denying actions based on specific tags.
Resource ARN: Controls can be placed based on the Amazon Resource Name (ARN) of resources being accessed.
Multi-Factor Authentication: Policies can mandate MFA for certain actions like you need to put MFA code for terminating an EC2 instance
AWS Services Conditions: Conditions can be set to allow or deny actions based on the AWS service used to make the request.
Customer Managed Policies over Inline Policies
While AWS-managed policies serve as a good starting point, they don’t strictly adhere to the least privilege principle. It’s advisable to employ policies that strictly follow the least privilege principle. The most secure approach involves crafting a custom policy tailored to grant only the necessary permissions required by your team.
Attach policies to Groups Instead of Users
Permission Policies should be attached to groups and then users should be added to the group for granting access instead of attaching policies directly to users.
Use SCPs to restrict theAccess at Organization Level
Service control policies (SCPs) are a type of organization policy that you can use to manage permissions in your organization.
SCPs are often used to restrict permissions rather than grant them. They can be used to create a whitelist of allowable services and actions, ensuring that accounts within the organization do not exceed certain permission boundaries.
By default, SCPs have a “deny all” principle, meaning that if an action is not explicitly allowed by an SCP, it is denied. This allows administrators to create a secure baseline and explicitly grant permissions as needed.
SCPs are commonly used for security and compliance purposes. For example, they can be used to ensure that certain accounts or OUs do not have access to specific AWS services or actions to meet regulatory requirements.
Prefer IAM roles instead of access keys
For applications requiring AWS access use temporary credentials using IAM role instead of access keys. As access keys pose a higher risk of compromise due to their long-term validity.
Never put your access keys in unencrypted code/plain text.
Use AWS Identity Center
Use IAM Identity Center to securely scale access across accounts and applications. Below are the benefits of using Identity Center
Centralized Identity Governance: If you need comprehensive governance and management of identities across multiple AWS environments.
Lifecycle Management: When you require tools and capabilities for managing the complete lifecycle of identities, including provisioning, access control, and deprovisioning.
Compliance and Risk Management: For implementing governance policies, ensuring compliance, and managing risks related to identity and access across AWS.
Continuous Monitoring and Auditing
Deploy continuous monitoring mechanisms to track user activities, access attempts, and system changes. Regularly conduct audits to identify anomalies, ensuring compliance and swift response to potential threats. Use cloudtrail, AWS config, and Guraduty logs for monitoring and alerting for any anomalous activity.
Out-of-the-Box AWS IAM Security with Coralogix
So far we have discussed best practices for AWS IAM. Equally important is to have in place mechanisms to be notified in real-time of any unusual or abnormal events and/or configuration changes. Hence detective controls are needed to be in place.
Coralogix security offering provides a comprehensive set of out-of-the-box detections & alerts for AWS IAM. Some of the notable ones include: