Como migrar do Amazon S3 para o Cloud Storage

Nesta página, você aprenderá como fazer a migração do Amazon Simple Storage Service (Amazon S3) para o Cloud Storage, se você for um usuário que envia solicitações usando uma API.

Se você ainda é inexperiente no Cloud Storage e não pretende usar a API diretamente, pense na possibilidade de usar o Console do Google Cloud Platform para definir e gerenciar transferências. O Console do Google Cloud Platform fornece uma interface gráfica para o Cloud Storage que permite realizar muitas de suas tarefas de armazenamento usando apenas um navegador, incluindo a migração de dados do Amazon S3 para o Cloud Storage.

Visão geral da migração

Se você é um usuário do Amazon S3, conseguirá migrar facilmente seus aplicativos para o Cloud Storage. Há duas opções de migração:

  • Migração simples: é a maneira mais fácil de dar os primeiros passos no Cloud Storage se você já é usuário do Amazon S3 porque requer apenas algumas mudanças simples nas ferramentas e bibliotecas que você utiliza atualmente.

  • Migração completa: a migração completa do Amazon S3 para o Cloud Storage requer algumas etapas adicionais em comparação com a migração simples. No entanto, o benefício é que será possível usar todos os recursos do Cloud Storage, incluindo a compatibilidade com contas de serviço, vários projetos e autenticação por meio do OAuth 2.0.

Migração simples

Na migração simples do Amazon S3 para o Cloud Storage, você usará suas ferramentas e bibliotecas atuais para gerar solicitações REST autenticadas para o Amazon S3 e também enviar solicitações autenticadas para o Cloud Storage. As únicas etapas necessárias para fazer solicitações ao Cloud Storage são estas:

  • Definir um projeto padrão do Google.
  • Conseguir uma chave HMAC.
  • Nas ferramentas ou bibliotecas atuais, fazer as alterações a seguir:

    • Alterar endpoint de solicitações para usar o endpoint de solicitações da API XML do Cloud Storage.
    • Substituir o acesso e a chave secreta do Amazon Web Services (AWS) pela chave de acesso e chave secreta correspondentes do Cloud Storage, que juntas são conhecidas como chave HMAC do Cloud Storage.

Com essas alterações, é possível começar a usar suas ferramentas e bibliotecas atuais para enviar solicitações de código de autenticação de mensagens de hash com chave (HMAC, na sigla em inglês) para o Cloud Storage.

Os exemplos a seguir mostram como listar intervalos do Cloud Storage usando o SDK do Amazon S3:

Java

Para mais informações, consulte a documentação de referência da API Cloud Storage para Java.

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

Para mais informações, consulte a documentação de referência da API Cloud Storage para Python.

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"])

A maioria das ações está disponível usando o SDK do Amazon S3 V2. No entanto, para listar objetos é necessário usar o método de listagem de objetos do Amazon S3 V1. Os exemplos a seguir demonstram como isso é feito:

Java

Para mais informações, consulte a documentação de referência da API Cloud Storage para Java.

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

Para mais informações, consulte a documentação de referência da API Cloud Storage para Python.

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"])

Ao usar a API XML do Cloud Storage na migração simples, especifique o identificador de assinatura AWS no cabeçalho Authorization para que o Cloud Storage espere receber cabeçalhos x-amz-* e a sintaxe XML de lista de controle de acesso (ACL, na sigla em inglês) do Amazon S3 na solicitação.

Como definir um projeto padrão

Para usar o Cloud Storage na migração simples, é necessário escolher um projeto padrão. Ao fazer isso, você informa ao Cloud Storage qual projeto usar em operações como um serviço GET ou um intervalo PUT.

Siga as etapas abaixo para definir o projeto padrão:

  1. Abra a página Configurações do Cloud Storage no Console do Google Cloud Platform.
  2. Selecione Interoperabilidade.
  3. Clique em Tornar PROJECT-ID meu projeto padrão.

    Se o projeto já for o padrão, você verá PROJECT-ID como projeto padrão para acesso interoperável.

