# ポリシーのコントロール (特定のアプリケーションに対する特権昇格の理由入力のグローバルポリシー)
本例は、明示的に定義した**アプリケーションコレクション**を対象とする**特権昇格ポリシー**で、コレクション内のアプリケーションを昇格した権限で実行する前にユーザーに**正当な理由**の入力を求める方法を示します。対象内のすべてのエンドポイントにわたる、説明責任と監査のコントロールポイントになります。**グローバル特権昇格正当化ポリシー**をこのように整えたうえで、同じコレクション内で信頼できる管理者にはプロンプトなしで昇格を許可するポリシーを重ねたり、より機密性の高いシナリオでは承認やMFA要件へエスカレーションしたりできます。 *** #### このポリシーの動作 **対象内エンドポイント**上のユーザーが、対象のアプリケーションコレクションからアプリケーションを昇格した権限で実行しようとするとき、以下のとおりです。 1. 要求は**特権昇格**のポリシーエンジンで評価されます。 2. ポリシーは定義済みのアプリケーションコレクションを対象にしているため、対象の各エンドポイントでは、そのコレクション内のアプリケーションに対する昇格試行にだけ一致します。 3. 昇格が続行される前に、ユーザーは**正当な理由**を入力する必要があります。昇格自体はブロックされませんが、監査ログに残る説明を入力するまで先へ進めないようになっています。 #### この動作の理由 このポリシーは意図的に「対象を絞った一致」として書かれ、特権昇格の地点でブロックではなく説明責任の摩擦を加えます。 * **適用**: ポリシーは有効で、(ログだけでなく) コントロールを適用します。 * **一致時の正当化コントロール**: ポリシーに一致すると、昇格が進む前にユーザーは正当な理由の入力を求められます。正当な理由は、ユーザー ID、タイムスタンプ、エンドポイントとともに監査ログに記録されます。 * **すべてのユーザー**: ワイルドカードのユーザーフィルターにより、対象マシン上のあらゆるユーザーアカウントに適用されます。既定ではどのユーザーも正当化要件から除外されません。 * **特定のアプリケーションコレクション**: 定義されたアプリケーションコレクションは、その中に明示的にまとめたアプリケーションだけを対象にするため、同じエンドポイント上の無関係な昇格試行には影響しません。 * **別途の確認は不要**: `NotificationRequiresAcknowledge` が `false` に設定されているため、正当化のプロンプトを完了する以外に通知を別途閉じる必要はなく、操作の負担を抑えつつ説明に必要な情報は監査ログに残せます。 * **組み込みチェック**: 標準のチェック (ユーザー、マシン、ファイル、日時・曜日、証明書) があります。日時・曜日・証明書の制約を適用していないため、対象エンドポイント上の対象アプリケーションコレクションに対してポリシーは常に有効です。 #### 複数エンドポイントに広げる場合の修正 現状、マシンのターゲティングには単一のエンドポイント識別子が含まれています。同じ正当化要件を複数エンドポイントに適用するには、マシンのターゲティングを複数のエンドポイント識別子を含むように更新するか、希望するエンドポイントをまたぐマシンコレクションにポリシーを割り当てます。たとえば以下のとおりです。 * **変更前**: `MachineCheck` にエンドポイントIDが1つ * **変更後**: `MachineCheck` に複数のエンドポイントIDを含めるか、ポリシーを関連するすべてのエンドポイントをカバーするマシンコレクションにスコープする エンドポイントのカバレッジを広げる以外の変更は不要です。 #### ユーザー側で起きること * 対象内エンドポイントで、対象のアプリケーションコレクションからアプリケーションを昇格した権限で実行しようとすると、**正当化プロンプト** (昇格の理由を入力する必須テキスト) が表示されます。 * 正当な理由を送信すると昇格は続行されます。このポリシーは「プロンプトして記録」であり「ブロック」ではありません。摩擦は意図的ですが、正当な必要があるユーザーの作業は止めません。 * `NotificationRequiresAcknowledge` が `false` のため、正当化の入力以外に閉じる手順はなく、中断は最小限です。 * 通知メッセージは、どのカテゴリのツールが制御されているか、なぜ正当な理由が必要かを明確に示し、理由のないプロンプトにならないようにしてください。 *** #### 重要な注意点とよくある調整 * **通知メッセージの内容を正確に**: メッセージを更新し、この昇格には正当な理由の入力が必要であることと、その理由を簡潔に説明してください (例: 「このアプリケーションを管理者権限で実行するには、簡潔な業務上の正当な理由が必要です。入力内容は監査目的でログに記録されます。」)。 * **アプリケーションコレクションを最新に**: 新しいアプリケーションの展開や廃止に合わせて、ポリシーではなくコレクション本体を更新してください。ポリシーはコレクションを対象としており個別のアプリケーションIDではないため、コレクションに追加されたアプリケーションはポリシー変更なしで自動的に正当化要件の対象になります。 * **より強い確認が必要なら確認を有効化**: 正当な理由に加えて、ユーザーにポリシー通知を明示的に読んだことを確認させたい場合は、`NotificationRequiresAcknowledge` を `true` にします。閉じる手順が増えますが、通知の内容が目に入ることが保証されます。 * 必要に応じて**アプリケーションコレクションを拡張または絞り込み**: * コレクションにアプリケーションを追加し、昇格時に同じ正当化摩擦が妥当な他のツールにも適用範囲を広げる * コレクション内で証明書の制約を使い、検証済みの署名ビルドにだけコントロールをかける * **低摩擦の例外でユーザースコープを狭める**: このコレクションのアプリケーションを頻繁に昇格するIT管理者やセキュリティチーム向けに、別の優先度の高い**許可**ポリシーを用意し、正当化プロンプトが過剰にならないようにする * **パターンが見えたらコントロールをエスカレーション**: * 監査ログに説明のつかない、または疑わしい正当な理由が並ぶ場合は **APPROVAL** にエスカレーションし、昇格の前に人間の承認者を要するようにする * コレクション内のアプリケーションが高度に機密のシステムや認証情報にアクセスする場合は **MFA** を追加し、ステップアップ認証を強化する * これらのアプリケーションの昇格利用を定義された時間帯 (営業時間や変更管理のウィンドウなど) にだけ許可するなら、**時刻・曜日・日付の制限**を加える * **リスクレベルを意味のある値に**: リスクレベルの値は、コレクション内のアプリケーションが昇格時に実行しうる操作の機密性と整合させてください。認証情報ストアや特権インフラとやり取りする場合は値を高くし、セキュリティのダッシュボードやレポートで目立つようにします。 *** ### アプリケーションコレクション向けグローバル特権昇格正当化ポリシーの作成手順 {% stepper %} {% step %} **ポリシーの作成** **Keeper管理コンソール**のエンドポイント特権マネージャーページで**ポリシー**タブを開き、**ポリシーの作成**ボタンをクリックします。 **ポリシー作成フォーム**がモーダルウィンドウで開きます。
{% endstep %} {% step %} **ポリシー名** 新しい**グローバル特権昇格正当化ポリシー**用の、内容が分かる名前を入力します。ポリシー一覧で識別しやすいよう、対象のアプリケーションコレクション名をポリシー名に含めること (例: `_Elevate_Justify_AdminTools`) を推奨します。
{% endstep %} {% step %} **ポリシータイプ** **ポリシータイプ**の選択リストから**特権昇格**を選びます。このタイプは昇格試行だけをポリシー評価でインターセプトします。対象コレクションのアプリケーションが管理者または昇格した権限で実行されるときにだけ発動し、通常の起動では発動しません。
{% endstep %} {% step %} **ステータス** **ポリシーの作成**フォームを完了して送信したときに、新しい**グローバル特権昇格正当化ポリシー**に付けたいステータスを選びます。まず**監視**で正しいアプリケーションコレクションが対象か、昇格の頻度を把握してから**適用**に切り替えることを推奨します。
{% endstep %} {% step %} **コントロール** **コントロールの追加**サブフォームから**正当な理由が必要**を選びます。対象コレクションのアプリケーションを昇格した権限で実行しようとするたびに、ユーザーに業務上の正当な理由の入力を求めます。正当な理由は、ユーザー ID、エンドポイント、タイムスタンプとともに監査ログに記録されます。
{% endstep %} {% step %} **ユーザーグループ** ポリシー作成フォームで**グループの追加**リンクをクリックします。**グループの追加**サブフォームが開きます。 **グループの追加**サブフォームで**すべてのユーザーを選択**にチェックを入れ、サブフォームの外側をクリックして閉じます。**すべてのユーザーとグループ**が、**グローバル特権昇格正当化ポリシー**に適用された**ユーザーグループ**の下に表示されます。
IT管理者やセキュリティチームなど、正当化プロンプトから除外すべき特定のユーザーは、ここで除外するのではなく、別の優先度の高い**許可**ポリシーで対象を絞ってください。 {% endstep %} {% step %} **マシンコレクション** ポリシー作成フォームで**コレクションの追加**リンクをクリックします。**コレクションの追加**サブフォームが開きます。
**コレクションの追加**サブフォームで**すべてのマシンを選択**にチェックを入れ、サブフォームの外側をクリックして閉じます。**すべてのマシン**が、**グローバル特権昇格正当化ポリシー**に適用された**マシンコレクション**の下に表示されます。 {% endstep %} {% step %} **アプリケーション** ポリシー作成フォームで**アプリケーションの追加**リンクをクリックします。**アプリケーションの追加**サブフォームが開きます。
昇格時に正当な理由の入力を求めたい**特定のアプリケーション**を検索して選択します。**すべてのアプリケーションを選択**のチェックボックスは使わないでください。このポリシーは意図的に、正当化を求める定義済みリストにスコープが絞られており、すべてのアプリケーションではありません。対象にしたい各アプリケーションのチェックボックスにチェックを入れます。 選択した**アプリケーション**が、**グローバル特権昇格正当化ポリシー**に適用された**アプリケーション**の下に表示されます。 {% endstep %} {% step %} **日付と時刻** グローバル特権昇格正当化ポリシーでは、**日付と時刻の範囲**を**常時**にすることを推奨し、正当化要件が途切れなく適用されるようにします。組織でこれらのアプリケーションの昇格利用を定義された時間帯 (営業時間や変更管理のウィンドウなど) にだけ許可する場合は、日付と時刻の制限をそれに合わせて構成します。
{% endstep %} {% step %} **グローバル特権昇格正当化ポリシーの保存** これまでの手順どおりフォームに十分入力すると、**保存**ボタンが非アクティブからアクティブに変わります。**保存**をクリックします。**ポリシーの作成**モーダルが閉じ、**グローバル特権昇格正当化ポリシー**が保存されます。
{% endstep %} {% endstepper %} *** ### 代表的な利用場面 このパターンは、昇格の段階で定義済みアプリケーションコレクションにだけ正当化をかけるものです。エンドポイント特権マネージャーで意図した役割を果たします。コレクション内のアプリケーションの利用者を制限したり通常動作をブロックしたりはしませんが、匿名の昇格利用はなくなります。コレクション内のあらゆる特権実行は帰属先が付き、説明があり、記録に残ります。主な利用場面とその背景を以下に整理します。 #### 基本的な考え方: 「定義された管理ツール群に対する帰属付き昇格」 アプリケーションコレクションは、共通のリスクプロファイル、機能、または所有者を共有する関連実行ファイルをまとめます。正当化ポリシーを個別アプリではなくコレクション単位で適用すると、スケーラブルで保守の手間が少ない説明責任コントロールが得られます。コレクションに新しいアプリケーションを足すだけで正当化要件の対象に自動的に含まれ、ポリシー自体を変える必要はありません。問題としているのはツールの存在や利用そのものではなく、手がかりなしでは昇格が正当利用か悪用か切り分けにくいことです。昇格レイヤーでの正当化ポリシーは、すべての特権実行に帰属と説明を付けます。 #### 主な利用場面 **1. 管理ツールのカテゴリ全体にわたるスケーラブルな監査証跡** すべての管理ユーティリティに個別の正当化ポリシーを書く代わりに、アプリケーションコレクションにスコープしたポリシーで、IT管理ユーティリティ全体、展開エージェント全体、データベース管理アプリケーション全体など、カテゴリ全体を単一の保守しやすいコントロールで覆えます。ツール群が変わっても更新するのはコレクションだけで、ポリシーは安定したままです。 **2. 高価値ツールカテゴリに対するインサイダー脅威の抑止** 認証情報ストア、特権インフラ、機密データとやり取りするツールカテゴリは、インサイダー悪用の格好の標的です。コレクション内のいかなる昇格の前にも書面の正当な理由を求めると、匿名の悪用はかなり難しくなります。ユーザーは記録に残る理由を述べる必要があり、機会主義的な悪用は抑止され、後から悪用が判明した場合の調査材料にもなります。 **3. 最小権限および説明責任要件への対応** 多くのコンプライアンス枠組み (SOC 2、ISO 27001、NIST 800-53、CIS Controls) では、機密ツールへの特権アクセスを制御し文書化することが求められます。**グローバル特権昇格正当化ポリシー**は、カテゴリ全体に説明責任とログの要件をまとめて満たせます。完全な承認ワークフローほど業務を遅らせずに、すべての特権利用が帰属し文書化されていることを示せます。 **4. より厳しいコントロールを入れる前のベースライン説明責任** ツールのカテゴリに**承認**や **MFA** を課そうとしているが運用影響が読めない場合、正当化ポリシーが最初の一歩になります。昇格の頻度、ユーザー層、コレクション全体にわたる記載された利用パターンなど、現実のデータが得られ、コントロールをエスカレーションするかどうか、どのようにするかの判断に直結します。評価期間中はワークフローを乱しません。 **5. 異なるユーザー層に対する段階的コントロール** コレクションへのアクセス権を持つユーザーのリスクプロファイルは同じではありません。すべてのユーザーに正当化をかけると普遍的な説明責任のベースラインになり、信頼できるIT職員やセキュリティエンジニア向けの優先度の高い許可ポリシーで、そのユーザーは作業が妨げられにくくなります。信頼できるユーザーは妨げず、それ以外にはすべて説明責任を求めるという階層的な姿勢になります。 **6. 大規模な変更管理および運用ガバナンス** 正式な変更管理プロセスがある環境では、コレクションにスコープした正当化ポリシーにより、コレクション内のいかなるアプリケーションの昇格利用も宣言された変更活動に結び付きます。通知で変更チケットやメンテナンスウィンドウを参照するよう指示すると、正当な理由のテキストがツールカテゴリ全体にまたがる軽量な運用ガバナンスになり、個別のポリシー作成や ITSM との完全統合は不要です。 *** #### 特権昇格ポリシーとする理由 (ファイルアクセスポリシーではない理由) 重要な違いです。**ファイルアクセスポリシー**は、標準ユーザー起動を含むあらゆる権限レベルでのファイル**実行**をポリシー評価でインターセプトします。**特権昇格ポリシー**は、**昇格した権限**で何かを実行しようとしたときにだけインターセプトします。標準権限では普通に使い、特定の操作だけ昇格が必要な管理ツールには、このレイヤーがまさに適しています。セキュリティと監査上重要なのはすべての起動ではなく**昇格の瞬間**です。特権昇格ポリシーを使うと、正当化プロンプトは意味があるときにだけ出し、同じツールとの標準権限のやり取りには摩擦を作りません。 #### ベースラインを土台としたレイヤー型のポリシー戦略 複数のポリシーを同一リソースに重ねるレイヤー型の構成で、防御の深さを確保できます。アプリケーションコレクションの正当化ベースラインが整ったあとは、その周りに制御された例外とエスカレーションを重ねられます。 | 優先度 | ポリシー | スコープ | | ----------- | --------------------------------------- | ---------------------------- | | 高 | **許可** — 昇格の必要性が明確な信頼できるIT管理者/セキュリティチーム | 特定ユーザー/グループ、対象アプリケーションコレクション | | 高 | **MFA + 正当化** — 高度に機密のシステムやボルトへの昇格アクセス | 特定のマシンコレクションまたは環境 | | 中 | **承認** — 監督付きで時折昇格が必要なユーザー | 特定ユーザー/グループ、対象アプリケーションコレクション | | 低 (キャッチオール) | **正当化** — 上記以外のすべてのユーザー | すべてのユーザー、対象アプリケーションコレクション | 優先度の高い許可ポリシーに一致したユーザーは、そのまま昇格が許可されます。MFAまたは承認の層に一致したユーザーには、より強いコントロールが適用されます。残りのすべてのユーザーは、昇格の際に正当な理由の入力を求められます。 *** #### 運用上の重要な考慮事項 このポリシーは**正当な理由が必要なコントロール**と `NotificationRequiresAcknowledge` が `false` の組み合わせのため、ユーザー操作は意図的に簡素に抑えられています。正当化プロンプトで理由を入力すると昇格が続行され、通知を閉じる追加の手順はありません。監査記録の質は、通知メッセージの明快さに直結します。ログに何が残り、なぜ入力を求めているのかが伝わるメッセージであれば、意味のある内容で検索しやすい正当な理由のテキストが得られ、形式的な一行に終わりにくくなります。コレクション方式では、アプリケーション構成が変わってもポリシー自体を更新する必要がなく、継続的な作業はアプリケーションコレクションの保守に集中できます。コレクションに、幅広いユーザーが頻繁に使うツールが含まれる場合は、まず**監視**で対象が正しいかと昇格の頻度を確認し、そのうえで**適用**に切り替えることを強く推奨します。 --- # Agent Instructions: 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: ``` GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-examples/policy-global-privilege-elevation-justification-policy-for-specific-application-s.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.