Live Share のセキュリティ機能

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 の参加通知

Visual Studio で次の操作を行います。

Visual Studio の参加通知

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

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

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 の設定ウィンドウ

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

Visual Studio Code:

Visual Studio Code の参加承認要求

Visual Studio で次の操作を行います。

Visual Studio の参加承認要求

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

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

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

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

  • VS Code で、settings.json (\[ファイル] > [Preferences]\(ユーザー設定\) > [設定]\) の liveshare.anonymousGuestApproval を、必要に応じて acceptreject、または prompt (既定値) に設定します。

  • Visual Studio で、[ツール] > [オプション] > [Live Share] > [匿名ゲストの承認] を、必要に応じて [Accept]\(許可\)、[Reject]\(拒否\)、または [Prompt]\(プロンプト\) (既定値) に設定します。

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

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

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

オプション 結果
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 ファイルの内容は、上位レベルで確立された規則を補完 (またはオーバーライド) します。

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

既定で、Live Share では、ホストが開くファイルは、共有フォルダーやソリューションの外部にあっても共有されます。 これにより、他の関連ファイルを再共有しなくても、すばやく簡単に開くできます。

この機能を無効にするには、次のようにします。

  • VS Code で、settings.json に次の内容を追加します。

    "liveshare.shareExternalFiles": false
    
  • Visual Studio で、[ツール] > [オプション] > [Live Share] > [外部ファイルの共有] を False に設定します。

読み取り専用モード

ホストとしてコードを共有する場合に、ゲストには編集を許可したくない場合があります。 ゲストにコードの一部を見せることが必要な場合や、プロジェクトを大勢のゲストに示しながらも、不必要な編集や意図しない編集が行われないようにしたい場合があります。 Live Share には、読み取り専用モードでプロジェクトを共有する機能が用意されています。

ホストは、共有するときに、コラボレーション セッションに対して読み取り専用モードを有効にすることができます。 参加したゲストは、互いのカーソルの確認、強調表示、プロジェクト内の移動などは行えますが、コードを編集することはできません。

読み取り専用モードの場合でも、ゲストと共同デバッグできます。 ゲストはデバッグ プロセスをステップ実行することはできませんが、ブレークポイントを追加または削除したり、変数を検査したりすることはできます。 また、サーバーとターミナル (読み取り専用) をゲストと共有することもできます。

読み取り専用コラボレーション セッションの開始について詳しくは、次を参照してください。VS CodeVS

共同デバッグ

厄介なコーディングの問題やバグの処理をする場合、デバッグを誰かと共同で行えると非常に助けになります。 Visual Studio Live Share では、ホストがデバッグを開始するときはいつでも、デバッグ セッションをすべてのゲストと共有することにより、"共同デバッグ" を有効にできます。

ホストは、デバッグ セッションをいつ開始または停止するかを完全に制御できますが、信頼できないユーザーと共有している場合は、共同デバッグによっていくつかのリスクが生じます。 Live Share では、ホストが招待したゲストに対して、コンソール/REPL コマンドの実行を許可します。したがって、ホストが実行させるつもりのないコマンドを悪意のあるアクターが実行するリスクが生じます。

そのため、信頼できるユーザーとのみ共同デバッグを行う必要があります。

詳細情報: VS CodeVS

ローカル サーバーの共有

共同デバッグを行うとき、デバッグ セッション用にホストが提供するアプリケーションのさまざまな部分にアクセスできると非常に便利です。 ブラウザーでアプリにアクセスしたり、ローカル データベースにアクセスしたり、またはツールから 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

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

この機能の構成について詳しくは、次を参照してください。VS CodeVS

ターミナルの共有

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

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

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

"liveshare.autoShareTerminals": false

詳細情報: VS CodeVS

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

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

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

関連項目

問題が発生していますか? トラブルシューティングまたはフィードバックの送信に関するページをご覧ください。