いまさら聞けないIAMのお話し　その①

投稿日: 2025/09/22

はじめに

こんにちは、園田です。

いまさらシリーズとして、いまさら聞けないAWSのサービスについて基本から応用（？）まで幅広く記載していきたいと思います。

第1弾はIAMになります。書くことがいっぱいありそうですね。
IAMはAWSを管理する上での根幹となるサービスになります。最重要サービスと言っても過言ではありませんが、色々なことが出来る分、理解することがなかなか難しいサービスになります。

IAMをきちんと理解することがAWSマスターへの第一歩です。
という訳でIAMのお話をしていきましょう。

なお、きちんとIAMについて勉強したいよ。という方はAWSからBlack Belt というオンラインセミナーの資料がありますので、以下のページから参照ください。

https://aws.amazon.com/jp/events/aws-event-resource/archive/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc&awsf.tech-category=*all

とはいえ、Black Beltってちょっと難しいんですよね。
IAMは2つに別れており、Part1が67ページ、Part2が62ページとなっています。
それだけ大切なサービスという事ですが、読むのも大変ですね。
このシリーズはもうちょっとギュッと圧縮したいと思います。

そもそもIAMってなに？

IAMは「Identity and Access Management」の略で、そのまま訳すと「身分とアクセス管理」になりますね。
要するに、「誰であるか」と「何が出来るか」を管理するものになります。

とはいえ、純粋にユーザIDとパスワードという単純な物ではありません。
なので、IAMは説明が難しいサービスだと思われます。

あまりにも説明が大変なので、大体こんな感じで説明しています。

上記概要について、1つずつ説明していきましょう。

図の通り、IAMには①～④まで利用方法があります。
実際にはもっと色々ありますが、まずは基本という事でこの4つと理解ください。細かいところは後半の部分で説明したいと思います。

①管理者がAWSコンソール（マネジメントコンソール）にアクセスする

はい、1番分かり易い「IAMユーザ」の話ですね。

AWSのマネジメントコンソール（https://aws.amazon.com/jp/console/）にアクセスする際、ユーザIDとパスワードを入力してログインを行います。
IAMユーザには、権限（IAMポリシー）が割り振られており、ユーザ毎に「何が出来る」、「何が出来ない」を細かく設定することが可能です。

②③サーバ等からIAMのアクセスキーを利用してAWSの操作を実施する

こちらも「IAMユーザ」になりますね。
IAMユーザを発行時、マネジメントコンソールにログインする、「ユーザID・パスワード」の他、「アクセスキー・シークレットキー」の発行が可能です。

マネジメントコンソール上だとこんな感じで「アクセスキーを作成」をクリックすると「アクセスキー・シークレットキー」が作成されます。

作成した「アクセスキー・シークレットキー」はプログラムに埋め込んだり、aws configureコマンドでサーバのプロファイルに埋め込んだりすると、そのIAMユーザの権限でAWSの操作をすることが可能です。

この「アクセスキー・シークレットキー」はプログラムでAWSを操作したい時に利用します。例えば「サーバの一覧を出力したい」とか「定期的にバックアップを取りたい」とかそんな感じですね。

頭を使わなくてもAWSの操作が出来る大変お手軽なやり方ですが、一方で「アクセスキー・シークレットキー」が漏洩した際は即アカウントを乗っ取られるなどのセキュリティ事故が発生します。

プログラム埋め込みなんてことをやってしまうと公開されているGitHubにプログラムをプッシュしてしまう方もいるので本当に危険です。
プログラムにアクセスキー、シークレットキーは絶対に入れないでください。
良い子の諸君！　お兄さんとのお約束だぞ。

基本はセキュリティ意識が低い（無い）人がいるという前提において、「アクセスキー・シークレットキー」は発行しないようにしておきましょう。
どうしても発行したい場合は、極力sts権限だけにしておきましょう。
（stsの権限については後で記載します。）

