Características de seguridad de Live Share

Las sesiones de colaboración en Visual Studio Live Share son potentes en el sentido de que permiten a cualquier número de personas unirse a una sesión y editar, depurar y mucho más en colaboración. Sin embargo, dado este nivel de acceso, sin duda te interesarán las funciones de seguridad que proporciona Live Share. En este artículo, le proporcionaremos algunas recomendaciones y opciones para proteger su entorno según sea necesario.

Como con cualquier herramienta de colaboración, recuerde que solo debe compartir su código, contenido y aplicaciones con personas en las que confíe.

Conectividad

Al iniciar una sesión entre pares, Live Share intenta establecer una conexión de igual a igual, y solo si esto no es posible (por ejemplo, debido a cortafuegos/NAT), recurre al uso de una retransmisión en la nube. Sin embargo, en ambos tipos de conexión (P2P o relé), todos los datos transmitidos entre pares se cifran de extremo a extremo mediante el protocolo SSH. En el caso de una conexión de retransmisión, el cifrado SSH se superpone a los WebSockets cifrados TLS. Esto significa que Live Share no depende del servicio de retransmisión en la nube para la seguridad. Incluso si la retransmisión se viera comprometida, no podría descifrar ninguna de las comunicaciones de Live Share.

El papel del servicio Live Share se limita a la autenticación de usuarios y al descubrimiento de sesiones. El servicio en sí no almacena ni tiene acceso al contenido de una sesión. Todo el contenido del usuario en Live Share se transmite a través de la sesión SSH. Eso incluye código, terminales, servidores compartidos y cualquier otra característica de colaboración proporcionada por Live Share o extensiones que se basen en él.

Para obtener más información sobre cómo modificar estos comportamientos y los requisitos de conectividad de Live Share, consulte Requisitos de conectividad para Live Share.

Cifrado de cables

El protocolo SSH utiliza un intercambio de claves Diffie-Hellman para establecer un secreto compartido para la sesión, y deriva de él una clave para el cifrado simétrico AES. La clave de cifrado se rota periódicamente durante toda la sesión. El secreto de sesión compartido y todas las claves de cifrado solo se mantienen en memoria por ambas partes, y solo son válidos mientras dura la sesión. Nunca se escriben en el disco ni se envían a ningún servicio (incluido Live Share).

Autenticación de pares

La sesión SSH también se autentica en dos sentidos. El host (rol de servidor SSH) utiliza autenticación de clave pública/privada como es estándar para el protocolo SSH. Cuando un host comparte una sesión Live Share, genera un par de claves públicas/privadas RSA único para la sesión. La clave privada del host solo se guarda en la memoria del proceso del host; nunca se escribe en el disco ni se envía a ningún servicio, incluido el servicio Live Share. La clave pública del host se publica en el servicio Live Share junto con la información de conexión de la sesión (dirección IP y/o punto final de retransmisión), donde los invitados pueden acceder a ella a través del enlace de invitación. Cuando un invitado se conecta a la sesión SSH del host, el invitado utiliza el protocolo de autenticación de host SSH para validar que el host posee la clave privada correspondiente a la clave pública publicada (sin que el invitado llegue a ver realmente la clave privada).

El invitado utiliza un token Live Share para autenticarse con el host. El token es un JWT firmado emitido por el servicio Live Share que incluye afirmaciones sobre la identidad del usuario (obtenida mediante MSA, AAD o inicio de sesión en GitHub). El token también contiene afirmaciones que indican que el invitado tiene permiso para acceder a esa sesión específica de Live Share (porque tenían el enlace de invitación y/o fueron invitados específicamente por el host). El host valida ese token y comprueba las afirmaciones (y, dependiendo de las opciones, puede preguntar al usuario host) antes de permitir que el invitado se una a la sesión.

Invitaciones y acceso a la sesión

Cada vez que se inicia una nueva sesión de colaboración, Live Share genera un nuevo identificador único que se coloca en el enlace de invitación. Estos enlaces proporcionan una base sólida y segura para invitar a personas de confianza, ya que el identificador del enlace es "no adivinable" y solo es válido durante una única sesión de colaboración.

Eliminar a un invitado inesperado

Como host, se le notifica automáticamente cada vez que un invitado se une a la sesión de colaboración.

