コメントありがとうございます。

世界中の何百万人ものユーザーが、安全なコラボレーションのためにWebexに依存しています。 企業の役員会議室や政府の立法会議から、機密性の高い医師と患者の相談まで、Webex は重要なコミュニケーションのための信頼できるプラットフォームとして機能します。

リモートワークの需要が高まるにつれ、堅牢で機密性の高いコラボレーションツールの必要性も高まっています。 Webexは他のどのベンダーよりも長くこのニーズに応えてきました。 AIを活用したなりすましや高度なディープフェイク脅威の台頭により、本人確認済みのポリシー主導型のコラボレーションが最も重要です。 お客様にとって、セキュリティは単なる機能ではなく、スケジュール、参加者のID、コンテンツ保護など、会議のライフサイクル全体に統合されたコンポーネントです。

Webexには、強力なエンドツーエンド暗号化（E2EE）をサポートしてきた長い歴史があります。 私たちの Webex ゼロトラストセキュリティモデルは、この伝統を 3 つの主要な柱を通して発展させています。

• 標準ベースで正式に検証された暗号の基盤を確立します
• エンドツーエンドの暗号化を、エンドツーエンドの検証済みIDで強化します
• 現在の Webex デバイスと Webex アプリへのサポートの拡大

このテクニカルペーパーでは、エンドツーエンドのセキュリティの背景を説明し、WebexZero Trust Securityの仕組みの技術的基盤について説明します。 会議セッションの種類、予定された会議とパーソナル会議室のセキュリティの違い、管理者と主催者の制御、会議内容の共有と保持、会議体験におけるより広範なAIとディープフェイクの耐障害性など、会議運営上のセキュリティについては、関連するWSMP Meetings Securityテクニカルペーパーを参照してください。

E2Eセキュリティを提供してきた18年の伝統

Webexは、2008年に会議用のE2E暗号化を開拓しました。 定義上、E2Eセキュリティは、コンテンツが送信された瞬間から受信者に表示されるまで暗号化され、クラウドプロバイダーや第三者がデータにアクセスしたり改ざんしたりするのを防ぎます。

ビデオ会議プロバイダーがE2Eのセキュリティメカニズムにどれだけ投資するかによって、図1に示すように、さまざまなレベルの保護を提供できます。 どのE2Eセキュリティも、転送中と保存時だけ暗号化するよりも優れています。

保護レベル	ネットワーク攻撃者	パッシブ攻撃（盗聴）	アクティブ攻撃（なりすまし）	例
転送中と保存中の暗号化	はい	いいえ	いいえ	E2EE以外のアプリ
E2E暗号化です	はい	はい	いいえ	レガシーE2EEとコンシューマーアプリ
E2E暗号化とE2Eアイデンティティ	はい	はい	はい	Webex ゼロトラストセキュリティ

E2Eセキュリティを提供すると主張するほとんどのアプリケーションは、受動的な攻撃からの保護しか提供しません。 受動的な保護のみの対策は、悪意のある人物が会議の進行中のみを盗聴できるようにするため、依然として価値があります。 しかし、最善のアプローチは、受動的攻撃と能動的攻撃の両方から保護することです。このような攻撃では、会議プロバイダー自体が正当な参加者のふりをして会議に参加する可能性があります。 このためには、E2E暗号化に加えてE2E IDレイヤーが必要です。

ゼロトラストセキュリティにより、Webexは会議をより強力に暗号化し、エンドツーエンドの暗号化をエンドツーエンドの検証済みIDで強化して、あらゆる攻撃から会議を安全に保ちます。

技術的な詳細に入る前に、ユーザーエクスペリエンスを理解しておくと役に立ちます。 E2E暗号化会議を作成するには、主催者はWebexアプリのスケジュール時に適切な会議タイプを選択します（図2）。

参加者が参加すると、会議がE2Eで暗号化されていることを示す「鍵の付いた盾」アイコンが表示されます（図3）。 このアイコンをタップすると、会議の保護に関する詳細が表示されます。

最後に、Webexアプリケーションは、会議の参加者リストで、参加者の身元がE2eセキュアな方法で検証されたかどうか、つまりシスコ以外の誰かが参加者の身元を保証したかどうかを示します（図4）。

また、参加者は全員が同じセキュリティコードを使用していることを確認して、全員が会議について同じ意見を持っていることを確認できます。これにより、なりすまし攻撃から保護されます。 顧客が提供したエンドツーエンドのID証明書を使用する導入では、登録簿に記載されていることで身元保証に関する透明性が高まります。

