要求事項
以下のように、K5を利用する組織や部門の用途に応じて、部門別に環境を構築したいといった要求事項に対応するパターンです。
- 課金など契約は1つの組織でまとめるが、リソース配備・削除やアクセス制御は部門ごとに行いたい
- イントラネットなどとの外部接続はセキュリティの統制上1つのプロジェクトにまとめるが、
業務システムは部門ごとに分けて管理したい
対応するK5デザインパターン概要
K5では、契約内で利用する仮想リソース、グループ、およびユーザーを、プロジェクトという単位で分割して管理します。
プロジェクトは、利用者の目的に応じて使い分けることができます。
このパターンでは、部門別にプロジェクトを分割する活用例を記載します。
プロジェクト作成の手順は、大枠で以下のとおりです。
- 全体管理者の権限 (ロール) をもつユーザが、部門別に、それぞれ別のプロジェクトを作成します。
- 部門のユーザごとに、プロジェクトに対する権限 (ロール) を設定します。
- ユーザが多い場合は、複数のユーザを1つにまとめるグループを使います。
グループに対しても、ユーザに対する設定と同じように、ロールを設定することができます。
構造 (イメージ図)
実装サンプル
メリット・効果
- 各システムの構築運用を部門ごとの利用者に委任することが可能
- 外部接続のプロジェクトを業務システムのプロジェクトと分離することで、
セキュリティ統制などを一部門に集約することが可能
注意事項
- 異なるプロジェクト同士では、セキュリティグループを共有することは出来ません。
- ユーザには、API操作の際にデフォルトで属するプロジェクトが割り当てられます。
あるユーザがプロジェクトA とプロジェクトB に属する場合、いずれかがAPI操作の際にデフォルトで割り当てられます。
プロジェクトA がデフォルトで割り当てられている場合に、プロジェクトB のリソースに対する API操作をする場合は、
プロジェクトB に対する操作を行えるよう、APIの認証トークンを取得しなおしてください。
その他
特にありません。
関連資料
(2015年11月検証)