[入門] AWS IAMの基本のキ

こんにちは。サービス開発室の武田です。

AWSを使い始めると必ず出てくる「IAM」という言葉があります。このエントリでは IAM User と IAM Role に絞って解説をします（以下、IAMユーザー、IAMロールと表記）。

このエントリの狙い

網羅的な説明はすでに多くありますので、このエントリでは次の項目が説明できることを目標にします。

• AWSアカウントにおけるルートユーザーとは何か
• IAMユーザーの基本的な使い方
• なぜIAMロールを使用するのか

AWS IAMとは

AWS IAM（以下、IAM）とは、AWS Identity and Access Managementの略で、AWSのサービスやリソースへのアクセスを安全に管理するためのしくみ（サービス）です。

ちなみに読み方は「アイアム」派が多いと思います（少なくとも社内では）。ただ「アイエーエム」でも間違いではないため、好きな方でいいと思います（筆者はアイアム派です）。

ルートユーザーとは

IAMの説明の前に、ルートユーザーについて説明します。AWSアカウントを作成すると、最初に「ルートユーザー」が作成されます。これは、そのアカウントの「神様」のような存在です（専門的には特権ユーザーと呼ばれます）。ルートユーザーは基本的になんでもできる権限を持っていますが、逆に言えば権限が強すぎるため、日常業務で使うのはとても危険です^[1]。誤って重要な設定を変えてしまうリスクや、もしルートユーザーの情報が漏れてしまうとたいへんなことになります。ルートユーザーは無効化もできないため、パスワードやMFA^[2]をしっかりと設定し、普段は使わずに安全に管理しましょう。

ルートユーザーは日常業務には向かない、ということで登場するのがIAMというしくみです。IAMを使うことで、細かくアクセス権限をコントロールでき、安全にAWSを使うことができます。

IAMユーザーとは

IAMユーザーは、一般的に想像される「アカウント」や「ユーザー」に該当すると思って問題ありません。たとえば、GitHubやSlackを使うときにアカウントを作ってパスワードを設定し、ログインしますよね？IAMユーザーも基本的には同じイメージです。

つまり「AWSにアクセスするためのユーザーを作成する」＝「IAMユーザーを作成する」です。また、ユーザーの共有は重大なセキュリティリスクとなりやすいため、AWSにアクセスする人が複数いる場合は、IAMユーザーも人数分用意するのが基本です。

このエントリでは詳細は述べませんが、実用上は作成したIAMユーザーに対して権限設定も必要です。これは「IAMポリシー」というもので、簡単に言えば「AWS上でどんな操作ができるか」を決めておくことです。

IAMユーザーは作成しただけではパスワードが設定されておらず、そのままではログインできません。つまり、IAMユーザーを作っただけではAWSにアクセスできないのです。

図はユーザーAとユーザーBをそれぞれ作成して、AWSにアクセスしているイメージ図です。

IAMユーザーに必要な追加作業

次のいずれかの認証情報（よくクレデンシャルと呼ばれます）を設定することで、IAMユーザーはAWSにアクセスできます。

• パスワードの作成

パスワードを設定すると、AWSマネジメントコンソール（ブラウザ上の操作画面）からログインできます。ただし、マネジメントコンソールを使わない場合はパスワードを設定しないほうが安全です。無駄にリスクを増やさないためです。

• アクセスキーの作成

アクセスキーとシークレットアクセスキー（2つ合わせてアクセスキーペアと呼ばれます）を作成すると、AWS CLI^[3]やプログラムからAWSにアクセスできます。これも使う予定がなければ発行しないほうが安全です。

このように、IAMユーザーは「パスワード」か「アクセスキー」のどちらかを発行することで、AWSの操作が可能になります。ブラウザから操作するのか、プログラムなどから操作するのか（あるいは両方か）に応じて発行します。

IAMユーザーだけでは困るケース

IAMユーザーは人に紐づくアカウント（ユーザー）ですので、基本的には「この人がこのAWSリソースを操作する」という使い方に向いています。しかし、次のようなケースではIAMユーザーだけでは不便だったり問題があったりします。

• 一時的に別の権限を使いたいとき
  • たとえば、ある作業だけ特別な権限が必要な場合に、そのためだけのユーザーを新しく作るのは手間ですし、セキュリティリスクも高まる
