Implementing Least Privilege in AWS: Strategies for Minimizing Security Risks

Published 07/14/2023

Written by Abhishek Bansal, Founder, Autharva.

Problem Statement

In the dynamic and ever-changing digital landscape, organizations find themselves in a perpetual battle against the looming specter of security breaches and unauthorized access to their most sensitive data. These risks have escalated to a point of paramount concern, with one specific security challenge demanding immediate attention: the pervasive issue of granting excessive privileges to users and services. Regrettably, this practice unwittingly expands the attack surface, leaving organizations perilously exposed to an elevated risk of data breaches. This conundrum assumes even greater significance in cloud computing environments, such as Amazon Web Services (AWS), GCP (Google Cloud Platform), Azure etc. compelling organizations to embrace proactive measures in order to forge resilient security frameworks that can withstand the test of time.

Impact of the Problem

Granting excessive privileges in AWS can have severe consequences and there have been lots of such incidents where excessive privilege gave leverage to attackers to increase the blast radius. If an unauthorized user gains access to an AWS account with extensive permissions, they can manipulate resources, compromise data, or launch destructive attacks. The impact of such incidents can be catastrophic, resulting in financial loss, reputational damage, legal implications, and regulatory compliance violations.

Moreover, overprivileged accounts can unintentionally cause damage. Misconfigurations or mistakes by users with excessive privileges may lead to data leaks, service disruptions, or unauthorized changes to critical infrastructure, affecting business continuity and customer trust.

Solution Definition

To address the problem of excessive privileges, organizations must implement the principle of least privilege (PoLP). The principle states that each user or service should have the minimum privileges necessary to perform their intended tasks and nothing more. By applying the PoLP in an AWS environment, organizations can significantly reduce the attack surface and mitigate security risks.

Solution Facts and Evidence

The PoLP can be implemented in multiple areas of AWS. Let’s review them in the order of priority:

1. Identity and Access Management (IAM) Policies:

AWS Identity and Access Management (IAM) allows fine-grained control over access permissions. Organizations can create IAM policies to define precise permissions for users, groups, and roles. By following the PoLP, these policies restrict access to only the necessary AWS resources, reducing the risk of unauthorized actions.

For example, an application running on an EC2 instance may only require read access to a specific S3 bucket. By crafting an IAM policy that grants read access to that bucket only, any compromise of the application or instance would be limited to the specified resource.

Example of one such Non-Compliant Policy :

{ 
  "Version": "2012-10-17",
  "Statement": [
    {    
  "Action": "s3:*"   
  "Resource": "*",   
  "Effect": "Allow"
    }
  ]
}

The policy above is overly permissive and grants unrestricted access to perform any action (s3:*) on any S3 resource (*). This poses a significant security risk as it allows full control over all S3 resources within the AWS account ☹️

Let’s make the policy resource-specific and enhance security. We must specify the specific S3 resources that the policy should apply to. So as an example of a resource-specific policy that allows read access to a specific S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject","s3:PutObject"]  
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Evidence:

Incident 1:

One such incident happened with a health-care organization on January 11, 2021; 20/20 Eye Care Network and Hearing Care Network which notify 3,253,822 health plan members of breach that deleted contents of AWS S3 buckets.

Incident 2:

Magecart S3 global write access allowed anyone to push anything in the bucket

Non-Compliant bucket policy with Magecert:

{
  "Sid": "AllowPublicRead",
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": [
   "s3:GetObject",
   "s3:PutObject"
  ],
 "Resource": "arn:aws:s3:::media.twiliocdn.com/taskrouter/*"
}

2. AWS Security Groups and Network ACLs:

AWS provides security groups and network access control lists (ACLs) as network-level controls. By defining explicit inbound and outbound rules, organizations can restrict network traffic flow based on the principle of least privilege. These security measures ensure that only authorized communication occurs between resources, minimizing the risk of unauthorized access.

Example:

Imagine an organization has an application with a web server and database server. To implement the PoLP, separate security groups need to be created for each server. The web server security group should only allow ingress on port 80 (HTTP) and 443 (HTTPS) from trusted sources, such as load balancers or specific IP ranges. The database server security group should allow ingress only from the web servers on the necessary database ports. Egress traffic rules can be defined to restrict access to known and trusted destinations.

