目次

  1. 1. はじめに
  2. 2. IAMとは
  3. 3. IAMの基本
    1. a) IAMユーザー(グループ)とは
    2. b) IAMポリシーとは
    3. c) IAMロールとは
  4. 4. IAMのベストプラクティス
    1. a) 権限は最小限にする
    2. b) 多要素認証をできるだけ行う
    3. c) CloudTrailでモニタリングをする
    4. d) アクセスキーは極力使わない
  5. 5. まとめ

1. はじめに

AWS IAMについて詳しく記載していきます。IAMはAWSのセキュリティを考えるうえで基本的なサービスとなっていますので、AWSを安全に利用するためには正しく理解することが重要です。

2. IAMとは

IAM(Identity and Access Management:アイアム)とは、AWSのサービスで「認証」と「認可」の設定を行うことができるサービスです。「認証」「認可」を正しく設定することで、AWSの利用者や、AWSのサービスがアクセスできる範囲を制御することができます。

3. IAMの基本

IAMを理解する前に、IAMが行っている、「認証」「認可」の意味の違いについて説明します。認証と認可は似ているようでまったく異なる言葉です。簡単に書くと、以下のような違いになります。

  • 認証 → 相手が誰(何)なのか確認すること
  • 認可 → リソースへのアクセス権限を与えること

わかりやすく、AWSの資格試験を受ける場合を考えてみます。
AWSの資格試験を受ける際は、以下の2ステップを必ず実行します。

① 受験料を払って試験の申込をする。
② 試験会場でパスポートや免許証で本人確認を行う。

このように、①の段階で、お金を払って申し込みをした人はAWSの資格試験を受験する権利を与えられます。この、申し込みを行い受験資格を得るという行為が「認可」にあたります。そして試験会場に行って本人確認を行い、申込者本人か確認を行いますが、この行為が「認証」です。このように、認証と認可は、まったく別の行為ですが、セットで行われることが多いです。IAMも、認証と認可の機能を持っております。

IAMでは、以下の機能が用意されています。

  • IAMユーザー(グループ)
  • IAMポリシー
  • IAMロール

次の項目で、それぞれ詳しく見ていきましょう。

a) IAMユーザー(グループ)とは

IAMユーザーとは、AWSを利用するアカウントです。主に、AWSを操作するコンソール画面にログインを行うときに人が利用します。ログイン用のIDを決めて作成します。IAMユーザーが作成されると、以下のような画面から、AWSコンソール画面にログインを行うことができます。※画像のアカウントIDは実在しません。

また、IAMグループを作成し、複数のIAMユーザをまとめて管理をすることができます。会社などで、部署やチームごとにIAMユーザの権限を分けたい場合などに利用するといいでしょう。

b) IAMポリシーとは

IAMポリシーについて説明していきます。IAMポリシーとは、IAMユーザや後述のIAMロールにアタッチすることができる、AWSリソースへの操作権限を設定する機能です。IAMポリシーにも大きく分けて3種類あります。

AWS管理ポリシー

AWSが提供するIAMポリシーです。各サービスに対して大まかな制御ポリシーが設定できます。

カスタマー管理ポリシー

ユーザがJSONファイルなどを利用して設定するポリシーです。IPアドレスの制御など、AWS管理ポリシーよりも細やかな制御が可能です。

インラインポリシー

インラインポリシーは特定のIAMユーザやIAMロール専用に作成されるポリシーです。AWS管理ポリシーやカスタマー管理ポリシーは1つのポリシーを作成すれば多くのIAMユーザなどにアタッチすることができますが、インラインポリシーは1つのIAMユーザなど、1対1でのアタッチしかできません。

c) IAMロールとは

IAMロールについて詳しく記載していきます。IAMロールとは、ユーザーやグループではなく、EC2などのAWSのサービスや他のアカウントに対してにAWS の操作権限を付与するための仕組みです。
例えば、EC2にRDSへの操作を行うアプリケーションを導入する場合は、EC2にRDSへのアクセス権限を記載したIAMロールをアタッチします。
また、他アカウントにS3への接続を許可する場合には、自分のアカウントに他アカウント用のIAMロールを作成しておくと、他のアカウントから「スイッチ」することで自アカウントのS3を操作することができるようになります。

IDフェデレーションといって、GoogleやFacebookなどのIDプロバイダーに対してアクセスを許可するようなIAMロールを作成することもできます。
例えばWebアプリケーションを作成したときに、このIDフェデレーションの仕組みを利用すればいちいちアプリケーションの利用者がアカウントを作成せずに、Webアプリケーションを利用することができるようになります。

4. IAMのベストプラクティス

IAMのベストプラクティスについて記載していきます。IAMはAWSサービスへのアクセス制御を行うサービスなので、ベストプラクティスに従うことでセキュアにAWSを利用することができます。

a) 権限は最小限にする。

IAMユーザやIAMロールに設定する権限は極力、必要最小限にしましょう。例えば、読み込みだけが必要であれば、ReadOnlyなどの権限にとどめておく、といった形です。必要以上の権限を与えてしまうと、漏洩したときに思わぬ被害が出てしまう恐れがあります。

b) 多要素認証をできるだけ行う

パスワードリスト攻撃などを防御する際に非常に有効なのが多要素認証です。GoogleのアプリやAuthyといった、簡単に導入できるサードパーティのアプリで実装が可能なので、ぜひとも利用してみてください。

c) CloudTrailでモニタリングをする

IAMユーザで行った操作ログはCloudTrailでモニタリングし、保存しておくことが重要です。万が一パスワードが漏洩した際に、どのような操作が行われたのかを記録しておくことで、訴訟などに備えることができます。また、CloudTrailが無効にされた場合は、AWSの通知サービスであるSNS(Simple Notification Service)を利用することで通知を行うことが可能です。

d) アクセスキーは極力使わない

IAMユーザごとにアクセスキーを生成できますが、極力使わないようにしましょう。アクセスキーを誤ってGitなどにアップしてしまう事故が世界中で発生しています。また、そのように誤ってアップロードされたアクセスキーを探すためのクローラーが世界中で稼働しています。極力IAMロールを利用しましょう。

5. まとめ

IAMはAWSのサービスを操作するための、「認証」と「認可」を行う重要なサービスです。AWSを利用していくうえで必ず利用するサービスになります。IAMユーザやIAMロールを正しく組み合わせて利用することで、セキュアにAWSを利用することができます。

また、極力ベストプラクティスにしたがって設定を行いましょう。ベストプラクティスを理解して実行することで、思わぬ事故を防止することができます。