Agora, esse é seu projeto padrão. É possível alterar o projeto padrão a qualquer momento, basta escolher um projeto diferente e seguir essas mesmas etapas.

Como gerenciar chaves HMAC para uma migração simples

Para usar a API XML do Cloud Storage na migração simples, utilize as chaves de código de autenticação de mensagem baseada em hash (HMAC, na sigla em inglês) do Cloud Storage como suas credenciais. As chaves HMAC são compostas de uma chave de acesso e uma chave secreta. A chave de acesso é uma string alfanumérica de 24 caracteres vinculada à sua Conta do Google. Todas as solicitações autenticadas do Cloud Storage, exceto as que usam autenticação baseada em cookies, precisam usar uma chave de acesso para que o sistema do Cloud Storage saiba quem é o autor. Veja a seguir um exemplo de chave de acesso:

GOOGTS7C7FUP3AIRVJTE2BCD

Uma chave secreta é uma string codificada em Base64 e de 40 caracteres que está vinculada a uma chave de acesso específica. Trata-se de uma chave pré-compartilhada que apenas você e o sistema do Cloud Storage conhecem. Ela é usada para assinar todas as solicitações como parte do processo de autenticação. Veja a seguir um exemplo de chave secreta:

bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

Siga as etapas abaixo para gerar uma chave HMAC:

  1. Abra a página Configurações do Cloud Storage no Console do Google Cloud Platform.
  2. Selecione Interoperabilidade.
  3. Se você não configurou a interoperabilidade antes, clique em Ativar acesso à interoperabilidade.
  4. Clique em Criar uma nova chave.

Dicas de segurança para trabalhar com chaves HMAC

  • É possível criar várias chaves HMAC. Isso é útil para quem trabalha em vários projetos e quer usar chaves HMAC diferentes para cada um.

  • Nunca deixe que qualquer outra pessoa use suas chaves HMAC. Elas estão vinculadas à sua Conta do Google e, portanto, você precisa tratá-las do mesmo modo como qualquer outro conjunto de credenciais de acesso.

  • Como prática de segurança recomendada, altere regularmente suas chaves como parte do processo de rotação de chaves.

  • Se você acha que outra pessoa está usando suas chaves HMAC, exclua imediatamente as chaves HMAC afetadas e crie novas.

  • Quando você alterar suas chaves HMAC, atualize o código com as chaves novas antes de excluir as antigas. Depois de excluídas, as chaves HMAC se tornam inválidas imediatamente e não podem ser recuperadas.

Como fazer a autenticação na migração simples

Cabeçalho de autorização

Na migração simples, para as operações que exigem autenticação, inclua um cabeçalho de solicitação Authorization do mesmo modo como é feito para solicitações ao Amazon S3. A sintaxe do cabeçalho Authorization em uma solicitação do Amazon S3 é:

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

Na migração simples, você precisa apenas alterar o cabeçalho para usar sua chave de acesso HMAC do Google e verificar se o Signature que você anexou foi calculado com sua chave secreta HMAC do Google:

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

