[Cloud Architect] 10. Securing Access to Cloud Infrastructure

Overview

In this lesson, we will go ahead and discuss network and server access design methods to ensure network level access to your cloud resources.

By network level access, we mean access to IP networks provisioned by cloud customers using infrastructure as a service including VPCs, subnets, and resources deployed within them such as containers, VM instances, load balancers, database instances.

We will also discuss the ability to log into VM instances and other best practices for ensuring that VM instances are accessed in a secure manner.

 

Network level access includes access to:

• VPCs
• Subnets
• Containers and VM instances
• Load Balancers
• Database Instances
• Etc.

Other resources that can be accessed privately from within your cloud private network include S3 buckets, lambda functions, etc.

We will also investigate methods for controlling outbound traffic (egress) from our network to protect against data exfiltration and ensure compliance.

Lastly, we will explore the use of VPC endpoints so that the use of common AWS API's such as S3 does not need to leave your private VPC.

 

 

Key Questions

When designing and deploying cloud networks and infrastructure there are a few key questions to be asking related to security controls:

• Which trusted networks will traffic to your cloud environment originate from?
• Which components in your environment will need network connectivity to other components?
• Are security groups and network ACLs as specific as possible? Example: 10.0.0.0/16 vs 0.0.0.0/0
• Which components will be taking traffic from the internet? Example: those attackers server
• How is access to servers managed?
• Have outbound traffic needs been identified? Exampe: can we use private endpoint, instead of allow access the whole www

 

Common Practices for Accessing Servers in the Cloud

In this section, we will discuss a few common approaches to providing console login access to cloud instances or servers.

While providing console access to cloud instances predicates common actions such as server configuration, application deployment, and operations, providing this access could lead to security breaches in the cloud.

 

1. Usage of Asymmetric Key Pairs

An asymmetric key pair consists of a public key and a private key. The biggest risk is that end users are responsible for maintaining and managing private keys.

Asymmetric Key Pairs: A User has the Private Key and the Instance has the Public Key

 

2. Passwords are Enabled for SSH

This is highly discouraged as it can leave the server open to brute force SSH attacks.

Many Vulnerability Scanners Flag this as a Misconfiguration

 

3. Using a Privileged Access Management (PAM) Tool with Identity Federation

This can improve security by moving the responsibility of managing credentials and user privileges from the user to a trusted process used by the organization.

PAM Tool with Identity Federation

 

4. Use Cloud Providers Native Tools

AWS provides a service called SSM (AWS Systems Manager).

 

This service enables users to manage EC2 instances at the operating system level. The biggest risk is that SSM also has many other functions which may be used by other users.

No Internet Exposure is Required and Passwords/Private Keys Do Not Need to be Managed

 

5. Through an Open Vulnerability

Oftentimes web servers and applications have security vulnerabilities which allow users to exploit those vulnerabilities with the intention of gaining console access to the instance.

Users Can Exploit Vulnerable Instances

 

6. The Best Method to Log Into Cloud Servers and Instances...

… is to not login at all! This is called immutability and we will discuss it further in a future concept.

Just Don't Do It!

 

Additional Resources

• AWS SSM

 

Techniques to Provide Secure Access to Servers

Deploy Immutable Instances

Prevent unauthorized access through deploying servers as immutable components.

Immutable instances are launched from virtual machine images that are created in a private environment. The images have ideally gone through security patching and hardening, custom configuration, application code deployment, and vulnerability scanning.

When it’s time to update the application, a new image is created and deployed and the old instance is then deprovisioned.

During this cycle no individual ever needs to login to the instance.

This is a huge step in the right direction in protecting instances from security breaches and unauthorized access.

Example of an Immutable Instance

 

Configuration Management Tools

Use a configuration management tool to enforce hardening and configuration policies. Even in the event that someone deployed an instance with insecure configuration, the configuration management tool would override this by applying the correct configuration. Some popular tools with this regard are ansible, chef and puppet.

Configuration Management is the Next Best Option

 

Privileged Access Management Tools

The use of a Privileged Access Management (PAM) tool can provide additional benefits such as:

• time based or temporary access to elevated privileges
• granular privilege management
• session recording and audit trails
• password and secrets management
• multi factor authentication

Additional Best Practices To Prevent Unauthorized Access

Finally, in addition to choosing a method for providing access, it’s critical to observe a few additional best practices:

• Keep instances up to date and patched.
• Enforce hardening that encompasses security best practices around OS hardening
• Add monitoring for vulnerabilities to ensure that either OS or application vulnerabilities are addressed as soon as possible.
• Implement monitoring and alerting for suspicious events using tools such as intrusion detection systems or IDS or security information and event management or SIEM tools.

 

Further Research

Background Reading on Privileged Access Management

• CyberArk
• thycotic

AWS Systems Manager Session Manager

• Documentation

 

Controlling Network Traffic

Ingress

Ingress can be required to access services and resources that are running in our cloud environment.

A few examples of ingress traffic are:

• Web application traffic comes from the internet to your web applications.
• Traffic comes from other cloud virtual private networks.
• Traffic comes from on-premise networks such as data centers or corporate offices for management, internal user traffic, or other application integration for hybrid cloud environments.

Egress

We also need to be able to access the internet or other external networks for our applications to be able to function. We will call this egress.

Common egress destinations are:

• Integrations with other cloud based APIs.
• Application API traffic to AWS cloud services.
• Downloading patches, etc.
• Sending monitoring and metric data to external tools.

Controlling Access

Ingress traffic can be controlled and restricted using network ACLs, security groups, which are both effective firewalls, routing rules, and host based endpoint security tools which oftentimes contain firewall capabilities.

