Köszönjük visszajelzését.

Világszerte több millió felhasználó támaszkodik a Webex-re a biztonságos együttműködés érdekében. A vállalati tanácstermektől és a kormányzati jogalkotási ülésektől az érzékeny orvos-beteg konzultációkig a Webex megbízható platformként szolgál a kritikus kommunikációhoz.

Ahogy növekszik a távmunka iránti kereslet, növekszik a robusztus, bizalmas együttműködési eszközök iránti igény is. A Webex hosszabb ideig kezelte ezt az igényt, mint bármely más szállító. Az AI-kompatibilis megszemélyesítés és a kifinomult mélyhamis fenyegetések növekedésével a személyazonosság-ellenőrzött, politika-vezérelt együttműködés követelménye kiemelkedő fontosságú. Ügyfeleink számára a biztonság nem csupán funkció, hanem az értekezlet teljes életciklusának integrált összetevője, amely magában foglalja az ütemezést, a résztvevők identitását és a tartalom védelmét.

A Webex régóta támogatja az erős end-to-end titkosítást (E2EE). Webex Zero Trust Security modellünk három fő pilléren keresztül fejleszti ki ezt az örökséget:

• A szabványokon alapuló, hivatalosan ellenőrzött kriptográfia alapjainak létrehozása
• A végpontok közötti titkosítás bővítése végpontig ellenőrzött személyazonossággal
• Támogatás bővítése a jelenlegi Webex eszközökre, valamint a Webex alkalmazásra

Ez a műszaki dokumentum hátteret nyújt a végpontok közötti biztonságról, és bemutatja a WebExZero Trust Security működésének technikai alapjait. Az értekezletek működési biztonságát, például az értekezlettípusokat, az ütemezett találkozók és a személyes tárgyalótermek közötti biztonsági különbségeket, a rendszergazdai és a gazda vezérlését, az értekezlet tartalmának megosztását és megőrzését, valamint a szélesebb körű mesterséges intelligenciát és az értekezletélmény mélyreható rugalmasságát lásd a WSMP Meetings Security kísérő műszaki dokumentumban.

Az E2E biztonság megvalósításának 18 éves öröksége

A Webex úttörő szerepet játszott az E2E titkosítás az értekezletekhez 2008-ban. Az E2E biztonság definíció szerint biztosítja, hogy a tartalom titkosítva legyen a küldés pillanatától egészen addig, amíg a címzett meg nem jeleníti meg, megakadályozva a felhőszolgáltató vagy bármely harmadik fél számára az adatok elérését vagy manipulálását.

Attól függően, hogy egy videokonferencia szolgáltató mennyi befektetést tesz az E2E biztonsági mechanizmusaiba, különböző szintű védelmet nyújthatnak, amint azt az 1. ábra mutatja. Bármely E2E biztonság jobb, mint a titkosítás közlekedés közben és nyugalmi állapotban.

Védelmi szint	Hálózati támadók	Passzív támadások (lehallgatás)	Aktív támadások (megszemélyesítés)	Példák
Titkosítás tranzitban és nyugalmi állapotban	Igen	Nem	Nem	Nem E2EE alkalmazások
E2E titkosítás	Igen	Igen	Nem	Régi E2EE és fogyasztói alkalmazások
E2E titkosítás és E2E identitás	Igen	Igen	Igen	Webex Zero Trust Security

A legtöbb alkalmazás, amely azt állítja, hogy E2E biztonságot nyújt, csak védelmet nyújt a passzív támadások ellen. A csak passzív védelem továbbra is értékes, mert úgy teszi lehetővé, hogy a rossz szereplők csak akkor hallgassanak le egy találkozót, amíg az folyamatban van. A legjobb megközelítés azonban a passzív és az aktív támadások elleni védelem, ahol maga a konferenciaszolgáltató úgy tehet, mintha törvényes résztvevő lenne az értekezletre való belépéshez. Ehhez az E2E titkosítás mellett E2E identitásrétegre van szükség.

A Zero Trust Security segítségével a Webex erősebb kriptográfiát biztosít az értekezletekre, és bővíti a végpontok közötti titkosítást végpontig ellenőrzött személyazonossággal, hogy megvédje az értekezleteket a támadások teljes spektrumától.

Mielőtt belemerülne a technikai részletekbe, hasznos megérteni a felhasználói élményt. E2E titkosított értekezlet létrehozásához a gazda kiválasztja a megfelelő értekezlettípust a Webex App ütemezése során (2. ábra).

