AWS MFA でセキュリティを強化

By /

AWS MFA でセキュリティを強化 – アカウント保護のための究極ガイド

はじめに – なぜAWSアカウントのセキュリティが重要なのか

クラウドコンピューティングは現代のビジネスにおいて不可欠な技術となりました。Amazon Web Services (AWS) は、その柔軟性、スケーラビリティ、そして豊富なサービス群により、世界中の企業や開発者に利用されています。AWSを利用することで、企業はインフラストラクチャの管理から解放され、ビジネスの本質的な部分に集中できるようになります。

しかし、AWSアカウントは非常に価値の高い資産です。機密性の高いデータ、アプリケーションのソースコード、顧客情報、そしてサービスを動かすための計算リソースやストレージリソースがそこに集約されています。もしAWSアカウントが第三者によって不正にアクセスされた場合、以下のような深刻な被害が発生する可能性があります。

  • 情報漏洩: S3バケットに保管された個人情報や企業秘密が外部に流出する。
  • リソースの不正利用: EC2インスタンスが仮想通貨マイニングに悪用される、高額なマネージドサービスが無駄に利用されるなど、予期せぬ高額請求が発生する。
  • サービスの停止・破壊: 稼働中のアプリケーションやインフラストラクチャが改ざんされたり、削除されたりする。
  • マルウェア配布元となる: 侵害された環境がマルウェアの配布やサイバー攻撃の踏み台として悪用される。
  • 風評被害: アカウント侵害の事実が公になり、企業の信頼性が失われる。

これらのリスクを避けるためには、AWSアカウントへのアクセスを最大限に保護することが不可欠です。AWSは「責任共有モデル」に基づいています。AWSはクラウド自体のセキュリティ（リージョン、アベイラビリティゾーン、エッジロケーション、ハードウェア、ソフトウェア、ネットワークなど）に責任を持ちますが、クラウド内でのセキュリティ（ゲストOS、アプリケーション、データ、そしてアカウントやIDの管理）については、利用者が責任を持つ必要があります。アカウントへのアクセス制御は、この責任共有モデルにおいて利用者が果たすべき最も基本的な、そして最も重要な責任の一つです。

AWSアカウントを保護するための最初の、そして最も効果的なステップの一つが、多要素認証（Multi-Factor Authentication, MFA）の導入です。この記事では、AWS MFAがなぜ重要なのか、どのような種類があるのか、そしてどのように設定し、運用していくべきなのかを、詳細かつ実践的に解説します。

パスワード認証の限界 – なぜMFAが必要なのか

多くのシステムにおいて、ユーザー認証は主に「IDとパスワード」の組み合わせに依存しています。これは「知識情報」という一つの要素に基づいた認証方法です。パスワードは、ユーザーが覚えている必要があるため便利ですが、その手軽さゆえに多くの脆弱性を抱えています。

  • パスワードの推測・辞書攻撃・ブルートフォース攻撃: 短いパスワードやよく使われる単語、あるいは個人情報から推測しやすいパスワードは、これらの攻撃手法によって容易に破られてしまいます。攻撃者は大量のIDとパスワードの組み合わせを試行することで、不正ログインを試みます。
  • パスワードの使い回し: 多くのユーザーは複数のウェブサイトやサービスで同じ、あるいは類似したパスワードを使い回しています。もしそのうちの一つで情報漏洩が発生し、IDとパスワードの組み合わせが流出した場合、使い回している他のすべてのアカウントが危険に晒されます。これは「クレデンシャルスタッフィング」と呼ばれる攻撃手法で、流出した認証情報リストを使って他のサービスへの不正ログインを試みるものです。
  • フィッシング攻撃: 攻撃者は本物そっくりの偽サイトや偽メールを作成し、ユーザーを騙してIDやパスワードを入力させようとします。ユーザーが騙されて認証情報を入力してしまうと、攻撃者はその情報を使って正規のサービスにログインできてしまいます。
  • マルウェアによるキーロギング: ユーザーのPCやスマートフォンがマルウェアに感染した場合、キーロガーによって入力されたIDやパスワードが攻撃者に送信されてしまうリスクがあります。

パスワード単独の認証では、これらの攻撃手法に対して非常に脆弱です。一度パスワードが漏洩したり、破られたりした場合、攻撃者は正規のユーザーになりすまして自由にアカウントへアクセスできてしまいます。AWSのような機密性の高い情報を扱うプラットフォームにおいて、パスワード単独認証はもはや十分なセキュリティ対策とは言えません。

ここで必要となるのが、認証に複数の異なる要素を組み合わせる多要素認証（MFA）です。MFAを導入することで、たとえパスワードが漏洩したとしても、攻撃者は他の要素を持っていないため、アカウントへの不正ログインを阻止することができます。

多要素認証（MFA）とは

多要素認証（MFA）は、ユーザー認証を行う際に、以下の3つの異なるカテゴリのうち、少なくとも2つ以上の要素を組み合わせて認証を行うセキュリティ手法です。

  1. 知識情報 (Something you know): ユーザー自身だけが知っている情報。
    • パスワード
    • PINコード
    • 秘密の質問とその回答
  2. 所持情報 (Something you have): ユーザー自身だけが持っている物理的なもの。
    • スマートフォン（SMSで受信するワンタイムパスワード、認証アプリ）
    • ハードウェアトークン
    • セキュリティキー
    • キャッシュカード、クレジットカード
  3. 生体情報 (Something you are): ユーザー自身の身体的な特徴。
    • 指紋
    • 顔認証
    • 虹彩認証
    • 声紋

例えば、「パスワード」と「スマートフォンに表示されるワンタイムパスワード（TOTP）」の組み合わせは、「知識情報」と「所持情報」の2つの要素を用いた多要素認証です。また、「PINコード」と「指紋認証」の組み合わせは、「知識情報」と「生体情報」の組み合わせです。

なぜ複数の要素を組み合わせる必要があるのでしょうか？それは、ある一つの要素が破られたり、盗まれたりしても、他の要素は影響を受けない可能性が高いからです。例えば、パスワードがフィッシングで盗まれたとしても、攻撃者はユーザーのスマートフォンや指紋を持っていないため、アカウントにアクセスできません。逆に、スマートフォンを紛失したとしても、攻撃者はパスワードを知らないため、アカウントにアクセスできません。このように、異なる性質を持つ要素を組み合わせることで、セキュリティのレベルを飛躍的に向上させることができます。

多要素認証は、今日のサイバー攻撃の脅威に対して、アカウントを保護するための最も効果的かつ基本的な対策の一つとして広く推奨されています。

AWSにおけるMFAの種類と特徴

AWS Identity and Access Management (IAM) は、ユーザー、グループ、およびロールを作成し、AWSリソースへのアクセスを制御するためのサービスです。IAMでは、様々な種類のMFAデバイスを認証の第二要素として利用することができます。AWSでサポートされているMFAデバイスには、主に以下の種類があります。

1. 仮想MFAデバイス (Virtual MFA Devices)

これは、RFC 6238で定義されている時間ベースワンタイムパスワード（TOTP: Time-based One-Time Password）アルゴリズムを実装したスマートフォンアプリケーションです。ユーザーのスマートフォンなどのデバイス上で動作し、約30秒ごとに新しい6桁のワンタイムパスワード（OTP）を生成します。AWSへのログイン時など、認証が必要な際に、ユーザーはこのアプリに表示されているOTPを入力します。

  • 仕組み: AWS側のサーバーと仮想MFAアプリは、共有シークレットキーと現在の時刻を基に、同じアルゴリズムでOTPを生成します。生成されたOTPが一致すれば認証成功となります。
  • 代表的なアプリ:
    • Google Authenticator (iOS, Android)
    • Authy (iOS, Android, デスクトップ)
    • Microsoft Authenticator (iOS, Android)
    • LastPass Authenticator (iOS, Android)
    • といった、TOTPに対応した多くの認証アプリが利用可能です。
  • メリット:
    • コスト: 専用のハードウェアを購入する必要がなく、既存のスマートフォンにアプリをインストールするだけで利用できるため、非常に安価あるいは無料で導入できます。
    • 導入容易性: アプリをダウンロードし、AWSマネジメントコンソールに表示されるQRコードをスキャンするだけで簡単に設定できます。
    • 利便性: 多くのユーザーが常に携帯しているスマートフォンを利用できるため、使いやすいです。
  • デメリット:
    • スマートフォンの紛失・盗難・故障リスク: スマートフォン自体が使えなくなると、MFA認証ができなくなります。
    • スマートフォンのマルウェア感染リスク: 高度なマルウェアによっては、MFAアプリの情報や表示されるOTPを窃取される可能性がゼロではありません。
    • 時刻同期の必要性: TOTPは時間に依存するため、スマートフォンとAWSサーバーの時刻が大きくずれていると認証に失敗する可能性があります。
    • フィッシング耐性: ユーザーが偽サイトでOTPを入力してしまうフィッシング攻撃に対しては、ハードウェアセキュリティキーに比べて耐性が低いとされています。

2. ハードウェアMFAデバイス (Hardware MFA Devices)

