Ever feel lost in a sea of acronyms and cloud security terminology on AWS? You’re not alone! Let’s take a look at ten of the most common terms that you’ll hear when you’re learning about Amazon Web Services cloud security, and get an overview of what they mean for your own unique cloud security environment.
IAM stands for Identity and Access Management, and it’s the way that AWS allows you to control access to all of your resources on AWS. You’ll use the terms authenticated and authorized. Authenticated means that the user is signed in, and authorized means that they have the permissions that they need to use any given resources.
IAM is used to manage access in AWS. You do this by creating IAM identities, such as users, groups, or roles, and then attaching policies to these identities. This will define the permissions for each identity.
The root user will be the initial person that created the AWS account, and this is one single sign-in identity who will have access to all of the AWS services and resources that are in the account. AWS recommends that you only use this root user to create your first IAM user, as these access permissions are far too loose.
It’s important to note that defining policies using IAM logic doesn’t always mean that your environment is secure. In fact, even by design, some configurations can open you up to risk. Read more about AWS IAM and AWS Authorization logic.
AWS Lambda allows you to run code without any of the overhead and work of managing and provisioning servers. Think about time-consuming tasks such as integrating events, managing runtimes, or building scaling logic. This is all eliminated with a serverless compute service like AWS Lambda. You can write your code in any language, and then simply upload your code as a container image or a ZIP file, and Lambda will allocate the amount of power, and run the incoming request or event, at any scale.
Terms that you might hear when you’re reading about AWS Lambda include Functions; which are the scripts or program that run in Lambda, processing the event and returning the response, Runtimes; which allow you to run functions which have been written in various languages on the same environment, Lambda Layers; that helps you to manage your development function code and distribute your functions, and Log Streams; that allow you to add custom logging statements to analyze the flow and performance.
To learn more about the anatomy of AWS Lambda and using a Serverless framework, check out our article on AWS tools.
AWS Elastic Computing (EC2)
Amazon EC2 stands for Elastic Compute Cloud, and offers secure, scalable virtual servers that can be used to run AWS applications. You can configure your instances exactly how you like, including with memory, storage, CPU and networking requirements.
In order to secure EC2 instances, AWS suggests you use identity federation, IAM users and roles, implement rules according to least privilege, and ensure that your OS and applications are patched and up to date. However, this doesn’t cover all the risks on the cloud. One good example is managing SSH key pairs, which are often used for multiple instances, opening an organization up to risk.
At Lightspin, we offer a free, open-source Red Detector that can be used to scan your EC2 instances to find vulnerabilities using Vuls, as well as for signs of a rootkit using Chkrootkit. You can also use this tool to audit your EC2 instance using Lynis to find misconfigurations.
Amazon S3 buckets are storage, used to hold objects. Objects are data, files, metadata and so on. After creating a bucket, you will need to select a tier for your data, which will vary in terms of redundancy, price, and how often you can access the objects inside. You can have a single bucket that stores objects across multiple tiers.
AWS IAM service helps you to assign the right privileges and permissions for all the objects in any given S3 bucket, including creating access control lists. However, these can quickly become complex to manage. In addition, the access options from AWS don’t always allow you to ascertain whether your objects are public.
AWS Key Pair
A key pair is a set of security credentials that users need to access their instances, and is made up of a public and a private key. The public key is stored by AWS, and you create and hold the private key which is unique to you. In that way, it works like a password to access your buckets and objects. As your cloud environment grows, it becomes harder to manage key pairs, and like with password misuse, many companies and users share key pairs across different instances. However, when organizations use the same key pairs for multiple instances, attackers can access all of these servers by uncovering just the one credential.
Lightspin maps and visualize all EC2 instances, highlighting those that are using the same key pair, and prioritizing these by real-world attack paths, so that you can easily mitigate the key pair misuse that is opening your business up to risk.
AWS Least Privilege
The principle of least privilege (PoLP) is a concept that means all users have the permissions and access that they need to do their job, and no further. This means that if an attacker compromises an account, they are limited in terms of what they can access. This term was built for on-premises environments, and does not carry over entirely to cloud security.
There are a few reasons for this disconnect. First, on the cloud an attacker only needs one or two permissions to gain complete control over an account. Second, AWS least privilege isn’t always possible because of pre-set rules that can’t be amended by the user. Lastly, attempting to create the number of policies needed for least privilege creates a huge amount of work for DevOps teams.
Infrastructure-as-code makes it easier for DevOps to model, provision and manage a collection of resources. This is what AWS CloudFormation does, using templates. You can create resources with dependencies, and then configure these as one single stack, instead of needing to handle the individual parts. On AWS, these stacks can be used across multiple user accounts, and even across regions, too.
AWS CloudFormation saves time for DevOps, by allowing them to automate best practices and then roll them out quickly and easily across projects.
AWS Security Hub
AWS Security Hub brings all of your alerts together from all your AWS accounts into a centralized location. It is where you manage alerts that come in from your security tools, such as endpoint protection or firewalls, or compliance scanners for example, both for integrated AWS services, and also for solutions that come from within the AWS Partner Network. Integrated with SIEM or SOAR tools, or with AWS tools such as Amazon Detective, you can also take steps towards remediation.
The challenge is that organizations today have so many security tools, both that fall under these categories and those which do not, that alerts have escalated past what can be managed within AWS Security Hub alone. Security teams have hundreds of alerts per day, and many of them are impossible to prioritize without context. This leads to alert fatigue, and security teams who simply ignore many of these alerts, leaving their companies exposed to risk.
EKS is how Amazon runs the Kubernetes control plane across AWS availability zones to provide highly available Kubernetes clusters on AWS. You can start, run and scale your K8 applications either on-premises or on the cloud, and get all the benefits of the container orchestration system, in terms of deployment, management and scale.
There are many security considerations for companies running Kubernetes on AWS. For example, some of the AWS defaults can be overly-permissive or open you up to risk, and attackers can also exploit the K8 control plane to attempt account takeover. If you’re looking for advice on setting up your Kubernetes environment, or on using Amazon EKS securely, start with our webishop.
AWS Cross-account Access
Using the AWS console, you can set up cross-account access so that users can obtain access to objects from buckets belonging to other users. This is usually done using cross-account IAM roles with a trust policy, and setting up an AWS credentials file.