Gli utenti scelgono il nuovo tipo di riunione quando pianificano una riunione. Quando si ammissione dei partecipanti dall'area di ingresso virtuale e durante la riunione, l'organizzatore può visualizzare lo stato di verifica dell'identità di ciascun partecipante. È disponibile anche un codice riunione comune a tutti i partecipanti correnti nella riunione, che possono utilizzare per verificarsi l'uno con l'altro.
Condividere le seguenti informazioni con gli organizzatori delle riunioni:
Pianificazione di App Webex Meetings con crittografia end-to-end
Accesso a App Webex Meetings con crittografia end-to-end
Verifica dell'identità
end-to-end verifica dell'identità fornisce ulteriore sicurezza a una riunione con crittografia end-to-end.
Quando i partecipanti o i dispositivi a unirsi a un gruppo DI SICUREZZA (MESSAGING Layer Security) condiviso, presentano i propri certificati agli altri membri del gruppo che, quindi, convalidano i certificati in base all'autorità di certificazione/IE (CA) che emette. Confermando che i certificati sono validi, l'Autorità di certificazione verifica l'identità dei partecipanti e la riunione mostra i partecipanti/dispositivi come verificati.
Gli utenti del gruppo app Webex Meetings si autenticano verso l'archivio di identità Webex e, al termine, eseguono un token di accesso. Se necessitano di un certificato per verificarne l'identità in una riunione con crittografia end-to-end, la CA Webex emissione di un certificato in base al token di accesso. Non è ancora disponibile un modo per consentire agli Webex Meetings utenti di ottenere un certificato emesso da un'autorità di certificazione di terze parti/esterna.
I dispositivi possono autenticarsi utilizzando un certificato emesso dalla CA interna (Webex) o un certificato emesso da una CA esterna:
Per il caso ca interno, Webex emissione di un certificato interno basato sul token di accesso dell'account macchina del dispositivo. Il certificato è firmato dalla CA Webex. I dispositivi non dispongono di ID utente come fanno gli utenti, pertanto Webex utilizza (uno dei) domini della propria organizzazione quando scrive l'identità del certificato del dispositivo (CN)).
Per il caso CA esterno, richiedere e acquistare i certificati dei dispositivi direttamente dall'autorità di certificazione scelta. È necessario crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo all'utente.
Cisco non è coinvolto, il che fa in modo di garantire la crittografia end-to-end e l'identità verificata, e impedisce che Cisco possa determinare la riunione/ decrittografare il contenuto multimediale.
Certificato dispositivo emesso internamente
Webex elaga un certificato al dispositivo quando viene registrato dopo l'avvio e lo rinnova se necessario. Per i dispositivi, il certificato include l'ID account e un dominio.
Se la propria organizzazione non dispone di un dominio, la CA Webex emissione del certificato senza un dominio.
Se la propria organizzazione dispone di più domini, è possibile utilizzare Control Hub per indicare a Webex il dominio che il dispositivo utilizzare per la relativa identità. È anche possibile utilizzare l'API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com".
Se si dispone di più domini e non si imposta il dominio preferito per il dispositivo, Webex sceglie uno per l'utente.
Certificato dispositivo emesso esternamente
Un amministratore può fornire un dispositivo con il proprio certificato che è stato firmato con una delle CA pubbliche.
Il certificato deve essere basato su una coppia di chiavi ECDSA P-256, sebbene possa essere firmato da una chiave RSA.
I valori nel certificato sono a discrezione dell'organizzazione. Il nome comune (CN) e la san nome alternativo oggetto (SAN) verranno visualizzati nell'interfaccia utente della riunione Webex, come descritto in Crittografia end-to-end con verifica identità per Webex Meetings.
Si consiglia di utilizzare un certificato separato per dispositivo e un CN univoco per dispositivo. Ciò potrebbe, ad esempio, essere "meeting-room-1.example.com", per l'organizzazione che possiede il dominio "example.com".
Per proteggere completamente il certificato esterno dalla manomissione, viene utilizzata una funzione client-secret per crittografare e firmare diversi xcommand.
Quando si utilizza il segreto client, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite xAPI. Questo limite è attualmente limitato ai dispositivi online.
Attualmente, Webex fornisce i comandi API per gestire questa operazione.
Dispositivi
I dispositivi Webex Room registrati su cloud e i dispositivi serie Webex Desk possono accedere a riunioni con crittografia end-to-end, incluse:
Webex Board
Webex Desk Pro
Scrivania Webex
Webex Room Kit
Webex Room Kit Mini
I seguenti dispositivi non possono accedere alle riunioni end-to-end crittografate:
Webex serie C
Webex serie DX
Webex serie EX
Webex serie MX
Dispositivi SIP di terze parti
Client software
Dalla versione 41.6, il client desktop Webex Meetings accedere alle riunioni con crittografia end-to-end.
Se la propria organizzazione abilita l'app Webex per accedere alle riunioni avviando l'applicazione desktop Meetings, è possibile utilizzare tale opzione per accedere alle riunioni crittografate end-to-end.
Il client Web di Webex non può accedere a riunioni con crittografia end-to-end.
I soft client SIP di terze parti non possono accedere a riunioni con crittografia end-to-end.
identità
Non vengono fornite opzioni Control Hub per la gestione dell'identità dei dispositivi verificata esternamente. Questa decisione è stata scelta per impostazione predefinita poiché per la crittografia end-to-end, solo l'utente deve conoscere e accedere alle chiavi e all'algoritmo. Se è stato introdotto un servizio cloud per gestire tali chiavi, è possibile che vengano intercettate.
Attualmente non offriamo strumenti di assistenza nella richiesta o nella crittografia dei certificati di identità dei dispositivi e delle relative chiavi private. Attualmente, fornisci un 'recipe' per progettare i propri strumenti, in base alle tecniche di crittografia standard del settore, per fornire assistenza con questi processi. Non dobbiamo avere accesso reale o percepiva l'accesso alle vostre chiavi o vostre chiavi.
Riunioni
end-to-end le riunioni crittografate attualmente supportano un massimo di 200 partecipanti.
Di questi 200 partecipanti, un massimo di 25 dispositivi verificati esternamente possono accedere e devono essere i primi partecipanti a unirsi allariunione.
Quando un numero maggiore di dispositivi si unisce a una riunione, i servizi multimediali backend tentano di transcodificare gli streaming multimediali. Se non è possibile decrittografare, codificare e crittografare nuovamente il contenuto multimediale (perché non sono disponibili e non sono disponibili le chiavi di crittografia dei dispositivi), la transcodifica non riesce.
Per ridurre questa limitazione, si consigliano riunioni di dimensioni più ridotte per i dispositivi o sconsigliare gli inviti tra i dispositivi e i client Meetings.
Interfaccia di gestione
Si consiglia vivamente di utilizzare Control Hub per gestire il sito della riunione.
Il motivo principale di questa modifica è la differenza tra il modo in cui Control Hub e amministrazione sito l'identità. Le organizzazioni Control Hub hanno centralizzato l'identità per l'intera organizzazione, mentre nell'ambiente amministrazione sito identità è controllata su base sito per sito.
Ciò significa che non è possibile disporre dell'opzione di identità verificata da Cisco per gli utenti gestiti da amministrazione sito. Tali utenti emesse un certificato anonimo per partecipare a una riunione crittografata end-to-end e potrebbero essere escluse dalle riunioni in cui l'organizzatore desidera garantire l'identità.
Informazioni correlate
Sicurezza zero-trust per Webex (documento tecnico sulla sicurezza): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Presentazione Cisco Live 2021 (è necessaria l'iscrizione a Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Crittografia Web JSON (JWE) (standard IETF bozza): https://datatracker.ietf.org/doc/html/rfc7516
Documentazione per gli utenti: https://help.webex.com/5h5d8ab
Riferimento di esempio JWE
Esempio di JWE crittografato correttamente in base ai parametri specificati (appendice)
Webex Meetings 41.7.
Dispositivi serie Webex Room e Webex Desk registrati su cloud, in esecuzione
10.6.1-RoomOS_August_2021.Accesso amministrativo al sito per riunioni in Control Hub, per abilitare il nuovo tipo di sessione per gli utenti.
Uno o più domini verificati nella propria organizzazione Control Hub (se si utilizza la CA Webex per emettere certificati di dispositivo per l'identità verificata).
Le sale riunioni di collaborazione devono essere attivate in modo che le persone possano accedere dal proprio sistema video. Per ulteriori informazioni, vedere Autorizzazione per l'accesso dei sistemi Webex Meetings e Events sul sitoWebex.
È possibile ignorare questa operazione se non occorre un'identità verificata esternamente.
Per il livello massimo di sicurezza e per la verifica dell'identità, ciascun dispositivo deve disporre di un certificato univoco emesso da un'autorità di certificazione pubblica affidabile.
È necessario interagire con la CA per richiedere, acquistare e ricevere i certificati digitali e creare le chiavi private associate. Quando si richiede il certificato, questi sono i parametri da utilizzare:
Il certificato deve essere emesso e firmato da una CA pubblica nota.
Unico: Si consiglia vivamente di utilizzare un certificato univoco per ciascun dispositivo. Se si utilizza un certificato per tutti i dispositivi, si compromette la sicurezza.
Nome comune (CN) e Nome alternativo oggetto (SAN/s): Questi non sono importanti per Webex, ma devono essere valori che gli umane possono leggere e associare al dispositivo. Il CN visualizza agli altri partecipanti alla riunione come identità verificata principale del dispositivo e se gli utenti controllano il certificato attraverso l'interfaccia utente della riunione, visualizzano le SAN. Si potrebbe voler utilizzare nomi come
name.model@example.comma è una scelta propria.Formato di file: I certificati e le chiavi devono essere in formato .pem.
Scopo: Lo scopo del certificato deve essere Identità Webex.
Generazione delle chiavi: I certificati devono essere basati su coppie di chiavi ECDSA P-256 (algoritmo di firma digitale a curva ellittica che utilizza la curva P-256).
Questo requisito non estende la chiave di firma. La CA può utilizzare una chiave RSA per firmare il certificato.
È possibile ignorare questa operazione se non si desidera utilizzare l'identità verificata esternamente con i dispositivi.
Se si stanno utilizzando nuovi dispositivi, non registrarli ancora in Webex. Non è ancora possibile connetterli alla rete.
Se si dispone di dispositivi esistenti che si desidera eseguire l'aggiornamento per utilizzare l'identità verificata esternamente, sarà necessario ripristinare le impostazioni dei dispositivi.
Salvare la configurazione esistente se si desidera conservarla.
Pianificare una finestra quando i dispositivi non vengono utilizzati o utilizzare un approccio a più fasi. Avvisare gli utenti delle modifiche previste.
Assicurarsi dell'accesso fisico ai dispositivi. Se occorre accedere ai dispositivi su rete, tenere presente che se si viaggia in testo normale e si compromette la sicurezza.
Una volta completate queste operazioni, consentire ai sistemi video di accedere alle riunioni e agli eventi sul sito Webex.
Per assicurarsi che il contenuto multimediale del dispositivo non possa essere crittografato da un utente eccetto il dispositivo, è necessario crittografare la chiave privata sul dispositivo. Sono state progettate le API per il dispositivo per consentire la gestione della chiave crittografata e del certificato utilizzando la crittografia Web JSON (JWE).
Per garantire la crittografia end-to-end reale attraverso il nostro cloud, non possiamo essere coinvolti nella crittografia e nel caricamento del certificato e della chiave. Se occorre questo livello di sicurezza, l'accesso è importante per:
Richiedere i certificati.
Generare le coppie di chiavi dei certificati.
Creare (e proteggere) un segreto iniziale per ciascun dispositivo per impostare la funzionalità di crittografia del dispositivo.
Sviluppare e mantenere il proprio strumento per la crittografia dei file utilizzando lo standard JWE.
Di seguito viene descritto il processo e i parametri (non segrete) necessari e una recipe da seguire negli strumenti di sviluppo disponibili. Vengono forniti anche alcuni dati di test e i risultati JWE risultante come previsto, al modo in cui ci si attende, per aiutare l'utente a verificare il processo.
Un'implementazione di riferimento non supportata che utilizza Stereo3 e la libreria JWCrypto è disponibile da Cisco su richiesta.
Concatenare e crittografare il certificato e la chiave utilizzando lo strumento e il segreto iniziale del dispositivo.
Caricare il codice JWE risultante sul dispositivo.
Impostare lo scopo del certificato crittografato da utilizzare per l'identità Webex e attivare il certificato.
(Consigliato) Fornire un'interfaccia per (o distribuire) lo strumento per consentire agli utenti di dispositivi di modificare il segreto iniziale (per proteggere i relativi supporti).
Modalità d'uso del formato JWE
Questa sezione descrive come si prevede che l'JWE sia creato come input per i dispositivi, in modo che sia possibile creare il proprio strumento per creare le chiavi e certificati.
È necessario fare riferimento a Crittografia Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516 e firma Web JSON (JWS).https://datatracker.ietf.org/doc/html/rfc7515
Si è scelto di utilizzare la stringa compatta di un documento JSON per creare elementi JWE. I parametri che è necessario includere quando si creano le sistemazioni JWE sono:
Intestazione JOSE (protetta). Nell'intestazione Firma oggetto JSON e crittografia, È NECESSARIO includere le seguenti coppie di valori chiave:
"alg":"dir"L'algoritmo diretto è l'unico supportato per la crittografia del carico utile ed è necessario utilizzare il segreto del client iniziale del dispositivo.
"enc":"A128GCM"o"enc":"A256GCM"Sono supportati questi due algoritmi di crittografia.
"cisco-action": "add"o"cisco-action": "populate"o"cisco-action": "activate"o"cisco-action": "deactivate"Si tratta di una chiave proprietaria e di quattro valori. È stata introdotta questa chiave per segnalare lo scopo dei dati crittografati al dispositivo di destinazione. I valori sono denominati dopo i comandi xAPI sul dispositivo in cui si utilizzano i dati crittografati.
L'abbiamo chiamata
cisco-actionper evitare possibili problemi con future estensioni JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Un'altra chiave proprietaria. I valori forniti come input per la derivazione chiave sul dispositivo vengono utilizzati. L'icona
versiondeve essere1(versione della funzione di derivazione chiave). Il valore disaltdeve essere una sequenza base64 codificata da URL di almeno 4 byte, che è necessario scegliere in ordine casuale.
Chiave crittografata JWE. Campo vuoto. Il dispositivo deriva dal dispositivo iniziale
ClientSecret.Vettore di inizializzazione JWE. Specificare un vettore di inizializzazione codificato base64url per la decrittografia del carico utile. Il valore IV DEVE essere un valore casuale di 12 byte (stiamo utilizzando la famiglia di crittografia AES-GCM, che richiede un IV di 12 byte).
JWE AAD (dati autenticati aggiuntivi). È necessario omettere questo campo poiché non è supportato nel sistema Compact Compact.
Testo di crittografiaJWE: Questo è il carico utile crittografato che si desidera mantenere nascosto.
Il carico utile POTREBBE essere vuoto (ad esempio, per reimpostare il segreto del client, è necessario sovrascriverlo con un valore vuoto).
Esistono diversi tipi di carico utile, a seconda di ciò che si sta tentando di fare sul dispositivo. Diversi comandi xAPI prevedono diversi carichi di carico utile ed è necessario specificare lo scopo del carico utile con il
cisco-actionchiave, come segue:Con
"cisco-action":"populate"il testo di crittografia è il nuovoClientSecretCon "
"cisco-action":"add"il testo di crittografia è un PEM che porta il certificato e la relativa chiave privata (concatenata)Con "
"cisco-action":"activate"il testo di crittografia è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo attivando per la verifica dell'identità dei dispositiviCon "
"cisco-action":"deactivate"il testo di crittografia è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che viene disattivato dall'uso per la verifica dell'identità del dispositivo
Tag autenticazione JWE: Questo campo contiene il tag di autenticazione per verificare l'integrità dell'intera applicazione JWE in modalità compatta
La modalità di derivazione chiave di crittografia dalla ClientSecret
Dopo la prima popolazione del segreto, non accettiamo o non viene restituito il segreto come testo normale. Al scopo di evitare possibili attacchi del dizionario da parte di qualcuno che potrebbe accedere al dispositivo.
Il software del dispositivo utilizza il segreto client come input per una funzione di derivazione chiave (kdf), quindi utilizza la chiave derivata per la decrittografia/crittografia del contenuto sul dispositivo.
Ciò significa per l'utente che il proprio strumento per produrre certificati JWE deve seguire la stessa procedura per specificare la stessa chiave di crittografia/decrittografia dal segreto client.
I dispositivi utilizzano scrypt per la derivazione della chiave (vedere https://en.wikipedia.org/wiki/Scrypt), con i seguenti parametri:
CostFactor (N) è 32768
BlockSizeFactor (r) ha 8
ParallelizationFactor (p) è 1
Il sale è una sequenza casuale di almeno 4 byte; è necessario fornire lo stesso
saltquando si specifica lacisco-kdf.La lunghezza delle chiavi è di 16 byte (se si seleziona l'algoritmo AES-GCM 128) o 32 byte (se si seleziona l'algoritmo AES-GCM 256)
Il limite massimo di memoria è 64 MB
Questa serie di parametri è l'unica configurazione di scrypt compatibile con la funzione di derivazione chiave sui dispositivi. Questa chiave kdf sui dispositivi è denominata "version":"1", che è l'unica versione attualmente in uso da cisco-kdf.
Esempio non elaborato
Di seguito è riportato un esempio che è possibile seguire per verificare che il processo di crittografia JWE funzioni allo stesso modo del processo creato sui dispositivi.
Lo scenario di esempio consiste nell'aggiunta di un peM di accesso al dispositivo (microfoni che aggiungono un certificato, con una stringa molto breve anziché una chiave completa di certificato +). Il segreto del client nell'esempio è ossifrage.
Scegliere una crittografia. In questo esempio viene utilizzato
A128GCM(AES con chiavi a 128 bit nella modalità contatore galois). Lo strumento potrebbe utilizzareA256GCMse si preferisce.Scegliere un sale (deve essere una sequenza casuale di almeno 4 byte). In questo esempio viene utilizzato (byte esadecimali)
E5 E6 53 08 03 F8 33 F6. Base64url codifica la sequenza per ottenere5eZTCAP4M_Y(rimuovere il riempimento base64).Di seguito è riportato un esempio
scryptchiamata per creare il contenuto chiave di crittografia (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)La chiave derivata deve essere di 16 byte (hex) nel modo seguente:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acche base64url codifica alZ66bdEiAQV4_mqdInj_rA.Scegliere una sequenza casuale di 12 byte da utilizzare come vettore di inizializzazione. In questo esempio viene utilizzato (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83che base64url codifica aNLNd3V9Te68tkpWD.Creare l'intestazione JOSE con compact json (seguire lo stesso ordine dei parametri utilizzati qui) e codificare base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}L'intestazione JOSE codificata base64url è
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Questo sarà il primo elemento del sistema JWE.
Il secondo elemento del sistema JWE è vuoto poiché non viene fornito un chiave di crittografia JWE.
Il terzo elemento di JWE è il vettore di inizializzazione
NLNd3V9Te68tkpWD.- Utilizzare lo strumento di crittografia JWE per produrre un carico utile e un tag crittografati. Per questo esempio, il carico utile non crittografato sta per essere il falso PEMrca
this is a PEM fileI parametri di crittografia da utilizzare sono:
Carico utile
this is a PEM fileLa crittografia della crittografia è AES 128 GCM
Intestazione JOSE codificata base64url come dati autenticati aggiuntivi (AAD)
Base64url codifica il carico utile crittografato, che dovrebbe provocare
f5lLVuWNfKfmzYCo1YJfODhQQuesto è il quarto elemento (testo di crittografia JWE) nel sistema JWE.
Base64url codificare il tag prodotto al punto 8 per determinare
PE-wDFWGXFFBeo928cfZ1QQuesto è il quarto elemento nella finestra JWE.
Concatenare i cinque elementi del modello JWE con punti (JOSEheader.. IV.Ciphertext.Tag) per ottenere:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1QSe sono stati derivati gli stessi valori codificati base64url mostrati qui, utilizzando i propri strumenti, si è pronti a utilizzarli per proteggere la crittografia E2E e l'identità verificata dei dispositivi.
Questo esempio non funziona, ma in generale, il passo successivo consiste nell'utilizzare il comando JWE creato sopra come input al comando xcommand sul dispositivo che aggiunge il certificato:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Sono disponibili nuovi tipi di sessione per le riunioni con attendibilità zero, che saranno disponibili per tutti i siti delle riunioni senza costi aggiuntivi. Uno dei nuovi tipi di sessione è denominato Pro-End to End Encryption_VOIPonly. Questo è il nome del servizio pubblico che potrebbe cambiare in futuro. Per i nomi correnti dei tipi di sessione, vedere ID tipo di sessione nella sezione Riferimento di questo articolo.
Non è necessario eseguire alcuna operazione per ottenere la nuova funzionalità per il sito, ma occorre concedere il nuovo privilegio tipo di sessione (denominato anche privilegio riunione) agli utenti. È possibile effettuare questa operazione singolarmente attraverso la pagina di configurazione dell'utente o in massa con un'esportazione/importazione CSV.
| 1 | Accedere a Control Hub e aprire la pagina Riunione. |
||
| 2 | Fare clic sul nome del sito per aprire il pannello di configurazione del sito. |
||
| 3 | Fare clic su Configura sito. |
||
| 4 | Nell'area Impostazioni comuni, fare clic su Tipi disessione. In tale pagina, dovrebbero essere visualizzati uno o più tipi di sessione di crittografia end-to-end. Fare riferimento all'elenco di ID dei tipi di sessione nella sezione Riferimento di questo articolo. Ad esempio, è possibile visualizzare Pro-End to End Encryption_VOIPonly.
|
||
| 5 | Se ancora non si dispone delle nuove tipo di sessione, contattare il rappresentante Webex. |
Operazione successivi
Abilitare questo privilegio tipo di sessione/riunione per alcuni o tutti gli utenti.
| 1 | Fare clic su Utenti e selezionare un utente per aprire il pannello di configurazione dell'utente. |
| 2 | Nell'area Servizi, fare clic su Cisco Webex Meetings . |
| 3 | Selezionare il sito (se l'utente si trova in più di uno) e fare clic su Ospita. |
| 4 | Selezionare la casella accanto alla voce Webex Meetings gruppo etichettata Pro-End to End Encryption_VOIPonly. |
| 5 | Chiudere il pannello di configurazione dell'utente. |
| 6 | Se necessario, ripetere questa operazione per gli altri utenti. Se si desidera assegnare questa opzione a molti utenti, utilizzare l'opzione di massa CSV. |
| 1 | Accedere a Control Hub su https://admin.webex.com e aprire la pagina Riunione. |
||
| 2 | Fare clic sul nome del sito per aprire il pannello di configurazione del sito. |
||
| 3 | Nella sezione Licenze e utenti, fare clic su Gestione di massa. |
||
| 4 | Fare clic su Esporta e attendere la preparazione delfile. |
||
| 5 | Quando il file è pronto, fare clic su Esporta risultati, quindi scaricare . (È necessario chiudere manualmente tale finestra popup dopo aver fatto clic su Scarica. |
||
| 6 | Aprire il file CSV scaricato per la modifica. Per ciascun utente è presente una riga e il campo |
||
| 7 | Per ciascun utente a cui si desidera concedere il nuovo tipo di sessione, aggiungere |
||
| 8 | Aprire il pannello Configurazione sito riunione in Control Hub.
|
||
| 9 | Nella sezione Licenze e utenti, fai clic su Gestione di massa. |
||
| 10 | Fare clic su Importa e selezionare il file CSV modificato, quindi fare clic su Importa. Attendere il caricamento del file. |
||
| 11 | Al termine dell'importazione, è possibile fare clic su Importa risultati per esaminare la presenza di errori. |
||
| 12 | Andare alla pagina Utenti e aprire uno degli utenti per verificare se dispongono del nuovo indirizzo tipo di sessione. |
Se i dispositivi sono già presenti nell'organizzazione Control Hub e si desidera utilizzare l'autorità di certificazione Webex per generare automaticamente i relativi certificati di identificazione, non è necessario ripristinare le impostazioni delle impostazioni dei dispositivi.
Questa procedura seleziona il dominio utilizzato dal dispositivo per identificarsi ed è richiesta solo se si dispone di più domini nella propria organizzazione Control Hub. Se si dispone di più domini, si consiglia di effettuare questa operazione per tutti i dispositivi con identità "Cisco verificata". Se non si identifica il dominio Webex, ne viene scelto uno e l'errore potrebbe essere errato per gli altri partecipanti alla riunione.
Operazioni preliminari
Se i dispositivi non sono ancora presenti, è possibile seguire l'opzione Registra un dispositivo per eseguire l Cisco Webex mediante l'API o l'interfaccia Web locale o l'onboarding cloud per i dispositivi . È necessario anche verificare il/i dominio/i che si desidera utilizzare per identificare i dispositivi in Gestisci dispositivi.
| 1 | Accedere a Control Hub (https://admin.webex.com) e aprire la pagina Dispositivi. |
| 2 | Selezionare un dispositivo per aprire il relativo pannello di configurazione. |
| 3 | Selezionare il dominio che si desidera utilizzare per identificare questo dispositivo. |
| 4 | Ripetere per gli altri dispositivi. |
Operazioni preliminari
Hai bisogno:
Per ottenere un certificato firmato dalla CA e una chiave privata, in formato .pem, per ciascun dispositivo.
Per leggere l'argomento Processo di identità esterna per dispositivi, nella parte Preparazione di questo articolo.
Per preparare uno strumento di crittografia JWE in relazione alle informazioni in questo punto.
Uno strumento per generare sequenze di byte casuali di date di lunghezza.
Uno strumento per base64url codifica byte o testo.
Un
scryptImplementazione.Una parola o una frase segrete per ciascun dispositivo.
| 1 | Inserire i dati nel campo del dispositivo La prima volta che si compila il campo Il dispositivo ha il segreto iniziale. Non dimenticare che non è possibile recuperarlo e occorre ripristinare le impostazioni delle impostazioni di fabbrica per avviare nuovamente il dispositivo.
|
| 2 | Concatenare il certificato e la chiave privata: |
| 3 | Creare un codice JWE da utilizzare come input per il comando di aggiunta del certificato: |
| 4 | Aprire TShell sul dispositivo ed eseguire il comando di aggiunta (multiline): |
| 5 | Verificare che il certificato sia aggiunto eseguendo Copiare le impronte digitali del nuovo certificato. |
| 6 | Attivare il certificato allo scopo di Il dispositivo dispone di un certificato emesso da CA crittografato, attivo e pronto per essere utilizzato per identificarlo nelle riunioni Webex con crittografia end-to-end.
|
| 7 | Onboard il dispositivo nell'organizzazione Control Hub. |
| 1 | Pianificare una riunione del tipo corretto (Webex Meetings Pro-End fino alla fine Encryption_VOIPonly). |
| 2 | Accedere alla riunione come organizzatore da un Webex Meetings partecipanti. |
| 3 | Accedere alla riunione da un dispositivo di cui è stata verificata l'identità dalla CA Webex. |
| 4 | In quanto organizzatore, verificare che questo dispositivo venga visualizzato nell'ingresso virtuale con l'icona di identità corretta. |
| 5 | Partecipare alla riunione da un dispositivo di cui è stata verificata l'identità da una CA esterna. |
| 6 | In quanto organizzatore, verificare che questo dispositivo venga visualizzato nell'ingresso virtuale con l'icona di identità corretta. Ulteriori informazioni sulle icone di identità. |
| 7 | Accedere alla riunione come partecipante di riunioni non autenticate. |
| 8 | In quanto organizzatore, verificare che il partecipante venga visualizzato nell'ingresso virtuale con l'icona di identità corretta. |
| 9 | In quanto organizzatore, ammettere o rifiutare persone/dispositivi. |
| 10 | Convalidare l'identità dei partecipanti/dispositivi, ove possibile, controllando i certificati. |
| 11 | Verificare che tutti i partecipanti alla riunione vedano lo stesso codice di sicurezza della riunione. |
| 12 | Accedere alla riunione con un nuovo partecipante. |
| 13 | Verificare che tutti vedano lo stesso codice di sicurezza della riunione nuovo. |
Si stanno per impostare le riunioni con crittografia end-to-end come opzione predefinita della riunione o abilitarla solo per alcuni utenti o consentire a tutti gli organizzatori di decidere? Quando si decide come utilizzare questa funzione, preparare gli utenti che la utilizzeranno, specialmente in relazione alle limitazioni e agli aspetti da prevedere nella riunione.
È necessario assicurarsi che né Cisco né altri utenti possano decrittografare il contenuto o rappresentare i propri dispositivi? In tal caso, sono necessari i certificati di una CA pubblica. È possibile avere fino a 25 dispositivi in una riunione protetta. Se occorre questo livello di sicurezza, non consentire ai client di riunioni di partecipare.
Per gli utenti che a partecipare con dispositivi sicuri, consentire ai dispositivi di accedere prima e impostare le aspettative degli utenti che potrebbero non essere in grado di accedere se si uniscono in ritardo.
Se si dispone di diversi livelli di verifica dell'identità, consentire agli utenti di verificarsi l'un l'altro con l'identità supportata da certificato e il codice di sicurezza della riunione. Anche in alcune circostanze in cui i partecipanti possono apparire come Non verificati e i partecipanti devono sapere come controllare, le persone non verificate potrebbero non essere impostori.
Se si utilizza una CA esterna per rilasciare i certificati del dispositivo, è possibile monitorare, aggiornare e riapplicare i certificati.
Se hai creato il segreto iniziale, comprendi che i tuoi utenti potrebbero voler modificare il segreto del loro dispositivo. A tale scopo, è possibile che sia necessario creare un'interfaccia o distribuire uno strumento.
Prossimamente.
ID tipo di sessione |
Nome servizio pubblico |
|---|---|
638 |
Solo crittografia E2E+VoIP utente |
652 |
Pro-End fino alla fine dincryption_E VOIPonly |
660 |
Pro 3 chiamata end-end gratuita a Encryption_VOIPonly Crittografia E2E + Identità |
672 |
Pro 3 gratuito 50- Fine Encryption_VOIPonly |
673 |
Istruttore istruzione E2E Encryption_VOIPonly |
676 |
Broadworks Standard più crittografia end-to-end |
677 |
Broadworks Premium più crittografia end-to-end |
681 |
Crittografia gratuita gratuita più crittografia end-to-end |
In queste tabelle vengono descritti i comandi API dei dispositivi Webex aggiunti per le riunioni con crittografia end-to-end e l'identità verificata. Per ulteriori informazioni sull'uso dell'API, vedere Accesso all'API per la Webex Room e i dispositivi della scrivania e Webex Boards.
Questi comandi xAPI sono disponibili solo sui dispositivi che sono:
Registrato per Webex
Registrato in locale e collegato a Webex con Webex Edge per dispositivi
chiamata API |
Descrizione |
|---|---|
|
Questa configurazione viene effettuata quando l'amministratore imposta il dominio preferito del dispositivo da Control Hub. Necessario solo se l'organizzazione dispone di più domini. Il dispositivo utilizza questo dominio quando richiede un certificato dalla CA Webex. Il dominio identifica quindi il dispositivo. Questa configurazione non è applicabile se il dispositivo dispone di un certificato attivo ed emesso esternamente per identificare se stesso. |
|
Indica se il dispositivo può accedere a una riunione crittografata end-to-end. L'API cloud chiama in modo che un'app accoppiata sappia se può utilizzare il dispositivo per accedere. |
|
Indica se il dispositivo utilizza |
|
Identità del dispositivo come letta dal nome comune del certificato rilasciato esternamente. |
|
Legge informazioni specifiche da un certificato emesso esternamente. Nel comando visualizzato, sostituire
|
|
Lo stato dell'identità esterna del dispositivo (ad esempio, |
|
Indica se il dispositivo dispone di un certificato valido emesso dalla CA Webex. |
|
Identità del dispositivo come letta dal nome comune del certificato emesso da Webex. Contiene un nome di dominio se l'organizzazione dispone di un dominio. È vuoto se l'organizzazione non dispone di un dominio. Se il dispositivo è in un'organizzazione che dispone di più domini, questo è il valore della pagina |
|
Legge informazioni specifiche del certificato emesso da Webex. Nel comando visualizzato, sostituire
|
chiamata API |
Descrizione |
|---|---|
|
Questi tre eventi ora includono |
chiamata API |
Descrizione |
|---|---|
o
|
Accetta un valore di testo normale codificato base64url per la prima volta che viene restituito il segreto client sul dispositivo. Per aggiornare il segreto dopo tale prima volta, occorre fornire un agente JWE contenente il nuovo segreto crittografato dal segreto precedente. |
|
Aggiunge un certificato (con chiave privata). È stato esteso questo comando per accettare un sistema JWE contenente dati PEM crittografati. |
|
Attiva un certificato specifico per WebexIdentity. Per questo |
|
Disattiva un certificato specifico per WebexIdentity. Per questo |
