Okta Identity Engine（OIE） にアップグレードするのに最適な時期です。 セルフサービスアップグレードプロセス は成熟しており、組織のアップグレードが確実に成功するように支援します。 実際、ほとんどのアップグレードは数分で完了します。
すでにOIEをお使いですか？ セキュリティ体制を強化する方法については、No. 3「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ですべてをテストする必要があります。アップグレードプロセスを段階的に進めていき、本番orgがどのようになるかを現実的に理解できるようにするため、Preview orgの構成が本番のorgと同じであることを確認します。
Okta Previewでのアップグレード準備では、クラシックのエクスペリエンスを記録します。アップグレード後に、OIEでのエクスペリエンスが同じであることを確認します。（結果を追跡するための包括的なスプレッドシートとして、このUpgrade Test Matrixを参照してください。）Okta Previewですべてのユースケースをテストし、OIEでのエクスペリエンスを確認したら、本番環境に移行する準備が整います。
（備考：Preview orgをすでにアップグレードしている場合は、テストアップグレードを実行するための新しいOkta Preview orgをプロビジョニングできるかどうか、アカウントチームにお問い合わせください。）
ここで重要なことですが、アップグレード前や直後にポリシー変更を行うことは推奨されません。このプロセスの目標は、ダウンタイムを起こさず、ユーザーへの影響を最小限に抑えて、クラシックから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組織で追加費用なしで利用できます。今すぐ始めましょう。
本資料および本資料に含まれる推奨事項は、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言ではありません。本資料は、一般的な情報提供のみを目的としており、最新のセキュリティ、プライバシー、法律の動向、また関連する問題をすべて反映しているわけではありません。本資料の利用者は、自身の責任において、自身の弁護士またはその他の専門アドバイザーから法律、セキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本資料に記載された推奨事項に依存すべきではありません。本資料に記載された推奨事項を実施した結果生じるいかなる損失または損害に対しても、Oktaは一切の責任を負いません。Oktaは、これらの資料の内容に関して、いかなる表明、保証、またはその他の保証も行いません。お客様に対するOktaの契約上の保証に関する情報は、okta.com/agreementsをご覧ください。