なお、「アクセスキー・シークレットキー」ですが、こちら実際には①～④の全ての操作にて利用しています。

①の操作においては、テンポラリのアクセスキー（一定時間後、無効となる）が発行され利用しているのに対し、②③のアクセスキーは永続的に利用が可能なものとなります。
これは「AWSの操作は全てAPIで実施する」という思想の元、作られているためマネジメントコンソールの操作についてもAPIを実行しているためです。

この辺はCloudTrailのイベントレコードを確認すれば、マネジメントコンソールにログインしたユーザについても「accessKeyId」が割り振られていることが分かります。マネジメントコンソールでログインした際に利用した「accessKeyId」がテンポラリのアクセスキーですね。

④AWSのサービスにIAMロールを割り当てる

「アクセスキー・シークレットキー」を発行せず（厳密には永続的な「アクセスキー・シークレットキー」を発行せず）AWSのサーバ等からAWSの操作をしたいという時、IAMロールを利用します。

IAMロールは原則、AWS内のインスタンス（EC2など）に割り当てて利用する形となります。（実際には信頼ロールという事で他のサービス等から信頼する形で利用が可能ですが、こちらは後で説明します）

こちらもIAMユーザと同様、IAMロールに権限（IAMポリシー）が割り振られており、ロール毎に「何が出来る」、「何が出来ない」を細かく設定することが可能です。

これまでの説明を聞いて良く分からないという方は、とりあえずユーザがログインするときはIAMユーザ、プログラム等でAWSを操作したい時はIAMユーザじゃなくて、IAMロールを使う。と覚えておいてください。

IAMの基本要素

IAMってこんな感じ。というのを説明したので、次はIAMの基本要素についてお話しします。IAMの基本要素は以下になります。

それぞれの関係性は以下のような形となります。

〇関係性はこんな感じ

１．IAMユーザ

「そもそもIAMってなに？」の所で説明しているので割愛します。

２．IAMグループ

画像の通り、IAMポリシーを纏めたものです。
ただ単に管理をしやすくするための物です。それ以上の意味はありません。

なぜかIAMユーザのみIAMグループが利用でき、IAMロールにはIAMグループは設定できません。
IAMユーザやIAMロールに割り当てられるIAMポリシーには上限があるので（デフォルト10です。上限緩和可能です）、IAMグループを利用させていただきたい所ですが、IAMロールは利用不可という不可解な制限があります。

「ルールをあわせるためにはIAMグループを使わない方が良いのでは？」と思いますが、利用の可否は利用者の判断に委ねます。

なお、しつこいですが、IAMグループは「ただ単に管理をしやすくするための物」になります。後述するIAMポリシーの条件として、IAMグループは利用できません（Condition句として利用できない）。

時々、お客様から「IAMグループで制限したいんですけど」とか要望を貰うのですが、正直設定できないので園田はIAMグループは使いません。

説明が面倒なのでIAMグループは無くすか、IAMロールにも利用できる、かつIAMポリシーのCondition句として利用できるように改修して欲しいところです。
（2025年9月現在の情報です。ただ多分、この改修が実施されないと思います。）

３．IAMロール

「そもそもIAMってなに？」の所で説明しているので割愛します。

４．IAMポリシー

権限を定義しているものとなります。
IAMポリシーには大きく分けて以下２つが存在します。

「AWS管理」のIAMポリシーは例えば、AWSのサービスに機能が増えた際に等に自動的に権限を追加してくれるため、基本的にメンテナンスフリーです。
問題なければ、「AWS管理」のIAMポリシーを使うと良いでしょう。

よく使うAWS管理のIAMポリシーは以下の通りです。覚えておきましょう。

IAMポリシーについて（詳細）

IAMポリシーの概要について説明が終わったので、もうちょっと細かくIAMポリシーについてみていきましょう。

IAMポリシーについてはすべて利用可能なAPIをjson形式にて記載しています。
jsonは　{ }　、とか　[ ]　で括られた表記法ですね。

