Amazon S3 から Cloud Storage への移行

このページでは、API を使用してリクエストを送信するユーザーを対象に、Amazon Simple Storage Service(Amazon S3)から Cloud Storage に移行する方法について説明します。現在 Amazon S3 を使用しておらず、Cloud Storage API を使用してリクエストを送信する場合は、XML API の概要をご覧ください。

Cloud Storage を初めて使い、API を直接使用しない場合は、Google Cloud Platform Console で転送の設定と管理を行うことを検討してください。Google Cloud Platform Console には Cloud Storage のためのグラフィカル インターフェースが用意されており、ブラウザを使って多くのストレージ タスクを実行できます。これには Amazon S3 から Cloud Storage にデータを移行するタスクも含まれます。

移行の概要

Amazon S3 ユーザーの場合は、Amazon S3 を使用するアプリケーションを Cloud Storage に簡単に移行できます。次の 2 つの移行オプションがあります。

単純な移行

この方法では Amazon S3 で現在使用しているツールとライブラリにいくつかの単純な変更を加えるだけで済むので、Amazon S3 から移行する場合は最も簡単です。詳しくは、単純な移行をご覧ください。

単純な移行では、Cloud Storage をすぐに使用できますが、Cloud Storage のすべての機能を使用できるわけではありません。Cloud Storage を十分に活用するには、完全な移行の手順を行います。

完全な移行

Amazon S3 から Cloud Storage への完全な移行には、単純な移行の手順に加え多少の作業が発生しますが、サービス アカウントのサポート、複数のプロジェクト、認証用の OAuth 2.0 などの Cloud Storage のすべての機能を使用できるという利点があります。詳しくは、完全な移行をご覧ください。

単純な移行

Amazon S3 から Cloud Storage への単純な移行では、既存のツールとライブラリを使用して、Amazon S3 に対する認証済みの REST リクエストを生成し、さらに認証済みのリクエストを Cloud Storage に送信することもできます。このセクションでは、既存のツールとライブラリに加える必要がある変更について説明します。

単純な移行をセットアップするには、以下の手順を行います。

設定は以上です。この時点で、既存のツールとライブラリの使用を開始し、キー付きのハッシュ メッセージ認証コード(HMAC)リクエストを Cloud Storage に送信できます。

単純な移行のシナリオで Cloud Storage XML API を使用する場合、AWS 署名 ID を Authorization ヘッダーで使用すると、Cloud Storage が x-amz-* ヘッダーと Amazon S3 ACL XML 構文がリクエスト内にあることを予期できます。

デフォルトのプロジェクトの設定

単純な移行のシナリオで Cloud Storage を使用するには、デフォルトのプロジェクトを選択する必要があります。デフォルトのプロジェクトを選択するときには、GET Service や PUT Bucket などのオペレーションで使用するプロジェクトを Cloud Storage に指定します。

デフォルトのプロジェクトを設定するには:

  1. Google Cloud Platform Console[Cloud Storage の設定] ページを開きます
  2. [相互運用性] を選択します。
  3. [プロジェクト ID をデフォルト プロジェクトにする] をクリックします。

    プロジェクトがすでにデフォルトになっている場合は、[プロジェクト ID がデフォルト プロジェクトです] と表示されます。

これで、このプロジェクトがデフォルトのプロジェクトになりました。いつでも別のプロジェクトを選択して相互運用可能なアクセスを有効にすることで、デフォルトのプロジェクトを変更できます。

単純な移行でのデベロッパー キーの管理

単純な移行のシナリオで Cloud Storage XML API を使用するには、キー付きハッシュ メッセージ認証コード(HMAC)認証と Cloud Storage デベロッパー キーを使用する必要があります。デベロッパー キーはアクセスキーとシークレットで構成されます。アクセスキーは 24 文字の英数字からなる文字列で、Google アカウントに関連付けられています。Cloud Storage のすべての認証済みのリクエスト(Cookie ベースの認証を使用するリクエストを除く)でアクセスキーを使用して、リクエストが誰からのものかが Cloud Storage に認識されるようにする必要があります。次にアクセスキーの例を示します。

GOOGTS7C7FUP3AIRVJTE2BCD

シークレットは、40 文字からなる Base-64 でエンコードされた文字列で、特定のアクセスキーに関連付けられています。シークレットは、自分と Cloud Storage システムだけが知っている事前共有鍵です。認証プロセスの中ですべてのリクエストにシークレットを使用して署名する必要があります。シークレットの例を次に示します。

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

