記事公開日 2026/06/08

AWS初心者が最初に知るべき「IAMポリシー」の読み方と、安全運用の第一歩

AWS IAM

目次

はじめに
基本要素：「IAM User」「IAM Role」「IAM Policy」の違い
暗号じゃない！IAMポリシー（JSON）の解剖図
初心者は自分で作らなくてOK！「AWS管理ポリシー」の探し方
安全運用のための「最小権限の原則」とは？
まとめ

はじめに

こんにちは。DXソリューション営業本部の佐藤です。

AWSのアカウントを運用する上で安全に、そしてスマートに使いこなすための第一歩が「IAM（Identity and Access Management：アイアム）」という仕組みです。
今回は、「これだけ読めばIAMポリシーの正体がわかる」というポイントを、初心者目線で分かりやすく整理しました！

基本要素：「IAM User」「IAM Role」「IAM Policy」の違い

ブログのテーマである「IAMポリシー」をより深く理解するために、まずはセットでよく登場する3つの言葉の違いを整理してみましょう。

IAM User（ユーザー）： 日常の作業を行う「社員（人）」です。
- ※現在のAWSでは、セキュリティ（マルチアカウント運用）の観点から、人を直接IAMユーザーに紐付けるのではなく、「IAM Identity Center（IdC）」という機能を使ってログイン権限を集中管理する方法が推奨されています。
IAM Role（ロール）： 一時的に変身する「役職」です。サーバー（EC2）などが他のサービスを操作するときにこの役割になります。
IAM Policy（ポリシー）： 今回の主役である、何をして良いかが書かれた「許可証」です。

「新しく作ったIAM UserやIAM Roleに、この『IAMポリシー（許可証）』を貼り付けて権限を渡す」のが、AWS運用の基本になります。

暗号じゃない！IAMポリシー（JSON）の解剖図

IAMユーザーを作ったら、次に「そのユーザーに何を許可するか」を決めます。その許可証になるのが「IAMポリシー」です。

真ん中の3行だけ英語のパズルだと思って読んでみてください。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

① Effect（効果）： 「していいよ（Allow）」か「ダメ（Deny）」か。
② Action（行動）： 具体的に何を？ s3:GetObject は「S3のファイルをダウンロードする」という意味です。
③ Resource（対象）： どこの場所で？ここでは my-bucket-name という名前のS3バケットの中身すべて（/*）を指定しています。

これらをつなげて日本語に翻訳すると、「指定したS3バケットのファイルを、ダウンロードしても良い」と言う内容になります。そう思うと、意外とシンプルに見えてきませんか？

初心者は自分で作らなくてOK！「AWS管理ポリシー」の探し方

最初からコードを書く必要は無く、AWSが最初から用意してくれている便利なテンプレート（AWS管理ポリシー）があります。

画面上のフィルターで「ポリシータイプ：AWS管理」にチェックを入れて、以下の代表的な3つの権限を探してみることから始めてみましょう。

AdministratorAccess（管理者権限）
- 特徴： AWSのほぼすべての操作ができる「何でも屋さん」。日常の検証用メインアカウントに付与します。
PowerUserAccess（開発者権限）
- 特徴： サーバー構築やデータベース操作など何でもできるけど、「他のユーザーの追加・削除（IAM操作）」だけはできない権限。実務で開発メンバーにアカウントを渡すときの定番です。
ReadOnlyAccess（閲覧専用権限）
- 特徴： 設定の変更や削除は一切できないけれど、画面を見る（閲覧する）ことだけはできる権限。「設定画面を確認したいだけ」の人や、まずは触って慣れたい新人に最適です。

検索窓に「S3」や「EC2」といったサービス名を入力して、これらの管理ポリシーを探す癖をつけるのがおすすめです。

安全運用のための「最小権限の原則」とは？

AWSの世界には、「最小権限の原則」という共通のルールがあります。これは「その人が行う作業に、必要最低限の権限だけを渡す」という考え方です。

新人にいきなり何でもできる AdministratorAccess を渡して、操作ミスで数百万の課金が発生したり、大事なデータが全削除されたりしたら大惨事になってしまいます。
だからこそ、ポリシーを使って「S3を見るだけ」「EC2を動かすだけ」と絞ることが重要なのです。

ユースケースとして、「AWSが用意してくれた管理ポリシーだけで、この最小権限は達成できるのか？」を考えてみました。

例えば、AmazonS3ReadOnlyAccess（S3の読み込み専用権限）という管理ポリシーをメンバーに渡した場合、そのメンバーは社内にあるすべてのS3バケット（データ置き場）を覗けるようになってしまいます。もし「特定のプロジェクトのバケットだけを見せたい」という場合は、先ほどのJSONコードの Resource の部分を、以下のように特定のバケット名に書き換えた「カスタムポリシー」を作る必要があります。

"Resource": "arn:aws:s3:::a-project-bucket-name/*"

このように、管理ポリシーで大まかな権限を与えつつ、必要に応じてピンポイントにリソースを絞り込めるようになると、実務や資格試験でも役立つセキュリティの理解につながります！

まとめ

難しそうに見えるAWSのセキュリティですが、まずは以下のステップを意識するだけで安全性が大きく上がります。

User / Role / Policyの役割の違いを理解する
日常のアクセスは、現在の主流であるIAM Identity Center（IdC）を活用する
AWS管理ポリシーの探し方を覚え、慣れてきたらリソースを絞った「最小権限」を意識してみる

今回は、サーバーやデータベースを構築する前段階の「基本のキ」をお届けしました。
AWSのサービスは細かいですが、このように文字に起こすだけでも自分の理解へつながるので今後もブログとしてナレッジにできればと思います。

もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問い合わせフォームまでお気軽にご連絡ください。複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞

AWS導入・コスト最適化支援

AWS高速PoC支援

弊社AWS関連ブログ

＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞

ASC-J ホワイトペーパー

※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。