Distribuzione di riunioni con attendibilità zero
Sicurezza zero-trust da Webex fornisce crittografia end-to-end e verifica di identità attendibile nelle tue riunioni pianificate e in sala riunioni personale.
Gli utenti scelgono il tipo di riunione quando pianificano una riunione. Quando si ammettono i partecipanti dall'area di ingresso virtuale e durante la riunione, l'organizzatore può visualizzare lo stato di verifica dell'identità di ciascun partecipante. Esiste anche un codice riunione comune a tutti gli attuali partecipanti alla riunione, che possono utilizzare per verificare che la riunione non sia stata intercettata da un Meddler In The Middle (MITM) di terze parti indesiderato.
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 identità
La crittografia end-to-end con verifica dell'identità fornisce ulteriore sicurezza per una riunione con crittografia end-to-end.
Quando i partecipanti o i dispositivi accedono a un gruppo MLS condiviso (Messaging Layer Security), presentano i certificati agli altri membri del gruppo, che quindi convalidano i certificati in base alle autorità di certificazione (CA) che li rilasciano. Confermando la validità dei certificati, la CA verifica l'identità dei partecipanti e la riunione mostra i partecipanti/dispositivi come verificato.
Gli utenti dell'app Webex eseguono l'autenticazione dall'archivio delle identità Webex, che genera un token di accesso quando l'autenticazione ha esito positivo. Se è necessario un certificato per verificare la propria identità in una riunione con crittografia end-to-end, l'autorità di certificazione Webex genera un certificato in base al token di accesso. Attualmente, gli utenti Webex Meetings non possono ottenere un certificato emesso da un'autorità di certificazione esterna/di terze parti.
I dispositivi possono autenticarsi utilizzando un certificato emesso dalla CA interna (Webex) o un certificato emesso da una CA esterna:
-
CA interna: Webex emette un certificato interno in base al token di accesso dell'account macchina del dispositivo. Il certificato è firmato dalla CA Webex. I dispositivi non dispongono di ID utente nello stesso modo in cui gli utenti utilizzano Webex (uno dei) domini della tua organizzazione quando scrivi l'identità del certificato dispositivo (nome comune (CN)).
-
CA esterna: richiedere e acquistare i certificati del dispositivo direttamente dall'emittente scelto. È necessario crittografare, caricare direttamente e autorizzare i certificati utilizzando un segreto noto solo all'utente.
Cisco non è coinvolto, il che rende questo il modo per garantire la vera crittografia end-to-end e l'identità verificata, e prevenire la possibilità teorica che Cisco possa intercettare 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 il nome alternativo oggetto (SAN) verranno visualizzati nell'interfaccia utente della riunione Webex, come descritto nella crittografia end-to-end con verifica dell'identità per Webex Meetings.
Si consiglia di utilizzare un certificato separato per dispositivo e di disporre di un CN univoco per dispositivo. Ad esempio, "meeting-room-1.example.com" per l'organizzazione proprietaria del 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 client secret, è possibile gestire in modo sicuro il certificato di identità Webex esterno tramite xAPI. Questo limite è attualmente limitato ai dispositivi online.
Webex attualmente fornisce i comandi API per la gestione di questa operazione.
Dispositivi
I seguenti dispositivi Webex Room registrati su cloud e serie Webex Desk possono accedere alle riunioni E2EE:
-
Webex Board
-
Webex Desk Pro
-
Webex Desk
-
Webex Room Kit
-
Webex Room Kit Mini
I seguenti dispositivi non possono accedere alle riunioni E2EE:
-
Webex serie C
-
Webex serie DX
-
Webex serie EX
-
Webex serie MX
-
Dispositivi SIP di terze parti
Client software
-
L'app Webex per client desktop e mobili può accedere alle riunioni E2EE.
-
Il client Web Webex non può accedere alle riunioni E2EE.
-
I client soft SIP di terze parti non possono accedere alle riunioni E2EE.
identità
-
Per impostazione predefinita, non forniamo opzioni Control Hub per la gestione dell'identità del dispositivo verificata esternamente. Per una vera crittografia end-to-end, solo l'utente deve conoscere/accedere ai segreti e alle chiavi. Se è stato introdotto un servizio cloud per gestire tali chiavi, è possibile che vengano intercettate.
-
Attualmente forniamo una "ricetta" per progettare i propri strumenti, in base a tecniche di crittografia standard del settore, per assistere nella richiesta o crittografia dei certificati di identità del dispositivo e delle relative chiavi private. Non dobbiamo avere accesso reale o percepiva l'accesso alle vostre chiavi o vostre chiavi.
Riunioni
-
Le riunioni E2EE attualmente supportano un massimo di 1000 partecipanti.
- È possibile condividere nuove lavagne nelle riunioni E2EE. Esistono alcune differenze rispetto alle lavagne nelle riunioni regolari:
- Nelle riunioni E2EE, gli utenti non possono accedere alle lavagne create al di fuori della riunione, incluse lavagne private, lavagne condivise da altri e lavagne dagli spazi Webex.
- Le lavagne create nelle riunioni E2EE sono disponibili solo durante la riunione. Non vengono salvati e non sono accessibili al termine della riunione.
- Se qualcuno condivide contenuto in una riunione E2EE, è possibile annotarlo. Per ulteriori informazioni sulle annotazioni, vedi App Webex | Contrassegna il contenuto condiviso con le annotazioni.
Interfaccia di gestione
Si consiglia vivamente di utilizzare Control Hub per gestire il sito Meetings, poiché le organizzazioni Control Hub hanno un'identità centralizzata per l'intera organizzazione.
Informazioni correlate
-
Sicurezza zero-trust per Webex (documento tecnico di sicurezza)
-
Crittografia Web JSON (JWE) (bozza standard IETF)
-
Webex Meetings 41.7.
-
Dispositivi serie Webex Room e Webex Desk registrati sul cloud, in esecuzione
10.6.1-RoomOS_August_2021
. -
Accesso amministrativo al sito della riunione in Control Hub.
-
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 Consenti ai sistemi video di accedere a riunioni ed eventi sul sito Webex.
Puoi saltare questa fase se non hai bisogno di identità verificate esternamente.
Per il massimo livello di sicurezza e per la verifica dell'identità, ciascun dispositivo deve disporre di un certificato univoco rilasciato da un'autorità di certificazione pubblica attendibile (CA).
È necessario interagire con la CA per richiedere, acquistare e ricevere i certificati digitali e creare le chiavi private associate. Quando si richiede il certificato, utilizzare i seguenti parametri:
-
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. È possibile utilizzare nomi come
name.model@example.com
. -
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.
Puoi ignorare questa operazione se non desideri utilizzare l'identità verificata esternamente con i tuoi dispositivi.
Se si stanno utilizzando nuovi dispositivi, non registrarli ancora in Webex. Per essere sicuri, non connetterli alla rete a questo punto.
Se disponi di dispositivi esistenti che desideri aggiornare per utilizzare un'identità verificata esternamente, devi ripristinare le impostazioni di fabbrica 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. Abbiamo progettato API per il dispositivo per consentire la gestione della chiave crittografata e del certificato, utilizzando JSON Web Encryption (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 hai bisogno di questo livello di sicurezza, devi:
-
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.
Il processo e i parametri (non segreti) di cui avrai bisogno sono spiegati di seguito, così come una ricetta da seguire nei tuoi strumenti di sviluppo di scelta. 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) il proprio strumento per consentire agli utenti del dispositivo di modificare il segreto iniziale e proteggere i relativi supporti da voi.
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.
Fare riferimento a JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 e JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.
Utilizziamo la serializzazione compatta di un documento JSON per creare blobs JWE. I parametri da includere nella creazione dei blobs 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": "A660 GCM"
o"enc": "A660 GCM"
Sono supportati questi due algoritmi di crittografia.
-
"cisco-action": "add"
o"cisco-action": "populate"
o"cisco-action": "activate"
o"cisco-action": "disactivate"
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 denominata
cisco-action
per attenuare potenziali conflitti con future estensioni JWE. -
"cisco-kdf": { "versione": "1", "sale": "base64URLEncodedRandom4+Bytes" }
Un'altra chiave proprietaria. I valori forniti come input per la derivazione chiave sul dispositivo vengono utilizzati. La
versione
deve essere1
(la versione della nostra funzione di derivazione chiave). Il valore disale
deve essere una sequenza con codifica URL base64 di almeno 4 byte, che deve scegliere in modo casuale.
-
-
Chiave crittografata JWE. Campo vuoto. Il dispositivo deriva dal
ClientSecret
iniziale. -
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 (ulteriori dati autenticati). È necessario omettere questo campo poiché non è supportato nel sistema Compact Compact.
-
Testo crittografico JWE: Questo è il carico utile crittografato che si desidera mantenere nascosto.
Il payload PUÒ 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 payload diversi e è necessario specificare lo scopo del payload con il tasto
azione
cisco, come segue:-
Con
"cisco-action":"popolate"
il testo della crittografia è il nuovoClientSecret
. -
Con "
"cisco-action":"add"
il testo della crittografia è un blob PEM che trasporta il certificato e la sua chiave privata (concatenata). -
Con "
"cisco-action":"activate"
il testo della crittografia è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo attivando per la verifica identità del dispositivo. -
Con "
"cisco-action":"deactivate"
il ciphertext è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo disattivando per essere utilizzati 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
Come otteniamo la chiave di crittografia da 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
sale
quando si specifica il parametrocisco-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. Questo kdf sui dispositivi si chiama "versione":"1"
, che è l'unica versione attualmente utilizzata dal parametro 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 cliente nell'esempio è ossifrage
.
-
Scegliere una crittografia. Questo esempio utilizza
A128GCM
(AES con chiavi a 128 bit in modalità contatore Galois). Il tuo strumento potrebbe utilizzareA174 GCM
se preferisci. -
Scegliere un sale (deve essere una sequenza casuale di almeno 4 byte). Questo esempio utilizza (byte esadecimali)
E5 E6 53 08 03 F8 33 F6
. Base64url codifica la sequenza per ottenere5eZTCAP4M_Y
(rimuovere l'imbottitura base64). -
Di seguito è riportata una chiamata di
scrypt
di esempio per creare la chiave di crittografia del contenuto (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 ac
che di base64url codifica alZ66bdEiAQV4_mqdInj_rA
. -
Scegliere una sequenza casuale di 12 byte da utilizzare come vettore di inizializzazione. Questo esempio utilizza (esadecimale)
34 b3 5d dd 5f 53 7b af 2d 92 95 83
, dove la base64url codificaNLNd3V9Te68tkpWD
. -
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 in base64url è
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
Questo 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 del blob 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 payload non crittografato sarà il blob PEM falso
questo è un file PEM
I parametri di crittografia da utilizzare sono:
Payload è
un file PEM
La crittografia della crittografia è AES 128 GCM
Intestazione JOSE codificata base64url come dati autenticati aggiuntivi (AAD)
Base64url codifica il payload crittografato, che dovrebbe risultare in
f5lLVuWNfKfmzYCo1YJfODhQ
Questo è il quarto elemento (testo di crittografia JWE) nel sistema JWE.
-
Base64url codifica il tag prodotto al punto 8, che dovrebbe risultare in
PE-wDFWGXFFBeo928cfZ1Q
Questo è 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-wDFWGXFFBeo928cfZ1Q
-
Se 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:
xCertificati di sicurezza dei comandi Aggiungi
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
I tipi di sessione per le riunioni zero-trust sono disponibili per tutti i siti di riunioni senza costi aggiuntivi. Uno di questi tipi di sessione si chiama Pro-End to End Encryption_VOIPonly
. Questo è il Nome servizio pubblico, che potremmo cambiare in futuro. Per i nomi correnti dei tipi di sessione, vedere ID tipo di sessione nella sezione Riferimento di questo articolo.
Non è necessario fare nulla per ottenere questa funzionalità per il sito; è necessario concedere il nuovo 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 |
Accedi a Control Hub e vai a . |
2 |
Fai clic su Siti , scegli il sito Webex per il quale desideri modificare le impostazioni, quindi fai clic su Impostazioni. |
3 |
In Impostazioni comuni, selezionare Tipi di sessione. |
4 |
È necessario visualizzare uno o più tipi di sessione con 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.
Una versione precedente tipo di sessione con un nome molto simile: Crittografia Pro-End-End. Questa tipo di sessione include l'accesso degli utenti PSTN alle riunioni non crittografato. Accertarsi di disporre della versione _solo VOIP per garantire la crittografia end-to-end. È possibile controllare passando il mouse sul collegamento PRO nella colonna del codice sessione. In questo esempio, il target del collegamento deve essere I nomi dei servizi pubblici per questi tipi di sessione potrebbero essere modificati in futuro. |
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 |
Accedi a Control Hub e vai a . |
2 |
Selezionare un account utente da aggiornare, quindi selezionare Riunioni. |
3 |
Dall'elenco a discesa Impostazioni , selezionare il sito della riunione da aggiornare. |
4 |
Selezionare la casella accanto a Pro-End to End Encryption_VOIPonly. |
5 |
Chiudere il pannello di configurazione dell'utente. |
6 |
Se necessario, ripetere questa operazione per gli altri utenti. Per assegnare questa opzione a molti utenti, utilizzare l'opzione successiva, Abilita riunioni E2EE per più utenti. |
1 |
Accedi a Control Hub e vai a . |
2 |
Fare clic su Siti, scegliere il sito Webex per il quale si desidera modificare le impostazioni. |
3 |
Nella sezione Licenze e utenti, fai clic su Gestione di massa. |
4 |
Fare clic su Genera report e attendere durante la preparazione del file. |
5 |
Quando il file è pronto, fare clic su Esporta risultati, quindi scaricare . Dopo aver fatto clic su Download chiudere manualmente la finestra popup. |
6 |
Aprire il file CSV scaricato per la modifica. Per ogni utente è presente una riga e la colonna |
7 |
Per ciascun utente che si desidera concedere il nuovo tipo di sessione, aggiungere Il riferimento al formato di file CSV Webex contiene dettagli sull'obiettivo e sul contenuto del file CSV. |
8 |
Aprire il pannello Configurazione sito riunione in Control Hub. Se si era già presenti nella pagina di elenco dei siti per riunioni, potrebbe essere necessario aggiornarlo. |
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. |
È possibile aggiungere una filigrana alle registrazioni delle riunioni con il tipo di sessione Webex Meetings Pro-End to End Encryption_VOIPonly
, che consente di identificare il client o il dispositivo di origine delle registrazioni non autorizzate delle riunioni riservate.
Quando questa funzione è abilitata, l'audio della riunione include un identificativo univoco per ciascun client o dispositivo partecipante. È possibile caricare registrazioni audio in Control Hub, che quindi analizza la registrazione e cerca gli identificatori univoci. È possibile esaminare i risultati per vedere quale client di origine o dispositivo ha registrato la riunione.
- Per essere analizzata, la registrazione deve essere un file AAC, MP3, M4A, WAV, MP4, AVI o MOV non più grande di 500 MB.
- La registrazione deve essere più lunga di 100 secondi.
- Puoi analizzare solo le registrazioni per le riunioni organizzate da persone nella tua organizzazione.
- Le informazioni filigrane vengono conservate per la stessa durata delle informazioni della riunione dell'organizzazione.
Aggiungi livelli raggiungibili audio alle riunioni E2EE
- Accedi a Control Hub, quindi in Gestione, seleziona Impostazioni organizzazione.
- Nella sezione Filigrane riunione , attiva Aggiungi filigrana audio.
Qualche tempo dopo l'attivazione, gli utenti che pianificano riunioni con il tipo di sessione
Webex Meetings Pro-End to End Encryption_VOIPonly
visualizzano un'opzione Digital Watermarking nella sezione Sicurezza.
Carica e analizza una riunione contrassegnata da acqua
- In Control Hub, in Monitoraggio, seleziona Risoluzione dei problemi.
- Fare clic su Analisi livello raggiungibile.
- Cercare o selezionare la riunione nell'elenco, quindi fare clic su Analizza.
- Nella finestra Analizza livello raggiungibile audio , immettere un nome per l'analisi.
- (Opzionale) Inserire una nota per l'analisi.
- Trascina la selezione del file audio da analizzare o fai clic su Scegli file per passare al file audio.
- Fare clic su Chiudere.
Una volta completata, l'analisi sarà visualizzata nell'elenco dei risultati nella pagina Analizza livello raggiungibile .
- Selezionare la riunione nell'elenco per visualizzare i risultati dell'analisi. Fare clic su per scaricare i risultati.
Funzioni e limitazioni
I fattori coinvolti nella decodifica di un livello raggiungibile registrato includono la distanza tra il dispositivo di registrazione e l'altoparlante che distribuisce l'audio, il volume dell'audio, il rumore ambientale, ecc. La nostra tecnologia di filigrana ha una resilienza aggiuntiva ad essere codificato più volte, come potrebbe accadere quando i media vengono condivisi.
Questa funzione è progettata per consentire la decodifica riuscita dell'identificatore del livello raggiungibile in un insieme ampio ma ragionevole di circostanze. Il nostro obiettivo è che un dispositivo di registrazione, come un telefono cellulare, che si trova su una scrivania vicino a un endpoint personale o un client portatile, crei sempre una registrazione che risulti in un'analisi di successo. Poiché il dispositivo di registrazione viene allontanato dalla sorgente o viene oscurato dall'ascolto dell'intero spettro audio, le possibilità di un'analisi di successo sono ridotte.
Per analizzare correttamente una registrazione, è necessaria un'acquisizione ragionevole dell'audio della riunione. Se l'audio di una riunione viene registrato sullo stesso computer che ospita il client, le limitazioni non devono essere applicate.
Se i tuoi dispositivi sono già caricati nella tua organizzazione Control Hub e desideri utilizzare la CA Webex per generare automaticamente i certificati di identificazione, non devi ripristinare le impostazioni di fabbrica 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 indica a Webex quale dominio identifica il dispositivo, se ne sceglie automaticamente uno e questo potrebbe apparire errato per gli altri partecipanti alla riunione.
Operazioni preliminari
Se i dispositivi non sono ancora caricati, seguire Registra un dispositivo su Cisco Webex utilizzando l'API o l'interfaccia Web locale o l'onboarding cloud per Board, Desk e serie Room. È inoltre necessario verificare i domini da utilizzare per identificare i dispositivi in Gestisci domini.
1 |
Accedi a Control Hub e in Gestione seleziona 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
-
Ottieni un certificato firmato da CA e una chiave privata, nel formato
.pem
, per ogni dispositivo. -
Nella scheda Prepara , leggi l'argomento Comprensione del processo di identità esterna per i dispositivi,
-
Preparare uno strumento di crittografia JWE in relazione alle informazioni in esso contenute.
-
Assicurarsi di avere uno strumento per generare sequenze byte casuali di determinate lunghezze.
-
Accertarsi di disporre di uno strumento per la base di byte o testo di codifica di64url.
-
Assicurati di disporre di un'
implementazione scrypt
. -
Assicurati di avere una parola o una frase segreta per ciascun dispositivo.
1 |
Popolare La prima volta che popolate il Il dispositivo ha il segreto iniziale. Non dimenticare questo; non puoi recuperarlo e devi ripristinare le impostazioni di fabbrica del dispositivo per riavviarlo.
|
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 stato aggiunto eseguendo Copiare le impronte digitali del nuovo certificato. |
6 |
Attivare il certificato allo scopo 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 delle 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 |
Se possibile, convalida le identità dei partecipanti/dispositivi 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.
-
Se disponi di diversi livelli di verifica dell'identità, consenti agli utenti di verificarsi a vicenda con l'identità supportata dal certificato. 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.
ID tipo di sessione |
Nome servizio pubblico |
---|---|
638 |
Solo crittografia E2E+VoIP utente |
652 |
Pro-End fino alla fine EVOIPonlyncryption_ |
660 |
Fine gratuita Pro 3 a fine EVOIPonlyncryption_ Crittografia E2E + Identità |
672 |
Pro 3 gratuito 50-fine EVOIPonlyncryption_ |
673 |
Istruttore istruzione E2E EVOIPonlyncryption_ |
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 la verifica |
|
Identità del dispositivo come letta dal nome comune del certificato rilasciato esternamente. |
|
Legge informazioni specifiche da un certificato emesso esternamente. Nel comando mostrato, 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 si trova in un'organizzazione con più domini, questo è il valore di |
|
Legge informazioni specifiche del certificato emesso da Webex. Nel comando mostrato, 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 |