退職・脅威をリアルタイムに監視！常に検証し続ける証明書ライフサイクル

〜OneLogin・CrowdStrike連携による証明書の動的発行〜

はじめに

昨今、ゼロトラストの考え方が広がり、「社内だから安全」「一度認証したから問題ない」といった従来の前提を捨て、常に検証し続ける＝信頼しない仕組みが求められています。

そういった背景からネットワーク認証やIDaaS認証などでは、ユーザーのID・パスワードだけでなく、利用デバイスそのものを認証要素として扱うことが不可欠になってきています。そしてこの要件を実現できる代表的な手段としてクライアント証明書による認証方式があります。クライアント証明書はデバイスごとに固有に発行され、盗まれたID・パスワードだけでは突破できないことから、「だれが」だけでなく「どのデバイスから」アクセスしているかを担保できます。

ここで一般的に、クライアント証明書の運用は以下のようなライフサイクルとなっています。

発行：MDMなどを通じてデバイスごとに証明書を発行
更新：有効期限が切れる前に再発行
失効：問題がある場合は失効

この一連のプロセスを管理する仕組みのことをPKI (Public Key Infrastructure)と呼びます。PKIは長年標準的に利用されてきた仕組みですが、その一方で従来の運用方法のままでは「一度発行したら期限まで有効」という静的な性質を避けられず、ゼロトラストに求められる継続的な検証を実現できません。次セクションではこうした課題を克服するDynamic PKIについて紹介します

Dynamic PKIであるSecureW2が実現すること

従来のPKIでは証明書を発行するとき、IntuneなどのMDMを通じてデバイス情報を検証し、ポリシーに準拠していることを条件に証明書を発行する、というような流れが一般的でした。しかしながらこのままでは、証明書のライフサイクル（発行・更新・失効）において以下のような課題があります。

証明書発行時、MDMを通じたデバイス情報しか検証されず、ユーザーステータス・デバイスの健全性については検証されない
証明書が一度発行されたら、その証明書は有効期限までずっと利用し続けることができる。そのためユーザーが退職したり、デバイスが脅威に晒されたとしても、その証明書は有効のままとなってしまう

こういった課題に対してDynamic PKIであるSecureW2は以下のようなことを実現できます。

証明書発行時、IDaaS・MDM・EDRなど複数のソースと連携し、ユーザーおよびデバイスの信頼性を多面的に検証した上で発行する
証明書発行時だけでなく、常にユーザー・デバイス情報を検証し、ポリシー違反やリスクに応じてリアルタイムに証明書の更新・失効処理を行う

これにより証明書の発行から失効までを完全に自動化し、複数サービスと連携した動的なライフサイクルを実現できます。

どんなメリットがあるのか

上セクションにて、Dynamic PKIであるSecureW2を導入することで、証明書の発行から失効までの流れがどのように変化するか紹介しました。この変化は単なる証明書ライフサイクルの自動化にとどまらず、以下のようなメリットを生み出します。

	従来型PKI	SecureW2 (Dynamic PKI)
証明書発行ポリシーの強化	MDMのポリシーに準拠したデバイスであれば証明書発行を許可	退職したユーザーやリスクのあるデバイス宛てに発行することを防止
運用負担の軽減	手動での証明書運用特定の問題（退職・デバイスのリスク検知）発生時、手動で失効	自動化された証明書運用ユーザー・デバイス情報に応じて自動で更新・失効
ガバナンスの厳格化	問題発生のたび管理者が個別対応するため、対応方法にバラツキが発生証明書のライフサイクルや問題発生時の対応が不透明で、属人的な運用に依存	問題ごとの対応を事前に定義し、組織全体で一貫したポリシー適用を実現ライフサイクルや対応フローが明確化され、透明性・監査の実効性が向上

具体的にどんなことができるのか

SecureW2は上図にあるようにさまざまなサービスと連携することができます。またそれぞれから以下のような情報を取得し利用することができます。

IDaaS：ユーザーステータス、所属グループなど
MDM：デバイスコンプライアンスなど
EDR：デバイスの健全性スコアなど

これらを利用することで例えば以下のようなことを実現できます。

ユーザーステータスがアクティブであり、デバイス健全性スコアが設定値以上である場合のみ、証明書を発行する
デバイス健全性スコアが設定値を下回ったら、証明書を即時失効する

本記事では上記のうち1の実現を目的として、OneLogin（IDaaS）・CrowdStrike（EDR）と連携し、ユーザー・デバイス健全性を検証した上で、証明書を動的に発行する方法について説明します。これによりIDaaS上でアクティブでないユーザーに発行してしまう、またはデバイス健全性に問題があるのに発行してしまう、といった事態を防ぐことができます。

簡易的な導入手順

OneLoginとSecureW2とのAPI連携

OneLogin管理ポータルからAPI Credentialを生成し、Client IDとClient Secretの値をメモします。
OneLoginから取得したテナントURLおよびAPI認証情報を入力し、API連携の設定を行います。これでOneLoginが持つユーザー情報の取得ができるようになります。

