Funkcje zabezpieczeń rozszerzenia Live Share

Sesje współpracy w programie Visual Studio Live Share są zaawansowane, dzięki czemu dowolna liczba osób może dołączyć do sesji i wspólnie edytować, debugować i nie tylko. Jednak biorąc pod uwagę ten poziom dostępu, bez wątpienia będziesz zainteresowany funkcjami zabezpieczeń udostępnianymi w usłudze Live Share. W tym artykule udostępnimy kilka zaleceń i opcji zabezpieczania środowiska zgodnie z potrzebami.

Podobnie jak w przypadku dowolnego narzędzia do współpracy, pamiętaj, że należy udostępniać kod, zawartość i aplikacje tylko osobom, którym ufasz.

Łączność

Podczas inicjowania sesji między elementami równorzędnymi usługa Live Share próbuje ustanowić połączenie równorzędne i tylko wtedy, gdy nie jest to możliwe (np. z powodu zapór/nats), czy wraca do korzystania z przekaźnika w chmurze. Jednak w obu typach połączeń (P2P lub przekaźniku) wszystkie dane przesyłane między elementami równorzędnymi są szyfrowane kompleksowo przy użyciu protokołu SSH. W przypadku połączenia przekaźnika szyfrowanie SSH jest warstwowe na podstawie szyfrowanych protokołem TLS obiektów WebSocket. Oznacza to, że usługa Live Share nie zależy od usługi przekazywania w chmurze na potrzeby zabezpieczeń. Nawet jeśli przekaźnik został naruszony, nie może odszyfrować żadnej komunikacji z usługą Live Share.

Rola usługi Live Share jest ograniczona do uwierzytelniania użytkowników i odnajdywania sesji. Sama usługa nie przechowuje ani nigdy nie ma dostępu do żadnej zawartości sesji. Cała zawartość użytkownika w usłudze Live Share jest przesyłana za pośrednictwem sesji SSH. Obejmuje to kod, terminale, serwery udostępnione i wszelkie inne funkcje współpracy udostępniane przez usługę Live Share lub rozszerzenia, które na nim bazują.

Aby dowiedzieć się więcej na temat zmiany tych zachowań i wymagań dotyczących łączności usługi Live Share, zobacz wymagania dotyczące łączności dla usługi Live Share.

Szyfrowanie przewodu

Protokół SSH używa wymiany kluczy Diffie-Hellman w celu ustanowienia wspólnego wpisu tajnego dla sesji i pochodzi z tego klucza dla szyfrowania symetrycznego AES. Klucz szyfrowania jest okresowo obracany przez cały czas trwania sesji. Wspólny klucz tajny sesji i wszystkie klucze szyfrowania są przechowywane tylko w pamięci przez obie strony i są prawidłowe tylko przez czas trwania sesji. Nigdy nie są zapisywane na dysku ani wysyłane do żadnej usługi (w tym live share).

Uwierzytelnianie równorzędne

Sesja SSH jest również uwierzytelniana dwukierunkowo. Host (rola serwera SSH) używa uwierzytelniania za pomocą klucza publicznego/prywatnego, co jest standardem dla protokołu SSH. Gdy host udostępnia sesję live share, generuje unikatową parę kluczy publicznych/prywatnych RSA dla sesji. Klucz prywatny hosta jest przechowywany tylko w pamięci w procesie hosta; nigdy nie jest zapisywany na dysku ani wysyłany do żadnej usługi, w tym do usługi Live Share. Klucz publiczny hosta jest publikowany w usłudze Live Share wraz z informacjami o połączeniu sesji (adres IP i/lub punkt końcowy przekaźnika), gdzie goście mogą uzyskać do niego dostęp za pośrednictwem linku zaproszenia. Gdy gość łączy się z sesją SSH hosta, gość używa protokołu uwierzytelniania hosta SSH, aby sprawdzić, czy host posiada klucz prywatny odpowiadający opublikowanemu kluczowi publicznemu (bez rzeczywistego uzyskania dostępu gościa do wyświetlenia klucza prywatnego).