Amikor a résztvevők csatlakoznak, egy „pajzs zárral” ikon jelenik meg, amely jelzi, hogy az értekezlet E2E titkosítva van (3. ábra). Az ikonra koppintva az értekezlet védelmének részleteit tartalmazza.

Végül, az értekezlet résztvevői listáján a Webex alkalmazás jelzi, hogy a résztvevő személyazonosságát E2E-biztonságos módon igazolták-e - vagyis a Cisco-n kívül valaki garantálta-e a résztvevő személyazonosságát (4. ábra).

A résztvevők azt is ellenőrizhetik, hogy mindegyikük azonos biztonsági kóddal rendelkezik-e, hogy megerősítse, hogy mindegyikük azonos nézettel rendelkezik az értekezletről, és így biztonságban vannak a megszemélyesítő támadásoktól. Az ügyfél által biztosított végpontok közötti azonosító tanúsítványokat használó telepítéseknél a névjegyzék állapota átláthatóságot biztosít az identitásbiztosítással kapcsolatban.

A Zero Trust Security iparági szabványú kriptográfiai protokollokra épül, amelyeket a Cisco a biztonság és a magánélet más vezetőivel, köztük a Google, a Cloudflare, a Wickr és a Wire mellett vezet. A Cisco vezette a biztonságos Voice over IP (VoIP) első generációját olyan technológiákkal, mint a Secure Real-Time Protocol (SRTP), a DTLS-SRTP, a STIR/SHAKEN és a WebRTC, és a Cisco ugyanezt teszi a Zero Trust Security szolgáltatással (5. ábra).

Réteg	Ma	Zero Trust Security
Személyazonosság	SSO (SAML, OpenID)	X.509 tanúsítvány
Kulcscsere	SDES/DTLS	Üzenetkezelési réteg biztonsága (MLS)
Média titkosítás	SRTP	Biztonságos keretek (SFrame)

Alapvetően három réteg van a rendszernek, és minden rétegnél a régi hop-by-hop technológiát alkalmazzuk, és további védőréteggel erősítjük azt. A három réteg a következőket tartalmazza:

• Identitás — Az E2E identitás megköveteli, hogy az ügyfelek személyazonosságukat igazoló hitelesítő adatokkal rendelkezzenek. A Zero Trust E2E Identity segítségével az ügyfelek hitelesítő adatait egy Webex Independent biztosítja. Certificate Authority
• Kulcscsere — Az E2E értekezleten részt vevő ügyfeleknek be kell állítaniuk az E2E titkosításhoz szükséges kulcsokat anélkül, hogy a konferenciaszolgáltató hozzáférhessen ezekhez a kulcsokhoz. Az Messaging Layer Security (MLS) protokoll egy ratifikált szabvány, az RFC 9420, amely a nyílt forráskódú közösségben kifejlesztett technológiákra épül, és szigorú, formálisan ellenőrzött környezetben helyezi őket.
• Tartalomvédelem — Végül, az értekezlet tényleges médiatartalmának teljes körű védelemre van szüksége. Az SFrame (a „Secure Frames”) az RFC 9605. Ez egy gyors és egyszerű titkosítási keretrendszer a valós idejű adathordozók titkosításához, amely lehetővé teszi egy extra titkosítási réteg hozzáadását minimális költségekkel.

Nézzük meg ezeket a technológiákat egy kicsit részletesebben, alulról felfelé kezdve.

A média titkosítási rendszer az értekezlet résztvevői által megosztott kulcs átvételének módja annak, hogy megvédje az értekezleten megosztott tényleges tartalmat, például a hang-, videót és képernyőmegosztást. Protokoll szinten a titkosítási rendszernek további információkat kell küldenie minden titkosított adategységgel, ami a legfontosabb:

1. Egy fejléc, amely megmondja a vevőnek, hogyan kell visszafejteni a csomagot, és
2. Hitelesítési címke, amelyet a vevő használ annak ellenőrzésére, hogy a csomagot nincs-e módosítva.

Például az SRTP-ben a titkosítás egysége egy RTP csomag; az SRTP az RTP fejlécre támaszkodik a beállításhoz, és hitelesítési címkét csatol a csomag végéhez.

