セキュリティ - Live Share

[アーティクル]
04/18/2023

Visual Studio Live Share のコラボレーションセッションは、任意の数のユーザーがセッションに参加し、編集やデバッグなどを共同で行えるという点で強力です。しかし、このレベルのアクセスを考えると、Live Share で提供されるセキュリティ機能に関心をお持ちになるに違いありません。この記事では、環境を必要に応じてセキュリティで保護するための推奨事項とオプションについて説明します。

他のコラボレーションツールと同様、コード、コンテンツ、アプリケーションは、信頼できるユーザーとのみ共有するようにしてください。

接続

ピア間のセッションを開始すると、Live Share はピアツーピア接続の確立を試み、それが不可能な場合 (ファイアウォールや NAT などにより) にのみ、フォールバックしてクラウドリレーを使用します。ただし、どちらの接続の種類 (P2P またはリレー) でも、ピア間で送信されるすべてのデータは、SSH プロトコルを使用してエンドツーエンドで暗号化されます。リレー接続の場合、SSH 暗号化は、TLS で暗号化された WebSocket の上位に階層化されます。これは、Live Share がセキュリティの点でクラウドリレーサービスに依存しないことを意味します。リレーが侵害された場合でも、Live Share 通信の暗号化を解除することはできません。

Live Share サービスの役割は、ユーザー認証とセッション検出に限定されます。このサービス自体は、セッションのコンテンツを格納したり、それにアクセスしたりすることはありません。 Live Share 内のすべてのユーザーコンテンツは、SSH セッションを介して送信されます。これには、コード、ターミナル、共有サーバー、および Live Share またはその上に構築される拡張機能によって提供されるその他のコラボレーション機能が含まれます。

これらの動作の変更と Live Share の接続要件の詳細については、「Live Share の接続性要件」を参照してください。

ワイヤ暗号化

SSH プロトコルは、Diffie-Hellman キー交換を使用してセッションの共有シークレットを確立し、AES 対称暗号化のキーから派生します。この暗号化キーは、セッションの間、定期的にローテーションされます。共有セッションシークレットとすべての暗号化キーは、両方の側によってメモリ内でのみ保持され、そのセッションの間のみ有効です。それらがディスクに書き込まれることや、サービス (Live Share を含む) に送信されることはありません。

ピア認証

SSH セッションも 2 つの方法で認証されます。ホスト (SSH サーバーロール) では、SSH プロトコルで標準的な、公開キーと秘密キーによる認証を使用します。ホストが Live Share セッションを共有すると、そのセッションに対して一意の RSA 公開キーと秘密キーのペアが生成されます。ホストの秘密キーは、ホストプロセス内のメモリにのみ保持されます。これは、ディスクに書き込まれることも、Live Share サービスを含むサービスに送信されることもありません。ホストの公開キーは、セッション接続情報 (IP アドレスやリレーエンドポイント) と共に Live Share サービスに公開され、ゲストは招待リンクを使用してこの情報にアクセスできます。ゲストは、ホストの SSH セッションに接続するときに、SSH ホスト認証プロトコルを使用して、公開された公開キーに対応する秘密キーをホストが保持していることを検証します (ゲストが実際に秘密キーを確認することはありません)。

ゲストは、Live Share トークンを使用してホストで自身を認証します。このトークンは、Live Share サービスによって発行された署名付き JWT であり、ユーザー ID (MSA、AAD、または GitHub サインインを使用して取得したもの) に関する要求が含まれます。また、このトークンには、ゲストに特定の Live Share セッションへのアクセスが許可されている (招待リンクがあるか、またはホストによって明示的に招待されているため) ことを示す要求も含まれています。ホストは、そのトークンを検証し、要求を確認し (オプションによってはホストユーザーにプロンプトが表示される場合があります)、ゲストがセッションに参加できるようにします。

招待および参加アクセス

新しいコラボレーションセッションを開始するたびに、Live Share によって新しい一意の識別子が生成され、招待リンクに配置されます。これらのリンクは、リンク内の識別子が "推測不可能" で、単一のコラボレーションセッションの間にのみ有効であるため、信頼できるユーザーを招待するための堅固で安全な基盤を提供します。

