セキュリティ ウォッチ島巡り : 望ましくない依存関係を軽減する
Jesper M. Johansson
先月のセキュリティ ウォッチの記事では、USB フラッシュ ドライブを使用したネットワークの攻撃の発端となる手続きについて説明しました。ネットワークへの攻撃は、ウイルスに感染した USB フラッシュ ドライブが 1 台のコンピュータに接続されることで開始され、その後、自動的に、またはユーザーのわずかな手助けによって (簡単なソーシャル
エンジニアリングを利用します) 悪意のあるコードが実行されるということを説明しました。この攻撃はワークステーションのローカルだけにとどまりましたが、マルウェアがネットワークに蔓延する可能性は十分にあります。このようなネットワーク上で行われる攻撃については、近日出版予定の私の著書『Windows Server 2008 Security Resource Kit』(Microsoft Press®、2008 年) で詳しく説明しています。この記事では、その章の一部を変更してお届けします。
当然のことですが、保護対策の選択肢の 1 つは、リムーバブル ドライブの使用を禁止することです。これは賢明な対策であるように思えますが、このような対策を講じようとするものなら、駐車場で待ち伏せしているだれかに襲撃される可能性が高いでしょう。それに、このような行為を咎めるのも難しいかもしれません。重要度の高い機密データを保持しているほぼすべての環境において適切な対策は、その環境がはらんでいるリスクを管理して、危険にさらされるのを阻止することです。
また、クライアント コンピュータを危険にさらす方法は、リムーバブル ドライブだけではありません。「セキュリティに関する 10 の鉄則」(microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) を覚えていますか。鉄則 3 の文言は、ここでも当てはまります。つまり「悪意のある攻撃者があなたのコンピュータに対して物理的なアクセスを無制限に行える場合、もはやそれはあなたのコンピュータではない」ということです。この説明の状況では、攻撃者があなたのコンピュータにアクセスした場合、そのコンピュータは危険にさらされたと考えられるということです。攻撃者があなたのコンピュータでコードを実行できる場合、リモートからでも危害を与えることができます。これについては、「セキュリティに関する 10 の鉄則」の鉄則 1 として認識されている方がいらっしゃるかもしれませんね。つまり「悪意のある攻撃者の誘惑に乗って、攻撃者のプログラムをあなたのコンピュータで実行した場合、もはやそれはあなたのコンピュータではない」ということです。
この鉄則が有効であるのは間違いないでしょう。鉄則には順応性があることがわかっていますし、コンピュータのしくみが根本的に変わるまでは、著しく変化する可能性は高くないでしょう。そのため、既に説明したシナリオで、この鉄則がどのように当てはまるのかを考えると、リムーバブル ドライブを無効にすることは、非常に重要です。リムーバブル ドライブは、レジストリを調整することで無効にすることができます。
もちろん、追加の保護対策を講じる必要もあります。クライアント コンピュータの多くが、既に危険にさらされている、または組織でセキュリティに最も関心があり常時注意を払っているユーザーによって操作されているとは限らないと考えるのが妥当でしょう。つまり、このようなコンピュータのネットワークに対する影響を軽減する必要があるということです。そして、この必要性により、セキュリティの依存関係を理解、分析、および軽減することの重要性が高まります。
セキュリティの依存関係を定義する
セキュリティの依存関係は、あるコンピュータのセキュリティが別のコンピュータのセキュリティに依存する場合に起こります。「ドメイン コントローラ (DC) がハッキングに遭った場合、ネットワーク全体がハッキングされたことになる」と言われているのはご存知でしょう。これは、すべてのドメイン メンバのセキュリティは、DC に依存していることを簡潔に表しています。DC のセキュリティが確保されていなければ、メンバ コンピュータのセキュリティも確保されません。攻撃者がドメインのセキュリティ構成を変更できる場合は、たとえば、メンバ コンピュータの Administrators グループに新しいアカウントを追加することによって、ドメイン内のあらゆるコンピュータを乗っ取ることができます。管理者がコンピュータを危険にさらすことができるという脆弱性は、興味深いということでは済まされません。管理者は管理しているものなら何でも完全にアクセスできるのです。
コンピュータ システムの依存関係は避けることができません。実際には、依存関係は一般的で望ましい場合が多いです。ただし、だからと言ってすべての依存関係が許容されるものだというわけではありません。今月の記事では、許容される依存関係と許容されない依存関係の種類について説明します。また、依存関係の種類を分析して軽減する方法についても説明します。『Windows Server 2008 Security Resource Kit』では、特定の依存関係の詳細や依存関係を管理する方法について説明しています。
許容される依存関係
一般的に、セキュリティを確保するために、重要度の低いシステムが、より重要度の高いシステムに依存するという依存関係は許容されます。コンピュータとシステムは、一般的に重要度に基づいて分類することができます (ここで重要なのは、継承できる分類があるということなので、特定の環境における一連の分類は一般的な説明からは除外します)。説明の便宜上、ここではワークステーションと DC という 2 つの分類があるとします。このシナリオでは、セキュリティを確保するために、ワークステーションが DC に依存するのは許容される依存関係です。DC コンピュータは、ワークステーション コンピュータよりも機密性が確実に高いため、DC のセキュリティはワークステーションよりも強化されている必要があります。
ユーザー アカウントに関しても同じことが言えます。ユーザーが所有しているデータに管理者がアクセスするのは許容範囲です。これは、管理者は、より大きな責任があり、コンピュータとコンピュータ上のすべてのものに対して自由に (必ずしも直接または明示的にというわけではありませんが) アクセスできるからです。この点を理解してコンピュータを適切に管理すれば、この依存関係に問題はありません。
ソフトウェアについても同じように分析できます。セキュリティを確保するために、Web ブラウザなどの重要度の高くないソフトウェアが、オペレーティング システムなどの重要度の高いソフトウェアを使用して依存することは、もちろん許容される依存関係です。OS にバグがある場合、Web ブラウザも新しい問題に対して脆弱になるということは当然の結果です。しかし、一番の関心は OS や他の重要なアプリケーションとデータにあるため、Web ブラウザの脆弱性は緊急課題リストの下位項目として位置付けられるでしょう。これは、バグの修正方法や修正プログラムの適用箇所に関連しています。つまり、バグはできるだけ問題の根源で修正する必要があります。そうすることで、修正プログラムによる保護対象範囲を最大限にすることができます。そのため、Web ブラウザの問題に対処するよりも OS 自体の問題を修正する必要があるのです。
また、設計を変更することで依存関係をなくすこともできます。たとえば、Web ブラウザを書き換えて OS への依存度合いを軽減することができます。重要度の低いコンポーネント (たとえば、Web ブラウザ) が、セキュリティが厳重に確保されているコンポーネント (この場合は OS) の機能が、意図されていない用途に使用されている場合は、設計を変更するという後者のアプローチが適切です。
許容されない依存関係
許容される依存関係について説明したので、許容されない依存関係の定義はもう明らかでしょう。基本的に、セキュリティを確保するために、重要度の高いシステムが重要度の低いシステムに依存するようなことがあってはなりません。
ワークステーションが危険にさらされることが DC のセキュリティ侵害になる場合、セキュリティ上の重大な問題を抱えていることになります。ネットワークの総合的なセキュリティが、そのネットワーク上の個々のコンピュータに依存している場合、ネットワークを保護することは不可能です。
次の例を統計的に考えてみましょう。ネットワーク上のすべてのコンピュータが、稼動時間の 99.999% の間 "保護されている" 場合、安全なネットワークだと思われるかもしれません。実際、この割合は、今日の最も小規模なネットワークを除くネットワークの実状よりもはるかに高い数値でしょう。しかし、ネットワークに 40,000 台のコンピュータがあり、個々のコンピュータが稼働時間の 0.001% の間脆弱である場合を考えてみてください。ネットワーク全体は、その稼働時間のうち最大 40% の間、安全ではないと言えます。
依存関係が管理されていない場合、ネットワーク全体を危険にさらすのに必要なのは、そのたった 0.001% の脆弱な時間に 1 台のコンピュータに攻撃を加えるだけです。この場合、ネットワークはどのくらい安全でしょうか。機密性の高いシステムを機密性の高くないシステムから保護することが最も重要であるのは明白です。
ユーザー アカウントやソフトウェアについても、同じことが言えます。たとえば、Windows® の新しいターミナル サービス クライアントでは、ユーザー名とパスワードを保存して、ユーザーがターミナル サービスのログオン操作を意識しないようにすることができます。このような資格情報は、Credential Manager API (資格情報マネージャの API) を使用して保存され、最初のログオン セッションで使用される資格情報によって保護されています。
このような構成により、セキュリティの依存関係が生じます。ネットワーク管理者が自分のワークステーションにログオンしている場合について考えてみましょう。この管理者は、このワークステーションを使用して、電子メールやインターネットを閲覧したり、インフォメーション ワーカーが抱えている一般的な作業をしたりしています。もちろん、この用途には、権限の低いアカウントを使用しています。
1 日のうちのある時点で、彼女は DC の 1 つに接続して管理作業を行います。この作業には、ターミナル サービス クライアントを使用し、今後、簡単に接続できるようにパスワードを保存するようにしています。この構成により、少なくとも 1 つ、場合によっては 2 つの許容されないセキュリティの依存関係が生じます。1 つ目はドメイン管理者アカウントの資格情報が、権限の低いインフォメーション ワーカーの資格情報で保護されているということです。この権限の低いユーザー アカウントが危険にさらされると、ドメインの管理権限を持つユーザー アカウントも危険にさらされることになり、ドメイン全体に危害が加えられることになります。
2 つ目の依存関係は、ドメイン コントローラではないコンピュータでドメイン管理者の資格情報を入力したことにより生じます。管理者個人が使用しているワークステーションが、(おそらく、そのようなことはないでしょうが) 少なくとも DC と同レベルで保護されている場合を除き、DC のセキュリティが、ワークステーションのセキュリティに依存するという依存関係が生じます。たとえば、職場で不満を抱いている従業員がネットワーク管理者のワークステーションにキーストローク ロガーをインストールすると、ドメイン管理者の資格情報が取得されてしまいます。ドメイン コントローラではないコンピュータでドメイン管理者の資格情報を入力すると、ドメイン全体が、ドメイン コントローラではないコンピュータのセキュリティ上の欠陥にさらされることになります。
ドメイン管理者が、現在ログオンしている、ログオンしたことがある、またはログオンするであろうコンピュータに、攻撃者がリムーバブル ドライブを接続したとします。そのドメイン管理者は危険にさらされ、その結果、ドメイン全体も危険にさらされることになります。このような状況を回避するには、この状況を理解することが必要不可欠です。もちろん、ある特定のタスクを実行するために、安全性の高いアプリケーションが、安全性の低いアプリケーションの機能に依存する場合、ソフトウェアでも同じ事態が起こり得ます。
攻撃を分析する
悪意のあるリムーバブル ドライブをコンピュータに接続すると、どのようなことが起こるのかについては既に説明しました。ただし、何が起こるかが明確なのは、このようなリムーバブル ドライブが接続されたコンピュータについてだけだと思うので、その後の影響についても説明しましょう。では、図 1 に示すように、問題のコンピュータがドメインに参加しているとします。
図 1** 理想的なドメインの依存関係 **
この図は理想的な依存関係を表しています。矢印は依存関係の方向を表し、依存関係の継承元を指し示しています。たとえば、ワークステーションのセキュリティは DC のセキュリティに依存し、ユーザーのセキュリティはワークステーションのセキュリティに依存しています。攻撃者はワークステーションに侵入して、ユーザーがワークステーションに格納している情報を危険にさらすことはできるかもしれませんが、侵入はそこで食い止められます。
しかし、ワークステーションにログオンしたユーザーが、サーバーのローカルの Administrators グループのメンバである場合はどうでしょうか。また、このドメイン管理者が、サーバーに頻繁にログオンするとしましょう。この場合の依存関係は、図 2 のようになります。
図 2** 危険にさらされるドメインの依存関係 **
問題のコンピュータにログオンした人が変わるだけで、ネットワーク全体のセキュリティが危険にさらされてしまいます。ドメイン管理者は、サーバーにログオンするので、DC とドメイン全体のセキュリティは、そのサーバーのセキュリティに依存します。
サーバーで DC と同レベルのセキュリティが確保されていれば、これは許容される依存関係です。ただし、この場合、ワークステーションにログオンしたユーザーは、サーバーの Administrators グループのメンバなので、サーバーのセキュリティはワークステーションのセキュリティに依存します。つまり、ドメイン全体のセキュリティがワークステーションのセキュリティに依存するということになります。そして、このワークステーションで、攻撃者が用意したツールをユーザーが間違って実行してしまったら、どうなるでしょうか。
今日の情報セキュリティにおいて、セキュリティの依存関係を把握することよりも重要な概念は、ほとんどないと言えるでしょう。ネットワークの分析を始めて依存関係を把握しようとすれば、ほぼ間違いなく、許容されない依存関係に遭遇するでしょう。最悪のシナリオは、皆さんが考えるよりもありふれているものですが、ネットワーク全体のセキュリティがネットワーク全体に依存している場合です。つまり、個々のコンピュータのセキュリティがなんらかの方法で他のすべてのコンピュータのセキュリティに依存しているという場合です。このような環境では、依存関係を制御できず、その複雑さは理解し難いので、どのような種類の現実的で理にかなったリスク管理戦略も立てることはできません。この場合の解決策は、依存関係を分析して管理することです。
今月の記事では、依存関係の概略と、依存関係を分析して軽減する方法について簡単に説明しました。詳細については、私の著書『Windows Server 2008 Security Resource Kit』をご覧いただければ、と思います。この本には、管理者アカウントの管理などのありふれた手法だけでなく、サーバーとドメインの分離などの高度な技術を併用し、依存関係を分析および軽減することによるネットワークの保護に関するトピックに特化した章があります。
このコラムの基になった荒削りのアイデアを形作るのに協力してくれた David LeBlanc 氏に感謝します。
Jesper M. Johansson は、ソフトウェアのセキュリティ問題に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。**MIS の博士号を持ち、セキュリティの分野で 20 年以上の経験があります。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.