Incident:

Globally exposed resources with AWS credentials enlisted tesla’s cloud to mine.

3. AWS Organizations and Service Control Policies (SCPs)

AWS Organizations allows organizations to manage multiple AWS accounts centrally. Service Control Policies (SCPs) enable administrators to set fine-grained permissions across accounts, restricting access to specific services or actions. By implementing SCPs aligned with the PoLP, organizations can prevent users or accounts from obtaining excessive permissions, reducing the attack surface across the entire organization's AWS infrastructure.

We can create base service control policies to implement PoLP. SCP is a Deny base policy instead of Allow, which means you can use it only for deny actions which is pretty cool :

Region Restriction Use Case

As in AWS, we have multiple regions available, but not all the regions we use for our work, One reason can be security and compliance. Let’s say we work in health-care or the financial sector and our org never shares data outside the country or region hence we need the resources to be available in a specific region.

Another reason can be Risk Mitigation, for instance region restriction policies can help in reducing the attack surface area and protecting valuable assets.

Like the below policy, we are restricting global services and services in region us-east-1 (Virginia) & ap-northeast-1 (Tokyo) to be used:-

- sid: "RestrictToSpecifiedRegions"
 effect: "Deny"
 not_actions:
   - "a4b:*"
   - "acm:*"
   - "aws-marketplace-management:*"
   - "aws-marketplace:*"
   - "aws-portal:*"
   - "awsbillingconsole:*"
   - "budgets:*"
   - "ce:*"
   - "chime:*"
   - "cloudfront:*"
   - "config:*"
   - "cur:*"
   - "directconnect:*"
   - "ec2:DescribeRegions"
   - "ec2:DescribeTransitGateways"
   - "ec2:DescribeVpnGateways"
   - "fms:*"
   - "globalaccelerator:*"
   - "health:*"
   - "iam:*"
   - "importexport:*"
   - "kms:*"
   - "mobileanalytics:*"
   - "networkmanager:*"
   - "organizations:*"
   - "pricing:*"
   - "route53:*"
   - "route53domains:*"
   - "s3:GetAccountPublic*"
   - "s3:ListAllMyBuckets"
   - "s3:PutAccountPublic*"
   - "shield:*"
   - "sts:*"
   - "support:*"
   - "trustedadvisor:*"
   - "waf-regional:*"
   - "waf:*"
   - "wafv2:*"
   - "wellarchitected:*"
 condition:
   - test: "StringNotEqualsIgnoreCase"
     variable: "aws:RequestedRegion"
     values:
       - us-east-1
       - ap-northeast-1
 resources:
   - "*"

4. Continuous Monitoring and Auditing:

Implementing the PoLP is an ongoing process. Organizations should regularly monitor and audit their AWS environment for compliance with security best practices. AWS provides services like AWS CloudTrail, Security-Hub and Amazon GuardDuty, which log and analyze API calls and network traffic, respectively. By leveraging these services and using security information and event management (SIEM) solutions, organizations can detect and respond to security incidents proactively.

Conclusion

Implementing least privilege in AWS is crucial for minimizing security risks and protecting sensitive data. By adhering to the PoLP, organizations can reduce the attack surface, prevent unauthorized access, and mitigate the potential impact of security incidents. By leveraging AWS services such as IAM, security groups, network ACLs, AWS Organizations, SCPs, and monitoring tools like AWS Trusted Advisor, organizations can establish robust security postures in their AWS environments.

By continuously monitoring and auditing their infrastructure and promptly addressing any identified vulnerabilities or misconfigurations, organizations can ensure that their AWS deployments remain secure. The PoLP serves as a fundamental pillar in maintaining a strong security posture and bolstering overall cybersecurity resilience in the face of evolving threats.

Citations

Incident Details:

Amazon Links for Learning:

About the Author

Abhishek Bansal, a thought leader in IAM, has over 11 years of experience in the cybersecurity industry. He has previously served at several leadership roles in large enterprises, and has been a part of the founding team of IGAaaS based cybersecurity startup. As a recognized global leader in cybersecurity, angel investor, startup advisor, and a subject matter expert of information security (Identity and Access Management, Identity Governance and Compliance), he possesses a rare ability to understand both the technical and business sides of the industry.

AWS Identity and Access Management Zero Trust