FlexOrgs の概要

FlexOrgs の内容とそれを使用する理由

FlexOrgs を使用すると、組織は、組織階層の複数のレベルにわたるユーザーアクセス、共有、および委任をより細かく制御できます。

FlexOrgs では、組織を複数の組織単位 (OU) で構成される階層として構築および管理します。各組織単位には、VMware Aria Cost powered by CloudHealth プラットフォームを通じてリソースを管理するためのアクセス権と責任が割り当てられます。

FlexOrgs を使用すると、次のことができます。

会社の階層を反映した組織構造を作成します。
クラウドインフラストラクチャの管理方法を反映した組織単位を定義およびリンクします。
各 OU が属しているインフラストラクチャのみを表示するように、階層内の各組織単位を分離します。
ユーザーを特定の組織単位にマッピングし、各組織単位でのアクセスレベルを制御します。

FlexOrgs の基本単位

FlexOrgs は、組織単位 (OU)、ユーザー、ユーザーグループ、ロールドキュメントで構成されています。

組織単位は、割り当てられたユーザーがプラットフォームで表示できるコンテンツとデータを定義し、AWS アカウント、Azure サブスクリプション、または GCP プロジェクトに基づいています。OU は、最上位の組織単位 (TLOU) の下で、階層が親 OU と子 OU に分かれた編成になっています。組織単位の詳細については、「組織単位を使用した組織階層の定義」を参照してください。
ユーザーは、VMware Aria Cost プラットフォームにアクセスできる従業員です。
ユーザーグループは、OU の特性を定義し、ロールドキュメントを使用してユーザーグループ内のユーザーに権限を割り当てます。ユーザーグループは、ユーザーに 1 つ以上の OU へのアクセス権を付与できます。手動でまたはシングルサインオン (SSO) を使用して、ユーザーをユーザーグループに割り当てることができます。ユーザーグループの詳細については、「ユーザーグループを使用した FlexOrgs 関係の定義」を参照してください。
ロールドキュメントは、ユーザーがプラットフォームでコンテンツに対してできることを定義する権限のリストです。ロールドキュメントはユーザーグループに添付されます。ロールドキュメントの詳細については、「ロールドキュメントを使用した権限の定義」を参照してください。

組織単位を使用して組織階層を定義

組織階層は、接続された組織単位 (OU) のコレクションとして表されます。各 OU は、クラウドインフラストラクチャの一部を所有します。最上位の組織単位 (TLOU) と呼ばれる、階層の最上部にある OU は、組織全体のすべての資産を所有します。

階層の各レベルには、覚えておくべき運用上のルールがあります。

org-hierarchy-representation

最上位の組織単位はすべての資産を所有する

運用ルール 1：VMware Aria Cost の各顧客は、組織のすべての資産を所有する TLOU を 1 つだけ持つことができます。

VMware Aria Cost の顧客である Acme Corporation が VMware Aria Cost プラットフォームにログインすると、Acme Corporation と呼ばれる最上位の OU (TLOU) が作成されます。この TLOU は、この顧客のすべてのクラウド資産を所有します。組織ごとに 1 つの TLOU しか設定できません。VMware Aria Cost プラットフォームで資産と呼ばれるクラウドリソースには、EC2 インスタンス、EBS ボリューム、S3 バケットなど、さまざまなタイプがあります。

階層の子 OU による分散

運用ルール 2：子 OU はそれぞれ 1 つの親 OU のみを持つことができますが、親 OU は複数の子 OU を持つことができます。

運用ルール 3：組織には最大で 10 レベルを指定できます。各レベルには任意の数の OU を設定できますが、組織全体で最大で 5,000 OU を含めることができます。

この例では、TLOU Acme Corporation が 1,000 のクラウド資産を所有しています。これらの資産は、運用上の境界を確立するためにより小さな子 OU に分散できます。その後、各 OU が個別に動作し、特定のユーザーおよびグループへのアクセスを提供して、所有する資産を管理します。子 OU は、その親 OU に属する資産のみを継承できます。親 OU は、その子 OU の 1 つにのみ資産を割り当てることができます。つまり、各資産は階層レベルごとに 1 つの OU にのみ属することができます。子 OU はそれぞれ 1 つの親 OU のみを持つことができますが、親 OU は複数の子 OU を持つことができます。

この分割を行う簡単な方法は、Acme Corporation の部門別またはチーム固有の階層を使用して、それを VMware Aria Cost プラットフォームに実装することです。

構築された 3 レベルの階層はこのように VMware Aria Cost プラットフォーム内の所有権構造に変換されます。

レベル	このレベルの内容	VMware Aria Cost での指定
ルート	Acme Corporation	TLOU
レベル 1	ビジネスグループ (x2)	2 つの OU
レベル 2	製品 (x4)	4つの OU
レベル 3	チーム (x8)	8つの OU

ユーザーグループを使用して FlexOrgs 関係を定義

ユーザーグループは、1 つ以上の OU のコンテンツに対して同じレベルのアクセス権を必要とするユーザーの集合です。たとえば、あるユーザーグループは、同じチームに属する従業員として定義される場合があります。ユーザーグループは、ユーザー、OU、およびロールドキュメント間の関係を定義します。ユーザーグループは、ロールドキュメントを OU にリンクして、ユーザーグループのユーザーがその OU に対して持つアクセス権のレベルを定義します。1 つのユーザーグループに複数の OU/ロールドキュメントのペアを含めることができます。これにより、1 つのユーザーグループ内の異なる OU に対するさまざまなレベルのアクセス権をユーザーに付与できます。

ユーザーグループを作成する方法については、「ユーザーグループの作成」を参照してください。

ug-ou-rd-relationship

1 つの OU を複数のユーザーグループに割り当てることができます。これにより、さまざまなユーザーグループのユーザーが、異なるレベルのアクセス権で同じ OU にアクセスできます。

ug-overlap

SSO 属性に基づいてユーザーをログイン時に自動的に追加するように、ユーザーグループを構成できます。ユーザーをユーザーグループに手動で割り当てることもできます。

ユーザーグループとロールドキュメントの階層

ロールドキュメントの階層は、ユーザーグループ内でのみ機能します。OU が複数のユーザーグループに割り当てられている場合、1 つのユーザーグループのロールドキュメント階層は、2 番目のユーザーグループのロールドキュメント階層には影響しません（ユーザーが両方のユーザーグループに割り当てられていない限り）。ユーザーが同じ OU の複数のユーザーグループに割り当てられている場合、競合する権限は 許可の無効化を拒否 によって解決されます。

deny-overruling

たとえば、同じ OU に 2 つのユーザーグループがあります。ユーザーグループ A の管理者ユーザーロールのドキュメントでは、VMware Aria Cost プラットフォームへの完全な読み取りおよび編集アクセス権がユーザーに付与されます。ユーザーグループ B のエンドユーザーロールのドキュメントでは、VMware Aria Cost プラットフォーム全体に対する読み取り専用アクセス権が付与されます。両方のユーザーグループに同じ OU がある場合でも、2 つのユーザーグループは完全に区別され、互いに影響を与えることはありません。ユーザーグループ A のユーザーは、プラットフォームへの編集アクセス権を失うことはありません。

overlapping-permissions

1 人のユーザー（ユーザー I）が両方のユーザーグループに属しています。ユーザーグループ A の管理者ユーザーロールドキュメントには、ユーザーグループ B のエンドユーザーロールドキュメントよりも高い権限が付与されています。この場合、ロール階層が有効です。エンドユーザーロールドキュメントの拒否権限は、管理者ユーザーロールドキュメントの許可権限よりも優先されます。ユーザー I は、この OU のプラットフォームに対する読み取り専用アクセス権を持っています。ユーザーグループ A のほかのメンバーは、この OU の別のユーザーグループに属していないため、読み取りおよび編集アクセス権を保持します。

ロールドキュメントを使用して権限を定義

ロールドキュメントでは、ユーザーに付与される権限を定義します。これにより、ユーザーがアクセスできるプラットフォーム機能が決定されます。たとえば、管理者のロールドキュメントでは、完全な読み取り/編集権限を付与することができます。また、エンドユーザーのロールドキュメントによって、制限付きの読み取り権限が付与される場合があります。ロールドキュメントは、ユーザーグループを介して OU とユーザーに割り当てられます。複数のロールドキュメントを 1 つの OU に割り当てると、権限の重複するタペストリが作成されます。

ロールドキュメントを作成する方法については、ロールドキュメントの作成を参照してください。

role-doc-hierarchy

ロールドキュメントは、トップダウンで OU 階層に適用されます。したがって、親 OU に割り当てられているロールドキュメント内の権限も、子 OU に割り当てられます。親 OU と子 OU の権限が競合している場合、拒否権限によって許可権限が常に却下されます。

