AWS IAMポリシーを理解する

IAM

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、川原です。

AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。

ポリシーの基本

ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。
記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。

例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
このポリシーではS3のリソースに対する参照操作を許可しています。このポリシーをEC2インスタンスに関連づけると(正確にはIAMロールを経由して関連づける)、そのEC2インスタンス上のプログラム(AWS CLI、AWS SDKを利用したプログラム)から、S3リソースに対する参照操作(Get、List)が可能となります。

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

ポリシーの分類

ポリシーを分類すると以下のような感じになると思います、多分。
この全体感を理解するのが一番重要な気がします。

  1. ユーザーベースのポリシー
    • AWS管理ポリシー
    • カスタマー管理ポリシー
    • インラインポリシー
  2. リソースベースのポリシー
  3. IAM ロールの信頼ポリシー(別名:信頼関係?)

以下ではそれぞれのポリシーについて説明します。

ユーザーベースのポリシー

ユーザーベースのポリシーは、IAMユーザー、IAMグループ、IAMロールに関連づけるポリシーになります。

上の説明では、ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述する、と述べました。 しかし、このポシリーには「誰が」(つまり、操作する主体)の部分(ポリシーの記述項目で言うとPrincipal)は記述しません。 なぜならば、「誰が」は、記述するまでもなくポリシーを関連づけた先のIAMユーザー、IAMグループ、IAMロールになるからです。

上の例で示したAmazonS3ReadOnlyAccessポリシーはユーザーベースのポリシーですが、操作主体に対応するPrincipalは記述していません。 このポリシーを関連づけたIAMユーザー、IAMグループ、IAMロール(IAMロールをEC2インスタンスにアタッチした場合は、EC2インスタンス)が、「誰が」の部分に該当します。
なので、AmazonS3ReadOnlyAccessポリシーを関連づけたIAMユーザー(やIAMグループ、IAMロール)がS3リソースを参照できる、という事になります。

ユーザーベースのポリシーは作成者や管理方法の観点でさらに以下3つに分類できます。これらの差異の概要は以下表に記載した通りです。詳細は管理ポリシーとインラインポリシー をご参照ください(手抜。。。

# 分類名 概要
1 AWS管理ポリシー AWSが用意している再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
2 カスタマー管理ポリシー ユーザーが作成した再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
3 インラインポリシー 各IAMユーザー(やIAMグループ、IAMロール)専用にユーザーが個別作成するポリシー。

以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。アクセス許可タブでユーザーベースのポリシーの設定が行えます。

mod_スクリーンショット_2016-05-09_19_55_18

リソースベースのポリシー

リソースベースのポリシーはユーザーベースのポリシーと似ていますが、関連づける先がユーザーではなく「AWSサービス」であるという点が異なります。 (ざっくり言うと、操作する主体(≒ユーザー)ではなく、操作を行われるモノ(AWSリソース)に関連づけるポリシーです)
よく使われているリソースベースのポリシーは、S3のバケットポリシーと思います。

ポリシーの記述内容レベルでの違いは、操作主体を表すPrincipalの有無です。
ユーザーベースのポリシーの場合、「人(ユーザー、グループ、ロール)」に関連付けるので操作主体は「関連づけた先のユーザーやグループ、ロール」と暗黙的に決まりました。一方、リソースベースのポリシーは「モノ(AWSリソース)」に関連づけるので暗黙的には決まらず、「誰が」の部分にあたるPrincipalの記載が必要になります。

以下にS3のバケットポリシーの例を示します。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
    "Action": [
      "s3:PutObject",
      "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::example-bucket/*"
  }
}

この例では、「AWSアカウント:777788889999のIAMユーザー:bob」 が 「example-bucket S3バケット配下」に「操作:PutObject、PutObjectAcl」を「許可する」事を意味しています。

リソースベースのポリシーはS3等の一部のAWSサービスのみに対応しています。
対応しているAWSサービスは IAM と連携する AWS サービス の表において、「リソースベース」がYesになっている行です。
また、Principal に指定できる値については、この辺り をご参照ください。

IAMロールの信頼ポリシー

IAM ロールの信頼ポリシーは、AWSのドキュメントでは「信頼関係」と記載されている箇所もあります(実はこっちが正式名称??)。

このポリシーは上で紹介した2つのポリシーとは毛色が少し異なり、IAMロールの権限移譲操作に特化したポリシーになります。また、その名前の通り、ポリシーを関連づける先(対象)はIAMロールです。

ポリシーの記載内容をざっくり言うと、当該の信頼ポリシーを関連づけたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(を許可)する、ということを記述します。
うまく説明できていないと思うので、誤解を恐れずにもっとざっくり言うと、「信頼ポリシーを関連づけたIAMロール」に「Principal(主体者)」が(権限的に)なりすませる、ということです。

これ以上、一般論での説明は私には難しそうなので、例で説明します。
以下は信頼ポリシーの記述例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/bob""
      },
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
      "Action": "sts:AssumeRole",
    }
  ]
}

例えば、この信頼ポリシーをAWSアカウント:999988887777 の IAMロール:kawaharaに関連づけたとします。
すると、この場合、AWSアカウント:999988887777 の kawahara ロールの権限を、AWSアカウント:123456789012 の IAMユーザー:bob に謙譲許可すること1を意味します。つまり、IAMユーザー:bob は IAMロールkawaharaの持っている権限と同等の権限を保有することができます。
もし、IAMロール:kawahara がAWSアカウント:9999888777 配下のEC2インスタンスを起動する権限(この権限はユーザーベースのポリシーでIAMロールに関連づけている)を保有していれば、(AWSアカウント:123456789012の)IAMユーザー:bob も同様にAWSアカウント:999988887777配下のEC2インスタンスを起動できます2

以下のキャプチャは、マネジメントコンソールのIAMサービスの画面です。信頼関係タブで信頼ポリシーの設定が行えます。

mod_スクリーンショット_2016-05-09_19_05_45

mod_スクリーンショット_2016-05-09_19_06_06

まとめ

AWSではポリシーによりAWSリソースに対する操作権限を制御しています。
本ブログの内容が皆様の「AWS ポリシー」を理解する一助になれば何よりです。

参考情報

AWS再入門 AWS IAM (Identity and Access Management) 編

[AWS IAM] 経験者向けManaged Policy対応ガイド

IAM ポリシーエレメントの参照


  1. AWSの用語的には、AWSアカウント:123456789012 のIAMユーザー :bobが 999988887777 の IAMロール:kawaharaを引き受ける(AssumeRole)、と言う。 
  2. 正確には、IAMユーザー:bobが直接EC2インスタンスを起動できるわけではなく、IAMロール:kawahara にスイッチロール(kawaharaロール用のアクセストークン取得処理)した後に起動できるようになります。 

AWS Cloud Roadshow 2017 福岡