デジタルライフをセキュリティドメインに分割する (2011)

デジタルライフをセキュリティドメインに分割する

以下の図は、私がデジタルライフをセキュリティドメインにどのように分解したかを示しています。これはかなり高度なスキームであり、ほとんどのユーザーはもっとシンプルなものを望むかもしれませんが、議論する価値はあると思います。これらのドメインは、Qubes OS上の軽量なAppVMとして実装されています。図は、各ドメインが許可されているネットワーク接続の種類も示しています。

［画像］

この図を少しずつ見ていきましょう。3つの基本的なドメインは、ワーク（緑色のラベル）、 パーソナル（黄色のラベル）、そして信頼できない、機密性のないすべてのタスクを実行するためのレッド（赤色のラベル）です。これらは図中に太枠で示されています。

ドメインラベル（色）についての簡単な補足ですが、Qubes OSでは各ドメインは、明確な名前を持つことに加えて、ラベルも割り当てられています。これは基本的に、いくつかの定義済みカラーのいずれかです。これらの色は、信頼できるウィンドウマネージャーによってウィンドウの装飾を描画するために使用されます（カラーフレーム）。ユーザーフレンドリーで、認識しやすく、与えられたウィンドウの信頼度を示すためのものです。これらの色をどのように解釈するかは、完全にユーザー次第です。私にとっては、赤色を信頼できず危険なもの（「赤信号」-- 止まれ！危険！）に、緑色を安全で信頼できるものに、そして黄色やオレンジ色をその中間に関連付けることは、ある程度明白でした。私はこのスキームを拡張して、青色と黒色も含めました。これらは緑色よりも徐々に信頼性が高くなるドメインを示し、黒色が究極的に信頼できるものを示します。

私のドメインに戻りましょう。ワークドメインは、職場のメールにアクセスし、職場のPGPキーを保管し、レポート、スライド、論文などを準備する場所です。また、さまざまな契約書やNDAもここに保管しています（はい、これらはPDFですが、信頼できる送信元から暗号化および署名されたメールで受信したものです。それ以外の場合は、Disposable VMで開きます）。ワークドメインは、私の職場のメールサーバー（SSL経由のSMTP/IMAP4）へのネットワークアクセスのみを持ち、それ以外はありません。

Qubes Wikiの編集、LinkedInの招待の承諾、プレゼンテーション用のfotolia.comからのクールな写真のダウンロード、intel.comからの仕様やマニュアルのダウンロードなど、Webアクセスを必要とするその他の仕事関連のタスクについては、これらすべてにワークパブドメインを使用します。このドメインには黄色のラベルを割り当てており、ある程度信頼できると考えていますが、PGPキーや仕事関連の機密情報をここに置くことは絶対にありません。

パーソナルドメインは、個人のメールやカレンダー、ホリデーの写真、ビデオなど、仕事以外のすべてのものを保持する場所です。実際にはWebへのアクセスはありませんが、もし私がソーシャルネットワーキングに興味があれば、FacebookのようなものにHTTPSを許可するでしょう。

ある程度疑い深い性質から、私は特別なベリーパーソナルドメインも持っています。これは、家を離れているときにパートナーとのコミュニケーションに使用します。もちろんPGPを使用しており、この目的のために別のPGPキーを持っています。ここでは秘密や機密性の高いことは議論しませんが、親密な会話はプライベートに保ちたいと考えています。

ショッピングは、すべてのインターネットeコマースサイトにアクセスするために使用します。基本的にこのドメインを定義するのは、クレジットカード番号と個人住所（配送用）へのアクセスです。専用の「法人」クレジットカードを持っていないため、食料品からスポーツ用品、ホテルの予約、飛行機の予約まで、すべての買い物をこのドメインで行います。もし個別のビジネス用クレジットカードがあれば、おそらくショッピングドメインをパーソナルショッピングとワークショッピングに分割するでしょう。また、銀行口座の管理のみに使用するバンキングドメインもあります（これは個人口座と会社口座の両方を兼ねています）。