これは、物理的なデバイスとして提供されるMFAトークンです。大きく分けて二つのタイプがあります。

  • ハードウェアTOTPトークン (CodeKey): 物理的なキーフォブ（キーホルダー）型デバイスで、ディスプレイに数秒ごとに変わる6桁のOTPが表示されます。ユーザーは表示されたOTPをAWSの認証画面に入力します。

    • 仕組み: 仮想MFAと同様にTOTPアルゴリズムに基づいています。デバイス内部にシークレットキーと時刻同期機能を持っています。
    • メリット:
      • スマートフォンから独立しているため、スマートフォンのバッテリー切れや故障、マルウェア感染の影響を受けません。
      • OTP生成機能以外の機能を持たないため、攻撃対象になりにくいです。
    • デメリット:
      • 購入コスト: デバイスごとに費用がかかります（Amazonなどで購入可能）。
      • 持ち運びの必要性: スマートフォンとは別に、デバイスを常に携帯する必要があります。
      • 紛失・故障リスク: デバイス自体を紛失したり、故障したりする可能性があります。
      • 電池寿命: 電池が切れると使えなくなります（通常は数年持ちます）。
      • フィッシング耐性: 仮想MFAと同様に、偽サイトでOTPを入力してしまうフィッシング攻撃に対しては耐性が低いとされています。
    • 注意点: AWSではCodeKeyを直接販売していませんが、互換性のあるサードパーティ製品を利用できます。登録時にはデバイスのシリアル番号とOTPを入力する必要があります。

  • U2F/FIDOセキュリティキー (Security Key): Universal 2nd Factor (U2F) や FIDO2 という標準規格に準拠したUSBデバイスです。PCのUSBポートに挿入したり、NFCやBluetoothで接続したりして使用します。ユーザーはログイン時に物理的なボタンを押すなどの操作を行います。

    • 仕組み: 公開鍵暗号方式を利用しており、認証時にはウェブサイト（ここではAWS）のドメイン情報を含むチャレンジに対して、デバイスが秘密鍵で署名します。これにより、認証情報がどのサイトに対して発行されたものかを検証できるため、フィッシング攻撃に強いのが特徴です。最新のFIDO2規格は、単体でパスワードレス認証（パスワードの代わりにセキュリティキーだけで認証）にも対応可能ですが、AWSではMFA（第二要素）として利用します。
    • 代表的な製品: YubiKey (Yubico社), Titan Security Key (Google社) など。
    • メリット:
      • 高いフィッシング耐性: 認証時にアクセスしているサイトのドメイン情報を検証するため、偽サイトでキーを操作しても認証は成功しません。
      • 使いやすさ: OTPを手で入力する必要がなく、デバイスを接続してボタンを押すなどの簡単な操作で認証が完了します。
      • 高いセキュリティ: 認証情報がデバイスから漏洩するリスクが非常に低いです。
      • 電池不要: USB接続タイプは通常、電池は不要です。
    • デメリット:
      • 購入コスト: ハードウェアTOTPトークンよりはやや高価な場合があります。
      • 対応デバイス/ブラウザの確認: セキュリティキーを利用するには、利用するPCのOS、ブラウザ（Chrome, Firefox, Edge, Safariなど）、そしてAWSマネジメントコンソールがFIDO/WebAuthn標準に対応している必要があります（主要な環境では概ね対応しています）。
      • 持ち運びの必要性: デバイスを常に携帯する必要があります。
      • 紛失リスク: デバイスを紛失するとMFA認証ができなくなります。
      • 複数のデバイスでの利用: セキュリティキーは通常、登録した特定のPCやブラウザでの利用がスムーズです。別のPCやスマートフォンからアクセスする場合、対応するデバイス（同じセキュリティキー、または別のセキュリティキーを複数登録）が必要になります。
MFAデバイスの種類 仮想MFAデバイス (TOTPアプリ) ハードウェアTOTPトークン (CodeKey) セキュリティキー (U2F/FIDO)
認証方法 アプリ表示のOTPを手入力 デバイス表示のOTPを手入力 デバイス操作 (ボタン押し等)
要素 所持情報 所持情報 所持情報
フィッシング耐性 △ 低い △ 低い ◎ 高い
コスト ◎ 安価～無料 〇 中程度 〇 中程度
利便性 (携帯) ◎ スマートフォンで完結 〇 専用デバイスが必要 〇 専用デバイスが必要
紛失/故障リスク △ スマートフォン依存 △ デバイス単体 △ デバイス単体
電池 スマートフォンに依存 必要 (数年寿命) 不要 (USB接続タイプ)
対応環境 TOTPアプリがインストール可能 AWSが対応していればOK OS, ブラウザ, AWSの対応必須
登録可能な数 (IAM) 1個 1個 最大8個
登録可能な数 (Root) 1個 1個 最大1個

どの種類のMFAデバイスを選択するかは、セキュリティ要件、コスト、利便性、そして利用者の技術レベルなどを考慮して決定します。一般的には、フィッシング耐性の高いセキュリティキーが推奨されますが、手軽さやコストを重視する場合は仮想MFAデバイスがよく利用されます。ハードウェアTOTPトークンは、スマートフォンを業務に使用しない場合などに選択肢となります。

重要なポイント: ルートユーザーには、仮想MFAデバイス、ハードウェアTOTPトークン、セキュリティキーのいずれかを1つ登録できます。IAMユーザーには、仮想MFAデバイス、ハードウェアTOTPトークン、そしてセキュリティキーを合計で最大8個まで登録できます。異なる種類のデバイスを複数登録しておくことで、一方を紛失・故障した場合でももう一方のデバイスで認証できるため、可用性が向上します。

AWS MFAの設定方法 – ステップバイステップガイド

AWSアカウントにMFAを設定することは、セキュリティを大幅に向上させるための最も重要なステップです。特にAWSアカウント作成直後のルートユーザーへのMFA設定は、真っ先に実行すべき必須タスクです。

最も重要なルートユーザーへのMFA設定

AWSアカウントを作成した際に最初に利用できるのが「ルートユーザー」です。ルートユーザーはアカウントに対するすべての権限（サービスへのフルアクセス、アカウント設定の変更、サポートプランの変更、支払情報の確認など）を持っています。ルートユーザーは非常に強力な権限を持つため、日常的な操作には使用せず、ごく限られた管理タスク（例えば、最初のIAMユーザー作成、アカウント設定の変更、請求情報の確認、サポートへの連絡など）にのみ使用し、強固に保護する必要があります。 ルートユーザーの認証情報（メールアドレスとパスワード）が漏洩することは、アカウント全体の侵害に直結します。そのため、ルートユーザーには必ずMFAを設定する必要があります。

ルートユーザーにMFAを設定する手順は以下の通りです。（ここでは仮想MFAデバイス（TOTPアプリ）を例に説明しますが、ハードウェアMFAデバイスやセキュリティキーの場合も基本的な流れは同じです。）

前提条件:

  • AWSアカウントのルートユーザーとしてサインインできること。
  • スマートフォンに仮想MFAに対応した認証アプリ（Google Authenticator, Authyなど）がインストールされていること。
  • インターネットに接続できること。

