クラウド管理者がCloud Identityでユーザアカウント作成の権限をクラウド利用者に移譲する方法

はじめに

大規模なエンタープライズ企業の場合、クラウドを管理する部署（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内においてのみユーザアカウントの作成や削除が可能になります。

ユーザーアカウント作成の権限移譲するための具体的な手順

クラウド管理部が実施

Admin consoleでOUを作成します。

クラウド利用部署用の管理者ユーザアカウントを作成します。その際、先程作成したOUを指定します。

作成した管理者用のユーザアカウントに対して、OUのScopeでUser Management Adminのロールを付与します。

作成したユーザーアカウントをクリックし、ASSIGN ROLESをクリックします。

Scope of roleとして、作成したOUを指定し、User Management Adminをアサインします。

作成したユーザアカウントの認証情報をクラウド利用部署の管理者に連携します。

クラウド利用部署の管理者が実施

Admin Consoleにログインします。

OUを指定しないでユーザアカウントを作成をしてみるとエラーになります。

任意のOUを指定してユーザアカウントを作成すると成功します。

もちろん、OU内のユーザアカウントのみ表示されます。

これで、ユーザアカウント作成の権限移譲が完了しました。

グループ作成について

GCPにおける権限付与は、ユーザアカウント単位ではなく、グループに対して実施することがベストプラクティスになります。そのため、グループにおける権限移譲についての検討したいと思います。

GCPにおける、ユーザアカウント、グループ、GCPリソースのマッピングは以下のようなイメージになります。

GCPにおけるグループは、ユーザアカウントと同じく、Cloud Ideneityで管理されます。違いとしては、グループはOUによる管理をすることが出来ません。つまり、Groups Adminを付与すると、操作可能なOU以外のユーザをグループに追加したりすることが可能になります。

実際にグループ作成の権限をクラウド利用部署の管理ユーザに付与して、グループ作成とメンバーの追加をしてみます。

クラウド利用部署の管理者ユーザアカウントに付与します。

任意のOU内に作成したユーザアカウント(test123)をグループに追加します。ADD TO GRPOUPをクリックして、グループに追加します。

試しに、別のOUに存在するユーザアカウント(superadmin)を追加してみます。こちらもメンバーに追加可能です。これは、最初に書いた通り、グループへの操作が、OUを指定したScope設定ができないことに依存します。