初めてのOkta Workforce Identity Cloud (WIC) [第3回] 「Hardware Protected」って何だ？
本記事では、Okta Workforce Identity Cloud (以降、Okta WIC) での「Hardware Protected (ハードウェア保護)」機能について解説します。
Security > Authentication Policiesで、Rule内のTHEN以下の設定を見ると「Hardware Protected」というチェックボックスがありますが「これって何？有効にした方がいいの？」と思っている人も少なからずいらっしゃると思います。
結論から言うと、FastPassが使える状況ならば、これは「有効にした方が良い」です。
しかし、これが何をするものなのかを理解しておかないと、Okta WICの管理者は「この設定のせいで、ユーザーの誰かが 『つながらないぞ、コノヤロー！ 』 とか言い出したら嫌だな。。。」とか考えてしまい、有効にすることを躊躇する人もいると思います。
そこで本ブログ記事では、この「Hardware Protected (ハードウェア保護)」について解説します。
以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。
- 初めてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築
- 初めてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く
- 初めてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く
Hardware Protected (ハードウェア保護) とは？
Hardware Protected (ハードウェア保護) とは、Microsoft Windowsの場合だとTPM (Trusted Platform Module)、Apple製品 (Mac、 iPhone 等) の場合だとSecure Enclave と呼ばれるものが該当します。
TPMやSecure Enclaveは、認証に使う秘密鍵などの機密データをハードウェアで保護し、攻撃者がデータにアクセスしたり、データを改ざんしたりするのを防ぐためのものです。
TPMやSecure Enclaveの詳しい解説は各メーカーの情報をご参照いただくとして、ここではWindowsのTPMを例にして、簡単なイメージをお伝えします。
まずは、TPMがない場合です。
こちらのブログ記事の「『FastPass』と『生体』認証の話」 の章で、FastPassは秘密鍵と公開鍵を使った認証を行っていることを解説しました。
なので、FastPass認証を行うには、パソコンの中のどこかに秘密鍵を保管しておかなくてはなりません。
TPMが存在しない場合、秘密鍵はHDDやSSDなどのストレージ内に保管することになります。
仮にストレージが暗号化されているとしても、CPUで暗号処理や署名処理を行うためには、秘密鍵を一旦ストレージからメモリに読み出す必要があります。
攻撃者は、Windowsパソコンにマルウェアを仕込んでメモリダンプを行ったり、サイドチャネル攻撃を行ったりして、メモリ上の秘密鍵を盗み出すことができてしまうかもしれません。
攻撃者は、秘密鍵さえ入手できれば、公開鍵暗号を用いた認証を突破できてしまう可能性は格段に上がるので、この状況はかなりよろしくありません。
次に、TPMがある場合です。
秘密鍵はストレージではなくTPM内に保管され、そこから出ることはありません。
暗号/署名処理が必要な場合にはTPMに対して要求し、TPMが処理を行い、TPMはその結果だけを返答します。
またTPMは「耐タンパ性」に優れた機構を持っているので、容易に秘密鍵を取り出すことができないようになっています。
「耐タンパ性」とは、 内部情報を不正に読み取られる・改ざんされることに対する耐性のことです。
Secure Enclaveの場合も同様のイメージです。
このように、TPMやSecure Enclave＝Hardware Protected (ハードウェア保護) の機能を持つデバイスの方がより安全なので、Okta WICでは、それらを使って秘密鍵が保護されているかどうかを認証時に確認できるようになっています。
Hardware Protectedの動作確認
上記を踏まえて、以降、Hardware Protectedの動作を確認してみたいと思います。
TPMを持たないデバイスの準備
TPMやSecure Enclaveが有効なデバイスだと、Hardware Protectedを無効にした時と有効にした時の違いが分からないので、本ブログ記事では、「TPMが無効なWindows11」を使います。
===== << Tips >> =====
最近は、TPMやSecure Enclaveを持たない (または無効な) デバイスを用意するのが難しくなりました。
Windows 11からは、TPM (TPM2.0) を持たないハードウェアには基本的にはOSをインストールできなくなり、OSインストール後に、OS側からの設定によるTPMの無効化もハードルが高そうです。
また、最近のApple製品はほぼSecure Enclaveを持っており、OSの設定で無効化する方法も見当たりませんでした。
一方、Windows 10であればTPMを無効化できるような情報がありましたので、もしWindows10デバイスをお持ちであれば、動作確認にはそちらをご利用になられるのも一つの手段かと思います。
私はWindows 10環境を準備できなかったので、やや強引なのですが、「Parallels® Desktop 18 for Mac」を用いて、Windows 11仮想マシンのハードウェア設定からTPMチップを削除して、TPMを持たない状態にして起動しました。
Windows 11を起動した後、「設定」 > 「プライバシーとセキュリティ」 > 「Windowsセキュリティ」 > 「デバイスセキュリティ」で、TPMの有無を確認できます。
TPMが有効なWindows11起動後の状態:
TPMが無効なWindows11起動後の状態:
(＝セキュリティ プロセッサとセキュアブートが存在しない)
(上画面の「セキュリティ プロセッサの詳細」をクリックして表示された画面↓)
以降、この「TPMが無効なWindows11」を用いて、動作確認を行っていきます。
================
Authentication PolicyのRuleで、一旦Hardware ProtectedをOFFにする
第1回目と第2回目のブログ記事と同様に、RSA SAML Test Service Providerアプリを使って動作を確認することにします。
現在、Security > Authentication Policies で表示されるポリシーのうち、「Any two factors」がRSA SAML Test Service Providerアプリと紐づいています。
Any two factors > Catch-all Rule の Actionsをクリックして表示されたEditをクリックします。
表示された以下の画面で、THENの下の「 [AND] Possession factor constraints are」で、以下のようにHardware Protectedを含む全てのチェックボックスをOFFにして、Saveします。
Csaku Ckawaさんをパスワードだけで登録しておく
新規ユーザーで動作確認することにします。
第1回目のブログ記事のAsaku Akawaさんをパスワードだけで登録したのと同じ方法で、以下2点を行っておきます。
(1) Csaku Ckawaさん ([email protected]) を新規にパスワードだけで登録。
(2) RSA SAML Test Service Providerアプリケーションを、Csaku Ckawaさんに割り当て。
Csaku CkawaさんでOkta Verifyによるデバイス登録を行う
TPMが無効なデバイス (本ブログ記事では「TPMが無効なWindows11」) にOkta Verifyをインストールし、Csaku Ckawaさん ([email protected]) でデバイス登録を行います。
(方法は第2回目のブログ記事の「FastPassのデバイス登録から認証まで」の章をご参照ください。)
その際、Windows Helloによる認証 (顔、指紋、PIN番号のいずれか) も設定しておきます。
本ブログ記事では、テスト環境の都合上 (顔や指紋が使えないので)、PIN番号を使います。
===== << Tips >> =====
こちらの「AND［Possession factor constraints are（所有要素の制約）］」の解説には、以下の記載があります。
注：デフォルトでは、Okta Verifyはデバイスの安全なハードウェア（WindowsおよびAndroidデバイスの場合はTrusted Platform Module（TPM）、macOSおよびiOSデバイスの場合は安全なエンクレーブ）にOkta Verifyキーを保存しようとします。安全なハードウェアが利用できない場合は、ソフトウェアストレージが使用されます。
ということですので、この動作確認用に用意した「TPMが無効なWindows11」の場合、TPMではなくストレージにOkta Verifyキー ＝ 秘密鍵が保存される、ということになります。
================
デバイス登録した端末で認証(1) 〜Hardware Protected設定「なし」の状態〜
RSA SAML Test Service Providerアプリに、SP-Initiatedでアクセスします。
SP-Initiatedは、WICトライアル環境構築時にも行った、RSA SAML Test Service Providerアプリ側に表示された、以下のようなURLに最初にアクセスするパターンです。
表示された画面で「Okta FastPassでサインインする」をクリックします。
次の画面で「Okta FastPassを使用する」の「選択」をクリックします。
次に自身が選んだWindows Helloの方式 (顔、指紋、PIN番号のいずれか) での認証が要求されます。
本ブログ記事のテスト環境ではPIN番号です。
Okta WICのAuthentication PolicyでHardware Protected機能を無効にしているので、認証が完了して、RSA Test Service Providerにアクセスできます。
デバイス登録した端末で認証(2) 〜Hardware Protected設定「あり」の状態〜
今度は、Hardware Protected設定を有効にして認証してみます。
結果を先に伝えると、ご想像通り、このデバイスはTPMを持っていないので認証は失敗します。
Security > Authentication Policies > Any two factors > Catch-all RuleのActionsでEditをクリックします。
表示された以下の画面で、THENの下の「[AND] Possession factor constraints are」で、「Hardware Protected」のチェックボックスをONにしてSaveします。
===== << Tips >> =====
「Hardware Protected」を有効にすると、その下の「Exclude phone and email authentication」も自動的に有効になります。
Phone (電話) もemail (電子メール) も、ハードウェア保護の機能を持っていないので、これらの「所持」要素は自動的に除外されるようになっています。
================
先の動作確認と同様に、SP-InitiatedでRSA SAML Test Service Providerアプリにアクセスしてみます。
結果、TPMを持っていないデバイスからのアクセスなので、以下のように拒否されます。
参考: Okta Admin ConsoleからデバイスのTPM有無を確認
デバイスがTPMやSecure Enclaveを使える状態にあるかどうかは、Okta Admin Consoleから確認できます。
Directory > Devices で表示されたデバイスのリストから、確認したいデバイスを選択します。
上記の動作確認に利用した「TPMが無効なWindows11」(=名称: WIN11PRO2) の「Trusted Platform Module」は「Not in Use」になっています。
まとめ
本ブログでは、Hardware Protected (ハードウェア保護) 機能についてご紹介しました。
この機能によって、TPMやSecure Enclaveによるハードウェア保護機能を持たないユーザーからのアクセスは拒否できるようになります。
もはや、最近ではTPMやSecure Enclaveを持たないデバイスを探す方が難しくなってきましたが、それでもまだそれらを持たないデバイス (例えば、本記事執筆時点ではメーカーサポート中であるWindows 10デバイス) も存在します。
なので、機微な情報を扱うSaaSアプリケーションの認証には、この機能を有効にして、秘密鍵を盗まれてしまう可能性の高いデバイスからのアクセスを排除しておくことが望ましいでしょう。
また、Okta WICでは、認証の強化だけでなく、管理者が行うユーザーの登録/変更/削除に関わる業務の自動化や、人事管理システムや既設ディレクトリなどとの柔軟な連携も可能です。
Oktaでは、これらの機能を体感頂くことができる「Okta Essentials」トレーニングをご用意しております。(日本語でのトレーニングもご用意しております。)
このトレーニングは全体像を体系的にご理解頂ける内容となっておりますので、是非ともご活用ください。
Follow 岸本 卓也
