ServiceNowのローカル認証でできること・設定方法（パスワードポリシー・ロックアウト・MFA）

ServiceNowにおいて、Azure ADやOktaなどServiceNow以外の認証基盤を用いたSSOに対して、ServiceNow自身の認証機能を使って行う認証（ローカル認証）でできることと設定方法について解説します。

ローカル認証とSSO
ローカル認証設定でできること
ローカル認証の設定方法

ローカル認証とSSO

現在、企業は多くのクラウド・パッケージ製品を組み合わせて業務を行っています。そのため、各システムで個別にアカウントやパスワードを管理することは非効率的ですし、何より安全ではありません。そこで、Azure ADやOktaなどのIDaaS製品を用いてアカウントやパスワードを管理し、各システムはIDaaSが提供するSSO認証機能を用いて認証を行うのが一般的です。

ServiceNowも例に洩れず、私の知る多くの事例でSSO連携を行っているのですが、SSOを使っていたとしても、管理者によるSSO連携の設定の変更や、IDaaS側でアカウントを管理していないユーザが存在する場合など、ローカル認証を併用する場合があります。そのため、たとえSSO環境だとしても、ローカル認証機能について理解しておくことは重要です。

ローカル認証設定でできること

多くの企業では「8文字以上で少なくとも1文字以上の大文字、小文字、数字、特殊文字を含むこと」といったパスワードポリシーが定められていると思います。ServiceNowではこのような認証に関する要件に対応するための機能が存在します。

ただし、ご存じの方も多いと思いますが、この分野の世界標準になっているNIST（米国国立標準技術研究所）が定めるデジタル認証ガイドラインでは、パスワードに複数の文字種を含むよう強制したり、定期的なパスワード変更を促すことは推奨されておらず、認証に関する設定を行うときはそれが本当に意味があるか、セキュリティ対策として妥当かを考える必要があります。そのためこの記事では機能の紹介とともに、NISTの推奨事項を示します。

参考:
NIST, SP 800-63 Digital Identity Guidelines
JIPDEC, OIDF-J・JIPDEC共催OpenID BizDay#11「NIST SP 800-63-3を読む」（日本語訳版が掲載されています）

パスワードポリシー

パスワードポリシーを実現するための機能を紹介します。

パスワードの長さ（NIST推奨）

パスワードの最小長及び最大長を設定することができます。

NISTのガイドラインでは、ユーザが自ら設定する場合は最小8文字と定められています。

大文字、小文字、数字、特殊文字の出現回数（NIST非推奨）

大文字、小文字、数字、特殊文字の各文字種が最低いくつ含まれるべきかを指定することができます。なお、特殊文字については、何を特殊文字としてみなすかを制御可能です。

NISTのガイドラインでは、これらの要件を課すべきではないとされています。

ユーザ自身に関連する単語を禁止（NIST推奨）

ユーザのユーザID、姓、名、会社名を含むパスワードを禁止することができます。

NISTのガイドラインでは、一般的に使われている値、予測可能な値、危殆化している値は拒否すべきとあり、その一例としてユーザ名やそこから派生するような、文脈に依存する値が例として挙げられています。

（オプション）複雑な正規表現によるルールの設定

必要に応じてスクリプトを用いたカスタムポリシーを設定することができます。これにより、上述の設定ではできない複雑な正規表現によるルールを定めるなど、任意のパスワードポリシーが設定可能です。

なお、NISTのガイドラインで定められている要件のうち、この機能を使わなければ実現できないものはないと思われます。

繰り返し、シーケンス（連番）の禁止（NIST推奨）

“aaaa…”, “1111…,”などの繰り返しや、”abcd…”, “1234…”といったシーケンス（連番）を禁止することができます。禁止する場合は、何文字以上繰り返したら（連続したら）繰り返し（連番）とみなすかを指定できます。

なお、シーケンス（連番）については、ドキュメントによると”abcd…”や”1234…”という辞書順だけでなく、”1qaz…”といったキーボード上で連続している文字列なども含め判定するようです。
（参考: Enable password policies on your instance）

NISTのガイドラインでは、一般的に使われている値、予測可能な値、危殆化している値は拒否すべきとあり、その一例として繰り返しやシーケンスが挙げられています。

除外パスワード・ブラックリスト（NIST推奨）

ServiceNowは除外パスワードリスト（ブラックリスト）を持っており、推測しやすいパスワードや過去に漏洩したパスワードを禁止することができます。“Password1″などの文字列が予め含まれたリストがServiceNow社より提供されており、標準ではSmall(5,000件)がインストールされています。オプションとして、Medium(50,000件)、Large(200,000件以上)も選択できます。さらに、ユーザが新たに文字列を追加することも可能です。

NISTのガイドラインでは、一般的に使われている値、予測可能な値、危殆化している値のリストを保持し、そこに含まれている値はパスワードとして設定できないようにすべきだとされており、具体例として過去漏洩したパスワードと類似したもの、辞書に含まれる単語、繰り返しやシーケンス（連番）、サービス名やユーザ名が挙げられています。

