Configuración y seguridad del sitio web Azure DevOps local

  • Artículo
  • Tiempo de lectura: 3 minutos

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 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 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 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 utilicen otras soluciones como IPSec. Por lo tanto, pueden ser vulnerables a 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 instancias. 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, decidimos que había llegado el momento de 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 de configuración de sitio web en todos los escenarios de configuración de 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 configuración.

Grupo de configuración predeterminado

El grupo de configuración Predeterminado 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 y HTTP con grupo de configuración de redireccionamiento.

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 ningún nombre de host especificado. 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 de 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 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 son:

  • Permitir que el Asistente para configuración de TFS genere certificados autofirmados para que los use 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.

Errores de certificado en 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 en el servidor y lo usa 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 las máquinas 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.
  • Use el cmdlet export-Certificate de PowerShell, disponible en Windows 8 o Windows Server 2012 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, 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 Las 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, cambiar 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.