Protezione dei carichi di lavoro di rendering

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo articolo spiega come adottare misure per proteggere la pipeline di rendering su Google Cloud. Puoi utilizzare le funzionalità di sicurezza di Google Cloud, come i progetti e IAM (Gestione di identità e accessi), per il controllo dell'accesso, il controllo automatico dei criteri, la crittografia, le subnet e le regole firewall. Questo articolo spiega come rispettare il protocollo di sicurezza richiesto dai principali studi cinematografici.

La seguente immagine mostra un'architettura di rendering ibrido come riferimento:

Diagramma di un'architettura di rendering ibrido

Fai clic per visualizzare una versione più grande.

Progetti e accesso

I progetti sono un componente organizzativo principale di Google Cloud. I progetti forniscono un raggruppamento astratto che puoi utilizzare per associare risorse a un reparto, un'applicazione o un team funzionale. Tutte le risorse di Google Cloud, come le istanze di Compute Engine e i bucket Cloud Storage, appartengono a un progetto. Puoi gestire i progetti utilizzando la console Google Cloud e l'API Resource Manager. L'API IAM include un set di metodi per gestire le autorizzazioni del progetto tramite l'API Resource Manager.

Utilizzo dei progetti per controllare l'accesso alle risorse

I progetti forniscono un confine di isolamento sia per i dati di rete che per l'amministrazione dei progetti. Tuttavia, puoi concedere interconnessioni esplicite tra le risorse Google Cloud utilizzate dalla tua organizzazione o altri progetti all'interno della tua organizzazione. Puoi concedere a utenti e gruppi ruoli diversi, ad esempio viewer, editor e owner, per diversi progetti. Per assegnare i ruoli, puoi utilizzare la pagina IAM e amministrazione della console Google Cloud o dell'API IAM.

Inoltre, puoi delegare il controllo sugli utenti che hanno accesso a un determinato progetto. Gli utenti a cui è stato assegnato il ruolo owner possono concedere e revocare l'accesso per utenti, gruppi e account di servizio.

L'immagine seguente mostra un esempio di gerarchia di risorse di Google Cloud:

diagramma di una struttura di progetto

Concessione dell'accesso

Se la tua organizzazione ha implementato Google Workspace, puoi concedere l'accesso a qualsiasi progetto Google Cloud a qualsiasi utente o gruppo all'interno dell'organizzazione. Se gestisci le tue identità al di fuori di Google Workspace, puoi anche stabilire le credenziali utente in base al tuo server LDAP, incluso Microsoft Active Directory, utilizzando Google Cloud Directory Sync.

Puoi anche concedere a qualsiasi utente di un'organizzazione l'accesso a un progetto o una risorsa aggiungendoli a un gruppo Google che ha accesso al progetto o alla risorsa. I gruppi consentono di concedere rapidamente l'accesso a parti esterne, come contrattisti e liberi professionisti. La tua organizzazione potrebbe non voler consentire questo livello di flessibilità, a seconda dei criteri di sicurezza. Puoi utilizzare l'API Cloud per creare funzionalità di monitoraggio che monitora le assegnazioni off-policy, quindi genera un avviso o li revoca automaticamente.

Accesso tramite SDK e API

Se accedi a Google Cloud tramite l'SDK gcloud o gsutil, devi autenticarti quando ti connetti all'API Google Cloud. Devi eseguire questa operazione una sola volta per ogni ambiente utente locale.

Se le tue applicazioni o i tuoi script accedono a Google Cloud tramite le librerie client API, devi prima autenticarti tramite l'SDK. Le librerie client dell'API quindi recuperano le credenziali create.

Identificazione dei progetti

Ogni progetto ha un ID progetto univoco universale, che è una breve stringa di lettere minuscole, cifre e trattini. Quando crei un progetto, devi specificarne il nome. L'ID progetto è basato su questo nome, con numeri aggiunti per renderlo univoco a livello globale. Puoi sostituire l'ID progetto assegnato, ma il nome deve essere univoco a livello globale.

Al tuo progetto viene anche assegnato un numero di progetto casuale lungo e univoco a livello globale, che viene generato automaticamente. Gli ID progetto possono contenere da 6 a 30 caratteri, mentre i nomi dei progetti possono contenere da 4 a 30 caratteri.

Dopo la creazione del progetto, l'ID e il numero del progetto rimangono invariati, anche se modifichi il nome del progetto.

Ti consigliamo di dedicare un po' di tempo alla pianificazione dei nomi dei progetti per gestirli. I progetti con nomi adeguati possono ordinare correttamente e ridurre la confusione.

Una tipica convenzione di denominazione dei progetti potrebbe utilizzare il seguente pattern:

[studio]-[project]-[role (rnd, dev, prod)]

Il nome di un file risultante potrebbe essere, ad esempio: mystudio-myproject-rnd.

Automazione dei controlli di sicurezza

