1. はじめに
前回の記事 (第11回) では、TLSにおけるクライアント証明書認証の概要について解説しました。
本ブログ記事では、OktaのPIV/CACと呼ばれるスマートカードAuthenticatorを用いたクライアント証明書認証 (以降、「PIV/CAC」と呼びます) の具体的な設定方法をお伝えします。
名称が「スマートカード」となっているので、「ICチップ付きの物理カードが必要なの？」と思いがちな機能ですが、必ずしもスマートカードは必要ではなく、クライアントPC内の証明書ストアに入っているクライアント証明書もご利用可能です。
また、この認証機能はWebブラウザが持つ標準の機能を利用しますので、Okta Verifyをクライアントデバイスにインストールする必要はありません。
※PIV/CACの機能は、残念ながらトライアル環境ではデフォルトでは有効になっていませんので、トライアル環境でご利用になられたい場合は、Okta営業またはOkta SEまでご連絡ください。
2. クライアント証明書の準備
PIV/CACの設定には、当然ながらクライアント証明書が必要です。
クライアント証明書の発行には、例えば、Active Directoryで管理されているWindowsデバイスであれば、Active Directory 証明書サービス (ADCS: Active Directory Certificate Services) の利用が考えられます。
もちろん、PIV/CACと呼ばれるようなICチップ付きの物理カードとカードリーダーが利用できるなら、それが最も良い選択だと思います。
しかし「そのような環境はない」という場合には、あくまで動作確認を目的とした方法となりますが、OpenSSLを使って証明書を生成することもできます。
その手順については、下記をご参照ください。
参考資料A: 「はじめてのOkta Workforce Identity [号外] クライアント証明書をOpenSSLで作ってみよう」
以降は、この「参考資料A」に記載された内容に従って生成した証明書を利用する前提で説明していきます。
※※※＜＜本番環境に向けた推奨事項＞＞※※※
本ブログ記事では、動作検証をスムーズに行うために「参考資料A」のOpenSSLを使用して発行した証明書を利用する手順を解説していますが、これはあくまで「動作確認用」の手順です。
実際の組織運用 (本番環境) においては、セキュリティと運用効率の以下の観点から、MDM (Intune/Jamf等) や ADCS (Active Directory 証明書サービス) が提供する「証明書の自動登録 (Enrollment) 機能」の活用を強く推奨します。
◼︎ 秘密鍵のハードウェア保護 (TPM / Secure Enclave):
MDMやADCSの自動登録機能を利用すると、秘密鍵はデバイスのセキュリティチップ (TPM や Secure Enclave) 内で直接生成され、その外に出ることなく格納されます。これにより、OSの管理者権限であっても物理的に抽出 (エクスポート) 不可能な状態を実現し、私物PCへの流用や盗難リスクを封じ込めます。
◼︎ 配布プロセスの安全性:
秘密鍵の生データ (PFXファイル)がネットワークを流れたり、管理者のPCに一時保存されたりすることがありません。「デバイスが自ら鍵を生成し、証明書を要求する」 仕組みのため、配布過程での紛失や漏洩リスクをゼロにできます。
◼︎ 運用ライフサイクルの自動化:
100台、1,000台といった大規模環境への一斉配布に加え、有効期限に伴う更新作業もユーザーや管理者の手を介さず全自動化が可能です。
※※※※※※※※※※※※※※※※※※※※※※
3. PIV/CACの設定
では、実際に設定していきましょう。設定ステップは割と少なめです。
3.1. IDプロバイダーの設定
まずは、IDプロバイダーの設定が必要です。
「セキュリティ」→「IDプロバイダー」→「IDプロバイダー」タブで、「IDプロバイダーを追加」をクリックします。
「Smart Card〜」を選択し、「次へ」をクリックします。
以下の画面の「名前」には任意の値 (ここでは「OKTAJ-InterCA」としました) を入力します。
「証明書チェーン」の下の「証明書チェーンをアップロード」では、クライアント証明書を発行した認証局の証明書ファイルを選択してください。
(「参考資料A」では、中間認証局の「interCAcrt.pem」が該当します。)
「証明書チェーンを構築」をクリックします。
「ユーザーの一致」の下の「IdPユーザー名」では、クライアント証明書内のどの値をユーザー名として利用するかを指定します。
(「参考資料A」では、クライアント証明書のsubjectAltNameにはEmailで設定しているので、「idpuser.subjectAltNameEmail」を選択します。)
「セキュリティ特性」では、「PINで保護」も「ハードウェア保護」もどちらもOFFにします。
(なぜなら「参考資料A」で生成したクライアント証明書では、どちらも該当しないからです。)
「終了」をクリックします。
===== << Tips >> =====
「セキュリティ特性」の設定は、Oktaがクライアントの状態をチェックしてくれる機能ではありません。
なぜなら、クライアント証明書認証の仕組み上、サーバー側 (Okta側) に伝わるのは「クライアントが正しい秘密鍵を持っていること」の証明 (署名) だけであり、その鍵が物理的にどこ (ディスク、TPM、USBトークン等) に保管されているかという情報やPINで保護されているかどうかの情報は、標準的なプロトコルではサーバー (Okta) 側に送られないからです。
では、なぜこのような設定があるのでしょうか？
それは、管理者側が「事前」に、秘密鍵がPINで保護またはハードウェア保護されていることを知っているなら、この機能をONにすることで、スマートカードAuthenticatorの要素タイプを変えることができるからです。
具体的には、例えば「PINで保護されている」と管理者が事前に知っているとしましょう。
その場合、「PINで保護」をONにすることで、こちらに記載されているように、スマートカードAuthenticatorを「所有」だけでなく「知識」としての要素も持っている＝スマートカードAuthenticatorだけで二要素として利用できる、ということです。
繰り返しになりますが、Okta側では「実際にPINが使われているかどうかは分からない」ので、その点は注意が必要です。
===================
3.2. スマートカードAuthenticatorの設定
次に、スマートカードAuthenticatorの設定を行います。
「セキュリティ」→「Authenticator」→「Authenticatorの追加」をクリックします。
「スマートカード Authenticator ー セキュリティカード (PIV/CAC) による認証」の「追加」をクリックします。
「スマートカードIDプロバイダー」には、事前に設定しておいたIDプロバイダー: 「OKTAJ-InterCA」を選択して、「追加」をクリックします。
3.3. 認証ポリシーの設定
この環境では、Okta Dashboardへのアクセスの際にPIV/CACが使えるように、認証ポリシーに「任意の2要素タイプで許可」の設定を行っています。
===== << 重要 >> =====
PIV/CACを動作させるには、CRL (Certificate Revocation List: 証明書失効リスト) が必須です。
CRLについては、Okta側の設定はなく、クライアント証明書内のCRL Distribution Pointに記載されたURLをOktaが参照して、そのURLに問い合わせる、という仕様になっています。
OktaからCRLの参照ができないと、PIV/CACの認証は失敗します。
CRLの生成及び配置については「参考資料A」内に記載していますので、ご参照ください。
===================
PIV/CACの設定は以上です。
4. 動作確認
設定が完了したので、動作を確認してみましょう。
では、(「参考資料A」では、asaku.akawa@atko.email用のクライアント証明書を発行したので、)asaku.akawa@atko.emailでログインしてみましょう。
※ 現在、asaku.akawa@atko.emailが持っているAuthenticatorは「パスワードのみ」である、という前提です。
まず、パスワードの入力を求められます。
「Smart Card Authenticator」の下の「セットアップ」をクリックします。
クライアント証明書の選択が求められます。
私のクライアント環境 (Windows 11) では、クライアント証明書を3つ (asaku用, bsaku用, csaku用) 入れています。
今回はasakuなので、asaku.akawa@atko.email 用のクライアント証明書を選択して、OKをクリックします。
この動作確認では他のAuthenticatorは不要ですので、「続行」をクリックします。
結果、Okta Dashboardにログインできると思います。
一旦サインアウトして、もう一度ログインしてみてください。
「パスワード」と「クライアント証明書」の二要素の認証が求められると思います。
ではちょっと実験をしてみましょう。
「セキュリティ」→「IDプロバイダー」→「IDプロバイダー」タブで、「OKTAJ-InterCA」の「アクション」→「IDプロバイダーを構成」をクリックします。
「編集」をクリックして、「セキュリティ特性」の下の「PINで保護」をONにし、「IDプロバイダーを更新」をクリックします。
もう一度、asaku.akawa@atko.email でOkta Dashboardにログインしてみてください。
今度は、「クライアント証明書認証だけ」＝パスワードの入力は求められなくなったはずです。
要するに、上記の設定だけでクライアント証明書が二要素を満たしている、とOktaが判断したためです。
このクライアントの環境では、秘密鍵へのアクセスにPINを要求するように設定されていませんから、この状態は「偽り」の状態であるため、よい状態ではありません。
よって、上記の「セキュリティ特性」設定は、自社の環境に合わせた設定を行ってください。
5. まとめ
本ブログ記事では、クライアント証明書認証 (PIV/CAC) の設定方法について解説しました。
このクライアント証明書認証 (PIV/CAC) は、Okta側は比較的簡単に設定ができ、ユーザーの操作も容易で、フィッシング耐性もある機能ですから、各端末にユーザー毎のクライアント証明書が用意できる環境であれば、認証要素の一つとしてご採用をご検討頂ければと思います。
==========
Okta Workforce Identityでは、認証の強化だけに留まらず、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しています。(日本語でのトレーニングもご用意しています。)
このトレーニングは全体像を体系的にご理解頂ける内容となっていますので、是非ともご活用ください。
