【SaaS架构】SaaS镜头-架构支柱-安全支柱之基础设施保护

安全支柱包括帮助保护信息、系统和资产的能力，同时通过风险评估和缓解策略实现业务价值。

设计计原则

在云中，有许多原则可以帮助您加强系统安全性。

定义

云安全有五个最佳实践领域：

• 身份和访问管理
• 侦探控件
• 基础设施保护
• 数据保护
• 事件响应

多租户为您的SaaS架构增加了一层额外的考虑因素。使用SaaS，您的用户现在可以在给定租户的上下文中访问共享环境。必须在应用程序体系结构的所有层中捕获和传递此上下文，并在确保环境的总体占地面积方面发挥基本作用。

从安全角度来看，您需要了解租赁是如何引入您的环境的，以及如何使用它来保护租户资源。总的来说，您需要确保每个租户都有一个谨慎约束的体验，防止他们访问任何其他租户的资源。

 

最佳实践

话题

• 身份和访问管理
• 检测控制
• 基础设施保护
• 数据保护
• 事件响应

基础设施保护

SaaS SEC 2：您如何确保租户资源免受跨租户访问？

租户隔离是每个SaaS提供商必须解决的基本问题之一。随着独立软件供应商（ISV）转向SaaS并采用共享基础架构模型以实现成本和运营效率，他们还面临着确定其多租户环境如何确保租户无法访问另一租户资源的挑战。对于SaaS业务来说，以任何形式跨越这一边界都将是一个重大且可能无法恢复的事件。

尽管租户隔离的需求被视为SaaS提供商的基本需求，但实现这种隔离的策略和方法并不普遍。有很多因素可以影响租户隔离在任何SaaS环境中的实现方式。域、遵从性、部署模型和AWS服务的选择都为租户隔离带来了自己独特的考虑因素。

隔离心态

在概念层面，许多SaaS提供商都同意保护和隔离租户资源的重要性和价值。然而，当您深入了解实施隔离策略的细节时，您通常会发现，每个SaaS ISV都有自己的隔离定义。

鉴于这些不同的观点，我们在下面概述了一些原则，这些原则将有助于指导租户隔离的整体价值体系。每个SaaS提供商都应该建立一套清晰的高级隔离要求，以指导其团队定义其SaaS环境的隔离足迹。以下是通常形成整个SaaS租户隔离模型的一些关键原则：

隔离不是可选的–隔离是SaaS的一个基本要素，以多租户模式提供解决方案的每个系统都应确保其系统采取措施确保租户资源被隔离。

身份验证和授权不等于隔离–虽然您可以通过身份验证和权限控制对SaaS环境的访问，但超越登录屏幕或API的入口并不意味着您已经实现了隔离。这只是隔离难题的一部分，单靠它本身是不够的。

隔离执行不应留给服务开发人员——尽管开发人员永远不会引入可能违反隔离的代码，但期望他们永远不会无意中跨越租户边界是不现实的。为了缓解这种情况，应该通过一些共享机制来控制对资源的访问范围，该机制负责应用隔离规则（在开发人员的视野之外）。

如果没有现成的隔离解决方案，您可能必须自己构建它——有许多安全机制，如AWS身份和访问管理（IAM），可以帮助您简化租户隔离的路径。将这些工具与更广泛的安全方案相结合，有助于简化隔离过程。。然而，在某些情况下，您的隔离模型可能没有通过相应的工具或技术直接解决。没有一个明确的解决方案不应该是降低隔离要求的机会，即使这意味着要建立自己的解决方案。

隔离不是资源级别的构造——在多租户和隔离的世界中，有些人会将隔离视为在具体基础设施资源之间划出硬边界的一种方式。这通常转化为隔离模型，在该模型中，您可能为每个租户拥有单独的数据库、计算实例、帐户或虚拟私有云（VPC）。虽然这些是常见的隔离形式，但并不是隔离租户的唯一方式。即使在实际上共享资源的场景中，特别是在共享资源的环境中，也有实现隔离的方法。在这个共享资源模型中，隔离可以是由运行时应用的策略强制执行的逻辑构造。这里的关键点是，隔离不应等同于拥有孤立的资源。

