Okta Identity Engineを採用するための4つのベストプラクティス
このブログはこちらの英語ブログ（2024年4月1日公開）の翻訳、大野 克之によるレビューです。
今こそ、Okta Identity Engine（OIE）へのアップグレードに最適なタイミングです。セルフサービスのアップグレードプロセスは十分に整備されたものとなっており、お客様のOrgのアップグレードの成功を確実にサポートします。実際、多くのアップグレードはわずか数分で完了します。
すでにOIEをご利用中であれば、下記の３にスキップして、セキュリティ態勢を強化する方法を学びましょう。
OIEにアップグレードすべき理由
アイデンティティの最新のイノベーションへのアクセスに関して、OIEは最も多くのオプションを提供する無料のプラットフォームアップグレードです。OIEは、新しいポリシーフレームワーク、セキュリティの強化、ユーザーエクスペリエンスの向上を提供します。OIEの一般的なユースケースには、パスワードレスソリューション、高度なデバイスコンテキスト、ゼロトラストイニシアチブのサポートなどがあります。さらに、OIEは、Okta Desktop Access、特権アカウントへのパスワードレスアクセス、Okta AIなどの新しい機能を利用可能にします。
ここでは、OIEへのアップグレードを成功させるための4つのベストプラクティスをご紹介します。
1. 準備を整え、計画を立てる
Oktaは、OIEのアップグレードプロセスに関する豊富な情報を提供しています。この情報をしっかり理解しましょう。まずは、「De-Mystifying the Upgrade」ウェビナーから始めると良いでしょう。アップグレードプロセスで何を期待できるかについて、豊富なヒントや洞察を得ることができます。機能の変更を確認し、アップグレードFAQにも目を通してください。
次に、変更管理の計画を立てます。エンドユーザーに対して、アップグレードのタイミング、変更点、変更完了後の問題報告先を通知することが必要です。Oktaは、このプロセスをサポートするためのLaunch Kit for Okta Adminsを用意しています。Oktaの更新情報をチームに伝えるために役立つテンプレートやリソースが含まれていますので、ぜひチェックしてください。
2. 最初にPreviewでアップグレードしてテストする
次にテストします。有償のOkta Preview Sandbox環境をお持ちの場合は、まずPreviewですべてをテストする必要があります。アップグレードプロセスを段階的に進めていき、本番環境のOrgがどのようになるかを現実的に理解できるようにするため、プレビュー環境のOrgの構成が本番環境のOrgと同じであることを確認します。
Okta Previewでのアップグレード準備では、Classicのエクスペリエンスを記録します。アップグレード後に、OIEでのエクスペリエンスが同じであることを確認します（結果を追跡するための包括的なスプレッドシートとして、このUpgrade Test Matrixを参照してください）。Okta Previewですべてのユースケースをテストし、OIEでのエクスペリエンスを確認したら、本番環境に移行する準備が整います。
（備考：プレビュー環境のOrgをすでにアップグレードしている場合は、テストアップグレードを実行するための新しいOkta PreviewのOrgをプロビジョニングできるかどうか、アカウントチームにお問い合わせください。）
ここで重要なことですが、アップグレード前や直後にポリシー変更を行うことは推奨されません。このプロセスの目標は、ダウンタイムを起こさず、ユーザーへの影響を最小限に抑えて、ClassicからOIEにOrgをアップグレードすることです。アップグレードにポリシーの移行を任せ、その後にIdentity Engineでアップグレードをテストします。
すべてが期待どおりに機能することを確認したら、新機能の使用を開始できます。
3. OIEを活用してセキュリティポスチャを強化する
アップグレード後の状態が安定したら、セキュリティポスチャを再評価します。アプリのサインオンポリシーが、OIEでは認証ポリシーと呼ばれるようになりました。すべてのアプリに1つずつポリシーがありますが、今では1つのポリシーを複数のアプリで共有できるようになっています。
ポリシーは、次のルール基準によって評価されます。
- アイデンティティのコンテキスト（グループメンバーシップ）
- デバイスのコンテキスト（デバイスが既知か、登録済みか、管理されているか）
- デバイスのポスチャ（デバイスの健全性）
- ネットワークのコンテキスト（要求の発信元）
- 過去のユーザーの行動パターン
OIEでは、認証ポリシーがさらに強化されて柔軟性が高くなり、リソースの機密度に応じて認証要件を微調整できるようになりました。（Orgにアプリごとのポリシーがある場合、またはデフォルトのポリシーを使用している場合は、アップグレード中にOktaがポリシーをマージします。）
Orgのアプリケーションを保証レベル（低、中、高）に基づいて、慎重にグループ化します。（保証レベルの詳細についてはこちら、NISTの公式な要件についてはこちらをご覧ください。）リスク/コンプライアンスチームを巻き込んで、各レベルを決定することをお勧めします。各グループが特定の認証ポリシーを共有することも可能ですし、これらのグループを活用してエクスペリエンスをきめ細かく調整することも可能です。
ユーザーの利便性とセキュリティを両立させる認証ポリシーの実装例について：Setting the Right Levels of Assurance for Zero Trust
4. 新しいOIE機能を調べる
ここからが面白い部分です。OIEには、前述の共有可能で柔軟なアプリポリシー、より深いデバイスコンテキスト、新しいリカバリフロー、FastPassといった強力な新機能が満載です。
FastPassは多くのビジネスにとってゲームチェンジャーとなっています。フィッシング耐性のあるパスワードレス認証は、アイデンティティとアクセス管理でOktaが追求し続けているバランス、つまりシームレスなユーザーエクスペリエンスと適切なレベルのセキュリティの両立を実現します。
FastPassとOIEの新しい認証ポリシーの柔軟性についての詳細は、「Going Password-less in OIE」ウェビナーで確認できます。
FastPassは、OIEのデバイス拡張機能と組み合わせることで、さらに強力でシームレスになります。ユーザーが最初にログインした瞬間から評価を開始し、ユーザーが新しいアプリケーションを開くたびにバックグラウンドで監視を続けます。これにより、デバイスが変更されていないことを確認した上で、ダウンストリームアプリケーションへのアクセスを許可します。
「Deep Dive on Devices」ウェビナーで、OIEの強化されたデバイス機能に関する詳細をご確認ください。
Okta Identity Engineのメリット
Okta Identity Engineは、ビジネスにどのようなメリットをもたらすでしょうか。まず、生産性の向上に役立ちます。また、ユーザーエクスペリエンスの改善やセキュリティの強化にも貢献します。何よりも素晴らしいのは、これらの新機能を追加費用なしでOkta orgに利用できるようになっていることです。今すぐ始めましょう。
本資料および本資料に含まれる推奨事項は、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言ではありません。本資料は、一般的な情報提供のみを目的としており、最新のセキュリティ、プライバシー、法律の動向、また関連する問題をすべて反映していないことがあります。本資料の利用者は、自身の責任において、自身の弁護士またはその他の専門アドバイザーから法律、セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本書に記載された推奨事項に依存すべきではありません。本資料に記載された推奨事項を実施した結果生じるいかなる損失または損害に対しても、Oktaは責任を負いません。Oktaは、これらの資料の内容に関して、いかなる表明、保証、またはその他の保証も行いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsをご覧ください。
以上の内容は、原文（英語）の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。
