セキュリティのジレンマ（パート2）: 侵入防止

執筆者: Matt Frye

• はじめに
• システムの特徴付け
• 潜在的ターゲットの特定
• セキュリティの実装
• セキュリティ確保に必要な体制: チームワーク
• 結論
• 執筆者について

はじめに

このシリーズの最初のパートでは、誰かがLinuxシステムに対する無許可のアクセス権を取得したことがわかった場合の措置、考慮事項、および調査項目に焦点を合わせました。このシリーズの第2のパートでは、システムが脆弱化される前にとるべき措置を中心に説明します。この記事では、特定の技術的ソリューションに集中するのではなく、安全な思考プロセスについて概説し、考慮事項を示します。

システムの特徴付け

システムを攻撃または侵入から保護する最初のステップは、システムを分類することです。システムを、その重要性、データ損失のリスク、およびシステム復旧に必要な時間に基づいて分類すれば、システムに割り当てるべきリソース、およびシステムを効果的に保護する方法を効率的に確認できます。

資産を保護する最初のステップは、その資産の価値と対象を把握することです。システムをその目的と可用性の要件に基づいて定義することによって、それらのシステムをセキュリティ要件に関してより効果的に評価できます。この記事では、説明と単純化のために、サーバについて3つの異なるグループを考えます。

Production Available（PA）システムとは、その目的と可用性がコアビジネスを規定しているようなシステムです。これらのシステムは、多くの場合、本質的に計算に関係するシステムです。たとえば、銀行や証券会社のトレーディング用クラスタ、または取引システムなどです。

Data Available（DA）システムとは、データベース、CRM、ERP、その他の特に管理対象データが活用されるシステムを指します。DAシステムは、本稼動のデータセンターではPAシステムに対して同様に重要ですが、それらはビジネスを継続させるにとどまらず、ビジネスを支えています。

Customer Available（CA）システムは、顧客にサービスを提供する一方、ビジネスプロセスを最適化して収益を増加させ、消費者の生産性を高めます。これらのシステムは、多くの場合、PAシステムのフロントエンドを構成します。

もちろん、これらはこの記事のために便宜的に採用したシステムの一般的分類に過ぎません。お分かりのように、多くのシステムはこれらのカテゴリに重複して含まれます。しかし、PA、DA、CAは、ホストベースのセキュリティ、およびこれらのサーバをセキュリティとアプリケーションのインフラストラクチャに統合する方法との関係でシステムを評価するのに役立ちます。

このシリーズの最初のパートでは、システムが侵犯された場合にとるべき措置を決定するためのRisk of Action（rA）について説明しました。rAを利用すると、システムの特徴付けの際、データのセキュリティに特に注意する必要があるかどうかを事前に評価できます。たとえば、PAシステムは通常、Risk of Intrusion（rI）がValue of Data（vD）を超える場合に正のrAを持ちます。これはPAシステム内のデータが価値を持たないという意味ではありませんが、相対的価値としてrAは正になります。rAが正の場合、データリカバリの必要性は小さく（または相対的に小さく）なりますが、ダウンタイムは許容しにくくなります。したがって、PAシステムでは、アクティブセキュリティに向けた措置を強化することが重要になります。

注: rAを事前に計算しておくと、ホストベースのセキュリティポリシーの定式化が容易になります。また、rAによってデータリカバリの必要性を確認できます。

DAシステムでは、評価はほぼ反対になります。この場合もセキュリティが問題となりますが、rAは負になり、データの完全性とリカバリが第1の関心事になります。rAが負の場合は、システムを閉鎖してセキュリティ問題に対応する方が効果的であるため、アクティブセキュリティは二義的になります。

CAシステムはPAとDAの中間になり、その位置付けは使用するセキュリティおよびアプリケーションインフラストラクチャに左右されます。CAシステムでは多くの場合、リスクは小さくなりますが、その目的のためにインターネット上でパブリックIPアドレスを持つ場合があります。これらは攻撃者によってスキャンされるマシンとなるため、アクティブセキュリティとデータリカバリへの即応性とのバランスを保証します。一般に、CAシステムはソフトウェアアーキテクチャのライフサイクルを通じて拡張され、移行されるため、PAシステムへと変化する傾向があります。

潜在的ターゲットの特定

計算済みのrAを利用すれば、明白なターゲットを簡単に特定できます。ビジネスクリティカルなPAシステムはもちろんですが、DAおよびCAシステムが侵犯され、脆弱化された場合も、簡単に1つの事業単位が麻痺させられます。しかし、問題はそれほど単純ではありません。攻撃の潜在的ターゲットを実際に特定するには、攻撃者と同様に考える必要があります。

一般的な攻撃は、次の5段階で実行されます。

・構成調査と探索
・脆弱性の評価
・攻撃の設計と準備
・攻撃の実行
・痕跡の隠蔽

一連の流れの始めに、攻撃者はまず、侵入する入口のあたりをつけます。攻撃者はここでターゲットを特定しますが、防御側でもそれは可能です。攻撃者が特定のシステムを探しているわけではない場合（その可能性はあっても低い）、このプロセスは不安に満ちていますが、備えによって緩和できる場合もあります。上記の5つのステップと同様、攻撃は一般に法医学的パターンに従います（このシリーズのパート1を参照）。攻撃者の視点に立つと、環境内でドア（システム）のまわりを調べることによって、最初のターゲットの位置がすぐに分かります。

