Welcome to 'Back to Basics'.
I am Gerardo Estaba,
and today we're going to talk about the basics of protecting your network
in the cloud.
Great network security looks a lot like an onion,
a beautifully designed vegetable that protects itself
through multiple layers
that if you try to break into, you'll end up crying.
We want to apply this same layered approach to network security,
so that all of these layers block the traffic
that's not intended to the application.
So let's get started on some patterns for protecting your network in the cloud.
Let's start with a simple architecture example,
a single Amazon EC2 Instance.
The best way to protect the network access to the instance
is by configuring its security group.
A security group acts as a virtual firewall for your instance network interface.
With security groups, you can configure inbound rules
and outbound rules.
These rules specify sources, protocols,
and ports that you want to allow traffic from.
An important thing to consider is that security groups are stateful.
If an inbound request is allowed by the inbound rules,
then the response outbound traffic for that connection is automatically allowed.
So what sort of sources, protocols, and ports
should you allow in your security group?
Of course, the minimum necessary for the intended operation of the instance.
You can use security groups to allow any network protocol,
but if all you want is to allow web traffic from the internet,
we can improve our security and availability
by adding an Elastic Load Balancer in front of it.
Elastic Load Balancers add many benefits,
such as the ability to distribute traffic across multiple instances,
such as handling failover among them,
but also adding security benefits like,
for example, implementing a web application firewall.
By implementing a load balancer,
you're effectively adding one layer to our onion,
abstracting your instances from the outside world,
removing direct access from the internet to your instance,
and you can configure a security group for the load balancer as well.
So far these resources exist
in our Amazon Virtual Private Cloud or VPC.
A VPC gives you your own dedicated and isolated virtual private network
with complete control over your IP address ranges,
gateways, subnets, and other network constructs.
Another way of adding a layer to our onion is by implementing different subnets.
For example, if we add an Amazon RDS database
to our architecture with no need for internet access,
then it can be placed in a private subnet
that has no route to or from the internet.
Traffic between subnets can only occur if the VPC route table
and the network access control lists allow it.
And an access control lists or a NACL,
is an optional firewall layer between subnets.
As opposed to security groups, NACLs are a stateless,
meaning that if we want our instances to talk to our database,
we need to explicitly allow traffic from subnet A to subnet B
and also from subnet B to subnet A.
If we want our instances to make outbound connections to the internet,
instead of configuring direct access
we can add one layer by introducing an AWS managed NAT gateway.
NAT gateways allow for traffic initiated from private subnets
to reach the internet
but prevents traffic initiating from the internet to reach our instances.
If your instance needs to communicate with other AWS services,
instead of allowing traffic to or from the internet,
you can use VPC endpoints.
VPC endpoints allow private connections from your VPC to AWS services
like Amazon S3 or DynamoDB,
or even other services that can be exposed by AWS PrivateLink.
You could configure endpoint policies
to specify the traffic that you want to allow through VPC endpoints.
We can also protect network access at the edge.
Amazon CloudFront is a fast, content delivery network or CDN.
Configuring a CloudFront distribution in front of our load balancer
is a good idea so that we speed up the delivery of content to our users,
while at the same time, adding another layer of network security
with advanced TLS capabilities.
We can also block direct internet access to our load balancer
to enforce access via CloudFront.
CloudFront also works well with other edge protection services
that are worth adding to our onion.
AWS Web Application Firewall or WAF to protect against common web exploits,
and AWS Shield to protect
from distributed denial-of-service or DDoS events.
So there you have it.
We've added several layers of network security to our onion,
each layer aims to allow only the network traffic
that is expected by the application.
This layer approach mitigates the impact of a misconfiguration
in one of the layers that could end up in unintended access.
So keep building securely, and I'll see you next time.