ServiceNow に Keeper Secrets Manager を統合する

ServiceNow のユーザーは、Keeperシークレットマネージャーとのシームレスな統合を介して Keeper Vault から認証情報を動的に取得することで、組織内におけるシークレットの広がりを排除できます。

ServiceNow は、ワークフローの自動化、サービス管理、ビジネスプロセスの自動化ソリューションを企業に提供する、クラウドベースのプラットフォームです。 ServiceNow は、今日利用可能な IT サービスソリューション（ITSM）で最も人気があり、広く導入されているものの 1 つです。

ServiceNow Management、Instrumentation and Discovery（MID）Server は、ServiceNow の IT 運用管理（ITOM）スイート、特に発見とオーケストレーションモジュールには不可欠なコンポーネントです。 MID は、クラウドの ServiceNow インスタンスと、組織のローカルネットワークやインフラストラクチャの橋渡し役として機能します。

発見やオーケストレーションなどのタスクにおいて、MID サーバーがさまざまなインフラストラクチャコンポーネント（システム、デバイス、アプリケーション、サーバーなど）にアクセスする必要がある場合は、通常 ServiceNow インスタンスに保存されている認証情報に依存します。 しかし、認証情報を ServiceNow インスタンスに直接保存すると、統合や監査の課題が組織に発生する可能性があります。 ただ、それよりも重要なことは、認証情報を ServiceNow に保存すると認証情報の保存場所が分散化されるため、組織の攻撃対象領域が増加することです。

シークレットスプロールとは

企業では、SSH キー、SNMP コミュニティ文字列、OAuth トークン、ユーザー名/パスワードの組み合わせなどの認証情報に対して、適切な管理や追跡、保護が行われないことによる「シークレットスプロール」現象が発生する場合があります。

シークレットスプロールは、以下のような深刻なセキュリティリスクを生み出します。

• 攻撃対象領域の増加：シークレットが存在する場所が多いほど、攻撃者がそれらを見つけて悪用する機会が増えます。
• 説明責任の欠如：シークレットが一元管理されていないと、誰がどのシークレットにアクセス可能なのか、シークレットが最後に使用または変更されたのはいつなのかを把握するのは困難です。
• 対応の難しさ：侵害が発生した場合、漏洩したシークレットを特定し、それらを迅速にローテーションすることはより困難です。
• コンプライアンス違反：GDPR、CCPA、HIPAA などの規制は、センシティブデータの厳重な管理を義務付けています。 シークレットスプロールは、コンプライアンス違反や、関連する罰則につながる可能性があります。

Keeperシークレットマネージャー（KSK）は、これらの課題を回避します。 KSM を使用すると、手頃な価格で簡単に導入できる完全に管理されたクラウドベースのプラットフォームで、DevOps と DevSecOps チームがシークレットの管理と保護を実現します。

ServiceNow のお客様は、オンデマンドの発見やインシデント対応のため、そしてカスタム認証情報のプロバイダーとして KSM を使用することができます。

例：新しいデータセンターのオンボーディング

ある企業が、サーバー、ネットワークデバイス、その他のインフラストラクチャコンポーネントの組み合わせで新しいデータセンターを設立しました。 IT チームは、これらの新しいアセットすべてを ServiceNow の構成管理データベース（CMDB）内で文書化し、管理することを目指しています。

開始：IT 管理者が、新しいデータセンターのアセットを ServiceNow に追加する必要があることに気付きます。 管理者は ServiceNow にログインし、新しいデータセンターでオンデマンドの発見プロセスを開始します。

トリガー：ServiceNow はリクエストを検知し、新しいデータセンターでインフラストラクチャと通信してアセットを発見する必要性を認識します。 ServiceNow は MID サーバーに要求を送信し、新しいデータセンターと関連付けられた特定の IP 範囲やドメインの発見プロセスを開始します。

認証情報の取得：ServiceNow や MID サーバーに認証情報を保存する（セキュリティリスクとなる可能性）代わりに、MID サーバーは、Keeperシークレットマネージャー と通信して必要な認証情報を取得します。 ServiceNow インスタンスは、すべての認証情報、それらの種類（SSH、SNMP、Windows など）、および関連する認証情報アフィニティに対し、唯一無二の識別子を保持します。 MID サーバーは、認証情報の識別子、種類、および IP アドレスをインスタンスから取得し、Keeper vault を使用してこれらの要素を使用可能な認証情報に変化させます。

発見プロセス：必要な認証情報で身を固めた MID サーバーは、新しいデータセンター内のインフラストラクチャにアクセスします。 MID サーバーは、サーバーやネットワークデバイス、ソフトウェアアプリケーション、構成、その他の関連情報を特定します。 MID サーバーは、このプロセスを実行中に KMS の認証情報を使用するため、それらが漏洩したり、保存の際に安全性が欠けたりすることはありません。

CMDB の更新：発見プロセスが完了すると、MID サーバーは情報を ServiceNow に送り返します。 ServiceNow は、新しく発見したアセットで CMDB を更新し、それらが文書化および分類され、プラットフォーム内で管理できる状態にします。

完了：IT 管理者は、ServiceNow 内で新しいデータセンターのアセットを閲覧することや、それらの管理、他の IT サービスへのリンク、必要に応じてそれらを保持、更新、廃止することができるようになります。

KSM を統合することで、発見プロセスで使用される認証情報を安全に保ち、漏洩のリスクを低減します。 発見の特性がオンデマンドであるため、アセットがオンボーディングされるとすぐに CMDB に追加され、記録を最新の状態に保ちます。 CMDB を正確かつタイムリーに更新することで、組織は内部ポリシーや外部規制を確実に遵守できます。

この例では、Keeperシークレットマネージャー と ServiceNow の統合により、発見プロセスが合理化され、それが効率的かつ安全であることが保証されています。 静的で保存された認証情報を排除し、代わりに KSM から動的に取得された認証情報を使用することで、「シークレットスプロール」のリスクが減少し、組織全体のセキュリティ体制が強化されます。 これは KSM と ServiceNow を統合する多くのユースケースのほんの一例です。

Keeper と ServiceNow を統合するメリットについての詳細は、今すぐデモを予約してください。