アクセス制御リストの詳細

アクセス制御リスト (ACL) の詳細について説明します。

すべてのアクセス制御リストのルールは、次のものを指定しています。

• ACL を定義する「意思決定タイプ」、「ルールタイプ」、および「操作」
• 保護される「オブジェクト」
• オブジェクトにアクセスするために必要な「条件」

ACL のコンポーネント

意思決定タイプは、条件が満たされた場合にユーザーのオブジェクトへのアクセスを許可するか、条件が満たされない限りオブジェクトへのアクセスを拒否するかを定義します。

決定タイプ	説明
Deny-Unless (次の場合を除き却下)	条件を満たさない限りアクセスを明示的に拒否することで、リソースへのアクセスを制限します。詳細については、「acl-denial-behavior.html#acl-denial-behavior__section_qnd_snl_zbc」を参照してください。
次の場合に許可 (Allow-If)	条件を満たしている場合にリソースへのアクセスを許可します。

「オブジェクト」は、アクセスを制御する必要があるターゲットです。各オブジェクトは、特定のテーブル、フィールド、またはレコードを一意に識別するタイプと名前で構成されます。[適用先] フィールドを使用すると、ユーザーはこの ACL が適用される特定のレコードをきめ細かく制御できます。

たとえば、次のエントリはすべてオブジェクトを指定します。

タイプ	名前	保護されたオブジェクト
レコード	[incident].[--None--]	インシデントテーブル。
record	[incident].[active]	インシデントテーブルのアクティブフィールド。
レコード	[incident] 適用先：優先度 = P1	インシデントテーブル内の優先度 1 のインシデントのみ。
REST_Endpoint	user_role_inheritance	user_role_inheritance Scripted REST API のレコード。

各「操作」は、指定されたオブジェクトに対してシステムが実行できる有効な「アクション」を説明しています。レコードなどの一部のオブジェクトは複数の操作をサポートしますが、REST_Endpoint などの他のオブジェクトは 1 つの操作のみをサポートします。

たとえば、これらすべてのエントリは操作を指定します。

タイプ	名前	運用	保護されている操作
レコード	[incident].[-- None --]	create	インシデントテーブルでのレコードの作成。
レコード	[incident].[active]	write	インシデントテーブルでのアクティブフィールドの更新。
REST_Endpoint	user_role_inheritance	execute	user_role_inheritance Scripted REST API の実行。

「条件」は、指定のオブジェクトと操作に対して、ユーザーがどういった場合にアクセスできるかを指定します。セキュリティアドミニストレーターは、次のものを追加することで条件要件を指定できます。

• [ロールが必要] リストへの 1 つ以上のユーザーロール。
• 1 つ以上のセキュリティ属性が true と評価される必要があります。
• 1 つ以上のデータ条件。
• true または false に評価するスクリプト、または answer 変数を true または false に設定するスクリプト。

オブジェクトと操作にアクセスするには、ユーザーはアクセス制御にリストされているすべての条件を渡す必要があります。たとえば、このアクセス制御は、インシデントテーブルの表示操作へのアクセスを制限します。

インシデントテーブルのレコードを更新するには、ユーザーがリストされているロールを持ち、レコードが条件を満たす必要があります。

条件タイプ	要件	説明
必要なロール	必要なロール：itil	itil ロールを持つユーザーのみがインシデントを更新できます。
セキュリティ属性	UserIsAuthenticated	認証されたユーザーのみがインシデントを更新できます。
データ条件	[インシデント状況] [ではない] [クローズ済み]	アクティブなインシデントレコードの更新のみを許可します。

適用先の動作

[適用先] フィールドは ACL がレコードに適用されるかどうかを決定しますが、データ条件は既に適用されている ACL を評価します。適用先 は、ACL が特定のレコードに影響を与えるかどうかを指定します。空の場合、ACL はすべてのレコードに適用されます。適用先 はきめ細かな ACL の適用に使用できますが、「データ条件」は評価基準です。

注:

Applies-to では大文字と小文字が区別されます。

デフォルトで却下する動作

デフォルトでは、ACL が空または無効な場合、ACL エンジンはアクセスを完全に拒否します。空の ACL とは、次のコンポーネントを 1 つ以上持たない ACL として定義されます。

• 定義されたロール
• セキュリティ属性
• データ条件
• スクリプト

無効な ACL は次のように定義されます。

• 存在しないロールを持つ ACL (例：データベースに行がない)
• (データベースに行がないなど) 存在しないセキュリティ属性を持つ ACL
• 「answer=true」または「true」が含まれるスクリプトを持つ ACL

システムは、ACL を作成しているユーザーを検出すると、そのユーザーにロールまたは既存のセキュリティ属性を選択するように求めます。

ACL 評価プロセス

ACL ルールは、ユーザーが一致する ACL ルールに必要なすべての条件を満たしている場合にのみ、オブジェクトへのアクセスを許可します。

• 条件は true と評価される必要があります。
• スクリプトは true と評価されるか、true の値を持つ answer 変数を返す必要があります。
• ユーザーは、必要なロールリストのいずれかのロールを持っている必要があります。リストが空の場合、この条件は true と評価されます。
• [レコード ACL ルールのみ] 一致するテーブルレベルの ACL ルールとフィールドレベルの ACL ルールの両方が true と評価される必要があります。

図 : 1. ACL 評価条件

セッションでデータが要求されるたびに、要求されたオブジェクトと操作に一致するアクセス制御ルールが検索されます。一致するアクセス制御ルールがある場合、ユーザーがオブジェクトと操作にアクセスするために必要な条件を持っているかどうかが評価されます。アクセス制御ルールで複数の条件が指定されている場合、ユーザーがオブジェクトと操作へのアクセス権を得るには、すべての条件に適合する必要があります。いずれかの条件チェックに失敗すると、ユーザーは一致するオブジェクトと操作にアクセスできません。

ユーザーが最初に一致したルールの条件を満たさない場合、アクセス制御処理順序で指定されたとおりに次に一致するアクセス制御ルールの条件が評価されます。一致したどのアクセス制御ルールの条件もユーザーが満たせない場合、システムは要求されたオブジェクトと操作へのアクセスを拒否します。

注:

要求されたオブジェクトと操作に一致するアクセス制御ルールがない場合、ユーザーにアクセス権が付与されます。実際には、システムにはすべてのレコード操作を保護する一連のデフォルトのアクセス制御ルールがあるため、一致するルールが見つからないことはほとんどありません。

オブジェクトへのアクセスが拒否された場合の影響は、ユーザーが満たしていない ACL ルールによって異なります。たとえば、読み取り操作の ACL ルールを満たしていない場合、ユーザーはオブジェクトを表示できません。保護されているオブジェクトに応じて、ACL ルールによってフォーム上のフィールドが非表示にされたり、リストの行が非表示にされたり、ユーザーが UI ページへのアクセスを禁止されたりします。次の表には、特定の操作とオブジェクトタイプの ACL ルールを満たしていない場合の結果の完全なリストが示されています。

クエリー前後の ACL チェック

インスタンスは、ユーザーがクエリーを実行する前と後に ACL ルールをチェックします。クエリーの前と後で使用可能な情報が異なるため、結果が異なる可能性があります。

クエリー前の ACL チェック

インスタンスはデータベースクエリを実行する前に、クエリ対象のテーブル内の各フィールドの ACL ルールをチェックして、ユーザーがアクセスできるフィールドを判断します。このチェックでは、ユーザーのロールのみを調べ、これらのロールがフィールドへのアクセスを許可されるかどうかを確認します。このチェックはクエリの前に実行されるため、ACL はテーブルのレコードにアクセスできず、そのデータを考慮することができません。レコードの内容を知ることに依存するスクリプトと条件は評価されません。

この時点でユーザーに読み取りアクセス権がない場合、フィールドの値はユーザーに表示されません。

クエリー後の ACL チェック

クエリーの後に、インスタンスはクエリーによって返された各レコードをチェックします。このチェック中には、ACL のコンテキストがあるため、ACL のロール、条件、およびスクリプトの部分が評価されます。この時点でユーザーが読み取りアクセス権を持っていない場合、フィールドの値はユーザーに表示されませんが、ユーザーのロールがフィールドへのアクセスを許可されているものである場合は、フィールドラベルが表示されます。

運用	オブジェクトに関する ACL ルールを満たしていない場合の結果
execute	ユーザーは、レコードまたは UI ページでスクリプトを実行できません。
作成	ユーザーはフォームから新しい UI アクションを表示できません。ユーザーは、Web サービスなどの API プロトコルを使用してテーブルにレコードを挿入することもできません。 フィールドに特定の値が含まれることを要求する条件を持つ 作成 ACL は、false と評価される場合があります。新しいレコードのフィールドは、レコードが保存されるまで空と見なされます。
read	ユーザーはフォームまたはリスト内のオブジェクトを表示できません。ユーザーは、Web サービスなどの API プロトコルを使用してレコードを取得することもできません。
write	ユーザーにはフォームとリストの読み取り専用フィールドが表示され、Web サービスなどの API プロトコルを使用してレコードを更新することはできません。
delete	ユーザーはフォームから削除 UI アクションを表示できません。ユーザーは、Web サービスなどの API プロトコルを使用してテーブルからレコードを削除することもできません。
edit_task_relations	ユーザーはタスクテーブル間の関係を定義できません。
edit_ci_relations	ユーザーは構成アイテム [cmdb_ci] テーブル間の関係を定義できません。
save_as_template	テンプレートの作成時に保存する必要があるフィールドを制御するために使用されます。
add_to_list	ユーザーはリストメカニックの特定の列を表示またはカスタマイズすることができません。
list_edit	ユーザーはリストからレコード (行) を更新できません。
report_on	ユーザーは ACL テーブルでレポートを作成できません。詳細については、「ACL ルールを使用してレポートの作成を制限する」を参照してください。
report_view	ユーザーは、ACL テーブルまたは ACL フィールドのレポートの内容を表示できません。詳細については、「Reporting」を参照してください。
personalize_choices	ユーザーは [リスト] フィールドを右クリックして [設定の選択] を選択することはできません。

オブジェクトの ACL 一致要件

オブジェクトタイプ	アクセスオブジェクトに必要な一致する ACL ルール	既存のワイルドカード ACL ルール
クライアント呼び出し可能スクリプトインクルード	ユーザーは次の 2 つの ACL ルールの条件を満たす必要があります。 オブジェクトのすべてのワイルドカード ACL ルール (操作に対する ACL ルールが存在する場合)。 オブジェクトの名前に一致する最初の ACL ルール (操作に対する ACL ルールが存在する場合)。	デフォルトでは、これらのオブジェクトタイプにワイルドカード (*) ルールはありません。これらのオブジェクトの 1 つにワイルドカード ACL ルールを作成すると、ACL ルールがこのタイプのすべてのオブジェクトに適用されます。
プロセッサー
UI ページ	ユーザーは次の 2 つの ACL ルールの条件を満たす必要があります。 レコードのフィールドに一致する最初の ACL ルール (操作に対する ACL ルールが存在する場合)。 レコードのテーブルに一致する最初の ACL ルール (操作に対する ACL ルールが存在する場合)。	デフォルトでは、作成、読み取り、書き込み、および削除操作用のワイルドカードテーブルルール (*) と、personalize_choices、create、および save_as_template 操作用のワイルドカードフィールドルール (*.*) があります。テーブルを作成するときは、提供されているワイルドカード ACL ルールを使用する場合を除き、テーブルの ACL ルールを作成します。
レコード

注:

セキュリティマネージャーのデフォルトの動作 (glide.sm.default_mode) プロパティは、ユーザーがワイルドカードテーブルの ACL ルールにのみ一致するオブジェクトにアクセスできるかどうかを決定します。このプロパティが [アクセスを拒否] に設定されている場合、アドミンのみがワイルドカードテーブルの ACL ルールにアクセスできます。

注:

作成操作のワイルドカードフィールド ACL ルール (*.*) は、書き込み操作と同じ条件を再利用します。これは、明示的な作成操作の ACL ルールが定義されない限り、作成条件は書き込み条件と同じになることを意味します。

処理順序の同じ時点にある複数の ACL ルール

2 つ以上のルールが処理順序の同じ時点で一致する場合、ユーザーは、オブジェクトにアクセスするためにいずれかの ACL ルールの条件を渡す必要があります。たとえば、incident.number に対して 2 つのフィールド ACL ルールを作成した場合、1 つのルールを満たすユーザーは、ユーザーが処理順序の同じ時点で他のフィールド ACL ルールを満たしていないかどうかにかかわらず、その番号フィールドにアクセスできます。

必要なロール

通常のアドミンユーザーは、アクセス制御ルールを表示してデバッグできます。ただし、既存のアクセス制御ルールを作成または更新するには、admin が security_admin ロールに権限を昇格させる必要があります。手順については、「特権ロールへの昇格」を参照してください。

スコープ対象のアプリケーションの ACL ルール

ACL ルールと同じスコープ内にあるオブジェクトに対して ACL ルールを作成できます。また、ACL ルールと同じスコープ内にある少なくとも 1 つのフィールドを持つテーブルに対して、ACL ルールを作成できます。

ACL ルールレコードとは異なるスコープ内のテーブルの場合は、ルールのタイプが制限されます。

• ACL ルールと同じスコープ内にある任意のテーブル、UI ページ、またはその他のオブジェクトに対して ACL ルールを作成できます。
• ACL ルールと同じスコープ内にあるフィールドに対して ACL を作成できます。
  • テーブルが同じスコープ内にある場合は、スクリプトを使用して条件を評価できます。
  • テーブルが別のスコープ内にある場合は、スクリプトを使用して条件を評価できません。
• アプリケーションピッカーで選択したアプリケーションとは異なるスコープにあるオブジェクトの ACL ルールを作成または変更することはできません。これには、異なるスコープの ACL へのロールの追加も含まれます。
• ワイルドカードテーブルルール (*) は、グローバルスコープでのみ作成できます。
• ACL ルールと同じスコープ内のテーブルに対してのみ、ワイルドカードフィールドルール (*) を作成できます。