Policy Scanner fornisce un framework per eseguire controlli di sicurezza automatici sul tuo progetto per garantire che i criteri siano impostati correttamente. I progetti scansionati che si discostano da un criterio noto come "Buono" sono taggati e ti avvisano in caso di problemi. Puoi eseguire Policy Scanner on demand o impostarlo in base a una pianificazione settimanale o giornaliera.

Controllare l'accesso degli utenti

Non tutti gli utenti di un progetto devono avere accesso illimitato a tutte le istanze, i servizi e i dati archiviati in esecuzione. In una pipeline di rendering, le autorizzazioni degli utenti vengono generalmente gestite on-premise con impostazioni di autorizzazione a livello di sistema operativo, abbinate a un servizio di directory come LDAP o Active Directory.

A differenza di una tipica pipeline di rendering, la maggior parte degli artisti non ha bisogno di accedere ai progetti, dato che la maggior parte delle attività basate su cloud, come la sincronizzazione degli asset, il rendering e la scrittura o la copia dei dati vengono eseguite dal software di gestione delle code che opera all'interno di un account di servizio.

Implementando il principio del privilegio minimo sia on-premise che nel cloud, puoi limitare l'accesso degli utenti solo alle aree del progetto o alle informazioni necessarie per eseguire attività specifiche in base al loro ruolo.

A differenza dei carichi di lavoro basati sul Web, le pipeline di rendering richiedono in genere accesso diretto alle istanze in esecuzione, ad esempio per risolvere un problema di rendering in un determinato tipo di istanza. Puoi accedere a un'istanza tramite un'API, ad esempio il comando gcloud, oppure usare SSH per connetterti direttamente a un'istanza se hai stabilito coppie di chiavi SSH.

Limita l'accesso diretto agli amministratori di sistema e agli altri ruoli responsabili della gestione o della risoluzione dei problemi di rendering. L'accesso diretto è essenziale per:

  • Eseguire il debug o risolvere i problemi dei job non riusciti.
  • Controllo del gestore della coda di rendering sull'avvio e sulla chiusura delle istanze.
  • Concedere l'accesso tramite un meccanismo di logging o software che tiene traccia dell'utilizzo della memoria o della CPU.
  • Esecuzione delle attività eseguite durante il job stesso.

È importante distinguere tra le autorizzazioni utente in IAM e quelle impostate a livello di sistema operativo in un'istanza in esecuzione. Sebbene funzionino insieme per fornire un profilo utente completo, i due sistemi hanno scopi diversi e vengono creati e modificati con meccanismi diversi.

IAM non gestisce SSH né l'accesso utente alle singole istanze. L'accesso è gestito dalle autorizzazioni utente a livello di sistema operativo, che possono essere sincronizzate con IAM. La concessione delle autorizzazioni IAM a un account utente o di servizio non cambia il modo in cui gli utenti accedono alle istanze o le loro autorizzazioni dopo aver eseguito l'accesso. I due sistemi sono progettati per essere complementari: IAM viene utilizzato per concedere l'accesso alle risorse Google Cloud, come la console o l'API, e l'accesso diretto viene eseguito solo per gli utenti che ne hanno bisogno.

Se crei un'immagine personalizzata, puoi attivare o disattivare l'accesso SSH modificando ssh e l'agente guest di Google sul disco di avvio. A tale scopo, esamina le funzionalità di sicurezza già incorporate nelle nostre immagini pubbliche.

IAM

Per gestire le risorse Google Cloud, IAM consente di creare e gestire le autorizzazioni a livello di organizzazione, progetto e risorsa. IAM unifica il controllo dell'accesso per i servizi Google Cloud in un unico sistema e presenta un insieme coerente di operazioni.

Ruoli e gruppi IAM

Esistono tre ruoli IAM di base: owner, editor e viewer.

Proprietario Solo un gruppo limitato di persone di fiducia in una struttura o in un progetto deve disporre dei privilegi a livello di proprietario del progetto, ad esempio membri del reparto IT, amministratori di sistema o responsabili di produzione. I proprietari del progetto possono cambiare tutto, dagli account di fatturazione ai livelli di accesso per qualsiasi altro utente, quindi questo ruolo deve essere assegnato con estrema attenzione.

Puoi creare un progetto con uno o più proprietari. Il ruolo Amministratore organizzazione può mantenere questi proprietari a livello di organizzazione. Questo ruolo di amministratore può creare progetti, modificare la fatturazione dei progetti e assegnare ruoli, il tutto senza concedere l'accesso completo al livello di proprietario a ogni singolo progetto.

Gli amministratori dell'organizzazione ricevono la maggior parte delle notifiche per tutti i progetti dell'organizzazione, anche se, per definizione, alcune notifiche sono inviate solo ai proprietari dei progetti.

Editor Un editor del progetto può eseguire azioni che modificano lo stato, ad esempio la lettura e la scrittura dei dati del progetto, l'avvio e la chiusura delle istanze oppure la lettura e la scrittura dei metadati del progetto su tutte le risorse del progetto.

