Funzionalità di sicurezza di Live Share

Le sessioni di collaborazione in Visual Studio Live Share sono potenti in quanto consentono a un numero qualsiasi di persone di partecipare a una sessione e di modificare in modo collaborativo, eseguire il debug e altro ancora. Tuttavia, dato questo livello di accesso, sicuramente si sarà interessati alle funzionalità di sicurezza offerte da Live Share. In questo articolo verranno fornite alcune raccomandazioni e opzioni per proteggere l'ambiente in base alle esigenze.

Come per qualsiasi strumento di collaborazione, tenere presente che è consigliabile condividere solo il codice, il contenuto e le applicazioni con persone attendibili.

Connettività

Quando si avvia una sessione tra peer, Live Share tenta di stabilire una connessione peer-to-peer e solo se non è possibile ,ad esempio a causa di firewall/NAT, esegue il fallback all'uso di un inoltro cloud. Tuttavia, in entrambi i tipi di connessione (P2P o inoltro), tutti i dati trasmessi tra peer sono crittografati end-to-end usando il protocollo SSH. Nel caso di una connessione di inoltro, la crittografia SSH viene sovrapposta ai WebSocket crittografati TLS. Ciò significa che Live Share non dipende dal servizio di inoltro cloud per la sicurezza. Anche se l'inoltro è stato compromesso, non è stato possibile decrittografare alcuna comunicazione di Live Share.

Il ruolo del servizio Live Share è limitato all'autenticazione utente e all'individuazione delle sessioni. Il servizio stesso non archivia né ha accesso ad alcun contenuto di una sessione. Tutto il contenuto utente in Live Share viene trasmesso tramite la sessione SSH. Che include codice, terminali, server condivisi e qualsiasi altra funzionalità di collaborazione fornita da Live Share o estensioni basate su di essa.

Per altre informazioni sulla modifica di questi comportamenti e sui requisiti di connettività di Live Share, vedere Requisiti di connettività per Live Share.

Crittografia in transito

Il protocollo SSH usa uno scambio di chiavi Diffie-Hellman per stabilire un segreto condiviso per la sessione e deriva da tale chiave per la crittografia simmetrica AES. La chiave di crittografia viene ruotata periodicamente per tutta la durata della sessione. Il segreto della sessione condivisa e tutte le chiavi di crittografia vengono mantenute in memoria solo da entrambi i lati e sono valide solo per la durata della sessione. Non vengono mai scritti su disco o inviati a qualsiasi servizio (incluso Live Share).

Autenticazione peer

Anche la sessione SSH è autenticata bidirezionale. L'host (ruolo server SSH) usa l'autenticazione con chiave pubblica/privata così come è standard per il protocollo SSH. Quando un host condivide una sessione di Live Share, genera una coppia chiave pubblica/privata RSA univoca per la sessione. La chiave privata dell'host viene mantenuta solo in memoria nel processo host; non viene mai scritto su disco o inviato a qualsiasi servizio incluso il servizio Live Share. La chiave pubblica dell'host viene pubblicata nel servizio Live Share insieme alle informazioni di connessione della sessione (indirizzo IP e/o endpoint di inoltro) in cui gli utenti guest possono accedervi tramite il collegamento di invito. Quando un guest si connette alla sessione SSH dell'host, il guest usa il protocollo di autenticazione host SSH per verificare che l'host contenga la chiave privata corrispondente alla chiave pubblica pubblicata (senza che il guest visualizzi effettivamente la chiave privata).

Il guest usa un token di Live Share per autenticarsi con l'host. Il token è un token JWT firmato rilasciato dal servizio Live Share che include attestazioni sull'identità utente (ottenute tramite l'accesso a MSA, AAD o GitHub). Il token ha anche attestazioni che indicano che il guest è autorizzato ad accedere a tale sessione specifica di Live Share (perché ha avuto il collegamento di invito e/o sono stati invitati specificamente dall'host). L'host convalida il token e controlla le attestazioni (e a seconda delle opzioni può richiedere all'utente host) prima di consentire al guest di partecipare alla sessione.

Inviti e accesso di join

Ogni volta che si avvia una nuova sessione di collaborazione, Live Share genera un nuovo identificatore univoco inserito nel collegamento di invito. Questi collegamenti forniscono una base solida e sicura per invitare coloro che si considerano attendibili poiché l'identificatore nel collegamento è "non indovinabile" ed è valido solo per la durata di una singola sessione di collaborazione.

