Google Cloud Platform - corso

Cloud foundations kickoff

Identity management

target: gestire le utenze in modo sicuro forte controllo su chi può accedere e cosa può fare autenticazione sincronizzazione nostre utenze (magari Active Directory) su Google Cloud per avere unica sorgente di verità importanza delle utenze nominali (chi fa cosa) anche per avere audit utili auditing è in alcuni contesti nemmeno disattivabile su Gcp

Cloud Identity

è forma di gsuite ma molto ridotta, scopo: creare identità che possa fare login con google (poi non avrà gmail, drive, calendar) non costose (meno di gsuite), ma da non consentire accessi con account esterni, in modo da avere > controllo sulle utenze collegabili che possa cmq: usare GCP, chrome.. vengono gestite dallo stesso pannello gsuite (single pane of glass) si possono cmq anche gestire con pannelli diversi per poter gestire domini diversi Users - Groups - Org Units (sotto cartelle, per partizionare le utenze/policy che si applicano su quelle cartelle in giù) Il Provisioning (come creare queste Cloud Identity) : manuale da pannello o via api, o caricare csv Cloud IAM (associare Cloud Idendity con cosa può fare) Cloud Identity : admin.google.com (managing User, groups, auth settings) GCP : console.cloud.google.com (gestire risorse e autorizzazioni) indrizzo mail : classificatore utenze (importante il dominio) domini e alias domini (xxx.com e xxx.co.uk) dominio principale (ma poi possibili domini secondari) per fare un setup di questa CI, dominio GSuite? -> policy richiedono segregazione degli admin? se mettiamo risorse sullo stesso dominio chi ha permessi massimi su GSuite -> avrebbe anche permessi massimi anche su risorse dello stesso dominio si potrebbe creare quindi un nuovo dominio e creare altri superadmin per avere risorse non associate allo stesso dominio (gcp.credem.it) su gcp possiamo, volendo, dire che utenze credem.it possano accedere a gcp.credem.it (le puoi autorizzare ma per lui sono cmq esterne) Cloud Identity free vs premium (più basso di gsuite ma non troppo) free non vuol dire che sono illimitate, proporzionate al numero di gsuite presenti, la differenza più evidente è la non presenza di SLA massimi ruoli sui due pannelli: (CI) Super Admin vs (Cloud IAM) Org. Admin Super Admin può darsi Org. Admin su GCP (ma non il contrario) Super Admin dovrebbe essere nominale e non dovrebbe essere l'utenza che si usa tutti i giorni (disabilitato il SSO su quell'account, così può accedere sempre sicuramente [anche se ldap sincronizzato non funzionasse]) Un CI Domain aiuta a dare a colpo d'occhio una parte di utenze, es: @fornitori.credem.it non si può avere un secondo pannello senza un altro dominio Si consiglia di avere dai 2 ai 3 Super Admin

User authentication options

Google Authentication (no SSO)
SSO - Google Auth + Cloud Identity as Identity Provider
SSO - External Identity Provider

hardware tokens : chiavette sicure Google cloud directory sync (GCDS) : sincronizza utenze esterne per sapere internamente la lista utenti su Google (a scadenze regolari), one way sync (può sincronizzare anche i gruppi o ou per riportare la gerarchia) Evitare possibilmente utenze google consumer account (@gmail.com), non gestisco io e se bucato è in gestione a lui e comunque se solitamente richieste maggiori sicurezze lui potrebbe comunque entrare solo con utenza e pwd meglio se account google di un cliente, meglio ancora se gestiti internamente con CI Esiste un tool di trasferimento, tutta la sua roba può essere portata su altri utenti (es caso di licenziamento)

Auditing

Admin security tab : audit security settings come monitor password strength, 2SV status, auth/revoke access to approved oauth applications Audit reports: log su azioni relative all'identità Custom alerts: notifications per login sospetti, admin console changes... Reports API: log per user login, document sharing, email usage... User security review: validation check, review della conf per la gsuite Security center : centralizza log ecc e review automatica di eventuali attacchi o configurazioni non corrette

Demo admin.google.com

Console contiene servizi GSuite, se fosse solo Cloud Identity ci sarebbe meno cose Utenti, gruppi, applicazioni, gestione policy accesso all'account (,fatturazione) applicativi/servizi che si possono anche attivare/disattivare per unità organizzativa Gruppo: unione utenti, service account e altri gruppi buona norma avere gruppo "admin gcp" i gruppi devono essere identificati da almeno un indirizzo mail, si indica anche owner del gruppo (chi può gestirlo) Da questa console puoi gestire policy di accesso per gli account ma solo per gli account aziendarli non esterni (tipo usare 2fa o SSO [quindi appoggiandosi a SSO esterno a google]) i super admin sono anche super admin di gcp di default (per lo stesso dominio), per questi se attivata la SSO l'accesso è fatto senza SSO (per sicurezza di poter loggarsi sempre) NON dovrebbero essere mai account personali questi super admin, ovvero un account dedicato sotto i super admin ci sono gli admin, quindi con SSO e il resto (tranne piccole cose, tipo chiudere account ecc) si possono attivare notifiche per login "strani" o attivazione di permmessi sospetti ecc si può attivare la protezione avanzata per alcune utenze context aware assets : limitare accessi alla piattaforma per gestione geografica, limitare dai soli ip aziendali (tipo vpn interna), verifiche su client win10 e certa versione o solo se non ho proxy settati sul browser ecc google adotta approccio "zero trust" : non solo quello che dentro ok e esterno male, ovvero non ho un perimetro che do per sicuro, in primis auth utente e suoi permessi personali si può fare il controllo e gestione dei device: quali dispositivi possono avere accesso, con i dispositivi aziendali si può avere controllo totale (anche disattivare fotocamere) si possono gestire anche delle policy anche su endpoint pià classici: win10 e macos dispositivi chrome (chromebook) browser gestiti data loss prevention : si possono mettere anche degli alert su condivisione di documenti di dati sensibili (con algoritmi di AI di google)

Key components

Resource Management

Naming delel risorse (meglio avere una naming convention) Ogni servizio deve appartenere necessariamente a un progetto, potenzialmente tutti i servizi sono sempre disponibili e attivabili sul progetto i progetti non costano, questi contenitori sono separati tra loro a compartimenti stagni, posso settare policy, per questo sono obbligato a creare un prog (diventandone owner) (questo si può fare anche con un GMail qualunque) Organization è il mio nodo radice, quando creo un progetto questo viene associato al nodo radice, le policy posso darle anche al nodo radice propagandole a tutto il resto Le organizzazioni possono avere progetti ma anche uno strato ulteriore: cartelle e sottocartelle (di progetti) i diritti all'interno di GCP sono sempre additivi, non è mai possibile togliere un permesso maggiore a un livello più alto. Meglio espandere i permessi ai livelli più bassi dell'albero è possibile condividere risorse condivise tra più progetti (es: networking), questo è possibile solo se sopra c'è una folder o una organizzazione (no quindi su classico GMail) ci sono modi per mettere in comunicazione due progetti, tipo creare vpn o equivalenti sulla rete google i progetti possono essere fatti per ambienete: dev, test, prod (per poter decidere accessi specifici) ci sono alcune risorse che accettano policy IAM (prima il livello più basso era il progetto) Folder : di solito si usano per suddividere gli accessi gcp per dipartimento o privilegi, max 10 livelli (ma consigliat non più di 4). In qualunque momento si possono muovere folder e progetti in altre folder, ma ci sono implicazioni da considerare Organization policies : constraint che ogni cliente dovrebbe avere:

compute engine -> external ip (limitare se possibile), skip default network conf, require os login (se sospendo l'utente anche se ha accesso via ssh key viene precluso l'accesso in questo modo)
cloud iam -> domain restricted sharing : assicurare accessi solo da utenti in whitelist domains
gcp : resource location restriction (impossibilità di posizionare risorse in altre aree rispetto alla selezionata)
cloud storage : enforce bucket policy only (per retrocompatibilità non si comporta come tutto il resto, mettendo questa policy obbligo lo storage ad avere gli stessi permessi e che non ce ne siano nascosti e specifici per lo storage)

Organization policy hierarchy evaluation che succede se due policy sono in conflitto? a differenza dalle policy iam qui non siamo solo additive qui si possono rimuovere nell'albero "restore default value" : impostazione predefinite dell'organizzazione si può disattivare l'ereditarietà del padre oltre a restore default value prima si guardano le org policy, poi il parent e poi se non posso leggere da questi due -> torno al default se faccio un DENY questo ha sempre la precedenza

Sui log non posso dare permessi su risorse specifiche, va su progetto, quindi se non posso far vedere certi log devo fare progetti diversi

