In a previous article, I shared some tips on securing Virtual Private Clouds (VPCs). These are a core feature of Amazon Web Services (AWS) that enable you to define logically isolated virtual networks where you can provision virtualized servers, services and applications in the Amazon public cloud. Securing your VPCs is foundational for making sure your other cloud resources such as servers, applications and data are secure in your AWS cloud environment. So building on that foundation I now want to talk a bit about some ways you can make sure your virtualized servers — what AWS calls “instances” — are properly secured once.
AWS instances are hosted within an AWS web service called Amazon Elastic Compute Cloud (EC2). This web service provides elastic and scalable computing capacity that allows you to save on hardware costs by running servers virtually in the cloud. While EC2 is secure by default in many ways, there are a number of steps you can perform as an AWS administrator to make sure your virtual servers are sufficiently secure to meet the requirements of your business.
The key problem, of course, is that servers in the cloud are useless to your organization unless you can also access them. So while total security is possible by completely isolating EC2 instances from the outside world, this is not useful from a business point of view. Customers and employees must be able to access EC2 instances if you want them to buy your product or perform their work. And administrators must also be able to access these instances to configure, maintain, monitor and troubleshoot them. So a key part of securing EC2 instances is to make sure communications between them and the outside world are secure.
That’s not all that’s important, however. Even if the communications channels between your instances and outside users and applications are secure in terms of the “CIA triad” requirements of data confidentiality, integrity and availability, there’s still the matter of what the contents are of the data being uploaded to your instances. For example, if the payload should happen to be malware and your instances is not running any malware protection software, the guest operating system of the instance may be compromised and with it your sensitive business data.
Of course, this is also a concern for the underlying physical hosts of the EC2 cloud: If the host running your EC2 instance should be compromised in some fashion, your instances is potentially compromised as well. Fortunately, (or unfortunately, if you prefer) handling physical host security is something that only Amazon’s own administrators are concerned with. As an AWS customer, you only have to worry about safeguarding your virtualized servers, not the underlying physical servers hosting them.
Having set the stage then with this discussion, here are three essential tips that can help you make sure that your EC2 instances are properly secured.
Understand security groups
As I mentioned in my previous article, AWS provides you with two kinds of virtual firewalls you can use to control the inward and outward flow of network traffic in your environment. These two firewalls are network access control lists (NACLs) and security groups. And while NACLs are key to securing communications with VPCs because they control access to subnets in your cloud environment, security groups are key to securing communications with EC2 instances. So to secure your EC2 instances you need to start by ensuring that you have a proper understanding of how security groups work. Amazon has a good description of how security groups can be used to secure inbound traffic for Linux instances, and by working through the scenario they present you can gain a good understanding of how to use security groups for protecting other kinds of instances. But the basic principles are simple: assign one or more security groups to your instance, then add rules to each security group to allow specific types of traffic for your instance. As you do this, keep in mind the cardinal rules for controlling access, namely: least privilege and least access.
Use IAM roles
When you first set up your AWS environment you’re provided with security credentials that have pretty much unlimited access to your AWS resources including EC2. Don’t use these default AWS credentials for granting users, applications, or services access to your instances! Instead use AWS Identity and Access Management (IAM) to control the degree to which users, applications and services can access your instances and the other resources like storage that they utilize. IAM is a powerful, easy to use AWS feature that lets you create users and groups and assign them unique security credentials. IAM can also be used to create policies in JSON format for performing various tasks on instances using the EC2 APIs.
Even more important from a perspective of managing instance security, IAM also lets you create roles. IAM roles provide a way for managing AWS credentials for applications running on EC2 instances. This is important because applications making API calls must have these requests signed with valid AWS credentials. What typically happens is you create an IAM role and assign it to your EC2 instance. The IAM role has been configured to provide secure access to some other AWS resource such as an S3 bucket, and the necessary permissions required by the role are defined by an IAM policy you created. The instance is then launched in EC2 and the IAM role generates temporary credentials the instance can use to access the bucket. The advantage of using IAM roles in this fashion is that long-term credentials stored in the instance are not used for accessing the bucket; temporary credentials are used instead, which is more secure because the long-term credentials are not exposed.
Safeguarding your EC2 instances against malware infection is as I mentioned earlier an essential part of the task of securing your instances. Here you can simply put into effect many of the same practices you use to harden the physical servers in your server room or datacenter against malware. This means for example that you should:
- Ensure any applications or other executable code you deploy on your instance comes from a trusted source.
- Ensure that the Amazon Machine Image (AMI) you launch your instance from (if you’re using AMIs) also comes from a trusted source.
- Ensure the guest operating system on your instance is properly secured according to standard hardening procedures for that particular operating system.
- Ensure the guest OS and installed applications on your instance are fully patched and that newly released patches are applied in a timely manner.
- Ensure the guest OS has trusted antivirus software installed and running on it, and that the signatures of this software are updated regularly.
And don’t forget to back up your EC2 instances
Finally, make sure you regularly back up your EC2 instances so you can recover them quickly in the event of a breach. Remember, in the real world there is no such thing as perfect security. So despite all your efforts to secure your instances, bad things probably will happen to them from time to time.