Esta seção fornece contexto adicional sobre itens de configuração importantes relacionados a Serviços Híbridos.

Esses pontos são cruciais se você deseja implementar com sucesso o recurso de Chamadas Híbridas para dispositivos Webex. Destacamos esses itens em particular, pelas seguintes razões:

• Queremos explicar sobre eles para que você compreenda o papel deles em uma implantação híbrida e se sinta seguro.

• Eles são obrigatórios pré-requisitos que garantir uma implantação segura entre nossa nuvem e seu ambiente local.

• Eles devem ser tratados como atividades anteriores ao início da implantação: podem demorar um pouco mais para concluir a configuração típica em uma interface de usuário, então, reserve um período de tempo para classificar esses itens.

• Após a resolução desses problemas em seu ambiente, o restante da configuração dos seus Serviços Híbridos ocorrerá sem dificuldades.

A implantação do par Expressway-C e Expressway-E permite chamadas de e para a Internet usando tecnologias de travessia de firewall. Essa implementação é o que integra, de forma segura, o controle de chamadas local ao Webex.

O Expressway-C e Expressway-E não exigem qualquer porta de entrada a serem abertas na zona desmilitarizada (DMZ) do firewall, devido a arquitetura transversal do firewall. Mas as portas SIP TCP sinalizadas e as portas de mídia UDP devem estar com a entrada aberta no firewall da internet para permitir o recebimento de chamadas. Você deve aguardar um tempo para que a porta apropriada seja aberta no firewall da empresa.

A arquitetura transversal do firewall é mostrada no diagrama a seguir:

Por exemplo, para chamadas de entrada business-to-business (B2B) usando o protocolo SIP, portas TCP 5060 e 5061 (5061 é usada para SIP TLS) devem ser abertas no firewall externo, juntamente com as portas de mídia UDP usadas para serviços de voz, vídeo, compartilhamento de conteúdo vídeo bidirecional, e assim por diante. Quais portas de mídia abrir depende do número de chamadas simultâneas e o número de serviços.

Você pode configurar a porta de escuta SIP no Expressway para qualquer valor entre 1024 para 65534. Ao mesmo tempo, esse valor e o tipo de protocolo devem ser anunciados nos registros públicos do DNS SRV, e esse mesmo valor deve ser aberto no firewall da Internet.

Embora o padrão para SIP TCP seja 5060 e para SIP TLS 5061, nada impede a utilização de portas diferentes, como o exemplo a seguir mostra.

Exemplo

Neste exemplo, assumimos que a porta 5062 é usada para chamadas de entrada SIP TLS.

O registro DNS SRV para um grupo de dois servidores Expressway se parece com isto:

_sips._tcp.example.com Localização do serviço SRV:

prioridade = 10

peso = 10

porta = 5062

SVR hostname = us-expe1.example.com

_sips._tcp.example.com Localização do serviço SRV:

prioridade = 10

peso = 10

porta = 5062

SVR hostname = us-expe2.example.com

Estes registos significam que as chamadas são direcionadas para us-expe1.example.com e us-expe2.example.com com a carga de compartilhamento igual (prioridade e peso) usando TLS como o tipo de transporte e 5062 como o número de porta de escuta.

Um dispositivo que é externo à rede (na Internet) e que faz uma chamada SIP para um usuário no domínio corporativo (user1@example.com) deve consultar o DNS para entender qual tipo de transporte utilizar, o número da porta, como carregar-compartilhar o tráfego e para quais servidores SIP enviar a chamada.

Se a entrada DNS incluir _sips._tcp, a entrada especifica SIP TLS.

TLS é um protocolo cliente-servidor e, nas implementações mais comuns, utiliza certificados para autenticação. Em um cenário de chamada business-to-business, o cliente TLS é o dispositivo de chamada e o servidor TLS é o dispositivo chamado. Com o TLS, o cliente verifica o certificado do servidor, e se a verificação do certificado falhar, ele desliga a chamada. O cliente não precisa de um certificado.

O Handshake do TLS é mostrado no diagrama a seguir:

No entanto, a especificação do TLS afirma que o servidor também pode verificar o certificado do cliente enviando uma mensagem de solicitação de certificado para o cliente durante o protocolo de handshake do TLS. Esta mensagem é útil em uma conexão servidor-servidor, como em uma chamada estabelecida entre o Expressway-E e a nuvem Webex. Esse conceito é chamado de TLS com autenticação mútua e é necessário para a integração com o Webex.

Tanto a parte que chama quanto a parte que é chamada verificam o certificado do outro par, como mostra o diagrama a seguir:

A nuvem verifica a identidade do Expressway e o Expressway verifica a identidade da nuvem. Por exemplo, se a identidade de nuvem no certificado (CN ou SAN) não corresponde ao que está configurado no Expressway, a conexão é terminada.