Function-oriented hierarchy (dividere funzionalmente) App > Prod | Test > projects consente separazione per Shared Services... Attenzione a usare un progetto per ogni enviroment (anti pattern): blast radius (potrebbe impattare tutto l'ambiente), separation of duties: all'interno di un prog possono esserci "oggetti" con dati che non c'entrano tra loro environment-oriented hierarchy: divisi per prod, test, dev (ma non è detto che tutti i team di prod debbano vedere tutti i prog di prod..) granular access-oriented hierarchy - BU first (consigliata solitamente: common pattern, non best practice, dipende dall'azienda) prima divisione aziendale (retail, risk mgmt, financial..), poi funzionale (apps, sandbox, shared...), poi Env (prod, dev..), poi projects granular access-oriented hierarchy ENV first : altro common pattern simile: Env, divisione aziendale, funzionale

One project for each application and environment : pattern comune e valido

Progetto identificato da: project name (user assigned, non unico globally, modificabile) - project ID (user, globally unique) : lettere minuscolo numeri e '-' - project number (globally unique, google defined) prj id vs prj num : prj id è unico in tutto il mondo ma se lo cancello poi si potrà riutilizzare, il prj num è assegnato da google e resta e persiste anche dopo la cancellazione

a possible naming convention : "company-department-product-env" occorre stabilire anche un workflow di approvazione per fare modifiche

Resource quotas la maggior parte delle quota sono applicati per progetto basate sulla location delle risorse Le risorse nascono con dei limit quota di default Cloud Monitoring aiuta a tener sotto controllo le soglie le soglie sono incrementabili con richieste verso google, prima sono valutate da una intelligenza artificiale, se la richiesta è un po' particolare o non sufficientemente giustificata c'è una revisione umana (un paio di gg circa), quando creo un prj dovrei considerare il caso pessimo ed eventualmente chiedere per tempo l'espansione, la richiesta è fatta da cansole, in caso di urgenza si può fare una emergency request (da usare il meno possibile)

Access

Access Management

Assicurasi che solo le giuste psersone e servizi siano autorizzati per fare le giuste azioni e sulle giuste risorse

IAM policy una polici ha una tripla di elementi (+1 opzionale) : Identity (user, group, service account, org), IAM role, Resource elemento opzionale (aggiunto di recente): Condition (condizione entro cui far valere la policy) IAM roles: primitivi (google: editor, owner, viewer), predefiniti (google, more granular based on job function), custom (user defined) role: collection of permission may be assigned to one Identity owner > editor > viewer > browser

project browser si può mettere anche a livelli diversi (non solo sul proj), Organization admin invece sarà possibile metterlo solo su org -> un ruolo di livello inferiore può essere messo anche sopra, uno superiore non può essere messo sotto browser su un proj : vede solo la dashboard e gerarchia progetto, non può vedere risorse (serve solo per far cliccare il prj a un utente, utile per fare il least priviledge -> questo come base e poi vengono dati permessi specifici)

Custom roles: provide granular control over the exact permission provided to a role (es: abilitazione api per ricerca prodotti), si possono applicare anche a org level

Context aware : libreria da cui attingi per costruire le tue condizioni (trasversale, ma applicabila a singolo prj)

ORG-level groups : Org Admin, Network admin, Security Admin, Billing admin più trasversali, in genere non creano ma controllano

Folder e project-level groups : SRE/DevOps, Developers, Data Analysts

Gestione accessi macchine virtuali : fatta la macchina e aperte le porte per accedere, poi è demandato al OS l'accesso e qui Google non può controllare più. Google ti può dare aiuto iniettando chiavi sulla macchina linux ad esempio. Al momento è possibile, solo per linux, è possibile tramite IAM gestire l'accesso alla macchina centralizzando lato google. In questo modo se ho 100 macchine e un utente se ne va lo tolgo e istantaneamte su tutte non potrà più accedere.

Nella pagina IAM la colonna Inheritance è visibile popolata solo se si è org admin o hai permessi per cambiare la gerarchia dei permessi

Google Docs - pagina Understanding roles dove ci sono le classificazione dei ruoli e permessi, utili quindi per dare permessi

serviceaccount : nome utente + identificativo prj (da google) + 1 o più chiavi da tenere in sicurezza (con magari politiche di rotazione) un SA è sia un Identity che ha permessi con i SA user role, ma è anche una risorsa (e in quanto una risorsa di un progetto occorre avere i permessi per quella risorsa per poterla creare e configurare)

