概要
企業では特に3大クラウドを活用する機会が増えているかと思います。
弊社でもAWSやGoogle Cloudを使用した支援を行っています。
私自身、AWS、Google Cloud、Azureとこれら全ての権限周りを勉強したことがありますが、仕組みが異なるため、1つを勉強したら1つを忘れるようになっておりました。
AzureはEntra ID（旧Azure AD）が必ず必要なため、少し毛色は変わってきますが、AWSとGoogle Cloudは言葉や仕組みが似ているため、逆にわかりにくい部分があります。
そのため、今回は、AWSとGoogle CloudのIAM周りの基礎的な知識を解説していきます。
それぞれのクラウドを触る前や資格試験受験の際の理解に使用していただけると幸いです。
※ 序盤にGoogle Cloud、後半にAWSの話をします。AWSの章では途中Google Cloudと比較しながら理解していきます。
Google Cloud
IAMユーザー
Google CloudでのIAMユーザーは、他のGoogleサービス（YoutubeやGmail）でも使用できる@gmail.comのような無料ユーザーや@sample.classmethod.xyzなどのような独自ドメインを使用したGoogle アカウントになります。
よって、Google Cloudを利用する前に、Googleアカウントを作成していなければなりません。
無料の@gmail.comユーザでもGoogle Cloudを使用する事は可能ですが、後に紹介する組織というセキュリティー機能を豊富に揃えたサービスが利用できないため、どの場合でもCloud IdentityというIDPに登録することを推奨します。
Cloud Identityに登録すると組織を使用できるようになり、フォルダやプロジェクトなどをまとめて管理し、さらにセキュリティー機能を有効化することができます。（【組織】の章で後述）
リソースの作成
BigQueryやCloud Storageなどのリソースを作成するためには、Google Cloud プロジェクトが必要となります。
いわゆる一種の課金単位とも呼べ、プロジェクトごとに請求先アカウントが紐付く形となります。（【請求】の章で後述）
基本的にはプロジェクトを作成したユーザがオーナーとなり、必要であれば、その他ユーザにロールを付与して、そのプロジェクトに有効な権限を付与します。
この辺の考え方は、AWSとあまり変わりはありませんが、一つ一つの単語（例えばロールやポリシー） の概念は異なるため、わかりにくいかもしれません。
請求
Googleクラウドを使用する上では、請求先アカウントという1つの請求先が登録されたアカウントが必要となります。
通常Googleクラウドを初めて利用する場合には、プロジェクトを作成する際に、同時にクレジットカードを登録してこの請求先アカウントを作成することになります。
請求先アカウントを使用せずにプロジェクトを作成することも可能ですが、その場合リソースを作成することができません。
また、予算アラートを設定することにより、課金をメールやアプリに通知することが可能です。
Googleクラウドを使用する際には、今まで説明してきた以下3つのリソースが最低限必要となります。
- Googleクラウドアカウント
- Googleクラウドプロジェクト
- 請求先アカウント
組織
Google Cloud を企業で運用する上で、組織の活用はセキュリティと管理の効率化を図る上で非常に重要となります。
IAMユーザーの権限設定と密接に関係しており、組織を有効化することで共有VPCや組織ポリシーなど、より高度なセキュリティ機能を利用できるようになります。
イメージとしては、Google Cloud内に現実の企業組織構造を反映させることができるのが組織であり、例えば組織の下にフォルダを作成することで、プロジェクトを部署単位でグルーピングすることができます。
※ 独自ドメインを所持していないと組織は作成できません。
フォルダはプロジェクトの上位概念として機能し、プロジェクトを部署ごとにまとめ、アクセス管理や予算管理を効率化できます。
よって、組織を導入するメリットとしては、アプリケーションや請求を部署単位で明確に分別できるようになり、セキュリティを担保しながら、煩雑な管理から解放されます。
AWS
IAMユーザー
AWSにおけるIAMユーザーは、AWSのサービスにアクセスするためのユーザーアカウントです。Googleアカウントのように他のサービスとアカウントを共有するのではなく、AWS専用のものとなります。
AWSを利用するには、まずルートユーザーでアカウントを作成します。ルートユーザーはAWSアカウントの全ての権限を持つため、セキュリティ上、普段使いのアカウントとしては推奨されません。
代わりに、IAMユーザーを作成し、必要な権限のみを付与するのがベストプラクティスとなります。
リソースの作成
AWSでEC2インスタンスやS3バケットなどのリソースを作成するには、AWSアカウントが必要です。アカウントは課金の単位となり、アカウントごとに請求情報が紐付けられます。（【請求】の章で後述）
※また、AWS Organizationsを利用する場合には請求もまとめることができます。
アカウント作成後、ルートユーザー以外のユーザーでリソースを作成する場合は、IAMポリシーを使用して権限を適切に設定する必要があります。
Google Cloudのポリシーはユーザー（プリンシパル）やサービスアカウント（SA）とロール（権限）の組み合わせですが、AWSではユーザー、グループ、ロールに対してポリシーを割り当てることで、リソースへのアクセス権限を制御します。
こちらはGoogle Cloudも同様となりますが、最小権限の原則に基づき、ユーザーやアプリケーションには必要な権限のみを付与することが推奨されています。
つまり、AWSでいうロールはあくまでもエンティティ（権限自体ではない）であり、Google Cloudのロールは権限自体という違いがあります。
AWSでいうアシュームロールのような機能はGoogle Cloudには存在しませんが、サービスアカウントを使用すれば類似する機能を実現することができます。
請求
AWSを利用するには、有効な請求先情報をアカウントに登録する必要があります。
Google Cloud同様にアカウント作成時にクレジットカードを入力し登録を行います。
請求情報はAWSマネジメントコンソールで確認でき、請求アラートを設定することで、予期せぬ高額請求を回避することも可能です。（Google Cloudでは予算アラート）
よって、AWSを利用するには、今まで説明してきた以下3つが最低限必要となります。
- AWSアカウント（ルートユーザー）
- IAMユーザー
- 請求先情報
この辺りの関係性はGoogle Cloudと大して変わらない気がするので、細かな説明は省略します。
Organizations
AWS Organizationsは、複数のAWSアカウントを統合管理するためのサービスです。Google Cloudの組織と同様に、企業におけるAWS環境のセキュリティとガバナンスを強化する上で重要な役割を果たしております。
Organizationsを利用すると、組織ルートと呼ばれるルートアカウントを作成し、その下に複数のAWSアカウントを階層的に配置できます。（Google Cloudでいう組織→フォルダ→プロジェクト）
これにより、アカウント全体のアクセス管理や請求の一元化、組織全体のポリシー適用などが可能となり、管理の効率化とセキュリティリスクの低減を実現します。
組織は、アカウントを組織単位（OU）と呼ばれるグループにまとめることで、よりきめ細かい管理を行うことができます。OU単位でポリシーを適用したり、請求レポートを集約したりすることが可能です。
現状、Google Cloudではフォルダ単位（AWSでいうOU）に請求先アカウントを紐づけられないため、プロジェクトごとで管理する必要があります。
よって、Organizationsを導入するメリットとしては、アカウント管理の負担を軽減しながら、セキュリティとコンプライアンスを向上させることができます。
筋肉的なまとめ
誤解を恐れずに言うと、Google Cloud 組織やAWS Organizationsは、筋トレ目線で話す場合、人間でいうところの脳みそであり、身体（四肢や体幹）が部署単位で分かれたフォルダやOU、そして一つ一つの筋繊維がプロジェクトや子アカウントになると私は思います。
やはりどんな体を作りたいのかという組織ポリシーや、SCPような筋トレ（ボディメイク）ポリシーをあらかじめ定義し、そのポリシーに乗っ取ってトレーニングを行う事はとても重要です。
どの世界、業界、筋トレでもこのポリシーというものは、いわゆるその行為の妥当性を保障してくれるものだと思います。
筋トレでいうセキュリティーは様々言い換えることができますが、例えばベンチプレスやスクワットで追い込む場合、しっかりとセーフティーバーを使うことや、重い重量を上げるときには関節を保護する補助ストラップを使うなどが挙げられます。
伝えられる事は全て伝えたので、今回はこの辺で締めたいと思います。 筋トレ、クラウドの悩みはクラスメソッドへご相談ください。（あくまでも筋トレは私宛にしてください）
2
