このブログはこちらの英語ブログの機械翻訳です。
Oktaは、お客様に最高レベルのセキュリティを提供することに尽力しています。Oktaは、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の7つのSecure by Design原則へのコミットメントを誓約した最初のテクノロジープロバイダーの1つであり、1年前にはOkta Secure Identity Commitmentを開始しました。
これらのイニシアチブのもと、私たちは企業のインフラストラクチャと製品ポートフォリオのために、多くの不可欠な機能とアップグレードを発表し、提供してきました。これには、お客様に利用可能な最も効果的なセキュリティ対策の1つである、多要素認証（MFA）に対する強力で一貫したアプローチを推奨することも含まれます。すべての人のセキュリティベースラインを引き上げるために、2024年にすべてのOkta Admin Consoleログインに対してMFAの適用を開始しました。これは、アイデンティティファーストのセキュリティに対する私たちの共通のコミットメントにおける、賢明で必要なステップです。
本日、Oktaは、既存のすべてのOktaテナントに対して、Okta Admin Consoleへの100% MFA適用を1年間で達成したことを発表いたします。また、すべての新規テナントに対して、MFAはOkta Admin Consoleへのアクセス ポリシーのデフォルトかつ変更不可能な要件となっています。
Okta Admin ConsoleにMFAが適用されるのはなぜですか？
Okta Admin Consoleは、Oktaユーザー、Oktaで保護されたアプリケーション、およびOktaセキュリティポリシーを管理するための中央ハブです。このコンソールへの不正アクセスは、以下のような壊滅的な結果をもたらす可能性があります。
- データ侵害：攻撃者は機密性の高いユーザー情報やアプリケーションデータにアクセスする可能性があります。
- システムの侵害: 脅威アクターは、セキュリティ設定の変更、バックドアアカウントの作成、および重要なセキュリティ機能の無効化を行う可能性があります。
- サービス中断：許可されていない変更は、エンドユーザーの機能停止や機能障害につながる可能性があります。
- 風評被害: セキュリティインシデントは、組織のビジネスとブランドに深刻な影響を与える可能性があります。
MFA は、モバイル認証アプリからの時間ベースのワンタイムパスワード (TOTP)、指紋スキャン、ハードウェアトークンなど、パスワードに加えて 2 つ目の検証要素を要求することにより、これらの結果のリスクを大幅に軽減します。Okta は知識、所持、または生体認証の 2 つの要素による MFA のみを義務付けていますが、Okta は管理者にパスワードからの移行を強く推奨し、Okta Verify FastPass や FIDO2 WebAuthn 認証システムなどのフィッシング耐性のある認証システムを含む、利用可能な最も安全な認証システムを有効にすることを推奨しています。
Oktaは、管理者アクセスにMFAを強制するための堅牢な機能を提供します。すべてのOktaテナントには、パスワードに加えて、Okta Verify TOTP、FastPass、メールなどのサポートされている要素のベースライン数が付属しています。Oktaはまた、管理者が特にOkta Admin Consoleに対してMFAを強制できる柔軟なポリシーを提供します。
コンソールのアプリケーションポリシーでは、常にデフォルトでMFAが必須でした。ただし、管理者は設定を1要素認証(1FA)にダウングレードすることが許可されていましたが、多くの管理者はさまざまな理由でそれを行うことを選択しました。現在、Oktaはこのデフォルトのセキュリティスタンスがダウングレードされるのを防ぎ、既存のすべてのお客様がMFAでセキュリティ体制を強化できるよう支援しています。
Oktaのお客様にMFAの適用を納得させた方法
管理者が1要素認証（1FA）ポリシーを維持する必要があるという認識をどのように克服し、Okta Admin Consoleへのアクセスを保護するために多要素認証（MFA）を導入できたのかを見ていきましょう。一般的に、お客様はMFAを導入することは良いことだと認識していました。しかし、1FA保証レベルにとどまらざるを得ないと考えるいくつかの一般的な理由がありました。
- 管理者は、1FAアクセスを許可するポリシールールがあることに気付いていませんでした。
- 管理者は、パスワードを保管し、使用するたびにローテーションしているため、多要素認証（MFA）は必要ないと考えていました。
- 管理者は、Okta とは異なるアイデンティティ プロバイダー (IdP) で MFA を完了し、Okta Admin Console にフェデレーションしていました。
- 管理者は、コンソールにログインする必要がある自動テストアカウントを持っていました。
- 管理者は、Lightweight Directory Access Protocol（LDAP）およびActive Directory（AD）エージェントの運用を懸念していました。
これらのハードルと懸念事項のそれぞれに対処するために苦心しました。最後の問題は、通常のエージェントの動作に影響がないことを簡単に確認することで十分に対処できました。
ただし、他の点については、まず、HealthInsights機能を通じて、1FAアクセスを許可するルールを持つテナントをお持ちの管理者に対して警告を発行しました。
また、これらの違反ルールを強調表示するOkta Admin Consoleポリシーからの警告も公開しました。
管理者が定期的にパスワードを保管およびローテーションしているため、MFAは必要ないと考えていた管理者に対して、MFA保護の方が優れていることを強調しました。顧客は引き続き秘密鍵を保管およびローテーションする必要がありますが、追加の要素要件、特に所持または生体認証要素を追加する必要もあります。保管されたパスワードが複数のユーザーと共有されている場合は、代わりに各ユーザーが独自の個別のアカウントを持つことをお勧めしました。
他の顧客に関しては、外部 IdP で MFA を完了し、Okta Admin Console にフェデレーションすることを選択した顧客もいます。ごく最近まで、Okta はそのインバウンドフェデレーションを単一の要素として扱っていました。ただし、現在、クレーム共有と呼ばれる新機能があります。IdP は SAML または OIDC 応答内で標準ベースの AMR クレームを送信でき、Okta は他の IdP で完了した要素を MFA 保証に十分であるとして尊重します。したがって、別のハードルが取り除かれました。
自動テストアカウントを使用してコンソールにログインし、テストを完了する顧客の場合、管理者は追加の要素を提供することは不可能だと考えていました。Oktaはこの問題に対処するために、テストアカウントがTOTP要素に登録し、パスワードとともに共有シークレットを保管することを推奨しました。パスワードをチェックアウトした後、共有シークレットもチェックアウトして、ログイン時にプログラムで生成するために利用できます。
これらすべての顧客の課題が解決されたため、お客様は行動を起こす準備ができました。
変更を展開する準備
Oktaテナントの数が非常に多く、無料トライアルや開発者テナントから大規模で複雑な実装のテナントまであったため、通常の運用への混乱を最小限に抑えるために、段階的に展開する必要がありました。したがって、Okta Admin ConsoleにMFA（多要素認証）を慎重に適用するために、いくつかの戦術を採用しました。
- イニシアチブの告知：MFAの強制適用が間近に迫っていることを示す広報発表やブログに加え、Oktaの開発者ポータルおよびサポートポータルに製品内ガイドとバナーを掲載し、今後の変更について管理者に知らせるための対象を絞ったメールを送信しました。
- すべての新しい1要素認証（1FA）アクセス ポリシーの作成を阻止する: 第一段階として、Oktaはすべてのテナントに変更を展開し、新しい1FAアクセス ポリシーが確立されないようにしました。これは、完全な修正を展開する前に、出血を止めるための対策でした。
- MFA（多要素認証）を適用するために顧客をコホートに分割する：Oktaへのサポートチケットの殺到のリスクを軽減し、不必要な管理者ロックアウトを防ぐために、この変更を顧客コホートごとに展開しました。まず、各テナントの構成を調べ、MFA（多要素認証）を適用するために必要な修復手順に基づいてグループ化しました。次に、各コホートに異なる適用日を選択し、具体的な修復手順を準備しました。
管理者は、次の方法でOkta Admin Consoleのポリシーを変更するように指示されました。
- パスワードのみの保証のルールは、パスワードと別の要素を要求するように変更する必要があります。
- 1FA保証または所有要素のみの保証を持つルールは、2つの要素を要求するように変更する必要があります。
変更が行われると、管理者は1FA保証にダウングレードできなくなりました。管理者が対応しなかった場合、Oktaは、明確に伝えられた日付に、そのテナントのコンソールに対してMFAを強制しました。
Oktaのお客様は、MFAに向けて順調に進んでいます
ロールアウトの最初の4か月以内に、Oktaは該当するすべてのテナントの99%でMFAの適用を完了しました。残りの1%は、クレーム共有などの機能拡張や、この新しい必須セキュリティレベルで運用するためにさまざまなプロセスを更新するための時間など、Oktaからの追加サポートを必要とするテナントでした。Oktaはこの顧客グループと連絡を取り合い、彼らの苦痛を深く理解し、この新しい方向への移行に自信を持てるようになるまで協力しました。
Okta Admin Console（Okta管理者コンソール）への100% MFA（多要素認証）適用により、管理者はコンソールにサインインするために、さまざまな要素と認証要素を活用しています。使用されている上位3つの要素は、パスワード、Okta Verifyプッシュ通知、Okta FastPassです。MFA（多要素認証）のチャレンジを完了するために使用されるこれらの要素の一般的な組み合わせには、パスワードとOkta Verifyプッシュ、およびパスワードとOkta FastPassがあります。
現在、Okta Admin Console への MFA アクセスは、現在および新しくオンボーディングされたすべての Okta 管理者にとって必須の要件です。デフォルトでこの安全な姿勢を採用することにより、お客様は攻撃対象領域が縮小され、重要なアイデンティティ インフラストラクチャの保護が強化されるというメリットを享受できます。
Adaptive MFAのWebページにアクセスして、OktaのMFA製品の詳細をご覧ください。Okta Secure Identity Commitmentについて学習して、Oktaがアイデンティティベースの攻撃と戦うために行っていることを常に把握してください。
