App Tiers Affected:
The term Multi-cloud refers to when a single organizations uses more than one public cloud service provider. The F5 State of Application Strategy Report noted that more and more organizations are using multi-clouds each year. But what does multi-cloud mean and what are the implications for security? Let's start with the basics.
What makes a cloud, a cloud? The characteristics of cloud computing, according to “The NIST Definition of Cloud Computing”1 (NIST 800-145), a computing platform is a cloud if it includes:
- A self-service system that can automatically bring virtualized computing resources online,
- Extensive network connectivity, both between each resource within the cloud as well as outside the cloud,
- Shared resources among multiple consumers (multitenant) but still somewhat independent and abstracted,
- The ability to rapidly expand or shrink (elasticity) resources based on demand, such that these resources appear unlimited to the user,
- And has measured and metered usage, usually in some abstract manner.
All of these cloud functions can be automated or, in more complex configurations, orchestrated. The real power of cloud technology is providing operational agility. With a pay-per-usage model, you rent what you need, when you need it, and turn large investments of capital expenditures (CapEx) into bite-sized operational expenses (OpEx). Following the business theory “do-what-you-do-best-and-subcontract-the-rest,” using the cloud allows you to focus on your applications. The cloud providers deal with the servers, racks, cables, server rooms, facilities, and the skilled personnel needed to run it all. Those cloud providers can use that economy of scale to provide depth (more services) and breadth (more resources). It’s no wonder that most organizations look to the cloud for application modernization because they can scale up new ideas quickly and get them into the hands of users and customers.
Several types of technical services are offered as cloud services, which are often mixed and matched according to an organization’s need. These include:
- Software as a Service (SaaS): A cloud business application delivered via an API or a web service. Examples include Dropbox, Zoom, Office 365, Salesforce, and ServiceNow.
- Platform as a Service (PaaS): An elastic software platform on which to rapidly build applications using cloud-running components. Examples include Azure, SAP Cloud, Google App Engine, Heroku, Amazon Web Services (AWS) Lambda, Salesforce Lightning, Cloud Foundry, and OpenShift.
- Functions as a Service (FaaS): A special form of PaaS that runs microservices or singular functions in a serverless environment (only code, no servers). MicroservicesMicroservices: Small, single-purpose application components that are used to form larger, more complex applications. You can write a microservice program for a singular function, and because each one focuses on a single capability, they are relatively quick to develop and mesh together. are small, single-purpose application components used to form larger, more complex applications. A microservice program can be written for a single function, and because each one focuses on a specific capability they are relatively quick to develop and mesh together.
- Containers as a Service (CaaS): Another form of PaaS that provides a platform for containers. ContainersContainers: A lightweight method of virtualizing an application so that it is encapsulated and isolated in its own operating environment. It enables developers to build and deploy an application faster while also reducing overhead associated with virtual machines. are a lightweight method for virtualizing an application so that it is encapsulated and isolated in its own operating environment. It enables developers to build and deploy an application faster while also reducing overhead associated with virtual machines. CaaS often run systems like Kubernetes or Docker Swarm to manage containers.
- Infrastructure as a Service (IaaS): Virtual computers on which organizations can load operating systems and run software. The cloud systems virtualize all the system’s computing, memory, and storage subsystems. Examples include Google Compute Engine, DigitalOcean, Linode, and AWS.
Another way to categorize cloud services is by where they reside. These deployment modes include:
- Public cloud: Shared Internet-reachable cloud services available to anyone who can pay for them. This is the most common cloud computing model.
- Private cloud: A cloud that an organization builds for itself on its own hardware for use only by that organization. AWS began as a private cloud supporting Amazon’s e-tail business. Some organizations have even moved their workloads off of public clouds to their own private clouds in a phenomenon that’s called cloud repatriation.
- Hybrid cloud: A combination that puts some services on a private cloud and some on public clouds. This is usually done to maintain better control over data and costs.
- Community cloud: Multitenant cloud systems that allow several organizations to work together on the same platform, given that they have similar needs and concerns. Government organizations often use this deployment model.
Now that we’ve established definitions, we can explore the different use cases of a multi-cloud. Going back to the basics, the most common form of multi-cloud describes using services (SaaS, PaaS, IaaS) from two or more public cloud providers. So, if an organization has an application deployed in AWS (IaaS), a customer relationship management system in Salesforce (PaaS), and uses Dropbox for storage (SaaS), they’d be considered multi-cloud. Now you can see how this is likely to be pretty common.
Given the different applications spread across clouds, it is also likely that individual organizational teams and business processes are running specialized cloud-based deployments unique to their needs. Different cloud providers have better functionality for certain types of applications, and business users will gravitate toward best-of-breed solutions. Often this happens in a makeshift manner over time as different teams find newer and better solutions and move off legacy systems to pockets of different cloud deployments. This could mean a fragmented approach to IT governance and therefore a fragmented approach to IT security. A big problem.
As organizations mature, they often realize they need to consolidate these multi-cloud deployments into a single, unified strategy (and security policy). We’ll talk more about this as we go on.
A force multiplier for cloud computing is using containers and microservices. These tools allow applications to become even more portable, so they can be deployed quickly into different FaaS or CaaS clouds as needed. This means that organizations can dynamically change where an application runs to take advantage of better pricing, geographic proximity to users, changing legal requirements, or in response to availability events. Effectively, organizations can hyperscale and load balance across many cloud providers around the world. This form of multi-cloud is sometimes called omni-cloud.
Note that you don’t have to use microservices or containers to do this—you can also use plain old general compute instances in an IaaS. It’s just faster to use containers and microservices because they’re smaller and therefore easier to deploy.
We’ve seen how organizations drift into using a multi-cloud through circumstance and not by plan. In fact, shadow IT coupled with the ease of acquiring/deploying cloud applications has placed many companies into a multi-cloud configuration before an enterprise-wide strategy was formed. However, organizations choose to use a multi-cloud for a variety of reasons:
- Access to the best features: Each cloud provider has special offerings and strengths, while many organizations have different departments that may need these specific toolsets and features.
- Access to better pricing: Each cloud provider also charges differently for different services, so organizations may want to pick and choose the cheapest options as needed from an array of providers.
- Reduce cloud concentration risk: Why put all your eggs in one cloud provider’s basket? Organizations like the flexibility of migrating to whatever cloud platform works best as needed. For large deployments, vendors can compete for an organization’s business.
- Increase resilience: Related to vendor dependence, multi-cloud means having more backup options should a cloud provider experience an outage. This puts organizations in a position to load balance applications across all cloud providers around the world.
- Bring connectivity closer to users/customers: Different cloud providers offer different services in different geographic regions. By combining clouds, organizations can offer a more complete set of services in the regions closest to their users and customers.
- Achieve data sovereigntyData Sovereignty: The specific regulations countries have for storing and processing data about their citizens within their borders.: Many countries have specific regulations that require data about their citizens be stored and processed within their country. With a multi-cloud, organizations can combine offerings from different cloud providers with different regional sites for a global footprint while still maintaining compliance with data sovereignty laws.
Obviously, using more cloud services means more buttons and levers as well as more dashboards to review. There are also more built-in security and management tools to master. As with every other cybersecurity challenge, the problems flow directly from IT operational proficiency. Organizations that can’t manage their stuff will have blind spots and leaks for attackers to exploit. But a multi-cloud tooling patchwork makes operational management difficult.
The key to operational efficiency and effectiveness is consistency across all environments. This is achievable by reducing complexity and centralizing control. However, in a multi-cloud environment, each cloud provider has their own approach to infrastructure security. This includes identity management, network security, automation options, configuration templates, and audit logging.
One of the biggest inconsistencies to overcome is that cloud providers often use different security models. This disparity can go far deeper than security, as they also have varying responsibilities and compliance obligations (what the provider does and what the customer does). They also have differing best-practice frameworks and even names for the same conceptual cloud objects.
Overstretched security teams now need to add cloud platform skills. Consider the specific cybersecurity skills that are platform-specific, including forensics, penetration testing, identity/access management, and audit review.
The simplest path to consistency in these situations is to fall back to the lowest common denominator of controls. Unfortunately, this also often means losing functionality and operational granularity.
It’s simple: the more technology you have on the Internet, the more things that can be attacked. Multi-cloud also provides more chances for cloud resource sprawl of forgotten or unmanaged cloud instances holding critical data or authentication keys.
Over the years, as we’ve reported in our Application Protection Reports, there are plenty of cloud data leakages occurring. Most cloud security incidents revolve around misconfigured cloud-based storage, APIs, or login credentials.
More resources online also means a larger operational footprint to manage with more moving parts, more communication pathways, and more flowing processes to secure. Concurrency and visibility lag can also become a problem, as change alerts may be incomplete or delayed in a large, active multi-cloud operation. Knowing the true configuration state of all your environments, from development through test to production is critical, especially when spread across cloud platforms.
The good news is that, as with all cloud platforms (not counting private clouds), organizations don’t need to worry about securing back-end infrastructure. Even using multi-cloud, the providers are at least responsible for the physical security, electricity, HVAC, and network foundation. Cloud providers also always securely administer the virtualization software and hardware.
No matter how many cloud platforms are managed, organizations are still responsible for the security, compliance, and governance of their own data. Even in the cloud shared-responsibility model, an organization will be named first in that newspaper story, class action lawsuit, or compliance judgment.
IT operational proficiency is the root of many cybersecurity problems, cloud or otherwise. Therefore, multi-cloud security begins with consistent, scalable processes for key cloud platform practices such as deployment, access control, and monitoring. This also means having defined strategic goals for what an organization will accomplish, like resilience versus cost savings. Security objectives should be based on these strategic goals, as there is no agreed upon measure for secure enough.
Just as in regular cybersecurity, multi-cloud governance is at least as important as technology. Governance works to ensure that an organization has adequate controls and roles in place. Some of the basic key governance problems get exponentially more complex in a multi-cloud.
Governance is defined by policy and the processes it oversees. And conversely, lack of proper policy and process is where human error, such as configuration mistakes, leads to gaps in coverage, which can lead to data breaches, outages, and compliance failures.
At the highest level, organizations should have a data and operational usage policy that then flows down to a unified set of policies proscribing how to handle all provisioned cloud services. These policies set security standards for how to handle each data classification, which can then be applied to the specific cloud platforms.
Given that the attack surface expands with each cloud platform used, it is even more vital to clearly know the source of truth and recheck it often. This means that a vital operational and security process for a reliable and complete inventory must be a regular practice. Standardization has huge security benefits, as there are fewer configurations to track and review. Organizations also need to detect for configuration driftConfiguration drift detection: A tool used to measure how close a running system matches the defined configuration policy. to verify that what is running live matches the defined policy configuration. Additionally, organizations should also be aware of what cloud objects are interacting with external services, such as APIs, and how that connection is managed. Unfortunately, since many organizations find themselves retrofitting an existing but unplanned multi-cloud configuration, this step becomes even more crucial.
The good news is that in the cloud, infrastructure is defined by configuration scripts, so counting and reviewing cloud objects doesn’t have to be done physically by humans in a server room with a clipboard. Those scripts can just be downloaded and scanned. The bad news is that a multi-cloud setup contains a lot of details, in many differing formats. This is where automated analysis tools can be leveraged to do the interpretation and correlation for you. Two common tools are Cloud Workload Protection Platforms (CWPP)Cloud Workload Protection Platform (CWPP): Scans cloud workloads, such as servers, for vulnerabilities, weak configurations, and access control lists. Enables observability across multiple cloud configurations in a single tool. Can use software agents. for reviewing server security configurations on cloud systems, and Cloud Security Posture Management (CSPM)Cloud security posture management (CSPM): A tool that scans cloud objects and systems to expose deviations from a defined security standard and misconfigurations. for inventory and compliance testing. Another tool, Cloud-Native Application Protection Platform (CNAPP)Cloud-Native Application Protection Platform (CNAPP): A cloud security scanning automated tool that look for vulnerabilities and compliance divergences in cloud objects, even in hybrid or multi-cloud configurations. Combines the capabilities of CWPP and CSPM tools. combines the functionality of CWPP and CSPM. There are other specialized tools for reviewing the security of CaaS configurations such as Kubernetes Security Posture Management (KSPM)Kubernetes Security Posture Management (KSPM): An automated security scanning tool specialized in examining Kubernetes container environments such as excessive access permissions, container misconfigurations, and vulnerable imported third-party resources.. The goal of all these tools, especially in a multi-cloud environment, is to bring visibility and control into a single management dashboard.
With infrastructure as code, cloud work at scale can be driven by automation and orchestrationOrchestration: Refers to a series of automation scripts that run multiple processes, which wait and react to events and conditions.. In fact, the power and ease of automation is a motivation for many organizations to move to the cloud. To begin with, the security strategy will need to ensure that the authentication keys that automation systems use are well protected. More cloud platforms means more keys, which means more opportunities for leaks and misconfigurations.
Automation systems are written as scripts, which exist as code. Therefore, with those automated cloud scanning tools, you can get ahead of problems with vulnerability scans of that cloud infrastructure code for proposed changes beforehand. After the fact, automation can perform drift detection and then automatically freeze and rebuild deviating systems on the fly. This means that even if a system is compromised, it won’t remain online and available to attackers for long.
There’s no getting away from the fact that organizations need to manage access control for cloud platforms. This starts with the system administrators, includes employees and contractors, and extends all the way to customers and users logging into the applications. Every cloud object should make use of this access management system, including containers and microservices, in a zero trust manner.
Keeping with being consistent, it’s best for each accessing role to have one login across all cloud platforms in the multi-cloud. This role should be managed with least privilege, monitored, and strongly authenticated. For service and operator accounts, secure management methods are also a way to improve access control.
Infrastructure as code and automation can help with this. Cloud identity and entitlement management (CIEM)Cloud identity and entitlement management (CIEM): Tools that provide oversight and control over the many combinations of identities and permissions on cloud platforms. tools can provide oversight and control over those many combinations of identities and permissions on cloud platforms.
While cloud providers handle the hardware and base infrastructure, what organizations need to secure will be on based on the cloud services and deployment models used in multi-cloud.
Multi-Cloud SaaS Security
For SaaS deployments, the primary concern is access control and bot filtering for logins and APIs. There are good tools available, such as web application and API protection (WAAP) services. Don’t forget potential integration connections, since many applications interlink with other applications via APIs. All external connections need to be managed to ensure that confidential data doesn’t leak and unauthorized commands don’t get injected.
Multi-Cloud PaaS Security
In addition to SaaS controls, cloud platforms also require multi-cloud PaaS security. At this level of developing applications, code security and business logic security are important. Tools here include analysis of code, packages, and software libraries.
Organizations also need to consider the security of the application deployment processes. This means vulnerability and image scanning before deployment to look for unprotected service ports or embedded unencrypted keys. Containers and functions also need to be securely orchestrated so they can be updated, removed, and scaled appropriately. Many of these applications use platform services outside of the application itself, such as software-defined networking, data storage, code/container storage, and database and messaging services. These also need to be reviewed for security. Don’t forget that, in the multi-cloud world, each of these platforms will likely have different controls and characteristics. All these systems, as well as managing orchestrating and automation tools, should be strongly authenticated, have tight authorization, and be encrypted from eavesdropping.
If applications are being deployed to multiple clouds, then mechanisms need to be in place to ensure that the same authorized version is running in all the environments. This means having secure and verifiable multi-cloud deployment processes in place.
Multi-Cloud IaaS Security
At the infrastructure level, everything previously discussed needs to be implemented, and then operating system hardening and patching needs to be included. And like the other tiers, how each cloud provider runs virtualized systems and how operating system images are configured can vary quite a bit. A higher level of networking service configuration will be done here, entailing additional management of network access control.
Multi-cloud computing comes with new security challenges. However, there are enough benefits that organizations either already have multi-clouds or are heading toward multi-cloud environments. One thing to remember is to understand the business drivers behind the multi-cloud choice. From these, organizations can look at security choices regarding specific features, better pricing, gaining vendor independence, increasing resilience, improving geocentric connectivity, and achieving data sovereignty.