運用ルール 4：子 OU は、親 OU のロールドキュメントの権限を継承します。

運用ルール 5：OU の割り当てられたまたは継承されたロールドキュメントの権限が競合する場合、拒否権限が許可権限を却下します。

ロールドキュメントの階層の例

例 1

この例では、親 OU「Acme Corporation」には、2 つの子 OU（ビジネスグループ 1、およびビジネスグループ 2）があります。Acme Corporation には、この OU のユーザーが VMware Aria Cost プラットフォームのパースペクティブを作成、読み取り、更新、および削除することを許可するロールドキュメントが割り当てられています。ビジネスグループ 2 のロールドキュメントも、パースペクティブに完全にアクセスすることを許可しますが、ビジネスグループ 1 のロールドキュメントはあらゆるアクセスを拒否します。Acme Corporation とビジネスグループ 2 の両方のユーザーは、パースペクティブを作成、読み取り、更新、および削除することができますが、ビジネスグループ 1 の拒否権限が Acme Corporation の許可権限を却下するため、ビジネスグループ 1 のユーザーはこれらの操作を実行することができません。

role-docs-example1

例 2

この例では、親 OU（ビジネスグループ 1）に、パースペクティブの作成、読み取り、更新、および削除のアクセス権限を拒否するロールドキュメントが割り当てられています。親 OU に割り当てられたロールドキュメントの権限は子 OU にも割り当てられるため、製品 1.1 と製品 1.2 の両方にもこの権限が割り当てられます。拒否権限は許可権限を却下するため、製品 1.1 および製品 1.2 に割り当てられたユーザーはパースペクティブにアクセスできません。

role-docs-example-2

例 3

この例では、OU に 2 つの異なるロールドキュメントが割り当てられています。ロールドキュメント B では、パースペクティブを作成、読み取り、更新、削除するためのアクセス権限が拒否されていますが、ロールドキュメント C ではアクセス権限が許可されています。拒否権限は許可権限を却下するため、チーム 1.1.1 に割り当てられたユーザーはパースペクティブにアクセスできません。

role-docs-example-3

FlexOrgs プランニングのベストプラクティス

VMware Aria Cost で FlexOrgs を構成する前に、組織単位 (OU)、ロールドキュメント、およびユーザーグループの各 FlexOrgs 構成要素を編成および構成する方法を計画する必要があります。

組織の目標の決定

FlexOrgs を構築するときに、構築プロセスを始めるにあたって、どの作業に集中すべきかが把握できるように、組織の最終的な目標を理解しておくことが重要です。

リソース管理の委任

組織の規模が大きくなると、発生する問題も大規模になる可能性があります。FlexOrgs は、組織内のさまざまなレベルでユーザーに任せる業務管理と責任の範囲を広げることにより、この問題の解決を図る上で役立ちます。組織内の各レベルで管理者、パワーユーザー、および通常のユーザーに、適切な権限レベルを付与することができます。これにより、ユーザーは所属する OU にあるレポートやポリシーなど、独自のコンテンツを作成できるようになります。

FlexOrgs を使用してリソース管理を委任することが組織の目標である場合は、まず組織の階層構造を定義することから始めることをお勧めします。

組織で必要な階層はいくつありますか。
各階層は、部門、BU、またはチームなど、どのように定義されますか。
各階層に属するユーザーのグループはどのようなものですか。

このフレームワークが決まった段階で、ユーザーの各グループにどの権限セットが適しているかを戦略的に決めることができます。

セキュリティ

FlexOrgs により、セキュリティ意識の高い組織では、可視性を制限し、不要なアクションを防止するほか、ユーザーが見るべきでない情報を非表示にするためのコントロールを強化することができます。システム定義、またはカスタム仕様で作成したロールドキュメント、および綿密に考えられた FlexOrgs 構造を組み合わせることにより、個々のユーザーの可視性とアクションを厳密に制御することができます。

組織での優先事項がセキュリティの場合は、管理者とパワーユーザーが誰であるかを集中的に定義することをお勧めします。システムで定義された管理者およびパワーユーザーのロールドキュメントで許可されるデフォルトの権限を理解した上で、既製の権限セット、またはカスタム仕様のロールドキュメントを使用すべきかを判断します。カスタムロールドキュメントが必要な場合はまず、これらのドキュメントを作成してから、FlexOrgs の階層構造を作成します。

