Windows 7 Enterprise / UltimateがAppLockerを導入したため、ソフトウェア制限ポリシーはMicrosoftによって非推奨になりました（SRPは事実上サポートされていないとテクネットが主張しています）。
実際には、SRPには、偽陰性と偽陽性の両方に特定の落とし穴があります。AppLockerには、引き続き積極的に保守およびサポートされているという利点があります。AppLockerがオプションの場合は、時間とリスクを考慮した後、より安価なものになる可能性があります。適切なサードパーティの代替手段もあります（ただし、この質問にはそのオプションは含まれていませんでした:)。
うまくいけば、SRPの落とし穴を完全に理解してから、SRPの落とし穴のいずれかに陥ることになります</sarcasm>。それらのいくつかは、VadimsPodānsからの素晴らしいセキュリティ記事で説明されています。
既知の落とし穴
デフォルトでは、\Windowsフォルダからの実行が許可されています。一部のサブフォルダーは、ユーザーが書き込むことができます。Applockerも同じですが、少なくとも公式ドキュメントではこの制限について言及しています。
編集：「ユーザーの書き込みアクセス権を持つすべてのフォルダーを列挙するには、たとえば、SysinternalsパックのAccessEnumユーティリティを使用できます。」（またはAccessChk）。
技術的には、ドキュメントはデフォルトのルールを上書きしないように警告しています。編集：NSAドキュメントには、SRPでブラックリストに16個のフォルダーの例がありますが、レジストリパスルールはバックスラッシュを誤って使用するため、修正する必要があり（以下のレジストリパスのポイントを参照）、一般的なブラックリストの一般的なエントリについて警告します。
明らかな問題は、\Windows代わりに個々のパスを慎重にホワイトリストに登録しない理由です。（\Windows\*.exeレガシーSystem32\*.exeなどを含む）。これに対する答えはどこにもありませんでした:(。
などの環境変数を使用%systemroot%すると、環境変数をクリアすることで、ユーザーがSRPをバイパスできます。編集：これらは推奨されるデフォルトでは使用されません。しかし、彼らは使いたくなるかもしれません。このフットガンは環境変数を参照しないため、AppLockerで修正されます。
- 推奨されるデフォルトは、
\Program Files最新の64ビットインストールで使用される2つの異なるものを考慮に入れていません。より安全な「レジストリパス」を使用してこれを解決すると、ランダムな状況で誤った拒否が報告されますが、テストでは簡単に見落とされる可能性があります。たとえば、SpiceWorks SRP howtoに関するコメントを参照してください。編集：これは、レジストリのWOW6432Nodeから関連するパスを読み取る32ビットアプリケーションと関係があります：解決策は、これらのパスの両方をSRPに追加して、すべてのプログラムが32ビットおよび64ビットマシン上で無制限として動作できるようにすることですx64またはx86ホストプロセス：%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
- デフォルトの拡張機能では、WindowsでサポートされているPowerShellスクリプト（* .PS1）を禁止していません。（ビデオを参照）。また、APPXも... Microsoftの比較表によると、SRPはWindows 8で「パッケージ化されたアプリ」を管理できないため、これが何を意味するのかわかりません。
- レジストリパスの規則はすぐに最後のパーセント記号（Microsoft自身の中に含まれているにもかかわらず、内蔵XP / Server 2003のルール）の後にスラッシュを持っていなければならず、バックスラッシュは（仕事へのルールのためにforwardslashesに交換しなければならない1 / 2 / 3）。
- SRPで見つけたソースのうち、上記の完全なリストをまとめてくれるものはありません。そして、偶然ヴァディムスポダンの記事を発見しただけです。 他に何が潜んでいますか？
- 多くのソースは、単にリストからLNKファイルを削除することを推奨しています。（そして、お気に入りを壊さないためのWebショートカット？！）。不快なことに、LNKの脆弱性について議論しているソースはないようです... または、スクリプトインタープリターに予期しない拡張子のファイルを実行させる
wscript /e ...など、またはインラインスクリプトパラメーターに十分なシェルコードを詰め込むなど...
- デスクトップ上のLNKファイルを許可して妥協しようとして、ユーザーにデスクトップへの書き込みアクセスを許可すると、ユーザーはポリシーを完全にバイパスできるようになります。再びVadimsPodānsからの素敵なチップ。この説明は、パスルールで任意の拡張子を使用する場合に適用されることに注意してください。Microsoftは、これを含む複数の例を提示
*.Extensionしていますが、警告はありません。したがって、公式のドキュメントを信頼することはできません。現在修正される可能性は低いようです。
- [潜在的なAppLockerの欠点]。VadimsPodānsは、マップされたドライブを使用するSRPエントリが機能しないと報告しています。代わりにUNCパスを使用する必要があります。それから、マップされたドライブを介したアクセスに適用されるでしょうか？100％明確ではありません。どうやらAppLockerは異なっていました：どちらでも動作し ませんでした。 」
実用的なアプローチ
ソフトウェアのホワイトリスト登録は、潜在的に非常に強力な防御策です。シニカルになった場合：これが、Microsoftが低価格バージョンを廃止し、より複雑なバージョンを発明する理由です。
他のオプションが利用できない場合があります（サードパーティのソリューションを含む）。次に、実用的なアプローチは、できるだけ簡単にSRPを構成することです。既知の穴がある追加の防御層として扱います。上記の落とし穴を一致させる：
- デフォルトのルール（Win7以前の時代から）から開始します。
- などの環境変数を使用しないことをお勧めします
%systemroot%。
- ルールを追加して
\Program Files\、最新の64ビットマシンで両方のディレクトリが許可されるようにします。あなたが追加する必要があります余分な「レジストリパス」\Program Files\64ビットコンピュータ上ではある%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%と%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%。
- レジストリパスの規則に追加するときは、すぐにパーセント記号の後にバックスラッシュを残して、任意の更なるバックスラッシュ置き換え
\forwardslashesとを/（例えば%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe）
- 制御された拡張機能のリストにPS1を追加します。
- 管理可能なSRP構成は、それを打ち負かすことに決めたユーザーに対して安全ではないことを理解してください。その目的は、「ドライブバイダウンロード」などの攻撃からユーザーを保護するために、ユーザーがポリシーの範囲内で作業することを支援/奨励することです。
- LNKファイルを許可します。（できれば、何らかのパスルールではなく、拡張機能リストから削除してください）。
- 上記を参照 ：）。
- ログオンスクリプトフォルダーが許可されていることを確認します。NSAドキュメントは追加を提案し
\\%USERDNSDOMAIN%\Sysvol\ます。（ポイント＃2、ため息をついて、ポイント＃6をご覧ください）。