Configuración y seguridad del sitio web para Azure DevOps local

TFS 2017 | TFS 2015 | TFS 2013

Información previa

Para muchas versiones, la configuración predeterminada del sitio web para Azure DevOps Server, anteriormente denominada Team Foundation Server (TFS), ha sido:

• Un único enlace HTTP para el sitio web de Azure DevOps Server en el puerto 8080, sin especificar ningún nombre de host ni dirección IP.
• Una dirección URL pública (anteriormente denominada dirección URL de notificación) del formulario http://machine-name:8080/tfs.

La principal ventaja de esta configuración es que son muy fáciles de configurar y conveniente para los usuarios finales en la mayoría de los escenarios. En concreto:

• El uso de HTTP en lugar de HTTPS evita la necesidad de obtener e instalar certificados.
• El uso de 8080 en lugar de 80 evita posibles conflictos con otros sitios en la misma máquina.
• El uso de "tfs" como directorio virtual para el sitio facilita el hospedaje de Azure DevOps Server y otros sitios web en el mismo puerto en el mismo servidor.
• Con el nombre de la máquina, en lugar del nombre de dominio completo (FQDN), en la dirección URL pública se guarda una gran cantidad de escritura.
• Dejar el nombre de host en el enlace sin especificar permite flexibilidad en la conexión: el nombre de la máquina, el FQDN o la dirección IP funcionarán cuando los usuarios intenten conectarse a sus servidores.

Sin embargo, esta configuración no es segura de forma predeterminada. En concreto, al no usar un enlace HTTPS, la comunicación hacia y desde Azure DevOps Server no se cifra en tránsito a menos que se usen otras soluciones como IPSec. Por lo tanto, son potencialmente vulnerables a la supervisión de actores malintencionados o incluso modifican el contenido de la comunicación. Estos problemas se mitigan en cierta medida cuando Azure DevOps Server se implementan en una intranet detrás de un firewall corporativo, ya que la gran mayoría de las instancias de Azure DevOps Server son. Pero incluso en estos escenarios, los datos enviados hacia y desde Azure DevOps Server incluyen código fuente, datos de elementos de trabajo y otra información que a menudo podría beneficiarse de la seguridad adicional.

Además, en TFS 2017 existen nuevos escenarios de autenticación (autenticación de cuenta de servicio del agente de compilación o versión, tokens de acceso personal) que envían tokens de portador a través de la conexión. Si estos tokens se obtienen mediante usuarios malintencionados, se pueden usar para suplantar a los usuarios a los que pertenecen.

Dado todo esto, decidimos que el tiempo había llegado para defender más fuertemente el uso de enlaces HTTPS en Azure DevOps Server implementaciones.

Configuración de grupos

TFS 2017 presenta opciones de configuración del sitio web en todos los escenarios de configuración del servidor. Se proporcionan varios grupos de configuración, que agrupan combinaciones de enlaces de sitio, directorios virtuales y direcciones URL públicas que recomendamos y creemos que se usarán con más frecuencia. En escenarios en los que ninguno de estos grupos de configuración sea adecuado, la configuración se puede personalizar completamente mediante el cuadro de diálogo Editar configuración del sitio.

El grupo De configuración predeterminado incluye la misma configuración que se usó en versiones anteriores de Azure DevOps Server. Por todas las razones enumeradas anteriormente, esta configuración sigue siendo la predeterminada para las nuevas implementaciones de Azure DevOps Server. En el caso de las implementaciones existentes, intentaremos conservar la configuración existente, lo que a menudo provocará que se seleccione el grupo de configuración predeterminado.

El grupo de configuración HTTPS y HTTP (con redirección) aprovisiona dos enlaces:

• Un enlace HTTPS en el puerto 443, con el nombre de dominio completo (FQDN) del equipo como nombre de host.
• Un enlace HTTP en el puerto 80, de nuevo con el FQDN de la máquina como nombre de host.

El enlace HTTP en el puerto 80 solo se agrega como comodidad para los usuarios finales: se configura un redireccionamiento para que todo el tráfico termine usando el enlace HTTPS en el puerto 443. La dirección URL pública de este grupo de configuración tiene el formato https://fully-qualified-domain-name. De forma predeterminada, este grupo de configuración aprovisionará nuevos certificados autofirmados y los usará para el enlace HTTPS. Normalmente no se recomienda usar certificados autofirmados para implementaciones de TFS de producción. Consulte Opciones de certificado a continuación para obtener más información sobre cuándo es adecuado usar certificados autofirmados y qué otras opciones están disponibles.

El único grupo de configuración https aprovisiona un único enlace HTTPS en el puerto 443, con el FQDN de la máquina como nombre de host. De nuevo, la dirección URL pública de este grupo de configuración tiene el formato https://fully-qualified-domain-namey los certificados autofirmados se aprovisionarán de forma predeterminada.

El grupo de configuración Solo HTTP aprovisiona un único enlace HTTP en el puerto 80 sin especificar ningún nombre de host. La dirección URL pública de este grupo de configuración tiene el formato http://machine-name.

