Architecting and building a new platform that is secure by design.
TL;DR: Auth0 replatformed our private cloud offering into a multi-cloud Kubernetes architecture. This large architectural change brings with it new threats and new security challenges. We took the opportunity to design and integrate security into the platform from the start, as opposed to "bolting it on" at the end.
In this post, we'll discuss how we approached securely replatforming the Auth0 Identity Platform into a large, multi-cloud architecture. We'll walk through the risks that most concern Auth0's Security team and the threats that could result in those risks becoming real, tangible, negative outcomes. After that, we'll discuss the challenges our team encountered while addressing those threats in a multi-cloud environment alongside the principles we applied to address them. Finally, we'll review the controls Auth0 put in place to mitigate the identified threats.
If you haven't read the previous posts yet, A Technical Primer of Auth0's New Private Cloud Platform and The Architect's View of Auth0's New Private Cloud Platform, I encourage you to check them out first. They provide foundational knowledge and context which will help you better understand this post.
Understanding What Risks Affect Us
At the highest level, Auth0's Security team is responsible for identifying, assessing, and mitigating risks to our business and, in effect, our customers. It's our job to reduce the impact and/or likelihood of undesirable business outcomes caused by security events. Specifically, we're interested in mitigating security and privacy risks, such as those involving:
- Product/platform compromises: bad actors gaining control of a product or platform component
- Customer or Auth0 data loss: unintended deletion or unauthorized access to customer or Auth0 data
- Service disruptions and outages: disrupting the Auth0 service and causing an outage for our customers
There are more risks than the three listed above and more nuance as well, but we'll use them for brevity. These high-level risks help us enumerate our list of threats.
Identifying How the Platform Will be Attacked
This new Kubernetes-native, multi-cloud architecture is large and complex, which makes it challenging to secure. Our approach is to start by enumerating the areas of the architecture most likely to be targeted and how they can be attacked. This process, called threat modeling, helps us determine where to focus our resources and implement countermeasures (also known as security controls). These "areas to focus on," or threats, are circumstances or events that could cause one of the risks highlighted above to occur.
The threat modeling process results in a long list of threats of varying severity. For the purposes of this post, we'll focus on a short list of significant ones:
- Employee account takeover: an attacker compromises or gains access to employee credentials and utilizes them to access Auth0 systems
- Malicious insiders: an internal employee abuses existing authorized access to Auth0 systems
- Service or application compromise: an attacker gains control of an Auth0 product or platform service, third-party managed service, or a cloud provider service
- Software supply chain compromise: an attacker tampers with or exploits misconfigurations/vulnerabilities in software dependencies used by the Auth0 product or platform
This list of threats informs what secure design patterns and security controls we deploy into the platform's architecture.
Securing Multi-Cloud Architecture is Hard
Now that we have defined the list of threats we're protecting against (the "what"), we can start determining the design changes, secure design patterns, and security controls that will address those threats (the "how"). But first, before jumping into that, let's take a step back and understand the challenges with securing a platform that utilizes multiple cloud providers. In Auth0's case, we use both Amazon Web Services (AWS) and Microsoft Azure.
Top comments (0)