As partes do cabeçalho Authorization são:

  • ALGORITMO: o algoritmo e a versão de assinatura que você está usando. Usar AWS4-HMAC-SHA256 indica que você está utilizando uma assinatura HMAC V4 e pretende enviar cabeçalhos x-amz-*. Também é possível usar GOOG4-HMAC-SHA256, que indica que você está utilizando uma assinatura HMAC V4 e pretende enviar cabeçalhos x-goog-*.

  • GOOG-ACCESS-KEY: a chave de acesso que identifica a entidade que fez e assinou a solicitação. Na migração simples, substitua o ID da chave de acesso da Amazon Web Service (AWS) que você usa para acessar o Amazon S3 por sua chave de acesso HMAC do Google. Sua chave de acesso HMAC do Google começa com GOOG.

  • CREDENTIAL_SCOPE: o escopo da credencial é uma string que tem a seguinte estrutura:

    DATE/LOCATION/SERVICE/REQUEST_TYPE
    • DATA: data no formato AAAAMMDD.
    • LOCAL: a região onde o recurso reside ou será criado.
    • SERVIÇO: o nome do serviço.
    • REQUEST_TYPE: o tipo da solicitação.

    Veja abaixo um exemplo de escopo de credencial no estilo do Amazon S3:

    20150830/us-east-1/iam/aws4_request

    Na migração simples, não é necessário alterar o escopo da credencial se você estiver usando AWS4-HMAC-SHA256 como o valor de ALGORITMO. Se você quiser usar GOOG4-HMAC-SHA256, substitua aws4_request por goog4_request.

  • SIGNED_HEADERS: uma lista de nomes de cabeçalhos separados por ponto e vírgula que precisa ser incluída para assinar a solicitação. Todos os cabeçalhos precisam estar em letras minúsculas e classificados por código de caractere.

    Veja abaixo um exemplo de string de cabeçalho assinada no estilo do Amazon S3:

    content-type;host;x-amz-date

    Na migração simples, não é necessário fazer qualquer alteração na string de cabeçalho assinada.

  • ASSINATURA: o hash criptográfico da string a ser assinada que permitiu que a solicitação fosse autenticada. A assinatura é criada usando HMAC-SHA256 como a função hash e uma chave derivada da sua chave secreta e escopo de credencial como a chave criptográfica. O resumo resultante será codificado em Base64. Quando o Cloud Storage recebe sua solicitação assinada, ele usa a chave de acesso para pesquisar a chave secreta e verificar que foi você quem criou a assinatura. Para mais informações sobre como conseguir a chave de acesso e a chave secreta, consulte Como gerenciar chaves HMAC para acesso na migração simples.

    Na migração simples, substitua a chave de acesso secreta da AWS por sua chave secreta HMAC do Google para gerar a chave criptográfica.

Cálculo de autenticação

Nesta seção, descreveremos o processo de autenticação de uma solicitação da API XML em um cenário de migração simples. Mesmo que esta seção possa ser usada para desenvolver seu próprio código para assinar solicitações, o objetivo principal é que ela seja uma revisão caso você já tenha ferramentas ou bibliotecas que assinem suas solicitações para o Amazon S3. Nesse caso, continue usando essas ferramentas para acessar o Cloud Storage por meio da API XML, com as alterações mostradas aqui.

As assinaturas fornecem identidade e autenticação forte sem revelar a chave secreta. Fornecer identidade e autenticação em todas as solicitações ajuda a garantir que cada solicitação seja processada em uma conta de usuário específica e com a respectiva autoridade. Isso é possível porque somente você e o sistema do Cloud Storage conhecem a chave secreta. Quando você faz uma solicitação, o sistema do Cloud Storage usa sua chave secreta para calcular a mesma assinatura que você calculou quando fez a solicitação. Se as assinaturas forem correspondentes, o sistema do Cloud Storage saberá que somente você poderia ter feito a solicitação.

Veja no pseudocódigo a seguir como criar a assinatura para o cabeçalho de autorização:

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

Para criar a assinatura, use uma função de hash criptográfico conhecida como HMAC-SHA256. HMAC-SHA256 é um código de autenticação de mensagem (MAC, na sigla em inglês) baseado em hash. Ele está descrito no RFC 4868 (em inglês). Esse código requer dois parâmetros de entrada, ambos codificados em UTF-8: uma chave de assinatura e uma string a ser assinada.

A chave de assinatura é derivada da sua chave secreta do Cloud Storage e é específica de acordo com a data, o local, o serviço e o tipo de solicitação associados à sua solicitação. Além disso, esses valores precisam ser correspondentes aos valores especificados no escopo da credencial. Veja no pseudocódigo a seguir como criar a chave de assinatura:

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")