また、使用頻度は低いですが、いくつかの専門的な仕事関連のドメインもあります。ワークアドミンドメインは、Webサーバー、Qubesリポジトリ＆Wikiサーバー、メールサーバー、DNS管理など、ほとんどすべてのITLサーバーを管理するために使用されます。このドメインは、これらのサーバーへのSSHトラフィックと、いくつかのWebベースの管理サーバーへのHTTPSのみが許可されています。ワークブログは、あなたが今読んでいるこのブログを管理するために使用されます。これがワークアドミンやワークから分離されている理由は、私が過度に疑い深く、ブロガーサービスが侵害され、その後私がブログを編集するために使用するブラウザのバグが悪用された場合、その人物がITLサーバーへの管理者アクセスも得られることを望まないからです。

同様に、誰かが例えばAmazon Web Management Consoleを侵害し、その後ワークアドミンの私のブラウザを悪用した場合、少なくとも私のブログへのアクセスを維持したいです。もしTwitterを使用していたら、個人的なTwitterアカウントでない限り、おそらくこのワークブログドメインから管理するでしょう。個人的なアカウントの場合は、パーソナルから実行します。

qubes-devドメインは、すべてのQubes開発に使用されます。他の開発者のブランチのマージ（もちろん、タグの署名を確認した後！）、RPM/ISOのビルド（はい、Qubes Beta 1はDVD ISOとして出荷されます！）、そして最終的な署名です。署名キーがここにあるため、このドメインは非常に機密性が高いです。このドメインは、私たちのQubes gitサーバーへのSSHネットワークアクセスのみが許可されています。ここでも、誰かがこのGitサーバーを侵害したとしても、私たちが互いのリポジトリで全てのタグに署名し検証しているため、私たちにとって大きな問題にはならないでしょう（誰かがそこで実行されているSSH/Gitデーモンも変更して、サーバーに接続したときに私のgitクライアントソフトウェアの仮説的なバグを悪用できる場合を除き）。

また、すべての会計関連のものを別のドメインに保持することにしました。請求書を受け取るたびに、それをアカウンティングドメインにコピーします。この根拠は、ワークドメインに保管するPDFよりも、これらのPDFを信頼していないことです。

年に一度、私はワークドメインから古いメールスプールや古い契約書、NDAなどの古いものをワークアーカイブドメインに移動します。これは、ワークドメインへの潜在的な攻撃の影響を最小限に抑えるためです（例えば、MITM攻撃でThunderbirdのプロトコルハンドシェイクの仮説的なバグを悪用したり、GPGの仮説的なバグを悪用したりして、ワークドメインが攻撃される可能性があります）。

ボルトドメインは、すべてのパスワード（keepassを使用）とマスターGPGキーを生成し、保持する究極的に信頼できるドメインです。もちろん、このボルトドメインはネットワークアクセスを持ちません。これらのパスワードのほとんど、例えばメールサーバーへのアクセスパスワードは、それを使用する特定のドメイン、例えばワークドメイン、より具体的にはThunderbirdクライアントにも保持されています（例えば、Thunderbirdにパスワードを記憶させることを許可しないことに全く意味がありません。もし侵害されたら、次回手動で入力したときにそれを盗むだけです）。

そして最後に、前述のレッドドメインがあります（過去にジャンクやランダムと呼ぼうとしたこともありますが、結局レッドがより良い名前だと思います）。レッドドメインは完全に信頼されていません。もし侵害されても、気になりません。すぐに再作成するだけです。バックアップもしていません！基本的に、他のドメインに収まらず、機密情報を提供する必要のないことはすべてそこで行います。仕事関連か個人的なサーフィンかさえ区別しません。そこで行うすべてのタスクについて、匿名性を気にする必要はありません。もし匿名性を気にするなら、別の匿名ドメインを作成し、そこからtorプロキシ経由ですべてのトラフィックをプロキシするでしょう。

さて、これらすべては素敵で簡単に見えますよね？ ;) しかし、この上記の状況を複雑にする一つのことがあります...

ドメイン間のデータフロー

以下の図は同じドメインを示していますが、それらの間の典型的なデータフローを表す矢印が追加されています。

［画像］