デベロッパー キーを生成するには:

  1. Google Cloud Platform Console[Cloud Storage の設定] ページを開きます
  2. [相互運用性] を選択します。
  3. 以前に相互運用性をセットアップしていない場合は、[相互運用アクセスを有効にする] をクリックします。
  4. [新規キーの作成] をクリックします。

デベロッパー キーを操作する場合のセキュリティに関するヒント

最多で 5 つのデベロッパー キーを作成できます。プロジェクトが複数あってプロジェクトごとに別のデベロッパー キーを使用する必要がある場合に便利です。

また、キー管理ツールを使用して、デベロッパー キーの削除や新規作成を行うこともできます。削除や新規作成は、デベロッパー キーを他人に使用されている可能性がある場合や、キーの定期変更(セキュリティの観点から推奨されるベスト プラクティス)を行う場合に行います。デベロッパー キーがすでにいくつかある場合に新たに作成するには、古いキーを削除する前に新しいデベロッパー キーをコードに反映しておくことをおすすめします。デベロッパー キーを削除すると、キーはすぐに無効となり、元に戻すことはできません。

単純な移行のシナリオでの認証

認証ヘッダー

認証が必要な単純な移行のシナリオのオペレーションでは、Amazon S3 にリクエストを送信するときと同じように、Authorization リクエスト ヘッダーを含めます。Amazon S3 リクエストの Authorization ヘッダーの構文は次のとおりです。

Authorization: AWS AWS-ACCESS-KEY:signature

単純な移行のシナリオでは、Google デベロッパー アクセスキーを使用するようにヘッダーを変更するだけです。

Authorization: AWS GOOG-ACCESS-KEY:signature

Authorization ヘッダーの部分は次のようになります。

署名 ID
署名 ID は、使用している署名アルゴリズムとバージョンを識別します。AWS の使用は、x-amz-* ヘッダーを送信しようとしていることを意味します。
アクセスキー
アクセスキーはリクエストを作成して署名するエンティティを識別します。単純な移行では、Amazon S3 にアクセスするために使用する Amazon Web Service(AWS)アクセスキー ID を Google デベロッパー アクセスキーに置き換えます。Google デベロッパー アクセスキーは先頭に「GOOG」が付きます。
署名

署名はさまざまなリクエスト ヘッダーのキー付き暗号学的ハッシュから成っています。署名は HMAC-SHA1 をハッシュ関数として、シークレットを暗号鍵として使用して作成されます。その結果のダイジェストは Base64 でエンコードされます。Cloud Storage が署名付きのリクエストを受信した場合、アクセスキーを使用してシークレット検索し、署名の作成者であることを確認します。アクセスキーと秘密鍵を取得する方法について詳しくは、単純な移行でのデベロッパー キーの管理をご覧ください。

単純な移行では、暗号鍵としての AWS シークレット アクセスキーを Google デベロッパー キー シークレットに置き換えます。

認証の計算

このセクションでは、単純な移行のシナリオでの XML API 認証のプロセスについて説明します。このセクションを使用して、リクエストに署名するための独自のコードを開発できますが、主な目的は、Amazon S3 へのリクエストに署名するためのツールまたはライブラリをすでに持っているかどうかを確認することです。このケースでは、これらのツールを引き続き使用し、XML API を使用して Cloud Storage にアクセスしますが、ここに示す変更を加えます。

この認証方法では、シークレットを開示せずに識別と強固な認証を行うことができます。すべてのリクエストに識別と認証を与えることで、各 Cloud Storage リクエストが特定のユーザー アカウントの下、そのユーザー アカウントの権限で処理されることが保証されます。この方法はユーザーのシークレットを知っているのがユーザー本人と Cloud Storage システムに限定されていることにより、可能となっています。リクエストを行うと、Cloud Storage システムはユーザーのシークレットを使って、リクエストを行う際にユーザーが算出した署名と同じ署名を算出します。署名が一致すると、Cloud Storage システムは、このユーザーがリクエストを行うことができる唯一の人物であると認識します。

次の擬似コードは Authorization ヘッダー用の署名の作成方法を示しています。

Signature = Base64-Encoding-Of(HMAC-SHA1(YourGoogleStorageSecretKey, MessageToBeSigned))