em que GOOG-ACCESS-KEY identifica a entidade que está fazendo e assinando a solicitação.

A string a ser assinada inclui metainformações sobre sua solicitação e a solicitação canônica que você quer assinar. O pseudocódigo a seguir mostra como construir a string a ser assinada, incluindo o uso de novas linhas entre cada elemento:

SigningAlgorithm
RequestDateTime
CredentialScope
HashedCanonicalRequest

A string a ser assinada tem os seguintes componentes:

  • SigningAlgorithm: precisa ser AWS4-HMAC-SHA256 na migração simples.
  • RequestDateTime: a data e a hora atuais em formato ISO 8601: YYYYMMDD'T'HHMMSS'Z'.
  • CredentialScope: o escopo da credencial da solicitação para assinar a string, como abordado na seção Cabeçalho de autorização.
  • HashedCanonicalRequest: o hash SHA-256 codificado em hexadecimal da solicitação canônica. Use uma função de hash SHA-256 para criar um valor de hash da solicitação canônica. É necessário que sua linguagem de programação tenha uma biblioteca para criar hashes SHA-256. Veja abaixo um exemplo de valor de hash:

    436b7ce722d03b17d3f790255dd57904f7ed61c02ac5127a0ca8063877e4e42c

Veja abaixo um exemplo de string a ser assinada:

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

Exemplo de solicitação de autenticação

Os exemplos a seguir fazem upload de um objeto chamado /europe/france/paris.jpg para um intervalo chamado my-travel-maps, aplicam a ACL public-read predefinida e definem um cabeçalho de metadados personalizados para avaliadores. Veja abaixo uma solicitação para um intervalo no Amazon S3:

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

Esta é uma solicitação para um intervalo no Cloud Storage:

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

Esta é uma solicitação canônica correspondente que foi criada para a solicitação acima:

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

Esta é a string a ser assinada correspondente, criada para a solicitação:

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

A solicitação não forneceu um cabeçalho Content-MD5, portanto, uma string vazia é mostrada na segunda linha da mensagem.

Controle de acesso na migração simples

Para possibilitar as migrações simples, o Cloud Storage aceita ACLs produzidas pelo Amazon S3. Na migração simples, use AWS como o identificador de assinatura, para que o Cloud Storage saiba que receberá a sintaxe XML de ACL do Amazon S3. É necessário garantir que as ACLs do Amazon S3 usadas sejam mapeadas para o modelo de ACLs do Cloud Storage. Por exemplo, se suas ferramentas e bibliotecas usarem a sintaxe de ACL do Amazon S3 para conceder permissão WRITE ao intervalo, elas também precisarão conceder permissão READ ao intervalo, já que as permissões do Cloud Storage são concêntricas. Não é necessário especificar as duas permissões WRITE e READ ao conceder permissão WRITE usando a sintaxe do Cloud Storage.

O Cloud Storage aceita a sintaxe de ACL do Amazon S3 nos cenários a seguir:

  • Em uma solicitação ao Cloud Storage para recuperar ACLs (por exemplo, uma solicitação de objeto GET ou intervalo ), o Cloud Storage retorna a sintaxe de ACL do Amazon S3.
  • Em uma solicitação ao Cloud Storage para aplicar ACLs (por exemplo, uma solicitação de objeto PUT ou intervalo ), o Cloud Storage espera receber a sintaxe de ACL do Amazon S3.

O cabeçalho Authorization na migração simples usa AWS como identificador de assinatura, mas com sua chave de acesso do Google.

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

O exemplo a seguir mostra uma solicitação GET ao Cloud Storage para retornar as ACLs de um objeto.

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

A resposta à solicitação inclui a ACL usando a sintaxe de ACL do Amazon S3.

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

O exemplo a seguir mostra uma solicitação PUT ao Cloud Storage para definir as ACLs de um objeto. O exemplo mostra um corpo de solicitação com a sintaxe de ACL do 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>