Visualizzatore Questo ruolo di sola lettura potrebbe non essere utile in tutte le pipeline, ma è consigliabile assegnarlo ad alcuni account di servizio che monitorano i sistemi esterni e vi accedono. Ad esempio, i daily esaminano i sistemi che leggono le immagini, i video o le API che comunicano con i sistemi di gestione dei progetti, come Shotgun.

Ruoli predefiniti Alcuni ruoli predefiniti limitano gli utenti o gli account di servizio ad attività specifiche. Questi ruoli possono garantire che, ad esempio, un artista non abbia accesso ai dati di fatturazione di una produzione o che un assistente di produzione non sia in grado di eliminare un'istanza in esecuzione.

Utilizzo della gerarchia delle risorse per il controllo degli accessi

Puoi impostare i criteri IAM a diversi livelli della gerarchia delle risorse. Le risorse ereditano i criteri della risorsa padre. In questo modo puoi eseguire il mirroring della struttura gerarchica dei criteri IAM sulla struttura organizzativa. Consigliamo di seguire una serie di best practice per l'implementazione della gerarchia delle risorse.

Disattiva ruoli inutilizzati

Alcuni ruoli sono abilitati per impostazione predefinita e sono disponibili per l'assegnazione da parte di autori/proprietari del progetto. Per ridurre la confusione, potresti voler disabilitare i ruoli non applicabili al tuo particolare flusso di lavoro. Non puoi farlo in base al progetto, ma deve essere eseguito nelle impostazioni della tua organizzazione.

Controllo dell'accesso SSH alle istanze

Per fare in modo che le persone giuste abbiano accesso alle risorse sono necessari:

  • Sincronizzazione tra il servizio di directory e IAM utilizzando Google Cloud Directory Sync. In questo modo puoi assicurarti di avere un elenco identico di utenti e delle relative autorizzazioni sia on-premise che nel cloud.
  • Meccanismi di autenticazione utente per l'accesso SSH alle istanze, ad esempio utilizzando il modulo PAM Linux abbinato a LDAP.

Per i carichi di lavoro di rendering, consigliamo di limitare l'accesso SSH a un numero limitato di utenti, ad esempio membri del reparto IT, amministratori di sistema e wrangler di rendering.

I job inviati al cloud da un gestore di code sono generalmente di proprietà di un utente o daemon di rendering dedicato. Ad esempio, per impostazione predefinita, i job di rendering Qube! vengono eseguiti come utenti di tipo "qubeproxy". Ti consigliamo di modificare questa configurazione di Qube per eseguirla come utente che ha avviato il job, denominato 'modalità utente'. In questo modo, tutti i processi vengono eseguiti dall'utente che ha avviato il job. I rendering completati rimangono in questa proprietà.

Devi configurare la tua immagine di avvio come faresti con qualsiasi worker di rendering on-premise, con l'autenticazione eseguita utilizzando gli stessi protocolli dei worker di rendering on-premise.

Account di servizio

Un account di servizio è un Account Google speciale che può essere utilizzato per accedere ai servizi e alle risorse di Google in modo programmatico.

Per le pipeline di rendering, gli account di servizio sono utili per controllare in che modo viene eseguito il deployment o la terminazione delle istanze e nella modalità di allocazione e di esecuzione dei job sulle istanze. Il software di coda di rendering avvierà le istanze su Google Cloud utilizzando le credenziali dell'account di servizio, consentendo di avviare job sulla nuova istanza.

Quando viene creato un nuovo progetto, vengono creati diversi account di servizio predefiniti. Ti consigliamo di mantenere solo l'account di servizio denominato Compute Engine default service account, nonché gli account di servizio utilizzati dal software di coda per avviare le istanze. Fai attenzione quando elimini gli account di servizio perché potrebbero rimuovere l'accesso ad alcune risorse di progetto.

Puoi scegliere di avere account di servizio separati per singole attività di pipeline in modo da eseguire eventi basati sul programma. A questi account di servizio verrà assegnato un ruolo IAM in base all'ambito delle loro esigenze. Ad esempio:

  • Deployment di istanze da parte del gestore della coda di rendering: l'account di servizio principale per l'esecuzione di job di rendering su Google Cloud. A questo account di servizio verranno assegnati i ruoli compute.instanceAdmin e iam.serviceAccountActor.
  • Gestore risorse: un account di servizio per la pubblicazione, il recupero o la gestione dei database degli asset. Se utilizzi Cloud Storage, a questo account di servizio verrà assegnato il ruolo storage.admin.
  • Agente di logging: un account di servizio utilizzato specificamente dal meccanismo di logging del progetto, ad esempio Cloud Logging. A questo account di servizio verrà assegnato il ruolo logging.logWriter.

Ambiti di accesso

