Recursos de segurança do Live Share

As sessões de colaboração no Visual Studio Live Share são poderosas, pois permitem que qualquer número de pessoas participe de uma sessão e edite, depure e muito mais de forma colaborativa. No entanto, dado esse nível de acesso, você sem dúvida estará interessado nos recursos de segurança que o Live Share oferece. Neste artigo, forneceremos algumas recomendações e opções para proteger seu ambiente, conforme necessário.

Como acontece com qualquer ferramenta de colaboração, lembre-se de que você só deve compartilhar seu código, conteúdo e aplicativos com pessoas em quem confia.

Conectividade

Ao iniciar uma sessão entre pares, o Live Share tenta estabelecer uma conexão ponto a ponto e, somente se isso não for possível (por exemplo, devido a firewalls/NATs), ele volta a usar um retransmissor de nuvem. No entanto, em ambos os tipos de conexão (P2P ou retransmissão), todos os dados transmitidos entre pares são criptografados de ponta a ponta usando o protocolo SSH. No caso de uma conexão de retransmissão, a criptografia SSH é colocada em camadas sobre WebSockets criptografados por TLS. Isso significa que o Live Share não depende do serviço de retransmissão em nuvem para segurança. Mesmo que a retransmissão estivesse comprometida, ela não poderia descriptografar nenhuma comunicação do Live Share.

A função do serviço Live Share é limitada à autenticação do usuário e à descoberta de sessão. O serviço em si não armazena nem tem acesso a nenhum conteúdo de uma sessão. Todo o conteúdo do usuário no Live Share é transmitido pela sessão SSH. Isso inclui código, terminais, servidores compartilhados e quaisquer outros recursos de colaboração fornecidos pelo Live Share ou extensões que se baseiam nele.

Para saber mais sobre como alterar esses comportamentos e os requisitos de conectividade do Live Share, consulte Requisitos de conectividade do Live Share.

Criptografia de fio

O protocolo SSH usa uma troca de chaves Diffie-Hellman para estabelecer um segredo compartilhado para a sessão e deriva disso uma chave para criptografia simétrica AES. A chave de criptografia é girada periodicamente durante toda a duração da sessão. O segredo da sessão compartilhada e todas as chaves de criptografia são mantidas na memória apenas por ambos os lados e são válidas apenas durante a sessão. Eles nunca são gravados em disco ou enviados para qualquer serviço (incluindo Live Share).

Autenticação de ponto a ponto

A sessão SSH também é autenticada bidirecionalmente. O host (função de servidor SSH) usa autenticação de chave pública/privada como é padrão para o protocolo SSH. Quando um host compartilha uma sessão de Live Share, ele gera um par de chaves RSA público/privado exclusivo para a sessão. A chave privada do host é mantida somente na memória no processo do host; ele nunca é gravado em disco ou enviado para qualquer serviço, incluindo o serviço Live Share. A chave pública do host é publicada no serviço Live Share junto com as informações de conexão da sessão (endereço IP e/ou ponto de extremidade de retransmissão), onde os convidados podem acessá-la por meio do link de convite. Quando um convidado se conecta à sessão SSH do host, ele usa o protocolo de autenticação de host SSH para validar se o host mantém a chave privada correspondente à chave pública publicada (sem que o convidado realmente consiga ver a chave privada).

O convidado usa um token Live Share para se autenticar com o host. O token é um JWT assinado emitido pelo serviço Live Share que inclui declarações sobre a identidade do usuário (obtidas por meio de login MSA, AAD ou GitHub). O token também tem declarações que indicam que o convidado tem permissão para acessar aquela sessão específica do Live Share (porque eles tinham o link de convite e/ou foram especificamente convidados pelo anfitrião). O host valida esse token e verifica as declarações (e, dependendo das opções, pode solicitar ao usuário do host) antes de permitir que o convidado ingresse na sessão.

Convites e acesso a participar

Cada vez que você inicia uma nova sessão de colaboração, o Live Share gera um novo identificador exclusivo que é colocado no link de convite. Esses links fornecem uma base sólida e segura para convidar aqueles em quem você confia, já que o identificador no link é "não adivinhável" e só é válido para a duração de uma única sessão de colaboração.