域可能会施加特定的隔离要求——虽然实现租户隔离的方法很多，但给定域的现实可能会施加限制，需要特定的隔离风格。例如，一些高合规性行业可能要求每个租户都有自己的数据库。在这些情况下，共享的、基于政策的隔离方法可能不够。

核心隔离概念

隔离的部分挑战是租户隔离有多种定义。对一些人来说，隔离几乎是一种业务结构，他们认为整个客户都需要自己的环境。对于其他人来说，隔离更多的是一种架构构造，它覆盖了多租户环境的服务和构造。以下各节将探讨不同类型的隔离，并将特定术语与不同的隔离结构相关联。

 

筒仓隔离（Silo Isolation）

尽管SaaS提供商通常专注于共享资源的价值，但在某些情况下，SaaS提供商可能会选择将其部分（或全部）租户部署在一个模型中，每个租户都在运行一个完全孤立的资源堆栈。有人会说，这种全栈模型并不代表SaaS环境。然而，如果您已经用共享身份、入职、计量、度量、部署、分析和运营来围绕这些独立的堆栈，那么这是一种有效的SaaS变体，它以规模经济和运营效率换取法规遵从性、业务或域考虑。使用这种方法，隔离是一种跨整个客户堆栈的端到端构造。图16中的图表提供了这种隔离视图的概念视图。

图16：筒仓隔离模型

此图突出显示了孤立部署模型的基本占地面积。用于运行这些堆栈的技术在这里大多无关紧要。这可以是一个整体，可以是无服务器的，也可以是各种应用程序架构模型的任意组合。关键的概念是获取租户拥有的任何堆栈，并用一些构造将其包围，以封装该堆栈的所有活动部分。这成为隔离的边界。只要您能够防止租户逃离其完全封装的环境，就已经实现了隔离。

通常，这种隔离模型的实施要简单得多。通常有定义良好的构造，使您能够实现健壮的隔离模型。虽然该模型对SaaS环境的成本和敏捷性目标提出了一些实际挑战，但它对那些有非常严格隔离要求的人来说可能很有吸引力。

筒仓模型优点和缺点

每个SaaS环境和业务领域都有自己独特的需求集，这可能会使思洛存储器更适合。然而，如果您正朝着这个方向倾斜，您肯定希望考虑到与筒仓模型相关的一些挑战和开销。如果您正在探索SaaS解决方案的筒仓模型，则需要考虑以下利弊：

优点

• 支持具有挑战性的法规遵从性模型–一些SaaS提供商正在向实施严格隔离要求的受监管环境销售产品。筒仓模型为这些ISV提供了一个选项，使他们能够向部分或所有租户提供在专用模型中部署的选项。
• 无噪音邻居问题–尽管所有SaaS提供商都应尝试限制噪音邻居条件的影响，但一些客户仍会对使用系统的其他租户的活动影响其工作负载的可能性表示保留。筒仓模型通过提供一个专用环境来解决这一问题，该环境不可能出现嘈杂的邻居场景。
• 租户成本跟踪–SaaS提供商通常高度关注了解每个租户如何影响其基础设施成本。在某些SaaS模型中，计算每个租户的成本可能是一项挑战。然而，筒仓模型的粗粒度特性为您提供了一种更简单的方法来捕获和关联每个租户的基础设施成本。
• 减少影响范围–当SaaS解决方案中可能出现停机或事件时，筒仓模型通常会减少您的风险敞口。由于每个SaaS提供商都在其自己的环境中运行，因此在给定租户的环境中发生的任何故障都可能受限于该环境。虽然一个租户可能会遇到停机，但该错误不会在使用系统的其他租户之间级联。

缺点

