セッションタイトル： 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、安全なクラウドライフには必須なものなので、今一度振り返れたいい機会でした！
