# 摘要
客户相信他们的数据是安全的，而加密则是维护这种机密性的机制。这些数据的例子包括，但不限于个人身份信息（PII）、密码和专有信息。通过使用密钥，数据从一个可读的格式 "纯文本 "转变为不可读的密码文本形式。 另一种思考方式是，我们使用密钥来加密/锁定数据，只有拥有相应密钥的另一方（可以是设备或个人）才能解密/解锁数据。本白皮书中的其他指导意见将帮助你保护客户分享和委托给你的敏感数据的安全。
# 数据保护政策（DPP）要求
**传输中的加密：**开发人员必须对传输中的所有亚马逊信息进行加密（例如，当数据穿越网络，或以其他方式在主机之间发送）。这至少可以使用HTTP over TLS 1.2（HTTPS）来完成。开发人员必须对客户使用的所有适用的外部端点以及内部通信渠道（例如，存储层节点之间的数据传播渠道，与外部依赖的连接）和操作工具实施这种安全控制。开发人员必须禁用不提供传输中加密的通信通道，即使是未使用的通道（例如，删除相关的死代码，只用加密通道配置依赖关系，并限制使用加密通道的访问凭证）。
开发人员必须使用数据消息级加密（例如，使用AWS Encryption SDK），其中通道加密（例如，使用TLS）终止于不信任的多租户硬件（例如，不信任的代理）。
**静态加密：**开发者必须使用行业最佳实践标准（如使用AES-128位或更大的密钥，首选AES-256位，或密钥大小为2048位（或更大）的RSA）对所有PII进行静态加密（例如，当数据被持续保存时）。用于静态PII加密的加密材料（如加密/解密密钥）和加密能力（如实施虚拟可信平台模块和提供加密/解密API的守护程序）必须只能被开发者的进程和服务访问。开发人员不得将PII存储在可移动媒体（如USB）或不安全的公共云应用程序（如通过Google Drive提供的公共链接）。
开发人员必须安全地处理任何含有PII的打印文件。
# 数据加密的基础
随着企业寻求更快、更大规模的运作，保护关键信息变得更加重要。通过加密确保数据安全，以一种使内容在没有秘密密钥解密为可读格式的情况下不可读的方式进行转换。加密是将明文编码为另一种被称为密码文的格式。为了加密一个信息（数据），需要一个密钥。通过数据加密，我们使用一个密钥，也被称为秘密，来加密（锁定）和解密（解锁）一个信息。只有拥有正确密钥的人/设备才能解密信息并阅读其内容。加密有助于保持亚马逊信息的安全。即使一个恶意的用户获得了密码文本，如果没有解密的密钥，他们也无法阅读信息的内容。此外，这些加密密钥必须在其整个生命周期内得到保护，以防止未经授权的使用、访问、披露和修改。请记住，哈希函数和加密之间是有区别的。散列函数是一种加密算法，用于将大的随机大小的数据转换成小的固定大小的数据。散列允许对数据进行验证。另一方面，加密是一个对信息进行加密和解密的两步过程。加密通过使数据在未经授权的情况下无法被理解来保护数据。数据在静止状态或传输过程中都可以被加密。 使用NIST 800-53作为其框架的开发者可以参考系统和通信保护（SC），以获得关于保护其环境的具体指导。NIST的主要控制之一是[SC-13加密保护]（https://nvd.nist.gov/800-53/Rev4/control/SC-13）。SC-13确定了具体的控制措施，提供了额外的细节，以帮助开发人员了解亚马逊MWS和SP-API的加密要求。
开发人员必须使用加密技术来保护亚马逊信息和客户PII。在以下部分，我们描述了数据加密的关键组成部分，并提供了一些建议，以帮助开发人员遵守亚马逊MWS和SP-API数据保护政策（DPP）的加密要求。
# 数据分类
数据分类提供了一种根据敏感程度对组织数据进行分类的方法。它包括了解有哪些数据类型、数据的存储位置、访问级别以及数据的安全性。亚马逊信息可以被分为两类数据。PII和非PII。PII数据是可以用来识别亚马逊客户的任何数据。非PII数据是任何其他亚马逊数据，例如产品列表信息。开发人员可以通过仔细管理适当的数据分类系统、访问级别和符合DPP要求的数据加密来保护亚马逊信息。可用于识别亚马逊客户的亚马逊信息必须被加密，必须以受保护的方式存储，并且必须要求有授权的访问。亚马逊建议采取深入防御的方法，减少人类对亚马逊客户PII的访问。开发人员必须在他们的应用程序中设置强大的认证机制。此外，开发人员必须确保他们的应用程序的所有连接都来自于受信任的网络，并具有必要的访问权限。
# 数据完整性
开发人员必须确保其系统中的亚马逊信息在通过其系统时保持其完整性。加密哈希函数是建立数据完整性的一种可靠方式。散列函数是一个不可逆的函数，其中任意大小的原始数据被映射到一个固定大小的散列值。如果开发者通过下载提供亚马逊信息，其完整性有两个主要威胁：由网络/存储问题引起的意外数据变化，以及攻击者的篡改。开发者可以通过使用散列函数来验证文件的完整性来减轻这些威胁。例如，开发者可以在提供下载之前对文件的内容进行散列。当文件被上传到应用程序时，开发者可以在上传的文件上运行哈希函数，并将哈希输出与原始文件的输出进行比较，以验证文件的完整性。这为防止数据变化提供了最好的保护，无论这些变化是由网络或存储问题意外造成的还是由攻击者故意造成的。开发人员可以通过用多个哈希函数验证哈希值来增加他们对数据完整性的信心。
# 转运中的加密
当数据从一个系统传输到另一个系统时，很容易受到未经授权的用户或第三方的不希望的干扰。数据传输可以被限制在开发者的私人或公共网络中，但仍然容易受到恶意攻击的影响。
开发者必须通过实施传输中的加密来保护亚马逊信息的传输，包括在其他服务和终端用户之间的通信。这有助于保护数据的保密性和完整性。
传输中加密通过使用支持的加密协议，如TLS 1.2，或HTTPS（HTTP over TLS）来保护信息。这种级别的加密必须在所有外部和内部的终端上执行。通过渠道传播的数据、与外部依赖关系的连接以及操作工具必须得到传输中加密的保护。当亚马逊信息被传输时，所使用的通信渠道必须被加密，这样就不可能有未经授权的干扰。最佳做法是对所有通信进行加密和验证。在NIST 800-53中，在控制[SC-8 Transmission Confidentiality and Integrity]（https://nvd.nist.gov/800-53/Rev4/control/SC-8）中概述了传输中加密。利用该控制的开发者应考虑采用SC-8控制的增强功能，因为每个增强功能都可以为传输中的数据提供额外的保护。
开发人员在对传输中的数据进行加密时应考虑以下几点。
- 禁用不能支持传输中加密的通信渠道。
- 避免通过多租户基础设施节点路由流量。
- 如果不允许使用端到端TLS，则使用数据消息级别的加密。
[block:image] { "图像"。[ { "图像"。[ "https://files.readme.io/6447d52-https_protocol.png", "https_protocol.png"。 1195, 356, "#091313" ] } ] } [/block] 图1：使用中的HTTPS协议。
表1列出了一些符合亚马逊标准的安全协议，用于对传输中的数据进行加密。
| Transfer Type | Insecure Protocols (Non-Compliant) | Secure Protocols (Compliant) |
|---|---|---|
| Web Access | HTTP | HTTPS with TLS 1.2+ |
| E-Mail Servers | POP3, SMTP, IMAP | POP3S, IMAPS, SMTPS |
| File Transfer | FTP, RCP | FTPS, SFTP, SCP, WebDAV over HTTPS |
| Remote Shell | Telnet | SSH-2 |
| Remote Desktop | VNC | r-admin, RDP |
表1：在传输过程中加密数据的安全与不安全的协议。
# 静态加密
任何时候，当开发者将亚马逊信息保存在数据存储中时，它都必须受到保护。数据存储是任何可以保存数据并保留一定时间的存储介质。数据库解决方案、块存储、对象存储和存档的数据块都是必须保护的数据存储的例子。开发人员可以使用加密来保护数据存储中的数据，这被称为静态加密。实施加密和适当的访问控制可以减少未经授权的访问风险。在NIST，静态加密在SC-28 Protection of Information at Rest (opens new window)中得到解释。SC-28(1)旨在通过加密技术保护静止信息，SC-28(2)旨在通过离线存储保护信息。正如亚马逊MWS和SP-API DPP中所解释的那样，处理亚马逊客户PII的开发人员需要进行这两种控制。最佳做法是在将亚马逊信息上传到存储目的地之前对其进行加密，并使用经批准的加密算法保护存储本身。这可以在两个层面上保护数据：在从源头到存储目的地的传输过程中，以及在存储目的地中静止的整个生命期。
使用Amazon S3进行存储的开发者可以使用S3的本地加密功能来保护静态数据。 你不是 "加密S3 "或 "加密S3桶"，而是S3在AWS数据中心写到磁盘时，会在对象层面上对你的数据进行加密。 开发人员可以选择两种方式进行加密，通过刚才描述的服务器端加密（SSE）的例子，或客户端加密（CSE）。
当开发者想要更多的控制权时，可以选择CSE，并承担编写如何加密和解密数据的代码的责任，决定加密算法，在哪里获得密钥，以及从哪里发送加密的数据。CSE发生在对象上传到S3之前被加密的时候（因此密钥不由AWS管理）。开发人员可以实施一个亚马逊S3桶策略，防止上传未加密的对象。如果开发者不需要管理主密钥，那么他们可以使用S3管理的加密密钥的服务器端加密（SSE-S3）或AWS KMS管理的密钥的服务器端加密（SSE-KMS）。亚马逊S3使用信封加密来保护休息时的数据。每个对象都用一个独特的密钥进行加密，采用强大的多因素加密。作为额外的保障，AWS用AWS KMS的密钥进行加密。亚马逊S3服务器端加密使用AES-256来加密数据。在图2中，加密解决方案既保护了加密密钥，也保护了数据。在其他渠道或云供应商中存储数据的开发者将能够利用他们原生的类似工具（例如Azure Key Vault和GCP Default Encryption）。
[block:image] { "图像"。[ { "图像"。[ "https://files.readme.io/3b6dfff-Encryption_at_rest.png", "Encryption_at_rest.png"。 1270, 958, "#743d2f" ] } ] } [/block] 图2：Amazon S3中的加密-静态。
欲了解更多信息，请参考。如何防止将未加密的对象上传到Amazon S3。 (opens new window)
# 加密的类型
这些是常见的加密类型。
- 对称加密。这利用了相同的密钥进行加密和解密。因此，发送方和接收方都必须有相同的密钥。
- 非对称加密：**非对称加密。这要求发送方和接收方使用不同的密钥 - 一个公开密钥和一个私人密钥。公钥被广泛共享，但私钥受到保护，只由其所有者使用。私钥用于加密数据，公钥用于解密数据。
- 信封加密。这是用一个加密密钥对数据进行加密，然后用另一个密钥对加密密钥进行加密的做法。
一般来说，对称密钥算法比非对称算法更快，产生的密码文本更小。但非对称算法提供了固有的角色分离和更容易的密钥管理。信封加密让开发者结合了对称和非对称算法的优势。当开发者对亚马逊信息进行加密时，加密密钥也必须得到保护。信封加密帮助开发者保护加密密钥本身。
使用SSE-KMS的开发者可以使用一个加密密钥对数据进行加密，并使用另一个密钥对该加密密钥进行加密。一个密钥仍然是明文，所以客户端能够解密加密密钥，并使用解密的加密密钥来解密数据。
顶层的明文密钥被称为AWS KMS密钥。
[block:image] { "图像"。[ { "图像"。[ "https://files.readme.io/dfd53cc-AWS_KMS_Storing.png", "AWS_KMS_Storing.png"。 1037, 202, "#a81e20" ] } ] } [/block] 图3：AWS KMS存储和管理AWS KMS的密钥。
欲了解更多信息，请参阅AWS密钥管理服务 (opens new window)。
密钥大小对于定义加密密钥的强度很重要。按照亚马逊DPP的要求，密钥的长度必须至少为128位。亚马逊建议开发者对亚马逊客户的PII使用大于128位的密钥（首选256位）。额外的位数会成倍增加针对加密密钥的暴力攻击的复杂性。一个256位的对称密钥需要的计算能力是128位密钥的2128倍。开发人员应该轮换他们的加密密钥以进一步保护他们的系统。尽管较大的密钥大小更难被破解，但暴露的密钥会使密钥大小变得无关紧要，因为未经授权的实体可以使用暴露的密钥来访问亚马逊信息。关于密钥旋转的具体指导可以在NIST 800-53控制[SC- 12 Cryptographic Key Establishment and Management]（https://nvd.nist.gov/800-53/Rev4/control/SC-12）中找到。SC-12控制及其增强功能可以帮助开发者以其组织可接受的方式建立、保护和轮换钥匙，同时确保钥匙在需要时仍然可用。
# 亚马逊API应用可接受的加密标准
以下是开发人员应使用的常用和推荐的加密标准的概述。
# 高级加密标准(AES)
高级加密标准（AES），是一种使用区块密码的对称性加密算法。区块密码将一个固定的文本块加密成一个等长的密码文本块。AES在一个长度为128位的固定长度块上操作，可配置的对称密钥长度为128、192或256位。即使是128位的密钥，通过检查2128个可能的密钥值来破解AES的任务（暴力攻击）是如此密集的计算，以至于最快的超级计算机平均需要超过100万亿年才能完成。如果开发者选择使用AES密钥，密钥大小必须是AES 128位或更大（按照亚马逊DPP的要求）。亚马逊建议使用AES-256。亚马逊也认可使用AES-GCM/CBC/XTS。
# Rivest-Shamir-Adlemen加密标准(RSA)
Rivest-Shamir-Adlemen加密标准（RSA），是一种非对称算法，使用公钥加密技术在不安全的网络上分享数据。RSA将两个大素数的乘积的大整数作为因子来建立密钥大小。它通常使用1024位或2048位的密钥。较大的密钥大小提供了更大的安全性，但使用更多的计算能力来加密和解密信息。如果开发者选择RSA作为他们的加密标准，他们必须确保他们的密钥至少是2048位，这是亚马逊DPP的要求。
# 其他加密算法
虽然开发人员可以使用其他加密标准，但亚马逊DPP要求开发人员使用AES或RSA。表2列出了亚马逊批准的加密算法。如果开发者使用其他行业标准的加密算法，而这些算法没有列在下面的表格中，他们应该联系security@amazon.com进行咨询。
| 加密算法 | Amazon批准的类型 |
|---|---|
| AES | 256-bit (preferred) 128-bit or larger keys |
| AES with GCM mode | 96-bit cryptographically random initialization vector 128-bit tag length |
| AES with CBC mode | 128-bit cryptographically random initialization vector PKCS7 padding |
| AES with XTS mode | Linux: dm-crypt, LUKS Amazon EBS encryption |
| RSA | 2048-bit or larger keys RSA with OAEP |
表2：亚马逊API应用程序批准的加密算法。
AWS软件开发工具包（SDK (opens new window)）提供了一个客户端加密库，简化了加密的实施。默认情况下，它实现了一个框架，以行业密码学的最佳实践来保证你的数据安全，如何使用独特的加密密钥和保护这些密钥。该SDK是在GitHub开源库上开发的，这样你就可以分析代码，提交问题，并找到特定于你的实现的信息。
# 不使用的标准
这些标准已经被业界研究并证明是不安全的。
- DES
- RC4
- 具有1024位密钥的RSA-PKCSv1.5
- 1024位密钥的RSA-OAEP
- 布洛菲
- 双鱼
# 加密的最佳做法
以下是加密亚马逊信息的一些最佳做法。
未受保护的数据，无论是在传输过程中还是在静态中，都会使企业容易受到攻击。开发人员应确保所有数据通过加密得到保护。开发人员应遵循这些最佳实践，对传输中和静止的数据进行强有力的保护。
实施强大的网络安全控制，帮助保护传输中的数据。例如，开发商可以使用防火墙和网络访问控制列表来保护其网络免受恶意软件攻击或入侵。
实施积极主动的安全措施，识别有风险的数据，并对传输中和静止的数据实施有效的数据保护。不要等到发生安全事件时才实施安全措施。
选择具有政策的解决方案，以实现用户提示和阻止，或对传输中的PII数据进行自动加密。例如，当带有PII数据的文件被附加到电子邮件中，大型或敏感数据文件集被传输到外部文件共享网站时，应用程序必须显示警告或阻止该动作。
创建政策，对所有亚马逊信息进行系统的分类和分级。
确保在数据处于静止状态时应用适当的数据保护措施，无论数据存储在何处。
当未经授权的各方访问、使用或转移任何数据时，生成触发器。
仔细评估用于存储亚马逊信息的公有云、私有云或混合云提供商，根据其提供的安全措施来保护数据安全。
运输中的数据和静止中的数据的风险情况略有不同，但其固有的风险主要取决于亚马逊信息的敏感性和价值。坏人会试图获取传输中或静止状态下的宝贵数据。对数据和安全协议进行分类和归类，以便在每个阶段有效地保护亚马逊信息是很重要的。你可以遵循的步骤。
将亚马逊信息分类为敏感级别，并对关键数据进行加密。亚马逊客户PII必须始终使用亚马逊认可的加密机制进行加密。
建立自动化策略，提示或自动对传输中的关键数据进行加密。
使用公开可用和同行评议的算法（如AES）和秘密密钥进行加密和解密。
使用云基础设施的开发人员必须根据他们提供的安全措施和他们持有的安全合规认证来评估云供应商。
# 结论
所有的数据，尤其是PII，在静止状态和传输过程中都应该进行加密保护。通过对客户委托给我们的数据进行加密，我们可以确保没有未经授权的各方可以访问和滥用数据以达到恶意的目的。你可以通过这里分享的加密标准等机制来实现这一目标，应用政策、访问控制和其他记录在案的最佳实践来进一步阅读。
# 进一步阅读
有关其他信息，请参考。
- 数据保护政策 (opens new window)
- 可接受的使用政策 (opens new window)
- 安全、身份和合规的最佳实践 (opens new window)
- 保护传输中的数据 (opens new window)
- 保护静止的数据 (opens new window)
- NIST 800-53 Rev.5: 信息系统和组织的安全和隐私控制 (opens new window)
# 文档历史
| Date | Description |
|---|---|
| July 2022 | Revised for technical accuracy. |
| January 2020 | First publication |
# 通知
客户有责任对本文件中的信息做出自己的独立评估。本文件：(a) 仅供参考，(b) 代表当前 AWS 的产品和做法，如有变化，恕不另行通知，(c) 不构成 AWS 及其附属机构、供应商或许可方的任何承诺或保证。AWS的产品或服务是 "按原样 "提供的，没有任何形式的保证、陈述或条件，无论是明示还是暗示。AWS对其客户的责任和义务由AWS协议控制，本文件不是AWS与其客户之间的任何协议的一部分，也没有修改。
© 2022年Amazon.com Services LLC或其附属机构。保留所有权利。