予期しないゲストの削除

ホストには、ゲストがコラボレーションセッションに参加するたびに自動的に通知がなされます。

Visual Studio Code:

Visual Studio Code join notification

Visual Studio:

Visual Studio join notification

さらにホストは、この通知により、何らかの理由で知らないゲストが参加している場合、ゲストを削除することができます。 (たとえば、会社全体のチャットシステムに誤ってリンクを投稿し、ランダムな従業員が参加した場合など。) 表示される通知内の [削除] ボタンをクリックするだけで、該当するゲストをコラボレーションセッションから除外できます。

VS Code では、参加通知を閉じてしまった場合でも、後からその参加者を削除することができます。エクスプローラーまたは VS Code アクティビティバーのカスタムタブで Live Share ビューを開き、参加者の名前をポイントするか右クリックして、[参加者の削除] アイコンまたはオプションを選択できます。

Remove participant in VS Code

ゲスト承認の要求

通常、コラボレーションセッションに参加する参加者は、Microsoft の職場または学校アカウント (AAD)、個人の Microsoft アカウント、または GitHub アカウントを使用して Live Share にサインインします。サインインしたユーザーに対する "通知 + 削除" の既定の処理は、スピードと制御のバランスの点で優れていますが、機密情報を処理している場合は、それよりもロックダウンを厳重に行う必要な場合があります。

また、特定の状況では、コラボレーションセッションに参加するためにすべてのゲストにサインインを要求することが問題になる場合もあります。これには、Live Share の新しいユーザーにゲストとして参加するように依頼する場合、教室/学習シナリオ、サポートされているアカウントの種類の 1 つを持っていないユーザーと共同作業する場合などが含まれます。これらの理由により、Live Share では、サインインしていないユーザーがコラボレーションセッションに読み取り専用ゲストとして参加することを許可できます。既定で、ホストが承認してからでなければこれらのゲストは参加できませんが、これらの "匿名" ゲストを許可しないことや、常に承認することが必要になる場合があります。

サインインしているユーザーに対するゲスト承認の要求

サインインしているゲストについて、ホストが "承認" するまでコラボレーションセッションに参加できないようにするには、次の設定を変更します。

VS Code で、settings.json に次の内容を追加します (\[ファイル] > [Preferences]\(ユーザー設定\) > [設定]\)。
```
"liveshare.guestApprovalRequired": true
```
Visual Studio で、[ツール] > [オプション] > [Live Share] > の順に移動し、[ゲスト承認が必要] を True に設定します。

この時点以降、ホストは参加する各ゲストを承認するように求められます。

Visual Studio Code:

Visual Studio Code join approval request

Visual Studio:

Visual Studio join approval request

ゲストは、ホストがこの設定を有効にしているセッションに参加すると、ステータスバーまたは参加ダイアログが表示され、Live Share がホストによる承認を待機していることが通知されます。

サインインしていない (匿名) ユーザーの自動拒否または自動受け入れ

上で説明したように、Live Share では、サインインしていないユーザーがコラボレーションセッションに読み取り専用ゲストとして参加することを許可するように構成できます。参加するときにこれらの "匿名" ゲストは名前を入力する必要がありますが、単純な名前では実際のサインインと同じレベルの保証は提供されません。このため、上で説明した [ゲスト承認が必要] の設定に関係なく、既定で、ホストには匿名のゲストを承認するように求めるダイアログが表示されます。

代わりに、次のようにして、匿名のユーザーを常に拒否する (匿名のゲストを無効にする) か、常に受け入れることができます。

VS Code で、settings.json (\[ファイル] > [Preferences]\(ユーザー設定\) > [設定]\) の liveshare.anonymousGuestApproval を、必要に応じて accept、reject、または prompt (既定値) に設定します。
Visual Studio で、[ツール] > [オプション] > [Live Share] > [匿名ゲストの承認] を、必要に応じて [Accept]\(許可\)、[Reject]\(拒否\)、または [Prompt]\(プロンプト\) (既定値) に設定します。

いずれの場合も、Live Share 招待リンクは、信頼できるユーザーにのみ送信する必要があることにご注意ください。

ゲストコマンド制御を許可する

VS Code: The host doesn't allowing running this command.