署名を作成するには、HMAC-SHA1 という暗号学的ハッシュ関数を使用します。HMAC-SHA1 はハッシュベースのメッセージ認証コード(MAC)で、RFC 2104 に記載されています。これには UTF-8 エンコードされた 2 つの入力パラメータ、キーとメッセージが必要です。キーは自分の Cloud Storage シークレットで、メッセージは特定の HTTP ヘッダーを特定の順番で結合して構成する必要があります。次の擬似コードは、メッセージの構成方法を示しています。

MessageToBeSigned = UTF-8-Encoding-Of(CanonicalHeaders + CanonicalExtensionHeaders + CanonicalResource)

メッセージを構成する正則エンティティはそれぞれ、さまざまなヘッダーやリソースを厳密な順番で厳密にフォーマットして結合したものを表します。この後のセクションでは、これらのエンティティの作成方法を説明します。

CanonicalHeaders

MessageToBeSignedCanonicalHeaders 部分は、さまざまなヘッダーの値を結合させて構成しますが、各ヘッダー値の後には改行(U+000A)を追加します。次の擬似コードは、この構成方法を示します(改行は \n で表されています)

CanonicalHeaders = HTTP-Verb + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n"

結合文字列にはヘッダー名を含めないでください。含めるのはヘッダー値だけです。必須のヘッダーがリクエスト内にない場合、ヘッダー値に空の文字列を代入し、その後に必ず改行を追加してください。また、Date ヘッダーは認証が必要なすべてのリクエストに必須なので、このフィールドには有効な日付と時刻のスタンプを挿入する必要があります。日付と時刻のスタンプは Cloud Storage がリクエストを受信してから 15 分以内に行う必要があります。

x-amz-date または x-goog-date 拡張ヘッダーを使用して日付と時刻のスタンプを指定できます。日付拡張ヘッダーを使用すると、Cloud Storage はリクエスト内の Date ヘッダーを無視します。この場合、Date ヘッダーに空の文字列を代入してください。

CanonicalExtensionHeaders

メッセージの CanonicalExtensionHeaders 部分を作成するには、x-amz- または x-goog- で始まるすべての拡張(カスタム)ヘッダーを結合します。ただし、そのまま結合するのではなく、次の手順でヘッダーを結合することが必要です。

  1. カスタム ヘッダーの名前をすべて小文字にします。
  2. すべてのカスタム ヘッダーを、ヘッダー名の辞書式順序で並べ替えます。
  3. 重複したヘッダー名は、値をコンマで区切ってリストすることで 1 つのヘッダー名にします。値と値の間に空白文字がなく、コンマで区切られた値の順番がリクエストに表示されるヘッダーの順番と同じであることを確認してください。詳しい情報は、RFC 7230 のセクション 3.2 をご覧ください。
  4. 折りたたみ空白文字や改行(CRLF または LF)はすべて単一の空白文字に置き換えます。折りたたみ空白文字について詳しくは、RFC 2822 のセクション 2.2.3 をご覧ください。
  5. ヘッダー名の後のコロンの前後に空白文字があれば削除します。
  6. 各カスタム ヘッダーに改行(U+000A)を追加します。
  7. すべてのカスタム ヘッダーを結合します。

メッセージの CanonicalExtensionHeaders 部分を結合する際に、ヘッダー名とヘッダー値の両方を使用することに留意してください。これは、ヘッダー値しか使用しない、CanonicalHeaders 部分との相違点です。

CanonicalResource

メッセージの CanonicalResource 部分は、リクエストの対象であるリソースパス(バケット、オブジェクト、サブリソース)を結合することで構成します。この構成を行うには、次の手順を行います。

  1. 空の文字列で始めます。
  2. バケット名が Host ヘッダーに表示される場合は、スラッシュ(/)とバケット名を文字列に追加します(例: /travel-maps)。バケット名が HTTP リクエストのパス部分に表示される場合は、何もしません。
  3. 文字列に、HTTP リクエストのパス部分を追加します。ただし、クエリ文字列パラメータは除きます。たとえばパスが /europe/france/paris.jpg?acl で、すでにバケットの travel-maps を文字列に追加済みの場合、/europe/france/paris.jpg を文字列に追加する必要があります。
  4. リクエストが ?acl のようにサブリソースに範囲指定されている場合は、このサブリソースを疑問符(?)も含めて文字列に追加します。

HTTP リクエストパスを文字どおりにコピーし、すべての URL エンコード(パーセント記号)を作成する文字列に含める必要があります。サブリソースを指定するクエリ文字列(acl など)のみ含めるようにします。?prefix?max-keys?marker?delimiter などのクエリ文字列パラメータは含めないでください。