CrowdStrikeとSecureW2とのAPI連携

SecureW2はデバイス健全性の指標として、CrowdStrikeからデバイスのZero Trust Assessment Score (Overall assessment)を使用します。スコアは100点満点で、1に近づくほどセキュリティ上脆弱であり、100に近いほど安全であることを示しています。
例えば下記画面ではスコアが89となっており、比較的安全な状態であることを示しています。
CrowdStrike管理ポータルからAPI Clientを生成し、Client ID、Secret、Base URLをメモします。
CrowdStrikeから取得したテナントURLおよびAPI認証情報を入力し、API連携の設定を行います。
CrowdStrikeから取得したZero Trust Assessment Scoreとリスクレベルのグルーピングを行います。例えば以下のように設定したならば、Zero Trust Assessment Scoreが80~100の場合に、リスクレベル"Low"としてグルーピングされます。

Policy Workflowの設定

以下のように設定したなら、OneLoginへのユーザーステータス問い合わせが正常に動作したこと、またデバイスのリスクレベルがLowであること、を条件に証明書が発行されます。

デモンストレーション

今回は、証明書発行時にユーザーステータス・デバイス健全性をそれぞれ検証し、両方の条件に適合していた場合にのみ証明書が発行されることを確認します。

各項目の条件は以下の通りです。

ユーザーステータス：デバイスに紐づいているユーザーIDをOneLoginに問い合わせ、そのユーザーがアクティブであること
デバイス健全性：デバイスのシリアル番号をCrowdStrikeに問い合わせ、そのデバイスのリスクレベルがLowであること※

※本検証では、下記画像のようにZero Trust Assessment Score が 80〜100 の場合に「Low」と判定される設定を例としています。

以下のシナリオに沿って動作を確認します。

	⁠ユーザーステータス(OneLogin)	デバイス健全性(CrowdStrike)	⁠証明書発行
1	⁠⚪︎	⁠⚪︎	⁠成功
2	⁠×	⁠⚪︎	⁠失敗
3⁠	⁠⚪︎	⁠×	⁠失敗

1. ユーザーステータスおよびデバイス健全性の両方をクリアしている場合

以下のように、OneLogin上のユーザー（taro.yamada@example.com）はアクティブになっています。
CrowdStrikeから該当デバイスを確認すると、健全性スコア（Zero Trust Assessment Score）は87となっています。そのためこのデバイスのリスクレベルはLowにグルーピングされます。
デバイスにSCEPプロファイルを配布すると、ユーザーステータス・デバイス健全性の検証に成功したため、証明書を発行することができました。以下のようなログをJoinNow Management Portal > Enhanced Eventsから確認することができます。

2. ユーザーステータスに問題がある場合

以下のように、OneLogin上のユーザー（taro.yamada@example.com）は非アクティブになっています。
CrowdStrikeから該当デバイスを確認すると、健全性スコア（Zero Trust Assessment Score）は87となっています。そのためこのデバイスのリスクレベルはLowにグルーピングされます。
ユーザーステータス検証に失敗したため、証明書を発行することができませんでした。以下のようなログを確認することができます。

3. デバイス健全性に問題がある場合

以下のように、OneLogin上のユーザー（taro.yamada@example.com）はアクティブになっています。
CrowdStrikeから該当デバイスを確認すると、健全性スコア（Zero Trust Assessment Score）は79となっています。そのためこのデバイスのリスクレベルはMediumにグルーピングされます。
デバイス健全性の検証に失敗したため、証明書を発行することができませんでした。以下のようなログを確認することができます。

おわりに

従来のPKIでは、IntuneなどのMDMを通じてデバイス情報を検証し、ポリシーに準拠していることを条件に証明書を発行するのが一般的でした。しかしこのプロセスでは、ユーザーステータスやデバイスの健全性が考慮されず、発行後にユーザーが退職したりデバイスが管理外となっても、その証明書は有効のままでした。

これに対し、Dynamic PKIであるSecureW2は、IDaaS・MDM・EDRなど複数のソースと連携し、ユーザーとデバイスの信頼性を多面的に検証します。さらに、ポリシー違反やリスクの変化に応じてリアルタイムに証明書の更新・失効を自動で行います。本記事では、この仕組みのうち、IDaaS（OneLogin）とEDR（CrowdStrike）を連携させ、証明書を動的に発行する方法を紹介しました。

また加えて、SecureW2の「Real-Time Intelligence (RTI)」を利用すれば、ユーザーやデバイスの状態変化を継続的に監視し、リスク検知時にはネットワーク遮断まで即座に実行できます。

これらを組み合わせることで、証明書の発行から失効までを完全に自動化し、常に最新のセキュリティ状態に基づいたアクセス制御を実現します。結果として、管理者の負担を軽減しつつ、ゼロトラストの原則に沿ったきめ細やかなセキュリティ運用が可能になります。以上で、「退職・脅威をリアルタイムに監視！常に検証し続ける証明書ライフサイクル」を終わります。