AWS Cloud Security: Securing Compute Services (EC2)
Amazon EC2, the Amazon VM service
Introduction
The AWS EC2 (Amazon Elastic Compute Cloud) offers scalable computing capacity in the AWS Cloud. This effectively saves you from having hardware capital expenses and effectively offers computing as an operational cost for customers to increase and reduce computing on-demand. This allows AWS users to develop and deploy applications faster. Now the most important thing every AWS user should be asking after creating an EC2 Instance is how can I secure the EC2 instance?
Considering the shared responsibility model, customers are responsible for the deployment and maintenance of virtual servers when using IaaS.
General Best Practices You Should Keep in Mind:
- Use only trusted AMI when deploying EC2 instances.
Figure 1
An Amazon Machine Image (AMI) is a template that contains a software configuration, metadata, and permissions (for example, an operating system, an application server, and applications).
This compute engine resource can easily be designed and configured with vulnerabilities and malware that may not be detected by the self-service AMI scanning tool or AWS Security. Consequently, leaving your EC2 instances exposed to threat actors.
Figure 1 shows how multiple instances can be created using one AMI. If the AMI has vulnerabilities undetected, then all EC2 instances created with it will be exposed.
- Use a minimal number of packages inside an AMI, to lower the attack surface.
Keeping the number of packages inside an AMI helps lower the attack surface of the OS and minimizes the need to install patches for a security update.
- Use Amazon built-in agents for EC2 instances (patch management, hardening, backup, monitoring, and others).
- Use the new generation of EC2 instances, based on the AWS Nitro System, which offloads virtualization functions (such as network, storage, and security) to dedicated software and hardware chips.
The AWS user receives much better performance, security, and isolation of data when using the new generation of EC2 instances.
- Lastly, the AWS user is welcome to carry out penetration testing against the AWS computing environment at regular intervals.
In most cases, the user is an organization who could consider employing a third party to conduct tests on its behalf or have its cloud security team perform these tests. More information on this can be found at AWS Penetration Testing.
Best practices for authenticating to an instance
A customer’s Virtual Machines are not accessible by AWS.
Whether you opt to deploy a Windows or Linux machine through the EC2 launch deployment wizard, it is necessary to choose either an existing key pair or create a new key and I really cannot stress this enough. Proceeding without creating a key pair would allow anyone access to your EC2 Instance.
This set of keys is generated at the client browser and AWS does not have any access to the keys. This means they cannot access your EC2 instance. Furthermore, this also means if you lose your key, AWS cannot help you recover it.
For Linux instances, the key pair is used for logging in to the machine via the SSH protocol, and for Windows instances, the key pair is used for logging in to the machine via the RDP protocol.
The best practices are as follows:
- The user must store private keys in a secured location. Additionally, an alternative for the storing and retrieval of SSH keys is to use AWS Secrets Manager.
- Avoid storing private keys on a bastion host or any instance directly exposed to the internet. A good alternative to logging in using SSH, without an SSH key, is to allow and control permissions for SSH connections through Session Manager.
- Join Windows or Linux instances to an Active Directory (AD) domain and use your AD credentials to log in to the EC2 instances (and avoid using local credentials or SSH keys completely).
- Lastly, using Amazon EC2 Instance Connect offers a secure and seamless connection to your Linux instances using SSH (Secure Shell). This leverages the AWS Identity and Access Management (IAM) policies and principals to regulate SSH access to your instances and removes the need to store, share and manage SSH keys.
Best practices for securing network access to an instance
Network access to EC2 instances is controlled via security groups which are the equivalent of a firewall in AWS Cloud or a network access control list (NACL) at the subnet level which is the equivalent of access control mechanisms.
The customer decides how the network is configured by defining parameters such as the source IP, destination IP, destination port, and whether the port is TCP or UDP.
Figure 2.1
Figure 2.1 shows how the security group works.
Figure 2.2
As illustrated in figure 2.2, it is also possible to use another security group as either the source or destination in a security group.
For remote access and management of Linux machines, limit inbound network access to TCP port 22. Lastly, for remote access and management of Windows machines, limit inbound network access to TCP port 3389.
Best practices for securing backups
Backing up is crucial for EC2 instance recovery.
The AWS Backup service encrypts your backups in transit and at rest using AWS encryption keys, stored in AWS Key Management Service (KMS) applying Encryption in Cloud Services, as an extra layer of security, independent of your Elastic Block Store (EBS) volume or snapshot encryption keys.
The best practices are as follows:
- Configure the AWS Backup service with an IAM role to allow access to the encryption keys stored inside AWS KMS.
- Configure the AWS Backup service with an IAM role to allow access to your backup vault.
- Use tags for backups to identify which backup belongs to which EC2 instance.
- Consider replicating your backups to another region.
Conclusion
These are a few ways to keep your EC2 instance secure in the AWS Cloud. There are numerous ways to secure virtual machines, but the aforementioned practices should get you started with the cloud security of virtual machines in AWS.
