> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md). # 承認必須のワイルドカード許可ファイルアクセス ワイルドカード許可ファイルアクセスのポリシー例
本例は、**ファイルアクセスポリシー**を**アプリケーション実行に対するワイルドカードの承認要件**として使う方法を示します。有効にすると、ユーザーが起動しようとするあらゆるアプリケーションに適用され、すべてのエンドポイントにまたがる単一の最上位コントロールポイントになります。**ワイルドカードファイルアクセスポリシー**をこのように整えたうえで、特定のアプリケーション・チーム・シナリオについては承認なしで実行できるよう、追加のポリシーを足していけます。 ## このポリシーの動作 **対象内エンドポイント**上のユーザーがアプリケーションを実行しようとするとき、以下のとおりです。 1. 要求は**ファイルアクセス**のポリシーエンジンで評価されます。 2. ポリシーの対象範囲が広く設定されており (すべてのユーザー、すべてのアプリケーション)、対象の各エンドポイントではほとんどの実行試行に一致します。 3. 操作を続行する前に、**管理コンソール**で**承認**が得られる必要があります。 ### この動作の理由 このポリシーは意図的に「広く一致する」ポリシーとして書かれ、そのうえでコントロールを適用します。 * **適用:** ポリシーは有効で、(ログだけでなく) コントロールを適用します。 * **一致時の承認コントロール:** ポリシーに一致すると、承認ワークフローが起動します。 * **すべてのユーザー:** ワイルドカードのユーザーフィルターにより、対象マシン上のあらゆるユーザーアカウントに適用されます。 * **すべてのアプリケーション:** ワイルドカードのアプリケーションフィルターにより、このファイルアクセスポリシーで評価されるあらゆるアプリケーションに適用されます。 * **組み込みチェック:** 標準のチェック (ユーザー、マシン、ファイル、日時・曜日、証明書) があります。これらの制約を狭めていない場合 (例: 日時・曜日・証明書の制限を入れていない)、ポリシーは対象エンドポイント上の実行試行を広く拾う受け皿として機能します。 ### ユーザー側で起きること * 対象エンドポイントでは、多くのアプリケーション起動で**承認要求**が発生します。 * ポリシーにはユーザー向けの通知メッセージが含まれます。特定の日付や一回限りのイベントに言及している場合は、本番では汎用的な文言に差し替えるか、削除して混乱を避けてください。 ## 重要な注意点とよくある調整 * **プロンプトが非常に多くなる:** すべてのアプリケーションに当てはまるため、特にエンドポイント数を増やすと承認が大量になりがちです。 * 必要に応じて**スコープを狭める:** * アプリケーションフィルターを特定の実行ファイルやパスに限定する * ユーザーフィルターを特定のユーザー/グループに限定する * 証明書/発行者の制約を加え、信頼済みと未信頼のソフトウェアを分けて扱う * 段階的ロールアウトや営業時間内のみの適用のため、時刻・曜日・日付の制限を加える ## 承認必須のワイルドカードファイルアクセスポリシーの作成手順 {% stepper %} {% step %} **ポリシーの作成** **Keeper管理コンソール**のエンドポイント特権マネージャーページで\*\*\[ポリシー]\*\* タブを開き、**\[ポリシーを作成]** ボタンをクリックします。
Policies
**ポリシー作成フォーム**がモーダルウィンドウで開きます。
Create Policy Form
{% endstep %} {% step %} **ポリシー名** 新しいワイルドカードファイルアクセスポリシー用の、内容が分かる名前を入力します。
{% endstep %} {% step %} **ポリシータイプ** **ポリシータイプ**の選択リストから**ファイルアクセス**を選びます。
{% endstep %} {% step %} **ステータス** **ポリシーの作成**フォームを完了して送信したときに、新しい**ワイルドカードファイルアクセスポリシー**に付けたいステータスを選びます。
{% endstep %} {% step %} **コントロール** 必須アクセスコントロールで、**\[管理者承認]** を選びます。
{% endstep %} {% step %} **アカウントコレクション** **\[アカウントを追加]** フィールド内をクリックし、アカウントフォームで **\[すべて選択]** チェックボックスを選びます。これにより各アカウントコレクションが個別にポリシーへ追加されるわけではありません。すべてのアカウントを選ぶと、個々のアカウントコレクションIDの一覧ではなくワイルドカードが適用されます。
{% endstep %} {% step %} **マシンコレクション** **\[マシンを追加]** フィールド内をクリックし、マシンフォームで **\[すべて選択]** チェックボックスを選びます。これにより各マシンコレクションが個別にポリシーへ追加されるわけではありません。すべてのマシンを選ぶと、個々のマシンコレクションIDの一覧ではなくワイルドカードが適用されます。
{% endstep %} {% step %} **アプリケーションコレクション** **\[アプリケーションを追加]** フィールド内をクリックし、アプリケーションフォームで **\[すべて選択]** チェックボックスを選びます。これにより各アプリケーションコレクションが個別にポリシーへ追加されるわけではありません。すべてのアプリケーションを選ぶと、個々のアプリケーションコレクションIDの一覧ではなくワイルドカードが適用されます。
{% endstep %} {% step %} **日付と時刻** **ワイルドカードファイルアクセスポリシー**では、**日付と時刻の範囲**を**\[常時]** にすることを推奨します。時間帯の切れ目なく、承認を前提としたポリシー評価が継続して適用されます。
{% endstep %} {% step %} **ワイルドカードファイルアクセスポリシーの保存** これまでの手順どおりフォームに十分入力すると、**\[保存]** ボタンが非アクティブからアクティブに変わります。**\[保存]** をクリックします。**ポリシーの作成**モーダルが閉じ、**ワイルドカードファイルアクセスポリシー**が保存されます。
{% endstep %} {% endstepper %} ## 代表的な利用場面