Removendo um convidado inesperado

Como host, você é notificado automaticamente sempre que um convidado ingressa na sessão de colaboração.

No código do Visual Studio:

No Visual Studio:

Melhor ainda, a notificação lhe dá a capacidade de remover um convidado que se juntou se, por algum motivo, você não conhecê-lo. (Por exemplo, se você postou acidentalmente seu link em um sistema de bate-papo em toda a empresa e um funcionário aleatório ingressou.) Basta clicar no botão "Remover" na notificação que aparece e eles serão ejetados da sessão de colaboração.

No VS Code, mesmo que você tenha descartado uma notificação de participação, você também tem a capacidade de remover um participante depois disso. Ao abrir a visualização Live Share no Explorer ou a guia personalizada na barra de atividades do VS Code, você pode passar o mouse ou clicar com o botão direito do mouse no nome de um participante e selecionar o ícone ou a opção "Remover participante".

Exigir aprovação do hóspede

Normalmente, os participantes que ingressarem em uma sessão de colaboração entrarão no Live Share usando uma conta corporativa ou de estudante (AAD) da Microsoft, uma conta pessoal da Microsoft ou uma conta do GitHub. Embora o padrão "notificação + remoção" para usuários conectados forneça uma boa combinação de velocidade e controle para esses convidados, convém bloquear as coisas um pouco mais se estiver fazendo algo sensível.

Além disso, em determinadas circunstâncias, forçar todos os convidados a entrar para participar de uma sessão de colaboração pode ser problemático. Os exemplos incluem pedir a alguém novo no Live Share para participar como convidado, cenários de sala de aula/aprendizagem ou ao colaborar com alguém que não tenha um dos tipos de conta suportados. Por esses motivos, o Live Share pode permitir que usuários que não estão conectados participem de sessões de colaboração como convidados somente leitura. Embora o anfitrião precise aprovar esses convidados antes que eles possam participar por padrão, você pode querer não permitir esses convidados "anônimos" ou sempre aprová-los.

Exigindo aprovação de convidado para usuários conectados

Se você quiser impedir que convidados conectados participem de suas sessões de colaboração até que você os "aprove", altere a seguinte configuração:

• No VS Code, adicione o seguinte a settings.json (Configurações de preferências > de arquivo>):

  "liveshare.guestApprovalRequired": true
  

• No Visual Studio, defina Opções > de Ferramentas Live Share > "Exigir aprovação de > convidado" como True.

  

A partir deste ponto, você será solicitado a aprovar cada convidado que se juntar.

No código do Visual Studio:

No Visual Studio:

Como convidado, se você ingressar em uma sessão em que o host tenha essa configuração habilitada, será notificado na barra de status ou na caixa de diálogo de ingresso de que o Live Share está aguardando a aprovação do host.

Rejeitar ou aceitar automaticamente usuários que não estão conectados (anônimo)

Conforme descrito acima, o Live Share pode ser configurado para permitir que usuários que não estão conectados participem de uma sessão de colaboração como convidados somente leitura. Embora esses convidados "anônimos" devam inserir um nome ao entrar, um nome simples não fornece o mesmo nível de garantia que um login real. Portanto, por padrão, o host é solicitado a aprovar qualquer convidado anônimo, independentemente da configuração "exigir aprovação de convidado" descrita acima.

Você sempre pode rejeitar (desabilitar convidados anônimos) ou sempre aceitar usuários anônimos da seguinte maneira:

• No VS Code, defina liveshare.anonymousGuestApproval em settings.json (Configurações de preferências de arquivo >> ) como accept, rejectou prompt (o padrão) conforme apropriado.

• No Visual Studio, defina Opções > de Ferramentas Live Share > "Aprovação de > convidado anônimo" como Aceitar, Rejeitar ou Avisar (o padrão), conforme apropriado.

Independentemente disso, lembre-se de que você só deve enviar links de convite do Live Share para pessoas em quem você confia.

Permitindo o controle de comando de convidado

Para permitir que os convidados executem comandos arbitrários por meio de Ações de Código ("Correções Rápidas") e CodeLens, defina a seguinte configuração:

