A implantação do par Expressway-C e Expressway-E permite que as chamar para e através da Internet usando tecnologias transversais de firewall. Essa implantação é o que protege o controle de chamada do seu local e o conecta ao Cisco 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:

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

prioridade = 10

peso = 10

porta = 5062

SVR hostname = us-expe1.example.com

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

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 inclui _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 entre servidores, como na chamada que é estabelecida entre o Expressway-E e a Cisco Webex nuvem. Este conceito é chamado TLS com autenticação mútua e é necessário ao integrar com Cisco 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. Cisco Webex Serviços híbridos 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.

Business-to-business, Mobile e Remote Access e Cisco Webex tráfego no mesmo par do Expressway

Chamadas Business-to-business e Mobile e Remote Access e usam a porta 5061 para SIP TLS, e o Cisco Webex tráfego 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 Cisco Webex nuvem implementa para provar que você é quem você 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.

Uma história para mostrar a importância sobre a verificação da propriedade do domínio

A nuvem Cisco Webex executa 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 o domínio DNS definido como "hacker.com" compra Cisco Webex Serviços Híbridos. 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 se conecta ao Cisco Webex Teams 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 Cisco Webex Teams dela. John está sentado em seu escritório e vê uma chamada no seu dispositivo de vídeo proveniente de jane.roe@example.com; este é o diretório URI que está associado com 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 se proteger contra chamadas fraudulentas provenientes da Internet, mas uma das responsabilidades da nuvem Cisco Webex é ter certeza de que a identidade de quem chama de Cisco Webex está correta e não foi falsificada.

Para verificar a identidade, Cisco Webex requer que a empresa comprove que ela possui os domínios usados nas chamada híbrida. Se não tiver, não funcionará.

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 esse passo, a nuvem Cisco Webex executa uma consulta do registro TXT para esse domínio.

   • Se a consulta TXT é bem sucedida e o resultado coincide com o token que foi gerado a partir da nuvem Cisco Webex, o domínio é verificado.

   • Por exemplo, o administrador deve provar que possui o domínio "example.com", se quiser que os Serviços híbridos Cisco Webex funcionem no seu domínio.

   • Através de https://admin.webex.com, ela inicia o processo de verificação através da criação de um registro TXT para coincidir com o código que a nuvem Cisco Webex gerou:

     

   • Em seguida, o administrador DNS cria 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.

O host do conector Expressway-C deve ser registrado para Cisco Webex para que os serviços híbridos funcionem.

O Expressway-C é implantado na rede interna, e a forma como se registra na nuvem é através de uma conexão HTTPS de saída — o mesmo tipo que é usado para qualquer navegador que se conecta a um servidor web.

O registro e a comunicação com a nuvem Cisco Webex usa TLS. O Expressway-C é o cliente TLS e a nuvem Cisco Webex é o servidor TLS. Como tal, o Expressway-C 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 Expressway-C tiver que validar o certificado fornecido pela nuvem, ele deve 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 a relação de confiança com as autoridades de certificação usadas pela nuvem, a lista de certificados destas autoridades de certificação confiáveis devem estar no repositório de confiança do Expressway. Ao fazer isso, o Expressway pode verificar que a chamada é realmente proveniente da nuvem Cisco Webex.

Com o carregamento manual, você pode carregar todos os certificados relevantes da autoridade certificadora para o repositório de confiança do Expressway-C.

Com o carregamento automático, a própria nuvem carrega esses certificados no repositório de confiança do Expressway-C. Recomendamos que você use o upload automático. A lista de certificados pode mudar e upload automático garante que você tenha a lista mais atualizada.

Se você permitir a instalação automática de certificados da autoridade certificadora, você será redirecionado ao https://admin.webex.com (o portal de gerenciamento). O redirecionamento é feito pelo próprio Expressway-C sem nenhuma intervenção por parte do usuário. Você, como o administrador do Cisco Webex, deve se autenticar através de uma conexão HTTPS. Logo após, a nuvem faz ou push dos certificados de CA para o Expressway-C.

Até que os certificados sejam carregados para o repositório de confiança do Expressway-C, a conexão HTTPS não pode ser estabelecida.

Para evitar esse problema, o Expressway-C é pré-instalado com Cisco Webex- certificados de CA confiáveis. Esses certificados são usados apenas para configurar e validar a conexão HTTPS inicial, e não aparecem na lista de confiança do Expressway-C. Uma vez que os certificados das autoridades de certificação confiáveis são retirados da nuvem através esta conexão HTTPS inicial, esses certificados estão disponíveis para uso de toda a plataforma; em seguida, eles serão exibidos na lista de confiança do Expressway-C.

Esta lista mostra os certificados da autoridade certificadora que a nuvem Cisco Webex usa atualmente. Esta lista pode mudar no futuro:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

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 Cisco Webex usando o SIP com o TLS, aplicados pela autenticação mútua. O Expressway-E confia em chamadas vindas e provenientes da 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 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. Porque nós (Cisco) possuímos esse domínio, o nome do DNS "callservice.webex.com" é prova direta de que os pares remotos são realmente Cisco Webex.

Conector de calendário integrar Cisco Webex com o Microsoft Exchange 2010, 2013, 2016 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 do Expressway-C.

A conta de representação do Exchange é o método recomendado pela Microsoft para esta tarefa. Os administradores Expressway-C não precisam 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 a Expressway-C administrador tiver acesso raiz para a 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.