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

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)

管理 CLI を使用して RBAC を無効にするには、アクセス承認リソースの write-attribute 操作を使用して、provider 属性を simple に設定します。

RBAC を無効にする CLI

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization:write-attribute(name=provider, value=simple)

サーバーがオフラインの場合、XML 設定を編集して RBAC を有効または無効にすることができます。これを行うには、管理要素の access-control 要素の provider 属性を編集します。この値を rbac に設定して有効にし、simple で無効にします。

XML の例

Copy to Clipboard Toggle word wrap
<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 属性を必要なポリシー名に設定します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)

有効なポリシー名は rejecting および permissive になります。

CLI の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)

サーバーがオフラインの場合、XML 設定を編集してパーミッションの組み合わせポリシー (permission combination policy) 値を変更できます。これを行うには、access-control 要素の permission-combination-policy 属性を編集します。

XML の例

Copy to Clipboard Toggle word wrap
<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 操作を使用して、設定されたロールの完全なリストを取得します。

Copy to Clipboard Toggle word wrap
/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 操作を使用して、特定のロールの完全な詳細を取得します。

Copy to Clipboard Toggle word wrap
/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 操作で、新しいロール設定を追加します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME:add
  • ROLENAME は、新しいマッピングの対象となるロールの名前です (例: Auditor)。

CLI の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor:add

ロールに include されるユーザーの追加

この手順では、ユーザーをロールの include されたリストに追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロール、追加リストにユーザーエントリーを追加します。

Copy to Clipboard Toggle word wrap
/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 の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)

ロールに exclude されるユーザーの追加

この手順では、ロールの除外リストにユーザーを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロールの除外リストにユーザーエントリーを追加します。

Copy to Clipboard Toggle word wrap
/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 の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)

ユーザーロールの include 設定の削除

この手順では、ロールマッピングからユーザー包含エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
  • ROLENAME は、設定されているロールの名前です (例: Auditor)
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。

CLI の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove

注記

包含のリストからユーザーを削除しても、ユーザーはシステムから削除されません。また、ロールがそのユーザーに割り当てられないようにします。ロールはグループメンバーシップに基づいて依然として割り当てられる可能性があります。

ユーザーロールの exclude 設定の削除

この手順では、ロールマッピングからユーザー除外エントリーを削除する方法を説明します。

削除操作でエントリーを削除します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME は、設定されているロールの名前です。(例: Auditor)
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
Copy to Clipboard Toggle word wrap
/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 操作を使用して、設定されたロールの完全なリストを取得します。

Copy to Clipboard Toggle word wrap
/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 操作を使用して、特定のロールの完全な詳細を取得します。

Copy to Clipboard Toggle word wrap
/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 操作で、新しいロール設定を追加します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME:add

グループに include されるユーザーの追加

この手順では、グループをロールの include されたリストに追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロールの包含リストにグループエントリーを追加します。

Copy to Clipboard Toggle word wrap
/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 の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)

ロールを除外グループとして追加

この手順では、グループをロールの exclude されたリストに追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に作成する必要があります。

add 操作を使用して、ロールの除外リストにグループエントリーを追加します。

Copy to Clipboard Toggle word wrap
/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 の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)

グループーロールの包含設定の削除

この手順では、ロールマッピングからグループ包含エントリーを削除する方法を説明します。

削除操作でエントリーを削除します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
  • ROLENAME は、設定されているロールの名前です (例: Auditor)
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。

CLI の例

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove

注記

包含のリストからグループを削除しても、グループはシステムから削除されません。また、ロールがこのグループのユーザーに割り当てられないようにします。このロールは、引き続きグループのユーザーに割り当てられます。

ユーザーグループの exclude エントリーの削除

この手順では、ロールマッピングからグループ除外エントリーを削除する方法を説明します。

削除操作でエントリーを削除します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
  • ROLENAME は、設定されているロールの名前です。(例: Auditor)
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。
Copy to Clipboard Toggle word wrap
/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 ロールのユーザーのみです。

新しいスコープ指定されたロールの追加

スコープ設定されたロールを新たに追加するには、以下の操作を行う必要があります。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add
Copy to Clipboard Toggle word wrap
/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 を適切な情報に置き換えます。

スコープ指定ロールマッピングの表示および編集

スコープ指定されたロールの詳細 (メンバーを含む) は、次のコマンドを発行することで表示できます。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの詳細を編集するには、write-attribute コマンドを使用できます。以下に例を示します。

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの削除

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove

NEW-SCOPED-ROLE を適切な情報に置き換えます。

重要

ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。

ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は 標準ロールの追加と削除 と同じプロセスに従います。

4.3.7.2. 管理コンソールからのスコープ指定ロールの設定

重要

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。

  1. 管理コンソールへのログイン
  2. Access Control タブをクリックします
  3. 左側の 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-readconfigured-requires-writeconfigured-requires-addressable 属性を設定します。操作のタイプを機密に設定するには、属性の値を true に設定します。機密にしない場合は値を false に設定します。デフォルトでは、これらの属性は設定されず、default-requires-readdefault-requires-writedefault-requires-addressable の値が使用されます。設定した属性が適用されると、デフォルトではなく、その値が使用されます。デフォルト値は変更できません。

例: - 読み取りシステムプロパティーを機密操作にする

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)

結果

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource

Copy to Clipboard Toggle word wrap
{
    "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
        }
    }
}

これらの属性の設定に応じて、どのロールがどの操作を実行できるかを次のテーブルに要約します。

表4.1 機密性制約設定の結果
requires-readrequires-writerequires-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 アプリケーションリソースの分類を有効にする

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)

結果

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource

Copy to Clipboard Toggle word wrap
{
    "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-writeconfigured-requires-read の属性を true または false に設定します。デフォルトではそれらは設定されず、default-requires-readdefault-requires-write の値が使用されます。デフォルト値は変更できません。

vault 式への書き込みを非機密操作にする

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)

結果

Copy to Clipboard Toggle word wrap
/core-service=management/access=authorization/constraint=vault-expression:read-resource

Copy to Clipboard Toggle word wrap
{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}

この設定に応じて、どのロールが vault 式の読み取りと書き込みを実行できるかを次のテーブルに要約します。

表4.2 vault 式制約の設定結果
requires-readrequires-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
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.