9.4. 拡張例： すべてのリソースの表示、一部のリソースの編集
セキュリティーや管理プラクティスについては、アクセスは特定のユーザーに必要なものに制限する必要があります。セキュリティーは、デフォルトとしてアクセスを制限することで開始され、定義された権限（読み取り、変更、削除）を特定のリソースに明示的に付与します。
ユーザー（またはユーザーのセット）に必要なすべてのものを定義するアクセス制御ルールのセットを作成することは可能ですが、実際にはこれらのルールは複雑で複雑で複雑で、簡単に古い、または不正確です。アクセス制御は関係の定義です。多くの場合、ユーザーが持つさまざまな関係は、1 つのロールで定義することは複雑ではありません。
ロールの効果は累積的です。ユーザーのアクセスレベルの 合計 は、そのロールが属するすべてのロールの合計です。指定したリソースグループ内のすべてのリソースグループ内のリソースへのアクセス（これらのロールに付与されるパーミッション）が含まれます。
この影響は累積的であるため、レイヤー化された方法でアクセス制御を設計することが最も効果的です。これにより、アクセスセットが定義され、これらのロールを段階的にユーザーに追加することができます。
階層化された手法により、管理者は、人員およびインフラストラクチャーの分割に合わせたマクロレベルで、複雑な関係を定義および効果的に維持でき、また異なるリソースとの異なる関係を持つマイクロレベルでは、複雑な関係を定義および効果的に維持できます。
設定
たとえば、Corp. には、IT インフラストラクチャーに関連する 3 つの主要グループがあります（開発、QE、および実稼働環境）。各グループには、構成の管理、パフォーマンス設定の管理、および新規アプリケーションのロールアウトをサポートするために、他のチームからの情報が必要ですが、独自のシステムを管理できます。
各グループ内には、アプリケーションの新規バージョンを更新してデプロイし、最適なパフォーマンスを得るためにシステム設定を管理する 2 つの異なるアプリケーション管理タスクがあります。
The Plan
Tim the IT Guy は、まずアクセス制御内で表現する必要があるさまざまな関係を定義します。
- インフラストラクチャー内のすべてのスタックのパフォーマンスデータを表示できる必要があります。
- 各部門には、独自のシステムへの書き込みアクセスが必要になります。
- 各グループ内の少なくとも一部の管理者には、システム設定を更新する必要があります。
- 各グループ内の少なくとも一部の管理者には、バンドルを作成およびデプロイして、独自のグループ内でアプリケーションを管理する機能が必要です。
最初のステップは、各グループの最低必要なリソースで必要なグループを定義することです。簡素化された構造では、以下のようになります。
- 各スタック環境内のすべてのリソースが含まれる混合グループ。スタックには、プラットフォーム、Postgres データベース、EAP サーバー、Web コンテキスト、実稼働環境の管理に使用するその他のリソースが含まれます。これにより、Dev Stack、QE Stack、および Production Stack の 3 つのグループが生成されます。
- 3 つのスタックグループすべてを含む「すべてのスタック」ネストされたグループ。このグループは、すべてのリソースに該当せず、スタックグループのみが含まれます。ただし、JBoss ON 関連のリソースや、これらのスタックには関係しないその他の管理リソースが除外されます。
- これらの環境にはアプリケーション開発が含まれるため、デプロイメントを維持するために各組織に独自のバンドルグループも必要です。
- 環境間でバンドルをプロモートするためのメクnism が必要です。Tim the IT Guy は、「Promote Bundles」グループを作成し、別の環境に移動する準備ができたときにバンドルを追加できます。
同じ部門内の異なるユーザーが個別のリソースへのアクセスレベルを必要とする場合に、リソースとバンドルグループごとに分類できます。
次に、さまざまなユーザーがアクセスを必要とします。次に、Tim（IT 管理者）は、必要な異なるパーミッションをマッピングします。
- 設定ビューのみの権限を含む、すべてのリソースへの表示のみ権限
- スタック内のリソースに対する権限の編集によるモニタリング、アラート、ドリフト、操作、およびインベントリー
- 設定用にスタック内のリソースに対する権限の編集
- スタック内のバンドル権限の表示
- スタック内でのバンドル権限の作成およびデプロイ
各機能グループには基本的に 3 つのタイプのユーザーがあります。
- 一般ユーザー
- リソース設定を管理する管理者
- グループ間のバンドルを作成（昇格）できる管理者
ロールは、各リソースおよびバンドルグループに照合され、そのグループの最小要件（ローカルビューおよび編集）に設定されたパーミッションを持ちます。管理者のために、追加のパーミッション（設定およびプロモートコンテンツ）は、追加のパーミッションのみを持つ追加のロールを作成して追加されます。
通常のユーザーの場合は、スタック内のすべてのリソースおよびバンドルおよびリソースにロールを追加します。
Dev Stack
Bundle Group
|
Role BG1
|
V
Regular Joe
^ ^
| |
Role RG1 Role RG2
| |
"All Stack" Dev Stack
Resource Resource
Group Group
「 all Stack」ロールについて、すべてのインベントリーエリア および 設定に読み取り専用パーミッションを追加します。
^
|
Role RG1 <------Permissions
| |
"All Stack" View.alerts
Resource View.inventory
Group View.measurements
View.etc...
View.configuration
スタックグループについて、Tim(Timum)は、管理者ユーザー用に予約される設定を除き、すべての機能領域（measurement、アラート、操作、イベント）を編集するパーミッションを設定します。リソースグループには、バンドルをグループのリソースに デプロイする パーミッションも含まれます。バンドルをデプロイする機能は、バンドルを作成する機能とは異なります。
^
|
Role RG2 <------Permissions
| |
Dev Stack Edit.alerts
Resource Edit.inventory
Group Edit.measurements
Edit.etc...
Deploy.bundles
最後に、通常ユーザーのバンドルグループ内でバンドルを表示および作成するパーミッションを追加します。
Dev Stack
Bundle Group
|
Role BG1 <-----Permissions
| |
V View.bundles
Create.bundles
この設定では、管理者がスタック内でリソース設定の管理と次のワークグループにバンドルをプロモートする 2 つの追加のタスクがあります。管理者は、通常ユーザーの全ロールと、追加のタスクの追加ロールに追加されます。
Tim the IT Guy は、設定パーミッションを定義するために追加のロールを 1 つ作成します。これにより、管理者が表示できるリソースグループにのみ設定の編集が許可されます（作業グループ内のリソースグループ）。
"Regular Joe" roles
|
V
Group Lead <------Role RG3
|
Permissions
|
Edit.configuration
最後に、各管理者は各バンドルグループのロールに追加されます。バンドルグループのロールは、コンテンツの作成のみにバンドルグループへのアクセスを付与し、表示、デプロイ、または削除は行いません。これにより、管理者はワークグループ間でコンテンツをプロモートできますが、デプロイしたり、リソース設定に影響するりすることはできません。
Dev Stack Permission:
Bundle Group Create.Bundles
\ /
\ /
Role BG1
|
V
Role BG2 ----> Group Lead <---- Role BG3
/ \ / \
/ \ / \
QE Stack Permission: Prod Stack Permission:
Bundle Group Create.Bundles Bundle Group Create.Bundles結果
各グループ内のユーザーには、必要なパフォーマンスや設定情報を表示するアクセス権が付与されますが、変更できるのは指定されたグループ内のリソースのみです。各グループ内の管理者のみが設定変更を行うことができます。
アプリケーションのデプロイメントは、各機能領域（開発、QE、および実稼働環境）に限定されます。他のグループにコンテンツを作成できるが、デプロイできない特定の管理者。