• 扩展问题–可以调配的帐户数量有限制。此限制可能会阻止您选择基于帐户的模型。还有一个普遍的问题是，快速增长的客户数量可能会破坏您的SaaS环境的管理和运营体验。例如，每个租户拥有20个单独的账户可能是可以管理的。然而，如果您有1000个租户，那么这个数字可能会开始影响运营效率和灵活性。
• 成本–由于每个租户都在自己的环境中运行，传统上与SaaS解决方案相关的大部分成本效率都没有实现。即使这些环境是动态扩展的，您也可能会有一天中闲置资源未被使用的时间。虽然这是一个完全可以接受的模型，但它会破坏您的组织实现规模经济和利润效益的能力，而这些效益对SaaS模型至关重要。
• 敏捷性——向SaaS的转变通常是由以更快的速度进行创新的愿望直接推动的。这意味着采用一种模式，使组织能够快速响应市场动态。其中的一个关键部分是能够统一客户体验并快速部署新功能和功能。尽管筒仓模型可以采取一些措施来限制其对敏捷性的影响，但筒仓模型高度分散的特性增加了复杂性，影响了您轻松管理、运营和支持租户的能力。
• 入职自动化–SaaS环境重视自动化引入新租户。无论这些租户是以自助服务模式还是使用内部管理的资源调配流程进行入职，您仍需要自动化入职。而且，当您为每个租户设置了单独的siloe时，这通常会成为一个更重要的过程。提供新租户将需要提供新的基础设施，并可能需要配置新的帐户限制。这些增加的移动部件引入了额外的开销，从而为整个入职自动化带来了额外的复杂性，使您能够将更少的时间集中在客户身上。
• 去中心化管理和监控——SaaS的目标是拥有一块玻璃，使您能够管理和监控所有租户活动。当您拥有孤立的租户环境时，这一要求尤为重要。这里的挑战是，您现在必须从更分散的租户足迹中聚合数据。虽然有一些机制可以让您创建租户的聚合视图，但在孤立的模型中，构建和管理这种体验所需的努力和精力更为复杂。

池隔离（Pool Isolation）

您可以看到隔离的筒仓模型如何很好地映射到许多SaaS公司。许多正在转向SaaS的公司都在寻求让租户共享部分或全部底层基础设施的效率、灵活性和成本效益。这种共享基础设施方法（称为池模型）为隔离故事增加了一定程度的复杂性。图17中的图表说明了与在池模型中实现隔离相关的挑战。

图17：池隔离模型

在这个模型中，您会注意到我们的租户正在使用所有租户共享的基础设施。这使得资源能够与租户施加的实际负载成正比地扩展。图的右侧缩小了其中一个服务的计算方面，突出了租户1-N在任何给定时间都可能在共享计算中并行运行的事实。本例中的存储也是共享的，并表示为由单个租户标识符索引的表。

这种模式可以很好地适用于SaaS提供商，但是，它有可能使整个隔离过程复杂化。在共享资源的情况下，实现隔离并不是那么清晰和典型的网络，IAM结构不能用来在租户之间创建边界。

这里的关键是，即使这是一个更具挑战性的隔离环境，您也不能将其作为放松环境隔离要求的理由。共享模式增加了跨租户访问的机会，因此，它代表了一个需要您特别注意确保资源隔离的领域。

当我们深入研究池隔离模型时，您将看到这个体系结构足迹如何引入独特的挑战组合，每个挑战都需要自己类型的隔离构造来成功隔离租户的资源。

池模型的优点和缺点

尽管共享所有内容可以提高效率和优化，但这也需要SaaS提供商权衡采用该模型所带来的一些权衡。在许多情况下，水池模型的优点和缺点最终表现为筒仓模型的优点与缺点的反面。这些是通常与池隔离模型相关的主要优点和缺点。

优点

