セキュリティと Skype for Business Online
Important
21Vianet が中国で運営する Skype for Business Online は、2023 年 10 月 1 日に廃止されます。 Skype for Business Online ユーザーをまだアップグレードしていない場合は、 自動的にアップグレード支援がスケジュールされます。 組織を自分で Teams にアップグレードする場合は、今すぐアップグレード パスの計画を開始することを強くお勧めします。 アップグレードが成功すると技術的な準備とユーザーの準備が整っていることを忘れないでください。そのため、Teams への旅を進める際には 、アップグレード ガイダンス を活用してください。
Skype for Business Online (中国で 21Vianet が運営するサービスを除く) は、2021 年 7 月 31 日に廃止されました。
Skype for Business Online (SfBO) は、Microsoft 365 および Office 365 サービスの一部として、サービス内の多層防御、顧客制御、セキュリティ強化、運用のベスト プラクティスを通じて、サービス レベルのセキュリティなど、すべてのセキュリティのベスト プラクティスと手順に従います。 詳細については、Microsoft セキュリティ センター (https://microsoft.com/trustcenter) を参照してください。
設計による高い信頼性
Skype for Business Online は、https://www.microsoft.com/sdl/default.aspx に記載されている「Microsoft 信頼できるコンピューティングのセキュリティ開発ライフ サイクル」に準拠して設計、開発されました。 より安全な統合コミュニケーション システムを作成するうえでの最初のステップは、脅威モデルを設計し、各機能を設計時にテストすることでした。 複数のセキュリティ関連強化機能がコーディング過程と実践に組み込まれています。 ビルド時に使われるツールは、製品にコードが最終的にチェックインされる前にバッファ オーバーランなどの潜在的なセキュリティ上の脅威を検出します。 未知のセキュリティ上の脅威に対して設計することは不可能です。 完全なセキュリティを保証できるシステムはありません。 ただし、製品開発では最初から安全な設計原則が採用されているため、Skype for Business Online には、アーキテクチャの基本的な部分として業界標準のセキュリティ テクノロジが組み込まれています。
既定による高い信頼性
Skype for Business Online のネットワーク通信は、既定で暗号化されます。 すべてのサーバーに証明書の使用を要求し、OAUTH、TLS、Secure Real-Time Transport Protocol (SRTP)、その他の業界標準の暗号化手法 (256 ビット Advanced Encryption Standard (AES) 暗号化を含む) を使用することで、すべての Skype for Business Online データがネットワーク上で保護されます。
SfBO の一般的なセキュリティ上の脅威に対する対処方法
このセクションでは、SfBO サービスのセキュリティに対するより一般的な脅威と、Microsoft がそれらの脅威の軽減に用いる方法を明らかにします。
危害を受けたキーによる攻撃
キーとは、機密情報の暗号化、復号化、または検証に使用される秘密のコードまたは数値です。 考慮すべき公開キー基盤 (PKI) には、各証明書の所有者が所持する秘密キーと、通信パートナーによる ID およびセッション キーの交換が成功した後に使用されるセッション キーの 2 つの機密キーがあります。 侵害されたキーによる攻撃は、攻撃者が秘密キーまたはセッション キーを割り出した場合に発生します。 攻撃者がキーの割り出しに成功した場合、攻撃者はそのキーを使用して、データの送信者に関する知識がなくても、暗号化されているデータを解読できます。
Skype for Business Online では、Windows Server オペレーティング システムの PKI 機能を使用して、トランスポート層セキュリティ (TLS) 接続の暗号化に使用されるキー データを保護します。 メディアの暗号化に使用されるキーは、TLS 接続を介して交換されます。
ネットワークのサービス拒否攻撃
サービス拒否攻撃は、有効なユーザーによるネットワークの正常な使用または機能が、攻撃者によって妨害された場合に発生します。 攻撃者は、サービス拒否攻撃を使用して、次のことができます。
- 攻撃対象のネットワークで実行されているアプリケーションまたはサービスに対して無効なデータを送信して、そのようなアプリケーションまたはサービスが正常に機能するのを妨害する。
- 大量のトラフィックを送信してシステムを過負荷状態にして、適正な要求に対するシステムの応答を停止または低速化する。
- 攻撃の証拠を隠蔽する。
- ユーザーがネットワーク リソースにアクセスできないようにする。
このような攻撃を緩和するため、SfBO は Azure DDOS ネットワーク保護を実行し、同じエンドポイント、サブネット、およびフェデレーション エンティティからのクライアント要求を調整します。
盗聴
盗聴は、攻撃者が、ネットワークのデータ パスにアクセスし、トラフィックの監視と読み取りの機能を持っているときに起こる可能性があります。 これは、スニッフィングまたはスヌーピングとも呼ばれます。 トラフィックがプレーン テキストの場合、攻撃者は、ネットワークのパスにアクセスしたときにトラフィックを読み取ることができます。 例としては、データ パス上のルーターを制御することによって実行される攻撃があります。
SfBO では、Microsoft 365 または Office 365 内のサーバー通信とクライアントからサービスへの TLS に相互 TLS (MTLS) を使用するため、特定の会話が攻撃される可能性がある期間内にこの攻撃を実現することは困難になります。 TLS はすべての関係者を認証し、すべてのトラフィックを暗号化します。 これにより、傍受が妨げられますが、暗号化が壊れていない限り、攻撃者はトラフィックを読み取ることはできません。
TURN プロトコルは、リアルタイム メディア通信に使用されます。 TURN プロトコルでは、トラフィックの暗号化は必須ではなく、送信する情報は、メッセージの整合性によって保護されます。 盗聴は可能ですが、送信している情報 (つまり、IP アドレスとポート) は、パケットの送信元アドレスと宛先アドレスを調べることで直接抽出できます。 SfBO サービスは、クリア テキストで送信されない TURN パスワードを含むいくつかの項目から派生したキーを使用して、メッセージのメッセージ整合性を確認することで、データが有効であることを確認します。 メディア トラフィックには SRTP を使用し暗号化されています。
ID のスプーフィング (IP アドレスのスプーフィング)
スプーフィングは、権限をもたない攻撃者がネットワーク、コンピューター、ネットワーク コンポーネントの IP アドレスを特定して使用することで行われます。 攻撃が成功すると、攻撃者は、IP アドレスによって通常どおりに識別されたエンティティのように操作することが可能になります。 Microsoft Lync Server 2010 のコンテキスト内では、管理者が次の両方を実行した場合にのみ、この状況が発生します。
- 伝送制御プロトコル (TCP) のみをサポートする構成済みの接続 (TCP 通信は暗号化されていないため、推奨されません)。
- このような接続の IP アドレスを信頼されたホストとしてマークした。
トランスポート層セキュリティ (TLS) 接続では、TLS がすべての関係者を認証し、すべてのトラフィックを暗号化するため、このような問題は生じません。 TLS を使用すると、特定の接続 (相互 TLS 接続など) で攻撃者が IP アドレス スプーフィングを実行できません。 しかし、攻撃者が SfBO が使用する DNS サーバーのアドレスを偽装する可能性はあります。 ただし、SfBO での認証は証明書を使用して実行されるため、攻撃者は通信の当事者の 1 人を偽装するために必要な有効な証明書を持たないでしょう。
中間者攻撃
中間者攻撃は、攻撃者が 2 人の通信ユーザー間の通信を双方に気づかれることなく攻撃者のコンピュータを介するように再ルーティングすることで行われます。 攻撃者は、目的の受信者に到達する前にトラフィックをモニターし読み取ることができます。 通信の各ユーザーは、意図したユーザーとだけ通信していると考えながら、知らないうちに、攻撃者との間でトラフィックを送信したり、攻撃者からのトラフィックを受信したりします。 これは、攻撃者が Active Directory ドメイン サービスを変更して信頼するサーバーとして攻撃者のサーバーを追加したり、クライアントがサーバーに接続する際に攻撃者経由で接続するようにドメイン名システム (DNS) を変更できる場合に発生します。
中間者攻撃は、TLS を使うセッション開始プロトコル (SIP) を使用してピア間でネゴシエートされた暗号キーを使用する SRTP で暗号化された SfBO Point-To-Point 音声、ビデオ、アプリケーション共有ストリームを除き、2 つのクライアント間のメディア トラフィックでも発生する可能性がありますします。
RTP リプレイ アタック
リプレイ アタックは、二者間の有効なメディア伝送が傍受され、有害な目的のために再伝送されると生じます。 SfBO では、SRTP を使用し、受信側が既に受信した RTP パケットのインデックスを維持し、新しい各パケットをインデックスに既に一覧表示されているものと比較できるようにすることで、再生攻撃から転送を保護するセキュリティで保護されたシグナリング プロトコルを使用します。
SPIM
SPIM とは、一方的に送りつけられる営利目的のインスタント メッセージまたはプレゼンス サブスクリプション要求のことです。 それ自体はネットワークを侵害するものではありませんが、少なくとも迷惑なものであり、リソースの可用性および生産性を低下させ、結果としてネットワークの侵害を招く可能性があります。 SPIM の一例として、ユーザーが要求を送信することで相互に SPIM を送るケースがあります。 ユーザーは相互にブロックしてこれを防ぐことができますが、フェデレーションの場合、調整された SPIM 攻撃が確立されると、パートナーのフェデレーションを無効にしない限り、対処が困難になるおそれがあります。
ウイルスとワーム
ウイルスは、より多くの類似したコード単位数を再現することを目的とするコードの単位数です。 ウイルスは、有効に機能するためにホスト (ファイル、電子メール、プログラムなど) を必要とします。 ウイルスと同様に、ワームは、より似たコードユニットを再現するようにコード化されたコードの単位ですが、ウイルスとは異なり、ホストは必要ありません。 ウイルスとワームは、クライアント間でファイルを転送しているとき、または他のユーザーから URL が送信されたときに主に出現します。 ウイルスがコンピューター上に存在する場合、そのウイルスは、たとえば、無断でユーザー ID を使用してインスタント メッセージを送信する可能性があります。 定期的なウイルス スキャンなどの標準的なクライアント セキュリティのベスト プラクティスは、この問題を軽減します。
個人を特定できる情報
SfBO は、個人にリンクできる可能性のあるパブリック ネットワーク経由で情報を開示する可能性があります。 このような情報は、次の 2 つのカテゴリに分類できます。
- 拡張プレゼンス データ 拡張プレゼンス データは、フェデレーション パートナーへのリンクまたは組織内の連絡先との共有または共有をユーザーが選択できる情報です。 このデータは、パブリック IM ネットワーク上のユーザーと共有されません。 クライアント ポリシーや他のクライアント設定により、システム管理者に何らかのコントロールを与えることができます。 SfBO サービスでは、各ユーザーに拡張プレゼンス プライバシー モードを設定し、ユーザーの連絡先リストにない SfBO ユーザーがユーザーのプレゼンス情報を見ることを防ぐことができます。
- 必須データ 必須データは、サーバーまたはクライアントの適切な操作に必要なデータです。 これは、ルーティング、状態のメンテナンス、シグナリングを目的として、サーバーレベルまたはネットワークレベルで必要な情報です。 次の表に、SfBO が動作するために必要なデータを示します。
表 1 - 拡張プレゼンス データ
| データ | 使用可能な設定 |
|---|---|
| 個人データ | 名前、役職、会社、電子メール アドレス、タイム ゾーン |
| 電話番号 | 勤務先、携帯、自宅 |
| 予定表情報 | 空き時間、出張の通知、ミーティングの詳細 (予定表にアクセスできるユーザーに公開されます) |
| [プレゼンス状態] | 離れて、利用可能、ビジー、応答しない、オフライン |
表 2 - 必須データ
| データ | 使用可能な設定 |
|---|---|
| IP アドレス | コンピューターの実際のアドレスまたは NAT で変換したアドレス |
| SIP URI | david.campbell@contoso.com |
| 名前 | David Campbell (Active Directory Domain Services で定義されている名前) |
SfBO のセキュリティ フレームワーク
このセクションでは、Microsoft SfBO のセキュリティ フレームワークを形成する基本的な要素の概要について説明します。 具体的な要素は次のとおりです。
- Microsoft Entra ID は、ユーザー アカウントに対して信頼できる 1 つのバックエンド リポジトリを提供します。
- 公開キー基盤 (PKI) は、信頼された証明機関 (CA) によって発行された証明書を使用してサーバーを認証し、データの整合性を確保します。
- トランスポート層セキュリティ (TLS)、HTTPS over SSL (HTTPS)、相互 TLS (MTLS) を使用すると、エンドポイント認証と IM の暗号化ができます。 ポイント間の音声、ビデオ、アプリケーション共有のストリームは、セキュア リアルタイム転送プロトコル (SRTP) で暗号化され、整合性がチェックされます。
- ユーザーの認証には、業界標準のプロトコルができる限り使用されます。
このセクションの記事では、これらの基本的な要素のそれぞれが SfBO サービスのセキュリティを強化するためにどのように機能するかについて説明します。
Microsoft Entra ID
Microsoft Entra ID は、Microsoft 365 および Office 365 のディレクトリ サービスとして機能します。 すべてのユーザー ディレクトリ情報とポリシー割り当てが格納されます。
SfBO の公開キー基盤
SfBO サービスは、サーバー認証に証明書に依存し、クライアントとサーバー間、およびさまざまなサーバー ロール間で信頼のチェーンを確立します。 Windows サーバー公開キー基盤 (PKI) は、この一連の信頼チェーンを確立し、検証するための基盤を提供します。 証明書とはデジタル ID です。 証明書は、名前によってサーバーを識別し、そのプロパティを指定します。 証明書の情報が有効であることを確認するには、クライアントまたはサーバーに接続する他のサーバーによって信頼されている証明機関 (CA) によって証明書を発行する必要があります。 サーバーがプライベート ネットワーク上の他のクライアントおよびサーバーとのみ接続する場合は、CA はエンタープライズ CA で問題ありません。 サーバーがプライベート ネットワーク外のエンティティと対話する場合は、パブリック CA が必要な可能性があります。
証明書の情報が有効であっても、証明書を提示しているサーバーが、実際に証明書によって提示されているサーバーであることを確認する手段が必要です。 ここで Windows PKI が役立ちます。 各証明書は、公開キーにリンクされています。 証明書で名前が指定されているサーバーには、そのサーバーのみが知る、対応する秘密キーがあります。 接続しようとしているクライアントまたはサーバーは、公開キーを使用して無作為な情報の断片を暗号化し、それをサーバーに送信します。 サーバーがその情報を解読しプレーンテキストに戻すと、接続しようとしているエンティティは、証明書の秘密キーをサーバーが保持していること、つまり、そのサーバーが証明書で指定されていることを確認できます。
CRL 配布ポイント
SfBO では、すべてのサーバー証明書に 1 つ以上の証明書失効リスト (CRL) 配布ポイントが含まれている必要があります。 CRL 配布ポイント (CDP) とは、証明書の発行後にそれが失効していないこと、および証明書が有効期限内にあることを確認するために、CRL をダウンロードできる場所です。 CRL 配布ポイントは、URL として証明書のプロパティに記述され、セキュア HTTP です。 SfBO サービスは、すべての証明書認証で CRL を確認します。
拡張キーの使用方法
SfBO サービスのすべてのコンポーネントでは、サーバー認証で拡張キー使用法 (EKU) をサポートするために、すべてのサーバー証明書が必要です。 サーバー認証用に EKU フィールドを構成することは、サーバーの認証に対して、その証明書が有効であることを意味します。 この EKU は、MTLS には不可欠です。
SfBO の TLS と MTLS
TLS プロトコルと MTLS プロトコルにより、インターネット上での通信の暗号化とエンドポイント認証機能が提供されます。 SfBO では、これら 2 つのプロトコルを使用して、信頼されたサーバーのネットワークを作成し、そのネットワーク経由のすべての通信が確実に暗号化されるようにします。 サーバー間のすべての SIP 通信は MTLS により行われます。 クライアントからサーバーへの SIP 通信は TLS により行われます。
TLS を使用すると、ユーザーはクライアント ソフトウェアを使用して、接続先の SfBO サーバーを認証できます。 TLS 接続の場合、クライアントはサーバーからの有効な証明書を要求します。 証明書が有効であると見なされるためには、証明書の発行元の CA がクライアントからも信頼されていること、およびサーバーの DNS 名が証明書の DNS 名に一致していることが必要です。 証明書が有効な場合、クライアントは証明書内の公開キーを使用して、通信に使う対称暗号化キーを暗号化し、証明書の最初の所有者だけが、その秘密キーを使用して通信の内容を暗号化することができます。 結果として得られる接続は信頼され、その時点から他の信頼されたサーバーまたはクライアントによってチャレンジされることはありません。 このような意味合いで、Web サービスで使用される SSL (Secure Sockets Layer) は TLS ベースであるということができます。
サーバー間接続は、相互認証のために相互 TLS (MTLS ) を使用します。 MTLS 接続では、サーバーが発信したメッセージをサーバーが受信すると、相互に信頼できる CA からの証明書を交換します。 証明書は、各サーバーの ID を他のサーバーに証明します。 SfBO サービスは、このプロシージャに従っています。
TLS および MTLS は、盗聴と中間者攻撃の両方を防ぐのに役立ちます。 中間者 (man-in-the-middle) 攻撃では、攻撃者は 2 つのネットワーク エンティティ間の通信を、双方に気付かれることなく、攻撃者のコンピューターを経由して再ルーティングします。 TLS と SfBO の信頼されたサーバーの仕様は、2 つのエンドポイント間の公開キー暗号化を使用して調整されたエンドツーエンドの暗号化を使用して、アプリケーション 層の中間者攻撃のリスクを軽減します。攻撃者は、対応する秘密キーを持つ有効で信頼された証明書を持ち、クライアントが通信を解除するために通信しているサービスの名前に発行する必要があります。
SfBO の暗号化
SfBO では、TLS と MTLS を使用してインスタント メッセージを暗号化します。 すべてのサーバー間トラフィックでは、トラフィックが内部ネットワークに限定されているか、内部ネットワークの境界を越えるかに関係なく、MTLS が必要です。
次の表は、SfBO で使用するプロトコルをまとめたものです。
表 3 - トラフィック保護
| トラフィックの種類 | 保護用プロトコル |
|---|---|
| サーバー間 | MTLS |
| クライアントからサーバー | TLS |
| インスタント メッセージングとプレゼンス | TLS (TLS 用に構成されている場合) |
| オーディオとビデオ、メディアのデスクトップ共有 | SRTP |
| デスクトップ共有 (シグナリング) | TLS |
| Web 会議 | TLS |
| 会議コンテンツのダウンロード、アドレス帳のダウンロード、配布グループの拡張 | HTTPS |
メディアの暗号化
メディア トラフィックは、RTP トラフィックに対して機密性、認証、反射攻撃保護を提供する RTP (Real-Time Transport Protocol) のプロファイルである SRTP (Secure RTP) を使用して暗号化されます。 SRTP は、安全な乱数ジェネレータを使用して生成されたセッション キーを使用し、シグナリング TLS チャネルを使用して交換します。 さらに、仲介サーバーと内部ネクスト ホップの間で双方向に流れるメディアも SRTP を使用して暗号化されます。
SfBO は、TURN を使用したメディア リレーへの安全なアクセスのためのユーザ名/パスワードを生成します。 メディア リレーは、TLS で保護された SIP チャネル上でユーザー名/パスワードを交換します。
FIPS
SfBO は、暗号キーの交換に FIPS (Federal Information Processing Standard) に準拠したアルゴリズムを使用します。
ユーザー認証とクライアント認証
信頼されたユーザーとは、資格情報が Microsoft 365 または Office 365 の Microsoft Entra ID によって認証されたユーザーです。
認証では、ユーザーの資格情報が信頼されたサーバーまたはサービスに渡されます。 SfBO では、ユーザーの状態と場所に応じて、次の認証プロトコルが使用されます。
- 先進認証 (MA) は、クライアントとサーバー間の通信用に Microsoft が OAUTH 2.0 を実装したものです。 これにより、証明書ベースの認証、多要素認証、条件付きアクセスなどのセキュリティ機能が有効になります。 MA を使用するには、オンライン テナントとクライアントの両方で MA を有効にする必要があります。 2017 年 5 月以降に作成された SfBO テナントでは、MA は既定値として有効になっています。 これ以前に作成されたテナントの場合は、指示に従って有効にします。 Skype for Business 2015 または 2016 クライアント、Skype for Business on Mac、Lync 2013 クライアント、3PIP IP 電話、iOS、Android のすべてのクライアントは MA に対応しています。
- 組織 ID は、先進認証が有効になっていない (または使用できない) 場合に使用されます。
- ダイジェスト プロトコル: いわゆる匿名ユーザーに対して使用されます。 匿名ユーザーは、Active Directory の資格情報を認識していないが、オンプレミスの会議に招待され、有効な会議キーを持っている外部ユーザーです。 ダイジェスト認証は、他のクライアント操作には使用されません。
SfBO 認証は 以下の 2 つのフェーズで構成されます。
- クライアントとサーバーの間に、セキュリティ アソシエーションが確立されます。
- クライアントとサーバーは、既存のセキュリティ アソシエーションを使用して、送信するメッセージに署名し、受信するメッセージを検証します。 認証がサーバーで有効になっている場合、クライアントからの認証されていないメッセージは受け入れられません。
ユーザーの信用情報は、ユーザー ID 自体ではなく、ユーザーから送信される各メッセージに添付されます。 サーバーは、各メッセージについて、送信元ユーザーの資格情報が有効であるかどうか確認します。 ユーザー資格情報が有効な場合、メッセージは最初のサーバーによって受信されるだけでなく、SfBO 内の他のすべてのサーバーによって解放されません。
フェデレーション パートナーが発行した有効な資格情報を持つユーザーは信頼されますが、これらのユーザーに対しては、内部ユーザーに与えられる権限のうち一部の使用を、必要に応じて制限できます。
メディア認証には、ICE プロトコルおよび TURN プロトコルでも、IETF TURN RFC に記載されているとおり、ダイジェスト認証が使用されます。 詳細については、「 メディア トラバーサル」を参照してください。
クライアント証明書は、ユーザーが SfBO によって認証される別の方法を提供します。 ユーザー名とパスワードを提供する代わりに、ユーザーは証明書と、暗号化認証の解決に必要な証明書に対応する秘密キーを持ちます。
Windows PowerShell と SfBO 管理ツール
SfBO では、IT 管理者は O365 管理ポータルまたはテナント リモート パワーシェル (TRPS) を使用してサービスを管理できます。 テナント管理者は、先進認証を使用して、TRPS を認証します。
インターネット境界で SfBO へのアクセスを設定する
SfBO を適切に機能させるには (ユーザーが会議に参加できるなど)、SfBO クラウド内のサービスへの送信 UDP および TCP トラフィックが許可されるようにインターネット アクセスを構成する必要があります。 詳細については、以下を参照してください。 https://support.office.com/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#bkmk_lyo
UDP 3478 から 3481 と TCP 443
UDP 3478 〜 3481 および TCP 443 ポートは、クライアントが音声ビデオ エッジ サービスのサービスをリクエストするために使用されます。 クライアントは、この 2 つのポートを使用して、接続相手が接続するための UDP ポートと TCP ポートをそれぞれ割り当てます。 A/V Edge サービスにアクセスするには、クライアントが最初に SfBO レジストラーと認証された SIP シグナリング セッションを確立して、A/V Edge サービスの認証資格情報を取得する必要があります。 これらの値は、TLS で保護されたシグナリング チャネルを介して送信され、ディクショナリ攻撃を軽減するためにコンピュータで生成されます。 クライアントは、これらの資格情報を音声ビデオ エッジ サービスのダイジェスト認証に使用してメディア セッションで使用するポートを割り当てることができます。 クライアントから最初の割り当てリクエストが送信され、音声ビデオ エッジ サービスから 401 nonce/ チャレンジ メッセージが返されます。 クライアントは、ユーザー名と nonce のハッシュ メッセージ認証コード (HMAC) ハッシュを含む 2 番目の割り当てリクエストを送信します。
反射攻撃を防止するために、シーケンス番号メカニズムも用意されています。 サーバーは、ユーザー名とパスワードに関する自身の知識に基づき予想される HMAC を計算し、HMAC 値が一致する場合に割り当て手順を実行します。それ以外の場合、パケットは廃棄されます。 これと同じ HMAC メカニズムは、コール セッション内の後続メッセージに対しても適用されます。 ユーザー名 / パスワード値の有効期間は最大 8 時間です。クライアントは、後続のコールで新しいユーザー名 / パスワードを再取得します。
UDP/TCP 50,000～59,999
TCP 50,000 アウトバウンドは、アプリケーションとデスクトップの共有、ファイル転送などに SfBO が使用します。 UDP/TCP 50,000 〜 59,999 のポート範囲は、音声ビデオ エッジ サービスからの NAT/ ファイアウォール トラバーサル サービスを必要とする Microsoft Office Communications Server 2007 のパートナーとのメディア セッションに使用します。 A/V Edge サービスは、これらのポートを使用する唯一のプロセスであるため、ポート範囲のサイズは攻撃の可能性を示していません。 セキュリティ プラクティスとして、不要なネットワーク サービスを実行しないことにより、リスニング ポートの総数を最小限に抑えることを推奨します。 ネットワーク サービスが実行されていない場合、リモートの攻撃者によって悪用される可能性はなくなり、ホスト コンピューターの攻撃の表面が減少します。 ただし、1 つのサービス内でポートの数を減らすと、同じ利点は得られません。 音声ビデオ エッジ サービスソフトウェアでは、10,000 のポートを開けた状態でも 10 のポートより攻撃が多くなることはありませんでした。 この範囲内のポートの割り当てはランダムに行われ、現在割り当てされていないポートはパケットをリッスンしません。
外部ユーザーの音声ビデオ トラフィックのトラバース
外部ユーザーと内部ユーザーがメディアを交換できるようにするには、セッションのセットアップと切断に必要な SIP シグナリングを処理するアクセス エッジ サービスが必要です。 また、音声ビデオ エッジ サービスは、メディア転送用のリレーとして機能する必要があります。 コール シーケンスを次の図に示します。
ユーザーは、SfBO 会議に参加するための招待を含む電子メールを受け取ります。 電子メールには、会議キーと会議通話にリンクする HTTP ベースの URL が含まれます。 特定の会議では、キーと URL の両方が一意のものです。
ユーザーは、メール内の会議 URL をクリックして参加手順を開始します。これにより、ユーザーのコンピューターでクライアント検出プロセスが開始されます。 検出されたクライアントが起動します。 検出されない場合、ユーザーは Web クライアントにリダイレクトされます。
SfBO クライアントは、ユーザーの資格情報を含む SIP INVITE を送信します。 フェデレーション ユーザーまたはリモート ユーザーは、エンタープライズ資格情報を使用して会議に参加します。 フェデレーション ユーザーの場合、SIP INVITE はまずユーザーを認証し、INVITE を SfBO に転送する自身のホーム サーバーに送信されます。 匿名ユーザーは、ダイジェスト認証に通る必要があります。
SfBO はリモート ユーザーまたは匿名ユーザーを認証し、クライアントに通知します。 手順 2で説明したように、会議に参加するフェデレーション ユーザーは所属するエンタープライズにより認証されます。
クライアントは、音声ビデオ会議にユーザーを追加するために INFO リクエストを送信します。
A/V 会議は、他の情報の中から A/V 会議エッジ サービスに提示するトークンを含むユーザーの追加応答を送信します。
[注]上記のすべての SIP トラフィックは、Access Edge サービスを通過しました。
クライアントは音声ビデオ会議サーバーに接続し、そのサーバーはトークンを検証し、別の認証トークンを含むリクエストを内部音声ビデオ会議サーバーにプロキシします。 会議に参加するのが有効なユーザーであることをさらに確実にするために、音声ビデオ会議サーバーは SIP チャネルで最初に発行された承認トークンを検証します。
クライアントと A/V 会議サーバー間で、メディア接続のネゴシエーションを行うと、SRTP でセットアップされます。
ユーザーは、SfBO 会議に参加するための招待を含む電子メールを受け取ります。 電子メールには、会議キーと会議通話にリンクする HTTP ベースの URL が含まれます。 特定の会議では、キーと URL の両方が一意のものです。
SfBO のフェデレーション保護対策
フェデレーションは、組織が IM とプレゼンスを共有するために他の組織と通信する機能を提供します。 SfBO では、フェデレーションは既定で有効です。 ただし、テナント管理者は、Microsoft 365 または Office 365 管理ポータルを使用してこれを制御できます。 続きを見る。
SfBO 会議の脅威に対する取り組み
SfBO は、エンタープライズ ユーザーにリアルタイムな Web 会議の作成と参加の機能を提供します。 エンタープライズ ユーザーは、Microsoft Entra ID、Microsoft 365、または Office 365 アカウントを持たない外部ユーザーを招待して、これらの会議に参加することもできます。 フェデレーション パートナーにより雇用され、安全で認証された ID を持つユーザーは会議に参加することもできます。また、権限を与えた場合はプレゼンターになることもできます。 匿名ユーザーは発表者として会議を作成したり会議に参加したりすることはできませんが、参加後に発表者に昇格させることはできます。
外部ユーザーが SfBO 会議に参加できるようにすることは、この機能の価値は大幅に高めますが、セキュリティ上のリスクも伴います。 このリスクに対処するために、SfBO はさらに以下のセーフガードを提供します。
- 参加者の役割により会議通話のコントロール権限が決定します。
- 参加者の種類別に特定の会議へのアクセスを制限できます。
- どの会議にどの種類の参加者が出席できるかは、定義されている会議の種類によって決まります。
- 会議のスケジュール設定は、Microsoft Entra アカウントと SfBO ライセンスを持つユーザーに制限されます。
- 匿名 (認証されていない) ダイヤルイン会議に参加するユーザーは、いずれかの会議アクセス番号をダイヤルし、電話会議 ID の入力を求められます。 認証されていない匿名ユーザーも名前の記録を求められます。 記録された名前で、会議内の認証されていないユーザーを識別します。 匿名ユーザーは、少なくとも 1 人のリーダーまたは認証済みユーザーが参加するまで会議に参加できません。また、定義済みのロールを割り当てることはできません。
参加者の役割
会議参加者は 3 つのグループに分類され、以下のようにそれぞれに独自の特権と制限があります。
- 開催者 会議を一時的にまたはスケジュールに基づいて作成するユーザー。 開催者は、認証されたエンタープライズ ユーザーである必要があり、会議のすべてのエンド ユーザーの側面を制御できます。
- 発表者 サポートされているメディアを使用して、会議で情報を提示することが承認されているユーザー。 会議の開催者は当然発表者でもあり、発表者となることができる他のユーザーを決定します。 開催者は、会議をスケジュールするとき、または会議中にこの点を決定できます。
- 出席者 会議に出席するように招待されているが、発表者として機能する権限がないユーザー。
発表者は、会議中に参加者を発表者に昇格することもできます。
参加者の種類
会議の参加者は、場所と資格情報によっても分類されます。 これらの両方の特性を使用して、特定の会議にアクセスできるユーザーを指定できます。 ユーザーは、大きく次のカテゴリに分類できます。
-
テナントに属しているユーザー これらのユーザーは、テナントの Microsoft Entra ID に資格情報を持っています。
a. コープネット内 – これらのユーザーは、企業ネットワーク内から参加しています。
b. リモート ユーザー - これらのユーザーは企業ネットワークの外部から参加しています。 自宅や外出先で作業している従業員や、サービス規約に基づいて企業の資格情報を与えられている信頼できる仕入先の従業員などを含めることができます。 リモート ユーザーは、会議を作成して参加し、発表者として機能できます。 -
テナントに属していないユーザー これらのユーザーは、テナントの Microsoft Entra ID に資格情報を持っていません。
a. フェデレーション ユーザー - フェデレーション ユーザーは、フェデレーション パートナーとの有効な資格情報を所有しているため、SfBO によって認証されたものとして扱われます。 フェデレーション ユーザーは会議に参加でき、会議に参加した後に発表者に昇格できますが、フェデレーション対象の企業では会議を作成できません。
b. 匿名ユーザー - 匿名ユーザーには Active Directory ID がなく、テナントとフェデレーションされていません。
顧客データは、多くの会議に外部ユーザーが関与していることを示しています。 また、同じ顧客は、外部ユーザーに会議への参加を許可する前に、そのユーザーの ID に対する不安の排除を求めています。 次のセクションで説明するように、SfBO は会議へのアクセスを明示的に許可されたユーザー タイプに制限し、すべてのユーザー タイプで会議に参加するために適切な資格情報の提示を求めます。
参加者入場許可
SfBO では、匿名ユーザーはロビーと呼ばれる待機エリアに転送されます。 プレゼンターは、このようなユーザーを会議に参加させるか、拒否することができます。 ユーザーがロビーに転送されるとリーダーに通知され、ユーザーはリーダーが会議への参加を受け入れるか拒否するか、接続がタイムアウトするまで待ちます。ロビーにいる間、ユーザーには音楽が聞こえています。
既定の設定では、PSTN からダイヤルインする参加者は直接会議に入りますが、このオプションを変更してダイヤルイン参加者も強制的にロビーに転送することができます。
会議の開催者が、参加者がロビーで待たずに会議に参加できるかどうかをコントロールします。 それぞれの会議は、次のいずれかの方法でアクセスできるように設定できます。
- 会議の開催者である自分のみ 主催者を除くすべてのユーザーは、入所するまでロビーで待機する必要があります。
- 会社から招待したユーザー 招待されていなくても、会社の誰でも会議に直接参加できます。
- 自分の組織のユーザー Microsoft 365 または Office 365 テナントのすべての SfBO ユーザーは、配布リストに含まれていないユーザーでも、ロビーで待機することなく会議に参加できます。 すべての外部ユーザーと匿名ユーザーを含む他のすべてのユーザーは、承認されるまでロビーで待機する必要があります。
- 誰でも 会議へのアクセス権を持つすべてのユーザー (制限はありません) は、会議に直接アクセスします。 開催者のみ (ロック済み) 以外の方法が指定されている場合、会議の開催者はロビーで待機せず電話でダイヤルインするユーザーを指定することもできます。
プレゼンターの指定
会議の開催者は、会議中に参加者が出席できるかどうかをコントロールします。 各ミーティングでは、プレゼンターになれる参加者を次のいずれかに制限することができます。
- 開催者のみ 会議の開催者のみがプレゼンターになれます。
- 会社内の人 すべての内部ユーザーがプレゼンターになれます。
- 会社外の人を含むすべての人 会議に参加するすべての人がプレゼンターになれます (制限はありません)。
- 選択したユーザー 会議の開催者は、発表者の一覧にユーザーを追加することで、表示できるユーザーを指定します。