AWS IAMユーザーのセキュリティ実践ガイド
はじめに
AWS(Amazon Web Services)を利用するうえで、IAM(Identity and Access Management)ユーザーのセキュリティ設定は極めて重要です。
初期構築後に設定が不十分なまま運用を続けた結果、セキュリティインシデントが発生するケースも少なくありません。
この記事では、AWS公式が推奨するベストプラクティスに基づき、IAMユーザーのセキュリティ強化に必要な設定・運用ポイント、よくあるミスとその対策を紹介します。
初級〜中級のインフラ/アプリケーションエンジニアを対象に、実務で活用できる具体例を交えて解説します。
背景・前提知識
IAMとは?
IAM(Identity and Access Management)は、AWS上のリソースに対するアクセス制御を行うサービスです。IAMでは、ユーザー、グループ、ロール、ポリシーを用いて「誰が」「何を」「どこまで」できるかを細かく制御できます。
AWSでは「最小権限の原則(PoLP: Principle of Least Privilege)」を遵守することが強く推奨されており、必要最小限のアクセス権を付与することが基本です。
なぜIAMユーザーのセキュリティが重要か
AWSでは、ルートユーザーとは別にIAMユーザーを作成し、日常的な運用に利用するのが一般的です。しかし、IAMユーザーに過剰な権限を与えたり、MFA(多要素認証)などの保護が不十分であったりすると、重大なセキュリティリスクにつながります。
2024年以降、AWSはMFAの有効化を強く推奨しており、新規アカウントやルートユーザーに対してはデフォルトで有効化されるなど、その重要性が増しています。
1. IAMユーザーの最小権限設定
IAMポリシーを活用して、ユーザーやグループには最小限の権限だけを付与しましょう。たとえば、S3の特定バケットに対する読み取りのみを許可するには、以下のようなポリシーを利用します:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}
IAMポリシーは、可能な限りマネージドポリシー(AWS管理ポリシーまたはカスタム管理ポリシー)を使い、ユーザーに直接ではなくグループやロールを介して権限を割り当てるのが望ましい運用です。
加えて、条件付きポリシーを使って、IPアドレスや時間帯でアクセスを制限することもできます:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "xxx.xxx.xxx.0/24"
}
}
}
2. MFA(多要素認証)の有効化
MFA(Multi-Factor Authentication)は、不正アクセスを防ぐための基本かつ強力な対策です。IAMユーザー、特に運用・管理系ユーザーにはMFAの設定が強く推奨されます。
2024年以降、AWSはMFAの有効化を段階的に義務化しており、未設定のIAMユーザーにはコンソール上で警告が表示されます。
仮想MFAの設定手順:
- IAMコンソールで対象ユーザーを選択
- 「セキュリティ認証情報」タブを開く
- 「MFA デバイスの割り当て」→「仮想MFA デバイスの追加」を選択
- QRコードを認証アプリ(Google Authenticator、Authyなど)で読み取る
- 表示されたコードを2回入力して確認
また、AWSは2023年以降、パスキー(FIDO2)にも対応しており、セキュリティキーや顔認証などを使ったログインが可能です。ユーザビリティとセキュリティの両立に優れた選択肢です。
3. パスワードポリシーの設定
IAMユーザーでコンソールログインを許可する場合は、パスワードの複雑性を担保するためにパスワードポリシーを必ず設定しましょう。
設定可能な項目例:
- 最小文字数(例:12文字以上)
- 大文字、小文字、数字、記号の含有を必須にする
- パスワードの再利用制限(例:過去3件)
- 有効期限の設定(任意)
設定手順:
- IAMコンソール → 「アカウント設定」
- 「パスワードポリシーの変更」から条件を指定
4. アクセスキーの管理
アクセスキー(Access Key ID / Secret Access Key)は、プログラムによるAWSアクセス時に使われます。誤った取り扱いは深刻なインシデントに直結します。
管理のベストプラクティス:
- アクセスキーの使用を避ける(可能な限りIAMロールやSTSを使用)
- 使用が必要な場合は90日以内でローテーション
- 未使用のキーは無効化または削除
- コードにハードコーディングしない
- 公開リポジトリ(GitHub等)に誤ってアップロードしない
- ルートユーザーにはアクセスキーを発行しない
使用状況の確認には、CloudTrailやIAMアクセスアドバイザーを利用すると便利です。
5. CloudTrailによる監査
CloudTrailは、AWSアカウント内の操作ログを取得・保存するサービスで、セキュリティ監査やトラブルシュートに不可欠です。
主なログタイプ:
- 管理イベント:IAMポリシーの変更、ユーザー作成など
- データイベント:S3のファイル取得、Lambdaの関数呼び出しなど(明示的に有効化が必要)
ログはS3に保存され、CloudWatch LogsやAmazon SNSと連携することで、リアルタイムアラートを構成できます。
詳細はCloudTrail公式ドキュメントを参照してください。
よくあるミスや注意点
ミス・不備内容 | 説明・対策 |
---|---|
MFA未設定 | ルートユーザーや管理者にMFAが未設定だと致命的。速やかに有効化を。 |
過剰な権限の付与 |
AdministratorAccess を安易に付与せず、職務に応じた限定的な権限に絞る。 |
アクセスキーの放置 | 利用状況を定期確認し、未使用キーは削除。 |
パスワードポリシー未設定 | 強度の低いパスワードが放置されるリスクがある。最低限の複雑性要件を設定。 |
インラインポリシーの多用 | トラブルの元。可能な限り管理ポリシー(マネージドポリシー)を使用。 |
まとめ
IAMユーザーのセキュリティ対策は、AWS利用における最も基本かつ重要なポイントです。MFA、最小権限、パスワードポリシー、アクセスキーの適切な管理、CloudTrailによる監査を組み合わせて、安全な運用体制を構築しましょう。
また、IAMユーザーの利用を最小限に抑え、可能な限りIAMロールやAWS IAM Identity Centerの利用も検討しましょう。AWSアカウント構成やアクセス管理の定期的な見直しも忘れずに行うことが重要です。
Discussion