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

TFS 2017 | TFS 2015 | TFS 2013

Segundo plano

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

• Uma única associação HTTP para o site Azure DevOps Server 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. Especialmente:

• Usar HTTP em vez de HTTPS evita a necessidade de obter e instalar certificados.
• O uso do 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 o host de Azure DevOps Server e 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 – o nome do computador, o FQDN ou o endereço IP funcionarão 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 Azure DevOps Server não é criptografada em trânsito, a menos que outras soluções como IPSec sejam usadas. Eles são, portanto, potencialmente vulneráveis a atores mal-intencionados que monitoram ou até modificam o conteúdo da comunicação. Esses problemas são mitigados até certo ponto quando Azure DevOps Server é implantado em uma intranet por trás de um firewall corporativo, como a grande maioria das instâncias de Azure DevOps Server. Mas, mesmo nesses cenários, os dados enviados de e para Azure DevOps Server 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/versão, tokens de acesso pessoal) que enviam tokens de portador pela transmissão. 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 de Azure DevOps Server.

Configuração de grupos

O TFS 2017 apresenta opções de configuração de configuração de site em todos os cenários de configuração do servidor. Vários grupos de configurações 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ções é apropriado, as configurações podem ser totalmente personalizadas usando a caixa de diálogo Editar Configurações do Site.

O grupo configuração padrão inclui as mesmas configurações usadas em versões anteriores do Azure DevOps Server. Por todos os motivos listados acima, essas configurações ainda são o padrão para novas implantações de Azure DevOps Server. Para implantações existentes, tentaremos preservar as configurações existentes, o que geralmente resultará na seleção do grupo 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ções é do formulário https://fully-qualified-domain-name. Por padrão, esse grupo de configurações provisionará novos certificados autoassinados e os usará para a associação HTTPS. Normalmente, não recomendamos usar certificados autoassinados para implantações de TFS de produção. Consulte 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ções é do formulário https://fully-qualified-domain-namee os certificados autoassinados serão provisionados por padrão.

O grupo de configuração Somente HTTP provisiona uma única associação HTTP na porta 80 sem nenhum Nome de Host especificado. A URL pública para esse grupo de configurações é do formulário http://machine-name.

Ao usar o grupo de configurações 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 de Azure DevOps Server. Muitas organizações têm políticas específicas sobre a implantação de certificados, portanto, a primeira etapa para decidir qual certificado usar para uma implantação de Azure DevOps Server geralmente é conversar com um grupo de tecnologia da informação no nível da organização.

As opções incluem:

• Permitir 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 de Azure DevOps Server, pois são muito fáceis de provisionar e usar. Elas são menos apropriadas para implantações de produção de Azure DevOps Server e não recomendamos que elas sejam usadas para implantações Azure DevOps Server expostas à Internet pública. Geralmente, os certificados autoassinados são suscetíveis a ataques de homem no meio. Eles também causam problemas para os usuários, pois eles 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 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 por Azure DevOps Server. 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 a necessidade de 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:

• Usando o snap-in do MMC certificados para exportar manualmente o certificado no servidor e importá-lo em cada cliente.
• Usando o cmdlet do powershell Export-Certificate, disponível em Windows 8/Windows Server 2012 e sistemas operacionais posteriores, para exportar o certificado. Import-Certificate pode ser usado para importá-lo em cada cliente.
• Usando 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 Azure DevOps Server. Se sua organização tiver sua própria infraestrutura de chave pública, essa poderá ser uma boa opção para sua implantação de Azure DevOps Server.

Quando outras opções não são apropriadas ou 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 Assinatura 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 em sua 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 bits igual ou superior a 2048.

Alterando sua URL pública

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