Service account key management : pensate per machine to machine (?), certificato per ogni SA (può averne N per ogni SA), non posson essere scaricate, automaticamente ruotate. User managed keys : create, scaricabili, gestite dagli utenti. rotate/audit via api (a carico dell'utente) hanno maggiore validità dei token (1h) Key roatator: prodotto google messo open source, si occupa di rotazione e archiviazione sicura delle chiavi dei SA, alternativa alla gestione automatica di Google. Esistono anche altri strumenti esterni: HashiCorp Vault (creatori anche di Terraform), servizio a pagamento. Best practice per i SA:

vita breve per le credenziali dei SA; tipi solitamente usati: OAuth2.0 e OpenId Connect ID. con token, entrambi, di 1h
evitare di usare il service account di default del Compute Engine (creato da google in automatico), meglio usare uno custom con i permessi al minimo
i SA possono essere usati per regole di Firewall, il sorgente della regola può essere un tag, .., ma anche un SA; posso dire che tutte le macchine che usano quel SA hanno quel tipo di permesso, possono differenziare permessi quindi all'interno della stessa network (in base ai SA usati)
meglio creare SA in prj dedicati alla creazione dei SA
no embed SA keys all'interno del codice
fare auditing delle chiavi genereate e utilizzate (c'è uno strumento per questo che aiuta per fare l'inventario: Forseti. C'è anche la versione gestita da Google [Google Cloud Security Command Center, che fa di + di Forseti] (sw che fa capo alla org). Si può anche far controllare che non ci siano chiavi vecchie (più vecchie di tot, si può fare una regola)

Forseti security fa scansioni anche in base a policy e notifica le violazioni, si possono fare anche enforcement di queste policy. risultati su diversi canali (chat, mail, slack.. e bucket) le regole sono per ORG ma si possno mettere dei filtri, tipo se il progetto inizia per... ecc Regole solitamente usate (esempi):

controllo sulle condivisioni e che rispettino access policy (su BigQuery, Cloud Storage..), esempio evitare "all users" policy, concedere accesso solo a SA in prod env
google group e setting: forsety riesce a esploderei i gruppi per vedere se ci sono violazioni sulle policy (chi può far parte di gruppi, chi può invitare, whitelist/blacklist)
SA key : audit maximum age
networking: firewall rules e instance network interface - disallow permessive rules, ensure instances with extetrnal ip siano in whitelist...
Resources : verifiche sulla location delle risorse
Logging : logging level, export, retention, tipo assicurarsi che log siano attivi nei prj, i log siano esportati...

Cloud Security Command Center : ha anche meccanismi di rilevazione automatica di problemi, tipo se macchina bucata e installato un crypto mining

Organization policies : policies applicate a org, folders e prj

Policy Intelligence (Beta) : G sta cercando di creare strumenti per ridurre i rischi e suggerisce come modificare ruoli pe permessi (es: anche in base all'utilzzo dei permessi che realmente un utente sta usando) viene usati algo di Google ML e AI Troubleshooter - ti suggerisce in caso non si riesca a fare una certa azione Validator : monitoraggio per correggere alcuni comportamenti che stanno avvenendo (poi eventualmente si potrà fare un enforcement)

Networking

VPC networks

subnet è il vero spazio di indirizzamento. una compute engine verrà associata una subnet da cui staccherà il suo indirizzo ip. macchine sulla stessa subnet possono comunicare tra loro in alto throughtput. Vpc è un contenitore di subnets. tra loro le subnet non possono avere indirizzi in collisione. prima faccio la subnet poi le macchine. Regione = datacenter. Tutti i datacenter di G si dividono in partizioni: Zone. tutte dentro la singola zona è ancora più efficiente. due zone in stessa region possono avere anche tecnologie diverse e centrali di alimentazioni diverse.

classi di indrizzi (cidr) : https://it.wikipedia.org/wiki/Classi_di_indirizzi_IP

Private Google access

si può far abilitare alle solo api google (ma non internet)

Cross project communication

Shared VPC

es: un prj (di host) di network di prod che condivide con altre app di prod e quando creaiamo le macchine virt di ogni prj (di service, chi usano la networkd i host) useremo la network del prj host. La usiamo se vogliamo centralizzare la gestione della network (e magari i prj che la devono usare hanno solo accesso alla possibilità di usarla, nient'altro).

VPC Peering

tutti i prj, host e service, deve essere nella stessa org. in pratica puoi creare dei tunnel, ad esempio, tra prj diversi con network diverse, in modo che magari si possa accedere a un servizio centralizzato. Le due reti posson essere dello stesso prj (ma diverse). si possono anche creare due proj shared vpc e metterli in peering

Cloud VPN

tutti i prj, host e service, NON deve essere nella stessa org, quindi anche clienti google diversi. come peering, tra network interne o anche interne con esterne. solo tra rete e rete (non tra macchine e rete) e deve essere in comunicazione ipsec. dobbiamo noi configurare gli endpoint. si può, ad esempio, creare un tunnel verso la rete on premise da un network gcp. E' transitiva quindi con A - B - C riesco a far comunicare A con C, col peering no. perché farlo con due network google? non sono esattamente sovrapponibili col peering, in particolare la trasitività.

DNS Topology

internal metadata server acts as DNS resolver

Internal DNS* di default viene creato questo FQDN (dns zonale per identificare l'istanza non solo per nome ma anche a una zona specifica, metodo consigliato per gestire dns) [instance_name].[zone].c.[project_id].internal

Cloud DNS al difuori di questa tutte le richieste esterne comunicano attraverso l'FQDN che parla col Cloud DNS (sla 100%) dove posso importare o creare zone dns pubbliche (classico sito pubblico) o private (saranno risolvibili solo all'itnerno della nostra rete VPC)

Cloud DNS

Private DNS Zones, es: eu.local private zone records:

ciao.eu.local = 10.10.0.50
miao.eu.local = 10.10.0.51 funziona solo all'interno di un progetto, se + network si può specificare dove applicarla DNS peering : consente a un prj che ha un service project può fare richieste a un host project che ospita il servizio. prj y va a fare un richiesta di peering vero prj X, e poi potrà risolvere quegli indirizzi (entrambi hanno cloud dns attivi e in uno sarà indicato di utilizzarlo in peering verso un altro). Unidirezionale : uno ha il servizio e l'altro può solo accedere. Servizio completamente SAAS DNS forwarding : la possibilità di un dominio di inoltrare le query ad un altro indrizzo (es azienda.local già presente on premise e allora decido inoltrare le mie richieste a un server on prem queste richieste, sempre fatto tutto tramite cloud dns) Outbound policy (es alternative name server, quando tutto il traffico dns ha bisogno di essere monitorato) Inbound policy: usato per On premise to Google Cloud Forwarding zone: usato per Google cloud to on-premise (il + usato), queries hasve the same ip range as source (da gestire) Hub-and-spoke Model: serie di prj spoke che parlano con l'hub prj, l'hub può poi a sua volta comunicare con on premise

Connectivity options

come fare per far comunicare google con rete on prem tre possibilità:

Public Internet: site to site (ipsec vpn), classica vpn, uno dei modi più veloci per comunicare tra le due sedi (G e on prem). possiamo comunicare con ip privati. le limitaizioni lato G Cloud sono banda massima a 3 Gbps e connettività pubblica dove demandiamo al fornitore di connettività la comunicazione tra sede e G Cloud. static/dynamic (BGP) based vpn
Cloud Interconnect: più enterprise, connessinoe dedicata a un datacenter di G in 2 varianti (dedicated interconnect: rete G min 10 Gbps, ancora non attiva in italia. partner interconnect: partite da 50 Mbps, quindi si possono scegliere tagli + bassi e meno costosi, fino a 10 Gbps; unico interlocutore per la connettività). a effetto pratico funziona come una normale vpn
Peering: molto diverso da vpn, non si basa la connessione di reti private, ma minimizzare il numero di nodi per la comunicazione (strada migliore), migliorando performance, soprattutto usato per servizi SAAS, ma anche servizi G Cloud, ma non è una connettività privata (no tunnel sicuro)

Cloud router : un appliance virtuale che conosce tutte le network che comunica con protocolli avanzati (tipo bgp) che consente architetture di rete complesse (come avere due connessioni, una backup dell'altra e il BGP in caso di problemi su una fare redirigere sull'altro canale). col bgp se aggiungessi una network on prem lo rileverei in automatico.

Cloud VPN : mi serve ip statico (entrambi i lati), lo scambio di chiavi avviene con IKE v1/2. non devono esserci ip in overlap tra indirizzi locali e in G. lato G scegliamo solo la chiave e l'ip pubblico, il resto automatico.

Se Private Google Access attivo le chiamate verso G Api, rende private le chiamate alle api passando dalla rete G cloud (quindi senza passare necessariamente da rete pubblica), funziona anche sulla rete on prem (purché canale vpn con G), disabilitato di default (non si vede come possa dare problemi, meglio attivarla)

Private Service Access : possibilità di connettersi a servizi G senza dover usare necessariamente un ip pubblico, ma indirizzo della subnet vpc (servizio ancora in beta)

On-premise IP (L4) / UR (L7) Perimiter filtering

Zero-trusth access (beyondCorp), reccomended
VPC Service Controls / Private Google Acess
IP (L4) / UR (L7), range ip (json aggiornato) per capire tutti gli indirizzi provenienti da G Cloud (per whitelisting), se non è concesso mettere *.google.com

Reference Architecture

architettura hub-and-spoke : diversi progetti hub che contengono network e conf che condividono con altr prj chiamati spoke. magari un proj hub per ogni ambiente applicativo (dev, test, prod) al suo interno una network con policy firewall, dns, nat e rotte verso on prem (vpn o interconnect ad esempio), poi uno o più prj client (spoke) utilizzando quelle network per ospitarci servizi. per ogni prj hub al momento ci posson esser max 25 prj spoke (a breve 1000).

firewall offerto da G per tutte le vpc, ma non è di tipo next-gen E' possibile includerli in GCP (barracuda, check point, fortinet, palo alto networks) che ispeziona tutto il traffico in e out della nostra vpc

HA with third party devices: non consentito ma soluzioni con paolo alto e fortinet usando dei firewall per simulare comportamenti di broadcast e multicast è possibile fare un packet mirroring su altra vm, così si può ad esempio analizzare il traffico per eventuali problemi di sicurezza

Load Balancing

fe che consente di smistare traffico su una o più istanze di GCloud all'interno di GCP ci sono:

load balance interni (solo interno a vpc o in peering)
TCP/UDP solo regional, comunicazione pass-trough
https (L7), regional, url headers ...gestite dal load balancer (es: /a da una parte e /b da un'altra)
load balance esterni (rappresenta un ip pubblico)
TCP/UDP solo regional, comunicazione pass-trough
https (L7), non solo regional, url headers ...gestite dal load balancer (es: /a da una parte e /b da un'altra)
TCP Proxy
SSL Proxy

load balance globale da proxy può consentire di non dover sottostare alla latenza per alta magari per via di paesi diversi per la verifica della connessione ssl, usando il proxy vicino al cliente la latenza sarà solo tra noi e il load balancer Quindi unico ip pubblico e in unicast: quindi in base a dove sono può rispondermi il servizio più vicino, in assoluto il sistema più efficiente per ottimizzare le comunicazioni client e host Per applicazioni global distributed questo è il top, google fa tutto in automatico Si può fare affinity, ovver fare in modo che per la stessa sessione si vada sulle stesse macchine DDOS protection si possono usare porte custom

tutti SAAS nella network di G, il pacchetto recapitato e duplicato all'iterno di G (per maggiori performance)

load balancing interno (tech + evoluta di quelli esterni) viene fatto tramite software "envoy" che è un proxy che si mette a fianco ai nostri client e può fare cose tipo url mapping, health check sui client per capire se sono up, sbloccare logiche che il load balancer globale non riesce (tipo alpha testing) tramite logiche di riconoscimento delle utenze

Cloud CDN le parti statiche possono essere restituite direttamente da G tramite la sua cache bonus: se sotto attacco ddos a me non impatta minimamente

instanziando indirizi ip su google è possibile definire un network tier in versione o standard o premium (fa uscire il pacchetto + vicino possibile alla rete del cliente)

Network access control

per controlloare la superficie esterna da una istanza ci sono vari modi (per esporla o navire in internet) la + semplice tramite regole di firewall posso esporre un istanza (che non ha ip pubblico) tramite load balancer usando Cloud NAT posso usare un unico ip esterno ma far navigare diverse istanze (in modo che da fuori non si possa mai capire il chiamante, nessuno sa chi ha chiamato) Quindi la cosa + sicura: no ip esterno, esposto tramite NAT Minimize exposure: disable external ip, controllare accessi con iap, nat, balancer

VPC firewall gratis, statefull with connection tracking, distribuito e applicato allo strato di networking in automatico firewall di G, due path uno in ingresso e uno in uscita, di def tutti in ingresso bloccato, in out concesso si possono usare le etichette per definire permessi (tipo può uscire su internet) sorgenti: ip range o service account target: altro SA, target tag, tutte le istanze network si possono controllare: vm <-> vm, vm <-> prem, vm <-> internet regole di firewall hanno priorità, se stessa priorità un DENY prevale su un ALLOW

Cloud Armor per protezione DDOS anche geo filtering

Vpc service controller serve per definire perimetro su GCP per mitigare tentativi di accesso e uso non autorizzato di api e servizi google si può bloccare sorgenti e destinazioni in base a parametri cosa si differenzia da un firewall? posso controllare:

GCloud serivce <-> vm
GCloud serivce <-> internet
GCloud serivce <-> on prem
GCloud serivce <-> GCloud serivce il firewall si limita alle sole vm condizioni possibili su: vpc netowork, prj, SA, ip adderess granularità a livello di prj, con deroga per poter fare un Perimeter Brdige per mettere in comunicazione diversi servizi in prj differenti

Identity-aware proxy prende il concetto di tunnel e la applica a una serie di servizi GCP per poter accedere a risorse private un untente esterno chiede richesta a un Cloud IAP, se passa auth G vengono considerati ruoli e permessi vari, se sì allora il load balancer di G passa verso il firewall, se ok allora è instaurato un tunnel su cui ad es posso fare ssh. Quindi tunnel su IAP. Posso farlo da qualsiasi posto, indipendemente da vpn quindi, totalmente sicuro. per le macchine è trasparente. Access Context Manager : a che servizio può accedere un determinato utente con IAP desktop (solo windows) ci si può collegare via ssh o rdp su macchine non esposte e si preoccupa in modo trasparente di fare il tunnel IAP con la tua utenza google

Tools

Come InfoSec voglio vedere log di accesso e far auditing, voglio un serverless log sink come Architect voglio i log di tutte le network nella mia vpc come Operations voglio integrare con la mia SIEM solution, così da esser allertato di incidents nella cloud

Cloud Operations (ex StackDriver)

Monitor pyramid:

system and infrastructure (storage, os, cpu, memory)
application (saas, microservice, paas, db, repository..)
business processes (Orders, user login, trasferimento fondi..)

Cloud Operations

Monitoring
Logging
Performance (osservare senza comportare overhead sulle prestazioni, possibilmente)
Multi-Cloud

Cloud operations architecture Workspaces orgaize monitoring information in Cloud Monitoring Workspace ora integrato su GCP (prima dovevi prima fare il ws e poi il resto), viene creato un ws alla creazione del prj. Si può poi dire di prendere metriche anche da altri prj. Prima recupera le metriche (agenti, api, sistema..) e poi il collezionamento per mostrarli sulla dashboard. possiamo anche fare delle metriche custom con api.

cloud operations workspace strategy log raggruppati in base a come vogliamo centralizzare o meno (magari divisi per env) NB: Un prj può dare metriche anche a più workspace

Cloud Logging

Collect (automatic per prj)
Export
Analyze
Retain (30gg log applicativi aumentabile fino a 10 anni ma può essere costo, 400 audit non modificabili)

Data management

Data encryption Google Cloud KMS gestione delle chiavi in modo centralizzato (a livello di progetto ma condivisibile), gestisce le credenziali (solo alcune) volte alla cifratura e la verifica puoi generare, usare, ruotare, distruggere encryption keys compliant con standard di sicurezza (di terze parti) Encryption by default, envelope encryption: con key encryption key (kek: cifra la chiave chi cifra il dato) e data encryption key (dek:cifra il dato). le KEK possono essere nel G KMS o addirittura la tengo in custodia io. G smembra i dati in chunk e le cifra con la dek assieme alla dek cryptata ma con la kek.
default G enc: usa encryption per tutti i servizi che richiedono salvataggio di file (?) si possono fare customizzazioni ma i servizi supportati saranno minori
CMEK : Customer-managed enc keys, key enc key retrieved from Cloud KMS
CSEK : Customer supplied enc keys : key supplied via Customer-supplied enc key (CSEK) api + per-resource random cryptographic nonce
Manaual enc: noi criptioamo prima di salvare su storage e decriptiamo alla lettura

Storing application secrets

Google Secret Manager: store secrets encrypted with G managed keys protected by GCP IAM policy
Berglas : prodotto google open source
HashiCorp Vault

Cloud DLP (Data loss prevention) rileva dati sensibili e li toglie, con:

Redaction (mette asterischi)
Hashing or tokenizing (criptato ma reversibile)
... (sostituisce dati con altri) Le sorgenti possono essere varie, storage, cloudsql, bigquery... e output diversi DLP potrebbe essere usato anche solo per verificare che non ci siano dati sensibili in certi flussi di dati (per poi eventualmente creare alert)

Google Cloud Storage: Access control overivew

IAM permission
ACL
signed urls
signed policy document

Object versioning Object lifecycle management

Cost control

Ogni risorsa ha un modello di costo diverso.

sulle vm ho due scelte:

pay per use
allocare un certo numero di risorse e avere uno sconto su questo

Billing Accounts Solitamente un prj è legato a un BA, se non lo è non può utilizzare risorse (si può cambiare anche dopo). Un prj può essere legato a un solo BA, un BA può avere N prj. Si possono avere + BA. I BA sono:

Offline (accordi con G, si paga in altri modi tipo bonifici, aziende grosse)
Online (di solito, a fine mese G tira una riga, calcola e prende i soldi dalla carta o conto) Se si passa da un reseller il cliente paga il reseller e G fa pagare il reseller. L'associazione del prj al BA può essere fatto manualmente (console o api) o in automatico (terraform, ansible..). I costi si possono esportare quasi in tempo reale in un dataset. Il Prj Billing Manager è un permesso che se dato ci consente di cambiare BA a un prj. i BA non possono essere associati a folders.

Cost management

Capture spend
Report on costs
Actively manage costs
Forecast usage

####Capture spend Exporting to BQ. In documentazione già presenti utili query per fare analisi su aggreagati. Usare le label per identificare l'uso delle risorse (si possono ad esempio usare stesse label su prj diversi (es per uno specifico centro di costo) in modo che posso filatre cross prj ma sulle spec labels). Alcune risorse (sku che producono costo) non sono associabili a label (tipo il traffico di rete). Quindi filtrando per label mi escluderebbe alcuni costi. Poi le label vengono messe (spesso?) a mano e quindi non sempre affidabili.

####Reporting

Data Studio : app gratis di reporting, gratis e permette di collegarsi a diverse cose tra cui BQ. C'è un concetto di templating e quindi si può crere una dashboard di un BA abbastanza facilmente, modificabile cmq. Console Reports : devi entrare sul singolo prj per vedere. A meno che non si abbia diritti di visualizzazioone del BA e da li si possono vedere tutti i prj del BA e il report comulativo.

####Manage Billing budgets and alerts. Budget contiene un filtro : o tutto il BA e prj oppure un elenco di prj. Alert possono scattare al raggiungimento della soglia come scalare o percentuale. Allo scattare un alert possiamo dirgli cosa fare: una mail ai billing account users e owners, oppure tramite notification channels (tramite monitoring e associazione ad esempio mail?), oppure mandare un messaggio in una coda pub/sub, a codice riceviamo l'alert e facciamo quello che vogliamo. Si lavora sempre su mese solare. Ruoli:

Billing account admin
Billing account viewer (visualizza solo)
Billing account user (non visualizza ma associa prj)
Billing account creator (inizialmente dato in fase di creazione della org, consigliabile toglierlo a singola persona)
Project billing manager
Payment contacts

Cost optiomization strategies:

Demand menagement
use serverless infrastructure (where possible)
take advantage of discounts (ie: preemptible vms)
hold departments and teams to account (responsabili per area)

Risorse in commitment (solo per vm) può far risparmiare per 1year -> 40% per 3 years -> 57% (comunque si paga ogni mese) Commit deal: in base a volumi (sconti su alti volumi?)

Infrastructure as code

configuration manager: tipo ansible Il servizio infr as code di G è il Google Cloud Deployment Manager. Di solito però si usa terraform. Comunque sia si userà un SA per autenticarsi.

Kube config connector

G ha fatto uno step in più, invece di descrivere solo componenti applicativi su kube, facciamo che nelle desc di kube su cluster ci mettiamo anche oggetti satelliti, risorse a fianco di kube, tipo cache server (redis) o un cloudSql... e kube si occupa di tirare su anche questi componenti, tutto con una desc sola. E questo è IaC (infraastructure as code). Se faccio evolvere la mia app devo verificare che siano aggiornati anche i componenti accessori (es ingrandire il db ecc), lui non risolverà problemi di migrazione in toto. Ma con una sola desc riesco a fare tutta la delivery.

Cloud Foundation Toolkit

un toolkit di G con template fatti utili per partire

Architecting for resilience

Sli : indicatore
Slo : obiettivo
Sla : agreement - conseguenze in caso di SLO non raggiunto

rto: tempo per rimettere in piedi il sistema dopo disaster recovery

Gabri/gcp cloud sql proxy.md

Gcp Cloud Sql Proxy