Gość używa tokenu live share do uwierzytelniania się za pomocą hosta. Token jest podpisanym zestawem JWT wystawionym przez usługę Live Share, która zawiera oświadczenia dotyczące tożsamości użytkownika (uzyskane za pośrednictwem logowania MSA, AAD lub GitHub). Token zawiera również oświadczenia wskazujące, że gość może uzyskać dostęp do tej konkretnej sesji live share (ponieważ mieli link zaproszenia i/lub zostali specjalnie zaproszeni przez hosta). Host sprawdza, czy token i sprawdza oświadczenia (i w zależności od opcji może monitować użytkownika hosta) przed zezwoleniem gościowi na dołączenie do sesji.

Zaproszenia i dostęp do dołączania

Za każdym razem, gdy rozpoczynasz nową sesję współpracy, usługa Live Share generuje nowy unikatowy identyfikator umieszczony w linku zaproszenia. Te linki zapewniają solidną, bezpieczną podstawę do zapraszania zaufanych osób, ponieważ identyfikator w linku jest "nie do odgadnięcia" i jest ważny tylko przez czas trwania jednej sesji współpracy.

Usuwanie nieoczekiwanego gościa

Jako host jest automatycznie powiadamiany za każdym razem, gdy gość dołączy do sesji współpracy.

W programie Visual Studio Code:

W programie Visual Studio:

Jeszcze lepiej, powiadomienie daje możliwość usunięcia gościa, który dołączył, jeśli z jakiegoś powodu ich nie znasz. (Jeśli na przykład przypadkowo wysłano link w systemie czatów w całej firmie i dołączono do losowego pracownika). Po prostu kliknij przycisk "Usuń" w wyświetlonym powiadomieniu i zostanie on wyrzucony z sesji współpracy.

W programie VS Code, nawet jeśli odrzucono powiadomienie o dołączeniu, masz również możliwość usunięcia uczestnika po tym. Otwierając widok Live Share w Eksploratorze lub na karcie niestandardowej na pasku działań programu VS Code, możesz zatrzymać wskaźnik myszy lub kliknąć prawym przyciskiem myszy nazwę uczestnika i wybrać ikonę lub opcję "Usuń uczestnika".

Wymaganie zatwierdzenia gościa

Zazwyczaj uczestnicy, którzy dołączają do sesji współpracy, zostaną zalogowani do usługi Live Share przy użyciu konta służbowego Microsoft (AAD), osobistego konta Microsoft lub konta Usługi GitHub. Podczas gdy domyślne "powiadomienie + usuwanie" dla zalogowanych użytkowników zapewnia dobrą kombinację szybkości i kontroli dla tych gości, możesz chcieć zablokować rzeczy nieco więcej, jeśli robisz coś wrażliwego.

Ponadto w pewnych okolicznościach zmuszanie wszystkich gości do zalogowania się w celu dołączenia do sesji współpracy może być problematyczne. Przykłady obejmują prośbę o dołączenie do usługi Live Share jako gościa, scenariuszy zajęć/uczenia się lub współpracy z osobą, która nie ma jednego z obsługiwanych typów kont. Z tych powodów usługa Live Share może zezwalać użytkownikom, którzy nie są zalogowani w celu dołączenia do sesji współpracy jako goście tylko do odczytu. Mimo że gospodarz musi zatwierdzić tych gości, zanim będą mogli domyślnie dołączyć, możesz chcieć nie zezwalać na tych "anonimowych" gości lub zawsze je zatwierdzać.

Wymaganie zatwierdzenia gościa dla zalogowanych użytkowników

Jeśli chcesz uniemożliwić zalogowanym gościom dołączanie do sesji współpracy do momentu ich zatwierdzenia, zmień następujące ustawienie:

• W programie VS Code dodaj następujące elementy do settings.json (Ustawienia preferencji > pliku>):

  "liveshare.guestApprovalRequired": true
  

• W programie Visual Studio ustaw opcję Narzędzia > Opcje > udziału na żywo > "Wymagaj zatwierdzenia gościa" na wartość True.

  

Od tego momentu zostanie wyświetlony monit o zatwierdzenie każdego gościa, który dołącza.

