CYBIRD Advent Calendar 2022の7日目を担当します、新卒1年目の@tomoko_ishizakaです。6日目は@cy-yuka-WP さんの「Google スプレッドシートやExcelで知っていると便利な関数」でした。

この記事の概要

最初自分がAWSのアカウントやユーザー、そしてIAMについて聞いたとき、非常に複雑で混乱してしまった。そこで本記事では、多くの人が知っているであろうソーシャルゲーム（以下ソシャゲ）（ダンジョン/素材集め/ガチャ等の機能がある一般的なものを想定している）を効率よくプレイしようとする主人公()のストーリー仕立てで、IAMの概観をざっくりとふんわりと説明していく。

※実際にAWSのIAMのような機能を搭載しているソシャゲはおそらくありません。フィクションです。

(最初に少しだけ)AWSとIAMについて

Amazon Web Services (AWS) とは

Amazonの提供するクラウドコンピューティングサービス。
つまり、サーバーやデータベースなどをクラウド上で作成/管理できるサービスのことである。

AWS Identity and Access Management (IAM) とは

AWS リソースへのアクセスを安全に管理するためのウェブサービス。
つまり、誰(もしくは何)が、何をできるのか？を管理する仕組みである。

アカウントとルートユーザー

「最近流行りのソシャゲを始めるぞ！まずは、メールアドレスとパスワードを設定して、アカウントを作るみたいだ。」

AWSの機能を利用するには、ゲームのログインと同じように、メールアドレスを使ってAWSアカウントを作成する必要がある。なお、AWSでは、メールアドレスを使ってログインしたユーザーは、ルートユーザーと呼ばれ、アカウントにあるリソースを全て利用できる。

IAMユーザー

「ソシャゲ楽しいなあ。ダンジョン周回、ガチャ、武器の錬成、毎日やりこんでいる。欲を言えば誰かに代わりにダンジョン周回とかやって欲しいなあ。このアカウント情報を友達に渡せば友達もログインできるぞ。でも、自分のメアドとパスワードを渡すのはちょっと嫌だし、いい方法でこのアカウントに友達をログインさせたいなあ。。。」

AWSには、そんな機能を実現するためのIAMユーザーというものがある。これは、１つのアカウントに複数の人間が入れるようにしたものだ。IAMユーザーはメアドとパスワードではなく、ユーザー名とそのユーザー名に対応するパスワード、そしてAWSアカウントIDの３つを使ってログインする。

IAMポリシー

「よし、これで友達が自分のアカウントに入って、ダンジョン周回とか手伝ってくれるようになったぞ。でも、、、勝手にガチャとか回されたらやだなあ。。ダンジョン周回だけしかできないようにしたいな。」

AWSには、そんな機能を実現するためのIAMポリシーというものがある。IAMポリシーとは、AWSリソース(EC2やS3など)への権限が書かれた設定のことで、例えばDatabaseAdministratorというポリシーは「データベースの作成、設定、メンテナンスを行うためのアクセス許可」という内容だったり、Billingというポリシーは「請求、コスト、支払い方法、予算、レポートを管理できる」という内容だったりする。他にもさまざまなポリシーがAWSによってあらかじめ用意されている。なお、自分で新たにポリシーを作成することもできる。

そして、このポリシーをIAMユーザーに付与すると、そのユーザーはポリシーで設定された権限を持つようになる。

IAMポリシーの複数付与

「これで友達にはダンジョン周回の権限だけを与えることができて安心だ！でも、ダンジョンだけじゃなくて、武器の強化も勝手にやってて欲しいなあ。」

AWSのIAMポリシーは、複数付与することができる。例えば特定のユーザーにDatabaseAdministratorとBillingという２つのポリシーを適用すれば、そのユーザーはデータベース関連のアクセスと請求周りの管理の両方の権限を持つことになる。（※実際の運用に適している例ではありません）

IAMグループ

「他の友達も何人かゲームを手伝ってくれることになったぞ。でも、全員にまたダンジョンの許可やら武器強化の許可やらを与えないといけないのは、面倒だなあ。一気に全員同じ許可を与えたいなあ。」

AWSには、そんな機能を実現するためのIAMグループというものがある。グループを作成し、IAMユーザーをそこに含めることができる。ポリシーはグループに付与することもでき、その場合ユーザーには、所属するグループに付与されたポリシーが適用される。

IAMロール

「新しいソシャゲを始めたぞ！また友達に手伝ってもらいたい。こっちでも彼らのユーザーを作るのはちょっと手間だし管理も面倒だなぁ….以前のソシャゲで渡したユーザーのアカウントでこっちにもログインして欲しいな。」

AWSには、そんな機能を実現するためのIAMロールというものがある。
すでにIAMユーザー（以降ユーザーA）が存在するアカウントをA、そのユーザーでアクセスしたいアカウントをBとする。まずBにてIAMロールというものを作成し、そのロールに必要なポリシーを適用する。さらにそのIAMロールに「アカウントAのユーザーAを信頼する」ポリシーを付与し、ユーザーAには「Bのロールを許可する」ポリシーを付与することで、ユーザーAはアカウントBに入って許可された操作をすることができるようになる。

「よし、これで友達が新しい方のソシャゲも手伝ってくれるようになったぞ。欲を言えば、最近流行りの自動化ツールを導入したい。でも、もしツールがバグって勝手にガチャとか回し始めたらやだな…」

AWSでは、IAMポリシーを直接AWSサービスに付与することは基本的にできないが、IAMロールを通してであれば付与することができる。ユーザーへの付与と同様に、まずポリシーを適用したロールを用意し、それをサービスに付与することで、サービスの操作権限を設定することができる。

おわりに

いかがでしたでしょうか…？
まだ一年目なので理解も甘いところがあるかとおもいますが、少しでも苦手意識なくIAMまわりについて読めればと思い本記事を書きました。

「わーい、これでソシャゲ無双だああ！」※だめです

明日のCYBIRD Advent Calendar 2022 8日目は、@moffunnya さんの「Terraformを使った環境構築入門（AWS）」です！