AWS Security: IAM, API Gateway, Lambda, Cloud Databases, S3

Published in

Pentester Academy Blog

7 min readFeb 4, 2021

In this post, we outline the 5 AWS services most commonly used in Cloud Deployments and best practices to secure them.

To practice the below concepts hands-on, subscribe to access our labs and on-demand AWS Security bootcamp!

The 5 most common AWS components: IAM, API Gateway, Lambda, Cloud Databases and S3.

With the advent of cloud computing, individuals, enterprises and large conglomerates are migrating towards the cloud. Amazon Web Services (AWS) is the most popular cloud service provider, supporting well over 100 services. Given its complexity and ubiquity, misconfigurations are common and AWS is an attractive attack vector.

Web applications built on AWS provide the interface for the enterprises to present their products to the world. The serverless web application architecture is a commonly used model for building these applications, and typically use the following components: IAM, API Gateway, Lambda, Cloud Databases and S3. It is therefore important to understand these components and how to set them up securely.

So, what are these components exactly? Let’s delve into each of them individually:

AWS IAM (Identity and Access Management)

In any company that uses the cloud, it’s inevitable to have different teams accessing resources simultaneously when working on projects. The question thus arises: how can access be provided to everyone in a secure manner?

This is where IAM (Identity and Access Management) comes into the picture. IAM allows administrators to provide access to other users, applications and services to interact with specific AWS resources.

With IAM, access can be provided to users within the same account as well to users from other AWS accounts. The access to resources can be restricted with the help of IAM policies.

Of course, IAM risks misconfigurations that result in security vulnerabilities, such as:

Creating privileged roles which can be assumed by any AWS user. Anyone with the knowledge about the role can assume the role and perform privileged operations.
Providing overly permissive privileges to a role used by a service such as EC2 or Lambda. Upon exploiting a vulnerability/misconfigurations in the application running/using the service, the attacker might be able to get hold of the role’s temporary access credentials, allowing the attacker to perform privileged operations.
Providing low privileged users the ability to perform critical IAM operations such as attaching policy, adding user to group, etc.

Here are some defensive implementations that you can perform:

Utilize AWS Config that comes with prebuilt rules.
For IAM permissions, follow the principles of least-privileged access when creating policies and only assign a minimal set of permissions. Use tools like CloudTracker (https://github.com/duo-labs/cloudtracker) to help identify unused permissions. You can also limit IAM permissions using service control policies and permissions boundaries.
Use third-party tools such as ScoutSuite (https://github.com/nccgroup/ScoutSuite) and Pacu (https://github.com/RhinoSecurityLabs/pacu) to audit accounts for security misconfigurations

AWS API Gateway

AWS API Gateway acts as the “front door” for applications to access data, business logic, or functionality from your backend services. It also supports containerized and serverless workloads, as well as web applications.

API Gateway provides benefits such as:

Traffic management
Authorization & authentication
Monitoring & logging
API versioning

AWS has 2 different types of API Gateways which are RESTful APIs and WebSocket APIs that enable real-time two-way communication applications.

Many API gateways fall into the trap of exposing too much information and relying on the client to filter out any unnecessary data. These extra details can provide insight into your application architecture with verbose stack traces or giving access to data that should not be available.

To ensure API Gateway is secure, consider the following practices:

Setting up data transformations for REST APIs, you can sanitize the outbound data to send only what is needed.
Application with multiple use cases, such as mobile apps, IoT devices and integration with internal systems, consider creating separate API gateways for each one. This is to prevent exposing endpoints that are intended for internal use.
Ensure you remove any APIs that are no longer in use and remove any old versions which do not include new security measures implementation at the application level.
Ensure constant monitoring on your API Gateway to give you an oversight of all the APIs and their usage.

AWS Lambda

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes.

Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and logging. All you need to do is supply your code in one of the languages that Lambda supports.

You can write Lambda functions in your favorite language (Node.js, Python, Go, Java, and more) and use both serverless and container tools, such as AWS SAM or Docker CLI, to build, test, and deploy your functions.

With Lambda being able to access anything, security becomes a major consideration. Here are some best practices:

Follow the principle of least privilege for the role associated with the lambda function
It is a good practice to keep the AWS credential away from the code

It’s also prudent to train developers to have a security-first mindset such as:

Embrace secure coding principles and try to do adopt these principles as you develop
Run tools to seek for code vulnerabilities
Focus on permissions from the bottom-up, assuming the function requires nothing

Cloud Databases (such as AWS DynamoDB)

AWS DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability.

DynamoDB lets you offload the administrative burdens of operating and scaling a distributed database so that you don’t have to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling.

With DynamoDB, you can create database tables that can store and retrieve any amount of data and serve any level of request traffic. You can scale up or scale down your tables’ throughput capacity without downtime or performance degradation. However, applications which use DynamoDB may not be coded properly, which results in vulnerabilities such as NoSQL and SQL Injection attacks.

When setting up AWS DynamoDB, here are some best practices to follow:

Encryption at rest
Use IAM roles to authenticate access to DynamoDB
Use IAM policy conditions for fine-grained access control
Use a VPC endpoint and policies to access DynamoDB
Consider client-side encryption
Monitor DynamoDB compliance & configuration with AWS Config rules
Tag your DynamoDB resources for identification and automation

AWS S3

AWS S3 (Simple Storage Service) is a storage service that offers industry-leading scalability, data availability, security, and performance.

This means customers of all sizes and industries can use it to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics.

AWS S3 provides easy-to-use management features so you can organize your data and configure finely-tuned access controls to meet your specific business, organizational, and compliance requirements.

Although S3 is highly scalable, reliable, and easy to use. But getting the security of S3 right — and making sure it stays that way — continues to bewilder many AWS customers.

Here are 7 security practices for AWS S3 to consider:

Implement a “Least Privilege” access model to limit access to S3 resources by using a combination of Identity and Access Management (IAM) policies, bucket policies, and S3 Access Points
Ensure that your S3 buckets are not publicly accessible
Encrypt all Amazon S3 data at rest using Server-side Encryption (SSE) or client-side encryption
Use versioning to preserve, retrieve, and restore your objects
Enable Multi-factor Authentication (MFA) Delete and S3 Object Lock when appropriate
Identify and audit all of your Amazon S3 buckets
Implement monitoring of your S3 environment and bucket policies

Learn from an attacker’s viewpoint

Our on-demand AWS Security bootcamp covers the 5 components in-depth.

To learn how to secure the 5 components, look no further than our on-demand bootcamp: learn to identify, exploit and secure vulnerabilities in the 5 most commonly used AWS components, so you can be a job-ready Cloud Security practitioner.

Along with our on-demand bootcamp, our lab platform also includes 50+ exercises for hands-on practice. Unlike other platforms, our labs let you practice attacks without the hassle and risk of using your personal AWS account. Getting started with Cloud Security has never been easier!