Network and Storage are two foundational elements that can be found in both a traditional on-premises data center and a public cloud. Therefore, it’s important to understand both of these concepts as you move forward with implementing a security strategy for the public cloud.
In part one of this series, we presented an overview of public cloud security, an introduction to AWS services, and some key aspects to consider before migrating to AWS. Now in part two, we will give an introduction to network and storage concepts in the public cloud, such as VPCs and Object Storage, while also covering some important security concerns and strategies.
Security Considerations in VPCs
In a world where you don’t have your own dedicated networking gear (and data centers), the VPC (Virtual Private Cloud) concept allows you to have a private and isolated networking space in the cloud using SDNs (Software Defined Networks). A single VPC is usually bound to a specific region (in AWS) and can contain multiple networks, or subnets. Traditional perimeter-based security, i.e., via a firewall, also changes a bit, although the same fundamental concept applies.
Subnets
On a subnet level you have the ability to apply a Network ACL (Access Control List) to filter both incoming and outgoing traffic. This can be combined with Security Groups that are applied on an instance and also filter traffic at that level. As a rule of thumb, Network ACLs are more permissive than Security Groups because, even if you have a permissive network traffic rule on an instance Security Group, that traffic can be blocked by a Network ACL.
Private vs. Public Subnets
In a VPC, there are multiple ways to enable Internet access. The subnets you create can be fully public (i.e., with a public address space), but you need to add an additional resource to your VPC–called Internet Gateway–to enable Internet routing for the resources in that VPC/public subnet. However, security is an issue here, so it is preferable to use private subnets as much as possible within your VPC.
Enabling Internet Connectivity
When using private subnets, there are two ways to achieve Internet connectivity: via a NAT (Network Address Translation) Gateway or Self-Hosted NAT instances. Enabling a NAT Gateway in your VPC is quite straightforward, covers most use cases, and doesn’t bring any additional operational burden. But, as it is a managed service over which you don’t have full control, you might need to use a self-hosted NAT instance for some advanced corner cases. Examples of this include when you are using an IDS (Intrusion Detection System) with deep packet inspection, or if you need to restrict outbound connectivity behind the limits imposed by NACLs and proxies. Of course, such cases bring additional operational burden (and potential single point of failure) since you are responsible for keeping the instance up and running. However, this can be partially mitigated with auto-scaling groups.
VPC Connectivity
When moving from on-premises to the public cloud, or if you have a hybrid-cloud or multi-cloud strategy, a company needs to connect to and from its VPCs. This can usually be achieved via VPC Peering within the same cloud provider (e.g., AWS). But if you require VPC connectivity to a different cloud provider or your own on-premises data center, you should use either VPN Gateway or Direct Connect (see Figure 1). The VPN Gateway option is usually the most cost effective; it allows you to easily create one or more VPN tunnels (via a managed service) between your VPC and a different environment. The AWS Direct Connect option also allows you to achieve connectivity between your environment and your VPC but it works in a very different way. Direct Connect works by establishing a dedicated and physical connection between the two sites (AWS and your data center), enabling a higher speed and bandwidth throughput, although at a higher price tag.
The majority of AWS services are Internet-facing by default, so you might be wondering how your application running inside a VPC can leverage AWS services privately and securely. It used to be that the only way to use them was by enabling Internet connectivity in the VPC. But today, VPC Endpoints are present in several AWS services. This effectively provides a private AWS endpoint to a given service (e.g., S3) that is only reachable by your VPC.
Storage
Storage is one of the most important elements of any system architecture and is especially relevant to security. Storage enables the system to have data persistence and is thus a target for any attacker looking to steal information.
While there are not many differences between storage in traditional on-premises data centers and the public cloud, there is one type of storage that typically only exists in the public cloud: Object Storage.
Object Storage
In a nutshell, Object Storage enables applications to upload and download files (also called objects) via a REST API. It completely abstracts the underlying implementation details, requires minimal operational effort, and features out-of-the-box high availability and infinite growth capacity. Security-wise, due to its nature (access via public APIs, etc.), misconfiguration of the object storage service is one of the main causes for data leaks and other security incidents for companies using the public cloud. It is thus crucial to have an in-depth understanding of how Object Storage works and to make it a key element in your security strategy.
In AWS, Object Storage is provided by a service called Simple Storage Service, or S3. Here, a collection of objects is organized in buckets. A single bucket can contain multiple objects, yet an object only belongs to a single bucket.
Permissions
Properly securing these buckets and their objects is crucial, as incorrectly doing so has been the root cause for the majority of cloud data breaches in recent years. An S3 bucket can be either defined as private (default) or public. As the name suggests, data in a public bucket is completely exposed to the Internet. This is because objects inside the bucket inherit the permissions defined for the bucket; however, distinct permissions per object can be set if needed. In practice, this can mean that an object is defined as public while the bucket itself is set as private, but this is highly uncommon. Permissions in a private bucket are often adjusted to allow only specific resources to access the objects inside of it. This enables customers to be very specific in defining only the resources (e.g., an EC2 instance) that truly need privileges to a given S3 bucket or object.
Permissions are configured using S3 Bucket Policies, IAM Policies, or a combination of both. This is where customers need to be extra cautious since a misconfiguration in the policy could make the data publicly available. In part three of this series, we will introduce Identity and Access Management (IAM) and explore the different types of permission policies.
A good strategy for preventing mistakes and mitigating potential security incidents is to automate this process as much as possible. One best practice is to use Infrastructure as Code (IaC) for S3 bucket management, including policies. Also, it is recommended to regularly scan and test buckets for unwanted data exposed to the public via tools such as AWS Lambda or Config rules.
Conclusion and Next Step
In part one of this series, we started by introducing the public cloud and providing some real-world examples in AWS. Now in part two, we’ve discussed an introduction to the concepts of network and storage in the public cloud and their security considerations. While these elements share many similarities with the ones that can be found in traditional on-premises data centers, it is important to be aware of the security impact that misconfigurations can have.
In the next and last part of this series, we will continue to dig deeper and talk about two important topics in public cloud security: Identity and Access Management and existing services that can be leveraged in AWS to enhance your security practices.
This guest article is by Bruno Amaro Almeida.
