翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 追加のガードレール 署名付きリクエストがソリューションビルダーとユーザーによって適切に使用されると、ユーザーにデータへのアクセスを許可する安全なメカニズムが提供されます。さらに、署名付きリクエストを生成する機能は、プリンシパルにまだ持っていないアクセスを提供しません。 そのコンテキストでは、追加のコントロールが必要ですか? 追加のコントロールの根拠は、アクセスを拒否する必要性ではなく、モニタリング、使用の承認、境界の設定、ユーザーエラーによるリスクを軽減する機能を提供することに基づいています。このようにして、使用が適切で必要であることを確認することができます。 次のガードレールは、この目標に役立ちます。これらのコントロールを有効にする前に、署名付きリクエストを識別して既存の使用状況を確認することをお勧めします。この識別は、ガードレールが既存の使用状況に与える影響に備えたり、必要に応じて例外を計画したりするのに役立ちます。 ## s3:signatureAge のガードレール 署名付きリクエストの定義特性の 1 つは、有効期限を記述することです。リクエストの署名には日付が含まれます。この日付は、署名付き URL の`X-Amz-Date`クエリ文字列パラメータとして、および署名付き POST [の日付または x-amz-date ヘッダー](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html)として送信されます。 URLs Amazon S3 には条件キー [s3:signatureAge](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html) が用意されています。これを使用して、署名日からリクエストの有効な有効期限までの最大時間を制限できます。この条件は有効期間を延長することはできませんが、短縮できます。 次のポリシーでは、 `s3:signatureAge`条件キーは署名付きリクエストを 15 分の有効性に制限します。次の例では、すべて 15 分を使用して、標準署名がサポートするのと同様の期間に有効性を制限します。 ポリシーの 2 番目のステートメントは、署名バージョン 2 へのアクセスを拒否します。[このバージョンの署名プロトコルは廃止されています](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAWSSDK.html#UsingAWSSDK-sig2-deprecation)が、一部の では引き続きサポートされています AWS リージョン。完全に廃止する前に、明示的にブロックすることをお勧めします。 次のポリシーを AWS Organizations サービスコントロールポリシー (SCP) として適用できます。署名の生成から使用までの時間が 15 分未満であれば、ユーザーは署名付きリクエストを使用し、それらのリクエストに依存するソリューションをデプロイできます。実装によっては、この制限は影響しないか、ソリューションが使用できなくなるか、再試行できる障害が時折発生する可能性があります。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] } ``` ### 例外 ソリューションが有効期限より長い時間を必要とするため、前述のポリシーの影響を受ける場合は、例外を承認する方法を指定することをお勧めします。SCP で例外が列挙されないようにするには、次のポリシーのように [aws:PrincipalTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) を使用して、スケーラブルな方法で例外を管理します。AWS データ境界ポリシー AWS の例など、その他の例では、この戦略を使用します。 [https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md) を使用して例外ポリシーを実装する場合は`aws:PrincipalTag`、プリンシパルのタグの設定へのアクセスを制御する必要があります。このタイプのタグは、[設定できるタグ値を制御するこの例のように、プリンシパルから直接取得でき、SCP によって制御できます](https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/service_control_policies/data_perimeter_governance_scp.json)。このタイプのタグは、ID プロバイダー (IdP) または の使用時に設定される[セッションタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html)から取得することもできます AWS STS。へのアクセスの制御`aws:PrincipalTag`は複雑なトピックです。ただし、[属性ベースのアクセスコントロール (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) の使用経験のある組織には、このユースケース`aws:PrincipalTag`で を適切に使用するための経験とコントロールがあります。 次の例では、 `aws:PrincipalTag`条件は、名前付きタグ (`long-presigned-allowed`) が割り当てられ、 に設定されたすべてのプリンシパルを許可する例外を作成します`true`。この例外を除き、署名の有効期間の制限は適用されません。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] } ``` ### バケットポリシー 次の例のようにポリシーを使用して、バケットポリシーをすべてのバケットまたは選択したバケットに適用できます。SCP とは異なり、バケットポリシーは[サービスプリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services)の使用もターゲットにします。[付録 A](appendix-a.md) は、署名付きリクエストの予想されるサービスプリンシパルの使用を文書化していませんが、その制限を証明するためにコントロールを実装する場合は、次のポリシーがそのコントロールを提供します。また、SCP とは異なり、バケットポリシーは管理アカウントのプリンシパルに適用できます。 ABAC ベースの例外は、SCP と同じ方法でバケットポリシーで機能します。バケットポリシーの目標は、組織外のプリンシパルに適用される場合があるため、ABAC 例外は、ABAC コントロールが適用されるプリンシパルに制限する必要があります。 次の例では、最初のステートメント`aws:PrincipalTag`の条件により、名前付きタグ (`long-presigned-allowed`) が割り当てられ、 に設定されたプリンシパルの例外が作成されます`true`。この例外を除き、署名の有効期間の制限は適用されません。2 番目のステートメントは、バケットを所有する組織外のすべてのプリンシパルに AWS この制限を適用します。この 2 番目のステートメントの範囲は、プリンシパルの名前付きタグを設定する ABAC コントロールと一致する必要があります。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] } ``` ## リソースコントロールポリシー [リソースコントロールポリシー (RCPs) を使用して、大規模なバケットにポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)を適用できます。SCPs やバケットポリシーとは異なり、RCPsサービスプリンシパルの使用を対象としません。RCPs、任意のアカウントのサービス以外のプリンシパルに影響しますが、管理アカウントのリソースには影響しません。詳細については、[AWS Organizations のドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#actions-not-restricted-by-rcps)を参照してください。 バケットポリシーと同様に、 `aws:PrincipalTags`を使用してプリンシパルの例外を作成する場合は、プリンシパルのタグ付けに関する ABAC コントロールの範囲に注意してください。 次の RCP は、署名期間を 15 分に制限することで、組織内のすべての S3 バケットで署名付き URL の使用を制限します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true", } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] } ``` ## s3:authType のガードレール 署名付き URLs[クエリ文字列認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html)を使用し、署名付き POSTs は常に [POST 認証](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authentication-HTTPPOST.html)を使用します。Amazon S3 は、[s3:authType](https://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html) 条件キーを介した認証タイプに基づくリクエストの拒否をサポートします。 `REST-QUERY-STRING`はクエリ文字列`s3:authType`の値で、 `POST`は POST `s3:authType`の値です。 次のポリシーを SCP として適用できます。ポリシーは を使用して`s3:authType`、ヘッダーベースの認証のみを許可します。また、個々のユーザーまたはロールに例外を提供するメソッドも設定します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] } ``` 認証タイプに基づいてリクエストを拒否すると、拒否された認証タイプを使用するソリューションまたは機能に影響します。たとえば、 を拒否すると、ユーザーは Amazon S3 コンソールからアップロードまたはダウンロードを実行`REST-QUERY-STRING`できなくなります。ユーザーに Amazon S3 コンソールを使用させたい場合は、このガードレールを使用したり、ユーザーに例外を設定したりしないでください。一方、ユーザーに Amazon S3 コンソールを使用しないようにする場合は、ユーザー`REST-QUERY-STRING`に対して拒否できます。 Amazon S3 リソースへのユーザーの直接アクセスを既に拒否している可能性があります。この場合、認証タイプのガードレールは冗長です。ただし、直接アクセスを拒否する実装は通常、例外を含む多くのコントロールステートメントにまたがるため、`s3:authType`拒否ステートメントはdefense-in-depthユーティリティを提供します。 通常、ワークロードに使用されるロールは、クエリ文字列や`POST`認証にアクセスする必要はありません。例外は、署名付きリクエストを使用するように設計されたサービスをサポートするロールです。これらのロールに特定の例外を作成できます。 次のようなポリシーを使用して、バケットポリシーをすべてのバケットまたは選択したバケットに適用することもできます。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] } ``` このバケットポリシーは、**CopyObject** API と **UploadPartCopy** APIs を使用してクロスリージョンコピーを行うことを拒否する効果があります。Amazon S3 レプリケーションは、これらの APIs に依存しないため、影響を受けません。 上記のポリシーなどのバケットポリシーを使用し、引き続きクロスリージョン **CopyObject** または **UploadPartCopy** API をサポートする場合は、`aws:ViaAWSService`次のような の条件を追加します。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] } ``` ## 署名付きガードレールと例外を他のガードレールと組み合わせる ユーザーとロールにガードレールを一般的に適用する予定がない場合は、他の一般的なガードレールの例外に適用して、それらの例外が署名付きリクエストをサポートしないようにすることができます。 ネットワーク制限があるが、外部パートナーまたは特別なユースケースの例外を許可する場合は、特に必要であると識別されない限り、例外が適用されるときにクエリ文字列または`POST`認証をブロックする必要があります。 ## s3:signatureAge の制限事項 管理者は、 の影響`s3:signatureAge`をより完全に理解すると便利です。すべての署名付きリクエストには`X-Amz-Date`、現在の時刻を示す が含まれます。この値はクライアントによって入力され、request signer. AWS rejects は無効な時間があると見なすリクエストを拒否します。ただし、署名者は将来の時間に署名を事前に生成できます。Amazon S3 は、送信が早すぎる場合、将来の時間を指定するリクエストを拒否します。ただし、署名にサインインするまでリクエストが送信されない場合、署名は以前に生成され、後で送信できます。 `s3:signatureAge` は、署名付きリクエストに対してのみ、署名`X-Amz-Date`内の の最大有効期間を制限します。 `X-Amz-Expires`または `POST`ポリシーの有効期限が有効であると宣言した場合でも、指定された有効期間より古いリクエストは拒否されます。 `s3:signatureAge` は、明示的な有効期限を含まないリクエストの有効期間を変更しません。また、クライアント`X-Amz-Date`が署名に使用する の値も制御しません。 システムクロックが間違っている場合、またはクライアントが意図的に将来の日付をリクエストした場合、署名時刻は署名が生成された時刻ではない可能性があります。 これにより、 がソリューションを制御`s3:signatureAge`できる量が制限されます。署名を生成する現在の時刻を使用するソリューションは、予想される方法で制限されます。署名は、 で指定されたミリ秒数の間有効です`s3:signatureAge`。現在の時刻を使用しない ソリューションには、異なる制限があります。1 つの制限は、署名に使用された認証情報がまだ有効であることです。管理者は、発行された一時的な認証情報の最大有効期間を制御できます。認証情報を最大 36 時間有効にすることも、15 分まで有効に制限することもできます。一時的な認証情報の有効期限は、 の値に依存しません`X-Amz-Date`。 永続的な認証情報にはこの制限はありません。 [一時的な認証情報のみを使用すること](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)がベストプラクティスであり、永続的な認証情報を明示的に取り消すことができます。これにより、その認証情報に基づく署名も無効になります。 `s3:signatureAge` はミリ秒単位で測定されますが、適切に同期されたクロックと低レイテンシーの使用量があっても、60 秒未満に設定することは実用的ではありません。60 秒未満の 設定では、有効なリクエストを拒否するリスクがあります。署名の生成とリクエストの送信の間に遅延が予想される場合、またはクロックの同期に問題がある場合は、 の管理でこれらを考慮する必要があります`s3:signatureAge`。 ## 大規模なバケットのターゲット設定 SCPsと RCPsは、 `aws:PrincipalTag`を使用してユーザーの例外を作成できます。バケットのタグを使用してアクセスを制御することはできません`aws:ResourceTag`。[アクセスコントロールにはオブジェクトタグのみが使用されます](https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html)。通常、このコントロールを適用するすべてのオブジェクトにタグを追加することはスケーラブルではありません。  多くのユースケースに適した解決策は、SCP または RCP が適用されるアカウントを変更するか、[aws:ResourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)、[aws:ResourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgpaths)、または [aws:ResourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid) を使用して、ポリシーと例外をアカウントレベルで適用することです。たとえば、SCP または RCP を一連の本番稼働用アカウントに適用できます。 もう 1 つの解決策は、[カスタム AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html)を使用して[検出コントロール](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/detective-controls.html)または[応答コントロール](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-security-controls/responsive-controls.html)を実装することです。目標は、すべてのバケットに適切なガードレールを持つバケットポリシーを含めることです。バケットポリシーの内容のテストに加えて、バケットに特定の値がタグ付けされている場合、カスタム AWS Config ルールはバケットからタグを取得し、ルールからバケットを除外できます。そのルールがコンプライアンスチェックに失敗した場合、バケットを非準拠としてマークするか、修復を呼び出してバケットのポリシーにガードレールを追加できます。 **注記** リクエストのタグコンテンツを [PutBucketTagging](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketTagging.html) に制限することはできません。バケットのタグ付け方法の制御を維持するには、 `PutBucketTagging`および [DeleteBucketTagging](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketTagging.html) へのアクセスを制限する必要があります。