ゼロトラストセキュリティは業界標準の暗号プロトコルに基づいて構築されており、シスコはGoogle、Cloudflare、Wickr、Wireなど、セキュリティとプライバシーの分野で業界をリードする他のリーダーと協力してこのプロトコルを推進しています。 シスコは、セキュア・リアルタイム・プロトコル（SRTP）、DTLS-SRTP、STIR/SHAKEN、WebRTCなどのテクノロジーで第1世代の安全なボイスオーバーIP（VoIP）をリードしました。シスコはゼロトラストセキュリティでも同じことをしています（図5）。

レイヤー	今日は	ゼロトラストセキュリティ
アイデンティティ	SSO (SAML、オープンID)	X.509証明書です
キー交換	SDES/DTLS	メッセージング層セキュリティ (MLS)
メディア暗号化	SRTP	セキュアフレーム（SFrame）

システムには基本的に3つの層があり、各層で古いホップバイホップ技術を採用し、エンドツーエンドの保護層を追加して強化しています。 3つのレイヤーには以下が含まれます：

• 身元—E2Eのアイデンティティには、クライアントが身元を証明する資格情報を持っている必要があります。 ゼロトラストE2E IDでは、クライアントの資格情報はWebex Independentによって提供されます。Certificate Authority
• 鍵交換-E2E会議に参加するクライアントは、会議プロバイダーがそれらの鍵にアクセスできないように、E2E暗号化用の鍵を設定する必要があります。 メッセージング層セキュリティ（MLS）プロトコルは、オープンソースコミュニティで開発されたテクノロジーに基づいて構築され、それらを厳密で正式に検証された設定に組み込んだRFC 9420の批准規格です。
• コンテンツ保護—最後に、会議の実際のメディアコンテンツにはエンドツーエンドの保護が必要です。 sFrame（「セキュアフレーム」用）はRFC 9605です。 これは、リアルタイムメディアを暗号化するための高速でシンプルな暗号化フレームワークです。これにより、最小限のオーバーヘッドで暗号化レイヤーを追加できます。

これらのテクノロジーを、下から順にもう少し詳しく見ていきましょう。

メディア暗号化スキームは、会議の参加者が共有した鍵を受け取り、それを使用して、音声、ビデオ、画面共有など、会議で共有される実際のコンテンツを保護する方法です。 プロトコルレベルでは、暗号化スキームは暗号化されたデータの各単位に追加情報を送信する必要があります。最も重要なのは、

1. 受信者にパケットの復号化方法を伝えるヘッダー、および
2. 受信者がパケットが改ざんされていないことを確認するために使用する認証タグ。

たとえば、SRTPでは、暗号化の単位はRTPパケットです。SRTPはRTPヘッダーを使用して設定し、パケットの最後に認証タグを追加します。

これらすべての追加情報により、E2E暗号化会議に必要な帯域幅が増えるため、SFrameは必要最小限のフレーミングを提供します。 SFrameヘッダーは、どのキーを使用すべきかを示し、キーのローテーションを可能にし、初期化ベクトルを定義する固有のシーケンス番号を提供します。 この後に、E2Eキーと認証タグで暗号化されたコンテンツが続きます。 その後、SFrameのヘッダー、コンテンツ、タグはSRTPパケットに包まれます。これにより、SRTPはネットワーク攻撃者による検査や改ざんを防ぎ、SFrameは会議プロバイダーのメディア要素から保護します（図6の例を参照）。

このミニマリストなアプローチには他にも利点があります。 SFrameは基盤となるトランスポートから独立しているので、RTP over QUIC、RIPTなどの新しいテクノロジーとの上位互換性があります。 また、暗号化のオーバーヘッドをさらに減らすために、フレーム全体などのマルチパケット単位で動作するようにSFrameを設定することもできます。

グループが信頼できないチャネルにしかアクセスできないときに、グループに秘密鍵を設定するのは魔法のように思えます。 これを行う手法は1980年代に初めて開発され、今日ではWebブラウジングの90％以上がトランスポート層セキュリティ（TLS）を使用してまさにこれを行っています。 メッセージングレイヤーセキュリティ（MLS）はこの機能をグループに拡張しますが、TLSはポイントツーポイントでのみ機能するため、Webexは会議プロバイダーが信頼できない場合でもMLSを使用して会議キーを設定できます。