Gli ambiti di accesso sono il metodo legacy per specificare le autorizzazioni per un'istanza. Queste autorizzazioni si applicano a qualsiasi utente nell'istanza. Gli ambiti di accesso concedono le autorizzazioni predefinite da un'istanza alle API di Google. Risorse come Compute Engine e Cloud Storage sono accessibili tramite queste API.

Anziché concedere le autorizzazioni predefinite a tutti gli utenti di un'istanza, puoi utilizzare i ruoli IAM insieme agli ambiti di accesso per concedere l'autorizzazione a un singolo utente o account di servizio.

Specifica il flag --no-scopes per impedire l'applicazione degli ambiti predefiniti durante la creazione di un'istanza. Se non specifichi --no-scopes e se non viene specificato alcun ambito con il flag --scope, all'istanza verrà applicato un insieme predefinito di ambiti.

Per impostazione predefinita, le istanze iniziano con un set di ambiti, la maggior parte dei quali è necessario per accedere agli account utente IAM, leggere dai bucket Cloud Storage e scrivere i log utilizzando l'API Cloud Logging.

Quando crei una nuova istanza, vengono concessi i seguenti ambiti:

Ambito

Attività dell'API

read only

Questo ambito impedisce a qualsiasi utente sull'istanza di scrivere in un bucket Cloud Storage utilizzando l'API Compute Engine

logging.write

Consente l'accesso in scrittura alle istanze dei log di Compute Engine utilizzando l'API Cloud Logging (v2).

monitoring.write

Consenti all'istanza di pubblicare dati di metriche nei progetti di Google Cloud utilizzando l'API Cloud Monitoring (v3).

servicecontrol

Consenti all'istanza di gestire i dati Google Service Control utilizzando l'API Service Control.

service.management.readonly

Consenti all'istanza di pubblicare dati di metriche nei progetti di Google Cloud utilizzando l'API Cloud Monitoring (v3).

trace.append

Consenti all'istanza di raccogliere e scrivere dati di latenza per un progetto o un'applicazione utilizzando l'API Trace.

L'insieme predefinito di ambiti, ad esempio, non consente alle istanze di scrivere nei bucket Cloud Storage. Se la tua pipeline di rendering richiede che le istanze scrivano i rendering completati in Cloud Storage, aggiungi l'ambito storage-rw prima di avviare le istanze worker solo della visualizzazione. Tieni presente, tuttavia, che questa operazione consente agli utenti di copiare tutti i dati dall'istanza, quindi non aggiungere questo ambito alle istanze con accesso a dati sensibili.

Gestione delle chiavi di crittografia

Cloud Storage

Tutti i dati di progetto, così come tutti i dati su Google Cloud, vengono criptati at-rest utilizzando la crittografia AES128 o AES256. Puoi anche scegliere di fornire le tue chiavi di crittografia per Cloud Storage e i dischi Compute Engine.

Cloud Storage cripta sempre i dati sul lato server prima che siano scritti su disco. Per impostazione predefinita, Cloud Storage utilizza le proprie chiavi lato server per criptare i dati. I dati vengono criptati in modo granulare con una chiave di crittografia dei dati (DEK), che a sua volta è criptata da una chiave di crittografia della chiave (KEK). Le KEK sono gestite in un servizio di gestione delle chiavi centrale e vengono condivise con altri servizi Google come Gmail.

Per decriptare un blocco di dati, il servizio di archiviazione chiama il servizio di gestione delle chiavi interno di Google per recuperare la chiave di crittografia dei dati (DEK) senza wrapping per il blocco di dati:

immagine

Tieni presente che puoi anche scegliere Cloud KMS per gestire le chiavi di crittografia delle chiavi.

Anche se spesso facciamo riferimento a una singola chiave, in realtà intendiamo dire che i dati sono protetti utilizzando un set di chiavi: una chiave attiva per la crittografia e un set di chiavi storiche per la decriptazione, il cui numero è determinato dalla pianificazione della rotazione delle chiavi.

In alternativa, puoi fornire le tue chiavi di crittografia per utilizzarle in Cloud Storage e per i dischi permanenti di Compute Engine, ma a meno che tu non abbia già un servizio di gestione delle chiavi on-premise, ti consigliamo vivamente di consentire a Google di gestire e ruotare le chiavi dei dati di archiviazione, che vengono ruotate ogni 90 giorni.

Cloud KMS è un servizio di Google Cloud che consente di mantenere centralmente le chiavi di crittografia nel cloud, per un utilizzo diretto da parte dei servizi cloud. Al momento non sono presenti integrazioni a livello di archiviazione per la crittografia dei dati archiviati in altri servizi Google Cloud.

Ti consigliamo di configurare un progetto centralizzato separato per l'esecuzione di Cloud KMS per tutti i tuoi progetti.

Account di servizio

Quando crei un account di servizio, viene generata automaticamente una coppia di chiavi pubblica/privata specifica per tale account. La chiave pubblica è gestita da Google, ma la chiave privata è gestita da te. Questa chiave privata è necessaria per autenticare l'account di servizio quando esegue attività su Google Cloud.

