【数据加密】加密白皮书

为什么公司要转向云计算？这通常是因为云环境具有可扩展性、可靠性和高可用性。然而，这些并不是唯一的考虑因素——安全性可以胜过云的其他优势。这就是为什么云提供商需要有一个全面的安全策略。Zoho的安全策略涵盖多个方面，加密是其中至关重要的一部分。本页面将告诉您关于Zoho加密策略的所有信息，以及我们如何使用它来确保您的数据安全。

概述

以下是我们将在本白皮书中讨论的内容

• 什么是加密？
• 传输中的加密
• 静止时的加密
• 应用程序级加密
• 密钥管理
• 我们在服务中加密哪些数据？
• 全磁盘加密

什么是加密？

加密主要用于保护邮件的内容，以便只有预期收件人才能阅读。这是通过将内容替换为不可识别的数据来实现的，而这些数据只能由预期收件人理解。这就是加密如何成为一种保护数据免受那些可能想窃取数据的人攻击的方法。

加密是指通过特殊的编码过程更改数据，使数据变得不可识别（加密）。然后你可以应用一个特殊的解码过程，你会得到原始数据（解密）。通过对密钥保密，其他人无法从加密数据中恢复原始数据。

编码过程遵循诸如AES 256的加密算法，该算法是公开的。然而，该过程本身取决于密钥，该密钥用于加密数据和解密数据。

这把钥匙是保密的。如果没有密钥，任何可能成功访问数据的人都只能看到一个“密码文本”，这将没有真正的意义。因此，数据受到保护。

为什么我们加密您的数据

最后一层保护-尽管全面的安全策略有助于公司保护数据免受黑客攻击，但加密是防止窃取数据的最后手段。它完成了数据保护，确保您的数据在不幸的安全漏洞事件中既不会损坏也不会被盗。

隐私-加密是对互联网隐私问题的保证。加密有助于保护隐私，确保除了预期的各方之外，没有人能够理解正在进行的通信。当您与我们互动并将数据存储在我们的服务器中时，加密有助于我们确保您的隐私。

我们所说的“数据”是什么意思

我们处理两种类型的数据-

• 客户数据-您通过Zoho服务与我们一起存储的数据。通常，这些数据由Zoho服务通过客户的帐户处理，该帐户可以在我们的IAM（身份和访问管理）数据库中识别。敏感数据是指暴露后可能对相关个人或组织造成伤害的数据。根据数据的敏感性和用户在各自Zoho服务中的要求，有些客户数据是加密的，而有些则不是。
• 派生数据-不是您直接提供的数据，而是从您的数据派生的数据。例如，身份验证令牌、唯一ID、URL和报告等都与我们一起存储。根据数据的敏感性，一些派生数据是加密的，而另一些则不是。

在后面的章节中，“数据”指的是经过加密的数据。

传输中的加密

当您使用Zoho服务时，您的数据会通过互联网从浏览器传输到我们的数据中心或其他第三方（使用第三方集成时）。加密传输中的数据可以保护您的数据免受中间人攻击。

对传输中的数据进行加密时有两种情况：

• 当数据从您的浏览器传输到我们的服务器时。
• 当数据从我们的服务器传输到非Zoho服务器（第三方）时

在你和Zoho之间

Zoho制定了严格的策略，以使传输层安全性（TLS）适应其所有连接。TLS允许连接双方进行身份验证，并对要传输的数据进行加密，从而确保您和Zoho服务器之间的安全连接。TLS协议确保没有第三方可以窃听或篡改您和Zoho之间的通信。。

我们遵循最新的TLS协议版本1.2/1.3，并使用使用SHA 256和密码生成的证书（AES_CBC/AES_GCM 256位/128位密钥用于加密，SHA2用于消息验证，ECDHE_RSA作为密钥交换机制）。我们还实现了完美的前向保密，并在所有网站上实施HTTPS严格传输安全（HSTS）。

Zoho与第三方之间

我们在与第三方通信时遵循https协议。对于涉及敏感数据和用例的交易，我们使用非对称加密，它利用公钥和私钥系统来加密和解密数据。

对于这种方法，我们在KMS（密钥管理服务）中生成一对公钥和私钥，该服务在所有服务中创建、存储和管理密钥。我们使用主密钥对这些对进行加密，并且加密的密钥对存储在KMS本身中。主密钥存储在一个单独的服务器中。

当我们将私钥存储在KMS中时，我们通过证书将公钥提供给第三方，经过身份验证后，加密的数据在KMS中将被解密。

静止时的加密

有两个主要的加密级别-

• 应用层加密
• 基于硬件的全磁盘加密

在应用程序级别加密数据的策略取决于数据存储的位置和方式-

