【ServiceNow】Xanaduリリース新機能！Deny-Unless ACLを検証してみた！

Deny-Unless ACLとは？

Deny-Unless ACLとはXanaduリリースから登場した新機能です。

今まではホワイトリスト型のアクセス許可のみでしたが、ブラックリスト型のアクセス制御を提供します。

これまでのホワイトリスト型のACLはAllow If ACLという機能になっています。

以下はServiceNow公式ドキュメント記載の説明です。

「次の場合を除き却下 (Deny-Unless)」ACL の詳細について説明します。

「次の場合を除き却下 (Deny-Unless)」ACL は「deny-unless」アプローチで評価されます。ACL は却下されないユーザーを定義します。別の言い方をすると、ロール、条件、およびスクリプト要件が満たされない限り、ユーザーはアクセスを拒否されます。

重要: 「次の場合を除き却下 (Deny-Unless)」ACL は、ACL 評価で「次の場合に許可 (Allow-If)」ACL より優先されます。

ServiceNow公式ドキュメントより引用
（https://www.servicenow.com/docs/ja-JP/bundle/xanadu-platform-security/page/administer/contextual-security/concept/acl-denial-behavior.html）

実際にAllow If ACLとDeny-Unless ACLでどのような挙動の違いがあるかを検証してみます。

Deny-Unless ACLの検証

今回はDeny-ACLの挙動を理解するために、まずは①Allow If ACLのみを設定した状態でデータがどのように参照できるかを検証し、次に②Deny-Unless ACLのみの設定での参照制御を検証します。

最後に③Allow If ACLとDeny-Unless ACLを両方作成した際の挙動を確認します。

#	パターン
①	Allow If ACLのみを作成
②	Deny-Unless ACLのみを作成
③	Allow If ACLとDeny-Unless ACLの両方を作成

検証の準備

検証①Allow If ACLのみを作成し、A・Bロールを保有する全てのユーザーに参照権限を付与

ACLの設定

A Role, B Roleを保有するユーザーが全てのレコードを参照できるようAllow If ACLを作成します。

Decision Type	Name	Operation	Requires role	Data Condition
Allow If	申請.None	Read	A Role, B Role	–

検証結果①

こちらは通常通りA User, B Userともに申請テーブルの全てのレコードが参照可能となります。

実際の画面ではこのように見えています。

検証②Deny-Unless ACLのみを作成し、自分にアサインされているレコード以外参照不可とする

次にDeny-Unless ACL単独ではどのような挙動をするのかを確認してみます。

ACLの設定

次に、Deny-Unless ACLを作成し、アサイン先が自分以外のレコードが参照不可となるよう設定します。

Decision Type	Name	Operation	Requires role	Data Condition
Deny-Unless	申請.None	Read	–	Assigned to is (dynamic) Me

検証結果②

A User, B Userともにテーブル自体の参照ができなくなってしまいました。

それぞれのユーザーで画面は以下のように見えています。

どうやら、レコードを参照するためにはDeny-Unless ACLだけでなく、Allow If ACLでアクセス許可をしてあげる必要があるみたいです。

検証③Deny-Unless ACLとAllow If ACLを作成し、自分にアサインされているレコード以外参照不可とする

最後に、Allow If ACLとDeny-Unless ACLを組み合わせて、どのような挙動が実現できるかを確認します。

ACLの設定

Allow If ACLを作成し、A Role, B Roleを持つユーザーに申請テーブルの全てのレコードへの参照権限を付与した上で、自分にアサインされているレコード以外参照不可とするDeny-Unless ACLを作成します。

Decision Type	Name	Operation	Requires role	Data Condition
Deny-Unless	申請.None	Read	–	Assigned to is (dynamic) Me
Allow If	申請.None	Read	A Role, B Role	–

検証結果③

こちらは、自分にアサインされているレコードのみが参照可能となりました。

実際の見え方は以下のようになっています。

Allow If ACLでは全てのレコードが参照可能となっているものの、Deny-Unless ACLでアクセスを拒否したレコードは参照不可となりました。

まとめ

ドキュメントにも記載がありましたが、検証結果よりDeny-Unless ACLはAllow If ACLよりも優先的に評価されます。

Deny-Unless ACLによってアクセスが拒否されているレコードを除外し、残りのレコードに対してAllow If ACLでアクセスが許可されているか判断をしているようです。

評価の順番を図にすると以下のようになります。

また、Deny-Unless ACLがAllow If ACLよりも優先的に評価されるため、たとえAllow If ACLでアクセスが許可されていても、Deny-Unless ACLでアクセスが拒否されていればユーザーは参照することができません。

以下のベン図では赤枠で囲った範囲のみ参照可能となります。

今回の検証で分かったDeny-Unless ACLのポイントは以下２点となります。

実際にどのように活用すべきか、どのようなユースケースに適用可能かはもう少し触りながら検討していきます。

読んでいただきありがとうございました。