Sicurezza della rete

Tutte le istanze di calcolo vengono create come membri di una rete virtuale Cloud. Per impostazione predefinita, tutte le reti sono reti di subnet automatiche in cui vengono create automaticamente subnet a livello di area geografica. Ogni rete è limitata a un singolo progetto; non possono esistere più progetti sulla stessa rete. Solo gli utenti con i ruoli specifici di proprietari di progetti, amministratori dell'organizzazione o amministratori di rete Compute possono modificare le proprietà di rete.

Reti e subnet

Puoi isolare le risorse su reti separate per aggiungere un ulteriore livello di sicurezza. Ad esempio, una sequenza di inquadrature con contenuti altamente riservati può essere visualizzata solo all'interno di una rete separata, isolata dal resto dei dati di progetto. I singoli progetti possono essere un modo ancora più efficace di separare i dati.

Quando crei un nuovo progetto, grazie alla funzionalità di subnet automatiche, vengono create più subnet, una per regione di Compute Engine. Quando avvii una nuova istanza in un'area geografica specifica, questa viene inserita nella subnet di quell'area geografica e viene assegnato un IP interno all'interno di quella subnet.

Regole firewall

Ogni rete ha un firewall che blocca tutto il traffico verso le istanze. Per consentire il traffico in entrata, devi creare regole di firewall.

La rete etichettata default in ogni progetto ha regole firewall predefinite, come mostrato di seguito. Nessuna rete creata manualmente di alcun tipo ha regole firewall. Per tutte le reti tranne quella predefinita, devi creare tutte le regole firewall necessarie.

Non tutte queste regole predefinite sono necessarie per una pipeline di rendering:

Regola

Nota

Suggerimento

default-allow-internal

Necessario per consentire la comunicazione tra istanze. Se il gestore della coda è on-premise, è probabile che le istanze non debbano comunicare tra loro.

Elimina questa regola se le istanze non devono comunicare con altre istanze.

default-allow-ssh

Utilizzato per consentire l'accesso tramite SSH sulla porta 22.

Elimina questa regola e creane una simile che consenta solo SSH su una VPN o un IP noto.

default-allow-rdp

necessaria solo se vuoi accedere alle istanze tramite Remote Desktop Protocol (RDP) tramite la porta 3389. Nella maggior parte dei casi l'accesso SSH è sufficiente, pertanto questa regola può essere eliminata.

Elimina questa regola, a meno che non utilizzi macchine che eseguono Windows.

default-allow-icmp

Consente la comunicazione di errori o informazioni operative sulla rete. Questa regola consente l'accesso da qualsiasi IP.

Elimina questa regola e creane una simile che consenta solo ICMP da indirizzi IP noti.

Per impostazione predefinita, le regole firewall si applicano all'intera rete. Se vuoi che due subnet si scambino il traffico, devi configurare le autorizzazioni allow in entrambe le direzioni.

Puoi integrare i tag di istanza nella tua pipeline per consentire l'accesso a tipi di istanze specifici con una regola firewall. Ad esempio, puoi taggare tutte le istanze di rendering per consentire l'accesso SSH per la risoluzione di determinati ruoli. Qualsiasi istanza assente da questo tag limiterebbe automaticamente l'accesso SSH, ad esempio al tuo server delle licenze.

Se né sourceRangessourceTags sono specificati durante la creazione di una regola firewall, il valore predefinito di sourceRange sarà 0.0.0.0/0, quindi la regola verrà applicata a tutto il traffico in entrata all'interno e all'esterno della rete.

Se non viene specificata alcuna porta durante la creazione di una regola firewall TCP o UDP, le connessioni saranno consentite da tutte le porte.

Route di rete

Tutte le reti hanno automaticamente creato route alla rete Internet pubblica e agli intervalli IP nella rete. Il traffico in uscita non è bloccato per impostazione predefinita. Solo le istanze con un indirizzo IP esterno e una route del gateway Internet predefinita possono inviare pacchetti all'esterno della rete.

Puoi accedere alle API Google Cloud (ad esempio gcloud e gsutil) solo tramite IP pubblici, quindi devi conservare la route del gateway Internet predefinita in Networking > Route.

Disattivazione degli indirizzi IP esterni

Per motivi di sicurezza, consigliamo che le tue istanze non abbiano un indirizzo IP esterno. Per impostazione predefinita, un indirizzo IP esterno viene assegnato a tutte le istanze all'avvio. Per evitare questo problema, puoi avviare le istanze con il flag --no-address.

Per fare in modo che il gestore della coda di rendering controlli le tue istanze senza un indirizzo IP esterno, devi implementare una Cloud VPN. Il gateway VPN è l'unica risorsa della tua rete con un indirizzo IP esterno, a meno che non aggiungi un router Cloud, che utilizza il protocollo gateway di confine (BGP) per trasmettere intervalli IP privati tra la rete on-premise e le reti Google Cloud.

