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

Esses pontos são cruciais se você quiser implantar com sucesso o Hybrid Calling para dispositivos Webex. Destacamos esses itens em particular pelos seguintes motivos:

• Queremos explicá-los para que você entenda o papel deles em uma implantação híbrida e se sinta seguro.

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

• Elas devem ser tratadas como atividades anteriores ao dia zero: elas podem levar um pouco mais de tempo para serem concluídas do que a configuração típica em uma interface de usuário, portanto, permita um prazo 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 do par Expressway-C e Expressway-E permite chamadas de e para a Internet usando tecnologias de passagem de firewall. Essa implantação é o que segura seu controle de chamadas local e o vincula ao Webex.

O Expressway-C e o Expressway-E não exigem que nenhuma porta de entrada seja aberta no firewall da zona desmilitarizada (DMZ) devido à arquitetura transversal do firewall. Mas as portas de sinalização TCP SIP e as portas de mídia UDP devem ser abertas no firewall da Internet para permitir que as chamadas recebidas cheguem. Você deve reservar tempo para que a porta apropriada seja aberta no firewall da sua empresa.

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

Por exemplo, para chamadas de entrada entre empresas (B2B) usando o protocolo SIP, as portas TCP 5060 e 5061 (5061 é usada para SIP TLS) devem ser abertas no firewall externo, junto com as portas de mídia UDP usadas para serviços como voz, vídeo, compartilhamento de conteúdo, vídeo duplo e assim por diante. As portas de mídia a serem abertas dependem do número de chamadas simultâneas e do número de serviços.

Você pode configurar a porta de escuta SIP no Expressway para qualquer valor entre 1024 e 65534. Ao mesmo tempo, esse valor e o tipo de protocolo devem ser anunciados nos DNS SRV registros públicos 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 o uso de portas diferentes, como mostra o exemplo a seguir.

Exemplo

Neste exemplo, supomos que a porta 5062 seja usada para chamadas SIP TLS de entrada.

O DNS SRV registro de um cluster de dois servidores Expressway tem a seguinte aparência:

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

priority = 10

weight = 10

port = 5062

nome do host svr = us-expe1.example.com

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

priority = 10

weight = 10

port = 5062

nome do host svr = us-expe2.example.com

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

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

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

O TLS é um protocolo cliente-servidor e, nas implementações mais comuns, usa certificados para autenticação. Em um cenário de chamada entre empresas, 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 desconecta a chamada. O cliente não precisa de um certificado.

O handshake TLS é mostrado no diagrama a seguir:

No entanto, a especificação TLS afirma que o servidor também pode verificar o certificado do cliente enviando uma mensagem de solicitação de certificado ao cliente durante o protocolo de handshake TLS. Essa mensagem é útil em uma conexão de servidor a 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 na integração com o Webex.

Tanto a parte chamadora quanto a chamada verificam o certificado do outro par, conforme 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 da nuvem no certificado (CN ou SAN) não corresponder ao que está configurado no Expressway, a conexão será interrompida.

Se a autenticação mútua estiver ativada, o Expressway-E sempre solicitará o certificado do cliente. Como resultado, o Mobile and Remote Access (MRA) não funcionará, porque na maioria dos casos os certificados não são implantados em clientes Jabber. Em um cenário business-to-business, se a entidade chamadora não puder 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á estiver sendo usado para comunicações entre empresas, recomendamos especificar um subdomínio do domínio corporativo como o destino SIP no Control Hub e, consequentemente, um registro públicoDNS SRV, da seguinte forma:

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

Tráfego entre empresas, dispositivos móveis Remote Access e Webex no mesmo par Expressway

As chamadas Business-to-Business (B2B) e Mobile e 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 da propriedade do domínio faz parte da 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 é realizada em duas etapas:

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

   • Domínio de e-mail

   • Domínio DNS Expressway-E

   • Domínio URI do diretório

2. Verificação de propriedade do nome DNS do Expressway-E. Essa etapa é executada por meio da implementação do TLS com autenticação mútua e envolve o uso de certificados públicos na nuvem e no Expressway. Diferentemente da verificação de identidade do domínio, essa etapa é executada durante qualquer chamada feita e recebida da nuvem.

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

A nuvem Webex realiza a verificação de propriedade do domínio para reforçar a segurança. O roubo de identidade é uma possível ameaça se essa verificação não for realizada.

A história a seguir detalha o que pode acontecer se uma verificação de propriedade do domínio não for realizada.

Uma empresa com domínio DNS definido como “hacker.com” compra o Webex Hybrid Services. Outra empresa, com seu próprio domínio definido como “example.com”, também está usando serviços híbridos. Uma das gerentes gerais da empresa Example.com se chama Jane Roe e tem o diretório URI jane.roe@example.com.

A administradora da empresa Hacker.com define um dos URIs de seu 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 URI do SIP neste exemplo.

