Cloud Storage の認証

Cloud Storage で実行するほとんどのオペレーションは認証される必要があります。唯一の例外は、匿名アクセスが許可されているオブジェクトに対するオペレーションです。allUsers グループに READ 権限がある場合は、オブジェクトに匿名でアクセスできます。allUsers グループには、インターネット上のすべての人が含まれます。

OAuth 2.0

認証

Cloud Storage は、OAuth 2.0 を使って API の認証と承認を行います。認証とは、クライアントの身元を確認するプロセスを指します。認証の詳細は、Cloud Storage へのアクセス方法によって変わりますが、一般的に以下の 2 種類のいずれかになります。

  • サーバー中心のフローでは、認証を行うためのサービスアカウントの認証情報を、アプリケーションが直接保持します。このフローは、アプリケーションがユーザーデータではなくアプリケーション自体のデータを処理する場合に使用します。Google Cloud Platform プロジェクトでは、デフォルト サービス アカウントを使用するか、新しいサービス アカウントを作成できます。

  • ユーザー中心のフローでは、アプリケーションがエンドユーザーから認証情報を取得できます。ユーザーは、認証を完了するためにログインします。このフローは、アプリケーションがユーザーデータにアクセスする必要がある場合に使用します。ユーザー中心のフローが適しているシナリオについては、このページで後述するユーザー アカウント認証情報のセクションをご覧ください。

1 つのアプリケーションで両方の種類の認証を使用することもできます。認証の詳しい背景情報については、Google Cloud Platform Auth ガイドをご覧ください。

スコープ

承認とは、認証されたユーザーが、指定のリソースに対してどのような権限を持つかを判定するプロセスを指します。OAuth 2.0 では、認証されたユーザーを承認するかどうかを判定するために、スコープを使用します。アプリケーションは認証情報(ユーザー中心の認証フローやサーバー中心の認証フローで取得したもの)と、1 つ以上のスコープを使って、保護されたリソースにアクセスするためのアクセス トークンを Google 承認サーバーに要求します。たとえば、スコープが read-only に設定されたアクセス トークンを持つアプリケーション A にはデータの読み取りのみが許可されますが、スコープが read-write に設定されたアクセス トークンを持つアプリケーション B には、データの読み取りと変更が許可されます。いずれのアプリケーションもオブジェクトとバケットに適用されるアクセス制御リストの読み取りと変更は許可されません。これらの操作を行えるのは、full-control のスコープを持つアプリケーションのみです

種類 説明 スコープの URL
read-only バケットの一覧表示を含め、データを読み取るためのアクセスのみを許可します。 https://www.googleapis.com/auth/devstorage.read_only
read-write データの読み取りと変更を行うためのアクセスは許可しますが、IAM ポリシーなどのメタデータへのアクセスは許可しません。 https://www.googleapis.com/auth/devstorage.read_write
full-control IAM ポリシーの変更を含め、データに対する完全アクセス権を許可します。 https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Google Cloud Platform サービス全体のデータを表示します。Cloud Storage の場合、これは devstorage.read-only と同じです。 https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform すべての Google Cloud Platform サービスにわたるデータを表示して管理します。Cloud Storage の場合、これは devstorage.full-control と同じです。 https://www.googleapis.com/auth/cloud-platform

gsutil 認証

gsutilCloud SDK からインストールした場合、認証にはサービス アカウント認証情報を使用する必要があります。

  1. 既存のサービス アカウントを使用するか、新規サービス アカウントを作成し、必要な秘密鍵をダウンロードします。

  2. gcloud auth activate-service-account を使用して、サービス アカウントで認証を行います。

    gcloud auth activate-service-account --key-file [KEY_FILE]

    [KEY_FILE] は、サービス アカウント認証情報を含むファイルの名前です。

gcloud auth は、アクセス トークンを取得する際に cloud-platform スコープを使用します。

gsutil を Cloud SDK とは別にインストールした場合は、gsutil のインストール ページで、認証方法を確認してください。

クライアント ライブラリの認証

