AWS CLIでIAMユーザーを確実に管理！確認と運用のコツ

AWS CLIによるIAMユーザー管理の全体像と基本コマンド

IAMの基本概念と最小権限の原則

AWSクラウド環境のセキュリティを堅牢にするためには、AWS Identity and Access Management（IAM）の理解が不可欠です。IAMは、AWSリソースへのアクセスを安全に管理するためのサービスで、主に「ユーザー（User）」「グループ（Group）」「ロール（Role）」「ポリシー（Policy）」の4つの構成要素で成り立っています。ユーザーは人やアプリケーション、グループはユーザーの集合、ロールはサービスやアプリケーションに一時的な権限を与える仕組み、ポリシーはJSON形式で権限を定義するルールブックです。経済産業省やIPA（情報処理推進機構）等の公的機関も、最小限の権限のみを付与する「最小権限の原則」を強く推奨しています。これは、IAMユーザーに必要以上の権限を与えないことで、万が一認証情報が漏洩した場合でも、被害を最小限に抑えるための基本原則です。AWS CLI（Command Line Interface）を活用することで、この原則に基づいた厳密な管理と定期的な棚卸しを効率的に実施できます。

AWS CLIのセットアップと基本的なコマンド

AWS CLIを初めて利用する場合、まず環境にインストールし、AWSアカウントの認証情報を設定する必要があります。ターミナルやコマンドプロンプトで`aws configure`コマンドを実行し、アクセスキーID、シークレットアクセスキー、デフォルトリージョン、出力フォーマットを入力することでセットアップが完了します。この際、最も重要な注意点として、ルートユーザーのアクセスキーは絶対に作成してはなりません。ルートユーザーはAWSアカウントの全ての権限を持つため、アクセスキーが漏洩すると甚大な被害につながる可能性があります。日常的な管理にはIAMユーザーを使用し、最小権限の原則に基づいた権限を付与してください。IAMユーザー管理の基本的なCLIコマンドとしては、例えば`aws iam list-users`で全IAMユーザーを一覧表示したり、`aws iam get-user`で特定のユーザーの詳細情報を確認したりするコマンドがあります。これらのコマンドを使いこなすことで、IAM環境の現状を素早く把握し、問題点を特定できます。

IAMユーザー作成と権限付与のCLI手順

AWS CLIを使用すれば、IAMユーザーの作成から権限付与までの一連の作業を効率的に行えます。新しいIAMユーザーを作成するには、`aws iam create-user –user-name `コマンドを実行します。作成後、このユーザーがAWSコンソールにログインするためのパスワードが必要であれば、`aws iam create-login-profile –user-name –password –password-reset-required`で設定できます。次に、作成したユーザーに権限を付与しますが、個別のユーザーに直接ポリシーを付与するよりも、関連するユーザーをグループにまとめ、そのグループにポリシーをアタッチするのが推奨される運用方法です。例えば、`aws iam create-group –group-name `でグループを作成し、`aws iam add-user-to-group –user-name –group-name `でユーザーをグループに追加します。その後、`aws iam attach-group-policy –group-name –policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess`のように、グループに管理ポリシーをアタッチすることで、複数のユーザーに一括で権限を付与でき、管理が容易になります。

出典：IAM でのセキュリティのベストプラクティス、サイバーセキュリティ経営ガイドライン Ver 3.0

IAMユーザー情報取得と一覧表示の具体的なステップ

全IAMユーザーの一覧と詳細情報の取得

AWS環境におけるIAMユーザーの現状を把握することは、セキュリティ管理の第一歩です。AWS CLIを使用すると、アカウント内の全IAMユーザーのリストや、個々のユーザーの詳細情報を簡単に取得できます。全IAMユーザーを一覧表示するには、`aws iam list-users`コマンドを実行します。このコマンドは、ユーザー名、ARN（Amazon Resource Name）、作成日時などの基本情報を返します。さらに、特定のユーザーに関する詳細な情報が必要な場合は、`aws iam get-user –user-name `コマンドを利用します。これによって、ユーザーIDや作成日時といったメタデータに加え、アタッチされている管理ポリシーやインラインポリシーの有無も確認できます。ユーザーに直接アタッチされた管理ポリシーを確認するには、`aws iam list-attached-user-policies –user-name `を、インラインポリシーを確認するには`aws iam list-user-policies –user-name `を利用します。これらの情報をもとに、各ユーザーの権限が適切かどうかを定期的に評価することが重要です。