MLSは3つの重要なセキュリティ機能を提供します。

1. 共有鍵 — この鍵は、認証されたグループメンバーだけが知っています。
2. 一貫性 —すべてのメンバーがグループロスターについて一貫した見方をできるようにします。
3. ローテーション — メンバーが参加または退会したときにキーを自動的に更新します。

最初の機能は、SFrameでメディアを暗号化するために使用するキーを提供します。 2つ目の機能とともに、E2Eアイデンティティの出発点となります。 3つ目の機能では、メディアを復号化できるのは、現在会議に参加している人だけです。参加する前、または退出した（または追い出された）後のメディアを復号化することはできません。

これらすべてを実現するために、会議に参加しているクライアントは、会議の重要なポイントでMLSメッセージを交換して、いつでも会議の参加者全員を含むMLSグループを維持します。 Webexはクライアント間でメッセージをルーティングしますが、MLSはこれらのメッセージを保護して、Webexが安全に処理できるようにします。 図7は、メッセージがどのように流れるかを示しています。

作成：主催者であろうとなかろうと、最初に会議に参加した人が、会議のMLSグループを作成し、MLSの目的の「リーダー」になります。 どの時点でも、会議の1人の参加者がリーダーとして指定されます。 ほとんどの場合、この参加者が会議の主催者になります。 セッションが開始されると、MLSはすべての会議参加者がリーダーとして行動するための暗号情報を持っていることを保証します。Webexは混乱を避けるためにリーダーを1人指定するだけです。

参加：新しい参加者が会議に参加したい場合、公開鍵と認証情報を提供するMLS Key Packageメッセージをリーダーに送って、参加を許可してほしいと頼みます。 リーダーは、会議の他の参加者について参加者に伝えるウェルカムメッセージで応答します。 リーダーはまた、グループに追加メッセージとコミットメッセージをブロードキャストします。 追加メッセージは、すでに会議に参加している人に新しい参加者を知らせるものです。 コミットメッセージは、現在の参加者全員が古いグループキーをハッシュして、現在拡張されているグループの新しいキーを取得します。ウェルカムメッセージは、このキーを参加者に提供します。

退席：誰かが会議を辞めたら、その人をロックアウトするのがリーダーの仕事です。 リーダーは、MLS Remove and Commitメッセージを会議に残っている全員にブロードキャストすることでこれを行います。 削除メッセージは残りの参加者に脱退したことを伝え、コミットは残りの参加者全員に新しい鍵を暗号化しますが、脱退した人には暗号化しません。 残りの参加者は、新しいキーを古いグループキーとハッシュして、残った人が持っていないキーを取得します。 去った参加者がリーダーの場合、Webex は新しいリーダーを任命し、新しいリーダーは古いリーダーを削除します。

キーローテーションでは、会議への参加や削除にさらに数秒かかる場合がありますが、セキュリティが確実に保証されます。会議の参加者リストに誰かが載っていなければ、内容を解読するための鍵を持っていません。

E2E暗号化会議の参加者リストには、各ユーザーの本人確認が表示されます。 顧客発行のID証明書を使用すると、シスコが改ざんできないという意味で、真のE2E検証済みIDが得られます。 このような場合、参加者リストには、参加者が属するドメインが青い文字で表示されます。 たとえば、図8に示す会議では、ケビンはexample.comの確認済みメールアドレスを持っていて、Isabellaはcompany.comの確認済みメールアドレスを持っていることがわかります。

Webexが発行するビデオデバイスIDなどのID証明書はCertificate Authority、より限定的な保護しか提供しません。 Certificate AuthorityWebexを侵害する攻撃者だけがユーザーになりすますことができます。 これは、ID保護がまったくないよりはましですが、そのような会議の参加者は、ゼロトラストのエンドツーエンドID検証済みとして青色でマークされません。 Webex Trust ID 検証を示すグレーのテキストで表示されています。

これらの手続きの裏付けとして、Webexは会議のセキュリティコードも提供しています。 セキュリティコードは、MLSプロセスの出力として計算される、人間が読める短い文字列です。 セキュリティコードは、グループの鍵や参加者から提示された証明書など、会議の暗号状態を要約したものです。 このコードはなりすまし攻撃の検出に使用できます。このような攻撃により、少なくとも1人の参加者が他の参加者とは異なる暗号状態になるためです。 しかし、すべての人が同じコードを持っていることを確認した場合にのみ、なりすましは除外されます。 参加者の一部が同じコードを持っていることを確認した場合、彼らは自分の身元が互いに忠実に伝えられていることを知っていますが、コードを確認しない人はなりすまされた可能性があります。 図9は、会議でのセキュリティコードの表示方法の例を示しています。

