Introduction
This article is the second one in a series of articles where we illustrate some of the challenges NSC42 has faced and the solutions proposed to our clients to achieve a cost-efficient implementation of access control and compliance.
In the previous article, I gave you a short history of network security, appliances and native controls. In this one, I will take you through the individual solution patterns we’ve used at NSC42 to create secure solutions and environments compliant to requirements and standards.
The article will talk you through the various cases and patterns.
So that the article doesn't become too unruly I will be covering the most common patterns and those that can be replicated easily. There may be some specific use cases that will not fit into the particular patterns discussed in so feel free to comment or get in touch.
A caveat I'd like to add though is that this article is by no means the finished product as the security controls in the cloud are ever changing.
As our clients will already know, here at NSC42 we are whiteboard people, so some of the pictures will be in the form of whiteboard drawings, let me know if they're not clear, or you don’t like the style.
Use cases and common pitfalls
Security appliance vendors are still updating their appliances to include typical cloud architecture that integrates into the cloud provider fabric more efficiently. Some others are instead coming up with customised and managed sets of rules for cloud provider specific controls (e.g. managed WAF rules).
The patterns in this section refer to the traditional multi-tier architecture (sometimes referred to as a three-tier model) and the patterns explored here will apply to IaaS cloud deployment. The patterns are adapted to hybrid models (e.g. IaaS and SaaS), but for the sake of time, this part will focus only on IaaS deployments.
The reference that I use in those hybrid environments is usually web API: whenever a service in IaaS needs to communicate with another cloud implementation (external IaaS, SaaS, PaaS) I’ll secure the communication as I would do between two API traversing public internet.
The deployment blueprints of traditional Firewalls and Web Access Firewall (WAF) appliances are similar to conventional DC implementation with few exceptions. Nonetheless, please note that an access control relying only on firewalls struggles already in an IaaS model as it limits the capability of the cloud too.
Traditional firewall access control will struggle in a more modern hybrid integration between SaaS, PaaS and IaaS/Data Center. So, the location of the ACL should be carefully considered when one or more layer is exposed outside of the traditional IaaS infrastructure. I’ll provide some considerations on those hybrid scenarios later on.
Management Problem
The role of a central ACL rule manager becomes crucial, for operational processes and ease of use, as otherwise, the deployment of the rules is mostly atomic (e.g. inside one or more scripts). A typical scenario that requires a manager is when a cloud deployment has two or more firewall appliances.
A central rule manager enables the automatic synchronisation of rules, as most of the systems do not currently support synchronisation of rules/sessions to an individual application level.
Usually, the management of ACL together with other crucial managing components should be deployed in an ad-hoc environment; I’ll refer to this as a management layer.
Patterns
In this section, I am going to illustrate some of the patterns NSC42 has used in some cases but be mindful that different cloud providers have a different technical implementation.
Full native stack
AWS Use Case:
The picture below displays a full stack deployment in an IaaS cloud environment.
The pattern display on the left a classical 3 tier with the integration of different native AWS services like:
IP access control rules — for port-based filtering and as compensating controlELB/ALB for load balancing and SSL offloadingWAF for specific WEB Layer 7 rules
The organisation can decide to tip the scale of integration one way or another leveraging more on the cloud.
In this pattern, the controls are fully native and integrated with the fabric of the cloud.
Utilising this pattern has the advantage that deployment or redeployment can be automated.
The disadvantage is that the rules are distributed across various controls and not centrally managed. The distributed rules could be quite complicated from the management perspective, as usually, the managing elements of infrastructure are deployed in an isolated environment (Azure subscription or AWS account).
Access to these management environments should be restricted to as the top security level. Any attack brought to this level of administration and control impacts and lowers the overall security posture of the environment.
The above diagram is derived from the reference AWS architecture.
References: https://aws.amazon.com/blogs/aws/building-three-tier-architectures-with-security-groups/
Azure:
The above diagram displays the cloud controls in Azure. The picture is equivalent in AWS with some variation on the controls.
In Azure, the following are the equivalent controls, with few comparisons with the AWS equivalent:
Access controls via Network Security Groups (NSG)
Load balancers (even though they are not as mature as the AWS)
The WAF is not as mature and does not have the same level of managed rules as in AWS
The WAF does not have central rule management like the AWS equivalent.
References:
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-hybridhttps://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws-part-2-network-zoning/https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
Alternative Azure SQL three-tier stack blueprint:
The above is an extract of the AWS blueprint available here: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/n-tier-sql-server
Full appliance stack
Azure
The following provides a high level and detailed implementation of a Full-stack Network virtual appliance in a three tier. The whiteboard presents a couple of options:
Single Firewall between web and internet (usually in Small and Medium Business deployment)
Multiple firewalls at multiple levels (usually in Enterprise organisations)
Azure Blueprint:
Note: In the blueprint, there is a mix of NSG (network security groups) and NVA (Network virtual appliances). The NSG can be left empty unless you’d like to implement a hybrid approach. As in the previous section for AWS, the organisation needs to decide how much they want to use the native controls (WAF/NSG…) and how much they want to use traditional appliances (Firewalls/WAF…).
Single firewall detailed deployment:
The above diagram displays an implementation with multiple subscriptions.
The deployment leverage on the Azure subscriptions to enforce isolation of networks.
The NVA can be deployed as an individual and single appliance if the enterprise does not require high availability.
This deployment mode spares the enterprise in deploying script to update UDR, but the UDR would still need to point to the southern interface of the firewall.
The UDR informs the various virtual networks (vNETs) where to point as the default gateway, the southern firewall interface.
for more information refer to https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview and https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
Multiple firewall scenario detailed deployments:
The table below displays the steps and the controls in various areas
The above is just a simplified scenario with some controls. It is an example of how to connect an enterprise (On-Prem) with a cloud deployment.
The network is divided into Prod, Dev and UAT subscriptions (on the left) as in a similar way to the on-prem system (bottom right part of the picture).
The numbers display the flows of traffic from an external request to the internal system with the various controls.
The one that follows will provide some more level of detail:
The deployment leverage on the Azure subscriptions to deploy isolation.
This blueprint requires peering on the southern interface of the firewall NVA with the Load balancer on the northern side.
This picture (prettier than the above sketch) displays one method of deployment in Azure.
Please note that the various subscription needs to be equipped with UDR as the south part of the firewall does not have a load balancer.
This deployment will persist up until the point when Azure will develop the load balancers to enable persistent sessions.
As an alternative to the UDR, the firewall could have load balancers on the north side.
For a reason explained above, the southern part of the firewall is peered to multiple subscriptions. To have a route to the firewall, and hence the internet, the VNETs needs to have User Defined Routes (UDR).
To achieve load balancing and high availability, the various subscriptions need a script to dynamically update the default gateway in the UDR to be the active firewall's southern interface.
The script guarantees high availability in case one of the instances goes down.
The script would probe the interface dynamically and update the default gateway on the UDR,
for more information refer to https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview and https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
AWS:
Following a couple of examples for NVA deployment in AWS the scenario is similar to Azure with some difference in the peering, custom routes and probing.
Firewall and Datacenter scenarios:
The above pucture displays a deployment of two appliances inside a single VPC with multiple availability zones.
The Firewall is deployed in front of the WAF, while thetThe VPC also peers with an on-Prem (or could be another VPC/Account).
The appliances will be located behind ELB/ALB shielded by the Firewall and WAF. As with the previous case, the NVA appliance (Firewall) could cover multiple VPC in AWS.
Detailed Firewall scenario:
The following represent the deployment of the firewall with multiple VPC in a similar model as Azure.
Each VPC will have a VPN gateway that is peered with both firewalls. The active Firewall will peer with the VPN gateway and form a BGP peering. Being peered with BGP to the AWS VPN gateway, the active Firewall will inject a default route. In case the primary system fails the other firewall will become active and start advertising the default route.
As previously discussed the Firewall could be deployed in standalone mode or with the aid of a WAF. The WAF could be implemented as cloud front-end filtering service (e.g. AWS WAF) or an external SaaS service (e.g. Imperva or similar).
Hybrid Approach
The hybrid approach makes use of some the models described above and layers them up with the use of native cloud controls (WAF, IP Filtering etc…)
The significant difference in hybrid is how many rules you want to implement in the cloud access controls (NSG/ACL/NACL) and how many you want to implement in the Firewalls.
The reasons behind this approach are multiple: the cloud immaturity of an organisation or the alternative rationale is to keep most of the access control rules in one place. A hybrid use of the rule could be a useful migration approach but is not recommended as the rules are scattered around multiple access control points and would make the management of those ultimately more complicated.
Conclusions
As we’ve explored there are multiple deployed patterns. At NSC42 we’re committed to delivering what our customers want to achieve and guide them to the best solution that will fit their needs, budget and level of maturity.
The organisation shall have a clear, and solid strategy and idea as the patterns above are difficult to change once the deployment is underway.
Infrastructure as a code enables “easy” re-deployment of the various components, but this would always imply testing and additional effort.
My recommendation on the back of NSC42's experience is to have a series of workshops with the key stakeholder and agree a deployment model that makes everyone comfortable (operation, management, compliance and security).
Having a solid foundation results in a happier or less painful cloud journey.
Depending on the organisation’s appetite for cloud readiness and the level of cloud maturity of the operations team a cloud-first from a control perspective could be more or less recommended.
For organisations that are more traditional, the firewall appliances remain, with exceptions, operationally easier to maintain.
While, native access control is recomended to cloud first organisations with more advanced skilled team native access controls.
Acronyms used
We all hate them, but we can’t live without them, for the sake of clarity; I’ll list the meanings of the terms that I have used in the article.
AD — Microsoft Active Directory
AWS — Amazon Web Services
ACL — Access control List (AWS)
NACL — Network Access Control List (AWS)
NSG — Network Security Group (Azure)
EU GDPR — European Union General Data Protection Regulation (in force from May 2018)
EU — European Union
FW — Firewall
HA — High Availability
IDS/IPS — Intrusion Prevention/Detection System
L3 — ISO/OSI Layer 3 — Network Layer
L2 — ISO/OSI Layer 2 — Data Layer
SMB — Small and Medium Businesses
MS — Microsoft
NAT/PAT — Network/Port Address Translation
NVA — Network Virtual Appliances
WAF — Web Application Firewall
Other article on medium: