Функции системы безопасности Live Share

Сеансы совместной работы в Visual Studio Live Share эффективны в том, что они позволяют любому количеству пользователей присоединяться к сеансу и совместно редактировать, отлаживать и многое другое. Однако, учитывая этот уровень доступа, вы, несомненно, будете заинтересованы в функциях безопасности Live Share. В этой статье мы предоставим некоторые рекомендации и варианты защиты среды по мере необходимости.

Как и в любом средстве совместной работы, помните, что вам следует предоставлять общий доступ только к коду, содержимому и приложениям, которым вы доверяете.

Подключение

При инициировании сеанса между одноранговыми узлами Live Share пытается установить одноранговое подключение и только в том случае, если это невозможно (например, из-за брандмауэров или NATs), он возвращается к использованию облачного ретранслятора. Однако в обоих типах подключений (P2P или ретрансляторе) все данные, передаваемые между одноранговыми узлами, шифруются с помощью протокола SSH. В случае подключения ретранслятора шифрование SSH сложено поверх tls-зашифрованных WebSockets. Это означает, что live Share не зависит от облачной службы ретрансляции для безопасности. Даже если ретранслятор был скомпрометирован, он не мог расшифровать ни одно из обмена данными Live Share.

Роль службы Live Share ограничена проверкой подлинности пользователей и обнаружением сеансов. Сама служба не хранит или когда-либо имеет доступ к содержимому сеанса. Все содержимое пользователя в Live Share передается через сеанс SSH. Это включает код, терминалы, общие серверы и любые другие функции совместной работы, предоставляемые Live Share или расширениями, которые создаются на нем.

Дополнительные сведения об изменении этих действий и требованиях к подключению Live Share см. в статье о требованиях к подключению для Live Share.

Шифрование провода

Протокол SSH использует обмен ключами Diffie-Hellman для установления общего секрета для сеанса и является производным от этого ключа для симметричного шифрования AES. Ключ шифрования периодически поворачивается на протяжении всего сеанса. Общий секрет сеанса и все ключи шифрования хранятся только в памяти обеими сторонами и действительны только в течение сеанса. Они никогда не записываются на диск или отправляются в любую службу (включая live Share).

Одноранговая проверка подлинности

Сеанс SSH также проходит двухсторонняя проверка подлинности. Роль сервера SSH использует проверку подлинности с открытым и закрытым ключом, как стандартная для протокола SSH. Когда узел предоставляет общий доступ к сеансу Live Share, он создает уникальную пару открытого и закрытого ключа RSA для сеанса. Закрытый ключ узла хранится только в памяти в процессе узла; он никогда не записывается на диск или отправляется в любую службу, включая службу Live Share. Открытый ключ узла публикуется в службе Live Share, а также сведения о подключении сеанса (IP-адрес и/или конечная точка ретрансляции), где гости могут получить доступ к нему по ссылке приглашения. Когда гость подключается к сеансу SSH узла, гость использует протокол проверки подлинности узла SSH для проверки того, что узел содержит закрытый ключ, соответствующий опубликованному открытому ключу (без того, как гость фактически получает, чтобы увидеть закрытый ключ).

Гость использует маркер Live Share для проверки подлинности себя с помощью узла. Маркер — это подписанный JWT, выданный службой Live Share, которая включает утверждения о удостоверении пользователя (полученное через MSA, AAD или вход в GitHub). Маркер также имеет утверждения, указывающие, что гость может получить доступ к определенному сеансу Live Share (так как у них была ссылка на приглашение и /или они были специально приглашены узлом). Узел проверяет, что маркер и проверка утверждения (и в зависимости от параметров может запрашивать пользователя узла), прежде чем разрешить гостевой присоединиться к сеансу.

Приглашения и доступ к присоединению

Каждый раз при запуске нового сеанса совместной работы Live Share создает новый уникальный идентификатор , размещенный по ссылке приглашения. Эти ссылки предоставляют твердый, безопасный фундамент для приглашения тех, кому вы доверяете, так как идентификатор в ссылке является "неизгадываемым" и действителен только в течение одного сеанса совместной работы.

Удаление непредвиденного гостя

В качестве узла вы автоматически уведомляетесь, когда гость присоединяется к сеансу совместной работы.

В Visual Studio Code:

В Visual Studio:

Тем не менее, уведомление дает возможность удалить гостя, присоединенного, если по какой-то причине вы не знаете их. (Например, если вы случайно опубликовали ссылку в системе чата на уровне компании и случайный сотрудник присоединился.) Просто нажмите кнопку "Удалить" в появившемся уведомлении, и они будут удалены из сеанса совместной работы.

В VS Code, даже если вы отклонили уведомление о присоединении, вы также можете удалить участника после этого. Открыв представление Live Share в Обозреватель или настраиваемой вкладке в строке действий VS Code, вы можете навести указатель мыши или щелкнуть имя участника правой кнопкой мыши и выбрать значок или параметр "Удалить участника".

Требование утверждения гостя

Как правило, участники, которые присоединяются к сеансу совместной работы, будут входить в Live Share с помощью рабочей или учебной учетной записи Майкрософт (AAD), личной учетной записи Майкрософт или учетной записи GitHub. Хотя значение по умолчанию "уведомление и удаление" для пользователей, вошедшего в систему, обеспечивает хорошее сочетание скорости и управления для этих гостей, может потребоваться заблокировать вещи немного больше, если вы делаете что-то конфиденциальное.

Кроме того, в определенных обстоятельствах, принудив всех гостей войти в сеанс совместной работы может быть проблематично. Примеры включают запрос кого-то нового в Live Share для присоединения в качестве гостя, аудитории и обучения сценариев или при совместной работе с кем-то, у кого нет одного из поддерживаемых типов учетных записей. По этим причинам Live Share может разрешить пользователям, которые не вошли в сеансы совместной работы в качестве гостей только для чтения. Хотя узел должен утвердить этих гостей, прежде чем они смогут присоединиться по умолчанию, вы можете запретить этих "анонимных" гостей или всегда утвердить их.

Требование утверждения гостя для пользователей, вошедшего в систему

Если вы хотите запретить вход гостям присоединяться к сеансам совместной работы до тех пор, пока вы не одобрили их, измените следующий параметр:

• В VS Code добавьте следующее в settings.json (параметры > файла > Параметры):

  "liveshare.guestApprovalRequired": true
  

• В Visual Studio установите для параметров Live Share > параметры > инструментов > "Требовать утверждение гостя" значение True.

  

С этого момента вам будет предложено утвердить каждого гостя, который присоединяется.

В Visual Studio Code:

В Visual Studio:

Если вы присоединяетесь к сеансу, где узел имеет этот параметр, вы получите уведомление в строке состояния или в диалоговом окне присоединения, которое live Share ожидает утверждения узла.

Автоматическое отклонение или принятие пользователей, которые не вошли (анонимные)

Как описано выше, live Share можно настроить, чтобы пользователи , которые не вошли в сеанс совместной работы в качестве гостей, доступных только для чтения. Хотя эти "анонимные" гости должны ввести имя при присоединении, простое имя не предоставляет тот же уровень гарантии, что и реальный вход. Поэтому по умолчанию узел запрашивает утверждение любого анонимного гостя независимо от параметра "требовать утверждения гостя", описанного выше.

Вы всегда можете отклонить (отключить анонимных гостей) или всегда принимать анонимных пользователей, как показано ниже.

• В VS Code задайте liveshare.anonymousGuestApproval в файле settings.json (параметры > файла > Параметры) acceptзначение , rejectили prompt (по умолчанию) в соответствии с соответствующими параметрами.

• В Visual Studio задайте для >> параметра ">Анонимный гостевой ресурс" значение "Принять, отклонить или запросить" (по умолчанию).

Независимо от того, следует помнить, что вы должны отправлять только ссылки на приглашения Live Share пользователям, которым вы доверяете.

Разрешение гостевого командного элемента управления

Чтобы разрешить гостям выполнять произвольные команды с помощью действий кода ("Быстрые исправления") и CodeLens задайте следующий параметр:

• В VS Code задайте liveshare.languages.allowGuestCommandControl значение settings.json (параметры файла >> Параметры) true или false (по умолчанию).

Управление доступом к файлам и видимостью

В качестве гостя удаленная модель Live Share обеспечивает быстрый доступ на чтение и запись к файлам и папкам, к которым узел предоставил общий доступ, не синхронизируя все содержимое проекта. Таким образом, вы можете самостоятельно перемещать и изменять файлы во всем общем дереве файлов. Однако эта свобода представляет некоторые риски для узла. В концепции разработчик может пойти и изменить исходный код без знаний или увидеть конфиденциальный исходный код или "секреты", расположенные где-то в общем дереве файлов. Следовательно, в качестве узла может не всегда потребоваться, чтобы гостевой пользователь мог иметь доступ ко всему проекту, к которому вы предоставляете общий доступ. К счастью, добавлено преимущество этой удаленной модели заключается в том, что вы можете отказаться от "исключения" файлов, которые вы не хотите делиться с кем-либо, не жертвуя функциональными возможностями. Ваши гости по-прежнему могут участвовать в таких случаях, как сеансы отладки, которые обычно требуют доступа к этим файлам, если они хотят сделать это самостоятельно.

Это можно сделать, добавив vsls.json-файл в папку или проект, к которым вы предоставляете общий доступ. Все параметры, добавляемые в этот форматированный файл json, изменяют способ обработки файлов Live Share. Помимо прямого контроля, эти файлы также могут быть зафиксированы в системе управления версиями, чтобы любой пользователь клонировать проект сможет воспользоваться этими правилами без дополнительных усилий со своей стороны.

Ниже приведен пример VSLS.json-файла:

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

Примечание.

При запуске сеанса совместной работы можно также сделать все файлы и папки, к которым вы используете общий доступ только для чтения. Подробные сведения см. ниже.

Давайте рассмотрим, как эти свойства изменяют возможности гостей.

Свойства

Свойство excludeFiles позволяет указать список шаблонов файлов GLOB (очень похожих на найденные файлы .gitignore), который предотвращает открытие определенных файлов или папок live Share для гостей. Имейте в виду, что это включает в себя такие сценарии, как гостевой пользователь или переход к расположению редактирования, переход к файлу во время совместной отладки, любые функции навигации по коду, такие как переход к определению, и многое другое. Он предназначен для файлов, к которым вы никогда не хотите предоставлять общий доступ при любых обстоятельствах, таких как содержащие секреты, сертификаты или пароли. Например, так как они управляют безопасностью, vsls.json-файлы всегда исключаются.

Свойство hideFiles аналогично, но не совсем так строго. Эти файлы просто скрыты из дерева файлов. Например, если во время отладки произошел шаг в один из этих файлов, он по-прежнему открыт в редакторе. Это свойство в первую очередь полезно, если у вас нет установки файла .gitignore (как и в случае, если вы используете другую систему управления версиями) или если вы просто хотите расширить то, что уже есть, чтобы избежать загромождений или путаницы.

Параметр gitignore определяет, как Live Share должен обрабатывать содержимое файлов gitignore в общих папках. По умолчанию любые глобы, найденные в файлах gitignore, обрабатываются так, как если бы они были указаны в свойстве hideFiles. Однако можно выбрать другое поведение, используя одно из следующих значений:

Параметр	Результат
none	Содержимое .gitignore отображается гостям в дереве файлов (если они не фильтруются с помощью параметра гостевого редактора).
hide	По умолчанию. Globs внутри .gitignore обрабатываются, как если бы они были в свойстве "hideFiles".
exclude	Globs внутри .gitignore обрабатываются, как если бы они были в свойстве "excludeFiles".