通常のデータフローのほとんどは、より信頼できるドメインから信頼性の低いドメインへのものであることがわかります。例えば、ワークドメインのメールで受信したURLをコピーして、信頼性の低いレッドドメインのブラウザで開くために貼り付けたり、請求書をワークドメイン（メールで受信した場所）からアカウンティングドメインに移動させたりします。

しかし、残念ながら、信頼性の低いドメインからより信頼できるドメインへの転送もいくつかあります。その一例は、レッドドメインでサーフィン中に偶然見つけた興味深いURLをコピーして、職場の同僚や友人と共有したい場合に、それをワークドメイン（同僚向け）またはパーソナルドメイン（友人向け）のメールクライアントにコピー＆ペーストすることです。

さて、信頼性の低いドメインからより信頼できるドメインへのデータのコピーは、重大な問題を引き起こします。ThunderbirdのメールエディタにURLを貼り付ける操作は非常に無害に思えるかもしれませんが、それでも信頼されていない入力です。そして、レッドドメインがローカルクリップボードに実際に何を貼り付けたのか、そしてそれをワークドメインのThunderbirdメールエディタに貼り付けるものが何になるのか（おそらく、エディタのundoバッファをオーバーフローさせるようなジャンクデータ64kB？）を私たちは実際には知りません。さらに恐ろしいのは、プレゼンテーションスライドで使用するために、Webからクールに見えるグラフィックファイルをワークドメインにコピーする例です（例えば、xkcdの画像）。悪意のあるJPEGやその他のグラフィック形式を介した攻撃、およびレンダリングコードのバグを悪用する攻撃は、10年以上前から知られています。

しかし、この問題、つまり信頼性の低いシステムからより信頼できるシステムへのデータ転送をどのように処理するかは、残念ながら実際には容易に解決できません。

軍事および政府用途の高セキュリティシステムを設計・構築する人々の中には、信頼性の低いからより信頼できるへのデータ転送については、逆方向の転送を実行する方法がないことを保証できれば、関心がないと言う人もいます。

したがって、より信頼できるドメインが、たとえ両方のドメインが侵害されたとしても、決して信頼性の低いドメインにデータを転送できないシステムを構築できれば、彼らは一方通行の「アップロード」を許可することに満足します。実際には、これは2つの協力的なドメイン間のすべての隠蔽チャネルを排除する必要があることを意味します。ここでの協力的なという言葉は重要なキーワードであり、この考え方全体をIMHOでは実用的ではないものにしています。

このスキームでは、協力的なドメイン間の隠蔽チャネルの排除が実際に必要です。なぜなら、信頼性の低いドメインからのデータ転送が、より信頼できるドメインを実際に侵害した可能性があるという仮定があるからです。しかし、これでも、少なくとも元のドメインへの、そして後にこの信頼性の低いドメインがおそらく接続されている、より分類レベルの低いネットワークへのデータ漏洩は発生しないはずです。ここでの仮定の一つは、そのようなシステムのユーザーが複数の、分離されたネットワークに接続されているということです。たとえそうであっても、ドメイン間のすべての隠蔽チャネルを排除すること（または少なくとも帯域幅を無用なものにまで最小化すること - 本当に無用とは何か？）は大きな課題であり、おそらくシステムのパフォーマンスを大幅に犠牲にする準備ができたときにのみ可能になるでしょう（スマートスケジューリングトリックが時間的隠蔽チャネルを最小化するために必要です）。

近い将来、そしておそらく長期的に見ても、Qubesでドメイン間の協力的な隠蔽チャネルを排除することに関心がないことを明確にしたいと思います。私はそのようなアプローチを信じていませんし、また、このアプローチがより信頼できるドメインの整合性を維持するために何もしていないことも気に入っていません。それは単に分離の側面に焦点を当てています。したがって、攻撃者は秘密を信頼性の低いドメインに漏洩できないかもしれませんが、そのより信頼できるドメインでは他のすべてを行うことができます。整合性を維持しないのであれば、分離は何の役に立つのでしょうか？

