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 que você 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 voltará a usar uma retransmissão 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 de nuvem para segurança. Mesmo que a retransmissão tenha sido comprometida, ela não poderá 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 e 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 baseadas nele.

Para saber mais sobre como alterar esses comportamentos e os requisitos de conectividade do Live Share, consulte requisitos de conectividade para o 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 é rotacionada periodicamente durante toda a sessão. O segredo da sessão compartilhada e todas as chaves de criptografia são mantidas apenas na memória por ambos os lados e são válidos apenas durante a sessão. Eles nunca são gravados em disco ou enviados para nenhum serviço (incluindo Live Share).

Autenticação de pares

A sessão SSH também é autenticada bidirecional. O host (função de servidor SSH) usa autenticação de chave pública/privada como padrão para o protocolo SSH. Quando um anfitrião compartilha uma sessão do Live Share, ele gera um par de chaves público/privado RSA exclusivo para a sessão. A chave privada do host é mantida apenas 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 possui 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 anfitrião. O token é um JWT assinado e emitido pelo serviço Live Share que inclui declarações sobre a identidade do usuário (obtidas por meio de MSA, AAD ou entrada no GitHub). O token também tem declarações que indicam que o convidado tem permissão para acessar essa sessão específica do Live Share (porque eles tinham o link de convite e/ou foram especificamente convidados pelo anfitrião). O anfitrião valida esse token e verifica as declarações (dependendo das opções, pode solicitar o usuário anfitrião) antes de permitir que o convidado ingresse na sessão.

Convites e acesso para 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, pois o identificador no link é "não adivinhável" e é válido apenas durante uma única sessão de colaboração.

Removendo um convidado inesperado

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

No Visual Studio Code:

No Visual Studio:

Melhor ainda, a notificação permite remover um convidado que ingressou se, por algum motivo, você não o conhecer. (Por exemplo, se você postou acidentalmente seu link em um sistema de bate-papo em toda a empresa e um funcionário aleatório entrou.) 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 ingresso, também poderá remover um participante depois disso. Ao abrir o modo de exibiçã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 convidado

Normalmente, os participantes que ingressarem em uma sessão de colaboração serão conectados ao Live Share usando uma conta corporativa ou de estudante da Microsoft (AAD), 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, você pode querer bloquear um pouco mais as coisas se estiver fazendo algo confidencial.

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. Exemplos incluem pedir a alguém novo no Live Share para ingressar como convidado, cenários de sala de aula/aprendizagem ou ao colaborar com alguém que não tem um dos tipos de conta suportado. Por esses motivos, o Live Share pode permitir que os usuários que não estão conectados ingressem em sessões de colaboração como convidados somente leitura. Embora o anfitrião precise aprovar esses convidados antes que eles possam entrar por padrão, você pode querer proibir esses convidados "anônimos" ou sempre aprová-los.

Exigir 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 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 Ferramentas > Opções > Live Share > "Exigir aprovação do convidado" como Verdadeiro.

  

Deste ponto em diante, você será solicitado a aprovar cada convidado que entrar.

No Visual Studio Code:

No Visual Studio:

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

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

Conforme descrito acima, o Live Share pode ser configurado para permitir que os usuários que não estão conectados ingressem em uma sessão de colaboração como convidados somente leitura. Embora esses convidados "anônimos" devam inserir um nome ao ingressar, um nome simples não fornece o mesmo nível de garantia que um login real. Portanto, por padrão, o anfitrião é solicitado a aprovar qualquer convidado anônimo, independentemente da configuração "exigir aprovação do 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 Ferramentas > Opções > Live Share > "Aprovação anônima de convidado" como Aceitar, Rejeitar ou Solicitar (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 confia.

Permitindo o controle de comando do 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 dos arquivos

Como convidado, o modelo remoto do Live Share oferece acesso rápido de leitura/gravação a arquivos e pastas que o anfitrião compartilhou com você sem precisar sincronizar todo o conteúdo do 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 teoria, 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 deseja que o convidado tenha acesso à totalidade de um projeto que você está compartilhando. Felizmente, uma vantagem adicional desse modelo remoto é que você pode optar por "excluir" arquivos que 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 fazer isso 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 os arquivos. Além de fornecer controle direto, esses arquivos também podem ser enviados ao controle do código-fonte para que qualquer pessoa que clonar um projeto possa aproveitar essas 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"
    ]
}