Mivel ez az extra információ növeli az E2E titkosított értekezletekhez szükséges sávszélességet, az SFrame biztosítja a szükséges minimális mennyiségű keretezést. Az SFrame fejléc jelzi, hogy melyik kulcsot kell használni, lehetővé téve a kulcs elforgatását, és egyedi sorozatszámot ad, amely meghatározza az inicializációs vektort. Ezt követi az E2E kulccsal titkosított tartalom és egy hitelesítési címke. Az SFrame fejlécét, tartalmát és címkét ezután egy SRTP-csomagba csomagolják, így az SRTP védelmet nyújt a hálózati támadók általi ellenőrzés vagy módosítás ellen, az SFrame pedig védelmet nyújt a konferenciaszolgáltató médiaelemeivel szemben (lásd a 6. ábrán látható példát).

Ennek a minimalista megközelítésnek más előnyei is vannak. Az sFrame független a mögöttes szállítástól, így továbbkompatibilis a feltörekvő technológiákkal, mint például az RTP over QUIC és a RIPT. Lehetőség van az SFrame konfigurálására is, hogy többcsomagos egységeken, például egész képkockákon működjön, hogy tovább csökkentse a titkosítási költségeket.

Varázslatnak tűnik egy titkos kulcs beállítása egy csoport között, amikor a csoport csak egy megbízhatatlan csatornához fér hozzá. Ennek technikáit először az 1980-as években fejlesztették ki, és manapság a webböngészés több mint 90 százaléka használja a Transport Layer Security (TLS) pontosan erre. Az Messaging Layer Security (MLS) kiterjeszti ezt a funkciót csoportokra is, míg a TLS csak pontról pontra működik, így a Webex az MLS-sel is beállíthatja a konferenciakulcsokat, ha a konferenciaszolgáltató nem megbízható.

Az MLS három kritikus biztonsági funkciót kínál:

1. Megosztott kul cs — A kulcs csak hitelesített csoporttagok számára ismert.
2. Következ etesség — Biztosítja, hogy minden tag következetes képet kapjon a csoport listájáról.
3. Elforgat ás — Automatikusan frissíti a kulcsokat, amikor egy tag csatlakozik vagy távozik.

Az első funkció biztosítja számunkra azokat a kulcsokat, amelyeket a média titkosításához használunk az SFrame segítségével. A második funkcióval együtt ez adja az E2E identitás kiindulópontját. A harmadik funkció biztosítja, hogy csak azok tudják visszafejteni a médiát, akik jelenleg részt vesznek az értekezleten — nem tudja visszafejteni a médiát a csatlakozás előtt vagy azután, hogy távozott (vagy kirúgták).

Mindezek elérése érdekében az értekezleten részt vevő ügyfelek MLS-üzeneteket cserélnek az értekezlet kritikus pontjain, hogy fenntartsák egy olyan MLS-csoportot, amely pontosan tartalmazza az értekezlet résztvevőit bármikor. A Webex továbbítja az üzeneteket az ügyfelek között, de az MLS védi ezeket az üzeneteket, hogy a Webex biztonságosan kezelje őket. A 7. ábra az üzenetek áramlását mutatja be.

Létre hozás: Az első személy, aki csatlakozik az értekezlethez, akár házigazda, akár nem, létrehozza az MLS-csoportot az értekezlethez, és az MLS céljaira „vezetővé” válik. Bármely időpontban az ülés egyetlen résztvevőjét jelölnek ki vezetőnek. A legtöbb esetben ez a résztvevő lesz a találkozó házigazdája. A munkamenet megkezdése után az MLS biztosítja, hogy minden értekezlet résztvevője rendelkezik a vezetőként való működéshez szükséges kriptográfiai információkkal; a Webex egyszerűen egy vezetőt jelöl ki a zavar elkerülése érdekében.

Csat@@ lakoz ás: Amikor egy új résztvevő csatlakozni akar az értekezlethez, akkor az MLS-kulcscsomag üzenetet küld a vezetőnek, amely megadja a nyilvános kulcsot és a hitelesítési információkat. A vezető üdvözlő üzenettel válaszol, amely elmondja az asztalosnak a találkozó többi résztvevőjéről. A vezető egy Hozzáadás üzenetet és egy Közzételi üzenetet is közvetít a csoportnak. A Hozzáadás üzenet bejelenti az új csatlakozót azoknak, akik már részt vesznek az értekezleten. Az Elkötelezés üzenet arra készteti, hogy az összes jelenlegi résztvevő kigyorsítja a régi csoportkulcsot, hogy új kulcsot kapjon a most kibővített csoport számára; az üdvözlő üzenet ezt a kulcsot adja az összekötő számára.

