AWS 03：IAM：誰に何を許すか ― 認証・認可・ロール・最小権限

関所は2つ：①「あなたは誰？」

AWS に何かを頼むとき（API を呼ぶとき、第1章）、その頼みごと（リクエスト）は必ず2つの関所を通ります。図の赤い小包がリクエストです。

最初の関所は認証（Authentication）です。「あなたは誰か」を確かめることです。

たとえるなら、会社の受付で身分証を見せることです。受付は「この人はフォトログ開発者の山田さんだ」と確かめますが、この時点では、山田さんがどの部屋に入ってよいかまでは決めていません。

AWS での認証には、次のようなものが使われます。

第1章でルートユーザーに MFA を付けたり、Identity Center を用意したりしたのは、この認証を強くするためでした。パスワードが盗まれても「本人だ」と言い張れないようにしたわけです。

でも、本人だとわかっただけでは、まだ半分です。次の関所に進みます。

関所は2つ：②「それをしてよい？」

2つめの関所は認可（Authorization）です。「その人に、その操作が許されているか」を決めることです。

受付を通った山田さんが、サーバー室の扉の前に来ました。門番は名簿を見て、「山田さんはサーバー室に入ってよい人か」を確かめます。名簿に載っていなければ、本人であっても入れません。

AWS では、この名簿にあたるものをポリシーと呼びます。

大事なのは、AWS はリクエストのたびに毎回この2つを確かめることです。コンソールでボタンを押すたび、CLI で命令を打つたび、サーバーが写真を1枚置くたびに、「誰か」と「してよいか」が確かめられます。

一度入れたら何でもできる、ということはありません。だからこそ、ポリシーで細かく「ここまで」と決めておけば、それがいつでも効きます。

IAM の中心は、この認可の側です。ここからは、「誰に」と「何を」をどう表すかを順に見ていきます。

「誰」にあたるもの：ユーザー・グループ・ロール

IAM で「誰に」にあたるものは3種類あります。

ロールは少しわかりにくいので、後でじっくり説明します。今は「決まった持ち主がいない、かぶる帽子のようなもの」と思っておいてください。

ここで第1章を思い出してください。Identity Center で作ったのは IAM ユーザーではなく、Identity Center のユーザーでした。Identity Center のユーザーがアカウントに入ると、中では許可セットから作られたロールをかぶって操作します。

AWS が今勧めているのは、人もサーバーも、ロールをかぶって期限つきの鍵で操作する形です。IAM ユーザーは、長く使える鍵を持ててしまうので、どうしても必要な場合（ロールを使えない古い道具など）に限ります。

この本でも、IAM ユーザーは作りません。人は Identity Center、サーバーや自動化はロールで入ります。

許可は人ではなく「まとまり」に付ける

許可を1人ずつに付けていくと、どうなるでしょうか。

最初は3人でも、人が増え、異動し、辞めていきます。「佐藤さんには付けたが、鈴木さんに付け忘れた」「辞めた人の許可を消し忘れた」という漏れが必ず出てきます。

そこで、許可はまとまりに付け、人をまとまりに出し入れするのが基本です。

図では、「開発者のまとまり」にポリシーを付けています。山田さん・佐藤さん・鈴木さんは、このまとまりに入っているので、同じ許可を持ちます。

新しい人が入ったら、まとまりに入れるだけで、同じ許可になります。辞めた人は、まとまりから外すだけです。1人ずつの許可を管理しなくてよいので、漏れが起きにくくなります。

「開発者」「読むだけの人」「請求担当」のように、仕事の役割ごとにまとまりを作るとわかりやすくなります。人の名前ではなく、役割でまとめるのがコツです。

ポリシー：許可を書いた「名簿」

では、名簿であるポリシーの中身を見てみましょう。ポリシーは JSON（ジェイソン）という書式で書きます。JSON は、{ } の中に "名前": 値 を並べて情報を表す書式で、人にも機械にも読みやすいので、Web の世界で広く使われています。

図の左が、フォトログの Web サーバー用のポリシーの例です。日本語に直すと、右のようになります。

photolog-photos という写真の置き場の中のファイルを、読む（GetObject）ことと置く（PutObject）ことを、許す（Allow）。

たったこれだけです。このポリシーを持つ者は、写真の置き場のファイルを読み書きできますが、それ以外は何もできません。サーバーを消すことも、データベースを見ることも、別の置き場を覗くこともできません。

Statement（文）の中には、このような「許す・禁じる」のかたまりをいくつも並べられます。たとえば「写真を読む・置く」と「ログを書く」の2つを1つのポリシーに書くことができます。

次に、この3行の読み方をもう少し詳しく見ます。

ポリシーの読み方：「許す／禁じる」「何を」「どれに」