Immagini disco

In una pipeline VFX, ti consigliamo di utilizzare un progetto separato a livello di organizzazione per la gestione delle immagini. Questo approccio impedisce la modifica dei modelli di immagine predefiniti a livello di struttura, che potrebbero essere in uso da parte di tutti i progetti. Questo approccio aiuta anche a organizzare le immagini di avvio in una posizione centrale, accessibile da tutti gli altri progetti, data l'assegnazione del ruolo appropriata.

Puoi utilizzare i ruoli IAM per condividere le immagini tra progetti. Per ulteriori informazioni, consulta la sezione Condividere immagini tra progetti.

Immagini pubbliche

Compute Engine offre molte immagini pubbliche preconfigurate che hanno sistemi operativi Linux e Windows compatibili. Ogni immagine del sistema operativo è configurata in modo da includere determinati pacchetti, ad esempio l'interfaccia a riga di comando gcloud, o i servizi sono abilitati, ad esempio SSH.

Queste immagini includono anche una raccolta di pacchetti che configurano e gestiscono account utente, oltre ad attivare l'autenticazione basata su chiave SSH.

Immagini personalizzate

Puoi creare una immagine disco personalizzata basata su un'immagine esistente. Ti consigliamo vivamente di fare in modo che le tue immagini rispettino queste best practice per la sicurezza.

Ti consigliamo di installare l'ambiente Linux Linux per Google Compute Engine per accedere alla funzionalità disponibile per impostazione predefinita nelle immagini pubbliche. L'installazione dell'ambiente guest ti consente di eseguire attività con gli stessi controlli di sicurezza dell'immagine personalizzata che utilizzi per le immagini pubbliche, come l'accesso ai metadati, la configurazione del sistema e l'ottimizzazione del sistema operativo per l'utilizzo su Google Cloud.

Connettività

Esistono diversi modi per connettersi a Google dalla tua struttura. In tutti i casi, devi implementare una rete privata virtuale (VPN). Alcuni metodi richiedono una configurazione aggiuntiva, come descritto di seguito, per garantire la trasmissione sicura dei tuoi dati.

Di seguito sono riportati alcuni metodi di sicurezza applicati ai tuoi dati:

  • Cripta i link di dati a Google utilizzando TLS con un certificato a 2048 bit generato dall'autorità di certificazione di Google.
  • Cripta i dati mentre vengono spostati tra i nostri data center sulla nostra rete privata.
  • L'upgrade di tutti i certificati RSA a chiavi a 2048 bit rende la nostra crittografia in transito per Google Cloud e tutti gli altri servizi Google ancora più efficace.
  • Utilizzare la proprietà Perfect Forward Secrecy (PFS), che aiuta a ridurre al minimo l'impatto di una chiave compromessa o una svolta crittografica.

Connessione a Internet

Puoi connetterti alla rete di Google per usufruire del nostro modello di sicurezza end-to-end semplicemente accedendo ai servizi Google Cloud su Internet. Quando viaggi in tunnel VPN, i tuoi dati sono protetti da protocolli autenticati e criptati.

Peering diretto

Google ospita l'infrastruttura di networking perimetrale in più di 100 strutture POP in tutto il mondo a cui i clienti Google Cloud possono collegarsi direttamente. Qualsiasi cliente Google Cloud che abbia un ASN pubblico e un prefisso IP pubblicamente instradabile è benvenuto alla peer con Google. Questa opzione utilizza lo stesso modello di interconnessione della rete Internet pubblica.

Cloud Interconnect

Per i clienti che non hanno ASN pubblici o che vogliono connettersi a Google utilizzando un provider di servizi, il servizio Cloud Interconnect è un'opzione. Cloud Interconnect è indicato per i clienti che vogliono una connettività di livello enterprise al perimetro di Google. I provider di servizi partner Cloud Interconnect contribuiscono a fornire connettività di livello aziendale in uno dei due modi seguenti:

  • Tramite le connessioni in peering esistenti, gestite congiuntamente, per garantire prestazioni elevate e bassa latenza.
  • Tramite interconnessioni dedicate che hanno come target solo il traffico dei clienti di Google Cloud (anche se Google annuncia route per tutti i servizi su questi link).

Cloud VPN

Le pipeline di rendering on-premise non criptano sempre i dati in transito. Per una pipeline di rendering cloud ibrida, tuttavia, consigliamo di criptare tutti i dati in transito.

Indipendentemente da come sei connesso a Google, devi proteggere la tua connessione con una VPN. Cloud VPN connette il gateway VPN peer alla tua rete Google Cloud tramite una connessione VPN IPsec. Il traffico tra le due reti è criptato da un gateway VPN, quindi viene decriptato dall'altro gateway VPN. Questo contribuisce a proteggere i tuoi dati mentre viaggiano su Internet e non richiede l'implementazione della crittografia dei dati nell'ambito della tua pipeline di rendering.