Távozás: Amikor valaki elhagy ja az értekezletet, a vezető feladata, hogy bezárja őket. A vezető ezt úgy teszi meg, hogy az MLS eltávolítása és elküldése üzeneteit közvetíti az értekezleten maradó mindenkinek. Az Eltávolítás üzenet tájékoztatja a többi résztvevőt, akik távoztak, a Commit pedig új kulcsot titkosít az összes fennmaradó résztvevőnek, de nem a távozó személynek. A fennmaradó résztvevők az új kulcsot a régi csoportkulccsal megkapják, hogy olyan kulcsot kapjanak, amellyel a távozó személy nem rendelkezik. Ha a távozó résztvevő a vezető, a Webex új vezetőt nevez ki, az új vezető pedig eltávolítja a régi vezetőt.

A kulcsok elforgatása azt jelentheti, hogy néhány másodpercet vesz igénybe az értekezletbe való csatlakozás vagy valaki eltávolítása, de egyértelmű biztonságot nyújt: ha valaki nem jelenik meg az értekezlet résztvevői listáján, akkor nincsenek a tartalom visszafejtéséhez szükséges kulcsok.

Az E2E titkosított értekezlet résztvevői listája az egyes felhasználók személyazonosságának ellenőrzését mutatja. Az ügyfél által kiállított személyazonosító tanúsítványok használata valódi E2E hitelesített személyazonosságot biztosít abban az értelemben, hogy a Cisco nem tudja megváltoztatni azt. Ezekben az esetekben a résztvevők listája kék szövegben mutatja be azt a tartományt, amelyhez a résztvevő tartozik. Például a 8. ábrán látható értekezleten láthatja, hogy Kevinnek van egy ellenőrzött e-mail címe az example.com webhelyről, Isabella-nak pedig hitelesített e-mail címe van a company.com webhelyről.

A Webex által kiadott személyazonossági tanúsítványokCertificate Authority, mint például a videóeszköz azonosítása, korlátozottabb védelmet nyújtanak. Csak az a támadó, aki veszélyezteti a Webex-et, képes megszemélyes Certificate Authority íteni felhasználót. Annak ellenére, hogy ez jobb, mint egyáltalán nincs személyazonosság-védelem, az értekezlet ilyen résztvevőit nem kék színnel jelölik, mivel a Zero Trust végponttól végpontig ellenőrzött személyazonosság. Szürke szöveggel jelennek meg, amelyek jelzik a Webex megbízhatósági személyazonosságának ellenőrzését.

Ezeknek az eljárásoknak a háttérképeként, a Webex biztonsági kódot is biztosít az értekezlethez. A biztonsági kód egy rövid, ember által olvasható karakterlánc, amelyet az MLS-folyamat kimeneteként számolnak ki. A biztonsági kód összefoglalja az értekezlet kriptográfiai állapotát, beleértve a csoport kulcsait és a résztvevők által bemutatott tanúsítványokat. Ez a kód felhasználható egy megszemélyesítési támadás észlelésére, mivel egy ilyen támadás azt eredményezné, hogy legalább egy résztvevő más kriptográfiai állapotban legyen, mint mindenki más. De csak akkor zárja ki a megszemélyesítést, ha mindenki ellenőrzi, hogy ugyanaz a kódja van. Ha a résztvevők egy részhalmaza ellenőrzi, hogy ugyanazzal a kóddal rendelkezik-e, tudják, hogy személyazonosságukat hűségesen ábrázolják egymás előtt, de valakit, aki nem erősíti meg kódját, megszemélyesíthették volna. A 9. ábra egy példát mutat arra, hogy a biztonsági kód hogyan jelenik meg egy értekezleten.

Ez a kód nagyon erős védelmet nyújt a megszemélyesített támadások ellen. Ez az MLS protokoll része, ezért robusztus biztonsági elemzéssel rendelkezett. Mivel szorosan kötődik az értekezlet állapotához, a biztonsági kód minden alkalommal megváltozik, amikor valaki csatlakozik az értekezlethez. Ennek eredményeként, az értekezlet résztvevőinek minden alkalommal újra ellenőrizniük kell biztonsági kódjukat, amikor valaki csatlakozik. A kód nem forog el, amikor valaki távozik, mert a távozás nem vezethet be megszemélyesítőt.

