Managing cloud environments on large scale has many challenges.
One of the challenges many organizations are facing is managing network inbound/outbound network connectivity to their cloud environments.
Due to the nature of the public cloud, all resources are potentially public, unless we configured them otherwise.
What are the challenges in the network security domain?
There are many challenges related to network security, here are the most common ones:
- Unauthorized inbound network access – Publicly facing resources (such as virtual machines, object storage, databases, etc.) allowing anyone on the Internet access to the resources
- Unrestricted outbound network access – Internal resources (such as virtual machines, databases, serverless, etc.) can initiate outbound traffic to resources on the public Internet
- Managing network access rules at large scale – Ability to control thousands of firewall rules created over time, while managing multiple accounts for a specific cloud provider (or even multiple different cloud providers)
- Understanding the network attack surface – Ability to get a clear view of what inbound or outbound traffic is allowed or denied in a large cloud environment with multiple accounts
- Enabling the business, while keeping the infrastructure secure – Ability to respond to multiple business requests, using small network/information security / IT team
With all the above challenges, how do we keep our cloud network infrastructure secure and at a large scale?
Set Guardrails
One of the common ways to configure guardrails is to use organizational policies using Policy-as-Code.
All major cloud providers support this capability.
It allows us to configure rules for the maximum allowed permissions over our cloud environments according to our company security policy while allowing developers / DevOps to continue provisioning resources.
AWS Service control policies (SCPs)
Below are sample service control policies that can be configured at the AWS organizational level (with inheritance to the underlining OU's), for restricting inbound access:
- Detect whether any Amazon EC2 instance has an associated public IPv4 address
- Detect whether Amazon S3 settings to block public access are set as true for the account
- Detects whether an Amazon EKS endpoint is blocked from public access
- Detect whether the AWS Lambda function policy attached to the Lambda resource blocks public access
- Detect whether any Amazon VPC subnets are assigned a public IP address
Azure Policy
Below are sample Azure policies that can be configured at the Azure subscription level, for restricting inbound access:
- Container Apps should disable external network access
- Network interfaces should not have public IPs
- All network ports should be restricted on network security groups associated to your virtual machine
- Function apps should disable public network access
- Azure SQL Managed Instances should disable public network access
- Public network access on Azure SQL Database should be disabled
- Public network access should be disabled for MySQL servers
- Public network access should be disabled for PostgreSQL servers
- Storage accounts should disable public network access
Google Organization Policies
Below are sample Google organization policies that can be configured at the GCP Project level, for restricting inbound access:
- Restrict public IP access on Cloud SQL instances
- Enforce Public Access Prevention
- Disable VM serial port access
- Define allowed external IPs for VM instances
Controlling inbound/outbound network traffic at scale
At large scale, we cannot rely on the built-in layer 4 access control mechanisms (such as AWS Security groups, Azure Network Security Groups, or GCP Firewall Rules) to define inbound or outbound traffic from/to our cloud environments.
For large scale, we should consider alternatives that will allow us to configure network restrictions, while allowing us central visibility over our entire cloud environment.
Another aspect we should keep in mind is that the default layer 4 access control mechanisms do provide us advanced protection against today's threats, such as the ability to perform TLS inspection, control web traffic using URL filtering, etc.
Cloud-native firewall services:
Note: If you prefer to use 3rd party NGFW, you can deploy it using AWS Gateway Load Balancer or Azure Gateway Load Balancer.
Additional references
Understanding the network attack surface
One of the common issues with large cloud environments is to have a visibility of which inbound or outbound ports are opened to the Internet, exposing the cloud environment.
Common services to allow network visibility:
Another alternative for getting insights into attack surface or network misconfiguration is to deploy 3rd party Cloud Security Posture Management (CSPM) solution, which will allow you central visibility into publicly accessible virtual machines, databases, object storage, and more, over multiple cloud providers' environments.
Summary
In this blog post, I have presented common challenges in managing network security aspects in cloud environments.
Using a combination of organizational policies, strict inbound/outbound traffic control, and good visibility over large or complex cloud environments, it is possible to enable the business to move forward, while mitigating security risks.
As the cloud threat landscape evolves, so do security teams need to research for suitable solutions to enable the business, while keeping the cloud environments secure.
About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.
Eyal is an AWS Community Builder since 2020.
You can connect with him on Twitter and LinkedIn.
Top comments (0)