Cloud Storage の組織のポリシーに関する制約

このページでは、Cloud Storage に適用される組織のポリシーの制約に関する補足情報について説明します。制約を使用して、プロジェクト全体または組織全体にバケットおよびオブジェクトの動作を適用します。

Cloud Storage の制約

次の制約を組織のポリシーに適用して、Cloud Storage に関連付けることが可能です。

公開アクセスの防止を適用する

API 名: constraints/storage.publicAccessPrevention

リソースに publicAccessPrevention 制約を適用すると、そのリソースに含まれるすべてのバケットとオブジェクト（新規と既存の両方）で公開アクセスが制限されます。

publicAccessPrevention の有効化または無効化が反映されるまでに 10 分ほどかかることがあります。

保持ポリシー期間（秒）

API 名: constraints/storage.retentionPolicySeconds

retentionPolicySeconds 制約を適用する場合は、制約の一部として 1 つ以上の期間を指定します。設定したバケットの保持ポリシーには、指定された期間のいずれかを含める必要があります。retentionPolicySeconds は、新しいバケットを作成する場合だけでなく、既存バケットに保持ポリシーを追加または更新する場合にも必要です。ただし、既存のバケットには必要ありません。

異なるリソースレベルで複数の retentionPolicySeconds 制約を設定すると、これらの制約は階層的に適用されます。このため、上位層のポリシーも考慮されるように、inheritFromParent フィールドを true に設定することをおすすめします。

均一なバケットレベルのアクセスを必須にする

API 名: constraints/storage.uniformBucketLevelAccess

uniformBucketLevelAccess 制約を適用する場合は、新しいバケットで均一なバケットレベルのアクセス機能を有効にする必要があります。この機能を有効にしている既存のバケットではこの機能を無効にすることはできません。均一なバケットレベルのアクセスが無効になっている既存のバケットを有効にする必要はありません。

詳細な監査ロギングモード

API 名: constraints/gcp.detailedAuditLoggingMode

detailedAuditLoggingMode 制約を適用する場合は、Cloud Storage オペレーションに関連する Cloud Audit Logs のログには、詳細なリクエスト情報とレスポンス情報が含まれます。この制約は、SEC Rule 17a-4(f)、CFTC Rule 1.31(c)-(d)、FINRA Rule 4511(c) などのさまざまなコンプライアンスが目標である場合は、バケットロックと組み合わせて使用することをおすすめします。

ログに記録される情報には、クエリ パラメータ、パスパラメータ、リクエスト本文パラメータが含まれます。ログでは、リクエストとレスポンスで機密情報に関連する部分は除外されます。たとえば、以下のものが除外されます。

  • 認証情報（Authorization、X-Goog-Signature、upload-id など）。
  • 暗号鍵の情報（x-goog-encryption-key など）。
  • 未加工のオブジェクト データ。

この制約を使用する場合は、次の点に注意してください。

  • 詳細なリクエスト情報とレスポンス情報が必ず返されるとは限りません。まれに、空のログが返されることがあります。

  • detailedAuditLoggingMode を有効にすると、監査ログに保存されるデータ量が増加し、それがデータアクセス ログの Cloud Logging の料金に影響する可能性があります。

  • detailedAuditLoggingMode の有効化または無効化が実施されるまでに 10 分程度かかります。

  • ログに記録されたリクエストとレスポンスは、JSON API のフィールド名と一致する汎用形式で記録されます。

認証タイプを制限する

API 名: constraints/storage.restrictAuthTypes

restrictAuthTypes 制約を適用すると、制限付き認証タイプを使用して Cloud Storage リソースにアクセスするリクエストは、リクエストが有効であるかどうかにかかわらず失敗します。この制約は、規制要件がある場合や、データ セキュリティの強化が必要な場合におすすめします。

制限できる認証タイプは次のとおりです。

  • USER_ACCOUNT_HMAC_SIGNED_REQUESTS: ユーザー アカウントの HMAC キーで署名されたリクエストを制限します。

  • SERVICE_ACCOUNT_HMAC_SIGNED_REQUESTS: サービス アカウントの HMAC キーで署名されたリクエストを制限します。

  • in:ALL_HMAC_SIGNED_REQUESTS: ユーザー アカウントまたはサービス アカウント HMAC キーで署名されたリクエストを制限します。データ主権の要件を満たす必要がある場合は、HMAC で署名されたすべてのリクエストを制限することをおすすめします。

この制約を有効にすると、次のようになります。

  • Cloud Storage では、制限付き認証タイプで認証されるリクエストへのアクセスは制限されます。リクエストはエラー 403 Forbidden で失敗します。

  • リクエストの実行を事前に承認されたエンティティには、認証タイプが無効になっていることを示すエラー メッセージが表示されます。

  • HMAC キーが制限されている場合:

    • 制約が適用された HMAC キーを、制約が適用されるリソースで作成したり、有効にすることはできません。HMAC キーの作成または有効化のリクエストは、エラー 403 Forbidden で失敗します。

    • 既存の HMAC キーは残りますが、使用できなくなります。無効化または削除は可能ですが、再度有効にすることはできません。