Rimozione di un guest imprevisto

In qualità di host, si riceve automaticamente una notifica ogni volta che un guest partecipa alla sessione di collaborazione.

In Visual Studio Code:

In Visual Studio:

Meglio ancora, la notifica ti offre la possibilità di rimuovere un guest che ha aggiunto se per qualche motivo non li conosci. Ad esempio, se il collegamento è stato pubblicato accidentalmente in un sistema di chat a livello aziendale e un dipendente casuale aggiunto. È sufficiente fare clic sul pulsante "Rimuovi" nella notifica visualizzata e verranno espulsi dalla sessione di collaborazione.

In VS Code, anche se è stata ignorata una notifica di join, è anche possibile rimuovere un partecipante. Aprendo la visualizzazione Live Share in Esplora risorse o nella scheda personalizzata nella barra delle attività di VS Code, è possibile passare il puntatore del mouse o fare clic con il pulsante destro del mouse sul nome di un partecipante e selezionare l'icona o l'opzione "Rimuovi partecipante".

Richiesta di approvazione guest

In genere, i partecipanti che partecipano a una sessione di collaborazione verranno connessi a Live Share usando un account Microsoft aziendale o dell'istituto di istruzione (AAD), un account Microsoft personale o un account GitHub. Mentre l'impostazione predefinita "notification + remove" per gli utenti connessi offre una buona combinazione di velocità e controllo per questi utenti guest, è possibile bloccare le cose un po 'di più se si esegue qualcosa di sensibile.

In alcune circostanze, inoltre, l'accesso a una sessione di collaborazione può essere problematico per tutti gli utenti guest. Gli esempi includono la richiesta a un nuovo utente di Live Share di partecipare come guest, scenari di classe/apprendimento o quando si collabora con qualcuno che non ha uno dei tipi di account supportati. Per questi motivi, Live Share può consentire agli utenti che non hanno eseguito l'accesso per partecipare alle sessioni di collaborazione come guest di sola lettura . Anche se l'host deve approvare questi guest prima di poter partecipare per impostazione predefinita, è consigliabile non consentire questi guest "anonimi" o approvarli sempre.

Richiesta dell'approvazione guest per gli utenti connessi

Se si vuole impedire agli utenti guest connessi di partecipare alle sessioni di collaborazione fino a quando non sono state "approvate", modificare l'impostazione seguente:

• In VS Code aggiungere quanto segue a settings.json (Impostazioni preferenze > file>):

  "liveshare.guestApprovalRequired": true
  

• In Visual Studio impostare > Strumenti Opzioni > Live Share > "Richiedi approvazione guest" su True.

  

Da questo punto in poi, verrà chiesto di approvare ogni guest che partecipa.

In Visual Studio Code:

In Visual Studio:

In qualità di guest, se si partecipa a una sessione in cui è abilitata questa impostazione, si riceverà una notifica nella barra di stato o nella finestra di dialogo di aggiunta che Live Share è in attesa dell'approvazione dell'host.

Rifiuto automatico o accettazione di utenti che non hanno eseguito l'accesso (anonimo)

Come descritto in precedenza, Live Share può essere configurato per consentire agli utenti che non hanno eseguito l'accesso per partecipare a una sessione di collaborazione come guest di sola lettura. Anche se questi guest "anonimi" devono immettere un nome durante l'aggiunta, un nome semplice non fornisce lo stesso livello di garanzia di un accesso reale. Pertanto, per impostazione predefinita, all'host viene richiesto di approvare qualsiasi guest anonimo indipendentemente dall'impostazione "Richiedi approvazione guest" descritta in precedenza.

È sempre possibile rifiutare (disabilitare gli utenti guest anonimi) o accettare sempre utenti anonimi come indicato di seguito:

• In VS Code impostare liveshare.anonymousGuestApproval in settings.json (Impostazioni preferenze > file>) su accept, rejecto prompt (impostazione predefinita) in base alle esigenze.

• In Visual Studio impostare > Strumenti Opzioni > Live Share > "Approvazione guest anonima" su Accetta, Rifiuta o Prompt (impostazione predefinita) in base alle esigenze.

Indipendentemente da ciò, tenere presente che è consigliabile inviare solo collegamenti di invito di Live Share alle persone che si considerano attendibili.

