1. はじめに
本ブログ記事では、デスクトップデバイス (WindowsまたはmacOS) 向けのOkta Device Trustについて解説します。
Okta Device Trustは、例えば「会社が許可したデバイスにだけ、会社のリソースへのアクセスを許可したい」という場合にご利用頂ける機能です。
前々回の記事 (第11回) と前回の記事 (第12回) では、「クライアント証明書認証」について解説しました。
一方、このOkta Device Trustもクライアント証明書を利用するので、「クライアント証明書認証」と混同しがちではないでしょうか？
Okta Device Trustは名称の通り、あくまで「デバイスを信頼する」＝「このユーザーにはこのデバイスだけ使わせる」という制御であって、「ユーザーの認証ではない」ので、そこを明確に区別する必要があります。
どういうことか、動作を確認しながら探っていきましょう。
2. Okta Device Trustの動作イメージ
Okta Device Trustは「ユーザー認証の手前」で動作し、Oktaが「このデバイスはダメ」「このデバイスはOK」という判断をします。
その判断には、クライアントデバイスにインポートされているクライアント証明書が使われます。
下記はその動作イメージです。
◼︎Okta Device Trustを利用する場合は、「デバイスにOkta Verifyのインストールが必須」です。
◼︎Okta Device Trustを含む (a)〜(d) の処理は「認証の前」に行われ、Oktaが「このデバイスは信頼できるか？」の判断をします。
◼︎その後で、信頼できるデバイスに対してのみ、ユーザー認証 (下図の (1)〜(3) ) が実行されます。
なので、Okta Device Trustを行う場合に、もし認証には「クライアント証明書認証 (PIV/CAC)」を使うなら、クライアントはOktaに対して、それぞれ別の目的で、クライアント証明書を2回提示することになります。
以降、Okta Device Trustを設定し、少々実験的に (＝この設定を実運用で使うかどうかは別として) 動作を確認してみましょう。
3. クライアント証明書の準備
Okta Device Trustを行うには、クライアント証明書が必要です。
クライアント証明書の発行には、以下の方法が推奨されます。
・MDM (例えば、IntuneやJamf 等) で管理されているデバイスであれば、そのMDMからSCEPプロファイルをデバイスに発行して、Oktaが発行するクライアント証明書をSCEPを使って受け取る。
・Active Directoryで管理されているWindowsデバイスであれば、Active Directory 証明書サービス (ADCS: Active Directory Certificate Services) から発行する。
「そのような環境はない」という場合には、あくまで動作確認を目的とした方法となりますが、OpenSSLを使って証明書を生成することもできます。
OpenSSLを使った証明書の発行手順については、下記をご参照ください。
参考資料A: 「はじめてのOkta Workforce Identity [号外] クライアント証明書をOpenSSLで作ってみよう」
本記事では、この資料 (OpenSSL) を使って、以下のいずれか2つのクライアント証明書を生成済みである前提で進めていきます。
asaku.akawa@atko.email
bsaku.bkawa@atko.email
csaku.ckawa@atko.email
※※※＜＜本番環境に向けた推奨事項＞＞※※※
本ブログ記事では、動作検証をスムーズに行うために「参考資料A」のOpenSSLを使用して発行した証明書を利用する手順を解説していますが、これはあくまで「動作確認用」の手順です。
実際の組織運用 (本番環境) においては、セキュリティと運用効率の以下の観点から、MDM (Intune/Jamf等) や ADCS (Active Directory 証明書サービス) が提供する「証明書の自動登録 (Enrollment) 機能」の活用を強く推奨します。
◼︎ 秘密鍵のハードウェア保護 (TPM / Secure Enclave):
MDMやADCSの自動登録機能を利用すると、秘密鍵はデバイスのセキュリティチップ (TPM や Secure Enclave) 内で直接生成され、その外に出ることなく格納されます。これにより、OSの管理者権限であっても物理的に抽出 (エクスポート) 不可能な状態を実現し、私物PCへの流用や盗難リスクを封じ込めます。
◼︎ 配布プロセスの安全性:
秘密鍵の生データ (PFXファイル)がネットワークを流れたり、管理者のPCに一時保存されたりすることがありません。「デバイスが自ら鍵を生成し、証明書を要求する」 仕組みのため、配布過程での紛失や漏洩リスクをゼロにできます。
◼︎ 運用ライフサイクルの自動化:
100台、1,000台といった大規模環境への一斉配布に加え、有効期限に伴う更新作業もユーザーや管理者の手を介さず全自動化が可能です。
※※※※※※※※※※※※※※※※※※※※※※
4. Okta Device Trustの設定
では、実際に設定していきましょう。
以降は「参考資料A」を使って生成した証明書を利用する前提で説明していきます。
4.1. デバイス統合の設定
まずは、デバイス統合の設定が必要です。
「セキュリティ」→「デバイス統合」→「認証局」タブで、「認証局を追加」をクリックします。
「ファイルの参照」をクリックして、クライアント証明書を発行した認証局の証明書ファイルを選択してください。
(「参考資料A」では、中間認証局の「interCAcrt.pem」が該当します。)
認証局の証明書ファイルが選択された状態です。「閉じる」をクリックします。
以下のような状態になります。
4.2. 認証ポリシーの設定
次に、認証ポリシーの設定を行います。
本ブログ記事では、動作確認にはOkta Dashboardを使うことにしますので、その認証ポリシーのルールを変更します。
現在、以下の2つのルールが設定されており、2つ目のキャッチオールルールは「拒否」にしています。
1つ目のルールで、「アクション」→「編集」をクリックします。
Okta Device Trustは、以下の「デバイス状態」を「登録済み」に変更して表示された、「デバイス管理」の「管理対象」を選択することで有効になります。
Okta Device Trustは、以下の「デバイス状態」を「登録済み」に変更して表示された、「デバイス管理」の「管理対象」を選択することで有効になります。
「Okta Verify - FastPass」が認証方法に存在していると、Okta Device Trustがいつ発生したのかが分かりづらい (＝自動的にユーザー認証まで進んでしまう) ので、外しておきましょう。
(これはあくまで、今回の動作検証を目的とした設定です。)
「認証方法」の「特定の認証方法を許可しない」を選択して、下図のように直下のフォームに「Okta Verify - FastPass」を選択して、認証方法に「パスワード」と「スマートカードAuthenticator」だけが残るようにしてください。
「保存」をクリックします。
5. 動作確認
設定が完了したので、動作を確認してみましょう。
前回の記事 (第12回) と同様に、本記事でも asaku.akawa@atko.email でログインすることにします。
前回記事のPIV/CACの設定は、そのまま設定されている前提で進めます。
5.1. 動作確認のための下準備
動作確認の前に、下準備をしておきます。
asaku.akawaに対して、一旦すでに登録されているAuthenticatorをリセットして、パスワードだけでログインできる状態にします。(今回の動作確認に限った話ですが、Okta Verifyインストール時に少々邪魔になるので。)
(この環境では、第12回で使ったスマートカードAuthenticatorが存在していたので、これをリセットします。)
Windowsデバイスに移動します。
Windowsデバイスのクライアント証明書は、一旦、前回のものが残っていれば削除して、空の状態にしてください。
WebブラウザでOktaへアクセスして、asaku.akawa@atko.emailでログインを試みると、Okta Verifyが要求されます。
このWindowsデバイス環境には、現時点ではOkta Verifyはインストールされていないので、「ここにダウンロード」
ダウンロードしたexeファイルを実行して、Okta Verifyのインストールを行います。
インストールが終わったら、ブラウザ画面の「Okta Verifyを開く」をクリックします。
Okta Verifyの設定画面が表示されますので、「はじめに」をクリックし、「次へ」をクリックします。
Okta VerifyをAuthenticatorとして登録するためには認証が必要です。
(これは、「Okta Device Trustが認証を要求しているわけではない」という点にご留意ください。)
現在、asaku.akawa@atko.emailのAuthenticatorはパスワードだけですので、パスワードを入力して、「確認」をクリックします。
今回は検証ということもあり、Windows Helloは「スキップ」しました。(「有効化」しても問題ありません。)
右画面のように、asaku.akawa@atko.emailがOkta Verifyに登録されます。
Webブラウザ画面に戻ると、下記のように「リソースの所有者または認証サーバーは要求を拒否しました。」という画面になると思います。
これは、クライアント証明書が存在していないためです。
下準備は以上です。
5.2. 動作確認-A
では、動作を確認してみましょう。
Webブラウザを再起動して、もう一度Oktaにアクセスしてください。
今度は、即座に下記の画面に遷移すると思います。
Okta Device Trustが動作した結果、クライアント証明書がないのでエラーになっている ＝ Oktaが「このデバイスは信頼できる状況ではない」と判定している、ということです。
この動きからも、Okta Device Trustの判定時には、認証は行われていないことが分かると思います。
===== << Tips >> =====
ちなみにユーザー名 (asaku.akawa@atko.email) の入力フォームが表示されないのは、Okta Verifyが自動的にOktaにユーザー名を伝えているためです (Okta Verifyの便利機能の一つです) 。
===================
5.3. 動作確認-B
実験として、クライアント証明書には「asaku.akawa用ではない」もの、例えば「csaku.ckawa@atko.email」をインポートしてみてください。
Webブラウザを再起動して、もう一度Oktaにアクセスしてください。
「動作確認-A」のときとは状況が変わりましたね。
これは、インポートしたこのクライアント証明書でOkta Device Trustを通過したことを示しています。
ここで注目いただきたいのは、Oktaへアクセスしているユーザーは「asaku.akawa@atko.email」ですが、クライアント証明書内のCommon Name (CN) やSubject Alternative Name (SAN) は「csaku.ckawa@atko.email」であっても、Okta Device Trustは通過する、という点です。
要するに、Okta Device Trustはクライアント証明書のCNやSANは問わない＝Oktaに登録した認証局の証明書で検証が成功するクライアント証明書であればよい、ということです。
ちなみに以下の認証画面は、Okta Device Trustが要求している認証ではなく、スマートカードAuthenticatorを登録するための認証です。どちらを選択してもよいですが、ここではパスワードを選択します。
パスワードを入力して「確認」をクリックします。
続いて、(Okta Verifyが登録済みなので) FastPass認証も行われます。「はい、私です」をクリックします。
スマートカードAuthenticatorの「セットアップ」をクリックします。
現在選択できるのは、csaku.ckawa@atko.emailのクライアント証明書だけなので、それを選択します。
スマートカードAuthenticator (PIV/CAC) の「認証」の場合は、Okta Device Trustと違って、CNやSANをチェックするので、csaku.ckawa@atko.emailではエラーになります。
Authenticatorの登録はエラーになりましたが、Okta上では「デバイス登録」は行われ、さらに「管理対象」となっている＝「Okta Device Trustが成功した」というステータスになっていることが分かります。
5.4. 動作確認-C
今度は、「asaku.akawa@atko.email」のクライアント証明書もインポートしてください。
Oktaからログアウトし、Webブラウザを再起動して、もう一度Oktaにアクセスしてください。
下記の画面までは「動作確認-B」と同様のステップを実施してください。
今度は、「asaku.akawa@atko.email」のクライアント証明書が選択できるので、それを選択して「OK」をクリックしてください。
認証が成功し、Okta Dashboard画面が表示されるはずです。
5.5. 動作確認-D
今度は、「asaku.akawa@atko.email」のクライアント証明書だけ残して、他は削除してください。
Oktaからログアウトし、Webブラウザを再起動して、もう一度Oktaにアクセスしてください。
今度は、「asaku.akawa@atko.email」のクライアント証明書だけが表示されますので、それを選択します。
結果、「動作確認-C」と同様に、認証が成功し、Okta Dashboard画面が表示されるはずです。
現在のOktaの設定では、Okta Device Trustの設定にも、PIV/CACの設定にも、同じ認証局の証明書を適用しているので、1つのクライアント証明書でどちらも成立します。
Oktaの設定で、Okta Device TrustとPIV/CACそれぞれで異なる認証局の証明書を適用するならば、クライアントには、それぞれの認証局から発行されたクライアント証明書 (＝2つ) のインポートが必要になります。
===== << Tips >> =====
Okta Device Trust用のクライアント証明書は、デバイス毎に一つずつユニークなものを発行してください。
「Okta Device Trustは、CNやSANがチェックされないのなら、一つのクライアント証明書を複数の端末にコピーしちゃえばいいじゃん。」と思ってしまうかもしれませんが、そのようなことはできない仕様になっています。
Okta内部では、各デバイスが持つID (deviceId) とクライアント証明書を紐付けて管理する仕様になっているので、別のデバイス (別のdeviceId) が同じクライアント証明書をOktaに送ってきたら、エラーになります。
そのことについては、管理証明に関するよくある質問 の「Oktaでは、複数のデスクトップデバイスへの証明書のコピーをどのように防止していますか？」に記載されています。
===================
6. まとめ
本ブログ記事では、Okta Device Trustについて解説しました。
「会社で管理されたデバイスだけに、会社リソースへのアクセスを許可したい」というニーズは根強く存在しますので、そのようなご要件の場合には、このOkta Device Trustの機能のご利用をご検討ください。
頭の中では混同しやすいOkta Device Trustとクライアント証明書認証 (PIV/CAC) ですが、「なるほど、役割が異なるんだな」ということが本ブログ記事を通じてすっきりとご理解頂けていれば幸いに思います。
==========
Okta Workforce Identityでは、認証の強化だけに留まらず、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しています。(日本語でのトレーニングもご用意しています。)
このトレーニングは全体像を体系的にご理解頂ける内容となっていますので、是非ともご活用ください。