restrictAuthTypes 制約を使用する場合は、HMAC 認証に依存する既存のリソースに注意してください。たとえば、Amazon Simple Storage Service（Amazon S3）から移行した場合、アプリケーションは HMAC キーを使用して Cloud Storage へのリクエストを認証する可能性があります。Cloud Monitoring の指標 storage.googleapis.com/authn/authentication_count を使用すると、リクエストの認証に HMAC キーが使用された回数を追跡できます。

顧客管理の暗号鍵（CMEK）の使用を必須にする

API 名: constraints/gcp.restrictNonCmekServices

restrictNonCmekServices 制約を適用する場合は、リソースが顧客管理の暗号鍵の使用を必須にするサービスを定義します。この制約を Cloud Storage オブジェクトまたはバケットに適用するには、制約を Deny に設定して、制限付きサービスのリストに storage.googleapis.com を追加します。制約の対象となる場合、Cloud Storage オブジェクトは、リクエストで指定されているか、宛先バケットでデフォルトの暗号鍵として設定されている Cloud KMS 鍵を使用して作成する必要があります。Cloud Storage バケットには、デフォルトの暗号鍵として Cloud KMS 鍵が設定されている必要があります。

Cloud KMS 鍵で暗号化されていないオブジェクト書き込みやバケットの作成を行うと、次のようなエラー メッセージが表示されます。「組織のポリシーで顧客管理の暗号鍵（CMEK）が必須になっています。バケットのデフォルトの CMEK を設定するか、リクエストで CMEK を指定してください。」

この制約を使用する場合は、次の点に注意してください。

  • restrictNonCmekServices を有効にした場合、デフォルトの Cloud KMS 鍵のないバケットに書き込むか、リクエストで Cloud KMS 鍵を除外すると、互換性のない変更が発生する可能性があります。

  • デフォルトの Cloud KMS 鍵を持たない既存のバケットは、制約の影響を受けません。ただし、制約が有効になっているときに既存のバケットに Cloud KMS 鍵を設定すると、そのバケットは制約の対象になります。

  • この制約は、Google が管理する暗号鍵または顧客指定の暗号鍵で暗号化された既存のオブジェクトに適用されません。ただし、将来このようなオブジェクトの書き換えを行う場合は制約が適用されます。

  • constraints/gcp.restrictNonCmekServices への変更が有効になるまで最大で 10 分ほどかかります。

この制約の詳細については、CMEK 組織のポリシーをご覧ください。

有効な顧客管理の暗号鍵（CMEK）でプロジェクトを制限する

API 名: constraints/gcp.restrictCmekCryptoKeyProjects

restrictCmekCryptoKeyProjects 制約を適用する場合は、Cloud KMS 鍵を使用してリクエストで使用できるプロジェクトを定義します。この制約を適用すると、次のようになります。

  • リクエストで指定された Cloud KMS 鍵は、組織のポリシーで許可されているプロジェクトから取得する必要があります。

  • 新しいバケットを作成する場合、バケットに設定する Cloud KMS 鍵は、許可されているプロジェクトから取得する必要があります。

  • 無効な Cloud KMS 鍵を持つ既存のバケットでは、オブジェクトの書き込みと更新に失敗します。バケットのデフォルトの Cloud KMS 鍵を、許可されたプロジェクトから提供された鍵に変更するか、Cloud KMS をバケットから削除する必要があります。restrictNonCmekServices 制約が有効になっている場合、バケットから Cloud KMS 鍵は削除できません。

許可されたプロジェクト以外からのリクエストで Cloud KMS 鍵を指定しようとすると、次のようなエラー メッセージが表示されます。「プロジェクトが組織のポリシーによって制限されているため、指定した鍵は使用できません。許可されたプロジェクトの顧客管理の暗号鍵（CMEK）を使用して、もう一度お試しください。」

許可されたプロジェクト以外の Cloud KMS 鍵を使用してバケットに書き込もうとすると、次のようなエラー メッセージが表示されます。「このバケットは、組織ポリシーによって制限されているプロジェクトのデフォルトの鍵を使用しています。許可された顧客管理の暗号鍵（CMEK）をバケットのデフォルトとして設定するか、リクエストで許可された CMEK を指定してください。」

この制約を使用する場合は、次の点に注意してください。

  • この制約は、既存のオブジェクトには適用されません。

  • この制約だけでは、許可されたプロジェクトの顧客管理の暗号鍵の使用は適用されません。許可されたプロジェクトの顧客管理の暗号鍵の使用を適用するには、constraints/gcp.restrictNonCmekServices と constraints/gcp.restrictCmekCryptoKeyProjects の両方の制約を適用する必要があります。

  • constraints/gcp.restrictCmekCryptoKeyProjects への変更が有効になるまで最大で 10 分ほどかかります。

この制約の詳細については、CMEK 組織のポリシーをご覧ください。

次のステップ