Por fim, na migração simples, também é possível usar o identificador de assinatura GOOG1 no cabeçalho Authorization. Nesse caso, é necessário usar a sintaxe de ACL do Cloud Storage e garantir que todos os cabeçalhos sejam do Google (x-goog-*). Tudo isso é possível, mas recomendamos realizar uma migração completa, conforme descrita abaixo, para aproveitar todos os benefícios do Cloud Storage.

Migração completa

Com a migração completa do Amazon S3 para o Cloud Storage, é possível aproveitar todos os recursos do Cloud Storage, incluindo:

  • Compatibilidade com contas de serviço : as contas de serviço são úteis para interações entre servidores que não exigem o envolvimento do usuário final. Para mais informações, consulte Contas de serviço.

  • Compatibilidade com vários projetos : por aceitar vários projetos, é possível ter de fato muitas instâncias do serviço do Cloud Storage. Isso permite que você separe diferentes funcionalidades ou serviços do seu aplicativo ou empresa conforme necessário. Para mais informações, consulte Projetos.

  • Autenticação pelo OAuth 2.0: o OAuth 2.0 depende da segurança do SSL em vez de exigir que o aplicativo faça a assinatura criptográfica diretamente, além de ser mais fácil de implementar. Com o OAuth, o aplicativo pode solicitar acesso a dados associados à Conta do Google de um usuário, e o acesso pode ser definido em vários níveis, incluindo somente leitura, leitura e gravação, e controle total. Para mais informações, consulte Autenticação do OAuth 2.0.

Para migrar totalmente do Amazon S3 para o Cloud Storage, faça as alterações a seguir:

  • Altere os cabeçalhos x-amz-* atuais para os cabeçalhos x-goog-* correspondentes.
  • Mude o XML de ACL do AWS para o XML de ACL do Cloud Storage correspondente. Consulte Como criar e gerenciar listas de controle de acesso.
  • Defina o cabeçalho x-goog-project-id nas suas solicitações. Na migração simples, você escolhe um projeto padrão para todas as solicitações. Isso não é necessário na migração completa.
  • Prepare-se para usar a autenticação do OAuth 2.0, conforme descrito em Autenticação do OAuth 2.0. O primeiro passo é registrar o aplicativo que emitirá as solicitações no Google. Usar OAuth 2.0 significa que o cabeçalho Authorization será semelhante ao abaixo:

    Authorization: Bearer <oauth2_token>

Controle de acesso na migração completa

Nesta seção, você verá alguns exemplos de controle de acesso que serão úteis na migração do Amazon S3 para o Cloud Storage. Para uma visão geral do controle de acesso no Cloud Storage, consulte Controle de acesso.

No Cloud Storage, há várias maneiras de aplicar ACLs a intervalos e objetos. Consulte Como criar e gerenciar listas de controle de acesso. Há duas formas de especificar as ACLs que são análogas ao que é feito no Amazon S3:

  • O parâmetro de string de consulta acl para aplicar ACLs a escopos específicos.
  • O cabeçalho de solicitação x-goog-acl permite aplicar ACLs predefinidas, que às vezes são conhecidas como ACLs pré-configuradas.

Como usar o parâmetro de string de consulta "acl"

É possível usar o parâmetro de string de consulta acl em uma solicitação do Cloud Storage exatamente da mesma forma que ele é utilizado em uma solicitação do Amazon S3. O parâmetro acl é usado junto com o método PUT para aplicar ACLs aos seguintes elementos: um objeto atual, um intervalo atual ou um intervalo que está sendo criado. Ao usar o parâmetro de string de consulta acl em uma solicitação PUT, é necessário anexar um documento XML (usando a sintaxe de ACL do Cloud Storage) ao corpo da solicitação. O documento XML contém as entradas de ACL individuais que você quer aplicar ao intervalo ou objeto.