W programie Visual Studio Code:

W programie Visual Studio:

Jako gość, jeśli dołączysz do sesji, w której host ma to ustawienie włączone, otrzymasz powiadomienie na pasku stanu lub oknie dialogowym dołączania, że live share oczekuje na zatwierdzenie na hoście.

Automatyczne odrzucanie lub akceptowanie użytkowników, którzy nie są zalogowani (anonimowi)

Zgodnie z powyższym opisem można skonfigurować usługę Live Share tak, aby umożliwić użytkownikom, którzy nie są zalogowani w celu dołączenia do sesji współpracy jako goście tylko do odczytu. Podczas gdy ci "anonimowi" goście muszą wprowadzić nazwę podczas dołączania, prosta nazwa nie zapewnia takiego samego poziomu pewności, jak podczas logowania rzeczywistego. W związku z tym domyślnie host jest monitowany o zatwierdzenie dowolnego anonimowego gościa niezależnie od ustawienia "wymagaj zatwierdzenia gościa" opisanego powyżej.

Zawsze można odrzucić (wyłączyć anonimowych gości) lub zawsze akceptować anonimowych użytkowników w następujący sposób:

• W programie VS Code ustaw liveshare.anonymousGuestApproval w settings.json (ustawienia preferencji > pliku>) na accept, rejectlub prompt (wartość domyślna), zgodnie z potrzebami.

• W programie Visual Studio ustaw opcję Narzędzia > Opcje > na żywo Udostępnij > na żywo "Anonimowe zatwierdzenie gościa" na wartość Akceptuj, Odrzuć lub Monituj (ustawienie domyślne) odpowiednio.

Niezależnie od tego należy pamiętać, że należy wysyłać tylko linki z zaproszeniem na żywo do osób, którym ufasz.

Zezwalanie na sterowanie poleceniami gościa

Aby zezwolić gościom na uruchamianie dowolnych poleceń za pomocą akcji kodu ("Szybkie poprawki") i funkcji CodeLens, ustaw następujące ustawienie:

• W programie VS Code ustaw liveshare.languages.allowGuestCommandControl w settings.json (ustawienia preferencji > pliku>) na true lub false (wartość domyślna).

Kontrolowanie dostępu do plików i widoczności

Jako gość model zdalny usługi Live Share zapewnia szybki dostęp do odczytu/zapisu do plików i folderów, które host udostępnił Tobie bez konieczności synchronizowania całej zawartości projektu. W związku z tym można niezależnie nawigować i edytować pliki w całym udostępnionym drzewie plików. Jednak ta wolność stanowi pewne zagrożenie dla hosta. W koncepcji deweloper może zdecydować się na przejście i zmodyfikowanie kodu źródłowego bez wiedzy lub wyświetlenia poufnego kodu źródłowego lub "wpisów tajnych" znajdujących się gdzieś w udostępnionym drzewie plików. W związku z tym jako host możesz nie zawsze chcieć, aby gość miał dostęp do całego udostępnianego projektu. Na szczęście dodatkową zaletą tego modelu zdalnego jest to, że możesz zdecydować się na "wykluczenie" plików, które nie chcesz udostępniać nikomu bez poświęcania funkcji. Goście mogą nadal uczestniczyć w takich sytuacjach jak sesje debugowania, które zwykle wymagają dostępu do tych plików, jeśli chcą to zrobić samodzielnie.

Można to zrobić, dodając plik .vsls.json do folderu lub projektu, który udostępniasz. Wszystkie ustawienia dodawane do tego pliku sformatowanego w formacie JSON zmieniają sposób przetwarzania plików w usłudze Live Share. Oprócz zapewnienia bezpośredniej kontroli, te pliki można również zobowiązać do kontroli źródła, aby każdy klonowanie projektu mógł korzystać z tych reguł bez dodatkowych wysiłków w ich części.

Oto przykładowy plik .vsls.json:

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

Uwaga

Możesz również ustawić wszystkie pliki/foldery, które udostępniasz tylko do odczytu podczas rozpoczynania sesji współpracy. Aby uzyskać szczegółowe informacje, zobacz poniżej .

