Características de seguridad de Live Share

Las sesiones de colaboración en Visual Studio Live Share son eficaces en que permiten que cualquier número de personas se unan a una sesión y editen, depuren y mucho más. Sin embargo, dado este nivel de acceso, sin duda estará interesado en las características de seguridad que proporciona Live Share. En este artículo, proporcionaremos algunas recomendaciones y opciones para proteger el entorno según sea necesario.

Al igual que con cualquier herramienta de colaboración, recuerde que solo debe compartir el código, el contenido y las aplicaciones con personas de confianza.

Conectividad

Al iniciar una sesión entre elementos del mismo nivel, Live Share intenta establecer una conexión punto a punto y solo si no es posible (por ejemplo, debido a firewalls o NAT), vuelve a usar una retransmisión en la nube. Sin embargo, en ambos tipos de conexión (P2P o retransmisión), todos los datos transmitidos entre pares están cifrados de un extremo a otro mediante el protocolo SSH. En el caso de una conexión de retransmisión, el cifrado SSH se superpone a WebSockets cifrados por TLS. Esto significa que Live Share no depende del servicio de retransmisión en la nube para la seguridad. Incluso si la retransmisión estaba en peligro, no pudo descifrar ninguna de las comunicaciones de Live Share.

El rol del servicio Live Share se limita a la autenticación de usuario y la detección de sesión. El propio servicio no almacena ni nunca tiene acceso a ninguno de los contenidos de una sesión. Todo el contenido del usuario en Live Share se transmite a través de la sesión SSH. Esto incluye código, terminales, servidores compartidos y cualquier otra característica de colaboración proporcionada por Live Share o extensiones que se basan 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 conexión

El protocolo SSH usa un intercambio de claves Diffie-Hellman para establecer un secreto compartido para la sesión y deriva de esa clave para el cifrado simétrico AES. La clave de cifrado se gira periódicamente a lo largo de la duración de la sesión. El secreto de sesión compartido y todas las claves de cifrado solo se mantienen en memoria por ambos lados y solo son válidos durante la sesión. Nunca se escriben en disco ni se envían a ningún servicio (incluido Live Share).

Autenticación del mismo nivel

La sesión SSH también está autenticada bidireccionalmente. El host (rol de servidor SSH) usa la autenticación de clave pública y privada, tal como es estándar para el protocolo SSH. Cuando un host comparte una sesión de Live Share, genera un par de claves pública y privada RSA único para la sesión. La clave privada del host solo se mantiene en memoria en el proceso de 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 sesión (dirección IP o punto de conexión de retransmisión) donde los invitados pueden acceder a él a través del vínculo de invitación. Cuando un invitado se conecta a la sesión SSH del host, el invitado usa el protocolo de autenticación de host SSH para validar que el host contiene la clave privada correspondiente a la clave pública publicada (sin que el invitado obtenga realmente la clave privada).

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

Invitaciones y acceso de unión

Cada vez que inicie una nueva sesión de colaboración, Live Share genera un nuevo identificador único que se coloca en el vínculo de invitación. Estos vínculos proporcionan una base sólida y segura para invitar a los que confía, ya que el identificador del vínculo es "no adivinable" y solo es válido durante una sola sesión de colaboración.

Eliminación de 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 quitar un invitado que se haya unido si por algún motivo no los conoce. (Por ejemplo, si ha publicado accidentalmente su vínculo en un sistema de chat de toda la empresa y un empleado aleatorio unido). Simplemente haga clic en el botón "Quitar" de la notificación que aparece y se expulsará de la sesión de colaboración.

En VS Code, incluso si ha descartado una notificación de unión, también tiene la capacidad de quitar un participante después de eso. Al abrir la vista Live Share en el Explorador o en la pestaña personalizada de la barra de actividades de VS Code, puede mantener el puntero sobre o hacer clic con el botón derecho en el nombre de un participante y seleccionar el icono o opción "Quitar participante".

Requerir aprobación de invitado

Normalmente, los participantes que se unen a una sesión de colaboración se iniciarán en Live Share mediante una cuenta profesional o educativa de Microsoft (AAD), una cuenta microsoft personal o una cuenta de GitHub. Aunque el valor predeterminado "notification + remove" 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 confidencial.

Además, en determinadas circunstancias, forzar a todos los invitados a iniciar sesión para unirse a una sesión de colaboración puede ser problemático. Algunos ejemplos incluyen pedir a alguien nuevo a Live Share que se una como invitado, escenarios de aula o aprendizaje, o cuando colabore con alguien que no tenga uno de los tipos de cuenta admitidos. Por estos motivos, 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 anfitrión debe aprobar estos invitados para poder unirse de forma predeterminada, es posible que desee no permitir a estos invitados "anónimos" o aprobarlos siempre en su lugar.