一般的に「人間が読みやすく、機械が解析しやすい（プログラムで読み取り易い）」という特徴を持ちます。

IAMポリシーの基本構成は以下になります。

これらの基本構成を適切に記載することで、ただしく権限を定義することが可能です。
具体的にAWSが管理している「AdministratorAccess」のポリシーを見てみましょう。

こんな感じです。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "*",
			"Resource": "*"
		}
	]
}

{
	"Version": "2012-10-17",
	"Statement": [
		…
	]
}	   

この表記についてはそういう決まりになっています。特に気にしないようにしましょう。
（変更するとエラーになっちゃいます。）

「AdministratorAccess」の場合、Effectが「許可」、Actionが「全て」、Resourceが「全て」となっているため、「全てのサービスに対し、全てのアクションが許可」という意味になります。
要するに「全ての操作を可能」ということです。

ActionやResourceを制限したい場合、必要なAction、必要なResourceのみを記載すればよいという形になります。
いきなり記載するのは難しいと思うので、まずはgoogle等で実現したい機能を検索して見てください。一応、良く使われるであろうポリシーはページの最後に載せておきますので見てみてください。

なお、「それでも自分で権限を作成したい」という方はマネジメントコンソールの「ポリシーエディタ」を利用すると意外と簡単に権限設定が出来かもしれません。

ポリシーエディタはマネジメントコンソールで「IAMポリシーの作成」をクリックすると出てくる画面です。

■ポリシーエディタの画面

ポリシーエディタでポリシーを作成する人はいないと思いますが、サービスに対し（例えばRDS）、どのような「アクション」があるのかな、というのを調べるのはとても便利です。

上記は、RDSのアクションですが、「書き込み権限ってどんな権限があるのだろう」というのを一覧で確認できます。

例えば、「RDSのバックアップだけを取る権限を定義したい」という場合、この一覧で調べると「CreateDBSnapshot」がそれに該当することが分かります。（実際にはそれっぽいなと思うのをgoogle先生にあってるかどうか確認してください）

そのうえで「特定の対象だけバックアップが取りたい」という場合、Condition句で制限を加えるというような形でポリシーを作っていく。というのが一般的なやり方になります。

IAMポリシーの注意点

IAMユーザ、並びにIAMロールに割り当てるIAMポリシーですが、いくつか注意点があります。

1つずつ説明していきましょう。

1.許可より、拒否が優先される

IAMのポリシーについては、「許可」より「拒否」が優先されます。
具体的には「PowerUserAccess」の権限をつけていても、EC2のアクションをdenyするポリシーがついていた場合は、EC2の操作が実施できません。

そのため、特定のIPアドレスからのみ操作を許可したいという場合、「特定のIPのみ許可する」ではなく「特定の条件のみDenyを有効としない」というポリシーを適用するのが有用です。（Administrator権限 + この権限を付与することでやりたいことを実現する）

こんな感じですね。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowRestriction",
			"Action": [
				"*"
			],
			"Effect": "Deny",
			"Resource": [
				"*"
			],
			"Condition": {
				"NotIpAddress": {
					"aws:SourceIp": [
						"xx.xx.xx.xx/xx",
						"xx.xx.xx.xx/xx"
					]
				}
			}
		}
	]
}		

このポリシーは「Condition」にて、
「NotIpAddress（このIPを除く）」と指定することで、逆説的に「それ以外のIPから全ての操作をDenyする」
という事を実現しています。

IAMポリシーではあまりDenyを使う事は少ないかもしれませんが、SCP（サービスコントロールポリシー）で全体的に統制をかけたい（制約を守らせたい）という時には非常に重要な考え方になります。

2.Condition句の利用について制限がある

Condition句で制限を掛けられるものは、「グローバル条件コンテキストキーまたはサービス固有のコンテキストキー」のみとなります。

詳細はこちら
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html

