Multi-cloud is on the rise — 60 percent of organizations are already using multiple clouds. Most are reaping many business benefits from a multi-cloud strategy, such as reduced vendor lock-in, the ability to optimize computing workloads, and even cost reduction. Multi-cloud also empowers developers with more ownership to choose their favorite cloud for deployments.
Although hybrid multi-cloud is the new normal, there are undoubtedly new security implications within this novel paradigm. The most obvious result is an increased surface area for attack. When you’re managing multiple clouds, there’s more room for misconfigurations and more administrative secrets and keys that could be exposed. Inconsistencies between cloud providers could result in broken institutional knowledge, not to mention that cloud-native technologies have varying degrees of default settings — some of which are more locked down than others.
Multi-cloud is becoming an unavoidable reality for most organizations. But, many of the risks associated with multi-cloud can be mitigated. Below is a brainstorm of some strategies to consider as your organization adopts multiple clouds. While not exhaustive, these tips are a starting point for addressing the unique cybersecurity implications of deploying and managing software across various cloud-based environments.
Tip #1: Continually audit your surface area.
The first step of any holistic cybersecurity strategy is to know your surface area. Without a clear depiction of your active workloads and resources and where they’re running across your stack, components could easily be left behind. Forgotten systems or shadow or zombie application program interfaces (APIs) might be outdated and contain unpatched vulnerabilities. It’s also good practice to tag ownership to each resource so that teams know who is in charge of maintaining it. Although still an evolving practice, requesting a Software Bill of Material (SBOM) from cloud-based dependencies is another method to audit your surface area.
Tip #2: Centralize common cloud configurations.
When an engineer goes to deploy code into a given cloud, there are many options to choose from, including region, computing type, size, scalability settings, permissions, and other factors. These fields vary slightly from cloud to cloud and configuring them differs in each cloud graphical user interface (GUI). It’s a good idea to centralize standard cloud configurations for reuse. Building knowledge repositories per cloud makes it easier to deploy code consistently. Even better, codifying configurations as infrastructure-as-code (IaC) can make them more structured for reuse and ensure more consistent policies that enforce access control.
Tip #3: Set guardrails for developers.
CloudOps will want to set common security policies across multiple clouds. For example, you might want to detect suspicious behavior or ensure traffic is not coming from an invalid IP address. Policies should also match developer administrative credentials. Such guardrails could help prevent accidents in the development lifecycle, such as haphazardly opening an EC2 instance or load balancer. Implementing real-time scanning for new code bases and container images, as well as checking policies in real time, can help ensure multi-cloud governance. Open-source tools such as Cloud Custodian or Open Policy Agent are popular options for implementing cloud-native policy-as-code.
Tip #4: Store and share secrets safely.
In 2020, GitGuardian found more than 2 million secrets exposed on GitHub. With more clouds come more secrets and keys to manage infrastructure, which, if leaked, could be used by hackers to escalate their permissions into your walled gardens. Thus, it’s important to ensure these administrative credentials are never revealed or inserted within public code repositories: Everything from API keys to cloud environments should be obfuscated. Furthermore, multiple authentications and authorization checks should be implemented to avoid hasty connections. OAuth and OpenID Connect, for example, help validate user identity, or SPIFFE/SPIRE helps initiate secure service-to-service connections.
Tip #5: Lock down insecure default states.
Don’t assume every platform handles security the same way — certain functions, such as multi-factor authentication, may be turned on by default in one environment but left off in another. Therefore, it’s a best practice to audit the default security schemes when adopting new cloud technologies. Open-source, cloud-native technologies that work between clouds may have insecure states as well. For example, the cloud-native community notes that Kubernetes, the popular container orchestrator, has default states that are “too open.” Applying a zero-trust approach, even for internal testing, can pay dividends in ensuring a more secure footprint.
Tip #6: Keep an eye on cloud vulnerabilities and exploits.
It’s a good practice to keep current with common vulnerabilities and exposures (CVEs), and even implement regular automated scanning of runtime environments. But it’s not only the code you host that might contain vulnerabilities — exploits have been found within major cloud service providers as well. For example, Log4Shell produced vulnerabilities in AWS that recently made it prone to privilege escalation. Or, in 2021, Microsoft Azure’s central database exposed a massive amount of customer records. Where sensitive data is concerned, it’s a good idea to pay special attention to highly valuable ingress and egress ports.
Tip # 7: Practice multi-cloud observability.
Observability is an evolution of application monitoring that involves logs, metrics, and traces to measure a system’s state and the data it creates. It’s been a much-hyped trend in recent years — and for a good reason. Applied to cybersecurity, an investment into observability can help reduce false positives and decrease the mean time to resolutions. These points can then be used to discover performance bottlenecks and the root causes of incidents. Improving how an organization responds to issues (and practicing this response process) can only aid a multi-cloud strategy.
Multiple clouds multiply the security response.
Adopting multiple clouds can multiply success, yet it also multiplies the risk potential. Access control and privilege issues remain a common concern for connected software, and organizations must take care to retain tight cloud service configurations. As investment into abstracted deployment processes increases, guardrails must be adopted to ensure these abstractions aren’t putting an organization at risk.
A defense-in-depth posture utilizes many layers to protect a digital system. In addition to the abovementioned concerns, general cybersecurity guidelines apply just as well to hardening multi-cloud adoptions. These include best practices like planning for backup and recovery, following common cybersecurity frameworks, and always adopting the rule of least privilege. From the onset, all these practices may seem overwhelming, but don’t let analysis paralysis set in — it’s good to start tackling things one at a time.
Want more cybersecurity insights? Visit the Cybersecurity channel:
