Instance Scan：設定の「よくない状態」を機械に探させる

「中身が空のACLが270件あります」。人が手で数えたら半日かかる調査を、ServiceNow は自前の機能で持っています。Instance Scan です。

設定の良くない状態をチェックとして定義しておき、まとめて走らせて、引っかかったレコードを指摘として残す。静的解析ツールの ServiceNow 版にあたる機能です。実機で読むと、340のチェックと805の指摘が残っていました。

4つのテーブルで動く

登場するのは4つです。

• チェック（scan_check） … 「これは良くない」の定義。実測 340件

• スイート（scan_check_suite） … チェックの束。実測 15件

• 結果（scan_result） … スキャン1回ぶんの記録。実測 14件

• 指摘（scan_finding） … 引っかかった1件ずつ。実測 805件

チェックを定義し、スイートでまとめ、走らせると結果が1件でき、その下に指摘がぶら下がる。この構造は Automated Test Framework（ATF）のテスト・ステップ・結果とよく似ています。

チェックは3つのクラスに分かれる

340件の内訳は、スクリプトのみが253件、テーブルチェックが80件、列の型チェックが7件でした。

テーブルチェックは「このテーブルで、この条件に合う行があれば指摘」という単純な形です。設定だけで作れるので、書きやすい。スクリプトのみのチェックは、複数のテーブルをまたいだり計算が必要な判定に使います。

数の比率が示すとおり、標準のチェックは大半がスクリプト型でした。単純な条件では表せない判定が多い、ということでもあります。

列の型チェックが7件しかないのも納得できます。「このテーブルのこの型のフィールドを探す」という判定は用途が限られるからです。実際、3DES暗号化の残骸を探すスイートのように、特定の型を横断で洗い出す場面で使われていました。

スイート15件はすべて有効

スイートの名前に、Instance Scan の用途がそのまま表れています。

セキュリティ系が目立ちます。数えると4つでした。

• Auditor

• Instance Security Hardening Settings

• Security Controls Activation

• Password2 Fields Security Assessment

次に多いのが非推奨API系です。Deprecated APIs / Encrypter / GlideEncrypter / GlideEncrypter Custom Key / GlideCryptoService。暗号化まわりの古いAPIを探す束だけで5つありました。

Schema 系が4つ（Validation / Dictionary / Hierarchy / Alias）あるのも特徴です。テーブル定義そのものの健全性を点検します。

つまり Instance Scan の主目的は「セキュリティの穴」「古いAPIの残骸」「壊れたスキーマ」の3つでした。どれも放置すると、アップグレードのときに問題になる種類です。