• 数据库（DB）-存储为表
• 分布式文件系统（DFS）-存储为文件
• URL加密
• 备份
• 日志
• 缓存

下图描绘了我们加密策略的全貌：

应用程序级加密

您使用的任何Zoho服务（或应用程序）都涉及数据：您提供的数据和我们代表您存储的数据，作为服务的一部分。数据可以作为文件或作为数据字段来接收。这些类别中的每一个在加密方式方面都有不同的处理方式。

本节讨论应用程序级别的静态加密。

字段级加密

输入到应用程序中的敏感数据或敏感服务数据存储在各自的Zoho服务数据库中。其中的数据根据AES256标准使用AES/CCB/PKCS5Padding模式进行加密。静止时加密的数据因您选择的服务而异。了解有关我们在服务中加密的数据的更多信息。

加密发生在应用程序层，只有授权的应用程序用户才能查看数据。由于静态数据加密是在应用层完成的，任何正常的数据库或支持用户都无法在没有KMS加密密钥访问的情况下查看数据。在SQL等普通数据库工具中直接查看时，只有加密数据才可见。

加密类型因数据字段的敏感性以及用户的选择和要求而异。

有两种类型的字段级加密-

• 取决于数据的敏感性
• 取决于搜索功能

注：从此以后，我们将使用Zoho服务并拥有有限数量用户的客户或组织称为“组织”。

取决于数据的敏感性

• 类型1-这是我们对所有组织的数据进行的默认加密类型。在这种类型中，我们的KMS为每个组织分配一个密钥。与该组织对应的数据将使用该密钥加密。使用主密钥对密钥进行加密，并且加密的密钥存储在单独的服务器中。
• 类型2-我们对敏感和个人身份信息（PII）进行这种类型的加密。此类别包括银行账号、身份号码和生物特征数据等字段。
  • 在这种类型中，KMS为表中的每一列生成一个唯一的键。特定列中的所有数据都将使用为该列生成的密钥进行加密。这些密钥再次使用主密钥进行加密，并存储在单独的服务器中。

取决于搜索功能

加密数据的搜索功能取决于加密期间使用的初始化矢量（IV）。IV是启动加密过程的随机值。该随机值确保每个数据块/单元以不同方式加密。这也意味着对同一数据加密两次会产生不同的密文。

为什么IV很重要？

如果您没有IV，并且只使用密钥使用密码块链接（CBC）模式，那么以相同数据开始的两个数据集将产生相同的第一个块。IVs使得两个不同数据的加密不太可能创建相同的输入/输出对（在分组密码级别，使用相同的密钥），即使其中一个与另一个有某种关系（包括但不限于：从相同的第一个块开始）。

当每个加密请求都允许使用随机IV时，第一个块将是不同的。攻击者无法推断出任何可能帮助他们解码加密数据的信息。

• 保持相等加密：在这种类型中，只有一个IV对应于一个密钥。这意味着，整个密文块可以用于搜索查询。由于组织/列的所有数据的IV都是相同的，因此搜索会为您获取数据。
• 标准加密：在这种类型中，每个数据条目都有一个唯一的IV。即使你用一个密钥加密整个数据，每个加密的数据条目也会产生一个独特的密文。此外，由于IV是随机的，并且对于每个数据都是唯一的，因此搜索查询不会为您获取数据。这是一个比“保持平等”变体更安全的选择。

在什么情况下会使用这些变体？

选择特定变体的决定通常取决于需求。如果数据必须接受最高标准的保护，我们会选择具有标准加密的Type-2。

然而，它并不总是只涉及保护。有时，用户可能希望搜索并获取一个字段，如“电子邮件ID”，以满足他们的要求。在这种情况下，标准选项是没有意义的，我们选择Type-1，使用“保持平等”加密。

文件加密

您创建或附加的文件将保存到我们的分布式文件系统（DFS）中。静止时加密的文件因您选择的服务而异。了解有关我们在服务中加密的数据的更多信息。加密发生在应用程序层，只有授权的应用程序用户才能查看数据。

加密基于标准AES 256算法，加密模式为CTR或GCM。在AES 256中，需要加密的明文被划分为数据包或块。由于我们在这里对文件的内容进行加密，因此算法应确保每个块的加密独立于另一个块，这样即使块密码被泄露，攻击者也不会获得有关文件的任何信息。

伽罗瓦/计数器模式 Galois/Counter Mode（GCM）是使用分组密码算法的典型分组密码操作模式。CTR只提供加密，GCM提供加密和身份验证。

如果加密的文件已损坏，在CTR模式下解密文件时将返回一个垃圾值。另一方面，在GCM模式中，我们有一个身份验证标签，它验证加密文件的真实性，然后解密数据。GCM模式为文件提供了一个附加的完整性层。

