If an application is running on an EC2 instance, it must pass credentials along with its API request. These credentials can be stored in the EC2 instance and managed by developers. Developers have to ensure that these credentials are securely passed to every EC2 instance and are rotated for every instance as well. This is a lot of overhead, which leaves room for errors and security breaches at multiple points.

Alternatively, you can use IAM roles for this purpose. IAM roles provide temporary credentials for accessing AWS resources. IAM roles do not store credentials on instances, and credentials are managed by AWS, so they are automatically rotated multiple times in a day. When an EC2 instance is launched, it is assigned an IAM role. This role will have required permissions to access the desired AWS resource. You can also attach an IAM role to an instance while it is running.

In the following figure, an IAM role to access an S3 bucket is created for an EC2 instance. The developer launches an instance with this role. The application running on this instance uses temporary credentials to access content in the S3 bucket.

In this scenario, the developer is not using long-term credentials that are stored in EC2 instances, thus making this transaction more secure.

Figure 2: IAM role for EC2 instance

Accessing the operating system of an EC2 instance requires different credentials than applications running on an EC2 instance. AWS lets you use your own credentials for the operating system; however, AWS helps you to bootstrap for initial access to the operating system. You can access the operating system of your instance using secure remote system access protocols such as Windows Remote Desktop Protocol (RDP) or Secure Shell (SSH).

You can set up the following methods for authenticating operating system access:

AWS provides key pairs for enabling authentication to the EC2 instance. These keys can be generated by AWS or by you; AWS stores the public key, and you store the private key. You can have multiple key pairs for authenticating access to multiple instances. For enhanced security, you can also use LDAP or active directory authentication as alternative methods for authentication, instead of the AWS key pair authentication mechanism.

An instance in the AWS cloud should be protected from malware (that is, viruses, trojans, spams, and so on), just like any server would be protected in your data center. Having an instance infected with a malware can have far-reaching implications on your entire infrastructure on the cloud.

When a user runs code on an EC2 instance, this executable code assumes the privileges of this user and it can carry out any action that can be carried out by this user based on the user privileges. So, as a rule of thumb, always run code that is trusted and verified with proper code review procedures on your EC2 instances.

If you are using an AMI to launch an EC2 instance, you must ensure this AMI is safe and trusted. Similarly, always install and run trusted software; download this software from trusted and established entities. You could create software depots for all your trusted software and prevent users from downloading software from random sources on the internet.

Ensure all your public facing instances and applications are patched with the latest security configurations and that these patches are revisited regularly and frequently. An infected instance can be used to send spam, a large number of unsolicited emails. This scenario can be prevented by avoiding SMTP open relay (insecure relay or third-party relay), which is usually used to spread spam.

Always keep your antivirus software, along with your anti-spam software updated from reputed and trusted sources on your EC2 instance.

In the event of your instance getting infected, use your antivirus software to remove the virus. Back up all your data and reinstall all the software, including applications, platforms, and so on, from a trusted source, and restore data from your backup. This approach is recommended and widely used in the event of an infected EC2 instance.

AWS lets you create your own virtual private network in the AWS cloud, as you learned in Lesson 1, AWS Virtual Private Cloud. VPC enables you to secure your infrastructure on the cloud using multiple options, such as security groups, network access control lists, route tables, and so on. Along with securing infrastructure, VPC also allows you to establish a secure connection with your data center outside of the AWS cloud or with your infrastructure in other AWS accounts. These connections could be through AWS direct connect or through the internet.

Security groups should be used to control traffic allowed for an instance or group of instances performing similar functions, such as web servers or database servers. A security group is a virtual, instance-level firewall. It is assigned to an instance when an instance is launched. You could assign more than one security group to an instance. Rules of security groups can be changed anytime, and they are applied immediately to all instances attached to that security group.

AWS recommends that you use security groups as the first line of defense for an EC2 instance. Security groups are stateful, so responses for an allowed inbound rule will always be allowed irrespective of the outbound rule, and if an instance sends a request, the response for that request will be allowed irrespective of inbound rule configuration.