設定手順:

  1. AWSマネジメントコンソールにルートユーザーとしてサインインします。
    • サインイン画面でアカウントのメールアドレスを入力し、「次へ」をクリックします。
    • パスワードを入力し、「サインイン」をクリックします。
  2. 画面右上のアカウント名をクリックし、「セキュリティ認証情報」を選択します。
    • または、IAMダッシュボードに移動し、左側のナビゲーションペインから「セキュリティ認証情報」を選択します。
  3. 「多要素認証 (MFA)」セクションを見つけ、「MFAをアクティブ化する」をクリックします。
  4. 「MFA デバイスの管理」ダイアログが表示されます。
    • 「ルートユーザー向け MFA デバイス」セクションが表示されていることを確認します。（もしIAMユーザーでログインしている場合は、IAMユーザー向けセクションが表示されます。必ずルートユーザーで設定していることを確認してください。）
    • 「デバイスの割り当て」で、設定したいMFAデバイスの種類を選択します。
      • 「仮想MFAデバイス」
      • 「ハードウェアMFAデバイス」
      • 「セキュリティキー」
    • ここでは「仮想MFAデバイス」を選択し、「続行」をクリックします。
  5. 仮想MFAデバイスの設定画面が表示されます。
    • 「デバイス名」は任意で入力できます（例: “MyPhone-MFA”）。
    • 「認証アプリをインストール」の項目で、推奨されるアプリがリストアップされています。インストール済みであればこのステップはスキップします。
    • 「QR コードの表示」をクリックします。 QRコードと設定キーが表示されます。
  6. スマートフォンの認証アプリを開き、新しいアカウントを追加します。
    • 多くのアプリでは「+」ボタンなどをタップし、「QRコードをスキャン」または「手動でキーを入力」を選択できます。
    • 推奨はQRコードのスキャンです。 スマートフォンのカメラでPC画面に表示されているQRコードをスキャンします。アプリが自動的にアカウント情報（AWSアカウントIDなど）とシークレットキーを読み込み、登録します。
    • QRコードが読み取れない場合や手動で設定する場合は、AWS画面に表示されている設定キーをアプリに手入力します。アカウント名は「AWS Root Account」などと分かりやすい名前で設定します。
  7. 認証アプリに表示されたMFAコードを入力します。
    • アプリが新しい6桁のMFAコードを生成し、表示します。
    • AWS設定画面の「MFA コード 1」の欄に、アプリに表示されている現在のMFAコードを入力します。
    • 約30秒後に新しいMFAコードが生成されるので、それが表示されたら「MFA コード 2」の欄に新しいコードを入力します。注意: 30秒以内に2つの異なるコードを入力する必要があるため、コード1を入力したら、コード2が表示されるのを待って素早く入力します。タイミングが重要です。
  8. 「MFA を追加」をクリックします。
  9. 「MFA デバイスが正常に割り当てられました。」というメッセージが表示されれば設定完了です。

これで、ルートユーザーでAWSにサインインする際には、パスワードに加えて、登録したMFAデバイスに表示されるMFAコードの入力が求められるようになります。

ルートユーザーのMFAデバイス紛失・故障時の復旧手順:

ルートユーザーのMFAデバイスを紛失したり、故障したり、交換したりした場合、MFAコードを入力できなくなるため、AWSマネジメントコンソールにサインインできなくなります。このような事態に備え、復旧手順を事前に理解しておくことが非常に重要です。

  1. 代替認証情報の使用: ルートユーザーは複数のMFAデバイスを登録できませんが、設定時に表示されるリカバリーコードや設定キーを安全に保管しておけば、別のデバイスで同じ設定を復元できる場合があります。（ただし、多くの仮想MFAアプリはエクスポート/インポート機能を標準で持っていないため、紛失すると復旧は難しい場合が多いです。ハードウェアMFAも基本的にはデバイスの交換が必要です。）
  2. アカウント復旧プロセス: MFAデバイスを紛失した場合でもサインインできない場合、AWSカスタマーサポートに連絡してアカウントの復旧を依頼する必要があります。
    • AWSサインイン画面の「Sign in using multi-factor authentication」の下にある「Troubleshoot MFA」または「Need help with MFA?」リンクをクリックします。
    • 指示に従って、アカウントのメールアドレスとパスワードを入力し、MFAコードを求められる画面で「Forgot your multi-factor authentication device?」または類似のリンクをクリックします。
    • アカウントの所有者であることを証明するための本人確認プロセスが開始されます。本人確認の方法は複数あり、例えば、アカウント登録時に使用したクレジットカード情報の一部、アカウントに登録されている電話番号へのSMS/音声通話、または公的機関が発行した身分証明書（運転免許証、パスポートなど）の提示を求められる場合があります。
    • 本人確認が成功すると、AWSサポートによってルートユーザーのMFA設定が解除され、パスワードだけでサインインできるようになります。
    • 復旧後は、速やかに新しいMFAデバイスを設定し直してください。
    • 重要: この復旧プロセスは時間がかかる場合があり、また本人確認ができない場合はアカウントへのアクセスを回復できないリスクもあります。そのため、MFAデバイスの紛失には最大限注意し、設定時に表示されるリカバリー情報があれば安全に保管しておくことが望ましいです。

IAMユーザーへのMFA設定

ルートユーザーだけでなく、日常的にAWSを操作するIAMユーザーにもMFAを設定することが強く推奨されます。特に管理者権限を持つユーザーや機密性の高いリソースにアクセスできるユーザーには、MFA設定を必須とすべきです。

