セキュリティ強化

本ページでは、KEPM展開におけるセキュリティのベストプラクティスと強化の推奨事項を取り扱います。デフォルト構成は最初から安全になるよう設計されていますが、本ガイドの設定は、エンタープライズや規制対象環境でより厳格なセキュリティ要件を満たすのに役立ちます。
ネットワークセキュリティ
すべての通信はlocalhost上に留まります。 KEPMエージェントは 127.0.0.1 にのみバインドします。HTTPサーバー (ポート6888および6889) と内部MQTTブローカー (ポート8675) はネットワークに公開されません。インバウンドアクセス用のファイアウォールルールは不要で、ネットワークレベルのアクセス制御も不要です。
ローカルAPIをネットワークに公開しないでください。 APIはローカルプロセス間通信専用に設計されています。リモート管理のためにネットワークインターフェースへバインドすることを検討している場合は、実行前にKeeperにお問い合わせください。認可モデルはネットワークからアクセス可能なエンドポイント向けに設計されていません。
展開後にlocalhostのみのバインドを確認
TLSは常に有効です。 すべてのHTTPS通信はTLS 1.2またはTLS 1.3を使用します。エージェントはlocalhost利用向けに起動時に自己署名証明書を生成します。これは正しく想定どおりの動作です。証明書はlocalhost通信を保護し、この文脈では自己署名証明書が適切です。
サービスアカウントの構成
SYSTEMまたはrootとして実行。 KeeperPrivilegeManagerサービスは、Windowsでは SYSTEM、Linux/macOSでは root として実行する必要があります。これは必須要件です。権限の低いアカウントで実行すると、エージェントが昇格リクエストをインターセプトし、ポリシーを適用できなくなります。
インストールパスはサービスアカウントのみが所有し、書き込み可能である必要があります。 インストールディレクトリとすべてのサブディレクトリはサービスアカウントが所有し、標準ユーザーは書き込み不可である必要があります。非特権ユーザーがインストールディレクトリ内の実行可能ファイルやプラグインファイルを変更できる場合、改ざんされたプラグインから保護する暗号検証が無効化されます。
Linux/macOSでパスセキュリティを確認
Windowsでは、インストールディレクトリのACLを確認します。
標準ユーザーには読み取りと実行権限があればよく、書き込みや変更権限は不要です。
証明書と署名の管理
特定の必要がない限り AlternativeSignatures は空のままにしてください。 appsettings.json の AlternativeSignatures 設定では、プラグイン署名用に追加の証明書サムプリントを信頼できます。デフォルト (空) 構成では、Keeper署名済みプラグインのみが読み込まれます。ここにサムプリントを追加すると、サードパーティまたはカスタムプラグインが許可されます。エントリを追加する前に必要性を慎重に検討してください。
証明書パスワードを構成ファイルに保存しないでください。 カスタム証明書を展開する場合は、Windows証明書ストアまたはプラットフォームの認証情報マネージャーで認証情報を保存してください。構成の CertPassword フィールドは常に空にしてください。
カスタム証明書は定期的にローテーションしてください。 組織がKEPM HTTPSエンドポイント用にカスタム証明書を使用している場合、PKIポリシー (通常は年次、または有効期限が近づいたとき) に沿ったローテーションスケジュールを確立してください。カスタム証明書が構成されていない場合、エージェントは再起動のたびに新しい自己署名証明書を自動生成します。
ファイル権限
以下の権限モデルをすべてのプラットフォームで適用してください。
インストールルート
サービスアカウント: フルコントロール; 管理者: 読み取り/実行; ユーザー: なし
Plugins/
サービスアカウント: フルコントロール; 管理者: 読み取り/実行; ユーザー: なし
Jobs/
サービスアカウント: フルコントロール; 管理者: 読み取り/実行; ユーザー: なし
KeeperStorage/
サービスアカウント: フルコントロール; 管理者: 読み取りのみ; ユーザー: なし
policies/
サービスアカウント: フルコントロール; 管理者: 読み取りのみ; ユーザー: なし
Linuxでは、/opt/keeper/sbin/ ディレクトリツリーがroot所有であり、グループおよびその他への書き込み権限がないことを確認します。
許可ホスト
appsettings.json の AllowedHosts 設定は、受け付けるHTTP Host ヘッダーを制御します。デフォルト値 "*" は任意のホストヘッダーを受け付けます。localhostのみの展開では許容できますが、厳格化できます。
ローカルプロセスのみがAPIとやり取りする本番展開では、localhost;127.0.0.1 に設定してください。AllowedHosts の変更にはサービスの再起動が必要です。
監査ログ
監査ログはデフォルトで有効であり、無効化できません。 すべてのポリシー評価、特権昇格、ファイルアクセス試行、構成変更、管理アクションは、MQTT AuditMessage トピックと統合ストレージへ自動的に記録されます。
監査ログは、コンプライアンスレビュー、インシデント対応、ポリシー有効性分析の主要な証拠源です。
ログを定期的に確認してください。 最低でも週次で監査ログを確認し、以下をチェックしてください。
単一ユーザーからの高頻度ポリシー評価の繰り返し: ポリシー回避の試みを示す可能性
管理アクション: 管理者レベルのAPI呼び出しは、ローカル認可モデルで最高特権を持ちます。実行者とタイミングを記録することで、特権乱用の検出とコンプライアンス要件の充足に必要な監査証跡が得られます
ポリシー評価の拒否: 拒否の急増は、正当な業務をブロックする誤構成のポリシー、または許可範囲を試すユーザー/プロセスのいずれかを示し、どちらも調査が必要です
構成変更:
appsettings.json、プラグイン構成、ジョブ定義の変更は、エージェントが信頼し適用する内容に直接影響します。不正または予期しない変更は、改ざんやサプライチェーン型攻撃の強い指標です認証失敗: ローカルAPIに対する繰り返しの失敗は、エンドポイント上のプロセスが不正アクセスを試みていることを示し、マルウェア、侵害されたアプリケーション、誤構成の統合によるアクセス試行の可能性があります
AUTHORIZATION_FAILEDとPROCESS_AUTHENTICATION_FAILEDは監査イベントタイプとして定義され記録されますが、これらは ローカルAPI認可失敗 であり、エンドポイントレベルのログイン失敗ではありません。特定の失敗シナリオが監査イベントとして記録されるかは、スタック内の発生位置によります
ポリシー回避の試み: ポリシーエンジンは
SessionIdまたはUserName+MachineNameの組み合わせをキーに、ソースごとの評価リクエストを追跡し、設定されたレート制限 (デフォルト: 1分あたり100リクエスト) を超えるリクエストをキューイングします。同一ソースから10回連続で失敗するとサーキットブレーカーが開き、自動リセットまで5分間開いたままになります。監査ログでは、単一のuser_info値が短時間に同一target_infoに対して異常な量のpolicy_evaluation_statusDENYイベントを生成している、またはレート制限キューをトリガーするバーストのいずれも、正当な業務ではなく許可的な実行パスを探るユーザーまたは自動化プロセスを示します
コンプライアンス要件の期間分ログを保持してください。 ログファイルはデフォルトで15日間保持されます。コンプライアンスフレームワーク (SOC 2、ISO 27001、FedRAMPなど) でより長い保持が必要な場合は、15日期間が切れる前にSIEMまたは中央ログストアへのログ転送を実装してください。ログファイルのパスについては、ログの確認をご参照ください。
セキュリティ監視の推奨事項
以下の条件を監視し、インフラで可能な場合はアラートを設定してください。
エージェント可用性
予期しないサービス停止やエージェントのオフラインを監視し、計画外の停止は除外されるまで改ざんの可能性として扱う
監査ログ(構成変更)
appsettings.json の変更をアラート; プラグインおよびジョブ構成ファイルはファイル整合性監視で別途監視
監査ログ(拒否)
定期的にSIEMへエクスポート; 短時間に同一 user_info からの繰り返しDENYイベントをアラート
監査ログ(登録)
計画された展開期間外のエージェント登録イベントをアラート
証明書
構成にパスワードを保存しない; AlternativeSignatures は空または最小限に保つ
ファイル権限
構成、ストレージ、ポリシーパスは管理者のみ読み書き
ログレベル
本番では Warning または Information ( Debug ではない)
ネットワーク
localhostのみのバインドを維持; AllowedHosts を特定ホスト名に設定
プロセス認証
KEPMが起動していないプロセスに関するプロセス認証イベントをサービスログで確認; PROCESS_AUTHENTICATION_FAILED として表示され、正常な展開では稀であるべき
サービスアカウント
WindowsではSYSTEM、Linux/macOSではrootとして実行
最終更新

