AWS IAMユーザー作成方法：ベストプラクティスと自動化

IAMユーザー作成の全体像とセキュリティ原則

IAMユーザー管理の現代的なアプローチ：フェデレーションへの移行

かつてAWSリソースへのアクセス管理は、IAMユーザーを作成し、それぞれに認証情報（パスワードやアクセスキー）を付与することが一般的でした。しかし、これらの長期的な認証情報は漏洩リスクを伴うため、セキュリティ上の課題がありました。現在では、このアプローチは非推奨とされ、AWS IAM Identity Center（旧AWS SSO）を活用したIDの一元管理（フェデレーション）が強く推奨されています。

フェデレーションは、組織内の既存のIDプロバイダ（Active Directory、Oktaなど）とAWSを連携させ、ユーザーが一度認証すれば、一時的な認証情報でAWSリソースにアクセスできる仕組みです。これにより、長期的なAWS認証情報をAWS上で管理する必要がなくなり、セキュリティが大幅に向上します。日本のパブリッククラウドサービス市場は2024年に4兆1,423億円に達すると予測されており（総務省「令和7年版 情報通信白書」より）、クラウド利用が拡大する中で、よりセキュアなID管理は避けて通れない課題となっています。

IAM Identity Centerを導入することで、ユーザーは既存のIDとパスワードでAWSにサインインできるようになり、管理者はIDプロバイダ側でユーザーとグループを一元管理できるため、運用の効率化にもつながります。新しいIAMユーザーを作成する前に、まずIAM Identity Centerの導入を検討することが、現代のベストプラクティスと言えます。

IAMセキュリティの根幹：最小権限の原則とMFAの徹底

AWS IAMにおけるセキュリティの根幹は、「最小権限の原則」に基づいています。これは、IAMユーザーやロールには、その役割を果たすために必要最低限の権限のみを付与する、という考え方です。過剰な権限は、たとえ意図しないものであっても、設定ミスや認証情報の漏洩時に深刻なセキュリティインシデントに発展するリスクを高めます。例えば、あるチームがS3へのアクセスのみを必要とするのに、誤ってEC2やRDSへのフルアクセス権限を与えてしまうと、もしそのユーザーの認証情報が漏洩した場合、意図しないリソースの操作やデータ漏洩につながる可能性があります。

この原則を実践するためには、IAM Access Analyzerのようなツールを活用し、現在のポリシーがどのようなアクセスを許可しているかを定期的に検証し、不要な権限を特定して削除する「削る運用」が推奨されます。さらに、多要素認証（MFA）の有効化は、特権ユーザーに限らず、すべてのIAMユーザーに必須のセキュリティ対策です。MFAは、パスワードだけでなく、スマートフォンアプリやハードウェアデバイスなど、複数の認証要素を組み合わせることで、万が一パスワードが漏洩した場合でも不正アクセスを防ぐ強固な壁となります。IPAの「情報セキュリティ白書2024」でも指摘されている通り、クラウドにおけるインシデントの多くは設定ミスに起因するため、これらの原則を徹底することが極めて重要です。

責任共有モデルにおける利用者の責任範囲とルートユーザー保護の重要性

AWSを利用する上で理解しておくべき重要な概念が「責任共有モデル」です。このモデルでは、クラウドインフラストラクチャの物理的なセキュリティや可用性の維持はAWSの責任（責任の「クラウド」）ですが、その上で構築・運用されるデータ、プラットフォーム、アプリケーション、そしてIAMユーザーの作成・管理・適切なポリシー設定は「利用者側の責任」（責任の「クラウド内」）となります。つまり、IAMユーザーが持つ権限やその管理方法が適切であるかは、完全に利用者に委ねられているのです。

特に注意が必要なのが「ルートユーザー」の扱いです。ルートユーザーは、AWSアカウントを作成した際に作成される最も強力な権限を持つユーザーであり、アカウント全体のあらゆるサービスやリソースにアクセスできるため、非常に強力な管理者権限を持っています。このため、ルートユーザーは日常の運用には絶対に使用せず、MFAを設定した上で、その認証情報（パスワードとアクセスキー）を厳重に保管する必要があります。具体的な運用では、IAMユーザーを作成して管理者権限を与え、そちらを日常的な管理者として使用することが推奨されます。また、長期的なアクセスキーは漏洩リスクが高いため、可能な限り使用を控え、利用する場合も定期的なローテーションが不可欠です。