IAMユーザーへのMFA設定は、以下のいずれかの方法で行えます。

  • 管理者による設定: IAM管理者がユーザーに代わってMFAデバイスを登録する。
  • ユーザー自身による設定: IAMユーザー自身が、割り当てられたMFAデバイスを自分のアカウントに紐付ける。

一般的には、ユーザー自身にMFAデバイスの設定を行わせるのが管理者の負担も少なく効率的です。

ユーザー自身によるIAMユーザーへのMFA設定手順 (仮想MFAデバイスの例):

  1. IAMユーザーとしてAWSマネジメントコンソールにサインインします。
  2. 画面右上のユーザー名をクリックし、「セキュリティ認証情報」を選択します。
  3. 「多要素認証 (MFA)」セクションを見つけ、「MFA デバイスを割り当て」をクリックします。
  4. 「MFA デバイスを管理」ダイアログが表示されます。
    • 割り当てたいMFAデバイスの種類を選択し、「続行」をクリックします。（ここでは「仮想MFAデバイス」を選択します。）
  5. 仮想MFAデバイスの設定画面が表示されます。
    • デバイス名は任意で入力できます。
    • 「QR コードの表示」をクリックし、表示されたQRコードをスマートフォンの認証アプリでスキャンします。
    • または、設定キーを手入力します。
  6. 認証アプリに表示された2つの連続したMFAコードを入力します。
  7. 「MFA を追加」をクリックします。
  8. 「MFA デバイスが正常に割り当てられました。」というメッセージが表示されれば設定完了です。

これで、このIAMユーザーでAWSにサインインする際に、パスワードに加えてMFAコードの入力が求められるようになります。

補足:

  • IAMユーザーは最大8個のMFAデバイス（仮想MFA、ハードウェアTOTP、セキュリティキーの任意の組み合わせ）を登録できます。複数のデバイスを登録することで、一方のデバイスを紛失・故障した場合でも他のデバイスでサインインできるというメリットがあります。
  • 管理者権限を持つIAMユーザーは、他のIAMユーザーのMFAデバイスを管理（追加、削除、無効化）することも可能です。これはユーザーがMFAデバイスを紛失した場合などに管理者によるサポートを可能にします。

MFAの利用シナリオとIAMポリシーによる強制

MFAを設定するだけでは、必ずしもMFAが要求されるわけではありません。AWSにサインインする際にMFAを必須にしたり、特定のアクションを実行する際にMFA認証済みであることを要求したりするためには、IAMポリシーを適切に設定する必要があります。

ログイン時のMFA要求

最も一般的なMFAの利用シナリオは、AWSマネジメントコンソールへのサインイン時にMFAを要求することです。これにより、パスワードが漏洩しても、MFAデバイスがなければアカウントにアクセスできなくなります。

IAMポリシーによるMFA強制:

IAMポリシーを使用すると、「ユーザーがMFA認証されていない場合、特定のアクション（またはすべてのアクション）を拒否する」というルールを定義できます。これにより、事実上、MFAなしでのサインインや重要な操作をブロックすることができます。

AWSは、IAMポリシーでMFAの状態を判断するための条件キー aws:MultiFactorAuthPresent を提供しています。この条件キーは、ユーザーがセッションの開始時にMFA認証を行っているかどうかを示します。

  • "aws:MultiFactorAuthPresent": "true": セッションがMFA認証済みであることを要求します。
  • "aws:MultiFactorAuthPresent": "false": セッションがMFA認証されていないことを要求します（MFA強制のポリシーでは通常使用しません）。

例1: すべてのAWSアクションに対してMFAを要求するポリシー

このポリシーをIAMユーザーまたはIAMグループにアタッチすると、そのユーザー/グループはMFA認証を行ってサインインしない限り、AWS上のほとんどすべてのアクションを実行できなくなります。

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllActionsIfMfaPresent",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Sid": "DenyAllActionsIfMfaNotPresent",
"Effect": "Deny",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}

  • AllowAllActionsIfMfaPresent: MFA認証済み (aws:MultiFactorAuthPresent が true) の場合に、すべてのアクション (Action: "*")、すべてのリソース (Resource: "*") へのアクセスを許可します。
  • DenyAllActionsIfMfaNotPresent: MFA認証されていない (aws:MultiFactorAuthPresent が false) の場合に、すべてのアクション (Action: "*")、すべてのリソース (Resource: "*") へのアクセスを明示的に拒否します。IAMポリシーはデフォルトでは拒否されるため、明示的な許可 (Allow) と組み合わせることで、MFA認証済みの場合のみ許可する、という制御を実現します。しかし、よりシンプルに実現できる場合もあります。

より一般的なMFA強制ポリシー (ログイン後のアクションを制限)

上記のポリシーは強力ですが、少し冗長かもしれません。通常は、特定の権限を付与するポリシーと組み合わせて使用します。例えば、ユーザーに特定の権限（EC2インスタンスの起動/停止など）を与えつつ、それらの権限を使用する際にはMFAが必須、というポリシーを作成します。

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireMfaForCriticalActions",
"Effect": "Deny",
"Action": [
"ec2:StopInstances",
"ec2:TerminateInstances",
"s3:DeleteBucket",
"iam:DeleteUser",
"iam:DeleteRole",
"rds:DeleteDBInstance"
// その他、重要または破壊的なアクションをリストアップ
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}

  • このポリシーは、リストアップされた特定のアクションを実行しようとした際に、ユーザーがMFA認証済みでない (aws:MultiFactorAuthPresent が false) 場合に拒否 (Effect: "Deny") します。
  • BoolIfExists: この条件キーは、aws:MultiFactorAuthPresent が存在しない場合（例えば、一部のAPIコールではこの情報が提供されない場合）でもエラーにならず、条件を満たさない（拒否されない）ようにします。通常、コンソールログインを対象とする場合は Bool で十分ですが、幅広いシナリオを考慮する場合は BoolIfExists が有用です。
  • このポリシーは、ユーザーに付与されている他の権限（Allowポリシー）と組み合わせて使用します。例えば、ユーザーにはEC2インスタンスの起動・停止を許可するポリシーが付与されていますが、同時にこのMFA強制ポリシーも付与されている場合、MFA認証せずにサインインしたセッションではEC2インスタンスを停止できなくなります。

