Eseguire la migrazione completa da Amazon S3 a Cloud Storage

Questa pagina descrive come eseguire la migrazione completa da Amazon Simple Storage Service (Amazon S3) a Cloud Storage per gli utenti che inviano richieste utilizzando un'API. Dopo aver completato la migrazione, puoi utilizzare tutte le funzionalità di Cloud Storage, inclusi più progetti e OAuth 2.0 per l'autenticazione.

Se vuoi iniziare a utilizzare Cloud Storage rapidamente, puoi scegliere una migrazione semplice, che richiede solo alcune modifiche agli strumenti e alle librerie che utilizzi con Amazon S3.

Migrazione da Amazon S3 a Cloud Storage

Per eseguire la migrazione completa da Amazon S3 a Cloud Storage, devi completare i seguenti passaggi:

  • Modifica tutte le intestazioni x-amz-* esistenti con le intestazioni x-goog-* corrispondenti.
  • Modifica l'XML dell'elenco di controllo dell'accesso (ACL) di AWS con l'XML dell'ACL di Cloud Storage corrispondente (vedi Creazione e gestione degli elenchi di controllo dell'accesso).
  • Imposta l'intestazione x-goog-project-id nelle richieste.

  • Configura l'autenticazione OAuth 2.0. L'utilizzo di OAuth 2.0 significa che l'intestazione Authorization ha il seguente aspetto:

    Authorization: Bearer OAUTH2_TOKEN

    OAuth 2.0 si basa su SSL per la sicurezza anziché richiedere all'applicazione di eseguire direttamente la firma crittografica ed è più facile da implementare. Con OAuth, l'applicazione può richiedere l'accesso ai dati associati all'account di un utente e l'accesso può essere limitato a diversi livelli, tra cui sola lettura, lettura-scrittura e controllo completo. Per ulteriori informazioni, consulta Ambiti OAuth 2.0 di Cloud Storage e Accesso ai dati per conto di un utente.

Controllo degli accessi

Questa sezione mostra alcuni esempi di controllo dell'accesso per aiutarti a eseguire la migrazione da Amazon S3 a Cloud Storage. Per una panoramica del controllo dell'accesso in Cloud Storage, consulta Controllo degli accessi.

