実行時に認証情報を取得
ServiceNow Discovery、Orchestration、Service Mappingは、KeeperボルトのシークレットをKeeperシークレットマネージャーを通じて取得し、ジョブ実行時に認証します。インスタンスは認証情報そのものを保管せず、ボルト内のシークレットを指し示す情報のみを保有します。必要に応じて、MID Serverがその情報をもとにボルトから実際の認証情報を取得します。
KeeperボルトとServiceNowを統合
KeeperとServiceNowは連携し、シークレットをボルトに保管したままチームの作業環境で活用できます。Keeperは、実行時にServiceNowのジョブ用の認証情報を提供し、セキュリティアラートをインシデントチケットとして送信します。また、ServiceNowのリクエストと承認プロセスを通じてボルトへのアクセス制御も行えます。必要な機能を選んで有効化できます。
インスタンスに認証情報を保管しない
ServiceNowに保管されるのは、認証情報のIDとタイプだけです。実際に使用可能なシークレットはKeeperに保管されたままです。
ゼロ知識設計
レコードの検索と復号はローカルで行われ、ジョブに必要なシークレットのみを取得します。
柔軟な識別とマッピング
UIDまたはタイプとタイトルの組み合わせでレコードを識別でき、mid_で始まるフィールドを使用することで、Keeperのレコードを任意の認証情報タイプにマッピングできます。
ServiceNowからボルトアクセスを管理
Keeper Commander®はコマンドラインツールで、MID Server上でサービスモードで動作し、ServiceNowのIntegrationHub、Flow Designer、サービスカタログポータルを通じてボルト操作を処理します。ユーザーがアクセスをリクエストし、承認者が許可または拒否することで、レコードが移動します。ユーザーはServiceNowを離れることなく、すべての操作が完結します。
セルフサービスによる申請と承認
レコードやフォルダへのアクセス、あるいはワンタイム共有をリクエストし、承認グループを通じてルーティングすることで、アクセスが許可または取り消されます。
ServiceNowからボルトに保管・検索
ボルトにログイン情報、データベース認証情報、サーバー認証情報、SSHキー、ソフトウェアライセンス、セキュアノートなどを追加して保管でき、既存のレコードとフォルダを検索できます。
EPM承認とPAMローテーション
エンドポイント特権マネージャーのリクエストを承認または拒否でき、付与されたアクセスが失効した時に、PAMレコードのパスワードを自動的にローテーションします。
認証情報の散逸を削減
Keeperで認証情報を一元管理し、ServiceNowの認証情報レコードに複製する必要がありません。複製されたデータは時間とともに古くなってしまいます。シークレットをローテーションまたは更新すると、次のジョブは実行時に最新の値を取得するため、複数のコピーを管理・追跡する手間がなくなります。
セキュリティ対応を迅速化
Keeperのアラートが自動的にServiceNowのセキュリティインシデント対応チケットとして到着するため、手動入力やシステム間での情報転記を待つ必要がありません。優先度マッピングにより、最も緊急なイベントタイプがキューの最前部に配置されるため、チームは重要なインシデントから優先的に対応できます。
完全な監査記録
認証情報の照会、アクセスリクエスト、承認がすべてログに記録されるため、誰が何をリクエストしたか、何にアクセスされたか、誰が承認したかを追跡できます。これにより、KeeperとServiceNowのすべての連携操作について、統一された監査証跡が得られます。
既存ワークフローとの連携
統合は、検出スキャン、SIRキュー、サービスカタログなど、チームがすでに使用しているServiceNowワークフローに組み込まれます。新しいツールを学ぶ必要はありません。Keeperはバックグラウンドで動作するため、業務プロセスを変更することなく導入できます。
シークレットはKeeperに保管
Keeperが認証情報を取得する場合も、アラートを送信する場合も、アクセスリクエストに対応する場合も、ボルトは常に唯一の信頼できる情報源であり続け、すべてのシークレットはゼロ知識暗号化によって保護されています。ゼロ知識とは、お客様側でのみデータが暗号化・復号されることを意味し、Keeperを含め他の誰もそのデータを読み取ることができません。
Keeperのアラートをインシデントに変換
Keeperのセキュリティアラートは、ServiceNowのSecurity Incident Response (SIR) モジュールへ直接送信され、既存のSIRワークフロー内でチームが対応の優先順位を判断するチケットとなります。アラートはWebhook経由で届き、自動的に保存されるとともにインシデントレコードへ変換されます。
安全なWebhook受信
OAuth 2.0で保護されたエンドポイントが、認可された送信元からのアラートを受け付けます。認証にはベアラートークンを使用し、トークンはKeeperアプリ内で管理します。
チケットの自動作成
受信したアラートはインポートセットテーブルに取り込まれ、事前定義されたマッピングルールを通じてSIRレコードとして自動的に作成されます。
300以上のイベントタイプに対応した優先度マッピング
Keeperの各イベントタイプをServiceNowの優先度にマッピングすることで、チームは最も緊急性の高いインシデントから優先的に対応できます。
KeeperとServiceNowを連携
よくある質問
ServiceNow連携の機能を1つだけ利用することはできますか？
はい。各機能は独立して動作するため、まず1つの機能から始めて、必要に応じて他の機能を追加していくことができます。ただし例外として、Workflowアプリのエンドポイント特権マネージャーの承認機能は、インシデントを作成するためにITSMアプリが必要です。
認証情報はどこに保管されますか？
認証情報はKeeperボルト内にのみ保管されます。ServiceNowがシークレットの正式な保管先になることはありません。認証情報の参照はインスタンス内に保持され、実行時にその参照からシークレットが取得されます。また、ワークフローアプリはレコードをボルトとの間で受け渡しますが、ServiceNow側に保存することはありません。
どのServiceNowモジュールに対応していますか？
認証情報の取得は検出 (Discovery)、オーケストレーション (Orchestration)、サービスマッピング (Service Mapping) を対象としています。アラートのチケット化にはSecurity Incident Responseを使用します。WorkflowアプリはIntegrationHub、Flow Designer、サービスカタログを使用します。
導入を始めるには何が必要ですか？
認証情報の取得には、Keeperシークレットマネージャー、設定済みのMIDサーバー、ServiceNowのExternal Credential Storageプラグインの有効化が必要です。ITSMアプリには、Security Incident Responseモジュールと、Keeper管理コンソールでのアラート設定が必要です。Workflowアプリには、Keeperコマンダーをサービスモードで実行するMIDサーバーが必要です。各アプリには個別のセットアップガイドが用意されています: Credential Resolver、ITSM、Workflow。