0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@wakinoza

[AWS] Policy Generator の使い方

0
Last updated at Posted at 2026-03-19

はじめに

こんにちは。
プログラミング初心者wakinozaと申します。
勉強中に調べたことを記事にまとめています。

十分気をつけて執筆していますが、なにぶん初心者が書いた記事なので、理解が浅い点などあるかと思います。
間違い等あれば、指摘いただけると助かります。

記事を参考にされる方は、初心者の記事であることを念頭において、お読みいただけると幸いです。

記事のテーマ

  • AWS SAA取得のため、AWSの勉強をしています。
  • この記事では、IAMポリシーとPolicy Generatorについて紹介していきます。

目次

1. ルートユーザーとIAMユーザー
2. IAMポリシー
3. 管理ポリシー
4. Policy Generator
5. IAMグループとIAMロール

1. ルートユーザーとIAMユーザー

AWS(Amazon Web Services)を利用する場合、2種類のユーザーがあります。
「ルートユーザー」と「IAM（Identity and Access Management）ユーザー」です。

「IAM」は「アイアム」と呼称されるのが一般的です。

ルートユーザーは、AWSアカウント作成時に自動的に作成されるアカウントです。無制限の権限をもつ強力なユーザーですが、その反面、万が一ルートユーザーのパスワードが漏洩すると深刻なセキュリティ問題を起こすリスクがあります。
そのため、普段の作業は、ルートユーザーではなく、後述するIAMユーザーを利用します。ルートユーザーは、緊急時やルートユーザーでないとできない処理のみに利用します。

IAMユーザーは、AWSの作業用のユーザーです。
後述するIAMポリシーによって、AWSサービス上で何ができるかできないかを定めることができます。
しかし、すべてのIAMユーザーに最大権限を与えていては、ルートユーザーを利用しているときとセキュリティリスクは変わりません。

このようなセキュリティリスクを低減するため、AWSでは「最小権限の原則（Least Privilege）」に基づいた運用が推奨されています。
最小権限の原則とは、ユーザーやシステムに対して「その業務を遂行するために必要最低限の権限だけを与え、それ以外の権限は一切持たせない」というセキュリティ向上のための方針です。
IAMユーザーが不必要な権限を持たないことで、誤動作による事故を防ぎ、ユーザー情報が漏洩した場合の被害を最小限にとどめることができます。

2. IAMポリシー

IAMユーザーにどのような権限を持たせるのかを規定するのが「IAMポリシー」です。
IAMポリシーの実態は、アクセス許可の定義を行う「JSONドキュメント」です。

JSONドキュメントの例は、以下の通りです。

{
  "Version":"2012-10-17",
  "Statement":[
   {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
    }
  ]
}
項目 内容
Version ポリシー言語のバージョンを指定
Statement ひとかたまりの権限ルール
Effect Allow(許可)かDeny(拒否)か
Action 対象の操作
Resource 対象のリソース名

上記のJSONドキュメントは、特定のS3バケット（amzn-s3-demo-bucket）に対して、その中身をリスト表示する操作（s3:ListBucket）を許可する設定例です。

また、複数のStatementを記述することも可能です。
複数のStatementを作成する場合は、各Statementを識別するためのIDである「Sid」項目を指定する場合もあります。

3. 管理ポリシー

ポリシーを決める際に一からJSONドキュメントを書くのは手間なので、AWSにはよく使いそうなポリシーがあらかじめ用意されています。
これらのポリシーを「管理ポリシー」と言います。
管理ポリシーは、AWSが管理し、自動アップデートしています。
そのため、権限情報の仕様が変更になった場合も、開発者が修正する必要はありません。

管理ポリシーは、2026年3月時点で1400以上用意されています。
IAMポリシーを設定する場合は、まずこの管理ポリシーから用途に合うものを探しましょう。

用途に合うポリシーを探すコツは、「絞り込みタイプ」と「検索窓」を利用することです。

2026年3月時点では、管理ポリシーのコンソールには「絞り込みタイプ」として「AWS管理 ジョブ機能」と「AWS管理」の2種類があります。

「AWS管理 ジョブ機能」は、「データベース担当者」「運用担当者」など役割ごとに必要な権限をセットにしたものです。複数のサービスをまたぐ権限が設定されているため、新しいスタッフにまず基本的な権限を与えたい場合などに有用です。

「AWS管理」は特定のサービスに特化した権限です。サービス単位で権限を細かく制御したい場合に有用です。「AWS管理」は非常に多くの権限が用意されているため、検索窓に「サービス名」「操作名」を入れてさらに絞り込むことで、求める権限が見つけやすくなります。

4. Policy Generator

