Loading

Alison's New App is now available on iOS and Android! Download Now

Module 1: Non puoi Secure il Cloud Right?

Study Reminders
Support
Text Version

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Comprendere Autenticazione e Autorizzazione
In questa prossima lezione si impara a sfruttare l'autenticazione e l'autorizzazione con Google Cloud IAM per migliorare la sicurezza della propria infrastruttura cloud e gestione degli accessi o Cloud I am consentono agli amministratori   di autorizzare chi può fare cosa su quale risorsa in cloud Google. Le policy di IAM possono applicarsi a molti tipi di utenti come le risorse. I soggetti che fanno parte di una IAM e policy possono essere un account Google o un utente di identità Cloud, un account di servizio o un gruppo Google o un intero dominio identity o Cloud identity. Molti utenti vengono avviati collegando la console GCP con un account Gmail personale. Per collaborare con i loro compagni di squadra usano i gruppi di Google per raccogliere insieme persone che sono nello stesso ruolo, questo approccio è facile per ottenere STARTED ma i suoi svantaggi il team s identity aren t t centrally - è riuscito ad esempio se qualcuno lascia l'organizzazione o il team non c'è un modo centrale per rimuovere immediatamente il loro accesso alle risorse del club. Gli utenti GCP che sono anche utenti GSuite possono definire le politiche di Google Cloud in termini di GSuite   utenti e gruppi in questo modo quando qualcuno lascia l'organizzazione un amministratore può immediatamente disabilitare il proprio account utilizzando la console admin di Google Cloud per g suite. Gli utenti GCP che non sono utenti GSuite possono acquisire le stesse funzionalità tramite l'identità cloud. L'identità cloud consente agli utenti e ai gruppi di essere gestiti utilizzando la console admin di Google Cloud ma i prodotti di collaborazione di g suite come Gmail, frecce, drive e calendario aren incluso per questo motivo l'identità cloud è disponibile gratuitamente ma cosa se si ha già un sistema di gestione e identità centralizzato come Microsoft active directory o elder. La sincronizzazione delle directory cloud di Google può aiutare questo strumento di sincronizzatori di utenti e gruppi da una directory attiva esistente o da un sistema LDAP che mappano gli utenti e i gruppi in un dominio di identità Cloud questa sincronizzazione è solo una sola modalità anche se la sincronizzazione delle directory cloud non può modificare le informazioni nei sistemi Microsoft active directory o ldap. La sincronizzazione delle directory cloud è in genere programmata per eseguire senza supervisione su un intervallo fisso come ogni 24 ore che abbiamo citato l'identità cloud citata qualche volta ora lasciamo che i like si tuffino in un po' più di dettaglio. L'identità cloud è un accesso unificato e l'identità cloud della piattaforma di gestione dei dispositivi è un'identità come soluzione di servizio che utilizza un servizio per la gestione dei gruppi di utenti e delle impostazioni di sicurezza. L'identità cloud può essere utilizzata come fonte centrale per le impostazioni a livello di dominio. L'identità cloud è associata ad un dominio pubblico unico può funzionare con qualsiasi nome di dominio abilitato alla ricezione di messaggi email ora che abbiamo parlato di The who let's can do what part of IAM. Il può fare ciò che parte è definito da un ruolo IAM che è una raccolta di permessi IAM, i permessi sono molto bassi e fine-grinzato ad esempio per gestire la macchina virtuale servono i permessi per creare cancellazione, arrestare, avviare e modificare un'istanza per rendere questo processo più facili i permessi sono spesso raggruppati in un ruolo IAM per renderli più facili da gestire. Sono costruiti in ruoli a disposizione di tutti gli utenti gcp e si possono anche costruire i propri e personalizzare i propri ruoli per la propria organizzazione. Infine lasciare che i m discutano sul quale parte la risorsa parte di IAM quando si dà un gruppo di utenti o i permessi di account di servizio su un elemento specifico della gerarchia delle risorse la politica risultante si applica all'elemento scelto così come gli elementi sotto quella risorsa nella gerarchia, ci sono tre tipi di ruoli e il cloud IAM primitivo, predefinito e personalizzato. Lasciati parlare di ognuno di essi a turno, le regole primitive IAM si applicano a tutte le risorse gcp in un progetto questi ruoli primitivi includono proprietario, editor, revisione e fatturazione admin. Se sei un viwer puoi esaminare le risorse ma non puoi cambiare il loro stato. Se ti trovi di nuovo un editor puoi fare tutto ciò che un viwer può fare più modificare lo stato e se il tuo proprietario è possibile fare tutto ciò che un editor può fare più gestire ruoli e permessi. Il ruolo proprietario di un progetto ti dà anche il controllo sulla funzionalità di fatturazione e gestione dei costi, spesso l'organizzazione vuole che qualcuno sia in grado di controllare la fatturazione per un progetto senza il diritto di modificare le risorse in quel progetto. È possibile concedere a qualcuno il ruolo di amministratore di fatturazione che concede l'accesso alle informazioni di fatturazione ma non concede l'accesso alle risorse all'interno del progetto. I ruoli predefiniti di IAM si applicano a un particolare servizio gcp in un progetto. Il servizio GCP viene offerto il proprio set di ruoli predefiniti e definiti sono quei ruoli possono essere applicati ad esempio il motore di elaborazione di Google offre una serie di ruoli predefiniti e puoi applicarli per calcolare le risorse del motore in un determinato progetto una determinata cartella o l'intera organizzazione. Un altro esempio è il cloud big che è un grande tavolo di servizio di database gestito e offre regole che si applicano su un'intera organizzazione, a un determinato progetto o anche singole istanze di database bigtable cloud. I ruoli predefiniti di IAM offrono permessi più fini su servizi particolari. Il ruolo admin dell'istanza del motore di Google compute consente a chi lo ha di eseguire una certa serie di azioni sulle macchine virtuali in questo esempio tutti gli utenti di un certo gruppo Google hanno il ruolo e lo hanno su tutte le macchine virtuali un progetto. L'ultimo tipo di ruolo IAM è un ruolo personalizzato per alcune organizzazioni i ruoli IAM primitivi e predefiniti potrebbero non offrire abbastanza granularità. I ruoli personalizzati di IAM consentono di creare le proprie regole che sono composte da autorizzazioni molto granulari. In questo esempio abbiamo definito un nuovo ruolo personalizzato chiamato operatore di istanza che consente agli utenti di avviare e arrestare le istanze ma non gli consente di cancellare o riconfigurare in questo momento ruoli personalizzati possono essere applicati solo a livello di progetto e organizzazione, non è attualmente possibile applicare regole personalizzate a livello di cartella. Un altro concetto importante legato alla gestione dell'identità e dell'accesso sono i conti di servizio, il servizio di controllo dei conti di servizio alla comunicazione di servizio affinché i servizi interagiscano tra loro hanno bisogno di qualche tipo di identità. Gli account di servizio sono utilizzati per autenticare il servizio alla comunicazione di servizio con gli account di servizio è possibile dare un accesso a livello di ruolo da un servizio all'altro. Supponga di avere un'applicazione in esecuzione in una macchina virtuale che deve accedere ai dati e alla memoria cloud si desidera solo che quella macchina virtuale abbia accesso a tali dati. È possibile creare un account di account di servizio autorizzato ad accedere a tali dati nella memoria cloud e quindi allegare tale account di servizio alla macchina virtuale. Gli account di servizio sono denominati con un indirizzo email di tendenza che termina in gserviceaccount.com   in questo esempio di account di servizio è stato concesso il ruolo admin dell'istanza, questo permetterebbe un'applicazione in esecuzione in una macchina virtuale con quell' account di servizio per creare, modificare ed eliminare altre macchine virtuali. Gli account di servizio incidentalmente devono essere gestiti troppo per esempio forse Alice ha bisogno di gestire una sorta di account di servizio mentre Bob deve solo essere in grado di visualizzare ciò che un particolare account di servizio può fare. Fortunatamente oltre ad essere un'identità un account di servizio è anche una risorsa in modo da poter disporre di politiche IAM di proprio attaccamento. Per esempio Alice può avere il ruolo di editor su un account di servizio e Bob può avere il ruolo di visualizzatore. Questo è proprio come concedere ruoli per qualsiasi altra risorsa gcp come una macchina virtuale. È possibile concedere alle macchine virtuali diverse identità. Questo rende più facile gestire differenti permessi di progetto attraverso le proprie applicazioni.   È anche possibile gestire le autorizzazioni dei conti di servizio senza dover ricreare le macchine virtuali. Qui si parla di uno scenario più complesso si dice che si ha un'applicazione che si trova implementata su un gruppo di macchine virtuali un componente della propria applicazione richiede il ruolo di editor su un altro progetto, progetto B, ma un altro componente doesn ha bisogno di autorizzazioni sul progetto B. Si vorrebbe creare due account di servizio diversi uno per ogni sottogruppo di macchine virtuali in questo esempio VMs in esecuzione su componente uno o concesso accesso di editor al progetto a B utilizzando l'account di servizio uno. Le macchine virtuali che eseguono il componente a due sono concesse l'accesso al visualizzatore di oggetti a un bucket che utilizza un account di servizio due permessi di account di servizio possono essere modificati senza ricreare le VM.