Se la tua struttura ha più località o reti, puoi mantenere sincronizzati i tuoi percorsi tra queste località e la tua VPN Cloud utilizzando un router Cloud.

VPN fornita dal cliente

Puoi configurare il tuo gateway VPN in Google Cloud, ma è meglio utilizzare Cloud VPN per una maggiore flessibilità e una migliore integrazione con Google Cloud.

File system

Sono disponibili diverse opzioni di file server per la gestione dei dati. A seconda della metodologia di pipeline, potrebbe essere necessario implementarne più di una.

Basato su oggetti

Cloud Storage è lo spazio di archiviazione a oggetti unificata che è appropriato per tutti i dati generati o consumati in tutta la pipeline di rendering. Poiché fa parte di Google Cloud, Cloud Storage può sfruttare le funzionalità di sicurezza di Google Cloud, come il controllo dell'accesso, IAM e la crittografia.

Quando la località in cui crei il bucket è un'area geografica, i dati all'interno del bucket sono accessibili a livello globale alle entità con le autorizzazioni appropriate, ma vengono archiviati all'interno di un data center specifico. Dal punto di vista delle prestazioni, è meglio mantenere l'archiviazione e il calcolo nella stessa area geografica per una migliore velocità effettiva e una latenza inferiore.

I dati su Cloud Storage sono disponibili a livello globale, pertanto puoi condividere i dati con un'altra struttura in un'altra parte del mondo senza richiedere la replica. Potrebbero essere applicati ulteriori addebiti in uscita. Poiché questi dati sono accessibili a livello globale, è essenziale gestire i tuoi ambiti VM, utenti e chiavi di accesso in modo appropriato per evitare che i dati vengano sottoposti a escape dalla pipeline di rendering.

Potresti dover adattare la pipeline di gestione degli asset per interfacciarti con l'architettura basata su oggetti di Cloud Storage.

Conforme a POSIX

I dati di produzione in tempo reale sono spesso archiviati su un file server conforme a POSIX, ideale per le pipeline di rendering che richiedono l'accesso ai metadati dei file, come i tempi di modifica, o che si basano sui percorsi dei file per le risorse di scena.

A seconda delle esigenze e del carico di lavoro della struttura, hai a disposizione alcune opzioni per l'implementazione di un file system NFS.

Server di file a nodo singolo

Un server NFS conforme a POSIX è disponibile come soluzione click-to-deploy. Puoi eseguire più file server a nodo singolo e montarli sulle tue istanze. Ciò significa che puoi isolare lo spazio di archiviazione per ogni porzione della pipeline, limitando l'accesso a livello di utente e di gruppo del sistema operativo nello stesso modo dei file system on-premise.

Puoi anche proteggere i dati su file server a nodo singolo montandoli come di sola lettura sulle istanze di rendering. Il software, gli strumenti di pipeline e le librerie di asset non devono mai essere modificati da un'istanza di rendering, quindi il montaggio come di sola lettura è un modo semplice per applicare questa restrizione.

Per proteggere ulteriormente il tuo progetto, puoi anche eseguire il deployment di un singolo nodo file per rete, poiché le istanze possono montare file server solo sulla stessa rete.

Puoi anche creare snapshot del tuo software o disco della pipeline per eseguire il rollback rapido alle versioni precedenti con un impatto minimo sulla produzione.

Altri file system

Con Google Cloud sono disponibili altri file system di terze parti, come file system in cluster e di memorizzazione nella cache. Consulta la documentazione di conformità del singolo fornitore per la sicurezza sui file system di terze parti per la memorizzazione nella cache.

Sicurezza dello spazio di archiviazione

Per impostazione predefinita, Cloud Storage gestisce le chiavi di crittografia lato server per tuo conto, utilizzando gli stessi sistemi di gestione delle chiavi con protezione avanzata che utilizziamo per i nostri dati criptati, inclusi controlli di accesso alla chiave e controlli rigorosi. Cloud Storage cripta i contenuti at-rest dell'utente e ogni chiave crittografica è a sua volta criptata con un set di chiavi principali ruotate regolarmente.

Tutte le classi di archiviazione supportano gli stessi controlli di accesso OAuth e granulari per proteggere i tuoi dati.

Consigliamo di utilizzare IAM per limitare l'accesso ai dati all'interno dei bucket Cloud Storage o di un progetto. Puoi anche utilizzare gli elenchi di controllo dell'accesso se devi gestire solo un numero limitato di oggetti.

Opzioni di trasferimento

La sicurezza dei dati in transito si riferisce alla sicurezza dei tuoi dati in quanto passa continuamente dal tuo spazio di archiviazione on-premise al cloud. Esistono numerose metodologie di pipeline che consentono di gestire lo spostamento dei dati tra on-premise e nel cloud, la cui progettazione e implementazione non rientra nell'ambito di questo documento. Tutti i metodi di trasferimento descritti di seguito (ad eccezione dei metodi di trasferimento di terze parti) vengono eseguiti all'interno della suite di sicurezza completa di Google per l'autenticazione e l'autorizzazione.