このガイドラインに基づいてか、ServiceNowとしても除外パスワードリスト（ブラックリスト）に下記の単語を追加することを推奨しています。

ブランド名または製品名
会社の本社などの一般的な場所
会社固有の用語や略語

パスワードの定期変更（NIST非推奨）

パスワードの定期リセットを課す機能は標準では存在しません。実装が必要な場合は最後のパスワード変更から一定期間が過ぎたユーザに対して、パスワードリセットを強制するためのフラグをONにするロジック（Business Rule）を作成する必要があります。

参考: KB0854574 Force Password Reset 90 Days After Last Change

NISTのガイドラインでは、危殆化したことが明らかでない場合は定期的なパスワード変更を要求すべきではないとされています。

同じパスワードの再利用の禁止

また、標準で直近n回のパスワードと同じパスワードの再利用を禁止する機能が存在します。しかし、そもそもパスワードは危殆化した場合のみ変更を強制するとしている場合、危殆化しなければ変更をする必要がないので使いまわしも何もなく、危殆化した場合は変更が必須となるため、同じパスワードは設定できません。そのため、この設定を使う必要は基本的にないでしょう。
（参考: KB0745424: Prevent users from re-using recently used passwords on the Password Reset screen）

ヒントや秘密の質問（NIST非推奨）

パスワードを思い出すためのヒントや秘密の質問を設定する機能は標準では存在しません。最近ではあまり見かけませんし、要件として出ることも少ないとは思います。

NISTのガイドラインではヒントや秘密の質問の設定はしてはいけないとされています。

アカウントロックアウトポリシー

同一アカウントに対する連続した認証失敗試行を制限する機能について紹介します。

レート制限（NIST推奨）

同一アカウントに対するログインが連続して失敗した場合に、そのアカウントをロックアウト（ログイン不可）にすることができます。最大失敗試行回数の設定も可能です。

ただし、標準では「試行回数に応じて次の試行までの待機時間を増やす」「一定時間以内に一定回数以上失敗した場合にロックアウトする」という機能はありません。実装するためには、カスタマイズが必要となります。

ロックアウト自動解除条件（NIST記載無し）

ロックアウト後、一定時間経過後にロックアウトを解除する機能があります。解除までの期間は設定可能です。しかし、この機能を有効化した場合、例えば最大連続失敗試行回数を5回、ロックアウト解除までの時間を15分としているとき、5回間違えて15分待機を4セット = 20回連続で失敗した場合は解除しない、といった制御はできないことに注意が必要です。

ロックアウトの自動解除の目的は運用負荷軽減だと思いますが、ほとんどの場合、通常のユーザはSSOを使い、ローカル認証を行うのは管理者など限られたユーザのみであるため問題にはなりません。そのため、あまり難しいことはせず、特定の回数でロックアウトを行う設定をするだけでよいと考えられます。過去実績でもこれ以上複雑なことをした例を知りません。

Multi-factor Authentication（多要素認証）

ServiceNowには、ローカルの多要素認証の機能があります。

概要

ServiceNowのローカル多要素認証は、RFC 6238で定義されているTOTP（時間ベースのワンタイムパスワード）を用います。TOTPは予め共有したシークレット（キー）と時刻からOTP（ワンタイムパスワード）を生成する方式です。

アルゴリズムが公開されているため、”Google Authenticator”など、このアルゴリズムに従ってOTPを生成できる任意のOTP生成器を使うことができます。一方で、デバイス認証や生体認証などは使えません。

権限（ロール）に基づく適用条件制御

標準では、ローカル多要素認証の適用要否をユーザの権限（ロール）に基づいて設定できます。一般的には管理者ユーザなど高い権限を持つユーザに対して適用します。

多要素認証をより高度な条件、例えば企業外部のネットワーク（IPアドレス）からのアクセスの場合のみ適用するといった設定も可能です。こちらについては別記事にまとめています。

ローカル認証の設定方法

上述の機能について、設定方法を記載します。

パスワードポリシー

パスワードポリシーの設定は、次の手順で行います。

パスワードポリシーの作成
使用するパスワードポリシーの指定
（オプション）除外パスワードリスト（ブラックリスト）の設定
（オプション）パスワードポリシーに関するプロパティの設定

なお、標準のパスワードポリシーを変更することで手順2を省略することもできますが、アップグレード時などの影響を考慮し、新規で作成する方針で説明します。

（参考: Enable password policies on your instance）

1. パスワードポリシーの作成

メニュー > All（すべて） > Password Policy（パスワードのポリシー） > Password Policie（パスワードのポリシー）よりパスワードポリシーの一覧を開く
“New（新規）”ボタンを押下しパスワードポリシーを作成する
「Password Strength Preset（パスワード強度のプリセット）」項目を指定する
この項目を指定することで、他の項目の表示/非表示、必須/非必須、デフォルト値が変更されます。
各項目を設定する
カスタマイズを行うときに指定すると思われるPassword Strength Preset = “Custom”の場合の設定例を下図に示します。

