IAM Policy: The Basic Structure And Best Practices

AWS IAM: A Basic Introduction

As organizations evolve from startups to large enterprises, the complexity of identity access management (IAM) increases accordingly and managing access and identity becomes more intricate with company expansion. AWS Identity and Access Management (IAM) is a service that offers precise control over access to AWS resources. With AWS IAM, developers and users determine the level of access for users, groups, or roles, answering the fundamental question of “Who can perform What Action on Which Resource?”.

In this article, we delve into the AWS IAM service, focusing on IAM policies. We’ll explore their structure, creation process, and best practices. Let’s begin with the smallest building block of the IAM – AWS Policies.

AWS Policies

The smallest building block of AWS Identity and Access Management (IAM) is undoubtedly the AWS policies. AWS policies are JSON documents that define permissions. They dictate what actions are allowed or denied on AWS resources. These policies are attached to IAM identities (such as users, groups, or roles) or AWS resources to manage access effectively. By default, within AWS, an entity lacks permission to perform any action unless specifically granted.

Policy Structure

AWS policies are structured in JSON (JavaScript Object Notation) format. This format provides flexibility and readability. Policy JSON documents are comprised of the following elements:

Versioning:

AWS policies include a “Version” field to specify the version of the policy language being used. This ensures compatibility and allows for updates to the policy language over time.

Statements:

The “Statement” element in a policy defines a set of permissions. Each statement can have multiple attributes such as “Effect”, “Action”, and “Resource” (the AWS resources to which the policy applies).

Principal

A principal represents an entity (an IAM user or application) that can request an action or operation on an AWS resource. This can range from a single user to an entire.

Examples:

"Principal": {"AWS": "arn:aws:iam::123456789012:user/John"}

"Principal": {"AWS": "arn:aws:iam::123456789012:role/OperationsRole"}

These examples illustrate different types of principals that can be specified in an IAM policy

Effect:

he “Effect” is a crucial element that specifies whether the permissions defined in the policy are granted or denied. It determines the outcome of evaluating the policy when a request is made to access AWS resources.

  • Explicit deny – Explicit deny: This occurs when an AWS request matches a statement with an Effect of Deny. An explicit deny takes precedence over allow statements
  • Implicit deny: This is the outcome when an AWS request doesn’t match any statement with either an Effect of Allow or Deny. All IAM policy evaluations begin with an implicit deny, which persists until a matching Allow or Deny statement is encountered.
  • Explicit allow: This happens when an AWS request matches a statement with an Effect of Allow and no matching Deny statement is found.
  • Implicit allow: This scenario is not applicable. Access to an AWS resource must be explicitly permitted

Action

In AWS policies, actions define the specific operations or tasks that are allowed or denied on AWS resources. These actions correspond to API operations provided by AWS services. Essentially, actions determine what users, roles, or services can do with the AWS resources.

Actions are typically specified in the form of “{service}:{action}” . Here, “service” refers to the AWS service, and “action” denotes the specific operation or action within that service. For example, “s3:PutObject” represents the action of uploading an object to an Amazon S3 bucket.

Resource

Resources refer to the AWS entities or objects to which the actions specified in the policy apply. These resources can include a wide range of AWS services such as EC2 instances, S3 buckets, RDS databases, IAM users, SQS queues, and many more.

Resources are identified using Amazon Resource Names (ARNs), which are unique identifiers for AWS resources. ARNs are structured strings that provide information about the AWS account, region, service, and specific resource.

For example, here are some examples of resources specified using ARNs in AWS policies:

"Resource": "arn:aws:s3:::testbucket"
"Resource": "arn:aws:rds:us-west-2:123456789012:db:mysql-db"

Sid

“Sid” stands for “Statement ID.” It is an optional element within IAM policies that allows you to assign a unique identifier to each statement within the policy. The Statement ID is a string value that helps you identify and reference individual statements within the policy.

Condition

Conditions is an optional statement that allows you to specify additional criteria that must be met for the policy to take effect. Conditions provide a way to add flexibility and granularity to access control by allowing you to define circumstances under which permissions are granted or denied.

Here’s an example of a JSON policy document:

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "ListAndGetObjectsInBucket",
           "Effect": "Allow",
           "Action": [
               "s3:ListBucket",
               "s3:GetObject",
               "s3:GetObjectAcl",
           ],
           "Resource": [
               "arn:aws:s3:::testbucket"
           "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/John"
           ]
       },
   ]
}

IAM Policy granting permissions to list bucket contents, retrieve objects, and access object ACLs within an S3 bucket named “testbucket.

For further insight into various IAM policies, refer to the IAM documentation. Additionally, you’ll discover strategies for effectively distributing ownership of these policies

Policy Types

