Security Considerations in Amazon Web Services (AWS)
What is Amazon S3?
What is Amazon EC2?
Misconfigurations in AWS EC2
AWS Identity and Access Management (IAM)
What is Amazon RDS?
There are several reasons to adopt cloud services, and there has been a growing increase in total spend on cloud services over the last decade. Cloud computing offers speed and agility, competitive pricing models to deploy various IT resources and flexibility.
The cloud services market share is dominated by Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Of the three main providers, AWS currently occupies the highest percentage of the market as of 2022. This blog focuses on security within AWS specifically, highlighting security issues within common services as well as secure design choices and practices.
AWS has hundreds of services within its global infrastructure. These can be broken down into high-level services such as Storage, Compute, Databases, and Security, Identity & Compliance. Below are some examples of the most popular services that sit within these class types:
● Storage – Simple Storage Service (S3)
● Compute – Elastic Compute Cloud (EC2)
● Security, Identity & Compliance – Identity Access Management (IAM)
● Databases – Relational Database Service (RDS)
What is Amazon S3?
Amazon S3 is one of the fundamental services of AWS used to store static files. Files or objects in AWS, are stored within buckets, which is AWS terminology for folders. S3 buckets are a widely used storage class within AWS and are an attractive target for adversaries as it is often used to store sensitive company data. Amazon S3 offers many features to ensure the security of S3 buckets, such as encryption and granular control over public access; however, it can be easy to misconfigure a bucket. For example, a bucket may unintentionally be made public that was only intended for internal use, containing sensitive company data.
A recent case of an insecure Amazon S3 bucket came to light, exposing the personal details of around 500,000 Ghanaian graduates. The exposed unencrypted data was related to Ghana's National Service Secretariate (NSS), and included personal information, employment records and scans of IDs. Whilst some of the files stored on the bucket had password protections, many did not and this allowed Researchers at vpnMentor to easily extract a large amount of sensitive data.
Delving into Amazon S3’s security capabilities, provided below are some high-level descriptions of controls that can be used to protect data stored on S3:
● Block Public Access – S3 offers granular control over the public access of buckets and objects. Block Public Access can be applied to every bucket within an account for both existing as well as buckets that are added in the future. By default, the Block Public Access setting is turned on when a bucket is created and requires the setting to be disabled to enable public access. This was not always the default behaviour; hence it is now harder to make the mistake of exposing sensitive data.
● Encryption – S3 supports both server-side using either Amazon S3-managed keys (SSE-S3) or customer-managed keys (CMKs) stored within AWS Key Management Service (AWS KMS) and client-side encryption for file uploads.
● Macie – A Service within AWS that uses machine learning and natural language processing to identify, categorise and protect sensitive data stored in S3, such as personal identifying information (PII).
Various other security features are integrated with Amazon S3 such as secure transport, versioning, and access logging.
Other S3 security features such as default encryption or versioning are not enabled by default and require the user to enable them.
What is Amazon EC2?
The Elastic Cloud Compute (EC2) service provides EC2 instances, which are customisable virtual machines in the cloud that enable rapid scalability, instant boot times and cost-effectiveness. Amazon EC2 can be used for countless use cases within an organisation, for example:
● Hosting services (e.g hosting a Web Application or Software)
● High-performance computing
● Development and test environments
AWS EC2 instance types
There are a number of EC2 instance types that Amazon provides which are all optimised and tailored to fit different cases:
● General Purpose Instances
● Compute Optimised Instances
● Memory Optimised Instances
● Accelerated Computing Instances
● Storage Optimised Instances
● Micro Instances
AWS uses the shared responsibility model; meaning AWS manages the security of their cloud, such as the physical security of its data centres or patching hypervisors that EC2 instances run on. On the other hand, customers are responsible for the security of their data, applications, networks etc. For example, customers are responsible for securing their EC2 instances, such as applying the latest patches or protecting sensitive data contained within them.
It is worth mentioning access to EC2 instances is typically achieved via SSH. It is recommended to adopt the use of controls such as key-based authentication and an approved list of IP addresses, to deter traditional attacker methods such as password brute forcing. Access to the underlying EC2 instance can often be catastrophic.
Misconfigurations in AWS EC2
Common misconfigurations or poor security controls that can occur on AWS EC2 instances and pose a security risk include:
● Credentials (Access Key/Secret Access Keys) stored on the EC2 instance
● No encryption for volumes and snapshots
● Missing patches, updates, and secure configurations on the operating system of the EC2 instance
Looking at the example of the misconfiguration that may expose credentials on an EC2 instance. Firstly, it is important to briefly explain permissions in AWS. IAM roles, groups and users in AWS are attached policies (permissions), these policies dictate what actions a user can perform. AWS provides granular control over permissions with their existing selection of policies.
If the access key ID and secret access key are stored on an EC2 instance and a threat actor manages to obtain unauthorised access to the instance, they could extract the access key ID and secret access key and use them to interact with the AWS account from anywhere in the world. Suppose that user has been inadvertently given more permissions than they require for their intended function, for example, they have been attached to the AdministratorAccess policy when they only need to interact with the S3 service, the attacker would effectively have full control over the AWS account.
Say you have provisioned an EC2 instance – any applications that run on that instance must include AWS credentials in the AWS API requests. This commonly results in AWS credentials stored directly on the EC2 instance, such as in the ./aws/credentials file as shown below.
Using roles is the preferred method of interacting with AWS services and the most secure because credentials are temporary and rotated automatically. The least privilege principle must be always followed, so entities only have the right set of permissions to perform their intended functions.
AWS Identity and Access Management (IAM)
Identity Access Management (IAM) is used within AWS to provision access for users, groups, and roles. A policy is an object in AWS that defines permissions, and there are a variety of AWS-managed policies that allow for control over the permissions that a user, group or role is given. Alternatively, custom policies can be created.
It is important to note when discussing IAM, there are three methods of interacting with AWS:
● Console Access (Username/Password)
● Programmatic Access Keys (Access Key and Secret Access Key ID)
● Software Development Kits (SDKs)
Security within IAM can be difficult. Done wrong, it can result in privilege escalation vectors, exposure of credentials or account compromises. Some examples include:
● Misconfiguration with IAM policies, e.g. making a new lambda function and giving it a role that allows it to do more
● Exposing credentials, e.g. uploading Access Keys to public GitHub repositories
● Highly privileged accounts (Root or AdministratorAccess) with weak passwords and no Multi-Factor Authentication (MFA)
Setting IAM policies correctly gets more complicated with larger organisations, so misconfigurations are common which can pose security risks.
Looking at a scenario that may emerge in the real world – let’s say a user has inadvertently been given the IAMFullAccess policy when they only require a policy that allows updating the membership of the marketing teams group.
In theory, the policy should allow the user to view information about the marketing team group, and to add and remove users from that group. The policy should not allow the user to view or edit the permissions. IAMFullAccess provides administrative permissions to perform all actions in IAM. The weakness in this policy is that anyone who has access to the IAM Full Access policy can create new IAM users who are administrators or add the administrative privilege to their own IAM User. Effectively, if a user has been given this policy when they do not need it to perform their intended job function, you are giving them full access to all resources in your AWS account. In certain scenarios where this policy may be legitimately needed, it should only be given to trusted administrators and MFA should be used.
How to improve security within IAM
Below are some steps that can be taken to improve security within IAM:
● Use MFA, particularly for highly privileged accounts as well as on cross-account assume roles
● Enforce a strong password policy
● Use roles and groups and follow the principle of least privilege
● Rotate Access Keys
● Avoid using the root account
● Prefer managed policies over inline policies
What is Amazon RDS?
Amazon Relational Database Service (Amazon RDS) is a distributed relational database service by Amazon Web Services. AWS has a number of database options available including traditional relational database services such as MySQL and PostgreSQL as well as Aurora (a relational database service developed and offered by AWS).
Within the shared responsibility model, services are classified into three different types:
● Infrastructure
● Container (Not to be confused with ECS)
● Abstracted
Effectively the responsibility can shift depending on what service type you are using. It is important to note when dealing with RDS that it falls into the container service type. Customers do not manage the operating system or platform for container services. It is AWS’s responsibility to secure, patch and manage the operating system the RDS instance is running on as well as keep the database software up to date. Within Amazon RDS you are still responsible for managing network access controls, and platform-level IAM to determine who is allowed to manage RDS and encryption.
Your database will be subject to standard injection-type attacks – these fall under the customer’s responsibility within the shared responsibility model, and the correct practices to protect against these attacks should always be followed.
Below are some examples of how to improve the security of Amazon RDS:
● Amazon RDS can be configured to encrypt database instances at rest. This includes the underlying storage of the database instance, automated backups, read replicas, and snapshots.
● Utilise Security Groups to provide control over access to database instances.
● The deletion protection feature can protect database instances from being deleted, either maliciously or inadvertently.
Of course, there is a plethora of AWS services, which will continue to be expanded. All services will have their nuances and security should be at the forefront of any decisions when using AWS.
Traditional security principles such as defence in depth, least privilege, and encryption are of course relevant for AWS environments; however, highly complex cloud environments can pose attack vectors inherently different from traditional approaches.
Find out how LRQA's team of AWS Security certified consultants can help you with Cloud Penetration Testing and Configuration Review services