• AWSのサービス（Amazon EC2やAWS Lambdaなど）に権限を与えたいとき
  • サービス自体は人ではないので、IAMユーザーを作ってパスワードやアクセスキーを設定するのは適切でない
• 別のAWSアカウントのIAMユーザーに権限を与えたいとき
  • 別のAWSアカウントからのアクセスを許可したい（クロスアカウントアクセスと呼ばれます）場合に、IAMユーザーでは管理も煩雑になる
• 長期間のアクセスキーを発行せずに済ませたいとき
  • アクセスキーは漏れた場合にリスクが大きいので、できるだけ短期間で使い捨てできるしくみが欲しい

これらの問題を解決できるしくみとして、IAMロールがあります。

IAMユーザーも、IAMロールも、あるんだよ

IAMロールは「役割」に紐づくもので、人ではなく「役割」に対して権限を与えます。IAMロール自体にはログイン用のパスワードやアクセスキーはありません。代わりに、IAMユーザーやAWSのサービスがIAMロールを「引き受ける（Assume）」ことで、一時的にそのIAMロールの権限を使うことができます。

IAMロールを「帽子」にたとえるとわかりやすいです（※別にお面でもいいです）。被った人が元はどんな人であっても、被った帽子の役割を引き受ける。帽子自体では動けない。というわけです。

なお、誰でもそのIAMロールを使用できては問題になるため、IAMロールを作成する際には誰が使用できるのかを「信頼関係ポリシー」というもので決めておきます。

図はEC2にアクセスできるロールXと、S3にアクセスできるロールYがあります（青帽子と白帽子）。青帽子を被ったAさんはEC2にアクセスできますが、S3にはアクセスできません。青帽子を被ったBさんも同様です。

また白帽子を被ったAさんはS3にアクセスできますが、EC2にはアクセスできません。白帽子を被ったBさんも同様です。

図ではどちらもユーザーのイメージでしたが、AWSサービスに対してもこの帽子を被せられます。このようにIAMロールを使用することで、ユーザーやサービスに「役割」を与え柔軟なアクセス制御が実現できるわけです。

IAMロールがあるととっても便利

IAMロールを使用することで、先ほど挙げたIAMユーザーだけでは解決できない問題を安全に解決できます。

• 一時的に権限を委譲する
  • IAMユーザーが必要なときだけIAMロールを引き受けて、一時的に強い権限を行使できる
  • 作業が終わればその権限もなくなるので、不要な権限を長期間持ち続けるリスクを減らせる
• AWSサービスに権限を与える
  • たとえばEC2インスタンスにIAMロール^[4]を割り当てると、そのインスタンス上のプログラムが安全にS3バケットにアクセスできる
  • アクセスキーをインスタンス上などで管理する必要がなくなるため、セキュリティが大幅に向上する
• クロスアカウントアクセス
  • 別のAWSアカウントのIAMロールを引き受けることで、安全にアカウント間でリソースを操作できる
• 共通の権限を使い回す
  • 複数のIAMユーザーやサービスが同じIAMロールを使うことで、権限管理がシンプルになる

まとめると、IAMロールを使うことでサービス間やアカウント間で安全に連携でき、権限管理もシンプルにできます。

まとめ

• AWSアカウントにおけるルートユーザーとは何か
  • なんでもできるユーザー。でも日常業務では強すぎるので使わない
  • サイバイマン相手に身勝手の極意使う みたいなもん
• IAMユーザーの基本的な使い方
  • 「パスワード」または「アクセスキー」を発行し、人がAWSを操作するために使用する
• なぜIAMロールを使用するのか
  • 一時的に別の権限を使いたい時や、サービス連携あるいはクロスアカウントアクセスにおいて便利だから
  • IAMユーザーより安全かつ柔軟に権限管理ができるから

このエントリを読んで、以上のことが理解できたら目標達成です！

IAMユーザーは人が使う。IAMロールはIAMユーザーやサービスに被せる帽子。このイメージが持てたらOKです。

脚注

1. AWS Organizationsの機能を使用すればルートユーザーの操作も制限できます。 ↩︎

2. Multi-Factor Authentication（多要素認証）の略。ユーザーに2つ以上の認証要素の提供を求める認証方法。 ↩︎

3. AWS Command Line Interfaceの略。コマンドでAWSを操作、管理できる統合ツール ↩︎

4. もちろん「S3バケットにアクセスできる権限が設定されている」IAMロールのことです ↩︎