ServiceNowは標準でIPアドレス制限やワンタイムパスワード方式の多要素認証（MFA）をサポートしていますが、これらを適用する条件をより高度に設定するための適応認証（Adaptive Authentication）というプラグインについて紹介します。なお、この機能は2022年11月Tokyoバージョン現在はプラグインですが、将来的に標準機能になる可能性があります（MFAもそうだった）。
Adaptive Authenticationとは？
機能概要
機能の概要を図解すると次のようになります。
適応認証（Adaptive Authentication）は、標準機能として存在する次の2つの機能を強化するような位置づけの機能です。特に、グループベースの制御と登録済みモバイルデバイスの管理は下記機能では実現できなかったポイントです。
- IPアドレスアクセス制御（IP Address Access Control）
… ホワイトリストまたはブラックリスト方式で接続元IPレンジを制限する機能。
- マルチファクタ認証（Multi-factor Authentication）
… ワンタイムパスワード方式の多要素認証を有効化するための機能。付随機能として、ロールに基づいてMFA適用対象ユーザを制御するMulti-factor Criteriaという機能が存在する。
これまでは上述の2つを設定するのが一般的でしたが、今後は適応認証（Adaptive Authentication）を有効化し、まとめて設定するのが一般的になると思われます。
ここからは、画像の下の方から各概念をボトムアップで説明していきます。
フィルター基準（Filter Criteria）
フィルター基準は、Authentication Policy（認証ポリシー）を設定する際の要素になる、アクセス制御やMFAの適用条件判定を行うための1つ1つの基準です。
フィルター基準には大きく2つの種類があります。
- ユーザ定義のフィルタ基準（IP Filter Criteria, Role Filter Criteria, Group Filter Criteria）
… ユーザが定義するフィルタ基準です。3つの種別があります。- IPフィルター基準（IP Filter Criteria）
… 接続元IPアドレスに基づくフィルター基準。IPレンジで指定（例: 126.xx.xx.xx～126.yy.yy.yy）する方式とサブネットで指定（例: 126.xx.xx.xx/16）で指定する方式が利用可能 - ロールフィルター基準（Role Filter Criteria）
… ユーザが持つロールに基づくフィルター基準。ロールを直接指定するだけでなく、「条件を満たすロール」という指定が可能（例: ロール名に”admin”を含むロール） - グループフィルター基準（Group Filter Criteria）
… ユーザが所属するグループに基づくフィルター基準。グループについてはロールと違い、直接指定する方法のみ利用可能
- IPフィルター基準（IP Filter Criteria）
- システム定義のフィルタ基準（Generic System Filter Criteria）
… システムで定義されており、ユーザ側での設定が不可能なフィルタ。2022年11月Tokyo現在では、予め登録（ペアリング）されたモバイルアプリかどうかを判定する基準である”Trusted Mobile App”という1つだけが存在
こちらについては下記の記事で詳しく解説しています。
認証ポリシー（Authentication Policy）
認証ポリシーは、フィルター基準（Filter Criteria）を組み合わせて、どんな時にアクセスを許可/拒否するか、MFAを適用する/適用しないか、という条件を定めるものです。
これによって、次のような条件による認証の制御ができるようになります。
- 企業の外部ネットワークからのアクセスの時だけMFAを適用する
（IPフィルター基準）
- 基本的には企業の内部ネットワークからのアクセスに限定するが、予め登録されたモバイルアプリに対してのみ外部ネットワーク（インターネット）からのアクセスを許可する
（IPフィルター基準 + システム定義フィルター基準”Trusted Mobile App”）
- 名前に”admin”を含むロールを持つユーザは企業の内部ネットワークからのアクセスに限定し、それ以外のユーザは外部ネットワークからのアクセスも許可する。ただし、外部ネットワークからのアクセスの場合はMFAを適用する
（ロールフィルター基準 + IPフィルター基準 + システム定義フィルター基準”Trusted Mobile App”）
事前認証/承認後のコンテキスト（Pre-/Post-Authentication Context）
事前認証/承認後のコンテキストは、認証の前/認証の後に適用されるポリシーを設定します。
デフォルトポリシー（Default Policy）
コンテキストにポリシーを紐づける際には、デフォルトポリシーを併せて設定する必要があります。デフォルトポリシーには次の2種類があります。
- Allow policy = ホワイトリスト方式
… デフォルトで拒否し、ユーザ定義ポリシーの基準を満たす場合のみ許可する方式。
- Deny Policy = ブラックリスト方式
… デフォルトで許可し、ユーザ定義ポリシーの基準を満たす場合のみ拒否する方式。
デフォルトポリシーの設定によって、設定したポリシーの使われ方が真逆になるので、具体例も載せておきます。
- 例1)
デフォルトポリシー: Allow policy = ホワイトリスト方式
設定したポリシー: 企業の外部ネットワークからのアクセスの時だけtrue
-> 企業の外部ネットワークからのアクセスの時だけ許可され、その他は拒否 - 例2)
デフォルトポリシー: Deny policy = ブラックリスト方式
設定したポリシー: 企業の外部ネットワークからのアクセスの時だけtrue
-> 企業の外部ネットワークからのアクセスの時だけ拒否され、その他は許可
事前認証コンテキスト（Pre-Authentication Context）と認証後コンテキスト（Post-Authentication Context）
認証コンテキスト（Authentication Context）には、事前と事後があります。
- 事前認証コンテキスト（Pre-Authentication Context）
… ログイン画面が表示される前に実行される。ログイン前でユーザが特定できないのでロールフィルター基準（Role Filter Criteria）とグループフィルター基準（Group Filter Criteria）が使えない
- 認証後コンテキスト（Post-Authentication Context）
… ログイン後に実行される。ログイン後でユーザが特定できるので、ロールフィルター基準（Role Filter Criteria）とグループフィルター基準（Group Filter Criteria）が使える
認証後コンテキスト（Post-Authentication Context）で全てのフィルター基準を使った評価ができるため、こちらだけでよいじゃんと思われるかもしれませんが、ログイン画面が表示されると、漏洩ID/パスワードの確認や（イマドキ行われているか詳しくありませんが）パスワードの総当たり攻撃といった攻撃の機会を与えてしまうため、基本的には事前認証コンテキスト（Pre-Authentication Context）で設定し、ロールとグループに基づいた制御が必要な部分のみ認証後コンテキスト（Post-Authentication Context）で実現するのがよいと思われます。
MFAコンテキスト（MFA Context）
MFAコンテキストは、どのようなときにMFAを適用するかを指定するポリシーを設定します。
デフォルトポリシー（Default Policy）
MFAコンテキストにもデフォルトポリシーが存在します。
- Step-up MFA policy = ブラックリスト方式
… デフォルトでMFAを適用せず、設定されたポリシーの基準を満たす場合のみMFAを適用する方式
- Step-down MFA Policy = ホワイトリスト方式
… デフォルトでMFAを適用し、設定されたポリシーの基準を満たす場合のみMFAを緩和（免除）する方式
事前認証/承認後のコンテキストと同様に、デフォルトポリシーの設定によって、ユーザ定義のポリシーの動作が真逆になるので注意です。
MFAは認証後に評価されるので、事前・事後はない（常に事後）
MFAコンテキストは、認証を行った上で追加のMFAを行うかどうかの判定になるため、事前・事後の区別はありません。強いて言うなら、常に事後ということになります。
設定方法
設定自体はドキュメントを見ながら行えば簡単なので、ここではポイントになる部分を中心に簡単に紹介します。
プラグインの有効化
適応認証（Adaptive Authentication）はプラグインなので、有効化が必要です。
- メニュー > システム定義（System Definition） > プラグイン（Plugins）よりプラグインの一覧を開く
- プラグイン”Adaptive Authentication (com.snc.adaptive_authentication)”をインストールする
- メニュー > 適応認証（Adaptive Authentication） > 認証ポリシー（Authentication Policies） > プロパティ（Properties）を開く
- 必要なプロパティを有効化する
基本的には下記2つを設定すればよいでしょう。
– 認証ポリシーを有効にします（Enable Authentication Policy）: “はい（Yes）”
– デバイス信頼フローの有効化（Enable Device Trust Flow）: モバイルアプリの機能を使う場合は”はい（Yes）” - “保存（Save）”ボタンを押下して保存する
filter criteria（フィルター基準）の作成
フィルター基準を作成します。最も代表的なIPフィルター基準（IP Filter Criteria）の例を示します。filter criteriaがtrueとなる条件を指定します。
- メニュー > IPフィルター基準（IP Filter Criteria）を開く
- “新規（New）”ボタンを押下してフィルター基準作成画面を開く
- 名前、説明、IP範囲、サブネット(CIDR)を指定
– IP範囲: 範囲の開始と終了を指定します（例: 0.0.0.0～255.255.255.255）
– サブネット(CIDR): ネットワークアドレスとサブネットマスクを指定します（例: 126.40.0.0/16）※ サブネットマスクが16ビットの場合は、”255.255.0.0″ではなく”16″と指定するので注意です - “送信（Submit）”ボタンを押下して保存する
認証ポリシー（Authentication Policy）の作成
フィルター基準を組み合わせてポリシーを作成します。
- メニュー > 適応認証（Adaptive Authentication） > 認証ポリシー（Authentication Policies） > すべてのポリシー（All Policies）を開く
- “新規（New）”ボタンを押下してポリシー作成画面を開く
- 名前を入力した上で”送信（Submit）”ボタンを押下し、保存する
この際、デモデータを参考に、名前の中にデフォルトポリシーとしてどちらを指定する前提のポリシーなのかを書いておくと設定ミスを防げると思われます - “ポリシーの入力（Policy Inputs）”タブでこのポリシーで使うfilter criteria（フィルター基準）を指定する
- “ポリシー条件（Policy Conditions）”タブで各フィルター基準がどうなっていればこの認証ポリシーがtrueと判定されるかを指定する
下図は「基本的には企業の内部ネットワークからのアクセスに限定するが、予め登録されたモバイルアプリに対してのみ外部ネットワーク（インターネット）からのアクセスを許可する」ポリシーの設定例です。
事前認証/承認後のコンテキスト（Pre-/Post-Authentication Context）
ポリシーと認証コンテキストを紐づけます。事前の場合を例に説明します。
- メニュー > 適応認証（Authentication Policy） > 認証ポリシーのコンテキスト（Auth Policy Contexts）> 事前認証のコンテキスト（Pre Authentication Context）を開く
- デフォルトポリシーを設定する
- 上記で定義した許可/拒否ポリシー（Allow/Deny Policy）を設定する
デフォルトポリシーに”許可ポリシー（Allow Policy）”を設定した場合は許可ポリシー（Allow Policy）項目を、”拒否ポリシー（Deny Policy）”を設定した場合は拒否ポリシー（Deny Policy）項目を設定します。 - “保存（Save）”ボタンを押下して保存する
保存すると、画面下部関連リストの”ポリシーの入力”タブおよび”ポリシー条件”タブに、設定したポリシーが自動で表示されます
おわりに
最近はユーザ企業側のクラウド利用に関するポリシーもしっかりしてきており、導入の際にこのあたりを聞かれることも多くなってきました。まだ設定していない場合は、すぐに設定することをお勧めします。
以上です。
コメント