exclude Недостатком параметра является то, что содержимое папок, таких как node_modules, часто находится в .gitignore, но может быть полезным для перехода во время отладки. Следовательно, Live Share поддерживает возможность отмены правила с помощью "!" в свойстве excludeFiles. Например, этот vsls.json-файл исключит все в файле .gitignore, кроме node_modules:

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

Правила скрытия и исключения обрабатываются отдельно, поэтому если вы по-прежнему хотели скрыть node_modules, чтобы уменьшить беспорядок, не исключая его, можно просто изменить файл следующим образом:

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

VSLS.JSON-файлы в вложенных папках

Наконец, так же, как gitignore, vsls.json-файлы можно поместить в вложенные папки. Правила скрытия и исключения определяются путем запуска файла VSLS.json в корневой папке, к которой вы предоставили общий доступ (если присутствует), а затем проходите по каждой вложенной папке оттуда, что приводит к заданному файлу для поиска файлов VSLS.json для обработки. Содержимое файлов VSLS.JSON в папках дальше вниз по дереву файлов, а затем дополняет правила (или переопределяют), установленные на более высоких уровнях.

Примечание. Невозможно повторно включить файл (!), если родительский каталог этого файла исключен. Аналогично gitignore при повторном включении файла, вам также потребуется повторно включить каждый родительский каталог файла.

Отключение общего доступа к внешним файлам

По умолчанию Live Share также предоставляет общий доступ к файлам, открываемым узлом, которые являются внешними для общей папки или решения. Это упрощает быстрое открытие других связанных файлов без необходимости повторного использования.

Если вы предпочитаете отключить эту функцию:

• В VS Code добавьте следующее в settings.json:

  "liveshare.shareExternalFiles": false
  

• В Visual Studio задайте > для параметров > live Share > "Общий доступ к внешним файлам" значение False

Режим только для чтения

Иногда при совместном использовании кода в качестве узла гости не хотят вносить изменения. Возможно, вам потребуется, чтобы ваш гость посмотрел на некоторый код, или вы показываете проект большому количеству гостей и не хотите, чтобы какие-либо ненужные или случайные изменения были сделаны. Live Share предоставляет возможность совместного использования проектов в режиме только для чтения.

В качестве узла при совместном использовании у вас есть возможность включить режим только для чтения для сеанса совместной работы. При присоединении гостей они не смогут вносить изменения в код, хотя вы по-прежнему можете видеть курсоры и выделения друг друга, а также перемещаться по проекту.

Вы по-прежнему можете совместно выполнять отладку с гостями в режиме только для чтения. Гости не смогут выполнять шаги по процессу отладки, но по-прежнему могут добавлять или удалять точки останова и проверять переменные. Кроме того, вы по-прежнему можете совместно использовать серверы и терминалы (только для чтения) с гостями.

Дополнительные сведения о запуске сеанса совместной работы только для чтения:

Совместная отладка

Когда вы решаете сложные проблемы программирования или ошибки, наличие дополнительной пары глаз при отладке может быть действительно полезно. Visual Studio Live Share включает "совместную отладку" или "совместное отладку", предоставляя общий доступ к сеансу отладки всем гостям при запуске отладки узла.

В качестве узла вы полностью управляете при запуске или остановке сеанса отладки, но совместное отладка представляет некоторые риски, если вы предоставляете общий доступ к кому-то, кому вы не доверяете. Live Share позволяет гостям запускать команды консоли или REPL, поэтому риск выполнения вредоносных субъектов, выполняющих команду, не требуется.

Следовательно, следует совместно выполнять отладку только с доверенными.

Подробнее:

Общий доступ к локальному серверу

