IAMエンティティ応用　IAMロール・ポリシーについて解説

本記事の目的

AWSのセキュリティを強化するための主要なサービスであるIAM（Identity and Access Management）には、多くのエンティティと概念が存在します。これらのエンティティの中でも、特に重要な「ロール」と「ポリシー」について、詳細に解説していくことが本記事の目的です。

前回、IAMエンティティの基本についての記事を公開しました。その中でユーザーやグループなどIAMの基本的なエンティティや、それらがどのように連携して機能するのかについて触れました。IAMの奥深い部分をより良く理解するためには、ロールとポリシーの知識がとても役立ちます。今回はこの2つのトピックを詳しく解説していきたいと思います。

前回の記事の振り返り

前回の記事では、IAMの基本的なエンティティ、すなわちユーザー、グループ、ロールについて概要を紹介しました。ユーザーはAWSリソースへのアクセスを持つエンティティ、グループは複数のユーザーをまとめるためのエンティティ、ロールは一時的なアクセス権を付与するためのエンティティとして紹介しました。

前回の内容を未読の方や、再度確認したい方は、こちらのリンクから詳細な記事をご覧いただけます。

https://envader.plus/article/246

IAMロールの深掘り

IAMロールとは？

IAMロールは、特定のAWSサービスやユーザーが一時的にAWSリソースにアクセスするための中継的な役割を果たします。IAMロールはアクセス許可を持ち、それを一時的に他のエンティティに"貸し出す"ことができます。直接アクセスキーを持たないエンティティでも、ロールを介して特定のリソースにアクセスすることが可能となります。

代表的な使用例

EC2インスタンス

EC2インスタンスがS3バケットや他のAWSリソースにアクセスする際、直接アクセスキーを持つことなく、IAMロールをアタッチすることで必要な権限を得ることができます。

Lambda

Lambda関数がRDSやDynamoDBテーブルなどのデータベースにアクセスする必要がある場合、関数にIAMロールを関連付けることで安全にアクセスすることが可能となります。

ロールのメリットとデメリット

メリット

• セキュリティの向上 アクセスキーを直接持たないため、キーの漏洩リスクが低減します。
• 柔軟なアクセス管理 ロールを介して一時的にアクセス権限を付与・変更することができるため、状況に応じた細やかなアクセス制御が可能です。

デメリット

• 設定の複雑さ IAMロールの設定や関連付け、ポリシーの適用など、初めての方には少々複雑に感じられるかもしれません。
• 適切なポリシーの選択が必要 ロールに適切なアクセス権限を持つポリシーを関連付ける必要があり、誤った設定はセキュリティリスクとなる可能性があります。

IAMポリシーの詳細

IAMポリシーは、AWSリソースへのアクセスを制御するためのドキュメントです。このセクションでは、IAMポリシーの種類やその構成、ベストプラクティスについて詳しく解説します。

マネージドポリシーとインラインポリシーの違い

マネージドポリシー

AWSが提供する既存のポリシーであり、複数のIAMエンティティ（ユーザー、グループ、ロール）に再利用可能です。公開されているものや、ユーザーがカスタムで作成したものが含まれます。

インラインポリシー

ユーザーが特定のIAMエンティティに直接関連付けるためのカスタムポリシーです。このポリシーは、関連付けられたエンティティにのみ適用され、再利用はできません。

JSON形式のポリシーの読み方と作成方法

IAMポリシーはJSON形式で記述されます。主要なキーには以下のようなものがあります。

• Effect：ポリシーが許可するか（"Allow"）、拒否するか（"Deny"）を指定します。
• Action：許可または拒否するアクションを指定します。例：s3:ListBucketやdynamodb:PutItemなど。
• Resource：アクションが適用されるリソースを指定します。例：特定のS3バケットやDynamoDBテーブルなど。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::example-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:us-west-1:123456789012:table/example-table"
    }
  ]
}

上記のサンプルポリシーでは、example-bucketというS3バケットのリストを表示する権限と、example-tableというDynamoDBテーブルにアイテムを追加する権限が許可されています。