Requerir aprobación de invitado para los usuarios que han iniciado sesión

Si desea impedir que los invitados que hayan iniciado sesión se unan a las sesiones de colaboración hasta que se hayan "aprobado", cambie la siguiente configuración:

• En VS Code, agregue lo siguiente a settings.json (Configuración de preferencias de > archivo>):

  "liveshare.guestApprovalRequired": true
  

• En Visual Studio, establezca Opciones de herramientas >> Live Share > "Requerir aprobación de invitado" en True.

  

A partir de este momento, se le pedirá que apruebe 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 habilitada esta configuración, se le notificará en la barra de estado o en el cuadro de diálogo de combinación que Live Share está esperando a que el host apruebe.

Rechazo automático o aceptación automática de usuarios que no han iniciado sesión (anónimo)

Como se ha descrito anteriormente, Live Share se puede configurar 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 escribir un nombre al unirse, un nombre simple no proporciona el mismo nivel de garantía que un inicio de sesión real. Por lo tanto, de forma predeterminada, se solicita al host que apruebe cualquier invitado anónimo, independientemente de la configuración "requerir aprobación de invitado" descrita anteriormente.

Siempre puede rechazar (deshabilitar invitados anónimos) o aceptar siempre usuarios anónimos como se indica a continuación:

• En VS Code, establezca liveshare.anonymousGuestApproval en settings.json (Configuración de > preferencias de archivo>) accepten , rejecto prompt (valor predeterminado) según corresponda.

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

Independientemente de , recuerde que solo debe enviar vínculos de invitación de Live Share a las personas en las que confía.

Permitir el control de comandos invitados

Para permitir que los invitados ejecuten comandos arbitrarios a través de Acciones de código ("Correcciones rápidas") y CodeLens establezca la siguiente configuración:

• En VS Code, establezca liveshare.languages.allowGuestCommandControl en settings.json (Configuración de > preferencias de archivo>) true en o false (valor predeterminado).

Control del acceso y la visibilidad de archivos

Como invitado, el modelo remoto de Live Share proporciona acceso rápido de lectura y escritura a 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 supone algunos riesgos para el anfitrión. En concepto, un desarrollador podría optar por entrar y modificar el código fuente sin su conocimiento o ver código fuente confidencial o "secretos" ubicados en algún lugar del árbol de archivos compartidos. Por lo tanto, como host, es posible que no siempre quiera que el invitado tenga acceso a toda la totalidad de un proyecto que comparte. Afortunadamente, una ventaja adicional de este modelo remoto es que puede optar por "excluir" archivos que no desea compartir con nadie sin sacrificar la funcionalidad. Los invitados todavía pueden participar en cosas como las sesiones de depuración que normalmente requerirían acceso a estos archivos si quisieran hacerlo por su cuenta.

Para ello, agregue un archivo .vsls.json a la carpeta o proyecto que va a compartir. Cualquier configuración que agregue a este archivo con formato json cambia la forma en que Live Share procesa los archivos. Además de proporcionar control directo, estos archivos también se pueden confirmar en el control de código fuente, por lo que cualquier persona que clone un proyecto podrá aprovechar estas reglas sin ningún esfuerzo adicional por su parte.

Este es un archivo .vsls.json de ejemplo:

