IAMユーザーとIAMロールの違いは？CLF-C02で迷わないための、認証情報と使う場面の整理

こんにちは、インフラエンジニアのryuです。

この記事は、AWSクラウドプラクティショナー（CLF-C02）の勉強をしていて、IAMユーザーとIAMロールの違いがはっきりしない人に向けて書いています。

IAMの章を読むと、ユーザー、グループ、ロール、ポリシーという言葉が一度に出てきます。どれも「権限」に関係しているので、問題を解くときにどれを選べばいいか迷いやすいところです。

特にユーザーとロールは、どちらにもポリシーを付けて権限を与えられるので、違いが見えにくいですよね。

この記事では、2つの違いを認証情報が長期か一時的かという1点から整理します。そのうえで、ロールを使う場面、CloudShellでの確認、確認問題4問と進めていきます。

IAMそのものが初めての人は、先にIAMとは？の解説記事を読んでおくと入りやすいです。CLF-C02全体の勉強の進め方は、CLF-C02の勉強方法の記事にまとめています。

IAMユーザーとIAMロールの違いとは？¶

まずは、2つの違いを表で並べてみます。

いちばん大きな違いは、認証情報の持ち方です。AWSのIAMユーザーガイドでは、ルートユーザーやIAMユーザー、アクセスキーは期限の無い長期の認証情報を持つと説明されています。

一方で、IAMロールにはパスワードやアクセスキーのような決まった認証情報がありません。ロールを引き受けたときに、その場で一時的な認証情報が発行されます。

AWSのドキュメントでは、IAMユーザーとアクセスキーによる長期の認証情報よりも、IAMロールやフェデレーションで得られる一時的な認証情報を使うことを強く勧めています。

IAMユーザーは「特定の誰か」の ID¶

IAMユーザーは、AWSアカウントの中に作る、特定の人やアプリケーションのためのIDです。

マネジメントコンソールにログインするためのパスワードや、AWS CLIから操作するためのアクセスキーを持たせることができます。これらは、削除したり変更したりするまでずっと使えます。

便利な反面、アクセスキーがGitHubに公開されてしまった、退職した人のユーザーが残っていた、といった事故につながりやすいのが弱点です。そのため、パスワードの変更やアクセスキーの管理、MFA（多要素認証）の設定が欠かせません。

IAMユーザーの作り方はIAMユーザーの作成方法の記事、MFAの設定はIAMユーザーでMFAを有効にする記事で手順を紹介しています。

IAMロールは「引き受けて使う」役割¶

IAMロールは、特定の誰かに結び付いたIDではありません。必要な人やサービスが、必要なときに引き受けて使う役割です。

ロールには、2種類のポリシーが関係します。

たとえば、EC2のインスタンスがS3のファイルを読むためのロールなら、信頼ポリシーで EC2 を、許可ポリシーで S3 の読み取りを許可します。

ロールを引き受けると、一時的な認証情報が発行されます。期限が切れると、その認証情報ではもう操作できません。もし漏れてしまっても、ずっと使われ続けることはないので、長期のアクセスキーよりも被害を小さくできます。

IAMポリシー・グループとの関係¶

ユーザーとロールの違いが分かったところで、残りの2つの言葉との関係も整理しておきます。CLF-C02の問題では、この4つを組み合わせた聞き方がよく見られます。

ポリシーは、それだけでは何もしません。ユーザー、グループ、ロールに付けて、はじめて権限として働きます。

グループは、ユーザーにまとめて権限を付けるためのもの¶

グループには、IAMユーザーだけを入れられます。ロールをグループに入れることはできません。

開発チームの5人に同じ権限を付けたいとき、1人ずつポリシーを付けるのは手間ですし、付け忘れも起きます。グループにポリシーを付けておけば、ユーザーをグループに入れるだけで同じ権限になります。

グループの作り方はIAMグループの作成記事、ポリシーの書き方はIAMポリシーの作成方法の記事で紹介しています。

最小権限の考え方¶

ユーザー、グループ、ロールのどれに権限を付けるときも、共通する考え方があります。それが最小権限の原則です。

作業に必要な権限だけを付けて、それ以上は付けないようにします。とりあえず管理者権限を付けておく、というやり方は、試験でも実務でも避けるべきものとして扱われます。

IAMロールを使う場面¶