グローバル条件コンテキストキーの詳細はこちら
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html

サービス固有のコンテキストキーの詳細はこちら
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html

ちょっと上記のドキュメントを見ても意味が分からないと思うので、EC2を例にとるとこんな感じです。

■特定のタグがあるもののみ操作が可能なポリシーを定義できるかどうかの例

上記の表を見てもらうと分かりますが、結構制限できないことが分かるかと思います。

Condition句を利用する際は、必ずテストして制限がかかることを確認してください。（よく使うIAMポリシー例を載せておきますので、参考にしてみてください。というかこれに載っていないものは結構難しいと思って貰って良いかと思います。後、需要が無いです）

だいぶ長くなってしまったので、前編、後編に分けたいと思います。
という訳で、「いまさら聞けないIAMのお話し　その①」としては以上としたいと思います。

続きは「いまさら聞けないIAMのお話し　その②」でお話ししたいと思います。

あと残っているのはこんな感じですかね。

このブログに書いてあることを「全部知ってるよ。簡単すぎー」という方は「IAM結構知ってるんだぜ」と言ってもいいかもしれません。

多分、

・AWS Certified Solutions Architect – Professional
・AWS Certified Security – Specialty

のAWS資格の問題は解けるレベルだとは思います。自信を持ちましょう。

という訳で「いまさら聞けないIAMのお話し　その②」に続きます。

【おまけ】よく使うIAMポリシー例

■IAMユーザにMFAが適用されていないと全ての操作が出来なくなるIAMポリシー（MFA未設定時はMFAの設定のみ可能）

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowViewAccountInfo",
			"Effect": "Allow",
			"Action": [
				"iam:GetAccountPasswordPolicy",
				"iam:ListVirtualMFADevices"
			],
			"Resource": "*"
		},
		{
			"Sid": "AllowManageOwnPasswords",
			"Effect": "Allow",
			"Action": [
				"iam:ChangePassword",
				"iam:GetUser"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "AllowManageOwnAccessKeys",
			"Effect": "Allow",
			"Action": [
				"iam:CreateAccessKey",
				"iam:DeleteAccessKey",
				"iam:ListAccessKeys",
				"iam:UpdateAccessKey"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "AllowManageOwnSigningCertificates",
			"Effect": "Allow",
			"Action": [
				"iam:DeleteSigningCertificate",
				"iam:ListSigningCertificates",
				"iam:UpdateSigningCertificate",
				"iam:UploadSigningCertificate"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "AllowManageOwnSSHPublicKeys",
			"Effect": "Allow",
			"Action": [
				"iam:DeleteSSHPublicKey",
				"iam:GetSSHPublicKey",
				"iam:ListSSHPublicKeys",
				"iam:UpdateSSHPublicKey",
				"iam:UploadSSHPublicKey"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "AllowManageOwnGitCredentials",
			"Effect": "Allow",
			"Action": [
				"iam:CreateServiceSpecificCredential",
				"iam:DeleteServiceSpecificCredential",
				"iam:ListServiceSpecificCredentials",
				"iam:ResetServiceSpecificCredential",
				"iam:UpdateServiceSpecificCredential"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "AllowManageOwnVirtualMFADevice",
			"Effect": "Allow",
			"Action": [
				"iam:CreateVirtualMFADevice",
				"iam:DeleteVirtualMFADevice"
			],
			"Resource": "arn:aws:iam::*:mfa/*"
		},
		{
			"Sid": "AllowManageOwnUserMFA",
			"Effect": "Allow",
			"Action": [
				"iam:DeactivateMFADevice",
				"iam:EnableMFADevice",
				"iam:ListMFADevices",
				"iam:ResyncMFADevice"
			],
			"Resource": "arn:aws:iam::*:user/${aws:username}"
		},
		{
			"Sid": "DenyAllExceptListedIfNoMFA",
			"Effect": "Deny",
			"NotAction": [
				"iam:CreateVirtualMFADevice",
				"iam:EnableMFADevice",
				"iam:GetUser",
				"iam:ListMFADevices",
				"iam:ListVirtualMFADevices",
				"iam:ResyncMFADevice",
				"sts:GetSessionToken"
			],
			"Resource": "*",
			"Condition": {
				"BoolIfExists": {
					"aws:MultiFactorAuthPresent": "false"
				}
			}
		}
	]
}

■特定のIPからのみ操作を可能とするIAMポリシー

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowRestriction",
			"Action": [
				"*"
			],
			"Effect": "Deny",
			"Resource": [
				"*"
			],
			"Condition": {
				"NotIpAddress": {
					"aws:SourceIp": [
						"xx.xx.xx.xx/xx",
						"xx.xx.xx.xx/xx"
					]
				}
			}
		}
	]
}

