AppLocker ポリシー設計の決定について
IT 担当者向けのこのトピックでは、Windows オペレーティング システム環境内で AppLocker を使ってアプリケーション制御ポリシーの展開を計画するときの設計に関する質問と考えられる回答、および決定の影響について説明します。
設計と計画プロセスを開始する場合は、設計に関する選択がどのような影響を及ぼすかを検討する必要があります。決定事項は、ポリシーの展開スキームと以降のアプリケーション制御ポリシーのメンテナンスに影響します。
次のすべてに該当する場合に、組織のアプリケーション制御ポリシーの一部として AppLocker を使用することを検討してください。
サポートされているバージョンの Windows が既に組織に展開されている。または、今後展開する予定である。特定のオペレーティング システムのバージョンの要件については、「AppLocker を使用するための要件」をご覧ください。
ユーザーがアクセスする組織のアプリケーションとデータへのアクセス制御を強化する必要がある。
組織内のアプリケーションの数がわかっていて、管理しやすい。
組織の要件に対するポリシーをテストするためのリソースを保持している。
エンドユーザーのアプリケーション アクセスの問題に関して、ヘルプ デスクを関与させるためのリソース、またはセルフ ヘルプ プロセスを構築するためのリソースを保持している。
生産性、管理容易性、およびセキュリティに関するグループの要件を、制限の厳しいポリシーで制御できる。
次の質問は、優先度順または発生順には並んでいません。次の内容は、アプリケーション制御ポリシーを展開するときに、(対象となる環境に応じて) 考慮する必要があります。
組織ではどのようなアプリを制御する必要がありますか。
組織では、機密データにアクセスする少数のアプリだけを制御すればよい場合もあれば、ビジネス上の目的で許可されたもの以外、すべてのアプリケーションを除外しなければならない場合もあります。また、厳密な制御を必要とするビジネス グループもあれば、独自のアプリケーションの使い方を推進するグループもあります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
すべてのアプリを制御します |
AppLocker ポリシーは、ファイルの種類ごとにアプリケーションの許可一覧を作成することで、アプリケーションを制御します。例外を設定することも可能です。AppLocker ポリシーは、サポートされているバージョンの Windows のいずれかを実行しているコンピューターにインストールされたアプリケーションにのみ適用できます。オペレーティング システムのバージョンに関する具体的な要件については、「AppLocker を使用するための要件」をご覧ください。 |
特定のアプリを制御します |
AppLocker 規則を作成すると、許可されたアプリの一覧が作成されます。その一覧に含まれているアプリは、すべて実行が許可されます (例外の一覧に含まれるアプリは除きます)。一覧に含まれないアプリは実行できません。AppLocker ポリシーは、サポートされているバージョンの Windows のいずれかを実行しているコンピューターにインストールされたアプリにのみ適用できます。オペレーティング システムのバージョンに関する具体的な要件については、「AppLocker を使用するための要件」をご覧ください。 |
従来の Windows アプリケーションのみ、ユニバーサル Windows アプリのみ、またはその両方を制御します |
AppLocker ポリシーは、ファイルの種類ごとにアプリの許可一覧を作成することで、アプリを制御します。ユニバーサル Windows アプリは発行元条件に基づいて分類されるため、従来の Windows アプリケーションとユニバーサル Windows アプリを一緒に制御することができます。ユニバーサル Windows アプリの AppLocker ポリシーは、Windows ストアをサポートするコンピューターにインストールされたアプリケーションにのみ適用できます。一方、従来の Windows アプリケーションは、サポートされているすべてのバージョンの Windows で AppLocker を使って制御できます。したがって、従来の Windows アプリケーションに対して現在構成されている規則はそのまま残し、ユニバーサル Windows アプリに対して新しい規則を作成することができます。 従来の Windows アプリケーションとユニバーサル Windows アプリの比較については、このトピックの「AppLocker ポリシーの設計に関する従来の Windows アプリケーションとユニバーサル Windows アプリの比較」をご覧ください。 |
ビジネス グループとユーザーによってアプリを制御します |
AppLocker ポリシーは、グループ ポリシー オブジェクト (GPO) を通じて、組織単位 (OU) 内のコンピューター オブジェクトに適用できます。各 AppLocker 規則は、個々のユーザーまたはユーザー グループに適用できます。 |
ユーザーではなくコンピューターごとにアプリを制御します |
AppLocker は、コンピューター ベースのポリシーの実装です。ドメインまたはサイトの組織構造が、OU などの論理ユーザー構造に基づいていない場合は、AppLocker の計画を開始する前に、その構造のセットアップが必要になる可能性があります。それ以外の場合は、ユーザー、ユーザーのコンピューター、ユーザーのアプリ アクセスの要件を特定する必要があります。 |
アプリの使用状況を把握する必要はありますが、アプリを制御する必要はありません |
アプリの使用状況を監査するように AppLocker ポリシーを設定すると、組織で使われているアプリを追跡するために役立ちます。その後、AppLocker イベント ログを使って AppLocker ポリシーを作成できます。 |
重要
AppLocker で管理できないファイルまたはファイルの種類を次に示します。
AppLocker は、NT 仮想 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 を呼び出すわけではありません。したがって、AppLocker が、すべての種類の解釈済みコードを制御できるとは限りません (Microsoft Office マクロなど)。
重要
これが実行されるようにするには、これらのホスト プロセスのセキュリティ設定を適切に構成する必要があります。たとえば、信頼できる署名済みマクロのみが読み込まれるように、Microsoft Office でセキュリティ設定を構成します。
AppLocker 規則は、アプリの起動を許可または禁止するものです。アプリの起動後の動作が AppLocker によって制御されることはありません。アプリケーションでは、関数にフラグを渡すことで、AppLocker 規則を回避し、他の .exe ファイルや .dll ファイルの読み込みを許可するように AppLocker に通知することができます。このため、実際には、AppLocker によって許可されたアプリであれば、これらのフラグを使って AppLocker 規則をバイパスし、子プロセスを起動することが可能です。AppLocker 規則を使ってアプリの実行を許可する場合は、ニーズに最も適したプロセスに従って、各アプリを事前に十分に調べる必要があります。
詳しくは、「AppLocker のセキュリティに関する考慮事項」をご覧ください。
AppLocker ポリシーの設計に関する従来の Windows アプリケーションとユニバーサル Windows アプリの比較
ユニバーサル Windows アプリの AppLocker ポリシーは、Windows ストア アプリをサポートする Windows オペレーティング システムを実行しているコンピューターにインストールされたアプリケーションにのみ適用できます。一方、従来の Windows アプリケーションは、ユニバーサル Windows アプリをサポートするコンピューターだけでなく、Windows Server 2008 R2 や Windows 7 でも制御できます。従来の Windows アプリケーションとユニバーサル Windows アプリの規則は同時に実施できます。ユニバーサル Windows アプリで考慮する必要のある違いを次に示します。
すべてのユニバーサル Windows アプリは、標準ユーザーによるインストールが可能です。これに対して、従来の Windows アプリケーションは、インストールに管理者資格情報を必要とするものがあります。このため、ユーザーのほとんどが標準ユーザーである環境では、膨大な実行規則が必要になることはありませんが、パッケージ アプリに対する明示的なポリシーがより多く必要になる可能性があります。
従来の Windows アプリケーションは、管理者資格情報で実行されていれば、システム状態を変更するコードを呼び出すことができます。ユニバーサル Windows アプリのほとんどは、制限されたアクセス許可で実行されるため、システム状態を変更することはできません。AppLocker ポリシーを設計するときは、許可するアプリが、システム全体にかかわる変更を行う可能性があるかどうかを把握することが重要です。
ユニバーサル Windows アプリは、ストアから入手するか、Windows PowerShell コマンドレットを使ってサイド ローディングできます。Windows PowerShell コマンドレットを使う場合、ユニバーサル Windows アプリを入手するには、特別なエンタープライズ ライセンスが必要です。従来の Windows アプリケーションは、ソフトウェア ベンダーや小売業者など、従来の方法で入手できます。
AppLocker では、さまざまな規則のコレクションを使って、ユニバーサル Windows アプリと従来の Windows アプリケーションを制御します。必要に応じて、ユニバーサル Windows アプリ、従来の Windows アプリケーション、またはその両方を制御するように選択できます。
詳しくは、「AppLocker のパッケージ アプリの規則とパッケージ アプリ インストーラーの規則」を参照してください。
組織では現在どのようにアプリの使用状況を制御していますか。
多くの組織では、アプリ制御ポリシーとメソッドの展開に長い時間を費やしてきました。セキュリティに対する懸念が高まり、デスクトップ使用に対する IT 制御の強化が重視されるようになると、組織では、アプリ制御プラクティスの統合や、包括的なアプリケーション制御スキームの設計を進める決断が下される可能性があります。AppLocker では、アプリケーション制御ポリシーのアーキテクチャと管理の SRP が向上しています。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
セキュリティ ポリシー (ローカル設定またはグループ ポリシーを使用) |
AppLocker を使うと、適切なポリシーの作成の計画に手間がかかりますが、結果的にはこれが配布方法の簡素化につながります。 |
Microsoft 以外のアプリ制御ソフトウェア |
AppLocker を使うには、完全なアプリ制御ポリシーの評価と実装が必要です。 |
グループまたは OU で管理する使用状況 |
AppLocker を使うには、完全なアプリ制御ポリシーの評価と実装が必要です。 |
承認マネージャーまたはその他の役割ベースのアクセス テクノロジ |
AppLocker を使うには、完全なアプリ制御ポリシーの評価と実装が必要です。 |
その他 |
AppLocker を使うには、完全なアプリ制御ポリシーの評価と実装が必要です。 |
どの Windows デスクトップおよびサーバー オペレーティング システムが組織で実行されていますか。
複数の Windows オペレーティング システムをサポートする組織では、アプリ制御ポリシーの計画はより複雑になります。初期設計段階における決定では、各バージョンのオペレーティング システムにインストールされているアプリケーションのセキュリティと管理の優先順位を検討する必要があります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
組織のコンピューターで実行されているのは、次のオペレーティング システムの組み合わせです。
|
AppLocker 規則は、サポートされているバージョンの Windows を実行しているコンピューターにのみ適用されますが、SRP 規則は、Windows XP および Windows Server 2003 以降のすべてのバージョンの Windows に適用できます。オペレーティング システムのバージョンに関する具体的な要件については、「AppLocker を使用するための要件」をご覧ください。 注SRP に割り当てられたように基本ユーザー セキュリティ レベルを使用している場合、これらの特権は、AppLocker をサポートする実行中のコンピューターではサポートされません。 GPO を使って適用される AppLocker ポリシーが、同じ GPO またはリンクされた GPO の SRP ポリシーよりも優先されます。SRP ポリシーは、同じ方法で作成して管理できます。 |
組織のコンピューターで実行されているのは、次のオペレーティング システムのみです。
|
AppLocker を使って、アプリケーション制御ポリシーを作成します。 |
カスタマイズされたアプリケーション制御ポリシーを必要とする特定のグループが組織に存在しますか。
ビジネス グループまたは部門のほとんどに、データ アクセス関連の特定のセキュリティ要件と、そのデータへのアクセスに使用するアプリケーションが存在します。組織全体にアプリケーション制御ポリシーを展開する前に、各グループのプロジェクトの範囲とそのグループの優先順位を検討する必要があります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい。 |
グループごとに、アプリケーション制御要件を含む一覧を作成する必要があります。これにより計画時間が長くなる可能性がありますが、多くの場合、より効率的に展開を行うことができます。 さまざまなポリシーを特定のグループに適用できるように GPO 構造が構成されていない場合は、代わりに GPO の AppLocker 規則を特定のユーザー グループに適用できます。 |
いいえ |
AppLocker ポリシーは、「AppLocker を使用するための要件」に記載されている、サポートされているバージョンの Windows を実行している PC にインストールされたアプリケーションにグローバルに適用できます。制御する必要があるアプリの数によっては、すべての規則と例外を管理するのは難しい場合があります。 |
IT 部門にはアプリケーションの使用を分析するリソース、またポリシーを設計して管理するリソースが存在しますか。
調査と分析の実行に使用できる時間とリソースは、ポリシーの継続的な管理とメンテナンスの計画およびプロセスの詳細に影響する場合があります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい |
時間をかけて、組織のアプリケーション制御の要件を分析して、できるだけ簡潔に作成された規則を使用する完全な展開を計画します。 |
いいえ |
少ない規則を使って、特定のグループを対象に集中的かつ段階的に展開することを検討してください。特定のグループのアプリケーションに制御を適用する場合は、その展開に基づいて、次の展開を計画します。 |
組織にはヘルプ デスクによるサポートが用意されていますか。
既知のアプリケーション、展開されたアプリケーション、または個人アプリケーションにユーザーがアクセスできないと、最初はエンドユーザーのサポートが増えます。セキュリティ ポリシーに従い、ビジネス ワークフローが妨げられないように、組織のさまざまなサポートの問題に対処する必要があります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい |
ユーザーが誤って自分のアプリケーションを使えなくなっている可能性があるため、計画フェーズの早い段階でサポート部門を関与させます。そうしないと、ユーザーは、特定のアプリケーションを使用するように例外を見つけようとする場合があります。 |
いいえ |
展開する前に、時間をかけて、オンライン サポート プロセスとドキュメントを開発します。 |
制限の厳しいポリシーを必要とするアプリケーションを知っていますか。
アプリケーション制御ポリシーを適切に実装できるかどうかは、組織またはビジネス グループ内でのアプリの使用状況に関する知識と理解に左右されます。さらに、アプリケーション制御の設計は、データとそのデータにアクセスするアプリのセキュリティ要件によって決まります。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい |
ビジネス グループのアプリケーション制御の優先順位を判断し、そのアプリケーション制御ポリシーの最もシンプルなスキームを設計するよう試みる必要があります。 |
いいえ |
アプリケーションの使用状況を検出するための監査および要件収集プロジェクトを実行する必要があります。AppLocker には、監査のみモードでポリシーを展開する手段と、イベント ログを表示するツールが用意されています。 |
アプリケーション (アップグレードまたは新規) をどのように組織に展開または許可しますか。
アプリケーション制御ポリシーを適切に実装できるかは、組織またはビジネス グループ内のアプリケーションの使用状況に関する知識と理解に左右されます。さらに、アプリケーション制御の設計は、データとそのデータにアクセスするアプリケーションのセキュリティ要件によって決まります。アップグレードおよび展開ポリシーを理解すると、アプリケーション制御ポリシーを作成するときに役に立ちます。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
アドホック |
各グループの要件を収集する必要があります。グループによっては、無制限のアクセスまたはインストールが必要になる可能性があります。また、厳密な制御を必要とするグループもあります。 |
厳密な書面によるポリシーまたはガイドラインに従う |
これらのポリシーが反映されている AppLocker 規則を作成し、その規則をテストおよび保守管理します。 |
プロセスなし |
アプリケーション制御ポリシーを作成するためのリソースがあるかどうか、および対象のグループを判断する必要があります。 |
組織には SRP が既に展開されていますか。
SRP と AppLocker の目的は同じですが、AppLocker は SRP の主要なリビジョンです。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい |
AppLocker を使って SRP の設定を管理することはできませんが、SRP を使うと、「AppLocker を使用するための要件」に記載されている、サポートされているオペレーティング システムのいずれかが実行されているコンピューターで、アプリケーション制御ポリシーを管理できます。また、AppLocker と SRP の設定が同じ GPO 内に構成されている場合は、AppLocker の設定だけが、サポートされているオペレーティング システムを実行しているコンピューターに適用されます。 注SRP に割り当てられたように基本ユーザー セキュリティ レベルを使用している場合、これらの権限は、サポートされているオペレーティング システムを実行するコンピューターではサポートされません。 |
いいえ |
AppLocker 用に構成されたポリシーは、サポートされているオペレーティング システムを実行するコンピューターにのみ適用できますが、これらのオペレーティング システムでは SRP も利用可能です。 |
アプリケーション制御ポリシーを実装するときの組織の優先順位を教えてください。
一部の組織は、生産性と準拠性を向上させることで、アプリケーション制御ポリシーからメリットを得ます。また、処理の実行が妨げられる組織もあります。各グループの優先順位を設定して、AppLocker の有効性を評価できるようにします。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
生産性: 組織がツールの動作と、必要なアプリケーションのインストールを保証します。 |
技術革新と生産性の目標を達成するために、一部のグループには、さまざまなソースからさまざまなソフトウェア (グループが開発したソフトウェアを含む) をインストールして実行する機能が必要です。このため、技術革新と生産性の優先順位が高い場合は、許可済み一覧によるアプリケーション制御ポリシーの管理に時間がかかり、進行の妨げになる可能性があります。 |
管理: 組織がサポート対象のアプリを認識して制御します。 |
ビジネス グループによっては、アプリケーションの使用状況を一元管理できます。この目的で AppLocker ポリシーを GPO に組み込むことができます。これにより、アプリ アクセスの負荷が IT 部門に移行しますが、実行できるアプリの数を制御し、それらのアプリのバージョンを管理できるというメリットもあります。 |
セキュリティ: 組織は、承認済みのアプリのみ使用を許可して、データをある程度保護する必要があります。 |
AppLocker により、データにアクセスするアプリの使用を定義済みのユーザー セットにのみ許可することで、データを保護できます。セキュリティが最優先の場合、アプリケーション制御ポリシーによる制限は最も厳しくなります。 |
組織では現在どのようにアプリにアクセスしていますか。
AppLocker は、組織にアプリケーション制限の要件があり、その組織の環境の構造がシンプルで、かつアプリケーション制御ポリシーの目的がわかりやすい場合に非常に効果的です。たとえば、AppLocker は、学校、図書館など、組織のネットワークに接続されているコンピューターに従業員以外がアクセスする環境で役に立ちます。大規模な組織も、管理するアプリケーションが比較的少ないデスクトップ コンピューターでより詳細なレベルの管理を実現することが目的の場合、または少ない規則でアプリケーションを管理できる場合は、AppLocker ポリシー展開のメリットを得られます。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
ユーザーは管理者権限なしで実行します。 アプリはインストール展開テクノロジを使ってインストールされます。 |
AppLocker は、人事部門、財務部門など、通常、使用するアプリが限られているビジネス グループの総保有コストを削減するために役立ちます。同時に、これらの部門では機密性の高い情報にアクセスする必要があり、その多くに秘密情報や専有情報が含まれています。実行を許可する特定のアプリに対して AppLocker で規則を作成すると、このような情報に未承認のアプリケーションがアクセスすることを制限できます。 注また、AppLocker は、ユーザーが管理者として実行される組織で、標準化されたデスクトップを作成するときにも効果的に利用できです。ただし、管理者資格情報を持つユーザーが、新しい規則をローカル AppLocker ポリシーに追加できることに注意が必要です。 |
ユーザーは、必要に応じて、アプリケーションをインストールできる必要があります。 ユーザーは、現在、管理者権限でのアクセス許可を持っており、これを変更するのは困難です。 |
IT 部門からの承認を待たず、必要に応じてアプリをインストールできることが求められるビジネス グループには、AppLocker 規則の実施は適していません。組織内の 1 つ以上の OU がこの要件を持っている場合、それらの OU では AppLocker を使ってアプリケーション規則を実施しないようにするか、または AppLocker で [監査のみ] の実施設定を実装するという選択肢があります。 |
Active Directory ドメイン サービス内の構造は組織の階層に基づいていますか。
Active Directory ドメイン サービス (AD DS) に既に組み込まれている組織構造に基づいてアプリケーション制御ポリシーを設計する方が、既存の構造を組織構造に変換するよりも簡単です。アプリケーション制御ポリシーの有効性は、ポリシーを更新する機能によって決まるため、展開を開始する前に、どのような作業を組織的に行う必要があるかを検討してください。
| 考えられる回答 | 設計時の考慮事項 |
|---|---|
はい |
AppLocker 規則は、AD DS 構造に基づいて、グループ ポリシーを使用して作成および実装できます。 |
いいえ |
IT 部門は、アプリケーション制御ポリシーを適切なユーザーまたはコンピューターに適用する方法を特定するスキームを作成する必要があります。 |
調査結果を記録する
このプロセスの次の手順では、上記の質問に対する回答を記録して分析します。AppLocker が目的に合ったソリューションである場合は、アプリケーション制御ポリシーの目的を設定して、AppLocker 規則を計画します。このプロセスで最も重要なのは、ドキュメントの作成および計画です。
ポリシーの目的の設定については、「アプリケーション制御の目的の決定」をご覧ください。
計画ドキュメントの作成については、「AppLocker 計画ドキュメントの作成」をご覧ください。