出典：総務省、AWS、IPA、経済産業省

AWSコンソールでのIAMユーザー作成基本手順

ユーザー作成前の準備とポリシー設計の考え方

AWSコンソールでIAMユーザーを作成する前に、最も重要なステップは「ポリシー設計」です。闇雲にユーザーを作成し、広範な権限を付与することは、セキュリティリスクを大幅に高めます。ユーザーがどのような役割を持ち、どのAWSサービスに対してどのような操作（読み取り、書き込み、削除など）が必要なのかを具体的に洗い出す必要があります。例えば、S3バケットへのファイルアップロードのみを行うユーザーであれば、S3へのPutObject権限のみを付与し、それ以外の権限は一切与えないようにします。

ポリシー設計の際には、「最小権限の原則」を常に意識し、必要最低限の権限から始めることが重要です。最初は読み取り専用の権限で様子を見たり、特定のパスに限定したアクセス権限を付与したりと、細かく権限を分割することを心がけましょう。チームやプロジェクトごとに役割を定義し、それに紐づくIAMグループを作成することも、後の運用を効率化する上で非常に有効です。事前にどのAWSサービスを、どのリソースに対して、どのようなアクションを許可するかを明確にしておくことで、適切なIAMポリシーを作成しやすくなります。

この準備を怠ると、後から権限を見直す手間が増えるだけでなく、意図しない設定ミスからセキュリティインシデントにつながる可能性も高まります。時間をかけてこのプロセスに取り組むことが、安全なAWS環境を構築するための第一歩となります。

AWSマネジメントコンソールを使ったユーザー作成ステップ

IAMユーザーの作成は、AWSマネジメントコンソールから直感的に行うことができます。まず、AWSアカウントにログインし、検索バーで「IAM」と入力してサービスにアクセスします。左側のナビゲーションペインから「ユーザー」を選択し、「ユーザーの追加」をクリックします。ここから、新しいユーザーの情報を設定していきます。

まず、ユーザー名を設定します。これはAWS上でユーザーを識別するための名前であり、後から変更できないため慎重に決めましょう。次に、「AWSアクセスタイプ」を選択します。「パスワード – AWSマネジメントコンソールへのアクセス」は、コンソールへのログインパスワードを生成し、人間が利用する際に必要です。「アクセスキー – プログラムによるアクセス」は、AWS CLIやSDK、API経由でのアクセスに必要となるアクセスキーIDとシークレットアクセスキーを生成します。両方選択することも可能ですが、必要なアクセスタイプのみを選択し、特にプログラムによるアクセスキーは、長期的な利用を避け、一時的な認証情報を利用することが推奨されます。パスワードを設定する際は、自動生成を選択し、ユーザーに初期パスワードの変更を強制する設定を有効にすることをおすすめします。

ポリシーのアタッチとグループへの所属：最小権限の実現

ユーザー名とアクセスタイプを設定したら、次に重要なのはアクセス権限の付与です。コンソールでは、以下の3つの方法でポリシーをアタッチできます。

1. 既存のポリシーを直接アタッチする
2. グループにユーザーを追加し、グループにアタッチされたポリシーを継承させる
3. 新しいポリシーを作成してアタッチする

最も推奨される方法は、IAMグループを作成し、そのグループにポリシーをアタッチし、ユーザーをそのグループに追加することです。この方法のメリットは、権限の管理がシンプルになる点です。例えば、開発者グループ、運用者グループなど、役割に応じたグループを作成し、それぞれのグループに適切な権限を持つポリシーをアタッチしておけば、新しいメンバーが参加した際に、その役割のグループに追加するだけで必要な権限を付与できます。これにより、個々のユーザーにポリシーを直接アタッチする手間が省け、権限の割り当てミスを防ぎやすくなります。