このコードは、なりすまし攻撃に対する非常に強力な防御を提供します。 MLSプロトコルの一部なので、しっかりとしたセキュリティ分析が行われています。 セキュリティコードは会議の状態と密接に結びついているため、誰かが会議に参加するたびにセキュリティコードが変更されます。 そのため、会議の参加者は、誰かが参加するたびにセキュリティコードを再確認する必要があります。 誰かが去ってもコードはローテーションされません。去ってもなりすまし者を紹介することはできないからです。

Webex ゼロトラストセキュリティは 2021 年に開始されました。 2026年、ウルトラセキュアWebexミーティングでは、E2Eで暗号化されたWebexミーティングのエンドポイントの追加サポート、ビデオメッシュノード（VMN）によるフル機能のゼロトラストE2EEミーティング、標準会議用のエンドツーエンドの暗号化とID機能が導入されました。

• 標準ベースで正式に検証された暗号
• ゼロトラストE2E暗号化
• ゼロトラスト E2E 認証済み ID
• 販売可能なすべてのWebexデバイスのサポート
• デスクトップ、モバイル、ウェブでの Webex アプリのサポート
• Webex ウェブアプリとウェブ SDK のサポート（27年第1四半期に予定）
• Webex Calling電話のサポート（26年第3四半期に予定）
• ビデオメッシュノードのサポート
• 予定会議や個人会議室でのE2E暗号化のサポート

ゼロトラストにはいくつかの制限があります。 E2E暗号化会議は以下をサポートしていません：

• シスコのクラウドサービスが提供する、プレーンテキストメディアへのアクセスが必要な機能には、次のようなものがあります。
  • Webex クラウドベースのレコーディングとサービス。AI Assistant これらのサービスは、ビデオメッシュノード（VMN）とのハイブリッド導入を使用して提供できます。
  • 会議チャット、ファイル、ホワイトボード、注釈を保存します。
  • PSTNまたはSIPの相互運用性。

今後、Webexは、クラウドに必要最小限の権限を与え、顧客がデータを制御できるようにするという原則に基づいて、E2E暗号化会議をいくつかの側面で改善します。

ユビキタスなE2Eセキュリティ：一部の会議だけでなく、すべてがE2Eセキュリティでなければなりません。 このビジョンを達成するための第一歩は、Web App Webexとクラウド接続されたCisco電話のE2Eセキュリティで達成されました。 最終的には、オープンで標準ベースのE2Eアーキテクチャにより、Webexはセッション開始プロトコル（SIP）インフラストラクチャも導入できるようになるはずです。

このホワイトペーパーで説明されているイノベーションは、常時稼働のE2E暗号化という長期ビジョンへの明確な道筋を示しています。 ユーザーがどこからでも接続でき、顧客が会議に必要な機能に安全にオプトインできるようになれば、すべての機能を有効にした非公式の臨時の会議から、ロックダウンされた高セキュリティ会議まで、すべてのWebex会議でE2E暗号化を使用できます。 E2E暗号化により、会議の内容は許可された参加者のみが利用できるようになり、顧客とユーザーはどの参加者が特定の会議に適しているかを決めることができます。

AI対応のなりすましとディープフェイクレジリエンス

Webexは、ゼロトラストのエンドツーエンド暗号化モデルを補完する階層化されたアプローチを通じて、AI対応のなりすましの脅威に対処します。 このホワイトペーパーでは、顧客が提供する証明書ベースの検証や暗号の完全性チェックなど、エンドツーエンドで検証されたIDの技術的基盤に焦点を当てていますが、Webexは、不正アクセスや有害なやりとりのリスクを軽減するために、会議体験における運用上のセキュリティ管理も提供しています。

会議セッションの種類、スケジュールされた会議とパーソナル会議室のセキュリティの違い、Control Hubのホストと管理者の制御、さらに幅広い会議体験におけるその他のAIとディープフェイクの検出と防止については、付属のWSMP会議のセキュリティ技術文書を参照してください。

Webexは、標準ベースの暗号化と検証済みIDを通じて、安全な会議の未来を定義しています。 オープンエコシステムへの取り組みにより、顧客は会議のシナリオに関係なく、データを完全に管理できます。