ワークスペースの信頼
2021年7月6日 Chris Dias、@chrisdias
自分を信頼できるか？これは、1.57 アップデート以降、多くのVisual Studio Codeユーザーが直面している実存的な問いです。
その問いに私たちが答えることはできませんが、ワークスペース信頼の概念を導入した理由については詳しくお伝えできます。
まず、少し背景を説明させてください。
猫とキーボード、そして問題のあるリンゴたち
インターネットには、キーボードを叩く猫の動画のように、楽しいもので溢れています。
開発者にとって、インターネットはまた、何時間も取り組んできた問題を解決しようと手助けしてくれる善意の人々が作ったツール、パッケージ、オープンソースで溢れています。VS Codeのような開発ツールは、パッケージマネージャー、コードリンター、タスクランナー、バンドラーなどを統合し、進化し続けるコミュニティからの最新かつ最高の進歩を活用した快適な体験を提供します。
しかし、この豊かなエコシステムがもたらす生産性は、しばしば開発マシンへの幅広いアクセスを提供することの結果です。急速な進化とウイルス的な共有および消費と相まって、開発ツールは悪用される魅力的な標的となります。特に、攻撃者が私たちのマシンを使って攻撃をさらに拡散できることを考えると（例えば、開発者マシンに保存されている認証トークンを介したり、開発者が作成したソフトウェアを通じてさえも）。
開発者であることはやりがいがありますが、リスクも伴います。プロジェクトに貢献するには、本質的にその作者を信頼する必要があります。なぜなら、`npm install`や`make`の実行、JavaやC#プロジェクトのビルド、自動テスト、デバッグといった活動はすべて、プロジェクトのコードがあなたのコンピューター上で実行されることを意味するからです。
ワークスペース信頼機能の目標は、ほんの一握りの「問題のあるリンゴたち」から安全を確保しつつ、開発をこれほど楽しいものにしているすべての素晴らしいものを引き続き享受できるように、適切なバランスを見つけることです。
「え、ただのエディターでしょ？」
はい、VS Codeはエディターです。しかし、ほとんどの最新のエディターと同様に、より豊かな開発体験を提供するために、ワークスペースからコードをユーザーの代わりに実行する機能を持っています。
コードの実行とデバッグは明白な例です。あまり明白でないコード実行としては、アプリの起動前に実行される`preLaunchTask`があり、ビルドとは無関係の任意のコードを実行する追加タスクを含むビルドを実行する可能性があります。あなたの暗号ウォレットの秘密鍵を盗むnpmモジュールについてはどうでしょう？簡単な編集を行うと、グローバルにインストールされているものではなく、`node_modules`フォルダーから悪意のあるリンターが読み込まれる可能性があります。コードを読むことさえ欺瞞的である可能性があり、攻撃者はUnicodeハックを使用して、悪意のあるコードを明白に隠すことができます。最悪の場合、所有されるためにソースコードを開く必要さえありません。
ここでの意図は、世の中にある素晴らしいツール（VS Codeを含む）からあなたを遠ざけたり、キャリアを変えさせたりすることではありません。信頼関係のない個人や組織が作成したコードをインターネットからダウンロードする際に、多くの攻撃機会が存在することへの意識を高めることです。
モグラ叩き
上記のすべてのシナリオにおいて、ツールは設計通りに機能しており、悪意のないコードベースでは非常に生産的です。デバッグ前にアプリをビルドするための`preLaunchTask`を設定することは、変更のたびにターミナルから手動でビルドする必要がないため、非常に時間の節約になります。リンターは、各チームの好みのコーディングガイドラインやスタイル（そうです、タブ対スペースです）をサポートするために高度にカスタマイズ可能です。プリコミットフックを使用すると、何か忘れていないかを確認したり、コミット前にテストが実行されることを確認したりできます。
さて、これらすべての攻撃に同時にさらされる可能性は低いでしょう。実際、新しい機会が生じた際に私たちに情報を提供してくれる素晴らしい専門家コミュニティがあるため、VS Codeを介したエクスプロイトはまだ発生していません。ワークスペース信頼導入前の私たちのアプローチは、脆弱性が発生したポイントで、局所的なアクセス許可プロンプトを使用して各シナリオに対処することでした。
例えば、Jupyter拡張機能は、ノートブックでビジュアライザーを開くと、埋め込まれたJavaScriptが実行される可能性があることをユーザーに警告していました。
ESLintの脆弱性は厄介なものでした。ワークスペースが読み込まれるときに実行されるからです（これが最初のモーダルダイアログでした）。
これは、どうやら勝ち目のない戦いであることが判明しました。ユーザーは、ワークスペース全体に適用されない複数の（そして少し異なる）アクセス許可プロンプトによって中断されます。*「あなたを信頼する、あなたも、あなたも、あなたも、あなたは信頼しない、そしてあなたも、でも火曜日だけは」*。私たちにとって、それはモグラ叩きの絶え間ないゲームであり、露出するたびに新たなプロンプトで各脆弱性を塞いでいました。
そこで、VS Codeを構築する際に私たちが従うパターンの1つは、ツールと拡張機能全体で似ているが矛盾なく実装されているエクスペリエンスに注目し、それをコアに取り入れられるかどうかを見ることです。信頼プロンプトはこのパターンに当てはまったため、ツールと拡張機能の両方が活用できる、より（願わくば）明確なユーザーエクスペリエンスを持つ機能とAPIを構築することにしました。
信頼
コードが知らぬ間に実行される様々な方法を理解した今、私たちがなぜこの質問を事前にしているのか、よりよく理解していただけたことを願っています。
私たちがこのワークスペースの作者を信頼するかどうかを具体的に尋ねるのは、VS Codeがそのコードが悪意のあるものかどうか（*ええ、私たちは1と0しか知らないのです*）、どこから来たのか、プロジェクトに貢献するつもりがあるのかなどを判別できないからです。
その一方で、あなたは賢く、コードがどこから来たのかを知っています。あなた自身（*よし*）、あなたの会社（*おそらくよし*）、あなたの相棒のカイ（*場合による*）、またはインターネット上の見知らぬ人（*絶対にだめ*）。
その知識がツールをよりスマートにするのに役立ちます。作者を信頼するなら、素晴らしいことです！ツールと拡張機能は自由に動作し、素晴らしい体験を提供でき、私たちはもうあなたを悩ませることはありません。
信頼しない場合、あなたは私たちに**「VS Code、気をつけて、コードを実行しないでください」**と伝えていることになります。これが**制限モード**と呼ぶものです。このモードでは、潜在的に有害な機能が無効になるため、より安全にコードを参照し、最終的に情報に基づいた決定を下すことができます。
でも、あのダイアログが！
お気持ちはわかります。モーダルダイアログはかなり大きく、設定するための行動を起こさない限り、新しいフォルダーを開くたびに表示され続けます。
最初からこのデザインを採用したわけではありません。私たちはESLintのモーダルダイアログに関する一連の出来事を検討し、視覚的な手がかりと、可能な限り遅延する単一の通知プロンプトを使用して、ノンブロッキングな体験を提供できるかを自問しました。私たちは目立たず、制限モードで開始し（実際には気づかずに）、最後の瞬間に信頼を促したいと考えていました。
私たちはワークスペースを信頼するかどうかを伝えられる「パッシブな」信頼通知を導入しました。ワークスペースが信頼されていないことを示すために、設定の歯車アイコンを補強したり、新しいセキュリティアイコンを導入したりするなど、様々なUI処理を試しました。
Insidersビルドを使用している場合、ワークスペース信頼で話しているようなVS Codeの新しい体験の最新の反復機能を利用できます。Insidersは毎日リリースされており、私たちはそれを使用してVS Codeを構築しています。
その考えとは、ユーザー（あなた！）が、**あなたの判断で**、ワークスペースの信頼を許可または拒否するタイミングを決定できるというものです。ツールや拡張機能が本当にアクセスを必要とする場合にのみ、ワークスペースを信頼するかどうかを尋ねる通知を表示するようにしました。
さて、多くの方が同意されると思いますが、VS Codeは私たちが「通知疲れ」と呼ぶものに悩まされています（*改善に取り組んでいますのでご安心ください* 😊）。私たちのテストでは、人々が通知を単に無視していることがわかりました。ユーザーは歯車アイコンや新しいセキュリティアイコンの通知さえも見ていませんでした。利用データは、パッシブな通知を通じて信頼を許可する割合が非常に低いことを示していました。ユーザー調査では、人々が何かを壊してしまったと思い込み、トラブルシューティングに時間を費やし、期待する状態に戻そうとしているのを見ました。
私たちは目立たず、可能な限り遅延させるつもりでしたが、現実は、制限モードでは製品が壊れているように感じられ、人々はそれが自分のせいだと思っていました。私たちにとっても、ユーザーにとっても、良い状況ではありませんでした。
ユーザーがコントロールできるように
フォルダーを信頼するかどうかの決定は、VS Codeの機能に根本的な影響を与えるため、あらゆる調査の結果、フォルダーを開こうとしたときにすぐに信頼に関する質問をすることが正しいと判断しました。モーダルダイアログは邪魔になるため、ダイアログを強力なものにすることでバランスを取り、いくつかの質問に答えるだけで、日常業務でプロンプトを目にする頻度を大幅に減らせるように努めています。
私たち自身のドッグフーディングや他の開発者へのインタビューを通じて、人々は一般的にすべてのソースを置き、信頼できると考える主要なフォルダーを持っていることがわかりました。そのため、ダイアログから直接**親**フォルダーを信頼する機能を追加しました。ワンクリックでそのフォルダーとそのすべてのサブフォルダーを信頼でき、その後は信頼プロンプトが再び表示されることはありません。
ワークスペース信頼エディター
ワークスペース信頼エディターは、信頼する内容に対してさらなるコントロールを提供し、ニーズに合わせて機能を簡単に設定できるよう、1.58リリースで更新されます。
そして、動作をカスタマイズできるため、信頼エディターにアクセスする方法はたくさんあります😊。**制限モード**ステータスバーメッセージ、制限モードバナー内の**管理**リンク、歯車メニューをクリックするか、コマンドパレット（F1）を開いて**ワークスペース: ワークスペース信頼の管理**コマンドを使用します。
ワークスペース信頼エディターから、現在のフォルダー、親フォルダー（およびすべてのサブフォルダー）、およびマシン上の任意のフォルダーを信頼できます。
また、すべてのワークスペース信頼設定に素早く移動して、体験を微調整することもできます。
ワークスペース信頼の活用方法
誰も歯のフロスを磨くのは好きではありませんが、それが正しいことだと知っているので、私たちはそうします。誰もセキュリティについて考えたくありませんが、それが正しいことだと知っています。エクスペリエンスをカスタマイズすることで、開発に内在する脅威から身を守りながら、開発体験を楽しいものに保つことができます（フロスって楽しい？！）。
VS Codeチームのほとんどのメンバーは、信頼できるソースを扱う最上位フォルダーから作業を開始します。例えば、私のMacでは、GitHubのMicrosoft組織から取得したすべてのソースを`~/src`フォルダーに入れています。私は`~/src`を信頼済みフォルダーとして指定しており、その下のすべてが本質的に信頼されます。`~/src/vscode`や`~src/vscode-docker`などを開くと、私の組織が作成し利用するコードを信頼しているため、それらは完全に信頼された状態で開かれます。
私は`~/scratch`（「一時作業領域」の略で、もちろん自由に名前を付けられます）という別のフォルダーを持っており、そこに他のすべてを入れ、デフォルトでは信頼されていないと仮定しています。その後、フォルダーごとに信頼の決定を行います。
ワークフローをスムーズにするために、私は`"security.workspace.trust.startupPrompt"`設定を`"never"`にしています。
この設定により、モーダルダイアログによるプロンプトは表示されず、ワークスペースは直接制限モードで開かれます。私はすでに`~src/scratch`フォルダーが信頼されていないと判断しているので、サブフォルダーを開くたびにプロンプトを表示する必要はありません。読んでいる、または書いているコードを信頼すると決めた場合、2回の素早いクリック（VS Codeの上部に表示される制限モード通知、次に信頼ボタン）でそのフォルダーで有効にできます。
私のWindowsマシンでは、少し事情が異なります。通常、Windows Subsystem for Linux (WSL) 上で実行されているUbuntuイメージ内で、WSL拡張機能を使用して作業しています。私はLinux上の`~/src`フォルダーと、Windows側の`d:\src`フォルダーを信頼しています。
チームの何人かはさらに一歩進んで、上部の制限モードバナーもオフにし（`"security.workspace.trust.banner": "never"`）、ステータスバーの通知だけを残しています。私にとってはこれはやりすぎで、上部のバナーは私を正直に保ち、インターネットからプルするときに注意を怠らないように思い出させてくれます。
オープンソースは素晴らしい
VS Codeが皆さんの「本業」をこなすためのツールであり、私たちが導入するいかなる障害も、次のユニコーン企業を構築し、立ち上げるのを遅らせるだけであることを私たちは認識しています。多くの方がTwitter、Reddit、および課題で時間を割いて連絡をくださり、率直なフィードバックに感謝いたします。皆様の意見に基づき、1.58リリースで多くの修正と改善を行いました。今後も議論を続けることを楽しみにしています。
今後、私たちは拡張機能の作者が任意のコード実行を避け、制限モードで実行される際により多くの機能を提供できるよう支援したいと考えています。私たちのロードマップでは、Visual Studio Marketplaceチームと協力して、検証済みのパブリッシャー、署名、プラットフォーム固有の拡張機能など、拡張機能エコシステムにさらなるセキュリティをもたらす作業（これを「信頼された拡張機能」と呼んでいます）について言及しています。要するに、ワークスペース信頼は、優れた拡張機能が適切な決定を下すのを助けると考えることができます。信頼された拡張機能は、悪意のある拡張機能からあなたを保護するのに役立ちます。
VS Codeをオープンに構築する利点の1つは、コミュニティが私たちに最高の体験を創造する手助けをしてくれることです。ですので、可能な限り目立たずに皆さんを安全に保ちながら、どのようにフローを改善できるか教えてください。既存の課題に（丁寧に！）コメントするか、新しい課題を提出するか、または@codeで私たちにツイートしてください。私たちは耳を傾けています！
よろしくお願いいたします。
クリスとVS Codeチーム
ハッピーコーディング（安全に）！