はじめに
こんにちは、Identity チームのすかんくです。最近エリミネーター400SEを購入しました。
「corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2024」16日目の記事（以降 “まゆかずさん記事” と表記）を拝見して、逆バージョンを書いたら面白そうだと思ったので、今回はOktaについて語ってみます。
本記事を読まれる前に、是非まゆかずさん記事もご覧ください。
前書き
自分はキャリアスタートからMicrosoft製品を触れる機会が多く、縁あって2020年からID/デバイス領域でMicrosoft MVPを受賞いただいております。
一方で弊社（クラウドネイティブ）はベストオブリードなスタンスですので、Microsoft製品が得意だからと言ってそれだけを仕事しているというわけではなく、日頃からOktaやその他IDaaSについても触れる機会が多くあります。
そんな背景と経験の中で感じられた、Entra IDと比較した際のOktaについて語ってみようというのが本記事の趣旨となります。
Okta の良い点シリーズ
ここではOktaが他のIDaaSと比べ優れていると個人的に思っている内容を紹介しつつ、Entra IDとの差異について見ていきます。
ディレクトリとしての柔軟性
OktaがEntra IDや他のIDaaSと比較して優位にある特性として、ディレクトリの柔軟性が挙げられると思います。
インポート
人事システムや既存のディレクトリからユーザー情報をインポートしたいと考えた際に、OktaではオンプレAD、LDAP、CSV、人事ドリブンといった複数のディレクトリソースに対応しているため、クラウドサービスメインで利用している企業から、歴史的にオンプレミス資産を多く抱える企業まで、様々なケースに対応することが可能です。
プロファイルの優先度
Oktaでは複数のディレクトリからインポートすることが可能であり、かつ重複属性に優先度をつけることが出来ます。
例として、歴史的な経緯としてADをメインのディレクトリとして活用したいが、姓名情報は人事システム側でしかメンテナンスされていないといったケースでは、姓名情報だけを人事システム側のディレクトリソースを優先するといった調整が可能です。
Oktaではこういった柔軟性が各所に見られ、Entra IDでは実現できない複雑な要件に対応することが出来る点は非常に優れているなと感じます。
勿論、本来はアイデンティティライフサイクル自体を見直し、AD側の運用やユーザー発行管理に関する全体観を整えるべき話ではあるのですが、現実としては対応が難しいケースが多く、そういったシナリオでOktaは非常に刺さる製品だと考えます
変更内容の伝搬
次に挙げたいのはOkta上での変更内容を各リソースへ伝搬する際の体験面についてです。
まゆかずさん記事でもプロビジョニング周りについて触れられておりましたが、Entra IDでは通常40分ごとの定期的な同期スケジュールであるのに対し、Oktaは変更内容を検知して自動的に各アプリケーションに対してプロビジョニングタスクを実行してくれます。
また、グループルール（動的ルール）の再評価も即時実施されるため、その点についても利用体験としては良いものだなと感じます。
併せてOkta Workflowsについても触れておきたいと思います。Okta Workflowsではユーザー属性の変更をトリガーとすることが可能ですので、SCIM未対応のクラウドサービスを利用しているケースでもシームレスに連携することが可能です。
Entra IDでも似たような機能はありますが、追加アドオンとしてのサービス提供かつ機能的にも劣っている印象があるのに対し、Okta Workflowsは標準的なライセンスさえ購入していれば5フローまで無料で利用できるのが嬉しいですね。（結局足りなくなりますが）
付け加えて、システムログの反映が即時なのも嬉しいポイントです。Entra IDではサインインログや監査ログが即時表示されないため、検証やトラブル対応においてストレスを感じるポイントだったりします。
ラッピングされたデバイストラスト
Oktaの良い点として最後に挙げるのはデバイストラストについてです。ここで言うデバイストラストとは、組織が管理されている端末のみIDP側で認可を与える仕組みのことを言います。
要は管理端末であることを証明するIDP側の仕組みのことを指しますが、ここは各製品で様々な思想・アプローチが見られ選定において重要なファクターとなります。
Oktaのデバイストラストにおけるアプローチで優れている点として、Okta Verifyアプリが上手に “管理端末であることを証明する” の部分をラッピングしてくれている点だと考えています。
Okta 認証時に要求される証明書を MDM 等を通じて配布しておくだけで、後は Okta Verify が自動で証明書を検出してくれるという一連の認証の流れはユーザー体験の面で非常に優れていると感じます。
参考記事：
- 弊社ブログより「Okta Identity EngineでのDevice Trustを検証してみた」
- Okta 公式ドキュメントより「管理証明に関するよくある質問」
Entra ID との比較では、WindowsとmacOSというプラットフォームレベルでの対応範囲と、連携サービスの選択肢における幅が挙げられると思います。
まゆかずさん記事でも振られているように、Entra IDはかなりWindowsに特化したIDaaSとなっており、Oktaと認証体験・セキュリティ面で同レベルのデバイストラストを実現するためには、オンプレADやMicrosoft Intune(MDM)との連携が必須になってきます。
加えて、macOS での Face ID/Touch ID にも未対応ですので、どうしてもこの点で劣っている感は否めないと感じます。
Oktaはこういった難しい部分をOkta Verifyというアプリケーションを開発することで解消しているため、任意のデバイス管理ツールを用いること出来ることから、IDaaS以外のサービスにおける組織の選択肢の幅を広げるという点にも役立っていると思います。
その上でmacOS 上での認証体験も優れているのですから言うことなしですね。
Okta の少し言いたいことがあるシリーズ
ここではOktaを利用していて個人的にちょっと微妙だなと感じる部分についてご紹介しつつ、Entra IDとの差異について見ていきます。
ライセンス管理
まず言えるのはOktaでは現在有効なライセンス数や消費対象となっているユーザーリストをGUIで確認する手段がありません。
ライセンス消費対象となるユーザーステータスは公開されているので、各社で独自にレポーティング環境を用意する必要があります。
Entra IDと違ってライセンスをユーザーにアタッチするという概念が無いためというのはユーザー発行で楽できる一方、棚卸などの管理業務全般で見た際には不便だなと感じる機会が多くあります。
システムログ画面のUI/UX
次はOktaのシステムログに一言申します。
OktaのSystem Logでは、認証ログ（ユーザーログ）とシステムログ（監査ログ）が混在しており、例えばユーザーのアクティビティを追うためにユーザーIDでフィルタしても、システム操作のログが混ざってくるのが煩雑だなと感じることがあります。
これはEntra ID → Oktaで学んだ流れの影響が強く出ている部分かもしれませんが、素直にGUIレベルで分離している方が嬉しいなと思っています。
一方、ログ単体における情報量やフォーマットに関しては、Oktaの方が充実しており優れていると感じます。例えばEntra IDでは扱っていないIP Chainの情報が見れたりするのは、不正アクセスが疑われる調査を実施する上で有難かったりします。
ただしOktaのAuthentication PolicyとEntra IDの条件付きアクセス、認証ポリシーの判定結果を確認するシナリオではEntra IDに優位性があると感じます。
どのポリシーが適用対象なのか・その結果がどうなのかをひと目で確認できるのが有難いです。
Okta Expression Languageの煩雑さ
最後はOkta Expression Language（OEL）についてとなります。
1つの体系的な言語として括るには制約が多すぎると感じています。例えばグループルールにはRegex関数が使えなかったりと、機能とOELの組み合わせで発生する制約が非常に多く、
これはOELの公式ドキュメントに記載されている注意書き(Note:)の数を見ていただければ一目瞭然かと思います。
出来ることならば、OEL自体の再設計、もしくはOELの公式ドキュメントを機能レベルで整備していただいて、初めて触る方でも習熟しやすい環境を整えて欲しいなと感じます。
文句たらたらですが、それでもEntra IDの動的ルールと比べれば非常に高機能なのは間違いないです。（高機能なだけ制約が多いというのも理解できるが、もう少し整備して欲しいというのが本音）
まとめ
- Oktaの良い点（採択するだけの理由になり得る要素）
- ディレクトリとしての柔軟性が高く、様々な機能要件への対応が可能
- 変更内容の反映が即時かつ高機能で、シームレスな運用が可能
- Okta Verifyが非常によくできており、強固な認証方式をストレスフリーなユーザー体験と共に提供してくれる
- Oktaの悪い点（運用してみてストレスを感じる要素）
- ライセンス管理用のGUIが無いので、各自レポーティング機能の用意が必要
- ログは情報量が多く良いが、ユーザー/システムログが混在するため調査時に煩雑さを感じるかも
- Okta Expression Languageは高機能だがOktaの機能毎に制約事項が適用されるため、習熟コストが高い
おわりに
今回ご紹介したのは、極一部の機能を切り取った中でのOktaとEntra IDの違いとなります。
IDPの選定においては、（ベンダーが出してくる○×表に踊らされることなく）このような細かなコンテキストの違いを理解し、自社に対してどのような影響を与えてくれるのか適切に測ることが大切だと考えます。
弊社クラウドネイティブではそういったご支援もしておりますので、もしご興味あれば気軽にお問い合わせください。ではまた。
