XEIZE
/脆弱性の文書/IaC/Google Deployment Manager/GCP/Cloud Storage バケットの ACL 設定の確認

Cloud Storage バケットの ACL 設定の確認

Cloud Storage の実際の ACL と IAM 権限を確認し、不要な公開アクセスを取り除きます。ACL を省略しただけでバケットが公開されるわけではありません。

説明

Cloud Storage の allUsers には匿名ユーザーも含まれ、allAuthenticatedUsers も同じプロジェクトのユーザーだけには限定されません。これらの主体に不要な権限を付与すると、想定した利用者以外にもバケットやオブジェクトを公開するおそれがあります。

許可される操作はロールと対象リソースによって異なります。バケットの READER はオブジェクトの一覧取得を許可しますが、内容を読む権限とは別です。defaultObjectAcl は、アップロード時に別の ACL を指定しなかった新しいオブジェクトに適用されます。変更しても既存のオブジェクトの ACL は変わりません。

ACL を指定せずに作成したバケットには、既定で projectPrivate が適用されるため、省略だけで公開アクセスを意味するわけではありません。均一なバケットレベルのアクセスを使うと ACL は無効になり、IAM で権限を管理します。実際の IAM ポリシーと公開アクセス防止の設定も確認してください。

想定される影響

  • 公開読み取りが許可されたオブジェクトの内容が、想定していない利用者に漏えいする可能性があります。バケットの一覧取得権限だけで、すべてのオブジェクトを読めるわけではありません。
  • 公開書き込みが許可されると、外部の利用者がオブジェクトを作成、置換、削除できる場合があります。
  • 公開用のデフォルトオブジェクト ACL が適用されると、その後アップロードするオブジェクトも公開されるおそれがあります。

対処方法

  • 実際の IAM ポリシーと ACL を確認し、不要な公開権限を取り除いてください。公開する必要がないバケットには公開アクセス防止を適用してください。
  • 均一なバケットレベルのアクセスに移行する前に、必要な ACL ベースの権限を IAM に移してください。すでにこの機能を使っているバケットに ACL を追加しないでください。
  • ACL が必要な場合は、指定する対象とロールを必要最小限にし、既存オブジェクトとデフォルトオブジェクト ACL の両方を確認してください。変更後も必要なアクセスができ、不要なアクセスが拒否されることをテストしてください。

例

以下は既存の Deployment Manager テンプレートの部分的な例です。バケット名を実際の環境に合わせ、サービスのサポート終了と移行に関する案内を確認してください。

既定の ACL を使用

yaml
resources:
  - name: storage-bucket
    type: storage.v1.bucket
    properties:
      name: my-bucket

ACL を明示せずにバケットを作成する例です。公開されているかどうかは、実際の IAM 権限とバケットのアクセス制御を確認して判断してください。

特定のユーザーに読み取りを許可

yaml
resources:
  - name: storage-bucket
    type: storage.v1.bucket
    properties:
      name: my-bucket
      acl:
        - entity: user-liz@example.com
          role: READER
      defaultObjectAcl:
        - entity: user-liz@example.com
          role: READER

ACL を使うバケットで、指定したユーザーにオブジェクトの一覧取得と、新しくアップロードされるオブジェクトの読み取りを許可する例です。必要な権限を持たせる実際のアカウントに置き換え、ほかの IAM 権限や既存オブジェクトの ACL が公開アクセスを許可していないかも確認してください。

参考資料

XEIZE Documentationテクニカルサポート