Infrastructure Security in AWS: Crafting Secure Networks for the Cloud
Cloud infrastructure is a massive concept. It helps to frame the infrastructure in terms of how your organization plans to leverage the different services. Infrastructure as a Service (IaaS) is the most similar to an on premises local datacenter. As such many of the security concepts are portable to the IaaS deployment model. However, as companies leverage Platform as a Service (PaaS) and Software as a Service (SaaS), the infrastructure protection concepts are reduced to configuration settings and typically center around data protection. As I read through the infrastructure protection section of the AWS well architected framework’s security pillar, I noticed familiar concepts from traditional security. For example, isolating network segments, and defense-in-depth still play an important role in cloud security planning. This blog entry will focus on the network protection aspects of the AWS well architected framework security pillar. Read below to find insights and commentary on the documentation.
To best understand how to protect your network assets, you have to analyze who and what nodes in the network can communicate with one another. Many of these services have default settings that either expose or shut off the service to other network nodes. Very rarely is it the case where the default settings support both your security and communication needs.
One of the anti-patterns noted in the documentation was the failure to use subnets. Some services, like EC2, default to deploying an asset in the default Virtual Private Cloud (VPC). Ease of implementation will almost always be prioritized over security practices. The cloud provider wants you to have as little friction as possible when using their services. Plus, the shared responsibility model stipulates that service configuration is left up to the customer. A VPC can and should be subnetted. Placing all your assets in a 10.0.0.0/16 network makes it easier for an adversary with unauthorized access to enumerate the network and move laterally.
It may seem daunting to figure out the size and security scope of the subnet. A best practice is to group similar assets with a documented purpose to communicate in the same subnet. One of the reasons for this approach is to limit the amount of damage an attacker could do if they gained control of one particular asset. When services need to communicate across subnets, AWS offers variety of security controls such as VPC security groups and network ACLs to help determine if the communication should be allowed or denied. Also, while route tables are not specifically security focused, they are configured in such a way that can permit or deny traffic based on both functional and security needs. This underscores why it’s imperative to plan out and group resources together based on their need to communicate. That way, when you set up the route table, the configuration should limit overprovisioning network access.
There’s certainly a lot to discussing cloud infrastructure security. While this post centered around network considerations, it only dealt with one aspect; using subnets in your VPC. Whether you’re a cloud administrator, architect, or security engineer, having a project on the roadmap that matures your organization’s VPC subnet distinction will enhance your security posture, and may even help isolate troubleshooting issues in the future.
As always, I appreciate you making it to the end. If you disagree, let me know. I’m always open to learning and getting feedback. What are some other ways you recommend securing the network traffic in your cloud environments?
