saas 数据安全_安全和数据隐私的SaaS信任模型

saas 数据安全

零信任模型是隐私中的终极选择，但很少有选择。 但这不必是零信任或完全信任。 中间信任模型的规模在不断变化。 这就是这些模型也具有价值的原因。 (Zero-trust models are the ultimate in privacy but are rarely an option. But it doesn’t have to be either zero-trust or full-trust. There’s a sliding scale of trust models in the middle. Here’s why these models also have value.)

Trust. It’s what powers business. Consumers and businesses buy from brands they trust. But in the world of software-as-a-service, trust is about far more than brand reputation.

相信。 这就是推动业务发展的动力。 消费者和企业从他们信任的品牌购买商品。 但是在软件即服务的世界中，信任远不止品牌声誉。

Our natural inclination is to trust the brands that our peers trust. This is why large companies are able to keep selling software even when their products stagnate. But even large companies need to watch out for the trapdoor at their feet and the thing that can turn their biggest advocates into their loudest critics: privacy.

我们的天性就是信任同行所信任的品牌。 这就是大型公司即使产品停滞不前仍能够继续销售软件的原因。 但是，即使是大型公司也需要注意脚下的活板门，并且可以将最大的拥护者变成最大声的批评者：隐私。

Privacy is becoming a reason for consumers to purchase a product, in the same way that “organic,” “free trade” and “cruelty-free” labels have driven products sales in the past decade.— Gartner

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

Zoom recently discovered this the hard way, when users learned that their security and privacy expectations weren’t being met.

当用户得知无法满足其安全性和隐私期望时，Zoom最近发现了这种困难的方法 。

信任模型的目的是什么？ (What is the purpose of a trust model?)

Trust models at a general level can be applied in many different settings. In cryptographic settings, there are very explicit attack models that serve as shorthand for understanding what different actors in secure protocols can or cannot learn. These have names like, “Adaptive chosen-ciphertext attack (CCA2).” These are incredibly useful when evaluating cryptographic protocols against need, but we lack a similar way to talk about SaaS offerings.

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

Having a common language and definitions make conversations about data privacy needs and requirements much easier. Different needs lead to different models and there’s a rich spectrum to choose from depending on use cases.

拥有通用的语言和定义使有关数据隐私需求的讨论变得更加容易。 不同的需求导致了不同的模型，并且根据使用案例有很多种选择。

For example, Customer Managed Keys (CMK, aka Bring Your Own Keys or BYOK), when done right, is a trust-but-verify model. This means the customer has control of a master key or keys for decrypting the data that their service provider holds and can see when their data is accessed. The service provider does not have access to this data without the ongoing consent of their customer.

例如，正确执行的客户管理密钥(CMK，又称“带您自己的密钥”或BYOK)是一种信任但验证的模型。 这意味着客户可以控制一个或多个主密钥，以解密其服务提供商所拥有的数据，并可以看到何时访问其数据。 未经客户的持续同意，服务提供商无法访问此数据。

什么是SaaS信任模型？ (What are the SaaS trust models?)

There are a number of models that are in widespread use today, though they aren’t often named as such. It’s worth noting that we sometimes see a mixture of models depending on the data or on the level of service. For example, Salesforce offers stronger trust models if you pay a premium for their Salesforce Shield features.

尽管没有经常这样命名，但如今有许多模型正在广泛使用。 值得注意的是，有时我们会根据数据或服务级别看到混合的模型。 例如，如果您为他们的Salesforce Shield功能支付了溢价，则Salesforce将提供更强大的信任模型。

Here are the models we see from most common to least common:

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

• Full-trust: This is the default and classic state for SaaS, IaaS, and PaaS: The service provider has full access to all of the data of its customers but promises not to abuse that privilege. The service provider makes contractual promises in the form of terms-of-service and privacy policies. The single most crucial test for whether a service is “full-trust” is whether or not an administrator of the service could access a customer’s data. So even if the data is encrypted, if that encryption is transparent to the administrator or they have access to the keys, it’s a full-trust model.

  完全信任：这是SaaS，IaaS和PaaS的默认和经典状态：服务提供商可以完全访问其客户的所有数据，但承诺不会滥用该特权。 服务提供商以服务条款和隐私政策的形式做出合同承诺。 服务是否是“完全信任”的最关键的测试是服务的管理员是否可以访问客户的数据。 因此，即使数据是加密的，但这种加密对管理员来说是透明的，或者他们可以访问密钥，这也是一种完全信任模型。

