本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 安全性 AWS Transfer Family
云安全 AWS 是重中之重。作为 AWS 客户，您可以受益于专为满足大多数安全敏感型组织的要求而构建的数据中心和网络架构。
安全是双方共同承担 AWS 的责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的* 安全性和云*中* 的安全性：
要了解是否属于特定合规计划的范围，请参阅AWS 服务 “[按合规计划划分的范围](https://aws.amazon.com/compliance/services-in-scope/)” ”，然后选择您感兴趣的合规计划。 AWS 服务 有关一般信息，请参阅[AWS 合规计划AWS](https://aws.amazon.com/compliance/programs/)。
您可以使用下载第三方审计报告 AWS Artifact。有关更多信息，请参阅中的 “[下载报告” 中的 “ AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。
您在使用 AWS 服务 时的合规责任取决于您的数据的敏感性、贵公司的合规目标以及适用的法律和法规。有关您在使用时的合规责任的更多信息 AWS 服务，请参阅[AWS 安全文档](https://docs.aws.amazon.com/security/)。
本文档可帮助您了解在使用时如何应用分担责任模型 AWS Transfer Family。以下主题向您介绍如何进行配置 AWS Transfer Family 以满足您的安全和合规性目标。您还将学习如何使用其他 AWS 服务来帮助您监控和保护您的 AWS Transfer Family 资源。
我们提供一个研讨会，提供规范性指导和动手实验，介绍如何在无需修改现有应用程序或管理服务器基础架构 AWS 的情况下构建可扩展且安全的文件传输架构。您可以[在此处](https://catalog.workshops.aws/basic-security-workshop-transfer-family/en-US)查看本次研讨会的详细信息。
**Topics**
+ [VPC 连接安全优势](#vpc-connectivity-security)
+ [AWS Transfer Family 服务器的安全策略](security-policies.md)
+ [AWS Transfer Family SFTP 连接器的安全策略](security-policies-connectors.md)
+ [使用混合后量子密钥交换 AWS Transfer Family](post-quantum-security-policies.md)
+ [数据保护和加密](encryption-at-rest.md)
+ [在 Transfer Family 中管理 SSH 和 PGP 密钥](key-management.md)
+ [的身份和访问管理 AWS Transfer Family](security-iam.md)
+ [合规性验证 AWS Transfer Family](transfer-compliance.md)
+ [韧性在 AWS Transfer Family](disaster-recovery-resiliency.md)
+ [在 VPC 和之间创建私有连接 AWS Transfer Family APIs](vpc-api-endpoints.md)
+ [中的基础设施安全 AWS Transfer Family](infrastructure-security.md)
+ [添加 Web 应用程序防火墙](web-application-firewall.md)
+ [防止跨服务混淆代理](confused-deputy.md)
+ [AWS Transfer Famil AWS y 的托管政策](security-iam-awsmanpol.md)
## VPC 连接安全优势
具有 VPC 出口类型的 SFTP 连接器通过跨虚拟私有网络资源访问提供增强的安全优势：
+ **网络隔离**：所有流量都保留在您的 VPC 环境中，从而为私有终端节点连接提供与公共互联网的完全网络隔离。
+ **源 IP 控制**：远程 SFTP 服务器只能看到您的 VPC CIDR 范围中的 IP 地址，因此您可以完全控制用于连接的源 IP 地址。
+ **私有终端节点访问**：使用私有 IP 地址直接连接到 VPC 中的 SFTP 服务器，从而消除对公共互联网的暴露。
+ **混合连接**：通过已建立的 VPN 或 Direct Connect 连接安全地访问本地 SFTP 服务器，无需额外的互联网接入。
+ **VPC 安全控制**：利用现有 VPC 安全组和路由策略来控制和监控 SFTP 连接器流量。 NACLs
### VPC 莱迪思安全模型
SFTP 连接器的 VPC 连接使用 AWS VPC 莱迪思和服务网络来提供安全的多租户访问：
+ **混乱的副手预防**：身份验证和授权检查可确保连接器只能访问其配置的特定资源，从而防止未经授权的跨租户访问。
+ **IPv6仅限服务网络**：使用 IPv6寻址来避免潜在的 IP 地址冲突并增强安全隔离。
+ **转发访问会话 (FAS)**：临时凭证处理无需长期存储凭证或手动共享资源。
+ **资源级访问控制**：每个连接器都与特定的资源配置相关联，从而确保对各个 SFTP 服务器进行精细的访问控制。
### VPC 连接的安全最佳实践
使用 VPC 出口类型连接器时，请遵循以下安全最佳实践：
+ **安全组**：将安全组配置为仅允许必要资源之间的 SFTP 流量（端口 22）。将源和目标 IP 范围限制在所需的最小范围内。
+ **资源网关放置**：尽可能在私有子网中部署资源网关，并确保它们跨越至少两个可用区以实现高可用性。
+ **网络监控**：使用 VPC 流日志和 Amazon CloudWatch 监控网络流量模式并检测异常活动。
+ **访问日志**：启用连接器日志记录以跟踪文件传输活动并维护合规性要求的审计跟踪。
+ **资源配置管理**：定期检查和更新资源配置，确保它们指向正确的 SFTP 服务器并使用适当的网络设置。
# AWS Transfer Family 服务器的安全策略
中的服务器安全策略 AWS Transfer Family 允许您限制与服务器关联的一组加密算法（消息身份验证码 (MACs)、密钥交换 (KEXs)、密码套件、内容加密密码和哈希算法）。
AWS Transfer Family 支持使用混合密钥交换算法的后量子安全策略，将传统加密方法与后量子算法相结合，以提供针对未来量子计算威胁的增强安全性。详情请参见[使用混合后量子密钥交换 AWS Transfer Family](post-quantum-security-policies.md)。
有关支持的密钥算法的列表，请参阅 [加密算法](#cryptographic-algorithms)。有关支持的服务器主机秘钥和服务托管用户秘钥算法列表，请参见 [在 Transfer Family 中管理 SSH 和 PGP 密钥](key-management.md)。
**注意**
我们强烈建议将您的服务器更新为我们的最新安全政策。
`TransferSecurityPolicy-2024-01`是使用控制台、API 或 CLI 创建服务器时附加到服务器的默认安全策略。
如果您使用默认安全策略创建 Transfer Family 服务器 CloudFormation 并接受默认安全策略，则会分配该服务器`TransferSecurityPolicy-2018-11`。
如果您担心客户端兼容性，请明确说明在创建或更新服务器时您希望使用哪种安全策略，而不是使用默认策略，默认策略可能会发生变化。要更改服务器的安全策略，请参阅[编辑安全策略](edit-server-config.md#edit-cryptographic-algorithm)。
有关 Transfer Family 安全性的更多信息，请参阅以下博客文章：
+ [提高 AWS Transfer Family 服务器安全性的六个技巧](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/)
+ [Transfer Family 如何帮助您构建安全、合规的托管文件传输解决方案](https://aws.amazon.com/blogs/security/how-transfer-family-can-help-you-build-a-secure-compliant-managed-file-transfer-solution/)
**Topics**
+ [加密算法](#cryptographic-algorithms)
+ [TransferSecurityPolicy-2024-01](#security-policy-transfer-2024-01)
+ [TransferSecurityPolicy-SshAuditCompliant -2025-02](#security-policy-transferSecurityPolicy-SshAuditCompliant-2025-02)
+ [TransferSecurityPolicy-2023-05](#security-policy-transfer-2023-05)
+ [TransferSecurityPolicy-2022-03](#security-policy-transfer-2022-03)
+ [TransferSecurityPolicy-2020-06 和-Restricted-2020-06 TransferSecurityPolicy](#security-policy-transfer-2020-06)
+ [TransferSecurityPolicy-2018-11 和-Restricted-2018-11 TransferSecurityPolicy](#security-policy-transfer-2018-11)
+ [TransferSecurityPolicy-FIPS-2024-01/-FIPS-2024-05 TransferSecurityPolicy](#security-policy-transfer-fips-2024-01)
+ [TransferSecurityPolicy-FIPS-2023-05](#security-policy-transfer-fips-2023-05)
+ [TransferSecurityPolicy-FIPS-2020-06](#security-policy-transfer-fips-2020-06)
+ [TransferSecurityPolicy-AS2 限量版-2025-07](#as2-restricted-policy)
+ [后量子安全策略](#pq-policies)
## 加密算法
对于主机密钥，我们支持以下算法：
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
+ `ssh-ed25519`
此外，以下安全策略允许`ssh-rsa`：
+ TransferSecurityPolicy-2018-11
+ TransferSecurityPolicy-2020-06
+ TransferSecurityPolicy-FIPS-2020-06
+ TransferSecurityPolicy-FIPS-2023-05
+ TransferSecurityPolicy-FIPS-2024-01
+ TransferSecurityPolicy-pq-ssh-fips-Experimental-2023-04
**注意**
了解 RSA 密钥类型（始终是）和 RSA 主机密钥算法（可以是任何支持的算法`ssh-rsa`）之间的区别非常重要。
以下是各种安全策略支持的加密算法列表。
**注意**
在下表和策略中，请注意算法类型的以下用法。
SFTP 服务器仅使用**SshCiphers**SshKexs****、和**SshMacs**部分中的算法。
FTPS 服务器仅使用该**TlsCiphers**部分中的算法。
由于FTP服务器不使用加密，因此不使用任何这些算法。
AS2 服务器仅使用**ContentEncryptionCiphers**和**HashAlgorithms**部分中的算法。这些部分定义了用于加密和签名文件内容的算法。
FIPS-2024-05 和 FIPS-2024-01 的安全策略是相同的，只是 FIPS-2024-05 不支持该`ssh-rsa`算法。
Transfer Family推出了新的限制性政策，这些政策与现有政策非常相似：
TransferSecurityPolicy-Restricted-2018-11 和 TransferSecurityPolicy -2018-11 安全策略完全相同，唯一的不同是受限策略不支持密码。`chacha20-poly1305@openssh.com`
TransferSecurityPolicy-Restricted-2020-06 和 TransferSecurityPolicy -2020-06 安全策略相同，唯一的不同是受限策略不支持密码。`chacha20-poly1305@openssh.com`
\$1 在下表中，`chacha20-poly1305@openssh.com`密码仅包含在非限制策略中，
| 安全策略 | 2024-01 | SshAuditCompliant-2025-02 | 2023-05 | 2022-03 | **2020-06** **2020-06 受限制** | **FIPS-2024-05** **FIPS-2024-01** | FIPS-2023-05 | FIPS-2020-06 | **2018-11** **2018-11 受限制** | TransferSecurityPolicy-AS2 限量版-2025-07 |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |
| **SshCiphers** |
| --- |
| aes128-ctr | ♦ | ♦ | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| aes128-gcm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes192-ctr | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes256-ctr | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes256-gcm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| chacha20-poly1305@openssh.com | | | | | ♦\$1 | | | | ♦\$1 | |
| **SshKexs** |
| --- |
| mlkem768x25519-sha256 | | | | | | | | | | ♦ |
| mlkem768nistp256-sha256 | | | | | | | | | | ♦ |
| mlkem1024nistp384-sha384 | | | | | | | | | | ♦ |
| curve25519-sha256 | ♦ | ♦ | ♦ | ♦ | | | | | ♦ | ♦ |
| curve25519-sha256@libssh.org | ♦ | ♦ | ♦ | ♦ | | | | | ♦ | ♦ |
| diffie-hellman-group14-sha1 | | | | | | | | | ♦ | |
| diffie-hellman-group14-sha256 | | | | | ♦ | | | ♦ | ♦ | |
| diffie-hellman-group16-sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| diffie-hellman-group18-sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| diffie-hellman-group-exchange-sha256 | ♦ | ♦ | ♦ | ♦ | ♦ | | ♦ | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp256 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp384 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp521 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| **SshMacs** |
| --- |
| hmac-sha1 | | | | | | | | | ♦ | |
| hmac-sha1-etm@openssh.com | | | | | | | | | ♦ | |
| hmac-sha2-256 | | | | ♦ | ♦ | | | ♦ | ♦ | |
| hmac-sha2-256-etm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| hmac-sha2-512 | | | | ♦ | ♦ | | | ♦ | ♦ | |
| hmac-sha2-512-etm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| umac-128-etm@openssh.com | | | | | ♦ | | | | ♦ | |
| umac-128@openssh.com | | | | | ♦ | | | | ♦ | |
| umac-64-etm@openssh.com | | | | | | | | | ♦ | |
| umac-64@openssh.com | | | | | | | | | ♦ | |
| **ContentEncryptionCiphers** |
| --- |
| aes256-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes192-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes128-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| 3des-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| **HashAlgorithms** |
| --- |
| sha256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha1 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| **TlsCiphers** |
| --- |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | | | | | | | | | ♦ | |
| TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA256 | | | | | | | | | ♦ | |
## TransferSecurityPolicy-2024-01
以下显示了 TransferSecurityPolicy -2024-01 安全策略。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2024-01",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-SshAuditCompliant -2025-02
以下显示了 TransferSecurityPolicy-SshAuditCompliant -2025-02 安全策略。
**注意**
此安全策略是围绕该工具提供的建议设计的，并且与该`ssh-audit`工具100％兼容。
```
{
"SecurityPolicy": {
"Fips": false,
"Protocols": [
"SFTP",
"FTPS"
],
"SecurityPolicyName": "TransferSecurityPolicy-SshAuditCompliant-2025-02",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER"
}
}
```
## TransferSecurityPolicy-2023-05
以下显示了 TransferSecurityPolicy -2023-05 安全策略。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2023-05",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2022-03
以下显示了 TransferSecurityPolicy -2022-03 安全策略。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2022-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512",
"hmac-sha2-256"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2020-06 和-Restricted-2020-06 TransferSecurityPolicy
以下显示了 TransferSecurityPolicy -2020-06 安全策略。
**注意**
TransferSecurityPolicy-Restricted-2020-06 和 TransferSecurityPolicy -2020-06 安全策略相同，唯一的不同是受限策略不支持密码。`chacha20-poly1305@openssh.com`
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2020-06",
"SshCiphers": [
"chacha20-poly1305@openssh.com", //Not included in TransferSecurityPolicy-Restricted-2020-06
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256"
],
"SshMacs": [
"umac-128-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"umac-128@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2018-11 和-Restricted-2018-11 TransferSecurityPolicy
以下显示了 TransferSecurityPolicy -2018-11 的安全策略。
**注意**
TransferSecurityPolicy-Restricted-2018-11 和 TransferSecurityPolicy -2018-11 安全策略完全相同，唯一的不同是受限策略不支持密码。`chacha20-poly1305@openssh.com`
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2018-11",
"SshCiphers": [
"chacha20-poly1305@openssh.com", //Not included in TransferSecurityPolicy-Restricted-2018-11
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256",
"diffie-hellman-group14-sha1"
],
"SshMacs": [
"umac-64-etm@openssh.com",
"umac-128-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"hmac-sha1-etm@openssh.com",
"umac-64@openssh.com",
"umac-128@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512",
"hmac-sha1"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
"TLS_RSA_WITH_AES_128_CBC_SHA256",
"TLS_RSA_WITH_AES_256_CBC_SHA256"
]
}
}
```
## TransferSecurityPolicy-FIPS-2024-01/-FIPS-2024-05 TransferSecurityPolicy
以下显示了-FIPS-2024-0 TransferSecurityPolicy 1 和-FIPS-2024-05 安全策略。 TransferSecurityPolicy
**注意**
FIPS 服务终端节点以及 TransferSecurityPolicy-FIPS-2024-01 和-FIPS-2024-05 安全策略仅在 TransferSecurityPolicy某些地区可用。 AWS 有关更多信息，请参阅 *AWS 一般参考* 中的 [AWS Transfer Family 端点和配额](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)。
这两种安全策略之间的唯一区别是-FIPS-2024-01支持该算法，而 TransferSecurityPolicy-FIPS-2024-05不支持该`ssh-rsa`算法。 TransferSecurityPolicy
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2024-01",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-FIPS-2023-05
FIPS 认证详情 AWS Transfer Family 可在以下网址找到 [https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all)
下图显示了 TransferSecurityPolicy-FIPS-2023-05 安全策略。
**注意**
FIPS 服务终端节点和 TransferSecurityPolicy-FIPS-2023-05 安全策略仅在某些地区可用。 AWS 有关更多信息，请参阅 *AWS 一般参考* 中的 [AWS Transfer Family 端点和配额](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2023-05",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-FIPS-2020-06
FIPS 认证详情 AWS Transfer Family 可在以下网址找到 [https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all)
以下显示了 TransferSecurityPolicy-FIPS-2020-06 安全策略。
**注意**
FIPS 服务终端节点和 TransferSecurityPolicy-FIPS-2020-06 安全策略仅在某些地区可用。 AWS 有关更多信息，请参阅 *AWS 一般参考* 中的 [AWS Transfer Family 端点和配额](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2020-06",
"SshCiphers": [
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1",
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-AS2 限量版-2025-07
此安全策略专为需要通过排除传统加密算法来增强安全性的 AS2 文件传输而设计。它支持现代 AES 加密和 SHA-2 哈希算法，同时取消了对 3DES 和 SHA-1 等较弱算法的支持。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-AS2Restricted-2025-07",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"AS2"
]
}
}
```
## 后量子安全策略
下表列出了 Transfer Family 后量子安全策略算法。有关此策略的详细描述，请参见[使用混合后量子密钥交换 AWS Transfer Family](post-quantum-security-policies.md)。
政策列表如下表所示。
**注意**
**较早的后量子政策（**TransferSecurityPolicy-pq-ssh-experimental-2023-04 和-pq-ssh-fips-experimental-2023-04）已被弃**用。TransferSecurityPolicy**我们建议您改用新政策。
| 安全策略 | TransferSecurityPolicy-2025-03 | TransferSecurityPolicy-FIPS-2025-03 |
| --- |--- |--- |
| **SSH ciphers** |
| --- |
| aes128-ctr | ♦ | ♦ |
| aes128-gcm@openssh.com | ♦ | ♦ |
| aes192-ctr | ♦ | ♦ |
| aes256-ctr | ♦ | ♦ |
| aes256-gcm@openssh.com | ♦ | ♦ |
| **KEXs** |
| --- |
| mlkem768x25519-sha256 | ♦ | ♦ |
| mlkem768nistp256-sha256 | ♦ | ♦ |
| mlkem1024nistp384-sha384 | ♦ | ♦ |
| diffie-hellman-group14-sha256 | ♦ | ♦ |
| diffie-hellman-group16-sha512 | ♦ | ♦ |
| diffie-hellman-group18-sha512 | ♦ | ♦ |
| ecdh-sha2-nistp384 | ♦ | ♦ |
| ecdh-sha2-nistp521 | ♦ | ♦ |
| ecdh-sha2-nistp256 | ♦ | ♦ |
| diffie-hellman-group-exchange-sha256 | ♦ | ♦ |
| curve25519-sha256@libssh.org | ♦ | |
| curve25519-sha256 | ♦ | |
| **MACs** |
| --- |
| hmac-sha2-256-etm@openssh.com | ♦ | ♦ |
| hmac-sha2-512-etm@openssh.com | ♦ | ♦ |
| **ContentEncryptionCiphers** |
| --- |
| aes256-cbc | ♦ | ♦ |
| aes192-cbc | ♦ | ♦ |
| aes128-cbc | ♦ | ♦ |
| 3des-cbc | ♦ | ♦ |
| **HashAlgorithms** |
| --- |
| sha256 | ♦ | ♦ |
| sha384 | ♦ | ♦ |
| sha512 | ♦ | ♦ |
| sha1 | ♦ | ♦ |
| **TLS ciphers** |
| --- |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ |
### TransferSecurityPolicy-2025-03
以下显示了 TransferSecurityPolicy -2025-03 安全策略。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2025-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
### TransferSecurityPolicy-FIPS-2025-03
以下显示了 TransferSecurityPolicy-FIPS-2025-03 安全策略。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2025-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr",
"aes128-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
### TransferSecurityPolicy-AS2 限量版-2025-07
以下显示了 TransferSecurityPolicy-AS2 限制型 2025-07 安全策略。
**注意**
此安全策略与 TransferSecurityPolicy -2025-03 相同，不同之处在于它不支持 3DES（in ContentEncryptionCiphers），也不支持 SHA1 （in）。 HashAlgorithms它包括2025-03年的所有算法，包括后量子加密算法（mlkem\$1）。 KEXs
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-AS2Restricted-2025-07",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
# AWS Transfer Family SFTP 连接器的安全策略
中的 SFTP 连接器安全策略 AWS Transfer Family 允许您限制与 SFTP 连接器关联的一组加密算法（消息身份验证码 (MACsKEXs)、密钥交换 () 和密码套件）。以下是每个 SFTP 连接器安全策略支持的加密算法列表。
**注意**
`TransferSFTPConnectorSecurityPolicy-2024-03`是应用于 SFTP 连接器的默认安全策略。
您可以更改连接器的安全策略。从 T **r** ansfer Family 左侧导航窗格中选择 “连接器”，然后选择您的连接器。然后在 **Sftp 配置**部分中选择**编辑**。在 “**加密算法选项**” 部分，从 “安全策略” 字段的下拉列表中选择任何可用的**安全策略**。
## 加密算法
对于主机密钥，SFTP 连接器支持 Transfer Family 服务器支持的所有算法，ed25519 除外：
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
此外，对于主机密钥，我们支持`ssh-rsa`，但仅支持`TransferSFTPConnectorSecurityPolicy-2023-07`。
对于身份验证，SFTP 连接器支持以下密钥类型：
+ `ssh-rsa`
+ `ecdsa`
## SFTP 连接器安全策略详细信息
下表显示了每个 SFTP 连接器安全策略支持的特定加密算法。
| 安全策略 | 转账 SFTPConnector SecurityPolicy-FIPS-2024-10 | 转账 SFTPConnector SecurityPolicy -2024-03 | 转会 SFTPConnector SecurityPolicy -2023-07 |
| --- |--- |--- |--- |
| **Ciphers** |
| --- |
| aes128-ctr | | | ♦ |
| aes128-gcm@openssh.com | ♦ | ♦ | ♦ |
| aes192-ctr | | ♦ | ♦ |
| aes256-ctr | | ♦ | ♦ |
| aes256-gcm@openssh.com | ♦ | ♦ | ♦ |
| **Kexs** |
| --- |
| curve25519-sha256 | | ♦ | ♦ |
| curve25519-sha256@libssh.org | | ♦ | ♦ |
| diffie-hellman-group14-sha1 | | | ♦ |
| diffie-hellman-group16-sha512 | | ♦ | ♦ |
| diffie-hellman-group18-sha512 | | ♦ | ♦ |
| diffie-hellman-group-exchange-sha256 | | ♦ | ♦ |
| ecdh-sha2-nistp256 | ♦ | | |
| ecdh-sha2-nistp384 | ♦ | | |
| ecdh-sha2-nistp521 | ♦ | | |
| **Macs** |
| --- |
| hmac-sha2-512-etm@openssh.com | | ♦ | ♦ |
| hmac-sha2-256-etm@openssh.com | | ♦ | ♦ |
| hmac-sha2-512 | ♦ | ♦ | ♦ |
| hmac-sha2-256 | ♦ | ♦ | ♦ |
| hmac-sha1 | | | ♦ |
| hmac-sha1-96 | | | ♦ |
| **Host Key Algorithms** |
| --- |
| rsa-sha2-256 | ♦ | ♦ | ♦ |
| rsa-sha2-512 | ♦ | ♦ | ♦ |
| ecdsa-sha2-nistp256 | ♦ | ♦ | ♦ |
| ecdsa-sha2-nistp384 | | ♦ | ♦ |
| ecdsa-sha2-nistp521 | | ♦ | ♦ |
| ssh-rsa | | | ♦ |
# 使用混合后量子密钥交换 AWS Transfer Family
Transfer Family 支持安全外壳 (SSH) 协议的混合后量子密钥建立选项。之所以需要建立后量子密钥，是因为已经有可能记录网络流量并将其保存以备将来由量子计算机解密，这被称为攻击。*store-now-harvest-later*
当您连接至 Transfer Family，您可使用此选项，将在 Amazon Simple Storage Service (Amazon S3) 存储或 Amazon Elastic File System (Amazon EFS) 内外安全传输文件。SSH 中的后量子混合密钥创建引入了后量子密钥建立机制，该机制与经典的密钥交换算法结合使用。通过传统密码套件创建的 SSH 密钥可以免受当前技术的暴力攻击。但是，在未来大规模量子计算出现之后，预计传统加密依然无法保证安全。
如果您的组织需要使 Transfer Family 连接传输的数据保持长期机密性，在目前没有大规模后量子计算机的情况下，可考虑改用后量子密码技术。
为了保护当今加密的数据免受未来潜在的攻击， AWS 正在与密码学界一起开发抗量子算法或后量子算法。我们在 Transfer Family 中实施了混合后量子密钥交换密码套件，通过将传统加密算法与后量子算法相结合。
这些混合密码套件可以在大多数 AWS 区域中用于您的生产工作负载。不过，由于混合密码套件的性能特征及带宽要求与传统密钥交换机制的性能特征及带宽要求有所不同，我们建议您针对您的 Transfer Family 连接开展测试。
在[后量子密码学](https://aws.amazon.com/security/post-quantum-cryptography/)安全博客文章中了解后量子密码的更多信息。
**Contents**
+ [关于 SSH 中的后量子混合密钥交换](#pq-about-key-exchange)
+ [后量子混合密钥创建如何在 Transfer Family 中运行](#pqtls-details)
+ [为什么 ML-KEM？](#why-mlkem)
+ [后量子混合 SSH 密钥交换和加密要求 (FIPS 140)](#pq-alignment)
+ [在 Transfer Family 中测试后量子混合密钥交换](#pq-policy-testing)
+ [在 SFTP 端点启用后量子混合密钥交换](#pq-enable-policy)
+ [设置支持后量子混合密钥交换的 SFTP 客户端](#pq-client-openssh)
+ [确认 SFTP 中的后量子混合密钥交换](#pq-verify-exchange)
## 关于 SSH 中的后量子混合密钥交换
Transfer Family 支持后量子混合密钥交换密码套件，该套件同时使用经典的 El [liptic Curve Diffie-Hellman (ECDH) 密钥交换算法和 ML-](https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final) KEM。ML-KEM是一种后量子公钥加密和密钥建立算法，[美国国家标准与技术研究所（NIST）已将其指定为其第一个标准](https://csrc.nist.gov/projects/post-quantum-cryptography)的后量子密钥协议算法。
客户端和服务器仍进行 ECDH 密钥交换。此外，服务器将后量子共享密钥封装至客户端后量子 KEM 公钥，该公钥参见客户端的 SSH 密钥交换消息。该策略将经典密钥交换的高度保证与拟议的后量子密钥交换的安全性相结合，以帮助确保只要 ECDH 或后量子共享机密无法破解，握手就会受到保护。
## 后量子混合密钥创建如何在 Transfer Family 中运行
AWS 最近宣布支持在 SFTP 文件传输中进行后量子密钥交换。 AWS Transfer Family Transfer Family 使用 SFTP 和其他协议安全地将 business-to-business文件传输扩展到 AWS 存储服务。SFTP 是 SSH 运行的文件传输协议 (FTP) 的更安全的版本。Transfer Family 的后量子密钥交换支持提高了 SFTP 传输数据的安全门槛。
Transfer Family 中对后量子混合密钥交换 SFTP 的支持包括将后量子算法 ML-KEM-768 和 ML-KEM-1024 与 P256、P384 或 Curve25519 曲线上的 ECDH 相结合。[后量子混合 SSH 秘钥交换草稿](https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/)中指定以下对应的 SSH 秘钥交换方法。
+ `mlkem768nistp256-sha256`
+ `mlkem1024nistp384-sha384`
+ `mlkem768x25519-sha256`
### 为什么 ML-KEM？
AWS 致力于支持标准化、可互操作的算法。ML-KEM 是 [NIST](https://csrc.nist.gov/projects/post-quantum-cryptography) 后量子密码学项目标准化和批准的唯一一种后量子密钥交换算法。标准机构已经在将 ML-KEM 整合到协议中。 AWS 已在某些 AWS API 端点中支持 TLS 中的 ML-KEM。
作为该承诺的一部分， AWS 已向IETF提交了一份后量子加密提案草案，该提案将ML-KEM与NIST批准的曲线（例如用于SSH的P256）相结合。为了帮助增强客户的安全性，在 SFTP 和 SSH 中 AWS 实施后量子密钥交换遵循了该草案。在我们的提案被 IETF 采纳并成为标准之前，我们计划支持未来更新。
随着草案向标准化发展，新的密钥交换方法（列于本节[后量子混合密钥创建如何在 Transfer Family 中运行](#pqtls-details)）可能会发生变化。
**注意**
后量子算法支持在 TLS 中用于后量子混合密钥交换 AWS KMS （参见[使用混合后量子 TLS AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html)）和 AWS Secrets Manager API AWS Certificate Manager端点。
### 后量子混合 SSH 密钥交换和加密要求 (FIPS 140)
对于需要符合 FIPS 标准的客户，Transfer Family 使用 FIPS 140 认证的开源加密库-LC 在 SSH 中提供 AWS FIPS 认可的加密。 AWS[根据NIST的SP 800-56Cr2（第2节），Tran TransferSecurityPolicy sfer Family中-FIPS-2025-03中支持的后量子混合密钥交换方法已获得FIPS的](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf)批准。德国联邦信息安全办公室 ([BSI](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html)) 和法国国家信息系统安全局 ([ANSSI](https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/)) 也推荐了这种后量子混合密钥交换方法。
## 在 Transfer Family 中测试后量子混合密钥交换
本节介绍测试后量子混合密钥交换所需步骤。
1. [在 SFTP 端点启用后量子混合密钥交换](#pq-enable-policy).
1. 遵循上述规范草案中的指导，使用支持后量子混合密钥交换的 SFTP 客户端 (例如 [设置支持后量子混合密钥交换的 SFTP 客户端](#pq-client-openssh))。
1. 通过 Transfer Family 服务器传输文件。
1. [确认 SFTP 中的后量子混合密钥交换](#pq-verify-exchange).
### 在 SFTP 端点启用后量子混合密钥交换
当您在 Transfer Family 创建 SFTP 服务器端点时，您可选择 SSH 策略，或在现有 SFTP 端点编辑加密算法选项。以下快照显示了您在 AWS 管理控制台 何处更新 SSH 策略的示例。
![\[显示为加密算法选项选定的后量子策略。\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/post-quantum-policy-choose.png)
**支持后量子密钥交换的 SSH 策略名称为 **TransferSecurityPolicy-2025-03 和-FIPS-2025-03**。TransferSecurityPolicy**有关 Transfer Family 政策的更多详情，请参阅 [AWS Transfer Family 服务器的安全策略](security-policies.md)。
### 设置支持后量子混合密钥交换的 SFTP 客户端
在 SFTP Transfer Family 端点中选择正确的后量子 SSH 策略后，您可以在 Transfer Family 中尝试后量子 SFTP。在本地系统上安装最新的 OpenSSH 客户端（例如 9.9 版）进行测试。
**注意**
确保您的客户端支持前面列出的一种或多种 ML-KEM 算法。您可以通过运行以下命令来查看您的OpenSSH版本支持的算法:. `ssh -Q kex`
您可以运行示例 SFTP 客户端，通过使用后量子混合密钥交换方法连接到 SFTP 端点（例如`s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com`），如以下命令所示。
```
sftp -v -o \
KexAlgorithms=mlkem768x25519-sha256 \
-i username_private_key_PEM_file \
username@server-id.server.transfer.region-id.amazonaws.com
```
在上一个命令中，将以下项目替换为您自己的信息：
+ *username\$1private\$1key\$1PEM\$1file*替换为 SFTP 用户的私钥 PEM 编码文件
+ 替换*username*为 SFTP 用户名
+ *server-id*替换为 Transfer Family 服务器 ID
+ *region-id*替换为 Transfer Family 服务器所在的实际区域
### 确认 SFTP 中的后量子混合密钥交换
要确认 SFTP 至 Transfer Family 的 SSH 连接期间是否使用了后量子混合密钥交换，请查看客户端输出。或者您可以使用数据包捕获程序。如果您使用 OpenSSH 9.9 客户端，则输出应类似于以下内容（为了简洁起见，省略了不相关的信息）：
```
% sftp -o KexAlgorithms=mlkem768x25519-sha256 -v -o IdentitiesOnly=yes -i username_private_key_PEM_file username@s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com
OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 146: Applying options for *
debug1: Reading configuration data /Users/username/.ssh/bastions-config
debug1: Reading configuration data /opt/homebrew/etc/ssh/ssh_config
debug1: Connecting to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com [xxx.yyy.zzz.nnn] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: compat_banner: no match: AWS_SFTP_1.1
debug1: Authenticating to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com:22 as 'username'
debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Ic1Ti0cdDmFdStj06rfU0cmmNccwAha/ASH2unr6zX0
[...]
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
[...]
Authenticated to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com ([xxx.yyy.zzz.nnn]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
[...]
Connected to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com.
sftp>
```
输出显示使用后量子混合 `mlkem768x25519-sha256` 方法执行的、以及成功创建 SFTP 会话的客户端协商。
# 数据保护和加密
AWS [分担责任模型分担责任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于 AWS Transfer Family （Transfer Family）中的数据保护。如本模型所述 AWS ，负责保护运行所有 AWS 云的全球基础架构。您负责维护对托管在此基础结构上的内容的控制。此内容包括您使用的 AWS 服务的安全配置和管理任务。有关数据隐私的更多信息，请参阅[数据隐私常见问题](https://aws.amazon.com/compliance/data-privacy-faq)。有关欧洲数据保护的信息，请参阅 *AWS 安全性博客*中的 [AWS 责任共担模式和 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 博客文章。
出于数据保护目的，我们建议您保护 AWS 账户凭据并使用设置个人用户帐户 AWS IAM Identity Center。这仅向每个用户授予履行其工作职责所需的权限。我们还建议您通过以下方式保护数据：
+ 对每个账户使用多重身份验证（MFA）。
+ 用于 SSL/TLS 与 AWS 资源通信。支持 TLS 1.2。
+ 使用设置 API 和用户活动日志 AWS CloudTrail。
+ 使用 AWS 加密解决方案以及 AWS 服务中的所有默认安全控制。
+ 使用高级托管安全服务（例如 Amazon Macie），它有助于发现和保护存储在 Amazon S3 中的个人数据。
+ 如果在通过命令行界面或 API 访问 AWS 时需要经过 FIPS 140-2 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅[美国联邦信息处理标准 (FIPS) 第 140-2 版](https://aws.amazon.com/compliance/fips/)。
我们强烈建议您切勿将敏感的可识别信息（例如您客户的账号）放入自由格式字段（例如**名称**字段）。这包括您使用控制台、API 或使用 Tr AWS ansfer Family AWS CLI或其他服务时 AWS SDKs。您输入至 Transfer Family 服务配置或其他服务配置中的数据可选择并纳入诊断日志。当您向外部服务器提供网址时，请勿在网址中包含凭证信息来验证您对该服务器的请求。
相比之下，来自 Transfer Family 服务器的上传和下载数据被视为完全私密，永远不会存在于SFTP 或 FTPS 连接等加密通道之外 。仅经过授权的人员才能访问这些数据。
## Transfer Family 中的数据加密
AWS Transfer Family 使用您为 Amazon S3 存储桶设置的默认加密选项来加密您的数据。如果对存储桶启用加密，则存储到该存储桶中的所有对象都会进行加密。这些对象使用服务器端加密，使用 Amazon S3 托管密钥 (SSE-S3) 或 () 托管密钥 AWS Key Management Service (SSE-KMS AWS KMS) 进行加密。有关服务器端加密的更多信息，请参阅 *Amazon Simple Storage Service 用户指南*中的[使用服务器端加密保护数据](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html)。
以下步骤向您展示了如何加密中的数据 AWS Transfer Family。
**允许加密 AWS Transfer Family**
1. 为 Amazon S3 存储桶启用默认加密。有关更多详细信息，请参阅 *Amazon Simple Storage Service 用户指南*中的[适用于 S3 存储桶的 Amazon S3 默认加密](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)。
1. 更新附加到用户的 AWS Identity and Access Management (IAM) 角色策略以授予所需的 AWS Key Management Service (AWS KMS) 权限。
1. 如果您为用户使用会话策略，则会话策略必须授予所需的 AWS KMS 权限。
以下示例显示了一个 IAM 策略，该策略授予与启用 AWS KMS 加密的 Amazon S3 存储桶 AWS Transfer Family 一起使用时所需的最低权限。如果您使用用户 IAM 角色策略和会话策略，请将此示例策略包含在其中。
```
{
"Sid": "Stmt1544140969635",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey",
"kms:GetPublicKey",
"kms:ListKeyPolicies"
],
"Effect": "Allow",
"Resource": "arn:aws:kms:region:account-id:key/kms-key-id"
}
```
**注意**
您在此策略中指定的 KMS 密钥 ID 必须与步骤 1 中为默认加密指定的密钥 ID 相同。
AWS KMS 密钥策略中必须允许根角色或用户使用的 IAM 角色。有关 AWS KMS 密钥策略的信息，请参阅*AWS Key Management Service 开发人员指南*[中的在 AWS KMS 中使用密钥策略](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)。
## AWS Transfer Family 静态加密
由于 AWS Transfer Family 是一项文件传输服务，因此它不管理您的静态存储数据。 AWS Transfer Family 支持的存储服务和系统负责保护处于该状态的数据。但是，有些与服务相关的数据是静态 AWS Transfer Family 管理的。
### 什么是加密？
唯一 AWS Transfer Family 可以处理的静态数据与操作文件传输服务器和处理传输所需的详细信息有关。 AWS Transfer Family 在 Amazon DynamoDB 中使用完全静态加密存储以下数据：
+ 服务器配置（例如，服务器设置、协议配置和端点详细信息）。
+ 用户身份验证数据，包括 SSH 公钥和用户元数据。
+ 工作流程执行详细信息和步骤配置。
+ 第三方系统的连接器配置和身份验证凭证。这些凭证使用 AWS Transfer Family 托管加密密钥进行加密。
#### 密钥管理
您无法管理用于在 DynamoDB 中存储与运行服务器和处理传输相关的信息的加密密钥。 AWS Transfer Family 这些信息包括您的服务器配置、用户身份验证数据、工作流程详细信息和连接器凭据。
### 哪些内容未加密？
尽管 AWS Transfer Family 不能控制存储数据的静态加密方式，但我们仍然建议您配置存储位置所支持的最高安全级别。例如，您可以使用 Amazon S3 托管加密密钥 (SSE-S3) 或密 AWS KMS 钥 (SSE-KMS) 加密对象。
详细了解 AWS 存储服务如何加密静态数据：
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html)
# 在 Transfer Family 中管理 SSH 和 PGP 密钥
在本节中，您可以找到有关 SSH 密钥的信息，包括如何生成密钥以及如何轮换的信息。有关使用 Transfer Family AWS Lambda 来管理密钥的详细信息，请参阅博客文章 “使用[AWS Transfer Family 和启用用户自助服务密钥管理](https://aws.amazon.com/blogs/storage/enabling-user-self-service-key-management-with-aws-transfer-family-and-aws-lambda/)” AWS Lambda。有关自动部署和管理拥有多个 SSH 密钥的用户，请参阅[Transfer Family terraform 模块](terraform.md)。
**注意**
AWS Transfer Family 接受用于 SSH 身份验证的 RSA、ECDSA 和 ED25519 密钥。
本节还介绍如何生成与管理 Pretty Good Privacy (PGP) 密钥。
有关所有支持的加密和密钥算法的全面概述，包括针对不同用例的建议，请参阅[加密和密钥算法概述](#encryption-algorithms-overview)。
## 加密和密钥算法概述
AWS Transfer Family 支持用于不同目的的不同类型的算法。了解针对您的特定用例使用哪些算法有助于确保文件传输的安全性和兼容性。
**算法快速参考**
| 使用场景 | 推荐算法 | 符合 FIPS | 注意 |
| --- | --- | --- | --- |
| SSH/SFTP 身份验证 | RSA (rsa-sha2-256/512)、ECDSA 或 ED25519 | RSA：是的，ECDSA：是，：否 ED25519 | 与所有 SSH 客户端和服务器兼容 |
| PGP 密钥生成 | RSA 或 ECC (NIST) | 是 | 用于工作流程解密 |
| PGP 文件加密 | AES-256 | 是 | 由 PGP 软件决定 |
## SSH 身份验证算法
这些算法用于在客户端和 AWS Transfer Family 服务器之间进行 SSH/SFTP 身份验证。在为用户身份验证或服务器主机密钥生成 SSH 密钥对时，请选择其中一个。
RSA（推荐）
**与所有 SSH 客户端和服务器兼容，并且符合 FIPS。**与 SHA-2 哈希一起使用可增强安全性：
+ `rsa-sha2-256`-推荐用于大多数用例
+ `rsa-sha2-512`-更高的安全性选项
ED25519
**现代而高效。**密钥大小更小，安全性强：
+ `ssh-ed25519`-快速安全，但不符合 FIPS
ECDSA
**椭圆曲线选项。**安全性和性能的良好平衡：
+ `ecdsa-sha2-nistp256`-标准曲线
+ `ecdsa-sha2-nistp384`-更高的安全性曲线
+ `ecdsa-sha2-nistp521`-最高安全性曲线
**注意**
我们 SHA1 支持`ssh-rsa`较旧的安全策略。有关更多信息，请参阅 [加密算法](security-policies.md#cryptographic-algorithms)。
**选择正确的 SSH 算法**
+ **对于大多数用户：将** RSA 与或一起`rsa-sha2-256`使用 `rsa-sha2-512`
+ **为了符合 FIPS 标准：**使用 RSA 或 ECDSA 算法
+ **适用于现代环境：** ED25519 提供卓越的安全性和性能
## PGP 加密和解密算法
PGP（Pretty Good Privacy）使用两种类型的算法协同工作来加密和解密工作流程中的文件：
1. **密钥对算法**-用于生成用于加密和数字签名的密 public/private 钥对
1. **对称算法**-用于加密实际文件数据（key pair 算法加密对称密钥）
### PGP key pair 算法
生成用于工作流解密的 PGP 密钥对时，请选择以下算法之一：
RSA（推荐）
**建议大多数用户使用。**广泛支持、成熟且符合 FIPS 标准。在安全性和兼容性之间取得了良好的平衡。
ECC（椭圆曲线密码学）
在保持强大安全性的同时，密钥大小较小，**比 RSA 更高效**：
+ **NIST 曲线**-广泛支持标准曲线且符合 FIPS
+ **BrainPool 曲线**-针对特定合规要求的替代曲线
+ **Curve25519**-现代高性能曲线提供强大的安全性和高效的计算
ElGamal
**传统算法。**支持与旧系统兼容。使用 RSA 或 ECC 进行新的实现。
有关生成 PGP 密钥的详细说明，请参阅[生成 PGP 密钥](generate-pgp-keys.md)。
### PGP 对称加密算法
这些算法会加密您的实际文件数据。使用的算法取决于 PGP 软件创建 PGP 文件的方式：
**符合 FIPS 的算法（建议在受监管的环境中使用）**
+ **AES-128、AES-192、AES-256**-高级加密标准（推荐）
+ **3DES**-三重数据加密标准（旧版，尽可能使用 AES）
**其他支持的算法**
+ IDEA、 CAST5、Blowfish、DES TwoFish、、CAMELLIA-128、CAMELLIA-192、CAMELLIA-256
**注意**
使用 AWS Transfer Family 工作流程时，您不会直接选择对称算法，而是由用于创建加密文件的 PGP 软件决定的。但是，您可以将 PGP 软件配置为首选符合 FIPS 的算法，例如 AES-256。
有关支持的对称算法的更多信息，请参见[支持的对称加密算法](nominal-steps-workflow.md#symmetric-algorithms)。
# 为服务托管用户生成 SSH 密钥
您可以设置服务器以使用服务管理的身份验证方法对用户进行身份验证，其中用户名和 SSH 密钥存储在服务中。用户的公有 SSH 密钥作为用户属性上传到服务器。服务器将此密钥用作密钥标准身份验证过程的一部分。每个用户均可使用单个服务器存档多个公有 SSH 密钥。有关每个用户可以存储的密钥数量限制，请参阅中的 *Amazon Web Services 一般参考* 中的 [AWS Transfer Family 端点和配额](https://docs.aws.amazon.com//general/latest/gr/transfer-service.html)。
作为服务托管身份验证方法的替代方法，您可以使用自定义身份提供商对用户进行身份验证，或者 AWS Directory Service for Microsoft Active Directory。有关更多信息，请参阅 [使用自定义身份提供程序](custom-idp-intro.md)或 [使用微软 Active Directory 的 AWS 目录服务](directory-services-users.md)。
服务器只能使用一种方法（服务托管、目录服务或自定义身份提供程序）对用户进行身份验证，并且该方法在创建服务器后无法更改。
**Topics**
+ [在 macOS、Linux 或 Unix 系统创建 SSH 密钥](macOS-linux-unix-ssh.md)
+ [在 Microsoft Windows 上创建 SSH 密钥](windows-ssh.md)
+ [将 SSH2 密钥转换为 SSH 公钥格式](convert-ssh2-public-key.md)
# 在 macOS、Linux 或 Unix 系统创建 SSH 密钥
在 macOS、Linux 或 Unix 操作系统中，您可以使用 `ssh-keygen` 命令创建 SSH 公钥和 SSH 私钥（也称为密钥对）。
**注意**
在以下示例中，我们未指定密码：在这种情况下，该工具会要求您输入密码，然后重复密码进行验证。创建密码可以更好地保护您的私钥，还可以提高系统整体安全性。您无法恢复密码：如果您忘记了密码，则必须创建新的密钥。
但是，如果要生成服务器主机密钥，则*必须*通过在命令中指定 `-N ""` 选项（或者在出现提示时按 **Enter** 两次）指定空密码，原因是 Transfer Family 服务器无法在启动时请求密码。
**若要在 macOS、Linux 或 Unix 操作系统上创建 SSH 密钥**
1. 在 macOS、Linux 或 Unix 操作系统，打开命令终端。
1. AWS Transfer Family 接受 RSA-、ECDSA-和 ED25519-格式的密钥。根据您生成的密钥对类型选择相应的命令。
**提示**：`key_name`替换为 SSH 密钥对文件的实际名称。
+ 生成 RSA 4096 位密钥对：
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ 若要生成 ECDSA 521 位密钥对（ECDSA 大小为 256、384 和 521），请执行以下操作：
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ 要生成 ED25519 密钥对，请执行以下操作：
```
ssh-keygen -t ed25519 -f key_name
```
下面是 `ssh-keygen` 输出的示例。
```
ssh-keygen -t rsa -b 4096 -f key_name
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in key_name.
Your public key has been saved in key_name.pub.
The key fingerprint is:
SHA256:8tDDwPmanTFcEzjTwPGETVWOGW1nVz+gtCCE8hL7PrQ bob.amazon.com
The key's randomart image is:
+---[RSA 4096]----+
| . ....E |
| . = ... |
|. . . = ..o |
| . o + oo = |
| + = .S.= * |
| . o o ..B + o |
| .o.+.* . |
| =o*+*. |
| ..*o*+. |
+----[SHA256]-----+
```
**提示**：如上所示运行`ssh-keygen`命令时，它会将公钥和私钥创建为当前目录中的文件。
您的 SSH 密钥对现已准备就绪，可以使用。按照步骤 3 和 4 为服务托管用户存储 SSH 公钥。这些用户在 Transfer Family 服务器端点上传输文件时使用这些密钥。
1. 导航到 `key_name.pub` 文件并打开它。
1. 复制文本并将其粘贴至服务托管用户的 **SSH 公钥**中。
1. 打开 AWS Transfer Family 控制台 [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)，然后从导航窗格中选择 “**服务器**”。
1. 在**服务器**页面，选择包含要更新用户服务器的**服务器 ID**。
1. 选择要为其添加公钥的目标用户。
1. 在 **SSH 公钥**窗格，选择**添加 SSH 公钥**。
![\[AWS Transfer Family 控制台，显示选定用户的用户详细信息。\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/edit-user-add-key-01.png)
1. 将您生成的公钥文本粘贴至 SSH 公钥文本框中，然后选择**添加密钥**。
![\[AWS Transfer Family 控制台，显示用于添加公钥的 “添加密钥” 页面。\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/edit-user-add-key-02.png)
新密钥列于 SSH 公钥窗格。
![\[AWS Transfer Family 控制台，在 SSH 公钥部分显示新添加的公钥。\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/edit-user-add-key-03.png)
# 在 Microsoft Windows 上创建 SSH 密钥
Windows 将 OpenSSH 作为一项内置功能包括在内，你可以用它来生成与 Linux 或 macOS 相同格式的 SSH 密钥。或者，你可以使用第三方工具，比如 PuTTY 的密钥生成器 (PuTTYgen)。
## 使用 Windows 内置的 OpenSSH
Windows 的最新版本默认包含 OpenSSH。你可以使用与 macOS/Linux 一节中所述相同的`ssh-keygen`命令：
1. 打开 Windows PowerShell 或命令提示符。
1. 根据要生成的密钥类型运行以下命令之一：
+ 生成 RSA 4096 位密钥对：
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ 要生成 ECDSA 521 位密钥对，请执行以下操作：
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ 要生成 ED25519 密钥对，请执行以下操作：
```
ssh-keygen -t ed25519 -f key_name
```
1. 按照与该 macOS/Linux 部分相同的步骤将您的公钥上传到 AWS Transfer Family。
## 使用 PuTTYgen （第三方工具）
某些适用于 Windows 的第三方 SSH 客户端（例如 PuTTY）使用不同的密钥格式。Putty 使用私`PPK`钥的格式。如果你使用的是 Putty 或 WinSCP 等相关工具，你可以使用 Pu TTYgen 来创建这种格式的密钥。
**注意**
如果您向 WinSCP 提供的私有密钥文件不是 `.ppk` 格式，该客户端会为您将密钥转换为 `.ppk` 格式。
有关使用 Pu 创建 SSH 密钥的教程TTYgen，请访问 [SSH.com 网站](https://www.ssh.com/ssh/putty/windows/puttygen)。
# 将 SSH2 密钥转换为 SSH 公钥格式
AWS Transfer Family 仅接受 SSH 格式的公钥。如果您有 SSH2 公钥，则需要对其进行转换。 SSH2 公钥的格式如下：
```
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20160402"
AAAAB3NzaC1yc2EAAAABJQAAAgEAiL0jjDdFqK/kYThqKt7THrjABTPWvXmB3URI
:
:
---- END SSH2 PUBLIC KEY ----
```
SSH 公钥的格式如下：
```
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAA...
```
运行以下命令将格式的公钥转换为 SSH SSH2 格式的公钥。*ssh2-key*替换为 SSH2 密钥的*ssh-key*名称和 SSH 密钥的名称。
```
ssh-keygen -i -f ssh2-key.pub > ssh-key.pub
```
# 轮换 SSH 密钥
出于安全原因，我们推荐轮换 SSH 密钥的最佳安全实践。通常，此轮换被指定为安全策略的一部分，并以某种自动化的方式实现。根据安全级别，对于高度敏感的通信，SSH 密钥对可能只使用一次。这样做可以消除因存储密钥而导致的任何风险。但是，更常见的做法是将 SSH 凭证存储一段时间，并设置一个不会给用户带来过多负担的间隔。通常，时间间隔为 3 个月。
**注意**
有关使用基础架构即代码的自动 SSH 密钥轮换，请参阅[Transfer Family terraform 模块](terraform.md)。
有两种方法用于执行 SSH 密钥轮换：
+ 在控制台上，您可以上传新的 SSH 公钥和删除现有 SSH 公钥。
+ 使用 API，您可以使用 AP [DeleteSshPublicKey](https://docs.aws.amazon.com//transfer/latest/APIReference/API_DeleteSshPublicKey.html)I 删除用户的安全外壳 (SSH) 公钥，使用 [ImportSshPublicKey](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ImportSshPublicKey.html)API 向用户账户添加新的安全外壳 (SSH) 公钥，从而更新现有用户。
------
#### [ Console ]
**若要控制台中执行密钥轮换**
1. 打开 AWS Transfer Family 控制台，网址为[https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)。
1. 导航至**服务器**页面。
1. 选择**服务器 ID** 列中的标识符以查看**服务器详细信息**页面。
1. 在**用户**下，选中要轮换其 SSH 公钥用户的复选框，然后选择**操作**，然后选择**添加密钥**以查看**添加密钥**页面。
或者
选择用户名以查看**用户详细信息**页面，然后选择**添加 SSH 公钥** 以查看**添加密钥**页面。
1. 输入新的 SSH 公钥并选择**添加密钥**。
**重要**
SSH 公有密钥格式取决于您生成的密钥的类型。
RSA 密钥的格式为 `ssh-rsa string`。
对于 ED25519 密钥，格式为`ssh-ed25519 string`。
对于 ECDSA 密钥，`ecdsa-sha2-nistp256` 字符串为 `ecdsa-sha2-nistp384` 或 `ecdsa-sha2-nistp521`，具体取决于您生成的密钥的大小。然后，先是 `string`，后跟开头字符串，这与其他秘钥类型类似。
您将返回**用户配置**屏幕，您刚刚输入的新 SSH 公钥将出现在 **SSH 公钥**部分。
1. 选中要删除的旧密钥旁边的复选框，然后选择**删除**。
1. 输入单词 `delete` 以确认删除操作，然后选择**删除**。
------
#### [ API ]
**若要使用 API 执行密钥轮换**
1. 在 macOS、Linux 或 Unix 操作系统，打开命令终端。
1. 输入以下命令，以检索要删除的 SSH 密钥。若要使用此命令，请将 `serverID` 替换为您的 Transfer Family 服务器的服务器 ID，然后将 `username` 替换为您的用户名。
```
aws transfer describe-user --server-id='serverID' --user-name='username'
```
该命令返回有关此用户的详细信息。复制 `"SshPublicKeyId":` 字段的内容。您将需要稍后在此程序中输入此值。
```
"SshPublicKeys": [ { "SshPublicKeyBody": "public-key", "SshPublicKeyId": "keyID",
"DateImported": 1621969331.072 } ],
```
1. 接下来，为您的用户导入新 SSH 密钥。在 提示符中，输入以下命令。若要使用此命令，请将 `serverID` 替换为您的 Transfer Family 服务器的服务器 ID，将 `public-key` 替换为您的用户名，并将 `username` 替换为新公钥的指纹。
```
aws transfer import-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-body='public-key'
```
``如果命令成功，则不返回任何输出。
1. 最后通过运行以下命令删除旧密钥。若要使用此命令，将 `serverID` 替换为 Transfer Family 服务器的服务器 ID，将 `username` 替换为您的用户名，将 `keyID-from-step-2` 替换为您在此程序第 2 步中复制的秘钥 ID 值。
```
aws transfer delete-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-id='keyID-from-step-2'
```
1. （可选）要确认旧密钥是否存在，请重复第 2 步。
------
# 生成 PGP 密钥
您可以对 Transfer Family 通过工作流程处理的文件使用 Pretty Good Privacy (PGP) 解密。要在工作流程步骤中使用解密，请提供 PGP 密钥。有关 PGP 密钥算法的详细信息，包括建议和 FIPS 合规性，请参阅。[PGP key pair 算法](key-management.md#pgp-key-algorithms)
AWS 存储博客上有一篇文章描述了如何使用 Transfer Family Managed 工作流程、使用 PGP [加密和解密文件以及，无需编写任何代码即可简单地解密文件](https://aws.amazon.com/blogs/storage/encrypt-and-decrypt-files-with-pgp-and-aws-transfer-family/)。 AWS Transfer Family
用于生成 PGP 密钥的运算符取决于您的操作系统和所使用的密钥生成软件的版本。
如果您使用的是 Linux 或 Unix，请使用软件包安装程序安装 `gpg`。根据您的 Linux 发行版，在以下选择适用于您的命令。
```
sudo yum install gnupg
```
```
sudo apt-get install gnupg
```
对于 Windows 或 macOS，您可以从 [https://gnupg.org/download/](https://gnupg.org/download/) 下载您需要的内容。
安装 PGP 密钥生成器软件后，运行 `gpg --full-gen-key` 或 `gpg --gen-key` 命令生成密钥对。
**注意**
如果您使用的版本是 `GnuPG` 2.3.0 或以上，则必须运行 `gpg --full-gen-key`。当提示输入要创建的密钥类型时，请选择 RSA 或 ECC。如果选择 **ECC**，则可以从NIST椭圆曲线BrainPool和中Curve25519进行选择。
**有用的 `gpg` 子命令**
以下是一些有用的`gpg`子命令：
+ `gpg --help` — 此命令列出了可用选项，可能还包括一些示例。
+ `gpg --list-keys`— 此命令列出了您创建的所有密钥对的详细信息。
+ `gpg --fingerprint`— 此命令列出了所有密钥对的详细信息，包括每个密钥的指纹。
+ `gpg --export -a user-name` — 此命令导出生成密钥时 `user-name` 使用密钥的公钥部分。
# 管理 PGP 密钥
要管理您的 PGP 密钥，请使用 AWS Secrets Manager。
**注意**
您的秘钥名称包括 Transfer Family 服务器 ID。这意味着您应在 AWS Secrets Manager中存储 PGP 秘钥信息*之前*识别或创建服务器。
如果您想为所有用户使用同一个密钥和密码，则可以将 PGP 密钥区块信息存储在机密名称 `aws/transfer/server-id/@pgp-default` 下，其中 `server-id` 是 Transfer Family 服务器的 ID。如果没有与正在执行工作流程的用户`user-name`匹配的密钥，Transfer Family 将使用此默认密钥。
您可以为特定用户创建密钥。在本例中，密钥名称的格式为`aws/transfer/server-id/user-name`，其中`user-name`匹配正在为 Transfer Family 服务器运行工作流程的用户。
**注意**
在每台 Transfer Family 服务器上，每位用户最多可存储 3 个 PGP 私钥。
**配置用户解密的 PGP 密钥**
1. 根据您使用的 GPG 版本，运行以下命令之一来生成 PGP key pair。
+ 如果您使用的是 **GnuPG** 版本为 2.3.0 或以上，请运行以下命令：
```
gpg --full-gen-key
```
您可以选择**RSA**，或者，如果选择**ECC**，则可以选择椭圆曲线**BrainPool**或**Curve25519**。**NIST**如果`gpg --gen-key`改为运行，则创建使用 ECC Curve 25519 加密算法的密钥对。
+ 对于 2.3.0 之前版本的 **GnuPG**，您可以使用以下命令，原因是 RSA 是默认的加密类型。
```
gpg --gen-key
```
**重要**
密钥生成过程中，您必须提供密码和电子邮箱地址。请务必记下这些值。在本过程的 AWS Secrets Manager 后面输入密钥详细信息时，必须提供密码。您必须提供相同的电子邮件地址才能在下一步中导出私钥。
1. 运行以下命令以导出私钥。要使用此命令，请将 `private.pgp` 替换为用于保存私钥块的文件名，并将 `marymajor@example.com` 替换为生成密钥对时使用的电子邮件地址。
```
gpg --output private.pgp --armor --export-secret-key marymajor@example.com
```
1. 用于存储 AWS Secrets Manager 您的 PGP 密钥。
1. 登录 AWS 管理控制台 并打开 AWS Secrets Manager 控制台，网址为[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)。
1. 在左侧导航窗格中，选择**密钥**。
1. 在**密钥**页面，选择**存储新密钥**。
1. 在**选择密钥类型**页面上，为**密钥类型**选择**其他密钥类型**。
1. 在**秘钥/值对**部分，选择**秘钥/值**选项卡。
+ **密钥** - 输入 **PGPPrivateKey**。
**注意**
必须准确输入 **PGPPrivateKey** 字符串：切勿在字符前面或字符之间添加任何空格。
+ **值** — 将您的私钥文本粘贴至值字段。您可以在文件中找到私钥文本（例如 `private.pgp`），该文件是在您之前导出密钥时指定的文件。密钥开头为 `-----BEGIN PGP PRIVATE KEY BLOCK-----`，结尾为 `-----END PGP PRIVATE KEY BLOCK-----`。
**注意**
确保文本块仅包含私钥，且不包含公钥。
1. 选择**添加行**，然后在**秘钥/值对**部分选择**秘钥/值**选项卡。
+ **键** — 输入 **PGPPassphrase**。
**注意**
必须准确输入 **PGPPassphrase** 字符串：切勿在字符前面或字符之间添加任何空格。
+ **值** – 输入您在生成 PGP 密钥对时使用的密码。
![\[\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/pgp-secrets-01.png)
**注意**
您最多可添加 3 组密钥和密码。若要添加第二组，请添加两行新行，为秘钥输入 **PGPPrivateKey2** 和 **PGPPassphrase2**，并粘贴至其他私钥和密码。若要添加第三组，秘钥值必须为 **PGPPrivateKey3** 和 **PGPPassphrase3**。
1. 选择**下一步**。
1. 在**配置密钥**页面，输入密钥的名称和描述。
+ 如果您要创建默认密钥，即可供任何 Transfer Family 用户使用的密钥，请输入 **aws/transfer/*server-id*/@pgp-default**。将 `server-id` 替换为包含解密工作流程服务器的 ID。
+ 如果您正在创建供特定 Transfer Family 用户使用的密钥，请输入 **aws/transfer/*server-id*/*user-name***。将 `server-id` 替换为包含解密工作流程服务器的 ID，将 `user-name` 更换为运行工作流程的用户名称。`user-name` 存储在 Transfer Family 服务器正在使用的身份提供程序。
1. 选择**下一步**，接受**配置轮换**页面的默认设置。然后选择**下一步**。
1. 在**审核**页面，选择**存储**以创建和存储密钥。
以下屏幕截图显示了指定 Transfer Family 服务器用户 **marymajor** 的详细信息。此示例显示三个密钥及其对应的密码。
![\[\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/pgp-secrets-02.png)
# 支持的 PGP 客户端
以下客户端已通过 Transfer Family 进行测试，可用于生成 PGP 密钥，以及加密您打算通过工作流程解密的文件。
+ **Gpg4win \$1 Kleopatra**。
**注意**
当您选择**签名/加密文件**时，请务必取消选择**签名身份**：我们目前不支持对加密文件进行签名。
![\[\]](http://docs.aws.amazon.com/zh_cn/transfer/latest/userguide/images/workflows-step-decrypt-kleopatra.png)
如果您对加密文件进行签名并尝试使用解密工作流程将其上传到 Transfer Family 服务器，则会收到以下错误：
```
Encrypted file with signed message unsupported
```
+ **GnuPG** 主要版本：2.4、2.3、2.2、2.0 和 1.4。
请注意，其他 PGP 客户端也可运行，但只有此处提到的客户端通过 Transfer Family 进行了测试。
# 的身份和访问管理 AWS Transfer Family
AWS Identity and Access Management (IAM) AWS 服务 可帮助管理员安全地控制对 AWS 资源的访问权限。IAM 管理员控制谁可以*进行身份验证*（登录）和*授权（有权*限）使用 AWS Transfer Family 资源。您可以使用 IAM AWS 服务 ，无需支付额外费用。
**Topics**
+ [受众](#security_iam_audience)
+ [使用身份进行身份验证](#security_iam_authentication)
+ [使用策略管理访问](#security_iam_access-manage)
+ [如何 AWS Transfer Family 与 IAM 配合使用](security_iam_service-with-iam.md)
+ [AWS Transfer Family 基于身份的策略示例](security_iam_id-based-policy-examples.md)
+ [AWS Transfer Family 基于标签的策略示例](security_iam_tag-based-policy-examples.md)
+ [对 AWS Transfer Family 身份和访问进行故障排除](security_iam_troubleshoot.md)
+ [用于组织治理的 IAM 条件密钥](transfer-condition-keys.md)
## 受众
您的使用方式 AWS Identity and Access Management (IAM) 因您的角色而异：
+ **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[对 AWS Transfer Family 身份和访问进行故障排除](security_iam_troubleshoot.md)）
+ **服务管理员**：确定用户访问权限并提交权限请求（请参阅[如何 AWS Transfer Family 与 IAM 配合使用](security_iam_service-with-iam.md)）
+ **IAM 管理员**：编写用于管理访问权限的策略（请参阅[AWS Transfer Family 基于身份的策略示例](security_iam_id-based-policy-examples.md)）
## 使用身份进行身份验证
身份验证是您 AWS 使用身份凭证登录的方式。您必须以 IAM 用户身份进行身份验证 AWS 账户根用户，或者通过担任 IAM 角色进行身份验证。
您可以使用来自身份源的证书 AWS IAM Identity Center （例如（IAM Identity Center）、单点登录身份验证或 Google/Facebook 证书，以联合身份登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。
对于编程访问， AWS 提供 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。
### AWS 账户根用户
创建时 AWS 账户，首先会有一个名为 AWS 账户 *root 用户的*登录身份，该身份可以完全访问所有资源 AWS 服务 和资源。我们强烈建议不要使用根用户进行日常任务。有关需要根用户凭证的任务，请参阅《IAM 用户指南》**中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。
### 联合身份
作为最佳实践，要求人类用户使用与身份提供商的联合身份验证才能 AWS 服务 使用临时证书进行访问。
*联合身份是指*来自您的企业目录、Web 身份提供商的用户 Directory Service ，或者 AWS 服务 使用来自身份源的凭据进行访问的用户。联合身份代入可提供临时凭证的角色。
要集中管理访问权限，建议使用。 AWS IAM Identity Center有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[什么是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。
### IAM 用户和群组
*[IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*是对某个人员或应用程序具有特定权限的一个身份。建议使用临时凭证，而非具有长期凭证的 IAM 用户。有关更多信息，请参阅 *IAM 用户指南*[中的要求人类用户使用身份提供商的联合身份验证才能 AWS 使用临时证书进行访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)指定一组 IAM 用户，便于更轻松地对大量用户进行权限管理。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 用户使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。
### IAM 角色
*[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*是具有特定权限的身份，可提供临时凭证。您可以通过[从用户切换到 IAM 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来代入角色。有关更多信息，请参阅《IAM 用户指南》**中的[担任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。
IAM 角色对于联合用户访问、临时 IAM 用户权限、跨账户访问、跨服务访问以及在 Amazon EC2 上运行的应用程序非常有用。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
## 使用策略管理访问
您可以 AWS 通过创建策略并将其附加到 AWS 身份或资源来控制中的访问权限。策略定义了与身份或资源关联时的权限。 AWS 在委托人提出请求时评估这些政策。大多数策略都以 JSON 文档的 AWS 形式存储在中。有关 JSON 策略文档的更多信息，请参阅*《IAM 用户指南》*中的 [JSON 策略概述](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。
管理员使用策略，通过定义哪个**主体**可以在什么**条件**下对哪些**资源**执行哪些**操作**来指定谁有权访问什么。
默认情况下，用户和角色没有权限。IAM 管理员创建 IAM 策略并将其添加到角色中，然后用户可以担任这些角色。IAM 策略定义权限，与执行操作所用的方法无关。
### 基于身份的策略
基于身份的策略是您附加到身份（用户、组或角色）的 JSON 权限策略文档。这些策略控制身份可以执行什么操作、对哪些资源执行以及在什么条件下执行。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《IAM 用户指南》*中的[在托管策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。
### 基于资源的策略
基于资源的策略是附加到资源的 JSON 策略文档。示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。
基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用 IAM 中的 AWS 托管策略。
### 访问控制列表 (ACLs)
访问控制列表 (ACLs) 控制哪些委托人（账户成员、用户或角色）有权访问资源。 ACLs 与基于资源的策略类似，尽管它们不使用 JSON 策略文档格式。
Amazon S3 和 Amazon VPC 就是支持的服务示例 ACLs。 AWS WAF要了解更多信息 ACLs，请参阅《*亚马逊简单存储服务开发者指南*》中的[访问控制列表 (ACL) 概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。
### 其他策略类型
AWS 支持其他策略类型，这些策略类型可以设置更常见的策略类型授予的最大权限：
+ **权限边界** – 设置基于身份的策略可以授予 IAM 实体的最大权限。有关更多信息，请参阅《 IAM 用户指南》**中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。
+ **服务控制策略 (SCPs)**-在中指定组织或组织单位的最大权限 AWS Organizations。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。
+ **资源控制策略 (RCPs)**-设置账户中资源的最大可用权限。有关更多信息，请参阅《*AWS Organizations 用户指南》*中的[资源控制策略 (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。
+ **会话策略** – 在为角色或联合用户创建临时会话时，作为参数传递的高级策略。有关更多信息，请参阅《IAM 用户指南》**中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
### 多个策略类型
当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解在涉及多种策略类型时如何 AWS 确定是否允许请求，请参阅 *IAM 用户指南*中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。
# 如何 AWS Transfer Family 与 IAM 配合使用
在使用 AWS Identity and Access Management (IAM) 管理访问权限之前 AWS Transfer Family，您应该了解哪些可用的 IAM 功能 AWS Transfer Family。要全面了解如何 AWS Transfer Family 和其他 AWS 服务与 IAM 配合使用，请参阅 IAM *用户指南中的与 IAM* [配合使用的AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。
**Topics**
+ [AWS Transfer Family 基于身份的策略](#security_iam_service-with-iam-id-based-policies)
+ [AWS Transfer Family 基于资源的政策](#security_iam_service-with-iam-resource-based-policies)
+ [基于 AWS Transfer Family 标签的授权](#security_iam_service-with-iam-tags)
+ [AWS Transfer Family IAM 角色](#security_iam_service-with-iam-roles)
## AWS Transfer Family 基于身份的策略
使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源，以及指定在什么条件下允许或拒绝操作。 AWS Transfer Family 支持特定操作、资源和条件键。要了解您在 JSON 策略中使用的所有元素，请参阅 *AWS Identity and Access Management 用户指南*中的 [IAM JSON 策略元素参考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。
### 操作
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。
正在执行的策略操作在操作前 AWS Transfer Family 使用以下前缀:`transfer:`. 例如，要授予某人使用 Transfer Family `CreateServer` API 操作创建 VPC 的权限，您应将 `transfer:CreateServer` 操作纳入其策略中。策略语句必须包括 `Action` 或 `NotAction` 元素。 AWS Transfer Family 定义了自己的一组操作，这些操作描述了可使用该服务执行的任务。
要在单个语句中指定多项 操作，请使用逗号将它们隔开，如下所示。
```
"Action": [
"transfer:action1",
"transfer:action2"
```
您也可以使用通配符 (\$1) 指定多个操作。例如，要指定以单词 `Describe` 开头的所有操作，请包括以下操作。
```
"Action": "transfer:Describe*"
```
要查看 AWS Transfer Family 操作列表，请参阅《*服务授权参考*》 AWS Transfer Family中[定义的操作](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-actions-as-permissions)。
### 资源
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。
```
"Resource": "*"
```
Transfer Family 服务器资源具有以下 ARN。
```
arn:aws:transfer:${Region}:${Account}:server/${ServerId}
```
例如，要在语句中指定 `s-01234567890abcdef` Transfer Family 服务器，请使用以下 ARN。
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/s-01234567890abcdef"
```
有关格式的更多信息 ARNs，请参阅《*服务授权参考*》中的 A [mazon 资源名称 (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) 或 [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *用户指南 ARNs中的 IAM*。
要指定属于特定账户的所有实例，请使用通配符 (\$1)。
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/*"
```
有些 AWS Transfer Family 操作是在多个资源上执行的，例如 IAM 策略中使用的资源。在这些情况下，您必须使用通配符（\$1)。
```
"Resource": "arn:aws:transfer:*:123456789012:server/*"
```
在某些情况下，您需要指定多种类型的资源，例如，如果您创建了允许访问 Transfer Family 服务器与用户的策略。要在单个语句中指定多个资源，请 ARNs 用逗号分隔。
```
"Resource": [
"resource1",
"resource2"
]
```
要查看 AWS Transfer Family 资源列表，请参阅《*服务授权参考*[》 AWS Transfer Family中定义的资源类型](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-resources-for-iam-policies)。
### 条件键
管理员可以使用 AWS JSON 策略来指定谁有权访问什么。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Condition` 元素根据定义的条件指定语句何时执行。您可以创建使用[条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)（例如，等于或小于）的条件表达式，以使策略中的条件与请求中的值相匹配。要查看所有 AWS 全局条件键，请参阅 *IAM 用户指南*中的[AWS 全局条件上下文密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。
AWS Transfer Family 定义自己的条件键集，还支持使用一些全局条件键。要查看 AWS Transfer Family 条件键列表，请参阅《*服务授权参考*》 AWS Transfer Family中的[条件密钥](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-policy-keys)。
### 示例
要查看 AWS Transfer Family 基于身份的策略的示例，请参阅。[AWS Transfer Family 基于身份的策略示例](security_iam_id-based-policy-examples.md)有关特定于 VPC 终端节点的 IAM 策略，请参阅。[限制 Transfer Family 服务器的 VPC 终端节点访问权限](create-server-in-vpc.md#limit-vpc-endpoint-access)
## AWS Transfer Family 基于资源的政策
基于资源的策略是 JSON 策略文档，用于指定委托人可以在哪些条件下对 AWS Transfer Family 资源执行哪些操作。Amazon S3 支持亚马逊 S3 *buckets* 的基于资源的权限策略。基于资源的策略允许您基于资源向其他账户授予使用权限。您也可以使用基于资源的策略来允许 AWS 服务访问您的 Amazon S3 *buckets*。
要启用跨账户访问，您可以将整个账户或其他账户中的 IAM 实体指定为[基于资源的策略中的委托人](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。将跨账户主体添加到基于资源的策略只是建立信任关系工作的一半而已。当委托人和资源位于不同的 AWS 账户中时，您还必须向委托人实体授予访问资源的权限。通过将基于身份的策略附加到实体以授予权限。但是，如果基于资源的策略向同一个账户中的主体授予访问权限，则不需要额外的基于身份的策略。有关更多信息，请参阅 *AWS Identity and Access Management 用户指南*中的 [IAM 角色与基于资源的策略有何不同](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)。
Amazon S3 服务仅支持一种基于资源的策略，即**bucket*策略*，该策略附加到。*bucket*这个策略定义哪些委托人实体（账户、用户、角色和联合身份用户）可以在对象上执行操作。
### 示例
要查看 AWS Transfer Family 基于资源的策略的示例，请参阅[AWS Transfer Family 基于标签的策略示例](security_iam_tag-based-policy-examples.md)。
## 基于 AWS Transfer Family 标签的授权
您可以为 AWS Transfer Family 资源附加标签或在请求中传递标签 AWS Transfer Family。要基于标签控制访问，您需要使用 `transfer:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。有关如何使用标签控制对 AWS Transfer Family 资源的访问的信息，请参阅[AWS Transfer Family 基于标签的策略示例](security_iam_tag-based-policy-examples.md)。
## AWS Transfer Family IAM 角色
I [AM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)是您的 AWS 账户中具有特定权限的实体。
### 将临时凭证与 AWS Transfer Family
可以使用临时凭证进行联合身份验证登录，分派 IAM 角色或分派跨账户角色。您可以通过调用[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)或之类的 AWS STS API 操作来获取临时安全证书[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)。
AWS Transfer Family 支持使用临时证书。
# AWS Transfer Family 基于身份的策略示例
默认情况下，IAM 用户和角色没有创建或修改 AWS Transfer Family 资源的权限。他们也无法使用 AWS 管理控制台 AWS CLI、或 AWS API 执行任务。IAM 管理员必须创建 IAM 策略，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，管理员必须将这些策略附加到需要这些权限的 IAM 用户或组。
要了解如何使用这些示例 JSON 策略文档创建 IAM 基于身份的策略，请参阅 *AWS Identity and Access Management 用户指南*中的[在 JSON 选项卡上创建策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)。
**Topics**
+ [策略最佳实践](#security_iam_service-with-iam-policy-best-practices)
+ [使用控制 AWS Transfer Family 台](#security_iam_id-based-policy-examples-console)
+ [允许用户查看他们自己的权限](#security_iam_id-based-policy-examples-view-own-permissions)
## 策略最佳实践
基于身份的策略决定了某人是否可以在您的账户中创建、访问或删除 AWS Transfer Family 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议：
+ **开始使用 AWS 托管策略并转向最低权限权限** — 要开始向用户和工作负载授予权限，请使用为许多常见用例授予权限的*AWS 托管策略*。它们在你的版本中可用 AWS 账户。我们建议您通过定义针对您的用例的 AWS 客户托管策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。
+ **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。
+ **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果服务操作是通过特定的方式使用的，则也可以使用条件来授予对服务操作的访问权限 AWS 服务，例如 CloudFormation。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。
+ **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **需要多重身份验证 (MFA**)-如果 AWS 账户您的场景需要 IAM 用户或根用户，请启用 MFA 以提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。
有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。
## 使用控制 AWS Transfer Family 台
要访问 AWS Transfer Family 控制台，您必须拥有一组最低权限。这些权限必须允许您列出和查看 AWS 账户中 AWS Transfer Family 资源的详细信息。如果您创建的基于身份的策略比所需的最低权限更严格，则无法为具有该策略的实体（IAM 用户或角色）正常运行控制台。有关更多信息，请参阅 *AWS Identity and Access Management 用户指南*中的[为用户添加权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)。
对于仅调用 AWS CLI 或 AWS API 的用户，您无需为其设置最低控制台权限。相反，只允许访问与您尝试执行的 API 操作相匹配的操作。
## 允许用户查看他们自己的权限
该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包括在控制台上或使用 AWS CLI 或 AWS API 以编程方式完成此操作的权限。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS Transfer Family 基于标签的策略示例
以下是如何根据标签控制 AWS Transfer Family 资源访问权限的示例。
## 使用标签控制对 AWS Transfer Family 资源的访问权限
IAM 策略中的条件是所需语法的一部分，您可以使用它们指定对 AWS Transfer Family 资源的权限。您可以根据这些 AWS Transfer Family 资源的标签来控制对这些资源（例如用户、服务器、角色和其他实体）的访问权限。标签是键值对。有关为资源添加标签的更多信息，请参阅中的为[AWS 资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。*AWS 一般参考*
在中 AWS Transfer Family，资源可以有标签，有些操作可以包含标签。在创建 IAM 策略时，您可以使用标签条件键来控制：
+ 根据 AWS Transfer Family 资源所具有的标签，哪些用户可以对资源执行操作。
+ 哪些标签可以在操作的请求中传递。
+ 是否特定标签键可在请求中使用。
通过使用基于标签的访问控制，您可以应用比 API 级别更精细的控制。与使用基于资源的访问控制相比，您还可以应用更多动态控制。您可以创建 IAM 策略，以允许或拒绝按请求中提供的标签（请求标签）执行操作。您还可以根据正在操作资源的标签（资源标签）创建 IAM 策略。通常，资源标签用于资源上已有的标签，请求标签用于向资源添加标签或从资源中删除标签。
有关标签条件键的完整请求和语义，请参阅 *IAM 用户指南*中的[使用资源标签控制 AWS 资源的访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)。有关使用 API Gateway 指定 IAM 策略的详细信息，请参阅 *API Gateway 开发人员指南*中的[控制访问具有 IAM 权限的 API](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)。
### 示例 1：基于资源标签拒绝操作
您可根据标签拒绝资源上执行的操作。如果用户或服务器资源通过秘钥 `stage` 和值 `prod` 标记，则以下示例策略拒绝 `TagResource`、`UntagResource`、`StartServer`、`StopServer`、`DescribeServer` 以及 `DescribeUser` 操作。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"transfer:TagResource",
"transfer:UntagResource",
"transfer:StartServer",
"transfer:StopServer",
"transfer:DescribeServer",
"transfer:DescribeUser"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/stage": "prod"
}
}
}
]
}
```
### 示例 2：基于资源标签允许操作
您可以允许根据标签对资源执行操作。如果用户或服务器资源通过秘钥 `stage` 和值 `prod` 标记，则以下示例策略拒绝 `TagResource`、`UntagResource`、`StartServer`、`StopServer`、`DescribeServer` 以及 `DescribeUser` 操作。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"transfer:TagResource",
"transfer:UntagResource",
"transfer:StartServer",
"transfer:StopServer",
"transfer:DescribeServer",
"transfer:DescribeUser"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/stage": "prod"
}
}
}
]
}
```
### 示例 3：拒绝根据请求标签创建用户或服务器
以下示例策略包含两个语句。如果标签的成本中心密钥无值，则第一条语句拒绝对所有资源执行 `CreateServer` 操作。
如果标签的成本中心密钥包含除 1、2 或 3 之外的任何其他值，则第二条语句将拒绝 `CreateServer` 操作。
**注意**
此策略确实允许创建或删除包含 `costcenter` 秘钥和 `1`、`2` 或 `3` 值的资源。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"transfer:CreateServer"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/costcenter": "true"
}
}
},
{
"Effect": "Deny",
"Action": "transfer:CreateServer",
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws:RequestTag/costcenter": [
"1",
"2",
"3"
]
}
}
}
]
}
```
# 对 AWS Transfer Family 身份和访问进行故障排除
使用以下信息来帮助您诊断和修复在使用 AWS Transfer Family 和 IAM 时可能遇到的常见问题。
**Topics**
+ [我无权在以下位置执行操作 AWS Transfer Family](#security_iam_troubleshoot-no-permissions)
+ [我无权执行 iam：PassRole](#security_iam_troubleshoot-passrole)
+ [我想允许 AWS 账户之外的人访问我的 AWS Transfer Family 资源](#security_iam_troubleshoot-cross-account-access)
## 我无权在以下位置执行操作 AWS Transfer Family
如果 AWS 管理控制台 告诉您您无权执行某项操作，则必须联系管理员寻求帮助。管理员是向您提供登录凭证的人。
如果 `mateojackson` IAM 用户尝试使用控制台查看有关 *widget* 的详细信息，但没有 `transfer:GetWidget` 权限，则会出现以下示例错误。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: transfer:GetWidget on resource: my-example-widget
```
在这种情况下，Mateo 请求他的管理员更新其策略，以允许他使用 `transfer;:GetWidget` 操作访问 `my-example-widget` 资源。
## 我无权执行 iam：PassRole
如果您收到一个错误，表明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给。 AWS Transfer Family
有些 AWS 服务 允许您将现有角色传递给该服务，而不是创建新的服务角色或服务相关角色。为此，您必须具有将角色传递到服务的权限。
当名为 `marymajor` 的 IAM 用户尝试使用控制台在 AWS Transfer Family中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。
如果您需要帮助，请联系您的 AWS 管理员。您的管理员是提供登录凭证的人。
以下示例策略包含将角色传递给 AWS Transfer Family的权限。**123456789012**替换为您的 AWS 账户 ID 和**MyTransferRole**您的实际 IAM 角色名称。
****
```
{
"Version":"2012-10-17",
"Statement": [
{ "Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MyTransferRole",
"Effect": "Allow"
}
]
}
```
## 我想允许 AWS 账户之外的人访问我的 AWS Transfer Family 资源
您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表 (ACLs) 的服务，您可以使用这些策略向人们授予访问您的资源的权限。
要了解更多信息，请参阅以下内容：
+ 要了解是否 AWS Transfer Family 支持这些功能，请参阅[如何 AWS Transfer Family 与 IAM 配合使用](security_iam_service-with-iam.md)。
+ 要了解如何提供对您拥有的资源的访问权限 AWS 账户 ，请参阅 [IAM 用户*指南中的向您拥有 AWS 账户 的另一个 IAM 用户*提供访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)权限。
+ 要了解如何向第三方提供对您的资源的访问[权限 AWS 账户，请参阅 *IAM 用户指南*中的向第三方提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)访问权限。 AWS 账户
+ 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。
+ 要了解使用角色和基于资源的策略进行跨账户访问之间的差别，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
# 用于组织治理的 IAM 条件密钥
AWS Transfer Family 提供了 IAM 条件密钥，允许您在任何 IAM 策略中限制资源配置。这些条件密钥可用于附加到用户或角色的基于身份的策略，或用于组织治理的服务控制策略 (SCPs)。
服务控制策略是适用于整个 AWS 组织的 IAM 策略，为多个账户提供预防性护栏。在中使用这些条件密钥时 SCPs，有助于在整个组织范围内强制执行安全与合规性要求。
**另请参阅**
+ [Transfer Family 的操作、资源和条件密钥](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html)
+ [服务控制策略 (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
+ 描述如何使用服务控制策略强制实施预防性护栏的视频
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/mEO05mmbSms)
## 可用的条件键
AWS Transfer Family 支持在 IAM 策略中使用以下条件键：
`transfer:RequestServerEndpointType`
根据终端节点类型（公共、VPC、VPC\$1ENDPOINT）限制服务器的创建和更新。通常用于阻止面向公众的端点。
`transfer:RequestServerProtocols`
根据支持的协议（SFTP、FTPS、FTP 等）限制服务器的创建和更新。 AS2
`transfer:RequestServerDomain`
根据域类型（S3、EFS）限制服务器的创建。
`transfer:RequestConnectorProtocol`
根据协议（AS2、SFTP）限制连接器的创建。
## 支持的操作
条件键可以应用于以下 AWS Transfer Family 操作：
+ `CreateServer`: 支持`RequestServerEndpointType``RequestServerProtocols`、和`RequestServerDomain`条件键
+ `UpdateServer`: 支撑键`RequestServerEndpointType`和`RequestServerProtocols`条件键
+ `CreateConnector`: 支持`RequestConnectorProtocol`条件键
## SCP 策略示例
以下示例 SCP 阻止在整个组织中创建公共 AWS Transfer Family 服务器：
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyPublicTransferServers",
"Effect": "Deny",
"Action": ["transfer:CreateServer", "transfer:UpdateServer"],
"Resource": "*",
"Condition": {
"StringEquals": {
"transfer:RequestServerEndpointType": "PUBLIC"
}
}
}]
}
```
# 合规性验证 AWS Transfer Family
AWS Transfer Family 作为多个合规计划的一部分，第三方审计师对安全性和 AWS 合规性进行评估。其中包括 SOC、PCI、HIPAA 等。有关完整列表，请参阅[按合规计划划分的范围内的AWS 服务](https://aws.amazon.com/compliance/services-in-scope)。
有关特定合规计划范围内的 AWS 服务列表，请参阅[按合规计划划分的范围内的AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。有关一般信息，请参阅 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)。
您可以使用下载第三方审计报告 AWS Artifact。有关更多信息，请参阅[中的下载报告 AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。
您在使用 AWS Transfer Family 时的合规责任取决于您的数据的敏感性、贵公司的合规目标以及适用的法律和法规。 AWS 提供了以下资源来帮助实现合规性：
+ [安全与合规性快速入门指南](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) — 这些部署指南讨论了架构注意事项，并提供了在上部署以安全性和合规性为重点的基准环境的步骤。 AWS
+ [HIPAA 安全与合规架构白皮书 — 本白皮书](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/introduction.html)描述了公司如何使用来 AWS 创建符合 HIPAA 标准的应用程序。
+ [AWS 合规性资源](https://aws.amazon.com/compliance/resources/)：此业务手册和指南集合可能适用于您的行业和位置。
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— 该 AWS 服务评估您的资源配置在多大程度上符合内部实践、行业指导方针和法规。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— 此 AWS 服务可全面了解您的安全状态 AWS ，帮助您检查是否符合安全行业标准和最佳实践。
# 韧性在 AWS Transfer Family
AWS 全球基础设施是围绕 AWS 区域和可用区构建的。 AWS 区域提供多个物理隔离和隔离的可用区，这些可用区通过低延迟、高吞吐量和高度冗余的网络相连。利用可用区，您可以设计和操作在可用区之间无中断地自动实现失效转移的应用程序和数据库。与传统的单个或多个数据中心基础架构相比，可用区具有更高的可用性、容错性和可扩展性。
AWS Transfer Family 最多支持 3 个可用区，并由 auto Scaling 的冗余队列提供支持，用于处理您的连接和传输请求。
对于所有 Transfer Family 端点：
+ 该服务内置了可用区域级别的冗余。
+ 每个可用区都有冗余实例集。
+ 这种冗余是自动提供的。
**注意**
对于虚拟私有云 (VPC) Private Cloud 中的终端节点，可以提供单个子网。但是，我们建议您在您的 VPC 内的多个可用区中创建终端节点，以降低可用区中断期间服务中断的风险。
**另请参阅**
+ 有关如何在 VPC 中创建 Transfer Family 服务器的详细信息，请参阅[在虚拟私有云中创建服务器](create-server-in-vpc.md)。
+ 有关 AWS 区域 和可用区的更多信息，请参阅[AWS 全球基础架构](https://aws.amazon.com/about-aws/global-infrastructure/)。
+ 有关如何使用基于延迟的路由来构建更高的冗余并最大限度地减少网络延迟的示例，请参阅博客文章[最大限度地减少服务器的网络延迟](https://aws.amazon.com/blogs/storage/minimize-network-latency-with-your-aws-transfer-for-sftp-servers/)。 AWS Transfer Family
# 在 VPC 和之间创建私有连接 AWS Transfer Family APIs
您可以 AWS Transfer Family APIs 通过创建由提供支持的接*口 VPC 终端节点在您的 VPC* 和之间建立私有连接[AWS PrivateLink](https://aws.amazon.com/privatelink/)。您可以像在 VPC 中 AWS Transfer Family APIs 一样进行访问，无需使用互联网网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。VPC 中的实例不需要公有 IP 地址便可与 AWS Transfer Family APIs 进行通信。
我们将在您为接口端点启用的每个子网中创建一个端点网络接口。有关更多信息，请参阅*AWS PrivateLink 指南 AWS PrivateLink*中的[通过访问 AWS 服务](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)。在为设置接口 VPC 终端节点之前 AWS Transfer Family APIs，请查看*AWS PrivateLink 指南*中的[注意事项](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)。
## 使用 VPC 终端节点策略控制访问
默认情况下，允许通过终端节点进行完全访问。 AWS Transfer Family APIs 您可以使用 VPC 端点策略控制对接口端点的访问。您可以为 VPC 端点附加控制对 AWS Transfer Family APIs 的访问的端点策略。该策略指定以下信息：
+ 可执行操作的**主体**。
+ 可执行的**操作**。
+ 可对其执行操作的**资源**。
有关更多信息，请参阅《Amazon VPC 用户指南》**中的[使用 VPC 端点控制对服务的访问](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)。
以下是的终端节点策略示例 AWS Transfer Family APIs。当连接到终端节点时，此策略授予对所有资源 AWS Transfer Family APIs 执行所有操作的访问权限，但标有密钥`Environment`和值的资源除外`Test`。
```
{
"Statement": [{
"Effect": "Deny",
"Action": "transfer:StartFileTransfer",
"Principal": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "Test"
}
}
}, {
"Effect": "Allow",
"Action": "transfer:*",
"Principal": "*",
"Resource": "*"
}]
}
```
## 为创建接口 VPC 终端节点 AWS Transfer Family APIs
您可以 AWS Transfer Family APIs 使用 Amazon VPC 控制台或 AWS 命令行界面 (AWS CLI) 创建 VPC 终端节点。有关更多信息，请参阅 *AWS PrivateLink 指南*中的[创建 VPC 端点](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)。
AWS Transfer Family APIs 使用以下服务名称之一创建 VPC 终端节点：
+ `com.amazonaws.region.transfer`
+ `com.amazonaws.region.transfer-fips`— 创建符合联邦信息处理标准 (FIPS) 出版物 140-3 美国政府标准的接口 VPC 终端节点。
如果为端点启用私有 DNS，则可以使用其默认 DNS 名称作为区域，向 AWS Transfer Family APIs 发送 API 请求，例如 `transfer.us-east-1.amazonaws.com`。
# 中的基础设施安全 AWS Transfer Family
作为一项托管服务 AWS Transfer Family ，受 AWS 全球网络安全的保护。有关 AWS 安全服务以及如何 AWS 保护基础设施的信息，请参阅[AWS 云安全](https://aws.amazon.com/security/)。要使用基础设施安全的最佳实践来设计您的 AWS 环境，请参阅 S * AWS ecurity Pillar Well-Architected Fram* ework 中的[基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。
您可以使用 AWS 已发布的 API 调用 AWS Transfer Family 通过网络进行访问。客户端必须支持以下内容：
+ 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。
+ 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。
## 避免将服务器放在 NLBs AWS Transfer Family 服务器前面 NATs
**注意**
配置有 FTP 和 FTPS 协议的服务器仅允许使用 VPC 进行配置：没有可用于 FTP/FTPS 的公共终端节点。
许多客户将 Network Load Balancer (NLB) 配置为将流量路由到其 AWS Transfer Family 服务器。他们之所以这样做，要么是因为他们之前创建了服务器， AWS 提供了一种从 VPC 内部和互联网访问服务器的方法，要么是为了支持 Internet 上的 FTP。这种配置不仅会增加客户的成本，还可能导致其他问题，我们在本节中对此进行了介绍。
当客户端从公司防火墙后面的客户专用网络进行连接时，NAT 网关是必不可少的组件。但是，您应该注意，当许多客户端位于同一 NAT 网关后面时，这可能会影响性能和连接限制。如果从客户端到 FTP 或 FTPS 服务器的通信路径中有 NLB 或 NAT，则服务器无法准确识别客户端的 IP 地址，因为只能 AWS Transfer Family 看到 NLB 或 NAT 的 IP 地址。
如果您在 NLB 后面使用 Transfer Family 服务器的配置，我们建议您移至 VPC 终端节点并使用弹性 IP 地址而不是 NLB。使用 NAT 网关时，请注意下述的连接限制。
如果您使用的是 FTPS 协议，则此配置不仅会降低您审核谁在访问您的服务器的能力，而且还会影响性能。 AWS Transfer Family 使用源 IP 地址在我们的数据平面上对您的连接进行分片。对于 FTPS 来说，这意味着通信路由上带有 NLB 或 NAT 网关的 Transfer Family 服务器不会同时拥有 10,000 个连接，而是仅限于 300 个同步连接。
尽管我们建议避免在 AWS Transfer Family 服务器前面使用网络负载均衡器，但如果您的 FTP 或 FTPS 实施需要在客户端的通信路由中使用 NLB 或 NAT，请遵循以下建议：
+ 对于 NLB，请使用端口 21 而不是端口 8192-8200 进行运行状况检查。
+ 对于 AWS Transfer Family 服务器，通过设置启用 TLS 会话恢复`TlsSessionResumptionMode = ENFORCED`。
**注意**
这是推荐的模式，因为它提供了增强的安全性：
要求客户端在后续连接中使用 TLS 会话恢复。
通过确保一致的加密参数来提供更强的安全保障。
有助于防止潜在的降级攻击。
在优化性能的同时保持对安全标准的合规性。
+ 如果可能，请停止使用 NLB，以充分利用 AWS Transfer Family 性能和连接限制。
有关 NLB 替代方案的更多指导，请通过 AWS Support 联系 AWS Transfer Family 产品管理团队。有关改善安全状况的更多信息，请参阅博客文章《[提高 AWS Transfer Family 服务器安全性的六个技巧》](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/)。
## VPC 连接基础设施安全
具有 VPC 出口类型的 SFTP 连接器通过网络隔离和私有连接提供增强的基础设施安全性：
### 网络隔离的好处
+ **私有网络流量**：所有到私有 SFTP 服务器的连接器流量都保留在您的 VPC 内，从不通过公共互联网。
+ **受控出口**：对于通过 VPC 访问的公共终端节点，流量通过您的 NAT 网关路由，让您能够控制出口 IP 地址和网络策略。
+ **VPC 安全控制**：利用现有 VPC 安全组 ACLs、网络和路由表来控制连接器网络访问。
+ **混合连接**：通过已建立的 VPN 或 Direct Connect 连接访问本地 SFTP 服务器，无需额外的互联网接入。
### 资源网关安全注意事项
资源网关为跨VPC资源访问提供安全的入口点：
+ **多可用区部署**：资源网关要求子网位于至少两个可用区中，以实现高可用性和容错能力。
+ **安全组控制**：将安全组配置为仅限授权来源访问 SFTP 端口（通常为端口 22）。
+ **私有子网放置**：连接到私有 SFTP 服务器时，在私有子网中部署资源网关以保持网络隔离。
+ **连接限制**：每个资源网关最多支持 350 个并发连接，TCP 连接的空闲超时时间为 350 秒。
# 添加 Web 应用程序防火墙
AWS WAF 是一种 Web 应用程序防火墙，可帮助保护 Web 应用程序和 APIs 免受攻击。通过它，您可以配置一组规则（称为 *Web 访问控制列表*，即 Web ACL），基于可自定义的 Web 安全规则以及您定义的条件，允许、阻止或统计 Web 请求。有关更多信息，请参阅[使用 AWS WAF 保护您的 APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)。
**要添加 AWS WAF**
1. 打开 API Gateway 控制台，网址为[https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/)。
1. 在**APIs**导航窗格中，然后选择您的自定义身份提供商模板。
1. 选择 **Stages (阶段)**。
1. 在 **Stages (阶段)** 窗格中，选择该阶段的名称。
1. 在 **Stage Editor (阶段编辑器)** 窗格中，选择**设置**选项卡。
1. 请执行以下操作之一：
+ 在 **Web 应用程序防火墙 (WAF)** 下，选择要与此阶段关联的 **Web ACL**。
+ 如果您所需的 Web ACL 不存在，则通过以下方式创建：
1. 选择**创建 Web ACL**。
1. 在 AWS WAF 服务主页上，选择**创建 Web ACL**。
1. 在 **Web ACL 详细信息**，在 **名称** 中键入 Web ACL 的名称。
1. 在**规则**，选择**添加规则**，然后选择**添加自己的规则和规则组**。
1. 对于**规则类型**，选择 IP 集以标识特定 IP 地址列表。
1. 对于**规则**，输入规则的名称。
1. 对于 **IP 集**，请选择现有的 IP 集。要创建 IP 集，请参阅[创建 IP 集](https://docs.aws.amazon.com/waf/latest/developerguide/waf-ip-set-creating.html)。
1. 对于**用作初始地址的 IP 地址**，请选择**标头中的 IP 地址**
1. 在**标头题字段名**中，输入 `SourceIP`。
1. 对于**标头内位置**，选择**第一个 IP 地址**。
1. 对于**缺少 IP 地址的回退**，请根据标题中无效（或缺失） IP 地址的处理方式，选择**匹配**或**不匹配**。
1. 在**操作**中，选择 IP 集的操作。
1. 对于**不符合任何规则请求的默认 Web ACL 操作**，请选择**允许**或**阻止**，然后单击**下一步**。
1. 对于步骤 4 和 5，选择**下一步**。
1. 在**审核和创建**中，查看您的选择，然后选择**创建 Web ACL**。
1. 选择**保存更改**。
1. 选择**资源**。
1. 对于**操作**，选择**部署 API**。
有关使用 AWS 网络应用程序防火墙的 Transfer Family 如何安全的信息，请参阅 AWS 存储博客中的[使用 AWS 应用程序防火墙和 Amazon API Gateway 保护 Transfer Fam](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) ily。
# 防止跨服务混淆代理
混淆代理问题是一个安全性问题，即不具有某操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在中 AWS，跨服务模仿可能会导致混乱的副手问题。一个服务（*呼叫服务*）调用另一项服务（*所谓的服务*）时，可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作，否则该服务不应有访问权限。为防止这种情况， AWS 提供可帮助您保护所有服务的数据的工具，而这些服务中的服务主体有权限访问账户中的资源。有关此问题的详细描述，请参阅 *IAM 用户指南*中的[混淆代理问题](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)。
我们建议在资源策略中使用[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)和[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)全局条件上下文密钥来限制 Transf AWS er Family 对资源的权限。如果使用两个全局条件上下文键，在同一策略语句中使用时，`aws:SourceAccount` 值和 `aws:SourceArn` 值中的账户必须使用相同的账户 ID。
防止混淆代理问题的最有效方法是使用您想要允许的资源的准确 Amazon 资源名称 (ARN)。如果您要指定多个资源，请使用带有通配符 (`*`) 的 `aws:SourceArn` 全局上下文条件键来表示 ARN 的未知部分。例如 `arn:aws:transfer::region::account-id:server/*`。
AWS Transfer Family 使用以下类型的角色：
+ **用户角色**-允许服务管理的用户访问必要的 Transfer Family 资源。 AWS Transfer Family 在 Transfer Family 用户 ARN 的背景下担任此角色。
+ **访问角色** - 仅提供对正在传输的 Amazon S3 文件的访问权限。对于入站 AS2 转移，访问角色使用协议的 Amazon 资源名称 (ARN)。对于出站 AS2 传输，访问角色使用连接器的 ARN。
+ **调用角色** – 用于作为服务器自定义身份提供程序的 Amazon API Gateway。Transfer Family 在 Transfer Family 服务器 ARN 的背景下扮演这个角色。
+ **日志角色**-用于将条目登录到 Amazon CloudWatch。Transfer Family 使用此角色记录成功和失败的详细信息以及有关文件传输的信息。Transfer Family 在 Transfer Family 服务器 ARN 的背景下扮演这个角色。对于出站 AS2 传输，日志角色使用连接器 ARN。
+ **执行角色** - 允许 Transfer Family 用户调用和启动工作流程。Transfer Family 在 Transfer Family 工作流程 ARN 的背景下担任此角色。
有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。
**注意**
在以下示例中，用您自己的信息替换每个*user input placeholder*示例。
**注意**
在我们的示例中，我们同时使用 `ArnLike` 和 `ArnEquals`。它们在功能上是相同的，因此您可以在制定策略时使用其中任何一个。Transfer Family 文档在条件包含通配符时使用 `ArnLike`，`ArnEquals` 用于表示完全匹配的条件。
## AWS Transfer Family 用户角色跨服务混淆副手预防
以下示例策略允许账户中的任何服务器担任该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/*"
}
}
}
]
}
```
以下示例策略允许任何特定服务器用户承担此角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/server-id/*"
}
}
}
]
}
```
以下示例策略允许特定服务器的特定用户担任该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/server-id/user-name"
}
}
}
]
}
```
## AWS Transfer Family 工作流程角色跨服务混乱副手预防
以下示例策略允许账户中的任何工作流程担任该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-west-2:111122223333:workflow/*"
}
}
}
]
}
```
以下示例策略允许特定工作流程承担此角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-west-2:111122223333:workflow/workflow-id"
}
}
}
]
}
```
## AWS Transfer Family 连接器角色跨服务混乱副手预防
以下示例策略允许账户中的任何连接器代入该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:connector/*"
}
}
}
]
}
```
以下示例策略允许特定的连接器代入该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:connector/connector-id"
}
}
}
]
}
```
## AWS Transfer Family 日志和调用角色跨服务混淆了副手预防
**注意**
以下示例可用于日志记录和调用角色。
在这些示例中，如果您的服务器未附加任何工作流程，则可以删除工作流程的 ARN 详细信息。
以下示例 logging/invocation 策略允许账户中的任何服务器（和工作流程）代入该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAllServersWithWorkflowAttached",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:transfer:us-west-2:111122223333:server/*",
"arn:aws:transfer:us-west-2:111122223333:workflow/*"
]
}
}
}
]
}
```
以下示例 logging/invocation 策略允许特定的服务器（和工作流程）担任该角色。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificServerWithWorkflowAttached",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnEquals": {
"aws:SourceArn": [
"arn:aws:transfer:us-west-2:111122223333:server/server-id",
"arn:aws:transfer:us-west-2:111122223333:workflow/workflow-id"
]
}
}
}
]
}
```
# AWS Transfer Famil AWS y 的托管政策
要向用户、群组和角色添加权限，使用 AWS 托管策略比自己编写策略要容易得多。[创建 AWS Identity and Access Management (IAM) 客户托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)仅向您的团队提供他们所需的权限需要时间和专业知识。要快速入门，您可以使用我们的 AWS 托管策略。这些策略涵盖常见使用案例，可在您的 AWS 账户中使用。有关 AWS 托管式策略的更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。有关所有 AWS 托管策略的详细列表，请参阅[AWS 托管策略参考指南](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html)。
AWS 服务维护和更新 AWS 托管策略。您无法更改 AWS 托管策略中的权限。服务偶尔会向 AWS 托管式策略添加额外权限以支持新特征。此类更新会影响附加策略的所有身份（用户、组和角色）。当启动新特征或新操作可用时，服务最有可能会更新 AWS 托管式策略。服务不会从 AWS 托管策略中移除权限，因此策略更新不会破坏您的现有权限。
此外，还 AWS 支持跨多个服务的工作职能的托管策略。例如，`ReadOnlyAccess` AWS 托管策略提供对所有 AWS 服务和资源的只读访问权限。当服务启动一项新功能时， AWS 会为新操作和资源添加只读权限。有关工作职能策略的列表和说明，请参阅 *IAM 用户指南*中的[适用于工作职能的AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。
## AWS 托管策略： AWSTransferConsoleFullAccess
该`AWSTransferConsoleFullAccess`政策提供通过 AWS 管理控制台对 Transfer Family 的完全访问权限。有关更多信息，请参阅 Transfer F [amily 的 AWS 服务相关角色](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferConsoleFullAccess.html)。
## AWS 托管策略： AWSTransferFullAccess
此 `AWSTransferFullAccess` 策略提供对 Transfer Family 服务的完全访问权限。有关更多信息，请参阅 Transfer F [amily 的 AWS 服务相关角色](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferFullAccess.html)。
## AWS 托管策略： AWSTransferLoggingAccess
该`AWSTransferLoggingAccess`政策授予 T AWS ransfer Family 创建日志流和群组以及将日志事件存入您的账户的完全访问权限。有关更多信息，请参阅 Transfer F [amily 的 AWS 服务相关角色](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferLoggingAccess.html)。
## AWS 托管策略： AWSTransferReadOnlyAccess
此 `AWSTransferReadOnlyAccess` 策略提供对 Transfer Family 服务的只读访问权限。有关更多信息，请参阅 Transfer F [amily 的 AWS 服务相关角色](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferReadOnlyAccess.html)。
## AWS 将 Family 更新转移到 AWS 托管政策
查看 Transfer Family AWS 托管政策自该服务开始跟踪这些变更以来这些更新的详细信息。 AWS 要获得有关此页面更改的自动提示，请订阅 [的文档历史记录 AWS Transfer Family](doc-history.md) 页面上的 RSS 源。
| 更改 | 描述 | 日期 |
| --- | --- | --- |
| 文档更新 | 为每个 Transfer Family 托管策略添加章节。 | 2022 年 1 月 27 日 |
| [AWSTransferReadOnlyAccess](#security-iam-awsmanpol-transferreadonlyaccess)：对现有策略的更新 | AWS Transfer Family 添加了允许读取策略的新权限 AWS Managed Microsoft AD。 | 2021 年 9 月 30 日 |
| AWS Transfer Family 开始追踪变更 | AWS Transfer Family 开始跟踪其 AWS 托管政策的变更。 | 2021 年 6 月 15 日 |