ゲストがコードアクション ("クイックフィックス") を使用して任意のコマンドを実行できるようにするには、CodeLens で以下の設定を行います。

VS Code で、settings.json の liveshare.languages.allowGuestCommandControl ([ファイル] > [ユーザー設定] > [設定]) を 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"
    ]
}

Note

共有するすべてのファイル/フォルダーを、コラボレーションセッションを開始するときに [読み取り専用] に設定することもできます。詳細については以下を参照してください。

次に、これらのプロパティによって、ゲストが行える処理がどのように変わるかを説明します。

Properties

excludeFiles プロパティを使用すると、glob ファイルパターン (.gitignore ファイルの場合とよく似たもの) の一覧を指定して、Live Share がゲストに対して特定のファイルやフォルダーを開けないようにすることができます。これには、ゲストによるホストの編集場所のフォローや編集場所へのジャンプ、共同デバッグ中のファイルへのステップイン、[定義へ移動] のようなコードナビゲーション機能などのシナリオが含まれることにご注意ください。これは、シークレット、証明書、またはパスワードを含む、どのような状況でも共有したくないファイルを対象としています。たとえば、.vsls.json ファイルは、セキュリティを制御するものであるため、常に除外されます。

hideFiles プロパティも似ていますが、同じほど厳密ではありません。これらのファイルは、単純にファイルツリーから非表示になります。たとえば、デバッグ中にこれらのファイルのいずれかにステップインすると、そのファイルはエディターで開かれます。このプロパティは、(別のソース管理システムを使用している場合のように) .gitignore ファイルの設定がない場合や、煩雑さや混乱を避けるために、既にあるものを拡張することにしたい場合に主に役立ちます。

gitignore 設定は、共有フォルダー内の .gitignore ファイルの内容を Live Share がどのように処理するかを決定します。既定では、.gitignore ファイル内に見つかる glob はすべて、"hideFiles" プロパティで指定されている場合と同様に扱われます。ただし、次の値のいずれかを使用することにより、別の動作を選択できます。

オプション	Result
`none`	.gitignore の内容は、ファイルツリー内でゲストに表示されます (ゲストエディター設定でフィルター処理されていない場合)。
`hide`	これが既定値です。 .gitignore 内の glob は、"hideFiles" プロパティにある場合と同様に処理されます。
`exclude`	.gitignore 内の glob は、"excludeFiles" プロパティにある場合と同様に処理されます。

exclude 設定の欠点は、node_modules のようなフォルダーの内容は .gitignore にある場合が多いのに、デバッグ中のステップインに役立つ場合があるということです。このため、Live Share では、excludeFiles プロパティで "!" を使用して、規則を反転する機能をサポートしています。たとえば、次の .vsls.json ファイルでは、node_modules を除く ".gitignore" 内のすべてが除外されます。

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

