トップ > IAM > 【入門編】IAMポリシー設計のポイントを整理してみる

【入門編】IAMポリシー設計のポイントを整理してみる

IAM 基礎から学ぶ 認証・認可
記事タイトルとURLをコピーする

週1回のサウナが習慣になったCI部1課の山﨑です。

今回はIAMポリシー設計のポイントを考えて整理してみました。

はじめに

AWSにおいて認証・認可（権限の付与）を司るサービスと言えば IAM（Identity and Access Management）です。IAMではJSON形式でポリシーステートメントに具体的に許可したい操作、拒否したい操作を記述して認可（権限の付与）を行い、IAMユーザーやIAMロールに関連付けたりしてポリシーを適用します。今回は実際にポリシーを設計する際のポイントを考えて整理してみました。なおAWSが扱うポリシーはいくつかの種類と評価の優先順位があるため本ブログを読み始める前にまずは以下のブログをご覧頂くと理解がよりスムーズになります。

blog.serverworks.co.jp

IAMポリシーの基本

IAMポリシーの要素

IAMポリシーを構成する要素はいくつかありますが、まずは以下の5つの要素を押さえておけば基本的なIAMポリシーの記述内容を理解することができます。その他の要素については参考ドキュメントをご覧ください。

要素 説明
Sid 記述するポリシーの説明を記述し、他のポリシーとの区別する。
Effect 操作を許可(Allow)するか、拒否(Deny)するかを記述する。
Action 具体的な操作内容を記述する。
Resource ポリシーの適用範囲(どのAWSリソースに適用するか)を記述する。
Condition どういった条件下でポリシーを適用するのかを記述する。

※参考ドキュメント：IAM JSON ポリシーの要素のリファレンス - AWS Identity and Access Management

ポリシー例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2FullAccess",
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::123456789123:user/yamasaki-user"
            }
        }
    ]
}

上記のポリシー例の内容を咀嚼すると以下のようになります。

要素 説明
Sid EC2へのフルアクセス権限を付与するポリシーなので「EC2FullAccess」と記述する。
Effect 操作を許可(Allow)する。
Action EC2の全ての操作を。
Resource ポリシーの適用範囲(どのAWSリソースに適用するか)に制限は設けない。
Condition Account IDが123456789123のyamasaki-userというIAMユーザーが操作主体だったらポリシーを適用する。

IAMポリシーの基本については以下のブログもご参照ください。

blog.serverworks.co.jp

IAMポリシー設計のポイント

5Wで要件を整理する

以下の5Wで要件を整理することで定義すべきポリシーが可視化されます。

  • Who(何が)
    • ポリシーの適用主体
  • Where(何に対して)
    • Resource要素
  • When(どんな条件下で)
    • Condition要素
  • What(どんな操作を)
    • Action要素
  • Want(どうしたい)
    • Effect要素

ポリシーを関連付ける対象別に5Wを表で整理してみます。今回は利用頻度を考慮してIAM Permissions Boundary とセッションポリシーは対象から除外しました。

ポリシーの関連付け対象 Who(何が) Where(何に対して) When(どんな条件下で) What(どんな操作を) Want(どうしたい)
Organizations SCP ・メンバーアカウント
・OU内の全アカウント		 要定義 要定義 要定義 要定義(Allow or Deny)
リソースベースのポリシー 要定義 ポリシーを適用したAWSリソース
※AWSリソースを絞ることは可		 要定義 要定義 要定義(Allow or Deny)
IAMユーザー IAMユーザー 要定義 要定義 要定義 要定義(Allow or Deny)
IAMロール 要定義 要定義 要定義 要定義 要定義(Allow or Deny)

ポリシーを関連付ける対象によってはWho(何が)やWhere(何に対して)が決まっているので「要定義」と記載がある箇所について検討し、ポリシーを設計する必要があります。

Organizations SCP

Who(何が) Where(何に対して) When(どんな条件下で) What(どんな操作を) Want(どうしたい)
・メンバーアカウント
・OU内の全アカウント		 要定義 要定義 要定義 要定義(Allow or Deny)

Organizations SCP ではWho(何が)は決まっているので、残りは以下を設計すれば良さそうです。

  • Who(何が)
    • どのメンバーアカウント、どのOUに適用するのか
  • Where(何に対して)
    • Resource要素
  • When(どんな条件下で)
    • Condition要素
  • What(どんな操作を)
    • Action要素
  • Want(どうしたい)
    • Effect要素