• No VS Code, defina liveshare.languages.allowGuestCommandControl em settings.json (Configurações de preferências de arquivo >> ) como true ou false (o padrão).

Controlando o acesso e a visibilidade de arquivos

Como convidado, o modelo remoto do Live Share oferece acesso rápido de leitura/gravação a arquivos e pastas que o host compartilhou com você sem precisar sincronizar todo o conteúdo de um projeto. Portanto, você pode navegar e editar arquivos de forma independente em toda a árvore de arquivos compartilhados. No entanto, essa liberdade representa alguns riscos para o anfitrião. Em conceito, um desenvolvedor poderia optar por entrar e modificar o código-fonte sem o seu conhecimento ou ver o código-fonte confidencial ou "segredos" localizados em algum lugar na árvore de arquivos compartilhados. Consequentemente, como anfitrião, você nem sempre pode querer que o convidado tenha acesso à totalidade de um projeto que você está compartilhando. Felizmente, uma vantagem adicional deste modelo remoto é que você pode optar por "excluir" arquivos que você não deseja compartilhar com ninguém sem sacrificar a funcionalidade. Seus convidados ainda podem participar de coisas como sessões de depuração que normalmente exigiriam acesso a esses arquivos se quisessem fazê-lo por conta própria.

Você pode fazer isso adicionando um arquivo .vsls.json à pasta ou projeto que está compartilhando. Todas as configurações adicionadas a esse arquivo formatado em json alteram a forma como o Live Share processa arquivos. Além de fornecer controle direto, esses arquivos também podem ser comprometidos com o controle do código-fonte para que qualquer pessoa que clone um projeto possa tirar proveito dessas regras sem nenhum esforço adicional de sua parte.

Aqui está um exemplo de arquivo .vsls.json:

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

Observação

Você também pode tornar todos os arquivos/pastas compartilhados somente leitura ao iniciar uma sessão de colaboração. Veja abaixo para obter mais detalhes.

Vamos explicar como essas propriedades mudam o que os hóspedes podem fazer.

Propriedades

A propriedade excludeFiles permite que você especifique uma lista de padrões de arquivo glob (muito parecidos com os arquivos .gitignore encontrados) que impede o Live Share de abrir determinados arquivos ou pastas para convidados. Lembre-se de que isso inclui cenários como um convidado seguindo ou pulando para seu local de edição, entrando em um arquivo durante a depuração colaborativa, quaisquer recursos de navegação de código, como ir para a definição, e muito mais. Destina-se a arquivos que você nunca deseja compartilhar em nenhuma circunstância, como aqueles que contêm segredos, certificados ou senhas. Por exemplo, como eles controlam a segurança, os arquivos .vsls.json são sempre excluídos.

A propriedade hideFiles é semelhante, mas não tão rigorosa. Esses arquivos são simplesmente ocultos da árvore de arquivos. Por exemplo, se você entrou em um desses arquivos durante a depuração, ele ainda será aberto no editor. Essa propriedade é útil principalmente se você não tiver uma configuração de arquivo .gitignore (como seria o caso se você estiver usando um sistema de controle de origem diferente) ou se simplesmente quiser aumentar o que já está lá para evitar confusão ou confusão.

A configuração gitignore estabelece como o Live Share deve processar o conteúdo de arquivos .gitignore em pastas compartilhadas. Por padrão, todos os globs encontrados em arquivos .gitignore são tratados como se fossem especificados na propriedade "hideFiles". No entanto, você pode escolher um comportamento diferente usando um dos seguintes valores:

Opção	Resultado
none	O conteúdo .gitignore é visível para convidados na árvore de arquivos (supondo que eles não sejam filtrados por uma configuração de editor convidado).
hide	O padrão. Globs dentro de .gitignore são processados como se estivessem na propriedade "hideFiles".
exclude	Globs dentro de .gitignore são processados como se estivessem na propriedade "excludeFiles".