与字段级加密一样，文件加密也有两种类型：

• 类型1-在这种类型中，每个组织都有一个密钥。来自该组织的每个文件都使用该密钥加密，但带有一个唯一的随机IV，该IV与文件本身一起存储。该密钥再次使用主密钥加密，并且该密钥存储在KMS中。
• 类型2-在这种类型中，每个文件都有一个唯一的密钥，并使用该密钥进行加密。用于加密文件的每个密钥都使用KEK再次加密，并且加密的密钥存储在Zoho服务数据库中，而文件存储在DFS中。该KEK对于每个组织都是唯一的，并且由KMS存储和管理。

URL加密

Zoho服务内的邀请链接或任何其他通信可能涉及在URL中传递的敏感数据。为了确保此通信的安全，对URL的部分内容进行了加密。如果URL中有任何可识别的内容，比如文档的ID，则该部分是加密的。

这种加密有两种类型-每个组织一个密钥或每个功能一个密钥。同样，这是由URL中数据的敏感性决定的。

备份加密

我们经常备份数据，我们的备份服务器配备了与主服务器相同的保护标准。我们作为备份的所有数据将在休息时进行加密。

日志的加密

Zoho Logs使用Hadoop分布式文件系统（HDFS）来存储和管理日志。我们使用Hadoop的加密技术对数据进行加密，而密钥管理由我们的KMS处理。

缓存加密

我们使用Redis开源软件来存储和管理缓存数据。缓存包含在服务操作中重复使用的数据，并且需要存储一定的时间。有时，您的数据可能会被缓存以改进服务或进行故障排除。如果任何数据包含敏感的个人信息，我们会选择对其进行加密。

密钥管理

我们的内部密钥管理服务（KMS）在所有服务中创建、存储和管理密钥。我们使用KMS拥有并维护密钥。目前，我们没有使用客户拥有的密钥加密数据的规定。

注意：我们正在开发一项支持自带密钥（BYOK）的新功能，通过该功能，您可以从自己选择的外部密钥管理器提供自己的加密密钥。

在加密的不同阶段使用不同类型的密钥：

• 数据加密密钥（DEK）：用于将数据从明文转换为密文的密钥，或用于加密数据的密钥。
• 密钥加密密钥（KEK）：用于加密DEK的密钥，并且是Zoho服务特定的。KEK是在一个单独的服务器中生成的。它提供了额外的安全层。

主密钥：用于加密KEK的密钥。为了安全起见，此密钥存储在一个独立的服务器中。

KMS是如何工作的？

所有类型的加密都是根据AES 256算法进行的。根据这种算法，数据被视为要加密的“块”。无论它是数据库中的字段还是DFS中的文件，当使用DEK对数据块进行加密时，都会开始加密。

此DEK使用KEK进行进一步加密。KEK再次使用存储在单独服务器中的主密钥进行加密。因此，以下是需要管理的元素-

• Encrypted data
• DEKs
• Encrypted DEKs
• KEKs
• Encrypted KEKs
• Master key

KMS以以下方式管理这些元素：

密钥是如何生成的？

KMS生成符合AES 256协议的256位密钥以及初始化矢量（IV）。IV、 如我们已经讨论过的，确保加密数据的第一块是随机的。这就是为什么在IVs的帮助下，相同的明文被加密成不同的密文。

KMS使用Java安全库和SecureRondom数字生成器生成这些密钥和IV。

钥匙存放在哪里？

KMS中生成的DEK使用KEK进行加密。这提供了一个额外的安全层。加密的DEK存储在KMS数据库中。

我们将密钥物理分离（将它们存储在不同的位置），这样，掌握一个密钥的攻击者就无法掌握其他相关密钥。我们使用主密钥对KEK进行加密，并将其存储在单独的服务器中。

对于Zoho Workdrive，我们为静态存储的文档提供了一个额外的安全层。

攻击者不能仅以KMS为目标来破坏数据。

钥匙有多安全？

物理分离-如前所述，主密钥保留在物理分离且安全的服务器中。这使得攻击者很难同时破坏DEK和KEK。

访问控制-访问控制有助于我们防止滥用和前所未有的钥匙访问。访问控制列表（ACL）只允许选择服务访问选择密钥。每次访问密钥时，都会对其进行身份验证，并记录该过程。这些日志通过定期审计进行监控。

默认情况下，访问KMS受到限制，并且仅允许Zohocorp的特定人员访问。任何其他访问都是作为票证提出的，只有在管理层批准后才允许。

