はじめに
本記事の目的
本記事は、AWSのユーザー管理を分かりやすく解説する入門ガイドです。初心者の方が基本概念を理解し、管理者が実務で役立つ運用方法まで学べる内容を目指します。実例を交えて丁寧に説明しますので、初めて扱う方でも安心して読み進められます。
なぜユーザー管理が重要か
クラウド環境では、誰が何をできるかを明確にすることが安全運用の基本です。誤った設定は情報漏えいやサービス停止につながる恐れがあります。適切なユーザー管理はリスクを下げ、業務の効率化にもつながります。
この章で得られること
- ルートユーザーとIAMユーザーの違いを簡潔に理解できます
- 本記事全体の流れと各章で学べる内容が分かります
読み方のポイント
順番に読むと理解が深まります。実際に手を動かす前に、まず本章で考え方を整理してください。
IAMユーザーの基本概念
IAMユーザーとは
IAMユーザーは、AWSで個々の人やアプリケーション向けに作るアカウントです。企業の社員や開発チーム、特定のサービスごとに個別のアカウントを用意できます。権限を必要最小限に絞って付与できる点が特徴です。
用途と具体例
- S3バケットの閲覧だけ許可するユーザー
- EC2インスタンスを起動できるが削除はできないユーザー
- バックアップスクリプト用のプログラム専用ユーザー（対話型ログイン不要、アクセスキーで操作）
認証の種類
コンソール用のパスワードと、APIやCLI用のアクセスキーを使い分けます。用途に応じていずれか、または両方を付与します。
ルートユーザーとの違い
ルートユーザーはアカウント作成時の全権限を持つ唯一の存在です。日常操作で使うとリスクが高いため、普段は使わずIAMユーザーで作業するのが安全です。
作成時の考え方
- 個人ごとに作成して操作履歴を追跡する
- アプリ用は人とは別に作る
- 必要最小限の権限を与える（最小権限の原則）
ベストプラクティス（簡潔に）
個別アカウントの採用、権限は細かく、ログイン情報は適切に管理することをおすすめします。
権限管理の仕組みと構造
はじめに
IAMユーザーの権限は「ポリシー」で定義します。ポリシーを組み合わせることで、柔軟かつ堅牢なアクセス管理を実現できます。ここでは仕組みと運用の基本をわかりやすく解説します。
ポリシーの種類と役割
- 管理ポリシー（AWS提供）: すぐ使える定義済みの権限セットです。例: AmazonS3ReadOnlyAccessはS3の閲覧のみ許可します。
- カスタマー管理ポリシー: 自社用に細かく作るポリシーです。特定のバケットや操作だけ許可するといった制御ができます。
グループベースの管理の利点
個別ユーザーに直接権限を付けるより、グループにポリシーを割り当てた方が管理が楽です。例: 「開発者」「運用」「監査」などのグループに分け、各グループへ必要な権限を付与します。これにより、ユーザーの入退社や役割変更時に作業が少なくなります。
最小権限の原則
ユーザーには業務に必要な最低限の権限だけを与えます。たとえば、データ閲覧だけの人に書き込みや削除の権限を与えないようにします。これで事故や誤操作のリスクを下げます。
明示的拒否と優先順位
ポリシーのルールでは「明示的な拒否」が最も強く効きます。許可と拒否が競合するときは拒否が優先されます。設計時はこの点を意識して例外処理を設けます。
設計の具体例
- S3の特定バケットを閲覧のみ許可するカスタムポリシー
- 開発環境だけにアクセスできるポリシー
グループにこれらを割り当て、ユーザーはグループに所属させるだけで権限を適用します。
運用上のポイント
- 監査ログを有効にして権限の利用状況を確認します。
- 定期的にポリシーを見直し、不要な権限を削除します。
- 管理者権限は限定的にし、必要なときだけ付与する運用にします。
（この章ではまとめを省き、実践的な仕組みと注意点を説明しました。）
IAMユーザー作成の具体的ステップ
準備
- AWSマネジメントコンソールに管理者アカウントでサインインします。
- ユーザーの役割や必要な操作（コンソール操作、APIアクセスなど）を確認します。
手順（画面操作の流れ）
- コンソールで「IAM」を開き、「ユーザー」を選択します。
- 「ユーザーを追加」をクリックし、ユーザー名を入力します。ユーザー名はアカウント内で一意です。
- アクセスの種類を選びます。例：
- コンソールアクセス（ウェブログイン）
- プログラムによるアクセス（アクセスキー）
必要に応じて両方を選択します。 - 権限の付与方法を選びます。推奨は「既存のグループに追加」です。グループを使う利点は複数ユーザーの管理が容易になる点です。直接付与する場合は管理ポリシーやカスタマー管理ポリシーを選択できます。
5.（任意）タグを付けます。例：部署や用途を示すキー=値（dept=marketing）。 - 設定を確認して「作成」を押します。
- 作成後に表示される認証情報は安全に保管します。コンソール用の初回パスワードはユーザーに連絡し、初回ログイン時に変更してもらいます。
ユーザー名の命名例
- フォーマット例：部署-役割-識別子（例：hr-manager-ya01）
- 日常業務で検索しやすく、誰が何のためのアカウントか分かるようにします。
権限付与の注意点
- 最小権限の原則に従い、必要な権限だけを与えます。
- 管理作業用アカウントはグループで管理し、急ぎの場合のみ個別に権限を付けます。
- アクセスキーは必要な場合だけ発行し、不要になったら無効化します。
作成後の確認項目
- ユーザーでログインできるか（必要なアクセス種別で）確認します。
- 権限が適切に動作するか、実際の操作でチェックします。
- 認証情報の保管と定期的な見直しのスケジュールを立てます。
管理者IAMユーザーの作成と運用フロー
目的と基本方針
AWS環境構築の最初に管理者用IAMユーザーを用意します。名前は「admin」「aws-admin」など分かりやすくします。最初は「AdministratorAccess」ポリシーを付与して作業を進めますが、作業後はできるだけ最小権限へ置き換えます。
作成手順（簡潔）
- ユーザー作成：ユーザー名を明確にし、管理者用グループへ追加します。
- 権限付与：初期はAdministratorAccessを割り当てます。
- 認証情報設定：コンソール用パスワードとAPIキーは必要時のみ発行します。
- MFAの有効化を推奨します（詳細は第6章）。
役割ごとの分離と権限割当
開発者、運用、監視など業務ごとに個別ユーザーを作成し、必要最小限の権限を与えます。管理者ユーザーは設定や事故対応のみに限定し、日常作業は権限を絞ったユーザーで行います。
運用フロー（ライフサイクル）
- 導入：管理者が初期設定とアカウント整備を実施します。
- 日常運用：管理者は監査ログ確認や緊急対応のみ使用します。
- 変更管理：権限変更は申請と承認の手順を設けます。
- 退職・権限削除：不要になったユーザーは速やかに無効化・削除します。
運用時の注意点
- ルートアカウントは普段使わない。
- アクセスキーは最小化し、定期的にローテーションします。
- CloudTrailなどで操作ログを収集し監査体制を整えます。
- 管理者ユーザーも定期的に権限見直しを行ってください。
セキュリティを強化するための多要素認証（MFA）設定
目的
管理者権限や本番環境アクセスを持つIAMユーザーには、パスワードだけでなく別の要素（MFA）を必須にします。これにより不正ログインのリスクを大幅に下げます。
MFAの種類とおすすめ
- スマホの認証アプリ（TOTP）：Google AuthenticatorやAuthyなど。導入が簡単で費用もかかりません。例：ログイン時に6桁を入力します。
- ハードウェアキー（例：FIDO/U2F）：高い安全性が必要な管理者に推奨します。
- SMS：手軽ですが、乗っ取りリスクがあるため重要権限には推奨しません。
IAMユーザーへの設定手順（簡易）
- 管理者でAWSコンソールにサインインします。
- IAM > Users から対象ユーザーを選びます。
- 「セキュリティ認証情報」タブで「MFA デバイスの管理」を選択します。
- デバイス種別を選び、表示されるQRコードを認証アプリで登録し、確認コードを入力して有効化します。
OrganizationsでのMFA強制（SCP例）
組織単位やアカウントに対して、MFA未使用時の操作を拒否するSCPで強制できます。例（全操作をMFAなしで拒否するシンプルな例）：
{
“Version”:”2012-10-17″,
“Statement”:[{
“Effect”:”Deny”,
“Action”:”“,
“Resource”:”“,
“Condition”:{“Bool”:{“aws:MultiFactorAuthPresent”:”false”}}
}]
}
このポリシーは強力です。まずテスト環境で試し、必要な例外（サービスロールや一部自動処理）を考慮してください。
運用上の注意点
- ルートアカウントは必ずMFAを有効にしてください。
- 管理者にはハードウェアキーの配布を検討してください。
- MFA紛失時の手順（管理者による再設定や認証情報の回復）を文書化しておきます。
- 定期的に有効化状況を確認し、未設定ユーザーを洗い出してください。
継続的な権限管理と定期的な見直し
概要
効果的なユーザー管理には継続的な監視と定期的な見直しが不可欠です。管理者権限（AdministratorAccess）は必要最小限のユーザーだけに付与してください。定期的に権限の棚卸しを行い、不必要な権限やアカウントを削除します。
見直しの頻度と手順
四半期ごとのレビューを基本にします。手順例：
1. 現在のユーザー一覧と付与権限を取得
2. 業務に不要な権限を識別
3. 所有者に確認して修正または削除
非アクティブ（90日以上）アカウントは一旦無効化する運用が有効です。
グループベースの管理
個別付与を避け、役割ごとのグループに権限をまとめます。これにより追加・削除が簡単になりミスが減ります。例：開発チーム、運用チームといったグループを作成します。
モニタリングと自動化
アクセスログと権限変更の監査を有効にし、異常な昇格や不審なログインをアラートします。自動化で棚卸しレポートや期限通知を出すと運用負荷が下がります。
ドキュメントと教育
権限付与のルールや申請フローを文書化し、定期的に担当者へ周知します。権限変更時は理由を記録し、レビュー履歴を保持してください。
