Configuración y seguridad del sitio web Azure DevOps local

TFS 2017 | TFS 2015 | TFS 2013

Segundo plano

En 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 Azure DevOps Server web en el puerto 8080, sin nombre de host ni dirección IP especificados.
  • Una dirección URL pública (anteriormente denominada dirección URL de notificación) con el formato http://machine-name:8080/tfs .

La principal ventaja de esta configuración es que son muy fáciles de configurar y cómodas 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 host de Azure DevOps Server y otros sitios web en el mismo puerto en el mismo servidor.
  • El uso del nombre de la máquina, en lugar del nombre de dominio completo (FQDN), en la dirección URL pública ahorra mucho escribir.
  • Dejar el nombre de host en el enlace sin especificar permite flexibilidad en la conexión: el nombre de equipo, 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 utilicen otras soluciones como IPSec. Por lo tanto, son potencialmente vulnerables a los actores malintencionados que supervisan o incluso modifican el contenido de la comunicación. Estos problemas se mitigan hasta cierto punto cuando Azure DevOps Server se implementa en una intranet detrás de un firewall corporativo, como la gran mayoría de Azure DevOps Server de datos. Pero incluso en estos escenarios, los datos enviados a 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 una seguridad adicional.

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

Dado todo esto, hemos decidido que ha llegado el momento de defender con más fuerza el uso de enlaces HTTPS en Azure DevOps Server implementaciones.

Configuración de grupos

TFS 2017 presenta opciones de configuración de configuración de 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 se recomiendan y creemos que se usarán con más frecuencia. En escenarios en los que ninguno de estos grupos de configuración es adecuado, la configuración se puede personalizar completamente mediante el cuadro de diálogo Editar configuración del sitio.

Default setting group

El grupo configuración predeterminada incluye la misma configuración usada en versiones anteriores de Azure DevOps Server. Por todos los motivos mencionados anteriormente, esta configuración sigue siendo la predeterminada para las Azure DevOps Server nuevas. En el caso de las implementaciones existentes, intentaremos conservar la configuración existente, lo que a menudo dará lugar a la selección del grupo de configuración Predeterminado.

HTTPS and HTTP with redirect setting group

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

  • Un enlace HTTPS en el puerto 443, con el nombre de dominio completo (FQDN) de la máquina 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 por comodidad para los usuarios finales: se configura una redirección 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 grupo de configuración solo 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 y los certificados autofirmados se https://fully-qualified-domain-name 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 el uso de una dirección URL pública HTTP. La mayoría de los exploradores modernos considerarán que el contenido HTTP y HTTPS mixto no es seguro de forma predeterminada y puede mostrar páginas vacías. Aunque normalmente es posible invalidar la configuración predeterminada del explorador y permitir contenido no seguro, esto dará lugar a 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 relacionada 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 trataremos 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 en torno a 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 ser hablar con un grupo de tecnologías de la información de nivel de organización.

Las opciones incluyen:

  • Permitir que el Asistente para configuración de TFS genere certificados autofirmados para su uso en 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 adecuadas para las implementaciones de producción de Azure DevOps Server y no se recomienda que se utilicen 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 sus certificados raíz estén instalados en cada equipo cliente. Por ejemplo, el explorador Edge mostrará el siguiente error.

Certificate errors in Edge

Cuando el Asistente para 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 otro, firmado por el primero, que se coloca en el almacén personal del servidor y que Azure DevOps Server. La configuración 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 mostrado anteriormente.

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

  • Usar el complemento MMC Certificados para exportar manualmente el certificado en el servidor y, a continuación, importarlo en cada cliente.
  • Mediante el cmdlet export-certificate de PowerShell, disponible en Windows 8 o Windows Server 2012 y sistemas operativos posteriores, para exportar el certificado. Import-Certificate se puede usar para importarlo en cada cliente.
  • Usar directiva de grupo para automatizar la distribución a los clientes.

Entidad de certificación interna y externa

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 los equipos 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, esta puede ser una buena opción para su Azure DevOps Server implementación.

Cuando otras opciones no son adecuadas o están disponibles, se pueden obtener certificados (normalmente a un costo) de una entidad de certificación (CA) externa. Las instrucciones para este proceso, que comienza con la creación de una solicitud de firmade 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 Propiedades del proveedor de servicios criptográficos, se recomienda seleccionar Proveedor criptográfico SChannel rsa de Microsoft 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 Azure DevOps Server existente, el cambio de la dirección URL pública afectará a los usuarios finales. Aunque todavía se recomienda convertir enlaces HTTP Visual Studio HTTPS, es necesario volver Visual Studio establecer las conexiones de cliente, 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 Azure DevOps Server implementación para evitar interrupciones significativas.