AWS入門：ロールとポリシーの違い

スポンサーリンク
AWS入門：ロールとポリシーの違い 用語解説
AWS入門：ロールとポリシーの違い
この記事は約7分で読めます。
よっしー
よっしー

こんにちは。よっしーです(^^)

今日は、ロールとポリシーの違いについて解説しています。

スポンサーリンク

背景

ロールとポリシーの違いについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。

ロールとポリシーの違い

AWSにおけるロール(Role)とポリシー(Policy)の違いは以下の通りです。

ロール(Role)

  • ロールは一種の権限の入れ物のような存在です
  • IAMリソース(ユーザー、アプリケーション、AWSサービスなど)に対する一定の権限をロールに付与できます
  • それ自体では特定の権限は持たず、ポリシーをアタッチすることで権限が付与されます

ポリシー(Policy)

  • ポリシーは具体的なアクセス許可や拒否の規則を定義するJSONドキュメントです
  • リソースへのアクセスを許可する操作や、アクセス対象のリソースなどを指定します
  • ポリシーをIAMロール、ユーザー、グループにアタッチすることで権限が付与されます

簡単に例えると、

  • ロールは「入れ物」
  • ポリシーは「中身」

に相当します。ロール単体では権限は持ちません。ポリシーをロールにアタッチすることで、そのロールに対して具体的な権限が与えられます。

例えば、S3バケットへの読み取りアクセスを与えるロールを作成したい場合:

  1. ロールを作成
  2. S3バケットの読み取り権限を定義したポリシーを作成
  3. 作成したポリシーをロールにアタッチ

とすることで、そのロールに対してS3読み取り権限が付与されます。このように、ロールとポリシーを使い分けることで、柔軟かつ詳細なアクセス権限の管理が可能になります。

使用例

AWS におけるロールとポリシーの具体的な使用例をいくつか挙げます。

1. EC2 インスタンスへの役割付与

EC2 インスタンスに一時的な認証情報を取得する権限を与えたい場合:

  • ロール: EC2インスタンスロール
  • ポリシー: AmazonEC2RoleforAWSCodeDeployRole (CodeDeployで使用)

このポリシーをEC2インスタンスロールにアタッチすることで、そのロールを持つEC2インスタンスは一時的な認証情報を取得でき、CodeDeployを使ってアプリケーションのデプロイが可能になります。

2. AWS LambdaファンクションでS3バケットアクセスを許可

LambdaファンクションにS3バケットの読み書き権限を与えたい場合:

  • ロール: LambdaS3アクセス用ロール
  • ポリシー: AmazonS3ReadOnlyAccess (読み取り) / AmazonS3FullAccess (読み書き)

作成したロールにS3の読み取りまたは書き込みポリシーをアタッチすることで、そのロールを使ったLambdaファンクションがS3バケットにアクセスできるようになります。

3. AWSサービス間の役割付与

AWS CodePipelineで AWS CodeBuildを実行するには:

  • ロール: CodePipeline用ロール
  • ポリシー: CodePipelineAccessRole

CodePipelineがCodeBuildを実行するためには、このロールとアクセス権限が必要です。CodePipelineにロールを割り当て、そのロールにCodeBuildの実行権限を付与したポリシーをアタッチします。

4. マネージドポリシーの利用

AWS が用意した事前定義されたポリシーをロールやユーザーにアタッチする例:

  • マネージドポリシー: AmazonS3ReadOnlyAccess
  • ロール: S3ReadOnlyRole

AmazonS3ReadOnlyAccessポリシーをS3ReadOnlyRoleにアタッチすれば、そのロールに対してS3の読み取りのみの権限が付与されます。

このように、ロールにはリソースやサービスの実行権限を与え、ポリシーでは具体的なアクセス許可を定義することで、セキュアで詳細な権限管理が可能になります。

ポリシーとは

AWSにおけるポリシー(Policy)とは、AWSリソースへのアクセス許可や拒否を定義するための規則のセットです。ポリシーはJSON形式で記述され、以下の3つの主要要素で構成されています。

  1. Effect – アクセスを許可するか拒否するかを指定します。値は”Allow”または”Deny”です。
  2. Action – 許可または拒否する操作を指定します。例えば”s3:GetObject”などのAPIアクションが該当します。
  3. Resource – アクセスの対象となるリソースを指定します。ARNなどでリソースを特定します。

また、ポリシーには以下の2種類があります。

1. マネージドポリシー

  • AWS側で作成・維持される事前定義されたポリシー
  • AmazonS3ReadOnlyAccessなど、一般的なユースケースをカバー
  • そのままロール/ユーザーにアタッチして利用可能

2. カスタマーマネージドポリシー

  • ユーザー側で作成・管理するポリシー
  • 組織固有の要件に合わせてカスタマイズ可能
  • JSON形式で自由にアクセス許可を定義

ポリシーは、IAMロール、ユーザー、グループにアタッチすることで、そのエンティティに対する権限を付与します。ロールとの組み合わせによって、必要最小限の権限だけを一時的に付与できるため、最小特権のアクセス制御が可能になります。

例えば、特定のS3バケットへの読み取り専用アクセスを許可するポリシーは以下のように定義できます。

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

このようにポリシーを使うことで、細かくアクセス制御ができ、最小特権の原則に基づくセキュリティ対策が可能になります。

ロールとは

AWSにおけるロール(Role)は、特定のタスクを実行する権限を一時的に付与するための認証エンティティです。ロール自体は認証情報を持たず、ロールに付与されたポリシーに基づいて権限が定義されます。

ロールの主な特徴と使用例は以下の通りです。

ロールの特徴

  • 一時的なセキュリティ認証情報を持つ
  • ポリシーをアタッチして権限を定義する
  • 特定のAWSリソース(EC2、Lambda、CodeBuildなど)に関連付けて使用する
  • リソースの実行時にのみ、ロールを引き受けてタスクを実行する

ロールの使用例

  1. EC2インスタンスロール
  • EC2インスタンスにロールを割り当て、一時的な認証情報を取得できるようにする
  • S3バケットへのアクセス権限などを付与できる
  1. AWS Lambda実行ロール
  • LambdaファンクションにロールをアタッチしてS3やDynamoDBなどへのアクセス権限を与える
  1. AWSサービスリソース間のロール
  • CodePipelineが他のAWSサービス(CodeBuild、ECS)を呼び出せるようにするロール
  1. フェデレーテッドユーザーのロール
  • 企業のディレクトリサービス(ADなど)と統合し、フェデレーテッドユーザーにAWSリソースへのアクセス許可を与えるロール
  1. クロスアカウントアクセスのロール
  • 別のAWSアカウントのリソースにアクセスするための、信頼されたアカウント用ロール

ロールを使うことで、IAMユーザーや実行する側のリソースに直接アクセス権を与えずに、必要最小限の権限だけを一時的に付与できます。これによりセキュリティリスクを最小限に抑えつつ、柔軟なアクセス制御が可能になります。

おわりに

今日は、 ロールとポリシーの違いについて解説しました。

よっしー
よっしー

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。

それでは、また明日お会いしましょう(^^)

コメント

タイトルとURLをコピーしました