钥匙旋转-我们有一个钥匙旋转系统，可以更改主钥匙，从而确保额外的安全性。当生成新的主密钥和IV时，意味着数据库中的密钥也必须进行修改。因此，首先使用旧的主密钥获取和解密数据库中的所有密钥，然后使用新的主密钥重新加密并在数据库中更新。

目前，只有在KMS中的密钥发生任何泄露的情况下，才会触发密钥轮换。

密钥的可用性—如果一个数据中心（DC）中的磁盘主存储发生故障，则会有一个从机和一个辅助从机用于备份，它们与主DC保存相同的数据。从设备和次从设备都有加密的密钥，与主设备相同。

我们在服务中加密哪些数据？

静止时加密的数据因您选择的Zoho服务而异。特定数据项的加密类型由您或我们决定，或由双方协商决定。

以下表格列描述了由各种Zoho服务加密的数据：

Service	Encrypted Fields
CRM	Custom fields, all files and all mail content sent and received via CRM. For more details, refer link.
Workdrive	All files. For more details, refer link.
Creator	Fields. For more details, refer link.
Campaigns	Fields that contain personal information, user uploaded files. For more details, refer link.
Cliq	ChatTranscript and personal information. For more details, refer link.
People	Custom Fields, all files. For more details, refer link.
Connect	Title, URL and contents of - feed, forum posts, articles, townhalls, groups, announcements, tasks and their comments, video files and attachments. For more details, refer link.
Desk	Ticket thread content, attachments, custom fields and tokens. For more details, refer link.
Finance	Bank account details, custom fields that contain personal information, employee details which contain sensitive personal information, travel documents, bank statements and attachments.
Projects	Attachments, fields that contain personal information, tokens. For more details, refer link.
Sprints	Files, attachments, tokens and fields that contain personal information. For more details, refer link.
Notebook	Notecard and Attachments. For more details, refer link.
Sign	Documents, signature images and tokens. For more details, refer link.
Reports	Custom fields, files uploaded by users, custom queries
Mail	All mail content, attachments and fields that contain personal information
Recruit	Custom fields and user-imported documents. For more details, refer link.
Social	Tokens, fields that contain personal information. For more details, refer link.
Service Desk Plus Cloud	Tokens, email server passwords and custom fields. For more details, refer link.
SalesIQ	File attachments, tokens, media recordings and chat transcripts. For more details, refer link.
Assist	Screenshots and session recordings. For more details, refer link.
Survey	Custom fields, files uploaded by respondents and email addresses provided in share feature. For more details, refer link.
Show	Presentations, uploaded files and personal information. For more details, refer link.
Directory	Custom fields. For more details, refer link.
Contracts	Contract Documents, Contract Letters, Negotiation Links' Passwords, Organization & Counterparty Contacts' Phone Number. For more details, refer link.
Learn	Contents of articles, lessons, attachments, templates and personal information. For more details, refer link.
Sites24x7	Mobile number, Email address, Hostname, IP address, URL, Access token, Domain name, Credentials provided by the user, Service Account configurations and files uploaded by the user. For more details, refer link.
Dataprep	PII (Personally Identifiable Information), ePHI (Electronically Protected Health Data), and credentials. For more details, refer link.

全磁盘加密

我们采用自加密驱动器（SED）来支持基于硬件的全磁盘加密。SED是一种内置加密电路的硬盘驱动器（HDD）或固态驱动器（SSD）。

自加密只是指写入存储介质的所有数据在写入之前都由磁盘驱动器加密，并在读取时由磁盘驱动器解密。

写入驱动器的数据使用存储在磁盘上的数据加密密钥（DEK）进行加密/解密。制造商提供的默认DEK由我们在设置时重新生成，以维护我们的安全标准。

为了进一步增强SED的安全性，我们使用身份验证密钥。身份验证密钥（AK）用于加密DEK并锁定/解锁驱动器。使用本地密钥管理系统（LKMS）来管理AK。

当服务器中启用加密时，AK会安全地传输到服务器。在磁盘被盗或未经授权的物理访问的情况下，如果没有AK，则无法解密DEK，因此无法访问或读取驱动器上的数据。通过这种方式，AK增加了一层额外的保护。

目前，基于硬件的全磁盘加密默认适用于印度（in）、澳大利亚（AU）和日本（JP）数据中心的所有Zoho服务。在其他DC中，全磁盘加密仅适用于某些Zoho服务。有关更多详细信息，请参阅相应的特定于服务的加密帮助文档。

结论

我们在存储敏感客户数据时、在互联网上传输时以及在我们的DC之间传输时对其进行加密。然而，加密只是我们安全策略的一部分。我们不断创新，努力通过实施最新的协议和技术来加强数据保护。