このワイルドカードファイルアクセスポリシーを最初のポリシーとすべき理由

**ワイルドカードファイルアクセス**として、既定であらゆる実行試行を対象に含め、**承認が必要**とするこのパターンは、エンドポイント特権マネージャーにおいて明確で重要な戦略的役割を果たします。主な利用場面とその背景を以下に整理します。 ### 基本的な考え方: 既定の承認必須による事実上の拒否 危険なアプリケーションを最初からすべて列挙するのはほぼ不可能なので、この方式は**モデルを反転**します。既定ではすべてに承認が必要とし、信頼できる既知の安全なアプリケーションだけを例外として切り抜きます。ルールセット末尾の、既定拒否に相当するファイアウォール規則と概念的に似ています。 ### 主な利用場面 #### 1. 規制対象または高セキュリティ環境 HIPAA、PCI-DSS、SOC 2、政府・防衛要件などのコンプライアンス枠組みの対象となる組織では、文書化された承認チェーンなしに**不正なソフトウェアが管理エンドポイントで実行されない**ことを示す必要がよくあります。承認必須のワイルドカードファイルアクセスポリシーを置くと、すべてのアプリケーション起動に対する単一の監査可能なコントロールポイントになります。 #### 2. アプリケーション許可リスト (アローリスト) の展開 アプリケーション許可リストを構築するときの理想的な**基盤層**です。いきなりすべてをブロックする (混乱が大きい) のではなく、以下のように進められます。 * ワイルドカードポリシー内で、すべてのアプリケーションに承認を求める要件から始める (ユーザーはまだ実行できるが、承認を要請する) * どの実行が承認要請の対象になるか観察する * IT承認済みソフト向けに、その上に**許可ポリシー**を追加する (承認ゲートを通さずに許可済みアプリが通過する) * 許可リストが成熟したら、ワイルドカード層を真の拒否ポリシーへ移行する このポリシー構成は意図的に「広く一致し、コントロールを適用する」形で書かれており、ユーザーとアプリケーションのフィルターがともにワイルドカードのため、対象エンドポイント上の実行を広く拾う受け皿として機能します。 #### 3. パイロットまたは段階的展開 エンドポイントの一群 (パイロットグループや部門など) に、アプリケーション実行の承認ワークフローを導入する例として使えます。セキュリティチームは承認フローを検証し、承認者のキャパシティを調整し、すべてのエンドポイントに展開する前に例外リストを構築できます。 #### 4. ゼロトラストのエンドポイント姿勢 ゼロトラストでは**暗黙の信頼を排除**します。標準ユーザー向けアプリケーションであっても同様です。承認必須のワイルドカードファイルアクセスポリシーを置くと、その姿勢を実行レイヤーで強制できます。マシン上にあるからといって、どのアプリケーションも暗黙には信頼されません。 #### 5. インシデント対応/侵害の封じ込め 侵害を経験した、または疑う組織では、このポリシーを迅速に展開して**エンドポイントのセグメントをロックダウン**し、調査中はすべてのアプリケーション起動を人間の承認にできます。すぐにすべてをブロックして全停止を招かずに済みます。 #### 6. 高リスクのユーザーグループまたはマシン 請負業者、第三者ベンダー、機密性の高いネットワークセグメント上のエンドポイント (OT隣接、財務系など) では、ワイルドカードの承認ポリシーにより、最初からアプリ単位の細かいポリシーを作らなくても最大限の監視を行えます。 ## ファイルアクセスポリシーとする理由 (特権昇格ポリシーではない理由) 細かいが重要な違いです。**ファイルアクセスポリシー**は、ファイルの**実行** (アプリケーションが起動した瞬間) をポリシー評価でインターセプトします。**特権昇格**ポリシーは、昇格した権限で何かを実行しようとしたときにだけインターセプトします。ここではファイルアクセスを使うことで、ユーザーが管理者権限を必要とするかどうかにかかわらず、**あらゆるアプリケーション起動**に承認要件がかかり、カバレッジが広がります。 ### ベースラインを土台としたレイヤー型のポリシー戦略 複数のポリシーを同一リソースに重ねるレイヤー型の構成で、防御の深さを確保できます。このワイルドカードファイルアクセスポリシーが整ったあとの運用イメージは以下のとおりです。
優先度ポリシースコープ
高許可: IT承認済みアプリ (ブラウザー、Officeなど)特定アプリ、すべてのユーザー
高許可: 開発者向けツール特定ユーザー/グループ
低 (受け皿)承認が必要: 上記以外すべてすべてのユーザー、すべてのアプリ
優先度の高い許可ポリシーに一致したアプリケーションは、そのまま実行が許可されます。明示的に許可されていないものはすべて、承認必須のワイルドカードファイルアクセスポリシーが適用されます。 ## 運用上の重要な考慮事項 このポリシーはすべてのアプリケーションに適用されるため、特にエンドポイントを広げると承認要求が非常に多くなります。そのためドキュメントでは**パイロットグループ**から始め、広く展開する**前に**例外 (許可) ポリシーを整えることを推奨しています。バッチで展開しながらシステム性能とユーザーからの反応を監視し、運用要件に応じてポリシーを調整するのが推奨される進め方です。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.