En Visual Studio Code:

En Visual Studio:

Mejor aún, la notificación le ofrece la posibilidad de eliminar a un invitado que se haya unido si por alguna razón no lo conoce. (Por ejemplo, si has publicado accidentalmente tu enlace en un sistema de chat de toda la empresa y se ha unido un empleado cualquiera). Simplemente haga clic en el botón "Eliminar" de la notificación que aparece y será expulsado de la sesión de colaboración.

En VS Code, incluso si ha descartado una notificación de unión, también tiene la posibilidad de eliminar a un participante después de eso. Al abrir la vista Live Share en el Explorer o la pestaña personalizada en la barra de actividades de VS Code, puede pasar el ratón por encima o hacer clic con el botón derecho en el nombre de un participante y seleccionar el icono o la opción "Eliminar participante".

Requerir la aprobación de un invitado

Normalmente, los participantes que se unen a una sesión de colaboración inician sesión en Live Share mediante una cuenta de trabajo o escolar de Microsoft (AAD), una cuenta personal de Microsoft o una cuenta de GitHub. Aunque la opción predeterminada "notificación + eliminar" para los usuarios que han iniciado sesión proporciona una buena combinación de velocidad y control para estos invitados, es posible que desee bloquear las cosas un poco más si está haciendo algo delicado.

Además, en determinadas circunstancias, puede resultar problemático obligar a todos los invitados a iniciar sesión para unirse a una sesión de colaboración. Algunos ejemplos incluyen pedir a alguien nuevo en Live Share que se una como invitado, escenarios de aula/aprendizaje, o cuando se colabora con alguien que no tiene uno de los tipos de cuenta soportados. Por estas razones, Live Share puede permitir que los usuarios que no hayan iniciado sesión se unan a las sesiones de colaboración como invitados de solo lectura. Aunque el host debe aprobar a estos invitados antes de que puedan unirse de forma predeterminada, es posible que desee no permitir a estos invitados "anónimos" o aprobarlos siempre en su lugar.

Requerir la aprobación de invitados para usuarios que han iniciado sesión

Si desea evitar que los invitados registrados se unan a sus sesiones de colaboración hasta que usted los haya "aprobado", cambie la siguiente configuración:

• En VS Code, añada lo siguiente a settings.json (Archivo > Preferencias > Configuración):

  "liveshare.guestApprovalRequired": true
  

• En Visual Studio, establezca Herramientas > Opciones > Live Share > "Requerir aprobación de invitados" en Verdadero.

  

A partir de este momento, se le pedirá que apruebe a cada invitado que se una.

En Visual Studio Code:

En Visual Studio:

Como invitado, si se une a una sesión en la que el host tiene activada esta opción, se le notificará en la barra de estado o en el cuadro de diálogo de acceso que Live Share está esperando la aprobación del host.

Rechazar o aceptar automáticamente usuarios que no han iniciado sesión (anónimos)

Como se ha descrito anteriormente, Live Share puede configurarse para permitir que los usuarios que no hayan iniciado sesión se unan a una sesión de colaboración como invitados de solo lectura. Aunque estos invitados "anónimos" deben introducir un nombre al entrar, un simple nombre no proporciona el mismo nivel de seguridad que un inicio de sesión real. Por lo tanto, por defecto, se pide al host que apruebe a cualquier invitado anónimo independientemente de la configuración de "requerir aprobación del invitado" descrita anteriormente.

Puede rechazar siempre (deshabilitar a los invitados anónimos) o aceptar siempre a los usuarios anónimos de la siguiente manera:

• En VS Code, establezca liveshare.anonymousGuestApproval en settings.json (Archivo > Preferencias > Configuración) a accept, reject, o prompt (el valor predeterminado) según corresponda.

• En Visual Studio, establezca Herramientas > Opciones > Live Share > "Aprobación de invitados anónimos" en Aceptar, Rechazar o Preguntar (el valor predeterminado) según corresponda.

En cualquier caso, recuerde que solo debe enviar enlaces de invitación a Live Share a personas en las que confíe.

Permitir el control de comandos a invitados

Para permitir que los invitados ejecuten comandos arbitrarios a través de Code Actions ("Quick Fixes") y CodeLens establezca la siguiente configuración:

• En VS Code, establezca liveshare.languages.allowGuestCommandControl en settings.json (Archivo > Preferencias > Configuración) a true o false (el valor por defecto).

Controlar el acceso a los archivos y su visibilidad

Como invitado, el modelo remoto de Live Share le proporciona un rápido acceso de lectura/escritura a los archivos y carpetas que el host ha compartido con usted sin tener que sincronizar todo el contenido de un proyecto. Por lo tanto, puede navegar y editar archivos de forma independiente en todo el árbol de archivos compartidos. Sin embargo, esta libertad plantea algunos riesgos para el host. En concepto, un desarrollador podría optar por entrar y modificar el código fuente sin tu conocimiento o ver código fuente sensible o "secretos" ubicados en algún lugar del árbol de archivos compartidos. En consecuencia, como host, no siempre querrás que el invitado tenga acceso a la totalidad de un proyecto que estás compartiendo. Afortunadamente, una ventaja añadida de este modelo remoto es que puedes optar por "excluir" los archivos que no quieres compartir con nadie sin sacrificar la funcionalidad. Sus invitados pueden seguir participando en cosas como sesiones de depuración que normalmente requerirían acceso a estos archivos si quisieran hacerlo por su cuenta.

Puede conseguirlo añadiendo un archivo .vsls.json a la carpeta o proyecto que está compartiendo. Cualquier configuración que añada a este archivo con formato json cambia la forma en que Live Share procesa los archivos. Además de proporcionarle un control directo, estos archivos también pueden comprometerse con el control de código fuente para que cualquiera que clone un proyecto pueda aprovechar estas reglas sin ningún esfuerzo adicional por su parte.

Aquí hay un ejemplo de archivo .vsls.json:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none",
    "excludeFiles":[
        "*.p12",
        "*.cer",
        "token",
        ".gitignore"
    ],
    "hideFiles": [
        "bin",
        "obj"
    ]
}

Nota:

También puede hacer que todos los archivos/carpetas que compartas sean de solo lectura cuando inicie una sesión de colaboración. Consulte esta sección más adelante para obtener más información.

Veamos cómo estas propiedades cambian lo que los invitados pueden hacer.

Propiedades

La propiedad excludeFiles le permite especificar una lista de patrones de archivo glob (muy parecidos a los que se encuentran en los archivos .gitignore) que impide que Live Share abra determinados archivos o carpetas para los invitados. Tenga en cuenta que esto incluye escenarios como un invitado siguiendo o saltando a su ubicación de edición, entrando en un archivo durante la depuración colaborativa, cualquier característica de navegación de código como ir a la definición, y más. Está pensado para archivos que no quieres compartir bajo ninguna circunstancia, como los que contienen secretos, certificados o contraseñas. Por ejemplo, ya que controlan la seguridad, los archivos .vsls.json están siempre excluidos.

La propiedad hideFiles es similar, pero no tan estricta. Estos archivos simplemente se ocultan del árbol de archivos. Por ejemplo, si usted entra en uno de estos archivos durante la depuración, todavía se abre en el editor. Esta propiedad es principalmente útil si no tiene un archivo .gitignore configurado (como sería el caso si está utilizando un sistema de control de código fuente diferente) o si simplemente desea aumentar lo que ya está allí para evitar el desorden o la confusión.

La configuración de gitignore establece cómo debe procesar Live Share el contenido de los archivos .gitignore en las carpetas compartidas. Por defecto, cualquier globo encontrado en archivos .gitignore se trata como si se hubiera especificado en la propiedad "hideFiles". Sin embargo, puede elegir un comportamiento diferente utilizando uno de los siguientes valores:

Opción	Resultado
none	Los contenidos de .gitignore son visibles para los invitados en el árbol de archivos (suponiendo que no estén filtrados por una configuración del editor de invitados).
hide	El valor predeterminado. Los globos dentro de .gitignore se procesan como si estuvieran en la propiedad "hideFiles".
exclude	Los globos dentro de .gitignore se procesan como si estuvieran en la propiedad "excludeFiles".

