Zoom Node導入時の考慮事項

さまざまな導入例がZoom NodeおよびZoom Nodeサービスモジュールをどのようにサポートするかについて詳しく学びます

このセクションには、Zoom Node が Zoom Meetings Hybrid や Zoom Phone Local Survivability（ZPLS）などのさまざまなサービスモジュールをどのようにサポートできるかについて、いくつかの例が含まれています。専用のIPアドレスを使用した一般的な導入は、次の図のコレクションのようになります。

Zoom Node に導入されるすべてのサービスには、一意のIPアドレスが必要です。Node に管理用の特定のアドレスと、Node 上に導入される各サービス（最大4つ）用のアドレスが1つずつ割り当てられている場合、Zoom Node には最大5つのIPアドレスが割り当てられます。単一のサービス（ZPLS など）を実行する Zoom Node は、Node とサービスが同じIPアドレスを共有するように割り当てられている場合、単一のIPアドレスで導入できます。

以下に、いくつかの導入オプションを示します。さまざまな導入オプションにおける IP の数と証明書（CN/SAN）に注意してください。

オプション 1: 専用 IP とホスト名で導入された Zoom Meetings Hybrid

上の画像は、導入するための IP と証明書 の構成要件を要約しています Zoom Meetings Hybrid オンプレミスまたはハイブリッド クラウド 環境で。

以下の表は、Node の例を詳細に示しており、そのアクティブなプロキシおよび MMR サービスモジュールが含まれています。

コンポーネント	ホスト名	TLS 証明書ロール	機能
Node OS	node1.customer.com	共通名（CN）	コア オーケストレーション
Zoom コネクタ Proxy	zcp1.customer.com	サブジェクト代替名（SAN）	シグナリングとセッション制御
メディアモジュールルーター 1	mmr1.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理
メディアモジュールルーター 2	mmr2.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理
メディアモジュールルーター 3	mmr3.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理

各モジュールに専用の静的IPアドレスを割り当てる必要があります。必要なIPアドレスの合計: 5

上の画像は、導入に必要な最小構成を概説しています Zoom Phone Local Survivability (ZPLS)。ZPLS は、Zoom Node VM 上でサバイバビリティ ロジックをローカルに実行することにより、インターネットまたはクラウド の障害が発生した場合でも継続的な電話サービスの可用性を実現します。

次のホスト名を DNS に設定し、TLS 証明書 に含める必要があります。

• node1.customer.com

• zplsl.customer.com

ホスト名の機能マッピング

コンポーネント	ホスト名	TLS 証明書ロール	機能
Node OS	node1.customer.com	共通名（CN）	コア オーケストレーション
ZPLS モジュール	zplsl.customer.com	サブジェクト代替名	Zoom Phone Local Survivability ロジック

TLS 証明書 の構成

フィールド	値
共通名（CN）	node1.customer.com
サブジェクト代替名	zplsl.customer.com

証明書 は、上記の CN と SAN の両方を含むように生成または調達する必要があります（公開または非公開 CA）。これにより、安全なモジュール間通信のための適切な TLS 検証が可能になります。

IPアドレスの要件

指標	値 / 説明
必要なIPアドレスの合計	5（一般的な割り当て）
ZPLS コンテキストで使用	2 つの IP（Node OS 用に 1 つ、ZPLS モジュール用に 1 つ）

一般的な導入には 5 つの IP が必要ですが、 アクティブに使用される IPアドレス は 2 つのみです ZPLS 導入では: モジュールごとに 1 つで、次の上で実行されます 専用のNode VM.

ZPLS は、Node VM ごとに 1 つのモジュールのみを許可します。同じ VM 上で ZPLS を他の Zoom モジュールと共存させることはできません。

これらの図はどのように比較されますか？ 1 枚目の画像は、Zoom Meetings ハイブリッド導入の例を示しています。2 枚目の画像は、Zoom Phone ローカル サバイバビリティ導入の例を示しています。

必要に応じて、最初の IP/ホスト名を OS と最初のモジュール間で共有して、必要な IPアドレス、ホスト名、および Subject Alternative Names (SANs) の数を削減できます。

オプション 2: 共有 IP と共有ホスト名を使用して導入された Zoom Meetings ハイブリッド

この構成は、オプション 1 の Zoom Meetings ハイブリッド図に見られる Node 構造を繰り返します。ただし、この導入では、 Node OS は IPアドレスを最初に導入されたモジュールと共有します （通常は Zoom コネクタ Proxy、ZCP です）。これにより、TLS と機能要件を維持しながら、IP の使用量を削減できます。

次のホスト名を DNS に設定し、TLS 証明書 に含める必要があります。

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

ホスト名の機能マッピング

コンポーネント	ホスト名	TLS 証明書ロール	機能
ZCP (Zoom コネクタ Proxy)	zcp1.customer.com	共通名（CN）	シグナリングとセッション制御
メディアモジュールルーター 1	mmr1.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理
メディアモジュールルーター 2	mmr2.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理
メディアモジュールルーター 3	mmr3.customer.com	サブジェクト代替名（SAN）	メディア ルーティング と処理

