#はじめに
大規模なエンタープライズ企業の場合、クラウドを管理する部署（CCoEと呼ばれる場合もある、本記事ではクラウド管理部署と呼ぶ）とクラウドを利用する部署(本記事ではクラウド利用部署と呼ぶ)が存在する場合が多いと思います。そういった組織体制の場合、クラウド管理部署は、クラウド利用部署にどこまで権限を移譲すべきについて設計する必要があります。当然、権限を移譲した方が、クラウド管理部署の運用負荷が軽くなります。クラウド利用の初期段階で、AWSアカウントやプロジェクト、ユーザの数が少ない場合は、権限移譲しなくても運用出来ると思いますが、ユーザ数が5千や1万といった数になってくると、クラウド利用部内でユーザの管理をして貰う必要がでてくると思います。こういった状況に対する対策として、Identitiy管理はActive direcotryなど別のIDPで実施し、Identitiy情報をSyncしたり、SSO設定をしたりすることも出来ますが、本記事においては、クラウド側でIdentitiyを作成、管理することを前提としています。

本記事では、移譲する操作のうちGCPにおけるIdentity(ユーザとグループ)の作成の権限移譲の方法について、AWSと比較しつつ検討してみたいと思います。

#結論
Googleユーザアカウント作成の権限移譲は完全に実施可能です。
グループ作成の権限移譲についても可能だが、仕様を理解して権限移譲する必要があります。

#前提
##AWSの場合
AWSアカウント毎にIAM user/Groupを作成することになります。
IdentityとEC2などのAWSリソースの管理をすべて1つのAWSコンソールで行います。（GCPの場合は異なる）
AWS SSOを使って、identityを集中管理して、それぞれのAWS accountのIAM roleにassume roleする構成も可能だが、比較の観点が明確にならなくなるため、この記事ではAWS SSOを使わない前提とします。
つまりAWSは、IdentityをそれぞれのAWSアカウントで分散管理するイメージになると思います。

##GCP
Cloud Identityによる集中管理が可能です。
Cloud Identityは、Admin consoleで管理する。GCPリソースは、Google Cloud Consoleで管理します。
Unmanaged userの場合は集中管理できないが、本記事ではCloud Identityによる集中管理を選定とします。
１つのIdentity(Google user account)を複数のプロジェクトに対して認可設定し、それぞれのプロジェクト内のGCPリソースを操作することが出来きます。
つまりGCPは、Identityをそれぞれのプロジェクトで管理せず、Cloud Identityによる集中管理するイメージになります。

両者を比較すると以下の様なイメージになります。Identitiyの管理場所や、コンソールの使い分けなどに差異があります。

#AWSのIdentity管理に対する考察
IAMユーザがAWSアカウント毎に作成されるので、新規にAWSアカウントを作る毎にIdentityの作成が必要になります。
上記の仕様は、Identity作成の権限移譲の観点では、権限移譲が容易であるというメリットがあります。
クラウド管理部は、AWSアカウント作成し、そのAWSアカウントでクラウド利用部用の管理者用のIAMユーザを作成した上で、ログイン情報をクラウド利用部署に伝えれば、後はクラウド利用部署側で必要なIAMユーザの作成ができます。

#GCPのIdentity管理に対する考察
GCPの場合は、Cloud Identityによる集中管理が可能です。新規にプロジェクトを作成した場合も、新しくGoogleユーザアカウントは作成する必要はなく、既存のGoogleユーザアカウントを、新規プロジェクトに対してメンバーとして追加すれば、プロジェクト内のGCPリソースの操作が可能になります。
Identity作成の権限移譲の観点では、Cloud Identity上でどのように制限してIdentityの作成権限を、クラウド利用部に付与すればよいのでしょうか。こちらはこの後に説明しますが、OUを使用する形になります。

#Cloud IdentityでのIdentityの作成権限移譲方法
Cloud Identityには、Googleユーザアカウントやグループの作成権限をRoleという形で設定することができます。

また、Organizational units（OU）というものが存在します。

OUは、ユーザアカウントを作成する際に指定できるもので、複数のユーザアカウントをまとめて管理し、例えばセキュリティ設定などをOU単位で実施することができます。以下の例では、OU 1に所属するユーザアカウントに対して、2段階認証を強制しています。

セキュリティ設定は以下のように、OUを指定して実施することができます。

更にOUは、Roleによる許可設定を実施する際に、許可の範囲を制限する用途として使用可能です。以下の例は、ユーザアカウントへのRoleを設定した例ですが、User Management Adminを1つのOUだけ制限して付与しています。つまり、任意のOU内においてのみユーザアカウントの作成や削除が可能になります。