信頼性の低いからより信頼できるへのデータ転送を処理する代替ソリューションは、JPEGなどの特定のファイルタイプを処理し、宛先ドメインで悪意のないファイルを取得できる信頼できる「コンバーター」または「検証者」を持つことです。これは古い悪いA/V技術を連想させるかもしれませんが、それは異なります。ここでは、信頼できるコンバーターは、おそらく安全な言語で書かれたプログラムであり、別の信頼できるドメインで実行されるものでしょう。巨大なデータベースに「悪い」パターンの署名を持つ、醜いA/Vプログラムよりもです。このアプローチの明らかな問題は、誰かがそれらのコンバーターを書かなければならないことであり、より信頼できるドメインに転送したいすべてのファイルタイプのためにそれらを書かなければならないことです。おそらく長期的には可能であり、おそらくQubesの将来のバージョンでそれを行うでしょう。

現時点では、この問題を無視しており、信頼性の低いからより信頼できるへのすべての転送は、ユーザー自身の責任で行われると述べています :) その間、お気に入りのファイルタイプのための信頼できるコンバーターを提出していただければ幸いです！

ドメイン間のファイルコピー

ドメイン間のファイルコピーと言えば、もう一つセキュリティ上の注意点があります。共通のネットワークリソースを共有しない物理的に分離された2台のマシンを想像した場合、それらのエアギャップされたマシン間でファイルを移動する唯一の方法は、USBスティックやCD-ROM、DVDディスクのようなものを介することになります。しかし、USBドライブやCD-ROMをマシンに挿入すると、デバイスが提供する情報の解析、必要なドライバー（USB用）のロード、ドライバーのパーティションテーブルの解析、マウント、そして最終的なファイルシステムの解析など、多くの処理がトリガーされます。これらの各段階では、マシンのOSが多くの信頼されていない入力を処理する必要があり、潜在的な攻撃空間は非常に広いです。したがって、たとえマシン/ドメイン間で無害なファイルのみをコピーすることに限定できたとしても（おそらく上記のように、途中で信頼できる当事者によって検証された場合）、元のドメインがターゲットドメインを侵害する大きな機会が依然として存在します。

Qubes Alphaでは、ドメイン間のファイルコピーのために同様のファイルコピーメカニズムを使用していました。Qubes Beta 1では、GUI仮想化に使用しているのと同じ共有メモリチャネルに基づいた新しいスキームを提供します。このソリューションの技術的な詳細は、近日中にWikiで公開される予定です。この新しいスキームで最も機密性の高い要素は、ターゲットドメインで実行され、受信したブロブを事前定義されたディレクトリツリー（例: /home/user/incoming/from-{domainname}/）に展開する、cpioライクなユーティリティです。私たちは、前述のすべての要素（USBデバイス解析、パーティション解析、ファイルシステム解析）よりも安全な、cpioライクなユーティリティを書くことができると信じています。ちなみに、Qubes Beta 1は3月末にリリースされる予定です。

パーティション強制と使いやすさ

どのようなセキュリティパーティショニングスキームも、現実世界で意味を持つためには、ユーザーが誤ってそれを回避しないようにするための強制メカニズムが必要です。特にこの目的のために、Qubes Beta 1で特別な、前述のファイアウォールサポートを開発しました。これは、別の記事で近日中に取り上げる予定です。

もう一つは、パーティショニングを使いやすくすることです。例えば、ポリシーにヒントを設定して、ワークドメインで受信したメールのURLをクリックしたときに、それが自動的にレッドドメインのデフォルトWebブラウザで開かれるようにしたいです。現在、Qubesではこれを行っていませんが、近い将来に検討しています。

要約

デジタルライフをセキュリティドメインに分割することは、確かに簡単なプロセスではなく、ある程度の思考が必要です。このプロセスは非常にユーザー固有でもあります。私が自分自身のために考案したパーティショニングスキームはかなり高度であり、ほとんどの人はもっとシンプルなものを望むでしょう。企業展開の場合、スキームはCIOまたはIT管理者が設計し、ユーザーに自動的に強制されるでしょう。家庭や小規模ビジネスのユーザーは、自分でパーティショニングを考案する必要があるため、より大きな問題となります。おそらく、Qubesの将来のバージョンでは、特定の「典型的な」ユーザーグループ向けのすぐに使えるテンプレートを提供するでしょう。