出展本からちょい出し：IAMから読み解くAWSとGoogle Cloudの思想の違い

今回は自社の有志と技術書典16に向けて執筆した「AWS vs Google Cloud アプリ開発七番勝負」を紹介させてください。本書はAWSもGoogle Cloudも大好きなメンバーが両者へのリスペクトを込めて執筆しました。

本書の中でIAM（権限管理）についても両者を比較しており、本記事ではIAMの部分から一部を要約してご紹介したいと思います。本記事によって、この本のイメージをつかんでいただければ幸いです。

表紙の「どっちがいい？どっちも好き！」のメッセージの通り、「どっちがいい」という絶対的な答えは存在しません。どのようなチームでどのようなアプリケーションを作ろうとしているのか、どのようなフェーズのビジネスか、等によって、どちらが良いかは変わります。皆様のチームや担当アプリにとってどちらが適しているか考えてもらうきっかけを作ることを目指した本になります。本記事からその雰囲気を感じてみてください。

まとめ

私がIAMから垣間見た、AWSとGoogle Cloudの方向性や思想の違いをまとめます。

AWS：エンタープライズ顧客の厳しい統制・セキュリティ要件にも対応・説明しやすい
- AWSアカウントによる権限境界が厳格なため
Google Cloud：デプロイの独立性を高め開発スピードを維持しやすい
- 多数のGoogle Cloudプロジェクトがあっても一括で許可権限を制御できるため

どちらも「できない」「していない」という話ではなく、方向性や思想の話です。

この理由・詳細を深堀りしていきましょう。

両クラウドの権限の与え方の違い

両クラウドの権限の与え方の違いをざっくり言うと次の通りです。

AWS：権限制御がAWSアカウントごとに厳格に独立している
Google Cloud：複数のGoogle Cloudプロジェクトの権限をポリシーの継承により一括制御できる

そもそも、両クラウドで権限の与え方がまったく異なるので混乱しないようにまずは概要を押さえておきましょう。

AWSはアイデンティティにポリシーをアタッチして権限を与えるアイデンティティベースの権限制御が基本です。一方、Google Cloudではリソースにポリシーをアタッチして権限を与えます。「ポリシー」という用語も同じ用語ながら、両クラウドでまったく考え方が異なります。詳細は本の中で説明しています。

ここでは、Google Cloud特有の考え方として「ポリシーの継承」を取り上げます。

Google Cloudでは、組織をルートとしたフォルダによる階層構造でGoogle Cloudプロジェクトを管理します。この組織やフォルダ、プロジェクトもリソースとしてポリシーを適用できます。適用したポリシーは組織階層にしたがって上位層から下位層に継承され、適用箇所以下の全リソースで効力を発揮します。つまり、1つの権限変更で複数のGoogle Cloudプロジェクトにおける許可権限を操作できるということです。これが「ポリシーの継承」です。

例えば、あるユーザに対してStorageバケット内のオブジェクト取得を許可するポリシーをあるフォルダに適用した場合を考えます。この場合、当該ユーザはポリシー適用箇所のフォルダ配下にあるすべてのGoogle Cloudプロジェクト内のすべてのStorageバケットのオブジェクトを取得できるようになります。

一方、AWSでは権限管理はAWSアカウントにより厳密に独立しています。あるAWSアカウントによる権限操作で他のAWSアカウントに最終的な操作の許可を与えることはできません。

「リソースポリシーで他のAWSアカウントのプリンシパルを許可したことがあるよ」と思う方もいらっしゃるかもしれません。これはあくまで最終的な許可の必要条件として許可を与えているだけで十分条件ではありません。最終的に操作を許可するかどうかは対向のAWSアカウントで許可を与えるかどうかに委ねられています。すなわち「対向のAWSアカウントで許可されているなら許可してもいいよ」と自アカウントに影響を与えているに過ぎません。この必要条件としての許可も、対象のリソースごと・対向のAWSアカウントごとに許可を与えていく必要があります。

両者の違いを図でまとめます。

権限の与え方の違いから見る両クラウドの方向性の違い

統制・セキュリティ要件の厳しい規制業界においては、AWSアカウントが厳格な権限境界として働くことは有力です。機密データを扱うといった厳格な統制・セキュリティが求められるコンポーネントをAWSアカウントで分離することで、重い統制・セキュリティ対応が求められる範囲を限定します。これにより、統制・セキュリティの要である権限制御も厳格に分離されるため、重い権限制御の負荷を必要最低限の範囲に押さえられます。「AWSアカウントで厳格に権限制御は分離されています」と説明できることも規制業界における監査対応では大きな利点です。ただし、AWSアカウントごとに権限制御が独立しているため、AWSアカウント数の増加に比例して権限管理のボリュームや複雑性が増加してしまうという懸念があります。

一方のGoogle Cloudでは、複数のGoogle Cloudプロジェクトの権限をポリシーの継承で一括制御できるため、Google Cloudプロジェクト数が増加しても権限管理のボリュームや複雑性は増加しにくいという利点があります。これにより、チームや機能に合わせてGoogle Cloudプロジェクトを分割しデプロイの独立性を高めデプロイの心理的安全性を保つことで、開発スピードを高めやすくなっています。ただし、あるひとつの権限操作で複数のGoogle Cloudプロジェクトにおける許可権限を操作できるということは、想定外に必要以上の許可権限を与えてしまう可能性があります。これは厳密な統制・セキュリティ要件が求められる場合には、組織全体の権限制御に対する統制・セキュリティ対応が重い要件に律速されることが懸念されます。 AWSのようにGoogle Cloudプロジェクトを厳格な権限制御の境界として監査で説明しきることは難しい面があります。

これが冒頭のまとめで述べた両クラウドの方向性や思想の違いです。