Compartir a través de

Seguridad

  • Artículo

Los túneles de desarrollo son un servicio de tunelización para desarrolladores centrado en la seguridad. En este artículo, obtenga información sobre cómo tuneles dev están protegidos.

Información general

De forma predeterminada, el hospedaje y la conexión a un túnel requieren autenticación con la misma cuenta de Microsoft, Microsoft Entra ID o GitHub que creó el túnel. La tunelización requiere que se realicen conexiones salientes al servicio hospedado en Azure. No se requiere ninguna conexión entrante para usar el servicio.

Dominios

El acceso a tuneles dev se puede controlar al permitir o denegar el acceso saliente a los dominios siguientes:

  • Autenticación

    • github.com
    • login.microsoftonline.com

  • Túneles de desarrollo

    • global.rel.tunnels.api.visualstudio.com
    • [clusterId].rel.tunnels.api.visualstudio.com
    • [clusterId]-data.rel.tunnels.api.visualstudio.com
    • *.[clusterId].devtunnels.ms
    • *.devtunnels.ms

La lista de valores actuales [clusterId] está disponible en https://global.rel.tunnels.api.visualstudio.com/api/v1/clusters.

Reenvío web

Se puede acceder directamente a los puertos de túnel que usan los protocolos HTTP(S)/WS(S) a través de la dirección URL de reenvío web proporcionada (por ejemplo: https://tunnelid-3000.devtunnels.ms).

  • Las conexiones de cliente no seguras siempre se actualizan automáticamente a HTTPS/WSS.
  • La seguridad de transporte estricta HTTP (HSTS) está habilitada con una antigüedad máxima de un año.
  • La versión mínima de TLS que admite el servicio es la 1.2, y TLS 1.3 es la versión preferida.
  • La terminación TLS se realiza en la entrada de servicio mediante certificados de servicio emitidos por una ENTIDAD de certificación de Microsoft.
    • Después de la terminación TLS, se realiza la reescritura de encabezados. Esto es necesario para muchos escenarios de desarrollo de aplicaciones web.

Protección contra suplantación de identidad (phishing)

Al conectarse a una dirección URL de reenvío web por primera vez, se presenta a los usuarios una página anti-phishing intersticial. La página se omite en las siguientes circunstancias:

  • La solicitud usa un método distinto de GET
  • El encabezado de solicitud Accept no contiene text/html
  • La solicitud contiene el X-Tunnel-Skip-AntiPhishing-Page encabezado
  • La solicitud contiene el X-Tunnel-Authorization encabezado
  • El usuario ya ha visitado la página y ha hecho clic en Continuar.

Acceso de túnel

De forma predeterminada, los túneles y los puertos de túnel son privados y solo son accesibles para el usuario que creó el túnel.

Si es necesario tener acceso a un túnel o un puerto de túnel sin autenticación, se puede agregar una entrada de control de acceso (ACE) de allow-anonymous (use --allow-anonymous).

El acceso de túnel también se puede ampliar al inquilino actual de Microsoft Entra (use --tenant) o a organizaciones específicas de GitHub (use --organization); para este último consulte Acceso a la organización de GitHub a continuación.

La CLI también se puede usar para solicitar tokens de acceso que concedan acceso limitado a cualquier persona que contenga el token (use devtunnel token). Se trata de una característica avanzada, pero puede ser útil en situaciones específicas.

Actualmente, hay disponibles cuatro tipos de tokens de acceso de túnel:

  • Un "token de acceso de cliente" permite al portador conectarse a cualquier puerto del túnel.
  • Un "token de acceso de host" permite al portador hospedar el túnel y aceptar conexiones, pero no realizar ningún otro cambio en él.
  • Un "token de administración de puertos de acceso" permite al portador agregar y eliminar puertos en un túnel.
  • Un "token de acceso de administración" permite al portador realizar cualquier operación en ese túnel, incluida la configuración de controles de acceso, hospedaje, conexión y eliminación del túnel.

Todos los tokens están limitados al túnel actual; no conceden acceso a ninguno de los otros túneles del usuario actual, si los hay. Los tokens expiran después de un tiempo (actualmente 24 horas). Los tokens solo se pueden actualizar mediante una identidad de usuario real que tenga acceso de ámbito de administración al túnel (no solo un token de acceso de administración).

La mayoría de los comandos de la CLI pueden aceptar un --access-token argumento con un token adecuado como alternativa al inicio de sesión.

Los clientes web pueden pasar un token en un encabezado para autorizar solicitudes a un URI de túnel:

X-Tunnel-Authorization: tunnel <TOKEN>

Sugerencia

Esto resulta útil para los clientes no interactivos, ya que les permite acceder a túneles sin necesidad de habilitar el acceso anónimo. Usamos el X-Tunnel-Authorization encabezado en lugar del encabezado estándar Authorization para evitar que interfiera potencialmente con la autorización específica de la aplicación.

Consulte la sección Administrar el acceso al túnel de desarrollo para obtener más información sobre cómo administrar el acceso de túnel a través de la CLI.

Acceso a la organización de GitHub

Para admitir túneles que concedan acceso a todos los miembros de una organización de GitHub, instale la aplicación Dev Tunnels de GitHub en la organización. Esto proporciona permiso al servicio Túneles de desarrollo para comprobar el estado de pertenencia de los usuarios en esa organización. (Los túneles de desarrollo no requieren permisos de repositorio para la organización). Es posible que deba ser administrador de la organización de GitHub para realizar esta operación.

Preguntas adicionales

Si después de revisar esta página, tiene más preguntas, consulte Comentarios y soporte técnico.