翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
追加のガードレール
署名付きリクエストがソリューションビルダーとユーザーによって適切に使用されると、データへのアクセスをユーザーに許可する安全なメカニズムが提供されます。さらに、署名付きリクエストを生成する機能は、プリンシパルにまだ持っていないアクセスを提供しません。
そのコンテキストでは、追加のコントロールが必要ですか？ 追加のコントロールの根拠は、アクセスを拒否する必要性ではなく、モニタリング、使用の承認、境界の設定、ユーザーエラーによるリスクを軽減する機能を提供することに基づいています。このようにして、使用が適切で必要であることを確認することができます。
次のガードレールは、この目標に役立ちます。これらのコントロールを有効にする前に、署名付きリクエストを識別して既存の使用状況を確認することをお勧めします。この識別は、ガードレールが既存の使用状況に与える影響に備えたり、必要に応じて例外を計画したりするのに役立ちます。
s3:signatureAge のガードレール
署名付きリクエストの定義特性の 1 つは、有効期限を記述することです。リクエストの署名には日付が含まれます。この日付は、署名付き URL のX-Amz-Dateクエリ文字列パラメータとして、および署名付き POST の日付または x-amz-date ヘッダーとして送信されます。 URLs
Amazon S3 には条件キー s3:signatureAge が用意されています。これを使用して、署名日からリクエストの有効な有効期限までの最大時間を制限できます。この条件は有効期間を長くすることはできませんが、減らすことができます。
次のポリシーでは、 s3:signatureAge条件キーは署名付きリクエストを 15 分の有効性に制限します。次の例では、すべて 15 分を使用して、標準署名がサポートするのと同様の期間に有効性を制限します。
ポリシーの 2 番目のステートメントは、署名バージョン 2 へのアクセスを拒否します。このバージョンの署名プロトコルは廃止されていますが、一部の では引き続きサポートされています 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 を使用して、スケーラブルな方法で例外を管理します。AWS データ境界ポリシー AWS の例など、その他の例では、この戦略を使用します。 https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md#tagging-conventions
を使用して例外ポリシーを実装する場合はaws:PrincipalTag、プリンシパルにタグを設定するアクセスを制御する必要があります。このタイプのタグは、設定できるタグ値を制御するこの例のように、プリンシパルから直接取得でき、SCP によって制御できますaws:PrincipalTagは複雑なトピックです。ただし、属性ベースのアクセスコントロール (ABAC) の使用経験のある組織には、このユースケースaws:PrincipalTagで を適切に使用するための経験とコントロールがあります。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
バケットポリシー
次の例のようにポリシーを使用して、バケットポリシーをすべてのバケットまたは選択したバケットに適用できます。SCP とは異なり、バケットポリシーはサービスプリンシパルの使用もターゲットにします。付録 A は、署名付きリクエストの予想されるサービスプリンシパルの使用を文書化していませんが、その制限を証明するためにコントロールを実装する場合は、次のポリシーがそのコントロールを提供します。また、SCP とは異なり、バケットポリシーは管理アカウントのプリンシパルに適用できます。ABAC ベースの例外は、SCP と同じ方法でバケットポリシーで機能します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
s3:authType のガードレール
署名付き URLsクエリ文字列認証を使用し、署名付き POSTs は常に POST 認証を使用します。Amazon S3 は、s3:authType 条件キーを介した認証タイプに基づくリクエストの拒否をサポートします。 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。
永続的な認証情報にはこの制限はありません。一時的な認証情報のみを使用することがベストプラクティスであり、永続的な認証情報を明示的に取り消して、その認証情報に基づいて署名を無効にすることもできます。
s3:signatureAge はミリ秒単位で測定されますが、適切に同期されたクロックと低レイテンシーの使用量があっても、60 秒未満に設定することは実用的ではありません。60 秒未満の設定では、有効なリクエストを拒否するリスクがあります。署名の生成とリクエストの送信の間に遅延が予想される場合、またはクロックの同期に問題がある場合は、 の管理でこれらを考慮する必要がありますs3:signatureAge。
大規模なバケットのターゲット設定
SCPsは、 aws:PrincipalTagを使用してユーザーの例外を作成できます。バケットのタグを使用してアクセスを制御することはできませんaws:ResourceTag。アクセスコントロールにはオブジェクトタグのみが使用されます。通常、このコントロールを適用するすべてのオブジェクトにタグを追加することはスケーラブルではありません。
多くのユースケースに適した解決策は、SCP が適用されるアカウントを変更するか、aws:ResourceAccount、aws:ResourceOrgPaths、または aws:ResourceOrgID を使用して、アカウントレベルでポリシーと例外を適用することです。たとえば、SCP を一連の本番稼働用アカウントに適用できます。
もう 1 つの解決策は、カスタム AWS Config ルールを使用して検出コントロールまたは応答コントロールを実装することです。目標は、すべてのバケットに適切なガードレールを持つバケットポリシーを含めることです。バケットポリシーの内容のテストに加えて、バケットに特定の値がタグ付けされている場合、カスタム AWS Config ルールはバケットからタグを取得し、ルールからバケットを除外できます。そのルールがコンプライアンスチェックに失敗した場合、バケットを非準拠としてマークするか、修復を呼び出してバケットのポリシーにガードレールを追加できます。
注記
リクエストのタグコンテンツを PutBucketTagging に制限することはできません。バケットのタグ付け方法の制御を維持するには、 PutBucketTaggingおよび DeleteBucketTagging へのアクセスを制限する必要があります。
