セッションタイトル： Learn to love IAM: The most important step in securing your cloud infrastructure
スピーカー: Elliott Abraham, Michele Chubirka

IAM こそ全て

なんと、95% 以上のアカウントで、設定されている権限の 3% 未満しか使っていないとのショッキングなデータから始まりました。
少しでもクラウドやセキュリティを勉強された方は、最小権限という言葉に触れてきたと思います。
ただ、一見、入門書レベルのことに見える最小権限は、真面目に取り組んでいる人ほどその深みにハマると思います。

IAM とは、誰が(Who)、何をできるのか（What）、その対象リソースは（Which）の３つの W で成り立ちます。

IAM は Key Rings であろうが、バケット制御であろうがあらゆるリソースにて使われているものです。

また、Google Cloud における IAM の特徴として、Admin (Google Workspace) と Platform (Google Cloud) へのリソースの定義場所が分かれているのも特徴と思います。
ちょっとここは腑に落ちるまでは、イメージが付きにくいかもですが、何度か触るうちにフッと認識に至ると思います。

リソースのハイエラルキー

Google Cloud のリソースは、階層構成をとります。
組織
↓
フォルダ
↓
プロジェクト
↓
リソース

といった形です。
この階層構成によって、境界を引くことによりセキュリティを担保することができます。
例えば、部門や地域でフォルダを分けることで、全部門や全地域に及ぶ影響を最小化することができます。

ペルソナとは？

ジョブファンクションという言葉で説明されておられました。例えば、PlatformEngineer という仕事内容でグルーピングして、PlatformEngineer として行う業務で必要な権限（Role）を整理します。
そうすることで、個人（IAM User） でなく、グループ（IAM Group）で管理できるようになり、効率がよくなります。

IAM Role の種類

権限を設定するにあたり、権限の種類を理解する必要があります。
基本定義（Basic）のロールと、事前定義のロールにあたります。
基本定義のロールは権限が広すぎることが多いです。
この例でもすごい差が。

セキュリティガードレール

Allow と Deny と Organization、これらの Policy を使ってセキュリティガードレールを構築します。
それぞれの特徴を活用します。

Service Account

ユーザーがコンソールにログインするときではなく、パイプラインなど API で使うものになります。
サービスアカウントも Google Cloud の IAM においては重要なものです。

やってはいけないこと


こういうまとめは助かります。
① 不必要にサービスアカウントを使わない、またサービスアカウントをユーザーのロールにアサインすることを避けよう
② 過剰権限の基本ロールを使わない
③ IAM Recomender を有効活用しよう　（こっちの訳の方が自然かなぁ）
④ サービスアカウントで暗号化鍵を複雑化しない
⑤ サービスアカウントキーを Cloud Function の変数やコード、リポジトリに載せない
⑥ テストなしに組織ポリシーを設定しない

IAM の改善サイクル

リコメンダー　→ アナライザー　→ シミュレート　→ トラブルシュート　→ …
レコメンドされたものを妄信的に設定するのではなく、精査やシミュレートをした上で適用しましょう。
また、システムは生き物。今後の機能追加などによって権限も変わります。
継続的に行いましょう。

まとめ

基本にして究極の IAM、安全なクラウドライフには必須なものなので、今一度振り返れたいい機会でした！

【iret presents】Google Cloud Next’24 Recap 4月19日16時より「【iret presents】Google Cloud Next’24 Recap」を開催します。4月9～11日にラスベガスで開催される Google Cloud が主催する「Next’24」のポイントを解説する Recap イベントです。

詳細はこちら：
https://cloudpack.jp/event/googlecloud-next-2024-recap.html