• Trust-but-verify: This model is similar to full-trust, except the customer retains an independent audit logging capability on the access of sensitive data so they know who is accessing it, when, and from where. Additionally, the customer has the ability to revoke access to their data from the service provider without relying on the service provider to remove the data. In other words, an employee or system at the provider can see all data, but the customer knows when they access it and can shut off that access at any time. The Salesforce Shield product is an example of a trust-but-verify model for the data that is protected by that product.

  信任但验证：该模型类似于完全信任，除了客户在敏感数据的访问方面保留独立的审核日志功能之外，这样他们就知道谁在何时何地访问数据。 此外，客户可以从服务提供商撤消对其数据的访问，而无需依赖服务提供商删除数据。 换句话说，提供者的员工或系统可以看到所有数据，但是客户知道何时访问它们，并且可以随时关闭该访问。 Salesforce Shield产品是该产品保护的数据的信任但验证模型的示例。

• Semi-trust: A semi-trusted provider facilitates access to data (or the ability to decrypt or access it) but can’t decrypt the data or grant access itself. Semi-trusted services generally have access to metadata and users are generally not anonymous. A semi-trusted player doesn’t have access to the data (zero-trust in this regard) but is trusted with other operations such as revocation. For example, a semi-trusted server might hold encrypted encryption keys and hand them out, but would not have a way to decrypt those keys nor to determine who can. This is an important model when looking at zero-trust data architectures as it is frequently as good as “zero trust” in an environment where anonymity is unimportant or disallowed.

  半信任：半信任的提供者有助于访问数据(或解密或访问数据的能力)，但不能解密数据或自身不授予访问权限。 半信任的服务通常可以访问元数据，而用户通常不是匿名的。 半受信任的播放器无权访问数据(在此方面为零信任)，但受其他操作(如吊销)信任。 例如，半受信任的服务器可能持有加密的加密密钥并将其分发出去，但是将无法解密这些密钥或确定谁可以解密。 在查看零信任数据体系结构时，这是一个重要的模型，因为在匿名性不重要或不允许匿名的环境中，它通常与“零信任”一样好。

• Split-trust: A split-trust security model requires two or more parties to collaborate to be able to see data. A common implementation of this model encrypts data and gives one entity the keys and another entity the encrypted data. Each entity promises not to share its data with the other entity. We sometimes see people talk about split-trust models within a single entity where trust is spread between servers. At a server-level, this may be true, but at a service provider level, it is not. So a service provider who splits trust between servers internally cannot say that it meets the SaaS Split-trust model since administrators within the service provider could still access data without needing the collaboration of a 3rd-party. Note: if the customer holds their own keys, that is not a split-trust model as split-trust implies the customer trusting two or more parties and trusting those parties not to collude. Customer-held keys can be either a trust-but-verify model if data is decrypted and seen by the service provider at their servers, or a zero-trust model if the data is only decrypted by the customer.

  信任分割：信任分割安全模型需要两个或多个参与方进行协作才能看到数据。 此模型的一种常见实现是对数据进行加密，并为一个实体提供密钥，而另一实体为加密数据。 每个实体保证不与另一个实体共享其数据。 有时我们会看到人们谈论单个实体内的拆分信任模型，信任在服务器之间分布。 在服务器级别，这可能是正确的，但在服务提供商级别，情况并非如此。 因此，内部在服务器之间拆分信任的服务提供商不能说它满足SaaS拆分信任模型，因为服务提供商内的管理员仍然可以访问数据而无需第三方的协作。 注意：如果客户拥有自己的密钥，则这不是拆分信任模型，因为拆分信任意味着客户信任两个或更多方，并且信任那些方不会串通。 如果服务提供者在其服务器上解密并查看数据，则客户持有的密钥可以是信任但验证模型，如果仅由客户解密，则可以是零信任模型。

