Moving from Public Internet to Private Connectivity
Our introductory blog on PaaS adoption in financial services outlined six core challenges facing institutions. This follow-up by Citihub Consulting’s Associate Partner Jim Oulton examines one of those challenges in more detail – how to protect a porous network boundary and looking ahead to CSPs making more of their services available with private, rather than public, endpoints.
Cloud Service Provider PaaS offerings are an attractive proposition, but financial services institutions looking to securely adopt these technologies face significant challenges, not least of which is the fact that most services were originally architected to use the public internet as their primary communication channel. Attempting to ‘privatise’ those services requires complex network engineering plus the layering of additional security controls.
The recent security breach suffered by Capital One is a case in point: early reports made it sound like the hacker gained access to Amazon S3 buckets through an improperly configured firewall, but a more detailed analysis suggests a variety of operational shortcomings (see our earlier blog) including a lack of IP restrictions. Information security always needs to be addressed in a multi-layered, defence-in-depth approach to reduce an organisation’s attack surface. But in this article, we will focus on the challenges of securing PaaS purely from a network perspective.
It is useful to split the problem into the two access planes that need to be considered:
- The Data Plane – the way in which customer application data is routed to the service in question (either within the cloud or to/from on-prem)
- The Management Plane – the communications required to manage, monitor and control services
Each bring their own complications which we will dive into below.
The Data Plane
(a) Intra-CSP traffic
The major CSPs enable certain services to be bound to your own virtual networks, so that traffic from within that virtual network uses the provider backbone rather than the public internet.
Stay current on your favourite topics
However, even with such a binding in place, the service may still be fully accessible from the Internet because the mechanism used to present these services into the virtual network merely provides routes out of the private IP space to specific public addresses. For example, an Azure Storage Account configured with a Service Endpoint still requires that you explicitly deny traffic originating from anywhere other than your virtual network as an additional step. But this differs from service to service and CSP to CSP e.g. when a Service Endpoint is enabled on Azure SQL Database it will block internet access by default and GCP’s Service Controls feature will remove all access from outside your VPC for a given service when enabled (even management). It is also worth noting that the use of a non-transparent proxy may bypass any form of virtual network binding, as an OS or app configured to use such a device will route all traffic to it by default. This will likely result in your traffic traversing the internet anyway.
So for each PaaS service to be used there will be service-specific networking nuances which need to be understood and baseline access patterns defined to ensure that access to data and systems are secure and performant. The networking patterns will need to be updated as CSPs continuously evolve the network features of each service and any systems using those services also will need to be modified in a timely manner.
(b) On-prem to CSP traffic (Hybrid)
Virtual network binding can work for components that are hosted exclusively within your virtual network but it does not solve for when services need to be accessible from on-premise infrastructure.
While each of the leading CSPs have their own branded solutions (Azure ExpressRoute, AWS Direct Connect and GCP Cloud Interconnect) to provide a private interconnect to their data centres, these will simply be ignored when accessing public PaaS offerings unless additional network engineering work is undertaken. This is because the norm for large regulated enterprises is to employ two perimeter networks – one dedicated to general outbound internet access and one for communications with (semi-) trusted third parties.
For brevity, let’s call the former the Internet Perimeter Network (IPN) and the latter the Partner Perimeter Network (PPN). The IPN’s primary objective is security and as such will include a full stack of network security controls (IDS/IPS, DLP, anti-malware) as well as being strictly limited to only outbound HTTP/S traffic. The PPN is where any private connections to your CSP are likely to be terminated and would normally be designed to strike more of a balance between security, performance and availability. With the most basic configuration in place, only traffic destined for corporate address space assigned to the CSP will be routed over this link. Traffic to services with public addresses will be treated like any other internet traffic and will be routed via the IPN. This will almost certainly be a death knell for hybrid integration with Database PaaS and other services using non-HTTP protocols. Even for web-traffic, integration issues can arise from the controls often enforced in an IPN due to SSL interception required to perform DLP, as well as Anti-Malware scanning of traffic.
To route via the PPN, Border Gateway Protocol (BGP) configuration needs to explicitly advertise the CSPs’ AS numbers on the private circuit. This will then allow more freedom of what services to allow and what level of DLP and traffic inspection to enforce. However, even this must be undertaken with caution. If your organisation accesses SaaS offerings hosted in that CSP, this could result in bypassing the controls that would normally be applied in your IPN.
Also, just as with Virtual Network access, services still need to be locked down with additional controls or they could be vulnerable to attack from the internet.
The Management Plane
PaaS offerings all require some level of management by the CSP. However, some services are little more than an install wizard that configure resources on behalf of a customer. In doing so, they will have requirements at build-time to access external internet resources for packages (and updates/patches as the service continues to be managed), which will need to managed carefully resulting in engineering and governance overhead.
Equally, some CSP offerings only allow monitoring and management of resources via public IP addresses. Again, this presents your resources to the outside world and requires additional controls to be applied, such as software-defined network ACLs and bullet proof management of identity and entitlements. You will need to coordinate with your CSP to document the IP addresses that need to be permissioned – don’t necessarily expect this to be well documented in advance.
Private Services: the Right Way Forward
The ideal answer to solving these network security and engineering challenges requires CSPs to make more of their services available with private, rather than public endpoints. This will shut off public internet access by default, or at least make the rules to do so simpler. It will also greatly simplify the routing required to solve the hybrid use-cases as traffic to your private CIDR ranges is already being routed via the private interconnect.
This evolution is still in the process of panning out. Although there is still some way to go, the three main CSPs have recognised the challenges for regulated firms and have begun down this path (see Microsoft’s recent announcement for Private Link). We expect a greater choice of ‘privatised’ PaaS offerings to come online and, when available, this will significantly reduce one of the major barriers to adoption.