ポリシーの書き方のベストプラクティス

最小権限の原則

必要最低限の権限のみを付与すること。これにより、不正なアクセスや誤操作のリスクを最小限に抑えることができます。

明確なリソースの指定

ポリシーでリソースを指定する際は、可能な限り具体的に指定すること。ワイルドカード（*）を使用する場合は注意が必要です。

IAMロールとポリシーのTerraformによるサンプルコード

Terraformは、AWSなどのクラウドプロバイダのリソースをコード化し、安定した環境を効率的にデプロイするためのツールです。以下は、Terraformを使用してIAMロールとポリシーを作成するサンプルコードです。

1. IAMポリシーの作成

resource "aws_iam_policy" "example" {
  name        = "ExamplePolicy"
  description = "My example policy description"
  
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action   = ["s3:ListBucket"],
        Effect   = "Allow",
        Resource = "arn:aws:s3:::example-bucket"
      }
    ]
  })
}

上記のコードは、S3のexample-bucketバケットの内容をリストする権限を持つIAMポリシーを作成します。

2. IAMロールの作成

resource "aws_iam_role" "example" {
  name = "ExampleRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Effect = "Allow",
        Sid    = ""
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "example-attach" {
  role       = aws_iam_role.example.name
  policy_arn = aws_iam_policy.example.arn
}

上記のコードは、EC2インスタンスがこのロールを引き受けることができるIAMロールを作成し、先に作成したIAMポリシーをそのロールにアタッチします。

これらのコードを適切な.tfファイル（例えばiam.tfなど）に配置し、terraform initおよびterraform applyを実行することで、IAMロールとポリシーをAWS上にデプロイできます。

IAMのベストプラクティス

AWSのIAMを効果的に使用するためのベストプラクティスを以下にまとめます。

最小権限の原則

セキュリティの基本的な考え方として、ユーザーやサービスに必要最低限の権限のみを付与する「最小権限の原則」があります。これにより、誤操作や不正アクセスによる損失を最小限に抑えることができます。

実践方法

ポリシーの作成方法

• AWSが提供するマネージドポリシーを活用する
• 必要な権限を個別に定義してカスタムポリシーを作成する

ポリシーの管理方法

• ポリシーのレビューを行う
• ポリシーを定期的に更新する

ルートユーザーの使用を避ける

AWSアカウントのルートユーザーは、AWSリソースに対する全ての権限を持っています。そのため、このユーザーの認証情報が漏洩すると、AWS環境に甚大なダメージが及ぶ可能性があります。

理由

• セキュリティ上のリスク

  • ルートユーザーは制限なく全ての操作ができるため、不正アクセス時のリスクが極大
  • 誤操作の可能性
  • 意図しない変更や削除が容易

• ルートユーザーの認証情報を複数人で共有するリスク

  • 共有しているうちの1人の認証情報が漏洩すると、AWSアカウントに甚大なダメージが及ぶ可能性

定期的なアクセス権限の見直し

組織の変更やプロジェクトの進行に伴い、IAMユーザーやロールの必要な権限は変わる可能性があります。そのため、定期的にアクセス権限の見直しを行うことが重要です。

重要性

• 不要な権限の削除によるセキュリティリスクの低減
  • 過去のプロジェクトや役割で付与された権限が現在も継続している場合、それを削除することでセキュリティリスクを低減
• 新しい権限の追加による作業効率の向上
  • 新しいプロジェクトやタスクのために新しい権限が必要になる場合があります。必要な権限を適切に追加することで、作業の効率を向上させることが可能

まとめ

AWSのIAMは、クラウドリソースの管理とセキュリティの強化に不可欠です。この記事では、IAMロール、ポリシー、そしてTerraformを使った適切な設定方法について学びました。IAMの設定は複雑であり、継続的な更新が求められますが、正しく適用することで、AWSの使用経験が向上します。これらの知識を活用し、より安全で効率的なAWS環境を追求しましょう。