Three Critical Considerations for Securing Highly Distributed Applicat…

The meteoric rise of AI, IoT, automation and streaming video services are driving a massive change in how organizations are deploying and supporting apps and their data. To better support these new technologies, apps and data are increasingly being distributed across heterogenous multi-cloud and edge environments, especially in industries such as financial services, telecom, e-commerce, healthcare and manufacturing. Gartner estimates that over the next several years, three quarters of enterprise-generated data will be created and processed outside traditional centralized data centers. The landscape will continue to shift rapidly through 2025.

However, due to a variety of factors, these highly distributed deployments are very difficult to secure. The bottom line is simple: While there are many mature technologies and proven approaches for securing apps located in individual on-prem environments or single public clouds, there are few solutions or established approaches to protecting apps spread across multiple clouds or apps located at the edge. Put another way, the growing distribution of apps across multi-cloud and edge environments is a new trend that’s emerging quickly, and the industry hasn’t yet developed adequate capabilities and effective methods to secure these distributed deployments and support this massive transition.

The emerging technologies that are driving the shift to multiple clouds and the edge are also changing the way apps and data are accessed. In the past, apps and data were mostly only accessed by users and employees. Now, as a result of AI and IoT, apps must access other apps or data without humans involved in the verification process. While it is straightforward to provide secure user and employee access to applications, it is much more complicated to secure app-to-app or app-to-data access.

There are three key issues that need to be addressed to secure apps and data in a highly distributed environment: bootstrapping universal identity, authentication and authorization, and secrets management. While there are a number of tools in the public cloud that address some of these concerns individually, they aren’t integrated well with one another and don’t work for multi-cloud deployments. And there are basically no tools for the edge that address any of these concerns, let alone all three.

Bootstrap of universal identity

To secure apps and data in either multi-cloud or edge settings, an organization needs cryptographically secure and unforgeable PKI-based identities for both applications as well as infrastructure. To achieve this, you need to address a core challenge: bootstrapping of universal identity.

When a child is born, they receive a birth certificate that establishes their identity. This first step is a sort of “bootstrap,” and from that initial birth certificate, the person can earn additional proofs of identity, such as a driver’s license. Whenever you launch an app or microservice, you also need to bootstrap a unique identity. As in the human example, that bootstrap identity will be used to gain additional identification credentials for the app or microservice down the road, which will be used to allow them to communicate with or access data from other apps.

When it comes to highly distributed environments, it’s difficult for apps to communicate with one another across multiple clouds or edge locations. Due to siloed identities and security policies, a traditional bootstrap identity of an app in AWS might not allow it to communicate with apps in Azure. For these distributed apps to function properly, they must be bootstrapped with universal identities that allow them to communicate across all these disparate environments.

Addressing this challenge requires identifying, securing, and leveraging critical phases in application deployment pipelines and building the underlying infrastructure to enable secure bootstrapping of universal identities. For example, in case of Kubernetes, leveraging a securely configured mutating webhook can insert the bootstrapping cryptographic material – similar to the birth record from the hospital for a child – into the launched application. Since applications vary in nature, handling of the bootstrap material and exchanging it for identity credentials can be delegated to a common sidecar. Applications can then offload identity-related heavy lifting to this sidecar without requiring many changes in the applications themselves.

Decoupling authentication and authorization from the bootstrap identity

When an app tries to access another app, the two must securely verify each other’s identity. This process is known as authentication. Then, once the app making the initial request is proven authentic (i.e., its stated identity is proven to be its real identity), the second app must determine if that app is permitted to access the resource it is requesting. This process is authorization.

As noted above with identity bootstrapping, siloed security policies have made it more difficult to authenticate and authorize apps that span multi-cloud or edge environments. Moreover, highly distributed deployments contain all sorts of different apps that rely on a wide range of protocols (such as gRPC, REST, IPSec and BGP). You’ll need to support authentication and authorization for apps running on any protocol, rather than only supporting certain protocols. To achieve this and deliver maximum flexibility, you should allow decoupling of both authentication and authorization from the bootstrap identity.

By decoupling authentication from the bootstrap identity, organizations gain the ability to derive different types of identity credentials like JWT tokens, API Keys, PKI certificates etc. for different communication protocols or peers. And by decoupling authorization from authentication and therefore the bootstrapped identity, you can create a wider set of authorization policies that work at different stages of request processing. Good authorization policies should always be evolving. The decoupling approach is the only way to easily customize or tweak these authorization policies at any time.

A blindfold approach to secrets management system

Apps use all sorts of secrets (such as token, passwords and TLS certificates). Many organizations take a straightforward approach and rely on a centralized vault to store all these secrets. These vaults can only be accessed via an authorized request, and the contents of the vault are typically encrypted with a single encryption key. Using a centralized vault seems like a particularly useful way to simplify secrets management for highly distributed environments. But there’s an enormous drawback: if the vault is breached, all your organization’s secrets will be vulnerable at once.

A better approach is to take a decentralized approach to secrets management and leverage technologies that make use of cryptographic blinding. This method allows the owner of a secret to encrypt it in such a way that the secret is never revealed in clear to any potentially risky third party (including the decryption server). The secret also won’t be kept in a central decryption server, which provides additional protection and also simplifies server design. Secrets can be unlocked using a similar security sidecar as described above for bootstrapping identity.

#Security may be the biggest challenge for companies to support distributed applications as they move toward multi-cloud and edge deployments. #respectdata Click to Tweet