IAMのベストプラクティスとMFA

導入

IAMは「設定できる」ことと「安全に設定されている」ことが別問題です。AWSは長年の運用経験から、守るべきベストプラクティスを明確に示しています。

説明

IAMを安全に使うための代表的なベストプラクティスは、次の通りです。

• ルートユーザーを日常利用しない … 第2章で学んだ通り、ルートユーザーは初期設定や特別な操作以外では使わず、日々の作業はIAMユーザーやロールで行う。
• MFA（多要素認証／Multi-Factor Authentication）を有効化する … パスワード（知っているもの）に加えて、スマートフォンアプリが生成するワンタイムコードやセキュリティキー（持っているもの）を要求し、パスワード漏えいだけでは突破されないようにする。特にルートユーザーと管理者権限を持つIAMユーザーには必須。
• 最小権限の原則を徹底する … 「とりあえず全部許可」ではなく、業務に必要な操作だけを許可する。
• アクセスキーを適切に管理する … プログラムからの認証に使うアクセスキーは、コードに直接書き込まず、不要になったら削除・定期的にローテーションする。
• 人にはユーザーではなくロールを使わせる … 社員が複数のAWSアカウントを行き来する場合も、ユーザーを増やすのではなくロールを引き受ける形にすることで、権限の一元管理がしやすくなる。
• IAM Identity Center（旧AWS SSO）で一元管理する … 複数のAWSアカウントにまたがる従業員のアクセスを1か所（シングルサインオン）でまとめて管理できる。
• パスワードポリシーを設定する … アカウント全体に対して「最低文字数」「大文字・数字・記号を含める」「過去のパスワードの再利用禁止」「有効期限（定期変更）」といったルールを強制できる。弱いパスワードを人の意識に任せず、仕組みで防ぐ。
• 定期的に棚卸しする … IAM認証情報レポート（アカウント内の全ユーザーのMFA有効化状況・パスワードやアクセスキーの最終使用日を一覧でダウンロード）とアクセスアドバイザー（そのユーザーが実際に使ったサービス）を見れば、使われていない権限や放置されたアクセスキーを見つけられる。
• 認証情報をコードに書かず、専用の場所に保管する … データベースのパスワードやAPIキーは AWS Secrets Manager（自動ローテーションに対応）や AWS Systems Manager のパラメータストア に預け、アプリは実行時に取り出す。

もう一つ、社員のIDをどこで管理するかという観点でアイデンティティフェデレーション（ID連携）を押さえましょう。すでに社内にMicrosoft Active Directoryや外部のIDプロバイダ（IdP）があるなら、AWS用にIAMユーザーを作り直す必要はありません。フェデレーションを使えば、既存のIDでサインインし、AWS側では一時的な認証情報でIAMロールを引き受ける形になります。

flowchart TD
    A["ルートユーザーは初期設定のみ"] --> E["安全なIAM運用"]
    B["全ユーザーにMFA"] --> E
    C["最小権限のポリシー"] --> E
    D["アクセスキーは最小限・定期ローテーション"] --> E

具体例

あるIT企業で、管理者のIAMユーザーのパスワードがフィッシング詐欺で盗まれる事件が起きかけました。攻撃者は盗んだパスワードでログインを試みます。

• MFAが無効だったら … パスワードだけで管理者権限にログインされ、全リソースを好き放題にされていたはず。
• MFAが有効だったので … ログインにはパスワードに加えて、管理者のスマホアプリが生成する6桁のワンタイムコードが必要。攻撃者はスマホを持っていないので突破できず、侵入を防げた。

この一件を機に、この会社はベストプラクティスを徹底しました。

1. ルートユーザーは金庫にしまい、普段はIAMユーザーで作業
2. 全員（特に管理者）にMFAを必須化
3. 各自の権限を「必要な分だけ」に見直し
4. コードに直書きされていたアクセスキーを廃止し、ロールに切り替え

「パスワードは漏れるもの」と考え、漏れても突破されない二重の鍵（MFA）をかけておく——これがアカウント保護の第一手です。

読んでみよう

CLF試験では「アカウントを保護する最初の一手は？」と問われたら、まずMFAの有効化とルートユーザーの非常用化を思い出しましょう。