既存のAWS管理ポリシー（例: AmazonS3ReadOnlyAccess）を活用することもできますが、より細かく権限を制御したい場合は、カスタムポリシーを作成する必要があります。カスタムポリシーはJSON形式で記述され、どのようなサービスに対して、どのようなアクションを、どのリソースに対して許可・拒否するかを詳細に設定できます。常に最小権限の原則を念頭に置き、ユーザーが必要とする最小限の権限のみを付与するよう心がけましょう。

CLI、Terraform、CSVによる効率的なユーザー管理

AWS CLIを活用したIAMユーザーの一括作成と管理

少数のIAMユーザーであればAWSマネジメントコンソールでの手動作成でも対応可能ですが、組織の拡大やプロジェクトの増加に伴い、ユーザー数が多くなると手動操作は非効率的であり、設定ミスを誘発するリスクが高まります。このような場合に有効なのが、AWS CLI（コマンドラインインターフェース）を用いたユーザーの一括作成と管理です。AWS CLIを使用することで、ターミナルからコマンドを実行するだけでIAMリソースを操作できるようになり、スクリプト化による自動化が可能になります。

例えば、`aws iam create-user –user-name [ユーザー名]` コマンドでユーザーを作成し、`aws iam add-user-to-group –group-name [グループ名] –user-name [ユーザー名]` でユーザーを特定のグループに追加できます。さらに、ポリシーの直接アタッチには `aws iam attach-user-policy` コマンドを使用します。これらのコマンドをシェルスクリプトやPythonスクリプトに組み込むことで、ユーザー名や所属グループなどの情報をCSVファイルなどから読み込み、複数のユーザーアカウントと関連する権限設定を一括で適用することができます。これにより、手作業によるヒューマンエラーを減らし、ユーザープロビジョニングにかかる時間を大幅に短縮し、管理の一貫性を保つことが可能になります。

IaCツールTerraformによるIAMリソースのコード管理

AWS CLIによるスクリプト化は便利ですが、より大規模かつ複雑な環境で、インフラストラクチャ全体をコードとして管理する（Infrastructure as Code: IaC）場合は、Terraformのような専用ツールの導入が強力な解決策となります。Terraformは、HCL（HashiCorp Configuration Language）という宣言的な言語を使用して、IAMユーザー、グループ、ポリシー、ロールなどのAWSリソースをコードとして記述し、バージョン管理システム（Gitなど）で管理することを可能にします。

Terraformを使用する最大のメリットは、IAM設定の変更履歴がすべてコードとして記録されるため、誰がいつどのような変更を加えたか、なぜその変更が必要だったかを明確に追跡できる点です。これにより、監査性が向上し、設定ミスが発生した場合も、以前の安全な状態にロールバックするプロセスが容易になります。また、開発環境、ステージング環境、本番環境といった複数の環境で同じIAM設定を再現することが容易になり、環境間の差異による問題を回避できます。TerraformによるIaCは、セキュリティチームと運用チームが連携し、より安全で効率的なIAM管理を実現するためのベストプラクティスの一つと言えるでしょう。

CSVファイルとスクリプトを用いた簡易的なユーザー情報管理

大規模なIaCツールの導入が組織の成熟度やリソースの都合で難しい場合でも、手動操作のデメリットを軽減し、効率的なユーザー管理を実現する方法があります。それが、CSVファイルと簡単なスクリプトを組み合わせた管理手法です。このアプローチでは、作成したいIAMユーザーのリスト（ユーザー名、初期パスワードの有無、所属させるグループなど）をCSVファイルに整理し、Pythonやシェルスクリプトなどの簡単なプログラムでこのCSVファイルを読み込み、前述のAWS CLIコマンドを自動的に実行します。

例えば、CSVファイルに「username,group,policy_arn」といった形式でユーザー情報を記述し、スクリプトが各行を読み取って`aws iam create-user`、`aws iam add-user-to-group`、`aws iam attach-user-policy`などのコマンドを順次実行する、といった流れです。この方法により、手動でフォームに入力する手間を省き、入力ミスを減らすことができます。ただし、スクリプト自体のセキュリティ（特にアクセスキーの扱い）には細心の注意を払い、認証情報が漏洩しないよう管理を徹底する必要があります。また、Terraformのような状態管理機能はないため、変更の履歴管理や既存設定の検出は別途行う必要がありますが、手動での管理とIaCの間を埋める実用的な方法として活用できます。

