PAM SC の許可の管理
内容
capamsc141
アクセス権限
capamsc141
CA Privileged Access Manager
の主な目的は、アクセス権限(アクセス権とも呼ばれます)を割り当て、適用することです。アクセス権限には、常に以下のコンポーネントがあります。
- アクセスの適用先のリソース(ファイル、ホスト、端末など)。
- アクセスのタイプ(読み取り、書き込み、削除、ログイン、実行など)。
- アクセサ(ユーザまたはグループのいずれか)。
以下の 1 つ以上の状況に当てはまる場合、ユーザに対してリソースにアクセスする権限が割り当てられます。
- リソースの ACL によってユーザにアクセス権限が許可されている。
- ユーザが、アクセス権限が割り当てられたグループのメンバ。
- ユーザが、アクセス権限があるプログラムを実行してる。たとえば、ユーザには、SPECIALPGM クラス内のプログラムを実行する権限、または SUDO クラス内のコマンドを実行する権限が割り当てられている。
クラス別のアクセス権限の詳細については、「selang リファレンス ガイド」を参照してください。
アクセス権限の設定 - 例
capamsc141
例: 内部ユーザへ読み取りアクセス権限を付与する
以下の selang コマンドは、端末 tty30 の ACL に内部ユーザ internal_user を追加し、端末への読み取りアクセス権限を付与します。
authorize TERMINAL tty30 access(READ) uid(internal_user)
例: エンタープライズ ユーザへ読み取りアクセス権限を付与する
以下の selang コマンドは、端末 tty30 の ACL にエンタープライズ ユーザ Terry を追加し、端末への読み取りアクセス権限を付与します。
authorize TERMINAL tty30 access(READ) xuid(Terry)
例: リソースに対するエンタープライズ ユーザのアクセス権限を変更する
以下の selang コマンドは、端末 tty30 への Terry のアクセスを none に設定し、Terry のアクセスを拒否します。
authorize TERMINAL tty30 access(NONE) xuid(Terry)
例: エンタープライズ ユーザのアクセス権限をリソースから削除する
以下の selang コマンドは、端末 tty30 の ACL から Terry を削除します。
authorize- TERMINAL tty30 xuid(Terry) access-
これで、Terry には、端末へのデフォルトのアクセス権が割り当てられます。
例: エンタープライズ ユーザにサブ管理者アクセスを付与する
以下の selang コマンドは、エンタープライズ ユーザ Terry を、ユーザとファイルを管理する権限を持つサブ管理者として設定します。
authorize ADMIN USER xuid(Terry) authorize ADMIN FILE xuid(Terry)
アクセス制御リスト
capamsc141
リソースに対するアクセス権限は、アクセス制御リストに指定されます。各リソース レコードには、少なくとも 2 つのアクセス制御リストが割り当てられます。
- ACLリソースへのアクセスが許可されるアクセサと、そのアクセサが許可されるアクセスのタイプを指定します。
- NACLリソースへのアクセスが拒否されるアクセサと、そのアクセサが拒否されるアクセスのタイプを指定します。
アクセス権限は、ユーザがローカルでログインするかどうかなど、アクセスに関する状況によっても異なります。
条件付きアクセス制御リスト
capamsc141
条件付きアクセス制御リスト(CACL)は、ACL の拡張機能です。アクセサがリソースへのアクセスを試みたときに、リソースの ACL と NACL にそのユーザのアクセス権限が定義されていない場合、
CA Privileged Access Manager
は条件付きアクセス制御リストを確認します。条件付きアクセス制御リストでは、アクセスが特定の方法による(たとえば、指定されたプログラムの使用による)場合のリソースへのアクセスを指定します。
たとえば、条件付きアクセス制御リストを使用して、Program Pathing ルールを定義できます。
CA Privileged Access Manager
では、以下の条件付きアクセス制御リストを使用することができます。- プログラム アクセス制御リスト(PACL)
- TCP クラス アクセス制御リスト
- CALENDAR クラス アクセス制御リスト
条件付きアクセス制御リストのエントリを定義するには、selang authorize コマンドの via オプションを使用します。
他のアクセス制御リストと同様に、条件付きアクセス制御リストの各エントリでは、リソースへのアクセスが許可されるアクセサと、許可されるアクセスのタイプを指定します。さらに、条件付きアクセス制御リストのエントリでは、権限を割り当てる条件も指定します。PACL の条件とは、アクセサがアクセスをするために実行する必要があるプログラムの名前です。
例: PACL の使用
エンタープライズ ユーザ sysadm1 がプログラム secured_su を実行することによってスーパーユーザになれるようにするには、以下の selang コマンドを使用して、条件付きアクセス ルールを指定します。
authorize SURROGATE user.root xuid(sysadm1) via(pgm(secured_su))
defaccess - デフォルト アクセス フィールド
capamsc141
リソースのレコードには、デフォルト アクセス フィールド defaccess を含めることができます。defaccess フィールドの値には、リソース アクセス制御リストのいずれでもカバーされないアクセサに許可するアクセス権限を指定します。
リソースに対するアクセス権限を決定する方法
capamsc141
アクセサがリソースにアクセスしようとすると、
CA Privileged Access Manager
はアクセス権限をチェックします。結果が得られるまで、事前定義された順序で 1 つ以上のチェックが実行されます。チェックによってアクセスの結果(アクセスの拒否または許可)が得られると、CA Privileged Access Manager
はそれ以上チェックを実行しません。代わりに、結果が返されます。これらのチェックを実行する順序は重要です。リソースごとに、
CA Privileged Access Manager
はデフォルトでは以下の順序でアクセス レコードをチェックします。- リソースの時間ベースの制限
- リソースの所有権(所有者はアクセスが許可される)
- B1 チェック
- リソースの NACL
- リソースの ACL
- リソースの PACL
- リソースの defaccess フィールド
accpac オプションの設定では、最後の 2 つのチェックの順序を決定します。リソース PACL の使用を無効にするには、selang コマンドの setoptions setpacl- を使用します。
1 つのアクセス制御リストに、同じユーザに影響する複数のエントリが含まれていることがあります。たとえば、ユーザを明示的に指定するエントリと、そのユーザが属する各グループに対するエントリが含まれることがあります。
CA Privileged Access Manager
は、各レベルで有効なすべてのエントリをチェックしてから、次のレベルに進みます。各レベルで競合するルールを解決する方法の詳細については、「ユーザのアクセス権限とグループのアクセス権限との相互作用」を参照してください。例: ファイルのアクセス許可の結果
以下の表は、アクセサ user1 がリソース file1 の読み取りを試みることを前提としています。
以下の表では、
CA Privileged Access Manager
は accpacl オプションのデフォルトの設定に従って PACL を使用します。user1 に対する NACL 内のエントリ | user1 に対する ACL 内のエントリ | user1 に対する PACL 内のエントリ | defaccess 内のエントリ | 結果的に付与されるアクセス許可 |
読み取り | (任意) | (任意) | (任意) | 読み取り拒否 |
(未定義) | なし | (任意) | (任意) | 読み取り拒否 |
(未定義) | 読み取り | (任意) | (任意) | 読み取り許可 |
(未定義) | (未定義) | via pgm securereader | (任意) | securereader プログラムの実行によって読み取り許可 |
(未定義) | (未定義) | (未定義) | 読み取り | 読み取り許可 |
エントリが
(未定義)
と表示されている場合、user1 に対するエントリがそのアクセス制御リストに存在しません。エントリが
(任意)
と表示されている場合、CA Privileged Access Manager
によるチェックが行われないため、そのアクセス制御リスト内のエントリは関係ありません。CA Privileged Access Manager
は、左から右にチェックします。すべての行で、アクセスが定義されているセルの右側にあるセルの値は、(任意)
であることに注意してください。逆に、アクセスが定義されているセルの左側にあるセルの値はすべて(未定義)
です。ユーザのアクセス権限とグループのアクセス権限との相互作用
capamsc141
ユーザ、およびユーザが属するグループに対して、アクセス権限を明示的に許可または拒否することができます。場合によってはこれらのアクセス権限が競合することがあります。以下の例では、ユーザが 2 つのグループ(Group 1 と Group 2)のメンバであるときに競合するアクセス権限が同じリソースに割り当てられた場合、どのような結果になるかを示します。
累積グループ権限オプションが設定されていることを前提とします(デフォルトの設定)。
ユーザのアクセス権限 | グループ 1 のアクセス権限 | グループ 2 のアクセス権限 | 最終的なアクセス権限 |
アクセス拒否 | (任意) | (任意) | アクセス拒否 |
アクセス許可 | (任意) | (任意) | アクセス許可 |
(未定義) | アクセス許可 | (未定義) | アクセス許可 |
(未定義) | (未定義) | アクセス許可 | アクセス許可 |
(未定義) | アクセス許可 | アクセス許可 | アクセス許可 |
(未定義) | アクセス拒否 | (任意) | アクセス拒否 |
(未定義) | (任意) | アクセス拒否 | アクセス拒否 |
エントリが
(未定義)
と表示されている場合、これはユーザまたはグループに対するエントリが定義されていないことを意味します。エントリが
(任意)
と表示されている場合、これは、CA Privileged Access Manager
によるチェックが行われず、アクセス権限は関係ないことを意味します。累積グループ権限(ACCGRR)
capamsc141
累積グループ権限
オプション(ACCGRR)は、CA Privileged Access Manager
がリソースの ACL をチェックする方法を制御します。ACCGRR が有効な場合、CA Privileged Access Manager
は、ACL で、ユーザが属するすべてのグループで許可されている権限をチェックします。ACCGRR が無効な場合、CA Privileged Access Manager
は、ACL で適用可能なエントリのいずれかに値 none が含まれているかどうかをチェックします。none が含まれている場合、アクセスは拒否されます。none が含まれていない場合、CA Privileged Access Manager
は、ACL 内の最初の適用可能なグループ エントリを除くすべてのグループ エントリを無視します。このオプションはデフォルトで有効です。ACCGRR オプションを有効にするために、以下の selang コマンドを使用できます。
setoptions accgrr
ACCGRR オプションを無効にするには、以下の selang コマンドを使用できます。
setoptions accgrr-
セキュリティ レベル、セキュリティ カテゴリ、およびセキュリティ ラベル
capamsc141
セキュリティ レベルとセキュリティ カテゴリは、リソースへのアクセスを制限する追加の方法を提供して、アクセス制御リストを補完します。
セキュリティ ラベルは、セキュリティ レベルとセキュリティ カテゴリを 1 つにまとめて、管理を簡易化する手段です。
セキュリティ レベル
capamsc141
セキュリティ レベル
は、アクセサおよびリソースに割り当てることのできる 0 から 255 までの整数です。リソースのアクセス制御リストでユーザにアクセス権限が付与されていても、アクセサのセキュリティ レベルがリソースのセキュリティ レベルより低い場合、そのアクセサはそのリソースにアクセスできません。リソースのセキュリティ レベルがゼロの場合、そのリソースに対してセキュリティ レベルのチェックは実行されません。セキュリティ レベルがゼロのアクセサは、セキュリティ レベルがゼロ以外のリソースにアクセスできません。
セキュリティ カテゴリ
capamsc141
セキュリティ カテゴリは、CATEGORY クラスにあるレコードの名前です。セキュリティ カテゴリは、アクセサとリソースに割り当てることができます。リソースに割り当てられているすべてのセキュリティ カテゴリにアクセサが割り当てられている場合のみ、そのアクセサはリソースにアクセスできます。
セキュリティ ラベル
capamsc141
セキュリティ ラベル
は、SECLABEL クラスにあるレコードの名前です。セキュリティ ラベルによって、セキュリティ ラベルと複数のセキュリティ カテゴリを 1 つにまとめることができます。セキュリティ ラベルをアクセサまたはリソースに割り当てると、そのセキュリティ ラベルに関連付けられたセキュリティ レベルとセキュリティ カテゴリの組み合わせが、アクセサまたはリソースに設定されます。セキュリティ ラベルは、アクセサまたはリソースに設定された特定のセキュリティ レベルおよびセキュリティ カテゴリよりも優先されます。例: セキュリティ ラベル High_Security の使用
High_Security は、セキュリティ レベル 255 と、セキュリティ カテゴリ MANAGEMENT および CONFIDENTIAL を含むセキュリティ ラベルであるとします。
ユーザ user1 をセキュリティ ラベル High_Security に割り当てた場合、user1 には、セキュリティ レベル 255 と、セキュリティ カテゴリ MANAGEMENT および CONFIDENTIAL が設定されます。