Vamos ver como essas propriedades mudam o que os convidados podem fazer.

Propriedades

A propriedade excludeFiles permite que você especifique uma lista de padrões de arquivo glob (muito parecidos aqueles encontrados em arquivos .gitignore encontrados) que impedem 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 o local de edição, entrando em um arquivo durante a depuração colaborativa, quaisquer recursos de navegação de código, como ir para definição e muito mais. Ele é destinado 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ê entrar em um desses arquivos durante a depuração, ele ainda será aberto no editor. Essa propriedade é útil principalmente se você não tiver um arquivo .gitignore configurado (como seria o caso se você estivesse usando um sistema de controle de origem diferente) ou se você simplesmente quisesse aumentar o que já está lá para evitar desordem 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 tivessem sido especificados na propriedade "hideFiles". No entanto, você pode escolher um comportamento diferente usando um dos seguintes valores:

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

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

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

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

.vsls.json arquivos em subpastas

Finalmente, assim como .gitignore, os arquivos .vsls.json, podem ser colocados em subpastas. As regras de ocultar/excluir são determinadas começando com o arquivo .vsls.json na pasta raiz que você compartilhou (se houver) e, em seguida, percorrendo cada subpasta a partir daí, levando a um determinado arquivo para procurar por arquivos .vsls.json para processar. O conteúdo de arquivos .vsls.json em pastas mais abaixo na á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 a .gitignore, ao reincluir novamente um arquivo, você também precisará reincluir novamente todos os diretórios pai do arquivo.

Desativando o compartilhamento de arquivos externos

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

Se você preferir desativar esse recurso:

• Em VS Code, adicione o seguinte ao settings.json:

  "liveshare.shareExternalFiles": false
  

• No Visual Studio, defina Ferramentas > Opções > Live Share > "Compartilhar Arquivos Externos" como Falso

Modo somente leitura

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

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

Você ainda pode codepurar com convidados enquanto estiver no modo somente leitura. Os convidados não terão a capacidade de percorrer o processo de depuração, mas ainda poderão adicionar ou remover pontos de interrupção e inspecionar variáveis. Além disso, você ainda poderá 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ê estiver lidando com bugs ou problemas de codificação difíceis, contar com a ajuda de mais alguém ao depurar pode ser muito útil. O Visual Studio Live Share habilita a "depuração colaborativa" ou "codepuração" compartilhando a sessão de depuração com todos os convidados sempre que o anfitrião inicia a depuração.

Como anfitrião, você tem controle total sobre quando uma sessão de depuração é iniciada ou interrompida, mas a codepuração apresenta 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 agente malicioso executar um comando que não deve ser executado.

Consequentemente, você só deve codepurar 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 no computador do anfitrião para exatamente a mesma porta no computador de convidado. Como convidado, você pode interagir com o aplicativo exatamente como se ele estivesse sendo executado localmente em seu computador (por exemplo, o anfitrião e o convidado podem acessar um aplicativo Web em execução em http://localhost:3000)..

No entanto, como anfitrião 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 sem que o anfitrião execute 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 Ferramentas > Opções > 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 em 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 anfitrião, você pode permitir que outros colaboradores vejam apenas a saída ou usem qualquer número de ferramentas de linha de comando para executar testes, compilações ou até mesmo classificar problemas específicos do ambiente.

Somente anfitriões podem iniciar terminais compartilhados para evitar que convidados iniciem um e façam algo que você não está esperando nem observando. Ao iniciar um terminal compartilhado como anfitrião, 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 como somente leitura por padrão. No entanto, você pode desabilitar isso adicionando o seguinte em settings.json:

"liveshare.autoShareTerminals": false

Saiba mais:

Consentimento do administrador do AAD

Ao entrar usando um endereço corporativo ou de estudante com suporte da Microsoft, você pode 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.

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

• Nome do aplicativo: Visual Studio Live Share (Insiders)
• Tipo de aplicativo: Aplicativo Web
• 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 qualquer pessoa que usasse o Live Share. Consulte aqui e aqui para obter detalhes.

Confira também

• Instale e entre no Live Share no Visual Studio Code
• Instale e entre no Live Share no Visual Studio Code
• Requisitos de conectividade do Live Share

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