ユーザーがインストールしたグレーウェアから知らないうちに感染したトロイの木馬ダウンローダーまで、迷惑アプリケーションを仕込まれたビジネスPCはあまりに多い。Microsoftの「Windows 7 AppLocker」(以下、AppLocker)は、実行できるプログラムを制限することにより、業務用PCを守る戦いで新たな攻勢に出た。
本稿はAppLockerに関する2回にわたる連載の第1回目として、AppLockerとWindows XP/Vista Software Restriction Policies(SRP)との違い、およびAppLockerのルール定義方法について解説する。
迷惑アプリケーションや正体不明アプリケーションの実行を防ぎたいというのは今に始まったことではない。管理者は何年も前から、デスクトップセキュリティの強化と柔軟性、効率性と管理しやすさとの間で、ちょうどいいバランスを見つけ出そうと努めてきた。
エンドユーザーから管理者権限を取り上げることで、ある程度の成功は収めたが、仕事とは無関係で権限がなくても実行できるプログラムを防ぐ役には立たなかった。各プログラムの実行前に暗号ハッシュを確認するといった“力ずく”の技術の場合、最新のソフトウェアパッチ適用との終わりなき競争になる。しかし、レジストリキーやファイル名/パスに基づいてグレーウェアをブロックするといった、メンテナンスが容易なアプローチでは簡単にかわされてしまう。
Windows XP/Vista SRPを利用する管理者がほとんどいないのは、以上のような理由による。SRPを使っている企業は通常、ブラックリスト、すなわちソースネットワークゾーン、パス名、ハッシュあるいは署名付き証明書に基づいて既知のマルウェアをブロックする「Group Policy Objects」(GPO)を作成する。具体的には、デフォルトのセキュリティレベル定義よりもSRPのルールを優先する形で、制限を解除したり(デフォルトが「許可しない」になっている場合)、あるいは制限を掛けたりする(デフォルトが「制限しない」になっている場合)。ただし、確実なSRPルールを定義するのは難しいため、ほとんどの企業はデフォルトのままの「制限しない」になっており、どんなプログラムでも自由な動作を取り立てて禁止されない状態にある。

MicrosoftはSRPに代わるAppLockerを、Windows Server 2008 R2とWindows 7 Enterprise/Ultimateで提供している。後方互換性を持たせるため、GPOはSRPとAppLockerの両方のルールに対応できる。この場合、AppLockerのルールはWindows 7搭載PCにのみ適用され、SRPルールはそれよりも古いPCにのみ適用される。
AppLockerはSRPと同様、プログラムの起動を許可あるいは不許可にできる。しかしAppLockerではポリシー定義方法が逆になり、デフォルトで「許可しない」設定になっている。Application Identity(AppID)サービスを起動してAppLockerルールを1つでも適用すると、AppLockerルールが割り当てられていないプログラムはすべて起動できなくなり、「このプログラムはグループポリシーによってブロックされています」というメッセージが表示される。
AppLockerはこの方法で、ブラックリストではなくホワイトリストの作成を強く促している。AppLockerのホワイトリストもメンテナンスは必要だが、許可したいプログラムをすべて指定するのは、正体不明でもしかしたら有害かもしれないプログラムを遮断する対象としてすべて洗い出す作業に比べればはるかに容易だ。その理由を理解するために、AppLockerルールの定義方法を見ていこう。
SRPルールが全ユーザー(または管理者を除く全ユーザー)に適用されるのに対し、AppLockerのルールはすべてが特定ユーザーまたはグループに限定され、ビジネスニーズに合わせて大まかなルールときめ細かなルールを組み合わせることも容易になる。ほとんどの管理者は、少数の大まかなAppLockerルールを全員に適用することから始め、その後「典型ユーザー」のプログラムを許可するルールで慎重に例外を設定しながら調整していく。
SRPルールの手法は簡単にかわすことができてしまい、制限が多過ぎて実用には向かず、メンテナンスも難し過ぎた。AppLockerはこれら手法のうちの2つをやめて、最も有用な手法を拡大し、効果の高さとメンテナンスしやすさのバランスを向上させている。具体的には、AppLockerルールは3種類の手法、すなわちパブリッシャールール(推奨)、ハッシュルール(署名のないプログラム)、パスルール(ほかに方法がない場合の最後の手段)に基づいて、プログラムの起動を許可するかしないかを決めている。
署名付きの実行可能ファイル(exeファイル)、インストーラ(msiMSI、mspMSPファイル)、スクリプト(バッチ、JavaScript、VBSファイルを含む)、ライブラリ(最終的にはdllDLLファイル)のデジタル署名をチェックして、プログラムの起動を許可または禁止する。パブリッシャールールは許可または禁止したいプログラムのリファレンスコピーを参照することにより作成される。このルールには、当該プログラムの署名から入手したソフトウェアパブリッシャー、製品名、ファイル名と(ファイルの)バージョンといった値が自動的に記録される。最後にスライダーを使ってルールの粒度を調整する。特定パブリッシャーのプログラムをすべて禁止することも、個別のプログラムの最低バージョンのみを許可することも可能だ。結果的に、パブリッシャールールはSRPの証明書ルールに比べて柔軟性が大幅に向上し、適用できるプログラムの数も増えた。
プログラムファイルの暗号ダイジェストを、以前作成しておいたそのファイルのフィンガープリント(特徴)と照らし合わせ、名称や場所と関係なくチェックできる。しかしSRPのハッシュルールと異なり、AppLockerはユーザーごと、グループごとにハッシュルールを適用でき、例外も指摘できる。それでもハッシュのメンテナンスは頭痛の種だが、AppLockerは利用できる署名がないプログラムにのみハッシュルールを奨励するので、負担は減る。
プログラムファイルが実際にある場所(ローカルフォルダ、ネットワークパス)と、スペック上あるべきパスとを照らし合わせる。この手法はSRPでも使われているが、AppLockerのパスルールは、パブリッシャールールもハッシュルールも複雑過ぎたり適用が難しいプログラムにのみ使われる最後の手段という想定だ。パスルールの好例として、Windowsディレクトリで誰もが、どんなプログラムでも実行を許されるようなケースが挙げられる。エンドユーザーがそのディレクトリにファイルを保存する権限を持たなければ、パスルールは安全かつ容易に、全員にOSの実行許可を与える手段になる。
最後に、AppLockerルールはSRPルールとは異なり、例外指定を盛り込むことができる。セキュリティポリシーは大部分の(だが全員ではない)グループやユーザーに適用されることが多く、この点が変わっただけでも、実際的なセキュリティポリシーの強制がはるかに容易になる。ただし、AppLockerルールが適用(あるいは適用除外)できるのはグループとユーザーのみであり、インターネットゾーンや個々のコンピュータには適用できないことを覚えておきたい。
本稿筆者のリサ・ファイファー氏はCore Competenceの副社長。25年以上にわたってネットワーク、セキュリティ、管理製品の設計、導入、評価に携わり、大小の企業を対象に、セキュリティの必要性、製品評価、新興技術の利用、ベストプラクティスについて助言してきた。