AWS/GCP/Azure における他社アカウント権限委任のベストプラクティス

権田原 ”パー子” 夢子

2023年05月30日

はじめに

平素は大変お世話になっております。
クイックガードのパー子です。

弊社は MSP (Managed Service Provider) であるため、お客様のシステムの運用全般をまるっと委任していただく案件が頻繁に発生します。

このようなケースではスタッフを 1人ずつ委任元のアカウントに招待してもらう方法が一般的ですが、弊社のように多数のお客様と関わる組織ではメンバー管理の手間が問題になってきます。

単純に、人数分の招待を繰り返さないといけないこと。
入退社や異動により、関与するすべての顧客において追加の招待やアカウント削除が必要になること。
顧客ごとの専用アカウントをいくつも管理しないといけないこと。

この問題に対処するため、3大クラウド・プロバイダの AWS、GCP、Azure はいずれも包括的な組織間委任の仕組みを提供しています。

今回の記事では、その仕組みを活用した委任管理の堅牢化・効率化のベストプラクティスをご紹介します。

クラウド・プロバイダにおける委任機能

委任元 (= 顧客) としては「スタッフ個々人ではなく、ベンダーに対して総体的に委任できる」こと、委任先 (= ベンダー) は「個々のスタッフに対する顧客環境へのアクセス権の与奪を自社内で行える」ことが重要です。

これを実現する手段として以下の仕組みを活用できます。

AWS

AWSアカウントをまたいで IAMロールを付与することができます。

この仕組みを用いることで、ベンダー側は単一の自社AWSアカウントで複数の顧客環境へ、それぞれ異なる権限でアクセスできるようになります。

顧客はベンダーに委任したい権限を持った IAMロールを作成し、ロールの引き受けを許可する対象としてベンダーの AWSアカウントID を指定するだけで OK です。

ベンダーは、当該ロールを引き受けることができるスタッフを選別し、対象のスタッフにロールの引き受け許可を与えます。
これはベンダーの AWSアカウント内で完結して行えるため、担当するスタッフを変更したくなったとしても何らかの作業を顧客に依頼する必要はありません。

GCP

GCP の場合、特別な仕組みは用意されていません。

元々 GCP では、自組織のアカウントに限らず任意の Googleアカウントにアクセス権を与えることができます。
そして、権限付与の対象はユーザ個人に留まらず、グループを指定することもできるのです。

よって、ベンダー側で適当にグループを作り、顧客にそのグループを招待してもらえば委任完了です。

お手軽ですね。

Azure

Azure Lighthouse という機能を使えます。

このドキュメントからは具体的に何ができるのか読み取りづらいのですが、ベンダーのスタッフをゲストアカウントとして顧客側に招待することなく、ベンダーのテナントに対してサブスクリプションまたはリソースグループへのアクセス権を与えることができます。

アクセス権を与える対象としてグループを選択できますが、グループの種類は “セキュリティ” とする必要があります。

また、委任できる権限は単一の組み込みロールに限定されます。
(カスタムロールはサポートされていません。)

込み入ったアクセス制限は難しいので、サブスクリプションやリソースグループをうまく区切ってベンダーに委任する範囲を限定する工夫が必要です。

ベンダー側でのメンバー管理のポイント

以上の委任機能の使うことで、メンバーが増減した場合でもベンダーの組織内で完結して管理できるようになります。

さらにメンバー管理を効率的に行うための工夫を見ていきましょう。

アカウントの一元管理

ある程度の規模の組織であれば、社内のアカウント管理を Active Directoryなどのディレクトリ・サービスで一元化していると思います。

クラウド・プロバイダごとにいちいちアカウントを登録して回るのは面倒なので、社内ディレクトリと ID連携しておきたいところです。

以降、ディレクトリとして Azure AD を利用している前提で話を進めます。

AWS

AWS では IAM Identity Center (旧名: Single Sign-On) にて SAML による SSO を設定できます。

アカウントは SCIM により自動でプロビジョニング (Azure AD側でアカウントが追加、更新、削除されると自動的に AWS側と同期) されます。

SSO の設定手順はこちら、自動プロビジョニングはこちらです。

ID連携すると、以降はこのようなポータルからサインインするようになります。

GCP

Google Workspace または Cloud Identity との間で SAML を用いて SSO を張ることができます。

設定手順はこちらです。