In Cloud Storage, esistono diversi modi per applicare gli ACL a bucket e oggetti (vedi Creazione e gestione degli elenchi di controllo dell'accesso). Due dei modi in cui specifichi gli ACL sono analoghi a quelli di Amazon S3:

  • Il parametro della stringa di query acl consente di applicare gli ACL per ambiti specifici.
  • L'intestazione della richiesta x-goog-acl consente di applicare ACL predefiniti, a volte noti come ACL preimpostati.

Utilizzo del parametro della stringa di query acl

Puoi utilizzare il parametro della stringa di query acl per una richiesta Cloud Storage esattamente come faresti per una richiesta Amazon S3. Il parametro acl viene utilizzato insieme al metodo PUT per applicare gli ACL a un oggetto esistente, a un bucket esistente o a un bucket che stai creando. Quando utilizzi il parametro della stringa di query acl in una richiesta PUT, devi allegare un documento XML (utilizzando la sintassi ACL di Cloud Storage) al corpo della richiesta. Il documento XML contiene le singole voci ACL che vuoi applicare al bucket o all'oggetto.

L'esempio seguente mostra una richiesta PUT ad Amazon S3 che utilizza il parametro della stringa di query acl. Gli ACL sono definiti in un documento XML inviato nel corpo della richiesta. La richiesta PUT modifica gli ACL di un oggetto denominato europe/france/paris.jpg che si trova in un bucket denominato my-travel-maps. L'ACL concede l'autorizzazione a jeffersonloveshiking@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: 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>jeffersonloveshiking@gmail.com</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Ecco la stessa richiesta a 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>jeffersonloveshiking@gmail.com</EmailAddress>
    </Scope>
  </Entry>
  </Entries>
</AccessControlList>

Tieni presente che Cloud Storage non richiede un elemento <Owner/> nel documento XML ACL. Per ulteriori informazioni, consulta Proprietà di bucket e oggetti.

Puoi anche recuperare gli ACL di bucket e oggetti utilizzando il parametro della stringa di query acl con il metodo GET. Gli ACL sono descritti in un documento XML, allegato al corpo della risposta. Devi disporre dell'autorizzazione FULL_CONTROL per applicare o recuperare gli ACL su un oggetto o un bucket.

Applicare gli ACL con un'intestazione della richiesta di estensione

Puoi utilizzare l'intestazione x-goog-acl in una richiesta Cloud Storage per applicare gli ACL predefiniti a bucket e oggetti esattamente come faresti con l'intestazione x-amz-acl in una richiesta Amazon S3. In genere, utilizzi l'intestazione x-goog-acl (x-amz-acl) per applicare un ACL predefinito a un bucket o a un oggetto quando crei o carichi il bucket o l'oggetto. Gli ACL predefiniti di Cloud Storage sono simili agli ACL preimpostati di Amazon S3 tra cui private, public-read, public-read-write, e altri. Per un elenco degli ACL predefiniti di Cloud Storage, consulta ACL predefiniti.

L'esempio seguente mostra una richiesta PUT Object che applica l'ACL public-read a un oggetto denominato europe/france/paris.jpg che viene caricato in un bucket denominato my-travel-maps in 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>

Ecco la stessa richiesta a 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>

Puoi anche utilizzare l'intestazione x-goog-acl per applicare un ACL predefinito a un bucket o a un oggetto esistente. Per farlo, includi il parametro della stringa di query acl nella richiesta, ma non includere un documento XML. L'applicazione di un ACL predefinito a un oggetto o a un bucket esistente è utile se vuoi passare da un ACL predefinito a un altro o se vuoi aggiornare gli ACL personalizzati a un ACL predefinito. Ad esempio, la seguente richiesta PUT Object applica l'ACL predefinito private a un oggetto denominato europe/france/paris.jpg che si trova in un bucket denominato 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>

Per ulteriori informazioni sulla gestione degli ACL, consulta Creazione e gestione degli elenchi di controllo dell'accesso.

Metodi di richiesta di migrazione da Amazon S3 a Cloud Storage

Cloud Storage supporta gli stessi metodi di richiesta HTTP standard per la lettura e la scrittura dei dati nei bucket supportati in Amazon S3. Di conseguenza, la maggior parte degli strumenti e delle librerie che utilizzi con Amazon S3 funziona così com'è con Cloud Storage. Cloud Storage supporta i seguenti metodi di richiesta:

  • Richiesta di servizio per GET.
  • Richieste di bucket, tra cui PUT, GET, DELETE e POST.
  • Richieste di oggetti, tra cui GET, POST, PUT, HEAD e DELETE.

Per ulteriori informazioni, consulta Metodi di riferimento dell'API XML Reference Methods. Tieni presente che quando invii richieste a Cloud Storage, devi modificare il corpo della richiesta, se applicabile, per utilizzare la sintassi di Cloud Storage appropriata. Ad esempio, quando crei una configurazione del ciclo di vita per un bucket, utilizza l'XML del ciclo di vita di Cloud Storage, che è diverso dall'XML del ciclo di vita di Amazon S3.

Di seguito è riportato un riepilogo di alcune differenze tra l'API XML di Cloud Storage e Amazon S3:

Funzionalità di Amazon S3 Funzionalità dell'API XML di Cloud Storage
Quando utilizzi le chiavi di crittografia fornite dal cliente in un caricamento in più parti, la richiesta finale non include la chiave di crittografia fornita dal cliente. Nell'API XML di Cloud Storage, tutte le richieste di un caricamento in più parti, inclusa la richiesta finale, richiedono di fornire la stessa chiave di crittografia fornita dal cliente. Questo requisito esiste perché Cloud Storage non memorizza le informazioni sulla chiave di crittografia mentre attende il completamento del caricamento, ma richiede la chiave per calcolare un checksum per l'oggetto completato.
In Amazon S3, le firme V4 possono essere utilizzate per autenticare i caricamenti che utilizzano la codifica del trasferimento a blocchi. Nell'API XML di Cloud Storage, la codifica del trasferimento a blocchi e le firme V4 non possono essere utilizzate contemporaneamente. Alcuni strumenti di Amazon S3 utilizzano la codifica del trasferimento a blocchi insieme alle firme per impostazione predefinita; in questi casi, devi disattivare la codifica del trasferimento a blocchi.
Parametri della stringa di query del bucket GET/POST:
  • "policy" - Utilizzo delle policy dei bucket Amazon S3.
  • "notification" - Notifiche per gli eventi del bucket.
  • "requestPayment" - Configurazione di chi paga la richiesta e il download dei dati da un bucket.
 Alternative:
  • Gli ACL di Cloud Storage, l'appartenenza al team del progetto e la possibilità di utilizzare più progetti risolvono molti degli scenari in cui vengono utilizzate le policy dei bucket.
  • "notification" - Utilizza gcloud CLI o le notifiche Pub/Sub dell'API JSON.
  • "requestPayment" - In Cloud Storage, il parametro della stringa di query equivalente a requestPayment è billing.

Intestazioni di migrazione da Amazon S3 a Cloud Storage

Cloud Storage utilizza diverse intestazioni HTTP standard e diverse intestazioni HTTP personalizzate (di estensione). Se stai eseguendo la transizione da Amazon S3 a Cloud Storage, puoi convertire le intestazioni personalizzate di Amazon S3 nell'intestazione personalizzata di Cloud Storage equivalente o in una funzionalità simile, come mostrato nelle tabelle seguenti.

Per molte intestazioni di Amazon S3, devi semplicemente sostituire il prefisso x-amz con x-goog:

Intestazione Amazon S3 Intestazione 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

Diverse intestazioni differiscono o non si applicano in Cloud Storage:

Intestazione Amazon S3 Intestazione Cloud Storage
x-amz-server-side-encryption Non obbligatorio. Cloud Storage cripta automaticamente tutti i dati prima che siano scritti su disco. Per ulteriori informazioni, consulta Crittografia.
x-amz-grant-* x-goog-acl con un valore ACL predefinito.
x-amz-version-id x-goog-generation
x-amz-mfa Utilizza l'autenticazione OAuth 2.0.
x-amz-decoded-content-length Non supportata come intestazione x-goog
x-amz-website-redirect-location, x-amz-copy-source-range n/a

Per un riferimento alle intestazioni di Cloud Storage, consulta Intestazioni HTTP e parametri della stringa di query per l'API XML.

Impatto delle policy dell'organizzazione sull'autenticazione con chiave HMAC

Se i carichi di lavoro di cui stai eseguendo la migrazione da Amazon S3 a Cloud Storage dipendono dalle chiavi HMAC (Hash-based Message Authentication Code) per l'autenticazione, tieni presente che il Google Cloud servizio Policy dell'organizzazione consente agli amministratori di applicare vincoli di sicurezza. La policy constraints/storage.restrictAuthTypes può essere utilizzata per impedire l'utilizzo di tipi di autenticazione specifici. Per ulteriori informazioni su ogni tipo di autenticazione, consulta Limitare i tipi di autenticazione.

Se la tua organizzazione ha una policy che nega il tipo di chiavi HMAC che gli strumenti sono configurati per utilizzare, i tentativi di connessione a Cloud Storage non vanno a buon fine e viene visualizzato un errore 403 Forbidden.

Per evitare che si verifichi questo errore, prima di eseguire la migrazione dei flussi di lavoro che dipendono dall'autenticazione con chiave HMAC, consulta l'amministratore dell'organizzazione per determinare se la policy è applicata e quali tipi di autenticazione, se presenti, sono limitati. Google Cloud constraints/storage.restrictAuthTypes Se l'utilizzo della chiave HMAC non è consentito, devi adattare gli strumenti e le applicazioni per utilizzare metodi di autenticazione alternativi, come le credenziali del account di servizio con OAuth 2.0. Google Cloud

Passaggi successivi