Uma desvantagem da exclude configuração é que o conteúdo de pastas como node_modules estão frequentemente em .gitignore, mas pode ser útil para entrar durante a depuração. Consequentemente, o Live Share oferece suporte à capacidade de reverter uma regra usando "!" na propriedade excludeFiles. Por exemplo, esse arquivo .vsls.json excluiria tudo em ".gitignore", exceto node_modules:

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

As regras de ocultar e excluir são processadas separadamente, portanto, se você ainda quiser ocultar node_modules para reduzir a desordem sem realmente excluí-la, você pode simplesmente editar o arquivo da seguinte maneira:

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

Arquivos .vsls.json em subpastas

Finalmente, assim como .gitignore, os arquivos .vsls.json podem ser colocados em subpastas. As regras de ocultação/exclusão são determinadas começando com o arquivo .vsls.json na pasta raiz que você compartilhou (se presente) e, em seguida, caminhando por cada subpasta a partir daí, levando a um determinado arquivo para procurar arquivos .vsls.json para processar. O conteúdo dos arquivos .vsls.json em pastas mais abaixo da árvore de arquivos complementa (ou substitui) as regras estabelecidas em níveis mais altos.

Nota: não é possível reincluir (!) um arquivo se um diretório pai desse arquivo for excluído. Semelhante ao .gitignore, ao reincluir um arquivo, você também precisará incluir novamente todos os diretórios pai do arquivo.

Desabilitando o compartilhamento de arquivos externos

Por padrão, o Live Share também compartilhará todos os arquivos abertos pelo host que sejam externos à pasta/solução compartilhada. Isso facilita a abertura rápida de outros arquivos relacionados sem ter que compartilhar novamente.

Se preferir desativar este recurso:

• No VS Code, adicione o seguinte a settings.json:

  "liveshare.shareExternalFiles": false
  

• No Visual Studio, defina Opções > de Ferramentas > Live Share > "Compartilhar arquivos externos" como False

Modo somente leitura

Às vezes, quando você compartilha seu código como anfitrião, não quer que seus convidados façam edições. Você pode precisar que seu convidado dê uma olhada em algum de seu código, ou você está mostrando seu projeto para um grande número de convidados e não quer que edições desnecessárias ou acidentais sejam feitas. O Live Share oferece a capacidade de compartilhar projetos no modo somente leitura.

Como host, ao compartilhar, você tem a opção de habilitar o modo somente leitura para uma sessão de colaboração. Quando um convidado ingressa, ele não poderá fazer edições no código, embora você ainda possa ver os cursores e destaques um do outro, bem como navegar pelo projeto.

Você ainda pode co-depurar com convidados enquanto estiver no modo somente leitura. Os convidados não terão a capacidade de passar pelo processo de depuração, mas ainda poderão adicionar ou remover pontos de interrupção e inspecionar variáveis. Além disso, você ainda pode compartilhar servidores e terminais (somente leitura) com convidados.

Você pode saber mais sobre como iniciar uma sessão de colaboração somente leitura:

Codepuração

Quando você está lidando com problemas de codificação ou bugs difíceis, ter um par de olhos extra ao depurar pode ser realmente útil. O Visual Studio Live Share habilita a "depuração colaborativa" ou a "codepuração" compartilhando a sessão de depuração com todos os convidados sempre que o host inicia a depuração.

Como host, você tem controle total sobre quando uma sessão de depuração é iniciada ou interrompida, mas a codepuração oferece alguns riscos se você estiver compartilhando com alguém em quem não confia. O Live Share permite que os convidados que você convidar executem comandos de console/REPL e, portanto, há o risco de um ator mal-intencionado executar um comando que você não gostaria que eles executassem.

Consequentemente, você só deve co-depurar com aqueles em quem confia.

Saiba mais:

Compartilhando um servidor local

