AppLocker のセキュリティに関する考慮事項
IT 担当者向けのこのトピックでは、AppLocker の実装時に対処する必要のあるセキュリティ上の考慮事項について説明します。
AppLocker の目的は、ユーザーの特定のグループに対して、または定義したビジネス グループ内で、ソフトウェアと、そのソフトウェアによってアクセスされるデータへのアクセスを制限することです。次に示しているのは、AppLocker に関するセキュリティ上の考慮事項です。
AppLocker は企業内に展開され、信頼された資格情報を持つ IT 部門によって一元的に管理されます。これにより、ポリシーの作成と展開は、同様のポリシー展開プロセスとセキュリティ上の制限に準拠するようになります。
AppLocker ポリシーは、既知のプロセスと手段によって、グループ ポリシーを介してドメイン内に配布されます。しかし AppLocker ポリシーは、管理者権限のあるユーザーが個々のコンピューターで設定でき、設定されたそれらのポリシーは、組織で定義されたセキュリティ ポリシーに反する可能性があります。ローカル ポリシーの実施設定は、グループ ポリシー オブジェクト (GPO) 内の同じ AppLocker ポリシーによって上書きされます。ただし、AppLocker 規則は付加的なものであるため、GPO にないローカル ポリシーはそのコンピューターに対して評価されます。
マイクロソフトは、AppLocker の拡張機能を開発する方法を提供していません。そのインターフェイスは公開されていません。管理者の資格情報を持つユーザーは、Windows PowerShell コマンドレットを使って、AppLocker の一部のプロセスを自動化できます。AppLocker 用の Windows PowerShell コマンドレットを使用する方法について詳しくは、Windows PowerShell の AppLocker コマンドレットに関するページをご覧ください。
AppLocker は、最上位の特権である Administrator または LocalSystem のコンテキストで実行されます。このセキュリティ コンテキストには誤用の可能性があります。管理者の資格情報を持つユーザーが、ドメインに参加しているローカル デバイスで AppLocker ポリシーを変更した場合、それらの変更は、ローカル デバイスで変更した同じファイル (またはパス) に対する AppLocker 規則を含む GPO によって、上書きまたは拒否されることがあります。ただし、AppLocker 規則は付加的なものであるため、GPO にないローカル ポリシーはそのコンピューターに対して評価されます。ローカル コンピューターがドメインに参加しておらず、グループ ポリシーによって管理されていない場合、管理者の資格情報を持つユーザーは AppLocker ポリシーを変更できます。
パス条件を使う規則によってディレクトリ内のファイルを保護するときは、規則で使っているのが許可アクションか拒否アクションかにかかわらず、セキュリティ ポリシーに従ってアクセス制御リスト (ACL) を設定することで、それらのファイルへのアクセスを制限することをお勧めします。
AppLocker は、仮想 DOS コンピューター (NTVDM) での 16 ビット DOS バイナリの実行に対する保護を提供しません。このテクノロジでは、Intel 80386 以降を使っているコンピューターで従来の DOS および 16 ビットの Windows プログラムを実行できますが、このとき、既に別のオペレーティング システムが、そのハードウェアを実行および制御していることがあります。つまり、AppLocker が Windows Server 2008 R2 と Windows 7 以外でバイナリとライブラリをブロックするように構成されていても、16 ビット バイナリが Windows Server 2008 R2 と Windows 7 で引き続き実行できます。16 ビット アプリケーションを実行できないようにするには、NTVDM.exe の実行可能ファイル規則のコレクションで拒否規則を構成する必要があります。
AppLocker (またはソフトウェアの制限のポリシー) を使って、Win32 サブシステム外でコードが実行されないよう指定することはできません。具体的には、これは Windows NT の (POSIX) サブシステムに適用されます。アプリケーションが POSIX サブシステムで実行されないようにするには、サブシステムを無効にする必要があります。
AppLocker は、VBScript、JScript、.bat ファイル、.cmd ファイル、および Windows PowerShell スクリプトのみを制御できます。Perl スクリプト、マクロなど、ホスト プロセス内で実行される解釈済みコードの中には制御されないものもあります。解釈済みコードは、ホスト プロセス内で実行される実行可能コードの一種です。たとえば、Windows バッチ ファイル (* .bat) は、Windows コマンド ホスト (cmd.exe) のコンテキスト内で実行されます。AppLocker を使って解釈済みコードを制御するには、ホスト プロセスは、その解釈済みコードを実行する前に AppLocker を呼び出してから、AppLocker によって返された決定を適用する必要があります。すべてのホスト プロセスが AppLocker で呼び出されるとは限らないため、Microsoft Office のマクロなど解釈済みコードの中には AppLocker によって制御できないものがあります。
重要
それらのコードが実行されるようにするには、これらのホスト プロセスのセキュリティ設定を適切に構成する必要があります。たとえば、信頼された署名済みマクロのみが読み込まれるように、Microsoft Office でセキュリティ設定を構成します。
AppLocker 規則を使うと、アプリケーションの起動を許可または禁止できます。AppLocker では、アプリケーションの起動後に、そのアプリケーションの動作は制御されません。アプリケーションには、規則を回避して他の .exe または .dll の読み込みを許可するように AppLocker に通知するフラグ (関数に渡すことが可能) が含まれている場合があります。実際、AppLocker によって許可されたアプリケーションが、これらのフラグを使って AppLocker 規則を無視し、子プロセスを起動することは可能です。AppLocker 規則を使ってアプリケーションの実行を許可する前に、それらの各アプリケーションを徹底的に検証する必要があります。
注
この状態を示すフラグは、SANDBOX_INERT (CreateRestrictedToken に渡すことが可能) と LOAD_IGNORE_CODE_AUTHZ_LEVEL (LoadLibraryEx に渡すことが可能) です。これらのフラグはいずれも、規則を回避して子 .exe または .dll の読み込みを許可するように AppLocker に通知します。