Cloud Storageのアクセス制御方法について

はじめに

こんにちは。
クラウド事業本部コンサルティング部の渡邉です。

Cloud StorageはGoogleが提供するオブジェクトストレージサービスで、あらゆる量のデータを安全に保存することができるスケーラブルなストレージサービスです。画像、動画、バックアップ、ログファイルなど様々な非構造化データの保存に適しています。

今回は、Cloud Storageへ接続するにあたり、様々なアクセス制御の方法について調べてみました。

Cloud Storageの基本的なアクセス制御

Cloud Storageには基本的なアクセス制御機能として均一なバケットレベルのアクセスとアクセス制御リストという機能があります。

均一なバケットレベルのアクセス

均一なバケットレベルのアクセスは、IAMのみを使用して権限を管理することができます。均一なバケットレベルのアクセスを有効化することで、アクセス制御リスト (ACL) は無効になります。Google Cloudとしてもこちらのアクセス制御を推奨しているため、原則こちらの機能を利用するべきと考えます。
IAMでのアクセス制御をすることにより、マネージドフォルダ、IAM Conditions、Workforce Identityの連携など、ACLでは使用できない機能を使用することができます。

均一なバケットレベルのアクセス

注意点として、均一なバケットレベルのアクセスは、バケットで90日間連続して有効にしていた場合、無効にすることはできなくなります。 また、均一のバケットレベルのアクセスを有効にすると、ACLでアクセスしているユーザーのアクセス権が取り消されるため、既存バケットで有効化する場合は、考慮事項が記載されているドキュメントを一読することをお勧めします。
均一なバケットレベルのアクセス  |  Cloud Storage  |  Google Cloud

コンソールからCloud Storageを作成する場合は、[アクセス制御] -> [均一]を選択することで、均一なバケットレベルのアクセスの設定をすることができます。

均一なバケットレベルのアクセスの設定をした既存のバケットで、オブジェクトデータのアクセス権を編集しようとすると、ACLを有効化することはできませんとエラーが表示されます。
ACLを利用したい場合は、バケットの設定から、均一なバケットレベルのアクセスの設定から90日以内にきめ細かい管理に変更する必要があります。

アクセス制御リスト (ACL)

アクセス制御リスト (ACL)は、きめ細かい管理とも呼ばれる機能で、もともとの思想はAmazon S3と相互運用できるように設計されているCloud Storage用のレガシーなアクセス制御システムです。ACLは、オブジェクト単位でアクセス権を指定することができます。

きめ細かいアクセスでは、IAMとACLで2つの異なるアクセス制御で調整が必要になります。このため、意図しないデータ漏洩が発生する可能性が高くなります。
以下のようなケースでACLの利用は検討します。

• バケット内の個々のオブジェクトへのアクセス権をカスタマイズする
• Amazon S3 からデータを移行する

ACLにはオブジェクトに付与する権限（何ができるか）として、以下があります。

• READER（読み取り）: ファイルをダウンロード、バケット内のファイル一覧を見る
• WRITER（書き込み）: ファイルの作成・削除（バケットのみ）
• OWNER（所有者）: すべての操作 + ACL設定の変更も可能

上記の権限をどのプリンシパルに付与するのか（スコープ）を設定してアクセスを制御します。

• allUsers: インターネット上の誰でも（認証不要）
• allAuthenticatedUsers: Googleアカウントでログインした全員
• 特定のユーザー: user:alice@example.com
• Googleグループ: group:developers@example.com
• ドメイン全体: domain:example.com

上記のように、オブジェクトごとに権限を付与していく必要があるため運用コストが高く、権限付与によるミスの発生も懸念されるため、基本的には均一なバケットレベルのアクセスが推奨されます。

その他のアクセス制御オプション

公開アクセスの防止

Cloud Storageには公開アクセスの防止という設定項目があり、公開アクセスを防止すると、Cloud Storageバケットやオブジェクトが誤って外部に公開されることを防ぐことができます。設定の方法としては、

• 個々のバケットへ設定する
• 組織ポリシーで設定する

の2つの方法があります。

Cloud Storageにアップロードするデータをインターネットに公開する必要がない場合は、セキュリティを高めるため公開アクセスの防止を設定してください。静的ウェブサイトのホスティングなどオブジェクトの公開が必要なプロジェクトは公開アクセスの防止を無効化する必要があります。

個々のバケットへ設定する場合は、[アクセス制御] -> [公開アクセスの防止] -> [このバケットに対する公開アクセス禁止を適用する]を選択することで、公開アクセスの防止の設定を行うことができます。

組織ポリシーで設定する場合については、後述します。

バケットIPフィルタリング