The following figure shows a security group SL-Web-SG configured for all web servers inside a VPC. There are three rules configured; HTTP and HTTPS traffic are allowed from the internet, and SSH for accessing this instance is allowed only from a public IP, that is, 118.185.136.34.

Figure 3: AWS security groups

Each AWS account has a default security group for the default VPC in every region. If you do not specify a security group for your instance, this default security group automatically gets associated with your EC2 instance. This default security group allows all inbound traffic from instances where the source is this default security group. Alongside, it allows all outbound traffic from your EC2 instance. You can modify rules for this default security group, but you cannot delete it.

Security groups are versatile in nature; they allow multiple options for sources for inbound access and destinations for outbound access. Apart from the IP address or range of IP addresses, you can also enter another security group as an object reference for source or destination in order to allow traffic for instances in your security group. However, this process will not add any rules to the current security group from the source security group.

The following figure depicts this example, where we have a security group for database servers; this security group allows traffic only from a web servers security group. In this configuration, the web servers security group is an object reference for the source field, so all the instances that are associated with the database security group will always allow traffic from all instances associated with the web servers security group.

Figure 4: AWS security groups object reference

An Intrusion Detection System (IDS) is a detective and monitoring control that continuously scans your network, servers, platform, and systems for any security breach or violation of security policy, such as a configuration change or malicious activity. If it detects an anomaly, it will report it to the security team.

An Intrusion Prevention System (IPS), on the other hand, is a preventive control. These controls are placed inside your network, behind organizations' firewalls, and act as a firewall for all known issues and threats related to incoming traffic. All traffic needs to pass IPS in order to reach their destination. If an IPS finds traffic to contain malicious content, it will block that traffic.

The AWS marketplace offers various IDS and IPS products to secure your network and systems. These products help you detect vulnerabilities in your EC2 instances by deploying host-based IDS and by employing behavioral monitoring techniques.

These products also help you secure your AWS EC2 instances from attacks by deploying next-generation firewalls in your network, which have features such as full stack visibility for all layers in your infrastructure.

An Elastic Load Balancer (ELB) is a managed AWS service that automatically distributes incoming traffic to targets behind a load balancer across all availability zones in a region. These targets could be EC2 instances, containers, and IP addresses.

An ELB takes care of all encryption and decryption centrally, so there is no additional workload on EC2 instances. An ELB can be associated with AWS VPC and has its own security groups. These security groups can be configured in a similar way to EC2 security groups with inbound and outbound rules.

Alongside, ELB also supports end-to-end traffic encryption through the Transport Layer Security (TLS) protocol for networks using HTTPS connections. In this scenario, you don't need to use an individual instance for terminating client connections while using TLS; instead, you can use ELB to perform the same function. You can create an HTTPS listener for your ELB that will encrypt traffic between your load balancer and clients initiating HTTPS sessions. It will also encrypt traffic between EC2 instances and load balancers serving traffic to these EC2 instances.

Quite often, organizations will have multiple features for securing their infrastructure, network, data, and so on. The AWS cloud gives you various such features in the form of VPC, security groups as virtual firewall for your EC2 instances, NACL as secondary firewalls for your subnets, and host-based firewalls and IDS, along with Intrusion Prevention System (IPS), for creating your own threat protection layer as part of your security framework.

This threat protection layer will prevent any unwanted traffic from reaching its desired destination, such as an application server or a database server. For example, in the following figure, a corporate user is accessing an application from the corporate data center. This user is connecting to AWS VPC using a secure connection, which could be a VPN connection or a direct connect connection and does not require interception by a threat protection layer.

However, requests made by all users accessing this application through the internet are required to go through a threat protection layer before they reach the presentation layer.

This approach is known as layered network defense on the cloud. This approach is suitable for organizations that need more than what AWS offers out of the box for protecting networking infrastructure. AWS VPC provides you with various features to support the building of your threat protection layer; these features include the following:

It is imperative for any Infrastructure Security Management System (ISMS) to continuously test their security measures and validate them against ever-evolving threats and vulnerabilities. Testing these security measures and controls involves testing the infrastructure and network provided by AWS. AWS recommends that you take the following approaches to test the security of your environment:

As of now, the AWS penetration testing policy allows testing of the following AWS services: