Zabezpečení nulové důvěry (Zero-Trust Security) od společnosti Webex poskytuje komplexní šifrování a silné ověření identity při naplánovaných a osobních schůzkách v místnosti.
Uživatelé vybírají typ schůzky při naplánovat schůzku. Při vpouštění účastníků z předsálí a také během schůzky může hostitel zobrazit stav ověření identity každého účastníka. K dispozici je také kód schůzky, který je společný pro všechny aktuální účastníky schůzky a pomocí kterého se mohou navzájem ověřit.
Sdílejte následující informace s hostiteli schůzky:
Naplánujte si schůzku služby Webex Meeting s šifrováním end-to-end
Připojte se ke schůzce Webex s koncovým šifrováním
Ověřte totožnost
Šifrování mezi koncovými zařízeními s ověřením identity poskytuje další zabezpečení schůzky s šifrováním mezi koncovými zařízeními.
Když se účastníci nebo zařízení připojí ke sdílené skupině MLS (Zasílání zpráv Layer Security), prezentují své certifikáty ostatním členům skupiny, kteří pak ověřují certifikáty oproti vydávajícím certifikačním autoritám (CA). Potvrzením platnosti certifikátů certifikační autorita ověří totožnost účastníků a schůzka zobrazí účastníky/zařízení jako ověřená.
Uživatelé aplikace Webex se ověřují podle úložiště identit Webex , které jim po úspěšném ověření vydá přístupový token. Pokud uživatelé potřebují certifikát k ověření identity na schůzce s šifrováním mezi koncovými zařízeními, certifikační autorita Webex jim vydá certifikát na základě jejich přístupového tokenu. V současné době neumožňujeme uživatelům Webex Meetings získat certifikát vydaný/externí certifikační autoritou třetí strany.
Zařízení se mohou ověřit pomocí certifikátu vydaného interní certifikační autoritou (Webex) nebo certifikátu vydaného externí certifikační autoritou:
Interní certifikační autorita – služba Webex vydává interní certifikát na základě přístupového tokenu účtu počítače zařízení. Certifikát je podepsán certifikační Webex . Zařízení nemají ID uživatelů stejným způsobem jako uživatelé, takže Webex používá při zápisu identity certifikátu zařízení (Common name (CN)) domény vaší organizace (jednu z)).
Externí certifikační autorita – Požádejte a zakupte certifikáty zařízení přímo od zvoleného vydavatele. Certifikáty je nutné zašifrovat, přímo nahrát a autorizovat pomocí tajemství, které znáte jen vy.
Cisco se na tom neúčastní, což umožňuje zaručit skutečné šifrování mezi koncovými zařízeními a ověřenou identitu a zamezit teoretické možnosti, že by společnost Cisco mohla odposlouchávat vaši schůzku / dešifrovat vaše média.
Interně vydaný certifikát zařízení
Webex vydá certifikát pro zařízení při registraci po spuštění a v případě potřeby jej obnoví. U zařízení certifikát obsahuje ID účtu a doménu.
Pokud vaše organizace nemá doménu, certifikační autorita Webex vydá certifikát bez domény.
Pokud má vaše organizace více domén, můžete použít Control Hub a sdělit Webex , kterou doménu má zařízení použít pro svou identitu. Můžete použít také API xConfiguration Conference EndToEndEncryption Identity PreferredDomain: "example.com"
.
Pokud máte více domén a nenastavili jste pro zařízení preferovanou doménu, Webex vám jednu vybere.
Externě vydaný certifikát zařízení
Správce může pro zařízení zřídit jeho vlastní certifikát, který byl podepsán jedním z veřejných certifikačních úřadů.
Certifikát musí být založen na páru klíčů ECDSA P-256, může však být podepsán klíčem RSA .
Hodnoty v certifikátu jsou na uvážení organizace. V uživatelské rozhraní schůzka Webex se zobrazí běžný název (CN) a alternativní název předmětu (SAN), jak je popsáno v části Úplné šifrování s ověřením identity pro Webex Meetings .
Doporučujeme použít samostatný certifikát pro každé zařízení a jedinečný kód KN pro každé zařízení. Například „zasedací-místnost-1.example.com“ pro organizaci, která vlastní doménu „example.com“.
Za účelem plné ochrany externího certifikátu před neoprávněnou manipulací se používá funkce utajeného klienta, která se používá k šifrování a podepisování různých příkazů x.
Při použití tajného klíče klienta je možné bezpečně spravovat externí certifikát identity Webex prostřednictvím rozhraní xAPI. Tato možnost je momentálně omezena na online zařízení.
Webex v současné době poskytuje příkazy API pro správu těchto událostí.
Zařízení
Následující zařízení řady Webex Room a Webex Desk registrovaná v cloudu se mohou připojit ke schůzkám s koncovým šifrováním:
Webex Board
Webex Desk Pro
Webex Desk
Webex Room Kit
Webex Room Kit Mini
Následující zařízení se nemohou připojit ke schůzkám s šifrováním mezi koncovými zařízeními:
Webex řady C
Webex řady DX
Řada Webex EX
Řada Webex MX
Zařízení protokol SIP třetích stran
Softwaroví klienti
Počínaje verzí 41.6 se může počítačový klient Webex Meetings připojit ke schůzkám s koncovým šifrováním.
Pokud vaše organizace povolí aplikace Webex, aby se připojila ke schůzkám spuštěním počítačové aplikace Schůzky, můžete tuto možnost použít k připojení schůzek s koncovým šifrováním.
Webový klient Webex se nemůže připojit ke schůzkám s koncovým šifrováním.
Softklienti protokol SIP jiných výrobců se nemohou připojit ke schůzkám s koncovým šifrováním.
Identita
Záměrně neposkytujeme možnosti prostředí Control Hub pro správu externě ověřené identity zařízení. Pro skutečné šifrování mezi koncovými zařízeními byste měli znát tajemství a klíče pouze vy a měli byste k nim mít přístup. Pokud jsme představili cloudovou službu pro správu těchto klíčů, existuje možnost, že budou zachyceny.
V současné době vám poskytujeme „recept“, můžete si navrhnout vlastní nástroje na základě standardních průmyslových šifrovacích technik, které vám pomohou s vyžádáním nebo zašifrováním certifikátů identity zařízení a jejich soukromých klíčů. Nechceme mít žádný skutečný ani domnělý přístup k vašim tajemstvím nebo klíčům.
Schůzky
Schůzky s šifrováním mezi koncovými zařízeními aktuálně podporují maximálně 200 účastníků.
Z těchto 200 účastníků se může připojit maximálně 25 externě ověřených zařízení musí být prvními účastníky, kteří se připojí ke schůzce .
Když se ke schůzce připojí větší počet zařízení, naše koncové mediální služby se pokusí překódovat mediální streamy. Pokud nemůžeme dešifrovat, překódovat a znovu zašifrovat médium (protože nemáme a neměli bychom mít šifrovací klíče daných zařízení), překódování se nezdaří.
Chcete-li toto omezení zmírnit, doporučujeme menší schůzky pro zařízení nebo rozložit pozvánky mezi zařízeními a klienty schůzek.
Rozhraní pro správu
Důrazně doporučujeme, abyste ke správě webu schůzky používali Control Hub, protože organizace s Control Hubem mají centralizovanou identitu pro celou organizaci, zatímco ve správa webu je identita řízena jednotlivě.
Uživatelé spravovaní ze správa webu nemohou mít možnost ověřené identity společností Cisco. Těmto uživatelům je vydán anonymní certifikát pro připojení ke schůzce s koncovým šifrováním a mohou být vyloučeni ze schůzek, na kterých chce hostitel zajistit ověření identity.
Související informace
Zabezpečení s nulovou důvěrou pro Webex (technický list zabezpečení): https://www.cisco.com/c/en/us/solutions/collateral/collaboration/white-paper-c11-744553.html
Prezentace Cisco Live 2021 (Je vyžadována registrace Cisco Live): https://www.ciscolive.com/2021/learn/session-catalog.html?tab.digitalbundle=Anytime21&search.sessiontype=BRK&search.learningmap=1614364767910003wzD6#/session/16106298425360015zrh
Šifrování JSON Web Encryption (JWE) (Koncept normy IETF): https://datatracker.ietf.org/doc/html/rfc7516
Dokumentace pro uživatele: https://help.webex.com/5h5d8ab
Webex Meetings 41.7.
Zařízení řady Webex Room a Webex Desk registrovaná v cloudu, spuštěna
10.6.1-RoomOS_August_2021
.Přístup pro správce na místo schůzky v centru Control Hub, aby bylo možné pro uživatele povolit nový typ relace .
Jedna nebo více ověřených domén ve vaší organizaci centra Control Hub (pokud k vydávání certifikátů zařízení pro ověřenou identitu používáte certifikační autoritu Webex ).
Spolupráce Místnosti musí být zapnuté, aby se lidé mohli připojit ze svého videosystému. Další informace naleznete zde Povolte videosystémům připojit se ke schůzkám a událostem na vašem web Webex .
Pokud nepotřebujete externě ověřené identity, můžete tento krok přeskočit.
V zájmu dosažení nejvyšší úrovně zabezpečení a ověření identity by mělo mít každé zařízení jedinečný certifikát vydaný důvěryhodnou veřejnou Certificate Authority (CA).
Chcete-li požádat, zakoupit, přijmout digitální certifikáty a vytvořit přidružené soukromé klíče, musíte jednat s certifikační autoritou. Při žádosti o certifikát použijte tyto parametry:
Certifikát musí být vydán a podepsán dobře známou veřejnou certifikační autoritou.
Jedinečné: Důrazně doporučujeme použít pro každé zařízení jedinečný certifikát. Pokud používáte jeden certifikát pro všechna zařízení, ohrožujete své zabezpečení.
Běžný název (KN) a alternativní názvy předmětů (SAN): Tyto hodnoty nejsou pro Webex důležité, ale mělo by se jednat o hodnoty, které lidé dokážou přečíst a přiřadit si k zařízení. Kód CN se bude ostatním účastníkům schůzky zobrazovat jako primární ověřená identita zařízení, a pokud uživatelé zkontrolují certifikát prostřednictvím uživatelského rozhraní schůzky, uvidí síť SAN/s. Můžete chtít použít názvy jako
name.model@example.com
.Formát souboru: Certifikáty a klíče musí být v
.pem
formátu.Účel: Účel certifikátu musí být Webex Identity.
Generování klíčů: Certifikáty musí být založeny na párech klíčů ECDSA P-256 (algoritmus digitálního podpisu s elipsou křivky využívající křivku P-256).
Tento požadavek se nevztahuje na podpisový klíč. certifikační autorita může k podepsání certifikátu použít klíč RSA .
Pokud nechcete ve svých zařízeních používat externě ověřenou identitu, můžete tento krok přeskočit.
Pokud používáte nová zařízení, zatím je neregistrujte do Webex . Pro jistotu je nyní nepřipojujte k síti.
Pokud máte stávající zařízení, která chcete upgradovat, aby používala externě ověřenou identitu, je nutné obnovit tovární nastavení zařízení.
Chcete-li stávající konfiguraci zachovat, uložte ji.
Naplánujte okno, když zařízení nejsou používána, nebo použijte postupný postup. Informujte uživatele o změnách, které mohou očekávat.
Zajistěte fyzický přístup k zařízením. Pokud musíte přistupovat k zařízením přes síť, mějte na paměti, že tajemství se nahrává v prostém textu a ohrožuje své zabezpečení.
Po dokončení těchto kroků povolte videosystémům připojit se ke schůzkám a událostem na vašem web Webex .
Aby bylo zajištěno, že média vašeho zařízení nebude moci být zašifrována nikým jiným než toto zařízení, je nutné zašifrovat soukromý klíč zařízení. Pro zařízení jsme navrhli rozhraní API, která umožňují správu šifrovaného klíče a certifikátu pomocí šifrování JSON Web Encryption (JWE).
Aby bylo možné zajistit skutečné šifrování mezi koncovými body prostřednictvím našeho cloudu, nemůžeme se do šifrování a nahrávání certifikátu a klíče podílet. Pokud potřebujete tuto úroveň zabezpečení, je nutné:
Vyžádejte si certifikáty.
Vygenerujte páry klíčů certifikátů.
Vytvořte (a chraňte) pro každé zařízení počáteční tajný klíč, který nastaví šifrovací schopnost zařízení.
Vyvíjejte a spravujte svůj vlastní nástroj pro šifrování souborů pomocí standardu JWE.
Níže je vysvětlen proces a (netajné) parametry, které budete potřebovat, a také recept, který je vhodné dodržovat ve vašich vývojových nástrojích. Poskytujeme také některá testovací data a výsledné objekty blob JWE podle očekávání, abychom vám pomohli proces ověřit.
Společnost Cisco je na vyžádání k dispozici o nepodporované implementaci reference pomocí jazyka Python3 a knihovny JWCrypto.
Zřeťte a zašifrujte certifikát a klíč pomocí svého nástroje a počátečního tajného klíče zařízení.
Nahrajte výsledný objekt blob JWE do zařízení.
Nastavte účel šifrovaného certifikátu, který se má použít pro identitu Webex , a aktivujte certifikát.
(doporučuje se) Poskytnout rozhraní (nebo distribuovat) svůj nástroj tak, aby uživatelé zařízení mohli měnit počáteční tajný klíč a chránit před vámi svá média.
Jak využíváme formát JWE
V této části je popsáno, jak očekáváme vytvoření souboru JWE jako vstupu pro zařízení, abyste si mohli sestavit vlastní nástroj k vytváření objektů BLOB z vašich certifikátů a klíčů.
Viz Šifrování JSON Web Encryption (JWE)https://datatracker.ietf.org/doc/html/rfc7516a Web podpis JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.
Používáme Kompaktní serializace dokumentu JSON k vytváření objektů BLOB JWE. Při vytváření objektů BLOB JWE musíte zahrnout tyto parametry:
Záhlaví JOSE (chráněno). Do hlavičky Podepisování a šifrování objektů JSON MUSÍTE zahrnout následující páry klíč–hodnota:
"alg":"dir"
Tento přímý algoritmus je jediný, který podporujeme k šifrování datové části a je nutné použít počáteční tajný klíč klienta zařízení.
"enc":"A128GCM"
nebo"enc":"A256GCM"
Podporujeme tyto dva šifrovací algoritmy.
"cisco-action": "add"
nebo"cisco-action": "populate"
nebo"cisco-action": "activate"
nebo"cisco-action": "deactivate"
Toto je patentovaný klíč, který může nabývat čtyř hodnot. Tento klíč jsme zavedli, abychom cílovému zařízení signalizovali účel šifrovaných dat. Hodnoty jsou pojmenovány podle příkazů xAPI na zařízení, ve kterém používáte zašifrovaná data.
Pojmenovali jsme to
cisco-action
ke zmírnění potenciálních konfliktů s budoucími rozšířeními JWE."cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }
Další proprietární klíč. Zadané hodnoty používáme jako vstupy pro odvození klíče na zařízení. Soubor
version
musí být1
(verze naší funkce pro odvození klíče). Hodnotasalt
musí být posloupnost kódování URL ve formátu Base64 o délce nejméně 4 bajtů, kterou proveďte moštu vybrat náhodně.
Šifrovaný klíč JWE . Toto pole je prázdné. Zařízení jej odvodí z iniciály
ClientSecret
.Inicializační vektor JWE . K dešifrování datové části je nutné zadat inicializační vektor kódování base64url. Událost IV MUSÍTE být náhodná hodnota o délce 12 bajtů (používáme skupinu šifer AES-GCM, která vyžaduje, aby byl kód IV dlouhý 12 bajtů).
JWE AAD (další ověřená data). Toto pole je nutné vynechat, protože není podporováno v kompaktní serializaci.
Šifrovaný text JWE : Toto je zašifrovaná datová část, kterou chcete zachovat v tajnosti.
Užitná zátěž MŮŽE být prázdná. Chcete-li například resetovat tajný klíč klienta, musíte jej přepsat prázdnou hodnotou.
Existují různé typy užitečné zátěže v závislosti na tom, co se na zařízení snažíte dělat. Různé příkazy xAPI očekávají různou datovou zátěž a vy je nutné zadat účel datové zátěže pomocí příkazu
cisco-action
klíče, a to takto:S
"cisco-action":"populate"
šifrovaný text je novýClientSecret
.S „
"cisco-action":"add"
šifrovaný text je objekt blob PEM obsahující certifikát a jeho soukromý klíč (zřetězený).S „
"cisco-action":"activate"
šifrovaný text je otisk (šestnáctkové znázornění sha-1) certifikátu, který aktivujeme pro ověření identity zařízení.S „
"cisco-action":"deactivate"
šifrovaný text je otiskem prstu (šestnáctkové znázornění sha-1) certifikátu, u kterého deaktivujeme použití k ověření identity zařízení.
Ověřovací značka JWE: Toto pole obsahuje ověřovací značku, která slouží k ověření integrity celého kompaktu serializovaného objektu BLOB JWE
Jak odvozujeme šifrovací klíč z ClientSecret
Po prvním naplnění tajného klíče nepřijímáme ani nevydáváme výstup jako prostý text. Toto má zabránit potenciálním slovníkovým útokům ze strany osoby, která by mohla mít přístup k zařízení.
Software zařízení použije tajný klíč klienta jako vstup pro funkci odvození klíče (kdf) a získaný klíč pak použije pro dešifrování/šifrování obsahu v zařízení.
Pro vás to znamená, že váš nástroj k vytváření objektů BLOB JWE musí používat stejný postup k odvození stejného šifrovacího/dešifrovacího klíče z tajného klíče klienta.
Zařízení používají šifrovat pro odvození klíče (vizhttps://en.wikipedia.org/wiki/Scrypt ) s následujícími parametry:
Nákladový faktor (N) je 32768
BlockSizeFactor (r) je 8
ParallelizationFactor (p) je 1
Sůl je náhodná posloupnost o délce nejméně 4 bajtů; totéž musíte zadat
salt
při zadávánícisco-kdf
parametr.Délka klíče je buď 16 bajtů (pokud zvolíte algoritmus AES-GCM 128) nebo 32 bajtů (pokud zvolíte algoritmus AES-GCM 256).
Maximální omezení paměti je 64 MB
Tato sada parametrů je jedinou konfigurací šifrovat která je kompatibilní s funkcí odvozování klíče na zařízeních. Tento kdf na zařízeních se nazývá "version":"1"
, což je jediná verze, kterou v současné době používá portál cisco-kdf
parametr.
Fungující příklad
Zde je příklad, podle kterého si můžete ověřit, že proces šifrování JWE funguje stejně jako proces, který jsme v daných zařízeních vytvořili.
V ukázkovém scénáři je přidání objektu BLOB PEM na zařízení (napodobuje přidání certifikátu s velmi krátkým řetězcem místo úplného cert + klíče). Tajné heslo klienta v příkladu je ossifrage
.
Zvolte šifrovací šifru. Tento příklad používá
A128GCM
(AES se 128bitovými klíči v režimu počitadla Galois). Váš nástroj by se mohl hoditA256GCM
chcete-li.Vyberte sůl (musí se jednat o náhodnou posloupnost nejméně 4 bajtů). V tomto příkladu je použita hodnota ( šestnáctkové bajty )
E5 E6 53 08 03 F8 33 F6
. Base64url zakóduje sekvenci, kterou chcete získat5eZTCAP4M_Y
(odeberte polstrování base64).Zde je ukázka
scrypt
volání vytvoření šifrovací klíč obsahu (cek):cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)
Odvozený klíč by měl mít 16 bajtů (šestnáctkových) a to následujícím způsobem:
95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac
do kterého se kóduje base64urllZ66bdEiAQV4_mqdInj_rA
.Vyberte náhodnou posloupnost 12 bajtů, kterou chcete použít jako inicializační vektor. V tomto příkladu je použita hodnota (šestnáctková)
34 b3 5d dd 5f 53 7b af 2d 92 95 83
do kterého se kóduje base64urlNLNd3V9Te68tkpWD
.Vytvořte hlavičku JOSE s kompaktní serializací (následujte stejné pořadí parametrů, jaké používáme zde) a pak ji zakódujte na base64url:
{"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}
V hlavičce JOSE je kódování base64url
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9
Toto bude první prvek objektu blob JWE.
Druhý prvek objektu blob JWE je prázdný, protože nezadáváme šifrovací klíč JWE.
Třetím prvkem objektu blob JWE je inicializační vektor
NLNd3V9Te68tkpWD
.- K vytvoření zašifrované datové části a značky použijte svůj šifrovací nástroj JWE. V tomto příkladu bude nešifrovanou datovou částí falešný objekt blob PEM
this is a PEM file
Měli byste použít tyto parametry šifrování:
Užitečná zátěž je
this is a PEM file
Šifrování je AES 128 GCM
Záhlaví JOSE s kódováním base64url jako dodatečná ověřená data (AAD)
Base64url zakóduje zašifrovanou datovou část, což by mělo vést k
f5lLVuWNfKfmzYCo1YJfODhQ
Toto je čtvrtý prvek (JWE Šifrovaný text) v objektu BLOB JWE.
Base64url zakóduje značku, kterou jste vytvořili v kroku 8, což by mělo vést k
PE-wDFWGXFFBeo928cfZ1Q
Toto je pátý prvek v objektu blob JWE.
Zřetězením pěti prvků objektu blob JWE s tečkami (JOSEheader..IV.Ciphertext.Tag), získáte:
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Pokud jste odvodili stejné hodnoty v kódování base64url, jaké znázorňujeme zde, za použití vlastních nástrojů, jste připraveni je použít k zabezpečení šifrování E2E a ověřené identity svých zařízení.
Tento příklad nebude ve skutečnosti fungovat, ale v zásadě by bylo vaším dalším krokem použití výše vytvořeného objektu BLOB JWE jako vstupu pro příkaz xcommand na zařízení, které přidává certifikát:
xCommand Security Certificates Add
eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q
Typy relací pro schůzky s nulovou důvěrou jsou k dispozici pro všechny weby schůzek bez dodatečných nákladů. Jeden z těchto typů relací se nazývá Pro-End to End Encryption_VOIPonly
. Toto je název veřejné služby, který můžeme v budoucnu změnit. Aktuální názvy typů relací naleznete v části ID typu relace v Odkaz části tohoto článku.
K získání této funkce pro svůj web nemusíte nic dělat. Musíte uživatelům nový typ relace (nazývaný také Meeting Privilege) udělit. Můžete tak učinit jednotlivě na stránce stránka konfigurace uživatele nebo hromadně pomocí exportu/importu souboru CSV .
1 | Přihlaste se do prostředí Control Hub a přejděte do části . | ||
2 | Klikněte na možnost Weby, vyberte web Webex, pro který chcete změnit nastavení, a poté klikněte na možnost Nastavení. | ||
3 | V části Obecná nastavenívyberte možnost Typy relací. | ||
4 | Měli byste vidět jeden nebo více typů relace se šifrováním koncových bodů. Viz seznam ID typu relace v Odkaz části tohoto článku. Můžete vidět například Pro-End to End Encryption_ Pouze VOIP .
| ||
5 | Pokud nový typ relace ještě nemáte, obraťte se na zástupce služby Webex . |
Co dělat dál
Udělte oprávnění tohoto typ relace / schůzky některým nebo všem uživatelům.
1 | Přihlaste se k Centrum Control Hub a přejděte na . |
2 | Vyberte uživatelský účet , který chcete aktualizovat, a pak vyberte Schůzky . |
3 | V rozevíracím seznamu Nastavení použít vyberte web schůzky, který chcete aktualizovat. |
4 | Zaškrtněte políčko vedle možnosti Pro-End to End Encryption_ Pouze VOIP . |
5 | Zavřete panel konfigurace uživatele . |
6 | V případě potřeby zopakujte pro ostatní uživatele. Chcete-li tuto možnost přiřadit více uživatelům, použijte další možnost, Povolte schůzky E2EE pro více uživatelů . |
1 | Přihlaste se do prostředí Control Hub a přejděte do části . | ||
2 | Klikněte na možnost Weby a vyberte web služby Webex, pro který chcete změnit nastavení. | ||
3 | V Licence a uživatelé části klikněte Spravovat hromadnou . | ||
4 | Klikněte na možnost Generovat zprávu a počkejte, než soubor připravíme. | ||
5 | Až bude soubor připraven, klikněte na tlačítko Exportovat výsledky a pak Stáhnout . (Po kliknutí na toto okno budete muset vyskakovací okno ručně zavřít Stáhnout .) | ||
6 | Otevřete stažený soubor CSV k úpravám. Pro každého uživatele existuje jeden řádek a možnost | ||
7 | Pro každého uživatele, kterému chcete udělit nový typ relace, přidejte Stránka Odkaz na formát souboru CSV Webex obsahuje podrobnosti o účelu a obsahu soubor CSV. | ||
8 | Otevřete panel konfigurace webu schůzky v Control Hubu.
| ||
9 | V Licence a uživatelé části klikněte Spravovat hromadnou . | ||
10 | Klikněte Import a vyberte upravený soubor CSV a klikněte na tlačítko Import . Počkejte, než se soubor nahraje. | ||
11 | Po dokončení importu můžete kliknout na Importovat výsledky a zkontrolovat, zda nedošlo k nějakým chybám. | ||
12 | Přejděte na Uživatelé a otevřete jednoho z uživatelů, abyste ověřili, že mají nový typ relace. |
Do záznamů schůzek můžete přidat vodoznak pomocí Webex Meetings Pro-End to End Encryption_VOIPonly
typ relace, který umožňuje identifikovat zdrojového klienta nebo zařízení neoprávněných záznamů důvěrných schůzek.
Když je tato funkce povolena, zvuk schůzky obsahuje jedinečný identifikátor každého zúčastněného klienta nebo zařízení. Zvukové záznamy můžete nahrát do prostředí Control Hub, které poté záznam analyzuje a vyhledá jedinečné identifikátory. Můžete se podívat na výsledky a zjistit, který zdrojový klient nebo zařízení schůzku zaznamenal.
- Aby bylo možné analyzovat záznam, musí být v souboru AAC, MP3, M4A, WAV, MP4, AVI nebo MOV a nesmí být větší než 500 MB.
- Záznam musí být delší než 100 sekund.
- Můžete analyzovat pouze záznamy pro schůzky hostované lidmi ve vaší organizaci.
- Informace o vodoznaku jsou uchovávány po stejnou dobu jako informace o schůzce organizace.
Přidejte do schůzek E2EE zvukové vodoznaky
- Přihlaste se do prostředí Control Hub a poté pod položkou Správa vyberte možnost Nastavení organizace.
- V Vodoznaky schůzky části, zapněte Přidat zvukový vodoznak .
Po určitou dobu po zapnutí funkce budou uživatelé plánovat schůzky s
Webex Meetings Pro-End to End Encryption_VOIPonly
Typ relace viz možnost Digitální vodoznak v části Zabezpečení.
Nahrajte a analyzujte schůzku s vodoznakem
- V centru Control Hub v části Monitorování a vyberte Odstraňování potíží .
- Klikněte Analýza vodoznaku .
- V seznamu vyhledejte nebo vyberte schůzku a klikněte na tlačítko Analyzovat.
- V Analyzovat zvukový vodoznak okně, zadejte název analýzy.
- (Volitelné) Zadejte poznámku pro analýzu.
- Přetáhněte zvukový soubor, který chcete analyzovat, nebo klikněte na tlačítko Vyberte soubor Chcete-li vyhledat zvukový soubor, přejděte na něj.
- Klikněte na tlačítko Zavřít.
Po dokončení analýzy se zobrazí v seznamu výsledků na webu Analyzovat vodoznak stránku.
- Chcete-li zobrazit výsledky analýzy, vyberte schůzku v seznamu. Klikněteke stažení výsledků.
Funkce a omezení
Faktory podílející se na úspěšném dekódování nahraného vodoznaku zahrnují vzdálenost mezi záznamovým zařízením a reproduktorem, hlasitost tohoto zvuku, hluk ve venkovním prostředí atd. Naše technologie vodoznaku má dodatečnou odolnost vůči vícenásobnému kódování, jak se může stát při sdílení média.
Tato funkce je navržena tak, aby umožnila úspěšné dekódování identifikátoru vodoznaku v širokém, ale rozumném souboru okolností. Naším cílem je, aby záznamové zařízení, jako je mobilní telefon, který leží na stole v blízkosti osobního koncového bodu nebo notebooku, vždy vytvořilo záznam, který vyústí v úspěšnou analýzu. Když je nahrávací zařízení přesunuto od zdroje nebo je zakryto slyšením plného zvukového spektra, šance na úspěšnou analýzu jsou sníženy.
Aby bylo možné úspěšně analyzovat záznam, je nutné přiměřené zachycení zvuku schůzky. Pokud je zvuk schůzky zaznamenán ve stejném počítači, ve kterém je hostování klienta, neměla by platit omezení.
Pokud jsou vaše zařízení již zaregistrována ve vaší organizaci Control Hub a chcete pro automatické generování jejich identifikačních certifikátů použít certifikační autoritu Webex , nemusíte obnovovat tovární nastavení zařízení.
Tento postup vybere doménu, kterou zařízení použije k identifikaci, a je vyžadován pouze v případě, že máte v organizaci centra Control Hub více domén. Pokud máte více než jednu doménu, doporučujeme tento krok provést pro všechna zařízení, která budou mít identitu „ověřeno Cisco“. Pokud Webex neřeknete, která doména zařízení identifikuje, je jedna doména vybrána automaticky a ostatní účastníci schůzky nemusí vypadat špatně.
Než začnete
Pokud vaše zařízení ještě nejsou registrována, postupujte podle pokynů Zaregistrujte zařízení ve Cisco Webex pomocí API nebo místního Web rozhraní nebo Registrace do cloudu pro řady Board, Desk a Room . Měli byste také ověřit domény, které chcete používat k identifikaci zařízení spravovat domény .
1 | Přihlaste se k centru Control Hub a pod Management a vyberte Zařízení . |
2 | Výběrem zařízení otevřete panel konfigurace. |
3 | Vyberte doménu, kterou chcete použít k identifikaci tohoto zařízení. |
4 | Opakujte pro další zařízení. |
Než začnete
Potřebujete:
Chcete-li získat certifikát podepsaný certifikační autoritou a soukromý klíč, in
.pem
formátu pro každé zařízení.Za přečtení tématu Proces externí identity pro zařízení , v Připravte se části tohoto článku.
Připravit šifrovací nástroj JWE s ohledem na uvedené informace.
Nástroj pro generování náhodných sekvencí bajtů daných délek.
Nástroj pro kódování bajtů nebo textu pro base64url.
An
scrypt
provádění.Tajné slovo nebo frázi pro každé zařízení.
1 | Vyplňte položky zařízení Při prvním vyplnění Zařízení má své počáteční tajemství. Nezapomeňte na toto; zařízení nelze obnovit a chcete-li jej znovu spustit, je nutné obnovit tovární nastavení zařízení.
|
2 | Zřetězení certifikátu a soukromého klíče: |
3 | Vytvořte objekt blob JWE, který chcete použít jako vstup pro příkaz přidání certifikátu: |
4 | Otevřete prostředí TShell na zařízení a spusťte příkaz přidat (více linek):
|
5 | Spuštěním ověřte, že byl certifikát přidán Zkopírujte otisk nového certifikátu. |
6 | Aktivujte certifikát pro tento účel Zařízení má šifrovaný aktivní certifikát vydaný certifikační autoritou, který je připraven k použití k identifikaci na schůzkách Webex s šifrováním mezi koncovými zařízeními.
|
7 | Zaregistrujte zařízení do organizace Control Hub. |
1 | Naplánujte schůzku správného typu ( Webex Meetings Pro-End to End Encryption_ Pouze VOIP ). |
2 | Připojte se ke schůzce jako hostitel z klienta Webex Meetings . |
3 | Připojte se ke schůzce ze zařízení, jehož identita byla ověřena certifikační Webex . |
4 | Jako hostitel ověřte, že toto zařízení je zobrazeno v předsálí se správnou ikonou identity. |
5 | Připojte se ke schůzce ze zařízení, jehož identita byla ověřena externí certifikační autoritou. |
6 | Jako hostitel ověřte, že toto zařízení je zobrazeno v předsálí se správnou ikonou identity. Další informace o ikonách identity . |
7 | Připojte se ke schůzce jako neověřený účastník schůzky. |
8 | Jako hostitel ověřte, že je tento účastník zobrazen v předsálí se správnou ikonou identity. |
9 | Jako hostitel přijměte nebo odmítněte osoby / zařízení. |
10 | Pokud je to možné, ověřte identitu účastníka / zařízení kontrolou certifikátů. |
11 | Zkontrolujte, zda všichni účastníci schůzky uvidí stejný bezpečnostní kód schůzky. |
12 | Připojit ke schůzce s novým účastníkem. |
13 | Ověřte, že všichni uvidí stejný nový bezpečnostní kód schůzky. |
Chystáte se nastavit schůzky s koncovým šifrováním jako výchozí možnost schůzky, nebo ji povolíte jen pro některé uživatele, případně povolíte všem hostitelům rozhodnout? Až se rozhodnete, jak budete tuto funkci používat, připravte uživatele, kteří ji budou používat, zejména s ohledem na omezení a to, co lze po schůzce očekávat.
Potřebujete zajistit, aby ani Cisco ani nikdo jiný nemohl dešifrovat váš obsah nebo se vydávat za identitu vašich zařízení? Pokud ano, potřebujete certifikáty od veřejné certifikační autority. Na zabezpečené schůzce můžete mít pouze 25 zařízení. Pokud tuto úroveň zabezpečení potřebujete, neměli byste klientům schůzek povolit připojení.
U uživatelů, kteří se připojují pomocí zabezpečených zařízení, nechte nejprve připojení zařízení a nastavte očekávání uživatelů, že se nemusí připojit, pokud se připojí později.
Pokud máte různé úrovně ověřování identity, nechte uživatele, aby se navzájem ověřili pomocí identity podpořené certifikáty a bezpečnostního kódu schůzky. Přestože za určitých okolností se účastníci mohou jevit jako neověření a účastníci by měli vědět, jak provést kontrolu, neověřené osoby nesmí být podvodníci.
Pokud k vydávání certifikátů zařízení používáte externí certifikační autoritu, je sledování, obnovení a opětovné použití certifikátů na vás.
Pokud jste počáteční tajný kód vytvořili vy, je třeba si uvědomit, že uživatelé mohou chtít toto nastavení změnit. Možná budete muset vytvořit rozhraní/distribuci nástroje, abyste jim to umožnili.
ID typu relace | Název veřejné služby |
---|---|
638 | E2E Encryption+ Pouze VoIP |
652 | Pro-End to End Encryption_ Pouze VOIP |
660 | Pro 3 Free-End to End Encryption_ Pouze VOIP Šifrování E2E + Identita |
672 | Pro 3 Free50-End to End Encryption_ Pouze VOIP |
673 | Instruktor vzdělávání E2E Encryption_ Pouze VOIP |
676 | Broadworks Standard plus šifrování mezi koncovými body |
677 | Broadworks Premium plus šifrování mezi koncovými body |
681 | Schoology Free plus šifrování mezi koncovými body |
V těchto tabulkách jsou popsány příkazy API zařízení Webex , které jsme přidali pro schůzky s koncovým šifrováním a ověřenou identitu. Další informace o používání API naleznete v části Přístup k API pro zařízení Webex Room, Desk a Webex Board .
Tyto příkazy xAPI jsou dostupné pouze na zařízeních, která jsou buď:
Registrováno ve Webex
Registrováno místní a propojeno se službou Webex pomocí Webex Edge pro zařízení
hovor API | Popis |
---|---|
| Tato konfigurace se provádí, když správce nastaví preferovanou doménu zařízení z Control Hubu. Je to nutné pouze v případě, že organizace má více než jednu doménu. Zařízení používá tuto doménu, když žádá o certifikát od certifikační autority Webex . Doména pak identifikuje zařízení. Tuto konfiguraci nelze použít, když má zařízení aktivní externě vydaný certifikát k identifikaci. |
| Udává, zda se zařízení může připojit ke schůzce s šifrováním mezi koncovými zařízeními. Cloudové API jej volá, aby spárovaná aplikace věděla, zda může zařízení použít k připojení. |
| Udává, zda zařízení používá |
| Identita zařízení při načtení z běžně dostupného názvu externě vydaného certifikátu. |
| Načte konkrétní informace z externě vydaného certifikátu. V zobrazeném příkazu nahradit
|
| Stav externí identity zařízení (např |
| Udává, zda má zařízení platný certifikát vydaný certifikační Webex . |
| Identita zařízení při načtení z běžného názvu certifikátu vydaného službou Webex. Obsahuje název domény , pokud má organizace doménu. Je prázdná, pokud organizace nemá doménu. Pokud se zařízení nachází v organizaci, která má více domén, je to hodnota z |
| Načte konkrétní informace z certifikátu vydaného službou Webex. V zobrazeném příkazu nahradit
|
hovor API | Popis |
---|---|
| Tyto tři události nyní zahrnují |
hovor API | Popis |
---|---|
nebo
| Přijme hodnotu prostého textu v kódování base64url pro první osazení tajného klíče klienta na zařízení. Chcete-li aktualizovat tajný klíč po tomto okamžiku, je nutné zadat objekt blob JWE obsahující nový tajný klíč zašifrovaný starým tajným kódem. |
| Přidá certifikát (se soukromým klíčem). Rozšířili jsme tento příkaz, aby přijímal objekt blob JWE obsahující zašifrovaná data PEM. |
| Aktivuje konkrétní certifikát pro WebexIdentity. Za toto |
| Deaktivuje konkrétní certifikát pro WebexIdentity. Za toto |