Supercloud lets applications work together across multiple cloud environments, but organizations must pay particular attention to how they protect their assets.
The number of available Cloud services has exploded over the last several years. While some of these new offerings feel experimental at best, many are quickly maturing and racking up users.
Here's a new one for you: application migration as a service, better known as supercloud. If you haven't yet heard of supercloud or worried about supercloud security, you will soon.
So, what is supercloud, and what does it mean for cybersecurity?
The term itself isn't necessarily new. The concept has been discussed since 2016. In a nutshell, supercloud lets applications move and work seamlessly across multiple cloud environments, including many private clouds. The goal is to reduce the headaches and potential incompatibility concerns in a multi-cloud architecture.
What are the benefits of supercloud?
Most organizations already committed to multi-cloud find it unwieldy, expensive, and difficult to operate and maintain. Supercloud offers users some promising benefits to solve these challenges.
First, applications can be run in VMs or containers or as abstracted code -- similar to serverless -- in any region with network connectivity into all major public cloud service providers (CSPs), among them AWS, Microsoft Azure, Google Cloud and others.
Second, applications can take advantage of each CSP's cloud-native functions and services -- without having to be customized to support the individual provider's framework. Instead, the supercloud provider abstracts the functions and services and makes them available and easily manageable through a single environment.
With supercloud, organizations wouldn't just reduce the amount of cloud resources now wasted; they could find it more cost-effective to use a variety of cloud services simultaneously.
What about supercloud security?
Like their counterparts managing multi-cloud deployments, security teams have largely realized that, to adequately protect their operations, each cloud requires new skills and different processes and workflows, along with the possible introduction of new security products and services.
A variety of potential security risks could well accompany this iteration of supercloud.
Security teams already struggle to develop and maintain adequate visibility, detection and response capabilities in each cloud they operate in. The overlay of a supercloud abstraction layer isn't likely to improve the situation.
The first concern -- and a valid one -- is vendor lock-in. While supercloud improves portability and seamless interconnectivity, there's no guarantee that shifting from one supercloud provider to another will be easy. In the same vein, supercloud could create a single point of failure, which means security and operations teams need to pay close attention to service-level agreements and resiliency measures.
The second concern is the supercloud provider itself with its centralized threat surface and avenue to compromise across a number of disparate environments. Security teams already struggle to develop and maintain adequate visibility, detection and response capabilities in each cloud they operate in. The overlay of a supercloud abstraction layer isn't likely to improve the situation. In this ecosystem, one compromised privileged user, such as a cloud engineer or DevOps engineer, could wreak havoc on an organization's entire cloud stack. Cloud identity and access management is an issue already; privileges and guardrails must be carefully defined. Otherwise, supercloud security problems will compound and insider threats and other scenarios will escalate.
Losing control
Supercloud is still too new and untested to fully understand all its potential risks. But one risk that is almost guaranteed: the lack of -- or loss of -- skills in each respective cloud while moving to an abstraction layer. Security teams will be increasingly hobbled as they try to prove for vulnerabilities in each respective cloud as organizations move to an abstraction layer.
Supercloud won't replace AWS, Microsoft Azure, Google Cloud, Oracle or other leading providers. After all, they provide the foundational software-defined infrastructure for storage, networking, orchestration and much more. There's no "easy" button for cloud. Applying a shiny veneer on top of it all via an abstraction layer could prove to be detrimental when no one knows how to architect or operate assets within each cloud independently.
Time will tell, but in the meantime, let's try to come up with a better expression than supercloud. Really, supercloud? Is batcloud next?