以下に、さまざまな種類のリクエストの署名メッセージの例を示します。

サンプルの認証リクエスト

次の例では、/europe/france/paris.jpg というオブジェクトを my-travel-maps というバケットにアップロードし、定義済み ACL public-read を適用して、レビューア用にカスタム メタデータ ヘッダーを定義します。Amazon S3 のバケットに対するリクエストを次に示します。

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Tue, 05 Nov 2013 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-meta-reviewer: joe,jane
Authorization: AWS AWS-ACCESS-KEY:Signature

Cloud Storage のバケットを次に示します。

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Tue, 05 Nov 2013 23:47:01 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-meta-reviewer: joe,jane
Authorization: AWS GOOG-ACCESS-KEY:Signature

Cloud Storage リクエスト MessageToBeSigned 用に署名される対応するメッセージを次に示します。

PUT\n
\n
image/jpg\n
Tue, 05 Nov 2013 23:47:01 GMT\n
x-amz-acl:public-read\n
x-amz-meta-reviewer:joe,jane\n
/my-travel-maps/europe/france/paris.jpg

このリクエストは、Content-MD5 ヘッダーを提供しなかったので、メッセージに空白の文字列が表示されます(2 行目)。

単純な移行のシナリオでのアクセス制御

単純な移行をサポートするために、Cloud Storage は Amazon S3 によって生成される ACL を受け入れます。単純な移行のシナリオでは、AWS を署名 ID として使用することで、Amazon S3 ACL XML 構文を使用して ACL 構文を除外するように Cloud Storage に指示します。使用する Amazon S3 ACL が Cloud Storage ACL モデルにマッピングされることを確認する必要があります。たとえば、ツールやライブラリが、Amazon S3 の ACL 構文を使用してバケットの WRITE 権限を付与する場合、バケットの READ 権限も付与する必要があります。Cloud Storage の権限は同心構造だからです。Cloud Storage 構文を使用して WRITE 権限を付与するときには、WRITEREAD の両方の権限を指定する必要はありません。

Cloud Storage は、次のシナリオで Amazon S3 ACL 構文をサポートします。

  • Cloud Storage に対して ACL を取得させるリクエスト(GET Object や GET Bucket リクエストなど)で、Cloud Storage は Amazon S3 ACL 構文を返します。
  • Cloud Storage に対して ACL を適用させるリクエスト(PUT Object や PUT Bucket リクエストなど)で、Cloud Storage は Amazon S3 ACL 構文を受け取ることを予期します。

単純な移行のシナリオの Authorization ヘッダーは、署名 ID として AWS を使用しますが、Google アクセスキーを使用します。

Authorization: AWS GOOG-ACCESS-KEY:signature

次の例は、オブジェクトの ACL を返す Cloud Storage に対する GET リクエストを示しています。

GET europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 07 Nov 2013 01:04:05 GMT
Content-Type: application/xml
Authorization: AWS GOOG-ACCESS-KEY:Sku4/Nc1q4yJ6+7q7Sk3PFAAelE=

リクエストのレスポンスには、Amazon S3 ACL 構文を使用する ACL が含まれています。

<?xml version='1.0' encoding='UTF-8'?>
<AccessControlPolicy>
    <Owner>
        <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490
        </ID>
        <DisplayName>OwnerName</DisplayName>
    </Owner>
    <AccessControlList>
        <Grant>
            <Grantee xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
                xsi:type='CanonicalUser'>
                <ID>00b4903a972faa8bcce9382686e9129676f1cd6e5def1f5663affc2ba4652490</ID>
                <DisplayName>UserName</DisplayName>
            </Grantee>
            <Permission>FULL_CONTROL</Permission>
        </Grant>
    </AccessControlList>
</AccessControlPolicy>

次の例は、オブジェクトの ACL を設定する Cloud Storage に対する PUT リクエストを示しています。次の例は、Amazon S3 ACL 構文を使用するリクエストの本文を示しています。

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 07 Nov 2013 01:55:16 GMT
Content-Type: application/xml
Content-Length: 337
Authorization: AWS GOOG-ACCESS-KEY:Ugm1lh6Bb+nAfNVa5ljUgfXYMfQ=

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AmazonCustomerByEmail">
        <EmailAddress>jane@gmail.com</EmailAddress>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

