Multi-Cloud Security: The Rise of the Supercloud
In December 2021 Dave Vellante wrote in siliconANGLE about “The Rise of the Supercloud”.
Supercloud describes an architecture (for companies like Snowflake and Databricks) that taps the underlying services and primitives of public cloud providers to deliver additional value above and beyond what’s available from those public cloud providers. A supercloud delivers capabilities through software, consumed as services, and can run on a single public cloud or span multiple clouds.
In this article we will learn that supercloud providers have challenges securing their data cloud, how multi-cloud networking is more difficult than it needs to be, and finally how supercloud providers can now control their own multi-cloud-native network fabrics to gain new superpowers of cloud-independent control and security. This will deliver Supercloud providers and their customers with better cost structures and revenue, far stronger multi-cloud security, and greater end-to-end control independent of underlay networks and underlay clouds.
Prominent examples of superclouds include Databricks, DataRobot, HashiCorp, Confluent, and Snowflake. The facts of their widespread adoption and realized value are evident in each of these examples. There is, however, an important, unsolved problem with superclouds. In the absence of a solution to this problem, the direct and indirect consequences are inevitably passed along to the end-user. Superclouds are deeply, logically integrated with the underlying cloud infrastructure on which they are built and do not control. The problem is that the realms of responsibility between the supercloud operator and their customers are overlapping in such a way that it’s impossible to achieve a clear separation of concerns, so both supercloud operator and customer end up with expensive dependencies on clouds and telcos, which compromise security, agility, and control.
Multi-Cloud Security
Dave’s follow-up article “Securing your Snowflake cloud data” maps this problem out nicely. As an example, Snowflake’s supercloud has “a shared responsibility model between Snowflake and its customers when it comes to fully securing their data cloud”. This model is a three-layered security approach – network, identity access management, and encryption. The customer is responsible for providing and managing infrastructure fundamentals including DNS, public access controls, inter-cloud connectivity (e.g., MPLS, VPN, raw internet), and a private link to the cloud environment. This hurts the supercloud provider and the customer – costs are high, security is low and agility is compromised. Superclouds are inherently distributed systems with central control, but they do not control the network or how to securely interconnect the distributed system. Ben Herzberg surmises, “Complexity is the enemy of security, and having those multi-cloud operations, from a security perspective, definitely adds complexity, which adds risks, so simplifying that is really, really helpful”.
The Lost Opportunities
This problem profoundly impacts multiple dimensions of security (e.g. confidentiality, integrity, availability), but even that does not encompass the entire realm of effect. Viewed through the prism of business benefits, there is the prize of greater adoption, realized value, and minimized costs. Today’s superclouds burden their customers with setting up security and connectivity for superclouds, all of which represent costs and risks for their customers. For example, all the services mentioned above are monetized by cloud providers or other 3rd parties including telecom companies. This is a lost revenue opportunity as well as slowing down time to revenue for superclouds. They also incur greater costs from supporting their customers to fix issues that are outside of their control. This is a lost opportunity for superclouds to create the most value for their customers.
How NetFoundry Handles Multi-Cloud Secure Connectivity
NetFoundry offers a cutting-edge solution for multi-cloud secure connectivity by leveraging its Zero Trust Networking principles and the open-source NetFoundry platform. Here’s how NetFoundry manages to secure connectivity across multiple cloud environments:
- Zero Trust Architecture
NetFoundry’s approach is grounded in Zero Trust principles, which fundamentally change how security is applied to network connections. This architecture assumes that no part of the network is inherently trustworthy, whether inside or outside the organization’s perimeter. All connections are authenticated, authorized, and encrypted, ensuring robust security at all times. - Overlay Networking with NetFoundry
NetFoundry utilizes the NetFoundry platform to create secure, software-defined overlay networks on top of existing infrastructure. This means that no changes are required to the underlying network, making it highly adaptable to various cloud environments. The overlay network ensures that all communication is secure and isolated from potential threats. - Microsegmentation
Microsegmentation is a key feature of NetFoundry’s solution. It involves dividing the network into smaller, isolated segments that can be managed and secured independently. This limits the lateral movement of attackers within the network and ensures that even if one segment is compromised, others remain secure. - Software-Defined Perimeters (SDP)
NetFoundry’s software-defined perimeters make applications and services invisible to unauthorized users. Only verified entities can access specific network resources using identity and context-based access controls. This approach drastically reduces the attack surface and mitigates the risk of external threats. - Identity-Centric Security
NetFoundry places a strong emphasis on identity verification for both users and devices. Every connection request is authenticated using multi-factor authentication (MFA) and other advanced identity verification techniques. This ensures that only legitimate users and devices can access the network, enhancing overall security. - End-to-End Encryption
NetFoundry ensures that all data transmitted across its network is encrypted end-to-end. This means that data is protected from interception and tampering as it moves between endpoints, whether they are in the same cloud, different clouds, or on-premises. - API-First Approach
NetFoundry’s platform is designed to be API-first, allowing for seamless integration with existing IT and DevOps tools. This enables organizations to programmatically automate and manage their network security policies and configurations, improving efficiency and consistency across multi-cloud environments. - Multi-Cloud Support
NetFoundry is designed to work seamlessly across multiple cloud environments, including public clouds (like AWS, Azure, and Google Cloud), private clouds, and hybrid setups. This multi-cloud support ensures that organizations can maintain consistent security policies and connectivity regardless of where their applications and data reside. - Simplified Management and Deployment
NetFoundry’s platform provides a centralized management console that simplifies the deployment and management of secure connectivity across multi-cloud environments. This console allows administrators to configure and monitor network security policies, manage identities, and oversee network performance from a single interface.
Example Use Case: Secure Multi-Cloud Deployment
Consider an enterprise that has applications deployed across AWS, Azure, and a private data center. With NetFoundry, the enterprise can:
- Establish Secure Connections: Use NetFoundry to create secure overlay networks that connect applications across AWS, Azure, and the private data center without exposing any part of the network to the public internet.
- Apply Microsegmentation: Segment the network so that different applications and services are isolated from each other, reducing the risk of lateral movement in case of a breach.
- Implement Zero Trust Access Controls: Ensure that only authenticated and authorized users and devices can access specific applications and services, regardless of their location.
- Use End-to-End Encryption: Strong encryption protects all data in transit, ensuring that it remains secure as it moves between different cloud environments.
- Centralized Management: Manage all network security policies and configurations from a console simplifying operations and improving visibility.
By leveraging NetFoundry’s innovative approach to multi-cloud secure connectivity, organizations can achieve greater security, flexibility, and control over their distributed IT environments, ultimately enhancing their ability to respond to evolving cyber threats and business requirements.
The Network is the Computer
John Gage of Sun Microsystems once coined the term, “The network is the computer”. What if superclouds could specify the network to the application instead of relying on all these problematic, shared systems and network infrastructure that is external to the application? This would allow their applications to be multi-cloud native, secure-by-design, and develop-once-deploy-anywhere (be it in hyper scalers or at the edge and in IoT). They would allow their customers to massively reduce complexity and deliver value faster to customers while providing greater revenue and lower costs for superclouds to benefit shareholders.
Supercloud innovators would get superpowers by controlling their networks and making them secure-by-design, programmable, API-first, and automation-friendly; but that does not sound like the description of a network.They will examine the problem with traditional network approaches which has led to the current shared responsibility model for superclouds.
The problem of powerless superclouds: Multi-cloud security
With the proper separation of concerns, a complex system like a supercloud doesn’t mean a complex network. If you’ve ever managed a mess of VPNs with Bi-NAT and split-horizon DNS in play, then you know what pain is. Now, I know you’re thinking, “There’s no way out of this mess!” and “You haven’t seen my network.” Let’s set the stage for a surprisingly simple survival plan with a bit of understanding of how we got here.
We discussed above that the concerns of the network are inseparable from the applications they deliver, i.e. “the network is the computer”. We illuminated a fundamental problem that emerges from that tight coupling: a shared responsibility model that overcomplicates service infrastructure and ultimately, unfortunately, overburdens the customer. Consequently, this impedes realizing the total value of the supercloud for customers and shareholders. We concluded with the recognition that supercloud innovators will eventually build secure and programmable connectivity into their offerings and thereby rebalance the operational burden.
Logical Separation > Inspectors and Gatekeepers
Network configurations are complex because they are specially configured to meet the needs of the applications they deliver. This app-to-network dependency requires the person with application know-how to communicate the app’s needs precisely to the person with the networking know-how. You’re probably thinking, “Doesn’t as-code automation solve this problem?” Sure, that’d be superior to hand-crafting specialized network configurations for apps, but what if we could prevent the problem from within the app instead of solving it with more app-external tooling, processes and skillsets?
As Dave Vellante’s ‘The Rise of the Supercloud’ pointed out, superclouds “can span multiple clouds — and on-premises workloads — and hide the underlying complexity of the infrastructure supporting this work”. The far-flung nodes in any distributed system must communicate over a network. This distributed system depends too much on the perfect alignment of the network configuration. Superclouds that require unique network configuration and have a presence in the network fabrics managed by the consumer of the supercloud have an issue of co-management. This forces the service provider to separate concerns in the wrong place, thereby burdening you, their customer, with shared responsibility for complex network configurations. This responsibility includes firewall exceptions, access control lists, proxies, virtual private networks, reverse tunnels, web application firewalls, and other sources of cranial agony.
Many vendors will bring a network-first approach to solving a ‘secure, multi-cloud network’. These certainly include vendors like Aviatrix and F5. Following first principles, a network’s purpose is to convey data packets from a sender address to a recipient address. You cannot secure them, only isolate them. ‘Secure network’ is an oxymoron, and so we can only say ‘secure, multi-cloud network’ with a hint of sarcasm. It is short-sighted to suggest that the application and its data are secured because the network is secure. Distributed networks using the public internet expose the application server to network-borne attacks – e.g., leveraging a known vulnerability to intrude, denial of service by abusing the login mechanism, and the inevitable future zero-day exploits. This is part of the reason why cybercrime is a trillion-dollar drag on the global economy, and surveillance techniques known as scan-and-exploit have become the No. 1 attack vector for cybercriminals. It’s quite simply the easiest way to gain an intrusive foothold.
Industry analysts have articulated this problem, but the discussed solutions do not go far enough to decouple the application from the network configuration. In 2021 Gartner® released its report ‘Innovation Insight for Comprehensive Secure Connectivity for Composite Applications’ (CASCE), “describing the convergence of application and network security to build a comprehensive policy configuration and enforcement model.” Core principles of CASCE include the perimeter being logical rather than physical, identity-based interaction with the application to access services and separation of policy definition and enforcement. They name ten vendors, including F5, HashiCorp, Kong, NetFoundry, and Palo Alto Networks. The report describes a real problem and points at the incremental improvements these vendors can offer with IP inspector and IP gatekeeper tactics. There are several broad problems with these approaches:
Almost all of the mentioned technologies for CASCE or multi-cloud are bolt-on solutions that operate at the cloud network level. They cannot be embedded into the application and are non-transparent to the user and customer.
Most of these technologies depend on public IPs at the source and destination, which means they can be subject to external network-level attacks from malicious actors. Therefore, companies try to isolate source and destination with proxies, firewalls, and other things simultaneously depending upon open inbound ports that reintroduce the same vulnerability to network-level attacks.
Many of the technologies are closed source, preventing the consumer from controlling the software to audit, build, and innovate. Instead, the consumer is locked in. Superclouds do not want to depend on any single cloud or service (e.g., using AWS Privatelink is tied only to AWS).
Bolt-on gatekeepers do not resolve the inherent tension between business velocity and security. They are not built for automation using Infrastructure-as-Code, APIs, GitOps, and DevOps tools and methodology.
“It’s not our fault; we don’t control the network”
For this reason, many superclouds and applications state, ‘We don’t control secure networking – that’s our customer’s job’. Snowflake, for example, gives this responsibility to their customers. The below illustrates the many layers of infrastructure that must align to deliver the Snowflake supercloud to the user. This is a picture of fragility, rigidity, and complexity in the name of security, but with many hidden costs, not the least of which is business velocity. Bolted-on solutions limit business velocity because they introduce handoffs, interfaces, and third parties. This is why the current shared-responsibility cybersecurity model doesn’t work, asymmetrically favors the cyber attacker, and ultimately offloads responsibility for securing the supercloud to the end user.
With respect to John Gage, the current operating model for most superclouds means that the network is no longer the computer in quite the same way. Building secure networking inside the application source code can dramatically improve the current operating mode. This ensures continual, perfect alignment of the application’s network configuration without burdening the customer with the shared responsibility model. Superclouds can get superpowers!
