翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS Transfer Family
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。
AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによる対象範囲内のコンプライアンス](https://aws.amazon.com/compliance/services-in-scope/)範囲内の」を参照し、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用可能な法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
このドキュメントは、 を使用する際の責任共有モデルの適用方法を理解するのに役立ちます AWS Transfer Family。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成する AWS Transfer Family ように を設定する方法について説明します。また、 AWS Transfer Family リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
既存のアプリケーションを変更したり、サーバーインフラストラクチャを管理 AWS したりすることなく、 でスケーラブルで安全なファイル転送アーキテクチャを構築する方法に関する規範的なガイダンスと実践的なラボを提供するワークショップを提供しています。このワークショップの詳細については、「[こちら](https://catalog.workshops.aws/basic-security-workshop-transfer-family/en-US)」をご覧ください。
**Topics**
+ [VPC 接続のセキュリティ上の利点](#vpc-connectivity-security)
+ [AWS Transfer Family サーバーのセキュリティポリシー](security-policies.md)
+ [AWS Transfer Family SFTP コネクタのセキュリティポリシー](security-policies-connectors.md)
+ [でのハイブリッドポスト量子キー交換の使用 AWS Transfer Family](post-quantum-security-policies.md)
+ [データ保護と暗号化](encryption-at-rest.md)
+ [Transfer Family での SSH キーと PGP キーの管理](key-management.md)
+ [の ID とアクセスの管理 AWS Transfer Family](security-iam.md)
+ [のコンプライアンス検証 AWS Transfer Family](transfer-compliance.md)
+ [の耐障害性 AWS Transfer Family](disaster-recovery-resiliency.md)
+ [VPC と AWS Transfer Family APIs間のプライベート接続を作成する](vpc-api-endpoints.md)
+ [のインフラストラクチャセキュリティ AWS Transfer Family](infrastructure-security.md)
+ [ウェブアプリケーションファイアウォールを追加する](web-application-firewall.md)
+ [サービス間の混乱した代理の防止](confused-deputy.md)
+ [AWS AWS Transfer Family の マネージドポリシー](security-iam-awsmanpol.md)
## VPC 接続のセキュリティ上の利点
VPC 出力タイプの SFTP コネクタは、クロス VPC リソースアクセスを通じてセキュリティ上の利点を強化します。
+ **ネットワーク分離**: すべてのトラフィックは VPC 環境内に留まり、プライベートエンドポイント接続のためにパブリックインターネットから完全にネットワーク分離されます。
+ **ソース IP コントロール**: リモート SFTP サーバーは VPC CIDR 範囲の IP アドレスのみを表示し、接続に使用されるソース IP アドレスを完全に制御できます。
+ **プライベートエンドポイントアクセス: **プライベート IP アドレスを使用して VPC 内の SFTP サーバーに直接接続し、パブリックインターネットへの露出を排除します。
+ **ハイブリッド接続**: インターネットにさらされることなく、確立された VPN または Direct Connect 接続を介してオンプレミス SFTP サーバーに安全にアクセスします。
+ **VPC セキュリティコントロール**: 既存の VPC セキュリティグループ、NACLs、ルーティングポリシーを活用して、SFTP コネクタトラフィックを制御およびモニタリングします。
### VPC Lattice セキュリティモデル
SFTP コネクタの VPC 接続では、VPC AWS Lattice とサービスネットワークを使用して、安全なマルチテナントアクセスを提供します。
+ **混乱した代理防止**: 認証と認可のチェックにより、コネクタは設定された特定のリソースにのみアクセスでき、不正なクロステナントアクセスを防ぐことができます。
+ **IPv6-onlyサービスネットワーク**: IPv6 アドレス指定を使用して、潜在的な IP アドレスの競合を回避し、セキュリティ分離を強化します。
+ **転送アクセスセッション (FAS)**: 一時的な認証情報処理により、認証情報の長期保存や手動リソース共有が不要になります。
+ **リソースレベルのアクセスコントロール**: 各コネクタは特定のリソース設定に関連付けられ、個々の SFTP サーバーへのきめ細かなアクセスコントロールが保証されます。
### VPC 接続のセキュリティのベストプラクティス
VPC 出力タイプのコネクタを使用する場合は、次のセキュリティのベストプラクティスに従ってください。
+ **セキュリティグループ**: 必要なリソース間でのみ SFTP トラフィック (ポート 22) を許可するようにセキュリティグループを設定します。送信元と送信先の IP 範囲を必要最小限に制限します。
+ **リソースゲートウェイの配置**: 可能な場合はプライベートサブネットにリソースゲートウェイをデプロイし、高可用性のために少なくとも 2 つのアベイラビリティーゾーンにまたがるようにします。
+ **ネットワークモニタリング**: VPC フローログと Amazon CloudWatch を使用して、ネットワークトラフィックパターンをモニタリングし、異常なアクティビティを検出します。
+ **アクセスログ**記録: コネクタログ記録を有効にしてファイル転送アクティビティを追跡し、コンプライアンス要件の監査証跡を維持します。
+ **リソース設定管理**: リソース設定を定期的に確認および更新して、正しい SFTP サーバーを指し、適切なネットワーク設定を使用していることを確認します。
# AWS Transfer Family サーバーのセキュリティポリシー
のサーバーセキュリティポリシー AWS Transfer Family を使用すると、サーバーに関連付けられた暗号化アルゴリズム (メッセージ認証コード (MACs)、キー交換 (KEXs)、暗号スイート、コンテンツ暗号化暗号、ハッシュアルゴリズム) のセットを制限できます。
AWS Transfer Family は、ハイブリッドキー交換アルゴリズムを使用するポスト量子セキュリティポリシーをサポートし、従来の暗号化メソッドとポスト量子アルゴリズムを組み合わせて、将来の量子コンピューティングの脅威に対するセキュリティを強化します。詳細については、「」を参照してください[でのハイブリッドポスト量子キー交換の使用 AWS Transfer Family](post-quantum-security-policies.md)。
サポートされている暗号アルゴリズムのリストについては、「[暗号アルゴリズム](#cryptographic-algorithms)」を参照してください。サーバーホストキーとサービス管理ユーザーキーでの使用がサポートされているキーアルゴリズムのリストについては、[Transfer Family での SSH キーと PGP キーの管理](key-management.md) を参照してください。
**注記**
サーバーを最新のセキュリティポリシーに更新することを強くお勧めします。
`TransferSecurityPolicy-2024-01` は、コンソール、API、または CLI を使用してサーバーを作成するときにサーバーにアタッチされるデフォルトのセキュリティポリシーです。
CloudFormation を使用して Transfer Family サーバーを作成し、デフォルトのセキュリティポリシーを受け入れると、サーバーには が割り当てられます`TransferSecurityPolicy-2018-11`。
クライアントの互換性について懸念がある場合は、変更される可能性のあるデフォルトポリシーを使用するのではなく、サーバーを作成または更新するときに使用するセキュリティポリシーを肯定的に記述してください。サーバーのセキュリティポリシーを変更するには、「」を参照してください[セキュリティポリシーを編集する](edit-server-config.md#edit-cryptographic-algorithm)。
Transfer Family のセキュリティの詳細については、次のブログ記事を参照してください。
+ [AWS Transfer Family サーバーのセキュリティを向上させるための 6 つのヒント](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/)
+ [Transfer Family が安全で準拠したマネージドファイル転送ソリューションの構築にどのように役立つか](https://aws.amazon.com/blogs/security/how-transfer-family-can-help-you-build-a-secure-compliant-managed-file-transfer-solution/)
**Topics**
+ [暗号アルゴリズム](#cryptographic-algorithms)
+ [TransferSecurityPolicy-2024-01](#security-policy-transfer-2024-01)
+ [TransferSecurityPolicy-SshAuditCompliant-2025-02](#security-policy-transferSecurityPolicy-SshAuditCompliant-2025-02)
+ [TransferSecurityPolicy-2023-05](#security-policy-transfer-2023-05)
+ [TransferSecurityPolicy-2022-03](#security-policy-transfer-2022-03)
+ [TransferSecurityPolicy-2020-06 および TransferSecurityPolicy-Restricted-2020-06](#security-policy-transfer-2020-06)
+ [TransferSecurityPolicy-2018-11 および TransferSecurityPolicy-Restricted-2018-11](#security-policy-transfer-2018-11)
+ [TransferSecurityPolicy-FIPS-2024-01/TransferSecurityPolicy-FIPS-2024-05](#security-policy-transfer-fips-2024-01)
+ [TransferSecurityPolicy-FIPS-2023-05](#security-policy-transfer-fips-2023-05)
+ [TransferSecurityPolicy-FIPS-2020-06](#security-policy-transfer-fips-2020-06)
+ [TransferSecurityPolicy-AS2Restricted-2025-07](#as2-restricted-policy)
+ [ポスト・クアンタム・セキュリティ・ポリシー](#pq-policies)
## 暗号アルゴリズム
ホストキーでは、次のアルゴリズムがサポートされています。
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
+ `ssh-ed25519`
さらに、次のセキュリティポリシーでは が許可されます`ssh-rsa`。
+ TransferSecurityPolicy-2018-11
+ TransferSecurityPolicy-2020-06
+ TransferSecurityPolicy-FIPS-2020-06
+ TransferSecurityPolicy-FIPS-2023-05
+ TransferSecurityPolicy-FIPS-2024-01
+ 転送セキュリティポリシー-PQ-SSH-FIPS-エクスペリメンタル-2023-04
**注記**
常に である RSA キータイプ`ssh-rsa`と、サポートされているアルゴリズムのいずれかである RSA ホストキーアルゴリズムの区別を理解することが重要です。
以下は、各セキュリティポリシーでサポートされている暗号アルゴリズムの一覧です。
**注記**
次の表とポリシーでは、アルゴリズムタイプの次の使用に注意してください。
SFTP サーバーは、**SshCiphers**、**SshKexs**、**SshMacs** セクションでのみアルゴリズムを使用します。
FTPS サーバーは、**TlsCiphers** セクションのアルゴリズムのみを使用します。
FTP サーバーは暗号化を使用しないため、これらのアルゴリズムを使用しないでください。
AS2 サーバーは、**ContentEncryptionCiphers** セクションと **HashAlgorithms** セクションでのみアルゴリズムを使用します。これらのセクションでは、ファイルのコンテンツの暗号化と署名に使用されるアルゴリズムを定義します。
FIPS-2024-05 と FIPS-2024-01 セキュリティポリシーは同じですが、FIPS-2024-05 は`ssh-rsa`アルゴリズムをサポートしていません。
Transfer Family は、既存のポリシーと密接に並列する新しい制限付きポリシーを導入しました。
TransferSecurityPolicy-Restricted-2018-11 と TransferSecurityPolicy-2018-11 セキュリティポリシーは同じですが、制限されたポリシーが`chacha20-poly1305@openssh.com`暗号をサポートしていない点が異なります。
TransferSecurityPolicy-Restricted-2020-06 セキュリティポリシーと TransferSecurityPolicy-2020-06 セキュリティポリシーは同じですが、制限されたポリシーが`chacha20-poly1305@openssh.com`暗号をサポートしていない点が異なります。
\$1次の表では、`chacha20-poly1305@openssh.com`暗号は非制限ポリシーにのみ含まれています。
| セキュリティポリシー | 2024-01 | SshAuditCompliant-2025-02 | 2023-05 | 2022-03 | **2020 年 6 月** **2020 年 6 月の制限** | **FIPS-2024-05** **FIPS-2024-01** | FIPS-2023-05 | FIPS-2020-06 | **2018 年 11 月** **2018 年 11 月の制限** | TransferSecurityPolicy-AS2Restricted-2025-07 |
| --- |--- |--- |--- |--- |--- |--- |--- |--- |--- |--- |
| **SshCiphers** |
| --- |
| aes128-ctr | ♦ | ♦ | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| aes128-gcm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes192-ctr | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes256-ctr | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes256-gcm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| chacha20-poly1305@openssh.com | | | | | ♦\$1 | | | | ♦\$1 | |
| **SshKexs** |
| --- |
| mlkem768x25519-sha256 | | | | | | | | | | ♦ |
| mlkem768nistp256-sha256 | | | | | | | | | | ♦ |
| mlkem1024nistp384-sha384 | | | | | | | | | | ♦ |
| curve25519-sha256 | ♦ | ♦ | ♦ | ♦ | | | | | ♦ | ♦ |
| curve25519-sha256@libssh.org | ♦ | ♦ | ♦ | ♦ | | | | | ♦ | ♦ |
| diffie-hellman-group14-sha1 | | | | | | | | | ♦ | |
| diffie-hellman-group14-sha256 | | | | | ♦ | | | ♦ | ♦ | |
| diffie-hellman-group16-sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| diffie-hellman-group18-sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| diffie-hellman-group-exchange-sha256 | ♦ | ♦ | ♦ | ♦ | ♦ | | ♦ | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp256 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp384 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| ecdh-sha2-nistp521 | ♦ | | | | ♦ | ♦ | | ♦ | ♦ | ♦ |
| **SshMacs** |
| --- |
| hmac-sha1 | | | | | | | | | ♦ | |
| hmac-sha1-etm@openssh.com | | | | | | | | | ♦ | |
| hmac-sha2-256 | | | | ♦ | ♦ | | | ♦ | ♦ | |
| hmac-sha2-256-etm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| hmac-sha2-512 | | | | ♦ | ♦ | | | ♦ | ♦ | |
| hmac-sha2-512-etm@openssh.com | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| umac-128-etm@openssh.com | | | | | ♦ | | | | ♦ | |
| umac-128@openssh.com | | | | | ♦ | | | | ♦ | |
| umac-64-etm@openssh.com | | | | | | | | | ♦ | |
| umac-64@openssh.com | | | | | | | | | ♦ | |
| **ContentEncryptionCiphers** |
| --- |
| aes256-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes192-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| aes128-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| 3des-cbc | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| **HashAlgorithms** |
| --- |
| sha256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| sha1 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| **TlsCiphers** |
| --- |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$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 | | | | | | | | | ♦ | |
## TransferSecurityPolicy-2024-01
TransferSecurityPolicy-2024-01 セキュリティポリシーを以下に示します。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2024-01",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-SshAuditCompliant-2025-02
TransferSecurityPolicy-SshAuditCompliant-2025-02 セキュリティポリシーを以下に示します。
**注記**
このセキュリティポリシーは、 `ssh-audit` ツールが提供する推奨事項を中心に設計されており、そのツールに 100% 準拠しています。
```
{
"SecurityPolicy": {
"Fips": false,
"Protocols": [
"SFTP",
"FTPS"
],
"SecurityPolicyName": "TransferSecurityPolicy-SshAuditCompliant-2025-02",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER"
}
}
```
## TransferSecurityPolicy-2023-05
次に示すのは TransferSecurityPolicy-2023-05 セキュリティポリシーです。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2023-05",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc",
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2022-03
次に示すのは TransferSecurityPolicy-2022-03 セキュリティポリシーです。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2022-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512",
"hmac-sha2-256"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2020-06 および TransferSecurityPolicy-Restricted-2020-06
次に示すのは TransferSecurityPolicy-2020-06 セキュリティポリシーです。
**注記**
TransferSecurityPolicy-Restricted-2020-06 セキュリティポリシーと TransferSecurityPolicy-2020-06 セキュリティポリシーは同じですが、制限されたポリシーが`chacha20-poly1305@openssh.com`暗号をサポートしていない点が異なります。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2020-06",
"SshCiphers": [
"chacha20-poly1305@openssh.com", //Not included in TransferSecurityPolicy-Restricted-2020-06
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256"
],
"SshMacs": [
"umac-128-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"umac-128@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-2018-11 および TransferSecurityPolicy-Restricted-2018-11
次に示すのは TransferSecurityPolicy-2018-11 セキュリティポリシーです。
**注記**
TransferSecurityPolicy-Restricted-2018-11 と TransferSecurityPolicy-2018-11 セキュリティポリシーは同じですが、制限されたポリシーが`chacha20-poly1305@openssh.com`暗号をサポートしていない点が異なります。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2018-11",
"SshCiphers": [
"chacha20-poly1305@openssh.com", //Not included in TransferSecurityPolicy-Restricted-2018-11
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256",
"diffie-hellman-group14-sha1"
],
"SshMacs": [
"umac-64-etm@openssh.com",
"umac-128-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"hmac-sha1-etm@openssh.com",
"umac-64@openssh.com",
"umac-128@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512",
"hmac-sha1"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512",
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
"TLS_RSA_WITH_AES_128_CBC_SHA256",
"TLS_RSA_WITH_AES_256_CBC_SHA256"
]
}
}
```
## TransferSecurityPolicy-FIPS-2024-01/TransferSecurityPolicy-FIPS-2024-05
TransferSecurityPolicy-FIPS-2024-01 および TransferSecurityPolicy-FIPS-2024-05 セキュリティポリシーを以下に示します。
**注記**
FIPS サービスエンドポイントと TransferSecurityPolicy-FIPS-2024-01 および TransferSecurityPolicy-FIPS-2024-05 セキュリティポリシーは、一部の AWS リージョンでのみ使用できます。詳細については、*AWS 全般のリファレンス*の「[AWS Transfer Family エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)」を参照してください。
これらの 2 つのセキュリティポリシーの唯一の違いは、TransferSecurityPolicy-FIPS-2024-01 が`ssh-rsa`アルゴリズムをサポートし、TransferSecurityPolicy-FIPS-2024-05 がアルゴリズムをサポートしていないことです。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2024-01",
"SshCiphers": [
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group18-sha512",
"diffie-hellman-group16-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-FIPS-2023-05
の FIPS 証明書の詳細については AWS Transfer Family 、「」を参照してください。 [https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all)
次に示すのは TransferSecurityPolicy-FIPS-2023-05 セキュリティポリシーです。
**注記**
FIPS サービスエンドポイントと TransferSecurityPolicy-FIPS-2023-05 セキュリティポリシーは、一部の AWS リージョンでのみ使用できます。詳細については、*AWS 全般のリファレンス*の「[AWS Transfer Family エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)」を参照してください。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2023-05",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-FIPS-2020-06
の FIPS 証明書の詳細については AWS Transfer Family 、「」を参照してください。 [https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all)
次に示すのは TransferSecurityPolicy-FIPS-2020-06 セキュリティポリシーです。
**注記**
FIPS サービスエンドポイントと TransferSecurityPolicy-FIPS-2020-06 セキュリティポリシーは、一部の AWS リージョンでのみ使用できます。詳細については、*AWS 全般のリファレンス*の「[AWS Transfer Family エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/transfer-service.html)」を参照してください。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2020-06",
"SshCiphers": [
"aes128-ctr",
"aes192-ctr",
"aes256-ctr",
"aes128-gcm@openssh.com",
"aes256-gcm@openssh.com"
],
"SshKexs": [
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group14-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256",
"hmac-sha2-512"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc",
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1",
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
]
}
}
```
## TransferSecurityPolicy-AS2Restricted-2025-07
このセキュリティポリシーは、レガシー暗号化アルゴリズムを除外してセキュリティを強化する必要がある AS2 ファイル転送用に設計されています。最新の AES 暗号化と SHA-2 ハッシュアルゴリズムをサポートし、3DES や SHA-1 などの弱いアルゴリズムのサポートは削除されています。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-AS2Restricted-2025-07",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"AS2"
]
}
}
```
## ポスト・クアンタム・セキュリティ・ポリシー
この表は、TTransfer Family ilyのポスト・クォンタム・セキュリティ・ポリシーのアルゴリズムを示しています。これらのポリシーについては、[でのハイブリッドポスト量子キー交換の使用 AWS Transfer Family](post-quantum-security-policies.md) で詳しく説明しています。
ポリシーの一覧は表の通りです。
**注記**
以前のポスト量子ポリシー (**TransferSecurityPolicy-PQ-SSH-Experimental-2023-04** および **TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04** は廃止されました。代わりに新しいポリシーを使用することをお勧めします。
| セキュリティポリシー | TransferSecurityPolicy-2025-03 | TransferSecurityPolicy-FIPS-2025-03 |
| --- |--- |--- |
| **SSH ciphers** |
| --- |
| aes128-ctr | ♦ | ♦ |
| aes128-gcm@openssh.com | ♦ | ♦ |
| aes192-ctr | ♦ | ♦ |
| aes256-ctr | ♦ | ♦ |
| aes256-gcm@openssh.com | ♦ | ♦ |
| **KEXs** |
| --- |
| mlkem768x25519-sha256 | ♦ | ♦ |
| mlkem768nistp256-sha256 | ♦ | ♦ |
| mlkem1024nistp384-sha384 | ♦ | ♦ |
| diffie-hellman-group14-sha256 | ♦ | ♦ |
| diffie-hellman-group16-sha512 | ♦ | ♦ |
| diffie-hellman-group18-sha512 | ♦ | ♦ |
| ecdh-sha2-nistp384 | ♦ | ♦ |
| ecdh-sha2-nistp521 | ♦ | ♦ |
| ecdh-sha2-nistp256 | ♦ | ♦ |
| diffie-hellman-group-exchange-sha256 | ♦ | ♦ |
| curve25519-sha256@libssh.org | ♦ | |
| curve25519-sha256 | ♦ | |
| **MACs** |
| --- |
| hmac-sha2-256-etm@openssh.com | ♦ | ♦ |
| hmac-sha2-512-etm@openssh.com | ♦ | ♦ |
| **ContentEncryptionCiphers** |
| --- |
| aes256-cbc | ♦ | ♦ |
| aes192-cbc | ♦ | ♦ |
| aes128-cbc | ♦ | ♦ |
| 3des-cbc | ♦ | ♦ |
| **HashAlgorithms** |
| --- |
| sha256 | ♦ | ♦ |
| sha384 | ♦ | ♦ |
| sha512 | ♦ | ♦ |
| sha1 | ♦ | ♦ |
| **TLS ciphers** |
| --- |
| TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$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 | ♦ | ♦ |
### TransferSecurityPolicy-2025-03
TransferSecurityPolicy-2025-03 セキュリティポリシーを以下に示します。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-2025-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
### TransferSecurityPolicy-FIPS-2025-03
TransferSecurityPolicy-FIPS-2025-03 セキュリティポリシーを以下に示します。
```
{
"SecurityPolicy": {
"Fips": true,
"SecurityPolicyName": "TransferSecurityPolicy-FIPS-2025-03",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes256-ctr",
"aes192-ctr",
"aes128-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"diffie-hellman-group-exchange-sha256",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512"
],
"SshMacs": [
"hmac-sha2-512-etm@openssh.com",
"hmac-sha2-256-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
"3des-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
"sha1"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
### TransferSecurityPolicy-AS2Restricted-2025-07
TransferSecurityPolicy-AS2Restricted-2025-07 セキュリティポリシーを以下に示します。
**注記**
このセキュリティポリシーは TransferSecurityPolicy-2025-03 と同じですが、3DES (ContentEncryptionCiphers 内) および SHA1 (HashAlgorithms 内) をサポートしていない点が異なります。これには、ポスト量子暗号化アルゴリズム (mlkem\$1 KEXs) を含む、2025 年 3 月のすべてのアルゴリズムが含まれます。
```
{
"SecurityPolicy": {
"Fips": false,
"SecurityPolicyName": "TransferSecurityPolicy-AS2Restricted-2025-07",
"SshCiphers": [
"aes256-gcm@openssh.com",
"aes128-gcm@openssh.com",
"aes128-ctr",
"aes256-ctr",
"aes192-ctr"
],
"SshKexs": [
"mlkem768x25519-sha256",
"mlkem768nistp256-sha256",
"mlkem1024nistp384-sha384",
"ecdh-sha2-nistp256",
"ecdh-sha2-nistp384",
"ecdh-sha2-nistp521",
"curve25519-sha256",
"curve25519-sha256@libssh.org",
"diffie-hellman-group16-sha512",
"diffie-hellman-group18-sha512",
"diffie-hellman-group-exchange-sha256"
],
"SshMacs": [
"hmac-sha2-256-etm@openssh.com",
"hmac-sha2-512-etm@openssh.com"
],
"ContentEncryptionCiphers": [
"aes256-cbc",
"aes192-cbc",
"aes128-cbc"
],
"HashAlgorithms": [
"sha256",
"sha384",
"sha512"
],
"TlsCiphers": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
],
"Type": "SERVER",
"Protocols": [
"SFTP",
"FTPS"
]
}
}
```
# AWS Transfer Family SFTP コネクタのセキュリティポリシー
の SFTP コネクタセキュリティポリシー AWS Transfer Family を使用すると、SFTP コネクタに関連付けられた暗号化アルゴリズム (メッセージ認証コード (MACs)、キー交換 (KEXs)、暗号スイート) のセットを制限できます。以下は、各 SFTP コネクタセキュリティポリシーでサポートされている暗号化アルゴリズムのリストです。
**注記**
`TransferSFTPConnectorSecurityPolicy-2024-03` は、SFTP コネクタに適用されるデフォルトのセキュリティポリシーです。
コネクタのセキュリティポリシーを変更できます。Transfer Family の左側のナビゲーションペインから**コネクタ**を選択し、コネクタを選択します。次に、**Sftp 設定**セクションで**編集**を選択します。**暗号化アルゴリズムオプション**セクションで、セキュリティポリシーフィールドのドロップダウンリストから使用可能な**セキュリティポリシー**を選択します。
## 暗号アルゴリズム
ホストキーの場合、SFTP コネクタは、ed25519 を除く Transfer Family サーバーでサポートされているすべてのアルゴリズムをサポートします。
+ `rsa-sha2-256`
+ `rsa-sha2-512`
+ `ecdsa-sha2-nistp256`
+ `ecdsa-sha2-nistp384`
+ `ecdsa-sha2-nistp521`
さらに、ホストキーでは がサポートされますが`ssh-rsa`、 でのみサポートされます`TransferSFTPConnectorSecurityPolicy-2023-07`。
認証の場合、SFTP コネクタは次のキータイプをサポートします。
+ `ssh-rsa`
+ `ecdsa`
## SFTP コネクタのセキュリティポリシーの詳細
次の表は、各 SFTP コネクタセキュリティポリシーでサポートされている特定の暗号化アルゴリズムを示しています。
| セキュリティポリシー | 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 | | | ♦ |
# でのハイブリッドポスト量子キー交換の使用 AWS Transfer Family
Transfer Family は、Secure Shell (SSH) プロトコルのハイブリッドポスト量子キー確立オプションをサポートしています。ポストクォンタムキー確立が必要なのは、ネットワークトラフィックを記録し、将来クォンタムコンピューターによって復号できるように保存することがすでに可能であるためです。これは、「store-now-harvest-later」攻撃と呼ばれています。
Transfer Family に接続すると、Amazon Simple Storage Service (Amazon S3) ストレージまたは Amazon Elastic File System (Amazon EFS) との間で安全なファイル転送を行う場合にこのオプションを使用できます。SSH でのポストクォンタムハイブリッドキー確立には、従来のキー交換アルゴリズムと組み合わせて使用するポストクォンタムキー確立メカニズムが導入されています。従来の暗号スイートで作成された SSH 鍵は、現在の技術ではブルートフォース攻撃から安全です。ただし、future、大規模な量子コンピューティングが登場しても、従来の暗号化は安全性を維持できないと予想されます。
もし、組織がトランスファーファミリー接続でやり取りされるデータの長期的な機密性に依存しているのであれば、大規模な量子コンピュータが利用可能になる前に、ポスト量子暗号への移行計画を検討すべきです。
現在暗号化されているデータを潜在的な将来の攻撃から保護するために、 AWS は量子耐性アルゴリズムまたはポスト量子アルゴリズムの開発に暗号コミュニティに参加しています。Transfer Family にハイブリッドポストクォンタムキー交換暗号スイートを実装しました。
これらのハイブリッド暗号スイートは、ほとんどの AWS リージョンで本稼働ワークロードで使用できます。ただし、ハイブリッド暗号スイートのパフォーマンス特性と帯域幅要件は、古典的な鍵交換メカニズ ムとは異なるため、Transfer Family の接続でテストすることを推奨します。
「[ポスト量子暗号技術](https://aws.amazon.com/security/post-quantum-cryptography/)」の詳細については、ポスト量子暗号のセキュリティに関するブログ記事をご覧ください。
**Contents**
+ [SSH におけるポスト量子ハイブリッドキー交換について](#pq-about-key-exchange)
+ [TransferFamilyにおけるポスト量子ハイブリッド鍵確立の仕組み](#pqtls-details)
+ [ML-KEM を使用する理由](#why-mlkem)
+ [ポスト量子ハイブリッド SSH 鍵交換と暗号要件（FIPS 140）](#pq-alignment)
+ [Transfer Family におけるポスト量子ハイブリッドキー交換のテスト](#pq-policy-testing)
+ [SFTP エンドポイントでポスト量子ハイブリッドキー交換を有効にします。](#pq-enable-policy)
+ [ポスト量子ハイブリッドキー交換をサポートする SFTP クライアントをセットアップします。](#pq-client-openssh)
+ [SFTP でのポスト量子ハイブリッドキー交換の確認](#pq-verify-exchange)
## SSH におけるポスト量子ハイブリッドキー交換について
Transfer Family は、従来の[楕円曲線 Diffie-Hellman (ECDH) ](https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final)キー交換アルゴリズムと ML-KEM の両方を使用するポスト量子ハイブリッドキー交換暗号スイートをサポートしています。ML-KEM は、[米国国立標準技術研究所 (NIST)](https://csrc.nist.gov/projects/post-quantum-cryptography) が最初の標準ポスト量子キー合意アルゴリズムとして指定したポスト量子パブリックキー暗号化およびキー確立アルゴリズムです。
クライアントとサーバーは依然として ECDH 鍵交換を行います。さらに、サーバーはポスト量子共有シークレットをクライアントのポストクォンタム KEM 公開鍵にカプセル化します。この公開鍵は、クライアントの SSH 鍵交換メッセージでアドバタイズされます。この戦略では、従来の鍵交換の高い保証と、提案されているポスト量子鍵交換のセキュリティを組み合わせて、ECDH またはポスト量子共有秘密が破られない限りハンドシェイクが確実に保護されるようにします。
## TransferFamilyにおけるポスト量子ハイブリッド鍵確立の仕組み
AWS は最近、 での SFTP ファイル転送におけるポスト量子キー交換のサポートを発表しました AWS Transfer Family。Transfer Family は、business-to-businessファイル転送を安全にスケーリングします。 AWS SFTP は、SSH 上で動作するファイル転送プロトコル (FTP) のより安全なバージョンです。TransTransfer Family ilyのポスト量子キー交換サポートにより、SFTPを介したデータ転送のセキュリティレベルが引き上げられます。
Transfer Family でのポスト量子ハイブリッドキー交換 SFTP サポートには、ポスト量子アルゴリズム ML-KEM-768 および ML-KEM-1024 と、P256, P384または Curve25519 曲線を介した ECDH の組み合わせが含まれます。「[ポスト・クォンタム・ハイブリッド SSH 鍵交換ドラフト](https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/)」では、対応する SSH 鍵交換方法として以下のものが規定されています。
+ `mlkem768nistp256-sha256`
+ `mlkem1024nistp384-sha384`
+ `mlkem768x25519-sha256`
### ML-KEM を使用する理由
AWS は、標準化された相互運用可能なアルゴリズムのサポートに取り組んでいます。ML-KEM は、[NIST Post-Quantum Cryptography プロジェクトによって標準化および承認された唯一のポスト量子](https://csrc.nist.gov/projects/post-quantum-cryptography)キー交換アルゴリズムです。標準ボディはすでに ML-KEM をプロトコルに統合しています。 AWS は、一部の AWS API エンドポイントで TLS で ML-KEM を既にサポートしています。
このコミットメントの一環として、 AWS は、ML-KEM と SSH 用の P256 のような NIST 承認曲線を組み合わせたポスト量子暗号の提案案を IETF に送信しました。お客様のセキュリティを強化するために、SFTP と SSH でのポスト量子キー交換の AWS 実装はそのドラフトに従います。私たちの提案がIETFに採用され、標準になるまで、今後の更新をサポートする予定です。
新しいキー交換方法 (セクション に記載[TransferFamilyにおけるポスト量子ハイブリッド鍵確立の仕組み](#pqtls-details)) は、ドラフトが標準化に向けて進化するにつれて変更される可能性があります。
**注記**
ポスト量子アルゴリズムのサポートは現在、TLS でのポスト量子ハイブリッドキー交換 AWS KMS (「 [でのハイブリッドポスト量子 TLS の使用」を参照 AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html))AWS Certificate Manager、および AWS Secrets Manager API エンドポイントで利用できます。
### ポスト量子ハイブリッド SSH 鍵交換と暗号要件（FIPS 140）
FIPS コンプライアンスを必要とするお客様向けに、Transfer Family は FIPS 140 認定のオープンソース暗号化ライブラリ AWS-LC を使用して SSH で AWS FIPS 認定の暗号化を提供します。Transfer Family の TransferSecurityPolicy-FIPS-2025-03 でサポートされているポスト量子ハイブリッドキー交換方法は、[NIST の SP 800-56Cr2 (セクション 2) ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf)に従って FIPS が承認されています。ドイツ連邦情報セキュリティ局（[BSI](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html)）とフランスの国家情報システムセキュリティ庁（[ANSSI](https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/)）も、このようなポスト量子ハイブリッドキー交換方法を推奨しています。
## Transfer Family におけるポスト量子ハイブリッドキー交換のテスト
このセクションでは、ポスト量子ハイブリッドキー交換をテストする手順について説明します。
1. [SFTP エンドポイントでポスト量子ハイブリッドキー交換を有効にします。](#pq-enable-policy).
1. 前述の仕様草案のガイダンスに従って、ポスト量子ハイブリッドキー交換をサポートする SFTP クライアント ([ポスト量子ハイブリッドキー交換をサポートする SFTP クライアントをセットアップします。](#pq-client-openssh) など) を使用してください。
1. Transfer Family サーバーを使用してファイルを転送します。
1. [SFTP でのポスト量子ハイブリッドキー交換の確認](#pq-verify-exchange).
### SFTP エンドポイントでポスト量子ハイブリッドキー交換を有効にします。
SSH ポリシーは、Transfer Family で新しい SFTP サーバーエンドポイントを作成するとき、または既存の SFTP エンドポイントの暗号化アルゴリズムオプションを編集するときに選択できます。次のスナップショットは、SSH ポリシー AWS マネジメントコンソール を更新する の例を示しています。
![\[暗号アルゴリズムオプションで選択されたポストクォンタムポリシーが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/post-quantum-policy-choose.png)
ポスト量子キー交換をサポートする SSH ポリシー名は、**TransferSecurityPolicy-2025-03** および **TransferSecurityPolicy-FIPS-2025-03** です。Transfer Familyポリシーの詳細については、[AWS Transfer Family サーバーのセキュリティポリシー](security-policies.md) を参照してください。
### ポスト量子ハイブリッドキー交換をサポートする SFTP クライアントをセットアップします。
SFTP Transfer Family エンドポイントで正しいポストクォンタム SSH ポリシーを選択したら、Transfer Family でポストクォンタム SFTP を試すことができます。テストするローカルシステムに最新の OpenSSH クライアント (バージョン 9.9 など) をインストールします。
**注記**
クライアントが前述の ML-KEM アルゴリズムを 1 つ以上サポートしていることを確認します。OpenSSH のバージョンでサポートされているアルゴリズムを表示するには、 コマンド を実行します`ssh -Q kex`。
次のコマンドに示すように、ポスト量子ハイブリッドキー交換メソッドを使用して、サンプル SFTP クライアントを実行して SFTP エンドポイント ( など`s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com`) に接続できます。
```
sftp -v -o \
KexAlgorithms=mlkem768x25519-sha256 \
-i username_private_key_PEM_file \
username@server-id.server.transfer.region-id.amazonaws.com
```
先のコマンドで、以下の項目を自分の情報に置き換える：
+ 「*ユーザー名\$1プライベートキー\$1PEM\$1ファイル*」を SFTP ユーザーのプライベートキー PEM エンコードファイルに置き換えます。
+ *username* はインスタンスのユーザー名に置き換えます。
+ 「*server-id*」をTransfer Family サーバー ID に置き換えます
+ 「*region-id*」をトランスポート・ファミリ・サーバが存在する実際の地域に置き換えます
### SFTP でのポスト量子ハイブリッドキー交換の確認
SFTP から Transfer Family への SSH 接続中にポスト量子ハイブリッドキー交換が使用されたことを確認するには、クライアント出力を確認します。オプションで、パケットキャプチャプログラムを使用できます。OpenSSH 9.9 クライアントを使用する場合、出力は次のようになります (簡潔にするために無関係な情報を省略）。
```
% sftp -o KexAlgorithms=mlkem768x25519-sha256 -v -o IdentitiesOnly=yes -i username_private_key_PEM_file username@s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com
OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 146: Applying options for *
debug1: Reading configuration data /Users/username/.ssh/bastions-config
debug1: Reading configuration data /opt/homebrew/etc/ssh/ssh_config
debug1: Connecting to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com [xxx.yyy.zzz.nnn] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: compat_banner: no match: AWS_SFTP_1.1
debug1: Authenticating to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com:22 as 'username'
debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Ic1Ti0cdDmFdStj06rfU0cmmNccwAha/ASH2unr6zX0
[...]
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
[...]
Authenticated to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com ([xxx.yyy.zzz.nnn]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
[...]
Connected to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com.
sftp>
```
この出力は、ポスト・クアンタム・ハイブリッド `mlkem768x25519-sha256` メソッドを使用してクライアント・ネゴシエーションが行われ、SFTP セッションが正常に確立されたことを示しています。
# データ保護と暗号化
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 AWS Transfer Family (Transfer Family) でのデータ保護に適用されます。このモデルで説明されているように、 AWS はすべての AWS クラウドを実行するグローバルインフラストラクチャを保護する責任があります。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。このコンテンツには、使用する AWS サービスのセキュリティ設定および管理タスクが含まれます。データプライバシーの詳細については、「[データプライバシーのよくある質問](https://aws.amazon.com/compliance/data-privacy-faq)」を参照してください。欧州でのデータ保護の詳細については、AWS セキュリティブログに投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」ブログを参照してください。
データ保護の目的で、 AWS アカウントの認証情報を保護し、個々のユーザーアカウントを で設定することをお勧めします AWS IAM アイデンティティセンター。この方法により、それぞれのジョブを遂行するために必要なアクセス許可のみを各ユーザーに付与できます。また、次の方法でデータを保護することをお勧めします。
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 がサポートされています。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。
+ AWS 暗号化ソリューションと、 AWS サービス内のすべてのデフォルトのセキュリティコントロールを使用します。
+ Amazon Macie などのアドバンストマネージドセキュリティサービスを使用します。これは、Amazon S3 に保存されている個人データの検出と保護を支援します。
+ コマンドラインインターフェースまたは API を使用して AWS にアクセスするときに FIPS 140−2 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[Federal information processing standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/)」(連邦情報処理規格 (FIPS) 140-2) を参照してください。
顧客のアカウント番号などの機密の識別情報は、[**Name **] (名前)フィールドなどの自由形式のフィールドに配置しないことを強くお勧めします。これは、コンソール、API、 AWS CLIまたは SDK を使用して Transfer Family または他の AWS サービスを使用する場合も同様です。 AWS SDKs Transfer Family または他のサービスに入力したデータはすべて、診断ログの内容として取得される可能性があります。外部サーバーへの URL を指定するときは、そのサーバーへのリクエストを検証するための認証情報を URL に含めないでください。
対照的に、Transfer Family サーバーへのアップロードおよびダウンロード操作のデータは完全にプライベートなものとして扱われ、SFTPまたはFTPS接続などの暗号化されたチャネルの外には存在しません。このデータには、権限のある人だけがアクセスできます。
## Transfer Family のデータ暗号化
AWS Transfer Family は、Amazon S3 バケットに設定したデフォルトの暗号化オプションを使用してデータを暗号化します。バケットで暗号化を有効にすると、バケットに保存されるすべてのオブジェクトが暗号化されます。オブジェクトは、Amazon S3 マネージドキー (SSE-S3) または AWS Key Management Service () マネージドキー (SSE-KMS AWS KMS) によるサーバー側の暗号化を使用して暗号化されます。サーバー側の暗号化の詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[サーバー側の暗号化を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html)」を参照してください。
次の手順は、 でデータを暗号化する方法を示しています AWS Transfer Family。
**で暗号化を許可するには AWS Transfer Family**
1. Amazon S3 バケットのデフォルト暗号化を有効にします。詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[S3 バケットの Amazon S3 デフォルト暗号化](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)」を参照してください。
1. ユーザーにアタッチされている AWS Identity and Access Management (IAM) ロールポリシーを更新して、必要な AWS Key Management Service (AWS KMS) アクセス許可を付与します。
1. ユーザーのセッションポリシーを使用している場合、セッションポリシーは必要な AWS KMS アクセス許可を付与する必要があります。
次の例は、 AWS KMS 暗号化が有効になっている Amazon S3 バケット AWS Transfer Family で を使用する場合に必要な最小限のアクセス許可を付与する IAM ポリシーを示しています。このポリシー例は、IAM ロールポリシーおよびセッションポリシー (使用している場合) の両方に含めます。
```
{
"Sid": "Stmt1544140969635",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey",
"kms:GetPublicKey",
"kms:ListKeyPolicies"
],
"Effect": "Allow",
"Resource": "arn:aws:kms:region:account-id:key/kms-key-id"
}
```
**注記**
このポリシーで指定する KMS キー ID は、ステップ 1 でデフォルト暗号化のために指定したものと同じである必要があります。
ルート、またはユーザーに使用される IAM ロールは、 AWS KMS キーポリシーで許可する必要があります。 AWS KMS キーポリシーの詳細については、 *AWS Key Management Service デベロッパーガイド*の[「KMS での AWS キーポリシーの使用](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)」を参照してください。
## AWS Transfer Family 保管時の暗号化
AWS Transfer Family はファイル転送サービスであるため、保管中のストレージデータは管理されません。 AWS Transfer Family がサポートするストレージサービスとシステムは、その状態のデータを保護する責任があります。ただし、 が保管中に管理するサービス関連のデータ AWS Transfer Family もあります。
### 暗号化されるもの
が保管時に AWS Transfer Family 処理する唯一のデータは、ファイル転送サーバーの運用と転送の処理に必要な詳細に関連しています。 は、Amazon DynamoDB で保管時の完全な暗号化を使用して次のデータ AWS Transfer Family を保存します。
+ サーバー設定 (サーバー設定、プロトコル設定、エンドポイントの詳細など）。
+ SSH パブリックキーとユーザーメタデータを含むユーザー認証データ。
+ ワークフロー実行の詳細とステップ設定。
+ サードパーティーシステムのコネクタ設定と認証情報。これらの認証情報は、 AWS Transfer Family マネージド暗号化キーを使用して暗号化されます。
#### キー管理
サーバーの実行と転送の処理に関連する情報を DynamoDB に保存するために が AWS Transfer Family 使用する暗号化キーを管理することはできません。この情報には、サーバー設定、ユーザー認証データ、ワークフローの詳細、コネクタ認証情報が含まれます。
### 暗号化されないのは何ですか?
AWS Transfer Family は保管時のストレージデータの暗号化方法を制御しませんが、サポートする最高レベルのセキュリティでストレージロケーションを設定することをお勧めします。たとえば、Amazon S3 マネージド暗号化キー (SSE-S3) または AWS KMS キー (SSE-KMS) を使用してオブジェクトを暗号化できます。
AWS ストレージサービスが保管中のデータを暗号化する方法について詳しく説明します。
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html)
# Transfer Family での SSH キーと PGP キーの管理
このセクションでは、SSHキーの生成方法やローテーション方法など、SSHキーに関する情報を見ることができます。で Transfer Family を使用してキー AWS Lambda を管理する方法の詳細については、ブログ記事[「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/)」を参照してください。複数の SSH キーを持つユーザーの自動デプロイと管理については、「」を参照してください[Transfer Family Terraform モジュール](terraform.md)。
**注記**
AWS Transfer Family は、SSH 認証用の RSA、ECDSA、ED25519 キーを受け入れます。
このセクションでは、プリティ・グッド・プライバシー (PGP) キーを生成して管理する方法についても説明します。
さまざまなユースケースの推奨事項など、サポートされているすべての暗号化アルゴリズムとキーアルゴリズムの包括的な概要については、「」を参照してください[暗号化とキーアルゴリズムの概要](#encryption-algorithms-overview)。
## 暗号化とキーアルゴリズムの概要
AWS Transfer Family は、さまざまな目的でさまざまなタイプのアルゴリズムをサポートしています。特定のユースケースに使用するアルゴリズムを理解することで、安全で互換性のあるファイル転送を確保できます。
**アルゴリズムクイックリファレンス**
| ユースケース | 推奨アルゴリズム | FIPS 準拠 | 注意事項 |
| --- | --- | --- | --- |
| SSH/SFTP 認証 | RSA (rsa-sha2-256/512)、ECDSA、または ED25519 | RSA: はい、ECDSA: はい、ED25519: いいえ | すべての SSH クライアントおよびサーバーと互換性があります |
| PGP キーの生成 | RSA または ECC (NIST) | はい | ワークフロー復号の場合 |
| PGP ファイルの暗号化 | AES-256 | はい | PGP ソフトウェアによって決定 |
## SSH 認証アルゴリズム
これらのアルゴリズムは、クライアントと AWS Transfer Family サーバー間の SSH/SFTP 認証に使用されます。ユーザー認証またはサーバーホストキーの SSH キーペアを生成する場合は、次のいずれかを選択します。
RSA (推奨)
**すべての SSH クライアントおよびサーバーと互換性があり、FIPS に準拠しています。**セキュリティを強化するために SHA-2 ハッシュで を使用します。
+ `rsa-sha2-256` - ほとんどのユースケースに推奨
+ `rsa-sha2-512` - セキュリティオプションの強化
ED25519
**モダンで効率的。**セキュリティが強化された小さなキーサイズ:
+ `ssh-ed25519` - 高速で安全、ただし FIPS に準拠していない
ECDSA
**楕円曲線オプション。**セキュリティとパフォーマンスの適切なバランス:
+ `ecdsa-sha2-nistp256` - 標準曲線
+ `ecdsa-sha2-nistp384` - セキュリティ曲線の向上
+ `ecdsa-sha2-nistp521` - 最高のセキュリティ曲線
**注記**
SHA1 `ssh-rsa`では、古いセキュリティポリシーがサポートされています。詳細については、「[暗号アルゴリズム](security-policies.md#cryptographic-algorithms)」を参照してください。
**適切な SSH アルゴリズムの選択**
+ **ほとんどのユーザーの場合:** `rsa-sha2-256`または で RSA を使用する `rsa-sha2-512`
+ **FIPS コンプライアンスの場合:** RSA または ECDSA アルゴリズムを使用する
+ **最新の環境の場合:** ED25519 は優れたセキュリティとパフォーマンスを提供します
## PGP 暗号化アルゴリズムと復号アルゴリズム
PGP (プリティグッドプライバシー) は、ワークフロー内のファイルを暗号化および復号化するために連携する 2 種類のアルゴリズムを使用します。
1. **キーペアアルゴリズム** - 暗号化とデジタル署名のパブリック/プライベートキーペアを生成するために使用されます
1. **対称アルゴリズム** - 実際のファイルデータを暗号化するために使用されます (キーペアアルゴリズムは対称キーを暗号化します)
### PGP キーペアアルゴリズム
ワークフロー復号用の PGP キーペアを生成するときは、次のいずれかのアルゴリズムを選択します。
RSA (推奨)
**ほとんどのユーザーに推奨されます。**幅広くサポートされ、十分に確立され、FIPS に準拠しています。セキュリティと互換性のバランスが取れています。
ECC (楕円曲線暗号)
強力なセキュリティを維持しながら、キーサイズが小さい **RSA よりも効率**的です。
+ **NIST 曲線** - 標準曲線は広くサポートされ、FIPS に準拠しています
+ **BrainPool 曲線** - 特定のコンプライアンス要件の代替曲線
+ **Curve25519** - 強力なセキュリティと効率的な計算を提供する最新の高性能曲線
ElGamal
**レガシーアルゴリズム。**古いシステムとの互換性のためにサポートされています。新しい実装には RSA または ECC を使用します。
PGP キーを生成する詳細な手順については、「」を参照してください[PGP キーを生成する](generate-pgp-keys.md)。
### PGP 対称暗号化アルゴリズム
これらのアルゴリズムは、実際のファイルデータを暗号化します。使用されるアルゴリズムは、PGP ソフトウェアによって PGP ファイルがどのように作成されたかによって異なります。
**FIPS 準拠のアルゴリズム (規制対象環境に推奨)**
+ **AES-128, AES-192, AES-256** - 高度な暗号化標準 (推奨)
+ **3DES** - トリプルデータ暗号化標準 (レガシー、可能であれば AES を使用)
**サポートされているその他のアルゴリズム**
+ IDEA、CAST5、Blowfish、DES、 TwoFish、CAMELLIA-128, CAMELLIA-192, CAMELLIA-256
**注記**
ワークフローを使用する AWS Transfer Family ときは、対称アルゴリズムを直接選択しません。これは、暗号化されたファイルの作成に使用される PGP ソフトウェアによって決まります。ただし、AES-256 などの FIPS 準拠のアルゴリズムを優先するように PGP ソフトウェアを設定できます。
サポートされている対称アルゴリズムの詳細については、「」を参照してください[サポートされている対称暗号化アルゴリズム](nominal-steps-workflow.md#symmetric-algorithms)。
# サービス管理ユーザーの SSH キーの生成
サーバーをセットアップする際、サービスで管理された認証方法でユーザーを認証するよう設定できます。この方法では、ユーザー名と SSH キーは、サービスに保存されます。ユーザーのパブリック SSH キーは、ユーザーのプロパティとしてサーバーにアップロードされます。このキーは、キーベースの標準認証プロセスの一部としてサーバーによって使用されます。各ユーザーに対し、個々のサーバーに複数のパブリック SSH キーを登録できます。ユーザ 1 人あたりに保存できるキー数の制限については、「Amazon Web Services 全般のリファレンス」の「[AWS Transfer Family エンドポイントとクォータ](https://docs.aws.amazon.com//general/latest/gr/transfer-service.html)」を参照してください。
サービスマネージド認証方法の代わりに、カスタム ID プロバイダー、または を使用してユーザーを認証できます AWS Directory Service for Microsoft Active Directory。詳細については、[カスタム ID プロバイダーの使用](custom-idp-intro.md)または[AWS Directory Service for Microsoft Active Directory の使用](directory-services-users.md)を参照してください。
サーバーがユーザー認証に使用できる方法は 1 つのみ (サービスマネージドまたはカスタム ID プロバイダー) であり、サーバーの作成後にそのメソッドを変更することはできません。
**Topics**
+ [macOS、Linux、または UNIX で SSH キーを作成する](macOS-linux-unix-ssh.md)
+ [Microsoft Windows での SSH キーの作成](windows-ssh.md)
+ [SSH2 キーを SSH パブリックキー形式に変換する](convert-ssh2-public-key.md)
# macOS、Linux、または UNIX で SSH キーを作成する
macOS、Linux、または UNIX のオペレーティングシステムでは、`ssh-keygen` コマンドを使用して、キーペトと呼ばれる SSH パブリックキーと SSH プライベートキーを作成します。
**注記**
以下の例では、パスフレーズは指定していません。この場合、ツールはパスフレーズの入力を要求し、確認のためもう一度入力するように求めます。パスフレーズを作成すると、秘密鍵の保護が強化され、システム全体のセキュリティも向上する可能性があります。パスフレーズは復元できません。忘れた場合は、新しいキーを作成する必要があります。
ただし、サーバーホスト鍵を生成する場合、Transfer Family サーバーは起動時にパスワードを要求できないため、コマンドで `-N ""` オプションを指定する（またはプロンプトが表示されたら **Enter** を 2 回押す）ことで、空のパスフレーズを「必ず」指定する必要があります。
**macOS、Linux、または UNIX のオペレーティングシステムで SSH キーを作成するには**
1. macOS、Linux、または UNIX でコマンドターミナルを開きます。
1. AWS Transfer Family は、RSA、ECDSA、および ED25519-formattedキーを受け入れます。生成するキーペアのタイプに基づいて適切なコマンドを選択してください。
**ヒント**: を SSH キーペアファイルの実際の名前`key_name`に置き換えます。
+ 4096 ビット RSA キーペアを生成する
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ ECDSA 521 ビットのキーペア (ECDSA のビットサイズは 256、384、521) を生成するには:
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ ED25519 キーペアを生成するには：
```
ssh-keygen -t ed25519 -f key_name
```
`ssh-keygen` 出力の例を以下に示します。
```
ssh-keygen -t rsa -b 4096 -f key_name
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in key_name.
Your public key has been saved in key_name.pub.
The key fingerprint is:
SHA256:8tDDwPmanTFcEzjTwPGETVWOGW1nVz+gtCCE8hL7PrQ bob.amazon.com
The key's randomart image is:
+---[RSA 4096]----+
| . ....E |
| . = ... |
|. . . = ..o |
| . o + oo = |
| + = .S.= * |
| . o o ..B + o |
| .o.+.* . |
| =o*+*. |
| ..*o*+. |
+----[SHA256]-----+
```
**ヒント**: 前述のように `ssh-keygen` コマンドを実行すると、パブリックキーとプライベートキーが現在のディレクトリにファイルとして作成されます。
これで、SSH キーペアを使用する準備ができました。ステップ 3 と 4 に従って、サービスマネージドユーザーの SSH パブリックキーを保存します。これらのユーザーは、Transfer Family サーバーエンドポイントでファイルを転送するときにキーを使用します。
1. `key_name.pub`.ファイルを見つけて開きます。
1. テキストをコピーして、サービス管理対象ユーザーの「**SSH 公開鍵**」に貼り付けます。
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開き、ナビゲーションペインから**サーバー**を選択します。
1. **[サーバー]** ページで、更新するユーザーを含むサーバーの **[サーバー ID]** を選択します。
1. パブリックキーを追加するユーザーを選択します。
1. **[SSH 公開鍵]** ペインで、**[SSH 公開鍵を追加]** を選択します。
![\[選択したユーザーのユーザーの詳細を示す AWS Transfer Family コンソール。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-user-add-key-01.png)
1. 生成した公開鍵のテキストを SSH 公開鍵テキストボックスに貼り付け、**[鍵の追加]** を選択します。
![\[AWS Transfer Family コンソールには、パブリックキーを追加するためのキーの追加ページが表示されます。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-user-add-key-02.png)
新しい鍵は SSH 公開鍵ペインに一覧表示されます。
![\[SSH パブリックキーセクションに新しく追加されたパブリックキーを示す AWS Transfer Family コンソール。\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/edit-user-add-key-03.png)
# Microsoft Windows での SSH キーの作成
Windows には OpenSSH が組み込み機能として含まれており、これを使用して Linux または macOS と同じ形式で SSH キーを生成できます。または、PuTTY のキージェネレーター (PuTTYgen) などのサードパーティー製ツールを使用することもできます。
## Windows 組み込み OpenSSH の使用
Windows の最新バージョンには、デフォルトで OpenSSH が含まれています。macOS/Linux セクションで説明されているのと同じ`ssh-keygen`コマンドを使用できます。
1. Windows PowerShell または コマンドプロンプトを開きます。
1. 生成するキーのタイプに基づいて、次のいずれかのコマンドを実行します。
+ 4096 ビット RSA キーペアを生成する
```
ssh-keygen -t rsa -b 4096 -f key_name
```
+ ECDSA 521 ビットキーペアを生成するには:
```
ssh-keygen -t ecdsa -b 521 -f key_name
```
+ ED25519 キーペアを生成するには：
```
ssh-keygen -t ed25519 -f key_name
```
1. macOS/Linux セクションと同じ手順に従って、パブリックキーを にアップロードします AWS Transfer Family。
## PuTTYgen の使用 (サードパーティー製ツール)
PuTTY など、Windows 用の一部のサードパーティー SSH クライアントは、異なるキー形式を使用します。PuTTY はプライベートキーに `PPK`形式を使用します。PuTTY または WinSCP などの関連ツールを使用している場合は、PuTTYgen を使用してこの形式でキーを作成できます。
**注記**
`.ppk` 形式でないプライベート・キー・ファイルを WinSCP に提示すると、WinSCP クライアントはキーを `.ppk` 形式に変換します。
PuTTYgen を使用した SSH キーの作成に関するチュートリアルについては、[SSH.com ウェブサイト](https://www.ssh.com/ssh/putty/windows/puttygen)を参照してください。
# SSH2 キーを SSH パブリックキー形式に変換する
AWS Transfer Family は SSH 形式のパブリックキーのみを受け入れます。SSH2 公開鍵がある場合は、それを変換する必要があります。SSH2 公開鍵は以下の形式になります。
```
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20160402"
AAAAB3NzaC1yc2EAAAABJQAAAgEAiL0jjDdFqK/kYThqKt7THrjABTPWvXmB3URI
:
:
---- END SSH2 PUBLIC KEY ----
```
SSH パブリックキーの形式は次のとおりです。
```
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAA...
```
次のコマンドを実行して、SSH2-formattedパブリックキーを SSH 形式のパブリックキーに変換します。*ssh2-key* を SSH2 キーの名前に置き換え、*ssh-key* を SSH キーの名前に置き換えます。
```
ssh-keygen -i -f ssh2-key.pub > ssh-key.pub
```
# SSH キーのローテーション
セキュリティ上、ベストプラクティスとして SSH キーのローテーションをお勧めします。通常、このローテーションは、セキュリティポリシーの一部として指定され、自動化した形で実装されます。セキュリティのレベルに応じて、機密性の高い通信では、SSH キーペアが 1 回しか使用されない場合もあります。これにより、キーを保存することのリスクがなくなります。ただし一般的には、SSH 認証情報を一定期間にわたって保存し、その期間をユーザーに過度の負荷がかからないような長さに設定するのが普通です。標準的な設定は 3 か月です。
**注記**
Infrastructure as Code を使用した自動 SSH キーローテーションについては、「」を参照してください[Transfer Family Terraform モジュール](terraform.md)。
SSH キーのローテーションを実行するには、2 つの方法があります。
+ コンソールで新しい SSH パブリックキーをアップロードすると既存の SSH 公開キーを削除できます。
+ [DeleteSSHPublic](https://docs.aws.amazon.com//transfer/latest/APIReference/API_DeleteSshPublicKey.html) API を使用してユーザーの Secure Shell (SSH) パブリックキーを削除でき、[ImportSshPublicKey](https://docs.aws.amazon.com/transfer/latest/APIReference/API_ImportSshPublicKey.html) API を使用してユーザーのアカウントに新しいセキュアシェル (SSH) パブリックキー公開キーを追加すれば、API で既存のユーザーを更新できます。
------
#### [ Console ]
**コンソールでキーローテーションを実行するには**
1. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/) で AWS Transfer Family コンソールを開きます。
1. [**Servers**] (サーバー) ページに移動します。
1. [**Server ID**] (サーバー ID) 列で ID を選択すると、[**Server Configuration**] (サーバーの構成) ページが表示されます。
1. [**Users**] (ユーザー) の下で、SSH パブリックキーをローテーションするユーザーのチェックボックスをオンにし、[**Actions**] (アクション) を選択してから [**Add key**] (キーの追加) を選択すると [**Add key**] (キーの追加) ページが表示されます。
または
ユーザー名を選択して**ユーザーの詳細**ページを表示し、**SSHパブリックキーの追加**を選択して**キーの追加**ページを表示する。
1. 新しい SSH パブリックキーを入力し、[**Add key**] (キーを追加する) を選択します。
**重要**
SSH 公開鍵の形式は、生成した鍵のタイプによって異なります。
RSA キーの場合、形式は `ssh-rsa string` です。
ED25519 キーの場合、形式は `ssh-ed25519 string` です。
ECDSA キーの場合、生成したキーのサイズに応じてキーは`ecdsa-sha2-nistp256`、`ecdsa-sha2-nistp384`、または `ecdsa-sha2-nistp521` で始まります。他のキータイプと同様に、最初の文字列の後には `string` が続きます。
[**User details**] (ユーザーの詳細) ページに戻ると、先ほど入力した SSH パブリックキーが [**SSH public key**] (SSH パブリックキー) セクションに表示されます。
1. 削除したい古いキーのチェックボックスをオンにしてから [**Delete**] (削除) を選択します。
1. `delete` という語を入力して削除オペレーションを確認してから [**Delete**] (削除) を選択します。
------
#### [ API ]
**API を使用してキーローテーションを実行するには**
1. macOS、Linux、または UNIX でコマンドターミナルを開きます。
1. 次のコマンドを入力することで、削除したい SSH キーを取得します。このコマンドを使用するには、`serverID` を Transfer Family サーバーのサーバー ID に、`username` をユーザー名に置き換えます。
```
aws transfer describe-user --server-id='serverID' --user-name='username'
```
このコマンドは、ユーザーについての詳細を返します。`"SshPublicKeyId":` フィールドの内容をコピーします。この手順の後半で、この値を入力する必要があります。
```
"SshPublicKeys": [ { "SshPublicKeyBody": "public-key", "SshPublicKeyId": "keyID",
"DateImported": 1621969331.072 } ],
```
1. 次に、ユーザー用の新しい SSH キーをインポートします。 プロンプトで次のコマンドを入力します。このコマンドを使用するには、`serverID` を Transfer Family サーバーのサーバー ID に、`username` をユーザー名に、`public-key` を新しい公開鍵のフィンガープリントに置き換えます。
```
aws transfer import-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-body='public-key'
```
``コマンドが成功した場合、出力は返りません。
1. 最後に、次のコマンドを実行して、古いキーを削除します。このコマンドを使用するには、`serverID` を Transfer Family サーバーのサーバー ID に、`username` をユーザー名に、`keyID-from-step-2` をこの手順のステップ 2 でコピーしたキー ID 値に置き換えます。
```
aws transfer delete-ssh-public-key --server-id='serverID' --user-name='username'
--ssh-public-key-id='keyID-from-step-2'
```
1. (オプション) 古いキーがもう存在しないことを確認するには、ステップ 2 を繰り返します。
------
# PGP キーを生成する
Transfer Family がワークフローで処理するファイルで、Pretty Good Privacy (PGP) 復号化を使用できます。ワークフローステップで復号を使用するには、PGP キーを指定します。レコメンデーションや FIPS コンプライアンスなど、PGP キーアルゴリズムの詳細については、「」を参照してください[PGP キーペアアルゴリズム](key-management.md#pgp-key-algorithms)。
AWS ストレージブログには、Transfer Family Managed ワークフローを使用してコードを記述せずにファイルを単純に復号する方法、[PGP と を使用してファイルを暗号化および復号する方法 AWS Transfer Family](https://aws.amazon.com/blogs/storage/encrypt-and-decrypt-files-with-pgp-and-aws-transfer-family/)を説明する投稿があります。
PGP キーの生成に使用する演算子は、オペレーティングシステムと使用しているキー生成ソフトウェアのバージョンによって異なります。
Linux または Unix を使用している場合は、パッケージインストーラーを使用して `gpg` をインストールします。お使いの Linux ディストリビューションに応じて、以下のコマンドのいずれかが動作するはずです。
```
sudo yum install gnupg
```
```
sudo apt-get install gnupg
```
Windows または macOS の場合は、「[https://gnupg.org/download/](https://gnupg.org/download/)」から必要なものをダウンロードできます。
PGP キージェネレータソフトウェアをインストールしたら、「`gpg --full-gen-key`」または「`gpg --gen-key`」コマンドを実行してキーペアを生成します。
**注記**
`GnuPG` バージョン 2.3.0 以降を使用している場合は、`gpg --full-gen-key` を実行する必要があります。作成する鍵の種類を求められたら、RSA または ECC を選択します。**ECC** を選択した場合は、楕円曲線Curve25519の NISTBrainPoolと から選択できます。
**役立つ`gpg` サブコマンド**
以下は `gpg` に役立つサブコマンドです。
+ `gpg --help` — このコマンドには、使用可能なオプションが一覧表示され、例もいくつか含まれている場合があります。
+ `gpg --list-keys` – このコマンドは、作成したすべてのキーペアの詳細を一覧表示します。
+ `gpg --fingerprint` – このコマンドは、各キーのフィンガープリントを含む、すべてのキーペアの詳細を一覧表示します。
+ `gpg --export -a user-name` — このコマンドは、`user-name`キーの生成時に使用されたキーの公開キー部分をエクスポートします。
# キーペアを管理する
PGP キーを管理するには、 を使用します AWS Secrets Manager。
**注記**
シークレットネームには、Transfer FamilyのサーバーIDが含まれます。つまり、PGP キー情報を AWS Secrets Manager保存する「前」に、サーバーを特定または作成しておく必要があります。
1つのキーとパスフレーズをすべてのユーザーに使いたい場合は、PGP キーブロック情報を秘密名 `aws/transfer/server-id/@pgp-default`（`server-id` は Transfer Family サーバーの ID）の下に保存することができます。Transfer Family は、 がワークフローを実行しているユーザー`user-name`と一致するキーがない場合、このデフォルトキーを使用します。
特定のユーザーのキーを作成できます。この場合、シークレット名の形式は です。 は`aws/transfer/server-id/user-name`、Transfer Family サーバーのワークフローを実行しているユーザー`user-name`と一致します。
**注記**
Transfer Family サーバー 1 台につき、1 ユーザーにつき最大 3 つの PGP 秘密鍵を保存できます。
**PGP 鍵を復号化に使用するように設定するには**
1. 使用している GPG のバージョンに応じて、次のいずれかのコマンドを実行して PGP キーペアを生成します。
+ **GnuPG** バージョン 2.3.0 以降を使用している場合は、次のコマンドを実行します。
```
gpg --full-gen-key
```
を選択する**RSA**か、 を選択する場合は**NIST**、楕円曲線**Curve25519**に **BrainPool**または **ECC**を選択できます。`gpg --gen-key` 代わりに を実行する場合は、ECC Curve 25519 暗号化アルゴリズムを使用するキーペアを作成します。
+ バージョン 2.3.0 より前の **GnuPG** では、RSA がデフォルトの暗号化タイプであるため、次のコマンドを使用できます。
```
gpg --gen-key
```
**重要**
キー生成プロセス中に、パスフレーズと E メールアドレスを指定する必要があります。これらの値は必ず書き留めておいてください。この手順の AWS Secrets Manager 後半でキーの詳細を に入力するときに、パスフレーズを指定する必要があります。また、次のステップでプライベートキーをエクスポートする場合も、同じメールアドレスを指定する必要があります。
1. 以下のコマンドを実行してプライベートキーをエクスポートします。このコマンドを使うには、`private.pgp` を秘密鍵ブロックを保存するファイル名に、`marymajor@example.com` をキーペアを生成したときに使った電子メールアドレスに置き換えます。
```
gpg --output private.pgp --armor --export-secret-key marymajor@example.com
```
1. AWS Secrets Manager を使用して PGP キーを保存します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/) で AWS Secrets Manager コンソールを開きます。
1. 左側のナビゲーションペインで **[サーバー]** を選択します。
1. [**シークレット**]ページで、[**新しいシークレットの保存**]を選択します。
1. [**シークレットタイプの選択**] ページの[**シークレットタイプ**] で[**その他のシークレットタイプ**] を選択します。
1. **[キー/値のペア]** セクションで、**[キー/値]** タブを選択します。
+ **キー** — **PGPPrivateKey**と入力します。
**注記**
**PGPPrivateKey** 文字列は正確に入力する必要があります。文字の前や間にスペースを入れないでください。
+ 「**値**」 — 秘密鍵のテキストを値フィールドに貼り付けます。プライベートキーのテキストは、この手順の前半でキーをエクスポートしたときに指定したファイル (`private.pgp` など) にあります。キーは `-----BEGIN PGP PRIVATE KEY BLOCK-----` で始まり、`-----END PGP PRIVATE KEY BLOCK-----` で終わります。
**注記**
テキストブロックには秘密鍵のみが含まれ、公開鍵も含まれていないことを確認してください。
1. **[行を追加]** を選択し、**[キー/値のペア]** セクションで **[キー/値]** タブを選択します。
+ **キー** — **PGPPassphrase**と入力します。
**注記**
**PGPPassphrase** 文字列は正確に入力する必要があります。文字の前や間にスペースを入れないでください。
+ 「**値**」 — PGP キーペアを生成したときに使用したパスフレーズを入力します。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/pgp-secrets-01.png)
**注記**
最大 3 セットのキーとパスフレーズを追加できます。2 つ目のセットを追加するには、2 つの新しい行を追加し、キーには **PGPPrivateKey2** と **PGPPassphrase2** を入力し、別のプライベートキーとパスフレーズを貼り付けます。3 番目のセットを追加するには、キー値は **PGPPrivateKey3** と **PGPPassphrase3** でなければなりません。
1. [**次へ**] を選択します。
1. **[シークレットの設定]** ページで、シークレットの名前と説明を入力します。
+ デフォルトキー、つまり Transfer Family のすべてのユーザーが使用できるキーを作成する場合は、**aws/transfer/*server-id*/@pgp-default** と入力します。`server-id`を、復号ステップを持つワークフローを含むサーバーの ID に置き換えます。
+ 特定の Transfer Family ユーザーが使用するキーを作成する場合は、**aws/transfer/*server-id*/*user-name*** と入力します。`server-id` を復号ステップを持つワークフローを含むサーバーの ID に置き換え、`user-name` をワークフローを実行しているユーザー名に置き換えます。`user-name` は、Transfer Family サーバーが使用している ID プロバイダーに保存されます。
1. **[次へ]** を選択し、**[ローテーションの設定]** ページのデフォルトを受け入れます。次いで、**[次へ]** を選択します。
1. **[レビュー]** ページで **[ストア]** を選択し、シークレットを作成して保存します。
次のスクリーンショットは、特定の Transfer Family サーバのユーザ **marymajor** の詳細を示している。この例では、3 つのキーとそれに対応するパスフレーズが表示されています。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/pgp-secrets-02.png)
# サポートされている PGP クライアント
以下のクライアントはTTransfer Family ilyでテストされており、PGPキーの生成や、ワークフローで復号化するファイルの暗号化に使用できます。
+ **GPG4Win \$1 クレオパトラ。**
**注記**
**[ファイルの署名/暗号化]** を選択した場合は、**[名前をつけて署名]** の選択が解除されていることを確認してください。現在、暗号化されたファイルへの署名はサポートされていません。
![\[\]](http://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/images/workflows-step-decrypt-kleopatra.png)
暗号化されたファイルに署名し、復号ワークフローを使用して Transfer Family サーバーにアップロードしようとすると、次のエラーが表示されます。
```
Encrypted file with signed message unsupported
```
+ 「**GnuPG**」の主要なバージョン:2.4、2.3、2.2、2.0 および 1.4。
他のPGPクライアントも同様に動作する可能性がありますが、TTransfer Family ilyでテストされたのはここに記載されているクライアントのみであることに注意してください。
# の ID とアクセスの管理 AWS Transfer Family
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインイン) し、誰に AWS Transfer Family リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [AWS Transfer Family が IAM と連携する方法](security_iam_service-with-iam.md)
+ [AWS Transfer Family アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [AWS Transfer Family タグベースのポリシーの例](security_iam_tag-based-policy-examples.md)
+ [AWS Transfer Family ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ [組織ガバナンスの IAM 条件キー](transfer-condition-keys.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS Transfer Family ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[AWS Transfer Family が IAM と連携する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[AWS Transfer Family アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウントのルートユーザー
を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間のユーザーに要求する AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。ユーザー[から IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときに、これらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、および Amazon VPC は AWS WAF、ACLs。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# AWS Transfer Family が IAM と連携する方法
AWS Identity and Access Management (IAM) を使用して へのアクセスを管理する前に AWS Transfer Family、使用できる IAM 機能を理解しておく必要があります AWS Transfer Family。 AWS Transfer Family およびその他の AWS のサービスが IAM と連携する方法の概要については、「IAM *ユーザーガイド*」の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [AWS Transfer Family ID ベースのポリシー](#security_iam_service-with-iam-id-based-policies)
+ [AWS Transfer Family リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [AWS Transfer Family タグに基づく認可](#security_iam_service-with-iam-tags)
+ [AWS Transfer Family IAM ロール](#security_iam_service-with-iam-roles)
## AWS Transfer Family ID ベースのポリシー
IAM アイデンティティベースのポリシーでは、許可または拒否されたアクションとリソースを指定でき、さらにアクションが許可または拒否された条件を指定できます。 AWS Transfer Family は、特定のアクション、リソース、および条件キーをサポートします。JSON ポリシーで使用するすべての要素については、*AWS Identity and Access Management ユーザーガイド* の「[IAM JSON ポリシーエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### アクション
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
のポリシーアクションは、アクションの前にプレフィックス AWS Transfer Family を使用します`transfer:`。たとえば、Transfer Family `CreateServer` API オペレーションを使用してサーバーを作成するアクセス許可を付与するには、ポリシーに `transfer:CreateServer` アクションを含めます。ポリシーステートメントには、`Action` 要素または `NotAction` 要素のいずれかを含める必要があります。 AWS Transfer Family は、このサービスで実行できるタスクを説明する独自の一連のアクションを定義します。
単一のステートメントに複数の アクションを指定するには、次のようにコンマで区切ります。
```
"Action": [
"transfer:action1",
"transfer:action2"
```
ワイルドカード \$1を使用して複数のアクションを指定することができます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "transfer:Describe*"
```
AWS Transfer Family アクションのリストを確認するには、*「サービス認可リファレンス*」の[「 で定義されるアクション AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-actions-as-permissions)」を参照してください。
### リソース
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Transfer Family サーバーリソースには、次の ARN があります。
```
arn:aws:transfer:${Region}:${Account}:server/${ServerId}
```
たとえば、ステートメントで `s-01234567890abcdef` Transfer Family サーバーを指定するには、次の ARN を使用します。
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/s-01234567890abcdef"
```
ARN の形式の詳細については、[「サービス認可リファレンスARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」、または「IAM **[ユーザーガイド」の「IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns)」を参照してください。 **
特定のアカウントに属するすべてのインスタンスを指定するには、ワイルドカード \$1を使用します。
```
"Resource": "arn:aws:transfer:us-east-1:123456789012:server/*"
```
一部の AWS Transfer Family アクションは、IAM ポリシーで使用されるものなど、複数のリソースで実行されます。このような場合はワイルドカード \$1を使用する必要があります。
```
"Resource": "arn:aws:transfer:*:123456789012:server/*"
```
場合によっては、複数のタイプのリソースを指定する必要があります。たとえば、Transfer Family サーバーとユーザーへのアクセスを許可するポリシーを作成する場合などです。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": [
"resource1",
"resource2"
]
```
AWS Transfer Family リソースのリストを確認するには、*「サービス認可リファレンス*」の「 [で定義されるリソースタイプ AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-resources-for-iam-policies)」を参照してください。
### 条件キー
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
AWS Transfer Family は独自の条件キーのセットを定義し、いくつかのグローバル条件キーの使用もサポートしています。 AWS Transfer Family 条件キーのリストを確認するには、*「サービス認可リファレンス*」の「 [の条件キー AWS Transfer Family](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html#awstransferfamily-policy-keys)」を参照してください。
### 例
AWS Transfer Family アイデンティティベースのポリシーの例を表示するには、「」を参照してください[AWS Transfer Family アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)。VPC エンドポイント固有の IAM ポリシーについては、「」を参照してください[Transfer Family サーバーの VPC エンドポイントアクセスの制限](create-server-in-vpc.md#limit-vpc-endpoint-access)。
## AWS Transfer Family リソースベースのポリシー
リソースベースのポリシーは、指定されたプリンシパルが AWS Transfer Family リソースに対して実行できるアクションと条件を指定する JSON ポリシードキュメントです。Amazon S3 は、Amazon S3 *バケット*に関するリソースベースのアクセス許可ポリシーをサポートします。リソースベースのポリシーでは、リソースごとに他の アカウントに使用許可を付与することができます。リソースベースのポリシーを使用して、 AWS サービスが Amazon S3 *バケット*にアクセスすることを許可することもできます。
クロスアカウントアクセスを有効にするには、アカウント全体、または別のアカウントの IAM エンティティを[リソースベースのポリシーのプリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)として指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウントにある場合は、プリンシパルエンティティにリソースへのアクセス許可も付与する必要があります。アクセス許可は、アイデンティティベースのポリシーをエンティティにアタッチすることで付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、ID ベースのポリシーをさらに付与する必要はありません。詳細については、*AWS Identity and Access Management ユーザーガイド*の「[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」を参照してください。
Amazon S3 サービスは、**バケット*ポリシー*と呼ばれるリソースベースのポリシーの 1 つのタイプのみサポートし、それが*バケット*にアタッチされます。このポリシーは、どのプリンシパルエンティティ（アカウント、ユーザー、ロール、および連携ユーザー）がオブジェクトに対してアクションを実行できるかを定義します。
### 例
AWS Transfer Family リソースベースのポリシーの例を表示するには、「」を参照してください[AWS Transfer Family タグベースのポリシーの例](security_iam_tag-based-policy-examples.md)。
## AWS Transfer Family タグに基づく認可
AWS Transfer Family リソースにタグをアタッチしたり、リクエストでタグを渡すことができます AWS Transfer Family。タグに基づいてアクセスを管理するには、`transfer:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。タグを使用して AWS Transfer Family リソースへのアクセスを制御する方法については、「」を参照してください[AWS Transfer Family タグベースのポリシーの例](security_iam_tag-based-policy-examples.md)。
## AWS Transfer Family IAM ロール
[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、特定のアクセス許可を持つ AWS アカウント内のエンティティです。
### での一時的な認証情報の使用 AWS Transfer Family
一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには、[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) や [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS STS API オペレーションを呼び出します。
AWS Transfer Family では、一時的な認証情報の使用がサポートされています。
# AWS Transfer Family アイデンティティベースのポリシーの例
デフォルトでは、IAM ユーザーおよびロールには、 AWS Transfer Family リソースを作成または変更するアクセス許可はありません。また、 AWS マネジメントコンソール、 AWS CLI、または AWS API を使用してタスクを実行することはできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。
これらの JSON ポリシードキュメント例を使用して IAM の ID ベースのポリシーを作成する方法については、*AWS Identity and Access Management ユーザーガイド*の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [AWS Transfer Family コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [ユーザーが自分の許可を表示できるようにする](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、誰かがアカウント内の AWS Transfer Family リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## AWS Transfer Family コンソールの使用
AWS Transfer Family コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 AWS アカウント内の AWS Transfer Family リソースの詳細を一覧表示および表示できます。最小限必要な許可よりも厳しく制限されたアイデンティティベースポリシーを作成すると、そのポリシーを添付したエンティティ (IAM ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。詳細については、*AWS Identity and Access Management ユーザーガイド*の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
## ユーザーが自分の許可を表示できるようにする
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS Transfer Family タグベースのポリシーの例
以下は、タグに基づいて AWS Transfer Family リソースへのアクセスを制御する方法の例です。
## タグを使用して AWS Transfer Family リソースへのアクセスを制御する
IAM ポリシーの条件は、 AWS Transfer Family リソースへのアクセス許可を指定するために使用する構文の一部です。 AWS Transfer Family リソース (ユーザー、サーバー、ロール、その他のエンティティなど) へのアクセスは、それらのリソースのタグに基づいて制御できます。タグはキーと値のペアです。リソースのタグ付けの詳細については、の[AWS 「リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)」を参照してください*AWS 全般のリファレンス*。
では AWS Transfer Family、リソースにタグを付けることができ、一部のアクションにタグを含めることができます。IAM ポリシーを作成するときに、タグ条件キーを使用して以下をコントロールできます。
+ AWS Transfer Family リソースのタグに基づいて、 リソースに対してアクションを実行できるユーザー。
+ アクションのリクエストで渡すことができるタグ。
+ リクエストで特定のタグキーを使用できるかどうか。
タグベースのアクセス制御を使用すると、API レベルよりも細かい制御を適用できます。また、リソースベースのアクセス制御を使用するよりも動的な制御を適用できます。リクエストで指定したタグ (リクエストタグ) に基づいて、オペレーションを許可または拒否する IAM ポリシーを作成できます。また、操作しようとするリソースのタグ (リソースタグ) に基づいて IAM ポリシーを作成することもできます。一般に、リソースタグはリソースに既に存在するタグ用であり、リクエストタグはリソースにタグを追加したり、リソースからタグを削除したりするときに使用します。
タグ条件キーの完全な構文とセマンティクスについては、*IAM ユーザーガイド*の「[リソースタグを使用した AWS リソースへのアクセスコントロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。API Gateway を使用した IAM ポリシーの指定の詳細については、*API Gateway デベロッパーガイド*の「[IAM アクセス許可により API へのアクセスを制御する](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html)」を参照してください。
### 例 1: リソースタグに基づいてアクションを拒否する
タグに基づいてリソースについて実行されるアクションを拒否できます。次の例では、ユーザーまたはサーバーのリソースがキー `stage` と値 `prod` でタグ付けされている場合にポリシーで `TagResource`、`UntagResource`、`StartServer`、`StopServer`、`DescribeServer`、および `DescribeUser` のオペレーションが拒否されます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"transfer:TagResource",
"transfer:UntagResource",
"transfer:StartServer",
"transfer:StopServer",
"transfer:DescribeServer",
"transfer:DescribeUser"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/stage": "prod"
}
}
}
]
}
```
### 例 2: リソースタグに基づいてアクションを許可する
タグに基づいてリソースに対するアクションの実行を許可できます。次の例では、ユーザーまたはサーバーのリソースがキー `TagResource` と値 `UntagResource` でタグ付けされている場合にポリシーで `StartServer`、`StopServer`、`DescribeServer`、`DescribeUser`、`stage`、および `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"
}
}
}
]
}
```
### 例 3: リクエストタグに基づくユーザーまたはサーバーの作成を拒否する
次のポリシー例には、2 つのステートメントが含まれています。1 つ目のステートメントでは、タグのコストセンターキーに値がない場合、すべてのリソースに対する `CreateServer` オペレーションが拒否されます。
2 つ目のステートメントは、タグのコストセンターキーに 1、2、または 3 以外の値が含まれている場合に `CreateServer` オペレーションが拒否されます。
**注記**
このポリシーでは、`costcenter` というキーと `1`、`2`、または`3` の値を含むリソースを作成または削除できます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"transfer:CreateServer"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/costcenter": "true"
}
}
},
{
"Effect": "Deny",
"Action": "transfer:CreateServer",
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringNotEquals": {
"aws:RequestTag/costcenter": [
"1",
"2",
"3"
]
}
}
}
]
}
```
# AWS Transfer Family ID とアクセスのトラブルシューティング
次の情報は、 および IAM の使用時に発生する可能性がある一般的な問題の診断 AWS Transfer Family と修正に役立ちます。
**Topics**
+ [でアクションを実行する権限がありません AWS Transfer Family](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がない](#security_iam_troubleshoot-passrole)
+ [自分の AWS アカウント以外のユーザーに自分の AWS Transfer Family リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## でアクションを実行する権限がありません AWS Transfer Family
にアクションを実行する権限がないと AWS マネジメントコンソール 通知された場合は、管理者に連絡してサポートを依頼する必要があります。管理者とは、サインイン認証情報を提供した担当者です。
以下の例のエラーは、`mateojackson` IAM ユーザーがコンソールを使用して [*ウィジェット*] の詳細を表示する際に、`transfer:GetWidget` 許可がない場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: transfer:GetWidget on resource: my-example-widget
```
この場合、Mateo は、`transfer;:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスが許可されるように、管理者にポリシーの更新を依頼します。
## iam:PassRole を実行する権限がない
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して AWS Transfer Familyにロールを渡すことができるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡す権限が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して AWS Transfer Familyでアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された権限が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
以下のサンプルポリシーには、ロールを AWS Transfer Familyに渡す権限が含まれています。を AWS アカウント ID **123456789012**に、 を実際の IAM ロール名**MyTransferRole**に置き換えます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{ "Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/MyTransferRole",
"Effect": "Allow"
}
]
}
```
## 自分の AWS アカウント以外のユーザーに自分の AWS Transfer Family リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ がこれらの機能 AWS Transfer Family をサポートしているかどうかを確認するには、「」を参照してください[AWS Transfer Family が IAM と連携する方法](security_iam_service-with-iam.md)。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、IAM *ユーザーガイド*の[「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
# 組織ガバナンスの IAM 条件キー
AWS Transfer Family には、任意の IAM ポリシーでリソース設定を制限できる IAM 条件キーが用意されています。これらの条件キーは、ユーザーまたはロールにアタッチされたアイデンティティベースのポリシー、または組織ガバナンスのためのサービスコントロールポリシー (SCPsで使用できます。
サービスコントロールポリシーは、 AWS 組織全体に適用される IAM ポリシーであり、複数のアカウントにわたって予防的ガードレールを提供します。SCPs で使用すると、これらの条件キーは組織全体でセキュリティ要件とコンプライアンス要件を適用するのに役立ちます。
**以下の資料も参照してください。**
+ [Transfer Family のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html)
+ [サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
+ サービスコントロールポリシーを使用して予防ガードレールを適用する方法を説明する動画
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/mEO05mmbSms)
## 使用可能な条件キー
AWS Transfer Family では、IAM ポリシーで使用できる以下の条件キーがサポートされています。
`transfer:RequestServerEndpointType`
エンドポイントタイプ (PUBLIC、VPC、VPC\$1ENDPOINT) に基づいてサーバーの作成と更新を制限します。一般に、パブリック向けエンドポイントの防止に使用されます。
`transfer:RequestServerProtocols`
サポートされているプロトコル (SFTP、FTPS、FTP、AS2) に基づいてサーバーの作成と更新を制限します。
`transfer:RequestServerDomain`
ドメインタイプ (S3、EFS) に基づいてサーバーの作成を制限します。
`transfer:RequestConnectorProtocol`
プロトコル (AS2、SFTP) に基づいてコネクタの作成を制限します。
## サポートされているアクション
条件キーは、次の AWS Transfer Family アクションに適用できます。
+ `CreateServer`: `RequestServerEndpointType`、`RequestServerProtocols`、および `RequestServerDomain`条件キーをサポート
+ `UpdateServer`: `RequestServerEndpointType`および `RequestServerProtocols`条件キーをサポート
+ `CreateConnector`: `RequestConnectorProtocol`条件キーをサポート
## SCP ポリシーの例
次の SCP の例では、組織全体でのパブリック AWS Transfer Family サーバーの作成を防止します。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyPublicTransferServers",
"Effect": "Deny",
"Action": ["transfer:CreateServer", "transfer:UpdateServer"],
"Resource": "*",
"Condition": {
"StringEquals": {
"transfer:RequestServerEndpointType": "PUBLIC"
}
}
}]
}
```
# のコンプライアンス検証 AWS Transfer Family
サードパーティーの監査者は、複数の コンプライアンスプログラムの一環として AWS Transfer Family のセキュリティと AWS コンプライアンスを評価します。このプログラムには、SOC、PCI、HIPAA などを含みます。詳細なリストについては、[AWS 「コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope)」を参照してください。
特定のコンプライアンスプログラムの対象となる AWS サービスのリストについては、[AWS コンプライアンスプログラムの対象となるサービス](https://aws.amazon.com/compliance/services-in-scope/)を参照してください。一般的な情報については、「[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「 でレポートをダウンロードする AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS Transfer Family は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。 AWS では、コンプライアンスに役立つ以下のリソースを提供しています。
+ [セキュリティとコンプライアンスのクイックスタートガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境をデプロイする手順について説明します AWS。
+ [HIPAA セキュリティとコンプライアンスのための設計ホワイトペーパー ](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/introduction.html) – このホワイトペーパーでは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法について説明します。
+ [AWS コンプライアンスのリソース](https://aws.amazon.com/compliance/resources/) – このワークブックとガイドのコレクションは、お客様の業界や場所に適用される場合があります。
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – この AWS サービスは、リソース設定が内部プラクティス、業界ガイドライン、および規制にどの程度準拠しているかを評価します。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS サービスは、 内のセキュリティ状態を包括的に把握 AWS し、セキュリティ業界標準とベストプラクティスへの準拠を確認するのに役立ちます。
# の耐障害性 AWS Transfer Family
AWS グローバルインフラストラクチャは、 AWS リージョンとアベイラビリティーゾーンを中心に構築されています。 AWS リージョンは、低レイテンシー、高スループット、および高度に冗長なネットワークで接続された、物理的に分離された複数のアベイラビリティーゾーンを提供します。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。
AWS Transfer Family は最大 3 つのアベイラビリティーゾーンをサポートし、接続および転送リクエストのオートスケーリング、冗長フリートによってバックアップされます。
すべての Transfer Family エンドポイントの場合:
+ アベイラビリティーゾーンレベルの冗長性は、 サービスに組み込まれています。
+ AZ ごとに冗長フリートがあります。
+ この冗長性は自動的に提供されます。
**注記**
Virtual Private Cloud (VPC) のエンドポイントでは、単一のサブネットを提供できます。ただし、アベイラビリティーゾーンの停止中のサービス中断のリスクを軽減するために、VPC 内の複数のアベイラビリティーゾーンにエンドポイントを作成することをお勧めします。
**以下の資料も参照してください。**
+ VPC で Transfer Family サーバーを作成する方法の詳細については、「」を参照してください[Virtual Private Cloud でサーバーを作成する](create-server-in-vpc.md)。
+ AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
+ レイテンシーベースのルーティングを使用して冗長性を高め、ネットワークレイテンシーを最小限に抑える方法の例については、ブログ記事[AWS Transfer Family 「サーバーでのネットワークレイテンシーを最小限に抑える](https://aws.amazon.com/blogs/storage/minimize-network-latency-with-your-aws-transfer-for-sftp-servers/)」を参照してください。
# VPC と AWS Transfer Family APIs間のプライベート接続を作成する
[AWS PrivateLink](https://aws.amazon.com/privatelink/) を搭載した*インターフェイス VPC エンドポイント*を作成することで、VPC と AWS Transfer Family APIs 間のプライベート接続を確立できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を使用せずに、VPC 内にあるかのように AWS Transfer Family APIs にアクセスできます。VPC のインスタンスは、パブリック IP アドレスがなくても AWS Transfer Family API と通信できます。
インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。詳細については、[「 AWS PrivateLink ガイド」の「PrivateLink 経由で AWS サービスにアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。 *AWS PrivateLink * AWS Transfer Family APIs*AWS 「 PrivateLink ガイド*」の[「考慮事項](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を参照してください。
## VPC エンドポイントポリシーを使用したアクセスの制御
デフォルトでは、 AWS Transfer Family APIsへのフルアクセスはエンドポイントを介して許可されます。VPC エンドポイントポリシーを使用してインターフェイスエンドポイントへのアクセスを制御できます。 AWS Transfer Family APIs へのアクセスを制御するエンドポイントポリシーを VPC エンドポイントにアタッチできます。このポリシーでは、以下の情報を指定します。
+ アクションを実行できる**プリンシパル**。
+ 実行可能な**アクション**。
+ アクションを実行できる**リソース**。
詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC エンドポイントでサービスへのアクセスを制御する](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
API の AWS Transfer Family APIs次に示します。エンドポイントにアタッチすると、このポリシーは、キー `Environment`と値 でタグ付けされたリソースを除くすべてのリソースに対するすべての AWS Transfer Family APIs アクションへのアクセスを許可します`Test`。
```
{
"Statement": [{
"Effect": "Deny",
"Action": "transfer:StartFileTransfer",
"Principal": "*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "Test"
}
}
}, {
"Effect": "Allow",
"Action": "transfer:*",
"Principal": "*",
"Resource": "*"
}]
}
```
## AWS Transfer Family APIs 用のインターフェイス VPC エンドポイントを作成する
Amazon VPC コンソールまたは コマンドラインインターフェイス () を使用して、 AWS Transfer Family APIs用の VPC AWS エンドポイントを作成できますAWS CLI。詳細については、*AWS 「 PrivateLink * [ガイド」の「VPC エンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。
次のいずれかのサービス名を使用して、 AWS Transfer Family APIs用の VPC エンドポイントを作成します。
+ `com.amazonaws.region.transfer`
+ `com.amazonaws.region.transfer-fips` — 連邦情報処理規格 (FIPS) 出版物 140-3 米国政府規格に準拠したインターフェイス VPC エンドポイントを作成します。
エンドポイントのプライベート DNS を有効にすると、 などのリージョンのデフォルトの DNS 名を使用して AWS Transfer Family APIs リクエストを実行できます`transfer.us-east-1.amazonaws.com`。
# のインフラストラクチャセキュリティ AWS Transfer Family
マネージドサービスである AWS Transfer Family は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が公開した API コールを使用して、ネットワーク AWS Transfer Family 経由で にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
## NLBsと NATs を AWS Transfer Family サーバーの前に配置しない
**注記**
FTP プロトコルと FTPS プロトコルで設定されたサーバーでは、VPC の設定のみが許可されます。FTP/FTPS で使用できるパブリックエンドポイントはありません。
多くのお客様は、トラフィックを AWS Transfer Family サーバーにルーティングするように Network Load Balancer (NLB) を設定します。これは通常、 が VPC 内とインターネットの両方からサーバーにアクセスする方法 AWS を提供するか、インターネットで FTP をサポートする方法を提供する前にサーバーを作成したためです。この設定により、顧客のコストが増加するだけでなく、このセクションで説明する他の問題が発生する可能性もあります。
NAT ゲートウェイは、クライアントが企業ファイアウォールの背後にある顧客のプライベートネットワークから接続する場合に必須のコンポーネントです。ただし、多くのクライアントが同じ NAT ゲートウェイの背後にある場合、パフォーマンスと接続制限に影響を与える可能性があることに注意してください。クライアントから FTP または FTPS サーバーへの通信パスに NLB または NAT がある場合、 は NLB または NAT の IP アドレスのみ AWS Transfer Family を表示するため、サーバーはクライアントの IP アドレスを正確に認識できません。
NLB の背後にある Transfer Family サーバーの設定を使用している場合は、NLB を使用する代わりに VPC エンドポイントに移動し、Elastic IP アドレスを使用することをお勧めします。NAT ゲートウェイを使用する場合は、以下で説明する接続制限に注意してください。
FTPS プロトコルを使用している場合、この設定により、サーバーにアクセスするユーザーを監査する機能が低下するだけでなく、パフォーマンスにも影響します。 はソース IP アドレス AWS Transfer Family を使用して、接続をデータプレーン全体にシャードします。FTPS の場合、つまり、10,000 個の同時接続を持つ代わりに、通信ルートに NLB または NAT ゲートウェイを持つ Transfer Family サーバーは、300 個の同時接続に制限されます。
AWS Transfer Family サーバーの前に Network Load Balancer を配置しないことをお勧めしますが、FTP または FTPS 実装でクライアントからの通信ルートに NLB または NAT が必要な場合は、次の推奨事項に従ってください。
+ NLB の場合、ポート 8192-8200 の代わりに、ヘルスチェックにポート 21 を使用します。
+ AWS Transfer Family サーバーで、 を設定して TLS セッションの再開を有効にします`TlsSessionResumptionMode = ENFORCED`。
**注記**
これはセキュリティを強化するため、推奨されるモードです。
クライアントは、後続の接続に TLS セッションの再開を使用する必要があります。
一貫した暗号化パラメータを確保することで、より強力なセキュリティ保証を提供します。
ダウングレード攻撃の可能性を防ぐのに役立ちます。
パフォーマンスを最適化しながら、セキュリティ標準への準拠を維持します。
+ 可能であれば、NLB の使用から移行して、パフォーマンスと接続の制限を最大限に活用 AWS Transfer Family します。
NLB の代替案に関する追加のガイダンスについては、 AWS サポートを通じて AWS Transfer Family 製品管理チームにお問い合わせください。セキュリティ体制の改善の詳細については、ブログ記事[AWS Transfer Family 「サーバーのセキュリティを向上させるための 6 つのヒント](https://aws.amazon.com/blogs/security/six-tips-to-improve-the-security-of-your-aws-transfer-family-server/)」を参照してください。
## VPC 接続インフラストラクチャのセキュリティ
VPC 出力タイプの SFTP コネクタは、ネットワーク分離とプライベート接続を通じてインフラストラクチャのセキュリティを強化します。
### ネットワーク分離の利点
+ **プライベートネットワークトラフィック: **プライベート SFTP サーバーへのすべてのコネクタトラフィックは VPC 内に残り、パブリックインターネットを経由することはありません。
+ **制御された出力**: VPC 経由でアクセスされるパブリックエンドポイントの場合、トラフィックは NAT ゲートウェイを経由し、出力 IP アドレスとネットワークポリシーを制御できます。
+ **VPC セキュリティコントロール**: 既存の VPC セキュリティグループ、ネットワーク ACLs、ルートテーブルを活用して、コネクタのネットワークアクセスを制御します。
+ **ハイブリッド接続**: インターネットにさらされることなく、確立された VPN または Direct Connect 接続を介してオンプレミス SFTP サーバーにアクセスします。
### Resource Gateway のセキュリティ上の考慮事項
リソースゲートウェイは、クロス VPC リソースアクセス用の安全な進入ポイントを提供します。
+ **マルチ AZ 配置**: リソースゲートウェイでは、高可用性と耐障害性を実現するために、少なくとも 2 つのアベイラビリティーゾーンにサブネットが必要です。
+ **セキュリティグループコントロール**: セキュリティグループを設定して、承認されたソースからのみ SFTP ポート (通常はポート 22) へのアクセスを制限します。
+ **プライベートサブネット配置**: プライベート SFTP サーバーに接続するときに、プライベートサブネットに Resource Gateway をデプロイして、ネットワークの分離を維持します。
+ **接続制限**: 各 Resource Gateway は、TCP 接続に対して 350 秒のアイドルタイムアウトで最大 350 の同時接続をサポートします。
# ウェブアプリケーションファイアウォールを追加する
AWS WAF は、ウェブアプリケーションと APIsから保護するのに役立つウェブアプリケーションファイアウォールです。定義したカスタマイズ可能なウェブセキュリティルールと条件に基づいて、ウェブリクエストを許可、ブロック、またはカウントする (*ウェブアクセスコントロールリスト*またはウェブ ACL と呼ばれる) 一連のルールを設定できます。詳細については、[「 を使用して API AWS WAF を保護する APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)」を参照してください。
**追加するには AWS WAF**
1. [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway/) で API Gateway コンソールを開きます。
1. **API** ナビゲーションペインでカスタム ID プロバイダーテンプレートを選択します。
1. [**Stages**] (ステージ) を選択します。
1. [**Stages**] (ステージ) ペインで、ステージの名前を選択します。
1. [**Stage Editor**] (ステージエディタ) ペインで [**Settings**] (設定) タブを選択します。
1. 以下のいずれかの操作をします。
+ [**Web Application Firewall (WAF)**] (Web アプリケーションファイアウォール (WAF)) の下にある [**Web ACL**] (ウェブ ACL) で、このステージに関連付けるウェブ ACL を選択します。
+ 必要なウェブ ACL が存在しない場合、次の手順に従ってウェブ ACL を作成する必要があります。
1. [**Create Web ACL**] (ウェブ ACL を作成) を選択します。
1. AWS WAF サービスのホームページで、**ウェブ ACL の作成**を選択します。
1. [**Web ACL details**] (ウェブ ACL の詳細) の [**Name**] (名前) にウェブ ACL の名前を入力します。
1. [**Rules**] (ルール) で [**Add rules**] (ルールの追加) を選択してから [**Add my own rules and rule groups**] (独自のルールとルールグループの追加) を選択します。
1. [**Rule set**] (ルールタイプ) で特定の IP アドレスのリストを識別する IP セットを選択します。
1. [**Rule**] (ルール) にルールの名前を入力します。
1. [**IP set**] (IP セット) で既存の IP セットを選択します。IP セットを作成するには、「[IP セットの作成](https://docs.aws.amazon.com/waf/latest/developerguide/waf-ip-set-creating.html)」を参照してください。
1. [**IP address to use as the originating address**] (発信アドレスとして使用する IP アドレス) で [**IP address in header**] (ヘッダー内の IP アドレス) を選択します。
1. [**Header field name**] (ヘッダーフィールド名) に `SourceIP` 入力します。
1. [**Position inside header**] (ヘッダー内の位置) で [**First IP address**] (最初の IP アドレス) を選択します。
1. [**Fallback for missing IP address**] (IP アドレスが見つからない場合のフォールバック) で、ヘッダー内の無効な (または欠落している) IP アドレスの処理方法に応じて [**Match**] (一致) または [**No Match**] (一致なし) を選択します。
1. [**Action**] (アクション) で IP セットのアクションを選択します。
1. [**Default web ACL action for requests that don't match any rules**] (どのルールにも一致しないリクエストに対するデフォルトのウェブ ACL アクション) で [**Allow**] (許可) または [**Block**] (ブロック) を選択してから [**Next**] (次へ) を選択します。
1. ステップ 4 と 5 では [**Next**] (次へ) を選択します。
1. [**Review and create**] (確認と作成) で選択内容を見直してから[**Create web ACL**] (ウェブ ACL を作成) を選択します。
1. [**Save Changes**] (変更を保存) を選択します。
1. [**Resources**] (リソース) を選択します。
1. [**Actions**] (アクション) で [**Deploy API**] (API のデプロイ) を選択します。
AWS ウェブアプリケーションファイアウォールを使用した Transfer Family の安全性については、 AWS ストレージブログの「[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/)」を参照してください。
# サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出す側サービスは、そのアクセス許可を使用して、他の顧客のリソースにアク セスするために、他の方法ではアクセス許可を持っていないはずの操作を行うことができます。これを防ぐため、 AWS では、アカウントのリソースへのアクセス権が付与されたサービスプリンシパルで、すべてのサービスのデータを保護するために役立つツールを提供しています。この問題の詳細な説明については、「IAM ユーザーガイド」の「[混乱した代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)」を参照してください。
AWS Transfer Family がリソースに対して持つアクセス許可を制限するには、リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) グローバル条件コンテキストキーを使用することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、`aws:SourceAccount` 値と、`aws:SourceArn` 値に含まれるアカウントが、同じアカウント ID を示している必要があります。
混乱した代理問題を回避するための最も効果的な方法は、許可するリソースに正確な Amazon リソースネーム (ARN) を使用することです。複数のリソースを指定する場合は、ARNの未知の部分にワイルドカード文字（`*`）を使用した`aws:SourceArn`グローバルコンテキスト条件キーを使用する。例えば、`arn:aws:transfer::region::account-id:server/*`。
AWS Transfer Family は、次のタイプのロールを使用します。
+ **ユーザーロール** – サービスマネージドユーザーが必要な Transfer Family リソースにアクセスできるようにします。 AWS Transfer Family は、Transfer Family ユーザー ARN のコンテキストでこのロールを引き受けます。
+ 「**アクセスロール**」 — 転送中の Amazon S3 ファイルのみへのアクセスを提供します。インバウンド AS2 転送の場合、アクセスロールは契約の Amazon リソースネーム (ARN) を使用します。アウトバウンド AS2 転送の場合、アクセスロールはコネクタの ARN を使用します。
+ 「**呼び出しロール**」 — Amazon API Gateway でサーバーのカスタム ID プロバイダーとして使用します。Transfer Family は、Transfer Family サーバー ARN のコンテキストでこの役割を引き受けます。
+ 「**ロギングロール**」 — Amazon CloudWatch にエントリを記録するために使用されます。Transfer Family はこのロールを使用して、成功と失敗の詳細をファイル転送に関する情報とともに記録します。Transfer Family は、Transfer Family サーバー ARN のコンテキストでこの役割を引き受けます。アウトバウンドAS2転送では、ログロールはコネクタARNを使用する。
+ 「**実行ロール**」 — Transfer Family ユーザーがワークフローを呼び出して起動できるようにします。Transfer Family は、Transfer Family のワークフローARNのコンテキストにおいて、この役割を引き受ける。
詳細については、「* IAM ユーザーガイド*」の「[IAM のポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。
**注記**
次の例では*ユーザー入力プレースホルダー*をユーザー自身の情報で置き換えます。
**注記**
この例では、`ArnLike` と `ArnEquals` の両方を使用しています。これらは機能的には同じなので、ポリシーを作成する際にはどちらを使用してもかまいません。Transfer Family ドキュメントでは、条件にワイルドカード文字が含まれる場合は `ArnLike`を使用し、完全一致の条件を示す場合は `ArnEquals` を使用しています。
## AWS Transfer Family ユーザーロールのサービス間の混乱した代理の防止
次のポリシーの例は、アカウント内の任意のサーバーのすべてのユーザーにロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/*"
}
}
}
]
}
```
次のポリシーの例は、特定のサーバーのすべてのユーザーにロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/server-id/*"
}
}
}
]
}
```
次のポリシーの例は、特定のサーバーの特定のユーザーにロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:user/server-id/user-name"
}
}
}
]
}
```
## AWS Transfer Family ワークフローロールのサービス間の混乱した代理の防止
次のポリシーの例は、アカウント内のすべてのワークフローでロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-west-2:111122223333:workflow/*"
}
}
}
]
}
```
次のポリシーの例は、特定のワークフローでロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-west-2:111122223333:workflow/workflow-id"
}
}
}
]
}
```
## AWS Transfer Family コネクタロールのサービス間の混乱した代理の防止
次のポリシー例では、アカウント内のすべてのコネクタがロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:connector/*"
}
}
}
]
}
```
次のポリシー例では、特定のコネクタがロールを引き受けることを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "transfer.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:transfer:us-east-1:123456789012:connector/connector-id"
}
}
}
]
}
```
## AWS Transfer Family のログ記録と呼び出しロールのサービス間の混乱した代理の防止
**注記**
以下の例は、ロギングロールと呼び出しロールの両方で使用できます。
これらの例では、サーバーにワークフローがアタッチされていない場合、ワークフローの ARN の詳細を削除できます。
次のログ記録/呼び出しポリシーの例では、アカウント内のすべてのサーバー (およびワークフロー) がロールを引き受けることを許可します。
****
```
{
"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/*"
]
}
}
}
]
}
```
次のログ記録/呼び出しポリシーの例では、特定のサーバー (およびワークフロー) がロールを引き受けることを許可します。
****
```
{
"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 AWS Transfer Family の マネージドポリシー
ユーザー、グループ、ロールにアクセス許可を追加するには、自分でポリシーを記述するよりも AWS 管理ポリシーを使用する方が簡単です。必要なアクセス許可のみをチームに提供する [AWS Identity and Access Management (IAM) カスタマー管理ポリシーを作成するには](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)、時間と専門知識が必要です。すぐに開始するには、 AWS マネージドポリシーを使用できます。これらのポリシーは、一般的なユースケースをターゲット範囲に含めており、 AWS アカウントで利用できます。 AWS マネージドポリシーの詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。すべての AWS 管理ポリシーの詳細なリストについては、「 [AWS 管理ポリシーリファレンスガイド](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html)」を参照してください。
AWS サービスは、 AWS 管理ポリシーを維持および更新します。 AWS 管理ポリシーのアクセス許可は変更できません。サービスでは新しい機能を利用できるようにするために、 AWS マネージドポリシーに権限が追加されることがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスは AWS マネージドポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が損なわれることはありません。
さらに、 は、複数のサービスにまたがるジョブ関数の マネージドポリシー AWS をサポートしています。たとえば、 `ReadOnlyAccess` AWS 管理ポリシーは、すべての AWS サービスとリソースへの読み取り専用アクセスを提供します。サービスが新機能を起動すると、 は新しいオペレーションとリソースの読み取り専用アクセス許可 AWS を追加します。ジョブ機能のポリシーの一覧および詳細については、「*IAM ユーザーガイド*」の「[AWS のジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
## AWS マネージドポリシー: AWSTransferConsoleFullAccess
この`AWSTransferConsoleFullAccess`ポリシーは、 AWS マネジメントコンソールを介して Transfer Family へのフルアクセスを提供します。詳細については、[AWS 「Transfer Family のサービスにリンクされたロール](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferConsoleFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AWSTransferFullAccess
この `AWSTransferFullAccess` ポリシーは、Transfer Family サービスへのフルアクセスを提供します 詳細については、[AWS 「Transfer Family のサービスにリンクされたロール](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AWSTransferLoggingAccess
この`AWSTransferLoggingAccess`ポリシーは、ログストリームとグループを作成し、アカウントにログイベントを配置するためのフルアクセスを AWS Transfer Family に付与します。詳細については、[AWS 「Transfer Family のサービスにリンクされたロール](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferLoggingAccess.html)」を参照してください。
## AWS マネージドポリシー: AWSTransferReadOnlyAccess
`AWSTransferReadOnlyAccess` ポリシーは、Transfer Familyサービスへの読み取り専用アクセスを提供します。詳細については、[AWS 「Transfer Family のサービスにリンクされたロール](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSTransferReadOnlyAccess.html)」を参照してください。
## AWS AWS 管理ポリシーへの Transfer Family の更新
このサービスがこれらの変更の追跡を開始してからの AWS Transfer Family の AWS マネージドポリシーの更新に関する詳細を表示します。このページへの変更に関する自動アラートについては、[のドキュメント履歴 AWS Transfer Family](doc-history.md) ページの RSS フィードを購読してください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| ドキュメントの更新 | Transfer Family の各管理ポリシーにセクションを追加しました。 | 2022 年 1 月 27 日 |
| [AWSTransferReadOnlyAccess](#security-iam-awsmanpol-transferreadonlyaccess) — 既存のポリシーに更新 | AWS Transfer Family は、ポリシーに の読み取りを許可する新しいアクセス許可を追加しました AWS Managed Microsoft AD。 | 2021 年 9 月 30 日 |
| AWS Transfer Family が変更の追跡を開始しました | AWS Transfer Family は AWS 、管理ポリシーの変更の追跡を開始しました。 | 2021 年 6 月 15 日 |