VMware Aria Cost では、最終的な構築プロセスを確定する前にまず、一連のサンプル OU とユーザーグループを使用して、ロールドキュメントをテストすることをお勧めします。

可視性

FlexOrgs では、ユーザーにとって最も重要なレポートとポリシーに集中できるように強固な基盤が提供されます。FlexOrgs は、ユーザー自身が必要だと判断して組織中をさまよい歩く無駄を排除することにより、混乱を軽減し、不要な雑音を回避する上で役に立ちます。

組織にとって主要な目標が可視性にある場合は、AWS アカウント、Azure サブスクリプション、および GCP プロジェクトの割り当て戦略に焦点を絞って、実際に組織の階層構造に適用していくことをお勧めします。まず個々の部門、ビジネス部門、チーム、または OU の定義に使用するあらゆる部門に関連付けて、各アカウントのマップを作成します。階層構造の構築を始めるにあたり、落とし穴を回避するために、アカウントと資産は下方向に流れるという点に注意する必要があります。

組織の真実の根拠を特定する

クラウドサービスプロバイダ (CSP)

Amazon、Azure、Google Cloud Platform はいずれにも組織構造を構築する機能があります。すでに既存の CSP でこの段階を終えている場合は、時間を節約するために VMware Aria Cost 内部でこの構造を複製することを検討してください。

ID プロバイダ (IdP)

SSO サービスを使用してユーザーにアプリケーションへの容易なアクセスを提供している場合は、VMware Aria Cost で同じ構造を再作成してユーザーによるアクセスを簡単にすることをお勧めします。FlexOrgs では、ユーザーを適切なユーザーグループにマッピングするために、SSO 構造で使用する任意のキー値ペアを渡すことができます。この結果、ユーザーがプラットフォームにログインすると、対応する権限を持つ適切な OU にシームレスに配置されます。

ゼロから開始

組織モデルとして CSP や IDP を使用していない場合は、個々の階層にある各 OU と OU 内で有効になっている各アカウントについて詳細に記述したスプレッドシートでマッピングドキュメントを設計する方法をお勧めします。

アカウント、サブスクリプション、プロジェクトの割り当て方法を決定する

アカウント、およびその中に含まれる資産は、FlexOrgs での組織階層の下方に向かって流れていきます。構成した個々のアカウントはすべて、最上位の組織単位 (TLOU) に常駐します。TLOU には、各 FlexOrgs 階層を構築するときのソースとして利用できるアカウントのプールが置かれています。

たとえば、FlexOrgs の階層中で、ある支社の第 4 層に特定の AWS アカウントを配置するとします。この支社の第 4 層にアカウントを常駐させるには、2 層と 4 層にある OU の親にもこのアカウントが存在していなければなりません。これは、必要とされる可視性とセキュリティの目標に影響を及ぼすことがあります。アカウントの割り当てと組織階層のマップは慎重に定義してください。

VMware Aria Cost ですでに従来の組織を構築してある場合は、サポートに問い合わせて、現時点で各アカウントが重複している場所を記述したレポート、および従来の組織から FlexOrgs へのアップグレードに関連するガイダンスについてご確認ください。

ユーザーをグループに分ける方法を決定する

FlexOrgs プロジェクトの構築フェーズを始める前に、ユーザーをグループに分ける方法を決定する必要があります。

ユーザーが、1 つ以上の OU で常駐するためには、特定のユーザーグループに割り当てられていなければなりません。ユーザーグループへのユーザーの割り当ては、プラットフォームで手動で割り当てる方法、SSO キー値ペアを各ユーザーにマッピングする方法、または両方のアプローチを組み合わせる方法のいずれかにより行うことができます。両方の方法を使用してユーザーをグループに割り当てる場合は、SSO の割り当てより、手動でのユーザー割り当てが優先されます。

必要なアクセスレベルを決定する

FlexOrgs では、管理者、パワーユーザー、および標準ユーザーの各権限に応じて、3 つのシステム定義によるロールドキュメントが提供されます。各ロールドキュメントの機能を確認して、追加のカスタムロールドキュメントを作成する必要があるかを判断します。チームによっては、デフォルトのロールドキュメントの権限で十分な場合もあります。

また、特定のユーザーグループに属する具体的な機能や特徴に対するアクセスを除去するために、制約的なロールドキュメントを構築することもできます。制約的なロールドキュメントは、通常のロールドキュメントとは反対の方向で機能します。つまり、権限を切り替えると、その権限が無効になります。