はじめに
クラウド環境でリソースを安全に管理するには、ユーザーの追加と適切な権限付与が欠かせません。本記事は、AWSのIAM（Identity and Access Management）を使ったユーザー追加を中心に、具体的な手順、権限の考え方、MFAなどのセキュリティ対策、運用のポイントを分かりやすく解説します。
対象はAWS初心者から管理者、開発者まで幅広く想定しています。コンソール画面の操作例や実務で使える注意点を取り上げ、実際の運用に役立つ知識を優先して紹介します。
本記事の構成は次の通りです。
– 第2章: ユーザー管理の基本
– 第3章: IAMユーザー追加の手順
– 第4章: 権限設定とセキュリティのベストプラクティス
– 第5章: 追加後のサインインと運用
– 第6章: CLIや外部連携の注意点
– 第7章: トラブルシューティング
– 第8章: まとめ
まずは全体像をつかみながら、安心して操作できるよう丁寧に進めていきます。
AWSにおけるユーザー管理の基本
はじめに
AWSではアカウント作成時にルートユーザーができますが、日常業務ではIAMユーザーを使うのが安全です。ルートは請求やアカウント設定のみに限定します。
ルートユーザーとIAMユーザーの違い
ルートユーザーはアカウント全権限を持ちます。一方、IAMユーザーは個別に権限を与えられます。例：開発者はS3とEC2、監査担当は読み取りのみという割り当てができます。
なぜIAMユーザーを使うか
個別の認証情報で責任を明確にできます。万が一の漏洩時も被害範囲を限定できます。また、多要素認証（MFA）をユーザー単位で有効にできます。
基本的な運用ルール
- 最小権限の原則：必要な権限だけを付与します。
- グループ運用：共通の権限はグループにまとめて管理します。
- 認証情報の使い分け：コンソールはパスワード、プログラムからはアクセスキーを使用します。キーは定期的にローテーションし、コードに直書きしないでください。
ポリシー付与の簡単な指針
AWS管理ポリシーを活用し、カスタムポリシーは最小限にします。ユーザーへは直接付与せず、まずはグループ経由で割り当てると管理が楽です。
実務上の注意点
名前付けルール（例：firstname.lastname、proj-role）を決めると検索が楽になります。強力な権限は少数に限定し、重要操作時はMFAを必須にしてください。
IAMユーザー追加の具体的な手順
ここでは、実際にIAMユーザーを追加する手順を画面操作の流れに沿って具体的に説明します。初心者にも分かりやすいよう例を交えて解説します。
- AWSマネジメントコンソールにサインイン
-
ルートユーザーまたは管理者権限をもつIAMユーザーでサインインしてください。管理者アカウント例：admin@example。
-
IAMコンソールへ移動
-
サービス一覧から「IAM」を選びます。
-
「ユーザー」→「ユーザーを追加」をクリック
-
画面右上のボタンを押します。
-
ユーザー名とアクセスの種類を設定
- ユーザー名を入力（例: developer-A）。
-
マネジメントコンソールアクセスを許可する場合はチェックを入れます。プログラム的アクセス（CLI/API）も必要なら同時に選択してください。
-
パスワード設定と初回パスワード変更
- 自動生成かカスタムパスワードを選べます。カスタムを使う場合は強いパスワードを設定してください。
-
「次回サインイン時にパスワードの変更を要求」を有効にすることを推奨します。
-
権限（ポリシー）を設定
- グループに追加、既存ユーザーからコピー、またはポリシーを直接アタッチのいずれかで権限を付与します。
-
例: 読み取り専用ならReadOnlyAccessをグループで付与します。権限は最小限にしてください。
-
タグ（任意）
-
所属や用途を示すタグを付けると運用が楽になります。
-
内容確認してユーザー作成
-
入力内容を確認して「ユーザーを作成」をクリックします。
-
作成後の注意点
- サインインURL、ユーザー名、パスワードが表示されます。プログラム的アクセスを選んだ場合はAccess key IDとSecret access keyが表示され、Secretは一度しか見られません。必ずCSVでダウンロードするか安全に保管してください。
- 情報は安全な手段で本人に伝え、可能であればMFAを有効にしてください。
ユーザー権限とセキュリティのベストプラクティス
最小権限の原則
ユーザーには業務に必要な操作だけを許可します。まず業務ごとに必要な権限を洗い出し、過剰な権限は付与しません。具体例：S3の特定バケットのみ読み書き可能にする、といった細かいスコープで制限します。
IAMグループとポリシーの活用
複数ユーザーは役割ごとにグループにまとめ、グループ単位でポリシーを管理します。ポリシーはできるだけAWS管理ポリシーではなくカスタムポリシーでスコープを限定してください。変更はドキュメント化し変更履歴を残します。
多要素認証（MFA）の導入
重要なアカウントやコンソールアクセスにはMFAを必須にします。ハードウェアトークンや認証アプリを使うと安全性が高まります。ルートアカウントには必ずMFAを設定してください。
ログと監査の設定
CloudTrailやログ保存を有効にして操作履歴を残します。不審な操作は早期に検出しアラートで知らせます。アクセスログは適切な保存期間を定めます。
パスワードとアクセスキーの運用
強いパスワードポリシーを適用し定期的に変更します。アクセスキーは必要時のみ作成し、長期間使わないキーは無効化または削除します。
定期的な権限見直し
少なくとも四半期ごとに権限を見直し、不要な権限や未使用のアカウントを削除します。レビューは担当者を決めて責任を明確にします。
ユーザー追加後のサインイン方法と運用のポイント
サインインURLの確認と共有方法
ユーザー作成時に専用サインインURLが表示されます。表示を控え忘れた場合は管理者画面（IAMのサインイン情報）から確認します。共有は安全な手段（社内チャットの暗号化やパスワード管理ツール）で行ってください。メールの平文送信は避けます。
初回サインインの手順
- 専用URLへアクセスします。2. ユーザー名と初期パスワードでログインします。3. 初回はパスワード変更を求められることが多いので、新しい強いパスワードを設定します。4. MFA（多要素認証）を必ず有効化してください。
権限変更後の再サインイン
権限を変更した場合、設定は即時反映されないことがあります。確実に反映させるため、ユーザーにログアウトして再ログインするよう伝えてください。APIやCLIではセッションを再作成する必要があります。
請求情報など敏感データの扱い
請求情報やクレジットカード関連は最小限のユーザーのみに許可します。Billingやアカウント管理権限は限定ポリシーで付与し、必要がなくなったらすぐに削除します。
運用のポイント
・パスワードは定期変更とパスワードマネージャーの利用を推奨します。
・必ずMFAを要求します。
・長期間使わないアカウントは無効化または削除します。
・監査ログ（CloudTrailや認証ログ）を定期的に確認します。
AWS CLIや外部サービス連携時の注意点
概要
AWS CLIや外部サービスはIAMユーザーのアクセスキーで操作できます。誤った運用は情報漏えいや不要な権限拡大の原因になります。ここでは実務で役立つ注意点を具体例と合わせて説明します。
アクセスキーの取り扱い
- 長期鍵は最小限に抑えます。CI/CDなどで必要な場合も、可能なら短期間のトークンやロールを使います。
- 保管は環境変数ではなく、シークレットマネージャやCIのシークレット機能を使います。
- 不要なキーは速やかに無効化・削除します。定期的に未使用キーをチェックしてください。
権限は最小化する
- サービスごとに必要な操作だけを許可します。例: S3からファイルを読むだけならGetObjectのみ付与します。
- テンプレートやポリシーの使い回しを避け、具体的なリソース指定を行います。
外部サービス連携の実例
- CI/CD: デプロイ用にS3やECRの限定的な権限を与える。アクセス鍵はシークレットに入れて参照します。
- サードパーティ: 可能ならIAMロールの委任（AssumeRole）やOIDCで一時的認証を使います。
監査と緊急対応
- CloudTrailやアクセスログで異常な利用を監視します。異常が見つかったら直ちにキーを無効化してください。
- 定期ローテーションとアクセスレビューを実施します。
チェックリスト（実践）
- キーの発行目的をドキュメント化する
- シークレットに保管する
- 最小権限を設定する
- 未使用キーを削除する
- CloudTrailで監査する
この章では、実際の運用でよくある落とし穴を避けるための具体的な対策を示しました。
トラブルシューティングとよくある失敗例
代表的な失敗例
- ルートユーザーで日常作業を続ける
- 問題点：権限分離ができず、誤操作で重要な設定まで変更してしまいやすい。
- 対処法：ルートは最小限の用途（請求やアカウント設定）に限定し、代わりに管理者権限のIAMユーザーやグループを作成します。ルートには必ずMFAを設定してください。
ポリシー設定のミス（権限不足・過剰付与）
- 権限不足の例：S3からファイルを取得できない（アクセス拒否）
- 対処法：必要なアクション（例：s3:GetObject）だけを追加し、テストして確認します。
- 過剰付与の例：”Resource”: ““や”Action”: ““を安易に使う
- 対処法：最小権限の原則に従い、リソースやアクションを限定します。ポリシーシミュレータで事前検証してください。
MFA未設定による乗っ取りリスク
- 問題点：パスワード漏えいだけでアカウントを奪われる恐れがあります。
- 対処法：ルートと重要ユーザーにMFAを必須にします。ソフトウェアトークンやハードウェアを利用し、バックアップも準備してください。
サインインURLや初期パスワードの紛失
- 例：組織で配布したサインインURLや初期パスワードを紛失した場合
- 対処法：管理者はユーザーのパスワードをリセットできます。ルート自体の情報を失った場合は、登録済みメールや電話で復旧手続きを行ってください。日常はパスワード管理ツールで情報を安全に保管します。
コンソール/CLIでのアクセス拒否エラーの切り分け
- ステップ：
- エラーメッセージを正確に保存する（例：AccessDenied）
- 該当ユーザーのポリシー、アクセス権限境界、サービスコントロールポリシー(SCP)を確認する
- リージョンやリソース名の指定ミスを確認する
- CloudTrailで直近の操作ログを確認する
- これらを順に実施すると原因を早く特定できます。
予防と日常のチェックリスト
- 管理者アカウントを限定し、グループ運用にする
- 全員にMFAを必須化する
- ポリシーは最小権限で作成し、ポリシーシミュレータで検証する
- 認証情報はパスワードマネージャーで一元管理する
- CloudTrailやログを有効にして監査可能にする
以上がよくある失敗例と実務的な対処法です。問題発生時は落ち着いてログとポリシーを確認し、まずは影響範囲を把握してください。
まとめ
振り返り
本書では、IAMユーザーの作成から権限設計、セキュリティ対策、運用上の注意点までを順に解説しました。基本を押さえることで、誤操作や不正アクセスのリスクを大きく減らせます。
重要なポイント
- 最小権限の原則でユーザーに必要な権限だけを付与します。グループやポリシーで管理すると楽です。
- コンソールやAPI用の認証情報は用途を限定し、アクセスキーは必要時のみ発行して定期的に更新します。
- 多要素認証（MFA）を全ユーザーで有効にし、アカウント乗っ取り対策を行います。
- 定期的に権限とログを見直し、不審な操作を早期に検知します。
実務での次の一歩
- 新規ユーザー作成時にチェックリストを用意する。
- 権限レビューを定期スケジュールに組み込む。
- 自動化できる作業（ユーザー追加、キーのローテーションなど）はスクリプト化してヒューマンエラーを減らす。
これらを実践すれば、安全で効率的なAWS運用につながります。何か不明点があれば気軽にご相談ください。
