次の方法で共有


スマート アプリ制御ポリシーを使用してスターター ポリシーを構築する

App Control for Business の一部の機能は、特定の Windows バージョンでのみ使用できます。 アプリ制御機能の可用性について詳しくは、こちらをご覧ください。

この記事では、Smart App Control ポリシーをテンプレートとして使用して、App Control for Business ポリシーを作成する方法について説明します。 スマート アプリ コントロール は、コンシューマー ユーザー向けに設計されたアプリ コントロール ベースのセキュリティ ソリューションです。 App Control for Business と同じテクノロジを使用するため、同等に堅牢で柔軟なエンタープライズ ポリシーの基礎として簡単に使用できます。

ヒント

Microsoft では、この記事で作成したポリシーを、エンド ユーザーのデバイスへのほとんどのアプリ制御展開に最適なスターター ポリシーとして推奨しています。 通常、App Control を初めて使用する組織は、この記事で説明したような制限の少ないポリシーから始める場合に最も成功します。 後の記事で説明するように、アプリコントロールで管理されたデバイスで全体的なセキュリティ体制を強化するために、時間をかけてポリシーを強化できます。

さまざまなシナリオでの App Control for Business の展開で行ったように、Lamna Healthcare Company (Lamna) の架空の例を使用して、このシナリオを説明しましょう。 Lamna は、管理対象デバイスで不要なアプリケーションや未承認のアプリケーションが実行されないように、アプリ制御を使用するなど、より強力なアプリケーション ポリシーを採用する予定です。

Alice Pena (彼女/彼女) は、アプリ コントロールのロールアウトを任された IT チームリーダーです。 Lamna は現在、アプリケーションの使用ポリシーを緩和し、ユーザーに最大限のアプリの柔軟性を提供するカルチャを備えています。 そのため、Alice は、アプリコントロールに対して段階的なアプローチを講じる必要があることを認識しており、ユーザー セグメントごとに異なるポリシーを使用する可能性があります。 しかし、今のところ、Alice は、変更を加えずにほとんどのユーザーをカバーできるポリシーを必要とします。Smart App Control の "署名された & リプタブル" ポリシーは、Lamna 用に適応されています。

スマート アプリ コントロールの "信頼の丸" が最適な方法を分析する

Alice は、 アプリ制御ポリシーライフサイクル管理の計画に関する記事のガイダンスに従い、まずスマート アプリ コントロールのポリシーの "信頼の丸" を分析することから始めます。 Alice は、スマート アプリ コントロールに関する Microsoft のオンライン ヘルプ記事を読んで、理解を深めます。 その読み取りから、Alice は、Smart App Control で、 インテリジェント セキュリティ グラフ (ISG) が安全であると予測する、パブリックに信頼された署名済みコードまたは署名されていないコードのみを許可することを学習します。 パブリックに信頼された署名済みコードは、署名証明書の発行者が Microsoft の信頼されたルート プログラムの証明機関 (CA) の 1 つであることを意味します。 コードが安全に実行されると ISG が予測できない場合、符号なしコードの実行がブロックされます。 安全でないと判断されたコードは常にブロックされます。

Alice は、Lamna の使用に合わせてポリシーを調整する方法を検討します。 Alice は、可能な限り緩和されたが、永続的なセキュリティ値を提供する初期ポリシーを作成したいと考えています。 Lamna 内の一部は、Alice プランよりも積極的なアプローチを提唱しています。 エンド ユーザーのデバイスをすぐにロックダウンし、限定的なフォールアウトを望んでいます。 しかし、リーダーシップ チームは Alice に同意します。時間の経過と共にゆっくりと形成された Lamna のアプリ文化は、一晩で消えるだけでなく、初期ポリシーには多くの柔軟性が必要です。

organizationに関する主な要因を検討する

