加密是一种数学方法，通过该方法，信息将对所有人员模糊处理，但被授权查看和使用这些信息的人员除外。 可以对数据文件进行加密，并且还可以对通过网络与数据进行交易的会话进行加密。 如今，大多数网站和服务都使用传输层安全性 (TLS) 作为加密和保护流量的一种方法。 你知道，当浏览器的地址行包含协议标识符 https://（而不是 http://）且用于保护会话的服务证书由某种“已验证”图标（如绿色复选框）表示时，站点使用 TLS。

加密在 Internet 和公有云平台上托管的应用程序安全性方面起着重要作用。 可以对数据进行静态加密（例如，在 Azure SQL 数据库或 AWS S3 存储中），以使其在被盗的情况下变得毫无用处，并且可以使用 TLS 对数据进行动态加密，以保护数据在云服务之间或用户与云服务之间通过网络传输的安全性。 最大的挑战在于密钥的可用性。 如果数据是加密的，那么如何以及在何处存储解密密钥，才能使应用程序可以检索数据，但攻击者不能检索数据？ 此外，如果使用 TLS 加密浏览器与 Web 服务器之间（或者 Web 服务器与数据库或负责验证用户身份的应用程序与标识提供者之间）的流量，那么如何才能使密钥可用但又不将其公开给潜在的攻击者？

为了回答这些问题，让我们回顾一下数字加密的基础知识并了解一些机制，这些机制使那些拥有密钥的人可以使用密钥，而又不会向那些没有密钥的人公开密钥。

在加密中，密钥是一系列数字，用于更改消息的内容，即对消息进行加密或解密。 对称加密是最原始的加密形式之一，其中的一个密钥可同时用于加密和解密数据。 对称加密通常用于加密数据库和云存储服务中的静态数据。

多年以来，人们已经开发了几种对称加密算法并将其用作标准，部分原因是（至今）还没有人找到胜过这些算法的方法。 其中一种就是高级加密标准（即 AES）。 美国国家标准技术研究院 (NIST) 早在 2001 年就采用了这种算法，该算法取代了数据加密标准 (DES)，后者在现代计算机面前被认为是无效的。 AWS 和 Azure 等云平台普遍使用 256 位密钥的 AES-256 加密其存储的数据。

对 AES-256 加密的数据进行暴力攻击将需要数十亿台超级计算机花费数十亿年的时间才能激活成功教程，这样就简化了问题。 可以说，对于当今的计算机，在没有密钥的情况下解密 AES-256 加密的数据在计算上是不可行的。 因此，对称加密的主要挑战不是加密和解密数据，而是以这样的方式存储密钥：可以将密钥提供给所有需要密钥的各方，但只将其提供给获得授权的人员。

加密（和解密）数据很容易，而保护用于加密和解密的密钥却非易事。 在存储机密的任何通信系统中，机密本身最容易成为恶意参与者的目标。

安全工程师建议组织使用经过验证的密钥管理服务，确保密钥存储无法被利用。 Azure Key Vault 就是此类服务的一个示例。 密钥管理器可帮助组织保持对 PCI DSS（本模块的后面部分介绍这一内容）之类的标准和框架的符合性，该标准和框架要求定期更改或轮换加密/解密密钥和其他机密。 它还减少了攻击者可以成功检索解密密钥、数据库连接字符串或其他机密的机会。

Azure Key Vault 是一项 SaaS 服务，允许用户和应用程序以高度安全的方式存储密钥、密码、连接字符串、证书和其他机密。 该服务使用 Microsoft Entra ID 验证用户身份，并与其他 Azure 服务（例如 Azure SQL 数据库和 Azure 存储）集成。 也可以通过 API 访问它，因此应用程序可以检索存储在那里的机密。 为了获得最大程度的保护，可以选择将机密存储在美国联邦信息处理标准 (FIPS) 140-2 级别 2 验证的硬件安全模块 (HSM) 中。 HSM 可供共享或专用。 值得注意的是，Microsoft 看不到存储在 Azure Key Vault 中的机密。

将密钥和其他机密存储在 Key Vault 中后，就可以将系统设置为自动轮换其值，而无需人工干预。 这使组织符合 PCI DSS 的条款。 如果发生安全事件或在定期安全审核期间，可将 Key Vault 用作生成与整个组织相关的 IAM 日志的中心位置。

AWS 以 AWS 密钥管理服务 (KMS) 的形式提供类似服务。 KMS 还支持 FIPS 140-2 级别 2 认证的 HSM，并且与 AWS CloudTrail 集成，以生成可审核的访问日志。 将 KMS 和 Azure Key Vault 集成到其各自的云平台中这一事实为这些平台中托管的应用程序提供了额外的安全性。 机密永远不会离开数据中心，因为使用机密的应用程序和存储机密的密钥保管库位于同一位置，这确实是更安全的机密。