バケットIPフィルタリングは、Cloud Storageバケットに保存されているデータへアクセスするために、リクエストの送信元IPアドレスに基づいてアクセスを制御する機能です。

送信元として、IPv4アドレス範囲、IPv6アドレス範囲、VPCがサポートされています。バケットIPフィルタリングを利用する利点としては以下の通りです。

• きめ細かいアクセス制御：リクエスト元のIPアドレスまたはVPCなどのネットワークレイヤーに基づいてアクセスを制御することができるため、信頼していないソースからの不正アクセスを防ぐことができます。
• 強化させたセキュリティ：承認済みのIPアドレスまたはVPCへのアクセスを制限することで、不正アクセスなどのリスクを制限することができます。
• 柔軟な構成：バケットレベルでIP範囲のリストを制御することができるため、アクセス要件に合わせて柔軟に対応することができます。

制限事項

現状、バケットIPフィルタリングを利用する上で、いくつか制限事項があります。

使ってみた

IPフィルタリングルールのあるCloud Storageバケットを作成してIPフィルタリングの挙動を確認してみます。

1. gcloud CLIのバージョン確認

gcloudコマンドで作成を行う場合、gcloud CLIのバージョンが526.0.0以降である必要があります。

$ gcloud version | head -n1
Google Cloud SDK 543.0.0

2. バケットのIPフィルタリング構成ファイルの作成

ある特定のパブリックIPアドレスからのリクエストは許可し、それ以外のIPアドレスからのリクエストは拒否するような構成ファイルを作成してみます。

  {
    "mode": "Enabled",
    "publicNetworkSource":
    {
      "allowedIpCidrRanges": ["xxx.xxx.xxx.xxx/32"]
    },
    "allowAllServiceAgentAccess": false
  }

3. IPフィルタリングルールのあるCloud Storageバケットの作成

gcloud alpha storage buckets createコマンドで、IPフィルタリング構成ファイルを指定してIPフィルタリングルールのあるCloud Storageバケットを作成します。

gcloud alpha storage buckets create gs://BUCKET_NAME --ip-filter-file=IP_FILTER_CONFIG_FILE

作成したバケットのIPフィルタリングルールを確認するには、gcloud alpha storage buckets describeコマンドを利用します。先ほど設定したルールが有効化であることが確認できています。

gcloud alpha storage buckets describe gs://BUCKET_NAME --format="default(ip_filter_config)"

ip_filter_config:
  allowAllServiceAgentAccess: false
  allowCrossOrgVpcs: false
  mode: Enabled
  publicNetworkSource:
    allowedIpCidrRanges:
    - xxx.xxx.xxx.xxx/32

4. IPフィルタリングルールのあるCloud Storageバケットへアクセス

Cloud ShellからIPフィルタリングルールのあるCloud Storageバケットへアクセスしてみます。Cloud ShellのIPアドレスレンジはIPフィルタリングルールに設定していないので、IPフィルタリングルールによってアクセスができないことが確認できました。

$ gcloud alpha storage buckets describe gs://BUCKET_NAME --format="default(ip_filter_config)"
ERROR: (gcloud.alpha.storage.buckets.describe) [xxxxxxxxxxx@xxxxxxxxx] does not have permission to access b instance [BUCKET_NAME] (or it may not exist): There is an IP filtering condition that is preventing access to the resource. This command is authenticated as xxxxxxxxxxx@xxxxxxxxx which is the active account specified by the [core/account] property.

5. バケットIPフィルタリングルールのバイパス

バケットIPフィルタリングルールの設定後に、接続元のIPアドレスが変わってしまった場合や、誤って異なるIPアドレスレンジを登録してしまった場合はバケットにアクセスすることができなくなってしまいます。
その際の対策として、IPフィルタリングルールをバイパスすることができる機能があります。

IPフィルタリングルールをバイパスすると、以下の操作がIPフィルタリングルールが有効化されているバケットに対してできるようになります。

• バケットのメタデータの取得
• バケットの更新
• バケットの削除

IPフィルタリングルールをバイパスするためには、storage.buckets.exemptFromIpFilter権限を持つカスタムロールを作成し、IAMでプリンシパルに付与する必要があります。

上記のカスタムロールを付与することで、IPフィルタリングの制限を受けずにサポートされているオペレーションを実行できます。誤った設定をしてしまった場合は、バイパス設定を行い、一時的にアクセス制御を回避して正しい設定に修正しましょう。

マネージドフォルダ

Cloud Storageのフォルダには、2つの概念があります。

1. シミュレートされたフォルダ

Cloud Storageはオブジェクトストレージなので、実際にはフォルダ構造を持ちません（フラットな構造）。シミュレートされたフォルダとは、実際にはフォルダ構造が存在しないにもかかわらず、フォルダのように見える仕組みのことを言います。

