メインコンテンツへスキップ
見出し画像

ServiceNowのログインはOOTBでどこまで守られている？ パスワードポリシーとMFAを実機で読む

    ServiceNow観察日記


    セキュリティ監査で「パスワードの要件は」「多要素認証は入っているか」と聞かれたとき、ServiceNow のどこを見れば答えられるでしょうか。素の状態でもポリシーは設定済みで、除外パスワードが5,000件入っていて、MFAのプロパティは有効になっています。ただし実際にMFAを使っているユーザーは0人でした。設定と実態のずれを実機で確かめます。

    検証環境：Australia PDI / OOTB / 2026-08-13 確認

    結論：パスワードは4段構えで守られている。MFAは「有効」だが誰も使っていない

    パスワード側は素の状態でもかなり作り込まれています。文字種と長さのポリシーがあり、よく使われるパスワード5,000件の除外リストが有効で、過去10世代との照合も設定されています。

    一方 MFA は、プロパティもプラグインも有効なのに、ユーザー側で有効にしている人が 638人中0人。MFA Dashboard は登録率0%、特権管理者のうち22人がMFA未設定、パスワードだけのログインが100%と表示していました。

    「機能が有効かどうか」と「実際に守られているかどうか」は別です。この記事では、その差がどこに出るかを画面で追います。

    パスワードポリシーは、そもそも何を決める仕組みなのか

    ログインの安全性は、大きく3つの層で決まります。

    1つ目がパスワードそのものの強さ。何文字以上か、どんな文字を混ぜるか、使い回していないか。ここを決めるのがパスワードポリシーです。

    2つ目がパスワード以外の要素。持ち物（スマートフォンのアプリ）や生体情報を足して、パスワードが漏れても入られないようにする。これが多要素認証（MFA）です。

    3つ目が入口そのものの制御。ログインを何回失敗したらロックするか、非アクティブなユーザーを弾くか、SSOに寄せるか。

    ServiceNow はこの3層すべてに設定を持っています。順に見ていきますが、まず押さえておきたいのは、パスワードポリシーが「1レコード」で表現されていることです。項目ごとにバラバラの設定が散っているわけではありません。password_policy テーブルの1行に条件がまとまっています。

    位置づけ：Password Reset とは別のもの

    紛らわしいのが Password Reset です。あちらは「忘れた人を助ける」仕組みで、本人確認の方法やリセットの流れを持っています。仕組みはPassword Reset：ログインできない人を、ログインさせずに助けるにまとめました。

    この記事で扱うパスワードポリシーは、リセットするときも通常の変更のときも共通で適用される「合格条件」のほうです。

    認証（誰であるかを確かめる）を通ったあとは、認可（何を見せるか）の話に移ります。そちらはServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどるとAccess Analyzer：「見えない」の理由を層で切り分けるで扱いました。この記事が見るのは、その手前にある「入口の鍵」だけです。

    パスワードポリシーは REST から読めない

    調べ始めていきなり足止めを食いました。password_policy を REST で取ろうとすると、admin の資格情報でも弾かれます。

    HTTP 403: {"error":{"message":"User Not Authorized",
           "detail":"Failed API level ACL Validation"}}

    同じ理由で user_multifactor_auth も 403、pwd_history も 403（Insufficient rights to query records）でした。

    セキュリティの中枢にあたるテーブルは、テーブルAPI経由での読み取りそのものが止められているということです。監査資料を自動収集しようとしてスクリプトを書くなら、この3つは画面から手で拾う前提になります。

    読めたのは blacklisted_password だけでした。

    OOTBのポリシーは「Default Strong」

    画面で開くと、ポリシーは2件登録されていました。


    画像

    行頭に緑のドットが付いているのが Default Strong です。もう1件が Medium。


    画像

    中身はこうなっていました。


    画像

    Default Strong は 8〜100文字で、大文字・小文字・数字・記号を各1文字以上。記号まで必須にしているのは、素の状態としてはしっかりしたほうです。

    Medium のほうが最小長は長い

    名前だけ見ると Default Strong のほうが厳しそうですが、最小長は Medium が12文字で、Default Strong の8文字より長い。

    Strong は「文字種を4つとも必須にする」方向、Medium は「長さで稼ぐ」方向という設計に見えます。名前の強弱と数字の大小が一致しないので、選ぶときは中身を開いて確かめたほうが安全です。

    最大長は、見る場所で数字が違う

    もう1つ引っかかったのが最大長です。


    画像

    実機のレコードと辞書の既定値は 100。ところが公式のフィールド説明には「Default is 40」と書かれている。フォーム内の Password Policy Script のコメント例も 40 で、Medium ポリシーの値も 40 です。

    100 が現在の実際の値であることは画面で確認できます。ただ、社内標準を決める会話で「既定は40だ」と言う人が出てきても、その人はドキュメントを読んでいるだけかもしれません。どちらの数字も製品の中に存在します。

    公式説明を読むと、使っていない機能が見える

    sys_documentation のフィールド説明には、フォームに並んでいる項目の意味が書かれています。


    画像

    とくに実務で効きそうなものを引きます。

    seq_length_threshold：Minimum length of sequence of characters that would be disallowed. For example this value is 4, a sequence of 4 or more contiguous and sequential letters like abcd, 56789, zxcvbn, 12#$5 e.t.c., are not allowed

    連続した文字列を禁止する設定です。abcd や 56789、さらに zxcvbn のようなキーボード配列まで例に挙げているのが面白いところ。

    repetition_length_threshold：Minimum number of repetitions of a character that would be disallowed. For example if this value is 4, 4 or more contiguous repeated letters like aaaa, 5555, sssss, e.t.c., are not allowed

    同じ文字の連続を禁止する設定。

    disallow_user_data：Checks password against user data including firstname, lastname, username, company

    姓名・ユーザー名・会社名をパスワードに含めさせない設定です。

    この3つは、OOTBでは値が入っていません（連続・繰り返しのしきい値は0、ユーザーデータ照合はオフ）。文字種の要件だけ厳しくして、こちらは素通りという状態です。要件定義のときに真っ先に足す候補になります。

    よく使われるパスワード5,000件が最初から禁止されている

    blacklisted_password（Excluded Passwords）を開くと、5,000件並んでいました。


    画像

    中身は !qaz1qaz、0987654321a、007james のような、流出パスワード集でよく見る文字列です。作成者はすべて system、作成日時も全件同じでした。

    有効化しているのは glide.enable.blacklist_password = true で、公式説明は Enable to validate user password against Excluded Passwords。

    「複雑さの要件は満たすが、世界中で使い回されている」パスワードを止める仕組みが最初から入っているわけです。ポリシーの数字だけ見ていると気づきません。

    この5,000件は編集できる普通のテーブルなので、自社で禁止したい単語を足せます。サービス名、社名の略称、部署のコード。その組織でだけ使われがちな文字列を入れておくと効きます。逆に5,000件のままで運用するなら、「既定の除外リストを採用している」と監査資料に一文書けるという使い方もあります。

    件数が5,000ちょうどというのは、元になったリストをそのまま取り込んだ形に見えます。作成日時が全件同じで、作成者が system になっているのも、まとめて投入された痕跡です。

    パスワードが弾かれる4つの関門

    ここまでを整理すると、素のインスタンスで新しいパスワードを設定するとき、通る関門は4つあります。


    画像

    3つ目の過去との照合は password_reset.history.limit = 10 で、公式説明は The number of the previous passwords to be checked in history.。直近10回分と同じものは使えません。


    画像

    このプロパティ群には、他にも運用で効くものが入っています。password_reset.request.max_attempt = 3（リセットの失敗許容回数）、max_attempt_window = 1440（超えたときの待ち時間・分）、sms.max_per_day = 10（SMSコードの1日上限）。1440分＝24時間なので、3回間違えると翌日まで待たされる計算です。

    ロックアウトの状態も見られる

    sys_user にはログイン失敗の記録があります。failed_attempts（失敗回数）と locked_out（ロック中か）です。


    画像

    素のPDIでも locked_out = true が2件ありました。デモデータとして最初から入っている状態です。「なぜかログインできない人がいる」ときに最初に見る場所がここになります。

    入口そのものにも、いくつかスイッチがある

    パスワードの中身とは別に、「そもそもログインさせるか」を決めるプロパティがあります。素の状態の値を並べておきます。

    glide.authenticate.only.allow.active.user.login は true。非アクティブにしたユーザーは、パスワードが合っていてもログインできません。退職者の処理でユーザーを無効化する運用は、この1行が前提になっています。

    glide.user.show.password.field は false。公式説明は Enable to show the password field on the sys_user Form. です。つまり 管理者がユーザーのフォームからパスワードを直接見たり書き換えたりする欄が、既定では隠されている。パスワードを配る運用をしたい現場が最初につまずくところです。

    glide.authenticate.mutual.enabled は true（証明書ベース認証の受け入れ）。一方 glide.authenticate.cert.ui.login.enabled は false なので、ログイン画面に「PIV/CAC でログイン」の選択肢は出ません。受け口はあるが画面には出していない、という状態です。

    glide.authenticate.auth.policy.enabled は false。Authentication Policy という仕組みがありますが、素では動いていません。

    この4つは、どれも1行のプロパティで挙動が変わります。 変更するとログインできる人の範囲が動くので、更新セットに含める前に検証環境で試す対象です。

    MFAはプロパティもプラグインも有効になっている

    ここからが本題の後半です。まず設定側から。


    画像

    glide.authenticate.multifactor は true。公式説明はそのまま Enable Multi-factor authentication です。周辺のプロパティも一通り揃っています。


    画像

    setup.bypass.count = 0 は「設定を後回しにできる回数がゼロ」、self_enrolment_period = 0 は「自己登録の猶予日数がゼロ」。猶予を与えない設定になっています。

    プラグイン側も見ておきます。


    画像

    com.snc.integration.multifactor.authentication は Active で、公式説明は Activate this plugin to set up Multifactor authentication on the instance.。一方 com.snc.authentication.sms_mfa（SMSでのMFA）は Inactive でした。SMSを使いたい場合は追加で有効化が要ります。

    それでもMFAは1人も使っていない

    設定は整っている。では実際は、と sys_user を見ると話が変わります。


    画像

    enable_multifactor_authn が true のユーザーは 0人。638人全員が false でした。

    専用のダッシュボードを開くと、もっとはっきりします。


    画像

    • Users enrolled in Multi-factor Authentication (MFA)：0%

    • Privileged admins without Multi-factor Authentication (MFA)：22

    • Multi-factor Authentication (MFA) factors used：No data available

    • User-password logins without Multi-factor Authentication (MFA)：100%


    画像

    プロパティを true にしただけでは、誰も守られません。 ユーザー側の enable_multifactor_authn が立って、実際に認証アプリを登録して初めて効きます。この2段階を混同すると、「MFAは有効です」と報告した中身が空になります。

    右側の「Learn about MFA」パネルには Guided Setup への導線があり、Helps you configure MFA and prepare for the MFA enforcement mandate introduced in the Yokohama release. と書かれていました。MFAの強制がリリースで進んでいることを製品側が案内しています。

    SSOに寄せると、ここまでの設定は効かなくなる

    最後に前提の話をひとつ。ここまで見てきたパスワードポリシーもMFAも、ServiceNow が自前でパスワードを検証する場合の話です。

    SAML や OIDC で外部の IdP に認証を任せると、パスワードの長さも文字種も IdP 側の設定で決まります。ServiceNow の password_policy は使われません。MFA も IdP 側のものが効きます。

    だから監査で「パスワード要件は」と聞かれたとき、まず「ローカル認証か SSO か」を確認しないと、答える場所を間違えます。SSO の環境で password_policy の値を見せても、それは実際には適用されていない数字です。

    外部連携側の認証設定については、OAuth設定はtypeで役割を見分ける（oauth_entity）で oauth_entity の使い分けを扱いました。API から叩かれたときの記録の残り方はServiceNowのAPI呼び出しは誰がいつ叩いたか分かる？にまとめています。

    実機を見て気づいたこと

    セキュリティの中枢テーブルは、admin でも API から読めない

    password_policy user_multifactor_auth pwd_history の3つが REST で 403 になったのは想定外でした。Failed API level ACL Validation というメッセージからすると、ロールの不足ではありません。テーブルAPIそのものに対する制限だと読めます。

    監査の証跡を自動で集める仕組みを作るなら、ここは手作業か別の経路が要ります。「REST で全部取れる」と見積もると、後から差し戻しになります。

    名前の強弱と、数字の厳しさは一致しない

    Default Strong の最小長が8で、Medium が12。名前で判断すると逆の結論になります。

    同じことが最大長でも起きていて、公式のフィールド説明は40、実機は100。製品の中に複数の「既定値」が同居しているので、議論のときは必ず画面の値を見せるようにしたほうが早いです。

    ダッシュボードが「特権管理者22人」を名指しできている

    MFA Dashboard の Privileged admins without MFA は、単なる合計ではなく権限の強いユーザーに絞った数字です。全体の登録率0%より、この22という数字のほうが現場では刺さります。

    自分で調査スクリプトを書く前に、この画面が出す数字で足りるかを確認する価値があります。

    実務では何に使えるか

    監査の質問に、画面のスクリーンショットで答える

    「パスワード要件は」と聞かれたら password_policy のフォーム、「多要素認証は」と聞かれたら MFA Dashboard。この2枚で大部分は答えられます。

    数字を口頭で答えるより、適用中のポリシーが1レコードで表示されている画面を見せるほうが早く終わります。

    導入前に足す設定を3つに絞る

    OOTBで未設定なのは、連続文字（seq_length_threshold）、繰り返し文字（repetition_length_threshold）、本人情報の照合（disallow_user_data）でした。

    文字種の要件はすでに厳しいので、追加で入れるならこの3つという判断ができます。ゼロから要件を洗い出すより早い。

    MFAは「有効化」と「登録」を分けて計画する

    プロパティを true にする作業と、ユーザーに登録してもらう作業は別物です。MFA Dashboard の登録率が上がらない限り、実態は変わりません。

    まず特権管理者から潰す、という順番が現実的です。この環境では22人でした。setup.bypass.count と self_enrolment_period が両方0なので、猶予を設ける場合は明示的に変更が要ります。

    「ログインできない」の切り分け手順を作っておく

    sys_user.locked_out と failed_attempts、そして password_reset.request.max_attempt = 3 / max_attempt_window = 1440。この組み合わせを知っていれば、「3回失敗して24時間待ち」の状態かどうかを即断できます。


    画像

    リセットの流れ自体は Password Reset Process で定義されています。問い合わせを受けたとき、どのプロセスに乗る人なのかをここで確かめられます。


    画像

    なお glide.security.forgot_password.display.link = true なので、ログイン画面に「パスワードを忘れた方」のリンクが出ます。自己解決してもらう導線は最初から有効です。

    個人情報を扱う画面と合わせて棚卸しする

    ログインの強度は、その先に何が見えるかとセットで評価されます。個人情報の扱いを絞る設定はServiceNowでAIに個人情報を渡さない設定はどこにある？で扱いました。

    「誰が入れるか」と「入った人に何を見せるか」を同じ資料にまとめると、監査の指摘が減ります。ロールの包含関係で想定外の権限が付く話はServiceNowで付けたロールが想定外の権限を含んでいた理由にあります。

    なお glide.security.forgot_password.display.link = true なので、ログイン画面に「パスワードを忘れた方」のリンクが出ます。自己解決してもらう導線は最初から有効です。

    用語

    password_policy：パスワードの合格条件を1レコードで持つテーブル。画面名は Password Policies。REST からは読めない。

    Excluded Passwords（blacklisted_password）：使わせないパスワードの文字列リスト。OOTBで5,000件入っている。

    enable_multifactor_authn：sys_user のフィールド。ユーザーごとにMFAを使うかどうかを持つ。プロパティとは別。

    MFA Dashboard：MFAの登録率と、未設定の特権管理者数を見る画面。/now/mfa-dashboard/home。

    locked_out / failed_attempts：sys_user のフィールド。ログイン失敗の回数と、ロック中かどうか。

    Authentication Policy：glide.authenticate.auth.policy.enabled で切り替える認証ポリシー機構。この環境では false。

    自分の環境で確認するときのURL

    自分のインスタンス名に続けて開きます。

    • パスワードポリシー：/password_policy_list.do

    • 除外パスワード：/blacklisted_password_list.do?sysparm_query=ORDERBYpassword

    • MFAのプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.authenticate.multifactor%5EORDERBYname

    • MFA Dashboard：/now/mfa-dashboard/home

    • MFA有効ユーザーの分布：/sys_user_list.do?sysparm_query=GROUPBYenable_multifactor_authn

    • ロックアウト中のユーザー：/sys_user_list.do?sysparm_query=locked_out%3Dtrue

    • パスワードリセット系プロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHpassword_reset%5EORDERBYname

    • Password Reset Process：/pwd_process_list.do

    • MFA関連プラグイン：/v_plugin_list.do?sysparm_query=idLIKEmultifactor%5EORidLIKEmfa

    引用した公式説明を自分で開く

    この記事で引用した説明文は、ServiceNow が製品に同梱しているものです。次のURLを開けば、引用元の記述に直接あたれます。

    • パスワードポリシーのフィールド説明（引用元）：/sys_documentation_list.do?sysparm_query=name%3Dpassword_policy%5EhintISNOTEMPTY

    • プロパティの説明（引用元）：/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.authenticate%5EdescriptionISNOTEMPTY

    • プラグインの説明（引用元）：/v_plugin_list.do?sysparm_query=descriptionISNOTEMPTY%5EidLIKEmultifactor

    • MFA Dashboard 内の Guided Setup 案内：/now/mfa-dashboard/home の右パネル

    検証範囲とおことわり

    Australia の PDI（OOTB）で 2026-08-13 に確認しました。件数はこの環境の実測値です。

    設定は一切変更していません。 パスワードを実際に変更してポリシーが弾くかどうかは試しておらず、フォームの Test Your Password も押していない状態です。MFAを1ユーザーで有効にしてログインを試すこともしていません。確認したのは設定値と画面の表示までで、動作そのものは追っていない範囲になります。

    user_multifactor_auth と pwd_history は REST が 403 だったため件数を取れておらず、画面も開いていません。

    ロックアウトされていた2件が誰で、なぜロックされたのかは追っていません。個人が特定できる情報なので画面にも載せていません。

    Medium ポリシーがどの条件で適用されるのかも調べていません。一覧に2件あることと、それぞれの値を確認しただけです。

    SSO（SAML / OIDC）を使う場合、パスワードポリシーもMFAも ServiceNow 側では効かなくなります。この記事はローカル認証の話です。

    本番環境ではプラグインの導入状況もユーザー数も違います。この記事の数字は素のPDIの状態です。

    関連記事

     
     

    ServiceNow観察日記

     
     
    ServiceNowのPDI（Personal Developer Instance）を実機で観察して、Noteに記事を書いています 実装・運用・教育の現場視点で淡々と記録中です リクエストがあればその記事も書きます 個人の観察日記です

    あなたへのおすすめ