# Security in AWS Transfer Family
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).
This documentation helps you understand how to apply the shared responsibility model when using AWS Transfer Family. The following topics show you how to configure AWS Transfer Family to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your AWS Transfer Family resources.
We offer a workshop that provides prescriptive guidance and a hands on lab on how you can build a scalable and secure file transfer architecture on AWS without needing to modify existing applications or manage server infrastructure. You can view the details for this workshop [here](https://catalog.workshops.aws/basic-security-workshop-transfer-family/en-US).
**Topics**
+ [VPC connectivity security benefits](#vpc-connectivity-security)
+ [Security policies for AWS Transfer Family servers](security-policies.md)
+ [Security policies for AWS Transfer Family SFTP connectors](security-policies-connectors.md)
+ [Using hybrid post-quantum key exchange with AWS Transfer Family](post-quantum-security-policies.md)
+ [Data protection and encryption](encryption-at-rest.md)
+ [Managing SSH and PGP keys in Transfer Family](key-management.md)
+ [Identity and access management for AWS Transfer Family](security-iam.md)
+ [Compliance validation for AWS Transfer Family](transfer-compliance.md)
+ [Resilience in AWS Transfer Family](disaster-recovery-resiliency.md)
+ [Create a private connection between a VPC and AWS Transfer Family APIs](vpc-api-endpoints.md)
+ [Infrastructure security in AWS Transfer Family](infrastructure-security.md)
+ [Add a web application firewall](web-application-firewall.md)
+ [Cross-service confused deputy prevention](confused-deputy.md)
+ [AWS managed policies for AWS Transfer Family](security-iam-awsmanpol.md)
## VPC connectivity security benefits
SFTP connectors with VPC egress type provide enhanced security benefits through Cross-VPC Resource Access:
+ **Network isolation**: All traffic remains within your VPC environment, providing complete network isolation from the public internet for private endpoint connections.
+ **Source IP control**: Remote SFTP servers only see IP addresses from your VPC CIDR range, giving you full control over the source IP addresses used for connections.
+ **Private endpoint access**: Connect directly to SFTP servers in your VPC using private IP addresses, eliminating exposure to the public internet.
+ **Hybrid connectivity**: Securely access on-premises SFTP servers through established VPN or Direct Connect connections without additional internet exposure.
+ **VPC security controls**: Leverage existing VPC security groups, NACLs, and routing policies to control and monitor SFTP connector traffic.
### VPC Lattice security model
VPC connectivity for SFTP connectors uses AWS VPC Lattice with service networks to provide secure multi-tenant access:
+ **Confused deputy prevention**: Authentication and authorization checks ensure that connectors can only access the specific resources they are configured for, preventing unauthorized cross-tenant access.
+ **IPv6-only service network**: Uses IPv6 addressing to avoid potential IP address conflicts and enhance security isolation.
+ **Forward Access Session (FAS)**: Temporary credential handling eliminates the need for long-term credential storage or manual resource sharing.
+ **Resource-level access control**: Each connector is associated with a specific Resource Configuration, ensuring granular access control to individual SFTP servers.
### Security best practices for VPC connectivity
When using VPC egress type connectors, follow these security best practices:
+ **Security groups**: Configure security groups to allow SFTP traffic (port 22) only between necessary resources. Restrict source and destination IP ranges to the minimum required.
+ **Resource Gateway placement**: Deploy Resource Gateways in private subnets when possible, and ensure they span at least two Availability Zones for high availability.
+ **Network monitoring**: Use VPC Flow Logs and Amazon CloudWatch to monitor network traffic patterns and detect anomalous activity.
+ **Access logging**: Enable connector logging to track file transfer activities and maintain audit trails for compliance requirements.
+ **Resource Configuration management**: Regularly review and update Resource Configurations to ensure they point to the correct SFTP servers and use appropriate network settings.
# Security policies for AWS Transfer Family servers
Server security policies in AWS Transfer Family allow you to limit the set of cryptographic algorithms (message authentication codes (MACs), key exchanges (KEXs), cipher suites, content encryption ciphers, and hash algorithms) associated with your server.
AWS Transfer Family supports post-quantum security policies that use hybrid key exchange algorithms, combining traditional cryptographic methods with post-quantum algorithms to provide enhanced security against future quantum computing threats. For more information, see [Using hybrid post-quantum key exchange with AWS Transfer Family](post-quantum-security-policies.md).
For a list of supported cryptographic algorithms, see [Cryptographic algorithms](#cryptographic-algorithms). For a list of supported key algorithms for use with server host keys and service-managed user keys, see [Managing SSH and PGP keys in Transfer Family](key-management.md).
**Note**
Starting in 2025, all new AWS Transfer Family security policies include post-quantum cryptographic support using hybrid key exchange algorithms. For more information about post-quantum security, see [Using hybrid post-quantum key exchange with AWS Transfer Family](post-quantum-security-policies.md).
**Note**
We strongly recommend updating your servers to our latest security policy.
`TransferSecurityPolicy-2024-01` is the default security policy attached to your server when creating a server using the console, API, or CLI.
If you create a Transfer Family server using CloudFormation and accept the default security policy, the server is assigned `TransferSecurityPolicy-2018-11`.
If you are concerned about client compatibility, please affirmatively state which security policy you wish to use when creating or updating a server rather than using the default policy, which is subject to change. To change the security policy for a server, see [Edit the security policy](edit-server-config.md#edit-cryptographic-algorithm).
**Note**
The earlier post quantum policies (**TransferSecurityPolicy-PQ-SSH-Experimental-2023-04** and **TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04**) are deprecated. We recommend that you use the new policies instead.
For more information on security in Transfer Family, see the following blog posts:
+ [Six tips to improve the security of your AWS Transfer Family server](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/)
+ [How Transfer Family can help you build a secure, compliant managed file transfer solution](https://aws.amazon.com/blogs/security/how-transfer-family-can-help-you-build-a-secure-compliant-managed-file-transfer-solution/)
**Topics**
+ [Cryptographic algorithms](#cryptographic-algorithms)
+ [Security policy details](#security-policy-details)
## Cryptographic algorithms
For host keys, we support the following algorithms:
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
+ `ssh-ed25519`
Additionally, the following security policies allow `ssh-rsa`:
+ TransferSecurityPolicy-2018-11
+ TransferSecurityPolicy-2020-06
+ TransferSecurityPolicy-FIPS-2020-06
+ TransferSecurityPolicy-FIPS-2023-05
+ TransferSecurityPolicy-FIPS-2024-01
**Note**
It is important to understand the distinction between the RSA key type—which is always `ssh-rsa`—and the RSA host key algorithm, which can be any of the supported algorithms.
The following is a list of supported cryptographic algorithms for each security policy.
**Note**
In the following table and policies, note the following use of algorithm types.
SFTP servers only use algorithms in the **SshCiphers**, **SshKexs**, and **SshMacs** sections.
FTPS servers only use algorithms in the **TlsCiphers** section.
FTP servers, since they don't use encryption, do not use any of these algorithms.
AS2 servers only use algorithms in the **ContentEncryptionCiphers** and **HashAlgorithms** sections. These sections define algorithms used for encrypting and signing file content.
The FIPS-2024-05 and FIPS-2024-01 security policies are identical, except that FIPS-2024-05 doesn't support the `ssh-rsa` algorithm.
Transfer Family has introduced new restricted policies that closely parallel existing policies:
The TransferSecurityPolicy-Restricted-2018-11 and TransferSecurityPolicy-2018-11 security policies are identical, except that the restricted policy doesn't support the `chacha20-poly1305@openssh.com` cipher.
The TransferSecurityPolicy-Restricted-2020-06 and TransferSecurityPolicy-2020-06 security policies are identical, except that the restricted policy doesn't support the `chacha20-poly1305@openssh.com` cipher.
\$1In the following table, the `chacha20-poly1305@openssh.com` cipher is included in the non-restricted policy only,
| Security policy | [TransferSecurityPolicy-2025-03](#security-policy-transfer-2025-03) | [TransferSecurityPolicy-FIPS-2025-03](#security-policy-transfer-2025-03-fips) | [TransferSecurityPolicy-SshAuditCompliant-2025-02](#security-policy-transferSecurityPolicy-SshAuditCompliant-2025-02) | [TransferSecurityPolicy-AS2Restricted-2025-07](#security-policy-transfer-as2restricted-2025-07) | [TransferSecurityPolicy-2024-01](#security-policy-transfer-2024-01) | **[TransferSecurityPolicy-FIPS-2024-01/TransferSecurityPolicy-FIPS-2024-05](#security-policy-transfer-fips-2024-01)** | [TransferSecurityPolicy-2023-05](#security-policy-transfer-2023-05) | [TransferSecurityPolicy-FIPS-2023-05](#security-policy-transfer-fips-2023-05) | [TransferSecurityPolicy-2022-03](#security-policy-transfer-2022-03) | **[TransferSecurityPolicy-2020-06 and TransferSecurityPolicy-Restricted-2020-06](#security-policy-transfer-2020-06)** | [TransferSecurityPolicy-FIPS-2020-06](#security-policy-transfer-fips-2020-06) | **[TransferSecurityPolicy-2018-11 and TransferSecurityPolicy-Restricted-2018-11](#security-policy-transfer-2018-11)** |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |
| **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\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | | | | | | | | | | | | ♦ |
| TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA256 | | | | | | | | | | | | ♦ |
## Security policy details
The following sections contain the JSON representation of each security policy.
### TransferSecurityPolicy-2025-03
The following shows the TransferSecurityPolicy-2025-03 security policy.
```
{
"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
The following shows the TransferSecurityPolicy-FIPS-2025-03 security policy.
```
{
"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-AS2Restricted-2025-07
This security policy is designed for AS2 file transfers that require enhanced security by excluding legacy cryptographic algorithms. It supports modern AES encryption and SHA-2 hash algorithms while removing support for weaker algorithms like 3DES and SHA-1.
**Note**
This security policy is identical to TransferSecurityPolicy-2025-03, except that it does not support 3DES (in ContentEncryptionCiphers) and does not support SHA1 (in HashAlgorithms). It includes all algorithms from 2025-03, including post-quantum cryptographic algorithms (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"
]
}
}
```
### TransferSecurityPolicy-SshAuditCompliant-2025-02
The following shows the TransferSecurityPolicy-SshAuditCompliant-2025-02 security policy.
**Note**
This security policy is designed around the recommendations provided by the `ssh-audit` tool, and is 100% compliant with that tool.
```
{
"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-2024-01
The following shows the TransferSecurityPolicy-2024-01 security policy.
```
{
"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-FIPS-2024-01/TransferSecurityPolicy-FIPS-2024-05
The following shows the TransferSecurityPolicy-FIPS-2024-01 and TransferSecurityPolicy-FIPS-2024-05 security policies.
**Note**
The FIPS service endpoint and TransferSecurityPolicy-FIPS-2024-01 and TransferSecurityPolicy-FIPS-2024-05 security policies are only available in some AWS Regions. For more information, see [AWS Transfer Family endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html) in the *AWS General Reference*.
The only difference between these two security policies is that TransferSecurityPolicy-FIPS-2024-01 supports the `ssh-rsa` algorithm, and TransferSecurityPolicy-FIPS-2024-05 doesn't.
```
{
"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-2023-05
The following shows the TransferSecurityPolicy-2023-05 security policy.
```
{
"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-FIPS-2023-05
The FIPS certification details for AWS Transfer Family can be found at [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)
The following shows the TransferSecurityPolicy-FIPS-2023-05 security policy.
**Note**
The FIPS service endpoint and TransferSecurityPolicy-FIPS-2023-05 security policy is only available in some AWS Regions. For more information, see [AWS Transfer Family endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html) in the *AWS General Reference*.
```
{
"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-2022-03
The following shows the TransferSecurityPolicy-2022-03 security policy.
```
{
"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 and TransferSecurityPolicy-Restricted-2020-06
The following shows the TransferSecurityPolicy-2020-06 security policy.
**Note**
The TransferSecurityPolicy-Restricted-2020-06 and TransferSecurityPolicy-2020-06 security policies are identical, except that the restricted policy doesn't support the `chacha20-poly1305@openssh.com` cipher.
```
{
"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-FIPS-2020-06
The FIPS certification details for AWS Transfer Family can be found at [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)
The following shows the TransferSecurityPolicy-FIPS-2020-06 security policy.
**Note**
The FIPS service endpoint and TransferSecurityPolicy-FIPS-2020-06 security policy are only available in some AWS Regions. For more information, see [AWS Transfer Family endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html) in the *AWS General Reference*.
```
{
"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-2018-11 and TransferSecurityPolicy-Restricted-2018-11
The following shows the TransferSecurityPolicy-2018-11 security policy.
**Note**
The TransferSecurityPolicy-Restricted-2018-11 and TransferSecurityPolicy-2018-11 security policies are identical, except that the restricted policy doesn't support the `chacha20-poly1305@openssh.com` cipher.
```
{
"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"
]
}
}
```
# Security policies for AWS Transfer Family SFTP connectors
SFTP connector security policies in AWS Transfer Family allow you to limit the set of cryptographic algorithms (message authentication codes (MACs), key exchanges (KEXs), and cipher suites) associated with your SFTP connector. The following is a list of supported cryptographic algorithms for each SFTP connector security policy.
**Note**
`TransferSFTPConnectorSecurityPolicy-2024-03` is the default security policy that is applied to SFTP connectors.
You can change the security policy for your connector. Select **Connectors** from the Transfer Family left navigation pane, and select your connector. Then select **Edit** in the **Sftp configuration** section. In the **Cryptographic algorithm options** section, choose any available security policy from the dropdown list in the **Security Policy** field.
## Cryptographic algorithms
For host keys, SFTP connectors support all the algorithms that are supported for Transfer Family servers, except for ed25519:
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
Additionally, for host keys, we support `ssh-rsa`, but only for `TransferSFTPConnectorSecurityPolicy-2023-07`.
For authentication, SFTP connectors support the following key types:
+ `ssh-rsa`
+ `ecdsa`
## SFTP connector security policy details
The following table shows the specific cryptographic algorithms supported by each SFTP connector security policy.
| Security policy | TransferSFTPConnectorSecurityPolicy-FIPS-2024-10 | TransferSFTPConnectorSecurityPolicy-2024-03 | TransferSFTPConnectorSecurityPolicy-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 | | | ♦ |
# Using hybrid post-quantum key exchange with AWS Transfer Family
Transfer Family supports a hybrid post-quantum key establishment option for the Secure Shell (SSH) protocol. Post-quantum key establishment is needed because it's already possible to record network traffic and save it for decryption in future by a quantum computer, which is called a *store-now-harvest-later* attack.
You can use this option when you connect to Transfer Family for secure file transfers into and out of Amazon Simple Storage Service (Amazon S3) storage or Amazon Elastic File System (Amazon EFS). Post-quantum hybrid key establishment in SSH introduces post-quantum key establishment mechanisms, which it uses in conjunction with classical key exchange algorithms. SSH keys created with classical cipher suites are safe from brute-force attacks with current technology. However, classical encryption isn't expected to remain secure after the emergence of large-scale quantum computing in the future.
If your organization relies on the long-term confidentiality of data passed over a Transfer Family connection, you should consider a plan to migrate to post-quantum cryptography before large-scale quantum computers become available for use.
To protect data encrypted today against potential future attacks, AWS is participating with the cryptographic community in the development of quantum-resistant or post-quantum algorithms. We've implemented hybrid post-quantum key exchange cipher suites in Transfer Family that combine classic and post-quantum elements.
These hybrid cipher suites are available for use on your production workloads in most AWS Regions. However, because the performance characteristics and bandwidth requirements of hybrid cipher suites are different from those of classic key exchange mechanisms, we recommend that you test them on your Transfer Family connections.
Find out more about post-quantum cryptography in the [Post-Quantum Cryptography](https://aws.amazon.com/security/post-quantum-cryptography/) security blog post.
**Contents**
+ [About post-quantum hybrid key exchange in SSH](#pq-about-key-exchange)
+ [How post-quantum hybrid key establishment works in Transfer Family](#pqtls-details)
+ [Why ML-KEM?](#why-mlkem)
+ [Post-quantum hybrid SSH key exchange and cryptographic requirements (FIPS 140)](#pq-alignment)
+ [Testing post-quantum hybrid key exchange in Transfer Family](#pq-policy-testing)
+ [Enable post-quantum hybrid key exchange on your SFTP endpoint](#pq-enable-policy)
+ [Set up an SFTP client that supports post-quantum hybrid key exchange](#pq-client-openssh)
+ [Confirm post-quantum hybrid key exchange in SFTP](#pq-verify-exchange)
## About post-quantum hybrid key exchange in SSH
Transfer Family supports post-quantum hybrid key exchange cipher suites, which uses both the classical [Elliptic Curve Diffie-Hellman (ECDH)](https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final) key exchange algorithm, and ML-KEM. ML-KEM is a post-quantum public-key encryption and key-establishment algorithm that the [National Institute for Standards and Technology(NIST)](https://csrc.nist.gov/projects/post-quantum-cryptography) has designated as its first standard post-quantum key-agreement algorithm.
The client and server still do an ECDH key exchange. Additionally, the server encapsulates a post-quantum shared secret to the client’s post-quantum KEM public key, which is advertised in the client’s SSH key exchange message. This strategy combines the high assurance of a classical key exchange with the security of the proposed post-quantum key exchanges, to help ensure that the handshakes are protected as long as the ECDH or the post-quantum shared secret cannot be broken.
## How post-quantum hybrid key establishment works in Transfer Family
AWS recently announced support for post-quantum key exchange in SFTP file transfers in AWS Transfer Family. Transfer Family securely scales business-to-business file transfers to AWS Storage services using SFTP and other protocols. SFTP is a more secure version of the File Transfer Protocol (FTP) that runs over SSH. The post-quantum key exchange support of Transfer Family raises the security bar for data transfers over SFTP.
The post-quantum hybrid key exchange SFTP support in Transfer Family includes combining post-quantum algorithms ML-KEM-768, and ML-KEM-1024, with ECDH over P256, P384, or Curve25519 curves. The following corresponding SSH key exchange methods are specified in [the post-quantum hybrid SSH key exchange draft](https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/).
+ `mlkem768nistp256-sha256`
+ `mlkem1024nistp384-sha384`
+ `mlkem768x25519-sha256`
### Why ML-KEM?
AWS is committed to supporting standardized, interoperable algorithms. ML-KEM is the only post-quantum key exchange algorithm standardized and approved by the [NIST Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography). Standards bodies are already integrating ML-KEM into protocols. AWS already supports ML-KEM in TLS in some AWS API endpoints.
As part of this commitment, AWS has submitted a draft proposal to the IETF for post-quantum cryptography that combines ML-KEM with NIST-approved curves like P256 for SSH. To help enhance security for our customers, the AWS implementation of the post-quantum key exchange in SFTP and SSH follows that draft. We plan to support future updates to it until our proposal is adopted by the IETF and becomes a standard.
The new key exchange methods (listed in section [How post-quantum hybrid key establishment works in Transfer Family](#pqtls-details)) might change as the draft evolves towards standardization.
**Note**
Post-quantum algorithm support is currently available for post-quantum hybrid key exchange in TLS for AWS KMS ( see [Using hybrid post-quantum TLS with AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html)),AWS Certificate Manager, and AWS Secrets Manager API endpoints.
### Post-quantum hybrid SSH key exchange and cryptographic requirements (FIPS 140)
For customers that require FIPS compliance, Transfer Family provides FIPS-approved cryptography in SSH by using the AWS FIPS 140-certified, open-source cryptographic library, AWS-LC. The post-quantum hybrid key exchange methods supported in the TransferSecurityPolicy-FIPS-2025-03 in Transfer Family are FIPS approved according to [NIST's SP 800-56Cr2 (section 2)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf). The German Federal Office for Information Security ([ 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)) and the Agence nationale de la sécurité des systèmes d'information ([ANSSI](https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/)) of France also recommend such post-quantum hybrid key exchange methods.
## Testing post-quantum hybrid key exchange in Transfer Family
This section describes the steps you take to test post-quantum hybrid key exchange.
1. [Enable post-quantum hybrid key exchange on your SFTP endpoint](#pq-enable-policy).
1. Use an SFTP client (such as [Set up an SFTP client that supports post-quantum hybrid key exchange](#pq-client-openssh)) that supports post-quantum hybrid key exchange by following the guidance in the aforementioned draft specification.
1. Transfer a file using a Transfer Family server.
1. [Confirm post-quantum hybrid key exchange in SFTP](#pq-verify-exchange).
### Enable post-quantum hybrid key exchange on your SFTP endpoint
You can choose the SSH policy when you create a new SFTP server endpoint in Transfer Family, or by editing the Cryptographic algorithm options in an existing SFTP endpoint. The following snapshot shows an example of the AWS Management Console where you update the SSH policy.
![\[Shows the post-quantum policy selected for the Cryptographic algorithm options.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/post-quantum-policy-choose.png)
The SSH policy names that support post-quantum key exchange are **TransferSecurityPolicy-2025-03** and **TransferSecurityPolicy-FIPS-2025-03**. For more details on Transfer Family policies, see [Security policies for AWS Transfer Family servers](security-policies.md).
### Set up an SFTP client that supports post-quantum hybrid key exchange
After you select the correct post-quantum SSH policy in your SFTP Transfer Family endpoint, you can experiment with post-quantum SFTP in Transfer Family. Install the latest OpenSSH client (such as version 9.9) on your local system to test.
**Note**
Make sure that your client supports one or more of the ML-KEM algorithms listed earlier. You can view the supported algorithms for your version of OpenSSH by running this command: `ssh -Q kex`.
You can run the example SFTP client to connect to your SFTP endpoint (for example, `s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com`) by using the post-quantum hybrid key exchange methods, as shown in the following command.
```
sftp -v -o \
KexAlgorithms=mlkem768x25519-sha256 \
-i username_private_key_PEM_file \
username@server-id.server.transfer.region-id.amazonaws.com
```
In the previous command, replace the following items with your own information:
+ Replace *username\$1private\$1key\$1PEM\$1file* with the SFTP user's private key PEM-encoded file
+ Replace *username* with the SFTP user name
+ Replace *server-id* with the Transfer Family server ID
+ Replace *region-id* with the actual region where your Transfer Family server is located
### Confirm post-quantum hybrid key exchange in SFTP
To confirm that post-quantum hybrid key exchange was used during an SSH connection for SFTP to Transfer Family, check the client output. Optionally, you can use a packet capture program. If you use the OpenSSH 9.9 client, the output should look similar to the following (omitting irrelevant information for brevity):
```
% 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>
```
The output shows that client negotiation occurred using the post-quantum hybrid `mlkem768x25519-sha256` method and successfully established an SFTP session.
# Data protection and encryption
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Transfer Family (Transfer Family). As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. This content includes the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, see the [AWS shared responsibility model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual user accounts with AWS IAM Identity Center. That way each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We support TLS 1.2.
+ Set up API and user activity logging with AWS CloudTrail.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing personal data that is stored in Amazon S3.
+ If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal information processing standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put sensitive identifying information, such as your customers' account numbers, into free-form fields such as a **Name** field. This includes when you work with Transfer Family or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any configuration data that you enter into Transfer Family service configuration, or other services' configurations, might get picked up for inclusion in diagnostic logs. When you provide a URL to an external server, don't include credentials information in the URL to validate your request to that server.
In contrast, data from upload and download operations into and out of Transfer Family servers is treated as completely private and never exists outside of encrypted channels—such as an SFTP or FTPS connection. This data is only ever accessible to authorized persons.
## Data encryption in Transfer Family
AWS Transfer Family uses the default encryption options you set for your Amazon S3 bucket to encrypt your data. When you enable encryption on a bucket, all objects are encrypted when they are stored in the bucket. The objects are encrypted by using server-side encryption with either Amazon S3 managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) managed keys (SSE-KMS). For information about server-side encryption, see [Protecting data using server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html) in the *Amazon Simple Storage Service User Guide*.
The following steps show you how to encrypt data in AWS Transfer Family.
**To allow encryption in AWS Transfer Family**
1. Enable default encryption for your Amazon S3 bucket. For instructions, see [Amazon S3 default encryption for S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) in the *Amazon Simple Storage Service User Guide*.
1. Update the AWS Identity and Access Management (IAM) role policy that is attached to the user to grant the required AWS Key Management Service (AWS KMS) permissions.
1. If you are using a session policy for the user, the session policy must grant the required AWS KMS permissions.
The following example shows an IAM policy that grants the minimum permissions required when using AWS Transfer Family with an Amazon S3 bucket that is enabled for AWS KMS encryption. Include this example policy in both the user IAM role policy and session policy, if you are using one.
```
{
"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"
}
```
**Note**
The KMS key ID that you specify in this policy must be the same as the one specified for the default encryption in step 1.
Root, or the IAM role that is used for the user, must be allowed in the AWS KMS key policy. For information about the AWS KMS key policy, see [Using key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide*.
## AWS Transfer Family encryption at rest
Because AWS Transfer Family is a file transfer service, it doesn't manage your storage data at rest. The storage services and systems that AWS Transfer Family supports are responsible for protecting data in that state. However, there is some service-related data that AWS Transfer Family manages at rest.
### What's encrypted?
The only data that AWS Transfer Family handles at rest relates to the details it needs to operate your file transfer servers and process transfers. AWS Transfer Family stores the following data with full at-rest encryption in Amazon DynamoDB:
+ Server configurations (for example, server settings, protocol configurations, and endpoint details).
+ User authentication data, including SSH public keys and user metadata.
+ Workflow execution details and step configurations.
+ Connector configurations and authentication credentials for third-party systems. These credentials are encrypted using AWS Transfer Family managed encryption keys.
#### Key management
You can't manage the encryption keys that AWS Transfer Family uses to store information in DynamoDB related to running your servers and processing transfers. This information includes your server configurations, user authentication data, workflow details, and connector credentials.
### What's not encrypted?
Though AWS Transfer Family doesn't control how your storage data is encrypted at rest, we still recommend configuring your storage locations with the highest level of security that they support. For example, you can encrypt objects with Amazon S3 managed encryption keys (SSE-S3) or AWS KMS keys (SSE-KMS).
Learn more about how AWS storage services encrypt data at rest:
+ [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)
# Managing SSH and PGP keys in Transfer Family
In this section, you can find information about SSH keys, including how to generate them and how to rotate them. For details about using Transfer Family with AWS Lambda to manage keys, see the blog post [Enabling user self-service key management with AWS Transfer Family and AWS Lambda](https://aws.amazon.com/blogs/storage/enabling-user-self-service-key-management-with-aws-transfer-family-and-aws-lambda/). For automated deployment and management of users with multiple SSH keys, see [Transfer Family Terraform modules](terraform.md).
**Note**
AWS Transfer Family accepts RSA, ECDSA, and ED25519 keys for SSH authentication.
This section also covers how to generate and manage Pretty Good Privacy (PGP) keys.
For a comprehensive overview of all supported encryption and key algorithms, including recommendations for different use cases, see [Encryption and key algorithms overview](#encryption-algorithms-overview).
## Encryption and key algorithms overview
AWS Transfer Family supports different types of algorithms for different purposes. Understanding which algorithms to use for your specific use case helps ensure secure and compatible file transfers.
**Algorithm Quick Reference**
| Use Case | Recommended Algorithm | FIPS Compliant | Notes |
| --- | --- | --- | --- |
| SSH/SFTP Authentication | RSA (rsa-sha2-256/512), ECDSA, or ED25519 | RSA: Yes, ECDSA: Yes, ED25519: No | Compatible with all SSH clients and servers |
| PGP Key Generation | RSA or ECC (NIST) | Yes | For workflow decryption |
| PGP File Encryption | AES-256 | Yes | Determined by PGP software |
## SSH authentication algorithms
These algorithms are used for SSH/SFTP authentication between clients and AWS Transfer Family servers. Choose one of these when generating SSH key pairs for user authentication or server host keys.
RSA (Recommended)
**Compatible with all SSH clients and servers, and FIPS-compliant.** Use with SHA-2 hashing for enhanced security:
+ `rsa-sha2-256` - Recommended for most use cases
+ `rsa-sha2-512` - Higher security option
ED25519
**Modern and efficient.** Smaller key sizes with strong security:
+ `ssh-ed25519` - Fast and secure, but not FIPS-compliant
ECDSA
**Elliptic curve option.** Good balance of security and performance:
+ `ecdsa-sha2-nistp256` - Standard curve
+ `ecdsa-sha2-nistp384` - Higher security curve
+ `ecdsa-sha2-nistp521` - Highest security curve
**Note**
We support `ssh-rsa` with SHA1 for older security policies. For details, see [Cryptographic algorithms](security-policies.md#cryptographic-algorithms).
**Choosing the right SSH algorithm**
+ **For most users:** Use RSA with `rsa-sha2-256` or `rsa-sha2-512`
+ **For FIPS compliance:** Use RSA or ECDSA algorithms
+ **For modern environments:** ED25519 offers excellent security and performance
## PGP encryption and decryption algorithms
PGP (Pretty Good Privacy) uses two types of algorithms working together to encrypt and decrypt files in workflows:
1. **Key pair algorithms** - Used to generate the public/private key pairs for encryption and digital signatures
1. **Symmetric algorithms** - Used to encrypt the actual file data (the key pair algorithms encrypt the symmetric key)
### PGP key pair algorithms
Choose one of these algorithms when generating PGP key pairs for workflow decryption:
RSA (Recommended)
**Recommended for most users.** Widely supported, well-established, and FIPS-compliant. Provides good balance of security and compatibility.
ECC (Elliptic Curve Cryptography)
**More efficient than RSA** with smaller key sizes while maintaining strong security:
+ **NIST curves** - Standard curves widely supported and FIPS-compliant
+ **BrainPool curves** - Alternative curves for specific compliance requirements
+ **Curve25519** - Modern high-performance curve offering strong security with efficient computation
ElGamal
**Legacy algorithm.** Supported for compatibility with older systems. Use RSA or ECC for new implementations.
For detailed instructions on generating PGP keys, see [Generate PGP keys](generate-pgp-keys.md).
### PGP symmetric encryption algorithms
These algorithms encrypt your actual file data. The algorithm used depends on how the PGP file was created by your PGP software:
**FIPS-compliant algorithms (recommended for regulated environments)**
+ **AES-128, AES-192, AES-256** - Advanced Encryption Standard (recommended)
+ **3DES** - Triple Data Encryption Standard (legacy, use AES when possible)
**Other supported algorithms**
+ IDEA, CAST5, Blowfish, DES, TwoFish, CAMELLIA-128, CAMELLIA-192, CAMELLIA-256
**Note**
You don't choose the symmetric algorithm directly when using AWS Transfer Family workflows - it's determined by the PGP software used to create the encrypted file. However, you can configure your PGP software to prefer FIPS-compliant algorithms like AES-256.
For more information about supported symmetric algorithms, see [Supported symmetric encryption algorithms](nominal-steps-workflow.md#symmetric-algorithms).
# Generate SSH keys for service-managed users
You can set up your server to authenticate users using the service managed authentication method, where usernames and SSH keys are stored within the service. The user's public SSH key is uploaded to the server as a user's property. This key is used by the server as part of a standard key-based authentication process. Each user can have multiple public SSH keys on file with an individual server. For limits on number of keys that can be stored per user, see [AWS Transfer Family endpoints and quotas](https://docs.aws.amazon.com//general/latest/gr/transfer-service.html) in the *Amazon Web Services General Reference*.
As an alternative to the service managed authentication method, you can authenticate users using a custom identity provider, or AWS Directory Service for Microsoft Active Directory. For more information, see [Working with custom identity providers](custom-idp-intro.md) or [Using AWS Directory Service for Microsoft Active Directory](directory-services-users.md).
A server can only authenticate users using one method (service managed, directory service, or custom identity provider), and that method cannot be changed after the server is created.
**Topics**
+ [Creating SSH keys on macOS, Linux, or Unix](macOS-linux-unix-ssh.md)
+ [Creating SSH keys on Microsoft Windows](windows-ssh.md)
+ [Converting an SSH2 key to SSH public key format](convert-ssh2-public-key.md)
# Creating SSH keys on macOS, Linux, or Unix
On the macOS, Linux, or Unix operating systems, you use the `ssh-keygen` command to create an SSH public key and SSH private key also known as a key pair.
**Note**
In the following examples, we do not specify a passphrase: in this case, the tool asks you to enter your passphrase and then repeat it to verify. Creating a passphrase offers better protection for your private key, and might also improve overall system security. You cannot recover your passphrase: if you forget it, you must create a new key.
However, if you are generating a server host key, you *must* specify an empty passphrase, by specifying the `-N ""` option in the command (or by pressing **Enter** twice when prompted), because Transfer Family servers cannot request a password at start-up.
**To create SSH keys on a macOS, Linux, or Unix operating system**
1. On macOS, Linux, or Unix operating systems, open a command terminal.
1. AWS Transfer Family accepts RSA-, ECDSA-, and ED25519-formatted keys. Choose the appropriate command based on the type of key-pair you are generating.
**Tip**: Replace `key_name` with the actual name of your SSH key pair file.
+ To generate an RSA 4096-bit key pair:
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ To generate an ECDSA 521-bit key-pair (ECDSA has bit sizes of 256, 384, and 521):
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ To generate an ED25519 key pair:
```
ssh-keygen -t ed25519 -f key_name
```
The following shows an example of the `ssh-keygen` output.
```
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]-----+
```
**Tip**: When you run the `ssh-keygen` command as shown preceding, it creates the public and private keys as files in the current directory.
Your SSH key pair is now ready to use. Follow steps 3 and 4 to store the SSH public key for your service-managed users. These users use the keys when they transfer files on Transfer Family server endpoints.
1. Navigate to the `key_name.pub` file and open it.
1. Copy the text and paste it in **SSH public key** for the service-managed user.
1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), then select **Servers** from the navigation pane.
1. On the **Servers** page, select the **Server ID** for server that contains the user that you want to update.
1. Select the user for which you are adding a public key.
1. In the **SSH public keys** pane, choose **Add SSH public key**.
![\[The AWS Transfer Family console, showing the user details for a selected user.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-user-add-key-01.png)
1. Paste the text of the public key you generated into the SSH public key text box, and then choose **Add key**.
![\[The AWS Transfer Family console, showing the Add key page for adding a public key.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-user-add-key-02.png)
The new key is listed in the SSH public key pane.
![\[The AWS Transfer Family console, showing the newly added public key in the SSH public keys section.\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/edit-user-add-key-03.png)
# Creating SSH keys on Microsoft Windows
Windows includes OpenSSH as a built-in feature, which you can use to generate SSH keys in the same format as on Linux or macOS. Alternatively, you can use third-party tools like PuTTY's key generator (PuTTYgen).
## Using Windows built-in OpenSSH
Recent versions of Windows include OpenSSH by default. You can use the same `ssh-keygen` commands as described in the macOS/Linux section:
1. Open Windows PowerShell or Command Prompt.
1. Run one of the following commands based on the type of key you want to generate:
+ To generate an RSA 4096-bit key pair:
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ To generate an ECDSA 521-bit key-pair:
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ To generate an ED25519 key pair:
```
ssh-keygen -t ed25519 -f key_name
```
1. Follow the same steps as in the macOS/Linux section to upload your public key to AWS Transfer Family.
## Using PuTTYgen (third-party tool)
Some third-party SSH clients for Windows, such as PuTTY, use different key formats. PuTTY uses the `PPK` format for private keys. If you're using PuTTY or related tools like WinSCP, you can use PuTTYgen to create keys in this format.
**Note**
If you present WinSCP with a private key file not in `.ppk` format, that client offers to convert the key into `.ppk` format for you.
For a tutorial about creating SSH keys by using PuTTYgen, see the [SSH.com website](https://www.ssh.com/ssh/putty/windows/puttygen).
# Converting an SSH2 key to SSH public key format
AWS Transfer Family only accepts SSH-formatted public keys. If you have an SSH2 public key, you need to convert it. An SSH2 public key has the following format:
```
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20160402"
AAAAB3NzaC1yc2EAAAABJQAAAgEAiL0jjDdFqK/kYThqKt7THrjABTPWvXmB3URI
:
:
---- END SSH2 PUBLIC KEY ----
```
An SSH public key has the following format:
```
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAA...
```
Run the following command to convert an SSH2-formatted public key into an SSH-formatted public key. Replace *ssh2-key* with the name of your SSH2 key, and *ssh-key* with the name of your SSH key.
```
ssh-keygen -i -f ssh2-key.pub > ssh-key.pub
```
# Rotate SSH keys
For security, we recommend the best practice of rotating your SSH keys. Usually, this rotation is specified as a part of a security policy and is implemented in some automated fashion. Depending upon the level of security, for a highly sensitive communication, an SSH key pair might be used only once. Doing this eliminates any risk due to stored keys. However, it is much more common to store SSH credentials for a period of time and set an interval that doesn't place undue burden on users. A time interval of three months is common.
**Note**
For automated SSH key rotation using infrastructure as code, see [Transfer Family Terraform modules](terraform.md).
There are two methods used to perform SSH key rotation:
+ On the console, you can upload a new SSH public key and delete an existing SSH public key.
+ Using the API, you can update existing users by using the [DeleteSshPublicKey](https://docs.aws.amazon.com//transfer/latest/APIReference/API_DeleteSshPublicKey.html) API to delete a user's Secure Shell (SSH) public key and the [ImportSshPublicKey](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ImportSshPublicKey.html) API to add a new Secure Shell (SSH) public key to the user's account.
------
#### [ Console ]
**To perform a key rotation in the console**
1. Open the AWS Transfer Family console at [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Navigate to the **Servers** page.
1. Choose the identifier in the **Server ID** column to see the **Server details** page.
1. Under **Users**, select the check box of the user whose SSH public key that you want to rotate, then choose **Actions**, and then choose **Add key** to see the **Add key** page.
or
Choose the username to see the **User details** page, and then choose **Add SSH public key** to see the **Add key** page.
1. Enter the new SSH public key and choose **Add key**.
**Important**
The format of the SSH public key depends on the type of key you generated.
For RSA keys, the format is `ssh-rsa string`.
For ED25519 keys, the format is `ssh-ed25519 string`.
For ECDSA keys, the key begins with `ecdsa-sha2-nistp256`, `ecdsa-sha2-nistp384`, or `ecdsa-sha2-nistp521`, depending on the size of the key you generated. The beginning string is then followed by `string`, similar to the other key types.
You are returned to the **User details** page, and the new SSH public key that you just entered appears in the **SSH public keys** section.
1. Select the check box of the old you key that you want to delete and then choose **Delete**.
1. Confirm the deletion operation by entering the word `delete`, and then choose **Delete**.
------
#### [ API ]
**To perform a key rotation using the API**
1. On macOS, Linux, or Unix operating systems, open a command terminal.
1. Retrieve the SSH key that you want to delete by entering the following command. To use this command, replace `serverID` with the server ID for your Transfer Family server, and replace `username` with your username.
```
aws transfer describe-user --server-id='serverID' --user-name='username'
```
The command returns details about the user. Copy the contents of the `"SshPublicKeyId":` field. You will need to enter this value later in this procedure.
```
"SshPublicKeys": [ { "SshPublicKeyBody": "public-key", "SshPublicKeyId": "keyID",
"DateImported": 1621969331.072 } ],
```
1. Next, import a new SSH key for your user. At the prompt, enter the following command. To use this command, replace `serverID` with the server ID for your Transfer Family server, replace `username` with your username, and replace `public-key` with the fingerprint of your new public key.
```
aws transfer import-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-body='public-key'
```
``If the command is successful, no output is returned.
1. Finally, delete the old key by running the following command. To use this command, replace `serverID` with the server ID for your Transfer Family server, replace `username` with your username, and replace `keyID-from-step-2` with the key ID value that you copied in step 2 of this procedure
```
aws transfer delete-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-id='keyID-from-step-2'
```
1. (Optional) To confirm that the old key no longer exists, repeat step 2.
------
# Generate PGP keys
You can use Pretty Good Privacy (PGP) decryption with the files that Transfer Family processes with workflows. To use decryption in a workflow step, provide a PGP key. For detailed information about PGP key algorithms, including recommendations and FIPS compliance, see [PGP key pair algorithms](key-management.md#pgp-key-algorithms).
The AWS storage blog has a post that describes how to simply decrypt files without writing any code using Transfer Family Managed workflows, [Encrypt and decrypt files with PGP and AWS Transfer Family](https://aws.amazon.com/blogs/storage/encrypt-and-decrypt-files-with-pgp-and-aws-transfer-family/).
The operator that you use to generate your PGP keys depends on your operating system and the version of the key-generation software that you're using.
If you're using Linux or Unix, use your package installer to install `gpg`. Depending on your Linux distribution, one of the following commands should work for you.
```
sudo yum install gnupg
```
```
sudo apt-get install gnupg
```
For Windows or macOS, you can download what you need from [https://gnupg.org/download/](https://gnupg.org/download/).
After you install your PGP key generator software, you run the `gpg --full-gen-key` or `gpg --gen-key` command to generate a key pair.
**Note**
If you're using `GnuPG` version 2.3.0 or newer, you must run `gpg --full-gen-key`. When prompted for the type of key to create, choose RSA or ECC. If you choose **ECC**, you can choose from NIST, BrainPool and Curve25519 for the elliptic curve.
**Useful `gpg` subcommands**
The following are some useful subcommands for `gpg`:
+ `gpg --help` – This command lists the available options and might include some examples.
+ `gpg --list-keys` – This command lists the details for all the key pairs that you have created.
+ `gpg --fingerprint` – This command lists the details for all your key pairs, including each key's fingerprint.
+ `gpg --export -a user-name` – This command exports the public key portion of the key for the `user-name` that was used when the key was generated.
# Manage PGP keys
To manage your PGP keys, use AWS Secrets Manager.
**Note**
Your secret name includes your Transfer Family server ID. This means you should have already identified or created a server *before* you can store your PGP key information in AWS Secrets Manager.
If you want to use one key and passphrase for all of your users, you can store the PGP key block information under the secret name `aws/transfer/server-id/@pgp-default`, where `server-id` is the ID for your Transfer Family server. Transfer Family uses this default key if there is no key where the `user-name` matches the user that's executing the workflow.
You can create a key for a specific user. In this case, the format for the secret name is `aws/transfer/server-id/user-name`, where `user-name` matches the user that's running the workflow for a Transfer Family server.
**Note**
You can store a maximum of 3 PGP private keys, per Transfer Family server, per user.
**To configure PGP keys for use with decryption**
1. Depending on the version of GPG that you are using, run one of the following commands to generate a PGP key pair.
+ If you are using **GnuPG** version 2.3.0 or newer, run the following command:
```
gpg --full-gen-key
```
You can choose **RSA**, or, if you choose **ECC**, you can choose either **NIST**, **BrainPool** or **Curve25519** for the elliptic curve. If you run `gpg --gen-key` instead, you create a key pair that uses the ECC Curve 25519 encryption algorithm.
+ For versions of **GnuPG** prior to 2.3.0, you can use the following command, since RSA is the default encryption type.
```
gpg --gen-key
```
**Important**
During the key-generation process, you must provide a passphrase and an email address. Make sure to take note of these values. You must provide the passphrase when you enter the key's details into AWS Secrets Manager later in this procedure. And you must provide the same email address to export the private key in the next step.
1. Run the following command to export the private key. To use this command, replace `private.pgp` with the name of the file in which to save the private key block, and `marymajor@example.com` with the email address that you used when you generated the key pair.
```
gpg --output private.pgp --armor --export-secret-key marymajor@example.com
```
1. Use AWS Secrets Manager to store your PGP key.
1. Sign in to the AWS Management Console and open the AWS Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).
1. In the left navigation pane, choose **Secrets**.
1. On the **Secrets** page, choose **Store a new secret**.
1. On the **Choose secret type** page, for **Secret type**, select **Other type of secret**.
1. In the **Key/value pairs** section, choose the **Key/value** tab.
+ **Key** – Enter **PGPPrivateKey**.
**Note**
You must enter the **PGPPrivateKey** string exactly: do not add any spaces before or between characters.
+ **value** – Paste the text of your private key into the value field. You can find the text of your private key in the file (for example, `private.pgp`) that you specified when you exported your key earlier in this procedure. The key begins with `-----BEGIN PGP PRIVATE KEY BLOCK-----` and ends with `-----END PGP PRIVATE KEY BLOCK-----`.
**Note**
Make sure that the text block contains only the private key and does not contain the public key as well.
1. Select **Add row** and in the **Key/value pairs** section, choose the **Key/value** tab.
+ **Key** – Enter **PGPPassphrase**.
**Note**
You must enter the **PGPPassphrase** string exactly: do not add any spaces before or between characters.
+ **value** – Enter the passphrase you used when you generated your PGP key pair.
![\[\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/pgp-secrets-01.png)
**Note**
You can add up to 3 sets of keys and passphrases. To add a second set, add two new rows, and enter **PGPPrivateKey2** and **PGPPassphrase2** for the keys, and paste in another private key and passphrase. To add a third set, key values must be **PGPPrivateKey3** and **PGPPassphrase3**.
1. Choose **Next**.
1. On the **Configure secret** page, enter a name and description for your secret.
+ If you're creating a default key, that is, a key that can be used by any Transfer Family user, enter **aws/transfer/*server-id*/@pgp-default**. Replace `server-id` with the ID of the server that contains the workflow that has a decrypt step.
+ If you're creating a key to be used by a specific Transfer Family user, enter **aws/transfer/*server-id*/*user-name***. Replace `server-id` with the ID of the server that contains the workflow that has a decrypt step, and replace `user-name` with the name of the user that's running the workflow. The `user-name` is stored in the identity provider that the Transfer Family server is using.
1. Choose **Next** and accept the defaults on the **Configure rotation** page. Then choose **Next**.
1. On the **Review** page, choose **Store** to create and store the secret.
The following screenshot shows the details for the user **marymajor** for a specific Transfer Family server. This example shows three keys and their corresponding passphrases.
![\[\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/pgp-secrets-02.png)
# Supported PGP clients
The following clients have been tested with Transfer Family and can be used to generate PGP keys, and to encrypt files that you intend to decrypt with a workflow.
+ **Gpg4win \$1 Kleopatra**.
**Note**
When you select **Sign / Encrypt Files**, make sure to clear the selection for **Sign as**: we do not currently support signing for encrypted files.
![\[\]](http://docs.aws.amazon.com/transfer/latest/userguide/images/workflows-step-decrypt-kleopatra.png)
If you sign the encrypted file and attempt to upload it to a Transfer Family server with a decryption workflow, you receive the following error:
```
Encrypted file with signed message unsupported
```
+ Major **GnuPG** versions: 2.4, 2.3, 2.2, 2.0, and 1.4.
Note that other PGP clients might work as well, but only the clients mentioned here have been tested with Transfer Family.
# Identity and access management for AWS Transfer Family
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS Transfer Family resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How AWS Transfer Family works with IAM](security_iam_service-with-iam.md)
+ [AWS Transfer Family identity-based policy examples](security_iam_id-based-policy-examples.md)
+ [AWS Transfer Family tag-based policy examples](security_iam_tag-based-policy-examples.md)
+ [Troubleshooting AWS Transfer Family identity and access](security_iam_troubleshoot.md)
+ [IAM condition keys for organizational governance](transfer-condition-keys.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting AWS Transfer Family identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How AWS Transfer Family works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [AWS Transfer Family identity-based policy examples](security_iam_id-based-policy-examples.md))
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### Federated identity
As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.
A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.
For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.
### IAM users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
### IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.
IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.
### Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.
Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.
### Access control lists (ACLs)
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.
### Other policy types
AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How AWS Transfer Family works with IAM
Before you use AWS Identity and Access Management (IAM) to manage access to AWS Transfer Family, you should understand what IAM features are available to use with AWS Transfer Family. To get a high-level view of how AWS Transfer Family and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [AWS Transfer Family identity-based policies](#security_iam_service-with-iam-id-based-policies)
+ [AWS Transfer Family resource-based policies](#security_iam_service-with-iam-resource-based-policies)
+ [Authorization based on AWS Transfer Family tags](#security_iam_service-with-iam-tags)
+ [AWS Transfer Family IAM roles](#security_iam_service-with-iam-roles)
## AWS Transfer Family identity-based policies
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. AWS Transfer Family supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *AWS Identity and Access Management User Guide*.
### Actions
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
Policy actions in AWS Transfer Family use the following prefix before the action: `transfer:`. For example, to grant someone permission to create a server, with the Transfer Family `CreateServer` API operation, you include the `transfer:CreateServer` action in their policy. Policy statements must include either an `Action` or `NotAction` element. AWS Transfer Family defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows.
```
"Action": [
"transfer:action1",
"transfer:action2"
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action.
```
"Action": "transfer:Describe*"
```
To see a list of AWS Transfer Family actions, see [Actions defined by AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-actions-as-permissions) in the *Service Authorization Reference*.
### Resources
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
The Transfer Family server resource has the following ARN.
```
arn:aws:transfer:${Region}:${Account}:server/${ServerId}
```
For example, to specify the `s-01234567890abcdef` Transfer Family server in your statement, use the following ARN.
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/s-01234567890abcdef"
```
For more information about the format of ARNs, see [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) in the *Service Authorization Reference*, or [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) in the *IAM User Guide*.
To specify all instances that belong to a specific account, use the wildcard (\$1).
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/*"
```
Some AWS Transfer Family actions are performed on multiple resources, such as those used in IAM policies. In those cases, you must use the wildcard (\$1).
```
"Resource": "arn:aws:transfer:*:123456789012:server/*"
```
In some cases you need to specify more than one type of resource, for example, if you create a policy that allows access to Transfer Family servers and users. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": [
"resource1",
"resource2"
]
```
To see a list of AWS Transfer Family resources, see [Resource types defined by AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-resources-for-iam-policies) in the *Service Authorization Reference*.
### Condition keys
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
AWS Transfer Family defines its own set of condition keys and also supports using some global condition keys. To see a list of AWS Transfer Family condition keys, see [Condition keys for AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-policy-keys) in the *Service Authorization Reference*.
### Examples
To view examples of AWS Transfer Family identity-based policies, see [AWS Transfer Family identity-based policy examples](security_iam_id-based-policy-examples.md). For VPC endpoint-specific IAM policies, see [Limiting VPC endpoint access for Transfer Family servers](create-server-in-vpc.md#limit-vpc-endpoint-access).
## AWS Transfer Family resource-based policies
Resource-based policies are JSON policy documents that specify what actions a specified principal can perform on the AWS Transfer Family resource and under what conditions. Amazon S3 supports resource-based permissions policies for Amazon S3 *buckets*. Resource-based policies let you grant usage permission to other accounts on a per-resource basis. You can also use a resource-based policy to allow an AWS service to access your Amazon S3 *buckets*.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the [principal in a resource-based policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). Adding a cross-account principal to a resource-based policy is only half of establishing the trust relationship. When the principal and the resource are in different AWS accounts, you must also grant the principal entity permission to access the resource. Grant permission by attaching an identity-based policy to the entity. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For more information, see [How IAM roles differ from resource-based policies ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)in the *AWS Identity and Access Management User Guide*.
The Amazon S3 service supports only one type of resource-based policy called a **bucket* policy*, which is attached to a *bucket*. This policy defines which principal entities (accounts, users, roles, and federated users) can perform actions on the object.
### Examples
To view examples of AWS Transfer Family resource-based policies, see [AWS Transfer Family tag-based policy examples](security_iam_tag-based-policy-examples.md).
## Authorization based on AWS Transfer Family tags
You can attach tags to AWS Transfer Family resources or pass tags in a request to AWS Transfer Family. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `transfer:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. For information about how to use tags to control access to AWS Transfer Family resources, see [AWS Transfer Family tag-based policy examples](security_iam_tag-based-policy-examples.md).
## AWS Transfer Family IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity within your AWS account that has specific permissions.
### Using temporary credentials with AWS Transfer Family
You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
AWS Transfer Family supports using temporary credentials.
# AWS Transfer Family identity-based policy examples
By default, IAM users and roles don't have permission to create or modify AWS Transfer Family resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *AWS Identity and Access Management User Guide*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices)
+ [Using the AWS Transfer Family console](#security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](#security_iam_id-based-policy-examples-view-own-permissions)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete AWS Transfer Family resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Using the AWS Transfer Family console
To access the AWS Transfer Family console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS Transfer Family resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (IAM users or roles) with that policy. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *AWS Identity and Access Management User Guide*.
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you're trying to perform.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or 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 tag-based policy examples
The following are examples of how to control access to AWS Transfer Family resources based on tags.
## Using tags to control access to AWS Transfer Family resources
Conditions in IAM policies are part of the syntax that you use to specify permissions to AWS Transfer Family resources. You can control access to AWS Transfer Family resources (such as users, servers, roles, and other entities) based on tags on those resources. Tags are key-value pairs. For more information about tagging resources, see [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) in the *AWS General Reference*.
In AWS Transfer Family, resources can have tags, and some actions can include tags. When you create an IAM policy, you can use tag condition keys to control the following:
+ Which users can perform actions on an AWS Transfer Family resource, based on tags that the resource has.
+ What tags can be passed in an action's request.
+ Whether specific tag keys can be used in a request.
By using tag-based access control, you can apply finer control than at the API level. You also can apply more dynamic control than by using resource-based access control. You can create IAM policies that allow or deny an operation based on tags provided in the request (request tags). You can also create IAM policies based on tags on the resource that is being operated on (resource tags). In general, resource tags are for tags that are already on resources, request tags are for when you're adding tags to or removing tags from a resource.
For the complete syntax and semantics of tag condition keys, see [Controlling access to AWS resources using resource tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) in the *IAM User Guide*. For details about specifying IAM policies with API Gateway, see [Control access to an API with IAM permissions](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) in the *API Gateway Developer Guide*.
### Example 1: Deny actions based on resource tags
You can deny an action to be performed on a resource based on tags. The following example policy denies `TagResource`, `UntagResource`, `StartServer`, `StopServer`, `DescribeServer`, and `DescribeUser` operations if the user or server resource is tagged with the key `stage` and the value `prod`.
****
```
{
"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"
}
}
}
]
}
```
### Example 2: Allow actions based on resource tags
You can allow an action to be performed on a resource based on tags. The following example policy allows `TagResource`, `UntagResource`, `StartServer`, `StopServer`, `DescribeServer`, and `DescribeUser` operations if the user or server resource is tagged with the key `stage` and the value `prod`.
****
```
{
"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"
}
}
}
]
}
```
### Example 3: Deny creation of a user or server based on request tags
The following example policy contains two statements. The first statement denies the `CreateServer` operation on all resources if the cost center key for the tag doesn't have a value.
The second statement denies the `CreateServer` operation if the cost center key for the tag contains any other value besides 1, 2 or 3.
**Note**
This policy does allow creating or deleting a resource that contains a key called `costcenter` and a value of `1`, `2`, or `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"
]
}
}
}
]
}
```
# Troubleshooting AWS Transfer Family identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Transfer Family and IAM.
**Topics**
+ [I am not authorized to perform an action in AWS Transfer Family](#security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my AWS Transfer Family resources](#security_iam_troubleshoot-cross-account-access)
## I am not authorized to perform an action in AWS Transfer Family
If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your sign-in credentials.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a *widget* but does not have `transfer:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: transfer:GetWidget on resource: my-example-widget
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `transfer;:GetWidget` action.
## I am not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to AWS Transfer Family.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in AWS Transfer Family. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
The following example policy contains the permission to pass a role to AWS Transfer Family. Replace **123456789012** with your AWS account ID and **MyTransferRole** with your actual IAM role name.
****
```
{
"Version":"2012-10-17",
"Statement": [
{ "Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MyTransferRole",
"Effect": "Allow"
}
]
}
```
## I want to allow people outside of my AWS account to access my AWS Transfer Family resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether AWS Transfer Family supports these features, see [How AWS Transfer Family works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
# IAM condition keys for organizational governance
AWS Transfer Family provides IAM condition keys that allow you to restrict resource configurations in any IAM policy. These condition keys can be used in identity-based policies attached to users or roles, or Service Control Policies (SCPs) for organizational governance.
Service Control Policies are IAM policies that apply to an entire AWS organization, providing preventative guardrails across multiple accounts. When used in SCPs, these condition keys help enforce security and compliance requirements organization-wide.
**See also**
+ [Actions, resources, and condition keys for Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html)
+ [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
+ Video describing how to enforce preventive guardrails using service control policies
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/mEO05mmbSms)
## Available condition keys
AWS Transfer Family supports the following condition keys for use in IAM policies:
`transfer:RequestServerEndpointType`
Restricts server creation and updates based on endpoint type (PUBLIC, VPC, VPC\$1ENDPOINT). Commonly used to prevent public-facing endpoints.
`transfer:RequestServerProtocols`
Restricts server creation and updates based on supported protocols (SFTP, FTPS, FTP, AS2).
`transfer:RequestServerDomain`
Restricts server creation based on domain type (S3, EFS).
`transfer:RequestConnectorProtocol`
Restricts connector creation based on protocol (AS2, SFTP).
## Supported actions
The condition keys can be applied to the following AWS Transfer Family actions:
+ `CreateServer`: Supports `RequestServerEndpointType`, `RequestServerProtocols`, and `RequestServerDomain` condition keys
+ `UpdateServer`: Supports `RequestServerEndpointType` and `RequestServerProtocols` condition keys
+ `CreateConnector`: Supports `RequestConnectorProtocol` condition key
## Example SCP policy
The following example SCP prevents the creation of public AWS Transfer Family servers across your organization:
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyPublicTransferServers",
"Effect": "Deny",
"Action": ["transfer:CreateServer", "transfer:UpdateServer"],
"Resource": "*",
"Condition": {
"StringEquals": {
"transfer:RequestServerEndpointType": "PUBLIC"
}
}
}]
}
```
# Compliance validation for AWS Transfer Family
Third-party auditors assess the security and compliance of AWS Transfer Family as part of multiple AWS compliance programs. These include SOC, PCI, HIPAA, and others. For the complete list, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope).
For a list of AWS services in scope of specific compliance programs, see [AWS services in scope by compliance program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS compliance programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS Transfer Family is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security and compliance quick start guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS.
+ [Architecting for HIPAA security and compliance whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/introduction.html) – This whitepaper describes how companies can use AWS to create HIPAA-compliant applications.
+ [AWS compliance resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – This AWS service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.
# Resilience in AWS Transfer Family
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
AWS Transfer Family supports up to 3 Availability Zones and is backed by an auto scaling, redundant fleet for your connection and transfer requests.
For all Transfer Family endpoints:
+ Availability Zone-level redundancy is built into the service.
+ There are redundant fleets for each AZ.
+ This redundancy is provided automatically.
**Note**
For endpoints in a Virtual Private Cloud (VPC), it is possible to provide a single subnet. However, we recommend that you create endpoints in multiple availability zones within your VPC, to reduce the risk of service disruptions during Availability Zone outages.
**See also**
+ For details on how to create Transfer Family servers in a VPC, see [Create a server in a virtual private cloud](create-server-in-vpc.md).
+ For more information about AWS Regions and Availability Zones, see [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
+ For an example on how to build for higher redundancy and minimize network latency by using Latency-based routing, see the blog post [Minimize network latency with your AWS Transfer Family servers](https://aws.amazon.com/blogs/storage/minimize-network-latency-with-your-aws-transfer-for-sftp-servers/).
# Create a private connection between a VPC and AWS Transfer Family APIs
You can establish a private connection between your VPC and AWS Transfer Family APIs by creating an *interface VPC endpoint*, powered by [AWS PrivateLink](https://aws.amazon.com/privatelink/). You can access AWS Transfer Family APIs as if it were in your VPC, without using an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC don't need public IP addresses to communicate with AWS Transfer Family APIs.
We create an endpoint network interface in each subnet that you enable for the interface endpoint. For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the *AWS PrivateLink Guide*. Before you set up an interface VPC endpoint for AWS Transfer Family APIs, review [Considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the *AWS PrivateLink Guide*.
## Controlling access using VPC endpoint policies
By default, full access to AWS Transfer Family APIs is allowed through the endpoint. You can control access to the interface endpoint using VPC endpoint policies. You can attach an endpoint policy to your VPC endpoint that controls access to AWS Transfer Family APIs. The policy specifies the following information:
+ The **principal** that can perform actions.
+ The **actions** that can be performed.
+ The **resources** on which actions can be performed.
For more information, see [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *Amazon VPC User Guide*.
The following is an example of an endpoint policy for AWS Transfer Family APIs. When attached to an endpoint, this policy grants access to all AWS Transfer Family APIs actions on all resources, except those that are tagged with key `Environment` and value `Test`.
```
{
"Statement": [{
"Effect": "Deny",
"Action": "transfer:StartFileTransfer",
"Principal": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "Test"
}
}
}, {
"Effect": "Allow",
"Action": "transfer:*",
"Principal": "*",
"Resource": "*"
}]
}
```
## Create an interface VPC endpoint for AWS Transfer Family APIs
You can create a VPC endpoint for AWS Transfer Family APIs using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.
Create a VPC endpoint for AWS Transfer Family APIs using one of the following service names:
+ `com.amazonaws.region.transfer`
+ `com.amazonaws.region.transfer-fips` — To create an interface VPC endpoint that complies with the Federal Information Processing Standard (FIPS) Publication 140-3 US government standard.
If you enable private DNS for the endpoint, you can make API requests to AWS Transfer Family APIs using its default DNS name for the Region, for example, `transfer.us-east-1.amazonaws.com`.
# Infrastructure security in AWS Transfer Family
As a managed service, AWS Transfer Family is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access AWS Transfer Family through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
## Avoid placing NLBs and NATs in front of AWS Transfer Family servers
**Note**
Servers configured with FTP and FTPS protocols only allow a configuration with a VPC: there is no public endpoint available for FTP/FTPS.
Many customers configure a Network Load Balancer (NLB) to route traffic to their AWS Transfer Family server. They typically do this either because they created their server before AWS offered a way to access it from both inside their VPC and from the internet, or to support FTP on the internet. This configuration not only increases costs for customers, but can also cause other issues, which we describe in this section.
NAT gateways are a mandatory component when clients are connecting from a customer private network behind a corporate firewall. However, you should be aware that when many clients are behind the same NAT gateway, this can impact performance and connection limits. If there's an NLB or NAT in the communication path from the client to the FTP or FTPS server, the server can't accurately recognize the client's IP address, because AWS Transfer Family sees only the IP address of the NLB or NAT.
If you're using the configuration of a Transfer Family server behind an NLB, we recommend that you move to a VPC endpoint and use an Elastic IP address instead of using an NLB. When using NAT gateways, be aware of the connection limitations described below.
If you're using the FTPS protocol, this configuration not only reduces your ability to audit who's accessing your server, but it can also impact performance. AWS Transfer Family uses the source IP address to shard your connections across our data plane. For FTPS, this means that instead of having 10,000 simultaneous connections, Transfer Family servers with NLB or NAT gateways on the communication route are limited to only 300 simultaneous connections.
Although we recommend avoiding Network Load Balancers in front of AWS Transfer Family servers, if your FTP or FTPS implementation requires an NLB or NAT in the communication route from the client, follow these recommendations:
+ For an NLB, use port 21 for health checks, instead of ports 8192-8200.
+ For the AWS Transfer Family server, enable TLS session resumption by setting `TlsSessionResumptionMode = ENFORCED`.
**Note**
This is the recommended mode, as it provides enhanced security:
Requires clients to use TLS session resumption for subsequent connections.
Provides stronger security guarantees by ensuring consistent encryption parameters.
Helps prevent potential downgrade attacks.
Maintains compliance with security standards while optimizing performance.
+ If possible, migrate away from using an NLB to take full advantage of AWS Transfer Family performance and connection limits.
For additional guidance on NLB alternatives, contact the AWS Transfer Family Product Management team through AWS Support. For more information about improving your security posture, see the blog post [Six tips to improve the security of your AWS Transfer Family server](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/).
## VPC connectivity infrastructure security
SFTP connectors with VPC egress type provide enhanced infrastructure security through network isolation and private connectivity:
### Network isolation benefits
+ **Private network traffic**: All connector traffic to private SFTP servers remains within your VPC, never traversing the public internet.
+ **Controlled egress**: For public endpoints accessed via VPC, traffic routes through your NAT gateways, giving you control over egress IP addresses and network policies.
+ **VPC security controls**: Leverage existing VPC security groups, network ACLs, and route tables to control connector network access.
+ **Hybrid connectivity**: Access on-premises SFTP servers through established VPN or Direct Connect connections without additional internet exposure.
### Resource Gateway security considerations
Resource Gateways provide secure ingress points for Cross-VPC Resource Access:
+ **Multi-AZ deployment**: Resource Gateways require subnets in at least two Availability Zones for high availability and fault tolerance.
+ **Security group controls**: Configure security groups to restrict access to SFTP ports (typically port 22) from authorized sources only.
+ **Private subnet placement**: Deploy Resource Gateways in private subnets when connecting to private SFTP servers to maintain network isolation.
+ **Connection limits**: Each Resource Gateway supports up to 350 concurrent connections with a 350-second idle timeout for TCP connections.
# Add a web application firewall
AWS WAF is a web application firewall that helps protect web applications and APIs from attacks. You can use it to configure a set of rules known as a *web access control list* (web ACL) that allow, block, or count web requests based on customizable web security rules and conditions that you define. For more information, see [Using AWS WAF to protect your APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html).
**To add AWS WAF**
1. Open the API Gateway console at [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/).
1. In the **APIs** navigation pane, and then choose your custom identity provider template.
1. Choose **Stages**.
1. In the **Stages** pane, choose the name of the stage.
1. In the **Stage Editor** pane, choose the **Settings** tab.
1. Do one of the following:
+ Under **Web Application Firewall (WAF)**, for **Web ACL**, choose the web ACL that you want to associate with this stage.
+ If the web ACL you need doesn't exist, you will need to create one by doing the following:
1. Choose **Create Web ACL**.
1. On the AWS WAF service homepage, choose **Create web ACL**.
1. In **Web ACL details**, for **Name**, type the name of the web ACL.
1. In **Rules**, choose **Add rules**, then choose **Add my own rules and rule groups**.
1. For **Rule type**, choose IP set to identify a specific list of IP addresses.
1. For **Rule**, enter the name of the rule.
1. For **IP set**, choose an existing IP set. To create an IP set, see [Creating an IP set](https://docs.aws.amazon.com/waf/latest/developerguide/waf-ip-set-creating.html).
1. For **IP address to use as the originating address**, choose **IP address in header**.
1. For **Header field name**, enter `SourceIP`.
1. For **Position inside header**, choose **First IP address**.
1. For **Fallback for missing IP address**, choose **Match** or ** No Match** depending on how you want to handle an invalid (or missing) IP address in the header.
1. For **Action**, choose the action of the IP set.
1. For **Default web ACL action for requests that don't match any rules**, choose **Allow** or **Block** and then click **Next**.
1. For steps 4 and 5, choose **Next**.
1. In **Review and create**, review your choices, and then choose **Create web ACL**.
1. Choose **Save Changes**.
1. Choose **Resources**.
1. For **Actions**, choose **Deploy API**.
For information on how secure Transfer Family with AWS web application firewall, see [Securing Transfer Family with AWS application firewall and Amazon API Gateway](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) in the AWS storage blog.
# Cross-service confused deputy prevention
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way that it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. For a detailed description of this problem, see [the confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) in the *IAM User Guide*.
We recommend using the [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) and [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) global condition context keys in resource policies to limit the permissions that AWS Transfer Family has for the resource. If you use both global condition context keys, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement.
The most effective way to protect against the confused deputy problem is to use the exact Amazon Resource Name (ARN) of the resource you want to allow. If you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcard characters (`*`) for the unknown portions of the ARN. For example, `arn:aws:transfer::region::account-id:server/*`.
AWS Transfer Family uses the following types of roles:
+ **User role** – Allows service-managed users to access the necessary Transfer Family resources. AWS Transfer Family assumes this role in the context of a Transfer Family user ARN.
+ **Access role** – Provides access to only the Amazon S3 files that are being transferred. For inbound AS2 transfers, the access role uses the Amazon Resource Name (ARN) for the agreement. For outbound AS2 transfers, the access role uses the ARN for the connector.
+ **Invocation role** – For use with Amazon API Gateway as the server's custom identity provider. Transfer Family assumes this role in the context of a Transfer Family server ARN.
+ **Logging role** – Used to log entries into Amazon CloudWatch. Transfer Family uses this role to log success and failure details along with information about file transfers. Transfer Family assumes this role in the context of a Transfer Family server ARN. For outbound AS2 transfers, the logging role uses the connector ARN.
+ **Execution role** – Allows a Transfer Family user to call and launch workflows. Transfer Family assumes this role in the context of a Transfer Family workflow ARN.
For more information, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
**Note**
In the following examples, replace each *user input placeholder* with your own information.
**Note**
In our examples, we use both `ArnLike` and `ArnEquals`. They are functionally identical, and therefore you may use either when you construct your policies. Transfer Family documentation uses `ArnLike` when the condition contains a wildcard character, and `ArnEquals` to indicate an exact match condition.
## AWS Transfer Family user role cross-service confused deputy prevention
The following example policy allows any user of any server in the account to assume the role.
****
```
{
"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/*"
}
}
}
]
}
```
The following example policy allows any user of a specific server to assume the role.
****
```
{
"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/*"
}
}
}
]
}
```
The following example policy allows a specific user of a specific server to assume the role.
****
```
{
"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 workflow role cross-service confused deputy prevention
The following example policy allows any workflow in the account to assume the role.
****
```
{
"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/*"
}
}
}
]
}
```
The following example policy allows a specific workflow to assume the role.
****
```
{
"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 connector role cross-service confused deputy prevention
The following example policy allows any connector in the account to assume the role.
****
```
{
"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/*"
}
}
}
]
}
```
The following example policy allows a specific connector to assume the role.
****
```
{
"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 logging and invocation role cross-service confused deputy prevention
**Note**
The following examples can be used in both logging and invocation roles.
In these examples, you can remove the ARN details for a workflow if your server doesn't have any workflows attached to it.
The following example logging/invocation policy allows any server (and workflow) in the account to assume the role.
****
```
{
"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/*"
]
}
}
}
]
}
```
The following example logging/invocation policy allows a specific server (and workflow) to assume the role.
****
```
{
"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 managed policies for AWS Transfer Family
To add permissions to users, groups, and roles, it is easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create AWS Identity and Access Management (IAM) customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions that they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. For a detailed listing of all AWS managed policies, see the [AWS managed policy reference guide](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html).
AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an AWS managed policy, so policy updates won't break your existing permissions.
Additionally, AWS supports managed policies for job functions that span multiple services. For example, the `ReadOnlyAccess` AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
## AWS managed policy: AWSTransferConsoleFullAccess
The `AWSTransferConsoleFullAccess` policy provides full access to Transfer Family through the AWS Management Console. For more information, see [Service-linked role for AWS Transfer Family](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferConsoleFullAccess.html).
## AWS managed policy: AWSTransferFullAccess
The `AWSTransferFullAccess` policy provides full access to Transfer Family services. For more information, see [Service-linked role for AWS Transfer Family](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferFullAccess.html).
## AWS managed policy: AWSTransferLoggingAccess
The `AWSTransferLoggingAccess` policy grants AWS Transfer Family full access to create log streams and groups and put log events to your account. For more information, see [Service-linked role for AWS Transfer Family](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferLoggingAccess.html).
## AWS managed policy: AWSTransferReadOnlyAccess
The `AWSTransferReadOnlyAccess` policy provides read-only access to Transfer Family services. For more information, see [Service-linked role for AWS Transfer Family](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferReadOnlyAccess.html).
## AWS Transfer Family updates to AWS managed policies
View details about updates to AWS managed policies for AWS Transfer Family since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the [Document history for AWS Transfer Family](doc-history.md) page.
| Change | Description | Date |
| --- | --- | --- |
| Documentation update | Added sections for each of the Transfer Family managed policies. | January 27, 2022 |
| [AWSTransferReadOnlyAccess](#security-iam-awsmanpol-transferreadonlyaccess) – Update to an existing policy | AWS Transfer Family added new permissions to allow the policy to read AWS Managed Microsoft AD. | September 30, 2021 |
| AWS Transfer Family started tracking changes | AWS Transfer Family started tracking changes for its AWS managed policies. | June 15, 2021 |