攻撃者は特定のシステムを探すことはほとんどありませんが、特定のタイプのシステムを探す傾向があります。簡単に侵犯できるシステムだけでなく、攻撃者は影響の大きい強力なシステムを探し出します。たとえば、Webサービスに対する攻撃では、攻撃者はWebサーバ、またはそれらのサーバにコンテンツを提供するソースを探します。

セキュリティの実装

起こり得る事態については説明したので、次にシステムのセキュリティを確保する措置について説明します。侵入者と同様に思考して環境に対する架空の攻撃を考えます。攻撃者の手順に従うことは、語学の訓練のようなものです。相手のやり方に従って対応します。

ここでホストレベルから考えることをやめて、ネットワーク全体を検討することにします。ルータ、スイッチ、サーバ、ワークステーションなど、インターネットに接続されているすべてのマシンを確認します。次に、それらのマシンに実装されたセキュリティ対策とrAを評価します。主要なファイアウォール、またはファイアウォールクラスタを配置している場合、これは第1の防衛ラインとなるため、データセンター内で最も高い（物理的およびネットワーク）セキュリティを備えたマシンにする必要があります。また、これは管理者が最も少ないマシンにします。コンピュータのセキュリティの度合いが管理者の信頼性に左右され、ユーザあたりの管理者数が多いほどリスクが高まることは広く認められています。

攻撃者は環境に侵入すると、たいていの場合、マシン全体を支配しようとするだけでなく、コンポーネントごとにシステムを悪用します。そのため、サーバをターゲットとして識別するにとどまらず、攻撃のコンポーネントをレイヤごとに考えることが有益です。Douglas Adams氏の言葉を借りれば、「深く考える（Think deep）」ということです。言い換えると、iptablesだけでは不十分です。システムを安全にするには、レイヤ単位でシステムのセキュリティを確保する必要があります。システムとデータのセキュリティを、攻撃者が考えるのと同様に考えます。

ウォッチリストとrAがあれば、システムにおけるセキュリティとユーザビリティのバランスについて決定を下すことができます。このタイプのサーバのセキュリティ確保には何が必要か。このマシンのセキュリティ要件は、どのようにセキュリティおよびアプリケーションインフラストラクチャに適合するか。十分なセキュリティを確保すると同時に、システム管理者やデータベース管理者などの作業遂行を妨げない措置は何か。

セキュリティ確保に必要な体制: チームワーク

セキュリティは、結局のところリスク管理に関係します。それは、ポリシー、プロセス、およびチームワークによる対策と軽減措置です。セキュリティポリシーはビジネス要件をサポートするとともに、企業の許容レベルにまでリスクを軽減します。

新しいセキュリティポリシーの実装は、個別のガイドラインまたはブレティンによって実現できます。各文書は電子メール、ファイアウォール、パスワードといった1つの主題を扱う必要があり、テストできるように十分詳細であることが必要です。内容は簡潔に絞り込み、責任を適切な組織レベルに割り当てます。

セキュリティチーム以外のスタッフも関与する必要があります。そうしなければ、おそらく十分な検討が行われません。セキュリティポリシーには現実性が必要です。ユーザが馬鹿げたポリシーだと考えたら、彼らがそれに従う可能性は低くなります。

現実的なポリシーが作成されたと判断したら、企業内で上級管理職の支持を取り付けます。この支持によってポリシーの実施が可能になり、それに従わないと実際に不利益を被ることがユーザに明らかになります。

ポリシーを導入したあと、実際にセキュリティ確保を実践することは、システムを使用する個々のスタッフの責任です。全スタッフがセキュリティ意識を高め、システムを積極的に監視するように働きかけます。

結論

セキュリティとは、詰まるところテクノロジとポリシーの組み合わせです。テクノロジによって完全に安全な世界が実現できれば素晴らしいことですが、完璧なセキュリティを実現するには、現在も、また今後も存在し得ないような完璧さが必要です。ソフトウェアは不完全なものであり、あらゆるソフトウェアにバグがあります。ソフトウェアを完璧に作成できたとしても、セキュリティのジレンマは完全には解決されません。大部分の攻撃には、何らかの人為的操作が関与するからです。攻撃技術の困難性を高めても、攻撃者はコンソールを操作するユーザに重点を移します。これはすでに多くのケースでそうなっています。セキュリティを維持するうえでの自分の役割を理解することによって、ユーザは脆弱ポイントになることを避けられます。

セキュリティとは、相対的、比例的で、また流動的なものです。システムおよびセキュリティ管理者は動的である必要があり、その標語は感知せよということです。

執筆者について

Matt Fryeは、ノースカロライナ在住のUNIX/Linuxシステム管理者です。彼はNorth Carolina System Administratorsの会長であり、Triangle Linux User Groupの活動的なメンバーです。余暇には、フライフィッシングとメンタルカンフーを楽しんでいます。