TLS 証明書 の構成

フィールド	値
共通名（CN）	zcp1.customer.com
サブジェクト代替名	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

証明書には、Zoom Node とインストールされた Zoom モジュール間の安全な TLS 通信をサポートするために、すべての SANs を含める必要があります。

IPアドレスの要件

指標	値 / 説明
必要なIPアドレスの合計	4
IP共有戦略	Node OS は最初のモジュール（ZCP）と IP を共有します
個別の IP が必要な対象	ZCP/MMR1、MMR2、MMR3

IPアドレスが 共有されている場合 Node OS と最初に展開されたモジュール（ZCP）の間で、 4 つの IPアドレス のみが必要です。この設計は、展開標準に準拠しながら IP の使用を最適化します。

上の画像は、最小構成の ZPLS 展開を示しており、 Node OS は、インストールされた ZPLS モジュールと IPアドレスを共有します。これは 唯一のシナリオです Zoom Node フレームワークにおいて、 単一ホストTLS証明書 が有効となるのは。

次のホスト名を DNS に設定し、TLS証明書に含める必要があります:

• zplsl.customer.com

ホスト名の機能マッピング

コンポーネント	ホスト名	TLS 証明書ロール	機能
ZPLS モジュール	zplsl.customer.com	共通名（CN）	Zoom Phone Local Survivability ロジック

TLS 証明書 の構成

フィールド	値
共通名（CN）	zcp1.customer.com
SANs	（不要）

この構成では、OS と ZPLS モジュールの両方が同じホスト名と IPアドレスを共有するため、単一ホスト証明書で十分です。

IPアドレスの要件

指標	値 / 説明
必要なIPアドレスの合計	1
IP共有戦略	Node OS と ZPLS は 1 つの IPアドレス を共有します
デプロイ制約	Node VM ごとに許可されるモジュールは 1 つだけです（ZPLS のみ）

Zoom Node アーキテクチャでサポートされる唯一のシナリオは ZPLS で、以下の条件を満たします:

• 単一ホスト証明書（CN のみ）は許容されます

• OS モジュール間の IPアドレス 共有のため、デプロイに必要なのは 1 つの IPアドレス のみです

• 同じ VM 上への追加モジュールの同居はサポートされていません

どの証明書管理方法がデプロイに最適かを判断してください

Zoom Node にデプロイされる各 Service Module には、Zoom Node の証明書信頼リストにある公開で信頼された証明書発行機関（CA）によって署名された有効な証明書が必要です。これには、よく知られた公開認証局が含まれます。

Zoom Node は 2 つの証明書管理方法を提供します:

• Auto PKI: この革新的なソリューションは、公開で信頼された証明書認証局（CA）を使用して、安全な証明書の登録と更新を自動化します。Zoom は、登録と更新に関連する費用を負担します。

• 独自証明書の持ち込み（BYOC）: このオプションでは、主要な公開信頼 CA のいずれかによって署名された独自の証明書を提供します。証明書の登録と更新はお客様が行います。お客様提供の証明書を使用する場合、Zoom Node では最大 5 つのホスト名/SAN を使用できる可能性があるため、追加の考慮事項が適用されます。詳細は以下で説明します。

Auto PKI による証明書の自動管理

Zoom Auto PKI は、Zoom Node プラットフォームおよびその上に展開されたすべてのモジュールに対して、有効で公開で信頼された CA の証明書を自動的にインストールします。証明書の更新も自動的に処理されます。これにより、すべてのサービスと Zoom Node 自体の証明書管理が簡素化されます。

Auto PKI の証明書登録と更新を理解する

次のシナリオは、証明書の登録と更新の仕組みを理解するのに役立ちます。

たとえば、管理者が新しい Node インスタンスを展開したとします。各インスタンスには有効な x509 証明書が必要です。 証明書の秘密鍵は、このインスタンスから決して出てはなりません.

Auto PKIプロセスは以下の手順を実行します。

1. テンプレートの取得：Zoomクラウド内のAuto PKIサービスから、複数のCAプロバイダー向けのオプションを含む、サポートされているすべての構成テンプレートを取得します。

2. IPアドレスの収集：Node上で実行されているサービスで使用されるすべてのIPアドレスを収集し、Zoomクラウド内のAuto PKIサービスに送信します。

3. DNS名のプロビジョニング：Auto PKIクラウドサービスは、次の形式のDNS名セットを返します <instance_識別子>.<customer_識別子>.zoomonprem.com。これらのドメインはA/AAAAレコードで構成されます。

4. 予約済みDNS名リクエスト：次の形式の予約済みDNS名を要求します rsvd-<randomized_string>.<customer_識別子>.zoomonprem.com.