IAMユーザー作成時に避けるべき誤設定と料金影響

ルートユーザーの日常利用と過剰なアクセス権限付与のリスク

IAMユーザーを作成する際に最も避けるべき誤設定の一つが、ルートユーザーを日常的な運用に使用してしまうことです。ルートユーザーはAWSアカウントの全てのサービスとリソースに対する絶対的な権限を持っており、これは例えるなら会社の全資産を管理する唯一の鍵を持つようなものです。この鍵を日常的に使用すると、不用意な操作でアカウント全体に深刻な影響を与えたり、認証情報が漏洩した際に甚大な被害が生じるリスクが極めて高まります。ルートユーザーは厳重に保管し、MFAを設定した上で、緊急時以外は使用しないのが鉄則です。

また、IAMユーザーに過剰なアクセス権限を付与することも重大なリスクです。特に`AdministratorAccess`などの管理ポリシーを安易に付与することは、そのユーザーの認証情報が漏洩した場合、攻撃者がアカウント内の全リソースを操作し、データの窃取、サービス停止、あるいは不正なリソース作成による予期せぬ料金発生など、壊滅的な損害を引き起こす可能性があります。最小権限の原則を遵守し、ユーザーが必要とする最小限の権限のみを付与するように徹底しましょう。例えば、S3バケットへの読み取りアクセスのみが必要なユーザーに、EC2インスタンスの起動権限を与えることは、セキュリティホールを作り出す行為に他なりません。

アクセスキーの不適切な管理と情報漏洩による損害

プログラムによるアクセスを行うIAMユーザーにとって必須となるのがアクセスキー（アクセスキーIDとシークレットアクセスキー）です。しかし、このアクセスキーの不適切な管理は、情報漏洩や不正アクセスの主要な原因となります。最も典型的な誤りとしては、以下の点が挙げられます。

• GitHubなどの公開リポジトリへの誤アップロード：意図せずソースコードと共にアクセスキーを公開してしまうと、悪意のある第三者に即座に悪用される危険性があります。
• 共有ドライブやチャットツールでの平文保存：セキュリティが不十分な環境でアクセスキーを共有することは、容易な漏洩経路となります。
• 定期的なローテーションの欠如：アクセスキーを長期間使い続けると、漏洩のリスクが高まります。定期的なローテーション（使用中のキーを無効化し、新しいキーを発行する）が不可欠です。

アクセスキーが漏洩した場合、攻撃者はそのキーを使ってAWSリソースにアクセスし、機密データの窃取、不正なリソースの作成（仮想通貨マイニングなど）、サービス停止などの損害を引き起こす可能性があります。これにより、企業は金銭的損害だけでなく、ブランドイメージの失墜や顧客からの信頼喪失といった無形の損害も被ることになります。長期的なアクセスキーの使用は可能な限り避け、一時的な認証情報（IAMロールを引き受けるなど）を利用する設計を優先しましょう。

IAM設定ミスがもたらす潜在的な料金影響とセキュリティインシデント

IAM設定ミスは、単にセキュリティ上の脆弱性を生み出すだけでなく、予期せぬAWS料金の発生に直結する可能性もあります。例えば、S3バケットに誰でも書き込み可能なパブリックアクセス設定を伴うポリシーを適用してしまった場合、不正なユーザーによって大量のデータがアップロードされたり、多額のデータ転送料金が発生したりする可能性があります。また、誤った権限設定により、開発者が停止すべきEC2インスタンスを停止できない、あるいは削除すべきRDSデータベースを削除できないといった事態に陥ると、不要なリソースが稼働し続け、その分のコンピューティング料金やストレージ料金が無駄に発生します。

IPAの「情報セキュリティ白書2024」でも、クラウドサービス利用におけるインシデントの多くは、設定ミスやオペレーションミスに起因することが指摘されています。IAMはAWSリソースへのアクセスを制御する最も重要なセキュリティコンポーネントであり、その設定ミスは、セキュリティインシデントと料金影響の両面で大きなリスクとなります。自動化ツールを導入する際も、ポリシー設定の妥当性を継続的に検証し、最小権限の原則を徹底することが、無駄なコストを削減し、安全なクラウド運用を実現するための鍵となります。

