クエリ前ビジネスルール - *その他* アクセス制御Descriptionアクセス制御は、データの可視化を必要とするユーザーを制限する優れたツールです。 ただし、いくつかの欠点があります。 「セキュリティ上の制約でこのリストからいくつかの行は削除されました」(Number of rows removed from this list by Security constraints) という望ましくないメッセージ。 多くの組織は、アクセスが拒否されていることをユーザーに知られたくありませんが、このメッセージによってすべてが明らかになってしまいます。データの大きなリストでは、「許可された」レコードは一番上に表示されず、ユーザーが見つけにくいリストの下のページに隠れることがあります。スクリプトベースの ACL では、返される行ごとにスクリプトを実行する必要があります。これにより、パフォーマンスが大幅に低下することがあります。 クエリ前(Before Query)ビジネスルールが役に立ちます。 詳細な説明 クエリ前ビジネスルールは、その名のとおり、テーブルに対するクエリが発生する前に実行されるビジネスルールです。 これらは、返されるデータを制限するクエリ用語を追加する機会を提供するため、セキュリティ対策として機能します。 可能な場合は、これらを使用することには多くの利点があります。 返されるデータのリストは事前にフィルター処理されているため、「セキュリティ上の制約でこのリストからいくつかの行は削除されました」というメッセージが表示されなくなり、すべてのデータが、エンドユーザーには「フィルター処理されていない」ように見えるクリーンなリストで返されます。データのフィルター方法を決定するためにスクリプティングまたは追加のクエリが必要な場合は、テーブルの各行でアクセス制御スクリプトを何百回または何千回繰り返し実行するよりも、クエリ前ビジネスルールで 1 回実行する方がはるかに効率的です。 実装手順 シナリオ例: 組織でユーザーをグループ別にセグメント化したいと考えています。すべてのユーザーには、自分のグループの 1 つに属する他のユーザーのみを表示できるようにする必要があります。 これを実現するには、ユーザーが属するすべてのグループのリストを収集する必要があります。 次に、そのグループのリストを使用して、各グループのすべてのメンバーを収集する必要があります。 特定のユーザーのグループ内のすべてのユーザーを収集するために [sys_user_grmember] テーブルに対するクエリが必要になるため、これは ACL では難しい場合があります。 [sys_user] テーブルの ACL スクリプトを使用してこれを実現するには、次のような解決策が考えられます。 answer = false;var myGroups = gs.getUser().getMyGroups();var myGroupMembers = [];var it = myGroups.iterator();var i=0;while(it.hasNext()){ var myGroup = it.next(); var gr = new GlideRecord("sys_user_grmember"); gr.addQuery("group", myGroup); gr.query(); while (gr.next()) { myGroupMembers.push(gr.user.sys_id); } i++;}for (var i=0; i < myGroupMembers.length; i++) { if (current.sys_id == myGroupMembers[i]){ answer = true; }} これにより目的は達成されますが、アクセスされる行ごとに実行する必要があります。数千のユーザーと数十万のグループメンバーシップを持つ組織では、パフォーマンスに悪影響が及ぶ可能性があります。 または、[sys_user] テーブルに次のクエリ前ビジネスルールを実装することもできます。 var myGroups = gs.getUser().getMyGroups();var myGroupMembers = [];var it = myGroups.iterator();var gr = new GlideRecord("sys_user_grmember");if (it.hasNext()){ myGroup = it.next(); var grps = gr.addQuery("group", myGroup);}while (it.hasNext()){ myGroup = it.next(); grps.addOrCondition("group", myGroup);}gr.query();while (gr.next()) { myGroupMembers.push(gr.user.sys_id);}if (myGroupMembers.length > 0){ var q = current.addQuery('sys_id',myGroupMembers[0]); for (var i=1; i < myGroupMembers.length; i++) { q.addOrCondition('sys_id', myGroupMembers[i]); }} これにより、アクセス制御スクリプトと同じ結果が返されますが、クエリの前に 1 回実行するだけですみます。 実際の実装では、十分な大きさのデータセットがある場合、この手法によりテーブルを返す処理時間が数分短縮されることが知られています。 Additional Informationクエリ前ビジネスルールは、行レベルでデータの可視化を制限するのに非常に効果的です。 フィールドレベルで可視化を制限するには、アクセス制御を使用する必要があります。クエリ前ビジネスルールはデータセットが返される前に実行されるため、アクセス制御が処理される前に実行されます。 アクセス制御が提供するセキュリティの安心感を顧客が希望する場合は、クエリ前ビジネスルールとアクセス制御の両方を実装して、同じ目的を同時に達成でき、同じパフォーマンス上のメリットが得られます。クエリ前ビジネスルールのパフォーマンスのベストプラクティス