Hartelijk dank voor uw feedback
Zero Trust-vergaderingen implementeren
Feedback?
Gebruikers kiezen het vergaderingstype wanneer ze een vergadering plannen. Wanneer u deelnemers toelaat vanuit de lobby en tijdens de vergadering, kan de host de identiteitsverificatiestatus van elke deelnemer zien. Er is ook een vergaderingscode die alle huidige deelnemers aan de vergadering gemeen hebben, die ze kunnen gebruiken om te controleren of hun vergadering niet is onderschept door een ongewenste MITM-aanval (Meddler In The Middle) van een derde partij.
Deel de volgende informatie met de hosts van uw vergadering:
-
Deelnemen aan een Webex-vergadering met end-to-end-codering
Identiteit verifiëren
End-to-end-codering met identiteitsverificatie biedt extra beveiliging aan een end-to-end gecodeerde vergadering.
Wanneer deelnemers of apparaten deelnemen aan een gedeelde MLS-groep (Messaging Layer Security), presenteren ze hun certificaten aan de andere groepsleden, die de certificaten vervolgens valideren voor de uitgevende certificeringsinstanties. Door te bevestigen dat de certificaten geldig zijn, verifieert de CA de identiteit van de deelnemers en toont de vergadering de deelnemers/apparaten als geverifieerd.
Gebruikers van de Webex-app verifiëren zichzelf op basis van de Webex-identiteitsopslag. Hierdoor krijgen ze een toegangstoken wanneer de verificatie slaagt. Als ze een certificaat nodig hebben om hun identiteit te verifiëren in een end-to-end gecodeerde vergadering, geeft de Webex-CA ze een certificaat uit op basis van hun toegangstoken. Op dit moment bieden we geen manier voor Webex Meetings-gebruikers om een certificaat te krijgen dat is uitgegeven door een externe/externe CA.
Apparaten kunnen zichzelf verifiëren met een certificaat dat is uitgegeven door de interne (Webex) CA of een certificaat dat is uitgegeven door een externe CA:
-
Interne CA: Webex geeft een intern certificaat uit dat is gebaseerd op het toegangstoken van het machineaccount van het apparaat. Het certificaat is ondertekend door de Webex CA. Apparaten hebben geen gebruikers-id's op dezelfde manier als gebruikers. Daarom gebruikt Webex (een van) de domeinen van uw organisatie bij het schrijven van de identiteit van het apparaatcertificaat (Common Name (CN)).
-
Externe CA: vraag en koop apparaatcertificaten rechtstreeks bij de gekozen uitgever. U moet de certificaten coderen, rechtstreeks uploaden en autoriseren met een geheim dat alleen u bekend is.
Cisco is niet betrokken. Dit maakt dit de manier om echte end-to-end-codering en geverifieerde identiteit te garanderen en de theoretische mogelijkheid te voorkomen dat Cisco uw vergadering kan afluisteren/uw media kan decoderen.
Intern uitgegeven apparaatcertificaat
Webex geeft een certificaat uit aan het apparaat wanneer het wordt geregistreerd na het opstarten en verlengt het indien nodig. Voor apparaten bevat het certificaat de account-id en een domein.
Als uw organisatie geen domein heeft, geeft de Webex-CA het certificaat zonder domein af.
Als uw organisatie meerdere domeinen heeft, kunt u Control Hub gebruiken om Webex te vertellen welk domein het apparaat moet gebruiken voor de identiteit. U kunt ook de API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com" gebruiken.
Als u meerdere domeinen hebt en u niet het voorkeursdomein voor het apparaat instelt, kiest Webex er een voor u.
Extern uitgegeven apparaatcertificaat
Een beheerder kan een apparaat inrichten met een eigen certificaat dat is ondertekend bij een van de openbare CA's.
Het certificaat moet zijn gebaseerd op een ECDSA P-256-sleutelpaar, hoewel het kan worden ondertekend met een RSA-sleutel.
De waarden in het certificaat worden naar goeddunken van de organisatie bepaald. De algemene naam (AN) en de alternatieve naam (SAN) van het onderwerp worden weergegeven in de gebruikersinterface van de Webex-vergadering, zoals beschreven in End-to-end-codering met identiteitsverificatie voor Webex Meetings.
We raden aan per apparaat een afzonderlijk certificaat te gebruiken en per apparaat een unieke CN te hebben. Bijvoorbeeld 'meeting-room-1.voorbeeld.com' voor de organisatie die eigenaar is van het domein 'voorbeeld.com'.
Om het externe certificaat volledig te beschermen tegen manipulatie, wordt een client-geheime functie gebruikt om verschillende xcommands te coderen en te ondertekenen.
Bij gebruik van het clientgeheim is het mogelijk om het externe Webex-identiteitscertificaat veilig te beheren via de xAPI. Dit is momenteel beperkt tot online apparaten.
Webex biedt momenteel API-opdrachten om dit te beheren.
Apparaten
De volgende cloud-geregistreerde apparaten uit de Webex Room-serie en Webex Desk-serie kunnen deelnemen aan E2EE-vergaderingen:
-
Webex Board
-
Webex Desk Pro
-
Webex-bureau
-
Webex Room-kit
-
Webex Room Kit Mini
De volgende apparaten kunnen niet deelnemen aan E2EE-vergaderingen:
-
Webex C-serie
-
Webex DX-serie
-
Webex EX-serie
-
Webex MX-serie
-
SIP-apparaten van derden
Softwareclients
-
De Webex-app voor desktop- en mobiele clients kan deelnemen aan E2EE-vergaderingen.
-
De Webex-webclient kan niet deelnemen aan E2EE-vergaderingen.
-
SIP-softclients van derden kunnen niet deelnemen aan E2EE-vergaderingen.
Identiteit
-
Er is bepaald dat we geen Control Hub-opties bieden voor het beheren van extern geverifieerde apparaatidentiteit. Voor echte end-to-end-codering moet alleen u de geheimen en sleutels kennen/openen. Als we een cloudservice hebben geïntroduceerd om deze sleutels te beheren, bestaat de kans dat ze worden onderschept.
-
Momenteel bieden wij u een 'recept' om uw eigen tools te ontwerpen, gebaseerd op industriestandaard encryptietechnieken, om te helpen bij het aanvragen of versleutelen van uw apparaatidentiteitscertificaten en hun privésleutels. We willen geen echte of vermeende toegang hebben tot uw geheimen of sleutels.
Vergaderingen
-
E2EE-vergaderingen ondersteunen momenteel maximaal 1000 deelnemers.
- U kunt nieuwe whiteboards delen in E2EE-vergaderingen. Er zijn enkele verschillen met whiteboards in reguliere vergaderingen:
- In E2EE-vergaderingen hebben gebruikers geen toegang tot whiteboards die buiten de vergadering zijn gemaakt, inclusief privéwhiteboards, whiteboards gedeeld door anderen en whiteboards uit Webex-ruimten.
- Whiteboards die zijn gemaakt in E2EE-vergaderingen zijn alleen beschikbaar tijdens de vergadering. Deze worden niet opgeslagen en zijn niet toegankelijk nadat de vergadering is beëindigd.
- Als iemand inhoud deelt in een E2EE-vergadering, kunt u aantekeningen maken op deze inhoud. Zie Webex-app | Gedeelde inhoud met aantekeningen markeren voor meer informatie over aantekeningen.
Beheerinterface
We raden u ten zeerste aan Control Hub te gebruiken om uw Meetings-site te beheren, omdat Control Hub-organisaties de identiteit voor de hele organisatie hebben gecentraliseerd.
Gerelateerde informatie
-
Zero-Trust Security voor Webex (technisch document over beveiliging)
-
JSON Web Encryption (JWE) (concept-IETF-standaard)
-
Webex Meetings 41.7.
-
Cloudgeregistreerde apparaten uit de Webex Room- en Webex Desk-serie, waarop
10.6.1-RoomOS_August_2021wordt uitgevoerd. -
Administratieve toegang tot de vergadersite in Control Hub.
-
Een of meer geverifieerde domeinen in uw Control Hub-organisatie (als u de Webex CA gebruikt om apparaatcertificaten voor geverifieerde identiteit uit te geven).
-
Samenwerkingsvergaderruimten (CMR) moeten zijn ingeschakeld zodat mensen kunnen deelnemen vanaf hun videosysteem. Zie Videosystemen toestaan deel te nemen aan vergaderingen en gebeurtenissen op uw Webex-site voor meer informatie.
U kunt deze stap overslaan als u geen extern geverifieerde identiteiten nodig hebt.
Voor het hoogste beveiligingsniveau en voor identiteitsverificatie moet elk apparaat beschikken over een uniek certificaat dat wordt uitgegeven door een vertrouwde openbare certificeringsinstantie (CA).
U moet communiceren met de CA om de digitale certificaten aan te vragen, te kopen en te ontvangen en de bijbehorende privésleutels te maken. Wanneer u het certificaat aanvraagt, gebruikt u deze parameters:
-
Het certificaat moet worden afgegeven en ondertekend door een bekende openbare certificeringsinstantie.
-
Uniek: We raden u ten zeerste aan voor elk apparaat een uniek certificaat te gebruiken. Als u één certificaat gebruikt voor alle apparaten, brengt u uw beveiliging in gevaar.
-
Algemene naam (CN) en alternatieve naam/namen onderwerp (SAN/namen): Deze zijn niet belangrijk voor Webex, maar moeten waarden zijn die mensen kunnen lezen en aan het apparaat kunnen koppelen. De algemene naam wordt weergegeven aan andere deelnemers aan de vergadering als de primaire geverifieerde identiteit van het apparaat en als gebruikers het certificaat via de gebruikersinterface van de vergadering inspecteren, zien ze de SAN('s). Mogelijk wilt u namen als
name.model@example.comgebruiken. -
Bestandsindeling: De certificaten en sleutels moeten de
.pemindeling hebben. -
Doel: Het certificaatdoel moet Webex-identiteit zijn.
-
Sleutels genereren: De certificaten moeten gebaseerd zijn op ECDSA P-256 sleutelparen (Elliptical Curve Digital Signature Algorithm met behulp van de P-256-curve).
Deze vereiste geldt niet voor de ondertekeningssleutel. De CA kan een RSA-sleutel gebruiken om het certificaat te ondertekenen.
U kunt deze stap overslaan als u geen extern geverifieerde identiteit met uw apparaten wilt gebruiken.
Als u nieuwe apparaten gebruikt, moet u deze nog niet registreren bij Webex. Verbind ze op dit moment niet met het netwerk om veilig te zijn.
Als u bestaande apparaten hebt die u wilt upgraden om extern geverifieerde identiteit te gebruiken, moet u de fabrieksinstellingen van de apparaten herstellen.
-
Sla de bestaande configuratie op als u deze wilt behouden.
-
Plan een venster wanneer de apparaten niet worden gebruikt of gebruik een gefaseerde aanpak. Breng gebruikers op de hoogte van de wijzigingen die ze kunnen verwachten.
-
Zorg voor fysieke toegang tot apparaten. Als u toegang moet krijgen tot apparaten via het netwerk, houd er dan rekening mee dat geheimen reizen in platte tekst en dat u uw veiligheid in het gedrang brengt.
Als u deze stappen hebt voltooid, kunnen videosystemen deelnemen aan vergaderingen en gebeurtenissen op uw Webex-site.
Om ervoor te zorgen dat de media van uw apparaat niet door iemand anders kunnen worden gecodeerd, behalve het apparaat, moet u de privésleutel op het apparaat coderen. We hebben API's voor het apparaat ontworpen om het beheer van de gecodeerde sleutel en het certificaat mogelijk te maken met behulp van JSON Web Encryption (JWE).
We kunnen niet betrokken zijn bij het coderen en uploaden van het certificaat en de sleutel om echte end-to-end-codering via onze cloud te garanderen. Als u dit beveiligingsniveau nodig hebt, moet u:
-
Vraag uw certificaten aan.
-
Genereer de sleutelparen van uw certificaten.
-
Maak (en bescherm) een eerste geheim voor elk apparaat om de coderingsmogelijkheden van het apparaat te seed.
-
Ontwikkel en onderhoud uw eigen tool voor het versleutelen van bestanden met behulp van de JWE standaard.
Het proces en de (niet-geheime) parameters die je nodig hebt worden hieronder uitgelegd, evenals een recept dat je moet volgen in je ontwikkeltools naar keuze. We leveren ook enkele testgegevens en de resulterende JWE-blobs zoals we verwachten, om u te helpen uw proces te verifiëren.
Een niet-ondersteunde referentie-implementatie met behulp van Python3 en de JWCrypto-bibliotheek is op verzoek beschikbaar bij Cisco.
-
Voeg het certificaat en de sleutel samen en coderen met uw hulpprogramma en het initiële geheim van het apparaat.
-
Upload de resulterende JWE-blob naar het apparaat.
-
Stel het doel in van het gecodeerde certificaat dat moet worden gebruikt voor de Webex-identiteit en activeer het certificaat.
-
(Aanbevolen) Zorg voor een interface voor (of distribueer) uw hulpprogramma zodat apparaatgebruikers het oorspronkelijke geheim kunnen wijzigen en hun media tegen u kunnen beschermen.
Hoe we de JWE-indeling gebruiken
In dit gedeelte wordt beschreven hoe we verwachten dat de JWE wordt gemaakt als invoer voor de apparaten, zodat u uw eigen tool kunt maken om de blobs van uw certificaten en sleutels te maken.
Raadpleeg JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 en JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.
We gebruiken de compacte serialisatie van een JSON-document om JWE-blobs te maken. De parameters die u moet opnemen bij het maken van de JWE-blobs zijn:
-
JOSE-koptekst (beveiligd). In de koptekst JSON-objectondertekening en -codering MOET u de volgende paren met sleutelwaarden opnemen:
-
"alg":"dir"Het directe algoritme is het enige algoritme dat wij ondersteunen voor de codering van de payload. U moet het initiële clientgeheim van het apparaat gebruiken.
-
"enc":"A128GCM"of"enc":"A256GCM"We ondersteunen deze twee coderingsalgoritmen.
-
"cisco-action": "add"of"cisco-action": "populate"of"cisco-action": "activate"of"cisco-action": "deactivate"Dit is een eigen sleutel en vier waarden die het kan aannemen. We hebben deze sleutel geïntroduceerd om het doel van de gecodeerde gegevens aan het doelapparaat aan te geven. De waarden zijn vernoemd naar de xAPI-opdrachten op het apparaat waarop u de gecodeerde gegevens gebruikt.
We noemden het
cisco-actionom mogelijke botsingen met toekomstige JWE-extensies te verzachten. -
"cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }Nog een eigen sleutel. We gebruiken de waarden die u opgeeft als invoer voor sleutelafleiding op het apparaat. De
versionmoet1(de versie van onze sleutelafleidingsfunctie) zijn. De waarde vansaltmoet een base64 URL-gecodeerde reeks van ten minste 4 bytes zijn, die u willekeurig moet kiezen.
-
-
JWE-gecodeerde sleutel. Dit veld is leeg. Het apparaat ontleent het aan de eerste
ClientSecret. -
JWE-initialisatievector. U moet een basis64url-gecodeerde initialisatievector opgeven voor het decoderen van de payload. De IV MOET een willekeurige waarde van 12 bytes zijn (we gebruiken de AES-GCM-versleutelingsfamilie, waarvoor de IV 12 bytes lang moet zijn).
-
JWE AAD (aanvullende geverifieerde gegevens). U moet dit veld weglaten omdat het niet wordt ondersteund in de compacte serialisatie.
-
JWE-cijfertekst: Dit is de gecodeerde payload die u geheim wilt houden.
De payload is MOGELIJK leeg. Als u het clientgeheim bijvoorbeeld wilt herstellen, moet u het overschrijven met een lege waarde.
Er zijn verschillende soorten payloads, afhankelijk van wat u probeert te doen op het apparaat. Verschillende xAPI-opdrachten verwachten verschillende payloads en u moet het doel van de payload met de
cisco-actionsleutel als volgt opgeven:-
Met
"cisco-action":"populate"de cijfertekst is de nieuweClientSecret. -
Met "
"cisco-action":"add"is de cijfertekst een PEM-blob met het certificaat en de private sleutel (concatenated). -
Met '
"cisco-action":"activate"is de cijfertekst de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we activeren voor apparaatverificatie. -
Met '
"cisco-action":"deactivate"is de cijfertekst de vingerafdruk (hexadecimale weergave van sha-1) van het certificaat dat we deactiveren voor de verificatie van de apparaatidentiteit.
-
-
JWE-verificatielabel: Dit veld bevat de verificatielabel om de integriteit van de gehele JWE compact geserialiseerde blob te verifiëren
Hoe we de coderingssleutel afleiden van de ClientSecret
Na de eerste populatie van het geheim accepteren of produceren we het geheim niet als platte tekst. Dit is om mogelijke woordenboekaanvallen te voorkomen door iemand die toegang heeft tot het apparaat.
De apparaatsoftware gebruikt het clientgeheim als invoer voor een sleutelafleidingsfunctie (kdf) en gebruikt vervolgens de afgeleide sleutel voor decodering/codering van inhoud op het apparaat.
Wat dit voor u betekent is dat uw tool om JWE-blobs te produceren dezelfde procedure moet volgen om dezelfde codering / decryptie sleutel af te leiden van de client geheim.
De apparaten gebruiken coderen voor sleutelafleiding (zie https://en.wikipedia.org/wiki/Scrypt), met de volgende parameters:
-
Kostenfactor (N) is 32768
-
BlockSizeFactor (r) is 8
-
Parallelisatiefactor (p) is 1
-
Zout is een willekeurige reeks van ten minste 4 bytes. U moet hetzelfde opgeven
saltwanneer u decisco-kdfparameter opgeeft. -
De sleutellengtes zijn 16 bytes (als u het AES-GCM 128-algoritme selecteert) of 32 bytes (als u het AES-GCM 256-algoritme selecteert)
-
De maximale geheugenlimiet is 64 MB
Deze set parameters is de enige configuratie van scrypt die compatibel is met de sleutelafleidingsfunctie op de apparaten. Deze kdf op de apparaten heet "version":"1", de enige versie die momenteel wordt gebruikt door de parameter cisco-kdf .
Bewerkt voorbeeld
Hier volgt een voorbeeld dat u kunt volgen om te controleren of uw JWE-coderingsproces hetzelfde werkt als het proces dat we op de apparaten hebben gemaakt.
Het voorbeeldscenario is het toevoegen van een PEM-blob aan het apparaat (bootst het toevoegen van een certificaat na, met een zeer korte tekenreeks in plaats van een volledig certificaat + sleutel). Het clientgeheim in het voorbeeld is ossifrage.
-
Kies een coderingscode. In dit voorbeeld wordt
A128GCMgebruikt (AES met 128-bits toetsen in de Galois Counter Mode). Uw tool kan gebruikenA256GCMals u dat wilt. -
Kies een zout (moet een willekeurige reeks van ten minste 4 bytes zijn). In dit voorbeeld wordt (hex-bytes)
E5 E6 53 08 03 F8 33 F6gebruikt. Basis64url codeert de volgorde die moet worden opgehaald5eZTCAP4M_Y(verwijder de base64-opvulling). -
Hier volgt een voorbeeldgesprek
scryptom de coderingssleutel voor inhoud (cek) te maken:cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)De afgeleide sleutel moet 16 bytes (hex) zijn als volgt:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff acwaarvan de basis64url-coderingenlZ66bdEiAQV4_mqdInj_rA. -
Kies een willekeurige reeks van 12 bytes om als initialisatievector te gebruiken. In dit voorbeeld wordt gebruikt (hex)
34 b3 5d dd 5f 53 7b af 2d 92 95 83waarbij64URL-codes worden gebaseerd opNLNd3V9Te68tkpWD. -
Maak de JOSE-header met compacte serialisatie (volg dezelfde volgorde van parameters die we hier gebruiken) en voer vervolgens de basis64url-codering uit:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}De JOSE-koptekst van de basis64url is
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9Dit wordt het eerste element van de JWE blob.
-
Het tweede element van de JWE-blob is leeg, omdat we geen JWE-coderingssleutel leveren.
-
Het derde element van de JWE-blob is de initialisatievector
NLNd3V9Te68tkpWD. - Gebruik uw JWE-coderingstool om een gecodeerde payload en tag te produceren. In dit voorbeeld wordt de ongecodeerde payload de valse PEM-blob
this is a PEM fileDe coderingsparameters die u moet gebruiken zijn:
Nettolading is
this is a PEM fileCoderingscode is AES 128 GCM
De basis64url-gecodeerde JOSE-koptekst als Aanvullende geverifieerde gegevens (AAD)
Basis64url codeert de gecodeerde payload, wat moet leiden tot
f5lLVuWNfKfmzYCo1YJfODhQDit is het vierde element (JWE Ciphertext) in de JWE blob.
-
Basis64url codeert de tag die u in stap 8 hebt geproduceerd, wat moet resulteren in
PE-wDFWGXFFBeo928cfZ1QDit is het vijfde element in de JWE blob.
-
Voeg de vijf elementen van de JWE-blob samen met stippen (JOSEheader..IV.Ciphertext.Tag) om het volgende te krijgen:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q -
Als u dezelfde basis64url-gecodeerde waarden hebt afgeleid die we hier weergeven, met behulp van uw eigen tools, bent u klaar om deze te gebruiken om de E2E-codering en de geverifieerde identiteit van uw apparaten te beveiligen.
-
Dit voorbeeld zal niet werken, maar in principe zou je volgende stap zijn om de JWE-blob te gebruiken die je hierboven hebt gemaakt als invoer voor de xcommand op het apparaat dat het certificaat toevoegt:
xCommand Security Certificates AddeyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Sessietypen voor Zero Trust-vergaderingen zijn beschikbaar voor alle vergaderingssites zonder extra kosten. Een van deze sessietypen heet Pro-End to End Encryption_VOIPonly. Dit is de Naam openbare dienst. Deze kan in de toekomst worden gewijzigd. Zie Sessietype-id's in het gedeelte Referentie van dit artikel voor de huidige namen van de sessietypen.
U hoeft niets te doen om deze mogelijkheid voor uw site te gebruiken. U moet het nieuwe sessietype (ook wel Vergaderrechten genoemd) aan gebruikers toewijzen. U kunt dit afzonderlijk doen via de configuratiepagina van de gebruiker of in bulk met een CSV-export/import.
De volgende stappen
Schakel dit sessietype/vergaderrecht in voor enkele of al uw gebruikers.
| 1 | |
| 2 |
Selecteer een gebruikersaccount dat u wilt bijwerken en selecteer vervolgens Vergaderingen. |
| 3 |
Selecteer in de vervolgkeuzelijst Instellingen toepassen op de vergadersite die u wilt bijwerken. |
| 4 |
Schakel het selectievakje naast Pro-End to End Encryption_Only VOIP in. |
| 5 |
Sluit het deelvenster Gebruikersconfiguratie. |
| 6 |
Herhaal dit indien nodig voor andere gebruikers. Als u dit aan veel gebruikers wilt toewijzen, gebruikt u de volgende optie E2EE-vergaderingen inschakelen voor meerdere gebruikers. |
| 1 |
Meld u aan bij Control Hub en ga naar Services > Vergadering. |
| 2 |
Klik op Sites en kies de Webex-site waarvoor u de instellingen wilt wijzigen. |
| 3 |
Klik in het gedeelte Licenties en gebruikers op In bulk beheren. |
| 4 |
Klik op Rapport genereren en wacht terwijl we het bestand voorbereiden. |
| 5 |
Als het bestand gereed is, klikt u op Resultaten exporteren en vervolgens op Downloaden. (U moet dat pop-upvenster handmatig sluiten nadat u op Downloaden hebt geklikt.) |
| 6 |
Open het gedownloade CSV-bestand om te bewerken. Er is een rij voor elke gebruiker en de |
| 7 |
Voor elke gebruiker die u het nieuwe sessietype wilt toewijzen, voegt u De Naslag Webex CSV-bestandsindeling bevat details over het doel en de inhoud van het CSV-bestand. |
| 8 |
Open het configuratiescherm van de vergaderingssite in Control Hub. Als u al op de pagina Lijst met vergaderingssites stond, moet u deze mogelijk vernieuwen. |
| 9 |
Klik in het gedeelte Licenties en gebruikers op In bulk beheren. |
| 10 |
Klik op Importeren en selecteer het bewerkte CSV-bestand en klik vervolgens op Importeren. Wacht terwijl het bestand is geüpload. |
| 11 |
Als het importeren is voltooid, kunt u klikken op Resultaten importeren om te controleren of er fouten zijn opgetreden. |
| 12 |
Ga naar de pagina Gebruikers en open een van de gebruikers om te controleren of ze het nieuwe sessietype hebben. |
U kunt een watermerk toevoegen aan vergaderingsopnamen met het Webex Meetings Pro-End to End Encryption_VOIPonly sessietype, waarmee u de bronclient of het apparaat van onbevoegde opnamen van vertrouwelijke vergaderingen kunt identificeren.
Wanneer deze functie is ingeschakeld, bevat de audio van de vergadering een unieke id voor elke deelnemende client of elk apparaat. U kunt audio-opnamen uploaden naar Control Hub, die de opname vervolgens analyseert en de unieke id's opzoekt. U kunt de resultaten bekijken om te zien welke bronclient of welk apparaat de vergadering heeft opgenomen.
- Om te worden geanalyseerd, moet de opname een AAC-, MP3-, M4A-, WAV-, MP4-, AVI- of MOV-bestand zijn dat niet groter is dan 500 MB.
- De opname moet langer dan 100 seconden zijn.
- U kunt alleen opnamen analyseren voor vergaderingen die worden gehost door mensen in uw organisatie.
- Watermerkgegevens worden bewaard voor dezelfde duur als de vergaderingsgegevens van de organisatie.
Audiowatermerken toevoegen aan E2EE-vergaderingen
- Meld u aan bij Control Hub en selecteer onder Beheer de optie Organisatie-instellingen.
- In het gedeelte Watermerken voor vergaderingen schakelt u Audiowatermerk toevoegen in.
Nadat dit is ingeschakeld, zien gebruikers die vergaderingen plannen met het sessietype
Webex Meetings Pro-End to End Encryption_VOIPonlyeen optie voor Digitale watermerken in het gedeelte Beveiliging.
Een watergemarkeerde vergadering uploaden en analyseren
- Selecteer in Control Hub onder Bewaking de optie Problemen oplossen.
- Klik op Watermerkanalyse.
- Zoek of selecteer de vergadering in de lijst en klik vervolgens op Analyseren.
- Voer in het venster Audiowatermerk analyseren een naam in voor uw analyse.
- (Optioneel) Voer een opmerking voor uw analyse in.
- Sleep het audiobestand dat moet worden geanalyseerd en zet het neer of klik op Bestand kiezen om naar het audiobestand te bladeren.
- Klik op Sluiten.
Wanneer de analyse is voltooid, wordt deze weergegeven in de lijst met resultaten op de pagina Watermerk analyseren .
- Selecteer de vergadering in de lijst om de resultaten van de analyse weer te geven. Klik op
om de resultaten te downloaden.
Functies en beperkingen
Factoren die betrokken zijn bij het succesvol decoderen van een opgenomen watermerk zijn onder andere de afstand tussen het opnameapparaat en de luidspreker die de audio overschrijdt, het volume van die audio, omgevingsgeluid, enzovoort. Onze watermerktechnologie heeft extra veerkracht om meerdere keren te worden gecodeerd, wat ook kan gebeuren wanneer de media wordt gedeeld.
Deze functie is ontworpen om succesvolle decodering van de watermerk-id in een brede maar redelijke reeks omstandigheden mogelijk te maken. Ons doel is dat een opnameapparaat, zoals een mobiele telefoon, dat op een bureau ligt in de buurt van een persoonlijk eindpunt of een laptopclient, altijd een opname moet maken die resulteert in een succesvolle analyse. Als het opnameapparaat van de bron wordt verwijderd of het volledige audiospectrum niet kan worden gehoord, neemt de kans op een succesvolle analyse af.
Voor een geslaagde analyse van een opname is een redelijke opname van de audio van de vergadering nodig. Als de audio van een vergadering wordt opgenomen op dezelfde computer die als host fungeert voor de client, zijn er geen beperkingen van toepassing.
Als uw apparaten al zijn geïntegreerd in uw Control Hub-organisatie en u de Webex CA wilt gebruiken om de identificatiecertificaten automatisch te genereren, hoeft u de apparaten niet te resetten naar de fabrieksinstellingen.
Met deze procedure wordt geselecteerd welk domein het apparaat gebruikt om zichzelf te identificeren. Dit is alleen vereist als u meerdere domeinen in uw Control Hub-organisatie hebt. Als u meer dan één domein hebt, raden we u aan dit te doen voor al uw apparaten met een 'Cisco-geverifieerde' identiteit. Als u niet aan Webex vertelt welk domein het apparaat identificeert, wordt er automatisch een gekozen en ziet dit er mogelijk fout uit voor andere deelnemers aan de vergadering.
Voordat u begint
Als uw apparaten nog niet zijn geïntegreerd, volgt u Een apparaat bij Cisco Webex registreren via API of lokale webinterface of Cloud-integratie voor Board, Desk en Room Series. U moet ook de domeinen verifiëren die u wilt gebruiken om de apparaten in Uw domeinen beheren te identificeren.
| 1 |
Meld u aan bij Control Hub en selecteer Apparaten onder Beheer. |
| 2 |
Selecteer een apparaat om het configuratiescherm te openen. |
| 3 |
Selecteer het domein dat u wilt gebruiken om dit apparaat te identificeren. |
| 4 |
Herhalen voor andere apparaten. |
Voordat u begint
-
Haal een door een CA ondertekend certificaat en een privésleutel in
.pemindeling voor elk apparaat op. -
Lees op het tabblad Voorbereiden het onderwerp Het proces van externe identiteit voor apparaten begrijpen.
-
Bereid een JWE-coderingstool voor met betrekking tot de daar aanwezige informatie.
-
Zorg ervoor dat u een hulpmiddel hebt om willekeurige bytereeksen van bepaalde lengtes te genereren.
-
Zorg ervoor dat u een hulpprogramma hebt om de bytes of tekst van64url-coderingen te baseren.
-
Zorg ervoor dat u een
scryptimplementatie hebt. -
Zorg ervoor dat u voor elk apparaat een geheim woord of een geheime zin hebt.
| 1 |
Vul het apparaat in De eerste keer dat u de Het apparaat heeft zijn initiële geheim. Vergeet dit niet; u kunt het niet herstellen en moet de fabrieksinstellingen van het apparaat opnieuw instellen om opnieuw te starten.
|
| 2 |
Voeg uw certificaat en privésleutel samen: |
| 3 |
Maak een JWE-blob om te gebruiken als invoer voor de opdracht voor het toevoegen van certificaten: |
| 4 |
Open de TShell op het apparaat en voer de opdracht voor toevoegen (meerdere regels) uit: |
| 5 |
Verifieer of het certificaat is toegevoegd door Kopieer de vingerafdruk van het nieuwe certificaat. |
| 6 |
Activeer het certificaat voor het doel Het apparaat heeft een gecodeerd, actief, door een certificeringsinstantie uitgegeven certificaat, dat klaar is voor gebruik om het te identificeren in end-to-end gecodeerde Webex-vergaderingen.
|
| 7 |
Integreer het apparaat in uw Control Hub-organisatie. |
| 1 |
Plan een vergadering van het juiste type (Webex Meetings Pro-End to End Encryption_Alleen VOIP). |
| 2 |
Neem als host deel aan de vergadering, vanuit een Webex Meetings-client. |
| 3 |
Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door de Webex CA. |
| 4 |
Als host controleert u of dit apparaat in de lobby wordt weergegeven met het juiste identiteitspictogram. |
| 5 |
Neem deel aan de vergadering vanaf een apparaat waarvan de identiteit is geverifieerd door een externe CA. |
| 6 |
Als host controleert u of dit apparaat in de lobby wordt weergegeven met het juiste identiteitspictogram. Meer informatie over identiteitspictogrammen. |
| 7 |
Deelnemen aan de vergadering als een niet-geverifieerde deelnemer aan de vergadering. |
| 8 |
Als host controleert u of deze deelnemer in de lobby wordt weergegeven met het juiste identiteitspictogram. |
| 9 |
Als host personen/apparaten toelaten of weigeren. |
| 10 |
Valideer deelnemers-/apparaatidentiteiten waar mogelijk door de certificaten te controleren. |
| 11 |
Controleer of iedereen in de vergadering dezelfde beveiligingscode voor de vergadering ziet. |
| 12 |
Neem deel aan de vergadering met een nieuwe deelnemer. |
| 13 |
Controleer of iedereen dezelfde, nieuwe beveiligingscode voor de vergadering ziet. |
-
Gaat u end-to-end gecodeerde vergaderingen de standaardvergaderoptie maken, of deze alleen voor sommige gebruikers inschakelen of alle hosts toestaan te beslissen? Wanneer u hebt besloten hoe u deze functie gaat gebruiken, bereidt u de gebruikers voor die deze gaan gebruiken, vooral met betrekking tot de beperkingen en wat ze kunnen verwachten in de vergadering.
-
Moet u ervoor zorgen dat Cisco noch iemand anders uw inhoud kunnen decoderen of zich voor uw apparaten kunnen doen gelden? Als dat het geval is, hebt u certificaten van een openbare CA nodig.
-
Als u verschillende niveaus van identiteitsverificatie hebt, kunt u gebruikers de mogelijkheid geven om elkaar te verifiëren met een identiteit op basis van certificaten. Hoewel er omstandigheden zijn waarin deelnemers kunnen verschijnen als Niet-geverifieerd en deelnemers moeten weten hoe ze moeten controleren, zijn niet-geverifieerde personen mogelijk geen bedriegers.
Als u een externe CA gebruikt om uw apparaatcertificaten uit te geven, moet u certificaten controleren, vernieuwen en opnieuw toepassen.
Als u het eerste geheim hebt gemaakt, begrijpt u dat uw gebruikers mogelijk het geheim van hun apparaat willen wijzigen. Mogelijk moet u een interface maken/een tool distribueren om hen in staat te stellen dit te doen.
|
Id van sessietype |
Naam openbare dienst |
|---|---|
|
638 |
E2E-codering + Alleen VoIP |
|
652 |
Alleen pro-end-Encryption_VOIP |
|
660 |
Pro 3 gratis end-to-end Encryption_alleen VoIP E2E-codering + identiteit |
|
672 |
Pro 3 Free50-Alleen end-to-end Encryption_VOIP |
|
673 |
Onderwijsinstructeur E2E Encryption_VOIPonly |
|
676 |
BroadWorks-standaard plus end-to-end-codering |
|
677 |
BroadWorks Premium plus end-to-end-codering |
|
681 |
Schoology Gratis plus end-to-end-codering |
Deze tabellen beschrijven API-opdrachten voor Webex-apparaten die we hebben toegevoegd voor end-to-end gecodeerde vergaderingen en geverifieerde identiteit. Zie Toegang tot de API voor Webex-ruimte- en bureauapparaten en Webex Boards voor meer informatie over het gebruik van de API.
Deze xAPI-opdrachten zijn alleen beschikbaar op apparaten die:
-
Geregistreerd bij Webex
-
Geregistreerd op locatie en gekoppeld aan Webex met Webex Edge voor apparaten
|
API-gesprek |
Beschrijving |
|---|---|
|
|
Deze configuratie wordt gemaakt wanneer de beheerder het voorkeursdomein van het apparaat instelt via Control Hub. Alleen nodig als de organisatie meer dan één domein heeft. Het apparaat gebruikt dit domein wanneer het een certificaat aanvraagt van de Webex CA. Het domein identificeert vervolgens het apparaat. Deze configuratie is niet van toepassing wanneer het apparaat een actief, extern uitgegeven certificaat heeft om zichzelf te identificeren. |
|
|
Geeft aan of het apparaat kan deelnemen aan een end-to-end gecodeerde vergadering. Deze wordt door de cloud-API gebeld zodat een gekoppelde app weet of deze het apparaat kan gebruiken om deel te nemen. |
|
|
Geeft aan of het apparaat |
|
|
De identiteit van het apparaat zoals gelezen uit de algemene naam van het extern uitgegeven certificaat. |
|
|
Leest specifieke informatie van een extern uitgegeven certificaat. In de weergegeven opdracht vervangt u
|
|
|
De status van de externe identiteit van het apparaat (bijv. |
|
|
Geeft aan of het apparaat een geldig certificaat heeft dat is uitgegeven door de Webex CA. |
|
|
De identiteit van het apparaat zoals gelezen uit de algemene naam van het door Webex uitgegeven certificaat. Bevat een domeinnaam als de organisatie een domein heeft. Is leeg als de organisatie geen domein heeft. Als het apparaat zich in een organisatie bevindt met meerdere domeinen, is dit de waarde uit de |
|
|
Leest specifieke informatie van het door Webex uitgegeven certificaat. In de weergegeven opdracht vervangt u
|
|
API-gesprek |
Beschrijving |
|---|---|
| Deze drie gebeurtenissen omvatten nu |
|
API-gesprek |
Beschrijving |
|---|---|
of
| Accepteert een basis64URL-gecodeerde waarde voor platte tekst voor het seeden van het clientgeheim op het apparaat voor de eerste keer. Als u het geheim na die eerste keer wilt bijwerken, moet u een JWE-blob leveren met het nieuwe geheim dat met het oude geheim is gecodeerd. |
| Hiermee wordt een certificaat (met privésleutel) toegevoegd. We hebben deze opdracht uitgebreid om een JWE-blob met de gecodeerde PEM-gegevens te accepteren. |
| Activeert een specifiek certificaat voor WebexIdentity. Voor deze |
| Deactiveert een specifiek certificaat voor WebexIdentity. Voor deze |