アクセスキーの使用状況とMFA設定の確認

IAMユーザーのアクセスキーや多要素認証（MFA）の設定状況は、AWSアカウントのセキュリティレベルを測る重要な指標です。`aws iam list-access-keys –user-name `コマンドを使用すると、特定のユーザーに紐づくアクセスキーの一覧とそのステータス（Active/Inactive）を確認できます。しかし、より詳細な情報、特に「アクセスキーの最終使用日時」や「MFAの有効化状況」を確認するためには、前述の`aws iam get-credential-report`コマンドが非常に強力です。このレポートは、アクセスキーが最後に使用されたサービスやリージョンまで詳細に表示するため、長期間使用されていないアクセスキーや、予期せぬ場所での使用履歴を特定するのに役立ちます。また、Datadogの2022年調査によれば、AWSコンソールへのアクセス権を持つIAMユーザーの10%がMFAを使用していなかったとされています。`aws iam list-mfa-devices –user-name `コマンドでユーザーに紐づくMFAデバイスを確認し、MFAが未設定のユーザーには速やかに設定を促すことが、セキュリティを大幅に強化します。

不要なIAMユーザーとアクセスキーの特定と削除

未使用のIAMユーザーやアクセスキーは、セキュリティリスクを高める要因となります。これらを定期的に特定し、適切に削除することが運用上非常に重要です。不要なIAMユーザーを特定する際も、`aws iam get-credential-report`コマンドで最終ログイン日時やアクセスキーの最終利用日時が古いユーザーを洗い出すのが効率的です。もし、長期間利用されていないユーザーやアクセスキーが見つかった場合は、その必要性を関係者に確認しましょう。不要と判断されたアクセスキーは、まず`aws iam update-access-key –access-key-id –status Inactive –user-name `で無効化し、一定期間影響がないことを確認した後に`aws iam delete-access-key –access-key-id –user-name `で削除するのが安全な手順です。同様に、不要と判断されたIAMユーザーも、そのユーザーに紐づくポリシーやアクセスキーを全て削除した後、`aws iam delete-user –user-name `で削除します。これらの作業を定期的に実施することで、アタックサーフェス（攻撃対象領域）を最小限に保つことができます。

出典：AWSセキュリティの現状、AWS セキュリティ認証情報

特定の状況下でのIAMユーザー管理と連携活用例

一時的なアクセス権限付与とIAMロールの活用

AWSのセキュリティベストプラクティスでは、長期間有効な静的な認証情報（アクセスキー）の使用を可能な限り避け、IAMロールによる一時的な認証情報を利用することが強く推奨されています。これは、静的なアクセスキーが漏洩した場合の被害が甚大であるためです。IAMロールは、特定のAWSサービスや別のAWSアカウント、またはオンプレミスのアプリケーションなどに一時的な権限を付与する仕組みです。例えば、EC2インスタンスがS3バケットにアクセスする必要がある場合、EC2インスタンスにIAMロールをアタッチすることで、アクセスキーをインスタンス内に保存することなく安全にS3へのアクセス権限を付与できます。AWS CLIからIAMロールを使用するには、まず`aws sts assume-role –role-arn –role-session-name `コマンドで一時的な認証情報を取得します。このコマンドを実行すると、アクセスキーID、シークレットアクセスキー、セッショントークンが発行され、これらを環境変数に設定することで、ロールの権限でCLI操作が可能になります。この一時的な認証情報は、指定した期間（最長12時間）が経過すると自動的に失効するため、セキュリティが大幅に向上します。

グループポリシーによる効率的な権限管理