なお、単純な移行のシナリオでは、Authorization ヘッダーで GOOG1 署名 ID を使用することもできます。この場合、Cloud Storage ACL 構文を使用し、すべてのヘッダーが Google ヘッダーの x-goog-* であることを確認する必要があります。以上の方法も可能ですが、Cloud Storage のすべての利点を実現するためには、次の説明に従って完全な移行を行うようおすすめします。

完全な移行

Amazon S3 から Cloud Storage に完全に移行すると、以下に挙げる Cloud Storage のすべての機能を利用できます。

サービス アカウントのサポート
サービス アカウントは、エンドユーザーの関与を必要としないサーバー間の相互作用のために役に立ちます。詳しくは、サービス アカウントをご覧ください。
複数のプロジェクトのサポート
複数のプロジェクトを使用すると、Cloud Storage サービスの多くのインスタンスを実際に使用できます。これにより、アプリケーションまたはビジネスの異なる機能またはサービスを必要に応じて分割できます。詳しくは、プロジェクトの使用をご覧ください。
OAuth 2.0 認証
OAuth 2.0 は、アプリケーションに直接暗号化の実行を要求する代わりに SSL を利用してセキュリティを実装できる、より容易な方法です。OAuth では、アプリケーションがユーザーの Google アカウントに関連付けられているデータへのアクセスを要求することが可能であり、読み取り専用、読み取り書き込み、フル コントロールなどのいくつかのレベルにアクセス範囲を設定できます。詳しくは、OAuth 2.0 認証をご覧ください。

Amazon S3 から Cloud Storage に完全に移行するには、次の変更を行う必要があります。

  • 既存の x-amz-* ヘッダーを対応する x-goog-* ヘッダーに変更します。
  • AWS アクセス制御リスト Access (ACL)XML を対応する Cloud Storage ACL XML に変更します(バケット ACL とオブジェクト ACL の指定をご覧ください)。
  • リクエスト内の x-goog-project-id ヘッダーを設定します。単純な移行のシナリオでは、すべてのリクエストでデフォルトのプロジェクトを選択します。これは完全な移行では必要ありません。
  • OAuth 2.0 認証の説明に従って、OAuth 2.0 を使用できるように設定します。最初にアプリケーション(リクエストの発行元)を Google に登録します。OAuth 2.0 を使用すると、Authorization ヘッダーが次のように表示されます。

    Authorization: Bearer <oauth2_token>

完全な移行でのアクセス制御

このセクションでは、Amazon S3 から Cloud Storage への移行に役立ついくつかのアクセス制御の例を紹介します。Cloud Storage でのアクセス制御の概要については、アクセス制御をご覧ください。

Cloud Storage では、バケットやオブジェクトに ACL を適用するための方法がいくつかあります(バケット ACL とオブジェクト ACL の指定をご覧ください)。ACL を指定する方法のうち 2 つは、Amazon S3 の方法と似ています。

  • 特定の範囲の ACL を適用するための acl クエリ文字列パラメータ。
  • x-goog-acl リクエスト ヘッダーを使用すると、定義済み ACL とも呼ばれる定義済み ACL を適用できます。

acl クエリ文字列パラメータの使用

Cloud Storage リクエストの acl 文字列パラメータは、Amazon S3 で使用する場合とまったく同じ方法で使用できます。acl パラメータを PUT メソッドと組み合わせて使用し、ACL を既存のオブジェクト、既存のバケット、作成中のバケットに適用します。PUT リクエストで acl クエリ文字列パラメータを使用する場合は、Cloud Storage ACL 構文を使用して、リクエストの本文に XML ドキュメントを添付する必要があります。この XML ドキュメントに、バケットまたはオブジェクトに適用する個別の ACL エントリを記述します。

次の例は、acl クエリ文字列パラメータを使用する Amazon S3 に対する PUT リクエストを示しています。ACL は、リクエストの本文で送信される XML ドキュメント内に定義されます。この PUT リクエストは my-travel-maps というバケット内にある europe/france/paris.jpg というオブジェクトの ACL を変更します。この ACL は jane@gmail.com に FULL_CONTROL 権限を付与します。

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 19:28:18 GMT
Content-Length: 598
Content-Type: application/xml
Authorization: AWS AWS-ACCESS-KEY:eNB6IUnqzsVAZ69TZZ5yFMQ5SvE=