例えば、

• bucket/folder01/test02.txt

でオブジェクトデータを作成した場合、コンソール上のフォルダブラウザではあたかもフォルダ階層になっていますが、実態としてはフォルダ階層になっておらず、フラットな構造になっています。そのためフォルダ単位で権限を付与したりすることはできません。

2. マネージドフォルダ

マネージドフォルダは、バケット内に存在する特定のオブジェクトをグループ化し、そのフォルダに対してIAMロールを付与することができるため、きめ細かいアクセス制御を行うことができる機能です。マネージドフォルダは、Cloud Storage 内のリソースとして存在します。

まず、バケット内にフォルダ[managed-folder01]を作成します。この時にはまだシミュレートされたフォルダと同じ状態です。

フォルダの作成後、フォルダの設定から[アクセス権の編集]をクリックします。

[アクセス権の編集]をクリックすると、[フォルダ管理を有効にしますか？]とマネージドフォルダの作成のポップアップが表示されるので、[有効にします]をクリックします。

すると、フォルダ[managed-folder01]に対するアクセス権の編集を行う画面が表示されるので、[プリンシパルを追加]をクリックします。

権限を付与したいプリンシパルに対して、[Storageオブジェクト閲覧者]権限を付与します。

権限が付与されたプリンシパルで、権限が付与されたフォルダのURLへアクセスし、Google Cloudコンソールを確認したところ、「managed-folder01」と配下オブジェクトのみ参照ができ、それ以外のオブジェクトやフォルダは[アクセスが拒否されました]と表示され、アクセスできないことが確認できました。

マネージドフォルダを用いることで、フォルダ単位にアクセス権限を制御することが可能になることがわかりました。しかし、1つのバケットでフォルダごとにアクセス権限を制御すると管理が煩雑になってしまうため使いどころは検討しましょう。

組織ポリシーによる強制

組織ポリシーを利用することで、組織配下のすべてのプロジェクトのCloud Storageに対して統制を効かせることができます。Cloud Storageのアクセス制御に関する組織ポリシーで導入を検討したいポリシーを以下に記載します。

公開アクセスの防止

公開アクセスの防止:constraints/storage.publicAccessPreventionの組織ポリシーを適用することで、組織ポリシーが適用されているプロジェクトのCloud Storageバケットは新規・既存の両方でパブリックアクセスが制限されます。
意図せぬオブジェクトの公開を防ぐためにも本組織ポリシーは原則適用する必要があると考えています。組織ポリシーは特定のプロジェクトで無効化することもできますので、静的ウェブサイトのホスティングなどオブジェクトの公開が必要なプロジェクトは無効化して運用する必要があります。

組織ポリシーで設定する場合は、[IAMと管理] -> [組織のポリシー] -> [storage.publicAccessPrevention]を適用することで、公開アクセスの防止の設定を組織配下のすべてのプロジェクトで行うことができます。

組織ポリシーを有効化後に、Cloud Storageの作成操作を行うと、公開アクセスの防止の設定項目の[このバケットに対する公開アクセス禁止を適用する]項目にチェックがついた状態でグレーアウトされており、強制的に公開アクセス禁止を適用させることができています。

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

均一なバケットレベルのアクセスを必須:constraints/storage.uniformBucketLevelAccessの組織ポリシーを適用することで、新規作成するCloud Storageバケットで均一なバケットレベルのアクセス機能の有効化が強制されます。既存のCloud Storageバケットで均一なバケットレベルのアクセス機能が有効化されている場合は、無効化することはできなくなります。

組織ポリシーで設定する場合は、[IAMと管理] -> [組織のポリシー] -> [storage.uniformBucketLevelAccess]を適用することで、均一なバケットレベルのアクセスの設定を組織配下のすべてのプロジェクトで行うことができます。

組織ポリシーを有効化後に、Cloud Storageの作成操作を行うと、アクセス制御の設定項目の[均一]項目にチェックがついた状態でグレーアウトされており、強制的に均一なバケットレベルのアクセスを適用させることができています。

最後に

今回は、Cloud Storageの様々なアクセス制御方法について記載しました。
組織全体でCloud Storageのセキュリティ統制を行っていきたい場合は、積極的に組織ポリシーの利用を行っていきましょう。組織ポリシーを利用することで組織配下のプロジェクトで公開アクセスの防止や均一なバケットレベルのアクセスを強制させることができます。

基本は、公開アクセスの防止や均一なバケットレベルのアクセスなどの組織ポリシー、IAMベースによるシンプルなアクセス制御を利用し、要件によってIPアドレスフィルタリングや、マネージドフォルダによるアクセス制御を検討していくとよいと思います。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部コンサルティング部の渡邉でした！