SaaS

Oktaのポリシーをマスターしよう！ -Authentication Policies編-

こんにちは！たつみんです。

Oktaのポリシーをマスターしよう！シリーズ記事のAuthentication Policies編です。

この記事ではAuthentication Policiesにおいてポリシーやルールでどのような構成が行えるかやどのような役割を持っているかなどを解説します。

Oktaのポリシーをマスターしよう！のシリーズ目次

概要編のおさらい

以下は概要編のおさらいです。

  • Device Assurance Policies以外のポリシーの中にはルールが存在する
  • ルールの中にはIF(AND)とTHENが存在する
  • ポリシーの適用はグループ単位やアプリケーション単位やOSプラットフォーム単位がある

Authentication Policiesとは

一言で言ってしまうとOktaに追加したアプリケーション(SP)の認証方針を設定します。

主に以下の観点を定義します。

  • IF(AND)部分でどのようなルールを作成するか
  • THEN部分で認証許可とするか拒否とするか
  • 許可する場合はどのような認証強度とするか

ここでよくある誤解としてはAuthentication Policiesでは認証強度を指定できますが具体的なAuthenticatorを直接的に指定することはできません。

Authentication Policyの適用範囲について

これまでの他のポリシーとは違いAuthentication Policyはその役割の特性上、アプリケーション(SP)と関連付けなければ意味をなしません。

ひとつのAuthentication Policyには複数のアプリケーション(SP)を関連付けできますが、逆にひとつのアプリケーション(SP)に複数のAuthentication Policyを関連付けることはできません。

具体的には以下のようになります。

Authentication Policyから見たアプリケーションの関連付け

アプリケーションから見たAuthentication Policyの関連付け

設定例

留意点

ここではポリシーとポリシーが内包するルールについて設定例を紹介することで解説を行いますが、推奨値という意味ではありません。ポリシーおよびルールを設計する際は各組織の考え方に則って検討の上、設定を行ってください。

用意されているポリシーとラベル付きポリシーについて

Authentication Policiesには初期状態からいくつかのポリシーが用意されています。その中でもグレーのラベルが付いているポリシーは特殊な役割があります。

  • DefaultラベルはOktaにアプリケーション(SP)を追加した時に自動的に関連付けされます。
  • Application-specific policyラベルは特定のアプリケーション(SP)のためのポリシーであることを示しており、アプリケーション(SP)の関連付けは固定されます。

基本的にDefaultラベルが付いているポリシー名Any two factorsをメインのポリシーとし作成します。アプリケーション(SP)レベルでポリシーを分けたい場合は別のポリシーを作成するのがよいでしょう。

以下では、よくあるユースケースとしてOkta Verifyが利用できずFIDO2(WebAuthn)なら利用できるコールセンターのユーザーが一部存在することを考慮した設計としました。上から順番にCall Center Users Rule、Device Trust Rule、Device Assurance Rule、そしてCatch-all Ruleの構成としています。

複数のルールがある場合は上から順番に参照され、IF(AND)部分の条件に合致する場合はTHENで指定した認証強度が求められます。この順番はドラッグ&ドロップで並び替えすることができます。ただしCatc-all RuleはIF(AND)はAny requestに固定され、優先順位も常に最下層に位置します。

個別ルールの解説

Call Center Users Rule

  • IF(AND)：GroupでCall Center Users Groupを指定します。さらにZoneで事前定義しておいたコールセンターのIPアドレスを指定します。
  • THEN：アクセスを許可し、認証手段としてPassword + Another factorを指定します。

OktaグループCall Center Users Group内のユーザーがコールセンターのIPアドレスからアクセスをした時に認証時にPassword + Another factorつまり、パスワードと別の要素が求められます。Re-authenticate afterで指定した時間を経過した場合にアクセスを行うと再認証が求められます。

グループ指定について

コールセンターユーザー向けルールではAuthenticator Enrollment Policy編でご紹介した非推奨：Okta Verifyを登録できない場合のグループと同じグループを指定するようにします。

Device Trust Rule

  • IF(AND)：DeviceでRegisteredを指定します。さらにManagedを指定します。
  • THEN：アクセスを許可し、認証手段にAny 2 factor typesを指定します。

ユーザーのアクセス元の端末がManaged（Device Trust状態）であれば、認証時に2つの認証要素を求められます。Re-authenticate afterで指定した時間を経過した場合にアクセスを行うと再認証が求められます。