Una desventaja de esta configuración exclude es que los contenidos de carpetas como node_modules están frecuentemente en .gitignore pero pueden ser útiles para entrar durante la depuración. En consecuencia, Live Share soporta la capacidad de invertir una regla usando "!" en la propiedad excludeFiles. Por ejemplo, este archivo .vsls.json excluiría todo en ".gitignore" excepto node_modules:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ]
}

Las reglas de ocultación y exclusión se procesan por separado, por lo que si aún desea ocultar node_modules para reducir el desorden sin excluirlo realmente, puede simplemente editar el archivo de la siguiente manera:

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"exclude",
    "excludeFiles":[
        "!node_modules"
    ],
    "hideFiles":[
        "node_modules"
    ]
}

Archivos .vsls.json en subcarpetas

Por último, al igual que .gitignore, los archivos .vsls.json pueden colocarse en subcarpetas. Las reglas de ocultación/exclusión se determinan comenzando por el archivo .vsls.json de la carpeta raíz que haya compartido (si está presente) y recorriendo a continuación cada una de las subcarpetas que desde allí conducen a un archivo determinado para buscar archivos .vsls.json que procesar. El contenido de los archivos .vsls.json de las carpetas situadas más abajo en el árbol de archivos complementa (o anula) las reglas establecidas en los niveles superiores.

Nota: no es posible volver a incluir (¡!) un archivo si un directorio padre de ese archivo está excluido. Al igual que con .gitignore, al volver a incluir un archivo, también tendrá que volver a incluir todos los directorios padre del archivo.

Desactivar la compartición de archivos externos

Por defecto, Live Share también compartirá cualquier archivo que el host abra y que sea externo a la carpeta / solución compartida. Esto facilita la apertura rápida de otros archivos relacionados sin tener que volver a compartirlos.

Si prefiere desactivar esta función:

• En VS Code, añada lo siguiente a settings.json:

  "liveshare.shareExternalFiles": false
  

• En Visual Studio, establezca Herramientas > Opciones > Live Share > "Compartir archivos externos" en False.

Modo de solo lectura

A veces, cuando comparte su código como host, no quiere que sus invitados hagan ediciones. Puede que necesite que su invitado eche un vistazo a parte de su código, o que esté mostrando su proyecto a un gran número de invitados y no quiera que se realicen ediciones innecesarias o accidentales. Live Share ofrece la posibilidad de compartir proyectos en modo de solo lectura.

Como host, al compartir, tiene la opción de habilitar el modo de solo lectura para una sesión de colaboración. Cuando un invitado se une, no podrá realizar ediciones en el código, aunque podrá ver los cursores y resaltados del otro, así como navegar por el proyecto.

Aún puede co-depurar con invitados mientras esté en modo de solo lectura. Los invitados no podrán avanzar en el proceso de depuración, pero podrán añadir o eliminar puntos de interrupción e inspeccionar variables. Además, aún puede compartir servidores y terminales (solo lectura) con invitados.

Puede obtener más información sobre cómo iniciar una sesión de colaboración de solo lectura:

Depuración conjunta

Cuando se enfrente a problemas o errores de codificación difíciles, contar con un par de ojos adicionales para depurar puede ser realmente útil. Visual Studio Live Share permite la "depuración colaborativa" o "co-depuración" compartiendo la sesión de depuración con todos los invitados cada vez que el host inicia la depuración.

Como host, tienes el control total sobre cuándo se inicia o detiene una sesión de depuración, pero la co-depuración plantea algunos riesgos si la comparte con alguien en quien no confía. Live Share permite a los invitados ejecutar comandos de consola/REPL, por lo que existe el riesgo de que un actor malintencionado ejecute un comando que usted no desea que ejecute.

Por lo tanto, solo debería co-depurar con aquellas personas en las que confíe.

Más información:

Compartir un servidor local