5. 証明書リクエストの生成：3番目の手順のDNS名をSANフィールドに、4番目の手順の予約名をCommon Name（CN）フィールドに使用して、x509証明書リクエストを生成します。

6. 証明書の発行：証明書署名要求（CSR）をZoomクラウド内のAuto PKIサービスに送信します。次にこのサービスはCAベンダーと連携して証明書を発行し、そこには前の手順のSANリストとCNフィールドが含まれます。

7. ローカルストレージ：最後の手順で新たに発行されたx509証明書と、それに対応する秘密鍵（前に生成済み）をローカルストレージに書き込み、Nodeインスタンス上で実行されるサービスで利用可能にします。

Auto PKIは、有効期限を自動的に監視して新しい証明書を要求することで、Zoom Node上の証明書管理を簡素化し、手動更新の必要をなくします。

Bring Your Own Certificates（BYOC）

ローカルWebインターフェースを使用して、独自の有効な公開署名済み証明書をZoom Nodeにインストールできます。これは初回インストール時にも、後からでも実行できます。このプロセスは、Webベースのアプリケーションに証明書をインストールすることに慣れている方には馴染みのあるものです。

独自の証明書を使用することを選択した場合、その証明書は複数のホスト名と通信するサーバー上に配置されることを忘れないでください。したがって、選択する証明書タイプは、複数のホスト名（証明書CN）から発生するトラフィックの暗号化をサポートしている必要があります。Nodeおよびデプロイされたすべてのサービスで使用されるすべてのホスト名は、Zoomのクラウドサービスから公開的に名前解決可能でなければなりません。

Zoomは2種類の証明書を推奨しています。

• ワイルドカード証明書

• マルチSAN証明書 （マルチドメイン証明書、SAN証明書、またはUCC証明書とも呼ばれます）

一般的な単一ホスト証明書は、単一のIPアドレスとホスト名がZoom Nodeと単一モジュールの間で共有される特定のシナリオを除き、Zoom Nodeでは機能しません。追加のコンテキストについては、次のZPLS図を参照してください Zoom Node導入時の考慮事項 セクション。

ワイルドカード証明書：簡便さのため推奨

ワイルドカード証明書は、ドメイン内の任意のホスト名からのトラフィックを暗号化できます。例：*.customer.com のようなワイルドカード証明書は、次からのトラフィックを暗号化できます ホスト1.customer.com および ホスト2.customer.com または次の配下の任意の名前 .customer.com.

Zoom Nodeをデプロイしてワイルドカード証明書をインストールすると、デプロイされたすべてのServicesがワイルドカードドメインの完全修飾ドメイン名（FQDN）を使用するという要件のもとで、Node上にデプロイするあらゆるサービスのトラフィックを自動的に暗号化します。

これにより、Node上にサービスをデプロイするための手間が最小限になります。デプロイ前にサービス名を把握しておく必要はありません。ただし、マルチSAN証明書方式を使用する場合は、サービス名を把握しておく必要があります。

マルチSAN、マルチドメイン、SAN、またはUCC証明書

Nodeに使用するホスト名とIPアドレス（最大1つ[1]）およびインストールするすべてのServices（最大4つ[4]）について把握している必要があります。

この情報は証明書を登録する前に必要です.

Zoom Nodeには、5つのホスト名からのトラフィックを暗号化するため、マルチSAN証明書が必要です。この証明書の一度限りの要求には、計画中のNode名やNode上にデプロイ予定のすべてのサービス名を含む、必要なすべての情報を事前に把握していることが必要です。たとえば、ZPLSのようなモジュールでは、Nodeごとに1つのZPLSモジュールのみがデプロイされるため、ZPLSサービスのホスト名には追加のSANが1つだけ必要です。

次の表は例として使用できます。

ホスト名（SAN）	IPアドレス
zoom-node01.company.com	10.1.50.100
zpls.company.com	10.1.50.100
zoom-recording.company.com	10.1.50.101
zoom-ウェビナー.company.com	10.1.50.102
（サービス4 - この例では未使用）	（該当なし）

この例は、1つのNodeが同じIP上でZPLSをホストし、さらに2つの追加サービスを別々のIP上でホストする一般的な構成を示しています。“company.com” を実際のドメインに置き換え、ネットワークのIPアドレスを使用してください。

DNS名前解決の要件

Zoomでは、双方向の信頼関係を確立できるよう、ホスト名が公開解決可能である必要があります。すべての Zoom Node のホスト名と、Node にデプロイされるすべてのサービスのホスト名を DNS ゾーンに含める必要があります。

組織が内部用と外部用で別々の DNS サービスまたはドメインを運用している場合、Zoom Node のホスト名は外部 DNS サーバーで解決可能なゾーンでホストする必要があります（Zoom の IP 範囲のみを解決するように制限できます）。内部の Zoom ユーザーと Zoomクラウドは、同じ一連のホスト名を使用して通信する必要があります。