MFA設定自体を強制するポリシー:

MFAが設定されていないユーザーには、サインイン後にMFA設定画面以外へのアクセスを許可しない、というポリシーを作成することも可能です。これは、新規ユーザーやまだMFAを設定していないユーザーに対して、MFA設定を促し、強制するための効果的な方法です。

json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToMfaSetupIfMfaNotPresent",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListUsers",
"iam:ListVirtualMFADevices"
// 仮想MFA設定に必要な最小限のアクションを許可
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}",
"arn:aws:iam::*:mfa/*"
],
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
},
{
"Sid": "DenyAllOtherActionsIfMfaNotPresent",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
},
"Null": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}

  • AllowAccessToMfaSetupIfMfaNotPresent: ユーザーがMFA認証されていない (aws:MultiFactorAuthPresent が false または存在しない) 場合に、MFAデバイスの作成や有効化に必要なIAMアクションのみを許可します。Resource でユーザー自身とMFAデバイスのリソースに限定することで、他のユーザーやリソースへのアクセスを防ぎます。
  • DenyAllOtherActionsIfMfaNotPresent: ユーザーがMFA認証されていない (aws:MultiFactorAuthPresent が false または存在しない) 場合に、上記で許可されたアクション以外のすべてのアクションを明示的に拒否します。

このポリシーをユーザーにアタッチすると、MFAを設定するまでは、そのユーザーはMFA設定画面しか操作できなくなります。MFA設定が完了し、MFA認証を行ってサインインすれば、他の通常の権限ポリシーによって許可されたアクションを実行できるようになります。

これらのポリシー例はあくまでテンプレートです。実際の環境に合わせて、許可/拒否するアクションやリソースを調整する必要があります。

CLI/SDK/APIアクセス時のMFA要求

AWS CLI (Command Line Interface) や SDK (Software Development Kit)、あるいは直接APIを呼び出す場合も、通常はMFA認証が必要です。ただし、コンソールログインとは認証のフローが少し異なります。

CLI/SDK/APIアクセスでは、主に以下の認証方法が使われます。

  • IAMユーザーのアクセスキーとシークレットアクセスキー: 長期的な認証情報です。デフォルトではMFAを直接要求できません。
  • 一時的な認証情報:
    • IAMユーザーがMFA認証を行って取得するセッショントークン (GetSessionToken API)。
    • IAMロールを引き受ける (AssumeRole API) ことで取得する認証情報。

一時的な認証情報とMFA:

IAMユーザーがCLI/SDK/APIからMFA認証を伴ってアクセスする場合、通常は GetSessionToken APIを使用します。このAPIは、IAMユーザーのアクセスキー、シークレットアクセスキー、そしてMFAデバイスのシリアル番号と現在のMFAコードを入力することで、有効期限付きの一時的な認証情報（アクセスキーID、シークレットアクセスキー、セッショントークン）を返します。この一時認証情報は、MFA認証されたセッションとして扱われます。

例: AWS CLIでMFAを要求して一時認証情報を取得し、S3にアクセスする（~/.aws/credentials ファイルを直接編集する場合）

“`ini
[default]
aws_access_key_id = YOUR_IAM_ACCESS_KEY_ID
aws_secret_access_key = YOUR_IAM_SECRET_ACCESS_KEY
output = json
region = us-east-1

[mfa]

MFA 認証が必要なプロファイル

デフォルトプロファイルの認証情報を使用し、MFAを要求

aws_access_key_id = YOUR_IAM_ACCESS_KEY_ID
aws_secret_access_key = YOUR_IAM_SECRET_ACCESS_KEY
output = json
region = us-east-1

MFA デバイスのARN (例: arn:aws:iam::ACCOUNT_ID:mfa/user-name または arn:aws:iam::ACCOUNT_ID:mfa/virtual-device-name)

mfa_serial = arn:aws:iam::ACCOUNT_ID:mfa/user-name

CLI コマンドでMFAコードを入力する際に使用される

credential_process を使用して GetSessionToken を呼び出すのが一般的ですが、

シンプルな例として mfa_serial を示す

“`

CLIコマンドを実行する際に、MFA認証を要求するよう設定されているIAMポリシーが適用されると、認証が拒否されることがあります。この場合、ユーザーは aws sts get-session-token コマンドを実行し、MFAコードを入力して一時的な認証情報を取得する必要があります。

bash
aws sts get-session-token \
--serial-number arn:aws:iam::ACCOUNT_ID:mfa/user-name \
--token-code 123456

このコマンドの出力として一時的な認証情報が返されます。ユーザーはこれらの情報を使って環境変数やAWSプロファイルを一時的に設定し、その後のコマンドを実行します。

IAMロールへのスイッチングとMFA:

IAMロールを使用することで、ユーザーは自身の認証情報（または一時認証情報）を使って、別の権限セットを持つロールに一時的に切り替える（AssumeRole）ことができます。IAMロールにもMFA認証を要求するポリシーを設定することが可能です。これは、例えば開発者が自身のIAMユーザー認証情報でサインインした後、より権限の高いデプロイメントロールにスイッチする際に、MFA認証を再度要求する、といったシナリオで有用です。

AssumeRoleを許可するポリシーに、以下のような条件を追加します。

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::ACCOUNT_ID:role/TARGET_ROLE_NAME",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}

このポリシーは、TARGET_ROLE_NAME というロールにスイッチする際に、呼び出し元のセッションがMFA認証済みであることを要求します。つまり、ユーザーがIAMユーザーとしてサインインした際にMFA認証を行っていない場合、このロールにスイッチすることはできません。ユーザーはまず自身のIAMユーザーとしてMFA認証を行って一時認証情報を取得するか、ログイン時にMFAを要求されるポリシーが適用されている場合はそれに従う必要があります。

長期的なアクセスキーの代替:

セキュリティ上の理由から、IAMユーザーに長期的なアクセスキーを割り当てることは推奨されません。代わりに、IAMロールと一時的な認証情報を活用し、必要に応じてMFA認証を組み合わせる設計がベストプラクティスです。自動化されたプロセスには、アクセスキーではなくIAMロールを割り当て、そのロールに必要な権限のみを付与します。自動化プロセスは人間ではないため、MFAは適用しませんが、ロールの信頼ポリシーや条件を厳格に設定することでセキュリティを確保します。

MFAの運用と管理のベストプラクティス

MFAを設定するだけでなく、適切に運用・管理していくことが重要です。

  1. MFA設定状況の定期的な確認:
    • ルートユーザー: AWS Trusted Advisorのセキュリティチェックリスト項目に、「ルートアカウントで MFA を有効にする」という項目があります。これを定期的に確認し、常にMFAが有効になっている状態を維持してください。
    • IAMユーザー: IAMダッシュボードの「IAM ユーザーのセキュリティステータス」で、MFAが有効になっているユーザーの数を確認できます。また、IAMレポートを生成することで、各IAMユーザーのMFAデバイス情報（デバイスの種類、最終使用日時など）を含む詳細なリストを取得できます。これらの情報を活用して、特に管理者権限を持つユーザーなど、MFAが必須であるべきユーザーにMFAが設定されているかを確認し、未設定のユーザーには設定を促してください。
  2. MFAデバイスの紛失・盗難時の対応:
    • MFAデバイスを紛失または盗難されたユーザーが発生した場合、速やかにそのMFAデバイスをAWSから削除（無効化）する必要があります。これはIAM管理者がマネジメントコンソールから行えます。
    • ユーザーがIAMユーザーの場合、管理者は該当ユーザーのMFAデバイスを削除し、新しいMFAデバイスを再設定させます。
    • ユーザー自身が新しいMFAデバイスを設定できない場合（例えばMFA強制ポリシーが適用されている場合）、一時的にポリシーを緩和するか、管理者が新しいデバイスを設定してあげる必要があります。
    • ルートユーザーのMFAデバイス紛失時は、前述の復旧手順に従ってAWSサポートに連絡し、MFAをリセットしてもらいます。
  3. 退職者のMFAデバイス解除:
    • 従業員が退職する際は、IAMユーザーアカウントを無効化または削除するとともに、そのアカウントに関連付けられているMFAデバイスも必ず解除または削除してください。これにより、退職者がMFAデバイスを使って不正にアクセスすることを防ぎます。
  4. MFA設定の見直しとポリシーのアップデート:
    • 組織のセキュリティ要件やAWSアカウントの利用状況は変化します。定期的にIAMユーザーとその権限、MFA設定状況、そしてMFAを強制するIAMポリシーを見直してください。
    • 新しいAWSサービスの利用を開始したり、既存のポリシーを変更したりする際には、MFA強制ポリシーとの整合性を確認し、必要に応じてポリシーをアップデートしてください。
  5. ユーザーへのMFA利用の啓蒙とトレーニング:
    • MFAの重要性、設定方法、そして紛失時の対応方法について、ユーザーに適切に周知し、トレーニングを実施してください。特に、なぜMFAが必要なのか、MFAを利用しないことのリスクを理解してもらうことが、ユーザーによる自主的なMFA利用を促進します。
    • MFAデバイスの安全な保管方法や、フィッシングメールに対する注意喚起なども含めて教育を行うとより効果的です。
  6. 緊急時アクセス用のMFAデバイス保管 (ルートユーザー):
    • ルートユーザーのMFAデバイスを紛失した場合の復旧は時間がかかる可能性があります。組織によっては、ルートユーザーのMFAデバイス（特にハードウェアトークン）を、権限を持つ担当者が複数名で確認できる金庫などに保管し、緊急時のみ使用する、といった対策を取る場合があります。ただし、これは運用の手間や物理的なセキュリティ対策も必要となるため、組織の状況に合わせて検討してください。

MFAの限界と多層的なセキュリティ対策

MFAは非常に効果的なセキュリティ対策ですが、万能ではありません。特定の攻撃手法に対しては限界があり、MFAだけですべての脅威を防げるわけではありません。

