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

TFS 2017 | TFS 2015 | TFS 2013

Contexto geral

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

• Uma única associação HTTP para o site do Servidor de DevOps do Azure na porta 8080, sem nome de host ou endereço IP especificado.
• Um URL público (anteriormente referido como o 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 especial:

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

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

Além disso, existem novos cenários de autenticação no TFS 2017 (autenticação da conta de serviço do agente de compilação/distribuição, tokens de acesso pessoal) que enviam tokens de portador através da rede. Se esses tokens forem obtidos por usuários mal-intencionados, eles podem ser usados para se passar pelos usuários aos quais pertencem.

Diante de tudo isso, decidimos que havia chegado a hora de defender mais fortemente o uso de associações HTTPS em implantações do Azure DevOps Server.

Definição de grupos

O TFS 2017 apresenta as opções de configuração das definições do site 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ções é apropriado, as configurações podem ser totalmente personalizadas usando a caixa de diálogo Editar configurações do site.

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

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

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

A ligaçã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 ligação HTTPS na porta 443. A URL Pública para este grupo de configurações tem o formato 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 o uso de certificados autoassinados para implantações do 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 apenas provisiona uma única ligação HTTPS na porta 443, utilizando o FQDN da máquina como Nome do Anfitrião. Novamente, a URL Pública para esse grupo de configurações tem o formato https://fully-qualified-domain-name, e os certificados autoassinados serão provisionados por padrão.

O grupo de configuração Somente HTTP provisiona uma única ligação HTTP na porta 80 sem Nome de Host especificado. A URL Pública para este grupo de configurações tem o formato 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 misto HTTP e HTTPS 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 ligações HTTPS e criptografia SSL/TLS está intimamente relacionada ao tópico mais amplo da infraestrutura de chave pública (PKI), que é um tópico rico e interessante para o qual já existe uma ampla variedade de documentação. Não tentaremos abordar toda a complexidade aqui, mas nos concentraremos em opções de alto nível para configurar associações HTTPS para implantações do Azure DevOps Server. 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 Azure DevOps Server 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.
• Obter um certificado de uma Autoridade de Certificação interna.
• Obter um certificado de uma Autoridade de Certificação externa.

Certificados autoassinados

Os 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. Eles são menos apropriados para implantações de produção do Servidor de DevOps do Azure e não recomendamos que sejam usados para implantações do Servidor de DevOps do Azure expostas à Internet pública. Geralmente, os certificados autoassinados são suscetíveis a ataques man-in-the-middle. Eles também causam problemas para os usuários, uma vez que causarão avisos e erros de certificado até que seus certificados raiz sejam instalados em cada máquina cliente. Por exemplo, o navegador Edge mostrará o erro abaixo.

Quando o assistente de configuração do TFS gera certificados autoassinados para sua implantação, ele cria dois - um que é colocado no armazenamento de 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 Azure DevOps Server. Configurar as coisas dessa maneira ajuda a mitigar a possibilidade de ataques man-in-the-middle e permite a rotação do certificado usado na vinculaçã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 máquinas cliente. Há várias maneiras de fazer isso, incluindo:

• Usando o snap-in de Certificados do MMC para exportar manualmente o certificado no servidor e, em seguida, importá-lo em cada cliente.
• Usando o cmdlet Export-Certificate powershell, disponível no Windows 8 / Windows Server 2012 e sistemas operacionais posteriores, para exportar o certificado. Import-Certificate pode então ser usado para importá-lo em cada cliente.
• Usando a Diretiva 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 podem emitir certificados de suas próprias Autoridades de Certificação. Normalmente, quando esse é o caso, os certificados raiz confiáveis para essas autoridades já serão distribuídos para máquinas cliente, evitando assim a necessidade de distribuir certificados adicionais para o Azure DevOps Server. Se sua organização tiver sua própria infraestrutura de chave pública, essa pode ser uma boa opção para sua implantação do Azure DevOps Server.

Quando outras opções não são apropriadas ou não estão disponíveis, os certificados podem ser obtidos (normalmente a um custo) de uma Autoridade de Certificação (CA) 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 autoridade de certificação. Algumas observações importantes:

• Certifique-se de que o Nome Comum fornecido na solicitação de certificado corresponda ao nome de host desejado em sua URL pública - por exemplo, tfs.contoso.com.
• Nas Propriedades do Provedor de Serviços de Criptografia, recomendamos selecionar Microsoft RSA SChannel Cryptographic Provider e um comprimento de bit igual ou superior a 2048.

Alterar o URL público

Também deve ser observado 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 ligações HTTP para HTTPS, as conexões de cliente do Visual Studio precisarão ser restabelecidas, os marcadores antigos não serão mais resolvidos corretamente e assim por diante. Portanto, é importante coordenar esse tipo de alteração com os usuários da implantação do Azure DevOps Server para evitar interrupções significativas.