アプリケーションコントロールの仕組み

Deep Security 10で導入された新機能です。

ほとんどの管理者は、コンピュータに最初にインストールされていたソフトウェアと比較し、その変更 (「ドリフト」または「デルタ」) に絞って監視することを望んでいます。アプリケーションコントロールはこのアプローチに対応して設計されています。

アプリケーションコントロールを有効にすると、Deep Security Agentで次のいずれかが実行されます。

• インストールされているソフトウェアのインベントリが検索され、初期ローカルルールセットが作成されます。または、
• 選択した共有ルールセットがダウンロードされます (APIで共有ルールセットを作成している場合)。

これがインストールされたソフトウェアを検索する際のベースラインとなり、そのコンピュータ上で想定される正常な状態のリストです。アプリケーションコントロールでは、現在インストールされているソフトウェアは承認されているものとみなされ、ベースラインのソフトウェアを許可する一連の初期ルールが作成されます (共有ルールセットは、APIを使用してDeep Security ManagerにそのルールセットをアップロードしてAgentの既存のローカルインベントリを変換すると作成されます。共有ルールセットはインベントリが完全に一致するコンピュータにのみ適用する必要があります)。

その後、Deep Security Agentは継続的にコンピュータを監視して変更の有無を確認します。アプリケーションコントロールカーネルおよびファイルシステムに統合されているため、ルートアカウントまたは管理者アカウントでインストールされたソフトウェアを含め、コンピュータ全体を監視する権限があります。監視対象は、ソフトウェアファイルに対するディスク上の書き込みアクティビティとソフトウェアの実行です。新規のソフトウェアやソフトウェアの変更を判定するために、最初にインストールされていたソフトウェアのハッシュと比較し、以下が異なる場合に変更であるとみなします。

• ファイル名
• パスまたは場所
• タイムスタンプ
• 権限
• ファイルコンテンツ

アプリケーションコントロールを有効にすると、メンテナンスモードの場合を除き、ソフトウェアのすべての変更がログに記録されます。ファイルシステムで新規または変更されたソフトウェアが検出されたり、許可されていないソフトウェアの実行が試行されたりするたびに、アプリケーションコントロールによってイベントが生成されます。ソフトウェアの起動が試みられたときにそのソフトウェアを許可またはブロックするルールを作成できます。

アプリケーションコントロールは、新しいソフトウェアが見つかったときに、そのソフトウェアを許可するかブロックするかを判定する必要があります。この判定には、ソフトウェアファイルの次の情報が使用されます。

• ハッシュ
• ファイルサイズ
• パス
• ファイル名

これらの情報を許可ルールまたはブロックルールのエントリと照合して、次の3つの状況のいずれに該当するかが特定されます。

• 許可ルールに登録されている (「既知の」ソフトウェア)
• ブロックルールに登録されている (「既知の」ソフトウェア)
• どちらにも登録されていない (「承認されていない」ソフトウェア)

「承認されていない」ソフトウェアと判定された場合は、アプリケーションコントロールイベントログの [理由] 列に、許可ルールまたはブロックルールと完全に一致しない理由が表示されます。

承認されていないソフトウェア (ルールで明示的に許可していない変更) は、無害なパッチアップデートである可能性も、危険なITセキュリティポリシー違反である可能性もあります。そのため、セキュリティ方針に応じて、アプリケーションコントロールでの承認されていないソフトウェアの処理方法を次のいずれかに設定できます。

• 実行を許可
• 実行をブロック

ブロックルールに登録されているか承認されていないためにブロックされたソフトウェアは起動できません。ソフトウェアによっては、そのソフトウェアの実行が許可されないことを示すOSからのエラーメッセージが表示されます。

アプリケーションコントロールで検出されるソフトウェア

すべてのファイルを監視する変更監視とは異なり、アプリケーションコントロールで初期インストールの調査時と変更の監視時に確認されるのはソフトウェアファイルのみです。

ソフトウェアには次のものも含まれます。

• Linuxの.soライブラリ (およびその他のコンパイルされたバイナリやライブラリ)
• Javaの.jarファイルと.classファイル (およびその他のコンパイルされたバイトコード)
• PHP、Python、シェルスクリプト (およびその他の実行時に変換またはコンパイルされるWebアプリやスクリプト)

たとえば、WordPressとそのプラグイン、Apache、IIS、nginx、Adobe Acrobat、app.war、/usr/bin/sshは、いずれもソフトウェアとして検出されます。

アプリケーションコントロールでテキストファイルとスクリプトを区別する基準に関して言えば、テキストドキュメントには実行権限がありませんが、Deep Securityのアプリケーションコントロールでは、実行権限がない場合でも、次にあげるPHP、Python、またはJavaの次のファイル拡張子を持つファイルはソフトウェアとして検出されます。

• .class
• .jar
• .war
• .ear
• .php
• .py
• .pyc
• .pyo
• .pyz

ローカルルールセットと共有ルールセット

パフォーマンスと管理の負荷を改善するために、ローカルルールセットと共有ルールセットのどちらか、またはその両方を使用できます。

• 共有ルールセット: すべてのルールデータをAgentとManager/Relay (有効になっている場合) の両方に同期します。これにより、ネットワークとディスクの使用量が増加します。ただし、初期インベントリ検索またはメンテナンスモードのルールを確認する必要がある場合、または設定が同一でなければならない多数のコンピュータで構成されるサーバファームを管理する場合は、共有ルールセットを使用する方が業務を簡素化できることがあります。共有ルールセットは、同じ構成のLAMP Webサーバで構成されるサーバプールや、複数仮想マシンでオートスケーリンググループを構成している場合などに便利です。また、管理者の作業負担を軽減できます。

  [承認されていないソフトウェアを明示的に許可するまでブロック] を有効にしている場合は、コンピュータの構成が完全に一致していないかぎり、共有ルールセットを使用しないでください。最初のコンピュータのルールセットには含まれていない他のコンピュータ上のソフトウェアがすべてブロックされます。それらのソフトウェアに重要なファイルが含まれている場合は、OSが破損する可能性があります。このような問題が発生した場合は、再インストール、バックアップの復元、またはOSリカバリモードの使用が必要になることもあります。
• ローカルルールセット: これが初期設定です。一部のデータを特定のコンピュータにのみ、ローカルに保持します。Deep Security Managerで設定された許可ルールまたはブロックルールはAgentに送信され、ManagerとAgentの両方に保持されます。ただし、Agentの初期インベントリ検索またはメンテナンスモードの許可ルールはManagerまたはRelayにアップロードされません。これにより、ネットワークの使用量とデータベースのディスク使用量が削減されます。ただし、Deep Security Managerでローカルルールセットを表示しても、ManagerにはAgentのローカルデータが存在しないためルールが表示されません。また、コンピュータの構成が完全に一致していて、同じルールセットを使用できる場合にこの設定を使用すると、管理者の作業負荷の増加につながります。