■特定のタグのついたEC2のみ停止、起動、再起動が可能なIAMポリシー

オンプレっぽく使いたいという場合、特定のサービスの特定の操作のみ許可したいという要望があるので、特定のタグが付いているリソースのみ操作可能というポリシーです。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "SystemIPStatus",
			"Action": [
			"ec2:Describe*",
			"cloudwatch:GetMetricStatistics",
			"cloudwatch:ListMetrics"
			],
			"Resource": [
			"*"
			],
			"Effect": "Allow"
		},
		{
			"Sid": "SystemIPOperation",
			"Action": [
			"ec2:StartInstances",
			"ec2:StopInstances",
			"ec2:RebootInstances"
			],
			"Condition": {
			"StringEquals": {
				"ec2:ResourceTag/タグ名": "タグ値"
			}
			},
			"Resource": [
			"*"
			],
			"Effect": "Allow"
		}
	]
}

■特定のタグが付いたRDSのメンテナスが可能

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": [
				"rds:Describe*",
				"rds:CreateDBSnapshot",
				"rds:CreateDBClusterSnapshot"
			],
			"Resource": "*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"rds:RebootDBInstance",
				"rds:ModifyDBInstance",
				"rds:StopDBInstance",
				"rds:StartDBInstance"
			],
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:ResourceTag/タグ名": "タグ値"
				}
			}
		},
		{
			"Effect": "Allow",
			"Action": "rds:ModifyDBParameterGroup",
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"rds:pg-tag/タグ名": "タグ値"
				}
			}
		}
	]
}

■特定のタグが付いたELBのメンテナスが可能

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "ELBModify",
			"Effect": "Allow",
			"Action": [
				"elasticloadbalancing:RegisterTargets",
				"elasticloadbalancing:DeregisterTargets",
				"elasticloadbalancing:ModifyTargetGroupAttributes",
				"elasticloadbalancing:ModifyTargetGroup"
			],
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:ResourceTag/タグ名": "タグ値"
				}
			}
		},
		{
			"Sid": "ELBTargetGroup",
			"Effect": "Allow",
			"Action": [
				"elasticloadbalancing:DescribeTargetGroupAttributes",
				"elasticloadbalancing:DescribeTags"
			],
			"Resource": "*"
		}
	]
}

■特定のS3のみ操作（閲覧、ファイルのアップロードなど）可能

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "S3ListUp",
			"Effect": "Allow",
			"Action": [
				"s3:ListAllMyBuckets",
				"s3:GetBucketLocation"
			],
			"Resource": "arn:aws:s3:::*"
		},
		{
			"Sid": "S3FullAccessBucket",
			"Action": "*",
			"Effect": "Allow",
			"Resource": [
				"arn:aws:s3:::バケット名",
				"arn:aws:s3:::バケット名/*"
			]
		}
	]
}

お問い合わせ

【著者プロフィール】

園田　一史（そのだ　かずし）

伊藤忠テクノソリューションズ株式会社　クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS（キュービック オン エーダブリューエス）」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年～2025年APN Ambassadorに選任。