Yokohamaリリースから強制されるMFA認証を今すぐチェック！

社内業務に関するシステムを一元化して運用・管理できるクラウドサービス「ServiceNow」。
株式会社ＫＹＯＳＯでは、これまでの豊富な運用経験をもとに、ServiceNowの企画立案から運用・保守、内製化までトータルでサポートしています。

このたび、Yokohamaリリースにアップグレード（※１）したタイミングでMFA認証が強制されることになりました。
そこで、このブログではServiceNowにおけるMFA認証を解説します。
また、アップグレードするとどのような変化があるかもご紹介します。
アップグレード後の変化については、以下の2パターンを確認しました。

MFA認証未設定でYokohamaリリースにアップグレード
すでにMFA認証を設定済みでYokohamaリリースにアップグレード

※１　ServiceNowでは毎年2種類の主要なプラットフォームアップグレードが公開されています。
　　　アップグレードすることで強化された機能、パフォーマンス、セキュリティ、ユーザビリティ
　　　を利用できます。

前提条件：ServiceNowの環境
MFA 認証とは
YokohamaリリースでMFA認証が適用される対象
- インスタンス
- ユーザー
Yokohamaリリースへのアップグレード検証
- ●MFA認証未設定でYokohamaリリースへアップグレードした場合
- ●すでにMFA認証を設定済みでYokohamaリリースへアップグレードした場合
さいごに
参考

前提条件：ServiceNowの環境

作成　・・・　PDI
バージョン　・・・　Yokohama（XanaduからYokohamaにアップグレード）
操作　・・・　System Administrator (admin)

MFA 認証とは

「MFA」は「Multi-Factor Authentication（マルチ・ファクター・オーセンティケーション）」の略です。
「多要素認証」のことを言います。
ユーザー名とパスワードに加えてもう一つの情報を要求する認証方法となります。
そのため、ID、パスワードでログインする場合はワンタイムパスワードなどの認証も必要になります。

ServiceNowでは不正ログイン対策として、Yokohamaリリースにアップグレードしたタイミングで強制されることになりました。

MFAの検証手段

ServiceNow の MFA は、さまざまな検証手段をサポートしています。

認証アプリケーション
生体認証スキャナー
ハードウェアキー　　※別途プラグインを使用
パスキー
メール
SMS　　　　　　　　※別途プラグインを使用

※詳細な情報は製品ドキュメント（MFAの検証手段）をご参照ください。

MFA認証の機能構成

ServiceNowインスタンスにおけるMFA認証のアプリケーション名は「マルチファクター認証」となっています。
この「マルチファクター認証」では「ユーザーベースのマルチファクター基準」を使用してMFAログインが必要なユーザーを個別に選択できます。
また、「ロールベースのマルチファクター基準」を使用して特定のロールに割り当てられたすべてのユーザーに対してMFAログインを適用します。

別機能の「適応認証」の「IPフィルター基準」や「グループフィルター基準」を使用することでユーザーのIPアドレスやグループに対しても設定できるようになります。
つまり、「適応認証」と組み合わせることで、よりビジネスニーズにあった設定が行えます。

＜機能の概要＞

マルチファクター認証
MFA認証が必要なユーザーとロールを設定します。
適応認証
ユーザーのIPアドレス、グループに基づき、ユーザーおよびAPIのインスタンスへのアクセスを制限します。

MFA認証の設定

ServiceNowでは4STEPで設定を行うことができます。

1 　システムプロパティの有効化
2 　フィルター基準の設定
3　認証ポリシーの設定
4　MFAコンテキストの設定

STEP1　システムプロパティの有効化

マルチファクター認証を有効にします。
① [すべて] > [マルチファクター認証] > [プロパティ]へ移動します。
② [マルチファクター認証を有効にする]のチェックをONにします。

グループやIPアドレスでの設定を行う場合は、適応認証のプロパティも有効にします。
① [すべて] > [適応認証] > [認証ポリシー] > [プロパティ]へ移動します。
② [認証ポリシーを有効にします]のチェックをONにします。

※Yokohamaリリースではマルチファクター認証、適応認証の両方が有効になります。

マルチファクター認証のプロパティ画面より抜粋　／　適応認証のプロパティ画面より抜粋

