Access Control Overview Moduleメモ

くろひつじ

復習のためにServiceNow Fundamentals On Demand関係の記事を流していこうと思います。
今回はAccess Controlについて。

前回の記事はこちら。

User permissions

ServiceNowは、エンド ユーザーがテーブルでCRUD操作を実行できるようになる前に、いくつかのレベルのセキュリティを提供しています。

  • ユーザー認証/ログイン：ユーザー、グループ、ロール

  • アプリケーション及びモジュールへのアクセス：アプリケーション及びモジュールレベルで構成されたロールで制御します

  • データベースアクセス：テーブル、レコード、フィールドへのアクセスはグローバル定義したシステムプロパティで制御します

システム管理者は以下のモジュールからアクセス制御が可能です。

  • System Properties > Security

  • System Security > Access Control(ACL)

  • System Security > High Security Settings

What is an access control?

アクセス制御は、行または列レベルで設定できます。
CRUD操作を制限することに加えて、アクセス制御ルールは、テーブルとフィールドに対するServiceNow固有の操作を制限できます。
ServiceNowの操作例は次のとおりです。

  • execute：ユーザーは、レコードまたはUIページでスクリプトを実行できません。

  • edit_ci_relations：ユーザーは構成アイテム[cmdb_ci]テーブル間の関係を定義できません。

  • save_as_template：テンプレートの作成時に保存する必要があるフィールドを制御します。

  • report_on：ユーザーはオブジェクトに関するレポートを作成できません。

  • personalize_choices：ユーザーは選択リストフィールドを右クリックして[選択の構成]を選択することはできません。

Access control definition: permission requirements

各アクセス制御ルールは以下を指定します。

  1. 保護されているオブジェクト（テーブル、フィールドなど）

  2. オブジェクトにアクセスするために必要な権限

    1. 役割

    2. 条件式

    3. スクリプト

  3. 操作-システムが実行できる有効なアクション（CRUD）

この例では、itilロールを持つユーザーに、Infinity テーブル [u_cmdb_ci_hardware_infinity] にレコードを書き込む (更新する) 権限が付与されます。

System created access controls

カスタムテーブルが作成されると、システムはデフォルトで4つのアクセス制御ルールを作成します。

  • create

  • delete

  • read

  • write

ロールもデフォルトで作成されます。
テーブルに関連付けられているアクセス制御を表示する方法は以下の通りです。

  1. フィルターナビゲーターで<table name>.configと入力

  2. Access Controls タブを選択

Table access control evaluations

ユーザーは、レコードオブジェクトにアクセスするために、テーブルとフィールドの両方のACLルールを渡す必要がある。（テーブル→フィールドの順）

アクセス制御は、上の画像に示されている順序で評価されます。
この処理順序により、フィールドへのアクセスを評価する前に (最も固有のものから最も一般的なものへ)、ユーザーがテーブルにアクセスできるようになります (最も具体的なテーブル ルールから最も一般的なものへ)。

ユーザーがテーブル アクセス コントロール ルールに違反すると、ユーザーがフィールド ACL ルールに合格したとしても、そのユーザーはテーブル内のすべてのフィールドへのアクセスを拒否されます。
ユーザーがテーブル ACL ルールに合格しても、フィールド ACL ルールに不合格の場合、ユーザーはフィールド ACL ルールによって記述されたフィールドにアクセスできません。

一致するアクセス制御ルール (システムによって作成されたアクセス制御によってほぼ保証されます) がある場合、システムは、ユーザーがオブジェクトと操作 (ロール、条件、スクリプト) にアクセスするために必要なアクセス許可を持っているかどうかを評価します。
アクセス制御規則で複数の権限が指定されている場合、ユーザーはオブジェクトと操作にアクセスするためにすべての権限を満たす必要があります。 いずれかの権限チェックに失敗すると、ユーザーは一致するオブジェクトおよび操作にアクセスできなくなります。

ユーザが最初に一致したルールのアクセス許可を満たさない場合、システムは、アクセス コントロールの処理順序で指定されているように、次に一致するアクセス コントロール ルールのアクセス許可を評価します。 ユーザーが一致するアクセス制御ルールの権限を満たさない場合、システムは要求されたオブジェクトと操作へのアクセスを拒否します。

Access control definition: rule types

table.--None-- テーブル全体に適用されます。
table.field テーブル上の1つの特定のフィールド、または家の特定の部屋です。
table.* *house.fieldルール（house.**）で定義されていない、テーブル内の他のすべてのフィールドまたは家の他のすべての部屋を表します。 この方法では、追加のアクセス許可がすべて閉じられるため、システム内のテーブルに書き込む必要のあるACLの数が減ります。

たとえば、ルールを作成してタイプ (table.--none--、table.field、または table.*) を決定するとき、実際にはオブジェクトのフィールド オプションを参照しています。
--None-- を選択する際は、アクセス制御の名前に注意してください。 テーブルに対する制限のない読み取り、作成、書き込み、および削除操作は「u_cmdb_ci_hardware_infinity」として表示され、どのフィールドにも制限がないことを示していることに注意してください。

Using the wildcard example

With *の例について

アクセス制御なし（sys_userとして表示される）は、すべての行とすべてのフィールドにtable_adminロールとtable_userロールの両方を付与しています。

.* は、すべての行とすべてのフィールドにtable_adminロールを付与しています。
table_adminロールはすでにすべての行とすべてのフィールドにアクセスできるため、このアクセス制御を使用するのは冗長です。
このアクセス制御の目的は、アクセス制御なしによって許可された役割であっても、他のすべての役割へのアクセスを拒否することです。

.home_phoneは、table_userがアクセス制御によってhome_phoneへのアクセスを拒否された場合でも、table_userロールにhome_phoneフィールドへのアクセスを明示的に与えます。
→フィールド固有のアクセス制御が .* よりも優先されるためです。

Without *の例について

アクセス制御なし（sys_userとして表示される）は、すべての行とすべてのフィールドにtable_adminロールとtable_userロールの両方を付与しています。

.home_phoneにより、home_phoneにtable_adminロールへのアクセスが許可されました。
table_userロールにNoneAccessControlによってhome_phoneアクセスが許可されていても、home_phoneをtable_adminに明示的に指定するとtable_userからhome_phoneアクセスが削除されます。

ベストプラクティス

  • .*アクセス制御を作成するときは、アクセス制御なしだけがレコードへのアクセスを許可するため、アクセス制御なしも作成します。

  • ほとんどの場合アクセスを許可するACLを作成するときは、アクセス制御なしのみを使用してください。

  • ほとんどの場合アクセスを拒否するACLを作成するときは、アクセス制御なしと.*を使用します。

この記事が気に入ったらサポートをしてみませんか？