hide 規則と exclude 規則は個別に処理されます。したがって、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 では "サーバーを共有" することができます。これにより、ホストのマシン上のローカルポートが、ゲストのマシン上のまったく同じポートにマップされます。次にゲストは、アプリケーションが自分のマシン上でローカルに実行されている場合とまったく同じように、そのアプリケーションとやり取りすることができます (例: ホストとゲストの両方が、次で実行される Web アプリにアクセスできます: http://localhost:3000).

ただし、ホストはゲストと共有するポートを注意深く選択して、システムポートではなくアプリケーションポートのみを共有する必要があります。ゲストから見ると、共有ポートは、サーバー/サービスが自分のコンピューターで実行している場合とまったく同じように動作します。これは非常に便利ですが、共有するポートを間違えると危険な場合もあります。このため、Live Share では、構成設定やホストによるアクションの実行がない場合、何を共有すべきで何を共有すべきでないかについて一切想定しません。

Visual Studio では、ASP.NET プロジェクトで指定された Web アプリケーションポートは、実行中の Web アプリへのゲストアクセスを容易にするため、デバッグ中にのみ自動的に共有されます。ただし、必要に応じて [ツール] > [オプション] > [Live Share] > [デバッグ時の Web アプリの共有] を "False" に設定することにより、この自動化を無効にできます。

Visual Studio Code で、Live Share は、適切なアプリケーションポートの検出と、それらのポートの共有を試みます。ただし、settings.json に次の内容を追加することにより、これを無効にできます。

"liveshare.autoShareServers": false

いずれの場合も、追加のポートを共有する場合は注意が必要です。

この機能の構成について詳しくは、こちらをご覧ください:

最新の開発では、さまざまなコマンドラインツールを頻繁に使用します。ありがたいことに、Live Share を使うとホストは必要に応じてゲストと "ターミナルを共有" することができます。共有されたターミナルは、読み取り専用または完全な共同作業用にすることができます。このため、ホストとゲストの両方がコマンドの実行と結果の確認を行うことができます。ホストは、他のコラボレーターに出力の表示のみを許可するか、任意の数のコマンドラインツールを使用してテスト、ビルド、または環境固有の問題のトリアージを行うことを許可することができます。

共有ターミナルを開始できるのはホストだけです。これは、ゲストが共有ターミナルを開始し、ホストが予期または監視していないことを実行することがないようにするためです。ホストは、共有ターミナルを開始するときに、ターミナルを読み取り専用にするか、読み取り/書き込みにするかを指定できます。ターミナルが読み取り/書き込みのときは、ホストを含むすべてのユーザーがターミナルに入力でき、ゲストが好ましくないことを行っている場合は簡単に介入できます。ただし、安全のため、ホストは、読み取り/書き込みアクセスはゲストが実際にそれを必要としていることがわかっている場合にのみ許可し、自分が実行するコマンドの出力をゲストに見せたいだけの場合は読み取り専用ターミナルを使用する必要があります。

Visual Studio では、ターミナルは既定では共有されません。 VS Code では、ターミナルは既定では読み取り専用として自動的に共有されます。ただし、settings.json に次の内容を追加することにより、これを無効にできます。

"liveshare.autoShareTerminals": false

詳細情報:

Microsoft の職場または学校のメールアドレスを使用してサインインすると、サインイン時に "管理者の承認が必要" というメッセージが表示される場合があります。これは、Live Share ではそのセキュリティ機能のためにユーザー情報への読み取りアクセスが必要であり、お使いの Azure AD テナントが、そのディレクトリの内容にアクセスする新しいアプリケーションに対して "管理者の同意" を要求するように設定されているためです。

AD 管理者は、次の情報を使用して、ホストに代わってこれを解決する必要があります。

アプリケーション名: Visual Studio Live Share (インサイダー)
アプリケーションの種類: Web アプリ
アプリケーションの状態: 実稼働
委任されたアクセス許可: User.Read
アプリケーション URL: https://visualstudio.microsoft.com/services/live-share/
[応答 URL]: https://insiders.liveshare.vsengsaas.visualstudio.com/auth/redirect/windowslive/

これは、Live Share を使用している各ユーザーについて 1 回のみ実行する必要があります。詳細については、こちらとこちらを参照してください。

次の方法で共有

接続

ワイヤ暗号化

ピア認証

招待および参加アクセス

予期しないゲストの削除

ゲスト承認の要求

サインインしているユーザーに対するゲスト承認の要求

サインインしていない (匿名) ユーザーの自動拒否または自動受け入れ

ゲストコマンド制御を許可する

ファイルアクセスと可視性の制御

Properties

サブフォルダー内の .vsls.json ファイル

読み取り専用モード

共同デバッグ

関連項目

フィードバック

その他のリソース

次の方法で共有

Live Share のセキュリティ機能

接続

ワイヤ暗号化

ピア認証

招待および参加アクセス

予期しないゲストの削除

ゲスト承認の要求

サインインしているユーザーに対するゲスト承認の要求

サインインしていない (匿名) ユーザーの自動拒否または自動受け入れ

ゲスト コマンド制御を許可する

ファイル アクセスと可視性の制御

Properties

サブフォルダー内の .vsls.json ファイル

外部ファイル共有の無効化

読み取り専用モード

共同デバッグ

ローカル サーバーの共有

ターミナルの共有

AAD 管理者の同意

関連項目

フィードバック

その他のリソース

ゲストコマンド制御を許可する

ファイルアクセスと可視性の制御

ローカルサーバーの共有