Oktaは、お客様に最高レベルのセキュリティを提供することに取り組んでいます。私たちは、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の「Secure by Design」7原則へのコミットメントを誓約した最初のテクノロジープロバイダーの一社であり、1年前には「Okta Secure Identity Commitment」を開始しました。
これらの取り組みのもと、Oktaは企業インフラと製品ポートフォリオに対して、数々の重要な機能やアップグレードを発表し提供してきました。その中には、お客様が利用可能な最も効果的なセキュリティ対策のひとつである、多要素認証（MFA）への強固かつ一貫したアプローチをお客様に促すことも含まれます。全体のセキュリティ水準を引き上げるため、2024年にはOkta Admin Consoleのログインに対してMFAを義務化し始めました。これは、アイデンティティファーストのセキュリティという私たちの共通の取り組みにおいて、賢明かつ必要不可欠なステップです。
本日、Oktaは、既存のすべてのOktaテナントに対し、1年間でOkta Admin Consoleへの MFA強制を100%達成したことをお知らせします。また、新たに作成されるすべてのテナントにおいては、Okta Admin Consoleのアクセスに対してMFAがデフォルトかつ変更不可能な要件となります。
なぜOkta Admin ConsoleにMFAを義務化するのか？
Okta Admin Consoleは、Oktaユーザー、Oktaが保護するアプリケーション、Oktaセキュリティポリシーを管理するための中核的ハブです。このコンソールへの不正アクセスは、以下のような壊滅的な結果を招く可能性があります。
データ漏えい：攻撃者が機密ユーザー情報やアプリケーションデータにアクセスする。
システム侵害：脅威アクターがセキュリティ設定を変更し、裏口アカウントを作成したり、重要なセキュリティ機能を無効化する。
サービス障害：不正な変更によって障害が発生し、エンドユーザー向け機能に悪影響が生じる。
評判へのダメージ：セキュリティインシデントが企業のブランドや事業に深刻な影響を与える。
MFAは、パスワードに加えて時間ベースのワンタイムパスワード（TOTP）、指紋スキャン、ハードウェアトークンなどの第二要素を要求することで、これらのリスクを大幅に軽減します。Oktaは、知識・所持・生体のいずれか2つの要素によるMFAのみを義務化していますが、管理者に対してはパスワードを排除し、Okta FastPassやFIDO2 WebAuthnなどフィッシング耐性のある認証方式を利用することを強く推奨しています。
Okta は、管理者のアクセスに対してMFAを強制する機能を提供しています。すべてのOkta テナントには、パスワードに加えて Okta Verify TOTP、Okta FastPass、メールなどの複数の要素が標準で含まれています。また、Oktaは管理者がOkta Admin Consoleに対してMFA を強制できる柔軟なポリシーも提供しています。
管理コンソールのアプリケーションポリシーは、従来からデフォルトでMFAを要求していましたが、管理者はこの設定を1要素認証（1FA）に引き下げることが可能で、多くの管理者がさまざまな理由でそうしていました。今回Oktaは、このデフォルトのセキュリティ設定を引き下げることを防止し、既存のすべてのお客様がMFAによってセキュリティ設定を強化できるようにしました。
OktaがどのようにしてMFA義務化をお客様に受け入れてもらったのか
ここでは、管理者が1FAポリシーを維持する必要があると認識していた理由、そしてOktaがどのようにしてMFA義務化をお客様に受け入れてもらったのかをご説明します。一般的に、お客様はMFAを導入することが良いことであると認識していました。しかし、以下のような理由から、管理者は1FAを維持しなければならないと考えていました。
管理者が1FAアクセスを許可するポリシールールの存在に気づいていなかった
管理者はパスワードをVault内に管理し、使用するごとにローテーションしていたため、MFAは不要だと考えていた
管理者が他のIdPでMFAを完了し、フェデレーションでOkta Admin Consoleに入っていた
管理者が自動テスト用アカウントをOkta Admin Consoleにログインさせる必要があった
LDAPやActive Directoryエージェントの動作への影響を懸念していた
Okta は、これらの障害や懸念のそれぞれに対処しました。最後の懸念は、通常のエージェント操作に影響がないことを確認することで容易に解決できました。
しかし、残りの懸念については、まずHealthInsights機能を通じて、1FAアクセスを許可するルールがあるテナントの管理者に警告を発しました。
Okta Admin Consoleのポリシーからも警告を表示し、問題のあるルールを強調しました。
パスワードをVault内に管理し、ローテーションしていたためMFAが不要だと考えていた管理者には、MFAのほうが優れた保護を提供することを強調しました。パスワードの保管とローテーションは継続すべきですが、特に所持要素や生体要素を追加する必要があります。また、Vault内のパスワードが複数のユーザー間で共有されている場合には、それぞれのユーザーが固有のアカウントを持つべきであると提案しました。
他のお客様については、別のIdPでMFAを完了し、Okta Admin Consoleにフェデレーションするケースがありました。つい最近まで、Oktaはそのフェデレーションを単一要素として扱っていました。しかし、現在は新機能「claims sharing」によって、IdPがSAMLまたは OIDCレスポンス内でAMRクレームを送信でき、Oktaは他のIdPで完了した要素をMFA assuranceとして認めます。これにより、もうひとつの障害が取り除かれました。
自動テスト用アカウントについては、追加要素が利用できないという懸念がありました。Oktaはこの問題に対し、テストアカウントをTOTP要素に登録し、パスワードとともに共有シークレットをVault内に保管する方法を提案しました。ログイン時にはパスワードと同時に共有シークレットを取り出し、プログラム的にTOTPを生成することができます。
こうした課題のすべてが解決されたことで、お客様は行動する準備が整いました。
変更を展開するための準備
Oktaは、無料トライアルの開発者テナントから、大規模かつ複雑な構成のテナントまで幅広いお客様を抱えています。そのため、通常の運用に影響を与えないよう、段階的なロールアウトが必要でした。具体的には、以下の戦術を採用しました：
イニシアチブの発表：MFA強制の開始が近いことを示す公開発表やブログに加え、製品内ガイド、開発者ポータル・サポートポータルでのバナー表示、管理者へのターゲットメール送信を行いました。
新しい1FAアクセスポリシーの作成禁止：まず最初に、すべてのテナントで新規の 1FAポリシーが作成できないようにし、影響範囲の拡大を防止しました。
お客様をコホート分けして段階的にMFA適用：サポートチケットの殺到や管理者ロックアウトを防ぐため、テナントの設定を調査し対処が必要なグループに分け、コホートごとに異なる強制日を設定しました。
管理者には以下の変更が指示されました：
パスワードのみのルールは、パスワード＋別要素に変更する
1FAや所持要素のみのルールは、任意の2要素に変更する
変更後は1FAに戻すことは許可されません。管理者が対応しない場合は、Oktaが指定日に自動的にMFAを強制しました。
Oktaのお客様は迅速にMFAを導入
ロールアウト開始から 4か月以内に、Oktaは対象テナントの99%に対してMFA適用を完了しました。残りの1%は、claims sharingなどOkta側での機能強化や、必要となる運用変更に時間を要したテナントでしたが、Oktaは密接に連携し、移行に対する不安を解消しました。
MFAが100%強制された現在、管理者はOkta Admin Consoleへのサインインにさまざまな要素と認証器を利用しています。最も多く使用されている要素は、パスワード、Okta Verifyプッシュ通知、Okta FastPassです。これらの組み合わせとしては、パスワード＋Okta Verify プッシュ、パスワード＋Okta FastPass が一般的です。
現在、Okta Admin ConsoleへのMFAアクセスは、すべての既存・新規のOkta管理者にとって必須の要件です。この強固な姿勢をデフォルトで採用することで、お客様は攻撃対象領域を減らし、重要なアイデンティティインフラをより強固に保護する恩恵を受けています。