出典：IPA

【ケース】過剰権限ユーザーの検知と最小権限への修正

過剰権限ユーザーの検知：Access Analyzerとログの活用

架空のケースとして、ある中規模システム開発企業「クラウドテック社」では、数年間のAWS運用を経て、特定のシステム運用担当者のIAMユーザーに過剰な権限が付与されている疑いがありました。このユーザーは初期段階で広範な管理者権限に近いポリシーがアタッチされていましたが、現在の担当業務は特定のEC2インスタンスの監視と停止、S3バケットへの特定ログファイルのアップロードに限られていました。このような状況で過剰権限を検知するため、クラウドテック社はまずIAM Access Analyzerを活用しました。

Access Analyzerを実行したところ、このユーザーが意図せず外部のAWSアカウントとリソースを共有している可能性や、未使用のアクセスキーが存在することが判明しました。さらに、CloudTrailのログを分析し、過去90日間のこのユーザーのAPI呼び出し履歴を詳細に調査しました。このログ分析により、実際にこのユーザーが実行しているアクションは、`ec2:DescribeInstances`、`ec2:StopInstances`、`s3:PutObject`、`s3:GetObject`に限定されていることが明確になりました。これにより、現在の付与されているポリシーが実際の業務に比べてはるかに広範であることが裏付けられました。

最小権限原則に基づくポリシーの見直しと適用プロセス

過剰権限が検知された「クラウドテック社」の運用担当者ユーザーに対し、次に最小権限原則に基づいたポリシーの見直しと適用プロセスが実行されました。まず、CloudTrailのログ分析で特定された「実際に利用されている権限」に限定した新しいカスタムポリシーをJSON形式で作成しました。具体的には、EC2の特定のタグが付与されたインスタンスの監視と停止権限、および特定のS3バケットへのPutObject（書き込み）とGetObject（読み取り）権限のみを許可するポリシーです。

次に、この新しいカスタムポリシーをテスト環境のIAMユーザーにアタッチし、運用担当者が行うべき業務が問題なく実行できるかを綿密に検証しました。特に、エラーが発生しないか、あるいは意図しない権限不足による問題がないかを複数回にわたって確認しました。検証が完了し、問題がないことを確認した後、本番環境の対象ユーザーから既存の広範なポリシーをデタッチし、新しく作成した最小権限ポリシーをアタッチしました。この段階的な適用と事前の厳格な検証を行うことで、本番環境への影響を最小限に抑え、安全に権限を修正することができました。

継続的な監査と自動化による権限管理のベストプラクティス

過剰権限ユーザーの修正は一度行えば終わりではなく、継続的な監査と改善が不可欠です。クラウドテック社では、この経験を活かし、IAM Access Analyzerを週次で自動実行する仕組みを導入しました。これにより、新たなポリシーの変更やリソースの共有が発生した場合に、即座に異常を検知できるようになりました。また、CloudTrailのログ分析も自動化し、定期的に各IAMユーザーの実際の活動と付与されている権限を比較照合するレポートを生成することで、権限のドリフト（時間の経過とともに権限が必要以上に拡大してしまう現象）を監視しています。

さらに、今後のIAMユーザーやロールの作成・変更は、手動でのコンソール操作を最小限に抑え、TerraformなどのIaCツールを用いてコードとして管理する方針に移行しました。これにより、全てのIAM設定がGitリポジトリでバージョン管理され、変更はレビュープロセスを経て適用されるため、設定ミスを大幅に削減し、セキュリティと運用の整合性を高めることができました。長期的な視点では、AWS IAM Identity Centerを導入し、組織の既存ID基盤とAWSアカウントを連携させることで、人間ユーザーのID管理をさらに一元化し、セキュリティと利便性を両立させる計画を進めています。このような継続的な取り組みが、安全で効率的なクラウド運用を実現するためのベストプラクティスとなります。

出典：AWS