では、ロールは具体的にどんな場面で使うのでしょうか。CLF-C02の受験者が押さえておきたいのは、次の3つです。

3つ目は、IAM Identity Center などを使ったフェデレーションです。AWSのベストプラクティスでは、人がAWSにアクセスするときは、IDプロバイダーを使って一時的な認証情報で入ることが勧められています。

EC2にロールを付ける例¶

ロールの使い方で、いちばんイメージしやすいのがEC2です。

EC2の上で動くアプリケーションがS3にファイルを保存するとき、アクセスキーをサーバーの設定ファイルに書くやり方もあります。ただ、その場合はサーバーが乗っ取られると、長期のアクセスキーがそのまま盗まれてしまいます。

代わりにEC2にロールを付けると、インスタンスはメタデータサービスから一時的な認証情報を受け取ります。AWS CLIやSDKは、この認証情報を自動で使ってくれます。

このとき、ロールの信頼ポリシーには、EC2のサービスがロールを引き受けてよいことを書きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principal が、ロールを引き受けてよい相手です。ここに ec2.amazonaws.com が書かれていないと、EC2はこのロールを使えません。

EC2そのものについては、EC2とは？の解説記事も参考にしてください。

今日やる練習：今使っている認証情報を確かめる¶

ここで、実際にAWSで手を動かしてみましょう。使うのは AWS CloudShell と、aws sts get-caller-identity というコマンドです。

このコマンドは、今どのIDでAWSを操作しているかを表示します。AWSのドキュメントによると、実行するのにIAMの権限は必要ありません。

手順1：CloudShellでコマンドを打つ¶

マネジメントコンソールにログインして、画面上部のアイコンからCloudShellを開きます。開いたら、次のコマンドを打ちます。

aws sts get-caller-identity

結果には、UserId、Account、Arn の3つが表示されます。Account はAWSアカウントの12桁の番号です。

CloudShellの開き方や、作業用のIAMユーザーの用意がまだの人は、AWS初心者が最初に試したい3つの操作の記事を先にやっておくと安心です。

手順2：Arnの形を読む¶

見てほしいのは Arn の形です。ユーザーで操作しているのか、ロールで操作しているのかによって、次のように形が変わります。

# IAMユーザーで操作しているとき
arn:aws:iam::123456789012:user/ユーザー名

# ロールを引き受けて操作しているとき
arn:aws:sts::123456789012:assumed-role/ロール名/セッション名

user/ なら、IAMユーザーの長期の認証情報で操作しています。assumed-role/ なら、ロールを引き受けて、一時的な認証情報で操作しています。

会社のアカウントで IAM Identity Center からログインしている人は、assumed-role/ の形になっているはずです。個人で作業用のIAMユーザーを作ってログインしている人は、user/ の形になります。

get-caller-identity は情報を表示するだけで、リソースを作るコマンドではありません。後片付けは必要ありません。

CLF-C02の確認問題¶

ここからは、この記事の内容をもとに作ったオリジナルの確認問題です。本番の問題ではありません。

問題1：EC2からS3を操作する方法¶

EC2のインスタンスで動くアプリケーションから、S3のバケットにファイルを保存します。AWSのベストプラクティスに沿った方法はどれでしょうか。

• A. IAMユーザーのアクセスキーを、インスタンスの設定ファイルに書く
• B. S3への書き込みを許可したIAMロールを、インスタンスに付ける
• C. ルートユーザーのアクセスキーを、環境変数に入れる

正解：B

EC2にロールを付けると、インスタンスは一時的な認証情報を受け取ってS3を操作できます。アクセスキーをサーバーに置かずに済むので、漏えいしたときの被害を小さくできます。ルートユーザーのアクセスキーを使うのは、いちばん避けるべき方法です。

問題2：認証情報の違い¶

IAMロールを引き受けたときに使われる認証情報について、正しい説明はどれでしょうか。

• A. ロールを作ったときに発行され、削除するまでずっと使える
• B. 引き受けたときに一時的に発行され、期限が切れると使えなくなる
• C. ロールにはパスワードが設定され、コンソールのログインに使う

正解：B

ロールには、パスワードやアクセスキーのような決まった認証情報がありません。引き受けたときに一時的な認証情報が発行され、期限が切れるとAWSはそれを受け付けなくなります。

