Securing Applications in a Multicloud World
There’s a familiar quip that the cloud is just someone else's computer. Although that’s true — to a certain extent — it doesn't convey how many options software architects have when using “someone else’s computer.” Since the early 2000s, the number of cloud computing providers and services has exponentially increased, and developers use them extensively. As a result, today we find ourselves deploying and managing distributed applications across multiple clouds.
The agility of distributed architectures
Distributed architectures provide added agility, as many experts have shown. Architects Martin Fowler and James Lewis wrote a great resource on the topic, which many consider definitive. I also sat down with one of IBM's senior architects to discuss the benefits of dividing a monolithic application into microservices — even while the application is still in production.
That same agility is one of the reasons why developers make use of multiple clouds. Different providers offer different locations, features, and solutions. Choosing the right one for each workload helps make the most of developers' already-stretched time. Shadow IT and acquisitions also contribute to a multicloud environment. Regardless of which path developers take, distributed architectures across multiple clouds have become the norm for most enterprises.
The rewards and challenges of multicloud architectures
As we learned from the movie “Spaceballs,” "... there's two sides to every Schwartz," and this architectural choice is no different. Although they provide agility and flexibility, distributed multicloud architectures can pose challenges to application security. The multitude of available environments, instances, and security needs can lead to an unmanageable, ad hoc set of solutions.
Three challenges in securing applications
Specifically, there are three challenges most enterprises face when trying to secure their applications:
Security needs vary across components
Security capabilities vary across clouds
Security should be integrated into development and QA workflows
Security needs vary across components
A typical application consists of a UI, static content (like images, JavaScript, and CSS), and API calls. Everything should have denial of service (DoS) protection. But an API, like an inventory search or authentication endpoint, needs additional protection via a web application firewall (WAF) and protection against malformed requests.
Similarly, if we want to protect our static content from scraping, those endpoints will need bot protection. Ultimately, each endpoint demands its own set of security controls, resulting in a large number of solutions to deploy and manage.
Security capabilities vary across clouds
Most cloud providers offer virtual equivalents of security components that work in their respective environments. But because they’re specific to each cloud, you can’t reuse the same components in different environments — for example, you can’t use your AWS WAF to protect a workload in Azure. As a result, using multiple clouds usually means duplicating security controls in each cloud, and often in each region. This again leads to sprawl in the number of security solutions that need to be deployed and maintained.
Security should be integrated into development and QA workflows
Dev and QA environments should mirror production closely while remaining practical. This includes mirroring security controls. In practice, though, these environments rarely use the same set of solutions, instead using only a small subset of controls that are rarely synced with what’s in production because of the effort required. As a result, testing is less accurate and can miss issues that arise in the production environment.
A common thread: management needed
All three of these challenges cause security sprawl, leading to headaches and inefficiencies. The most obvious issue is management. Security solutions all require some degree of management to stay effective against ever-changing threats. The more solutions you have, the more management you need. In addition, similar solutions vary across clouds, so each solution is operated and configured differently.
SecOps is also more challenging in a heterogenous security environment. It’s often impossible to correlate logs, alerts, and insights across solutions. That leaves a gap in infosec’s visibility across the entire application, hindering the ability to fight attacks.
Finally, deploying security with application infrastructure increases the time and effort needed to roll out new virtual private clouds (VPCs). For example, if you deploy security controls in each cloud, you have to duplicate all those controls before putting the service in production.
Security controls duplicated in each cloud
Security controls duplicated in each cloud
Securing multicloud infrastructures
The obvious solution is to decouple application infrastructure from security. After all, it’s reasonable to want (and need) more computing power and storage as traffic increases. But security components demand the opposite approach. They should grow to handle the additional capacity and regions without having to deploy additional instances.
Additional security components complicate operations unnecessarily. This may seem like an intractable problem, but there is a solution: adding an edge layer to the architecture.
Move components to the edge
Consider the types of security solutions needed to protect different application components. They commonly include DoS protection, WAFs, JavaScript scanning, bot management, fraud detection, upload scanning, API validation, and access control. When we move those components to the edge, we efficiently decouple them from our infrastructure. Moving the components to the edge simply means deploying these on an edge platform, instead of centralizing multiple instances in a cloud region.
Unified security controls at the edge
Unified security controls at the edge
When multicloud security controls are implemented on an edge platform, we can add regions, VPCs, or new cloud providers without having to scope and redeploy the security layer in the new environment — reducing the time and effort required to increase capacity. This also offers a unified view of security across all our application components.
For example, behaviors that trigger multiple security controls can be traced to an individual client. That’s crucial information for calculating a request’s risk profile. It’s nearly impossible to identify malicious clients and implement controls to mitigate them when manually correlating events across a sprawling set of security solutions. This hurts your security posture: You’re not acting on the available signals.
Overcoming challenges to security implementation
Now you know the challenges of implementing security controls across multicloud architectures, and understand a little about how to overcome them. We offer solutions that will work for you: Akamai Guardicore Segmentation provides a better way to segment and secure your cloud and data centers, and Akamai App & API Protector gives you tailored defenses for your websites, applications, and APIs.
Learn more
If you're interested in hearing more, check out our recent webinar for a deeper dive into multicloud security trends and best practices. The next in the series, focused on performance, is also now available. Stay tuned as the series continues!