管理ポリシーで、望むポリシーが作れない場合は、ユーザーがポリシーを自作することも可能です。

自作する場合は、JSONドキュメントを作成することになるのですが、慣れないうちはハードルが高いでしょう。

そのような場合に有用なのが、「AWS Policy Generator」というサイトです。

AWS Policy Generator

Policy Generatorは、JSONファイル形式のポリシードキュメントを簡単に作成できるサイトです。

使い方を説明します。

4.1. Select policy type

まずstep1で、ポリシーの種類を指定します。
Policy Generatorでは、IAMポリシーのほかに、S3バケットポリシーや、VPCエンドポイントポリシーなども作成可能です。

タブから、作成したいポリシーの種類を選択してください。
今回は「IAMポリシー」を選択します。

slelctType.png.png

4.2. Add statement

step2で、権限ルールのセット（Statement）を設定します。

まずは、「Effect」欄で、「Allow（許可）」か「Deny（拒否）」かを選択してください。

次に、「AWS」で対象のリソースを選択してください。
全てのサービスが対象の場合は、「All Services」にチェックを入れてください。

リソースを選択すると、その下に「Actions」「Amazon Resource Name (ARN)」の選択欄が表示されます。

「Actions」欄で具体的な操作を、「Amazon Resource Name (ARN)」欄で対象とするリソースの名前を選択してください。
こちらも、全操作や全リソースが対象の場合は、「All Actions」や「All Resources」にチェックを入れてください。

以下の画像では、EC2インスタンスにおいて、インスタンスの閲覧・停止・再開を許可する権限を設定しています。
リソース名は指定せず、「All Resources」としています。

addStatement.png.png

権限を選択し終わったら、「Add Statement」をクリックしてください。
すると、選択した権限が一覧で表示されます。

statementAdded.png.png

4.3. Generate policy

一覧の権限に問題がない場合は、「Generate Policy」のボタンをクリックしてください。

すると、以下のようにポリシーを示すJSONドキュメントが表示されます。

policyJson.png.png

表示されたJSONドキュメントをコピーし、AWSコンソール「ポリシーの作成」のポリシーエディタにペーストしてください。

policyEdit.png.png

なお、「Sid」項目はPolicy Generatorでは指定できません。
Sidなどを指定したい場合は、ポリシーエディタにペーストしたのち、手動で書き替えてください。

5. IAMグループとIAMロール

IAMポリシーを用いて、ユーザーに権限を付与します。
しかし、複数のユーザーでAWSのサービスを利用する場合、ユーザーごとにIAMポリシーを付与するのは煩雑で、ミスの原因となります。

そのため、「IAMグループ」と「IAMロール」を利用した権限の運用が推奨されています。

IAMグループは、IAMポリシーを付与したグループです。個別のユーザーに権限を付与するのではなく、権限を付与したグループにユーザーを所属させることで、必要な権限をユーザーに付与します。実務では、開発者や運用者、システム管理者などの役割に応じたIAMグループを作成する運用が行われます。

ユーザーではなく、特定のリソースに別のリソースへの権限を付与したい場合は、IAMロールを用います。
IAMロールは、一時的に権限を借りたいサービスに貸し出される「役割」のようなものです。
IAMロールをEC2などのリソースに関連付けることで、そのリソースが他のAWSサービスに対して操作を実行できるようになります。

リソースに権限を与える他の手段として、アクセスキーを直接埋め込む手法も存在します。しかし、これには認証情報の漏洩や更新管理の不備といったセキュリティリスクが伴います。
IAMロールは、AWSが自動的に認証情報を発行しますが、短時間で無効になるため、永続的なアクセスキーよりも漏洩時のリスクが低く抑えられます。また、認証情報の更新はAWSが自動的に行ってくれるため、開発者がキーの管理を意識しなくて済みます。
したがって、AWSのベストプラクティスでは、永続的なアクセスキーの利用を避け、可能な限りIAMロールを活用することが推奨されています。

まとめ

  • 最小権限の原則: リスクを最小化するため、必要最低限の権限のみを付与する。

  • IAMポリシー: JSON形式で定義される権限の設計図。

  • 管理ポリシーとPolicy Generator: 既存のポリシーを活用しつつ、必要に応じてGeneratorで効率的に自作する。

  • グループとロールの使い分け:

    • IAMグループ: 「人（ユーザー）」を職能ごとにまとめて管理。

    • IAMロール: 「リソース」や「一時的なアクセス」に、安全な認証情報を割り当て。

記事は以上です。
最後までお読みいただき、ありがとうございました。

参考情報一覧

この記事は以下の情報を参考にして執筆しました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?