Riga di comando

Per trasferire dati da o verso Cloud Storage, ti consigliamo di utilizzare il comando gsutil per copiare, spostare o sincronizzare i dati di dimensioni inferiori a 10 TB. Il comando gsutil utilizza le stesse funzionalità di sicurezza e l'autenticazione di Google Cloud, rispetta i ruoli IAM ed esegue tutte le operazioni utilizzando la crittografia a livello di trasporto (HTTPS). gsutil supporta anche i caricamenti paralleli.

Per effettuare il trasferimento da o verso file system compatibili con POSIX, come i file server a nodo singolo e il disco permanente, ti consigliamo di utilizzare scp o rsync attraverso una connessione VPN.

UDP

Se scegli di utilizzare una terza parte, Data Transfer Protocol basato su UDP per caricare i dati direttamente in un bucket Cloud Storage, ad esempio Aspera, Cloud FastPath, BitSpeed o FDT, consulta la documentazione della terza parte per conoscere il modello di sicurezza e le best practice. Questi servizi di terze parti non sono gestiti da Google.

Cloud Logging

Cloud Logging ti consente di monitorare e registrare una varietà di attività all'interno del tuo progetto o della tua organizzazione. Cloud Logging è stato originariamente scritto per applicazioni e servizi web, ma può essere utilizzato come server di logging per una pipeline di rendering, offrendo un punto di raccolta per l'enorme quantità di dati generati dal rendering dalla riga di comando.

L'API Cloud Logging non è abilitata per impostazione predefinita sui nuovi progetti Google Cloud. Consigliamo di abilitare l'API Cloud Logging, in modo che Cloud Logging possa fungere da server di logging per le applicazioni esterne.

L'audit logging ti aiuta a monitorare le attività amministrative utilizzando la console o l'API per modificare la configurazione o i metadati di un servizio o progetto. Non puoi modificare o eliminare gli audit log.

Tutti i log vengono conservati per un periodo di tempo specificato, dopodiché vengono eliminati. I criteri per le quote di Cloud Logging spiegano per quanto tempo vengono conservate le voci di log. Per conservare i log oltre il periodo di conservazione, puoi esportarli in un bucket Cloud Storage, un set di dati BigQuery, un argomento Cloud Pub/Sub o una qualsiasi combinazione dei tre.

I log vengono raccolti da singole istanze tramite l'agente Logging, che non è installato per impostazione predefinita. Le istruzioni per l'installazione sono disponibili qui.

Altre considerazioni

In questa sezione vengono trattati gli argomenti che non fanno parte della linea di prodotti Google, ma che in genere fanno parte di una pipeline di rendering ibrido.

Gestione della coda

Molti studi utilizzano un gestore di code per controllare il deployment, il monitoraggio e le attività di cui viene eseguito il deployment in una farm di rendering on-premise. A volte puoi utilizzare lo stesso gestore coda per eseguire il deployment dei job in Google Cloud. L'approccio specifico potrebbe variare a seconda del software utilizzato.

Alcuni gestori di code forniscono plug-in per software per consentire ai server e ai client di connettersi a Google Cloud. Consulta la documentazione di terze parti per esaminare le misure di sicurezza adottate.

Le istruzioni inviate a Google Cloud dal gestore della coda devono essere inviate utilizzando il comando gcloud. Se devi inviare comandi utilizzando ssh,, devi generare una chiave SSH per la comunicazione. Per evitare questo problema, potresti voler eseguire il server di gestione della coda su Google Cloud, anziché on-premise.

Automazione della creazione e della terminazione delle istanze

In alcuni casi, potresti automatizzare la creazione delle istanze all'avvio di un job e al termine dell'istanza al termine del job. Per motivi di sicurezza e costi, evita di mantenere le istanze in esecuzione quando non esegui un job.

Software personalizzati

Le pipeline di rendering includono in genere sia software di terze parti che personalizzati. I software personalizzati possono includere qualsiasi cosa, dagli script semplici agli elementi binari complessi e compilati con più dipendenze.

Per manipolare le istanze di Google Cloud dall'interno di script o programmi, utilizza le librerie client disponibili. Ogni versione fornisce i metodi per l'autorizzazione con OAuth 2.0.

Licenze

Server licenze on-premise

Il tuo server di licenze on-premise può contribuire a fornire un ambiente più sicuro se stai eseguendo una VPN. Il livello di sicurezza è ancora soggetto alle limitazioni della tecnologia di gestione delle licenze in uso.

Server licenze Cloud

Se esegui il tuo server di licenze su Google Cloud, ti consigliamo di eseguirlo su una rete separata per consentire un ulteriore controllo e monitoraggio.

Passaggi successivi