Von Amazon S3 zu Cloud Storage migrieren

Auf dieser Seite wird beschrieben, wie Nutzer, die Anfragen über eine API senden, von Amazon Simple Storage Service (Amazon S3) zu Cloud Storage migrieren.

Wenn Sie neu bei Cloud Storage sind und die API nicht direkt nutzen, ziehen Sie die Verwendung der Google Cloud Platform Console zum Einrichten und Verwalten von Übertragungen in Betracht. Die Google Cloud Platform Console bietet eine grafische Benutzeroberfläche für Cloud Storage, die es Ihnen ermöglicht, viele Ihrer Speicheraufgaben komplett im Browser auszuführen. Dazu zählt auch die Migration Ihrer Daten von Amazon S3 zu Cloud Storage.

Übersicht über die Migration

Als Nutzer von Amazon S3 können Sie Anwendungen, die Amazon S3 verwenden, problemlos zu Cloud Storage migrieren. Für die Migration haben Sie zwei Optionen:

  • Einfache Migration: Dies ist die einfachste Möglichkeit für einen Umstieg auf Cloud Storage, wenn Sie bisher Amazon S3 verwendet haben. Bei den Tools und Bibliotheken, die Sie aktuell mit Amazon S3 verwenden, sind nur einige wenige einfache Änderungen erforderlich.

  • Vollständige Migration: Eine vollständige Migration von Amazon S3 zu Cloud Storage erfordert im Vergleich zur einfachen Migration einige zusätzliche Schritte. Der Vorteil ist jedoch, dass Sie alle Features von Cloud Storage nutzen können, einschließlich der Unterstützung von Dienstkonten, mehreren Projekten und OAuth 2.0 für die Authentifizierung.

Einfache Migration

Bei einer einfachen Migration von Amazon S3 zu Cloud Storage können Sie Ihre vorhandenen Tools und Bibliotheken verwenden, um authentifizierte REST-Anfragen an Amazon S3 zu richten und auch authentifizierte Anfragen an Cloud Storage zu senden. So senden Sie Anfragen an Cloud Storage:

  • Legen Sie ein Standard-Google-Projekt fest.
  • Rufen Sie einen HMAC-Schlüssel ab.
  • Nehmen Sie in Ihren vorhandenen Tools oder Bibliotheken folgende Änderungen vor:

    • Ändern Sie den Anfrageendpunkt so, dass der Cloud Storage XML API-Anfrageendpunkt verwendet wird.
    • Ersetzen Sie den Zugriffsschlüssel und den geheimen Schlüssel von Amazon Web Services (AWS) durch den entsprechenden Zugriffsschlüssel und den geheimen Schlüssel von Cloud Storage (zusammen Ihr Cloud Storage-HMAC-Schlüssel).

Mit diesen Änderungen können Sie Ihre vorhandenen Tools und Bibliotheken verwenden, um Anfragen mit Keyed-Hash Message Authentication Code (HMAC) an Cloud Storage zu senden.

In den folgenden Beispielen wird gezeigt, wie Sie Cloud Storage-Buckets mit dem Amazon S3 SDK auflisten:

Java

Weitere Informationen finden Sie in der Referenzdokumentation zur Cloud Storage Java API.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.Bucket;

import java.util.List;

