こんにちは！たつみんです。
Oktaのポリシーをマスターしよう！シリーズ記事のAuthenticator Enrollment Policy編です。
この記事ではAuthenticator Enrollment Policyにおいてポリシーやルールでどのような構成が行えるかやどのような役割を持っているかなどを解説します。
Oktaのポリシーをマスターしよう！のシリーズ目次
- 概要編
- Password Policy編
- Global Session Policy編
- Authenticator Enrollment Policy編←今日のブログはここ！
- Authentication Policies編
- Device Assurance Policies編(過去の検証ブログ)
概要編のおさらい
以下は概要編のおさらいです。
- Device Assurance Policies以外のポリシーの中にはルールが存在する
- ルールの中にはIF(AND)とTHENが存在する
- ポリシーの適用はグループ単位やアプリケーション単位やOSプラットフォーム単位がある
Authenticator Setupについて
Authenticator Enrollment Policyの解説の前にAuthenticator Setupについて触れておきます。このAuthenticator SetupではOktaテナント全体としてどのようなAuthenticatorを有効とするかを設定します。
Setupタブ内のAdd authenticatorから利用したいAuthenticatorを追加します。
NIST SP800-63Bを参考に最低限のAuthenticatorとして、PasswordとOkta Verifyを有効にします。特にOkta VerifyはFastPassやDevice Trustの実装の際に重要な役割を担うため、事実上必須となります。以下の記事で触れていますのでこちらもご参照ください。
次にOkta Verifyが利用できないケースが想定される場合にはFIDO2 (WebAuthn)の有効化を検討します。
Security QuestionとEmailはAuthenticatorとしては不適切であるため有効化はしません。
Authenticator Enrollment Policyとは
一言で言ってしまうと事前にAuthenticator Setupで利用可能としたOkta VerifyなどのAuthenticatorをユーザーにどのように登録してもらうかを設定します。
主に以下の観点を定義します。
- Authenticatorとして何を登録可能(必須/オプション/無効)とするか
- どのような状況になったら登録を促すか
Authenticator Enrollment Policyの適用範囲について
ポリシーを新しく作成する時は以下のように必ずグループを指定する必要があります。
また以下のように複数のポリシーがある場合は上から順番に参照されます。
- Policy A
- 対象グループ：Group A
- Policy B
- 対象グループ：Group B
もし、あるユーザーがGroup AとGroup Bの両方に所属している場合は、より上位に位置するPolicy Aが参照されます。この順番はドラッグ&ドロップで並び替えすることができます。ただしDefult Policyは対象グループがEveryoneに固定され、優先順位も常に最下層に位置します。
推奨設定
Defult Policyの更新
ここではユーザーに登録を促すAuthenticatorとしてOkta VerifyとPasswordを必須とし、それ以外のAuthenticatorであるFIDO2 (WebAuthn)はオプションとします。
Ruleについて
これまでの私の経験でDefault Ruleでも十分だと思っていますが、Ruleを追加した時にどのような設定があるか確認するために一度Add ruleをクリックした画面を見てみます。
User is accessing
Okta自体にアクセスした時やアプリケーションにアクセスした時を選択できます。
アプリケーションを選択した時はさらにAny application that supports MFA enrollmentもしくはSpecific applicationsのどちらかが選択できます。Specific applicationsを選択した場合はどのアプリケーションかをさらに指定できます
Enrollment is
Authenticatorの登録を許可するか拒否するかを選択できます。
上記のような選択肢はありますがAuthenticatorの登録という意味ではあまり条件を限定する必要はないのではないかと思います。
非推奨：Okta Verifyを登録できない場合
Policyの追加とRuleの追加
前述のようにOkta VerifyはFastPassやDevice Trustの実装において重要な役割を担いますが、コールセンター等を外部に委託していてOkta Verifyの利用できない場合に次善の策として以下のようにFIDO2 (WebAuthn)等の他のAuthenticatorを登録を促すポリシーをDefult Policyとはわけて設定します。
Yubikeyのような物理的なセキュリティキーもしくはMacbookのTouch ID、WindowsのWindows Helloなどが利用できればFIDO2 (WebAuthn)に対応可能です。
- 専用グループを作成する
- Add policyをクリックし、新規ポリシーを作成する
- 1.で作成したグループを対象とする
- Okta VerifyをDisabledとし、FIDO2 (WebAuthn)をRequiredとする
- ルールについては名前だけをつけて以下のようにデフォルト値のまま作成する
非推奨：MFAを行わない場合
Policyの追加とRuleの追加
Global Session Policy編でも少し触れた全くMFAを行わない場合はAuthenticator Enrollment PolicyでPasswordを必須とし、それ以外のAuthenticatorはすべて無効とします。
ルールについては名前だけをつけて以下のようにデフォルト値のまま作成する
このMFAを行わないポリシーの適用範囲はGlobal Session PolicyでMFAを行いポリシーで設定したグループと同じグループを指定する点を忘れないようにしましょう。 上記ではGroup Bという名称のグループですが実際にはわかりやすいグループ名にしておくと良いでしょう。
まとめ
Authenticator Enrollment Policyは新規Oktaユーザーのオンボーディングを行う際に強く意識すると思います。ユーザーにどのようなAuthenticatorを使ってもらうかはユーザー体験にも影響するためOktaテナント構築の初期段階でしっかりと作り込んでおくとよいでしょう。
ポリシーはシンプルにし、登録可能なAuthenticatorも必要最小限にしておくとユーザーが迷わずに登録進めてくれると思います。
次回はアプリケーションがアクセスする際に参照されるAuthentication Policiesについての解説です。