Przyjrzyjmy się, jak te właściwości zmieniają to, co mogą zrobić goście.

Właściwości

Właściwość excludeFiles umożliwia określenie listy wzorców plików glob (podobnie jak pliki .gitignore), które uniemożliwiają otwarcie niektórych plików lub folderów dla gości w usłudze Live Share. Należy pamiętać, że obejmuje to scenariusze, takie jak gość po lub przechodzenie do lokalizacji edycji, przechodzenie do pliku podczas wspólnego debugowania, wszystkie funkcje nawigacji kodu, takie jak przechodzenie do definicji i nie tylko. Jest ona przeznaczona dla plików, które nigdy nie mają być udostępniane w żadnych okolicznościach, takich jak te zawierające wpisy tajne, certyfikaty lub hasła. Na przykład ponieważ kontrolują zabezpieczenia, .vsls.json pliki są zawsze wykluczane.

Właściwość hideFiles jest podobna, ale nie jest tak ścisła. Te pliki są po prostu ukryte w drzewie plików. Jeśli na przykład nastąpiło przejście do jednego z tych plików podczas debugowania, nadal jest on otwarty w edytorze. Ta właściwość jest szczególnie przydatna, jeśli nie masz konfiguracji pliku gitignore (tak jak w przypadku korzystania z innego systemu kontroli źródła) lub jeśli po prostu chcesz rozszerzyć to, co już istnieje, aby uniknąć bałaganu lub pomyłek.

Ustawienie gitignore określa sposób przetwarzania zawartości plików gitignore w folderach udostępnionych w usłudze Live Share. Domyślnie wszystkie globy znalezione w plikach gitignore są traktowane tak, jakby zostały określone we właściwości "hideFiles". Można jednak wybrać inne zachowanie przy użyciu jednej z następujących wartości:

Opcja	Wynik
none	Zawartość .gitignore jest widoczna dla gości w drzewie plików (przy założeniu, że nie są filtrowane przez ustawienie edytora gościa).
hide	Domyślnie. Globy wewnątrz pliku .gitignore są przetwarzane tak, jakby znajdowały się we właściwości "hideFiles".
exclude	Globs wewnątrz .gitignore są przetwarzane tak, jakby znajdowały się we właściwości "excludeFiles".

Wadą exclude ustawienia jest to, że zawartość folderów, takich jak node_modules, są często w pliku gitignore, ale może być przydatna do przechodzenia do podczas debugowania. W związku z tym usługa Live Share obsługuje możliwość odwrócenia reguły przy użyciu elementu "!" we właściwości excludeFiles. Na przykład ten plik .vsls.json wykluczałby wszystkie elementy w pliku ".gitignore" z wyjątkiem node_modules:

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

Reguły ukrywania i wykluczania są przetwarzane oddzielnie, więc jeśli nadal chcesz ukryć node_modules w celu zmniejszenia bałaganu bez wykluczania go, możesz po prostu edytować plik w następujący sposób:

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

.vsls.json plików w podfolderach

Na koniec, podobnie jak .gitignore, pliki .vsls.json można umieścić w podfolderach. Reguły ukrywania/wykluczania są określane przez rozpoczęcie od pliku .vsls.json w folderze głównym, który został udostępniony (jeśli istnieje), a następnie przechodząc do każdego podfolderu, co prowadzi do wyszukania .vsls.json plików do przetworzenia. Zawartość plików .vsls.json w folderach dalej w dół drzewa plików, a następnie uzupełnić (lub zastąpić) reguły ustanowione na wyższych poziomach.

Uwaga: nie można ponownie dołączyć pliku (!), jeśli zostanie wykluczony katalog nadrzędny tego pliku. Podobnie jak w przypadku pliku gitignore, podczas ponownego dołączania pliku należy również ponownie dołączyć każdy katalog nadrzędny pliku.

Wyłączanie udostępniania plików zewnętrznych