Al depurar conjuntamente, puede ser muy útil obtener acceso a diferentes partes de la aplicación ofrecidas por el anfitrión para la sesión de depuración. Puede que quiera acceder a la aplicación en un explorador, acceder a una base de datos local o alcanzar un punto de conexión REST desde sus herramientas. Live Share le permite "compartir un servidor" que asigna un puerto local en la máquina del host al mismo puerto exacto en la máquina del invitado. Como invitado, puede interactuar con la aplicación exactamente como si se estuviera ejecutando localmente en su equipo (por ejemplo, tanto el host como el invitado pueden acceder a una aplicación web que se ejecuta en el servidor del invitado http://localhost:3000).

Sin embargo, como host, debe ser muy selectivo con los puertos que comparte con los invitados y solo compartir puertos de aplicación en lugar de puertos de sistema. En el caso de los invitados, los puertos compartidos se comportarán exactamente igual que si el servidor o servicio se estuviese ejecutando en su propia máquina. Esto es muy útil, pero podría ser también arriesgado si es que se comparte el puerto incorrecto. Por esta razón, Live Share no hace ninguna suposición sobre lo que debería o no debería compartirse sin un ajuste de configuración y sin que el host realice una acción.

En Visual Studio, el puerto de aplicación web especificado en los proyectos ASP.NET se comparte automáticamente durante la depuración solo para facilitar el acceso de invitados a la aplicación web cuando está en ejecución. Sin embargo, si lo prefiere, puede desactivar esta automatización configurando Herramientas > Opciones > Live Share > "Compartir aplicación web en depuración" en "False".

En Visual Studio Code, Live Share intenta detectar los puertos de aplicación adecuados y compartirlos. Sin embargo, puede desactivar esto añadiendo lo siguiente a settings.json:

"liveshare.autoShareServers": false

En cualquier caso, tenga cuidado al compartir puertos adicionales.

Puede obtener más información sobre la configuración de esta función aquí:

Compartir un terminal

El desarrollo moderno hace un uso frecuente de una amplia gama de herramientas de línea de comandos. Afortunadamente, como anfitrión, Live Share le permite, de forma opcional, "compartir un terminal" con los invitados. El terminal compartido puede ser de solo lectura o totalmente colaborativo, para que tanto usted como los invitados puedan ejecutar comandos y ver los resultados. Como host, puedes permitir que otros colaboradores vean la salida o utilicen cualquier herramienta de línea de comandos para ejecutar pruebas, construcciones o incluso solucionar problemas específicos del entorno.

Solo los hosts pueden iniciar terminales compartidas para evitar que los invitados inicien una y hagan algo que usted no espera o no está viendo. Cuando inicia un terminal compartido como host, puede especificar si debe ser de solo lectura o de lectura/escritura. Si el terminal es de lectura/escritura, todos los participantes pueden escribir en el terminal, incluido el anfitrión, lo que permite intervenir fácilmente si un invitado hace algo que no le gusta. Sin embargo, para estar seguros, debería darle acceso de lectura/escritura a los invitados solo cuando sabe que realmente lo necesitan y limitarse a los terminales de solo lectura en escenarios donde quiere que un invitado solo vea la salida de los comandos que ejecuta.

En Visual Studio, los terminales no se comparten por defecto. En VS Code, los terminales se comparten automáticamente como solo lectura por defecto. Sin embargo, puede desactivar esto añadiendo lo siguiente a settings.json:

"liveshare.autoShareTerminals": false

Más información:

Consentimiento del administrador de AAD

Al iniciar sesión utilizando una dirección de correo electrónico profesional o educativa respaldada por Microsoft, es posible que aparezca un mensaje que dice "Necesita aprobación del administrador" al iniciar sesión. Esto se debe a que Live Share requiere acceso de lectura a la información del usuario para sus funciones de seguridad y su inquilino de Azure AD está configurado para requerir el "consentimiento del administrador" para que las nuevas aplicaciones accedan al contenido del directorio.

Su administrador de AD tendría que resolver esto para usted utilizando la siguiente información:

• Nombre de la aplicación: Visual Studio Live Share (Insiders)
• Tipo de aplicación: Web App
• Estado de la aplicación: Producción
• Permisos delegados: User.Read
• URL de la aplicación: https://visualstudio.microsoft.com/services/live-share/
• URL de respuesta: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Esto solo tendría que hacerse una vez para cualquiera que utilice Live Share. Consulte aquí y aquí para más detalles.

Consulte también

• Instalación e inicio de sesión en Live Share en Visual Studio Code
• Instalación e inicio de sesión en Live Share en Visual Studio
• Requisitos de conectividad de Live Share

¿Tiene algún problema? Consulte la solución de problemas o envíe sus comentarios.