Considerações sobre a implementação do Zoom Node

Saiba mais sobre como vários exemplos de implementação dão suporte ao Zoom Node e aos Módulos de Serviço do Zoom Node

Esta seção contém vários exemplos de como o Zoom Node pode suportar vários Módulos de Serviço como Zoom Meetings Híbrido e Zoom Phone Local Survivability (ZPLS). Implantações típicas com um endereço IP dedicado podem se parecer com a seguinte coleção de diagramas.

Cada serviço implantado no Zoom Node requer um endereço IP exclusivo. Um Zoom Node terá até cinco (5) endereços IP atribuídos a ele se o Node tiver recebido um endereço específico para gerenciamento e um para cada serviço implantado (até quatro) no Node. Um Zoom Node executando um único serviço (como ZPLS) pode ser implantado com um único endereço IP se o Node e o serviço forem configurados para compartilhar o mesmo endereço IP.

Várias opções de implantação são mostradas abaixo. Observe o número de IPs e certificados (CN/SANs) para as várias opções de implantação.

Opção 1: Zoom Meetings Híbrido implantado com endereços IP dedicados e nomes de host

A imagem acima resume os requisitos de configuração de IP e certificado para implantar Zoom Meetings em ambientes locais ou de nuvem híbrida.

A tabela abaixo detalha o Node de exemplo e inclui seus módulos de serviço proxy Ativo e MMR:

Componente	Nome do host	Função de certificado TLS	Função
SO do nó	node1.customer.com	Nome Comum (CN)	Orquestração central
Zoom Conector Proxy	zcp1.customer.com	Nome Alternativo do Assunto (SAN)	Sinalização e controle de sessão
Roteador do Módulo de Mídia 1	mmr1.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia
Roteador do Módulo de Mídia 2	mmr2.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia
Roteador do Módulo de Mídia 3	mmr3.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia

Você deve Atribuir a cada módulo um endereço IP estático dedicado. Total de endereços IP necessários: cinco (5)

A imagem acima descreve a configuração mínima necessária para implantar Sobrevivência Local do Zoom Phone (ZPLS). O ZPLS permite a continuidade da disponibilidade do serviço telefônico no Evento de interrupção da internet ou da nuvem, executando a lógica de sobrevivência localmente em uma VM do Zoom Node.

Os seguintes hostnames devem ser configurados no DNS e incluídos no certificado TLS:

• node1.customer.com

• zplsl.customer.com

Mapeamento Funcional de Hostname

Componente	Nome do host	Função de certificado TLS	Função
SO do nó	node1.customer.com	Nome Comum (CN)	Orquestração central
Módulo ZPLS	zplsl.customer.com	Nome Alternativo do Assunto	Lógica de Local Survivability do Zoom Phone

Configuração do certificado TLS

Campo	Valor
Nome Comum (CN)	node1.customer.com
Nomes Alternativos do Assunto	zplsl.customer.com

Os certificados devem ser gerados ou obtidos (AC pública ou privada) para incluir tanto o CN como os SANs listados acima. Isso permite a validação TLS adequada para uma comunicação segura entre módulos.

Requisitos de endereço IP

Métrica	Valor / Descrição
Total de endereços IP necessários	5 (alocação geral)
Usado no contexto ZPLS	2 IPs (1 para o SO do Node, 1 para o módulo ZPLS)

Embora sejam necessários cinco (5) IPs para a implantação geral, apenas dois (2) endereços IP estão a ser usados ativamente na implantação ZPLS: um por módulo, executando em um VM Node dedicada.

O ZPLS permite apenas um módulo por VM do Node. Não é possível co-localizar o ZPLS com outros módulos do Zoom na mesma VM.

Como estes diagramas se comparam? A primeira imagem mostra um exemplo de uma implementação híbrida do Zoom Meetings. A segunda imagem mostra um exemplo de uma implementação de sobrevivência local do Zoom Phone.

Você pode compartilhar o primeiro IP/nome de host entre o SO e o primeiro módulo, se desejar, para reduzir o número de endereços IP, nomes de host e Subject Alternative Names (SANs) necessários.

Opção 2: Zoom Meetings Hybrid implantado com um IP partilhado e um nome de host partilhado

Esta configuração repete a estrutura Node conforme visto no diagrama Híbrido do Zoom Meetings da Opção 1. No entanto, nesta implementação, o O SO do nó compartilha seu endereço IP com o primeiro módulo implantado (tipicamente o Zoom Conector Proxy, ZCP). Isso resulta em menor utilização de IP, mantendo o TLS e os requisitos funcionais.

Os seguintes hostnames devem ser configurados no DNS e incluídos no certificado TLS:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Mapeamento Funcional de Hostname

Componente	Nome do host	Função de certificado TLS	Função
ZCP (Proxy do Conector Zoom)	zcp1.customer.com	Nome Comum (CN)	Sinalização e controle de sessão
Roteador do Módulo de Mídia 1	mmr1.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia
Roteador do Módulo de Mídia 2	mmr2.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia
Roteador do Módulo de Mídia 3	mmr3.customer.com	Nome Alternativo do Assunto (SAN)	Roteamento e processamento de mídia

