段階的ロールアウトの計画
段階的ロールアウトの考え方
段階的ロールアウトでは、コントロールを適用する前に、実運用でのポリシー評価結果 (ブロック、許可、監視対象としての記録) を把握できます。正当な業務ができなくなるリスクを抑えられます。最初に監視モードから始めると、挙動のベースラインが取れるため、フィルターやルールを事前に推測で書くより、精度の高いポリシーを用意しやすくなります。適用に進む頃には、管理者も利用者も内容を把握し、結果に自信を持てる状態になっています。
いずれのポリシーを適用にする前にも、ポリシーのステータスのライフサイクルを使い、利用者への影響を出さずに挙動だけを検証してください。
監視: ポリシーは評価しログに残しますが、コントロールはかかりません。利用者への影響はありません。挙動のベースラインを取り、フィルターが意図どおりのユーザー、マシン、アプリケーションに一致しているか確認するときに使います。
監視&通知: 監視と同じですが、操作を観測している旨をユーザーへ通知します。業務を止めずに周知を進め、のちの適用に備えられます。
適用: 自動許可、自動拒否、MFA、正当な理由、管理者承認といったコントロールが実際にかかります。前段階で挙動を確認してから適用に切り替えてください。
段階的ロールアウトの例
エージェンティックAIポリシーの段階的ロールアウト
エージェンティックAIポリシーは、AIエージェントや自律プロセスをエンドポイント上でどう識別、統制、監査するかを制御します。エージェンティックなワークロードは動的に起動し、人間が直接操作していなくても機微なリソースに触れることがあるため、適用前に挙動のベースラインを取ることが不可欠です。
エージェンティックAIポリシーは、エージェンティックアクセスポリシーやエージェンティック特権昇格ポリシーと重なることがよくあります。単独ではなく一体で計画し、コントロールを一貫して重ねてください。
推奨事項
ポリシーを書く前に、承認済みAIエージェントと想定される挙動を棚卸ししてください。ベースラインがないと、管理対象と管理外の活動を区別しにくくなります。
最初の適用は、エージェンティックワークロードを実行するユーザーとチーム (例: エンジニアリング、データサイエンス) にコレクションで適用範囲を絞り、組織全体へ広げる前に検証します。
エージェンティックAIポリシーに対応するアクセスポリシーと特権昇格ポリシーを組み合わせ、エージェントが到達できる範囲と実行できる操作を包括的にカバーします。
エージェンティックアクセスポリシーの段階的ロールアウト
エージェンティックアクセスポリシーは、AIエージェントが到達できるリソース (ファイル、パス、ネットワークエンドポイント ※Keeper EPM v2.2で対応予定、アプリケーション) を制御します。エージェントはマシン速度で、想定外の組み合わせでリソースにアクセスすることがあるため、適用前に実際のアクセスパターンを監視することが重要です。
フェーズ3以降 - 適用
適用に切り替え、リスクに応じたコントロールを設定します。
エージェントアクセスが承認されているリソースには自動許可。
エージェントが到達してはならない機微なパス (認証情報ストア、セキュリティツール、システムディレクトリ) には自動拒否。
ときどき正当だが監査証跡が必要なリソースアクセスには正当な理由。
エージェントの要求を実行前にエンドユーザーが承認する必要があるリソースアクセスにはエンドユーザー承認 (エージェントのアクセス試行は、エンドユーザーが明示的に許可するまで一時停止)。
監督アカウントではなく、上司またはセキュリティチームによるレビューが必要な高リスクなリソースアクセスには管理者承認。
エージェントが続行する前に、監督アカウントのステップアップ認証が必要なリソースアクセスにはMFA。
{userprofile}、{systemroot}、{programfiles} などのパス変数を使うと、移植しやすいクロスプラットフォームのエージェンティックアクセスポリシーを書けます。
推奨事項
広い自動拒否を適用する前に、承認済みワークフローでエージェントが必要とするリソースの許可リストを明確に定義します。
認証情報ストア、秘密情報を含む構成ファイル、セキュリティツールを明示的に対象にします。エージェントの到達から保護すべき価値が最も高いリソースです。
最初はエージェンティックワークロードを実行するチームにコレクションで適用範囲を絞り、その後組織全体へ広げます。
エージェンティック特権昇格ポリシーの段階的ロールアウト
エージェンティック特権昇格ポリシーは、AIエージェントがいつ、どのように昇格 (管理者) 権限で実行できるかを制御します。昇格したエージェント操作は、人間が直接監督していなくてもマシン速度でシステム状態を変えられるため、適用前の慎重なベースライン取得が重要です。ヒューマンインザループを実現するため、エージェンティック特権昇格ポリシーではエンドユーザー承認コントロールの導入を推奨します。
フェーズ3以降 - 適用
適用に切り替え、各操作のリスクレベルに応じたコントロールを設定します。
既知で安全な承認済み昇格ワークフロー (例: 信頼済みエージェントによる定期パッチ適用) には自動許可。
明示的に禁止する昇格エージェント操作には自動拒否。
まれだが監査証跡が必要な昇格要求には正当な理由。
エージェントの昇格を実行前にエンドユーザーが承認する必要がある場合にはエンドユーザー承認 (エージェントの昇格試行は、エンドユーザーが明示的に許可するまで一時停止)。
監督アカウントではなく、上司またはセキュリティチームによるレビューが必要な、高リスクまたは異例の昇格操作には管理者承認。
機微性の高い管理操作を試みるエージェントにはMFAまたは管理者承認 + MFA。
エージェンティック特権昇格は、最小特権ポリシーと組み合わせてください。エージェントが恒常的な管理者権限を持たず、昇格を明示的に要求する構成にします。
推奨事項
ユーザー昇格よりエージェント昇格を厳しく扱ってください。エージェントは人間より速く、大量に操作できるため、許可設定のミスによる影響範囲が大きくなります。
広い自動拒否を適用する前に、既知で承認済みのエージェントワークフロー向けの自動許可ポリシーを用意します。
エージェンティック特権昇格ポリシーとエージェンティックアクセスポリシーを組み合わせ、エージェントが何を、どこで実行できるかの両方を制御します。
コマンドラインポリシーの段階的ロールアウト
コマンドラインポリシーは、ユーザーが実行できるコマンド、スクリプト、シェル操作を制御します。コマンドラインは攻撃経路になりやすい一方、正当な業務でも欠かせないため、適用前にベースラインを慎重に取る必要があります。
フェーズ3以降 - 適用
適用に切り替え、コントロールを設定します。よくある構成例は以下のとおりです。
対象ユーザー向けに明示的に承認されたコマンドには自動許可 (例: 安全と分かっている管理ユーティリティ)。
既知の危険なコマンド (破壊的なファイル操作、ユーザーアカウント操作、承認されたフロー外のレジストリ変更など) には自動拒否。
ときどき正当だが監査証跡が必要なコマンドには正当な理由。
上司またはセキュリティチームの明示的な許可が必要なコマンドには管理者承認。
ステップアップ認証が必要な機微性の高いコマンドにはMFAまたは管理者承認 + MFA。
ポリシー適用範囲の理解
コマンドラインポリシーを書く前に、適用範囲がどう決まるかを押さえておいてください。
Extensionsセクションがないポリシーは、昇格時のみ対象のワイルドカードポリシーです。sudoのワイルドカード指定に相当する扱いで、昇格したコマンドすべてに適用します。昇格していないコマンドにポリシーを当てるには、
Extensionsに"IsElevated": falseを明示的に含める必要があります。ExtensionsにAllowCommandsセクションがないポリシーは、ワイルドカードのコマンドラインポリシーで、すべてのコマンドに適用します。AllowCommandsにコマンドを列挙すると、列挙したコマンドにだけ適用します。
具体的なポリシーはワイルドカードより優先されます。標準のポリシー評価ルールと同じです。
コマンドが
AllowCommandsに自動許可コントロールで載っていれば、ワイルドカード側がMFAなどを要求していても許可されます。逆に、特定のポリシーで正当な理由が要求されている場合、同じコマンド向けの別の特定ポリシーが自動許可になっていても、そのコントロールが優先されます。
コマンドラインポリシーは、親シェルプロセスではなく、実行されるコマンドに対して評価します。1つのシェルセッションでも、ユーザーが実行するコマンドごとに異なるポリシーが当てはまることがあります。
推奨事項
定義済みポリシーをベースラインとして始め、内容を見直しながら調整します。
いきなりすべてをホワイトリスト化するのではなく、リスクの高いコマンドだけを列挙した自動拒否リストから始めます。
広い制御に進む前に、初期のコマンドラインポリシーは昇格コンテキスト (
sudo、runas、昇格シェルなど) に適用範囲を絞ります。1つのシェルアプリケーション内で、
AllowCommandsとDenyCommandsを組み合わせて細かく定義します。ポリシーは具体的に保ちます。コマンドパターンに広すぎるワイルドカードを使うと意図しない一致が起きます。コマンドパターンを書く前にワイルドカードのリファレンスを確認してください。
ファイルアクセスポリシーの段階的ロールアウト
ファイルアクセスポリシーは、どのアプリケーションがファイルやフォルダを読み取り・書き込み・実行できるかを制御します。影響範囲が広いため、段階的に広げることが重要です。
フェーズ1 - 監視
すべてのユーザー、すべてのアプリケーション、すべてのマシンコレクションを対象とするファイルアクセスポリシーを作成し、監視モードに設定します。監査ログを確認し、環境全体でどのようなファイルアクセスが起きているか把握します。保護が必要な機微なパスを洗い出し、{userprofile} などの変数を含むフォルダ指定が意図どおり解決されるか確認します。
制御したい実行ファイル (PowerShell、コマンドプロンプト、DMG、pkg、ダウンロードやホームフォルダ内のアプリなど) が特定できたら以下のとおり進めます。
保護されたパスにない実行ファイルにはワイルドカードを使います。
追加のコントロールが必要な機微な領域にはコレクションを作ります。
ダウンロードやホームフォルダなど管理外領域を制限し承認を求めるポリシーを作ります。これらは承認 (ACK) なしで監視&通知にします。
フェーズ3以降 - 適用
適用に切り替え、リスクに応じたコントロールを設定します。
アクセスが明示的に承認されているパスとアプリケーションには自動許可。
禁止パスには自動拒否。
機微なディレクトリには正当な理由。
高リスク操作には管理者承認。
ステップアップ認証が必要な機微性の高いパス上のファイル操作にはMFA。
監視フェーズで観測した内容に合わせてフィルターを調整します。いきなり厳格な自動拒否にせず、まず正当な理由や管理者承認から始めることも検討してください。
ワイルドカードは対象範囲の洗い出しの出発点として推奨しますが、組織の要件によっては特定の実行ファイルだけを明示的に自動許可または厳格な自動拒否にする方が適切な場合もあります。必要に応じて粒度の細かい別ポリシーで定義できます。
ワイルドカードは対象範囲の洗い出しの出発点として推奨しますが、組織の要件によっては特定の実行ファイルだけを明示的に許可または厳格に拒否する方が適切な場合もあります。必要に応じて粒度の細かい別ポリシーで定義できます。
推奨事項
{userprofile}、{systemroot}、{programfiles}などの変数で、クロスプラットフォームで移植しやすいポリシーを書きます。すべてを広くブロックするのではなく、認証情報ストアや構成フォルダなど機微なディレクトリを明示的に対象にします。
機微なパスにアクセスしそうなグループにコレクションで適用範囲を絞り、組織全体へ広げる前に検証します。
機微な内容を含む非実行ファイルは個別に対象にします (例: キー、パスワード、アカウント名を含む構成ファイル。
hosts.infや/etc/hostsなど)。
最小権限ポリシーの段階的ロールアウト
最小権限ポリシーは、ユーザーから恒常的な管理者権限を外し、横移動や権限濫用の攻撃面を小さくします。端末上でできることが変わるタイプのため、混乱の可能性が最も高く、展開前の計画が最も重要です。
フェーズ3以降 - 適用
適用に切り替えます。最小権限ポリシー自体では操作ごとのコントロールは設定できません。適用すると、対象ユーザーの恒常的な管理者権限を外します。自動許可、自動拒否、正当な理由、管理者承認、エンドユーザー承認、MFA は最小権限ポリシーでは構成しません。
降格後の特定の管理操作を制御するには、1つ以上の特権昇格ポリシーを重ねます。個別の昇格要求に対する自動許可、自動拒否、正当な理由、管理者承認、MFA は特権昇格ポリシー側で設定します。
最小権限は、特権昇格ポリシーと組み合わせたときに最も効果を発揮します。昇格の道を用意せずに管理者権限だけを外すと、正当なワークフローが壊れ、問い合わせが増えます。
推奨事項
パワーユーザー、開発者、IT担当より、リスクの低い標準ユーザーから先に最小権限を適用します。
適用前に特権昇格ポリシーを組み合わせ、正当な管理操作のための承認済み経路を用意します。
組織全体を一度に切り替えるのではなく、部門、チーム、マシングループ単位でコレクションを使い段階的に適用します。
十分に前もって周知してください。最小権限は、ユーザーが最もすぐに気づくポリシータイプです。
特権昇格ポリシーの段階的ロールアウト
特権昇格ポリシーは、ユーザーまたはプロセスが昇格 (管理者) 権限でいつどう実行できるかを決めます。ソフトウェアのインストール、システム設定の変更、管理ツールの実行に直結するため、適用前の検証が不可欠です。
特権昇格ポリシーは、ユーザーのセッションではなく、昇格対象のアプリケーションに対して評価します。同じユーザーでも、昇格しようとするアプリケーションによって受けるコントロールは異なります。
推奨事項
より広い適用の前に、コレクションで高リスクなユーザー層 (例: 開発者、IT担当者) を先に対象にします。
広い自動拒否を適用する前に、既知で承認済みのアプリケーション向けの自動許可ポリシーを用意します。正当な業務の妨げを減らせます。
特権昇格ポリシーと最小権限ポリシーを組み合わせ、管理者権限の統制を一体で運用します。
最終更新