Consentire il controllo dei comandi guest

Per consentire agli utenti guest di eseguire comandi arbitrari tramite azioni di codice ("Correzioni rapide") e CodeLens imposta l'impostazione seguente:

• In VS Code impostare liveshare.languages.allowGuestCommandControl in settings.json (Impostazioni preferenze > file>) su true o false (impostazione predefinita).

Controllo dell'accesso e della visibilità dei file

Come guest, il modello remoto di Live Share consente di accedere rapidamente ai file e alle cartelle condivisi dall'host senza dover sincronizzare l'intero contenuto di un progetto. È quindi possibile spostarsi e modificare i file in modo indipendente nell'intero albero dei file condivisi. Tuttavia, questa libertà comporta alcuni rischi per l'ospite. In concetto, uno sviluppatore potrebbe acconsentire esplicitamente all'accesso e modificare il codice sorgente senza conoscere o visualizzare il codice sorgente sensibile o i "segreti" che si trovano in un punto qualsiasi nell'albero dei file condivisi. Di conseguenza, in qualità di host, potrebbe non essere sempre necessario che il guest abbia accesso all'intero progetto che si condivide. Fortunatamente, un vantaggio aggiunto di questo modello remoto è che è possibile scegliere di "escludere" i file che non si desidera condividere con nessuno senza sacrificare la funzionalità. Gli utenti guest possono comunque partecipare a operazioni come le sessioni di debug che normalmente richiedono l'accesso a questi file se vogliono farlo autonomamente.

A tale scopo, è possibile aggiungere un file .vsls.json alla cartella o al progetto condiviso. Tutte le impostazioni aggiunte a questo file in formato JSON cambiano il modo in cui Live Share elabora i file. Oltre a fornire il controllo diretto, questi file possono anche essere impegnati nel controllo del codice sorgente, in modo che chiunque cloni un progetto sarà in grado di sfruttare queste regole senza ulteriori sforzi da parte loro.

Di seguito è riportato un esempio di file .vsls.json:

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

Nota

È anche possibile impostare tutti i file/cartelle condivisi in sola lettura all'avvio di una sessione di collaborazione. Vedere più avanti per informazioni dettagliate.

Esaminiamo come queste proprietà cambiano le operazioni che gli utenti guest possono eseguire.

Proprietà

La proprietà excludeFiles consente di specificare un elenco di modelli di file glob (molto simili a quelli trovati con estensione gitignore) che impedisce a Live Share di aprire determinati file o cartelle per gli utenti guest. Tenere presente che questo è inclusivo di scenari come un guest che segue o passa alla posizione di modifica, eseguendo istruzioni in un file durante il debug collaborativo, qualsiasi funzionalità di spostamento del codice come passare alla definizione e altro ancora. È destinato ai file che non si desidera condividere in nessun caso come quelli contenenti segreti, certificati o password. Ad esempio, poiché controllano la sicurezza, .vsls.json file vengono sempre esclusi.

La proprietà hideFiles è simile, ma non abbastanza rigida. Questi file sono semplicemente nascosti dall'albero dei file. Ad esempio, se è stato eseguito l'istruzione in uno di questi file durante il debug, viene ancora aperto nell'editor. Questa proprietà è particolarmente utile se non si dispone di un'installazione di file con estensione gitignore (come nel caso in cui si usi un sistema di controllo del codice sorgente diverso) o se si vuole semplicemente aumentare ciò che è già presente per evitare confusione o confusione.

L'impostazione gitignore stabilisce in che modo Live Share deve elaborare il contenuto dei file con estensione gitignore nelle cartelle condivise. Per impostazione predefinita, tutti i glob trovati nei file con estensione gitignore vengono considerati come se fossero specificati nella proprietà "hideFiles". Tuttavia, è possibile scegliere un comportamento diverso usando uno dei valori seguenti:

Opzione	Risultato
none	I contenuti con estensione gitignore sono visibili agli utenti guest nell'albero dei file (presupponendo che non siano filtrati in base a un'impostazione dell'editor guest).
hide	Valore predefinito. I Glob all'interno di .gitignore vengono elaborati come se fossero nella proprietà "hideFiles".
exclude	I Glob all'interno di .gitignore vengono elaborati come se fossero nella proprietà "excludeFiles".