Configuração do certificado TLS

Campo	Valor
Nome Comum (CN)	zcp1.customer.com
Nomes Alternativos do Assunto	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

Os certificados devem incluir todos os SANs para Suporte à comunicação TLS segura entre o Zoom Node e os módulos Zoom instalados.

Requisitos de endereço IP

Métrica	Valor / Descrição
Total de endereços IP necessários	4
Estratégia de partilha de IP	O SO do nó partilha o IP com o primeiro módulo (ZCP)
IPs individuais necessários para	ZCP/MMR1, MMR2, MMR3

Quando o endereço IP é partilhado entre o SO do Node e o primeiro módulo implantado (ZCP), apenas quatro (4) endereços IP são necessários. Este design otimiza a utilização de IP, ao mesmo tempo que continua a cumprir as normas de implementação.

A imagem acima mostra uma implantação mínima do ZPLS em que o O SO do Node partilha o seu endereço IP com o módulo ZPLS instalado. Este é o único cenário no framework do Zoom Node em que um certificado TLS de um único anfitrião é válido.

O seguinte nome do anfitrião deve ser configurado no DNS e incluído no certificado TLS:

• zplsl.customer.com

Mapeamento Funcional de Hostname

Componente	Nome do host	Função de certificado TLS	Função
Módulo ZPLS	zplsl.customer.com	Nome Comum (CN)	Lógica de Local Survivability do Zoom Phone

Configuração do certificado TLS

Campo	Valor
Nome Comum (CN)	zcp1.customer.com
SANs	(não obrigatório)

Nesta configuração, um certificado de um único anfitrião é suficiente, uma vez que tanto o SO como o módulo ZPLS partilham o mesmo nome do anfitrião e endereço IP.

Requisitos de endereço IP

Métrica	Valor / Descrição
Total de endereços IP necessários	1
Estratégia de partilha de IP	O SO do Node e o ZPLS partilham um único endereço IP
Restrição de implementação	Apenas um módulo permitido por VM do Node (apenas ZPLS)

O ZPLS é o único cenário suportado na arquitetura do Zoom Node em que:

• Um certificado de anfitrião único (apenas CN) é aceitável

• É necessário apenas um (1 )endereço IP para a implementação devido à partilha de endereço IP entre o SO e o módulo

• A co-localização de módulos adicionais na mesma VM não é suportada

Decida qual método de gestão de certificados funciona melhor para as suas implementações

Cada Módulo de Serviço implementado no Zoom Node requer um certificado válido assinado por uma Autoridade de Certificação (CA) publicamente confiável da lista de confiança de certificados do Zoom Node. Isto inclui autoridades públicas bem conhecidas.

O Zoom Node oferece dois métodos de gestão de certificados:

• Auto PKI: Esta solução inovadora automatiza a inscrição e a renovação seguras de certificados com Autoridades Certificadoras (CAs) publicamente confiáveis. O Zoom cobre os custos associados à inscrição e à renovação.

• Traga Seu Próprio Certificado (BYOC): Com esta opção, você fornece seus próprios certificados, assinados por qualquer grande CA publicamente confiável. Você é responsável pela inscrição e pelas renovações dos certificados. Considerações adicionais se aplicam ao potencial do Zoom Node para até cinco nomes de host/SANs ao usar certificados fornecidos pelo cliente, detalhadas mais abaixo.

Gerenciamento Automático de Certificados com Auto PKI

O Zoom Auto PKI instala automaticamente certificados de CA válidos e publicamente confiáveis para a plataforma Zoom Node, bem como quaisquer módulos implantados nela. A renovação de certificados também é tratada automaticamente. Isso simplifica o gerenciamento de certificados para todos os serviços e para o próprio Zoom Node.

Entendendo a Inscrição e a Renovação de Certificados do Auto PKI

O cenário a seguir pode ajudar você a entender como a inscrição e a renovação de certificados funcionam.

Por exemplo: Um administrador implantou uma nova instância de Node. Cada instância requer um certificado x509 válido. A chave privada do certificado nunca deve sair desta instância.

O processo Auto PKI realiza os seguintes passos:

1. Recuperação de template: Puxa todos os modelos de configuração compatíveis, incluindo opções para vários provedores de CA, do serviço Auto PKI no Zoom cloud.

2. Coleta de endereço IP: Reúne todos os endereços IP usados por serviços executados no Nó e os envia ao serviço Auto PKI no Zoom cloud.

3. Provisionamento de Nome DNS: O serviço de nuvem Auto PKI retorna um conjunto de nomes DNS no formato <instance_identificador>.<customer_identificador>.zoomonprem.com. Estes domínios estão configurados com registos A/AAAA.