STEP2　フィルター基準の設定

フィルター基準 (ポリシー入力) は適応認証機能にあります。
設定できるタイプは５つありますが、標準で使用できるフィルター基準は３種類になります。

IPフィルター基準
ロールフィルター基準
グループフィルター基準
場所のフィルター基準　　　　　　　　※ゼロトラストアクセス機能で使用可能（有料ライセンス）
IDプロバイダー属性のフィルター基準　※ゼロトラストアクセス機能で使用可能（有料ライセンス）

既存のフィルター基準を使用する場合はSTEP4へお進みください。
新規でフィルター基準を作成する場合は以下の手順で作成します。
例：グループフィルター基準
① [すべて] > [適応認証] > [フィルター基準] > [グループフィルター基準]へ移動します。
② [新規]ボタンをクリックします。
③ [名前]を入力します。
④ [説明]を入力します。
⑤ [基準のグループ]にグループを設定します。
　「新しい行を挿入」をダブルクリックすると編集できます。

⑥ [送信]ボタンをクリックします。

STEP3　認証ポリシーの設定

認証ポリシーは、指定されたポリシー条件に基づいて認証要求を評価し、ポリシー条件評価の出力に応じてアクセスを許可または拒否します。
既存またはビルトイン認証ポリシー（※１）を使用する場合はSTEP4へお進みください。
新規で認証ポリシーを作成する場合は以下の手順で作成します。
① [すべて] > [適応認証] > [認証ポリシー] > [すべてのポリシー]へ移動します。
② [新規]ボタンをクリックします。
③ [名前]を入力します。
④ [説明]を入力します。
⑤ ヘッダー部を右クリックして[保存]をクリックします。
⑥ 関連リストの[ポリシー入力]タブにて[編集]ボタンをクリックします。
⑦ フィルター基準（※２）を選択し、[保存]ボタンをクリックします。

⑧ 関連リストの[ポリシー条件]タブにて[編集]ボタンをクリックします。
⑨ 条件を設定します。

[(=) TRUE]
フィルター基準が満たされている場合、MFA認証の対象となります。
[(=) FALSE ]
フィルター基準が満たされていない場合、MFA認証の対象となります。

⑩ [送信]ボタンをクリックします。　
　条件設定後に[ポリシー入力]タブのフィルター基準が使用済み＝trueとなります。

⑪ [更新]ボタンをクリックします。

※１：ビルトイン認証ポリシー
　　　詳細は製品ドキュメント：認証ポリシーをご参照ください。
※２：フィルター基準
　　　フィルター基準はSTEP2で作成したものや汎用的なフィルター基準から選択できます。
　　　詳細は製品ドキュメント：フィルター基準をご参照ください。

STEP4　MFAコンテキストの設定

MFAコンテキストでポリシーを設定します。　
① [すべて] > [マルチファクター認証] > [MFA コンテキスト]へ移動します。もしくは、
　[すべて] > [適応認証] > [認証ポリシーのコンテキスト] > [MFA コンテキスト]へ移動します。

② [デフォルトポリシー]で以下のいずれかを選択します。
　・ステップアップMFAポリシー
　　定義されたポリシー条件が true と評価された場合に MFA がユーザーに強制されます。
　・ステップダウンMFAポリシー
　　原則 MFA を適用します。
　　定義されたポリシー条件が true と評価された場合にかぎり、MFA はユーザーに強制されません。
　　つまり、定義された条件に合致したユーザー以外全員MFAが強制されます。

③ [ステップアップMFAポリシー]／[ステップダウンMFAポリシー]で定義済みの認証ポリシーを選択します。
　デフォルト値：Yokohamaリリースでは「Enforce MFA for non-SSO logins」、
　　　　　　　　Xanaduまでは「Step-Up MFA Policy」となっています。
　カスタマイズした認証ポリシーを使用する場合は事前にポリシーを作成しておきます。（STEP3）

④ 関連リストの[ポリシー入力]タブの[フィルター基準]より、フィルター基準を編集できます。
　フィルター基準の名前をクリックすると、フィルター基準の編集画面へ遷移します。
　編集画面は設定する基準によって異なります。

補足