クライアント ライブラリは、アプリケーションのデフォルト認証情報を使うことによって、Google API で簡単に認証を行い、これら API にリクエストを送信することができます。アプリケーションのデフォルト認証情報により、ローカルでアプリケーションのテストを行い、基本となるコードを変更することなくアプリケーションを導入できるようになります。コードのサンプルを含む、詳しい情報は、Google Cloud Platform Auth ガイドをご覧ください。

  • Google Cloud Platform

    App Engine または Compute Engine でアプリケーションを実行している場合は、環境内でサービス アカウントの認証情報がすでに用意されているため、それ以上の設定は必要ありません。Compute Engine の場合、サービス アカウントのスコープは、インスタンスを作成した方法に依存します。インスタンスに対するサービス アカウント アクセスのスコープの設定をご覧ください。App Engine では、cloud-platform スコープが使用されます。

  • その他の環境

    ローカルの開発環境または本番環境を初期化するには、GCP サービス アカウントを作成してサービス アカウントキーをダウンロードし、そのキーを使用するように GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定します。詳しい手順については、Cloud Storage クライアント ライブラリを使用した認証の設定をご覧ください。環境変数を設定する代わりに、サービス アカウント キーを直接コードで使用することもできます。

API の認証

OAuth 2.0 を使って Cloud Storage の XML API または JSON API に対するリクエストを行う場合は、認証が必要なすべてのリクエストの Authorization ヘッダーにアプリケーションのアクセストークンを指定します。アクセス トークンは OAuth 2.0 Playground で生成できます。

Authorization: Bearer <oauth2_token>

以下に、バケット内のオブジェクトを一覧表示するリクエストの例を示します。

JSON API

Objects リソースの list メソッドを使用します。

GET /storage/v1/b/example-bucket/o HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

コマンドラインを使用してリクエストを承認する場合、またはテスト目的でリクエストを承認する場合は、次の構文の curl コマンドを使用できます。

curl -H "Authorization: Bearer ACCESS_TOKEN" "https://www.googleapis.com/storage/v1/b/example-bucket/o"

ローカルテストでは、gcloud auth application-default print-access-token コマンドを使用してトークンを生成できます。

XML API

オブジェクトのリストリクエストを使用します。

GET / HTTP/1.1
Host: example-bucket.storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

コマンドラインを使用してリクエストを承認する場合、またはテスト目的でリクエストを承認する場合は、次の構文の curl コマンドを使用できます。

curl -H "Authorization: Bearer ACCESS_TOKEN" "https://example-bucket.storage.googleapis.com"

ローカルテストでは、gcloud auth application-default print-access-token コマンドを使用してトークンを生成できます。

アクセストークンの管理と更新は複雑な作業であり、暗号アプリケーションを直接扱うとセキュリティ上のリスクがあるため、検証済みのクライアントライブラリを使用することを強くおすすめします。

Amazon S3 との相互運用可能なアクセスのために XML API で使用する HMAC キーが必要な場合は、単純な移行での HMAC キーの管理をご覧ください。

ユーザー アカウント認証情報

認証のためのユーザー アカウント認証情報は、アプリケーションがユーザーの代わりにデータにアクセスする必要がある場合に使用します。それ以外の場合はサービス アカウント認証情報を使用します。以下は、ユーザー アカウント認証情報を使用できるシナリオの例です。

  • ウェブサーバーアプリケーション
  • インストールされたアプリケーションとデスクトップアプリケーション
  • モバイルアプリ
  • クライアント側の JavaScript
  • 入力が限られたデバイス上のアプリケーション

これらのシナリオの詳細については、OAuth 2.0 のシナリオをご覧ください。

エンドユーザー向けに複数の認証オプションをサポートするアプリケーションを設計している場合は、Firebase 認証を使用します。メールとパスワードによる認証に加えて、Google、Facebook、Twitter、GitHub などの ID プロバイダを使用した連携ログインがサポートされています。

ユーザー中心の認証フローで、エンドユーザーによりアクセス トークンが許可されている場合、そのアクセス トークンが持つ権限は、トークンを許可したユーザーが使用できる権限のみです。たとえば、jane@gmail.com に example-bucket に対する read-only アクセスが許可されている場合、Jane から read-write アクセス権が付与されたアプリケーションは、彼女に代わって example-bucket に書き込みを行うことはできません。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。