Want(どうしたい) についてですが、AWSのIAMのベストプラクティス （最小権限の許可）にしたがって細かい制御を行うのは運用負荷が高いので、SCPでは許可したいことではなく、拒否させたいことを設計する方が良いと思います。

SCPについては以下のブログもご覧ください

blog.serverworks.co.jp

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

Who(何が) Where(何に対して) When(どんな条件下で) What(どんな操作を) Want(どうしたい)
要定義 ポリシーを適用したリソース 要定義 要定義 要定義(Allow or Deny)

リソースベースのポリシー ではWhere(何に対して) は決まっているので、残りは以下を設計すれば良さそうです。

  • Who(何が)
    • ポリシーの適用主体
  • Where(何に対して)
    • AWSリソースを絞ることが可能です。例えばS3のバケットポリシーであればS3のARNを使ってディレクトリパスのレベルでWhere(何に対して)を絞り込むことが可能です
  • When(どんな条件下で)
    • Condition要素
  • What(どんな操作を)
    • Action要素
  • Want(どうしたい)
    • Effect要素

Who(何が) についてですが、Principal というIAMポリシーの要素を利用することで指定することが可能です。例えば以下のポリシー例ではWho(何が) をCloudTrail に指定することでCloudTrail からsample-bucket/AWSLogs/123456789123/ 配下のディレクトリに対して書き込み許可を付与しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::sample-bucket/AWSLogs/123456789123/*"
        }
    ]
}

IAMユーザー

Who(何が) Where(何に対して) When(どんな条件下で) What(どんな操作を) Want(どうしたい)
IAMユーザー 要定義 要定義 要定義 要定義(Allow or Deny)

IAMユーザー ではWho(何が)は決まっているので、残りは以下を設計すれば良さそうです。

  • Who(何が)
    • どのIAMユーザーに適用するか
  • Where(何に対して)
    • Resource要素
  • When(どんな条件下で)
    • Condition要素
  • What(どんな操作を)
    • Action要素
  • Want(どうしたい)
    • Effect要素

IAMエンティティに対して適用するポリシーに対して、AWSは予めよく利用するであろうポリシーをAWS管理ポリシーとしてパッケージ化して用意してくれています。管理ポリシーを含めポリシーは以下の3つに分類することができます。

ポリシー分類 説明
AWS管理ポリシー AWSが用意しているポリシー群で複数のIAMエンティティで再利用可能。ユーザーによる編集は不可。
カスタマー管理ポリシー ユーザーが作成するポリシー群で複数のIAMエンティティで再利用可能。ユーザーによる編集は可能。
インラインポリシー 各IAMエンティティ固有のポリシー群。再利用不可。ユーザーによる編集は可能。

IAMロール

Who(何が) Where(何に対して) When(どんな条件下で) What(どんな操作を) Want(どうしたい)
要定義 要定義 要定義 要定義 要定義(Allow or Deny)

IAMロールはこれまでのポリシーの関連付け対象とは異なり5Wの全てをイチから定義する必要があります。

  • Who(何が)
    • ポリシーの適用主体
  • Where(何に対して)
    • Resource要素
  • When(どんな条件下で)
    • Condition要素
  • What(どんな操作を)
    • Action要素
  • Want(どうしたい)
    • Effect要素

Who(何が) についてですが、IAMロールでこれを定義するのはポリシーステートメント内ではなく信頼関係です。

f:id:swx-yamasaki:20210922125842p:plain
IAMロール - 信頼関係 -

信頼関係では以下のようにしてIAMロールのWho(何が) を定義します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAMロールはAWS Security Token Service (AWS STS) というサービスを利用して一時的な認証情報を得ることで、IAMロールを関連付けた対象に対してIAMポリシーのポリシーステートメントに記載された権限を一時的に付与することができます。そのためAction要素にはSTSに関する操作を記述しています。この信頼関係の記述はリソースベースのポリシーに分類されるポリシーです。

上述の信頼関係のポリシーステートメントではEC2サービスをIAMロールのWho(何が) として定義しています。このIAMロールをEC2に関連付けることによってEC2はポリシーステートメント内の権限を利用することが可能になります。

まとめ

今回はIAMポリシー設計のポイントを考えて整理してみたが、5Wに従って要件を1つずつ整理していくと設計がよりスムーズになるのではないかと思いました。当ブログが皆様のお役に立てれば幸いです。

山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ

2019/12〜2023/2までクラウドインテグレーション部でお客様のAWS導入支援を行っていました。現在はIE（インターナルエデュケーション）課にて採用周りのお手伝いや新卒/中途オンボーディングの業務をしています。2023 Japan AWS Top Engineers/2023 Japan AWS Ambassadors