Configurações do site e segurança do Azure DevOps local

TFS 2017 | TFS 2015 | TFS 2013

Contexto

Para muitas versões, as configurações de site padrão do Azure DevOps Server, anteriormente denominado TFS (Team Foundation Server), foram:

• Uma única associação HTTP para o site do Servidor do Azure DevOps na porta 8080, sem nenhum nome de host ou endereço IP especificado.
• Uma URL pública (anteriormente conhecida como URL de Notificação) do formulário http://machine-name:8080/tfs.

O principal benefício dessas configurações é que elas são muito simples de configurar e convenientes para os usuários finais na maioria dos cenários. Em particular:

• Usar HTTP em vez de HTTPS evita a necessidade de obter e instalar certificados.
• Usar o 8080 em vez de 80 evita possíveis conflitos com outros sites no mesmo computador.
• O uso de "tfs" como diretório virtual para o site facilita a hospedagem do Azure DevOps Server e de outros sites na mesma porta, no mesmo servidor.
• Usar o nome do computador, em vez do FQDN (nome de domínio totalmente qualificado), na URL pública salva muita digitação.
• Deixar o nome do host na associação não especificada permite flexibilidade na conexão - nome do computador, FQDN ou endereço IP funcionará quando os usuários tentarem se conectar aos servidores.

No entanto, essas configurações não são seguras por padrão. Em particular, não usando uma associação HTTPS, a comunicação de e para o Servidor do Azure DevOps não é criptografada em trânsito, a menos que outras soluções como o IPSec sejam usadas. Eles são, portanto, potencialmente vulneráveis a atores mal-intencionados monitorando ou até modificando o conteúdo da comunicação. Esses problemas são mitigados até certo ponto quando o Azure DevOps Server é implantado em uma intranet por trás de um firewall corporativo, assim como ocorre com a grande maioria das instâncias do Azure DevOps Server. Mas, mesmo nesses cenários, os dados enviados de e para o Servidor do Azure DevOps incluem código-fonte, dados de item de trabalho e outras informações que geralmente podem se beneficiar de segurança adicional.

Além disso, no TFS 2017, existem novos cenários de autenticação (autenticação de conta de serviço do agente de build/publicação, tokens de acesso pessoal) que enviam tokens portadores pela rede. Se esses tokens forem obtidos por usuários mal-intencionados, eles poderão ser usados para representar os usuários aos quais pertencem.

Considerando tudo isso, decidimos que chegou a hora de defender mais fortemente o uso de associações HTTPS em implantações do Servidor do Azure DevOps.

Configurando grupos

O TFS 2017 apresenta opções de configuração de site da web em todos os cenários de configuração do servidor. Vários grupos de configuração são fornecidos, que agrupam combinações de associações de site, diretórios virtuais e URLs públicas que recomendamos e acreditamos que serão mais comumente usadas. Para cenários em que nenhum desses grupos de configuração é apropriado, as configurações podem ser totalmente personalizadas usando a caixa de diálogo Editar Configurações do Site.

O grupo de configuração padrão inclui as mesmas configurações usadas nas versões anteriores do Servidor do Azure DevOps. Por todos os motivos listados acima, essas configurações ainda são o padrão para novas implantações do Servidor do Azure DevOps. Para implantações existentes, tentaremos preservar as configurações existentes, o que geralmente resultará na seleção do grupo de configuração Padrão.

O grupo de configuração HTTPS e HTTP (com redirecionamento) provisiona duas associações:

• Uma associação HTTPS na porta 443, com o FQDN (nome de domínio totalmente qualificado) do computador como o Nome do Host.
• Uma associação HTTP na porta 80, novamente com o FQDN do computador como o Nome do Host.

A associação HTTP na porta 80 é adicionada apenas como uma conveniência para os usuários finais – um redirecionamento é configurado para que todo o tráfego acabe usando a associação HTTPS na porta 443. A URL pública para esse grupo de configuração é no formato https://fully-qualified-domain-name. Por padrão, esse grupo de configuração provisionará novos certificados autoassinados e os usará para a associação HTTPS. Normalmente, não recomendamos o uso de certificados autoassinados para implantações de TFS de produção. Consulte as Opções de Certificado abaixo para obter mais informações sobre quando é apropriado usar certificados autoassinados e quais outras opções estão disponíveis.

O grupo de configuração HTTPS provisiona apenas uma única associação HTTPS na porta 443, com o FQDN do computador como o Nome do Host. Novamente, a URL pública para esse grupo de configuração é do formulário https://fully-qualified-domain-namee os certificados autoassinados serão provisionados por padrão.

A configuração 'HTTP Only' provisiona uma única associação HTTP na porta 80 sem especificar o Nome do Host. A URL pública para esse grupo de configuração é da forma http://machine-name.

