セキュリティレポートに対するOktaの見解
2022年7月19日、あるセキュリティコンサルタント会社が、Oktaサービスの特定の機能のセキュリティに関連する主張をブログ記事で公開しました。ブログ記事の公開に先立ち、このセキュリティ調査会社はOktaに連絡し、調査結果の技術的な詳細を共有しました。弊社の徹底的な検証の結果、社内の製品チームおよびセキュリティチームは、指摘された懸念事項は脆弱性ではないことを確認しました。以下に、セキュリティに関するベストプラクティスの推奨事項を記載します。
私たちの目標は、お客様が必要とするあらゆるテクノロジーに確実に接続できるよう、お客様の要件や統合を考慮しながら、お客様をサポートすることです。解決しなければならない独自の課題を持つ多くのお客様を抱えているため、幅広い構成オプションをサポートしています。これらの設定オプションの中には、HTTPSの代わりにHTTPを有効にするなど、安全性が低いものもあります。また、移行シナリオ、システム統合、拡張性をサポートするために、クリアテキストの認証情報の使用を含む同期機能を提供し、お客様が複雑なユースケースを解決することを可能にしています。なお、保存されたクレデンシャルはすべて、お客様固有の暗号鍵を用いて暗号化されます。
Oktaのお客様の場合、何をすべきか
Oktaのお客様には、以下のベストプラクティスを推奨しています。お客様の特定の構成に照らし合わせてご検討ください。
- 常にHTTPSを使用して、データの安全な伝送を確保する。
- すべてのユーザーアカウントでMFAを有効にする。管理者アカウントのMFAは譲れないものであり、Oktaのデフォルトで有効になっています。Oktaでは、管理者だけでなく、すべてのユーザーが自分のアカウントでMFAを要求することを推奨しています。
- 管理者ロールの割り当てについてのアクセスレビューを定期的に実施し、管理者アクセスが許可された担当者に限定されていることを確認する。
- きめ細かい権限を付与するために、カスタム管理者ロールフレームワークを使用した委任管理シナリオの使用を検討する。
- 各Okta管理コンソールのログ記録プラットフォームであるOkta System Logに記録された管理者が行ったアクションを監視し、定期的にレビューする。
- Sync Password（パスワードの同期）機能が必要な場合のみ有効になっていることを確認する。この機能は、下流システムにパスワードをプッシュしてOktaと同期させる機能を提供するもので、相互運用性とハイブリッドID展開のための特別なケースでのみ使用されます。これは、Apps APIとRoles APIで自動化できます。
- Federated IDプロバイダを使用するお客様は、RegEx Filterを確認し、これが意図したユーザーのサブセットに認証を適切に制限していることを確認してください。
- Hub & Spoke アーキテクチャ（Org2Org とも呼ばれる）を使用しているお客様の場合は以下をご確認ください。
- 構成されているアイデンティティプロバイダを確認し、これらが信頼できるものであることを確認する。
- SpokeがHub内でユーザーを作成できるかどうかを制御する名前重複機能の使用を確認します。この機能をオフにするには、[既存ユーザーの属性を更新する]オプションを無効にします。
セキュリティへの継続的な取り組み
私たちは、製品の機能と性能を継続的に改善し、お客様、パートナー、セキュリティ研究者、さらには社員など、さまざまなグループからのフィードバックに基づいて、製品の継続的な強化の機会を探っています。
以下に、最近の製品への投資をいくつかご紹介しますが、これらは、より多様で堅牢なセキュリティ管理とより良いデフォルトを提供するための当社の取り組みを示すものです。
Okta Identity Engine
2022年3月、当社はOkta Identity Engine（OIE）を、すべての新規のお客様がデフォルトで利用できるようにしました。OIEには、最新の安全なアイデンティティとアクセス体験を構築するための以下のような主要機能が含まれています。
-
アプリレベルポリシー
- サインオンポリシーのデフォルト
- パスワードレスサインイン体験とデバイスコンテキスト
- 柔軟なアカウント復旧
1. アプリレベルポリシー
アプリレベルポリシーは、組織が業界で認められたデジタルアイデンティティのベストプラクティス（NISTの概要）に基づいて、アクセスのセキュリティ成果をモデル化できるようにする新しいポリシーフレームワークです。OIEは、認証方法を認証子に整理し、認証子の種類と具体的な特性を公開することで、管理者がアプリ認証のセキュリティ要件に合致した認証保証ポリシーを作成できるようにしています。
高いレベルでは、アプリレベルポリシーにより、管理者は以下のようにサインオンポリシーを設定することができます。
- FOR [指定されたアプリケーション]
- IF [特定のユーザーコンテキスト］
- THEN [特定の認証を適用]
IF + THEN のコンボは、特定の保証レベルを作成します。通常、一連の抽象的なレベル（低、中、高など）を定義し、アプリケーションの感度とセキュリティ要件に基づいて、これらのレベルにアプリケーションをマッピングすることが推奨されます。
要約すると、アプリレベルポリシーは、組織がアプリ単位でアクセスのセキュリティ結果をモデル化することを可能にする新しい最新のフレームワークです。認証機能の保証は、アプリレベルポリシーの基礎となるものです。アプリレベルポリシーの詳細なドキュメントはこちらでご覧いただけます。
2. サインオンポリシーのデフォルト
デフォルトで安全な監査の一環として、アカウント乗っ取りのリスクを高める一般的な誤設定に対処するため、サインインポリシーのエクスペリエンスをアップグレードしました。この取り組みの一環として、リスクの高いMFA構成が設定されたときに管理者に通知する新しいHealthInsightセキュリティタスクを提供しています。この機能に関する詳細なドキュメントはこちらでご覧いただけます。
APIはこちらからご覧いただけます： https://developer.okta.com/docs/reference/api/policy/#global-session-policy
3. パスワードレスサインイン体験とデバイスコンテキスト
Okta FastPassは、デバイスをまたいで仕事をするために必要なすべてのものにパスワードレス認証を可能にします。Okta FastPassの4つの主な利点は次のとおりです。
- 常にパスワードレスを実現：あらゆるデバイスや場所から、Oktaが管理するあらゆるアプリにパスワードレスで認証・ログイン。
- あらゆるデバイス管理ツールに対応：Active Directoryや特定のEMM（エンタープライズモビリティ管理）/MDM（モバイルデバイス管理）プロバイダに依存しないパスワードレスログイン。
- デバイスレベルの生体認証との組み合わせ：生体認証をサポートするデバイスでは、エンドツーエンド（ログインからアプリへのアクセスまで）でパスワードレス（生体認証でデバイスにログインし、Okta管理アプリにアクセスする際に追加のプロンプトが表示されない）。
- Device Trustをチェック：オプションで、Device TrustとOkta FastPassを組み合わせ、管理された準拠デバイスにのみパスワードレスを提供。
4. 柔軟なアカウント復旧
OIEにより、Oktaはエンドユーザーが認証情報をリセットまたは回復するために使用できる要素の選択肢を広げ、Okta Verify Pushを含めることができます。柔軟なアカウント復旧は、3つのサブ機能で構成されています。
- パスワードの変更
- パスワードのリセット（パスワードを忘れた場合）
- アカウントのロック解除（アカウントリカバリー）
Okta Verify Pushを柔軟なアカウント復旧に活用する場合、お客様はエンドユーザーに対して、2つの要素を使用してパスワードの変更またはリセット、ユーザーアカウントのロック解除を要求することができます。これにより、お客様は本質的に安全でないセキュリティ質問を使用せずに済むようになります。柔軟なアカウント復旧の設定方法に関する詳細なドキュメントは、こちらをご覧ください。
カスタム管理者ロール
今年初め、私たちは新しいカスタム管理者ロールフレームワークによって、委任管理シナリオのための重要な新しいプラットフォーム機能を一般に公開しました（GA）。この機能は、何千ものお客様に採用され、過剰な権限を持つ管理者の数を減らすのに役立っています。Oktaの製品チームは、この新機能を活用して、既存の製品機能によりきめ細かい権限を段階的に導入しています。例えば、最近、認証サーバやカスタマイズのための権限を追加しました。
管理者の役割と権限を簡単に監査できるレポートを作成し、過剰な権限を持つアカウントの特定を容易にします。
APIはこちらからご覧いただけます： https://developer.okta.com/docs/reference/api/roles/
オリジンベースのIFrame埋め込み許可
お客様は、OktaをiFrameとしてレガシーソリューションに埋め込む機能を持っています。この機能はセキュリティに大きな影響を与えるため、設定にはWebセキュリティモデルへの深い理解が必要です。私たちは、最近、このグローバルな機能を「信頼できるオリジン」フレームワークに移行し、お客様がこの権限を特定のオリジンに細かく設定できるようにし、影響範囲（blast radius）を劇的に縮小しました。
APIは、こちら（https://developer.okta.com/docs/reference/api/trusted-origins/）から入手できます。
最後に、セキュリティ設定と構成を定期的に見直すことが、脅威を先取りするための重要なポイントです。組織のセキュリティを強化したいOktaのお客様は、当社のオンライン製品ドキュメントを活用して、最も安全な設定を適用することができます。
Follow Arnab Bose