Let’s look at the different types of policies that exist in AWS.

  • Identity-based policies are attached directly to IAM identities such as users, groups, or roles. These policies define permissions specific to individual IAM entities and govern their access to AWS resources. Identity-based policies are versatile and can be tailored to meet the specific needs of each IAM entity.Policies could be either Managed policies or Inline policies.
  • Resource-based policies are attached to AWS resources such as S3 buckets, SQS queues, or Lambda functions. These policies define who (which IAM identities) can access the associated resource and what actions they are allowed to perform. Resource-based policies are commonly used for granting cross-account access or enabling access to publicly accessible resources.
  • IAM permissions boundaries control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure.
  • Access control lists(ACLs) are attached to resources and control cross-account permissions for principals from other accounts.
  • Organizations Service Control Policies(SCPs)  are a type of AWS Organizations policy that allows organizations to set broad controls over the AWS services and actions that are accessible within member accounts. SCPs are applied at the organizational unit (OU) level and can restrict access to certain services or actions across all accounts within the OU.

AWS IAM: 5 Best Practices

As previously noted,striking a balance between flexibility and security in IAM management is vital for maintaining application security and can prove challenging. Now, let’s delve into some recommended practices for harnessing the capabilities of IAM.

1. The least privilege principle

The principle of least privilege, ensures that identities are granted only the minimal access and responsibility required for their tasks. A recommended practice is to begin with a minimal set of permissions and incrementally grant additional permissions as needed.

Consider the scenario of managing objects within s3 buckects where you need users to read and write objects within an S3 bucket . Creating a policy with a wildcard allowing all bucket operations might seem convenient at first glance:

{
    "Statement": {
        "Effect": "Allow",
        "Action": "s3:*",
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
    }
}

Granting unrestricted access to all actions within an S3 bucket is generally not recommended for security reasons. This policy grants access to all s3 operations, including potentially harmful actions like deleting all an object with sensitive data. An optimal approach involves specifying each required action and narrowing the scope of the Resource section

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:GetObjectAcl",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket/*",
                "arn:aws:s3:::example-bucket"
            ]
        }

Although using wildcards is generally discouraged, it may be necessary in certain situations, as in the policy above where multiple objects may exist in the bucket making it impractical to reference each one individually, unless when necessary.

2. Use IAM Roles Effectively

IAM rolesare a versatile and powerful feature in IAM, similar to IAM users but with a crucial difference: roles can be assumed by multiple entities simultaneously. This flexibility allows for the issuance of temporary access grants without the risks associated with long-lived credentials.

IAM roles eliminate the need for long-term credentials like passwords or access keys, providing a more secure method of granting resource access. The temporary nature of these credentials reduces the risk of unauthorized access and enhances overall security.

IAM roles are especially valuable for allowing applications or services to utilize AWS resources without embedding AWS keys directly into the application. This mitigates the exposure of sensitive credentials, which can be challenging to update and potentially susceptible to extraction by unauthorized users.

3. Multi-Factor Authentication (MFA)

MFA adds an extra layer of security beyond passwords by requiring users to provide a second authentication factor, such as a code from an MFA device. This significantly reduces the risk of unauthorized access and enhances the overall security of AWS accounts and resources By implementing MFA, AWS users can mitigate the risk of unauthorized individuals gaining access to sensitive systems or data, as MFA ensures that even if passwords are compromised, an additional factor is required for access

4. Regularly remove unused users, and roles

It is advisable to minimize permissions and eliminate unused users and roles to achieve the principle of least privilege. Many compliance standards and regulations mandate the removal of unused users and roles to maintain a secure environment. Regularly reviewing and removing unused access aligns with security best practices and helps organizations meet regulatory requirements, ensuring data protection and privacy compliance

5. Monitoring usage using AWS CloudTrail

We need to use AWS CloudTrail for access management primarily because it provides comprehensive logging and monitoring capabilities for AWS API activity, offering insights into who accessed AWS resources, what actions were performed, and when they occurred. Here are the key reasons why CloudTrail is essential for AWS access management. CloudTrail records API calls made in AWS accounts, capturing details such as the identity of the caller, the time of the API call, the source IP address, and the actions performed. This audit trail provides visibility into user activity and helps organizations track changes and troubleshoot security incidents.

6. Delegate permissions guardrails across multiple accounts

As you expand your workloads, segment them by utilizing multiple accounts managed through AWS Organizations. We advise implementing Organizations service control policies (SCPs) to establish permission guardrails, ensuring access control for all IAM users and roles across your accounts. SCPs function as a form of organizational policy that enables you to manage permissions within your organization at the AWS organization, organizational unit (OU), or account level

Conclusions

In conclusion, IAM policies form the building block of access control and security within AWS environments, guiding the granularity of permissions granted to users, roles, and resources. Understanding IAM policy types, their structure, and the best practices surrounding IAM implementation is crucial for organizations seeking to fortify their cloud security posture.

By adopting a principle of least privilege, organizations can minimize the risk of unauthorized access and data breaches, while also ensuring compliance with regulatory requirements. Utilizing IAM policies effectively enables organizations to achieve a balance between security and operational flexibility, allowing for the precise delegation of permissions based on business needs.

 

Share

Leave a Reply

Your email address will not be published. Required fields are marked *