Veja no exemplo abaixo uma solicitação PUT para o Amazon S3 que usa o parâmetro de string de consulta acl. As ACLs são definidas em um documento XML enviado no corpo da solicitação. A solicitação PUT altera as ACLs em um objeto chamado europe/france/paris.jpg, que está em um intervalo chamado my-travel-maps. A ACL concede a permissão FULL_CONTROL a jane@gmail.com.

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>

Veja abaixo a mesma solicitação para o 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>

O Cloud Storage não exige um elemento <Owner/> no documento XML da ACL. Para mais informações, consulte Propriedade do intervalo e do objeto.

Também é possível recuperar as ACLs de intervalos e objetos usando o parâmetro de string de consulta acl com o método GET. As ACLs são descritas em um documento XML, que está anexado ao corpo da resposta. É necessário ter a permissão FULL_CONTROL para aplicar ou recuperar ACLs em um objeto ou intervalo.

Como aplicar ACLs com um cabeçalho de solicitação de extensão

É possível usar o cabeçalho x-goog-acl em uma solicitação do Cloud Storage para aplicar ACLs predefinidas a intervalos e objetos exatamente da mesma forma que o cabeçalho x-amz-acl é usado em uma solicitação do Amazon S3. Normalmente, usa-se o cabeçalho x-goog-acl (x-amz-acl) para aplicar uma ACL predefinida a um intervalo ou objeto ao criá-lo ou fazer upload dele. As ACLs predefinidas do Cloud Storage são semelhantes às ACLs pré-configuradas do Amazon S3, incluindo privada, de leitura pública, de leitura e gravação públicas e outras. Para ver a lista de ACLs predefinidas do Cloud Storage, consulte ACLs predefinidas.

O exemplo a seguir mostra uma solicitação de objeto PUT que aplica a ACL public-read a um objeto chamado europe/france/paris.jpg, que está sendo enviado para um intervalo chamado my-travel-maps no Amazon S3.

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>

Veja abaixo a mesma solicitação para o 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>

Também é possível usar o cabeçalho x-goog-acl para aplicar uma ACL predefinida a um intervalo ou objeto atual. Para fazer isso, inclua o parâmetro de string de consulta acl na sua solicitação, mas não inclua um documento XML nela. Aplicar uma ACL predefinida a um objeto ou intervalo atual é útil se você quiser mudar de uma ACL predefinida para outra ou atualizar ACLs personalizadas para uma predefinida. Por exemplo, a solicitação de objeto PUT a seguir aplica a ACL predefinida private a um objeto chamado europe/france/paris.jpg, que está em um intervalo chamado my-travel-maps.

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>

Para mais informações sobre o gerenciamento de ACLs, consulte Como criar e gerenciar listas de controle de acesso.

Como migrar dos métodos de solicitação do Amazon S3 para os do Cloud Storage

O Cloud Storage aceita os mesmos métodos de solicitação HTTP padrão para ler e gravar dados em intervalos que são utilizados no Amazon S3. Portanto, a maioria das ferramentas e bibliotecas que você usa atualmente com o Amazon S3 funciona no Cloud Storage, sem a necessidade de alterações. O Cloud Storage aceita os métodos de solicitação a seguir:

  • Solicitação de serviço para GET
  • Solicitações de intervalo, incluindo PUT, GET e DELETE
  • Solicitações de objetos, incluindo GET, POST, PUT, HEAD e DELETE

Para mais informações, consulte os Métodos de referência da API XML. Lembre-se de que ao enviar solicitações para o Cloud Storage, é necessário alterar o corpo da solicitação, quando aplicável, para usar a sintaxe apropriada do Cloud Storage. Por exemplo, ao criar uma configuração de ciclo de vida para um intervalo, use o XML do ciclo de vida do Cloud Storage, que é diferente daquele do Amazon S3.

Há algumas diferenças entre a API XML do Cloud Storage e o Amazon S3 que estão resumidas abaixo, com alternativas sugeridas para o Cloud Storage:

Funcionalidade do Amazon S3 Funcionalidade da API XML do Cloud Storage
Upload de várias partes.
POST /<object-name>, PUT /<object-name>

Na API XML do Cloud Storage, é possível fazer upload de uma série de objetos de componente, realizando um upload separado para cada um deles. Dessa forma, é possível estruturar os objetos em um único objeto composto.

Observação: a API JSON oferece um recurso de upload de várias partes, mas ele é usado para enviar metadados junto com dados de objeto. Portanto, ele não é equivalente ao recurso de upload de várias partes do S3.

Parâmetros da string de consulta de intervalo GET/POST:
  • "policy" - como trabalhar com políticas de intervalo do Amazon S3.
  • "website" - como configurar os sites dos intervalos.
  • "tagging" - como pôr tags em intervalos para fins de alocação de custos.
  • "notification" - como notificar eventos de intervalo.
  • "requestPayment" - como configurar quem paga pela solicitação e o download de dados de um intervalo.
Alternativas:
  • "policy" - as ACLs do Cloud Storage, a participação na equipe do projeto e a capacidade de usar vários projetos atendem a muitos dos cenários em que as políticas de intervalo são usadas.
  • "website" - use o comando web da gsutil para gerenciar sites ou teste a API JSON. Consulte os recursos de intervalos.
  • "tagging" - use vários projetos para monitorar centros de custo diferentes. Para mais informações sobre projetos, consulte Como gerenciar projetos.
  • "notification" - use a gsutil ou as Notificações do Cloud Pub/Sub da API JSON.
  • "requestPayment" - use vários projetos com diferentes perfis de faturamento para gerenciar quem paga por solicitações e downloads de dados de um intervalo. Para mais informações sobre como configurar o faturamento, consulte Faturamento na documentação da Ajuda do Console de APIs do Google.
Exclusão de vários objetos.
POST /?delete

Use o comando rm da gsutil para remover vários objetos com facilidade. O comando rm aceita a opção "-m" para executar exclusões paralelas (várias linhas de execução/multiprocessamento).

Como alternativa, a API JSON aceita o envio de solicitações em lote para reduzir o número de conexões HTTP feitas por seu cliente.

Como migrar dos cabeçalhos do Amazon S3 para os do Cloud Storage

O Cloud Storage usa vários cabeçalhos HTTP padrão, além de diversos cabeçalhos HTTP personalizados (extensão). Na migração do Amazon S3 para o Cloud Storage, é possível converter cabeçalhos personalizados do Amazon S3 em cabeçalhos personalizados equivalentes do Cloud Storage ou em uma funcionalidade semelhante, conforme mostrado nas tabelas abaixo.

Para muitos cabeçalhos do Amazon S3, basta substituir o prefixo x-amz por x-goog:

Cabeçalho do Amazon S3 Cabeçalho do Cloud Storage
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

Há vários cabeçalhos que são diferentes ou não se aplicam ao Cloud Storage:

Cabeçalho do Amazon S3 Cabeçalho do Cloud Storage
x-amz-server-side-encryption Não é obrigatório. Todos os dados do Cloud Storage são criptografados automaticamente antes de serem gravados no disco. Para mais informações, consulte o documento sobre criptografia.
x-amz-grant-* x-goog-acl com um valor de ACL predefinida.
x-amz-mfa Use a autenticação do OAuth 2.0.
x-amz-website-redirect-location, x-amz-copy-source-range n/a

Consulte os cabeçalhos HTTP e parâmetros de string de consulta da API XML para uma referência aos cabeçalhos do Cloud Storage.

Compatibilidade da API XML com o Amazon S3

Para discussões sobre a interoperabilidade da API XML, consulte o Stack Overflow usando a tag google-cloud-storage. Consulte a página Como receber suporte para mais informações sobre fóruns de discussão e como se inscrever para o recebimento de anúncios.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.