In addition to the configuration of ACLs and security groups, private access to VPC networks is also required, either from user work locations or from corporate-owned network spaces.

Egress traffic in AWS is generally handled using internet gateways and nat gateways. As with ingress traffic, egress traffic should also be controlled and restricted for a number of reasons.

 

Restrict Access to Cloud Resources

The use of firewalls will provide the ability to granularly restrict and control network traffic to and from cloud VPCs, subnets, instances, databases and other resources which reside in the private IP space of your VPCs.

Our goal should be to limit and restrict connectivity to specific IP ranges and ports.

This is traditionally done with the use of firewalls. In the cloud, there are a number of ways that we can implement firewall functionality.

1. Host based firewalls

Host based firewalls allow server admins and developers to define at the operating system level specific inbound and outbound sources and ports.

2. Firewall appliances

Commercial Firewall products or appliances can also be deployed in cloud environments.

3. Network ACLs

Network ALCs can be applied at a subnet level and allow you to add multiple firewall rules.

4. Security Groups

Security groups are a second layer and by far the most utilized tool to restrict traffic to and from your cloud hosts and instances

Most cloud native patterns will at minimum tend to use a combination of NACLs and Security groups.

 

General Guidelines for using ACLs and Security Groups

• Know and define your trusted networks for your source and destination traffic.
• Apply ACLs for incoming traffic to all subnets based on trusted networks.
• Apply Security groups to instances based on the role or functionality of that instance or application.
• For both Security groups and NACLs, following the principle of the least privilege only allows traffic from specific hosts or IP ranges to specific ports.
• Determine the default Security group for a VPC.

Further Reading

• AWS NACL Documentation

• AWS Security Group Documentation

 

Egress Control

Using NACLs and security groups to restrict internet bound traffic to specific entities is not the best approach.

AWS provides a few different conduits for connecting to internet sites from our VPC subnets:

• Resources deployed in a subnet can be assigned to public IP addresses and will have internet bound traffic routed through an "internet gateway".
• A NAT instance or NAT gateway can be deployed in public subnets so that instances in other subnets can use this device to gain access to the internet.

From a security perspective, it is not practical to deploy all application resources that require internet connectivity into a public subnet. This widens the attack surface and leaves the environment open to exploitation.

To solve this, a device such as the NAT gateway is the most common solution.

The shortfall with the NAT gateway solution from a security perspective is that it is difficult to monitor and restrict traffic at the application layer to specific domains and sites.

 

A Few Solutions

• Set Up a Web Proxy Layer: This is the simplest way to log application internet traffic. Proxies can also be used to restrict traffic to allowed sites. There are a few drawbacks:

  1. Additional Configuration: applications and instances that require internet access will need to be configured to make use of an http proxy.

  2. The proxy farm itself will need to be configured, managed and maintained.

• In-Line Gateway Appliance: These appliances generally come from commercial vendors and provide a range of capabilities for controlling and inspecting outbound traffic out of the box. Cost is the biggest barrier to this approach.

• Host-Based IDS: A host-based IDS is an agent based solution that runs on each instance. Providing many of the capabilities that the in-line gateway appliance provides including egress control and data loss prevention, intrusion detection and prevention. The biggest disadvantage is enforcing that all hosts in your environment have the agent running.

 

Additional Resources

We highly advise this article be reviewed in detail.

 

Access to Cloud Networks

Previously, we talked about obtaining console login access to cloud servers and instances. Oftentimes, developers and engineers will need to establish network connectivity with these hosts and other hosts running in private subnets, such as RDS database instances, etc.

Here, we will outline a few methods for establishing network access to resources running in your cloud environments.

Methods for Establishing Network Access to Resources Running in your Cloud Environments

Bastion Hosts

Bastion hosts, or jump hosts, are set up in a public subnet to allow a user to login from either their home or office network, and subsequently access or jump to resources in private networks.

• Pros: It is a simple and low cost method for getting onto your cloud VPC.
• Cons: It needs additional effort to harden the bastion host. It is not scalable for many users, and may not work if client applications need to be on the user's laptop or desktop. It is a common target for attackers who hope to gain access to the network by exploiting a vulnerability on the bastion host.

 

Virtual Desktop Solution

Similar to a bastion host, except that each user will get their own virtual bastion.

• Pros: It allows users to install their desktop application clients in the cloud environment without having connectivity to the VPC from their local laptop
• Cons: It costs more than a bastion host. Users will not have direct connectivity to any backend services in the VPC.

 

Client VPN

A client VPN solution allows a user to connect to the cloud VPC using a secure VPN client to establish an encrypted tunnel.

• Pros: Easy to set up. It has the ability to manage many users and roles. It places the user into the VPC so that they may use client applications on their local host to hit the resources deployed in the VPC.
• Cons: It has additional cost as compared to a bastion host. Users may need to install proprietary VPN clients on their local machines.

 

Site-to Site-VPN

We can connect a local trusted network's firewall with the AWS VPN service to establish VPN tunnel connectivity from the entire local network to the AWS VPC network.

• Pros: No need to install any VPN client software on each user's local machine.
• Cons: Additional routing and configuration needs to be performed on the local network. It often leads to delays in setup. No role based routing.

 

Direct Connect Link

A dedicated link from a corporate office network or co-location datacenter.

• Pros: Dedicated bandwidth. It is ideal for hybrid cloud environments.
• Cons: Higher costs and require more time to set up. Once set up, if users are not on the corporate LAN, a solution such as VPN or VDI will still need to be implemented. Generally, it is not an option for small or virtual teams that do not have a LAN to work out of.

 

Additional Resources

• AWS Client VPN

• AWS Workspaces

• OpenVPN on AWS

From:

 

To: