Come Cisco ha trasformato Spark Cloud in Fort Knox

È abbastanza chiaro dalle discussioni sulla piattaforma Spark di Cisco a Cisco Live che il gigante delle UC sta attribuendo molto del suo peso alla messaggistica aziendale e alla collaborazione in team. Durante la mia permanenza alla conferenza a Las Vegas ho avuto la possibilità non solo di parlare con Jonathan Rosenberg e Jens Megger, ma anche di partecipare alle loro discussioni su Spark e su dove andrà la piattaforma in seguito. Si può dire che Cisco sta cercando di sfruttare la sua vasta base di utenti di 215 milioni di clienti per sfruttare appieno Spark e spingerlo davvero nel mainstream.

Rosenberg ha affermato durante il suo keynote sulla messaggistica aziendale che la messaggistica aziendale sarà il prossimo grande cambiamento nelle tecnologie di comunicazione per team grandi e piccoli. In precedenza si trattava di chiamate, ogni ufficio aveva bisogno di un sistema telefonico per tenersi in contatto (e alla fine le videochiamate possono essere incluse qui), e poi quando arrivavano le e-mail, tutti dovevano adottare la casella di posta elettronica istantanea. Ora, ha detto Rosenberg, la messaggistica aziendale sta prendendo il posto della posta elettronica. Non che l'e-mail scomparirà, proprio come la nostra posta ordinaria standard non si è ancora dissolta, ma le piattaforme di collaborazione in team consentiranno ai team di ottenere di più, più velocemente.

La sicurezza è la chiave

Ma quando ti aspetti che i grandi attori Enterprise adottino la tua piattaforma, devi prendere in considerazione almeno un aspetto importante, ed è la sicurezza. Nessuna azienda vuole che una terza parte curiosa nelle loro comunicazioni interne, anche se ciò significa il fornitore del servizio stesso. Per assicurarti che tutti adottino la tua piattaforma, devi assicurarti che tutti si sentano al sicuro nell'utilizzarla. Cisco ha fatto di tutto per spuntare tutte le caselle quando stavano costruendo Spark da zero: hanno persino fatto il possibile per stabilire la crittografia end-to-end nel tessuto a livello del suolo di Spark. L'intero sistema è stato sviluppato pensando alla sicurezza e alla crittografia.

Uno dei principali vantaggi dei servizi cloud è il fatto che gli aggiornamenti della piattaforma possono essere eseguiti con la stessa rapidità con cui il provider di servizi cloud può implementarli. Una nuova funzionalità può essere implementata non appena è pronta per l'uso ed essere rapidamente trasferita alla base di utenti esistente, questo potrebbe essere chiamato "valore aggiunto".

La risposta di Cisco

Tuttavia, per la maggior parte dei prodotti di consumo l'aggiunta di valore avviene a spese degli utenti. Di solito richiedendo l'accesso completo ai dati e ai contenuti degli utenti, il servizio può sembrare vulnerabile. Oppure, d'altra parte, i servizi bloccati che garantiscono la sicurezza sacrificheranno queste funzionalità a valore aggiunto per mantenere tutto bello e sicuro. Rispetto ad altre soluzioni come Slack, Spark guadagna alcuni punti extra quando si tratta del suo alto livello di sicurezza.

Ciò che Cisco ha fatto con Spark è stato trovare un buon equilibrio nel mezzo. Crittografia end-to-end che offre alle aziende la possibilità di scegliere in modo specifico quali integrazioni a valore aggiunto desiderano includere. Facendo un ulteriore passo avanti, mentre Cisco si esclude dai tuoi dati, l'Enterprise può avere pieno accesso a sua scelta.

Cisco ha affermato che il sistema si basa su "un'architettura aperta per la distribuzione sicura delle chiavi di crittografia e la riservatezza dei dati". Ciò significa essenzialmente che il contenuto è crittografato sul client di ciascun utente e rimane tale fino a quando non raggiunge il destinatario. Niente tra ciascun client ha accesso alle chiavi di decrittazione, a meno che l'azienda non decida di fornire tale accesso agli utenti.

Quindi come fa tutto il lavoro

Per consentire l'accesso alla decrittazione, Cisco ha introdotto un sistema di chiavi per fornire l'accesso completo ai dati, se necessario e se concesso agli utenti. Questo sistema, il Key Management Server (KMS) è la base della crittografia end-to-end in Spark. Questo server creerà, memorizzerà l'autorizzazione e fornirà l'accesso alle chiavi di crittografia. In sostanza, il KMS è il gatekeeper di tutti i tuoi dati e file. In base alle autorizzazioni impostate dall'azienda, solo alcuni utenti possono avere accesso (personale IT), mentre Cisco stessa non è in grado di vedere i tuoi contenuti. Ogni impresa ha il proprio KMS univoco.

KMS = Key Management Server, il tuo Cisco Spark Gatekeeper

Lo stesso KMS è separato dall'unità Core di Spark, sono i loro "regni" che lavorano insieme. Mentre il KMS si trova nel regno di sicurezza, tutto il resto può essere etichettato come l'unità principale di Spark. Mantenere i regni separati è ciò che garantisce la crittografia end-to-end. Gli elementi principali della piattaforma non hanno accesso alle chiavi di crittografia e il sistema si affida al servizio di gestione delle chiavi per autenticare i token di accesso che non vengono utilizzati da nessun'altra parte nel cloud.

Come afferma Cisco, questo "garantisce un accesso appropriato alle chiavi di crittografia, garantendo al contempo che nessun componente del servizio principale possa accedere a quelle comunicazioni o chiavi memorizzate dal KMS".

In un altro passaggio per fornire il controllo totale all'utente finale, Cisco consente anche l'opzione dell'ambito della sicurezza come soluzione in hosting - in questo modo Cisco fa tutto il lavoro pesante - o una soluzione in loco per l'azienda estremamente cauta che vuole davvero blocca tutto. Con una soluzione ospitata, tutti i servizi nell'area di sicurezza sono localizzati e gestiti in un tenant separato su un'infrastruttura separata. Con la premessa, sta al business decidere.

Il processo in azione

Per farla breve, quando un utente desidera inviare un messaggio alla stanza Spark, il primo passaggio del client dell'utente è stabilire un canale sicuro tra il client e il Servizio di gestione delle chiavi. Questo passaggio richiede un processo di autenticazione tra il client e il KMS, che impedisce a Cisco oa terze parti di visualizzare o addirittura modificare le informazioni in transito. Dopo il processo di autenticazione, il client utilizzerà il canale stabilito per richiedere una nuova chiave di crittografia necessaria per crittografare il contenuto che verrà inviato a un altro client.

Dopo che il messaggio è stato scritto, il client crittografa il messaggio con una chiave di conversazione e lo etichetta con l'ID della stanza Spark di destinazione e lo invia al core. Il core riceve quindi un messaggio crittografato e, poiché è tenuto separato dall'area di sicurezza, non ha alcun accesso alle chiavi di conversazione necessarie per decrittografare detto messaggio. Il core cerca il destinatario e invia il messaggio crittografato verso la stanza di ricezione, ma memorizza anche il messaggio in un database associato alla stanza di ricezione.

Ora il processo avviene al contrario, il client ricevente riceve un messaggio crittografato e contatta il Servizio di gestione delle chiavi per ottenere la chiave necessaria per decrittografare il messaggio. Il Servizio di gestione delle chiavi autentica entrambi gli utenti per verificare le autorizzazioni necessarie per aprire il messaggio e distribuisce la chiave di conversazione al destinatario in modo che il suo client possa decomprimere e leggere il messaggio.

Se tutto è crittografato, come funziona la ricerca?

Poiché il Core stesso non vede mai nessuno dei contenuti che stai trasmettendo, non puoi consentire una semplice ricerca di messaggi attraverso il servizio cloud stesso. Per contrastare questo, Cisco ha escogitato qualcosa di davvero unico: ha integrato un componente Indexer direttamente nel Security Realm. Proprio come il KMS, l'Indicizzatore è completamente separato dal Core, ma è molto vicino al KMS. In sostanza, l'indicizzatore crea e interroga l'indice di ricerca all'interno del Servizio di gestione delle chiavi. In questo modo tutto rimane crittografato, ma ricercabile.

Si scopre che l'indicizzatore è in realtà uno Spark Bot invitato in ogni stanza, a seconda della politica aziendale. Ogni volta che un utente invia un messaggio, l'indicizzatore riceve una copia del contenuto crittografato, e, come il client, dialoga con il Servizio di gestione delle chiavi per accedere alla chiave di conversazione necessaria per aprire il messaggio. L'indicizzatore applica un hash, una modalità di autenticazione, a ciascuna parola all'interno del messaggio inviato e rispetta un elenco di tutte le parole con hash che appartengono alla stanza specifica in cui è stato ricevuto il messaggio.

L'indicizzatore è persino abbastanza intelligente da aggiungere parole casuali per garantire che i messaggi non possano avere la crittografia invertita. L'elenco degli hash viene quindi inviato a Spark Cloud e archiviato nell'indice di ricerca mentre si trova nel loro stato crittografato. Ora hai un indice ricercabile e completamente crittografato.

Il meglio di entrambi i mondi

Cisco voleva davvero offrire la tranquillità che anche l'impresa più paranoica potesse sentirsi sicura inviando i propri dati e file attraverso la piattaforma Spark Cloud. Altre applicazioni consumer consentono, o possono anche fare affidamento, l'accesso ai dati da parte del servizio stesso. Con la crittografia end-to-end così profondamente radicata nello sviluppo di Spark e persino la possibilità di ospitare il tuo regno di sicurezza, impostare i tuoi parametri e disposizioni, hai il Fort Knox della messaggistica aziendale e della collaborazione in team.