确保Auth0的新私有云平台的安全[ Auth0文件在几分钟内实现身份验证](https://auth0.com/do

[

Auth0文件

在几分钟内实现身份验证](auth0.com/docs)

**TL;DR:**Auth0将我们的私有云产品重新平台化为多云的Kubernetes架构。这种大型架构变化带来了新的威胁和新的安全挑战。我们利用这个机会，从一开始就把安全设计和整合到平台中，而不是在最后才 "栓上"。

在这篇文章中，我们将讨论我们如何将Auth0身份认证平台安全地复制到一个大型的多云架构中。我们将介绍Auth0安全团队最关注的风险，以及可能导致这些风险成为真实、有形、负面结果的威胁。之后，我们将讨论我们的团队在多云环境中应对这些威胁时所遇到的挑战，以及我们为解决这些问题所采用的原则。最后，我们将回顾Auth0为减轻已确定的威胁所采取的控制措施。

如果你还没有读过之前的文章《Auth0新私有云平台的技术入门》和《Auth0新私有云平台的架构师观点》，我鼓励你先看看。它们提供了基础知识和背景，将帮助你更好地理解这篇文章。

了解哪些风险会影响我们

在最高层面上，Auth0的安全团队负责识别、评估和减轻我们业务的风险，实际上也就是我们的客户。我们的工作是减少由安全事件引起的不良业务结果的影响和/或可能性。具体来说，我们对减轻安全和隐私风险感兴趣，例如那些涉及。

产品/平台妥协：坏人获得产品或平台组件的控制权
客户或Auth0数据丢失：对客户或Auth0数据的非故意删除或未经授权的访问
服务破坏和中断：破坏Auth0的服务，导致我们的客户中断服务

除了上面列出的三种风险，还有更多的细微差别，但为了简洁起见，我们将使用这些风险。这些高层次的风险有助于我们列举出我们的威胁清单。

识别平台将如何被攻击

这种新的Kubernetes原生的多云架构是庞大而复杂的，这使得它在安全方面具有挑战性。我们的方法是，首先列举架构中最有可能被攻击的领域，以及如何攻击这些领域。这个过程被称为威胁建模，帮助我们确定在哪里集中资源和实施对策（也称为安全控制）。这些 "需要关注的领域"，或称威胁，是可能导致上述强调的风险之一发生的情况或事件。

Platform

威胁建模过程产生了一长串严重程度不同的威胁清单。在这篇文章中，我们将重点讨论一个重要威胁的简短清单。

雇员账户接管：攻击者破坏或获得雇员的证书，并利用它们来访问Auth0系统
恶意内部人员：内部员工滥用现有授权访问Auth0系统
服务或应用程序受损：攻击者获得对Auth0产品或平台服务、第三方管理服务或云提供商服务的控制权
软件供应链破坏：攻击者篡改或利用Auth0产品或平台使用的软件依赖性中的错误配置/漏洞。

这份威胁清单说明了我们在平台架构中部署了哪些安全设计模式和安全控制。

确保多云架构的安全是困难的

现在我们已经定义了我们要保护的威胁清单（"什么"），我们可以开始确定设计变更、安全设计模式和安全控制，以应对这些威胁（"如何"）。但首先，在进入这个问题之前，让我们退后一步，了解保护一个使用多个云供应商的平台的挑战。在Auth0的案例中，我们同时使用亚马逊网络服务（AWS）和微软Azure。

复杂性增加

使用多个云供应商会增加架构的整体复杂性。每个云供应商都有类似的一般能力，如计算、网络、存储和记录。然而，每个云提供商以他们自己的方式实现这些能力。我们最终得到的是同一核心能力的多种实现方式，如虚拟机或blob存储。云供应商之间的这些细微差别带来了复杂的问题，对安全来说是个挑战。

让我们用一个例子来说明这些差异。Auth0产品需要blob存储，所以我们来比较AWS S3和Azure存储账户，只关注不同的访问方法。

AWS S3 and Azure

另一个例子是AWS安全组（SG）与Azure网络安全组（NSG）以及各自如何处理规则评估。AWS SG规则是加法的（即允许所有适用规则的超集），而Azure NSG规则被分配了一个优先值，并按照这个顺序进行评估。这些只是我们在新平台的架构设计中考虑到的AWS和Azure之间许多差异的两个例子。

更大的攻击面

使用多个云意味着有可能为每个云提供商确保多个类似的服务，例如AWS S3和Azure存储账户。上述的复杂性和服务数量的增加导致了更大的攻击面。例如，今天我们需要确保两个云服务提供商（AWS和Azure）的安全，这意味着要确保运行Auth0所需的每一个云特定服务的两套安全。这也意味着我们的检测和响应团队需要摄取和监测多套特定云的日志源，以正确监测和调查这些活动。这是一个需要保护的大面积区域。

跨云连接

同一云内的服务之间的通信是很简单的。我们只需要使用云提供商自己的机制，它应该 "只是工作"。然而，在我们新平台的架构中，有不同的点需要在AWS和Azure之间进行某种形式的通信。例如，网络连接需要在Azure存在点（PoPs）和Auth0 Central（运行于AWS）之间建立。在这种情况下，我们没有能力使用任何一个云的PrivateLink服务（这将是首选）。在另一个例子中，Azure Spaces需要将使用指标上传到Auth0 Central（AWS）。在单云架构中，我们可以简单地使用配置有适当角色分配的Azure RBAC。然而，在这种情况下，这是不可能的；Azure Kubernetes服务（AKS）集群/od将需要使用AWS S3认证方法进行认证。

应对多云挑战

到目前为止，我们回顾了Auth0最担心的风险，列举了一个简短的威胁清单，以帮助指导我们的安全决策，并讨论了Auth0在保护多云架构方面遇到的一些挑战。接下来，让我们走过我们应用的原则，以确定我们如何在这些多云挑战的背景下解决这些威胁。

通过基于风险和以威胁为中心的视角来看待所有与安全相关的决策。

这意味着所有的安全设计决策或实施的安全控制都与我们在前面的章节中列举的风险和威胁直接相关。确定优先次序是关键，使用这个镜头可以影响我们需要将可用的资源花在哪里，以及哪些对策是最有效的。

应用安全设计原则，并尽早和经常地将安全纳入平台。

Auth0安全团队参与了整个产品生命周期，从构思到设计到构建到运行，最后到废弃。我们大量参与设计和构建阶段的工作。这一点很重要，因为在技术建成之前，最容易进行架构上的改变。

建立明确的、可执行的信任边界。

这些信任边界告知我们如何实施各种应对措施，如访问控制。它们还封装了风险区域，使其更容易管理。例如，我们的开发和生产环境是完全隔离的，相互独立。操作人员不能使用开发访问权来影响生产环境的任何部分。

平衡云原生和云独立的能力。

这是一个棘手的问题，因为每个人都有自己的好处和挑战。云原生能力（如AWS管理的数据库）与云提供商紧密集成，这意味着你将获得这些集成--如GuardDuty或Microsoft Defender--开箱即用。另一方面，云原生服务与他们的云紧密耦合，为AWS和Azure部署它们会增加复杂性和攻击面（正如我们上面所讨论的）。与之相比，云原生能力可以提供单一的模式，并实现更简单的架构，减少攻击面。然而，与云供应商服务的整合往往需要更多的工作或 "胶水 "来把它们缝合在一起。例如，我们的Auth0产品由Kubernetes工作负载组成（与云无关）。我们使用管理的Kubernetes服务（AKS和EKS），而且很容易在两个云中使用相同的服务。这意味着更少的复杂性（即对Auth0产品的一个变化将应用于两个云）和更少的攻击面（即一个服务的安全）。

选择正确的安全功能集

最后，让我们回顾一下Auth0在新平台上实施的各种安全功能，以应对上述威胁和多云挑战。除了我们自己的安全能力外，Auth0还利用了云的责任分担模式。分担责任模式使我们能够专注于保护平台的其他领域，而不是担心底层云服务提供商的基础设施。

云治理

所有Auth0空间、PoPs、中心和控制平面技术栈都被隔离到他们自己的AWS账户或Azure订阅中。这提供了干净和明确的资源隔离，特别是对于单租户空间。我们使用AWS组织来创建基于环境和功能的组织单元（OU）层次结构，并将每个账户添加到一个特定的OU。我们使用Azure管理组为Azure订阅号创建了一个类似的层次结构。我们创建的层次结构能够实现可扩展的、细化的访问控制和策略执行；我们对特定的管理组/OU或空间授予访问权或应用策略（Azure策略和AWS服务控制策略）。对于AWS，我们根据OU条件授予访问权，并将SCP分配给OU。对于Azure，我们将角色和策略分配给特定的管理组。然后，这些访问权限和策略会被目标账户或订阅者继承。

Cloud Governance

身份和访问管理

Auth0是为保证身份安全而建立的，所以我们利用Auth0 + Okta来保证我们平台工具的认证和授权。我们管理所有的云供应商，并使用最低权限的RBAC模型支持应用访问。我们还要求所有操作员访问平台时进行多因素认证（MFA）；这包括云供应商和所有支持的应用程序。运营商需要使用Azure特权身份管理（PIM）--它提供及时的访问--来进行任何管理活动。Azure AD身份保护可识别并阻止任何有风险的Azure租户登录。

网络安全

所有的单租户和多租户空间在逻辑上是相互隔离的，它们之间没有相互联系。这种强大的隔离大大降低了攻击者进入其他空间或PoPs并进一步进行攻击的能力。我们通过使用AWS和Azure PrivateLink从空间向外连接到PoP，进一步限制空间的入站连接。所有流量在传输过程中都使用TLS 1.2+进行加密。这包括所有云服务之间的网络流量，Kubernetes pod-to-pod流量，以及Kubernetes集群-to-cluster流量。对于一些工作负载，我们利用相互TLS（mTLS）。在网络边缘，我们保护基础设施免受DDoS攻击，识别和阻止机器人，执行速率限制，并通过网络应用防火墙（WAF）规则阻止恶意流量。运营商必须使用VPN来访问平台基础设施，为我们的深度防御战略增加了另一层。

Network Security

数据保护

所有数据在静止状态下使用AES-256或更高版本进行加密，并在多个层次（如磁盘、文件、数据库和应用层）进行加密。所有传输中的数据都使用TLS 1.2+进行加密。Auth0使用HashiCorp Vault对平台机密进行加密，并充分利用Azure Key Vault和AWS KMS对云服务中的数据进行加密。

Data Protection

检测和响应

Auth0使用云服务和我们自己的监控工具的组合来监控平台。除了我们自己的工具，我们还利用AWS GuardDuty和Microsoft Defender for Cloud。Auth0为平台使用的所有云服务摄取了大量的AWS和Azure平台的日志。这些日志被摄取到安全数据湖中，并通过定义为代码的检测进行监控。

Detection and Response

Kubernetes安全

在考虑Kubernetes安全时，云原生安全的4C是一个很好的框架。我们在不同的方面负责我们使用的云、我们运行的集群、在这些集群上运行的容器以及在容器内运行的代码的安全。Auth0使用管理的Kubernetes服务Azure Kubernetes Service（AKS）和AWS的Elastic Kubernetes Service（EKS）。Azure和AWS的这些产品具有丰富的安全功能。我们的工作节点符合Kubernetes CIS Level 1基准。集群的访问仅限于操作人员，并使用特定的RBAC角色强制执行最低权限。我们使用Kubernetes NetworkPolicy对象来限制Pod网络的入口和出口到授权来源和目的地。

Kubernetes Security

漏洞管理

我们的构建和部署管道持续扫描我们的集群、容器和代码的漏洞。我们的安全能力包括常规控制：对代码和基础设施即代码进行静态应用安全测试（SAST），对我们的应用和API端点进行动态应用安全测试（DAST），对我们的软件依赖和容器进行软件构成分析（SCA）。云安全态势管理（CSPM）工具可以识别和应对云的错误配置（例如，公开访问的S3桶）。打补丁是一个基本的安全控制；我们不断升级我们的容器和软件依赖。在共同责任模式中，Azure/AWS负责建立升级的节点镜像，而Auth0负责将镜像部署到我们的节点上。我们通过在每个Auth0产品发布周期用最新的镜像重建我们的Kubernetes节点来实现这一目标。

自动化是必须的

我们正在处理的规模使我们无法手动配置所有这些安全功能。为了解决他的挑战，Auth0安全团队创建了一个内部服务，可以自动创建和配置AWS账户和Azure订阅。类似于生产线，当需要新的空间和PoPs时，这项服务使用预定义模板创建AWS账户和Azure订阅，以满足我们严格的安全标准。它可以有效地按需 "戳穿 "完全配置好的新账户/订阅。当不再需要该账户或订阅时，该服务将删除所有资源，撤销所有访问，并使其退役。

不断改进Auth0的安全态势

所有这些工作最终形成了一个更安全、可扩展的平台，继续满足或超越实现ISO 27001/27018、SOC 2、PCI、STAR和HIPAA合规性所需的许多要求。

威胁形势千变万化，不断发展。Auth0安全团队的工作永远不会完成，一个核心原则是持续改进。总是有办法减轻更多的风险，增强我们的安全态势，我们不断研究更多的安全能力，使我们的平台和产品对客户更加安全。

我们正在发布一系列关于我们如何以及为什么重新建立平台的技术文章。这些文章发布后会在本篇文章的底部链接，也可以在我们的博客上找到。如果你有技术问题或对未来文章的想法，请通过Auth0社区与我们联系。(我们的营销团队还告诉我们，如果我们不包括一个与销售部对话的链接，那就是失职，所以这里也有。）

关于Auth0

Auth0身份认证平台是Okta的一个产品单元，采用现代的身份认证方法，使企业能够为任何用户提供对任何应用的安全访问。Auth0是一个高度可定制的平台，开发团队想要多简单就有多简单，需要多灵活就有多灵活。Auth0每月保障数十亿次的登录交易，提供便利、隐私和安全，使客户能够专注于创新。欲了解更多信息，请访问auth0.com。