大規模な組織や多くのIAMユーザーが存在する環境では、個々のユーザーに直接ポリシーをアタッチするよりも、IAMグループを活用した権限管理が非常に効率的です。IAMグループは、複数のIAMユーザーをまとめるためのコンテナであり、グループにポリシーをアタッチすることで、そのグループに属する全てのユーザーに同じ権限を付与できます。例えば、開発チーム、運用チーム、監査チームといった役割ごとにグループを作成し、それぞれの役割に応じたポリシーをグループにアタッチします。これにより、新しいユーザーがチームに加わった際には、該当するグループに追加するだけで、必要な権限を自動的に付与できます。ユーザーがチームを異動する際も、既存のグループから外し、新しいグループに追加するだけで権限の変更が可能です。`aws iam list-groups-for-user –user-name `コマンドを使用すれば、特定のユーザーがどのグループに属しているかを確認できます。グループを適切に活用することで、権限管理の複雑さを軽減し、一貫性とセキュリティレベルを維持しやすくなります。

CLIとスクリプト連携による自動化と監査

AWS CLIの真価は、シェルスクリプトやPythonなどのプログラミング言語と連携させることで、IAM管理作業の自動化と定期的な監査を可能にする点にあります。例えば、`aws iam get-credential-report`コマンドを定期的に実行し、その結果を解析するスクリプトを作成することで、長期間使用されていないアクセスキーやMFAが未設定のユーザーを自動的に検出できます。検出された問題ユーザーに対して、通知メールを送信したり、アクセスの無効化を提案したりする自動化フローを構築することも可能です。また、新しいIAMユーザー作成時に特定のグループへ自動的に追加するスクリプトや、ユーザーが退職した際に自動的にアカウントを無効化・削除するスクリプトも有効です。これらの自動化により、手動での作業ミスを減らし、運用負荷を大幅に軽減しながら、常に最新のセキュリティ基準を維持することができます。定期的な監査レポートの自動生成と解析は、セキュリティインシデントの早期発見にも繋がり、組織全体のセキュリティ体制強化に貢献します。

出典：AWSアカウントのセキュリティを改善するための10か条

IAMユーザー管理におけるセキュリティと運用の注意点

ルートユーザーの厳重な保護と最小権限の原則の徹底

AWSアカウントのルートユーザーは、アカウント内の全てのサービスとリソースに対して無制限のアクセス権を持つため、その管理は最も厳重に行う必要があります。具体的には、ルートユーザーのアクセスキーは絶対に作成せず、日常的なAWS操作には決して使用しないことが鉄則です。また、ルートユーザーには強力な多要素認証（MFA）を必須とし、認証情報は金庫に保管するなどの物理的セキュリティ対策も講じることが推奨されます。AWSの「責任共有モデル」において、物理インフラのセキュリティはAWSの責任ですが、IAMユーザーの設定ミスや認証情報の漏洩は「ユーザー側の責任」となるため、この原則の理解は非常に重要です。日常的に使用するIAMユーザーに対しても、「最小権限の原則」を徹底し、職務上必要な最低限の権限のみを付与し、不必要な権限は速やかに削除することで、万が一のインシデント発生時の被害範囲を限定できます。

多要素認証（MFA）の必須化と運用ルール

多要素認証（MFA）は、IAMユーザーのセキュリティを格段に向上させる最も効果的な手段の一つです。パスワードだけでは漏洩リスクがあるため、物理的なデバイスやアプリケーションによる第二の認証要素を組み合わせることで、不正アクセスを困難にします。Datadogの調査（2022年時点）では、AWSコンソールにアクセスするユーザーの10%がMFAを使用していなかったと報告されており、これは潜在的なセキュリティリスクを示唆しています。組織内の全てのIAMユーザーに対し、AWSコンソールへのログイン時およびCLI/APIアクセス時にMFAを必須化することを強く推奨します。MFAを導入するだけでなく、運用ルールも明確に定める必要があります。例えば、MFAデバイスの紛失や破損時の復旧手順、新しいMFAデバイスの登録方法などを事前に文書化し、ユーザーがスムーズに対応できるよう準備しておくことが重要です。`aws iam create-virtual-mfa-device`などのCLIコマンドを使って、仮想MFAデバイスの管理を行うことも可能です。

定期的な棚卸しとセキュリティインシデント対策

