大手クラウドのIAM比較
Alibaba Cloud、AWS、Azure、Google Cloudを比べてみた

クラウドのIAM比較

各クラウドのIAMのサービスの比較をしていきます。まずは、アクセスを許可される対象が誰または何であるのかを見てみましょう。

アイデンティティとはアクセス方針が適用されるサブジェクトです。その内訳として、どのクラウドにも（クラウドによって多少呼び名が違いますが）ユーザがいることが分かります。ユーザとは例えばブラウザから管理コンソールへログインしてインタラクティブな操作を行う利用者のことです。Eメールアドレスとの連携を想像するかもしれません。実際にその通りで、クラウドで登録しログインに利用します。ただし、Alibaba Cloud、AWSでは、Eメールアドレスとは別にIAM内で管理するIAMユーザを利用してログインすることが一般的です。

Azure、Google Cloudではユーザ以外にサービスと名称がつくアイデンティティが存在します。アプリケーションで利用する非インタラクティブなIDととらえてください。Alibaba Cloud、AWSではユーザによるアプリケーションの操作が許可されています。これはIAMユーザに紐づくアクセスキーを発行できるためです。IAMユーザを人と考えると複雑に感じます。アプリケーションが利用してもよいわけです。インタラクティブなコンソールログインを無効にもできるため、ログインにも使える他クラウドのサービスIDととらえると理解しやすいでしょう。またサービスに類似している機能としてロールをイメージするかもしれません。ロールはサービスと同義ではありません。ロールという権限集合をリソースへ委譲する形式となっているためです（ロールについては後述します）。

続いてアクセス方針の適用対象を見ていきます。

許認可の適用対象はリソースであり、各クラウドでも同じ名称が使われています。リソースの具体例としては、分かりやすいところでは、コンピュートノードやデータベースあたりでしょうが、それ以外にも、例えば請求情報やサポートのチケット等もクラウドが提供するリソースに含まれることがあります。詳細なリソースの内訳は各クラウドのドキュメントを参照ください。

最後に許認可の方針を比較してみましょう。適用対象へ割り当てる方針がポリシーであり、またその集合がロールとなります。

アクセス方針の論理的な適用範囲に違いが見えます。Azure、Google Cloudではプロジェクトであるのに対し、Alibaba Cloud、AWSではアカウントが境界として機能しています。

もう一点、クラウド間で大きな違いがあります。リソースには、請求情報などのクラウドの管理機能も含むと説明しましたが、例えばGoogle Cloudではユーザに付与するそれらの権限をアプリケーションへ渡することはできません。アクセス方針の書き換え可否という観点でも差があります。Azure、Google Cloudでは定義済みポリシーのみをロールへ付与してコントロールする方式をとっています。ポリシーがロール内に定義され、ロールとしてしか見えないような実装もあります。アクセス方針を独自に書き換えが可能であるAWSやAlibaba Cloudとは方針が異なります。

まとめ

クラウドのリソースを安全に扱うための基盤となるサービスであるIAMついて見てきましたがいかがだったでしょうか。類似点も多いですが、相違点にも気づかれたと思います。

今回は基本的な部分のみの比較でしたが、実運用に入ると、例えば、全く外部の組織への一部のリソースの許可希望があったりと、ややこしい要件が求められることもあるでしょう。各クラウドはそのような複雑な要件にも対応できるよう柔軟で、しかしセキュアな手段を提供しています。IAM内でできることもありますし、別の管理機構と組み合わせてコントロールすることもあります。各クラウドがこのあたりの機能をどう提供するのかについても関心を広げるのもおもしろいかもしれません。

関連サービス