零信任模式是隐私保护的终极模式，但很少有这种选择。但这并不一定是零信任或完全信任。信任模型在中间有一个滑动的比例。以下是为什么这些模型也有价值。

信任。这是商业的动力。消费者和企业购买他们信任的品牌。但在“软件即服务”的世界里，信任远不止品牌声誉。

我们天生倾向于相信同辈信任的品牌。这就是为什么大公司即使在产品停滞不前时也能继续销售软件的原因。但即使是大公司也需要提防脚下的活板门，以及可能把他们最大的拥护者变成最大声的批评者的东西:隐私。

隐私正在成为消费者购买产品的一个原因，就像“有机”、“自由贸易”和“无残忍”标签在过去十年里推动产品销售一样Gartner

Zoom最近发现了这个艰难的方式当用户得知他们的安全和隐私期望没有得到满足时，他们就开始抱怨。

信任模型的目的是什么?

一般级别的信任模型可以应用于许多不同的设置。在密码设置中，有非常明确的攻击模型这可以简化理解安全协议中的不同参与者可以或不能学习什么。这些攻击的名称类似于“自适应选择密文攻击(CCA2)”。在根据需要评估加密协议时，这些方法非常有用，但我们缺乏类似的方法来讨论SaaS产品。

拥有共同的语言和定义可以使关于数据隐私需求和要求的对话更加容易。不同的需求导致不同的模型，根据用例有丰富的选择范围。

例如，客户管理密钥(CMK，又名Bring Your Own Keys或BYOK)，如果使用得当，是一个信任但验证的模型。这意味着客户可以控制一个或多个用于解密其服务提供商持有的数据的主密钥，并且可以看到他们的数据何时被访问。如果没有客户的持续同意，服务提供商不能访问这些数据。

SaaS信任模型是什么?

目前有许多模型被广泛使用，尽管它们不经常被这样命名。值得注意的是，根据数据或服务水平，我们有时会看到混合模型。例如，如果你为Salesforce Shield功能支付额外费用，Salesforce就会提供更强的信任模型。

以下是我们从最常见到最不常见的模型:

• 完全信任:这是SaaS、IaaS和PaaS的默认和经典状态:服务提供者拥有对其客户的所有数据的完全访问权，但承诺不会滥用该特权．服务提供商以服务条款和隐私政策的形式做出合同承诺。服务是否“完全信任”的最关键测试是服务的管理员是否可以访问客户的数据。所以即使数据是加密的，如果加密对管理员是透明的或者他们可以访问密钥，这是完全信任模型。
• 信任,但要核查:此模型类似于完全信任，只是客户保留了对敏感数据访问的独立审计日志记录功能，以便他们知道谁在何时以及从何处访问它。此外，客户可以从服务提供者撤销对其数据的访问，而不依赖于服务提供者删除数据。换句话说，提供商的员工或系统可以看到所有数据，但客户知道他们何时访问数据，并可以随时关闭访问。Salesforce Shield产品就是一个例子信任,但要核查受该产品保护的数据的模型。
• Semi-trust:半可信的提供者有助于对数据的访问(或解密或访问数据的能力)，但不能对数据进行解密或授予访问权限。半可信服务通常可以访问元数据，用户通常不是匿名的。半信任的参与者没有访问数据的权限(在这方面是零信任)，但可以信任其他操作，如撤销。例如，半可信服务器可能存在加密加密密钥并分发出去，但没有办法解密这些密钥，也不知道谁能解密。在研究零信任数据架构时，这是一个重要的模型，因为在匿名不重要或不允许的环境中，它通常与“零信任”一样好。
• Split-trust:信任分离安全模型需要两方或多方协作才能看到数据。此模型的通用实现对数据进行加密，并向一个实体提供密钥，向另一个实体提供加密的数据。每个实体都承诺不与其他实体共享其数据。我们有时会看到人们在单个实体中谈论信任分裂模型，其中信任在服务器之间传播。在服务器级别上，这可能是正确的，但在服务提供者级别上则不是。因此，在服务器之间进行内部信任分割的服务提供商不能说它符合SaaS分离信任模型，因为服务提供商内部的管理员仍然可以在不需要第三方协作的情况下访问数据。注意:如果客户拥有自己的密钥，这不是一个分裂信任模型，因为分裂信任意味着客户信任两个或两个以上的方，并且相信这些方不会串通。如果数据是由服务提供者在其服务器上解密并看到的，则客户持有的密钥可以是信任但验证模型;如果数据仅由客户解密，则客户持有的密钥可以是零信任模型。
• Zero-trust:如果服务提供者持有加密数据，但无法访问服务器上的解密数据，并且对其持有的数据了解有限或没有，则该模型为零信任。我们有时称之为零能见度或zero-trust数据为了避免与网络级的零信任概念混淆。在零信任数据场景中，服务提供者没有密钥，不会解密数据，并且永远不会看到也不能看到其服务器上的解密数据。然而，客户或客户的员工能够通过在客户端(浏览器、移动应用程序或其他)或自己的服务器上解密数据来查看数据。
• Ephemeral-trust:当服务提供者在他们的服务器上看到一些数据，但在持久存储之前对其进行了加密，我们就有了一个临时信任模型。这在存储“有毒数据”时非常有用——即用户生成的私人内容，如聊天日志或电话会议记录，其中可能包含受监管的数据(健康、金融、内幕交易等)——服务提供商需要一次性访问这些数据，以向客户交付承诺的价值。例如，对于音频，服务可能会在其服务器上生成一个记录，然后加密记录和源音频，这样服务提供者就不能再访问它了。这有助于服务提供商在黑客或过于好奇的管理员的情况下最大限度地减少他们的暴露。

在IronCore与客户合作的许多案例中，存在多种信任模式。例如，附件可能遵循零信任模型，而敏感或受管制的数据可能遵循信任但验证模型。出于这些模型的目的，我们通常忽略客户不认为是私有的数据。

问正确的问题

也许有了共同的语言，我们都可以根据使用他们的服务时必须给予他们多少信任来更好地评估服务提供商。正确的答案取决于我们委托的是什么数据，好奇的管理员或黑客会带来什么伤害，潜在的监管处罚等等。但总的来说，我们可以更好地评估与SaaS提供商合作所承担的风险。

作为潜在客户，值得询问服务提供商的问题:

• 你们公司有没有人可以访问我的敏感数据?
• 如果是，该访问是持久的吗?
• 如果没有，你对看不到的数据了解多少?你有什么元数据?
• 是否有一种方法可以让我知道您公司中的某人何时访问了我的数据，即使那个人是数据库或系统管理员?
• 您是否有任何服务提供商(例如，Amazon Web Services)，他们的管理员可能会看到我的数据(例如，如果他们被执法命令或任何其他原因所强迫)?
• 你能提供一种加密数据的方法吗?这样我就可以拥有密钥了。

这些问题是评估信任的起点。不幸的是，在今天的大多数情况下，这些问题的答案意味着您必须完全信任服务提供者。但是，随着SaaS客户在我们提出的问题和我们如何评估业务方面的成熟，越来越多的SaaS公司将通过减少使用其服务所需的盲目信任来加强他们的信任游戏。