IAMユーザーの定期的な棚卸しは、セキュリティリスクを継続的に低減するために不可欠な運用プロセスです。不要になったIAMユーザー、未使用のアクセスキー、そして過剰な権限が付与されたポリシーは、放置されるとサイバー攻撃の足がかりとなる可能性があります。地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省、2024年10月）でも、サイバー攻撃に対処するための基本方針策定が義務付けられるなど、情報セキュリティに対する意識の高まりが伺えます。AWS CLIを活用し、`aws iam get-credential-report`などで得られる情報を基に、少なくとも四半期に一度はIAM環境全体のレビューを実施しましょう。また、アクセスキーの定期的なローテーション（更新）も重要な対策です。加えて、AWS CloudTrailを活用してIAM関連のAPIアクティビティを常に監視し、異常なログイン試行や権限変更があった場合にはアラートが発動するような仕組みを構築することが、セキュリティインシデントの早期検知と対応に繋がります。これにより、潜在的な脅威を未然に防ぎ、迅速に対応できる体制を整えることができます。

出典：地方公共団体における情報セキュリティポリシーに関するガイドライン（令和6年10月版）、AWSセキュリティの現状

【ケース】不要なアクセスキー放置によるセキュリティインシデント回避

架空のケーススタディ：未使用アクセスキーの特定

これは架空のケースですが、よくあるシナリオとして「以前開発チームに所属していた退職者AさんのIAMユーザーアカウントに紐づくアクセスキーが、削除されずに放置されていた」という状況を想定してみましょう。退職から半年以上が経過し、誰もそのアクセスキーを使用していないにも関わらず、有効な状態のまま存在していました。もしこのアクセスキーが悪意のある第三者に漏洩した場合、Aさんに付与されていた権限（例えば、S3バケットへの読み書き権限やEC2インスタンス操作権限など）が不正に利用され、機密情報の流出、不正なリソースの作成による多額の請求発生、さらには他のシステムへの攻撃の踏み台にされるといった甚大なセキュリティインシデントに発展する可能性があります。このようなリスクを回避するためには、AWS CLIを用いた定期的なIAM監査が極めて重要になります。具体的には、`aws iam get-credential-report`コマンドを定期的に実行し、レポートの中から最終利用日時が「N/A」または非常に古いアクセスキーを特定することが第一歩となります。

CLIによるアクセスキー無効化・削除の手順

上記のケースで、長期間未使用のアクセスキーを特定したら、次のステップは適切な手順でこれを無効化し、最終的に削除することです。まず、緊急時にそのアクセスキーがこれ以上利用されないように、無効化の措置を取ります。`aws iam update-access-key –access-key-id –status Inactive –user-name `コマンドを実行することで、アクセスキーを即座に無効化できます。この状態であれば、キーは無効でありながらAWS環境からは削除されていないため、万が一影響範囲の確認漏れがあった場合でも、再度「Active」に戻すことが可能です。一定期間（例えば1週間など）無効化した状態で運用し、システムへの影響がないことを十分に確認できたら、最終的にアクセスキーを削除します。`aws iam delete-access-key –access-key-id –user-name `コマンドで削除を実行します。削除後は、そのアクセスキーを復元することはできないため、実行前には必ず最終確認を行うようにしてください。

定期的なIAM監査とポリシー見直しによる予防策

不要なアクセスキーの放置によるセキュリティインシデントを未然に防ぐためには、単発の対処だけでなく、体系的な予防策の実施が不可欠です。組織として、月に一度または四半期に一度の定期的なIAM監査を義務付け、その実施状況を記録するルールを確立しましょう。監査の際には、退職者のアカウントや一時的なプロジェクトで作成されたアカウントが適切にクリーンアップされているか、既存のIAMユーザーに付与されているポリシーが現在の職務内容と合致しているか、過剰な権限がないかなどを入念に確認します。`aws iam list-attached-user-policies`や`aws iam simulate-principal-policy`などのCLIコマンドを組み合わせることで、ポリシーの有効性や影響範囲を事前にシミュレーションし、意図しない権限を特定することもできます。また、入社・退社・異動時にIAMアカウントの作成・変更・削除プロセスを自動化するスクリプトを導入し、手作業によるミスや漏れを防ぐことも有効な予防策です。このような継続的な取り組みを通じて、組織全体のセキュリティガバナンスを強化し、潜在的なリスクを低減できるでしょう。

出典：AWSアカウントのセキュリティを改善するための10か条