A Webex Zero Trust Security 2021-ben indult. 2026-ban az Ultra Secure Webex értekezletek további végpontok támogatását vezették be az E2E titkosított Webex értekezletekben, teljes körű Zero Trust E2EE találkozókat a Video Mesh Node (VMN) segítségével, valamint végpontok közötti titkosítási és azonosítási képességeket szabványos értekezletekhez:

• Szabványokon alapuló, hivatalosan ellenőrzött kriptográfia
• Zero Trust E2E titkosítás
• Zero Trust E2E ellenőrzött személyazonosság
• Támogatás az összes eladó Webex eszközhöz
• A Webex alkalmazás támogatása asztali, mobilon és weben
• A Webex Web alkalmazás és a Web SDK támogatása (tervezett Q1CY27)
• Támogatás Webex Calling telefonokhoz (a Q3CY26-ra tervezve)
• A Video Mesh Node támogatása
• Az E2E titkosítás támogatása ütemezett találkozókban és személyes tárgyalótermekben

A Zero Trust bizonyos korlátozásokkal rendelkezik. Az E2E titkosított értekezletek nem támogatják:

• A Cisco felhőszolgáltatásai által biztosított funkciók, amelyek hozzáférést igényelnek az egyszerű szöveges médiához, többek között:
  • Webex felhőalapú felvétel és szolgáltatások. AI Assistant Ezek a szolgáltatások hibrid telepítésekkel nyújthatók a Video Mesh Node (VMN) segítségével.
  • Értekezletcsevegés, fájlok, táblák és megjegyzések mentése.
  • PSTN vagy SIP interoperabilitás.

A továbbiakban a Webex néhány dimenzióban fejleszti majd az E2E titkosított értekezleteit, azon elvek alapján, hogy a felhőnek a szükséges legkevesebb kiváltságot biztosítsák, és az ügyfeleknek biztosítsák adataik feletti ellenőrzést.

Mindenütt jelen lévő E2E biztonság: Mindennek E2E biztonságosnak kell lennie, nem csak a kiválasztott értekezleteket. Ennek az elképzelésnek az első lépése a Webex Web App és a felhőalapú Cisco telefonok E2E biztonságával érhető el. Végül a nyílt, szabványokon alapuló E2E architektúrának lehetővé kell tennie a Webex számára, hogy bevezesse a Session Initiation Protocol (SIP) infrastruktúrát is.

Az ebben a cikkben tárgyalt újítások egyértelmű utat mutatnak a mindig működő E2E titkosítás hosszú távú jövőképéhez. Miután a felhasználók bárhonnan csatlakozhatnak, és az ügyfelek biztonságosan bekapcsolhatják az értekezleten kívánt funkciókat, az E2E titkosítás minden Webex-értekezleten használható — az informális ad hoc találkozóktól kezdve az összes funkció bekapcsolt funkciójáig egészen a lezárt, nagy biztonságú értekezletekig. Az E2E titkosítás mindig biztosítja, hogy az értekezlet tartalma csak az engedélyezett résztvevők számára érhető el, és az ügyfelek és a felhasználók döntik el, hogy melyik résztvevőcsoport megfelelő egy adott értekezletre.

AI-kompatibilis megszemélyesítés és mélyhamis rugalmasság

A Webex az AI-kompatibilis megszemélyesítési fenyegetésekkel foglalkozik egy réteges megközelítéssel, amely kiegészíti a Zero Trust végpontok közötti titkosítási modellt. Míg ez a cikk a végpontig ellenőrzött identitás technikai alapjaira összpontosít, beleértve az ügyfél által biztosított tanúsítványalapú ellenőrzést és a kriptográfiai integritási ellenőrzéseket, a Webex operatív biztonsági ellenőrzéseket is biztosít az értekezlet során, hogy csökkentse az illetéktelen hozzáférés és a káros interakciók kockázatát.

Az értekezlettípusokat, az ütemezett értekezletek és a személyes tárgyalótermek biztonságbeli különbségeit, a Vezérlőközpontban található gazda- és rendszergazdai vezérléseket, valamint a szélesebb körű értekezletélményben további mesterséges intelligencia és mélyhamis észlelést és megelőzést lásd a WSMP Meetings Security kísérő műszaki dokumentumban.

A Webex szabványokon alapuló kriptográfia és ellenőrzött identitás révén határozza meg a biztonságos találkozók jövőjét. A nyitott ökoszisztéma iránti elkötelezettség biztosítja, hogy az ügyfelek abszolút ellenőrzést tartsanak adataik felett, függetlenül az értekezlet forgatókönyvétől