Cuando se usa el grupo de configuración HTTPS y HTTP (con redireccionamiento), no se recomienda usar una dirección URL pública HTTP. La mayoría de los exploradores modernos considerarán el contenido HTTP y HTTPS mixto no seguro de forma predeterminada y pueden mostrar páginas vacías. Aunque normalmente es posible invalidar la configuración predeterminada del explorador y permitir contenido no seguro, esto dará como resultado una experiencia similar a la exploración de un sitio con un certificado SSL expirado.

Opciones de certificado

La implementación de sitios web mediante enlaces HTTPS y cifrado SSL/TLS está estrechamente relacionado con el tema más amplio de la infraestructura de clave pública (PKI), que es un tema enriquecido e interesante para el que ya existe una amplia variedad de documentación. Aquí no intentaremos cubrir toda la complejidad, sino que nos centraremos en opciones de alto nivel para configurar enlaces HTTPS para Azure DevOps Server implementaciones. Muchas organizaciones tienen directivas específicas sobre la implementación de certificados, por lo que el primer paso para decidir qué certificado usar para una implementación de Azure DevOps Server suele hablar con un grupo de tecnología de información de nivel de organización.

Las opciones son:

• Permitir que el Asistente para configuración de TFS genere certificados autofirmados para su uso por parte de la implementación.
• Obtener un certificado de una entidad de certificación interna.
• Obtener un certificado de una entidad de certificación externa.

Certificados autofirmados

Los certificados autofirmados son útiles para las implementaciones de prueba de Azure DevOps Server, ya que son muy fáciles de aprovisionar y usar. Son menos adecuados para las implementaciones de producción de Azure DevOps Server y no se recomienda que se usen para Azure DevOps Server implementaciones expuestas a la red pública de Internet. Por lo general, los certificados autofirmados son susceptibles a ataques de tipo "man in the middle". También provocan problemas para los usuarios, ya que provocarán advertencias y errores de certificado hasta que se instalen sus certificados raíz en cada equipo cliente. Por ejemplo, el explorador Edge mostrará el siguiente error.

Cuando el Asistente para la configuración de TFS genera certificados autofirmados para la implementación, creará dos: uno que se coloca en el almacén de entidades de certificación raíz de confianza en el servidor y un segundo, firmado por el primero, que se coloca en el almacén Personal en el servidor y lo usa Azure DevOps Server. La configuración de las cosas de esta manera ayuda a mitigar la posibilidad de ataques de tipo "man in the middle" y permite la rotación del certificado usado en el enlace HTTPS sin necesidad de distribuir un nuevo certificado a todos los clientes para evitar errores de certificado como el que se muestra anteriormente.

Para evitar esas advertencias y errores de certificado, puede exportar el certificado raíz e instalarlo en máquinas cliente. Hay varias maneras de lograrlo, entre las que se incluyen:

• Con el complemento MMC Certificados para exportar manualmente el certificado en el servidor y, a continuación, importarlo en cada cliente.
• Con el cmdlet de PowerShell Export-Certificate, disponible en Windows 8/Windows Server 2012 y sistemas operativos posteriores, para exportar el certificado. Después, import-Certificate se puede usar para importarlo en cada cliente.
• Usar directiva de grupo para automatizar la distribución a los clientes.

Entidades de certificación internas y externas

Muchas organizaciones grandes tienen su propia infraestructura de clave pública y pueden emitir certificados de sus propias entidades de certificación. Normalmente, cuando este es el caso, los certificados raíz de confianza para estas entidades ya se distribuirán a las máquinas cliente, lo que evita la necesidad de distribuir certificados adicionales para Azure DevOps Server. Si su organización tiene su propia infraestructura de clave pública, puede ser una buena opción para la implementación de Azure DevOps Server.

Cuando otras opciones no son adecuadas o disponibles, los certificados se pueden obtener (normalmente a un costo) de una entidad de certificación (CA) externa. Las instrucciones para este proceso, que comienzan con la creación de una solicitud de firma de certificado, se pueden encontrar en la mayoría de los sitios web de CA. Algunas notas importantes:

• Asegúrese de que el nombre común proporcionado en la solicitud de certificado coincide con el nombre de host que desea en la dirección URL pública, por ejemplo, tfs.contoso.com.
• En las propiedades del proveedor de servicios criptográficos, se recomienda seleccionar Proveedor criptográfico SChannel de Microsoft RSA y una longitud de bits de 2048 o superior.

Cambio de la dirección URL pública

También debe tenerse en cuenta que al actualizar una implementación de Azure DevOps Server existente, cambiar la dirección URL pública afectará a los usuarios finales. Aunque todavía se recomienda convertir de enlaces HTTP a HTTPS, las conexiones de cliente de Visual Studio deberán volver a establecerse, los marcadores antiguos ya no se resolverán correctamente, etc. Por lo tanto, es importante coordinar este tipo de cambio con los usuarios de la implementación de Azure DevOps Server para evitar interrupciones significativas.