Google Cloud Platform

AWS ユーザー向けの Google Cloud IAM ガイドを公開

IT 戦略の一環として複数ベンダーのクラウド サービスを併用したいと考える企業は少なくありません。そうすることで、さまざまなクラウド ベンダーが提供する独自のサービスを活用できるほか、災害や復旧の際にアプリケーションの可用性を保てるからです。

ただし、複数ベンダーのクラウドを運用していくには、プロバイダーによって異なる IAM(ID およびアクセス管理)のポリシーを扱うなど、より洗練された計画や管理が必要となります。さまざまなプラットフォームでリソースやデータを保護する際にカギとなるのは、正しい IAM ポリシーを設定することなのです。

私たち Google は先ごろ、Amazon Web Services(AWS)に備わる IAM の利用経験があるユーザーを対象に、Google Cloud Platform(GCP)の IAM ポリシーについて記したガイドを公開しました。AWS と GCP ではリソースやポリシーの枠組みが異なるため、両者の考え方の違いを計画段階で理解することは重要です。1 つのサービスの機能を、もう 1 つのサービスの機能に直接置き換えられない可能性があるためです。

Google Cloud の IAM における重要な概念の 1 つは、ポリシーの継承です。GCP のリソースは、プロジェクトやフォルダ、組織ごとに階層化して編成することが可能で、ポリシーもこの階層にわたって引き継がれます。

たとえば、組織内で「ログ閲覧者」の役割が与えられた人であれば、その組織内で作成されたプロジェクトやリソースのログを自動的に閲覧できるようになります。GCP の IAM を利用するときは、組織やチームの構成に合った階層の計画を立てるようにして、この機能を活用してみてください。そうすることでポリシー管理が簡素化されます。

AWS のポリシーは、以前はそれぞれのリソースの粒度に合わせて管理する手法をとっていましたが、最近になって AWS Organization が追加され、AWS のリソースに対しても GCP 同様に階層化モデルを適用できるようになりました。そうなると、相違点として残るのは GCP Project です。GCP Project とは、チームやアプリケーション、開発環境ごとに信頼の境界線を引く、いわばリソースのカプセル化のことです。

GCP には AWS ともう 1 つ異なる点があります。IAM の役割を活用し、個人の職務権限上意味のある面に合わせてグループごとに許可を与える手法です。

こうした IAM の役割により、GCP ではすべての権限を毎回リスト化することなく、異なるリソースに対しても同様のアクセス権限を与えることが可能となり、ポリシーが読みやすく、またわかりやすくなります。GCP の場合、事前に定義した役割を多数用意しているのに加え、近々カスタムで役割を設定することも可能になります。

先ごろ公開したガイドでは、こうした手法について詳細に解説しており、ID 管理や自動化など他の分野における GCP と AWS の IAM 機能についても比較しています。このガイドが、複数ベンダーのクラウド環境でポリシーや許可の管理を行う際の一助となれば幸いです。

* この投稿は米国時間 4 月 3 日、Product Manager である Rae Wang によって投稿されたもの(投稿はこちら)の抄訳です。

- By Rae Wang, Product Manager