Harmonic Society
オンライン予約 お問い合わせ
プログラミング

AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法

kento_morota 16分で読めます

「AWSアカウントのセキュリティが不安」「誰がどの権限を持っているか把握できていない」――AWS利用において、IAM（Identity and Access Management）の適切な設計は、セキュリティの土台となる最も重要な要素です。

この記事では、AWS IAMの最小権限の原則を実務で実装するための具体的な手順を解説します。ポリシーの設計方法からロール管理、MFA設定まで、中小企業のIT担当者がすぐに実践できる内容をお届けします。

AWS IAMとは？認証と認可の基本を理解する

AWS IAM（Identity and Access Management）は、AWSリソースへのアクセスを安全に管理するためのサービスです。「誰が」「何に」「どのような操作を」行えるかを制御する、AWSセキュリティの根幹をなす仕組みです。

認証（Authentication）と認可（Authorization）の違い

IAMを理解するうえで、まず認証と認可の違いを明確にしておきましょう。

概念 意味 IAMでの実現方法
認証（Authentication） 「あなたは誰か？」を確認する ユーザー名/パスワード、アクセスキー、MFA
認可（Authorization） 「何をしてよいか？」を制御する IAMポリシーによる権限の付与

IAMの主要コンポーネント

IAMは以下の4つの主要コンポーネントで構成されています。

  • IAMユーザー：個人に紐づくアカウント。コンソールログインやAPIアクセスに使用
  • IAMグループ：ユーザーをまとめて管理する単位。グループにポリシーを付与すると所属ユーザー全員に適用
  • IAMロール：AWSサービスや外部アカウントに一時的な権限を付与する仕組み
  • IAMポリシー：アクセス許可のルールを定義するJSON形式のドキュメント

ルートユーザーの保護｜最初にやるべき設定

AWSアカウントを作成した直後に絶対にやるべきのが、ルートユーザーの保護です。ルートユーザーはアカウントのすべてのリソースに対して無制限のアクセス権を持つため、万一乗っ取られると壊滅的な被害を受けます。

ルートユーザー保護の手順

手順1：MFA（多要素認証）を有効にする

  1. AWSマネジメントコンソールにルートユーザーでログイン
  2. 右上のアカウント名をクリックし「セキュリティ認証情報」を選択
  3. 「多要素認証（MFA）」セクションで「MFAデバイスの割り当て」をクリック
  4. ハードウェアMFAキーまたは認証アプリ（Google Authenticator等）を登録

手順2：ルートユーザーのアクセスキーを削除する

# ルートユーザーのアクセスキーが存在するか確認
# コンソールの「セキュリティ認証情報」から確認し、存在する場合は即座に削除

# アクセスキーの使用状況を確認する（IAMユーザーのキー）
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

手順3：日常業務ではルートユーザーを使用しない

管理者用のIAMユーザーを作成し、日常的な作業はそちらで行います。ルートユーザーが必要な操作は、請求設定の変更やアカウントの解約など、ごく限られたケースのみです。

最小権限の原則を実装する具体的な方法

最小権限の原則（Principle of Least Privilege）とは、「業務に必要な最小限の権限だけを付与する」という考え方です。これはIAM運用の最も重要な原則ですが、実務で実装するのが最も難しい部分でもあります。

ステップ1：まずAWS管理ポリシーで始める

最初からカスタムポリシーを作成するのは困難です。まずはAWSが用意する管理ポリシーから始め、段階的に絞り込んでいきましょう。

# 開発者に付与する管理ポリシーの例
aws iam attach-user-policy \
  --user-name developer01 \
  --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

ただし、PowerUserAccessはIAM以外のほぼすべてのサービスにアクセスできる強力な権限です。本番環境では使用を避け、開発・検証環境での一時的な利用に限定してください。

ステップ2：IAM Access Analyzerで実際の使用状況を把握する

