Network security and AWS Transit Gateway
There are a few ways you can improve your networking security using AWS Transit Gateway. If you are using AWS multi account or multi region, you probably should be using a transit gateway.
What is transit gateway?
AWS Transit Gateway is a network hub. Instead of creating individual VPC peeing connections you can connect multiple VPC to a single transit gateway and have it serve as the hub for your networking.
Transit gateways have many great features and can simplify your network design. The features include:
The main cost is based on the amount of data processed. There is also a small per-attachment cost.
By using the advanced routing functionality you can inspect all the traffic traversing your transit gateway by sending it via a security appliance.
There is also a new feature that I have been requesting for ages. You can now propagate references to other security group across transit gateways. This is an essential feature and it's great it is finally included. More on this below...
How to inspect VPC to VPC traffic
With AWS transit gateway it is possible to deliver all the traffic to a security appliance.
Look at this example - it is straight from the AWS documents. It is from the prescriptive documents on VPC to VPC traffic scanning with a transit gateway.
It uses a hub and spoke model. The transit gateway (centre) is the hub. The VPC on the left are spokes. The VPC on the right contains the security appliance. One of the great features is Availability Zones can be maintained across this flow. This reduces latency and cost. Other AZ can be used in the event of a failure.
The basic flow is as follows:
The whole process is followed in revers for return traffic
There area couple of other technical points to note:
This can be used as a simple firewall that controls traffic based on origin/destination rules (based on protocol, IP and port) or it can be used to implement deep packet inspection. Deep packet inspection also involves the breaking of secure TLS communication by having a trusted certificate on the firewall. Traffic can then be unencrypted and re-encrypted.
It is hard to implement IP/port based firewall rules in a transit gateway due to the nature of dynamic cloud networking.
Why inspect WAN traffic?
This allows complete scanning of all traffic crossing from one VPC to another. It is a pattern often used in organisations that require complete scanning of East-West traffic.
Note: In networking parlance North-South traffic refers to external traffic outside the WAN. East-West traffic refers to traffic within the WAN.
Many organisations employ some network traffic scanning at the boundary (North-South traffic). As part of a defence in depth strategy it necessary to include some internal checks as well as just perimeter security.
What are the issues?
There is a problem with the design of scanning all the traffic that flows between VPC. The major issue is that is it is a bit arbitrary.
In a modern AWS architecture I would encourage the use of multiple AWS accounts to separate concerns. This helps mitigate against any breech and limits the blast radius of any intrusion. It is a very good idea as writing complex IAM policies is error prone. It is also useful for separating administrative control or billing. I like to split workloads into separate AWS accounts. Also separate accounts should be used to separate production and development environments. I have also seen separate IAM accounts used to split types of workload like putting all the containerised workloads in one account, EC2 in another and Lambda workloads in a 3rd.
In an AWS world you can create multiple VPC when you want, but you are also forced to create separate VPC when you cross account or region boundaries.
The big problem is defining workloads and where you need to insert security controls. If you use a container platform it would be mad to deploy a Kubernetes cluster for each application. Many of your container workloads will sit in one cluster in a single VPC. Generally you want to insert the controls between independent workloads to monitor East-West traffic. But in a modern cloud environment this does not equate to a traditional data centre design.
领英推荐
What is the solution?
With all things security, there is not a one size fits all approach. You have to model threats and decide what risks you are really trying to mitigate.
Ofter other approaches like Zero Trust are a better idea. If you use strong 2-way authentication and encryption at every stage you can secure internal traffic.
Controls inside container clusters are important to secure internal traffic. Often network access within container platforms is overlooked. Within a cluster having strong controls like RBAC and pod security policies stops attackers moving sideways through a network. Using a service mesh if applicable can help manage the interactions of components and improve security.
The other important item is observability. You need to make sure observability is implemented where you need it.
Improved Security group Support (NEW)
This is probably one of the most requested feature in AWS history (I don't have any stats on that but I was told by AWS there had been a lot of requests). The reason is that it is such an important feature and has taken a while to be delivered. I have been asking of it pretty much since Transit Gateway was launched. I was also told (unofficially) by AWS that the reason this was taking so long was it involved some major changes to the networking stack and had some major dependancies. This feature is available with VPC peering.
I have had client projects where I have not been able to use transit gateways because of this feature being missing. We need up with lots of VPC peering an a much more complex network design!
Anyway - on to the feature. You can now reference security groups in other VPC (and in other accounts) when the VPC are connected via a transit gateway. This is a feature you have to specifically enable when you create a transit gateway.
aws?ec2?create-transit-gatewayt?\
--description?MyTransitGateway \
--options SecurityGroupReferencingSupport=enable
Th can also be turned on and off on each attachment. Wheres it defaults to off on the transit gateway, it is on by default for attachments. You can explicitly control it when creating the attachment:
aws?ec2?create-transit-gateway-vpc-attachment?\
--transit-gateway-id?[TGW-ID] \
--vpc-id?[VPC-ID] \
--subnet-id?[SUBNET-ID]
--options SecurityGroupReferencingSupport=enable
It can also be turned on later by modifying the transit gateway or attachment.
If you have 2 applications across 2 VPC connected by a transit gateway. They are set up as follows:
If you want Application 1 to send an API request to Application 2, you would need to include a specific rule ingress rule to SG2 to allow that traffic. When you create this rule you can reference SG2 as a source.
aws ec2?authorize-security-group-ingress \
?—group-name SG2 \
—protocol tcp —port 443
—source-group SG1 \
—groupowner [ACCOUNT 1 ID]
If the VPCs are across multiple accounts you need to add the groupowner parameter to reference the other account. Otherwise do not include this parameter. TCP port 443 is used for HTTPS traffic.
A couple of important notes:
Another important note is that this will not work with traffic inspection described above. It is an either/or choice at the moment.
This feature has been available for VPC peering for some time but has been missing for transit gateways.
Conclusion
It is almost impossible for anyone to design your security for you. You need to understand your application, regulatory requirements, your threat model and your organisations appetite to risk. Network security is part of a package of security measures and it also depends on what other controls you have in place. Having said all of that my preferred approach is:
Unless you absolutely need to I would try and avoid having a security appliance scanning east-west traffic. Not only will it break the new security group functionality, it can also cause other issues. It can also add an unacceptable amount of cost and latency and force security compromises in other areas.
One of the most important tips I would have for anybody is build a relationship with your security team. They may not be particularly experienced with cloud or AWS. You need to explain the trade-offs and take them on a journey to help them understand the risks.