public class ListGcsBuckets {
  public static void listGcsBuckets(String googleAccessKeyId,
      String googleAccessKeySecret) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds = new BasicAWSCredentials(googleAccessKeyId,
        googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient = AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current buckets
    List<Bucket> buckets = interopClient.listBuckets();

    // Print bucket names
    System.out.println("Buckets:");
    for (Bucket bucket : buckets) {
      System.out.println(bucket.getName());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }

Python

Weitere Informationen finden Sie in der Referenzdokumentation zur Cloud Storage Python API.

import boto3

def list_gcs_buckets(google_access_key_id, google_access_key_secret):
    """Lists all GCS buckets using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.
    client = boto3.client("s3", region_name="auto",
                          endpoint_url="https://storage.googleapis.com",
                          aws_access_key_id=google_access_key_id,
                          aws_secret_access_key=google_access_key_secret)

    # Call GCS to list current buckets
    response = client.list_buckets()

    # Print bucket names
    print("Buckets:")
    for bucket in response["Buckets"]:
        print(bucket["Name"])

Obwohl die meisten Aktionen mit dem Amazon S3 V2 SDK zur Verfügung stehen, können Objekte nur mit der Amazon S3 V1-Methode aufgelistet werden. In den folgenden Beispielen wird eine solche Objektauflistung gezeigt:

Java

Weitere Informationen finden Sie in der Referenzdokumentation zur Cloud Storage Java API.

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;

import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;
import com.amazonaws.services.s3.model.ObjectListing;
import com.amazonaws.services.s3.model.S3ObjectSummary;

import java.util.List;

public class ListGcsObjects {
  public static void listGcsObjects(String googleAccessKeyId,
      String googleAccessKeySecret, String bucketName) {

    // String googleAccessKeyId = "your-google-access-key-id";
    // String googleAccessKeySecret = "your-google-access-key-secret";
    // String bucketName = "bucket-name";

    // Create a BasicAWSCredentials using Cloud Storage HMAC credentials.
    BasicAWSCredentials googleCreds = new BasicAWSCredentials(googleAccessKeyId,
        googleAccessKeySecret);

    // Create a new client and do the following:
    // 1. Change the endpoint URL to use the Google Cloud Storage XML API endpoint.
    // 2. Use Cloud Storage HMAC Credentials.
    AmazonS3 interopClient = AmazonS3ClientBuilder.standard()
            .withEndpointConfiguration(
                new AwsClientBuilder.EndpointConfiguration(
                    "https://storage.googleapis.com", "auto"))
            .withCredentials(new AWSStaticCredentialsProvider(googleCreds))
            .build();

    // Call GCS to list current objects
    ObjectListing objects = interopClient.listObjects(bucketName);

    // Print objects names
    System.out.println("Objects:");
    for (S3ObjectSummary object : objects.getObjectSummaries()) {
      System.out.println(object.getKey());
    }

    // Explicitly clean up client resources.
    interopClient.shutdown();
  }
}

Python

Weitere Informationen finden Sie in der Referenzdokumentation zur Cloud Storage Python API.

import boto3

def list_gcs_objects(google_access_key_id, google_access_key_secret,
                     bucket_name):
    """Lists GCS objects using boto3 SDK"""
    # Create a new client and do the following:
    # 1. Change the endpoint URL to use the
    #    Google Cloud Storage XML API endpoint.
    # 2. Use Cloud Storage HMAC Credentials.

    client = boto3.client("s3", region_name="auto",
                          endpoint_url="https://storage.googleapis.com",
                          aws_access_key_id=google_access_key_id,
                          aws_secret_access_key=google_access_key_secret)

    # Call GCS to list objects in bucket_name
    response = client.list_objects(Bucket=bucket_name)

    # Print object names
    print("Objects:")
    for blob in response["Contents"]:
        print(blob["Key"])

Wenn Sie bei einem einfachen Migrationsszenario die Cloud Storage XML API verwenden, führt die Angabe des Signaturbezeichners AWS im Header Authorization dazu, dass Cloud Storage in Ihrer Anfrage Header des Typs x-amz-* und die ACL-XML-Syntax von Amazon S3 erwartet.

Standardprojekt festlegen

Zur Verwendung von Cloud Storage in einem einfachen Migrationsszenario müssen Sie ein Standardprojekt auswählen. Mit der Auswahl eines Standardprojekts legen Sie fest, welches Projekt von Cloud Storage bei Vorgängen wie einer GET-Anfrage für einen Dienst oder einer PUT-Anfrage für einen Bucket verwendet werden soll.

So legen Sie ein Standardprojekt fest:

  1. Öffnen Sie die Seite mit den Cloud Storage-Einstellungen in der Google Cloud Platform Console.
  2. Wählen Sie die Option Interoperabilität aus.
  3. Klicken Sie auf PROJEKT-ID als Standardprojekt festlegen.

    Wenn das Projekt bereits als Standardprojekt festgelegt wurde, erhalten Sie die Meldung PROJEKT-ID ist Ihr Standardprojekt für interoperablen Zugriff.

Dieses Projekt ist jetzt Ihr Standardprojekt. Sie können Ihr Standardprojekt jederzeit ändern. Dazu wählen Sie ein anderes Projekt aus und führen die folgenden Schritte aus.

HMAC-Schlüssel für eine einfache Migration verwalten

Zur Verwendung der Cloud Storage XML API in einem einfachen Migrationsszenario verwenden Sie für Ihre Anmeldedaten HMAC-Schlüssel (Hash-based Message Authentication Code). HMAC-Schlüssel bestehen aus einem Zugriffsschlüssel und einem Secret. Ein Zugriffsschlüssel ist ein 24-stelliger alphanumerischer String, der mit Ihrem Google-Konto verknüpft ist. Alle authentifizierten Cloud Storage-Anfragen, die keine Authentifizierung auf Basis von Cookies verwenden, müssen in der Anfrage einen Zugriffsschlüssel enthalten, sodass das Cloud Storage-System erkennt, von wem die Anfrage stammt. Hier ein Beispiel für einen Zugriffsschlüssel:

GOOGTS7C7FUP3AIRVJTE2BCD

Ein Secret ist ein 40 Zeichen langer String mit Base-64-Verschlüsselung, der mit einem bestimmten Zugriffsschlüssel verknüpft ist. Ein Secret ist ein gemeinsamer geheimer Schlüssel, der nur Ihnen und dem Cloud Storage-System bekannt ist. Sie verwenden Ihr Secret als Teil des Authentifizierungsprozesses zur Signierung aller Anfragen. Hier ein Beispiel für ein Secret:

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

So generieren Sie einen HMAC-Schlüssel:

  1. Öffnen Sie die Seite mit den Cloud Storage-Einstellungen in der Google Cloud Platform Console.
  2. Wählen Sie die Option Interoperabilität aus.
  3. Wenn Sie die Interoperabilität zuvor noch nicht eingerichtet haben, klicken Sie auf Interoperablen Zugriff aktivieren.
  4. Klicken Sie auf Neuen Schlüssel erstellen.

Sicherheitstipps für die Arbeit mit HMAC-Schlüsseln

  • Sie können mehrere HMAC-Schlüssel erstellen. Dies ist nützlich, wenn Sie an verschiedenen Projekten arbeiten und für jedes Projekt unterschiedliche HMAC-Schlüssel verwenden möchten.

  • Ihre HMAC-Schlüssel dürfen von keinem anderen Nutzer verwendet werden. Die Schlüssel sind mit Ihrem Google-Konto verknüpft und Sie sollten damit so wie mit allen anderen Arten von Anmeldedaten umgehen.

  • Als bewährte Sicherheitsmethode sollten Sie Ihre Schlüssel im Rahmen einer Schlüsselrotation regelmäßig ändern.

  • Wenn Sie den Verdacht haben, dass eine andere Person Ihre HMAC-Schlüssel verwendet, sollten Sie die betroffenen HMAC-Schlüssel sofort löschen und neue erstellen.

  • Wenn Sie HMAC-Schlüssel ändern, sollten Sie Ihren Code mit den neuen HMAC-Schlüsseln aktualisieren, bevor Sie die alten Schlüssel löschen. Wenn Sie HMAC-Schlüssel löschen, werden diese sofort ungültig und können nicht wiederhergestellt werden.

Authentifizierung in einem einfachen Migrationsszenario

Autorisierungsheader

Für Prozesse im Rahmen eines einfachen Migrationsszenarios, die eine Authentifizierung erfordern, fügen Sie genau wie bei Anfragen an Amazon S3 einen Authorization-Anfrageheader ein. Die Syntax des Authorization-Headers sieht bei einer Amazon S3-Anfrage so aus:

Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

In einem einfachen Migrationsszenario ändern Sie nur den Header, damit Ihr Google-HMAC-Zugriffsschlüssel verwendet wird, und sorgen dafür, dass die angefügte Signature mit Ihrem geheimen Google-HMAC-Schlüssel berechnet wird:

Authorization: ALGORITHM Credential=GOOG-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

Der Header Authorization umfasst folgende Bestandteile:

  • ALGORITHM: Der Signaturalgorithmus und die Version, die Sie verwenden. Die Verwendung von AWS4-HMAC-SHA256 zeigt an, dass Sie eine HMAC V4-Signatur verwenden und vorhaben, Header vom Typ x-amz-* zu senden. Der Wert GOOG4-HMAC-SHA256 zeigt an, dass Sie eine HMAC V4-Signatur verwenden und vorhaben, Header vom Typ x-goog-* zu senden.

  • GOOG-ACCESS-KEY: Der Zugriffsschlüssel kennzeichnet die Entität, die die Anfrage stellt und signiert. Bei einer einfachen Migration ersetzen Sie den Zugriffsschlüssel des Amazon Web Services (AWS), den Sie zum Zugriff auf Amazon S3 verwenden, durch den Google-HMAC-Zugriffsschlüssel. Ihr Google-HMAC-Zugriffsschlüssel beginnt mit GOOG.

  • CREDENTIAL_SCOPE: Der Anmeldedatenbereich ist ein String mit der folgenden Struktur:

    DATE/LOCATION/SERVICE/REQUEST_TYPE
    • DATE: Datum im Format JJJJMMTT
    • LOCATION: Region, in der sich die Ressource befindet oder erstellt wird
    • SERVICE: Dienstname
    • REQUEST_TYPE: Anfragetyp

    Ein Beispiel für einen Anmeldedatenbereich im Amazon S3-Stil sieht so aus:

    20150830/us-east-1/iam/aws4_request

    Bei einer einfachen Migration müssen Sie den Anmeldedatenbereich nicht ändern, wenn Sie AWS4-HMAC-SHA256 als ALGORITHM-Wert verwenden. Wenn Sie GOOG4-HMAC-SHA256 verwenden möchten, ersetzen Sie aws4_request durch goog4_request.

  • SIGNED_HEADERS: Eine durch Semikolons getrennte Liste mit Namen von Headern, die zum Signieren dieser Anfrage enthalten sein müssen. Alle Header sollten in Kleinbuchstaben angegeben und nach Zeichencode sortiert sein.

    Ein Beispiel für einen signierten Headerstring im Amazon S3-Stil sieht so aus:

    content-type;host;x-amz-date

    Bei einer einfachen Migration müssen Sie keine Änderungen an dem signierten Headerstring vornehmen.

  • SIGNATURE: Der kryptografische Hash des zu signierenden Strings, der die Authentifizierung der Anfrage ermöglicht hat. Zur Erstellung der Signatur werden HMAC-SHA256 als Hash-Funktion und ein von Ihrem Secret und dem Anmeldedatenbereich abgeleiteter Schlüssel als kryptografischer Schlüssel verwendet. Der Digest, der sich daraus ergibt, ist dann Base64-codiert. Wenn Cloud Storage Ihre signierte Anfrage empfängt, wird der Zugriffsschlüssel verwendet, um Ihr Secret abzurufen und zu prüfen, ob Sie die Signatur erstellt haben. Weitere Informationen dazu, wie Sie einen Zugriffsschlüssel und ein Secret erhalten, finden Sie unter HMAC-Schlüssel für den Zugriff in einem einfachen Migrationsszenario verwalten.

    Bei einer einfachen Migration ersetzen Sie den geheimen AWS-Zugriffsschlüssel durch Ihren Google-HMAC-Schlüssel, um daraus den kryptografischen Schlüssel abzuleiten.

Authentifizierung berechnen

In diesem Abschnitt wird der Prozess zur Authentifizierung einer XML API-Anfrage in einem einfachen Migrationsszenario beschrieben. Dieser Abschnitt kann Ihnen zwar als Hilfestellung dafür dienen, Ihren eigenen Code für das Signieren von Anfragen zu entwickeln, aber er soll hauptsächlich eine Übersicht darstellen, falls Sie bereits Tools oder Bibliotheken haben, die Ihre Anfragen an Amazon S3 signieren. In diesem Fall verwenden Sie unter Berücksichtigung der hier vorgestellten Änderungen weiterhin diese Tools, um mithilfe der XML API auf Cloud Storage zuzugreifen.

Signaturen bieten sowohl eine Identität als auch eine starke Authentifizierung, ohne Ihr Secret offenzulegen. Die Bereitstellung der Identität und der Authentifizierung bei allen Anfragen sorgt dafür, dass jede Anfrage über ein bestimmtes Nutzerkonto abgewickelt und mit der Autorisierung dieses Nutzerkontos verarbeitet wird. Dies ist möglich, weil nur Sie und das Cloud Storage-System Ihr Secret kennen. Wenn Sie eine Anfrage stellen, verwendet das Cloud Storage-System Ihr Secret, um die gleiche Signatur zu berechnen, die Sie berechnet haben, als Sie die Anfrage stellten. Stimmen die Signaturen überein, erkennt das Cloud Storage-System, dass nur Sie diese Anfrage gestellt haben können.

Der folgende Pseudocode veranschaulicht, wie die Signatur für den Autorisierungsheader erstellt wird:

Signature = HexEncode(HMAC-SHA256(SiginingKey, StringToSign))

Zur Erstellung der Signatur verwenden Sie eine kryptografische Hash-Funktion, die als HMAC-SHA256 bekannt ist. HMAC-SHA256 ist ein hash-basierter Message Authentication Code (MAC), der unter RFC 4868 beschrieben wird. Er erfordert zwei Eingabeparameter, die beide in UTF-8 codiert sein müssen: einen Signierschlüssel und einen zu signierenden String.

Der Signierschlüssel wird von Ihrem Cloud Storage-Secret abgeleitet und bezieht sich auf das Datum, die Region, den Dienst und den Anfragetyp Ihrer Anfrage. Außerdem müssen diese Werte den Angaben im Anmeldedatenbereich entsprechen. Der folgende Pseudocode zeigt, wie der Signierschlüssel erstellt wird:

key_date = HMAC-SHA256("AWS4" + GOOG-ACCESS-KEY, "YYYYMMDD")
key_region = HMAC-SHA256(key_date, "us-east-1")
key_service = HMAC-SHA256(key_region, "s3")
signing_key = HMAC-SHA256(key_service, "aws4_request")

Dabei identifiziert GOOG-ACCESS-KEY die Entität, die die Anfrage sendet und signiert.

Der zu signierende String enthält Metainformationen zu Ihrer Anfrage und zu der kanonischen Anfrage, die Sie signieren möchten. Der folgende Pseudocode zeigt, wie der zu signierende String erstellt wird, einschließlich der Verwendung von Zeilenumbrüchen zwischen den einzelnen Elementen:

SigningAlgorithm
RequestDateTime
CredentialScope
HashedCanonicalRequest

Der zu signierende String besteht aus den folgenden Komponenten:

  • SigningAlgorithm: Für eine einfache Migration sollte dies AWS4-HMAC-SHA256 sein.
  • RequestDateTime: Das aktuelle Datum und die aktuelle Uhrzeit im ISO 8601-Format: YYYYMMDD'T'HHMMSS'Z'.
  • CredentialScope: Der Anmeldedatenbereich der Anfrage zum Signieren des zu signierenden Strings, wie im Abschnitt Autorisierungsheader beschrieben.
  • HashedCanonicalRequest: Der hex-codierte SHA-256-Hash-Wert der kanonischen Anfrage. Verwenden Sie eine SHA-256-Hash-Funktion, um einen Hash-Wert der kanonischen Anfrage zu erstellen. Die Programmiersprache sollte eine Bibliothek zum Erstellen von SHA-256-Hash-Werten haben. Beispiel für einen Hash-Wert:

    436b7ce722d03b17d3f790255dd57904f7ed61c02ac5127a0ca8063877e4e42c

Ein zu signierender String könnte so aussehen:

AWS4-HMAC-SHA256
20190301T190859Z
20190301/us-east-1/s3/aws4_request
54f3076005db23fbecdb409d25c0ccb9fb8b5e24c59f12634654c0be13459af0

Beispiel für eine Authentifizierungsanfrage

In den folgenden Beispielen wird das Objekt /europe/france/paris.jpg in einen Bucket mit dem Namen my-travel-maps hochgeladen. Dabei wird die vordefinierte ACL public-read angewendet und ein benutzerdefinierter Metadatenheader für Prüfer festgelegt. Die Anfrage an einen Bucket in Amazon S3 sieht so aus:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.s3.amazonaws.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Die Anfrage an einen Bucket in Cloud Storage sieht so aus:

PUT europe/france/paris.jpg HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Mon, 11 Mar 2019 23:46:19 GMT
Content-Length: 888814
Content-Type: image/jpg
x-amz-acl: public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer: joe,jane
Authorization: AWS4-HMAC-SHA256 Credential=GOOG-ACCESS-KEY/20190311/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-acl;x-amz-date;x-amz-meta-reviewer, Signature=SIGNATURE

Dies ist die entsprechende kanonische Anfrage, die für diese Anfrage erstellt wurde:

PUT
/europe/france/paris.jpg

content-length:888814
content-type:image/jpg
host:my-travel-maps.storage.googleapis.com
x-amz-acl:public-read
x-amz-date:20190311T192918Z
x-amz-meta-reviewer:joe,jane

content-length,content-type,host,x-amz-acl,x-amz-date,x-amz-meta-reviewer
82e3da8b3f35989512e8d428add7eca73ab0e5f36586e66fbad8e1051343cbd2

Dies ist der entsprechende zu signierende String, der für diese Anfrage erstellt wurde:

AWS4-HMAC-SHA256
20190311T192918Z
20190311/us-east-1/s3/aws4_request
73918a5ff373d7a03e406fbf9ea35675396b06fca2af76c27a5c451fa783ef65

Diese Anfrage enthielt keinen Content-MD5-Header, also wird in der zweiten Zeile der Nachricht ein leerer String angezeigt.

Zugriffssteuerung bei einem einfachen Migrationsszenario

Zur Unterstützung einfacher Migrationen akzeptiert Cloud Storage ACLs, die von Amazon S3 erzeugt wurden. Bei einem einfachen Migrationsszenario verwenden Sie AWS als Ihren Signaturbezeichner. Dadurch erkennt Cloud Storage, dass eine ACL-Syntax in Form der ACL-XML-Syntax von Amazon S3 zu erwarten ist. Sie sollten dafür sorgen, dass die ACLs von Amazon S3, die Sie verwenden, dem ACL-Modell von Cloud Storage zugeordnet werden können. Wenn Ihre Tools und Bibliotheken beispielsweise die ACL-Syntax von Amazon S3 verwenden, um die Bucket-Berechtigung WRITE zu gewähren, muss auch die Bucket-Berechtigung READ gewährt werden, weil Cloud Storage-Berechtigungen konzentrisch sind. Sie müssen nicht die Berechtigungen WRITE und READ angeben, wenn Sie die Berechtigung WRITE gewähren und hierfür die Syntax von Cloud Storage verwenden.

Cloud Storage unterstützt die ACL-Syntax von Amazon S3 in folgenden Fällen:

  • Bei einer Anfrage an Cloud Storage zum Abrufen von ACLs (z. B. einer Anfrage für ein GET-Objekt oder einen -Bucket), gibt Cloud Storage die Antwort in der ACL-Syntax von Amazon S3 zurück.
  • Bei einer Anfrage an Cloud Storage zum Anwenden von ACLs (z. B. einer Anfrage für ein PUT-Objekt oder einen -Bucket), erwartet Cloud Storage, dass die Anfrage in der ACL-Syntax von Amazon S3 gestellt wird.

Der Header Authorization verwendet bei einem einfachen Migrationsszenario AWS als Signaturbezeichner, aber mit Ihrem Google-Zugriffsschlüssel.

Authorization: AWS4-HMAC-SHA256 Credential=GOOG-ACCESS-KEY/CREDENTIAL_SCOPE, SignedHeaders=SIGNED_HEADERS, Signature=SIGNATURE

Das folgende Beispiel zeigt eine GET-Anfrage an Cloud Storage, bei der die ACLs für ein Objekt zurückgegeben werden sollen.

GET europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

Die Antwort auf die Anfrage enthält die ACL, die in der ACL-Syntax von Amazon S3 dargestellt ist.

<?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>

Das folgende Beispiel zeigt eine PUT-Anfrage an Cloud Storage, mit der die ACLs für ein Objekt festgelegt werden sollen. Das Beispiel zeigt einen Anfragetext mit der ACL-Syntax von Amazon S3.

PUT europe/france/paris.jpg?acl HTTP/1.1
Host: my-travel-maps.storage.googleapis.com
Date: Thu, 21 Feb 2019 23:50:10 GMT
Content-Type: application/xml
Content-Length: 337
X-Amz-Date: 20190221T235010Z
Authorization: AWS4-HMAC-SHA256 Credential=GOOGMC5PDPA5JLZYQMHQHRAX/20190221/region/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=29088b1d6dfeb2549f6ff67bc3744abb7e45475f0ad60400485805415bbfc534

<?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>

Bei einem einfachen Migrationsszenario können Sie im GOOG1-Header aber auch den Signaturbezeichner Authorization verwenden. In diesem Fall müssen Sie die ACL-Syntax von Cloud Storage verwenden und dafür sorgen, dass alle Ihre Header Google-Header sind, also x-goog-*. Dies ist zwar möglich, wir empfehlen Ihnen jedoch die Durchführung einer vollständigen Migration (siehe Beschreibung unten), um sämtliche Vorteile von Cloud Storage nutzen zu können.

Vollständige Migration

Durch eine vollständige Migration von Amazon S3 zu Cloud Storage können Sie die Vorteile aller Features von Cloud Storage nutzen. Dazu zählen:

  • Support für Dienstkonten: Dienstkonten sind für die Interaktion zwischen Servern nützlich, die keine Beteiligung von Endnutzern erfordert. Weitere Informationen finden Sie unter Dienstkonten.

  • Unterstützung mehrerer Projekte: Mit mehreren Projekten haben Sie praktisch viele Instanzen des Cloud Storage-Dienstes. So können Sie bei Bedarf verschiedene Funktionen oder Dienste Ihrer Anwendung oder Ihres Geschäfts voneinander trennen. Weitere Informationen finden Sie unter Projekte.

  • Authentifizierung mit OAuth 2.0: OAuth 2.0 greift für die Sicherheit auf SSL zurück und ist leichter zu implementieren. Ihre Anwendung muss also keine direkte kryptografische Signierung vornehmen. Mit OAuth kann Ihre Anwendung Zugriff auf Daten anfordern, die mit dem Google-Konto eines Nutzers verknüpft sind. Der Zugriff kann mehrere Ebenen wie "read-only", "read-write" und "full-control" umfassen. Weitere Informationen finden Sie unter Authentifizierung mit OAuth 2.0.

Für eine vollständige Migration von Amazon S3 zu Cloud Storage müssen Sie die folgenden Änderungen vornehmen:

  • Ändern Sie alle vorhandenen Header des Typs x-amz-* in die entsprechenden Header des Typs x-goog-*.
  • Ändern Sie den ACL-XML-Code von AWS in den entsprechenden ACL-XML-Code von Cloud Storage (siehe Access Control Lists (ACLs) erstellen und verwalten).
  • Geben Sie in Ihren Anfragen den Header x-goog-project-id an. Beachten Sie, dass Sie bei einem einfachen Migrationsszenario ein Standardprojekt für alle Anfragen auswählen. Dies ist bei einer vollständigen Migration nicht erforderlich.
  • Richten Sie wie unter Authentifizierung mit OAuth 2.0 beschrieben die Verwendung der Authentifizierung mit OAuth 2.0 ein. Der erste Schritt besteht darin, Ihre Anwendung, von der Sie Anfragen senden werden, bei Google anzumelden. Bei der Verwendung von OAuth 2.0 sieht Ihr Authorization-Header so aus:

    Authorization: Bearer <oauth2_token>

Zugriffssteuerung bei vollständiger Migration

In diesem Abschnitt finden Sie einige Beispiele für die Zugriffssteuerung, die Ihnen die Migration von Amazon S3 zu Cloud Storage erleichtern sollen. Eine Übersicht über die Zugriffssteuerung in Cloud Storage finden Sie unter Zugriffssteuerungsoptionen.

In Cloud Storage gibt es mehrere Möglichkeiten, ACLs auf Buckets und Objekte anzuwenden (siehe Access Control Lists (ACLs) erstellen und verwalten). Zwei dieser Möglichkeiten zum Festlegen der ACLs entsprechen dem Vorgehen in Amazon S3:

  • Der Abfragestringparameter acl zum Anwenden von ACLs für bestimmte Bereiche
  • Der Anfrageheader x-goog-acl zum Anwenden vordefinierter ACLs, die auch als gespeicherte ACLs bekannt sind

Abfragestringparameter "acl" verwenden

Sie können den Abfragestringparameter acl für eine Cloud Storage-Anfrage genau auf dieselbe Weise wie für eine Amazon S3-Anfrage verwenden. Der acl-Parameter wird in Verbindung mit der PUT-Methode verwendet, um ACLs auf ein vorhandenes Objekt, einen vorhandenen Bucket oder einen Bucket, den Sie gerade erstellen, anzuwenden. Wenn Sie den Abfragestringparameter acl als Teil einer PUT-Anfrage verwenden, müssen Sie mithilfe der ACL-Syntax von Cloud Storage an den Anfragetext ein XML-Dokument anhängen. Das XML-Dokument enthält die einzelnen ACL-Einträge, die Sie auf den Bucket oder das Objekt anwenden möchten.

Das folgende Beispiel veranschaulicht eine PUT-Anfrage an Amazon S3, bei der der Abfragestringparameter acl verwendet wird. Die ACLs sind in einem XML-Dokument definiert, das mit dem Anfragetext gesendet wird. Die PUT-Anfrage ändert die ACLs für ein Objekt mit dem Namen europe/france/paris.jpg, das sich in einem Bucket namens my-travel-maps befindet. Die ACL gewährt jane@gmail.com die Berechtigung 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: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=4c45f25bb679fdab0de5a287625d6a143414728d93c9aeb9f4cc91c33a1c45fg

<?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>

Hier ist die gleiche Anfrage an 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>

Beachten Sie, dass Cloud Storage im ACL-XML-Dokument kein <Owner/>-Element benötigt. Weitere Informationen finden Sie unter Bucket- und Objektinhaberschaft.

Sie können auch Bucket- und Objekt-ACLs abrufen, indem Sie den Abfragestringparameter acl mit der GET-Methode verwenden. Die ACLs sind im XML-Dokument beschrieben, das an den Antworttext angehängt ist. Sie müssen die Berechtigung FULL_CONTROL haben, um ACLs auf ein Objekt oder ein Bucket anzuwenden oder sie abzurufen.

ACLs mit einem Erweiterungsanfrageheader anwenden

Sie können bei einer Cloud Storage-Anfrage den Header x-goog-acl genau auf dieselbe Weise wie den Header x-amz-acl bei einer Amazon S3-Anfrage verwenden, um vordefinierte ACLs auf Buckets und Objekte anzuwenden. Normalerweise verwenden Sie den Header x-goog-acl (x-amz-acl), um eine vordefinierte ACL auf einen Bucket oder ein Objekt anzuwenden, wenn Sie den Bucket oder das Objekt erstellen oder hochladen. Die vordefinierten ACLs von Cloud Storage sind den gespeicherten ACLs von Amazon S3 ähnlich, einschließlich "private", "public-read", "public-read-write" und anderen. Eine Liste der vordefinierten ACLs für Cloud Storage finden Sie unter Vordefinierte ACLs.

Das folgende Beispiel zeigt eine PUT-Anfrage für ein Objekt, bei der die ACL public-read auf ein Objekt mit dem Namen europe/france/paris.jpg angewendet wird. Dieses Objekt wird in einen Bucket namens my-travel-maps in Amazon S3 hochgeladen.

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: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=808150c37dbd1b425b2398421d6fc3dd6d4942dfaae9e519fd5835aa62fd62ab

<888814 bytes in entity body>

Hier ist die gleiche Anfrage an 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>

Sie können auch den Header x-goog-acl verwenden, um eine vordefinierte ACL auf einen vorhandenen Bucket oder ein vorhandenes Objekt anzuwenden. Hierfür muss Ihre Anfrage den Abfragestringparameter acl enthalten, darf jedoch kein XML-Dokument umfassen. Die Anwendung einer vordefinierten ACL auf ein vorhandenes Objekt oder einen vorhandenen Bucket ist nützlich, wenn Sie zwischen zwei vordefinierten ACLs wechseln oder benutzerdefinierte ACLs durch vordefinierte ACLs ersetzen möchten. Bei der folgenden PUT-Anfrage für ein Objekt wird beispielsweise die vordefinierte ACL private auf ein Objekt mit dem Namen europe/france/paris.jpg angewendet, das sich in einem Bucket namens my-travel-maps befindet.

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>

Weitere Informationen zum Verwalten von ACLs finden Sie unter Access Control Lists (ACLs) erstellen und verwalten.

Anfragemethoden für die Migration von Amazon S3 zu Cloud Storage

Cloud Storage unterstützt die gleichen standardmäßigen HTTP-Anfragemethoden zum Lesen und Schreiben von Daten in Ihren Buckets wie Amazon S3. Der Großteil Ihrer Tools und Bibliotheken, die Sie aktuell in Amazon S3 verwenden, funktioniert daher unverändert in Cloud Storage. Cloud Storage unterstützt die folgenden Anfragemethoden:

  • Dienstanfragen für GET
  • Bucket-Anfragen wie PUT, GET und DELETE
  • Objektanfragen wie GET, POST, PUT, HEAD und DELETE

Weitere Informationen finden Sie unter Referenzmethoden der XML API. Beachten Sie, dass Sie gegebenenfalls den Anfragetext ändern müssen, wenn Sie Anfragen an Cloud Storage senden, damit die richtige Syntax von Cloud Storage verwendet wird. Wenn Sie beispielsweise eine Lebenszykluskonfiguration für einen Bucket erstellen, sollten Sie den Lebenszyklus-XML-Code von Cloud Storage verwenden, der sich vom Lebenszyklus-XML-Code von Amazon S3 unterscheidet.

Zwischen der Cloud Storage XML API und Amazon S3 gibt es einige Unterschiede. Diese sind nachfolgend zusammen mit empfohlenen Alternativen für Cloud Storage aufgeführt:

Funktionalität bei Amazon S3 Funktionalität der XML API von Google Cloud Storage
Mehrteiliger Upload
POST /<Objektname>, PUT /<Objektname>

In der XML API von Cloud Storage können Sie eine Reihe von Komponentenobjekten hochladen. Dabei wird jede Komponente separat hochgeladen. Anschließend können Sie die Objekte in ein zusammengesetztes Objekt überführen.

Hinweis: Die JSON API bietet ein Feature für einen mehrteiligen Upload. Dieses wird zum Senden von Metadaten zusammen mit Objektdaten verwendet. Es entspricht nicht dem Feature für einen mehrteiligen Upload in S3.

GET/POST-Abfragestringparameter für einen Bucket:
  • "policy" – zur Arbeit mit den Bucket-Richtlinien von Amazon S3
  • "website" – zur Konfiguration von Bucket-Websites
  • "tagging" – zum Taggen von Buckets aus Gründen der Kostenzuweisung
  • "notification" – zur Meldung von Bucket-Ereignissen
  • "requestPayment" – zur Konfiguration, wer für die Anfrage und den Datendownload von einem Bucket bezahlt
Alternativen:
  • "policy": Die ACLs von Cloud Storage, die Mitgliedschaft in Projektteams und die Möglichkeit, mehrere Projekte zu verwenden, unterstützen viele der Szenarien, in denen Bucket-Richtlinien zur Anwendung kommen.
  • "website": Verwalten Sie Websites mit dem gsutil-Befehl web oder verwenden Sie die JSON API (siehe Buckets).
  • "tagging": Verwenden Sie mehrere Projekte, um verschiedene Kostenstellen zu beobachten. Weitere Informationen zu Projekten finden Sie unter Projekte verwalten.
  • "notification": Verwenden Sie "gsutil" oder die Cloud Pub/Sub-Benachrichtigungen der JSON API.
  • "requestPayment": Verwenden Sie mehrere Projekte mit unterschiedlichen Abrechnungsprofilen, um zu steuern, wer für Anfragen und aus dem Bucket heruntergeladene Daten bezahlt. Weitere Informationen zur Abrechnungskonfiguration finden Sie unter Abrechnung in der Hilfe zur Google APIs Console.
Löschen mehrerer Objekte
POST /?delete

Verwenden Sie den gsutil-Befehl rm, um problemlos mehrere Objekte zu entfernen. Der Befehl "rm" unterstützt die Option "-m", mit der parallele Löschvorgänge (mehrere Threads/Prozesse) ermöglicht werden.

Alternativ unterstützt die JSON API das Senden von Batchanfragen, sodass sich die Anzahl der HTTP-Verbindungen verringert, die Ihr Client herstellt.

Header für die Migration von Amazon S3 zu Cloud Storage

Cloud Storage verwendet mehrere Standard-HTTP-Header sowie mehrere benutzerdefinierte (Erweiterungs-)HTTP-Header. Wenn Sie von Amazon S3 auf Cloud Storage umsteigen, können Sie Ihre benutzerdefinierten Header von Amazon S3 in die benutzerdefinierten Header von Cloud Storage mit gleicher oder ähnlicher Funktionalität umwandeln (siehe Tabelle unten).

Bei vielen Amazon S3-Headern muss einfach das Präfix x-amz durch x-goog ersetzt werden:

Amazon S3-Header Cloud Storage-Header
x-amz-storage-class x-goog-storage-class
x-amz-acl x-goog-acl
x-amz-date x-goog-date
x-amz-meta-* x-goog-meta-*
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

Mehrere Header unterscheiden sich oder gelten nicht in Cloud Storage:

Amazon S3-Header Cloud Storage-Header
x-amz-server-side-encryption Nicht erforderlich. Cloud Storage verschlüsselt automatisch alle Daten, bevor sie auf ein Laufwerk geschrieben werden. Weitere Informationen finden Sie unter Verschlüsselung.
x-amz-grant-* x-goog-acl mit einem vordefinierten ACL-Wert.
x-amz-mfa Verwenden Sie die Authentifizierung mit OAuth 2.0.
x-amz-website-redirect-location, x-amz-copy-source-range

Unter HTTP-Header und Abfragestringparameter für die XML API finden Sie eine Referenz zu Cloud Storage-Headern.

Support für die Kompatibilität der XML API mit Amazon S3

Diskussionen über die Interoperabilität der XML API finden Sie bei Stack Overflow mithilfe des Tags google-cloud-storage. Weitere Informationen zu Diskussionsforen und zum Abonnieren von Ankündigungen finden Sie auf der Seite Support.