Крайне полезная функция при совместной отладке — доступ к разным частям приложения, предоставляемый организатором сеанса. Возможно, вы захотите открыть приложение в браузере, подключиться к локальной базе данных или к конечной точке REST из своих инструментов. Live Share позволяет "поделиться сервером", который сопоставляет локальный порт на компьютере узла с тем же портом на гостевом компьютере. В качестве гостя вы можете взаимодействовать с приложением точно так же, как если бы он работал локально на компьютере (например, узел и гость могут получить доступ к веб-приложению, запущенному на компьютере. http://localhost:3000).

Тем не менее, как узел, вы должны быть очень выборочными с портами, которыми вы предоставляете общий доступ к гостям, и использовать только порты приложений, а не системные порты. Для гостей предоставленные в общий доступ порты будут вести себя точно так же, как если бы этот сервер или служба были запущены прямо на их компьютере. Это очень полезно, но неудачный выбор порта может создать серьезные риски. По этой причине live Share не делает никаких предположений о том, что следует или не следует предоставлять общий доступ без параметра конфигурации и узла, выполняющего действие.

В Visual Studio порт веб-приложения, указанный в ASP.NET проектах, автоматически предоставляется во время отладки только для упрощения гостевого доступа к веб-приложению при запуске. Однако вы можете отключить эту автоматизацию, задав >> параметры live Share > "Общий веб-приложение для отладки" значение False, если вы предпочитаете.

В Visual Studio Code live Share пытается обнаружить соответствующие порты приложений и предоставить им общий доступ. Однако это можно отключить, добавив следующее в settings.json:

"liveshare.autoShareServers": false

В любом случае при совместном использовании дополнительных портов необходимо соблюдать осторожность.

Дополнительные сведения о настройке функции см. здесь:

Общий доступ к терминалу

В современной разработке часто используется обширный ряд инструментов командной строки. Расширение Live Share позволяет организатору при необходимости поделиться терминалом с гостями. Общий терминал может быть доступен только для чтения или полностью со всеми функциями совместной работы, чтобы и вы, и гости могли выполнять команды и просматривать результаты. Как узел, вы можете разрешить другим участникам совместной работы только видеть выходные данные или использовать любое количество средств командной строки для выполнения тестов, сборок или даже проблем с конкретной средой.

Только узлы могут запускать общие терминалы, чтобы предотвратить запуск одного и делать что-то, что вы не ожидаете или просматриваете. При запуске общего терминала в качестве узла можно указать, следует ли использовать только для чтения или чтения или записи. Если терминал открыт в режиме чтения и записи, ввод в него может осуществлять любой участник, в том числе и сам организатор, что позволяет быстро вмешаться в любые нежелательные действия гостя. Но не забывайте, что в целях безопасности следует предоставлять гостям доступ на чтение и запись только в том случае, когда это действительно необходимо. Для всех сценариев, когда гостям нужны только выходные данные выполняемых команд, ограничьтесь терминалом только для чтения.

В Visual Studio терминалы по умолчанию не используются. В VS Code терминалы автоматически предоставляют доступ только для чтения по умолчанию. Однако это можно отключить, добавив следующее в settings.json:

"liveshare.autoShareTerminals": false

Подробнее:

Согласие Администратор AAD

При входе с помощью рабочего или учебного адреса электронной почты Майкрософт может отображаться сообщение "Требуется утверждение администратора" при входе. Это связано с тем, что Для live Share требуется доступ на чтение к сведениям о пользователях для его функций безопасности, а клиент Azure AD настроен, чтобы требовать "согласие администратора" для новых приложений, обращаюющихся к содержимому каталога.

Администратор AD должен устранить эту проблему, используя следующие сведения:

• Имя приложения: Visual Studio Live Share (insiders)
• Тип приложения: веб-приложение
• Состояние приложений: рабочая среда
• Делегированные разрешения: User.Read
• URL-адрес приложения: https://visualstudio.microsoft.com/services/live-share/
• URL-адреса ответа: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

Это необходимо сделать только один раз для тех, кто использует Live Share. Дополнительные сведения см . здесь и здесь .

См. также

• Установка и вход в Live Share в Visual Studio Code
• Установка и вход в Live Share в Visual Studio
• Требования к подключению для Live Share

Возникли проблемы? Ознакомьтесь с разделом по устранению неполадок или отправьте отзыв.