アクセス制御リストの概要
アクセス制御リスト (ACL) を確認します。
ACL のコンポーネント
- 保護されるオブジェクトと操作
- オブジェクトにアクセスするために必要な権限
オブジェクトは、アクセスを制御する必要があるターゲットです。各オブジェクトは、特定のテーブル、フィールド、またはレコードを一意に識別するタイプと名前で構成されます。
たとえば、次のエントリはすべてオブジェクトを指定します。
| タイプ | 名前 | 保護されたオブジェクト |
|---|---|---|
| レコード | [インシデント]。[-- なし --] | インシデントテーブル。 |
| record | [incident].[active] | インシデントテーブルのアクティブフィールド。 |
| REST_Endpoint | user_role_inheritance | user_role_inheritance Scripted REST API のレコード。 |
各操作は、指定されたオブジェクトに対してシステムが実行できる有効なアクションを説明しています。レコードなどの一部のオブジェクトは複数の操作をサポートしますが、REST_Endpoint などの他のオブジェクトは 1 つの操作のみをサポートします。
たとえば、これらすべてのエントリは操作を指定します。
| タイプ | 名前 | 運用 | 保護されている操作 |
|---|---|---|---|
| record | [incident].[-- None --] | create | インシデントテーブルでのレコードの作成。 |
| record | [incident].[active] | write | インシデントテーブルでのアクティブフィールドの更新。 |
| REST_Endpoint | user_role_inheritance | execute | user_role_inheritance Scripted REST API の実行。 |
- [ロールが必要] リストへの 1 つ以上のユーザーロール。
- 1 つ以上の条件。
- true または false に評価するスクリプト、または
answer変数を true または false に設定するスクリプト。
オブジェクトと操作にアクセスするには、ユーザーはアクセス制御にリストされているすべての権限を渡す必要があります。たとえば、このアクセス制御は、インシデントテーブルの書き込み操作へのアクセスを制限します。
インシデントテーブルのレコードを更新するには、ユーザーがリストされているロールを持ち、レコードが条件を満たす必要があります。
| 権限タイプ | 要件 | 説明 |
|---|---|---|
| 必要なロール | 必要なロール：itil | itil ロールを持つユーザーのみがインシデントを更新できます。 |
| 条件 | [インシデントステータス] [ではない] [クローズ済み] | アクティブなインシデントレコードの更新のみを許可します。 |
ACL 評価プロセス
ACL ルールは、ユーザーが一致する ACL ルールに必要なすべての権限を満たしている場合にのみ、オブジェクトへのアクセスを許可します。
- 条件は true と評価される必要があります。
- スクリプトは true と評価されるか、true の値を持つ answer 変数を返す必要があります。
- ユーザーは、必要なロールリストのいずれかのロールを持っている必要があります。リストが空の場合、この条件は true と評価されます。
- [レコード ACL ルールのみ] 一致するテーブルレベルの ACL ルールとフィールドレベルの ACL ルールの両方が true と評価される必要があります。
セッションでデータが要求されるたびに、要求されたオブジェクトと操作に一致するアクセス制御ルールが検索されます。一致するアクセス制御ルールがある場合、ユーザーがオブジェクトと操作にアクセスするために必要な権限を持っているかどうかが評価されます。アクセス制御ルールで複数の権限が指定されている場合、ユーザーはオブジェクトと操作にアクセスするためにすべての権限を満たす必要があります。いずれかの権限チェックに失敗すると、ユーザーは一致するオブジェクトと操作にアクセスできません。
オブジェクトへのアクセスが拒否された場合の影響は、ユーザーが満たしていない ACL ルールによって異なります。たとえば、読み取り操作の ACL ルールを満たしていない場合、ユーザーはオブジェクトを表示できません。保護されているオブジェクトに応じて、ACL ルールによってフォーム上のフィールドが非表示にされたり、リストの行が非表示にされたり、ユーザーが UI ページへのアクセスを禁止されたりします。次の表に、特定の操作とオブジェクトタイプの 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 ルールの権限を満たす必要があります。
|
既定では、これらのオブジェクトの種類にワイルドカード (*) 規則はありません。これらのオブジェクトの 1 つにワイルドカード ACL ルールを作成すると、ACL ルールがこのタイプのすべてのオブジェクトに適用されます。 |
| プロセッサー | ||
| UI ページ | ユーザーは次の 2 つの ACL ルールの権限を満たす必要があります。
|
デフォルトでは、作成、読み取り、書き込み、および削除操作用のワイルドカードテーブルルール (*) と、personalize_choices、作成、およびsave_as_template操作用のワイルドカードフィールドルール (*.*) があります。テーブルを作成するときは、提供されているワイルドカード ACL ルールを使用する場合を除き、テーブルの ACL ルールを作成します。 |
| レコード |
処理順序の同じ時点にある複数の ACL ルール
2 つ以上のルールが処理順序の同じ時点で一致する場合、ユーザーは、オブジェクトにアクセスするためにいずれかの ACL ルールの権限を渡す必要があります。たとえば、incident.number に対して 2 つのフィールド ACL ルールを作成した場合、1 つのルールを満たすユーザーは、ユーザーが処理順序の同じ時点で他のフィールド ACL ルールを満たしていないかどうかにかかわらず、その番号フィールドにアクセスできます。
必要なロール
通常の管理者ユーザーは、アクセス制御ルールを表示してデバッグできます。ただし、既存のアクセス制御ルールを作成または更新するには、管理者が security_admin ロールに権限を昇格させる必要があります。手順については、「特権ロールへの昇格」を参照してください。
スコープ対象のアプリケーションの ACL ルール
ACL ルールと同じスコープ内にあるオブジェクトに対して ACL ルールを作成できます。ACL ルールと同じスコープ内にあるフィールドを少なくとも 1 つ持つテーブルに対しても、ACL ルールを作成できます。
- ACL ルールと同じスコープ内にある任意のテーブル、UI ページ、またはその他のオブジェクトに対して ACL ルールを作成できます。
- ACL ルールと同じスコープ内にあるフィールドに対して ACL を作成できます。
- テーブルが同じスコープ内にある場合は、スクリプトを使用して権限を評価できます。
- テーブルが別のスコープ内にある場合は、スクリプトを使用して権限を評価することはできません。
- アプリケーションピッカーで選択したアプリケーションとは異なるスコープにあるオブジェクトの ACL ルールを作成または変更することはできません。これには、異なるスコープの ACL へのロールの追加も含まれます。
- ワイルドカードテーブルルール (*) は、グローバルスコープでのみ作成できます。
- ACL ルールと同じスコープ内のテーブルに対してのみ、ワイルドカードフィールドルール (*) を作成できます。