マルチファクター認証の設定では適応認証機能と組み合わせることでより機能が強化されます。
例えば、認証ポリシーやフィルター基準は適応認証機能の一部になります。
そのため、マルチファクター認証と適応認証のどちらで何が設定できるかを簡単にまとめました。
MFAコンテキストについてはマルチファクター認証と適応認証の両方から設定できます。

YokohamaリリースでMFA認証が適用される対象

YokohamaリリースでMFA認証が強制されますが、対象外となることもあります。
例えば、MFAコンテキストポリシーがすでに有効な場合や、外部ユーザー、SSOでのログインユーザーは対象外となっています。
インスタンスとユーザーについて、対象／対象外を以下にまとめました。

インスタンス

対象
MFAポリシーを有効にしていない本番/非本番インスタンスのローカル認証、LDAP認証、モバイルアプリ
対象外
すでに適応認証のMFAコンテキストポリシーが有効な場合

ユーザー

対象
すべての社内ユーザー
対象外
外部ユーザー (snc_external ロールを持つユーザー)、SSO (SAML、OIDC 、証明書ベースの認証など)
外部連携やAPIログイン

Yokohamaリリースへのアップグレード検証

●MFA認証未設定でYokohamaリリースへアップグレードした場合

アップグレード後のインスタンスの状態

Yokohamaリリースへのアップグレード後の変化について確認しました。ポイントは3点です。

１．トップページへのMFA認証に関するメッセージの表示

2種類のメッセージがログイン後のトップページ画面に表示されました。

＊メッセージ「セキュリティ更新：MFA実装」　

MFA認証が有効化されたことをお知らせするメッセージです。
Admin権限のユーザーのみ表示されます。
「Acknowledge ➚」リンクをクリックするとシステムプロパティの「glide.authenticate.multifactor.enforcement.acknowledged」の設定画面が開きます。
遷移先の設定画面にはナレッジ記事（ KB1700938 ）のリンクが表示されています。
システムプロパティの値をTrueにするとこのメッセージが非表示になります。

＊メッセージ「重要なセキュリティ更新：」

MFA認証を適用するまでの猶予期間についてのメッセージです。
全ユーザーに表示されます。
ユーザーがログインした日を1日目として30日間はMFA認証の登録をしなくてもID、パスワードのみでログインできます。
「こちらをクリックしてください。」リンクをクリックすると製品ドキュメントのMFA認証のページが開きます。
各ユーザーのログインに関係なくアップグレード後、90日経過するとMFA認証の登録を行わないとログインができなくなります。
猶予期間が十分ではない場合、システムプロパティで猶予を伸ばすことが可能です。
　（ユーザーごとの猶予を90日まで延長可能、全ユーザーの猶予を最大270日に変更可能）

２．マルチファクター認証の有効化

Yokohamaリリースではマルチファクター認証と適応認証の2つの機能が有効化されました。
マルチファクター認証のプロパティ画面より抜粋　／　適応認証のプロパティ画面より抜粋

プロパティの確認や設定手順は「MFA認証とは」の「設定手順 STEP1 」をご参照ください。

３．MFAコンテキストのポリシーの変更

ステップアップMFAポリシーが「Enforce MFA for non-SSO logins」に変更されました。
Xanaduまでは「Step-Up MFA Policy」が設定されていました。
違いとして、「Enforce MFA for non-SSO logins」にはフィルター基準が２つ追加されており、
追加されたフィルター基準を設定してMFA認証の対象外を定義することができるようになっています。

＜関連リスト＞

＊ポリシー入力
[ステップアップMFAポリシー]で選択されているポリシーのフィルター基準の一覧が表示されます。
Yokohamaリリースでは「Enforce MFA for non-SSO logins」が選択されています。
この認証ポリシーには4つのフィルター基準が設定されています。
そのうち２つが今回のリリースで追加されたMFA認証の対象外を設定するフィルター基準です。

Has MFA exempted role
Is a member of MFA exempted group

＊ポリシー条件

ポリシー条件ではアクセスの許可または拒否を設定します。
条件を満たす場合にMFA認証の対象となります。

[(=) TRUE]
フィルター基準が満たされている場合、MFA認証の対象となります。
[(=) FALSE ]
フィルター基準が満たされていない場合、MFA認証の対象となります。

