セキュアにオンボーディングするためのIAM管理 [セッションレポート] #GoogleCloudNext

概要

「Secure onboarding to Google Cloud with Identity and Access Management (IAM)」というタイトルのセッションに参加してきました。 アジェンダは以下の通りです。

要所を絞って印象に残った話を紹介し、なるべくIAMがわからない方向けにも解説できたらなと思います。

また冒頭はIAMの基礎知識のような説明もあったのでまとめました。
試験や実務の取り入れなどの参考にできるよう、セッションの内容になぞらえて解説してみようかと思います。

セッション内容

境界

IAMの話になると定番の境界の話から始まりました。
昔はFW（ファイアウォール）の内側としてリソースが存在していたが、クラウドが主流の現在はクラウドの内側が外部とを隔てる境界線です。

今回はこの３要素に絞って話を展開していきました。（組織ポリシー、IAM、Cloud Identity）
組織ポリシーとIAMの制御はまた別の権限管理になりますが、併用することでよりセキュアな環境を構築することが可能です。

また、Cloud Identityがなければ組織ポリシーを使用することができません。
この3つの要素は互いに持ちつ持たれつの関係で成り立っています。

その他のセキュリティ要素として、VPCサービスコントロールなどもありますが、この機能もやはりIAMがあることでさらに追加で権限の制御を行うといったものです。

IAMの理解を深めることはクラウド利用には必須なのかと思います。

IAM

セッションでは、画像にあるような全てのリソースがIAMに依存していると言います。
その理由として、GCSやKMSにアクセスする際にはIAMで適用されたロール（権限）が必ず必要になってきて、それなしで運用することはもちろんありません。

クラウドの中が境界線になった今、IAMこそがセキュリティの根本的な要素になるわけです。

Google CloudのIAM

一旦、Google Cloudでの権限管理の仕組みを整理しておきましょう。
Google CloudのIAMは主に対象となるエンティティ＋ロール=ポリシーという順序で出来上がります。

これをリソースコンテナと呼ばれる組織、フォルダ、プロジェクトに割り当てていきます。

詳しい説明は過去のブログでも解説しているので、拝見ください。
【Google Cloud：IAMのイメージについてざっくりまとめてみた】

組織階層

図ではGoogle Cloudにおける組織の構成を表しています。
IAMポリシーも組織ポリシーも下位への継承が行われます。

DeptXに編集者ロールを割り当てた場合、その配下のフォルダ（TeamA,B）とプロジェクト（prod,no-prod）に権限が引き継がれます。

よって、フォルダを部署ごとなどの一定のグループ単位に分けることで、チームによる権限分離を可能にしています。

もちろん、そのルートにあるのが組織（MyOrd.com）なのでここに権限を与えてしまうと、組織全てのプロジェクトにそのIAMポリシー（＝ユーザー＋権限）が与えられてしまいます。

組織の階層の設計も企業で運用していく上ではかなり重要な要素になるかと思います。
詳しい説明は過去のブログでも解説しているので、拝見ください。
【「Cloud IdentityとAzure ADの基礎を比較」というタイトルで登壇しました】

ペルソナマッピング

ここで興味深い話が出てきました。
登壇者は、ペルソナマッピングを作成することが重要だと言います。

私はこのペルソナマッピングについて、ユーザーやサービスアカウントの役割を、Google CloudのIAMポリシーの役割にマッピングし管理することと理解しました。

ペルソナマッピングを行うことで、組織内のユーザーやサービスアカウントが、Google Cloudの各リソースに対して必要な権限のみを付与することができます。

実装するには、まず組織内のユーザーやサービスアカウントの役割を明確にする必要があり、しっかりと個人やチームの役割を理解しておく必要があります。

権限の種類

これはGoogle Cloudだけに言えることではないですが、ユーザーやグループ、サービスアカウントには必要最低限のロールだけを割り当てることが、セキュアな環境を構築する上で重要となります。（最小権限の原則）

Google Cloudでは３つのロール形式があり、基本ロール、事前定義ロール、カスタムロールになります。

基本ロールは使わない、事前定義ロールで済ませることができれば使用する、事前定義ロールよりさらに権限の分離を行いたい場合にはカスタムロールを使用する、このような考え方がいいかと思います。

少し気をつけなければいけないのが、カスタムロールについては、権限がサポート対象か否かなど要素が追加されるため、それを考慮して作成する必要があります。

また、カスタムロールを作り過ぎても管理が追いつかなくなる可能性も出てきて、逆にセキュリティホールになりかねないので、企業の運用方針に従うのがベストかもしれません。

組織ポリシー

組織ポリシーとIAMポリシーは別物です。
組織はGoogle Cloudを使用する上ではなくてなならないセキュリティ機能の部類ですが、必ずしも必須ではありません。

ですが、IAMポリシーは必須になります。
この辺りは、過去のブログを参考にしていただければと思いますので、組織ポリシーについて触れましょう。

Google Cloudの組織ポリシーは許可ルールと拒否ルールに分かれています。
優先順位は拒否ルールの方が高くなり、両方が適用されている場合拒否ルールが優先されます。

ユーザーAに対して、フォルダA内になるプロジェクトのCompute Engineへのアクセスを許可するという許可ルール、すべてのCompute Engine へのアクセスを拒否するという拒否ルールを適用した場合、ユーザーAはCompute Engineにアクセスすることは出来ません。

ただ、フォルダAの直下にもなく、関係のないフォルダBへのアクセス権限も別途用意している場合には、そのポリシーが適用されます。

このロール、ポリシー、権限、ユーザーの立ち位置的な認識が結構わかりにくいところですが、運用には必須の知識と言えます。

まとめ

今回は組織内のセキュリティをセッションの内容をもとに、IAMを含めて解説しました。
自分的にもこの組織作成周りはとても興味がある分野になるので、オンボオーディングの勉強会なども開催したいなー、、、と書いていて思いました。

最後にIAMのベストプラクティスが紹介されていたので、ご紹介します。