• Zero-trust: If the service provider holds encrypted data, but can’t gain access to the decrypted data at the servers and has limited or no insights about the data it holds, then the model is zero-trust. We sometimes call this zero-visibility or zero-trust data to avoid confusion with the network-level concept of zero-trust. In a zero-trust data scenario, the service provider doesn’t have keys, doesn’t decrypt data, and never sees nor could see decrypted data on its servers. The customer or the customer’s employees are, however, able to view data by decrypting it in their client (browser, mobile app, or whatever) or on their own servers.

  零信任：如果服务提供商拥有加密的数据，但无法访问服务器上的解密数据，并且对其拥有的数据了解有限或没有洞察力，则该模型为零信任。 有时我们将此称为零可见性或零信任数据，以避免与网络级别的零信任概念混淆。 在零信任数据方案中，服务提供者没有密钥，没有解密数据，也从不看到也看不到其服务器上的解密数据。 但是，客户或客户的雇员可以通过在其客户端(浏览器，移动应用程序或任何其他设备)或自己的服务器上解密数据来查看数据。

• Ephemeral-trust: When a service provider sees some data on their server, but encrypts it before persistently storing it, we have an ephemeral-trust model. This is useful when storing “toxic data” — that is, private user-generated content like chat logs or conference call recordings that could have regulated data (health, financial, insider-trading, etc.) inside — where the service provider needs one-time access to the data to deliver promised value to the customer. For example, in the case of audio, the service might generate a transcript on their server, then encrypt the transcript and the source audio such that the service provider can no longer access it. This helps the service provider to minimize their exposure in the case of a hack or an overly curious administrator.

  临时信任：当服务提供商在他们的服务器上看到一些数据，但是在将其持久存储之前对其进行加密时，我们就有了临时信任模型。 当存储“有毒数据”(即聊天记录或电话会议记录的私人用户生成的内容，这些内容可能具有管制数据(健康，财务，内部交易等)的内部时，此功能非常有用-服务提供商需要一个实时访问数据，以向客户交付承诺的价值。 例如，在音频的情况下，服务可能会在其服务器上生成一个笔录，然后对该笔录和源音频进行加密，以使服务提供商无法再访问它。 这可以帮助服务提供商在黑客或管理员过于好奇的情况下最大程度地降低其风险。

In many cases where IronCore has worked customers, there is a mixture of trust models. For example, it may be that attachments follow a zero-trust model while sensitive or regulated data follows a trust-but-verify model. For the purposes of these models, we generally ignore data that a customer would not deem to be private.

在许多情况下，IronCore已为客户服务，信任模型混合在一起。 例如，附件可能遵循零信任模型，而敏感或管制数据遵循信任但验证模型。 就这些模型而言，我们通常会忽略客户认为不属于私人的数据。

问正确的问题 (Asking the right questions)

Perhaps with a shared language, we can all better evaluate service providers according to how much trust we must grant to them if we use their service. The right answer depends on what data we’re entrusting, what harm could come from a curious admin or hacker, potential regulatory penalties, and more. But taken together, we can better evaluate the risk we take in partnering with a SaaS provider.

也许使用一种共享的语言，我们所有人都可以根据使用服务提供商时必须给予他们的信任程度来更好地评估服务提供商。 正确的答案取决于我们所委托的数据，好奇的管理员或黑客可能造成的危害，潜在的监管处罚等等。 但是总的来说，我们可以更好地评估与SaaS提供商合作所面临的风险。

Questions worth asking a service provider as a potential customer:

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

• Is there anyone in your company who can access my sensitive data?
  您公司中是否有人可以访问我的敏感数据？
• If so, is that access persistent?
  如果是这样，访问是否持久？
• If not, what do you know about the data that you can’t see? What metadata do you have?
  如果不是，您对看不到的数据有什么了解？ 你有什么元数据？
• Is there a way for me to know when someone in your company accesses my data, even if that person is a database or systems administrator?
  我可以通过某种方式知道您公司中的某人何时访问我的数据，即使该人是数据库或系统管理员也是如此？
• Do you have any service providers (for example, Amazon Web Services) where one of their admins could potentially see my data (for example, if they were compelled by a law enforcement order or any other reason)?
  您是否有任何服务提供商(例如Amazon Web Services)可以让他们的一位管理员看到我的数据(例如，如果它们是由执法命令或其他任何原因强迫的)？
• Do you offer a way to encrypt the data such that I can hold the keys?
  您是否提供一种加密数据的方式，以便我可以握住密钥？

These questions are the starting point for evaluating trust. Unfortunately, in most cases today, the answers to these questions mean you must fully trust the service provider. But as customers of SaaS mature in the questions we ask and how we evaluate businesses, more and more SaaS companies will up their trust game by reducing the amount of blind trust required to use their service.

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

翻译自: https://blog.ironcorelabs.com/saas-trust-models-for-security-and-data-privacy-a83731c2a446

saas 数据安全