KB2046494とKB2130442 について

[Masayoshi Kishi]

先日ServiceNowのセキュリティメンテナンスの一環でKB2046494にのっとりquery_range（query_match）のACLが大量に追加されました。

それに伴い、ServiceNowインスタンス上に構築した各アプリケーションの検索がエラーとなってしまい、中にはアプリケーションの動作にまで影響を及ぼしました。

①【KB2046494の理解】

*.*のACL（Deny Unless）で特定条件以外はすべて拒否

*.*のACL（Allow if）をnobodyにして誰もアクセス権なしに変更

この2つでquery検索を行えなくして、

テーブル名.フィールド名等のACL（Allow if）をServiceNowがいくつか追加して、暫定処置的なことを施している。

（こちら違ったら正しい内容をご指摘をいただきたいです。）

②【利用者側の対処】

KB2130442にのっとりquery_matchかquery_rangeのoperation、Table、filedでACLを追加

複数のアプリケーションが各々のアプリケーションスコープ内で機能を実装しており、そこからOOTB関連のTBLを参照なども行っています。

②の対処と何が不足しているのかを調べるのにテーブルのフィールド名と追加されたACLを愚直に突合していくしか方法は無いのでしょうか？

シンプルな方法とかのご紹介をいただきたくお願いいたします。

[iwai · Accepted solution]

今回のACLの判定は、デバッグで検知できます。 これでNGになっているACLを特定できるので、明確に対処可能です。

それと、Knowledgeを参照されているので把握されていると思いますが、問題となるテーブル類を一括で適切なACLを追加して今回の問題を解決するScript include “QueryRangeACLAuditor” の利用も検討すると良いです。

もうひとつ、公式資料にはまだ記載がないですが追加されたACL設定の詳細を確認するとRoleを付与することで、今回の問題の大部分を影響なくすることができます。 こちらのRoleは公式に情報がないのであえてここでは伝えないですが、新しいRoleが追加されていて、名前がそのままなのですぐにわかると思います。

Debugging Access Controls - Session Log | ServiceNow Developers

[Masayoshi Kishi]

ご回答いただきありがとうございます。

追加されたACLを見たところ、productionとNon-Productoinで少し差が見受けられました。

ProductionであったものがNon-Productionでは存在しなかったり。

このあたりのロジックが公開されてなさそうでした。

ServiceNow側で直近でアクセスのあったフィールドに対してなのか、統計的なのかで判断して付与したのかと。

ロールは渡すとしても特権ユーザークラスに絞って、各アプリケーションへの対応としては、足りないACLは適宜追加する方向になっています。（せっかくご意見いただき、ましたが。）

ありがとうございました。