こんにちは!たつみんです。
みなさんはOktaのリリースノートって読んでますか?
2022.08のリリースノートを読んでいたらDevice Assuranceという機能が気になったのでさっそく検証してみました。Device AssuranceはデバイスにインストールされたOkta Verifyアプリを通じてデバイスのOSバージョンや暗号化の有無などを確認して、アクセス制御に利用できる機能です。
設定方法
以下のドキュメントを参考に設定を行います。
Device Assurance Policiesの設定
Security配下にDevice Assurance Policiesという項目からAdd a policyをクリックします。

そうするとポリシー名の入力とOSプラットフォームを選択する画面が表示されます。

次にそれぞれのプラットフォームごとにどのような項目を設定できるかをご紹介します。
Androidを選択した場合

- Minimum Android version
最低限のOSバージョンをメジャーバージョンを指定するか、カスタマイズを選択しセキュリティパッチレベルまで指定することができます。 - Lock screen
スクリーンロックの設定が有効にされているか、さらに解除時に生体認証が有効化されているかを指定することができます。 - Disk encryption
ディスク暗号化がされているかを指定することができます。 - Hardware keystore
ハードウェア格納型キーストアをサポートしているかを指定することができます。 - Rooting
root化されていないかを指定することができます。
iOSを選択した場合

- Minimum iOS version
最低限のOSバージョンをメジャーバージョンを指定するか、カスタマイズを選択しセキュリティパッチレベルまで指定することができます。 - Lock screen
スクリーンロックの設定が有効にされているか、さらに解除時にTouch IDもしくはFace IDが有効化されているかを指定することができます。 - Jailbreak
Jailbreakがされていないかを指定することができます。
macOSを選択した場合

- Minimum macOS version
最低限のOSバージョンをメジャーバージョンを指定するか、カスタマイズを選択しセキュリティパッチレベルまで指定することができます。 - Lock screen
パスワード設定が有効化されているかを指定することができます。 - Disk encryption
内部ディスクとシステムディスクが暗号化がされているかを指定することができます。 - Secure Enclave
Secure Enclaveをサポートしているかを指定することができます。
Windowsを選択した場合

- Minimum Windows version
最低限のOSバージョンをメジャーバージョンを指定するか、カスタマイズを選択しセキュリティパッチレベルまで指定することができます。 - Lock screen
パスワード設定が有効化されているか、さらに解除時にWindows Helloが有効化されているかを指定することができます。 - Disk encryption
ディスク暗号化がされているかを指定することができます。 - Trusted Platform Module
TPMをサポートしているかを指定することができます。
Authentication policiesでの条件設定への活用
Device Assurance Policiesで作成したポリシーは下図のようにAuthentication policiesで条件として組み込むことができます。
まず、Device state isをRegisteredを選択すると、新たな条件項目としてDevice assurance policy isが表示されます。

Device assurance policy isをNo policyからAny of the following device assurance policiesを選択すると、先ほど作成したDevice assurance policyを複数選択することができます。

なお、Device assurance policy isをNo policyから変更した時点で、Device platform isは選択不可となります。これはDevice assurance policyを選択した時点でプラットフォームを選択した事と同じ意味を持つためです。

運用を考えたAuthentication policiesの設定例
以下のようなシナリオを想定した場合
- Windows端末およびMac端末はMDM配下にある会社支給端末のみからのアクセスとしたい
- iOS端末およびAndroid端末は個人端末からのアクセスを許容するが最低限のセキュリティレベルを担保したい
設定例

最上位のルールでは、プラットフォームがmacOSとWindowsで、Device state isがManagedである場合に1要素のみで認証を行う設定をしています。
2番目のルールではDevice Assuranceで作成したポリシー名がAndroid 12とiOS 15を指定し、条件に合致する場合に2要素で認証を行う設定をしています。
3番目のルールはデフォルトで用意されているCatch-all Ruleです。これはデフォルト設定からAccessをDeniedに変更し、アクセスを拒否する設定をしています。
これで個人端末のiOS端末やAndroid端末からOSバージョンの下限を指定したり、Jailbreakやroot化という企業データにアクセスするには望ましくない端末を除外することができます。
MDMでOS同じことをしようとすると…
実はOktaでDevice Trustをしていることが前提となりますが、Device Assuranceと同様の仕組みをMDM経由で構成プロファイルを制御することで実現できないかと検討したことがありました。
具体的には、IntuneおよびJamf Proで構成プロファイルを最低限のOSバージョンを条件とした動的グループで割り当てることを考えていました。ただこの方法には以下の懸念点がありました。
ラグの問題
IntuneもJamf Proもプロファイルの反映やインベントリ情報の更新が即時ではないためラグが発生します。それにより以下のようなことが発生するデメリットが大きすぎると判断していました。
- OSが古い状態となり、構成プロファイルが外れた後に、OSアップデートしても構成プロファイルがすぐに反映されないためユーザーの不満につながる懸念がある
- 逆に構成プロファイルが適用された端末がオフラインの状態が続くと実際には新しいOSバージョンがリリースされ、端末のOSが古い状態となっていてもMDMがインベントリを取得し、構成プロファイルの適用が外れるまでのラグによりアクセスできる状態となってしまう懸念がある
モバイルデバイスの問題
iOS端末およびAndroid端末についてはDevice Trust実現のためにマネジメントキーを埋め込んだOkta VerifyをMDMから配布することとなりますが、動的グループで制御を行うと以下のようなことが発生します。
- 動的グループの条件に合致しなくなるとモバイル端末内のOkta Verifyアプリが削除される
これはユーザーがOkta以外の認証情報をOkta Verifyに保存している場合や、条件が合致し再びOkta Verifyが配布された時に再セットアップを行う必要があるなど、ユーザーに対する影響が大きくなりすぎるという懸念がありました。
今回のOktaによるDevice AssuranceではMDMの介在なしにOkta Verifyアプリを利用するシンプルな構成で充実した条件を指定できることが非常に大きなメリットだと感じました。
こうだったらもっと嬉しい
Device Assurance Policiesでは下限のOSバージョンを細く指定ができますが、以下のようなポリシーをそれぞれ作成しても個別に判断されません。
- Minimum macOS versionでmacOS 12.5を指定
- Minimum macOS versionでmacOS 11.6を指定

上記のようなDevice Assurance Policiesを作成し、この両方をAuthentication policiesのRuleに条件として組み込んでもこれらをトータルで見た時の下限のバージョンであるmacOS 11.6以上であれば、macOS 12.3であっても条件に合致したとみなされます。
企業で利用する端末のメジャーバージョンが複数混在する環境というのはよくあるかと思います。その時に各メジャーバージョンの中でマイナーバージョンが最新化されていることを保証したいというニーズが多いのですが、現在のDevice Assurance Policiesでは実現できません。
2024.02.22追記
Dynamic OS version complianceがEarly Access(早期アクセス)として公開されたました。これにより上記のような複数のメジャーバージョンに対する最新のセキュリティパッチという条件を動的に指定することが可能となりました!
まとめ
Okta Verifyアプリを利用していれば基本的なデバイスセキュリティの状態を確認し、アクセス制御が行えるのは画期的だと思います。
MDMで制御しようとした時に懸念だった点も解消されたので、あとはOSバージョンの指定について、ブラッシュアップされるとかなり使える機能になると思います。
今後もOktaにどんな機能が追加されるかますます楽しみです!
次回はOktaのPolicyありすぎ問題についてのブログ記事を書きたいなと思っています。
それではまた〜?