4. Pedido de nome DNS reservado: Solicita um nome DNS reservado no formato rsvd-<randomized_string>.<customer_identificador>.zoomonprem.com.

5. Geração do pedido de certificado: Gera uma solicitação de certificado x509, usando os nomes DNS da terceira etapa no campo SAN e o nome reservado da quarta etapa no campo Nome Comum (CN).

6. Emissão de certificado: Envia a solicitação de assinatura de certificado (CSR) para o serviço de Auto PKI na Zoom cloud. Este serviço então trabalha com fornecedores de CA para emitir o certificado, que inclui a lista SAN e o campo CN da etapa anterior.

7. Armazenamento local: Grava o certificado x509 recém-emitido da etapa anterior e sua chave privada correspondente (gerada anteriormente) no armazenamento local, ficando Disponível para os serviços em execução na instância do Node.

Auto PKI simplifica o gerenciamento de certificados no Zoom Node ao monitorar automaticamente as datas de expiração e solicitar novos certificados, eliminando a necessidade de renovação manual.

Traga os seus próprios certificados (BYOC)

Pode instalar os seus próprios certificados válidos e assinados publicamente no Zoom Node através da interface web local. Pode fazê-lo durante a instalação inicial ou posteriormente. O processo será familiar para quem está habituado a instalar certificados em aplicações baseadas na Web.

Se optar por utilizar os seus próprios certificados, lembre-se de que o certificado estará num servidor que comunica com vários nomes de anfitrião. Por conseguinte, o tipo de certificado que Escolher deve oferecer Suporte à criptografia do tráfego proveniente de mais de um nome de anfitrião (CN do certificado). Todos os nomes de anfitrião utilizados para o Node e quaisquer serviços implementados devem poder ser resolvidos publicamente pelos serviços de nuvem do Zoom.

O Zoom recomenda dois tipos de certificados:

• Certificado curinga

• Certificado Multi-SAN (também conhecido como Certificado multidomínio, Certificado SAN ou Certificado UCC)

Um certificado típico de anfitrião único não funcionará com o Zoom Node, exceto no cenário específico em que um único endereço IP e nome de anfitrião são partilhados entre o Zoom Node e um único módulo. Para contexto adicional, consulte o diagrama ZPLS no Considerações sobre a implementação do Zoom Node secção.

Certificados curinga: recomendados pela simplicidade

Um certificado curinga pode criptografar o tráfego de qualquer nome de anfitrião no domínio. Por exemplo: um certificado curinga como *.customer.com pode criptografar o tráfego de host1.customer.com e host2.customer.com ou qualquer nome dentro de .customer.com.

Quando você implanta o Zoom Node e instala o certificado curinga, ele criptografará automaticamente o tráfego para quaisquer serviços que você implantar no Node, com a exigência de que todos os Serviços implantados usem um Nome de Domínio Totalmente Qualificado (FQDN) do domínio curinga.

Isso minimiza o esforço para implantar serviços no Node: você não precisa saber os nomes dos serviços antes de implantá-los. No entanto, você precisa saber os nomes dos serviços se estiver usando o método de certificado multi-SAN.

Certificados Multi-SAN, Multi-Domain, SAN ou UCC

Você deve saber os nomes de host e os endereços IP que usará para o Node (até um [1]) e quaisquer Serviços que estará instalando (até quatro [4]).

Essas informações são necessárias antes de inscrever um certificado.

Um certificado Multi-SAN é necessário para o Zoom Node porque ele criptografa o tráfego de cinco (5) nomes de host. Uma solicitação única para este certificado exige conhecimento prévio de todas as informações necessárias, incluindo os nomes planejados do Node e os nomes de todos os serviços programados para implantação no Node. Por exemplo, com um módulo como ZPLS, apenas um módulo ZPLS é implantado por Node, então apenas um SAN adicional é necessário para o nome de host do serviço ZPLS.

A tabela a seguir pode ser usada como exemplo:

Nome do host (SAN)	Endereço 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-webinar.company.com	10.1.50.102
(Serviço 4 - não usado neste exemplo)	(N/D)

Este exemplo é de uma configuração típica, com um Zoom Node hospedando o ZPLS no mesmo IP, além de dois serviços adicionais em IPs separados. Substitua “company.com” pelo seu domínio real e use os endereços IP da sua rede.

Requisitos de Resolução de DNS

O Zoom exige que os nomes de host sejam resolvíveis publicamente para que a confiança bidirecional possa ser estabelecida. Todos os nomes de host do Zoom Node e todos os nomes de host dos serviços implantados nos Nodes devem ser incluídos na Zona DNS.

Se sua Organização executa serviços ou domínios de DNS internos e externos separados, os nomes de host do Zoom Node precisam ser hospedados em uma zona que possa ser resolvida pelos seus servidores de DNS externos (podendo ser restrito a resolver apenas para intervalos de IP do Zoom). Seus usuários internos do Zoom e o Zoom cloud precisam se comunicar usando o mesmo conjunto de nomes de host.