Password Strength Preset = “Custom”の場合の設定例

“Save（保存）”ボタンを押下し保存
必要に応じて”Test Your Password”ボタンを押下し想定通りのポリシーになっているかをチェック

2. 使用するパスワードポリシーの指定

メニュー > All（すべて） > Password Reset > Credentials Stores（資格情報ストア）をクリック
リストから”Local ServiceNow Instance”を選択
※ このリストにはServiceNowインスタンスに保持されている資格情報（アカウントなど）のメタ情報が管理されています。標準では自身のインスタンス自体に関する資格情報を表す”Local ServiceNow Instance”だけが存在します。

Credentials Storesより”Local ServiceNow Instance”を選択

“Enable password policy”項目にチェックが入っていることを確認した上で”Password policy”項目に前手順で作成したパスワードポリシーを指定

3. （オプション）除外パスワードリスト（ブラックリスト）の設定

ServiceNowが提供する除外パスワードリスト（ブラックリスト）の確認・再インストールおよび新たな文字列を追加します。なお、標準でもSmall(5000件)がインストールされているはずですので、あくまでオプションです。

メニュー > All（すべて） > Password Policy（パスワードのポリシー） > Exclusion List Managaement（除外リストの管理）を開く
インストールされているリストを確認する

必要に応じて再インストールや、アンインストールを行う
※ 一度アンインストールを行うと、Medium(50,000件)、Large(200,000件以上)も選択可能です。
※ 再インストールやアンインストールには、security_adminロールへ昇格が必要です。
メニュー > All（すべて） > Password Policy（パスワードのポリシー） > Excluded Passwords（除外パスワード）を開く
“New（新規）”ボタンを押下し新たな文字列を追加する

4. （オプション）パスワードポリシーに関するプロパティの設定

基本的には標準の状態を変更する必要はありませんが、重要だと思われるプロパティを紹介します。

メニュー > All（すべて） > Password Policy（パスワードのポリシー） > Properties（プロパティ）を開く
必要に応じてプロパティを設定する
（参考: Password policy properties）
※ 最低限下記2つを明示的に設定しておけばよいでしょう

アカウントロックアウト

アカウントロックアウトの設定を行うためには、まずはロジックのイメージを持っておくとよいです。ServiceNowではログインに成功すると”login”イベントが、失敗すると”login.failed”イベントが生成されます。そして、各イベントの生成に応じて起動されるビジネスロジックであるScript Actionが定義されています。

ログインが成功すると、”SNC User Clear”によって失敗回数がリセットされます。こちらは変更する必要はありません。

ログインが失敗すると”SNC User Lockout Check”または”SNC User Lockout Check with Auto Unlock”によって失敗回数がプラス1され、一定の値を超えるとロックアウトされます。”SNC User Lockout Check with Auto Unlock”は一定時間後にロックアウトを自動解除するようになっています。ロックアウトに関するポリシーを設定しない場合は両方を無効化（非アクティブ）にしておき、有効化する場合はいずれかを有効化（アクティブ）にし、対応するプロパティを設定します。手順は次の通りです。

ロックアウトに使うロジックの有効化
（オプション）ロックアウトに関するプロパティの設定

（参考: Specify lockout for failed login attempts）

1. ロックアウトに使うロジックの有効化

メニュー > All（すべて） > System Policy（システムポリシー） > Script Action（スクリプトアクション）を開く
“SNC User Lockout Check”、”SNC User Lockout Check with Auto Unlock”を検索する
「Active（アクティブ）」項目にチェックを入れ/外し、有効化/無効化を行う

“SNC User Lockout Check with Auto Unlock”を有効化する場合

2. （オプション）ロックアウトに関するプロパティの設定

“SNC User Lockout Check with Auto Unlock”はプロパティによってロックアウトまでの最大失敗試行回数と、ロックアウト解除までの時間（分）を指定することができます。

（参考: Managing failed login attempts (instance security hardening)）

プロパティの設定方法についてはこちらも併せて参照ください。

Multi-factor Authentication（多要素認証）

ローカル多要素認証は標準で有効化されており、user_admin, admin, security_adminロールを持つユーザに対して適用されるようになっています。

なお、過去この設定はオプションだったので、かなり前からServiceNowを使っている場合、プラグインが有効化されていない可能性があります。メニュー > All（すべて） > Multi-factor Authentication（マルチファクタ認証）が存在しない場合は、まずプラグインを有効化しましょう。

設定の手順としては下記です。

多要素認証のプロパティ設定
多要素認証を適用するロールの設定

なお、上述のように、多要素認証をより高度な条件、例えば企業外部のネットワーク（IPアドレス）からのアクセスの場合のみ適用するといった設定を行うためには、2023年Tokyoバージョン現在はオプションのプラグインとなっているAdaptive Authenticationが必要で、この設定については下記の記事にまとめています。