ポリシーの1つのかたまりは、主に次の要素でできています。

ARN（Amazon Resource Name）は、AWS の中のものを1つに特定するための名前です。arn:aws:サービス:リージョン:アカウントID:もの の形をしています。S3 はリージョンやアカウントを書かない決まりなので、::: と空欄が続いています。

最後の /* は「この置き場の中のすべてのファイル」という意味です。* は「何でも」を表す記号で、s3:* と書けば S3 のすべての操作、Resource に * と書けばすべてのものを指します。便利ですが、* を使うほど許可は広くなります。

一番上の Version は、ポリシーの書式の版です。日付のように見えますが、いつも 2012-10-17 と書くものだと覚えておけば十分です。

判定の順番：最初は全部ダメ、Deny は Allow より強い

1人（1つのロール）に、複数のポリシーが付いていることはよくあります。そのとき AWS は、付いているポリシーを全部集めて、次の順に判定します。

覚えておくべきことは2つです。

1つめは、最初は全部拒否だということです。許可は「書いたものだけ」が通ります。ポリシーを書き忘れた操作は、何もしなくても拒否されます。これが安全の土台です。

2つめは、`Deny` は `Allow` より強いということです。どこかのポリシーで Allow していても、1か所でも Deny があれば拒否になります。これを使うと、「管理者であっても、東京以外のリージョンは使わせない」「本番のデータベースだけは消させない」のような絶対に越えさせない線を引けます。

なお、第1章で見たとおり、ルートユーザーだけはこの判定の外にいます（ポリシーで縛れません）。だからこそ金庫にしまうのです。

最小権限：必要な分だけを渡す

ここまでの道具を使って実現したいのが、最小権限という考え方です。仕事に必要な最小限の許可だけを渡すことです。

図の大きな赤い円が「管理者：できること全部」、中の小さな緑の円が「フォトログのサーバーに本当に必要な分」です。小さな円だけを渡しておけば、サーバーが乗っ取られても、被害は写真の置き場の範囲で止まります。

ただ、最初から「必要な分だけ」を正確に書くのは難しいものです。何が要るかは、動かしてみないとわからないことも多いからです。そこで、少しずつ絞っていきます。

IAM Access Analyzer には、ほかにも「アカウントの外（他人や全世界）に開いてしまっているもの」を見つける機能や、書いたポリシーの間違いを指摘する機能があります。

最小権限は、一度やって終わりではありません。付けすぎたものは、定期的に見直して外す。これを続けることが大切です。

ポリシーの3つの置き方

ポリシーには、置き方が3種類あります。

AWS 管理ポリシーは手軽ですが、多くの人に使えるよう作られているので、範囲は広めです。たとえば「S3 の全部を読める」ポリシーはあっても、「photolog-photos だけ読める」ポリシーはありません。

カスタマー管理ポリシーは、この章の例のように、自分のサービスに必要な分だけを書けます。名前を付けて1か所で管理でき、変えれば使っているところ全部に反映されます。

インラインポリシーは、あちこちに埋め込まれると、どこに何の許可があるのか見落としやすくなります。例外として使う程度にとどめます。

フォトログでは、Web サーバー用の許可をカスタマー管理ポリシーで書きます。

アクセスキーを作らない理由

第1章で「アクセスキーは作らない」と書きました。ここで改めて理由を説明します。

アクセスキーは、IAM ユーザー（やルートユーザー）が持てる、プログラム用の長く使える鍵です。CLI や自作のプログラムから AWS を操作するのに使えます。問題は、自分で消すまで、ずっと使えることです。

図の番号の順に、よくある事故の流れを追います。

悪用の多くは、あなたのアカウントで大量のサーバーを借り、暗号資産の採掘などに使うものです。気づいたときには、高額の請求が届いています。

ロールや Identity Center でもらう期限つきの鍵なら、万一漏れても数時間で使えなくなります。しかも、鍵を自分でファイルに書いて保管する必要がそもそもありません。

どうしてもアクセスキーが必要な場面は、今ではかなり限られています。迷ったら作らない。これで事故の大部分を防げます。

ロールは「かぶる帽子」

いよいよロールです。ロールは、かぶった者に、決まった許可を一時的に与える役割です。たとえるなら、「警備員の帽子」です。帽子をかぶっている間だけ、警備員として鍵を開けられます。脱げば、ただの人に戻ります。

ロールは2枚の紙でできています。

図の左のサーバーが、真ん中のロール photolog-web-role をかぶり、右の写真の置き場（S3）を使います。

ここでの大きな利点は、サーバーに鍵を置かなくてよいことです。アクセスキーを使うやり方では、サーバーの中の設定ファイルに鍵を書く必要がありました。サーバーが乗っ取られれば、鍵も盗まれます。ロールなら、サーバーには最初から鍵がありません。必要なときに、期限つきの鍵を受け取るだけです。

ロールをかぶれるのはサーバーだけではありません。

ロールをかぶると、期限つきの鍵が届く

実際にロールをかぶるときの流れを、図の番号で追います。

図の小包が、その期限つきの鍵です。

EC2 のサーバーの場合、1と2は自動で行われます。サーバーを作るときにロールを選んでおけば、サーバーの中のプログラム（AWS の SDK＝プログラムから AWS を使うための部品）が勝手に鍵を受け取り、期限が切れる前に新しい鍵に入れ替えてくれます。あなたのコードに鍵を書く必要は一切ありません。

この「かぶる」操作は、専門用語では AssumeRole（ロールを引き受ける）と呼ばれます。次の作り方のページで、信頼ポリシーの中に sts:AssumeRole という Action が出てきます。

第1章で、Identity Center のポータルから入ると「一時的な鍵」が渡されました。あれも裏では、同じようにロールをかぶって期限つきの鍵を受け取っていたのです。人もサーバーも同じ仕組みだとわかると、IAM がぐっと見通しよくなります。

フォトログの「誰に何を」表

ここまでの考え方で、フォトログの権限を表にしてみます。

どの行にも、長く使える鍵が出てこないことに注目してください。人は Identity Center、サーバーや自動化はロール。すべて期限つきの鍵です。

また、「管理者」は最初の自分にしか出てきません。他は全員、その仕事に必要な分だけです。

この表は、サービスが育つにつれて行が増えていきます。新しい「誰か」が増えるたびに、「その人（そのもの）の仕事に本当に要るのは何か」を考え、この表に1行足す。これが IAM の設計です。

サーバー用のロールを作る

フォトログの Web サーバー用のロールを作る手順です。第9章でサーバーを作るときに使います。

2番で「EC2」を選ぶと、図の左の信頼ポリシーが自動で作られます。読んでみましょう。

Principal（かぶる者）が ec2.amazonaws.com、つまり EC2 のサービスです。Action の sts:AssumeRole が「ロールをかぶる」操作です。まとめると「EC2 のサーバーが、このロールをかぶることを許す」となります。

写真の置き場（S3）そのものは第15章で作ります。名前が決まっていないと Resource が書けないので、許可ポリシーは第15章で仕上げます。それまでは、ロールを「入れ物」として作っておくだけで構いません。

なお、サーバーにロールを付けるときは、ロールをそのまま渡すのではなく「インスタンスプロファイル」という入れ物に包んで渡します。コンソールで作った場合は自動で用意されるので、今は名前だけ知っておけば十分です。

お金：IAM そのものは無料

IAM の基本的な機能には、料金がかかりません。

お金の面で IAM が効いてくるのは、むしろ事故を防ぐほうです。第1章の予算の知らせが「使いすぎたら気づく」仕組みだったのに対し、IAM は「そもそも使いすぎられないようにする」仕組みです。乗っ取られても大量のサーバーを借りられない許可にしておけば、高額請求の事故は起きにくくなります。

IAM は無料なので、ロールやポリシーはつい増えがちです。増えるほど見通しが悪くなり、「これは何のためだっけ」というものが残ります。次の片付けで扱う「最後に使った日」を見て、要らないものを消していきましょう。

具体的な料金は、IAM Access Analyzer の料金ページで確認してください。

よくある落とし穴

IAM で実際によく起きる失敗です。多くは「とりあえず」から始まります。

5つ目は、初めての人がよくつまずくところです。S3 の場合、「置き場の一覧を見る」操作は置き場そのもの（arn:aws:s3:::photolog-photos）に、「ファイルを読む・置く」操作は中のファイル（arn:aws:s3:::photolog-photos/*）に対して許可します。片方しか書かないと「許可したのに動かない」になります。

「許可したのに動かない」ときは、AWS が返すエラーの文言に、どの操作が、どのものに対して拒否されたかが書かれていることが多いので、まずそこを読みましょう。

片付け：使っていない許可と鍵を消す

IAM の片付けは、「作ったものを消す」よりも「使わなくなったものを見つけて消す」ことが中心です。そのための道具が用意されています。

たとえば、「90日以上使われていないロール」は、消しても困らない可能性が高いものです。消す前に、何のためのものかを確かめてから消しましょう。

この章で練習に作ったロールやポリシーのうち、使わないものは消してください。ロールの画面で選んで「削除」を押せば消えます。

ただし、photolog-web-role は第9章でサーバーに付けるので、残しておいて構いません。

IAM の見直しは、月に一度、請求の画面を見るついでに行う習慣にすると続けやすくなります。