Show Table of Contents
10.4. ロールベースのアクセス制御の定義
ロールベースのアクセス制御では、セルフサービスおよび委任アクセス制御の場合とは非常に異なる種類の権限をユーザーに付与します。ロールベースのアクセス制御は基本的には管理業務用で、たとえばエントリーの追加、削除、または大幅な修正などができます。
ロールベースのアクセス制御は、以下の 3 つの部分で構成されます。
- パーミッション。これは、(読み取り、書き込み、追加、または削除などの) 特定の操作と、これらの操作が適用される IdM LDAP ディレクトリー内のターゲットエントリーを定義します。パーミッションはビルディングブロックで、必要に応じて複数の権限に割り当てることができます。IdM パーミッションを使用すると、どのユーザーがどのオブジェクトにアクセスできるかや、それらのオブジェクトのどの属性にアクセスできるかという制御すら可能になります。IdM を使うと、個別の属性をブラックリスト化したりホワイトリスト化したりすることができるほか、全匿名ユーザー、全認証ユーザー、または権限のあるユーザーの特定グループのみに対するユーザー、グループ、または sudo といった特定の IdM 機能の視認性全体を変更することもできます。パーミッションに対するアプローチがこのように柔軟なことで、たとえば、管理者がユーザーやグループのアクセスをこれらのユーザーやグループが必要とする特定のセクションのみに限定し、他のセクションを完全に見えないようにする場合などに便利になります。
- ロールで利用可能な 権限。権限は、パーミッショングループに必須のものです。パーミッションは、ロールには直接適用されません。パーミッションは権限に追加され、そうすることで権限で完全かつ一貫性のあるアクセス制御ルールが作成されます。たとえば、automount の場所を追加、編集、削除するパーミッションを作成します。そしてそのパーミッションを FTP サービスを管理する別のパーミッションと組み合わせることで、ファイルシステム管理に関連する単一の権限を作成することができます。
- ロール。これは、権限で定義されたアクションの実行が可能な IdM ユーザーのリストになります。
完全に新しいパーミッションを作成したり、既存または新規のパーミッションをベースにして新たな権限を作成したりすることができます。
10.4.1. ロール
10.4.1.1. Web UI でのロールの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Role Based ACI 一覧の上部にある Add をクリックします。
図10.6 新規ロールの追加
- ロール名と説明を入力します。
図10.7 ロール追加のフォーム
- をクリックして新規ロールを保存し、設定ページに移動します。
- Users タブの上部で、グループ追加の場合は Users Groups タブで、Add をクリックします。
図10.8 ユーザーの追加
- 左側のユーザーを選択し、右矢印 を使って Prospective コラムに移動させます。
図10.9 ユーザーの選択
- Privileges タブの上部で をクリックします。
図10.10 権限の追加
- 左側の権限を選択し、右矢印 を使って Prospective コラムに移動させます。
図10.11 権限の選択
- をクリックして保存します。
10.4.1.2. コマンドライン でのロールの作成
- 新規ロールを追加します。
[root@server ~]# kinit admin [root@server ~]# ipa role-add --desc="User Administrator" useradmin ------------------------ Added role "useradmin" ------------------------ Role name: useradmin Description: User Administrator
- 必要な権限をロールに追加します。
[root@server ~]# ipa role-add-privilege --privileges="User Administrators" useradmin Role name: useradmin Description: User Administrator Privileges: user administrators ---------------------------- Number of privileges added 1 ----------------------------
- 必要なグループを追加します。このケースでは、既存の単一グループ
useradminを追加しています。[root@server ~]# ipa role-add-member --groups=useradmins useradmin Role name: useradmin Description: User Administrator Member groups: useradmins Privileges: user administrators ------------------------- Number of members added 1 -------------------------
10.4.2. パーミッション
10.4.2.1. Web UI での新規パーミッションの作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Permissions タスクリンクを選択します。
図10.12 パーミッションタスク
- パーミッション一覧の上部にある Add をクリックします。
図10.13 新規パーミッションの追加
- 表示されるフォームで新規パーミッションのプロパティーを定義します。
図10.14 パーミッション追加のフォーム
- フォームの下にある Add をクリックしてパーミッションを保存します。
以下のパーミッションのプロパティーを指定することができます。
- 新規パーミッションの名前を入力します。
- 適切な Bind rule type を選択します。
- permission がデフォルトのパーミッションタイプになります。これでアクセスが権限とロールによって付与されます。
- all を選択すると、パーミッションがすべての認証ユーザーに適用されます。
- anonymous を選択すると、非認証ユーザーを含むすべてのユーザーにパーミッションが適用されます。
注記
デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。 - パーミッションが付与する権限を Granted rights で選択します。
- パーミッションのターゲットエントリーを識別する方法を定義します。
- Type では、ユーザー、ホスト、またはサービスなどのエントリータイプを指定します。Type で値を設定すると、そのエントリータイプの ACI でアクセス可能な全属性が Effective Attributes に表示されます。Type を定義すると、Subtree と Target DN が定義済みのいずれかの値に設定されます。
- Subtree は、サブツリーエントリーを指定します。このサブツリーエントリー以下のすべてのエントリーがターゲットになります。Subtree はワイルドカードや存在しないドメイン名 (DN) を受け付けないので、既存のサブツリーエントリーを提供してください。例を示します。
cn=automount,dc=example,dc=com
- Extra target filter では、LDAP フィルターを使ってパーミッションが適用されるエントリーを特定します。このフィルターは有効な LDAP フィルターであればどれでも構いません。例を示します。
(!(objectclass=posixgroup))
IdM は、提供されたフィルターの有効性を自動的にチェックします。無効なフィルターが入力された場合は、パーミッションを保存使用とすると IdM が警告します。
- Target DN はドメイン名 (DN) を指定し、ワイルドカードを受け付けます。例を示します。
uid=*,cn=users,cn=accounts,dc=com
- Member of group は、特定のグループのメンバーにターゲットフィルターを設定します。
フィルター設定を記入して Add をクリックすると、IdM がフィルターの有効性を確認します。すべてのパーミッション設定が適切であれば、IdM は検索を実行します。設定が適切でない場合、IdM は該当設定についてのメッセージを表示します。 - Type を設定する場合は、Effective attributes で利用可能な ACI 属性一覧から選択します。Type を使用しない場合は、Effective attributes フィールドに手動で属性を追加します。属性は 1 つずつ追加します。複数の属性を追加するには、Add をクリックして別の入力フィールドを追加します。
重要
パーミッションの属性を設定しない場合は、デフォルトで全属性が含まれることになります。
10.4.2.2. コマンドライン での新規パーミッションの作成
新規パーミッションを追加するには、
ipa permission-add コマンドを発行します。対応するオプションを提供して、パーミッションのプロパティーを指定します。
- プロパティー名を提供します。例を示します。
[root@server ~]# ipa permission-add "dns admin permission"
--bindtypeでは、bind rule type を指定します。このオプションはall、anonymous、およびpermissionの引数を受け付けます。例を示します。--bindtype=all
--bindtypeを使用しない場合は、タイプは自動的にデフォルトのpermissionの値に設定されます。注記
デフォルト以外の bind rule type のパーミッションを権限に追加することはできません。また、権限に既にあるパーミッションをデフォルト以外の bind rule type に設定することもできません。--permissionsには、パーミッションで付与される権限を記載します。複数の属性を設定するには、--permissionsオプションを複数回使用するか、オプションを中括弧内にコンマ区切りの一覧で記載します。例を示します。--permissions=read --permissions=write --permissions={read,write}--attrsには、パーミッションが付与される属性を記載します。複数の属性を設定するには、--attrsオプションを複数回使用するか、オプションを中括弧内にコンマ区切りの一覧で記載します。例を示します。--attrs=description --attrs=automountKey --attrs={description,automountKey}--attrsに提供する属性は既存のもので、該当のオブジェクトタイプに許可されている必要があります。そうでない場合は、コマンドはスキーマ構文エラーで失敗します。--typeでは、ユーザー、ホスト、またはサービスなどのエントリータイプを定義します。各タイプには、許可するされる属性セットがあります。例を示します。[root@server ~]# ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
--subtreeでは、サブツリーエントリーを提供します。これでフィルターがこのサブツリーエントリー以下にあるすべてのエントリーをターゲットとします。--subtreeはワイルドカードや存在しないドメイン名 (DN) を受け付けません。ディレクトリー内の DN を使用してください。IdM は簡素化された平坦なディレクトリーツリー構造を使用しているので、--subtreeを使って、automount の場所のような、他の設定のコンテナーや親エントリーである、一定タイプのエントリーをターゲットにすることができます。例を示します。[root@server ~]# ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --permissions=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
--typeと--subtreeのオプションは、相互排他的になります。--filterは、パーミッションが適用されるエントリーを特定する LDAP フィルターを使用します。IdM は提供されたフィルターの有効性を自動的にチェックします。このフィルターは有効な LDAP フィルターにします。例を示します。[root@server ~]# ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --permissions=write --attrs=description
--memberofでは、特定のグループが存在することを確認した後、そのグループのメンバーにターゲットフィルターを設定します。例を示します。[root@server ~]# ipa permission-add ManageHost --permissions="write" --subtree=cn=computers,cn=accounts,dc=testrelm,dc=com --attr=nshostlocation --memberof=admins
--targetgroupでは、特定のユーザーグループが存在することを確認した後、そのグループにターゲットを設定します。
Target DN 設定は Web UI では利用可能ですが、コマンドラインでは使用できません。
注記
パーミッションの修正および削除に関する情報については、
ipa permission-mod --help と ipa permission-del --help のコマンドを実行してください。
10.4.2.3. デフォルトの管理パーミッション
管理 (Managed) パーミッションは、Identity Management でインストール済みとして提供されるパーミッションです。これらはユーザーが作成した通常のパーミッションのように動作しますが、以下の点が異なります。
- 名前、場所、およびターゲット属性が修正できません。
- 削除することができません。
- 以下の 3 つの属性セットがあります。
- default 属性は IdM が管理し、ユーザーは修正することができません。
- included 属性は、ユーザーが追加する属性です。included 属性を管理パーミッションに追加するには、
ipa permission-modコマンドで--includedattrsオプションを使用して属性を指定します。 - excluded 属性は、ユーザーが削除する属性です。excluded 属性を管理パーミッションに追加するには、
ipa permission-modコマンドで--excludedattrsオプションを使用して属性を指定します。
管理パーミッションは、default および included 属性セットに表示される全属性に適用されますが、excluded セットの属性には適用されません。
管理パーミッション修正時に
--attrs オプションを使用すると、included および excluded 属性セットは自動的に調整され、--attrs で提供された属性のみが有効になります。
注記
管理パーミッションは削除できませんが、その bind type を
permission に設定し、該当管理パーミッションを全権限から削除すると、実質的に無効となります。
すべての管理パーミッションの名前は
System: で始まります。たとえば、System: Add Sudo rule や System: Modify Services などです。
IdM の以前のバージョンでは、デフォルトのパーミッションに異なるスキームを使用しており、ユーザーはデフォルトのパーミッションを修正できず、パーミッションを権限に割り当てることのみが可能でした。これらデフォルトのパーミッションはほとんど管理パーミッションとなっていますが、以下のパーミッションはまだ以前のスキームを使用しています。
- Add Automember Rebuild Membership Task
- Add Replication Agreements
- Certificate Remove Hold
- Get Certificates status from the CA
- Modify DNA Range
- Modify Replication Agreements
- Remove Replication Agreements
- Request Certificate
- Request Certificates from a different host
- Retrieve Certificates from the CA
- Revoke Certificate
- Write IPA Configuration
管理パーミッションを Web UI から修正する場合は、修正できない属性は灰色表示となります。
図10.15 灰色表示となった属性
コマンドラインから管理パーミッションを修正する場合、修正不可能な属性の変更はシステムで許可されません。たとえば、デフォルトの
System: Modify Users パーミッションをグループに適用しようとすると失敗します。
$ ipa permission-mod 'System: Modify Users' --type=group ipa: ERROR: invalid 'ipapermlocation': not modifiable on managed permissions
ただし、
System: Modify Users パーミッションを GECOS 属性に適用しないようにすることは可能です。
$ ipa permission-mod 'System: Modify Users' --excludedattrs=gecos ------------------------------------------ Modified permission "System: Modify Users"
10.4.2.4. Identity Management の以前のバージョンのパーミッション
Identity Management の以前のバージョンでは、パーミッションは別の方法で処理されていました。たとえば、
- 書き込み、追加、および削除パーミッションタイプのみが利用可能でした。
- パーミッション設定のオプションは詳細設定ができませんでした。たとえば、同一のパーミッションにフィルターとサブツリーの両方を追加することはできませんでした。
- グローバルの IdM ACI は、ログインしていない匿名ユーザーを含めた、サーバーの全ユーザーに読み取りアクセスを付与していました。
パーミッションの処理方法が新しくなったことで、IdM ではユーザーまたはグループアクセスの制御が大幅に改善しました。一方で、以前のバージョンとの後方互換性も維持しています。IdM の以前のバージョンからアップグレードすると、全サーバー上のグローバルの IdM ACI が削除され、管理パーミッションで置き換えられます。
以前の方法で作成されたパーミッションは、修正時に自動的に新しいスタイルに変換されます。変更されない場合は、以前のスタイルのパーミッションは変換されずに残ります。パーミッションは一旦新しいスタイルを使用すると、元のスタイルに戻すことはできません。
注記
IdM の以前のバージョンを実行しているサーバー上でパーミッションを権限に割り当てることは、引き続き可能です。
ipa permission-show と ipa permission-find のコマンドは、新スタイルと以前のスタイルの両方のパーミッションを認識します。これらコマンドの出力は新スタイルになりますが、パーミッション自体を変更するものではありません。パーミッションエントリーはデータを出力する前にメモリーでのみアップグレードされ、変更は LDAP にコミットされません。
新スタイルおよび旧スタイルのパーミッションは両方とも、以前のバージョンの IdM および現行バージョンの IdM を実行している全サーバーに効力が及びます。ただし、以前のバージョンの IdM を実行しているサーバーでは新スタイルのパーミッションの作成や変更はできません。
10.4.3. 権限
10.4.3.1. Web UI での新規権限の作成
- トップメニューで IPA Server タブを開き、Role Based Access Control サブタブを選択します。
- Privileges タスクリンクを選択します。
図10.16 権限タスク
- 権限一覧の上部にある Add をクリックします。
図10.17 新規権限の追加
- 権限の名前と説明を入力します。
図10.18 権限追加のフォーム
- をクリックして、権限設定ページに移動し、パーミッションを追加します。
- Permissions タブを選択します。
- 権限に追加するパーミッション一覧のトップにある Add をクリックします。
図10.19 パーミッションの追加
- 追加するパーミッションの名前の横にあるチェックボックスを選択し、右矢印 を使って Prospective コラムに移動させます。
図10.20 パーミッションの選択
- をクリックして保存します。
10.4.3.2. コマンドライン での新規権限の作成
権限のエントリーは
privilege-add コマンドで作成されます。次に、privilege-add-permission コマンドを使ってパーミッションを権限グループに追加します。
- 権限エントリーを作成します。
[jsmith@server ~]$ ipa privilege-add "managing filesystems" --desc="for filesystems"
- 希望するパーミッションを割り当てます。
[jsmith@server ~]$ ipa privilege-add-permission "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.