Domyślnie usługa Live Share będzie również udostępniać wszystkie pliki otwierane przez hosta, które są zewnętrzne dla folderu udostępnionego/rozwiązania. Ułatwia to szybkie otwieranie innych powiązanych plików bez konieczności ponownego udostępniania.

Jeśli wolisz wyłączyć tę funkcję:

• W programie VS Code dodaj następujące elementy do settings.json:

  "liveshare.shareExternalFiles": false
  

• W programie Visual Studio ustaw opcje > narzędzi > Live Share > "Udostępnij pliki zewnętrzne" na wartość False

Tryb tylko do odczytu

Czasami, gdy udostępniasz kod jako host, nie chcesz, aby goście wprowadzali zmiany. Może być potrzebny gość, aby przyjrzeć się niektórym kodom lub pokazać projekt dużej liczbie gości i nie chcesz wprowadzać żadnych niepotrzebnych lub przypadkowych zmian. Funkcja Live Share umożliwia udostępnianie projektów w trybie tylko do odczytu.

Jako host podczas udostępniania masz możliwość włączenia trybu tylko do odczytu dla sesji współpracy. Po dołączeniu gościa nie będą mogli wprowadzać zmian w kodzie, ale nadal można zobaczyć kursory i wyróżnienia, a także przechodzić przez projekt.

Nadal można współ debugować z gośćmi w trybie tylko do odczytu. Goście nie będą mogli przechodzić przez proces debugowania, ale nadal mogą dodawać lub usuwać punkty przerwania i sprawdzać zmienne. Ponadto nadal można udostępniać serwery i terminale (tylko do odczytu) gościom.

Więcej informacji na temat rozpoczynania sesji współpracy tylko do odczytu:

Wspólne debugowanie

Podczas rozwiązywania trudnych problemów z kodowaniem lub usterek, posiadanie dodatkowej pary oczu, gdy debugowanie może być naprawdę przydatne. Program Visual Studio Live Share umożliwia "wspólne debugowanie" lub "współ debugowanie", udostępniając sesję debugowania wszystkim gościom za każdym razem, gdy host rozpoczyna debugowanie.

Jako host masz pełną kontrolę nad uruchamianiem lub zatrzymywaniem sesji debugowania, ale współ debugowanie stwarza pewne ryzyko, jeśli udostępniasz komuś, komu nie ufasz. Usługa Live Share umożliwia gościom zapraszanie do uruchamiania poleceń konsoli/REPL, dlatego istnieje ryzyko, że złośliwy aktor uruchamia polecenie, którego nie chcesz uruchamiać.

W związku z tym należy współ debugować tylko te, którym ufasz.

Dowiedz się więcej:

Udostępnianie serwera lokalnego