Durante a codepuração, pode ser muito útil obter acesso a diferentes partes do aplicativo que está sendo fornecido pelo host para a sessão de depuração. Talvez você deseje acessar o aplicativo em um navegador, acessar um banco de dados local ou um ponto de extremidade REST por meio de suas ferramentas. O Live Share permite que você "compartilhe um servidor" que mapeia uma porta local na máquina do host para a mesma porta na máquina do convidado. Como convidado, você pode interagir com o aplicativo exatamente como se ele estivesse sendo executado localmente em sua máquina (por exemplo, o host e o convidado podem acessar um aplicativo Web em execução em http://localhost:3000).

No entanto, como host, você deve ser muito seletivo com as portas que compartilha com convidados e compartilhar apenas portas de aplicativos em vez de portas do sistema. Para convidados, as portas compartilhadas se comportarão exatamente como fariam se o servidor/serviço estivesse em execução em seu próprio computador. Isso é muito útil, mas se a porta errada for compartilhada, isso também poderá ser um risco. Por esse motivo, o Live Share não faz suposições sobre o que deve ou não ser compartilhado sem uma definição de configuração e o host executando uma ação.

No Visual Studio, a porta do aplicativo Web especificada em ASP.NET projetos é compartilhada automaticamente durante a depuração apenas para facilitar o acesso de convidado ao aplicativo Web durante a execução. No entanto, você pode desativar essa automação definindo Opções de ferramentas >> Live Share > "Compartilhar aplicativo web na depuração" como "Falso", se preferir.

No Visual Studio Code, o Live Share tenta detectar as portas de aplicativo adequadas e compartilhá-las. No entanto, você pode desabilitar isso adicionando o seguinte a settings.json:

"liveshare.autoShareServers": false

Em ambos os casos, tenha cuidado ao compartilhar portas adicionais.

Você pode saber mais sobre como configurar o recurso aqui:

Compartilhando um terminal

O desenvolvimento moderno faz uso frequente de uma ampla gama de ferramentas de linha de comando. Felizmente, o Live Share permite que você, como host, opcionalmente, "compartilhe um terminal" com os convidados. O terminal compartilhado pode ser somente leitura ou totalmente colaborativo, de modo que você e os convidados possam executar comandos e ver os resultados. Como host, você pode permitir que outros colaboradores apenas vejam a saída ou usem qualquer número de ferramentas de linha de comando para executar testes, compilações ou até mesmo triar problemas específicos do ambiente.

Apenas os anfitriões podem iniciar terminais compartilhados para evitar que os hóspedes iniciem um e façam algo que você não está esperando ou assistindo. Ao iniciar um terminal compartilhado como host, você pode especificar se ele deve ser somente leitura ou leitura/gravação. Quando o terminal for leitura/gravação, todos poderão digitar no terminal, incluindo o host, o que facilita a intervenção caso um convidado faça algo indesejável. No entanto, para que seja seguro, você deve dar somente acesso de leitura/gravação aos convidados quando tiver ciência de que eles realmente precisam e continuar com os terminais somente leitura para cenários em que deseja que o convidado veja apenas a saída dos comandos que você executa.

No Visual Studio, os terminais não são compartilhados por padrão. No VS Code, os terminais são compartilhados automaticamente somente leitura por padrão. No entanto, você pode desabilitar isso adicionando o seguinte a settings.json:

"liveshare.autoShareTerminals": false

Saiba mais:

Consentimento do administrador do AAD

Ao entrar usando um endereço de email escolar ou profissional apoiado pela Microsoft, você poderá ver uma mensagem dizendo "Precisa de aprovação do administrador" ao entrar. Isso ocorre porque o Live Share requer acesso de leitura às informações do usuário para seus recursos de segurança e seu locatário do Azure AD está configurado para exigir "consentimento do administrador" para novos aplicativos que acessam o conteúdo do diretório.

Seu administrador do AD precisaria resolver isso para você usando as seguintes informações:

• Nome do aplicativo: Visual Studio Live Share (Insiders)
• Tipo de aplicativo: Web App
• Status dos aplicativos: Produção
• Permissões delegadas: User.Read
• URL do aplicativo: https://visualstudio.microsoft.com/services/live-share/
• URL de Resposta: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Isso só precisaria ser feito uma vez para quem usa o Live Share. Veja aqui e aqui os detalhes.

Confira também

• Instalar e entrar no Live Share no Visual Studio Code
• Instalar e entrar no Live Share no Visual Studio
• Requisitos de conectividade do Live Share

Está tendo problemas? Confira Solução de problemas ou envie comentários.