Ao usar o grupo de configuração HTTPS e HTTP (com redirecionamento), o uso de uma URL pública HTTP não é recomendado. A maioria dos navegadores modernos considerará o conteúdo HTTP e HTTPS misto inseguro por padrão e poderá exibir páginas vazias. Embora geralmente seja possível substituir as configurações padrão do navegador e permitir conteúdo inseguro, isso resultará em uma experiência semelhante à navegação em um site com um certificado SSL expirado.

Opções de certificado

A implantação de sites usando associações HTTPS e criptografia SSL/TLS está intimamente relacionada ao tópico mais amplo da PKI (infraestrutura de chave pública), que é um tópico avançado e interessante para o qual já existe uma ampla variedade de documentação. Não tentaremos cobrir toda a complexidade aqui, mas nos concentraremos em opções de alto nível para configurar associações HTTPS para implantações do Servidor do Azure DevOps. Muitas organizações têm políticas específicas em torno da implantação de certificados, portanto, a primeira etapa para decidir qual certificado usar para uma implantação do Servidor do Azure DevOps geralmente é conversar com um grupo de tecnologia da informação no nível da organização.

As opções incluem:

• Permitindo que o assistente de configuração do TFS gere certificados autoassinados para uso pela implantação.
• Obtendo um certificado de uma Autoridade de Certificação interna.
• Obtendo um certificado de uma Autoridade de Certificação externa.

Certificados autoassinados

Certificados autoassinados são úteis para implantações de avaliação do Azure DevOps Server, pois são muito fáceis de provisionar e usar. Elas são menos apropriadas para implantações de produção do Servidor do Azure DevOps e não recomendamos que sejam usadas para implantações do Servidor do Azure DevOps expostas à Internet pública. Geralmente, certificados autoassinados são suscetíveis a ataques de intermediário. Eles também causam problemas para os usuários, pois causarão avisos e erros de certificado até que seus certificados raiz sejam instalados em cada computador cliente. Por exemplo, o navegador Edge mostrará o erro abaixo.

Quando o assistente de configuração do TFS gerar certificados autoassinados para sua implantação, ele criará dois : um que é colocado no repositório Autoridades de Certificação Raiz Confiáveis no servidor e um segundo, assinado pelo primeiro, que é colocado no repositório Pessoal no servidor e usado pelo Servidor do Azure DevOps. Configurar as coisas dessa maneira ajuda a atenuar a possibilidade de ataques man-in-the-middle e permite a rotação do certificado usado na associação HTTPS sem também precisar distribuir um novo certificado para todos os clientes, a fim de evitar erros de certificado como o mostrado acima.

Para evitar esses avisos e erros de certificado, você pode exportar o certificado raiz e instalá-lo em computadores cliente. Há várias maneiras de fazer isso, incluindo:

• Usar o snap-in de certificados do MMC para exportar manualmente o certificado no servidor e importá-lo em cada máquina cliente.
• Usando o cmdlet Exportar-Certificado do PowerShell, disponível no Windows 8/Windows Server 2012 e em sistemas operacionais posteriores, para exportar o certificado. O Import-Certificate pode então ser usado para importá-lo em cada cliente.
• Usando a Política de Grupo para automatizar a distribuição para clientes.

Autoridades de Certificação internas e externas

Muitas grandes organizações têm sua própria infraestrutura de chave pública e são capazes de emitir certificados de suas próprias Autoridades de Certificação. Normalmente, quando esse for o caso, os certificados raiz confiáveis dessas autoridades já serão distribuídos para computadores cliente, evitando, assim, a necessidade de distribuir certificados adicionais para o Servidor do Azure DevOps. Se sua organização tiver sua própria infraestrutura de chave pública, essa poderá ser uma boa opção para a implantação do Servidor do Azure DevOps.

Quando outras opções não são apropriadas ou estão disponíveis, os certificados podem ser obtidos (normalmente a um custo) de uma AC (Autoridade de Certificação) externa. As instruções para esse processo, que começa com a criação de uma Solicitação de Autenticação de Certificado, podem ser encontradas na maioria dos sites da AC. Algumas observações importantes:

• Verifique se o Nome Comum fornecido na solicitação de certificado corresponde ao nome do host desejado na URL pública, por exemplo, tfs.contoso.com.
• Nas Propriedades do Provedor de Serviços Criptográficos, recomendamos selecionar o Provedor Criptográfico do Microsoft RSA SChannel e um comprimento de bit de 2048 ou superior.

Alterando sua URL pública

Também deve-se observar que, ao atualizar uma implantação existente do Azure DevOps Server, alterar a URL pública afetará os usuários finais. Embora ainda recomendemos a conversão de associações de HTTP para HTTPS, as conexões de cliente do Visual Studio precisarão ser restabelecidas, os marcadores antigos não funcionarão mais corretamente e assim por diante. Portanto, é importante coordenar esse tipo de alteração com os usuários da implantação do Servidor do Azure DevOps para evitar interrupções significativas.