对称加密非常适合用于加密静态数据，但在两方希望交换加密消息时会带来问题。 如果 Bob 加密了一条消息并将其发送给 Alice，那么 Alice 如何解密这条消息？ 如果 Bob 向 Alice 发送了解密密钥，则该密钥可能会被泄露（被盗），在这种情况下，Bob 和 Alice 指望的安全性实际上一点也不安全。 历史上不乏因此丢掉自己性命的人，因为他们认为私密的通信事实证明一点也不私密。 其中一个例子便是苏格兰的玛丽女王，她之所以被处死，是因为她在密谋暗杀伊丽莎白女王一世时使用了一种弱密码来模糊处理发送给同谋的消息¹。

在不公开解密密钥的情况下交换加密消息的这一挑战并不是一个学术难题。 每当连接到浏览器中的 https:// URL（应用程序访问第三方标识提供者）时以及其他时候，都将发生这种情况。 解决方案是使用非对称加密。 在非对称系统中，一个密钥用于加密消息，而另一个密钥用于解密消息。 这样，可以使用由收件人公开分发的密钥（公钥）对定向到特定收件人的消息进行加密。 只有第二个密钥可以用于解密使用公钥加密的消息。 此密钥由收件人保密，并成为私钥。 由于这个原因，有时将非对称密钥称为“公钥-私钥”。

如果 Bob 想要接收来自 Alice 的加密消息，则可以通过电子邮件向她发送公钥，或将公钥写在一张纸上并将其放在她的桌子上。 但如果浏览器需要来自 Web 服务器的公钥，并且还想验证它是否正在连接到它认为正在与其连接的服务器上，那么该如何操作？ 这里就会涉及到证书。

证书的目的是向将确定其持有者真实性的任何实体提供公钥。 证书颁发机构 (CA) 是此证书的制造者，并且可以通过物理验证每个寻求证书的个人或公司实体的身份来信任它。 因此，CA 使用可能受到质询和验证的代码对每个证书进行签名。

数字标识证书格式的国际标准是 X.509，该标准创建于 1998 年。 如图 3 所示，X.509 已有三个版本，新版本添加了涉及 CSP 的事务中必不可少的额外字段，特别是当多个提供商参与一项服务且那些参与方需要有关证书的发行者和签名者的额外信息时。

图 3：X.509 证书的组成部分。 [Courtesy Microsoft]

当浏览器使用 https:// URL 连接到 Web 服务器时，它将启动 TLS 握手，Web 服务器将在其中返回证书以验证其真实性并包含公钥。 但是它不使用公钥加密其传输到服务器的请求。 （可以，但是加密请求时，只有 Web 服务器才能解密请求。由于只有服务器拥有私钥，来自服务器的响应可能是不安全的，因为拥有公钥的任何人都可以解密请求。）相反，浏览器使用公钥加密传输到服务器的对称会话密钥。 此后，会话密钥用于加密（和解密）浏览器和 Web 服务器之间的所有通信。 因此，TLS 使用对称和非对称加密的组合：非对称加密用于加密对称密钥，而对称加密用于加密请求和响应。

证书并非仅由 Web 服务器使用。 它们也可供标识提供者和数据库服务器使用，分别用于加密凭据交换和加密数据库连接，等等。 简单来说，证书可在整个 Internet 和数据中心内使用，以保护移动数据。 云管理员的部分职责就是管理这些证书，包括从受信任的 CA 获得证书，将证书安装在 Web 服务器、数据库服务器、标识服务器以及其他需要它们的地方，并在证书过期之前对其进行更新。

随着加密逐渐发展成一个过程和一个行业，同态加密 (HE) 可能很快就会在数据安全方面发挥重要作用。 这是在技术上保持加密的同时从加密实体获取信息的一种方法。

HE 将取代非对称密钥管理，并以此代替对私钥管理系统或保管库的需求。 寻求身份验证的用户可以传递包含有效签名的证书，即使是用户也无法访问此签名。 此签名结果就是派生函数（例如哈希函数）。 为验证用户，标识提供者将从证书颁发机构获得加密的验证密钥，并使用该密钥提取签名，而无需实际解密证书。 目前正在对这一方法进行研究，并且大部分研究仅限于学术和研究机构。

1. Simon Singh. The Black Chamber. https://simonsingh.net/The_Black_Chamber/maryqueenofscots.html。