アカウントのプロビジョニングは、専用のユーザを Google側に作ったうえで、このユーザの権限を借り受けて同期されます。

また、特権管理者は SSO の対象から除外されるので、専用の特権ユーザを Google側に作成しておいたほうがよいでしょう。

Azure

Azure自体のアカウント管理に Azure AD が使われているので、明示的な ID連携は不要です。

グループ管理

AWS では IAM を柔軟に設定できるので、必ずしもグループ単位で委任を受ける必要はありません。
一方、GCP と Azure においては顧客環境に関与するスタッフを単一のグループに所属させないといけません。
そのため、Azure AD のレベルで一元的にグループ管理して、AWS の場合であってもグループ単位で権限を管理することをオススメします。

委任を受けるグループとして組織管理上の実在の部署を指定してしまうと、組織変更や担当チームの変更などのイベントに柔軟に対応できないため、組織の構造とは関係のない顧客ごとのプロジェクト・チームを編成するとよいでしょう。

関与する顧客が多くなるにつれて、入退社や異動などの人事イベントに追随して各プロジェクト・チームの所属スタッフを更新する手間が無視できなくなってきます。

スタッフの属性を見て自動でグループの所属スタッフを調整する “動的グループ” のような機能を活用しましょう。
(Azure AD であれば Azure AD premium P1 以上のライセンスがグループの人数分だけ必要です。)

あるいは、単純な属性だけで判断できない場合は、所属スタッフを同期する仕組みを自前で構築する必要があるかもしれません。

ウォークスルー

以上をまとめると、このような全体像になります。

各クラウド・プロバイダにおける委任設定について、実際に画面を操作しながらポイントを見ていきましょう。

AWS

顧客の AWSアカウントID を 335*********、ベンダーの ID を 682********* とします。

まず、顧客側のアカウント上に、ベンダーに委任する IAMロールを用意します。

その際、Trusted entities としてベンダーのアカウントIDを指定します。

こうすることで、このロールを引き受けることができるのは指定のベンダーだけになります。

次に、ベンダー側のアカウントで、顧客環境へアクセスできるスタッフを制限します。

IAM Identity Center の Permission sets にて、当該顧客を担当するチームの権限に sts:AssumeRole を追加します。
Resource には対象の IAMロールの ARN を指定します。

これでロールをスイッチできるようになります。

AWS CLI を使う場合は、事前に aws configure sso コマンドを実行して IAM Identity Center を通して認証されるように Profile を作成しておきます。
(Profile名はなんでもよいですが、ここでは quickguard とします。)

さらに、この Profile を基にした顧客環境用の Profile を追加します。

[profile customer-A]
role_arn = arn:aws:iam::335*********:role/VendorManagerRole
source_profile = quickguard

顧客環境に対してコマンドを実行したい場合は、まず SSO でログインしてトークンを取得したあとに、通常どおり顧客Profile を指定すれば OK です。

$ aws --profile quickguard sso login
$ aws --profile customer-A iam list-users

なお、現在、SSO による認証方式には新旧2種類あり、一部のツール (代表的なものでは AWS SDK for Go v1 を使っている Terraform や Copilot CLI) は新方式をサポートしていません。
そのようなツールでは、旧方式の Profile を source_profile に指定する必要があります。

GCP

顧客側のプロジェクトに、ベンダー側の担当チームのメールアドレスを登録するだけで OK です。

これだけでベンダー側から顧客プロジェクトへアクセスできるようになります。

Azure

ベンダー側で ARM (= Azure Resource Manager) テンプレートを作成し、顧客側でそのテンプレートをデプロイする、という流れです。

まず、ベンダー側のテナントで Azure Lighthouse のポータルにアクセスし、“Manage your customers” » “Create ARM Template” と進みます。

委任を引き受けたいグループや要求する権限などを指定して、“View template” を押下します。
なお、“Name” に設定した名前で顧客側に登録されるので、顧客から見てわかりやすい名前 (ベンダー名など) を入力するとよいでしょう。

ARMテンプレートが生成されるので、ダウンロードします。

ダウンロードした JSONファイルを顧客に送付したら、次は顧客側での操作です。

同じく Azure Lighthouse のポータルから “View service provider offers” を開き、続いてサイドメニューの “Service provider offers” に遷移します。
ここで Offer を追加し、ベンダーから受け取った JSONファイルをアップロードします。