Esta seção fornece um contexto adicional sobre os principais itens de configuração relacionados aos Serviços híbridos.

Esses pontos são cruciais se você deseja implantar com êxito as 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.

• Depois que esses itens forem abordados em seu ambiente, o restante da configuração dos Serviços híbridos ocorrerá sem problemas.

A implantação de emparelhamento Expressway-C e Expressway-E permite chamadas de e para a Internet usando tecnologias de passagem de firewall . Essa implantação é o que leva com segurança o controle de chamadas no local e o vincula 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 Local do serviço SRV:

prioridade = 10

peso = 10

porta = 5062

SVR hostname = us-expe1.example.com

_sips._tcp.example.com Local 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. Essa mensagem é útil em uma conexão servidor-para-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 ao se integrar 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 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á for usado para comunicações de negócios para negócios, recomendamos especificar um subdomínio do domínio corporativo como o destino SIP no Control Hub e, consequentemente, um registro SRV DNS público, da seguinte forma:

 Serviço e protocolo: _sips._tcp.mtls.example.com Prioridade: 1 Peso: Número da porta 10: Destino 5062: us-expe1.example.com 

Business-to-Business, Acesso móvel e remoto e tráfego Webex no mesmo par Expressway

As chamadas Business-to-Business (B2B) e Mobile and Remote Access (MRA) usam a porta 5061 para SIP TLS, e o tráfego Webex usa 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 que a nuvem Webex implementa para provar 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 definido como "hacker.com" compra serviços híbridos 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 inicia sessão 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 faz uma chamada para um colega, John Doe, discando john.doe@example.com do aplicativo Webex. John está sentado em seu escritório e vê uma chamada em seu dispositivo de vídeo vindo de jane.roe@example.com; que é o URI de diretório associado a essa 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 tem muitas maneiras de proteger contra chamadas fraudulentas provenientes da Internet, mas uma das responsabilidades da nuvem Webex é garantir que a identidade de qualquer pessoa que ligue do Webex esteja correta e não falsificada.

Para verificar a identidade, o Webex requer que a empresa prove que ela possui os domínios usados nas Chamadas híbridas. Se não funcionar, 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 executa uma consulta de registro TXT para esse domínio.

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

   • Por exemplo, o administrador deve provar que possui o domínio "example.com", se desejar que os serviços híbridos Webex funcionem em seu domínio.

   • Por meio 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 DNS cria um registro TXT para este domínio com o valor definido para 1234567 89abcdef123456789abcdef123456789abcdef123456789abcdef , 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.

O Conector de dispositivos Webex deve se comunicar com o Webex para que a Chamada híbrida funcione.

O Webex Device Connector é implantado na rede interna e a forma como ele se comunica com a nuvem é através de uma conexão HTTPS de saída — o mesmo tipo usado para qualquer navegador que se conecta a um servidor Web.

A comunicação com a nuvem Webex usa TLS. O Webex Device Connector é o cliente TLS e o Webex Cloud é o servidor TLS. Como tal, 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 tiver que validar o certificado fornecido pela nuvem, ele deverá usar a chave pública da autoridade de certificação 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 armazenamento confiável do Conector de dispositivos Webex.

Ao se comunicar com dispositivos, a ferramenta usa 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 o Webex em nuvem usando SIP com TLS, obrigatório pela autenticação mútua. O Expressway-E confia nas chamadas provenientes e indo para a nuvem, somente se o CN ou SAN do certificado apresentado pela nuvem durante a configuração de 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 deve ser comprovada para obter um certificado assinado. Como nós (Cisco) possuímos esse domínio, o nome DNS "callservice.webex.com" é a prova direta de que o par remoto é verdadeiramente 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.