最小権限を実現するには、実際に使用されている権限を把握する必要があります。IAM Access Analyzerのポリシー生成機能を使えば、CloudTrailのログに基づいて必要最小限のポリシーを自動生成できます。

# Access Analyzerのアナライザーを作成
aws accessanalyzer create-analyzer \
  --analyzer-name my-account-analyzer \
  --type ACCOUNT

# ポリシー生成を開始（90日間のCloudTrailログを分析）
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789012:user/developer01"
  }'

ステップ3：カスタムポリシーを作成する

Access Analyzerの結果をもとに、カスタムポリシーを作成します。以下は、特定のS3バケットに対する読み取り専用アクセスを許可するポリシーの例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mycompany-prod-assets-ap-northeast-1",
        "arn:aws:s3:::mycompany-prod-assets-ap-northeast-1/*"
      ]
    },
    {
      "Sid": "AllowLambdaReadOnly",
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:ListFunctions",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:iam::123456789012:function:mycompany-prod-*"
    }
  ]
}

ポリシー設計のポイントは以下の通りです。

  • Resourceを具体的に指定する："*"（全リソース）は避け、対象のARNを明示する
  • Actionを限定する："s3:*"ではなく、必要な操作のみをリストアップする
  • Conditionで追加制限をかける：IPアドレスや時間帯での制限が可能

S3のアクセス制御の詳細については、AWS S3の実務活用ガイドも参考にしてください。

IAMロールの活用｜アクセスキーをなくす運用

IAM運用で最も重要な方針は、可能な限りアクセスキーを使わず、IAMロールで権限を管理することです。アクセスキーは漏洩リスクが高く、管理コストも大きいため、IAMロールへの移行を強く推奨します。

EC2インスタンスにIAMロールを付与する

EC2インスタンス上でAWSサービスにアクセスする場合、アクセスキーをインスタンス内に保存するのは絶対に避けるべきです。代わりに、インスタンスプロファイルを通じてIAMロールを付与します。

# IAMロールを作成
aws iam create-role \
  --role-name EC2-S3-ReadOnly \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "ec2.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }'

# ポリシーをアタッチ
aws iam attach-role-policy \
  --role-name EC2-S3-ReadOnly \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# インスタンスプロファイルを作成・関連付け
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile \
  --role-name EC2-S3-ReadOnly

Lambda関数にIAMロールを付与する

