ポリシーのコントロール (グローバル許可ファイルアクセス - 承認必須)
グローバル許可ファイルアクセスのポリシー例
本例は、ファイルアクセスポリシーをアプリケーション実行に対するグローバルな承認要件として使う方法を示します。有効にすると、ユーザーが起動しようとするあらゆるアプリケーションに適用され、すべてのエンドポイントにまたがる単一の最上位コントロールポイントになります。ベースライン・ファイルアクセスポリシーをこのように整えたうえで、特定のアプリケーション・チーム・シナリオについては承認なしで実行できるよう、追加のポリシーを足していけます。
このポリシーの動作
対象内エンドポイント上のユーザーがアプリケーションを実行しようとするとき、以下のとおりです。
要求はファイルアクセスのポリシーエンジンで評価されます。
ポリシーの対象範囲が広く設定されており (すべてのユーザー、すべてのアプリケーション)、対象の各エンドポイントではほとんどの実行試行に一致します。
操作を続行する前に、Keeper管理コンソールで承認が得られる必要があります。
この動作の理由
このポリシーは意図的に「広く一致する」ポリシーとして書かれ、そのうえでコントロールを適用します。
適用: ポリシーは有効で、(ログだけでなく) コントロールを適用します。
一致時の承認コントロール: ポリシーに一致すると、承認ワークフローが起動します。
すべてのユーザー: ワイルドカードのユーザーフィルターにより、対象マシン上のあらゆるユーザーアカウントに適用されます。
すべてのアプリケーション: ワイルドカードのアプリケーションフィルターにより、このファイルアクセスポリシーで評価されるあらゆるアプリケーションに適用されます。
組み込みチェック: 標準のチェック (ユーザー、マシン、ファイル、日時・曜日、証明書) があります。これらの制約を狭めていない場合 (例: 日時・曜日・証明書の制限を入れていない)、ポリシーは対象エンドポイント上の実行試行に広く一致するキャッチオールとして機能します。
ユーザー側で起きること
対象エンドポイントでは、多くのアプリケーション起動で承認要求が発生します。
ポリシーにはユーザー向けの通知メッセージが含まれます。特定の日付や一回限りのイベントに言及している場合は、本番では汎用的な文言に差し替えるか、削除して混乱を避けてください。
重要な注意点とよくある調整
プロンプトが非常に多くなる
すべてのアプリケーションに当てはまるため、特にエンドポイント数を増やすと承認が大量になりがちです。
必要に応じてスコープを狭める
アプリケーションフィルターを特定の実行ファイルやパスに限定する
ユーザーフィルターを特定のユーザー/グループに限定する
証明書/発行者の制約を加え、信頼済みと未信頼のソフトウェアを分けて扱う
段階的ロールアウトや営業時間内のみの適用のため、時刻・曜日・日付の制限を加える
ベースライン・ファイルアクセスポリシーの作成手順
代表的な利用場面
このベースライン・ファイルアクセスポリシーを最初のポリシーとすべき理由
ベースライン・ファイルアクセスとして、既定であらゆる実行試行を対象に含め、承認が必要とするこのパターンは、エンドポイント特権マネージャーにおいて明確で重要な戦略的役割を果たします。主な利用場面とその背景を以下に整理します。
基本的な考え方: 既定の承認必須による事実上の拒否
危険なアプリケーションを最初からすべて列挙するのはほぼ不可能なので、この方式はモデルを反転します。既定ではすべてに承認が必要とし、信頼できる既知の安全なアプリケーションだけを例外として切り抜きます。ルールセット末尾の、既定拒否に相当するファイアウォール規則と概念的に似ています。
主な利用場面
1. 規制対象または高セキュリティ環境
HIPAA、PCI-DSS、SOC 2、政府・防衛要件などのコンプライアンス枠組みの対象となる組織では、文書化された承認チェーンなしに不正なソフトウェアが管理エンドポイントで実行されないことを示す必要がよくあります。承認必須のグローバルなファイルアクセスをベースラインにすると、すべてのアプリケーション起動に対する単一の監査可能なコントロールポイントになります。
2. アプリケーション許可リスト (アローリスト) の展開
アプリケーション許可リストを構築するときの理想的な基盤層です。いきなりすべてをブロックする (混乱が大きい) のではなく、以下のように進められます。
ベースライン内でグローバルな承認要件から始める (ユーザーはまだ実行できるが、承認を要請する)
どの実行が承認要請の対象になるか観察する
IT承認済みソフト向けに、その上に許可ポリシーを追加する (承認ゲートを通さずに許可済みアプリが通過する)
許可リストが成熟したら、ベースラインを真の拒否ポリシーへ移行する
このポリシー構成は意図的に「広く一致し、コントロールを適用する」形で書かれており、ユーザーとアプリケーションのフィルターがともにワイルドカードのため、対象エンドポイント上の実行に対する広いキャッチオールとして機能します。
3. パイロットまたは段階的展開
エンドポイントの一群 (パイロットグループや部門など) に、アプリケーション実行の承認ワークフローを導入する例として使えます。セキュリティチームは承認フローを検証し、承認者のキャパシティを調整し、すべてのエンドポイントに展開する前に例外リストを構築できます。
4. ゼロトラストのエンドポイント姿勢
ゼロトラストでは暗黙の信頼を排除します。標準ユーザー向けアプリケーションであっても同様です。承認必須のグローバルなファイルアクセスをベースラインにすると、その姿勢を実行レイヤーで強制します。マシン上にあるからといって、どのアプリケーションも暗黙には信頼されません。
5. インシデント対応/侵害の封じ込め
侵害を経験した、または疑う組織では、このポリシーを迅速に展開してエンドポイントのセグメントをロックダウンし、調査中はすべてのアプリケーション起動を人間の承認にできます。すぐにすべてをブロックして全停止を招かずに済みます。
6. 高リスクのユーザーグループまたはマシン
請負業者、第三者ベンダー、機密性の高いネットワークセグメント上のエンドポイント (OT隣接、財務系など) では、グローバルな承認ポリシーが、最初からアプリ単位の細かいポリシー作成なしに最大限の監視を提供します。
ファイルアクセスポリシーとする理由 (特権昇格ポリシーではない理由)
細かいが重要な違いです。ファイルアクセスポリシーは、ファイルの実行 (アプリケーションが起動した瞬間) をポリシー評価でインターセプトします。特権昇格ポリシーは、昇格した権限で何かを実行しようとしたときにだけインターセプトします。ここではファイルアクセスを使うことで、ユーザーが管理者権限を必要とするかどうかにかかわらず、あらゆるアプリケーション起動に承認要件がかかり、カバレッジが広がります。
ベースラインを土台としたレイヤー型のポリシー戦略
複数のポリシーを同一リソースに重ねるレイヤー型の構成で、防御の深さを確保できます。このベースラインのファイルアクセスポリシーが整ったあとの運用イメージは以下のとおりです。
高
許可 — IT承認済みアプリ (ブラウザー、Office など)
特定アプリ、すべてのユーザー
高
許可 — 開発者向けツール
特定ユーザー/グループ
低 (キャッチオール)
承認が必要 — 上記以外すべて
すべてのユーザー、すべてのアプリ
優先度の高い許可ポリシーに一致したアプリケーションは、そのまま実行が許可されます。明示的に許可されていないものはすべて、承認必須のベースライン・ファイルアクセスポリシーが適用されます。
運用上の重要な考慮事項
このポリシーはすべてのアプリケーションに適用されるため、特にエンドポイントを広げると承認要求が非常に多くなります。そのためドキュメントではパイロットグループから始め、広く展開する前に例外 (許可) ポリシーを整えることを推奨しています。バッチで展開しながらシステム性能とユーザーからの反応を監視し、運用要件に応じてポリシーを調整するのが推奨される進め方です。
最終更新