[Brazil調査] Access Findings：アップグレード後のセキュリティ点検を日次で行う仕組み
メジャーアップグレードの直後に、設定のどこに弱点が残っているかを人手で洗い出すのは大変な作業です。ACL は数万件あり、利用者とロールの付与も別々に確認しなければなりません。Access Management Console には、この点検を日次で行う Access Findings の仕組みがあります。
ベースの Access checks が24時間ごとに設定を調べ、見つかった弱点を Access Findings に一覧します。Brazil にアップグレードした PDI で、実際に何が出ているかを開いて確かめました。
検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認
画面で確かめた要点
Access Management Console の Findings に、アップグレード後の PDI で38件が出ていた
内訳は 2-High が31件、3-Moderate が7件
31件はすべて「ACLs with Entirely Invalid Roles」（参照するロールがすべて存在しない ACL）
残りは Dormant User Account が4件、Users with Direct Role Assignments が3件
Access checks は Suite Check として9件あり、画面の説明は「24時間ごとに実行」
Run all checks のボタンは押していない。表示は日次実行の結果
Access checks と所見の関係
Access checks と Access findings の役割分担
公式ドキュメントは、Access checks と Access findings を次のように分けています。
Access checks are the security definitions and logic that run in the background. ... Access findings are the actionable records generated when an Access check detects a violation.
（訳：Access checks は裏で動くセキュリティの定義とロジック。Access findings は、チェックが違反を検出したときに作られる、対応すべきレコード）
1つのチェックが、同じ弱点を持つレコードの数だけ所見を作ります。解消すると所見は Resolved になります。
公式の例では、チェックが「クライアントから呼べる Script Include に適切な ACL があるか」と問います。所見は「Script Include の UpdateAllKnowledge に ACL がない」という答えです。
画面の開き方と必要なロール
画面の開き方は次のページにあります。必要なロールは admin です。
コンソール全体の説明では、Overview、Access findings、Access analyzer の3つのタブに分かれています。コンソールを使うロールは access_analyzer_admin と user_admin が挙がっています。
引用元：Explore Access management console
引用元：Use Access management console
Brazil での変更点
Access Findings の日次チェックは Brazil の新機能ではありません。Australia のリリースノートに、ベースの Access checks 8件を日次で実行すると書かれています。Brazil の公式ドキュメントでは、新機能の項ではなく「About Access Management」で説明されています。
差分ノートの Access Management には、strict deny の変更が1行だけあります。無効なロールしか持たない ACL を厳格に拒否する動作で、アップグレードしたインスタンスは glide.security.acl_with_invalid_roles_strict_deny を設定して有効にする仕様です。
引用元：Access Management release notes
Access Management の全体像は、次のページにまとまっています。
Access Management Console の Overview
メニューとロール
Security Center の Access Management メニューに、Access Management Console と Access Findings が並んでいます。そのほかに Access Analyzer Queries と Access Simulator もあります。メニューを使えるロールは admin、access_analyzer_admin、user_admin です。
Overview タブの表示内容
コンソールを開くと、左に Findings のドーナツ、中央に Access Analyzer の評価フォーム、右に参考資料が見えます。①のドーナツが38件の内訳です。②の上部のタブ行から Access findings と Access analyzer に移れます。
Access Analyzer は、特定の利用者が表や項目を読めるかを評価する別の機能です。所見の一覧は Access findings のタブにあります。Access Analyzer の使い方は、公式ドキュメントにまとまっています。
引用元：Access Analyzer
所見の内訳と ACL の31件
一覧の列とタブ
Access findings のタブを開くと、Open が38件でした。Muted と Resolved のタブも並んでいます。
列は Number、Check、Priority、Status、Source の5つです。
Check でグループ化した内訳
Check でグループ化した画面が次です。
グループごとの件数を文字でも書き出します。
ACLs with Entirely Invalid Roles：31件（2-High）
Dormant User Account：4件（3-Moderate）
Users with Direct Role Assignments (Bypassing Groups)：3件（3-Moderate）
ロールが全部無効な ACL の意味
31件の Source は「Access Control: sys_cs_conversation_document」のように、ACL の対象の表名が付いた形です。ロールが1つも存在しない ACL は、設定の見た目では制限されているのに、誰も条件を満たせない状態になります。公式の ACL トラブルシューティングも、以前は使えたオブジェクトに入れなくなったときの確認先として、Access Findings の Access checks を挙げています。
引用元：ACL troubleshooting reference
公式のリリースノートでは、ロールがすべて存在しない ACL を厳格に拒否する設定が説明されています。新規インスタンスでは既定でオンです。アップグレードした場合は、プロパティで有効にします。
この PDI で名前を指定して調べました。プロパティ glide.security.acl_with_invalid_roles_strict_deny のレコードは sys_properties に見つかりませんでした。
アップグレード後の環境でこの設定をオンにする前に、まず31件の一覧で影響する ACL を見ておきます。
Access checks の一覧
9件の Suite Check
Access checks の画面には Suite Check が9件並び、条件は「Suite is Access Auditor」です。冒頭に「The following checks produce findings and are ran every 24 hours.」とあります。右上の Run all checks で手動実行もできますが、今回は押していません。
画面で見えたチェックを、優先度つきで書き出します。
Inactive Users with Assigned Roles：4-Low
Dormant User Account：3-Moderate
Access controls on UI Pages：2-High
External users with access to classified data：1-Critical
Access controls on Tables：2-High
Users with Direct Role Assignments (Bypassing Groups)：3-Moderate
画面の見方
①は左のメニューで、Access findings と Access checks を行き来できます。②の各行にはチェックの説明が書かれており、対応の判断材料になります。残り3件のチェック名は、一覧が1画面に収まらず確認していません。
説明文の例として、UI Pages のチェックは、ACL のない UI ページがログイン済みの内部利用者なら誰でも開ける点を挙げています。スクリプト側で gs.hasRole のような確認がなければ、他人のパスワード変更のような操作も可能になりうる、という説明です。表のチェックも同様に、ACL のない表のデータが、必要のない利用者にも見えるおそれを説明しています。
実務での点検の進め方
見る順番
アップグレード後の点検では、まず Access findings の Check のグループ別件数を見ます。件数の多いチェックから、Source の表名を使って該当の ACL や利用者を確認します。
対象は admin、access_analyzer_admin、user_admin のいずれかを持つ担当者
優先度は 1-Critical から 4-Low まで。1-Critical や 2-High から先に見る
直さない所見は Muted タブで管理できる（今回は操作していない）
日次なので、設定を直した翌日以降に Resolved へ移るかを確認する
ACL の全体像との対比
この PDI の ACL は5万件を超えます。数万件の ACL から、ロールが無効なものだけを画面で探すのは現実的ではありません。Check でグループ化すると対象は31件に絞られます。
ACL の考え方そのものは、公式の基礎ページにまとまっています。
引用元：Explore ServiceNow access control
所見1件の中身
所見を1件ずつ開くと、Check、Finding、Security Task の欄と、Activity の履歴が見られます。
Security Task を紐づければ、対応の依頼として追跡できる構成です。
①の Check で、どのチェックの結果かを特定します。②の Activities には、作成時と更新の履歴が System の変更として残っています。
アップグレード後の点検手順
アップグレード直後にやること
Brazil へのメジャーアップグレードが終わったら、次の順で Access findings を確認します。
コンソールの Overview で、Findings の合計と優先度別の内訳を見る
Access findings タブを Check でグループ化し、件数の多いチェックを把握する
Access checks の一覧で、各チェックの説明と優先度を読む
優先度の高い所見から、Source の表名や利用者を開いて内容を確かめる
対応する所見に Security Task を紐づけ、担当を決める
この PDI では1と2で、38件のうち31件が ACL 1種類に集中していることが分かりました。3以降の作業の優先順位は、この偏りから決まります。
Australia のときとの違い
Australia のリリースノートには、ベースの Access checks 8件を日次で実行する記述がすでにあります。実機の差は件数で、アップグレード後の Brazil の PDI では Suite Check が9件ありました。8件から9件への増加は公式ドキュメントでは確認していません。この記事の範囲では、Brazil で追加された機能とは扱いません。
画面の役割分担
Brazil の Access Management メニューには、Access Management Console、Access Findings、Access Analyzer Queries、Access Simulator が並んでいます。
評価の入力は Access Analyzer、結果の一覧は Access Findings と、目的ごとに画面が分かれています。点検の担当者は、まず Findings の一覧で全体像をつかむ流れです。個別の利用者を評価したくなったら、Analyzer へ移ります。
なお、Access Simulator はメニュー名の末尾に外部リンクを示す記号が付いており、別の画面へ移る項目です。今回は開いていません。
点検結果の共有項目
所見を関係者に共有するときは、件数だけを書くと伝わりません。次の4点を添えます。
どのチェックの結果か（Check の名前）
優先度（1-Critical から 4-Low）
対象（Source の表名や利用者）
対応の担当と期限
例えば、「ACLs with Entirely Invalid Roles が31件、すべて 2-High。対象は sys_cs_conversation_document などの ACL。アプリ担当が内容を確認し、不要な ACL は削除する」という形です。
利用者系の所見
Dormant User Account の4件
Dormant User Account は、有効な利用者のうち、設定した期間ログインしていないものを拾うチェックです。優先度は 3-Moderate です。
画面の説明には「Dormant accounts without proper review can lead to unmanaged, fragmented, or untracked access risks」とあります。
（訳：適切な見直しのない休眠アカウントは、管理されず追跡もできないアクセスのリスクになりうる）
休眠アカウントは、退職や異動のあとで無効化し忘れた利用者に多く現れます。4件が出た場合は、利用者の最終ログインと所属を確認し、無効化するか継続利用かを決めます。
Users with Direct Role Assignments の3件
Users with Direct Role Assignments (Bypassing Groups) は、グループを通さず、利用者に直接ロールを付けている例を拾います。画面の説明では、直接の付与は見通しを悪くして監査を複雑にするため、グループ単位の付与が望ましいとされています。
3件が出た場合は、直接付与しているロールを該当のグループに移して、利用者側の付与を外します。ロールの付き方がグループに寄ると、後から権限を棚卸しするときの確認先が減ります。
運用での担当分け
この3種類の所見を、点検の担当を分けて扱うと運用しやすくなります。
ACL 系：アプリや開発の担当が、対象の ACL を修正するか削除する
休眠アカウント：利用者管理の担当が、無効化の可否を判断する
直接付与：利用者管理の担当が、グループへの付け替えを実施する
所見の Security Task の欄に作業を紐づけておくと、誰が何を直しているかを一覧で追えます。直さないと決めた所見は、理由を残したうえで Muted に回します。
付録：自分の環境で確認する URL
引用した画面の開き方
この記事で見せた画面は、次の URL を自分のインスタンスで開くと同じ構成で確認できます。必要なロールは admin、access_analyzer_admin、user_admin のいずれかです。
コンソールの Overview：/now/access-management/overview
所見の一覧：/now/access-management/access_findings
チェックの一覧：/now/access-management/access_checks
従来の一覧画面（Check でグループ化）：/sn_access_analyzer_access_finding_list.do?sysparm_query=GROUPBYcheck
英語の用語メモ
Access check（アクセスチェック）：違反を探す定義とロジック。Suite Check として束ねられている
Access finding（所見）：チェックが違反を検出して作るレコード。番号は ACFN から始まる
Muted：対応しないと決めて、一覧から除外した状態
Security Task：所見の対応を依頼するためのタスク
実機を見て気づいたこと
新しいテーブルは Access Analyzer のスコープにある
Access Findings は独立した新しい機能に見えますが、テーブルはスコープ Access Analyzer の中にあります。Access Analyzer と同じ場所に入っているため、Access Analyzer の権限設計がそのまま関係します。
REST では所見を読めない
admin で REST から所見のテーブルを読むと、API レベルの ACL で 403 になりました。件数の確認は画面から行います。外部のツールで所見を集計したい場合は、別の経路を検討します。
所見が1種類に偏っている
大半が ACL 1種類のチェックに偏っていました。アップグレード後に最初に見る所見は、これで決まります。
厳格な拒否のプロパティ
ロールが無効な ACL の厳格な拒否のプロパティは、この PDI では見つかりませんでした。リリースノートの手順どおりに有効化できるかは確かめていません。
点検の頻度と再確認
画面の説明では、チェックは24時間ごとに実行されます。設定を直した直後は、一覧にまだ所見が残っている可能性があります。直した当日に件数が減らない場合は、次の実行まで様子を見る運用です。待てない場合は、Run all checks で手動実行する方法もあるものの、今回は、実行による所見の増減を確かめていません。
検証範囲とおことわり
Brazil Patch 0 の PDI（Australia からアップグレード）で、画面の確認だけを行った
Run all checks、Mute、所見の更新は実行していない。設定の変更とレコードの作成はない
Suite Check 9件のうち、名前を確認できたのは6件
所見の対応で Security Task が作られる流れと、Resolved への移行は確かめていない
件数は検証環境のデータで、他の環境では異なる