問題3：同じ権限を複数の人に付ける¶

新しく入った10人の開発者に、同じ権限を付けたいと考えています。管理の手間がいちばん少ない方法はどれでしょうか。

• A. 10人のIAMユーザーに、同じポリシーを1つずつ付ける
• B. IAMグループにポリシーを付け、10人のIAMユーザーをそのグループに入れる
• C. 1人のIAMユーザーを作り、10人で同じパスワードを使う

正解：B

グループにポリシーを付けておけば、ユーザーをグループに入れるだけで同じ権限になります。人が増えたり権限を変えたりするときも、グループの設定を1か所直すだけです。1つのユーザーを複数人で使い回すと、誰が操作したのかが分からなくなります。

問題4：誰がロールを引き受けられるか¶

IAMロールで、そのロールを誰が引き受けてよいかを決めるものはどれでしょうか。

• A. 信頼ポリシー
• B. パスワードポリシー
• C. バケットポリシー

正解：A

ロールを誰が引き受けてよいかは、信頼ポリシーで決めます。ロールを引き受けたあとに何をしてよいかは、ロールに付けた許可ポリシーで決まります。パスワードポリシーはIAMユーザーのパスワードのルール、バケットポリシーはS3のバケットに付けるポリシーです。

4問のうち、迷った問題はあったでしょうか。迷った問題は、正解していても解説をもう一度読んで、理由を説明できるようにしておきましょう。

CLF-C02では、どこで問われる？¶

CLF-C02の試験ガイドでは、IAMは「セキュリティとコンプライアンス」の分野に入っています。この分野は試験全体の30%を占めていて、4つの分野の中で2番目に大きい分野です。

この分野の中に、AWSのアクセス管理の機能を理解することが含まれています。ユーザー、グループ、ロール、ポリシーの使い分けや、ルートユーザーの保護、最小権限の考え方は、ここに当てはまります。

CLF-C02は、細かい設定の手順よりも、どの場面で何を使うかを問う試験です。この記事の表に出てきた、長期か一時的か、誰が使うのか、どんな場面で使うのかを説明できれば、IAMの問題で迷うことはかなり減ります。

サービス名を暗記するだけでは解けない問題が気になる人は、CLF-C02は暗記だけで受かるか？の記事もあわせて読んでみてください。

InfraAcademyで続ける¶

IAMの違いが整理できたら、ほかの分野の問題でも理解を確かめてみましょう。

InfraAcademyでは、トップページのInfraAcademy の資格模擬問題で「AWS認定 クラウドプラクティショナー模擬試験150問」を解けます。セキュリティとコンプライアンスの分野で間違えた問題があれば、この記事の表に戻って、ユーザーとロールのどちらの話なのかを確かめてみてください。

AWSの操作を順番に学びたい人は、InfraAcademyのAWSの講座も使えます。講座の中のシミュレーターで、AWSの操作を練習できます。講座の順番はAWSのロードマップにまとめています。

まとめ¶

IAMユーザーとIAMロールの違いを振り返ります。

• IAMユーザーは特定の誰かのIDで、パスワードやアクセスキーという長期の認証情報を持つ
• IAMロールは引き受けて使う役割で、引き受けたときに一時的な認証情報が発行される
• ロールを誰が引き受けられるかは信頼ポリシー、何をしてよいかは許可ポリシーで決める
• EC2やLambdaからの操作、別アカウントへのアクセス、会社のIDでのログインにはロールを使う
• グループはユーザーをまとめる入れ物で、ロールは入れられない
• CloudShellで aws sts get-caller-identity を打つと、今どちらで操作しているかが分かる

ユーザーとロールの違いが分かると、IAMの問題だけでなく、EC2やLambdaの問題も読みやすくなります。

1つずつ手を動かして確かめながら、合格まで進んでいきましょう。応援しています。

参考¶

• AWS security credentials - AWS Identity and Access Management
• IAM roles - AWS Identity and Access Management
• IAM users - AWS Identity and Access Management
• Security best practices in IAM - AWS Identity and Access Management
• Managing Elastic Beanstalk instance profiles - AWS Elastic Beanstalk
• GetCallerIdentity - AWS Security Token Service
• AWS Certified Cloud Practitioner (CLF-C02) 試験ガイド - AWS Documentation