<?xml version='1.0' encoding='utf-8'?>
<AccessControlPolicy>
  <Owner>
    <ID>5a6557ba40f7c86496ffceae789fcd888abc1b62a7149873a0fe12c0f60a7d95</ID>
    <DisplayName>ownerEmail@example.com</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>fd447671d60b979f78ee6fcec7b22afc80e6b26a4db16eed01afb8064047949b</ID>
        <DisplayName>jane@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

次に、Cloud Storage に対する同じリクエストを示します。

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 19:37:33 GMT
Content-Length: 268
Content-Type: application/xml
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<?xml version='1.0' encoding='utf-8'?>
<AccessControlList>
  <Entries>
  <Entry>
    <Permission>FULL_CONTROL</Permission>
    <Scope type="UserByEmail">
      <EmailAddress>jane@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

Cloud Storage では、ACL XML ドキュメント内に <Owner/> 要素は必要ありません。詳しくは、デフォルト オブジェクト ACL をご覧ください。

また、GET メソッドで acl クエリ文字列パラメータを使用して、バケットやオブジェクトの ACL を取得することもできます。ACL は、レスポンスの本文に添付された XML ドキュメントに記載されます。オブジェクトまたはバケットの ACL を適用したり取得したりするには、FULL_CONTROL 権限が必要です。

拡張リクエスト ヘッダーを使用した ACL の適用

Cloud Storage リクエストで x-goog-acl ヘッダーを使用すると、Amazon S3 リクエストで x-amz-acl ヘッダーを使用する場合とまったく同じ方法で事前に定義された ACL をバケットやオブジェクトに適用できます。通常は、バケットやオブジェクトの作成時またはアップロード時に x-goog-aclx-amz-acl)ヘッダーを使用して、定義済み ACL を適用します。Cloud Storage の定義済み ACL は、Amazon S3 Canned ACL と同様、private、public-read、public-read-write などを含んでいます。Cloud Storage の定義済み ACL のリストについては、定義済み ACL をご覧ください。

次の例は、europe/france/paris.jpg という名前のオブジェクトに public-read ACL を適用する PUT Object リクエストを示しています。このオブジェクトは、Amazon S3 では my-travel-maps という名前のバケットにアップロードされています。

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Wed, 06 Nov 2013 20:48:42 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
Authorization: AWS AWS-ACCESS-KEY:o8PRLyrTxsMEznHzgQvTt2TnWTI=

<888814 bytes in entity body>

次に、Cloud Storage に対する同じリクエストを示します。

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 20:49:57 GMT
Content-Length: 888814
Content-Type: image/jpg
x-goog-acl: public-read
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<888814 bytes in entity body>

また、x-goog-acl ヘッダーを使用して既存のバケットやオブジェクトに定義済み ACL を適用することもできます。これを行うには、リクエストに acl クエリ文字列パラメータを使用しますが、その際 XML ドキュメントは含めません。定義済み ACL を別のものに変更したい場合や、カスタム ACL を定義済み ACL に更新したい場合は、既存のオブジェクトやバケットに定義済み ACL を適用すると便利です。たとえば、次の PUT Object リクエストは、定義済み ACL privatemy-travel-maps というバケット内の europe/france/paris.jpg というオブジェクトに適用します。

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Wed, 06 Nov 2013 00:26:36 GMT
Content-Length: 0
x-goog-acl: private
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

<empty entity body>

ACL の管理については、アクセス制御の管理をご覧ください。

Amazon S3 から Cloud Storage リクエスト メソッドへの移行

Cloud Storage では、バケットのデータの読み取りと書き込みのために、Amazon S3 でサポートされるメソッドと同じ標準の HTTP リクエスト メソッドがサポートされています。そのため、Amazon S3 で使用中のツールとライブラリの多くは Cloud Storage で同様に使用できます。Cloud Storage では、次のリクエスト メソッドがサポートされています。

  • GET のサービス リクエスト。
  • PUT、GET、DELETE を含むバケット リクエスト。
  • GET、POST、PUT、HEAD、DELETE を含むオブジェクト リクエスト。

詳しくは、XML API リファレンス メソッドをご覧ください。Cloud Storage にリクエストを送信するときには、必要に応じて適切な Cloud Storage 構文を使用するよう、リクエストの本文を変更する必要があります。たとえば、バケットのライフサイクル構成を作成するときには、Cloud Storage ライフサイクル XML を使用します。これは、Amazon S3 ライフサイクル XML とは異なります。

