こんにちは〜。たつみんです。
今日はOktaの新しいプラットフォームであるOkta Identity Engine（以下OIE）について概要をサクっとご紹介いたします。
OIEに対してこれまでのOkta環境はOkta Classic Engineと呼ばれるようになりました。
2021年11月18日現在、OIEは新規発行されるテナントに限り適用されます。これまでのOkta Classic EngineからOIEへ移行する時期や方法については別途Okta社からのアナウンスをお待ちください。
それではOIEで追加された機能や変更点について解説していきます。
アプリケーション用のサインオンポリシー
OIEではAuthentication policiesという項目でアプリケーション用のサインオンポリシーを定義し、管理することが可能となりました。
これまでのClassic Engine環境では、グループを指定しOktaログインへのMFAの設定を強制したりすることはできましたが、アプリケーション単位では行うことができませんでした。
OIEではアプリケーションの重要度に応じて柔軟な設定を行うことができます。
FastPass（パスワードレス認証）
デスクトップアプリ版のOkta Verifyアプリが新たに登場します。Okta Verifyにあらかじめアカウントを登録しておくことでOktaへのサインオン時にパスワードレスで認証を行うことができます。
スマートフォン版のOkta VerifyもOIE環境であれば同様のパスワードレスでの認証が可能となります。
MDMから配布された証明書によるDevice Trust
Intune/Jamf ProなどのMDMソリューションと連携し、証明書を配布することでPC/Mac/Android/iOSをOktaにマネージドデバイスとして登録することが可能になりました。
アプリケーション毎のサインオンポリシーと組み合わせることでマネージドデバイスのみをアクセス可能とする設定が行えます。
EDR連携によるアクセスの許可/不許可の制御
EDR製品による端末状態をOkta Verifyを通じてOktaへ連携しアクセス制御に利用できます。
連携できるEDR製品がまだまだ少ないのですが端末状態がポリシーに満たない場合にアクセスさせないことでセキュリティを強化することができます。
Device Assuranceによるデバイス状態によるアクセス制御
MDM配下にないデバイスであってもOkta Verifyアプリを通じて、スクリーンロックがされているか？ディスクの暗号化がされているか？などの情報を収集することでアクセス制御に活用することができます。
これによりBYOD端末についてもDevice Trustほどではないにしろセキュアな端末からのみアクセスを可能とする設定が行えます。
詳細については以下のブログ記事をご確認ください。
まとめ
OIEの登場により柔軟なサイオンポリシーが構築できるため、利便性の向上とセキュリティ担保を同時に行いやすくなったと思います。
例えば、SlackはBYOD端末からのアクセスを許可するが、顧客情報が登録されているSalesforceについてはデバイストラスト済みの端末、なおかつEDRによる端末状態のチェックを行なって問題ない場合のみアクセスさせるなどができます。
これを実現するにはアプリケーション毎のサインオンポリシーを定義する必要があるため、まずは新規発行テナントからOIEを適用していくものだと想像しています。
簡単ではありますがOIEの特徴について説明をさせていただきました。今回ご紹介した機能の設定方法などは別の記事で詳細をご案内いたします。
今後はOIEならではの機能を紹介するブログはOkta Identity Engineというタグをつけますので目印にしてください。もちろんIdentity Engine、Classci Engineのどちらにも適用されるような話題の場合は単にOktaというタグをつけますのでこちらもお見逃しなく！
それではまた別の記事でお会いしましょう?