• 敏捷性–当您将租户迁移到共享基础架构模型中时，您可以利用自然的效率和简单性，帮助简化SaaS产品的敏捷性。池模式的核心是使SaaS提供商能够以统一的体验管理、扩展和运营所有租户。集中化和标准化体验是使SaaS提供商能够更轻松地管理所有租户并将更改应用于所有租户的基础，而无需逐个租户执行一次性任务。这种运营效率是SaaS环境整体敏捷性的关键。
• 成本效率——许多公司都因其成本效率而被SaaS所吸引。这种成本效率的很大一部分通常与隔离池模型有关。在共享环境中，您的系统将根据所有租户的实际负载和活动进行扩展。如果所有租户都处于离线状态，您的基础设施成本应该是最低的。这里的关键概念是，池化环境可以动态调整租户负载，并使您能够更好地调整租户活动与资源消耗。
• 简化了管理和操作–隔离池模型为您提供了一个系统中所有租户的视图。您可以通过触及系统中所有租户的单一体验来管理、更新和部署所有租户。这使得管理和操作的大部分方面更加简单。
• 创新–集合隔离模型所带来的灵活性也往往是SaaS提供商更快创新的核心。您越是远离分布式管理和筒仓模型的复杂性，就越能自由地关注产品的特性和功能。

缺点

• 吵闹的邻居——共享的资源越多，一个租户影响另一个租户体验的机会就越大。例如，一个租户的任何活动都会给系统带来沉重的负载，这可能会影响其他租户。一个好的多租户体系结构和设计将试图限制这些影响，但在共享隔离模型中，噪声邻居条件总是有可能影响一个或多个租户。
• 租户成本跟踪–在筒仓模型中，将资源消耗归因于特定租户要容易得多。然而，在集合模型中，资源消耗的归属变得更具挑战性。每一个SaaS提供商都应该寻找方法来检测他们的系统，并提供所需的粒度数据，以有效地将消费与单个租户关联起来。
• 减少影响范围–共享所有共享资源也会带来一些运营风险。在思洛存储器模型中，当一个租户发生故障时，该故障的影响可能仅限于该租户。然而，在共享环境中，停机可能会影响系统中的所有租户，这可能会对您的业务产生重大影响。这通常需要更深入地致力于建立一个有弹性的环境，以识别故障、浮出水面并从故障中优雅地恢复。
• 合规性阻碍——尽管您可以采取一些措施来隔离池模式中的租户，但共享基础设施的概念可能会造成您不愿意在这种模式中运行的情况。在域的法规遵从性或管理规则对资源的可访问性和隔离性施加严格限制的环境中尤其如此。尽管如此，即使在这些情况下，这也可能意味着系统的某些部分需要被孤立。

桥梁模型

尽管筒仓和池模型有非常不同的隔离方法，但许多SaaS提供商的隔离环境并不绝对。当您查看实际的应用程序问题并将系统分解为较小的服务时，您通常会发现您的解决方案需要混合使用思洛存储器和池模型。这种混合模型就是我们所说的隔离桥模型。图18中的图表提供了如何在SaaS解决方案中实现桥接模型的示例。

图18：桥梁隔离模型

此图突出显示了网桥模型如何使您能够组合思洛存储器和池模型。这里我们有一个具有经典web和应用程序层的整体架构。对于此解决方案，web层部署在所有租户共享的池模型中。虽然web层是共享的，但我们应用程序的底层业务逻辑和存储实际上部署在一个筒仓模型中，每个租户都有自己的应用程序层和存储。

如果单片被分解为微服务，那么系统中的每个微服务都可以利用筒仓和池模型的组合。关于这种方法的更多细节，将在使用不同AWS构造应用筒仓和池模型的细节描述中介绍。这里的关键信息是，对于分解为具有不同隔离要求的服务集合的环境，您对思洛存储器和池模型的看法将更加精细。

基于层的隔离