Cloud Storage XML API と Amazon S3 で異なる点と、推奨される Cloud Storage による代替手段については以下をご覧ください。

Amazon S3 の機能 Cloud Storage XML API の機能
マルチパート アップロード。
POST /<object-name>、 PUT /<object-name>

Cloud Storage XML API では、一連のコンポーネント オブジェクトをアップロードし、各コンポーネントの個別のアップロードを実行できます。これらは、オブジェクトを合成して 1 つのオブジェクトにできます。

注: JSON API にはマルチパート アップロード機能がありますが、この機能は、オブジェクト データとともにメタデータを送信するために使用するものです。S3 のマルチパート アップロード機能とは異なります。

GET/POST バケットクエリ文字列パラメータ:
  • 「policy」 - Amazon S3 バケット ポリシーを操作します。
  • 「website」 - バケット ウェブサイトを構成します。
  • 「tagging」 - コスト アプリケーションを目的としてバケットにタグ付けします。
  • 「notification」 - バケット イベントを通知します。
  • 「requestPayment」 - リクエストとバケットからのデータ ダウンロードのコストの負担元を設定します。
代替:
  • 「policy」 - Cloud Storage ACL、プロジェクト チーム メンバーシップ、複数のプロジェクトを使用できる機能は、バケット ポリシーが使用される多くのシナリオを解決します。
  • 「website」 - gsutil web コマンドを使用してウェブサイトを管理するか、JSON API を試してください(buckets リソースをご覧ください)。
  • 「tagging」 - 複数のプロジェクトを使用して、異なる複数のコストセンターをトラックします。プロジェクトについて詳しくは、プロジェクトの管理をご覧ください。
  • 「notification」 - gsutil または JSON API Cloud Pub/Sub Notifications を使用します。
  • 「requestPayment」 - 異なる課金プロファイルの複数のプロジェクト使用してリクエストとバケットからダウンロードされたデータコストの負担元を管理します。お支払いの設定について詳しくは、Google API コンソールのヘルプ ドキュメントのお支払いについての記事をご覧ください。
複数のオブジェクトの削除。
POST /?delete

gsutil rm コマンドを使用して、複数のオブジェクトを簡単に削除できます。rm コマンドは並列削除(マルチスレッドやマルチ処理)を実行するための「-m」オプションをサポートします。

または、JSON API は、バッチ リクエストの送信をサポートし、クライアントが行う HTTP 接続の数を減らすことができます。

Amazon S3 から Cloud Storage ヘッダーへの移行

Cloud Storage は、複数の標準の HTTP ヘッダーに加えて、カスタム(拡張)HTTP ヘッダーを使用します。Amazon S3 から Cloud Storage に移行する場合は、カスタム Amazon S3 ヘッダーを、下の表に示す同等の Cloud Storage カスタム ヘッダーまたは類似の機能に変換できます。

Amazon S3 ヘッダー Cloud Storage ヘッダー
x-amz-acl x-goog-acl
x-amz-date x-goog-date
x-amz-meta-* x-goog-meta-*
x-amz-grant-* x-goog-acl と定義済みの ACL 値。
x-amz-copy-source x-goog-copy-source
x-amz-metadata-directive x-goog-metadata-directive
x-amz-copy-source-if-match x-goog-copy-source-if-match
x-amz-copy-source-if-none-match x-goog-copy-source-if-none-match
x-amz-copy-source-if-unmodified-since x-goog-copy-source-if-unmodified-since
x-amz-copy-source-if-modified-since x-goog-copy-source-if-modified-since
x-amz-server-side-encryption 不要。Cloud Storage は、ディスクに書き込まれる前に、すべてのデータを自動的に暗号化します。詳しくは、暗号化をご覧ください。
x-amz-storage-class バケットを作成するときにストレージ クラスを指定できます。詳しくは、ストレージ クラスをご覧ください。
x-amz-mfa OAuth 2.0 認証を使用します。
x-amz-website-redirect-locationx-amz-copy-source-range 該当なし

Amazon S3 と XML API の互換性に関するディスカッション グループとサポート

以前に XML API 相互運用性と移行の問題をサポートしていた Cloud Storage gs-discussion グループは、アーカイブ モードになっています。このディスカッション グループは現在、タグ google-cloud-storage を使用して、Stack Overflow でアクセスできます。ディスカッション フォーラムとお知らせの受け取り登録について詳しくは、リソースとサポートページをご覧ください。

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

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

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