AWS Lambdaでは、関数ごとに実行ロールを設定します。関数が必要とする最小限の権限をロールに付与しましょう。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::mycompany-prod-assets-ap-northeast-1/*"
    }
  ]
}

クロスアカウントアクセスのロール設計

複数のAWSアカウント（本番・検証・開発）を運用している場合、クロスアカウントのIAMロールを使ってアクセスを管理します。

# 本番アカウント側：検証アカウントからのAssumeRoleを許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

この設定では、MFA認証済みの場合のみクロスアカウントアクセスを許可しています。

MFA（多要素認証）の全社導入

MFAは、パスワードが漏洩した場合でも不正アクセスを防ぐ最も効果的な対策です。すべてのIAMユーザーにMFAを強制しましょう。

MFAを強制するIAMポリシー

以下のポリシーを全ユーザーに付与すると、MFA未認証の状態ではほぼすべての操作が拒否されます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnMFA",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:ListMFADevices"
      ],
      "Resource": [
        "arn:aws:iam::*:mfa/${aws:username}",
        "arn:aws:iam::*:user/${aws:username}"
      ]
    },
    {
      "Sid": "DenyAllExceptMFASignIn",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

このポリシーにより、ユーザーはまずMFAを設定し、MFA認証を完了してからでなければ他の操作ができなくなります。

IAM運用の自動化と監査

IAMの設定は一度作って終わりではありません。継続的な監査と改善が必要です。

未使用の認証情報を定期的にクリーンアップする

# 認証情報レポートを生成
aws iam generate-credential-report

# レポートをダウンロードして確認
aws iam get-credential-report --output text --query Content | base64 --decode > credential-report.csv

認証情報レポートでは、以下の項目をチェックしましょう。

  • 90日以上パスワードが使用されていないユーザー：無効化を検討
  • 90日以上アクセスキーが使用されていないキー：削除を検討
  • MFAが未設定のユーザー：即座に設定を依頼
  • 複数のアクセスキーを持つユーザー：不要なキーを削除

AWS CloudTrailによる監査ログ

CloudTrailを有効にすると、すべてのAPI呼び出しが記録されます。「誰が」「いつ」「何をしたか」を追跡できるため、セキュリティインシデントの調査に不可欠です。

# CloudTrailの証跡を確認
aws cloudtrail describe-trails

# 最近のIAM関連イベントを確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=iam.amazonaws.com \
  --max-results 10

Terraformによるコード管理

IAMポリシーやロールの定義は、TerraformなどのIaCツールで管理することを強く推奨します。コードで管理することで、変更履歴の追跡やレビュープロセスの組み込みが可能になります。

# Terraform でIAMロールを定義する例
resource "aws_iam_role" "lambda_execution" {
  name = "lambda-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_execution.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

実務で使えるIAM設計パターン

中小企業でよくある組織構成に合わせた、IAM設計パターンを紹介します。

パターン1：少人数チーム（5名以下）

グループ名 対象者 付与するポリシー
Administrators IT管理者（1〜2名） AdministratorAccess
Developers 開発者 カスタム開発者ポリシー
ReadOnly 閲覧のみ必要な担当者 ReadOnlyAccess

パターン2：部門別管理（10名以上）

グループ名 対象者 主な権限
InfraAdmins インフラ管理者 VPC、EC2、RDSの管理
AppDevelopers アプリ開発者 Lambda、S3、DynamoDBの利用
DataEngineers データ分析担当 S3（読み取り）、Athena、Glueの利用
BillingViewers 経理・管理部門 請求情報の閲覧のみ

グループベースの管理により、人員の入れ替えがあってもグループの追加・削除だけで権限を管理できます。

まとめ｜IAMの基盤を固めてセキュアなAWS運用を実現する

AWS IAMはすべてのAWSサービスの土台となるセキュリティ基盤です。ここが崩れると、いくら他のサービスを正しく設定しても意味がありません。

本記事のポイントを振り返りましょう。

  • ルートユーザーの保護：MFA有効化、アクセスキー削除、日常利用の禁止
  • 最小権限の原則：Access Analyzerを活用し、実際の使用状況に基づいてポリシーを絞り込む
  • IAMロールの活用：アクセスキーをなくし、ロールベースの権限管理に移行する
  • MFAの全社導入：すべてのユーザーにMFAを強制するポリシーを適用する
  • 継続的な監査：認証情報レポートとCloudTrailで定期的にチェックする
  • コード管理：Terraformなどで変更履歴を追跡可能にする

IAMの基盤がしっかりしていれば、S3やECS/Fargate、RDSといったサービスも安心して利用できます。セキュリティは最初に投資すべき領域です。まずはルートユーザーの保護とMFAの有効化から始めてみてください。

#AWS#IAM#セキュリティ
共有:
無料メルマガ

週1回、最新の技術記事をお届け

AI・クラウド・開発の最新記事を毎週月曜にメールでお届けします。登録は無料、いつでも解除できます。

※ プライバシーポリシーに基づき管理します

関連記事

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説
AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド

AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド
AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化

AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化
AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術

AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術
AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド

AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド
AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング

AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング
AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践

AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践
AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成
AWS Well-Architected Frameworkの実践｜中小企業でも使える設計原則ガイド

AWS Well-Architected Frameworkの実践｜中小企業でも使える設計原則ガイド

AI活用のヒントをお探しですか？お気軽にご相談ください。

まずは話だけ聞いてもらう