Device Assurance Rule

  • IF(AND)：DeviceでRegisteredを指定します。さらにDevice Assuranceで事前定義していおいたDevice Assurance Policyを指定します。
  • THEN：アクセスを許可し、認証手段にAny 2 factor typesを指定します。

ユーザーのアクセス元の端末がManaged（Device Trust状態）であれば、認証時に2つの認証要素を求められます。Re-authenticate afterで指定した時間を経過した場合にアクセスを行うと再認証が求められます。

Catch-all Rule

  • IF(AND)：Any requestを指定します。
  • THEN：Deniedを指定します。

Catch-all Ruleは削除や無効化が行えず、必ず最下層に位置する。IF(AND)はAny requestで固定されている。THENでDeniedを指定することですべてのアクセスを拒否する。

アクセスを許可にしてしまうと、Catch-all Ruleより上位のルールでIF(AND)で条件を絞った意味がなくなってしまうために明示的にアクセスを拒否とする必要がある。

非推奨：MFAを行わない場合

ポリシー設計として推奨値はありませんが、MFAを行わないAuthentication Policyは非推奨です。

それでもなんらかの要因でMFA設定ができない場合に設定しますが、IF(AND)で最低限グループを指定し対象者を限定します。もちろん他の条件を追加し絞り込みが可能であれば設定をします。

NO MFA Rule

  • IF(AND)：GroupでCall Center Users Groupを指定します。
  • THEN：アクセスを許可し、認証手段にPasswordを指定します。

OktaグループNo MFA Group内のユーザーがアクセスをした時に認証時にPasswordのみが要素が求められます。Re-authenticate afterで指定した時間を経過した場合にアクセスを行うと再認証が求められます。

グループ指定について

MFAをまったく利用できないユーザー向けルールのグループはGlobal Session Policy編でご紹介した非推奨：MFAを行わない場合で指定したグループ、Authenticator Enrollment Policy編でご紹介した非推奨：MFAを行わない場合で指定したグループこれら全てで同じグループを指定するようにします。

ポリシー・ルールを作成する時のTips

名称はわかりやすいものを命名する

ポリシー名やルール名はログに記録されるため意図を簡潔に伝える名称としましょう。

ポリシーのDescription（説明）をしっかり書く

ルールの順番を含むポリシー設計の意図を記載しておきましょう。

ルールの優先順位は例外を上位に配置する

今回のユースケースではコールセンターを想定したルールを最上位に配置しています。このルールのIF(AND)の指定はグループとIPアドレスとしていますが、もしこれがより下層に位置した場合は本来適用させたいルールではないルールに合致してしまう可能性があるためです。

基本はシンプルな構成とする

ルールが多数あるポリシーは非常にわかりづらくなります。要件の整理を行いシンプルな構成となるように心がけましょう。

Okta Dashboard専用Policyについて

Okta Dashboard専用Policyとしてポリシー名：Okta Dashboardが用意されています。このPolicyではDevice TrustやDevice Assuranceを設定しません。

これは新入社員がOktaアカウントをアクティベーションを行う際にまずOkta Dashboardにアクセスするため必要があります。アクティベーションの段階ではアクセス元の端末がDevice TrustやDevice Assuranceを満たしていることが確認できません。

そのような強固なRuleを設定ししまうと条件に合致しないためにOkta Dashboardへアクセスが距離され、結果としてOktaアカウントのアクティベーションが行えずにスタックしてしまいます。

Microsoft Entra ID(旧:Azure AD)向けポリシーについて

OktaでMicrosoft Entra ID(Oktaアプリケーションとしての名称はMicrosoft Office 365)と連携した場合にApplication-specific policyラベルが付いた専用ポリシーであるMicrosoft Office 365が作成されます。

このポリシー内のルールにはIF(AND)にClient isという独自項目があります。ポリシー設計については下記で取り上げていますのでご参照ください。

Okta Identity EngineでのAzure ADとのフェデレーション設定はこれがおすすめだよ！
どーも、たつみんです。 今回はOkta Identity Engine（以下、OIE環境）でAzure ADと…
blog.cloudnative.co.jp

まとめ

Authentication Policiesはアプリケーション(SP)と関連付いているためイメージがしやすいポリシーかと思います。ただし、Authenticator Enrollment Policyとの関連性もありますし、Device Assurance Policyを組み込むこともできるため、いろいろなポリシーを意識することになると思います。

たつみん

事業会社の情シスからクラウドネイティブにJoin！
好きなものはF1海外観戦とベルギービール！
集中力の質は深く長く遅い典型的なシングルタスクタイプです。

記事一覧