AWS IAMとは?アクセス管理の基本をやさしく解説

AWS IAMとは?アクセス管理の基本をやさしく解説

AWSのアクセス管理に悩むクラウド初心者のイメージ
「AWSのアクセス管理って、どうやる?」
「ルートユーザーは、使っていい?」
「IAMロールって、結局なに?」

AWSを触り始めた頃、最初に作ったアカウントでそのまま全部やっていませんか。じつは、それが危ない使い方です。IAMとは、「誰が、何に、どこまでアクセスできるか」を管理するAWSの仕組みです。安全なAWSは、このIAMの設計から始まります。

 

この記事は、ルートユーザーとIAMユーザーの線引きから入り、「人・チーム・サービス」で権限の渡し方をどう選ぶかを決定フローで示し、最後によくある危ない設定まで潰します。AWS認定クラウドプラクティショナーのセキュリティ対策に効きます。

 

1. ルートユーザーは、金庫の親鍵

ルートユーザーとIAMユーザーの権限差のイメージ

あなたがAWSアカウントを作ると、最初に生まれるのがルートユーザーです。アカウント内のあらゆる操作ができる、最上位の存在。だからこそ、日常の作業では使いません。もし乗っ取られれば、被害はアカウント全体に及びます。

 

日常の作業にはIAMユーザーを作って使います。人やシステムごとに発行する個別のアカウントで、一人ひとりに専用の認証情報を持たせるので、「誰が操作したか」を後からたどれます。あなたがチームで作業するなら、メンバーごとにIAMユーザーを用意するのが基本です。似た役割の人をまとめるIAMグループを使えば、新しいメンバーをグループに加えるだけで必要な権限が揃い、管理の手間もぐっと減ります。

 

たとえるなら、ホテルのカードキーです。全部屋を開けられるマスターキー(ルートユーザー)は支配人が金庫に厳重にしまい、普段は使いません。宿泊客や清掃スタッフには、必要な部屋だけ開くカードキー(IAMユーザー)を渡す。開けられる範囲を人ごとに絞るのが、安全な鍵の配り方です。

 

このアクセス権の設計は、AWS責任共有モデルとは でいう「利用者が守る範囲」のど真ん中にあたります。クラウド事業者が守る部分と、あなたが守る部分の線引きを掴んでおくと、IAMの重みが腑に落ちます。

 

2. 権限の渡し方を、フローで選ぶ

権限付与手段を判定フローで選ぶイメージ

IAMでつまずくのは「ユーザー・グループ・ロール、どれを使えばいい?」という選択です。答えは、「誰に権限を渡すか」で機械的に決まります。判断の分かれ道を図にしました。

 

権限を渡す相手は? AWSサービス/アプリ 何人? IAMロール一時的に権限を借りる 1人 複数(同役割) IAMユーザー個別に発行 IAMグループ権限をまとめて付与 ルートユーザーは、この図のどこにも入らない(日常では使わない)

 

渡す相手が人なら、1人ずつならIAMユーザー、同じ役割が複数いるならIAMグループでまとめて権限を配ります。渡す相手がEC2などのAWSサービスやアプリなら、IAMロールの出番です。ロールは固定のIDやパスワードを持たず、必要なときだけ一時的に権限を引き受け、使い終われば手放すのが特徴。認証情報を持ち歩かないぶん、漏えいのリスクを抑えられます。

 

あなたが「ユーザーとロールの違いが曖昧」と感じるなら、この一点で分けてください。人が使い続ける入口がユーザー、サービスがその場で借りる入口がロール。たとえばEC2にロールを付けておけば、そのサーバーは必要な範囲だけ他のAWSサービスを操作でき、あなたがキーをコードに書き込む必要がなくなります。人には固定の身分証、機械には使い捨ての入館パス——そう捉えると取り違えません。

 

許可の中身を書いた設定がポリシー(JSON形式)です。「誰に・どのサービスの・どんな操作を許すか」の一覧、と捉えれば入門では十分。ユーザー・グループ・ロールという「誰が」に、ポリシーという「何を許すか」を貼り付ける——この組み合わせがIAMの骨格です。EC2にロールを付ける具体例は AWS EC2とは で見えてきます。

 

3. 最小権限とMFA、2つの守り

最小権限の原則とMFAで守るイメージ

IAMを設計するときの背骨が最小権限の原則です。利用者やサービスに、業務に必要な最小限の権限だけを与える。余分を渡さないから、万一乗っ取られても被害の範囲が狭くて済みます。最初は絞っておき、足りなければ後から足す。逆に「とりあえず広めに許可」は、思わぬ操作を招く火種になります。

 

もう1つの守りがMFA(多要素認証)です。パスワードに加えて、スマホの通知など「もう1つの要素」を組み合わせる仕組み。パスワードが漏れても、スマホまで揃わなければ突破されません。ルートユーザーと重要なIAMユーザーには、MFAをかけておきます。認証と認可の考え方の土台は 認証と認可の違いとは で押さえられます。

 

現役エンジニアとして権限設計に関わってきた立場で言うと、効くのは「この権限、本当に要る?」を付与の瞬間に一度問う習慣です。広い権限は、あとで絞るのが難しい。使い始めてから「実は使っていなかった」権限が残り続けるのが現場のあるあるで、最初に狭く始めるほうが、結局ラクに安全を保てます。

 

4. やってしまいがちな、危ない設定

IAMでありがちな危ない設定を避けるイメージ

試験でも実務でも、「これはダメ」という形で問われるパターンがあります。あなたが先に避けておくべき、代表的な3つです。

 

  • ルートユーザーの常用: 日常作業をルートで行うのは危険。IAMユーザーを作り、ルートはMFAで封印して普段は使わない
  • 権限の付けすぎ: 「面倒だから管理者権限を全員に」は最小権限の逆。役割ごとに必要な範囲へ絞る
  • アプリに固定のキーを埋め込む: プログラムへ固定の認証情報を持たせず、IAMロールで一時的な権限を引き受けさせる

 

3つに共通するのは、「便利さのために広く・強く・固定で持たせる」設定が、そのまま事故の入り口になるという点です。判断に迷ったら、「この鍵を落としたら、どこまで開いてしまうか」を想像してみてください。開く範囲が広いほど、絞るべきサインです。IAMは、この「開く範囲を最小にする」発想さえ握っていれば、細かい設定に振り回されずに済みます。

 

試験では、「ルートユーザーをどう扱うべきか」「アプリに権限を渡す適切な方法は」という形で、この3つの失敗が正誤の分かれ目になります。あなたが選択肢を見るときは、より狭く・より一時的な方を選べば、たいてい正解にたどり着きます。IAMの設問は「安全側はどちらか」を問うているからです。

 

 

次のステップ

IAMがセキュリティ領域のどこに位置するかを地図で見たいなら、AWS認定クラウドプラクティショナーの試験範囲と勉強法ガイド で全体の並びを先に確認しておくと、位置づけが見えてきます。

覚えた使い分けは、問題で試すと定着します。AWS セキュリティ領域の問題集 で、ルート・ユーザー・ロールの問われ方を、問題で試しておきましょう。