Podczas wspólnego debugowania bardzo przydatny może być dostęp do różnych części aplikacji obsługiwanych przez gospodarza w sesji debugowania. Możesz uzyskać dostęp do aplikacji w przeglądarce, uzyskać dostęp do lokalnej bazy danych lub użyć punktu końcowego REST z poziomu narzędzi. Usługa Live Share umożliwia "udostępnianie serwera", który mapuje port lokalny na maszynie hosta na dokładnie ten sam port na maszynie gościa. Jako gość możesz wtedy wchodzić w interakcje z aplikacją dokładnie tak, jakby była uruchomiona lokalnie na maszynie (np. host i gość mogą uzyskiwać dostęp do aplikacji internetowej uruchomionej na http://localhost:3000).

Jednak jako host należy bardzo selektywnie wybierać porty, które udostępniasz gościom i współużytkować tylko porty aplikacji, a nie porty systemowe. W przypadku gości współużytkowane porty będą zachowywać się dokładnie tak, jakby serwer/usługa była uruchomiona na własnej maszynie. Jest to bardzo przydatne, ale jeśli niewłaściwy port jest współużytkowany, może być również ryzykowny. Z tego powodu usługa Live Share nie przyjmuje żadnych założeń dotyczących tego, co powinno być udostępniane lub nie powinno być udostępniane bez ustawienia konfiguracji i hosta wykonującego akcję.

W programie Visual Studio port aplikacji internetowej określony w projektach ASP.NET jest automatycznie udostępniany podczas debugowania tylko w celu ułatwienia dostępu gościa do aplikacji internetowej podczas uruchamiania. Można jednak wyłączyć tę automatyzację, ustawiając opcję Narzędzia > Opcje > Live Share > "Udostępnij aplikację internetową podczas debugowania" na wartość "Fałsz", jeśli wolisz.

W programie Visual Studio Code usługa Live Share próbuje wykryć odpowiednie porty aplikacji i udostępnić je. Można to jednak wyłączyć, dodając następujące elementy do settings.json:

"liveshare.autoShareServers": false

W obu przypadkach należy zachować ostrożność podczas udostępniania dodatkowych portów.

Więcej informacji na temat konfigurowania funkcji można znaleźć tutaj:

Udostępnianie terminalu

We współczesnym procesie tworzenia często jest używana szeroka gama narzędzi wiersza polecenia. Funkcja Live Share umożliwia gospodarzowi opcjonalnie udostępnić terminal gościom. Udostępniony terminal może być tylko do odczytu lub w pełni współpracować, dzięki czemu zarówno Ty, jak i goście mogą uruchamiać polecenia i wyświetlać wyniki. Jako host możesz zezwolić innym współpracownikom na wyświetlanie danych wyjściowych lub używanie dowolnej liczby narzędzi wiersza polecenia do uruchamiania testów, kompilacji, a nawet klasyfikacji problemów specyficznych dla środowiska.

Tylko hosty mogą uruchamiać udostępnione terminale, aby uniemożliwić gościom uruchamianie jednego i robienie czegoś, czego nie oczekujesz ani nie oglądasz. Po uruchomieniu udostępnionego terminalu jako hosta można określić, czy ma być tylko do odczytu, czy do odczytu/zapisu. Gdy terminal jest odczytywany/zapisywany, każdy może wpisać terminal, w tym hosta, co ułatwia interweniowanie, jeśli gość robi coś, czego nie lubisz. Jednak aby zapewnić bezpieczeństwo, należy przyznać gościom dostęp tylko do odczytu/zapisu, gdy wiadomo, że rzeczywiście go potrzebują i trzymać się terminali tylko do odczytu w scenariuszach, w których tylko gość ma wyświetlać dane wyjściowe wszystkich uruchomionych poleceń.

W programie Visual Studio terminale nie są domyślnie udostępniane. W programie VS Code terminale są domyślnie automatycznie udostępniane tylko do odczytu. Można to jednak wyłączyć, dodając następujące elementy do settings.json:

"liveshare.autoShareTerminals": false

Dowiedz się więcej:

Zgoda administratora usługi AAD

Podczas logowania się przy użyciu służbowego adresu e-mail firmy Microsoft może zostać wyświetlony komunikat "Potrzebujesz zatwierdzenia przez administratora" podczas logowania. Jest to spowodowane tym, że usługa Live Share wymaga dostępu do odczytu do informacji o użytkowniku dla jej funkcji zabezpieczeń, a dzierżawa usługi Azure AD jest skonfigurowana tak, aby wymagać "zgody administratora" dla nowych aplikacji, które uzyskują dostęp do zawartości katalogu.

Administrator usługi AD musi rozwiązać ten problem, korzystając z następujących informacji:

• Nazwa aplikacji: Visual Studio Live Share (niejawni testerzy)
• Typ aplikacji: Aplikacja internetowa
• Stan aplikacji: Produkcja
• Uprawnienia delegowane: User.Read
• Adres URL aplikacji: https://visualstudio.microsoft.com/services/live-share/
• Adres URL odpowiedzi: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Należy to zrobić tylko raz dla wszystkich użytkowników korzystających z usługi Live Share. Aby uzyskać szczegółowe informacje, zobacz tutaj i tutaj .

Zobacz też

• Instalowanie i logowanie się do usługi Live Share w programie Visual Studio Code
• Instalowanie i logowanie do usługi Live Share w programie Visual Studio
• Wymagania dotyczące łączności dla rozszerzenia Live Share

Masz problemy? Przejdź do strony rozwiązywania problemów lub przekaż opinię.