MFAの限界の例:

  • MFA Bypass攻撃: フィッシングサイトでログイン情報だけでなく、MFAコードまで入力させてしまう攻撃（ただし、セキュリティキーはこの種のフィッシングに強いです）。あるいは、ユーザーのセッション自体をハイジャックする攻撃など。
  • マルウェアによるセッション情報窃盗: PCやスマートフォンがマルウェアに感染し、MFA認証後のセッション情報（Cookieなど）が窃盗された場合、MFAを再認証することなくアクセスされる可能性があります。
  • 設定・運用の不備: MFAが適切に設定されていなかったり、MFAを強制するポリシーが漏れていたりする場合、MFAがバイパスされてしまいます。また、紛失・盗難時の対応が遅れることもリスクとなります。

その他のセキュリティ対策との組み合わせ:

MFAはセキュリティ対策の「一要素」であり、AWSアカウントのセキュリティを確保するためには、他の様々な対策と組み合わせて、多層的な防御を構築することが不可欠です。

  • IAM最小権限の原則 (Least Privilege): 各ユーザーやロールには、職務を遂行するために必要な最小限の権限のみを付与します。これにより、仮にアカウントが侵害されても、被害範囲を最小限に抑えることができます。
  • 強力なパスワードポリシー: パスワード推測やブルートフォース攻撃を防ぐために、十分な長さ、複雑さ、そして定期的な変更を要求するパスワードポリシーを設定します。
  • ログの監視と分析: AWS CloudTrailやAmazon GuardDutyなどのサービスを利用して、アカウント上のアクティビティ（API呼び出し、ログイン履歴など）を継続的に監視し、異常な挙動を検知・分析します。MFAなしでのサインイン試行や、通常と異なる場所からのアクセスなどを検知するためのアラートを設定することが推奨されます。
  • ネットワークセキュリティ: セキュリティグループやネットワークACL、VPCなどの機能を活用して、AWSリソースへの不正なネットワークアクセスを制限します。
  • データ保護: S3やRDSなどのデータストアに保存されている機密データは、暗号化（保存時暗号化、通信時暗号化）やアクセスコントロールリスト（ACL）、バケットポリシーなどによって保護します。
  • 定期的なセキュリティ診断: AWS環境のセキュリティ設定を定期的に見直し、脆弱性がないか診断ツールなどを活用して確認します。AWS Security HubやAWS Configなどのサービスも役立ちます。
  • ユーザー教育: ユーザー自身がセキュリティリスクを理解し、MFAを含むセキュリティポリシーを遵守する意識を持つことが最も重要です。フィッシング詐欺の手口などについても教育を行います。

MFAはこれらの多層的なセキュリティ対策の「出発点」であり、最も効果的な対策の一つです。MFAを導入し、他の対策と組み合わせることで、AWSアカウントをより堅牢に保護することができます。

まとめ – MFAでAWSアカウントを堅牢に

AWSアカウントのセキュリティは、クラウド環境でビジネスを展開する上で最も重要な課題の一つです。アカウントの侵害は、情報漏洩、経済的損失、そして企業や個人の信頼失墜といった深刻な結果をもたらす可能性があります。

本記事で詳しく見てきたように、パスワード単独認証は現代のサイバー攻撃に対して非常に脆弱です。これを克服するための最も効果的かつ基本的な手段が、知識情報、所持情報、生体情報といった異なる要素を組み合わせて認証を行う多要素認証（MFA）です。

AWSは、仮想MFAデバイス（TOTPアプリ）、ハードウェアTOTPトークン（CodeKey）、そしてフィッシング耐性の高いセキュリティキー（U2F/FIDO）といった多様なMFAデバイスをサポートしています。これらのデバイスを活用することで、パスワードが漏洩した場合でも、攻撃者はMFAデバイスを持っていないため、アカウントへの不正アクセスを阻止できます。

特に、アカウントに対するすべての権限を持つルートユーザーには、最優先でMFAを設定することが絶対的に必要です。また、日常的な操作を行うIAMユーザー、特に管理者権限や機密リソースへのアクセス権を持つユーザーに対しても、MFA設定を必須とするべきです。IAMポリシーの aws:MultiFactorAuthPresent 条件キーを使用することで、MFA認証済みセッションのみに特定のアクションやリソースへのアクセスを許可したり、MFA未設定のユーザーにMFA設定を強制したりすることができます。

MFAの設定手順は比較的簡単ですが、MFAデバイスを紛失・故障した場合の復旧手順を事前に理解しておくこと、そして複数のMFAデバイスを登録しておくなど、可用性も考慮した設計を行うことが重要です。

MFAの導入・設定に加えて、MFA設定状況の定期的な確認、紛失時の迅速な対応、退職者のMFAデバイス解除といった運用・管理のベストプラクティスを遵守することが、MFAの効果を最大限に引き出し、継続的なセキュリティを維持するためには不可欠です。

最後に、MFAは強力な対策ですが、単独で完璧な防御を提供するものではありません。最小権限の原則に基づくIAMポリシーの適用、強力なパスワードポリシー、ログの監視・分析、ネットワークセキュリティ、データ暗号化、そして定期的なセキュリティ診断といった他のセキュリティ対策と組み合わせることで、AWSアカウント全体のセキュリティレベルをさらに高めることができます。

AWSアカウントのセキュリティ強化は、一度設定すれば終わりではなく、継続的な取り組みが必要です。多要素認証を導入し、適切に運用管理することで、最も基本的な、しかし最も重要なセキュリティの壁を構築し、安心してAWSサービスを利用できる環境を実現しましょう。これは、責任共有モデルにおいてお客様が果たすべき最も重要な責任の一つであり、ビジネス継続性とデータ保護の基盤となります。今すぐ、あなたのAWSアカウントでMFAが有効になっているか確認し、未設定の場合は本記事を参考に設定を進めてください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール