4.3. ロールベースのアクセス制御
ロールベースアクセス制御の基本については、セキュリティーアーキテクチャーガイド の ロールベースアクセス制御 および 管理インターフェイスへの RBAC の追加 のセクションで説明されています。
4.3.1. ロールベースのアクセス制御の有効化
デフォルトでは、Role-Based Access Control (RBAC) システムが無効になっています。有効にするには、provider 属性を simple から rbac に変更します。provider は、management 要素の access-control 要素の属性です。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。稼働中のサーバーで RBAC を無効化または有効化した場合、サーバー設定をリロードして変更を反映する必要があります。
一度有効にすると、無効化できるのは Administrator または SuperUser ロールのユーザーのみとなります。デフォルトでは、管理 CLI はサーバーと同じマシン上で実行される場合、SuperUser ロールとして実行されます。
管理 CLI を使用して RBAC を有効にするには、アクセス承認リソースの write-attribute 操作を使用して、provider 属性を rbac に設定します。
RBAC を有効化する CLI
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
管理 CLI を使用して RBAC を無効にするには、アクセス承認リソースの write-attribute 操作を使用して、provider 属性を simple に設定します。
RBAC を無効にする CLI
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
サーバーがオフラインの場合、XML 設定を編集して RBAC を有効または無効にすることができます。これを行うには、管理要素の access-control 要素の provider 属性を編集します。この値を rbac に設定して有効にし、simple で無効にします。
XML の例
<management> <access-control provider="rbac"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control> </management>
<management>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
</include>
</role>
</role-mapping>
</access-control>
</management>
4.3.2. Permission Combination Policy の変更
Permission Combination Policy は、ユーザーが複数のロールが割り当てられているかどうかの判断方法を決定します。permissive または reject に設定できます。デフォルトは permissive です。
permissive に設定すると、アクションを許可するユーザーにロールが割り当てられていると、そのアクションが許可されます。
rejecting に設定すると、複数のロールがユーザーに割り当てられている場合、アクションは許可されません。つまり、このポリシーが rejecting に設定されていると、各ユーザーには単一のロールのみを割り当てる必要があります。ポリシーが rejecting に設定されている場合、複数のロールを持つユーザーは管理コンソールまたは管理 CLI を使用できません。
Permission Combination Policy は、permission-combination-policy 属性を permissive または rejecting のいずれかに設定して設定します。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。permission-combination-policy 属性は access-control 要素の一部で、access-control 要素は management 要素にあります。
Permission Combination Policy の設定
アクセス承認リソースの write-attribute 操作を使用して、permission-combination-policy 属性を必要なポリシー名に設定します。
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
有効なポリシー名は rejecting および permissive になります。
CLI の例
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
サーバーがオフラインの場合、XML 設定を編集してパーミッションの組み合わせポリシー (permission combination policy) 値を変更できます。これを行うには、access-control 要素の permission-combination-policy 属性を編集します。
XML の例
<access-control provider="rbac" permission-combination-policy="rejecting"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control>
<access-control provider="rbac" permission-combination-policy="rejecting">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
</include>
</role>
</role-mapping>
</access-control>
4.3.3. ロールの管理
RBAC (Role-Based Access Control) を有効にすると、管理ユーザーが許可されている内容は、ユーザーが割り当てられているロールによって決まります。JBoss EAP 7 は、ユーザーとグループの両方のメンバーシップに基づいて包含と除外のシステムを使用し、ユーザーがどのロールに属するかを決定します。
ユーザーは、以下の場合にロールに割り当てられると見なされます。
- ロールに含めるユーザーとしてリスト表示される、または
- ロールに含まれるようにリスト表示されるグループのメンバー。
また、ユーザーが以下を実行しない場合、ユーザーはロールに割り当てられると見なされます。
- ロールから除外するユーザーとしてリスト、または
- ロールから除外されるリストのグループのメンバーです。
除外は包含よりも優先されます。
ユーザーおよびグループのロール包含および除外の設定は、管理コンソールと管理 CLI の両方を使用して設定できます。
この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。
4.3.3.1. 管理 CLI を用いたユーザーロール割り当ての設定
ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization に位置します。
この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。
ロール割り当て設定の表示
:read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。
/core-service=management/access=authorization:read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] }
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
"outcome" => "success",
"result" => [
"Administrator",
"Deployer",
"Maintainer",
"Monitor",
"Operator",
"SuperUser"
]
}
指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } }
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"include-all" => false,
"exclude" => undefined,
"include" => {
"user-theboss" => {
"name" => "theboss",
"realm" => undefined,
"type" => "USER"
},
"user-harold" => {
"name" => "harold",
"realm" => undefined,
"type" => "USER"
},
"group-SysOps" => {
"name" => "SysOps",
"realm" => undefined,
"type" => "GROUP"
}
}
}
}
新規ロールの追加
この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。
add 操作で、新しいロール設定を追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME:add
/core-service=management/access=authorization/role-mapping=ROLENAME:add
- ROLENAME は、新しいマッピングの対象となるロールの名前です (例: Auditor)。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor:add
/core-service=management/access=authorization/role-mapping=Auditor:add
ロールに include されるユーザーの追加
この手順では、ユーザーをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。
add 操作を使用して、ロール、追加リストにユーザーエントリーを追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
- ROLENAME は、設定されているロールの名前です。(例: Auditor)
- ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
- username は、包含リストに追加されるユーザーの名前です (例: max)。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)
ロールに exclude されるユーザーの追加
この手順では、ロールの除外リストにユーザーを追加する方法を説明します。
ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。
add 操作を使用して、ロールの除外リストにユーザーエントリーを追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
- ROLENAME は、設定されているロールの名前です。(例: Auditor)
- USERNAME は、除外リストに追加されているユーザーの名前です。
- ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)
ユーザーロールの include 設定の削除
この手順では、ロールマッピングからユーザー包含エントリーを削除する方法を説明します。
remove 操作を使用してエントリーを削除します。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
- ROLENAME は、設定されているロールの名前です (例: Auditor)
- ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove
包含のリストからユーザーを削除しても、ユーザーはシステムから削除されません。また、ロールがそのユーザーに割り当てられないようにします。ロールはグループメンバーシップに基づいて依然として割り当てられる可能性があります。
ユーザーロールの exclude 設定の削除
この手順では、ロールマッピングからユーザー除外エントリーを削除する方法を説明します。
削除操作でエントリーを削除します。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
- ROLENAME は、設定されているロールの名前です。(例: Auditor)
- ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove
除外のリストからユーザーを削除しても、ユーザーはシステムから削除されません。また、そのロールが必ずそのユーザーに割り当てられるようになるわけではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。
4.3.4. ロールおよびユーザーグループ
mgmt-users.properties
ファイルまたは LDAP サーバーのいずれかを使用して認証されたユーザーは、ユーザーグループのメンバーになることができます。ユーザーグループは、1 人以上のユーザーに割り当てることのできる任意のラベルです。
RBAC システムは、所属するユーザーグループに応じて、自動的にロールをユーザーに割り当てるように設定できます。また、グループメンバーシップに基づいてロールからユーザーを除外することもできます。
mgmt-users.properties
ファイルを使用する場合、グループ情報は mgmt-groups.properties
ファイルに保存されます。LDAP を使用する場合、グループ情報は LDAP サーバーに保存され、LDAP サーバーの責任者によって維持されます。
4.3.5. 管理 CLI を用いたグループロール割り当ての設定
ロールに含まれる、またはロールから除外されるグループは、管理コンソールおよび管理 CLI で設定できます。このトピックでは、管理 CLI の使用についてのみ説明します。
ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization の管理 API に位置します。
この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。
グループロール割り当て設定の表示
read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。
/core-service=management/access=authorization:read-children-names(child-type=role-mapping) { "outcome" => "success", "result" => [ "Administrator", "Deployer", "Maintainer", "Monitor", "Operator", "SuperUser" ] }
/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
"outcome" => "success",
"result" => [
"Administrator",
"Deployer",
"Maintainer",
"Monitor",
"Operator",
"SuperUser"
]
}
指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true) { "outcome" => "success", "result" => { "include-all" => false, "exclude" => undefined, "include" => { "user-theboss" => { "name" => "theboss", "realm" => undefined, "type" => "USER" }, "user-harold" => { "name" => "harold", "realm" => undefined, "type" => "USER" }, "group-SysOps" => { "name" => "SysOps", "realm" => undefined, "type" => "GROUP" } } } }
/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"include-all" => false,
"exclude" => undefined,
"include" => {
"user-theboss" => {
"name" => "theboss",
"realm" => undefined,
"type" => "USER"
},
"user-harold" => {
"name" => "harold",
"realm" => undefined,
"type" => "USER"
},
"group-SysOps" => {
"name" => "SysOps",
"realm" => undefined,
"type" => "GROUP"
}
}
}
}
新規ロールの追加
この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。
add 操作で、新しいロール設定を追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME:add
/core-service=management/access=authorization/role-mapping=ROLENAME:add
グループに include されるユーザーの追加
この手順では、グループをロールの include されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。
add 操作を使用して、ロールの包含リストにグループエントリーを追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
- ROLENAME は、設定されているロールの名前です。(例: Auditor)
- GROUPNAME は、包含リスト (例: investigators) に追加されるグループの名前です。
- ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)
ロールを除外グループとして追加
この手順では、グループをロールの exclude されたリストに追加する方法を説明します。
ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に作成する必要があります。
add 操作を使用して、ロールの除外リストにグループエントリーを追加します。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
- ROLENAME は、設定されているロールの名前です (例: Auditor)
- GROUPNAME は、包含リスト (例: supervisors) に追加されるグループの名前です。
- ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)
グループーロールの包含設定の削除
この手順では、ロールマッピングからグループ包含エントリーを削除する方法を説明します。
削除操作でエントリーを削除します。
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
- ROLENAME は、設定されているロールの名前です (例: Auditor)
- ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。
CLI の例
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove
包含のリストからグループを削除しても、グループはシステムから削除されません。また、ロールがこのグループのユーザーに割り当てられないようにします。このロールは、引き続きグループのユーザーに割り当てられます。
ユーザーグループの exclude エントリーの削除
この手順では、ロールマッピングからグループ除外エントリーを削除する方法を説明します。
削除操作でエントリーを削除します。
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
- ROLENAME は、設定されているロールの名前です。(例: Auditor)
- ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove
除外のリストからグループを削除しても、システムからそのグループは削除されません。また、ロールがグループのメンバーに割り当てられることを保証する訳ではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。
4.3.6. LDAP での RBAC の使用
LDAP で RBAC を使用する基本と、LDAP で RBAC を使用するように JBoss EAP 7 を設定する方法は、JBoss EAP アイデンティティー管理の設定方法 の LDAP および RBAC セクションを参照してください。
4.3.7. スコープ指定されたロール
スコープ指定されたロールは、標準的なロールのパーミッションを付与するユーザー定義のロールです。ただし、JBoss EAP マネージドドメインの 1 つ以上のサーバーグループまたはホストに対してのみ適用されます。スコープ指定されたロールでは、管理ユーザーに、必要なサーバーグループまたはホストのみに制限されるパーミッションを付与することができます。
スコープ指定されたロールは、Administrator または SuperUser ロールが割り当てられているユーザーが作成できます。
これらは、以下の 5 つの特性によって定義されます。
- 一意名。
- ベースになる標準ロール。
- サーバーグループまたはホストへ適用されるかどうか。
- 制限されたサーバーグループまたはホストのリスト。
- すべてのユーザーが自動的に組み込まれるかどうか。デフォルトは false です。
作成すると、スコープ指定されたロールは標準ロールと同じ方法でユーザーおよびグループに割り当てることができます。
スコープ指定されたロールを作成しても、新しいパーミッションを定義することはできません。スコープ指定されたロールは、制限されたスコープ内で既存のロールのパーミッションを適用する場合にのみ使用できます。たとえば、スコープ指定されたロールは、単一のサーバーグループに制限されている Deployer ロールに基づいて作成できます。
ロールには、以下の 2 つのスコープのみを使用できます。
- ホストスコープ指定ロール
- ホストスコープ指定ロールは、そのロールのパーミッションは単一または複数のホストに制限されます。つまり、アクセスは関連する /host=*/ リソースツリーに提供されますが、他のホストに固有のリソースは非表示になります。
- サーバーグループスコープ指定ロール
- サーバーグループスコープ指定ロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。また、ロールのパーミッションは、指定した server-groups に関連付けられたプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連していないものの内部のサブリソースは、ユーザーには認識できません。
4.3.7.1. 管理 CLI からのスコープ指定されたロールの設定
この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。
新しいスコープ指定されたロールの追加
スコープ設定されたロールを新たに追加するには、以下の操作を行う必要があります。
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])
NEW-SCOPED-ROLE、BASE-ROLE、および SERVER-GROUP-NAME を適切な情報に置き換えます。
スコープ指定ロールマッピングの表示および編集
スコープ指定されたロールの詳細 (メンバーを含む) は、次のコマンドを発行することで表示できます。
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)
NEW-SCOPED-ROLE を適切な情報に置き換えます。
スコープ指定ロールの詳細を編集するには、write-attribute コマンドを使用できます。以下に例を示します。
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)
NEW-SCOPED-ROLE を適切な情報に置き換えます。
スコープ指定ロールの削除
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove
NEW-SCOPED-ROLE を適切な情報に置き換えます。
ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。
ユーザーの追加および削除
スコープ指定ロールへのユーザーの追加および削除は 標準ロールの追加と削除 と同じプロセスに従います。
4.3.7.2. 管理コンソールからのスコープ指定ロールの設定
この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。
管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックすると、すべてのロール (スコープ指定されたロールを含む) が表示されます。
以下の手順では、スコープ指定ロールの設定タスクを実行する方法について説明します。
新しいスコープ指定されたロールの追加
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックします。
- Add をクリックします。
以下の詳細を指定します。
- Name: スコープ指定の新しいロールの一意の名前。
- Base Role: このロールがパーミッションを元にするロール。
- このロールをホストまたはサーバーグループのどちらに制限するかを Type します。
- Scope、ロールが制限されているホストまたはサーバーグループのリスト。複数のエントリーを選択できます。
- このロールに Include All のユーザーが自動的に含まれる場合は、すべてを含めます。デフォルトは no です。
- Save をクリックするとダイアログが閉じ、新しく作成されたロールがテーブルに表示されます。
スコープ指定されたロールの編集
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックします。
- 編集するスコープ付きロールをクリックし、Edit をクリックします。
- 変更する詳細を更新して、Save ボタンをクリックします。
スコープ指定されたロールメンバーの表示
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックします。
- 目的のスコープロールをクリックし、Include または Exclude を選択して、含めるメンバーまたは除外するメンバーを表示します。
スコープ指定ロールの削除
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックします。
- 目的のスコープロールをクリックし、Edit ボタンの横にあるドロップダウン矢印をクリックして、Remove をクリックします。
- Confirm をクリックします。ダイアログが閉じ、ロールが削除されます。
ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。
ユーザーの追加および削除
スコープ指定ロールへのユーザーの追加および削除は標準ロールの追加と削除と同じプロセスに従います。ユーザーのスコープ指定ロールを更新するには、以下を実行します。
- 管理コンソールへのログイン
- Access Control タブをクリックします
- 左側の Roles メニューをクリックします。
- 目的のスコープロールをクリックし、Include または Exclude を選択して、含めるメンバーまたは除外するメンバーを表示します。
- メンバーを追加するには、Add をクリックし、含めるメンバーまたは除外するメンバーを選択して、Save をクリックします。
- メンバーを削除するには、削除するメンバーを選択し、Remove をクリックします。
4.3.8. 制約の設定
4.3.8.1. 機密性制約の設定
各機密性制約は、sensitive であるとみなされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバーに重大な影響を与えるリソースのことです。アクセス制御システム自体も機密であると見なされます。リソースの機密性は、どのロールが特定のリソースの読み取り、書き込み、またはアドレス指定できるかを制限します。
機密性制約設定は /core-service=management/access=authorization/constraint=sensitivity-classification にあります。
管理モデル内で、それぞれの機密性制約は分類として識別されます。分類はタイプにグループ化されます。13 種類に分類された 39 の分類が含まれています。
機密性制約を設定するには、write-attribute 操作を使用して configured-requires-read、configured-requires-write、configured-requires-addressable 属性を設定します。操作のタイプを機密に設定するには、属性の値を true に設定します。機密にしない場合は値を false に設定します。デフォルトでは、これらの属性は設定されず、default-requires-read、default-requires-write、default-requires-addressable の値が使用されます。設定した属性が適用されると、デフォルトではなく、その値が使用されます。デフォルト値は変更できません。
例: - 読み取りシステムプロパティーを機密操作にする
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)
結果
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource
{ "outcome" => "success", "result" => { "configured-requires-addressable" => undefined, "configured-requires-read" => true, "configured-requires-write" => undefined, "default-requires-addressable" => false, "default-requires-read" => false, "default-requires-write" => true, "applies-to" => { "/core-service=platform-mbean/type=runtime" => undefined, "/system-property=*" => undefined, "/" => undefined } } }
{
"outcome" => "success",
"result" => {
"configured-requires-addressable" => undefined,
"configured-requires-read" => true,
"configured-requires-write" => undefined,
"default-requires-addressable" => false,
"default-requires-read" => false,
"default-requires-write" => true,
"applies-to" => {
"/core-service=platform-mbean/type=runtime" => undefined,
"/system-property=*" => undefined,
"/" => undefined
}
}
}
これらの属性の設定に応じて、どのロールがどの操作を実行できるかを次のテーブルに要約します。
値 | requires-read | requires-write | requires-addressable |
---|---|---|---|
true | 読み取りは機密です。Auditor、Administrator、SuperUser のみを読み取ることができます。 | 書き込みは機密です。Administrator および SuperUser のみが書き込み可能です。 | アドレス指定は機密です。Auditor、Administrator、SuperUser のみがアドレス指定できます。 |
false | 読み取りは機密ではありません。すべての管理ユーザーが読み取り可能です。 | 書き込みは機密ではありません。Maintainer、Administrator、および SuperUser のみが書き込み可能です。また、Deployer はリソースをアプリケーションリソースとして記述することもできます。 | アドレス指定は機密ではありません。すべての管理ユーザーがアドレス指定できます。 |
4.3.8.2. アプリケーションリソース制約の設定
各アプリケーションリソース制約は、通常はアプリケーションとサービスのデプロイメントに関連するリソース、属性、および操作のセットを定義します。アプリケーションリソース制約が有効化されると、Deployer ロールの管理ユーザーに、適用されるリソースへのアクセスが付与されます。
アプリケーション制約設定は /core-service=management/access=authorization/constraint=application-classification/ にあります。
各アプリケーションリソース制約は分類として識別されます。分類はタイプにグループ化されます。8 種類に分類された 14 の分類が含まれています。各分類には apply-to 要素があります。これは分類設定が適用されるリソースパスパターンのリストです。
デフォルトでは、有効になっている唯一のアプリケーションリソースの分類はコアです。コアには、デプロイメント、デプロイメントオーバーレイ、およびデプロイメント操作が含まれます。
アプリケーションリソースを有効にするには、write-attribute 操作を使用して、分類の configured-application 属性を true に設定します。アプリケーションリソースを無効にするには、この属性を false に設定します。デフォルトでは、これらの属性は設定されず、default-application 属性の値が使用されます。デフォルト値は変更できません。
logger-profile アプリケーションリソースの分類を有効にする
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)
結果
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource
{ "outcome" => "success", "result" => { "configured-application" => true, "default-application" => false, "applies-to" => {"/subsystem=logging/logging-profile=*" => undefined} } }
{
"outcome" => "success",
"result" => {
"configured-application" => true,
"default-application" => false,
"applies-to" => {"/subsystem=logging/logging-profile=*" => undefined}
}
}
アプリケーションリソース制約は、その設定に一致するすべてのリソースに適用されます。たとえば、Deployer ユーザーに、あるデータソースリソースへのアクセスを許可して、同じデータベースの別のリソースへのアクセスを拒否することはできません。このレベルの分離が必要な場合は、異なるサーバーグループでリソースを設定し、グループごとに異なるスコープ指定の Deployer ロールを作成することが推奨されます。
4.3.8.3. Vault 式制約の設定
デフォルトでは、vault 式の読み書きは機密操作です。Vault 式制約を設定すると、これらの操作のいずれかまたは両方を非機密に設定できます。この制約を変更すると、より多くのロールで vault 式の読み書きが可能になります。
Vault 式制約は /core-service=management/access=authorization/constraint=vault-expression にあります。
Vault 式制約を設定するには、write-attribute 操作を使用して configured-requires-write と configured-requires-read の属性を true または false に設定します。デフォルトではそれらは設定されず、default-requires-read と default-requires-write の値が使用されます。デフォルト値は変更できません。
vault 式への書き込みを非機密操作にする
/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)
/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)
結果
/core-service=management/access=authorization/constraint=vault-expression:read-resource
/core-service=management/access=authorization/constraint=vault-expression:read-resource
{ "outcome" => "success", "result" => { "configured-requires-read" => undefined, "configured-requires-write" => false, "default-requires-read" => true, "default-requires-write" => true } }
{
"outcome" => "success",
"result" => {
"configured-requires-read" => undefined,
"configured-requires-write" => false,
"default-requires-read" => true,
"default-requires-write" => true
}
}
この設定に応じて、どのロールが vault 式の読み取りと書き込みを実行できるかを次のテーブルに要約します。
値 | requires-read | requires-write |
---|---|---|
true | 読み取り操作は機密です。Auditor、Administrator、および SuperUser のみを読み取ることができます。 | 書き込み操作は機密です。Administrator および SuperUser のみが書き込み可能です。 |
false | 読み取り操作は機密ではありません。すべての管理ユーザーは読み取りが可能です。 | 書き込み操作は機密ではありません。Monitor、Administrator、および SuperUser は書き込み可能です。Deployer は、vault 式がアプリケーションリソースにある場合にも書き込み可能です。 |
4.3.8.4. アプリケーションリソース制約に関する参考情報
タイプ: コア - 分類: デプロイメント - オーバーレイ
- デフォルト: true
- PATH: /deployment-overlay=*
- PATH: /deployment=*
- PATH: /
- 操作: upload-deployment-stream、full-replace-deployment、 upload-deployment-url、upload-deployment-bytes
タイプ: データソース - 分類: データソース
- デフォルト: false
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/data-source=*
- パス: /subsystem=datasources/data-source=*
- /subsystem=datasources/data-source=ExampleDS
- PATH: /deployment=*/subsystem=datasources/data-source=*
タイプ: データソース - 分類: jdbc-driver
- デフォルト: false
- パス: /subsystem=datasources/jdbc-driver=*
タイプ: データソース - 分類: xa-data-source
- デフォルト: false
- パス: /subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subsystem=datasources/xa-data-source=*
- PATH: /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*
タイプ: ロギング - 分類: ロガー
- デフォルト: false
- パス: /subsystem=logging/logger=*
- パス: /subsystem=logging/logging-profile=*/logger=*
タイプ: データソース - 分類: logging-profile
- デフォルト: false
- パス: /subsystem=logging/logging-profile=*
タイプ: メール - 分類: mail-session
- デフォルト: false
- パス: /subsystem=mail/mail-session=*
タイプ: ネーミング - 分類: バインディング
- デフォルト: false
- パス: /subsystem=naming/binding=*
タイプ: resource-adapters- 分類: resource-adapters
- デフォルト: false
- パス: /subsystem=resource-adapters/resource-adapter=*
タイプ: セキュリティー - 分類: security-domain
- デフォルト: false
- パス: /subsystem=security/security-domain=*
4.3.8.5. 機密性制約に関する参考情報
タイプ: コア - 分類: access-control
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/access=authorization
- パス: /subsystem=jmx 属性: non-core-mbean-sensitivity
タイプ: コア - 分類: クレデンシャル
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username , password
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: username , password
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, recovery-username, password, recovery-password
- パス: /subsystem=mail/mail-session=*/custom=* ATTRIBUTE: username, password
- パス: /subsystem=datasources/data-source=*" ATTRIBUTE: user-name, password
- パス: /subsystem=remoting/remote-outbound-connection=*" ATTRIBUTE: username
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: username, password
- PATH: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*" ATTRIBUTE: recovery-username, recovery-password
タイプ: コア - 分類: domain-controller
- requires-addressable: false
- requires-read: false
- requires-write: true
タイプ: コア - 分類: domain-names
- requires-addressable: false
- requires-read: false
- requires-write: true
タイプ: コア - 分類: エクステンション
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /extension=*
タイプ: コア - 分類: jvm
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
タイプ: コア - 分類: management-interfaces
- requires-addressable: false
- requires-read: false
- requires-write: true
- /core-service=management/management-interface=http-interface
タイプ: コア - 分類: module-loading
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=module-loading
タイプ: コア - 分類: パッチ
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=patching/addon=*
- PATH: /core-service=patching/layer=*"
- PATH: /core-service=patching
タイプ: コア - 分類: read-whole-config
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: / OPERATION: read-config-as-xml
タイプ: コア - 分類: security-domain
- requires-addressable: true
- requires-read: true
- requires-write: true
- パス: /subsystem=security/security-domain=*
タイプ: コア - 分類: security-domain-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- パス: /subsystem=datasources/xa-data-source=* ATTRIBUTE: security-domain
- パス: /subsystem=datasources/data-source=* ATTRIBUTE: security-domain
- パス: /subsystem=ejb3 属性: default-security-domain
- パス: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* 属性:security-domain、recovery- security-domain、security-application、security-domain-and-application
タイプ: コア - 分類: security-realm
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /core-service=management/security-realm=*
タイプ: コア - 分類: security-realm-ref
- requires-addressable: true
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=native-interface ATTRIBUTE: security-realm
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: security-realm
- パス: /subsystem=remoting/remote-outbound-connection=* 属性: security-realm
タイプ: コア - 分類: security-vault
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=vault
タイプ: コア - 分類: service-container
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=service-container
タイプ: コア - 分類: snapshots
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: / ATTRIBUTE: take-snapshot, list-snapshots, delete-snapshot
タイプ: コア - 分類: socket-binding-ref
- requires-addressable: false
- requires-read: false
- requires-write: false
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=imap ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: socket-binding
- PATH: /subsystem=remoting/local-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /socket-binding-group=*/local-destination-outbound-socket-binding=* ATTRIBUTE: socket-binding-ref
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: outbound-socket-binding-ref
- PATH: /subsystem=mail/mail-session=*/server=smtp ATTRIBUTE: outbound-socket-binding-ref
- パス:/ /subsystem=transactions 属性: process-id-socket-binding、status-socket-binding、socket-binding
タイプ: コア - 分類: socket-config
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /interface=* OPERATION: resolve-internet-address
- PATH: /socket-binding-group=*
- PATH: /core-service=management/management-interface=http-interface ATTRIBUTE: port, secure-port, interface, secure-socket-binding, socket-binding
- PATH: / OPERATION: resolve-internet-address
- パス: /subsystem=transactions 属性: process-id-socket-max-ports
タイプ: コア - 分類: system-property
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /core-service=platform-mbean/type=runtime ATTRIBUTE: system-properties
- PATH: /system-property=*
- PATH: / OPERATION: resolve-expression
タイプ: データソース - 分類: data-source-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=datasources/xa-data-source=* ATTRIBUTE: user-name, security-domain, password
- パス: /subsystem=datasources/data-source=* 属性: user-name、security-domain、password
タイプ: jdr - 分類: jdr
- requires-addressable: false
- requires-read: false
- requires-write: true
- パス: /subsystem=jdr 操作: generate-jdr-report
タイプ: jmx - 分類: jmx
- requires-addressable: false
- requires-read: false
- requires-write: true
- パス: /subsystem=jmx
タイプ: メール - 分類: mail-server-security
- requires-addressable: false
- requires-read: false
- requires-write: true
- PATH: /subsystem=mail/mail-session=*/server=pop3 ATTRIBUTE: username, tls, ssl, password
- パス: /subsystem=mail/mail-session=*/server=imap 属性: ユーザー名、tls、ssl、password
- パス: /subsystem=mail/mail-session=/custom= 属性: username、tls、ssl、password
- パス: /subsystem=mail/mail-session=*/server=smtp 属性: username、tls、ssl、password
タイプ: ネーミング - 分類: jndi-view
- requires-addressable: false
- requires-read: true
- requires-write: true
- パス: /subsystem=naming 操作: jndi-view
タイプ: ネーミング - 分類: naming-binding
- requires-addressable: false
- requires-read: false
- requires-write: false
- パス: /subsystem=naming/binding=*
タイプ: remoting - 分類: remoting-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=remoting/connector=* ATTRIBUTE: authentication-provider, security-realm
- PATH: /subsystem=remoting/remote-outbound-connection=* ATTRIBUTE: username, security-realm
- パス: /subsystem=remoting/connector=*/security=sasl
タイプ: resource-adapters - 分類: resource-adapter-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- パス: /subsystem=resource-adapters/resource-adapter=*/connection-definitions=* 属性: security-domain、recovery-username、recovery-security-domain、security-application、security-domain-and-application、recovery-password
タイプ: セキュリティー - 分類: misc-security
- requires-addressable: false
- requires-read: true
- requires-write: true
- PATH: /subsystem=security ATTRIBUTE: deep-copy-subject-mode