Vai al contenuto
Ciao a tutti!
Rieccoci al nostro appuntamento settimanale della rubrica su Snowflake 🙂
Continuiamo oggi la panoramica sul Summit Annuale di Snowflake che si è tenuto lo scorso giugno. Alcuni dei nostri consulenti vi hanno partecipato e ci hanno raccontato che cosa è successo.
Tra i temi affrontati non poteva non esserci quello riguardante la sicurezza dei dati in Snowflake. La società leader di data warehousing non ha perso l’occasione per ribadire il suo impegno nello sviluppo e innovazione presentando le nuove features di sicurezza, governance e protezione dei dati introdotte nelle ultime versioni rilasciate. Come detto da Prasanna Krishnan, Snowflake Product Management Director, all’interno dell’evento The Future of Snowflake Secure Data Sharing, quando si tratta di condividere i dati, le necessità sono di mantenere i dati in sicurezza sia all’interno del cloud che nelle interazioni e di rimanere all’interno degli accordi e regolamentazioni internazionali sulla protezione dei dati. In particolare, in Europa questo punto è particolarmente sentito anche a fronte della recente approvazione del nuovo Codice di Condotta sui Servizi Cloud da parte del Comitato Europeo per la Protezione dei Dati (EDPB), a due anni dall’entrata in vigore del GDPR.
C’è da dire che in Snowflake la condivisione dei dati si trova all’interno della piattaforma insieme a tutte le funzionalità di sicurezza e di amministrazione. Questo già garantisce un grado di sicurezza dei dati in Snowflake più elevato rispetto ai vecchi metodi tradizionali basati sulla condivisione diretta o sulla creazione di API. Inoltre, con Snowflake, quando si desidera condividere dei dati, si possono scegliere oggetti specifici all’interno dell’account da condividere tramite le cosiddette Shares, ovvero oggetti specifici che incapsulano tutte le informazioni necessarie per condividere un database. Tutto ciò significa che quando un cliente richiede i dati, può avere accesso solo ad un pointer collegato ai dati originali in modo tale che i dati non lascino mai l’account, dal momento che il cliente esegue le query sul pointer. Insomma, già un notevole passo in avanti rispetto ai vecchi processi di condivisione ETL nei quali i dati venivano fisicamente estratti e trasformati prima di essere caricati successivamente in un sistema data warehouse.
Una panoramica sulle nuove funzionalità di governance, protezione e sicurezza dei dati in Snowflake
Il sistema di sicurezza dei dati in Snowflake è stato architettato attraverso più livelli di protezione: dall’accesso alla rete, all’autenticazione e al controllo dell’accesso, alla protezione dei dati tramite crittografia. Tale sistema è definito Layered Security Model (LSM). Grazie a questa architettura, Snowflake può proteggere i dati dei clienti tramite una difesa in profondità (o Defense-in-Depth), cioè una strategia che utilizza più livelli di sicurezza in modo tale da non compromettere l’intero sistema in caso di attacchi: se un livello viene compromesso, vengono messi in atto ulteriori livelli di protezione dagli altri due livelli in modo tale da mantenere un livello di sicurezza generale adeguato. In Snowflake, i tre livelli di sicurezza sono:
- Network Security
- Identity and Access Management
- Data Encryption
1. Network Security
Il Network Security Level rappresenta la prima linea di difesa di Snowflake. Questo livello garantisce comunicazioni di rete crittografate e isolate sia in entrata che in uscita. In entrata, è possibile adottare le Network Policies, le quali forniscono all’utente le opzioni per gestire le configurazioni di rete al servizio Snowflake, oppure utilizzare le nuove connessioni private per l’accesso agli internal stages. Ora i clienti possono connettersi on-premises attraverso la loro applicazione client/server a Snowflake tramite la loro connessione pubblica o usando un proxy. A tal proposito, di recente è stato introdotto il Google Cloud Platform (GCP) Private Service Connect, oltre ai già presenti AWS PrivateLink e agli Azure Private Endpoints for Internal Stages. Per quanto riguarda gli AWS PrivateLink, in collaborazione con AWS, è stata lanciata anche la nuova AWS PrivateLink for Amazon S3 con nuove interfacce endpoint per l’accesso ai buckets di Amazon S3 grazie alle quali i clienti non hanno più bisogno di usare proxy quando si connettono on-premises ai servizi di Snowflake e possono anche eseguire un accesso cross-region tramite una connessione peering VPC.
2. Identity and Access Management (IAM)
Gli utenti possono autenticarsi in Snowflake usando credenziali locali o attraverso il loro Identity Provider come SAML o OAuth. Snowflake ha introdotto interessanti novità per gli accessi tramite Identity Provider come l’autenticazione forzata per l’accesso tramite SAML o l’aggiunta da parte di Tableau del supporto PrivateLink con SnowflakeOAuth.
Per quanto riguarda le sessioni, Snowflake ha introdotto la possibilità di configurare UI o Account Session Time-Out e di impostare nuove policy di accesso ai propri database per tutti oppure per singoli utenti i fruitori. Nuove features sono state introdotte anche per le cosiddette Secondary Rules, cioè regole di accesso ai dati che l’utente può configurare solo per una certa sessione in aggiunta alle Primary Rules.
Per finire, Snowflake ha creato nuove partnership con ulteriori piattaforme per la gestione della privacy, della sicurezza informatica e dei rischi derivanti da terze parti. Per maggiori informazioni, qui potete trovare la lista completa degli strumenti e delle tecnologie di sicurezza e di governance noti per fornire Native SQL connectivity a Snowflake.
3. Data Encryption
Per quanto riguarda quest’ultimo livello, non ci sono particolari novità ma va sempre ricordato che tutti i file archiviati negli internal stages per le operazioni di carico e scarico dei dati sono automaticamente criptati utilizzando la crittografia AES-256bit con un hierarchical key model. Le chiavi sono automaticamente rinnovate regolarmente da Snowflake (per default ogni 30 giorni), e i dati possono essere automaticamente ricrittografati (rekeyed) su base regolare (per Enterprise Edition e superiori). In questo caso, ogni anno i vecchi dati saranno nuovamente crittografati con nuove chiavi di crittografia mentre l’amministratore dei dati può comunque cambiare questi parametri temporali direttamente in Snowflake.
Inoltre, con le Tri-Secret Secure e le chiavi gestite dal cliente, è possibile portare la propria chiave (BYOK) per la crittografia, e renderla disponibile a Snowflake e si avrà il pieno controllo su questa chiave. Questo creerà una chiave master composita che combina una chiave del cliente con la chiave predefinita di Snowflake.
L’accesso ai dati in Snowflake e la comunicazione sono forniti con una crittografia automatica End-to-end (E2EE) in cui nessuno, tranne gli utenti finali, può leggere i dati. In Snowflake, questo significa che solo un cliente e i componenti di runtime possono leggere i dati. Nessuna terza parte, compresa la piattaforma di cloud computing di Snowflake o qualsiasi ISP, può vedere i dati in chiaro. Le connessioni sono criptate nella Staging Area con TLS 1.2 usando HTTPS dal client al servizio Snowflake.
Per ulteriori domande su Snowflake vi invitiamo a contattarci all’indirizzo: info@theinformationlab.it
Speriamo che questo articolo vi abbia incuriosito e che continuiate a seguire il nostro blog.
Vi diamo appuntamento alla settimana prossima con alcuni consigli su come accedere ai dati open con Snowflake Data Marketplace!
Alla prossima! ❄️