Se a autenticação mútua estiver ativada, o Expressway-E sempre solicita o certificado de cliente. Como resultado, Mobile e Remote Access (MRA) não funcionarão, porque na maioria dos casos, os certificados não estão implantados nos clientes Jabber. Em um cenário de business-to-business, se a entidade de chamada não é capaz de fornecer um certificado, a chamada será desconectada.

Recomendamos que você use um valor diferente de 5061 para TLS com autenticação mútua, como a porta 5062. Os Serviços Híbridos do Webex usam o mesmo registro SIP TLS usado para B2B. No caso da porta 5061, alguns outros serviços que não podem fornecer um certificado de cliente TLS, não funcionarão.

Se um registro existente já estiver sendo usado para comunicações entre empresas (B2B), recomendamos especificar um subdomínio do domínio corporativo como destino SIP no Control Hub e, consequentemente, um registro DNS SRV público, conforme descrito a seguir:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

Tráfego B2B, móvel, de acesso remoto e Webex no mesmo par de vias expressas

As chamadas entre empresas (B2B) e de acesso remoto móvel (MRA) utilizam a porta 5061 para SIP TLS, e o tráfego do Webex utiliza a porta 5062 para SIP TLS com autenticação mútua.

A verificação de Propriedade do domínio é parte de verificação de identidade. A verificação de domínio é uma medida de segurança e verificação de identidade implementada pela nuvem Webex para comprovar que você é quem diz ser.

A verificação de identidade é executada em duas etapas:

1. Verificação de propriedade do domínio. Esta etapa envolve três tipos de domínios e é uma checagem de verificação única:

   • Domínio de e-mail

   • Domínio DNS do Expressway-E

   • Domínio do diretório URI

2. Verificação de propriedade do nome de DNS do Expressway-E. Esta etapa é realizada por meio da implementação do TLS com autenticação mútua e envolve o uso de certificados públicos tanto na nuvem quanto no Expressway. Ao contrário da verificação de identidade do domínio, esta etapa é executada durante qualquer chamada feita e recebida da nuvem.

A importância da verificação de propriedade do domínio

A nuvem Webex realiza a verificação de propriedade do domínio para reforçar a segurança. Roubo de identidade é uma possível ameaça se esta seleção não for executada.

A seguinte história detalha o que poderia acontecer se uma verificação da propriedade do domínio não for executada.

Uma empresa com domínio DNS configurado para "hacker.com" compra os Serviços Híbridos da Webex. Outra empresa, com o seu próprio domínio definido como "example.com", também está usando os serviços híbridos. Um dos gerentes gerais da empresa Example.com, chamado Jane Roe tem a URI de diretório jane.roe@example.com.

O administrador da empresa Hacker.com define um dos URIs do diretório como jane.roe@example.com e o endereço de e-mail como jane.roe@hacker.com. Ela pode fazer isso, porque a nuvem não verifica o domínio SIP URI neste exemplo.

Em seguida, ela entra no aplicativo Webex com jane.roe@hacker.com. Porque ela possui o domínio, o e-mail de verificação é lido e atendido, e ela pode iniciar sessão. Finalmente, ela liga para um colega, John Doe, discando... john.doe@example.com do aplicativo Webex dela. John está sentado em seu escritório e vê uma chamada em seu dispositivo de vídeo vinda de jane.roe@example.com; Esse é o URI do diretório associado àquela conta de e-mail.

"Ela está fora do país", ele pensa. "Ela deve estar precisando de algo importante". Ele atende o telefone e a falsa Jane Roe pede documentos importantes. Ela explica que seu dispositivo está danificado e porque está viajando, ela pede a ele para enviar os documentos para seu endereço de e-mail privado, jane.roe@hacker.com. Dessa forma, a empresa só se dá conta que informações importantes foram vazadas para fora da empresa, depois que Jane Roe volta para o escritório.

A empresa Example.com possui diversas maneiras de se proteger contra chamadas fraudulentas provenientes da Internet, mas uma das responsabilidades da nuvem Webex é garantir que a identidade de qualquer pessoa que ligue a partir do Webex seja correta e não falsificada.

Para verificar a identidade, a Webex exige que a empresa comprove ser proprietária dos domínios usados nas Chamadas Híbridas. Caso contrário, os Serviços Híbridos não funcionarão.

Para garantir esta propriedade, as duas etapas de verificação do domínio são obrigatórias:

1. Prove que a empresa possui o domínio de e-mail, o domínio do Expressway-E e o domínio do diretório URI.

   • Todos os domínios devem ser roteáveis e conhecidos pelo servidores de DNS públicos.

   • Para provar a propriedade, o administrador do DNS deve inserir um registro de texto do DNS (TXT). Um registro TXT é um tipo de registro de recurso no DNS usado para fornecer a capacidade de associar algum texto arbitrário e sem formatação com um organizador ou outro nome.

   • O administrador DNS deve inserir esse registro TXT na zona na qual a propriedade deve ser comprovada. Após essa etapa, a nuvem Webex realiza uma consulta de registro TXT para esse domínio.

   • Se a consulta TXT for bem-sucedida e o resultado corresponder ao token gerado pela nuvem Webex, o domínio será verificado.

   • Por exemplo, a administradora deve comprovar que é proprietária do domínio "example.com" para que os Serviços Híbridos do Webex funcionem em seu domínio.

   • Por meio de https://admin.webex.com, ela inicia o processo de verificação criando um registro TXT para corresponder ao token gerado pela nuvem Webex:

     

   • O administrador de DNS cria então um registro TXT para este domínio com o valor definido como 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, como no exemplo a seguir:

     

   • Neste ponto, a nuvem pode verificar se o registro TXT para o domínio example.com coincide com o token.

   • A nuvem realizará uma pesquisa de DNS TXT:

     

   • Como o valor TXT corresponde ao valor do token, esta correspondência comprova que o administrador adicionou o registro do seu próprio domínio ao DNS público, e que ela possui o domínio.

2. Verificação de propriedade do nome de DNS do Expressway-E.

   • A nuvem deve verificar se o Expressway-E tem uma identidade confirmada a partir de uma das autoridades de certificação em que a nuvem confia. O administrador do Expressway-E deve solicitar um certificado público para seu Expressway-E para uma dessas autoridades de certificação. Para emitir o certificado, a autoridade de certificação executa um processo de verificação de identidade, com base na verificação de um domínio (para certificados com domínio validado) ou a verificação de validação da organização (para certificados com organização validada).

   • As chamadas para a nuvem e da nuvem dependem do certificado que foi emitido para o Expressway-E. Se o certificado não for válido, a chamada é interrompida.

Para que as Chamadas Híbridas funcionem, o Conector de Dispositivo Webex precisa se comunicar com o Webex.

O Webex Device Connector é implantado na rede interna e se comunica com a nuvem por meio de uma conexão HTTPS de saída — o mesmo tipo usado por qualquer navegador que se conecta a um servidor web.

A comunicação com a nuvem Webex utiliza TLS. O Webex Device Connector é o cliente TLS e a nuvem Webex é o servidor TLS. Dessa forma, o Webex Device Connector verifica o certificado do servidor.

A autoridade de certificação assina um certificado de servidor usando sua própria chave privada. Qualquer pessoa com a chave pública pode decodificar essa assinatura e provar que a mesma autoridade de certificação assinou esse certificado.

Se o Webex Device Connector precisar validar o certificado fornecido pela nuvem, ele deverá usar a chave pública da autoridade certificadora que assinou esse certificado para decodificar a assinatura. Uma chave pública está contida no certificado da autoridade certificadora. Para estabelecer confiança com as autoridades de certificação usadas pela nuvem, a lista de certificados dessas autoridades de certificação confiáveis deve estar no repositório de confiança do Webex Device Connector.

Ao se comunicar com os dispositivos, a ferramenta utiliza certificados confiáveis que você fornece. Atualmente, a maneira de fazer isso é colocando-os em [home folder]/.devicestool/certs.

Uma lista de certificados da autoridade certificadora é necessária também para o Expressway-E no par transversal. O Expressway-E se comunica com a nuvem Webex usando SIP com TLS, com autenticação mútua garantida. O Expressway-E confia em chamadas provenientes da nuvem e destinadas a ela somente se o CN ou SAN do certificado apresentado pela nuvem durante o estabelecimento da conexão TLS corresponder ao nome do assunto configurado para a zona DNS no Expressway ("callservice.webex.com"). A autoridade de certificação só libera um certificado após uma checagem de identidade. A propriedade do domínio callservice.webex.com precisa ser comprovada para que um certificado seja emitido. Como nós (Cisco) somos proprietários desse domínio, o nome DNS "callservice.webex.com" é uma prova direta de que o servidor remoto é realmente o Webex.

O conector de calendário integra o Webex com o Microsoft Exchange 2013, 2016, 2019 ou Office 365 através de uma conta de representação. A função do gerenciamento de reconhecimento do aplicativo no Exchange permite que os aplicativos representem usuários em uma organização para executar tarefas em nome do usuário. A função de representação do aplicativo deve ser configurada no Exchange e usada no conector de calendário como parte da configuração do Exchange na interface Expressway-C.

A conta de representação do Exchange é o método recomendado pela Microsoft para esta tarefa. Expressway-C não precisa saber a senha, pois o valor pode ser inserido na interface Expressway-C por um administrador do Exchange. A senha não é claramente mostrada, mesmo se o administrador Expressway-C tiver acesso raiz à caixa Expressway-C. A senha é armazenada criptografada usando o mesmo mecanismo de criptografia de credenciais que outras senhas no Expressway-C.

Para obter segurança adicional, siga as etapas no Guia de implantação do serviço de calendário híbrido Cisco Webex para ativar o TLS a fim de proteger as conexões do EWS no cabo.

Para obter segurança adicional, siga as etapas em Implantar Expressway conector de calendário para Microsoft Exchange para ativar o TLS a fim de proteger as conexões do EWS no cabo.