Uno svantaggio dell'impostazione exclude è che il contenuto di cartelle come node_modules è spesso in .gitignore, ma può essere utile per eseguire l'istruzione durante il debug. Di conseguenza, Live Share supporta la possibilità di invertire una regola usando "!" nella proprietà excludeFiles. Ad esempio, questo file di .vsls.json esclude tutti gli elementi in ".gitignore" ad eccezione di node_modules:

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

Le regole di nascondi ed esclusione vengono elaborate separatamente, quindi se si desidera ancora nascondere node_modules per ridurre i disordini senza escluderlo, è possibile modificare semplicemente il file come segue:

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

.vsls.json file nelle sottocartelle

Infine, proprio come .gitignore, .vsls.json file possono essere inseriti in sottocartelle. Le regole di nascondi/esclusione vengono determinate a partire dal file .vsls.json nella cartella radice condivisa (se presente) e quindi passando attraverso ogni sottocartella da lì che porta a un determinato file per cercare .vsls.json file da elaborare. Il contenuto dei file di .vsls.json in cartelle più lontano dall'albero dei file e quindi integrare (o ignorare) regole stabilite a livelli più elevati.

Nota: non è possibile ri-includere (!) un file se viene esclusa una directory padre di tale file. Analogamente a .gitignore, quando si ri-include un file, è anche necessario includere nuovamente ogni directory padre del file.

Disabilitazione della condivisione di file esterni

Per impostazione predefinita, Live Share condividerà anche tutti i file aperti dall'host esterni alla cartella/soluzione condivisa. In questo modo è facile aprire rapidamente altri file correlati senza dover condividere di nuovo.

Se si preferisce disabilitare questa funzionalità:

• In VS Code aggiungere quanto segue a settings.json:

  "liveshare.shareExternalFiles": false
  

• In Visual Studio impostare > Strumenti Opzioni > Live Share > "Condividi file esterni" su False

Modalità di sola lettura

In alcuni casi, quando si condivide il codice come host, non si vuole che gli utenti guest esemettono modifiche. Potrebbe essere necessario che il guest esamini parte del codice oppure che il progetto venga mostrato a un numero elevato di utenti guest e che non desideri apportare modifiche non necessarie o accidentali. Live Share offre la possibilità di condividere progetti in modalità di sola lettura.

In qualità di host, quando si condivide, è possibile abilitare la modalità di sola lettura per una sessione di collaborazione. Quando un guest partecipa, non sarà in grado di apportare modifiche al codice, anche se è comunque possibile visualizzare i cursori e le evidenziazioni degli altri, nonché spostarsi nel progetto.

È comunque possibile eseguire il co-debug con gli utenti guest in modalità di sola lettura. Gli utenti guest non avranno la possibilità di eseguire il processo di debug, ma possono comunque aggiungere o rimuovere punti di interruzione e controllare le variabili. Inoltre, è comunque possibile condividere server e terminali (di sola lettura) con utenti guest.

Per altre informazioni sull'avvio di una sessione di collaborazione di sola lettura, vedere:

Debug congiunto

Quando si affrontano problemi di codifica o bug complessi, avere un paio di occhi aggiuntivi quando si esegue il debug può essere davvero utile. Visual Studio Live Share abilita il "debug collaborativo" o il "co-debug" condividendo la sessione di debug con tutti i guest ogni volta che l'host avvia il debug.

In qualità di host, si ha il controllo completo sull'avvio o l'arresto di una sessione di debug, ma il co-debug comporta alcuni rischi se si condivide con un utente non attendibile. Live Share consente agli utenti guest di invitare a eseguire comandi console/REPL e pertanto esiste il rischio che un attore malintenzionato esegua un comando che non si vuole che vengano eseguiti.

Di conseguenza, è consigliabile eseguire il co-debug solo con quelli attendibili.

Ulteriori informazioni:

Condivisione di un server locale

Durante il debug congiunto, può essere molto utile accedere a parti diverse dell'applicazione resa disponibile dall'organizzatore per la sessione di debug. È possibile che si voglia accedere all'app in un browser, accedere a un database locale o accedere a un endpoint REST dagli strumenti. Live Share consente di condividere un server che esegue il mapping di una porta locale nel computer dell'host alla stessa porta nel computer guest. Come guest, è quindi possibile interagire con l'applicazione esattamente come se fosse in esecuzione in locale nel computer (ad esempio, l'host e il guest possono accedere a un'app Web in esecuzione in http://localhost:3000).