＊MFA要素ポリシー

デフォルトではEMAILが設定されています。
※SMSを使用する場合は別途、プラグインのインストールが必要です。
　プラグインの詳細は製品ドキュメント：SMSをMFA要素として設定をご参照ください。
MFA認証として登録すると、ユーザーレコードに関連付けられたメール（EMAIL）／携帯電話番号（SMS）
に OTP（ワンタイムパスワード）が送信されます。

ユーザーのMFA認証要素の登録

MFA認証の登録をユーザー自身で行います。
ユーザーはログイン後に表示されるメッセージに従い、ユーザープロファイルから設定します。

MFA認証要素は複数登録可能です。
また、登録できる認証ツールも複数あります。
詳細は製品ドキュメント「マルチファクター認証 (MFA) の使用」をご参照ください。

●すでにMFA認証を設定済みでYokohamaリリースへアップグレードした場合

Xanaduで行ったMFA認証の設定

本ブログの検証で使用しているPDIでは、グループフィルター基準を設定しました。
そのため、対象のグループに所属するユーザーのみがMFA認証の対象になっています。

アップグレード後のインスタンスの状態

「MFA認証未設定でYokohamaリリースへアップグレードした場合」と同様に、MFA認証対象／対象外のユーザーへの影響や画面や設定内容の変化を確認しました。

１．トップページへのMFA認証に関するメッセージの表示

　　ログイン後にMFA認証に関するメッセージ表示はありませんでした。
　　検証で使用しているPDIではMFA対象ユーザーは一部という設定でしたが、
　　メッセージは表示されませんでした。
　　対象ユーザーの人数や割合に関係なくMFA認証が設定済みの場合はメッセージは表示されないようです。

２．マルチファクター認証の有効化

　　有効化に関するプロパティに変化はありませんでした。
　　その他、マルチファクター認証のプロパティ画面の表示内容に1点変更点がありました。
　　「ユーザーがマルチファクター認証の設定をバイパスできる回数」が表示されなくなりました。
　　（Yokohamaリリースでこのプロパティの値が0になっていましたのでその影響と思われます。）
　　画面上からは消えていますが、システムプロパティとしては残っています。
　　値を変更する場合はシステムプロパティの画面から直接設定することになります。
　　適応認証のプロパティ画面に変更はありませんでした。

３．MFAコンテキストのポリシーの変更

　　認証ポリシーは「Step-Up MFA Policy」のままで変更はありませんでした。
　　一方で、ポリシーのリストには「Enforce MFA for non-SSO logins」が追加されていました。
　　現在MFA認証を設定済みの場合もこちらのポリシーが選択可能になります。

４．ログイン

　　MFA認証対象外のユーザーはこれまでどおりID、パスワードでのログインができました。
　　また、既存のMFA認証対象のユーザーも変化はありませんでした。
　　結論として、既存ユーザーへの影響はありませんでした。

さいごに

セキュリティ強化のため、Yokohamaリリースより、原則として全社内ユーザーにMFA（多要素認証）を適用します。
インターネット経由のシステムでは、従来のID・パスワード認証の脆弱性が問題視されています。MFA認証の導入により、不正アクセスやアカウント乗っ取りのリスクを効果的に低減できます。
今回の導入を機に、MFAの適用範囲などについて、改めてご確認・ご検討いただくことを推奨いたします。

最後まで閲覧いただき、ありがとうございました。
あなたにとって有益な情報を提供できたのであれば、大変嬉しく思います。

参考

投稿者プロフィール

S H: 主にシステム開発の仕事に携わってきました。
[HTML/CSS/JavaScript/C#/VB.NET など]
2023年より開発業務と並行してServiceNowの学習を始めました。
CIS資格取得にも取り組んでおり、さまざまなServiceNowの研修を通して知識やスキルを磨いています。

保有資格
- ServiceNow Certified System Administrator
- ServiceNow Certified Application Developer
- ServiceNow Certified Implementation Specialist - Customer Service
Management
- ServiceNow Certified Implementation Specialist - IT Service Management

ブログ

Yokohamaリリースから強制されるMFA認証を今すぐチェック！

前提条件：ServiceNowの環境