Em seguida, ela entra no aplicativo Webex com jane.roe@hacker.com. Como ela é proprietária do domínio, o e-mail de verificação é lido e respondido, e ela pode fazer login. Finalmente, ela liga para um colega, John Doe, ligando para john.doe@example.com a partir de seu aplicativo Webex. 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 a essa conta de e-mail.

“Ela está no exterior”, ele pensa. “Ela pode precisar de algo importante.” Ele atende o telefone e a falsa Jane Roe pede documentos importantes. Ela explica que seu dispositivo está quebrado e, como está viajando, pede que ele envie os documentos para seu endereço de e-mail privado, jane.roe@hacker.com. Dessa forma, a empresa só percebe depois que Jane Roe volta ao escritório que informações importantes vazaram para fora da empresa.

A empresa Example.com tem muitas maneiras de se proteger contra chamadas fraudulentas vindas da Internet, mas uma das responsabilidades da nuvem Webex é garantir que a identidade de qualquer pessoa que esteja ligando do Webex esteja correta e não seja falsificada.

Para verificar a identidade, o Webex exige que a empresa prove que possui os domínios usados no Hybrid Calling. Se isso não acontecer, os Serviços Híbridos não funcionarão.

Para garantir essa propriedade, as duas etapas de verificação do domínio são necessárias:

1. Prove que a empresa é proprietária do domínio de e-mail, domínio Expressway-E e domínio URI do diretório.

   • Todos esses domínios devem ser roteáveis e conhecidos pelos servidores DNS públicos.

   • Para provar a propriedade, o administrador do DNS deve inserir um registro de texto 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 não formatado a um host ou outro nome.

   • O administrador do DNS deve inserir esse registro TXT na zona cuja 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 que foi gerado na nuvem Webex, o domínio será verificado.

   • Como exemplo, o administrador deve provar que ela possui o domínio “example.com”, se quiser que o Webex Hybrid Services funcione 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 que a nuvem Webex gerou:

     

   • Em seguida, o administrador de DNS cria um registro TXT para esse domínio com o valor definido como 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, como no exemplo a seguir:

     

   • Nesse ponto, a nuvem pode verificar se o registro TXT do domínio example.com corresponde ao token.

   • A nuvem realiza uma pesquisa de DNS TXT:

     

   • Como o valor TXT corresponde ao valor do token, essa correspondência prova que a administradora adicionou o registro TXT de seu próprio domínio ao DNS público e que ela é proprietária do domínio.

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

   • A nuvem deve verificar se o Expressway-E tem uma identidade confirmada por uma das autoridades de certificação nas quais a nuvem confia. O administrador do Expressway-E deve solicitar um certificado público para seu Expressway-E a 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 em uma verificação de validação de domínio (para certificados validados de domínio) ou verificação de validação da organização (para certificados validados pela organização).

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

O Webex Device Connector deve se comunicar com o Webex para que o Hybrid Calling funcione.

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

A comunicação com a nuvem Webex usa 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 de certificação que assinou esse certificado para decodificar a assinatura. Uma chave pública está contida no certificado da autoridade de certificação. 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 Webex Device Connector.

Ao se comunicar com dispositivos, a ferramenta usa certificados confiáveis fornecidos por você. Atualmente, a maneira de fazer isso é colocá-los [home folder]/.devicestool/certs.

Também é necessária uma lista de certificados de autoridade de certificação para o Expressway-E no par transversal. O Expressway-E se comunica com a nuvem Webex usando SIP com TLS, imposto pela autenticação mútua. O Expressway-E confia nas chamadas que vêm e vão para a nuvem, somente se o CN ou SAN do certificado apresentado pela nuvem durante a configuração da conexão TLS corresponder ao nome do assunto configurado para a zona DNS no Expressway (“callservice.webex.com”). A autoridade de certificação libera um certificado somente após uma verificação de identidade. A propriedade do domínio callservice.webex.com deve ser comprovada para que um certificado seja assinado. Como nós (Cisco) possuímos esse domínio, o nome DNS “callservice.webex.com” é uma prova direta de que o peer remoto é realmente Webex.

O conector de calendário integra o Webex com Microsoft Exchange 2013, 2016, 2019 ou Office 365 por meio de uma conta de representação. A função de gerenciamento de representação de aplicativos no Exchange permite que os aplicativos se façam passar por usuários em uma organização para realizar 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 essa tarefa. Os administradores do Expressway-C não precisam saber a senha, pois o valor pode ser inserido na interface do Expressway-C por um administrador do Exchange. A senha não é mostrada claramente, mesmo que o administrador do Expressway-C tenha acesso root à caixa Expressway-C. A senha é armazenada criptografada usando o mesmo mecanismo de criptografia de credenciais de outras senhas no Expressway-C.

Para maior segurança, siga as etapas no Guia de implantação do Cisco Webex Hybrid Calendar Service para habilitar o TLS a fim de proteger as conexões EWS na rede.

Para maior segurança, siga as etapas em Implantar o Expressway Calendar Connector Microsoft Exchange para habilitar o TLS a fim de proteger as conexões EWS na rede.