Tuttavia, come host, è consigliabile essere molto selettivi con le porte condivise con guest e condividere solo le porte dell'applicazione piuttosto che le porte di sistema. Per i partecipanti, le porte condivise si comportano esattamente come farebbero se il server o il servizio fosse in esecuzione nel computer locale. Ciò è molto utile ma, se viene condivisa la porta sbagliata, può anche essere rischioso. Per questo motivo, Live Share non presuppone ciò che deve essere condiviso o non deve essere condiviso senza un'impostazione di configurazione e l'host che esegue un'azione.

In Visual Studio la porta dell'applicazione Web specificata nei progetti ASP.NET viene condivisa automaticamente durante il debug solo per facilitare l'accesso guest all'app Web durante l'esecuzione. Tuttavia, è possibile disattivare questa automazione impostando Strumenti > Opzioni > Live Share "Share > Web app on debug" su "False" se si preferisce.

In Visual Studio Code Live Share tenta di rilevare le porte dell'applicazione appropriate e condividerle. Tuttavia, è possibile disabilitare questa opzione aggiungendo quanto segue a settings.json:

"liveshare.autoShareServers": false

In entrambi i casi, prestare attenzione quando si condividono porte aggiuntive.

Altre informazioni sulla configurazione della funzionalità sono disponibili qui:

Condivisione di un terminale

Nello sviluppo moderno viene spesso usata un'ampia gamma di strumenti da riga di comando. Fortunatamente Live Share consente all'organizzatore di "condividere un terminale" con i partecipanti. Il terminale condiviso può essere di sola lettura o completamente collaborativo, in modo che sia l'organizzatore che i partecipanti possano eseguire i comandi e visualizzare i risultati. In qualità di host, è possibile consentire ad altri collaboratori di visualizzare solo l'output o di usare un numero qualsiasi di strumenti da riga di comando per eseguire test, compilazioni o persino valutare problemi specifici dell'ambiente.

Solo gli host possono avviare terminali condivisi per impedire agli utenti guest di avviarne uno e di eseguire qualcosa che non ci si aspetta o si sta guardando. Quando si avvia un terminale condiviso come host, è possibile specificare se deve essere di sola lettura o di lettura/scrittura. Quando il terminale è di lettura/scrittura, tutti gli utenti possono digitare nel terminale, incluso l'organizzatore, e ciò consente di intervenire più facilmente nel caso in cui un partecipante stia eseguendo un'operazione ritenuta non appropriata. Tuttavia, per sicurezza, è consigliabile concedere l'accesso in lettura/scrittura ai partecipanti solo quando è effettivamente necessario e usare terminali di sola lettura per gli scenari in cui si vuole semplicemente che il partecipante possa vedere l'output dei comandi eseguiti.

In Visual Studio i terminali non sono condivisi per impostazione predefinita. In VS Code i terminali vengono condivisi automaticamente in sola lettura per impostazione predefinita. Tuttavia, è possibile disabilitare questa opzione aggiungendo quanto segue a settings.json:

"liveshare.autoShareTerminals": false

Ulteriori informazioni:

Consenso amministratore AAD

Quando si esegue l'accesso usando un indirizzo di posta elettronica aziendale o dell'istituto di istruzione supportato da Microsoft, è possibile che venga visualizzato un messaggio che indica che è necessaria l'approvazione dell'amministratore durante l'accesso. Questo perché Live Share richiede l'accesso in lettura alle informazioni utente per le funzionalità di sicurezza e il tenant di Azure AD è configurato per richiedere il "consenso amministratore" per le nuove applicazioni che accedono al contenuto della directory.

L'amministratore di ACTIVE Directory dovrà risolvere questo problema usando le informazioni seguenti:

• Nome applicazione: Visual Studio Live Share (Insider)
• Tipo di applicazione: App Web
• Stato applicazioni: produzione
• Autorizzazioni delegate: User.Read
• URL applicazione: https://visualstudio.microsoft.com/services/live-share/
• URL di risposta: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Questa operazione deve essere eseguita una sola volta per chiunque usi Live Share. Per informazioni dettagliate, vedere qui e qui .

Vedi anche

• Installare e accedere a Live Share in Visual Studio Code
• Installare e accedere a Live Share in Visual Studio
• Requisiti di connettività per Live Share

Problemi? Vedere la risoluzione dei problemi o inviare un feedback.