7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

こんにちは!花王株式会社でクラウドエンジニアをやっている @ma333 です。

  1. 弊社のようなJTCがクラウドサービスのコントロールを効かせ内製を進められること
  2. 一緒に携わる開発者-キャリア採用・開発パートナーの方も含めて、気持ち良い環境で開発を進められること

を目指し、本シリーズではその一要素として、「Microsoft Entra IDとGoogle Cloud, AWS, GitHubのユーザー連携やってみる」を紹介します。

今回は、各クラウドのリソース・ユーザー管理の違いと、Microsoft Entra IDを利用したユーザー管理方法についてお話します。

※会社公式ではなく、2025年7月1日時点でのma333の見解となります。

リソース管理体系の比較

3大クラウドのリソース管理体系を以下の表にまとめました。

AWSについては単一アカウントを想定しています。AWS Organizationsについては注意書きに記します。

管理範囲 Azure Google Cloud AWS
組織全体
※company.comなどドメインと紐づき
テナント Organization
リソース階層管理① 管理グループ フォルダ
リソース階層管理②
※請求管理
サブスクリプション プロジェクト アカウント
※呼び方注意。ユーザーアカウントの意味合いではない
リソース階層管理③ リソースグループ リソースグループ
リソース リソース リソース リソース
  • AzureやGoogle Cloudでは組織全体をドメインと紐づけて管理します
    • Google CloudについてOrganizationを利用しない使用方法もありますが、その場合は使用できないリソースもあります
  • リソース階層管理②の部分が請求を行う単位となります。
    • Azureの場合EA契約、CSP契約・・・などをサブスクリプションとして結び、利用することができます
    • Google Cloudの場合は請求アカウントというものをプロジェクトに紐づけます。リセール(請求代行)を利用する場合、権限付与された請求アカウントを選択・切り替えすることができます。
    • AWSではアカウントが請求に紐づきます。
  • 中間のとりまとめ用の階層が異なります
    • Google Cloudではプロジェクトをフォルダで階層化することができます。Azureも管理グループにて、サブスクリプションを階層化して管理することができます。
    • Azure, AWSはリソースグループでリソースという具体的なサービスをまとめることができます。
  • AWSのOrganizationでは複数アカウントの取りまとめ、請求取りまとめ、メンバーアカウントの一元管理などが可能です。

ユーザー管理体系の比較

各クラウドはIAM, RBACといったやり方で、どのユーザーがどのクラウドサービスへアクセスできるかを制御することができます。

一方、その大本のユーザーをどこで作成・管理するかという点が異なります。

  • AWSはアカウントにてユーザーを作成し、管理

  • Azure, Google Cloudでは組織に紐づくユーザー管理用のサービスで設定

    • 管理範囲 Azure Google Cloud
      ユーザー管理 Microsoft Entra ID Google 管理コンソール
      ライセンス Microsoft Entra ID Cloud Identity / Google Workspace
      外部ユーザーのクラウド利用設定 Microsoft Entra IDで登録し、Azureで設定 Googleアカウントであれば、Google Cloudのプロジェクトに設定可能

なお、ここまでのGoogle Cloudに関する基礎知識についてはクラスメソッドさんの情シス部門が主導する Google Cloud 導入:知っておくべき管理の基本がとても分かりやすかったです。

効率的なユーザー管理のポイント

クラウドごとに異なるユーザー管理体制を作る場合、運用負荷が高くなったり、環境ごとの抜け穴ができてしまうことがあります。

メインとなるID基盤(ここではMicrosoft Entra ID)側で、開発者を一括管理することで、それを避けることができます。

以下はイメージ図です。

メリットの1つは、退職・異動等に対応した棚卸機能が既存のID基盤で実装済みであれば、それを活用できることです。

また、一定の期間だけアクセスが必要な開発パートナーなども、外部ユーザーとしてID基盤側で管理することが可能となります。

外部ユーザーに対しては、アクセス範囲・利用規約を設定して

  1. PC貸与
  2. VDI/DaaS等からアクセス
  3. 外部ユーザーとしてアクセス

といった方式があるかと思いますが、ここでは3つ目の、セキュリティを担保してある使い慣れたPCで、開発に即参加してもらうことを想定しています。

特権管理については、各クラウドのPIM(Privileged Identity Management)を利用するもよし、ID基盤側のPIM・運用ルールに従う設計も可能です。

また、GitHub上でIaCやCDを実装することで、ユーザーに応じてクラウドへの権限を最小限に調整することができます。

まとめ

  • クラウドのリソース管理体系とユーザー管理体系を比較しました
  • Microsoft Entra IDを活用したユーザー管理方法を書いてみました

次回は、具体的な設定方法(Microsoft Entra ID → Google Cloud)を書く予定です!

7
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?