虽然我们对隔离的大部分讨论都集中在防止跨租户访问的机制上，但在某些情况下，您的产品的分层可能会影响您的隔离策略。在这种情况下，与其说是如何隔离租户，不如说是如何打包并为具有不同配置文件的不同租户提供不同风格的隔离。然而，这是另一个考虑因素，它可以决定您需要支持哪些隔离模式，以满足您想要接触的所有客户。图19中的图表提供了隔离如何在不同层之间变化的示例。

下面的示例使用了筒仓和池隔离模型的组合，这些模型已作为层提供给租户。Silver层的租户在共享环境中运行。尽管这些租户在共享基础架构模型中运行，但他们仍然完全希望自己的资源不会受到跨租户访问的保护。右边的租户要求提供一个完全专用的（筒仓）环境。为了支持这一点，SaaS提供商创建了一个高级层模型，使租户能够以更高的价格在这种专用模型中运行。

虽然SaaS提供商通常试图限制向其客户提供筒仓模型，但许多SaaS企业都有这种私有定价的概念，即这些租户提供在这种模型中部署的溢价。事实上，SaaS公司不会将其作为一个选项发布，也不会将其确定为一个层来限制选择此选项的客户数量。如果您的租户中有太多人陷入这种模式，您将开始回到完全孤立的模式，并继承前面概述的许多挑战。

图19：基于层的隔离

为了限制这些一次性环境的影响，SaaS提供商通常会要求这些高级客户运行部署到池环境的相同版本的产品。这使ISV能够通过一块玻璃继续管理和操作这两个环境。从本质上讲，思洛存储器环境变成了恰好支持一个租户的池环境的克隆。

目标的隔离

需要注意的是，系统中的隔离选择可能非常精细。系统中的每个微服务和这些服务接触的每个资源都可以选择配置不同的隔离模型。让我们来看看一些微服务示例，以更好地理解如何在不同的微服务之间改变隔离模型。图20中的图表提供了使用筒仓和池隔离模型的微服务视图。

在这个图中，您将看到一个系统实现了三种不同的微服务：产品、订单和帐户。每种微服务的部署和存储模型都突出了隔离（对于安全或嘈杂的邻居）如何在SaaS环境中实现。

让我们回顾一下这些服务的隔离模型。右上角的Product微服务部署在一个完整的池模型中，所有租户共享计算和存储。这里的表反映了租户在这里的所有土地作为单独的项目，在同一个表中进行索引。假设数据将与可以限制访问此表中租户项的策略隔离。Order微服务仅适用于租户1到租户3，并且也以池模式实现。这里唯一的区别是它支持一部分租户。本质上，任何没有得到Order微服务专用（筒仓）部署的租户都将在这个池部署中运行（将其视为租户1..N，只有少数租户作为筒仓微服务退出）。

出于本讨论的目的，让我们关注由专用订单微服务（右上）和Account微服务（下）表示的孤立服务。您会注意到，我们已经为租户4和5部署了Order微服务的独立实例。这里的想法是，这些租户对订单处理有一些要求（合规性、嘈杂的邻居等），要求在筒仓模型中部署此服务。这里的计算和存储都完全专用于这些租户。

最后，底部是Account微服务，它代表了筒仓模型，但仅在存储级别。微服务的计算由所有租户共享，但每个租户都有一个保存其帐户数据的专用数据库。在这种情况下，隔离问题只关注于分离数据。计算仍然可以共享。

图20：目标隔离

该模型显示了筒仓讨论如何变得更加精细。安全性、嘈杂的邻居以及各种因素将决定如何以及何时为服务采用筒仓隔离模型。这里的关键是，筒仓模型不是一个要么全有要么全无的决定。您可以考虑将思洛存储器模型应用于应用程序的特定组件，并仅在实际需要时（例如当潜在客户要求使用时）吸收该模型的挑战。在本例中，通过与客户进行更详细的讨论，您会发现只有几个特定的存储和处理领域值得关注。这样做将使您能够为系统中那些不需要思洛存储器隔离的部分获得池模型的效率，并为您提供灵活的分层结构，以支持单个服务的思洛存储器和池模型的混合。