Okta Admin ConsoleへAuthentication Policyの設定するときは先にBreak Glassの設定をしよう
はじめに
皆様こんにちは、あかいけです。
Okta Admin Consoleに対して、Authentication Policyを設定する機会がありました。
IP制限やMFA強制など、セキュリティを強化するための設定を行うわけですが、ここでひとつ怖い問題があります。
設定を誤ると、誰もAdmin Consoleにログインできなくなる可能性があるということです。
実際にOktaコミュニティでも「自分自身をロックアウトしてしまった」という報告は珍しくありません…。
- User unable to login due authentication policy error
- 403 access forbidden accessing admin dashboard
- Unable to access admin dashboard after disabling OKTA verify
そんなわけで今回は、Authentication Policyの設定時に必ず事前に行うべきBreak Glass用の設定についてまとめます。
OktaにおけるBreak Glassについて
Break Glassとは、通常のアクセス手段が使えなくなった緊急時のために用意しておく、いざというときの経路のことです。
Oktaに限らず、クラウドサービスや社内システムでも広く使われている考え方です。
Oktaにおいては、以下のような場面でBreak Glassが必要になると考えられます。
- Authentication Policyの誤設定により、管理者がAdmin Consoleにアクセスできなくなった
- IP制限を設定したが、許可したIPアドレスに誤りがあった
- MFAデバイスの紛失・故障により認証ができなくなった
- ネットワーク障害で信頼済みネットワークからアクセスできなくなった
こうした事態が発生してから慌てても手遅れです…。
なのでAuthentication Policyを変更する前に、Break Glass用の設定を行っておくことが重要です。
Authentication Policyのルール評価順序
Break Glassの設定方法を説明する前に、Authentication Policyのルール評価順序について確認しておきます。
この仕組みを理解しておかないと、Break Glass Ruleが正しく機能しない可能性があります。
OktaのAuthentication Policyは、優先度が高いものから順に評価されます。
具体的には以下の流れです。
- ポリシーに紐づくルールを 優先度の高い順（Priority 1から） に評価する
- ユーザーのアクセス条件がルールのIF条件にすべてマッチした時点で、そのルールのTHEN条件が適用される
- マッチした時点で評価は終了し、それ以降のルールは評価されない
つまり、Break Glass Ruleを最も高い優先度（Priority 1）に配置することで、緊急アクセス用のユーザーは他のルールの影響を受けずにアクセスできるようになります。
今回設定するルールの優先度は以下のとおりです。
| 優先度 | ルール名 | 役割 | 備考 |
|---|---|---|---|
| 1 | Break Glass Rule | 緊急アクセス用。特定のSuper Administratorのみ対象 | 新規作成 |
| 2 | Admin App Policy | 通常の管理者向け。IP制限+MFA強制 | デフォルトで存在するルール |
| 3 | Catch-all Rule | 上記に該当しないアクセスをすべて拒否 | デフォルトで存在するルール |
この構成にすることで、仮にAdmin App PolicyのIP制限設定を誤ったとしても、
Break Glass用のユーザーは影響を受けずにAdmin Consoleにアクセスでき、設定を修正することができます。
設定手順
ここからは、具体的な設定手順を説明します。
今回は 「特定のグローバルIPアドレス（社内ネットワーク・VPNなど）からのみAdmin Consoleにログインできるようにする」 というシナリオで設定を行います。
あわせてMFAも必須化し、意図しない経路からのアクセスはすべて拒否します。
設定は以下の順序で行います。
- Network Zoneの作成
- Break Glass Ruleの作成
- Admin App Policyの編集
- Catch-all Ruleの編集
- 動作確認
1. Network Zoneの作成
まずは、IP制限に使用するNetwork Zoneを作成します。
設定パス: Security > Networks > Add Zone > IP Zone
| 項目 | 設定値 | 備考 |
|---|---|---|
| Zone name | IP Whitelist for Okta Admin Console |
任意の識別名 |
| Block access from IPs matching conditions listed in this zone | 未チェック | ブロックではなく許可リストとして使用 |
| Gateway IPs | [許可するIPアドレス/CIDR] |
社内IP、VPN出口IPを列挙 |
ここでは、Admin Consoleへのアクセスを許可するIPアドレスを登録します。
社内ネットワークのIPやVPN経由のIPアドレスを設定してください。
2. Break Glass Ruleの作成
ここが最も重要なです！！
他のルールを編集する前に、必ずBreak Glass Ruleを作成してください。
設定パス: Security > Authentication Policies > App sign-in > Okta Admin Console > Rules > Add Rule
IF条件（ルール適用条件）
対象としてOktaユーザーを設定していますが、ここはOktaグループでも大丈夫です。
| 条件 | 項目 | 設定値 | 説明 |
|---|---|---|---|
| IF | User's user type is | Any user type | すべてのユーザータイプを対象 |
| AND | User's group membership | Any group | グループによる絞り込みなし |
| AND | User is | [Break Glass用のSuper Administratorユーザー] |
Okta Admin Consoleにログイン可能な特定のユーザーを指定 |
| AND | Device state is | Any | デバイスの登録状態を問わない |
| AND | Device assurance policy is | No policy | デバイスのセキュリティ状態チェックを行わない |
| AND | Device platform is | Any platform | すべてのOSを対象 |
| AND | User's IP is | Any IP | IP制限なし（緊急時にどこからでもアクセス可能） |
| AND | Risk is | Any | リスクレベルを問わない |
| AND | The following custom expression is true | （空欄） | カスタム条件式。高度な条件が不要な場合は空欄 |
ポイントは以下の2つです。
- User isに特定のSuper Administratorユーザーを指定する。「Any user」にしてしまうとBreak Glassの意味がなくなります
- User's IP isをAny IPにする。Break Glassの目的は緊急時のアクセス確保なので、IP制限をかけてはいけません
THEN条件（認証要件）
| 条件 | 項目 | 設定値 | 説明 |
|---|---|---|---|
| THEN | Access is | Allowed after successful authentication | 認証成功後にアクセス許可 |
| AND | User must authenticate with | Password + Another factor | パスワード+MFAを必須 |
| AND | Phishing resistant | 未チェック | フィッシング耐性認証は必須としない |
| AND | Hardware protected | 未チェック | ハードウェアキーは必須としない |
| AND | Require user interaction | Any interaction | ユーザー操作の方法を限定しない |
| AND | Authentication methods | Allow any method that can be used to meet the requirement | 要件を満たす任意の認証方式を許可 |
| AND | Option to stay signed in | 未チェック | 「サインインしたままにする」オプションを表示しない |
| AND | Prompt for password authentication | When an Okta global session doesn't exist | Oktaセッションが存在しない場合のみパスワードを要求 |
| AND | Prompt for all other factors of | Every time user signs in to resource | サインインのたびにMFAを要求 |
Break Glass用のユーザーといえど、セキュリティは確保する必要があります。
Password + Another factorを設定し、最低限MFAは必須にしておきましょう。
なおOkta公式では一般的な方法としては、Break Glassアカウントの認証にFIDO2セキュリティキーを複数登録しておくことを紹介しています。
優先度の設定
ルールを作成したら、必ず優先度を1に設定してください。
作成した「Break Glass Rule」の以下赤枠のあたりをドラッグし、既存の「Admin App Policy」の上にドロップすることで、優先度を1に変更できます。
（このドラッグの操作が絶妙に怖いんですよね…）
優先度を1に変えたら、「Break Glass Rule」で指定したOktaユーザーでログインできることを確認してください。
3. Admin App Policyの編集
Break Glass Ruleを作成した後に、管理者向けのIP制限+MFA強制ルールを設定します。
設定パス: Security > Authentication Policies > App sign-in > Okta Admin Console > Rules > Admin App Policy > Actions > Edit
IF条件（ルール適用条件）
対象としてOktaグループを設定していますが、ここはOktaユーザーでも大丈夫です。
| 条件 | 項目 | 設定値 | 説明 |
|---|---|---|---|
| IF | User's user type is | Any user type | すべてのユーザータイプを対象 |
| AND | User's group membership | [管理者グループ] |
Admin Consoleへのアクセスを許可するグループ |
| AND | User is | Any user | グループ内の全ユーザーを対象 |
| AND | Device state is | Any | デバイスの登録状態を問わない |
| AND | Device assurance policy is | No policy | デバイスのセキュリティ状態チェックを行わない |
| AND | Device platform is | Any platform | すべてのOSを対象 |
| AND | User's IP is | IP Whitelist for Okta Admin Console |
Network Zoneで定義したIPのみ許可 |
| AND | Risk is | Any | リスクレベルを問わない |
| AND | The following custom expression is true | （空欄） | カスタム条件式。高度な条件が不要な場合は空欄 |
THEN条件（認証要件）
| 条件 | 項目 | 設定値 | 説明 |
|---|---|---|---|
| THEN | Access is | Allowed after successful authentication | 認証成功後にアクセス許可 |
| AND | User must authenticate with | Password + Another factor | パスワード+MFAを必須 |
| AND | Phishing resistant | 未チェック | フィッシング耐性認証は必須としない |
| AND | Hardware protected | 未チェック | ハードウェアキーは必須としない |
| AND | Require user interaction | Any interaction | ユーザー操作の方法を限定しない |
| AND | Authentication methods | Allow any method that can be used to meet the requirement | 要件を満たす任意の認証方式を許可 |
| AND | Option to stay signed in | 未チェック | 「サインインしたままにする」オプションを表示しない |
| AND | Prompt for password authentication | When an Okta global session doesn't exist | Oktaセッションが存在しない場合のみパスワードを要求 |
| AND | Prompt for all other factors of | Every time user signs in to resource | サインインのたびにMFAを要求 |
このルールにより、指定したグループのユーザーは、許可されたIPアドレスからのみ、MFAを経てAdmin Consoleにアクセスできるようになります。
4. Catch-all Ruleの編集
最後に、Catch-all Ruleを設定します。
ただしこのルールはデフォルトで「上記のどのルールにも該当しないアクセスを拒否する」となっているため、今回の場合は特に設定せずそのまま利用します。
設定パス: Security > Authentication Policies > App sign-in > Okta Admin Console > Rules > Catch-all Rule > Actions > Edit
| 条件 | 項目 | 設定値 | 説明 |
|---|---|---|---|
| THEN | Access is | Denied | 上位ルールに合致しないアクセスをすべて拒否 |
5. 動作確認
すべてのルールを設定したら、動作確認を行います。
本記事の設定であれば、以下のチェックが全てOKであれば意図した通りの設定できています。
- Break Glass用ユーザーが許可IPからAdmin Consoleにログインできること
- Break Glass用ユーザーが非許可IPからAdmin Consoleにログインできること（IP制限なしであることの確認）
- 管理者グループのユーザーが許可IPからAdmin Consoleにログインできること
- 管理者グループのユーザーが非許可IPからAdmin Consoleにアクセスできないこと（拒否されること）
- 上記どちらにも該当しないユーザーがAdmin Consoleにアクセスできないこと（Catch-all Ruleで拒否されること）
なお、Break Glass用ユーザーとBreak Glass Ruleは、運用上の決めの問題ではありますが特段の理由がなければ残しておくでOKかと思います。
また、他の管理者ユーザーと同様にBreak Glass用ユーザーへもIP制限をかけるかどうかも決めの問題ではありますが、動作確認が取れた後に必要な場合は設定してください。
その他の注意点
Break Glass用ユーザーについて
- Break Glass用のユーザーは、Okta上で管理されるユーザーを使用を推奨します
- Active DirectoryやLDAP連携のユーザーだと、それらのシステムに障害が発生した場合にBreak Glassも使えなくなる可能性があります
- Super Administrator権限を持つユーザーを指定してください。Admin Consoleのすべての設定を変更できる権限が必要です
運用面での推奨事項
- 定期的にBreak Glassアカウントでのログインテストを行い、緊急時に確実に使えることを確認してください
- Break Glassアカウントの使用手順をドキュメント化し、必要なメンバーに共有しておきましょう
設定変更時のセーフティネット
Authentication Policyの変更作業中は、以下に気をつけてください。
- 別のブラウザやシークレットウィンドウでBreak Glassアカウントのセッションを維持しましょう、設定ミスがあってもすぐに修正できます
- 一度にすべてのルールを変更せず、変更は1つずつ段階的に行いましょう
- 変更前に現在の設定を記録(スクリーンショットなど)しましょう、問題発生時の切り戻しが容易です
さいごに
以上、OktaのAuthentication Policy設定時に行うべきBreak Glass設定についてまとめました。
Authentication Policyの設定自体はセキュリティ強化に不可欠ですが、設定を誤ると、誰もAdmin Consoleにログインできなくなる可能性があるというリスクが常にあります。
Break Glass Ruleを最優先で設定しておくことで、万が一の事態にも対応できるようになります。
この記事がOktaの設定で困っている方の助けになれば幸いです。