{
    "$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 o carpetas que comparta solo lectura al iniciar una sesión de colaboración. Consulte esta sección más adelante para obtener más información.

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

Propiedades

La propiedad excludeFiles permite especificar una lista de patrones de archivo glob (muy similares a los archivos .gitignore encontrados ) que impide que Live Share abra determinados archivos o carpetas para invitados. Tenga en cuenta que esto incluye escenarios como un invitado que sigue o salta a la ubicación de edición, pasa a un archivo durante la depuración colaborativa, cualquier característica de navegación de código como ir a la definición y mucho más. Está pensado para los archivos que nunca desea compartir en cualquier circunstancia, como los que contienen secretos, certificados o contraseñas. Por ejemplo, dado que controlan la seguridad, los archivos .vsls.json siempre se excluyen.

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

La configuración de gitignore establece cómo Live Share debe procesar el contenido de los archivos .gitignore en carpetas compartidas. De forma predeterminada, los globs encontrados en archivos .gitignore se tratan como si se especificaran en la propiedad "hideFiles". Sin embargo, puede elegir un comportamiento diferente mediante uno de los siguientes valores:

Opción	Resultado
none	El contenido de .gitignore es visible para los invitados en el árbol de archivos (suponiendo que no se filtren por una configuración del editor invitado).
hide	El valor predeterminado. Los globs dentro de .gitignore se procesan como si estuvieran en la propiedad "hideFiles".
exclude	Los globs dentro de .gitignore se procesan como si estuvieran en la propiedad "excludeFiles".

Una desventaja de la exclude configuración es que el contenido de carpetas como node_modules se encuentra con frecuencia en .gitignore, pero puede ser útil para profundizar durante la depuración. Por lo tanto, Live Share admite la capacidad de invertir una regla mediante "!" en la propiedad excludeFiles. Por ejemplo, este archivo .vsls.json excluiría todo en ".gitignore", excepto por 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 desea ocultar node_modules para reducir el desorden sin excluirlo realmente, simplemente puede 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 los archivos .gitignore, .vsls.json se pueden colocar en subcarpetas. Las reglas de ocultación o exclusión se determinan empezando por el archivo .vsls.json en la carpeta raíz que ha compartido (si está presente) y, a continuación, recorre cada subcarpeta desde allí, lo que conduce a un archivo determinado para buscar archivos .vsls.json que se van a procesar. El contenido de los archivos .vsls.json en carpetas más allá del árbol de archivos y, a continuación, complementa (o invalida) las reglas establecidas en niveles superiores.

Nota: no es posible volver a incluir (!) un archivo si se excluye un directorio primario de ese archivo. De forma similar a .gitignore, cuando vuelva a incluir un archivo, también tendrá que volver a incluir todos los directorios primarios del archivo.

Deshabilitación del uso compartido de archivos externos

De forma predeterminada, Live Share también compartirá todos los archivos que se abran en el host que sean externos a la carpeta o solución compartidas. Esto facilita la apertura rápida de otros archivos relacionados sin tener que volver a compartir.

Si prefiere deshabilitar esta característica:

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

  "liveshare.shareExternalFiles": false
  

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

Modo de solo lectura

A veces, cuando comparte el código como host, no quiere que los invitados realicen modificaciones. Es posible que necesite que el invitado eche un vistazo a parte del código, o que muestre el proyecto a un gran número de invitados y no quiera que se realicen modificaciones innecesarias o accidentales. Live Share ofrece la capacidad 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 modificaciones en el código, aunque todavía puede ver los cursores y resaltados de los demás, así como navegar por el proyecto.

Todavía puede depurar conjuntamente con invitados mientras está en modo de solo lectura. Los invitados no podrán recorrer paso a paso el proceso de depuración, pero aún pueden agregar o quitar puntos de interrupción e inspeccionar variables. Además, todavía 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 abordan problemas de codificación difíciles o errores, tener un par adicional de ojos cuando la depuración puede ser realmente útil. Visual Studio Live Share habilita "depuración colaborativa" o "depuración conjunta" al compartir la sesión de depuración con todos los invitados cada vez que el host inicia la depuración.

Como host, tiene control total sobre cuándo se inicia o detiene una sesión de depuración, pero la depuración conjunta supone algunos riesgos si comparte con alguien que no confía. Live Share permite a los invitados ejecutar comandos de consola o REPL y, por tanto, existe el riesgo de que un actor malintencionado ejecute un comando que no desea que se ejecuten.

Por lo tanto, solo debe depurar conjuntamente con los que confía.

Más información:

Uso compartido de 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 el equipo del host al mismo puerto en el equipo del invitado. Como invitado, puede interactuar con la aplicación exactamente como si se estuviera ejecutando localmente en el equipo (por ejemplo, el host y el invitado pueden acceder a una aplicación web que se ejecuta en el equipo). http://localhost:3000).

Sin embargo, como host, debe ser muy selectivo con los puertos que comparte con invitados y solo compartir puertos de aplicación en lugar de puertos del 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 este motivo, Live Share no realiza ninguna suposición sobre lo que debe o no debe compartirse sin una configuración y el host que realiza una acción.

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

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

"liveshare.autoShareServers": false

En cualquier caso, tenga cuidado al compartir puertos adicionales.

Puede obtener más información sobre cómo configurar la característica aquí:

Uso compartido de 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, puede permitir que otros colaboradores solo vean la salida o usen cualquier número de herramientas de línea de comandos para ejecutar pruebas, compilaciones o incluso evaluar problemas específicos del entorno.

Solo los hosts pueden iniciar terminales compartidos para impedir que los invitados inicien una y hagan algo que no espera ni observa. Al iniciar un terminal compartido como host, puede especificar si debe ser de solo lectura o de lectura y 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 de forma predeterminada. En VS Code, los terminales se comparten automáticamente de forma predeterminada de solo lectura . Sin embargo, puede deshabilitarlo agregando lo siguiente a settings.json:

"liveshare.autoShareTerminals": false

Más información:

Consentimiento del administrador de AAD

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

El administrador de AD tendría que resolverlo automáticamente con la siguiente información:

• Nombre de la aplicación: Visual Studio Live Share (insiders)
• Tipo de aplicación: Aplicación web
• Estado de las aplicaciones: producción
• Permisos delegados: User.Read
• Dirección 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 cualquier persona que use Live Share. Consulte aquí y aquí para obtener más información.

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.