Alice は次に、会社の "信頼の丸" に影響を与える Lamna の環境に関する重要な要因を特定します。このポリシーは、短期的および中期的にビジネスのニーズを満たすために柔軟である必要があります。 これにより、Lamna は新しいアプリ管理プロセスとポリシーを導入して、将来的により制限の厳しいアプリ制御ポリシーに対して実用的なものにすることができます。 重要な要素は、Alice が最初のデプロイに含めるシステムを選択するのにも役立ちます。 Alice は、計画ドキュメントで次の要因を書き留めます。

  • ユーザー特権: ほとんどのユーザーは標準ユーザーですが、ほぼ 4 分の 1 がデバイスのローカル管理者権限を持ち、選択したアプリを実行するオプションが大きな要因です。
  • オペレーティング システム: Windows 11はほとんどのユーザー デバイスを実行しますが、Lamna は、クライアントの約 10% が来年度まで、特に小規模なサテライト オフィスでWindows 10を維持すると予想しています。 現時点では、Lamna のサーバーと特殊な機器は範囲外です。
  • クライアント管理:Lamna は、Microsoft EntraクラウドネイティブとしてデプロイされたすべてのWindows 11 デバイスにMicrosoft Intuneを使用します。 Microsoft Endpoint Configuration Manager (MEMCM) は、ほとんどのWindows 10 デバイスで引き続き使用され、Microsoft Entraハイブリッド参加としてデプロイされます。
  • アプリ管理: Lamna には、ビジネス ユニット全体で数百の基幹業務 (LOB) アプリがあります。 Alice のチームは、Intuneを使用して、これらのアプリのほとんど (ただし、すべてではない) をデプロイします。 また、多くの "シャドウ IT" アプリを含む、小規模なチームが使用するアプリの長い尾があり、公式のチャーターはありませんが、それらを使用する従業員にとって重要です。
  • アプリ開発とコード署名: Lamna ビジネス ユニットは開発プラットフォームとフレームワークで標準化されていないため、大幅な変動と複雑さが考えられます。 ほとんどすべてのアプリで、符号なしコード (ほとんどは符号なし) コードが使用されます。 会社ではコード署名が必要になりましたが、Lamna のコード署名証明書は会社の公開キー インフラストラクチャ (PKI) から取得され、ポリシーにカスタム ルールが必要です。

軽く管理されたデバイスの "信頼の円" を定義する

Alice は、これらの要因に基づいて、Microsoft の署名済み & 信頼できるポリシーの Lamna バージョンの擬似規則を記述します。

  1. "Windows および Microsoft 認定カーネル ドライバー" 次の 1 つ以上の署名者ルールを許可します。

    • Windows とそのコンポーネント。
    • Windows ハードウェア品質ラボ (WHQL) 証明機関によって署名されたカーネル ドライバー。
  2. "パブリックに信頼された署名されたコード" 次の 1 つ以上の署名者ルールを許可します。

  3. Lamna 署名済みコード 次の 1 つ以上の署名者ルールを許可します。

    • Lamna Codesigning プライベート証明機関 (PCA) から発行された証明書によって署名されたコード。独自の内部 PKI から発行された中間証明書。
  4. "評判" に基づいてアプリを許可する ポリシー オプションでは、次の機能が許可されます。

    • アプリは、ISG によって "安全" であると予測されました。
  5. マネージド インストーラーを許可する ポリシー オプションでは、次の機能が許可されます。

    • ポリシーによってマネージド インストーラーとして指定されたプロセスによってシステムに書き込まれるコード。 Lamna のマネージド インストーラー ポリシーの場合、Alice には、Intune管理拡張機能と、広く使用されているアプリの既知の自動更新プロセスも含まれています。 Alice には、Lamna のヘルプデスク管理者がユーザーのアプリとシステムを修復するために使用するアプリ インストーラーとスクリプトをコピーするようにトレーニングされているファイルパス ルール "D:\ Lamna ヘルプデスク*" も含まれています。
  6. 管理専用パス 規則 次の場所に対する 1 つ以上のファイルパス規則。

    • "C:\Program Files*"
    • "C:\Program Files (x86)*"
    • "%windir%*"
    • "D:\Lamna ヘルプデスク*"

organizationの "署名済み & リプタブル" ポリシー テンプレートを変更する

Alice は、 https://aka.ms/appcontrolwizard からアプリ制御ポリシー ウィザードをダウンロードして実行します。

  1. [ようこそ] ページに、ポリシー作成者ポリシー エディター、ポリシーの合併の 3 つのオプションが表示されます。 Alice は ポリシー作成者 を選択し、次のページに移動します。

  2. [ ポリシーの種類の選択] で、 Alice は複数のポリシー形式 ポリシーを作成するか 、単一ポリシー形式 ポリシーを作成するかを選択する必要があります。 エンド ユーザーのすべてのデバイスは、Windows 11または現在のバージョンのWindows 10を実行するため、Alice は既定の複数ポリシー形式のままにします。 同様に、 基本ポリシー補足ポリシー の選択は簡単で、ここでは既定の 基本ポリシー も選択された状態のままにします。 [ 次へ ] を選択して続行します。

  3. 次のページでは、Alice が ポリシーの基本テンプレートを選択します。 アプリ制御ウィザードには、新しい基本ポリシーを作成するときに使用する 3 つのテンプレート ポリシーが用意されています。 各テンプレート ポリシーは、ポリシーの信頼とセキュリティ の円モデルを変更するために、わずかに異なる規則を適用します。 3 つのテンプレート ポリシーは次のとおりです。

    ポリシーの基本テンプレートの選択を示すスクリーンショット。

    テンプレートの基本ポリシー 説明
    既定の Windows モード 既定の Windows モードでは、次のコンポーネントが承認されます。
    • Windows オペレーティング システム コンポーネント - Windows の新規インストールによってインストールされたバイナリ
    • Microsoft Store MarketPlace 署名者によって署名された MSIX パッケージ アプリ
    • Microsoft Office365 アプリ、OneDrive、Microsoft Teams
    • WHQL 署名済みドライバー
    Microsoft モードを許可する Microsoft モードを許可すると、次のコンポーネントが承認されます。
    • 既定の Windows モードで許可されるすべてのコードにプラス...
    • すべての Microsoft 署名済みソフトウェア
    署名済みおよび信頼できるモード 署名済みおよび評判可能モードでは、次のコンポーネントが承認されます。

    Alice は 、署名済みおよび信頼できるモード テンプレートを選択し、[ 次へ] を選択し、ポリシーのファイル名と場所の既定値をそのまま使用します。

  4. [ ポリシー テンプレートの構成 - ポリシー ルール] で、ポリシーに対して有効になっている一連のオプションが確認されます。 テンプレートには、Microsoft が推奨するように設定されているオプションが既にほとんどあります。 Alice が行う唯一の変更は、Managed InstallerRequire WHQL のオプションをチェックすることです。 このように、Intuneまたは他の管理対象インストーラーによってインストールされたアプリは自動的に許可され、Windows 10以降用にビルドされたカーネル ドライバーのみを実行できます。 [ 次へ ] を選択すると、ウィザードが進みます。

  5. [ ファイル ルール] ページには、署名済みおよび信頼できるモードのテンプレート ポリシーのルールが表示されます。 Alice は、Lamna 署名されたコードを信頼する署名者ルールと、2 つの Program Files ディレクトリ、Windows ディレクトリ、および Lamna のヘルプデスク フォルダーの下にある管理者が書き込み可能な場所にあるコードを許可するファイルパス 規則を追加します。

    各ルールを作成するために、Alice は [+ カスタムの追加] を選択し、ルールの条件が定義されている [カスタム ルール ] ダイアログを開きます。 最初のルールでは、[ ルール スコープ ] と [ ルール アクション ] の既定の選択が正しいです。 [ ルールの種類 ] ドロップダウンでは、署名者ルールを作成するための適切な選択肢は [Publisher ] オプションです。 その後、Alice は [ 参照 ] を選択し、Lamna Codesigning PCA によって発行された証明書によって署名されたファイルを選択します。 ウィザードには、ファイルのリソース ヘッダー セクション (RSRC) からプルされた署名情報と情報 ( 製品名元のファイル名 など) が表示され、各要素によってチェック ボックスが付けられます。 この場合、Lamna の内部コード署名証明書で署名されたすべてのものを許可する予定であるため、Alice は 発行元 CAPublisher のみをチェックしたままにします。 Lamna Codesigning PCA ルール セットのルール条件を使用すると、Alice は [ルールの作成 ] を選択し、ルールが一覧に含まれていることを確認します。 Alice は、残りの Lamna のカスタム ルールに対してこれらの手順を繰り返します。

    カスタム filepublisher ファイル ルールの作成を示すスクリーンショット。

  6. 擬似ルールで説明されているすべての編集が完了すると、Alice は [次へ ] を選択し、ウィザードによってアプリ制御ポリシー ファイルが作成されます。 出力ファイルには、XML 形式とコンパイル済みのバイナリ 形式のポリシーが含まれます。 Alice は XML ポリシー ファイルを慎重に確認して結果が適切であることを確認し、ウィザードを閉じます。

Alice は、Lamna のアプリ制御ポリシー ファイル専用に作成された GitHub リポジトリに両方のファイルをアップロードします。

Alice のスターター ポリシーは、Lamna のマネージド デバイスに監査モードでデプロイする準備ができました。

このポリシーのセキュリティに関する考慮事項

Alice は、ユーザーの生産性に悪影響を与える可能性を最小限に抑えるために、セキュリティとユーザー アプリの柔軟性の間にいくつかのトレードオフを行うポリシーを定義しました。 トレードオフの一部は次のとおりです。

  • 管理アクセス権を持つユーザー

    このトレードオフは、最も影響を与えるセキュリティのトレードオフです。 これにより、デバイス ユーザーまたはユーザーの特権で実行されているマルウェアが、デバイスのアプリ制御ポリシーを変更または削除できます。 さらに、管理者は、管理されたインストーラーとして機能するように任意のアプリを構成できます。これにより、必要なアプリやバイナリに対して永続的なアプリの承認を得ることができます。

    考えられる軽減策:

    • アプリ制御ポリシーの改ざんを防ぐには、統合拡張ファームウェア インターフェイス (UEFI) ファームウェアを実行しているシステムで署名されたアプリ制御ポリシーを使用します。
    • マネージド インストーラーを信頼する必要をなくすには、署名付きカタログ ファイルを作成して展開するか、通常のアプリのデプロイとアプリ更新手順の一環として更新されたポリシーをデプロイします。
    • 他の企業リソースとデータへのアクセスを制御するには、デバイス構成証明を使用して、トラステッド コンピューティング グループ (TCG) ログからのアプリ制御の構成状態のブート時間測定を使用します。
  • 署名されていないポリシー

    管理者として実行されているプロセスは、署名されていないポリシーを置き換えたり削除したりできます。 同様に、署名されていない補足ポリシーは、オプション 17 Enabled:Allow Supplemental Policies を含む署名されていない基本ポリシーの "信頼の円" を変更できます。

    考えられる軽減策:

    • アプリ制御ポリシーの改ざんを防ぐには、UEFI ファームウェアを実行しているシステムで署名されたアプリ制御ポリシーを使用します。
    • リスクを最小限に抑えるには、デバイスの管理者に昇格できるユーザーを制限します。
  • マネージド インストーラー

    マネージド インストーラーに関するセキュリティに関する考慮事項を参照してください

    考えられる軽減策:

    • マネージド インストーラーを信頼する必要をなくすには、署名付きカタログ ファイルを作成して展開するか、通常のアプリのデプロイとアプリ更新手順の一環として更新されたポリシーをデプロイします。
    • リスクを最小限に抑えるには、デバイスの管理者に昇格できるユーザーを制限します。
  • インテリジェント セキュリティ グラフ (ISG)

    インテリジェント セキュリティ グラフでセキュリティに関する考慮事項を参照する

    考えられる軽減策:

    • ISG を信頼する必要を取り除くには、既存のアプリの使用状況とインストールに関する包括的な監査を実行します。 Microsoft Intuneなど、現在ソフトウェア配布ソリューションに管理されていないアプリをオンボードします。 IT によってアプリが管理されるよう要求するポリシーを実装します。 その後、ISG からマネージド インストーラー、署名付きカタログ ファイル、更新されたポリシー ルールに移行し、通常のアプリのデプロイとアプリ更新手順の一部としてデプロイします。
    • セキュリティ インシデントの調査やインシデント後のレビューで使用するデータをさらに収集するには、高度に制限の厳しいアプリ制御ポリシーを監査モードでデプロイします。 App Control イベント ログでキャプチャされたデータには、Windows 署名されていない実行されるすべてのコードに関する有用な情報が含まれています。 ポリシーがデバイスのパフォーマンスと機能に影響を与えないようにするには、ブート プロセスの一部として実行される Windows コードを最小限に抑えるようにしてください。
  • 補足ポリシー

    補足ポリシーは、基本ポリシーによって定義された "信頼の円" を拡張するように設計されています。 基本ポリシーも署名されていない場合、管理者として実行されているプロセスは、署名されていない補足ポリシーを配置し、基本ポリシーの "信頼の円" を制限なしで展開できます。

    考えられる軽減策:

    • 承認された署名付き補足ポリシーのみを許可する署名付きアプリ制御ポリシーを使用します。
    • 制限付き監査モード ポリシーを使用して、アプリの使用状況を監査し、脆弱性検出を強化します。
  • FilePath ルール

    ファイルパス規則の詳細を確認する

    考えられる軽減策:

    • デバイスの管理者に昇格できるユーザーを制限します。
    • ファイルパス 規則からマネージド インストーラーまたは署名ベースの規則に移行します。
  • 署名されたマルウェア

    コード署名だけではセキュリティ ソリューションではありませんが、App Control などのセキュリティ ソリューションを可能にする 2 つの重要な構成要素が提供されます。 最初に、コード署名はコードを実際の ID に強く関連付けます。...実際の ID は、署名されていないマルウェアを担当する無名の影の人物が発生しない結果に直面する可能性があります。 次に、コード署名は、発行元が署名した後も、実行中のコードがアンamperedのままであることを示す暗号化証明を提供します。 すべてのコードを必要とするアプリ制御ポリシーが署名されているか、ポリシーによって明示的に許可され、攻撃者の賭けとコストが発生します。 しかし、動機付けられた攻撃者が、少なくともしばらくの間、悪意のあるコードに署名して信頼してもらう方法が残っています。 また、ソフトウェアが信頼できるソースから提供された場合でも、安全に実行できるわけではありません。 任意のコードは、悪意のあるアクターが自分の悪意のために悪用できる強力な機能を公開できます。 また、脆弱性により、最も良性の高いコードが本当に危険なものに変わる可能性があります。

    考えられる軽減策:

    • 悪意のあるファイル、アドウェア、その他の脅威からデバイスを保護するには、Microsoft Defenderなどのリアルタイム保護を備えた評判の高いマルウェア対策ソフトウェアまたはウイルス対策ソフトウェアを使用します。