awsのmfa設定を徹底解説！安全運用の基本と注意点を完全ガイド

2025 12/01

2025/12/01

はじめに

本ドキュメントの目的

本書は、AWSの多要素認証（MFA）に関する実用的なガイドです。MFAの基本や、コンソールとCLIでの設定手順、プロファイル管理や自動化、組織での導入ルールまでを初心者〜中級者向けにわかりやすくまとめます。

読者想定

AWSの基礎（アカウント、IAM）の基本的な知識がある方
セキュリティ強化のためにMFAを導入・運用したい方
具体例を交えながら手順を示すので、初めて設定する方でも取り組みやすい内容です。

本書で得られること

MFAのメリットと推奨される使い方が分かります。
コンソールとCLI両方で実際に設定・利用する手順を習得できます。
組織でMFAを強制する方法や、よくあるトラブルの対処法も学べます。

使い方のヒント

各章は独立して読めますが、手順をそのまま実行する場合は第2章→第3章→第4章の順で読むとスムーズです。設定の前にバックアップ手段（別デバイスやシークレット保管）を用意して進めてください。

AWS MFAとは？なぜ設定が必要なのか

MFAの基本

AWS MFA（Multi-Factor Authentication）は、パスワードに加えて別の要素で本人確認を行う仕組みです。スマートフォンの認証アプリやハードウェアトークンが発行するワンタイムコードを使います。これにより、パスワードだけではログインできなくなります。

なぜ必要か

パスワードが漏れた場合でも、攻撃者はワンタイムコードを持たなければアクセスできません。フィッシングや辞書攻撃、漏洩した資格情報の使い回しといった脅威を大幅に低減します。具体例として、開発者のパスワードが流出しても、MFA未設定なら即座に悪用されますが、MFA設定があれば不正ログインを防げます。

誰が設定すべきか

ルートアカウントは必ず設定してください。IAMユーザーも特権アクセスを持つ場合やコンソールログインを許可する場合は設定を推奨します。管理者や運用担当者など、権限が高いアカウントほど優先度が高いです。

初期のおすすめ

まずルートアカウントにMFAを設定し、次に管理者グループのIAMユーザーへ広げます。バックアップ用の手順（予備デバイスやシリアル保管）も用意してください。

AWSコンソールでのMFA設定手順（ルートアカウント・IAMユーザー）

事前準備

スマホの認証アプリ（Google Authenticator、Authy 等）かハードウェアトークンを用意します。
コンソールにルートまたは対象のIAMユーザーでログインできることを確認します。

ルートアカウントでの設定手順

AWSコンソールにルートのメールアドレスとパスワードでログインします。
画面右上のアカウント名をクリックし「セキュリティ認証情報」を選びます。
「多要素認証（MFA）」セクションで「MFAデバイスの割り当て」をクリックします。
デバイスの種類（仮想MFA/ハードウェア）を選び、デバイス名を入力します。
仮想MFAの場合は表示されたQRコードを認証アプリで読み取ります。アプリに表示される6桁コードを2回連続で入力します（異なるタイミングのコード）。
「MFAを追加」をクリックして完了です。

IAMユーザーでの設定手順

管理者権限がある場合、IAMダッシュボードに移動します。権限がない場合は管理者に設定を依頼してください。
対象ユーザーを選び「セキュリティ認証情報」タブを開きます。
以降はルートと同様にMFAを割り当てます。

注意点と確認方法

コードは30秒ごとに変わります。入力は慎重に行ってください。
時刻がずれていると認証に失敗します。スマホの時刻自動同期を有効にしてください。
設定後にサインアウトしてMFAが動作するか確認してください。
デバイス紛失時は管理者またはルートでMFAを無効化・再設定します。

AWS CLIでのMFA認証設定方法

準備

まずIAMユーザーにMFAデバイスを登録し、アクセスキー（アクセスキーIDとシークレット）を取得します。ローカルにaws CLI（v2推奨）が入っている前提です。

手順概要

ベースの資格情報を設定（aws configure）
~/.aws/configにMFA用プロファイルを追加
CLIで操作時にMFAトークンを入力して一時的な認証情報を取得して使う

ベースプロファイルの設定

例：
$ aws configure –profile base
アクセスキーID、シークレット、リージョンを入力します。

~/.aws/configへの追記例

[profile dev-mfa]
region = ap-northeast-1
source_profile = base
role_arn = arn:aws:iam::123456789012:role/Developer
mfa_serial = arn:aws:iam::123456789012:mfa/youruser

この設定により、dev-mfaを使ってroleを引き受ける際にMFAが求められます。

CLIでの利用方法（2パターン）

A) assume-roleで直接実行：
$ aws sts assume-role –profile dev-mfa –role-arn arn:aws:iam::123456789012:role/Developer –role-session-name dev-session
Enter MFA code for arn:aws:iam::…:mfa/youruser: 123456
戻り値に一時的なキーが返ります。これを環境変数にセットしてコマンドを実行します。

B) get-session-tokenで一時キーを取得：
$ aws sts get-session-token –serial-number arn:aws:iam::123456789012:mfa/youruser –token-code 123456 –duration-seconds 3600 –profile base
出力されるCredentialsをコピーし、AWS_ACCESS_KEY_ID等を設定して使います。

注意点

mfa_serialにはIAMで登録したMFAデバイスのARNを正確に指定してください。
一時認証情報は有効期限があります。期限切れ時は再度MFAコードで取得してください。
スクリプト化する際はトークンや一時キーを端末に残さないよう注意してください。

プロファイル切り替えと自動化のテクニック

シェル関数で楽に切り替える

よく使うプロファイルは .bashrc や .zshrc に関数を追加すると便利です。以下は簡単な例です。

aws-profile() {
  if [ -z "$1" ]; then
    echo "Usage: aws-profile <profile>"
    return 1
  fi
  PROFILE="$1"
  export AWS_PROFILE="$PROFILE"
  MFA=$(aws configure get profile.$PROFILE.mfa_serial 2>/dev/null)
  if [ -n "$MFA" ]; then
    echo "プロファイル '$PROFILE' はMFAが必要です：$MFA"
    read -p "MFAコード: " TOKEN
    eval $(aws sts get-session-token --serial-number "$MFA" --token-code "$TOKEN" --profile "$PROFILE" --output json | \
      jq -r '.Credentials | "export AWS_ACCESS_KEY_ID=\(.AccessKeyId) AWS_SECRET_ACCESS_KEY=\(.SecretAccessKey) AWS_SESSION_TOKEN=\(.SessionToken)"')
  else
    echo "プロファイル '$PROFILE' を有効化しました（MFA不要）"
  fi
}

この関数は選んだプロファイルがMFAを持っているか確認し、必要なら一時認証情報を取得して環境変数に設定します。jq が必要です。

CI/CD環境での扱い

CI/CD（例：GitHub Actions）では人手でMFAコードを入力できません。そこで推奨する方法は次の通りです。
– OIDC を使ってワークフローからロールを直接引き受ける（長期鍵を置かない）
– CI用の役割を作り、必要な権限を限定する

MFAをCIに無理に適用すると運用が複雑になります。外部プロバイダーや短期トークン発行の自動化を検討してください。

運用上のポイント

スクリプトは短期トークンの有効期間を考慮して再取得機能を入れてください。
プロファイル切替時は既存の環境変数を上書きするため、セッションに注意してください。
ログや履歴にMFAコードや秘密情報を残さないでください。

組織全体でのMFA強制化とセキュリティポリシー

概要

AWS OrganizationsのSCP（Service Control Policy）を使うと、組織単位で「MFAが有効でないと重要操作を許可しない」ルールを適用できます。規模が大きくなるほど手動は非効率になり、自動化やポリシー化が有効です。

SCPでの強制化（簡単な手順と例）

管理アカウントでOrganizationsのコンソールを開きます。
新しいSCPを作成し、対象OUやアカウントにアタッチします。
例：MFA未使用時にIAMやEC2の操作を拒否するJSON（簡易版）

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": ["iam:*","ec2:*","s3:*"],
    "Resource": "*",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "false"}}
  }]
}

ポイント：SCPは権限を“減らす”ので既存の許可と組み合わせて動作します。サービスアカウントや自動化用ロールは例外設定や条件付き許可を用意してください。

新規IAMユーザー作成ワークフロー

ユーザー作成のテンプレートに「MFA登録を必須にする」タスクを組み込みます。
自動化例：CloudFormationやTerraformのプロビジョニング後にLambdaで未登録を検出し、SNSで通知するか一時的に権限を停止します。

自動化と運用のコツ

AWS ConfigでMFA未登録を監視し、違反を検出したら自動修復か通知を行います。
タグ付けで例外管理（例：ServiceAccount=true）を運用ルールに組み込みます。
ルートアカウントは強く保護し、MFA必須の管理手順をドキュメント化してください。

監査と対応フロー

CloudTrailで操作ログを集め、MFA未使用による拒否イベントを定期確認します。
違反が見つかれば、該当アカウントに対してMFA登録を促す手順書と期限を通知し、期限超過で自動的に権限を制限する仕組みを用意します。

MFAデバイスの種類と選択肢

認証アプリ（ソフトトークン）

最も一般的な方法です。スマートフォンやタブレットにアプリを入れ、表示される6桁コードを使って認証します。代表例はGoogle Authenticator、Microsoft Authenticator、Authyです。導入が簡単でコストも低く、オフラインでも使えます。

ハードウェアトークン（物理キー）

USBやNFCで接続する物理デバイスです。YubiKeyなどが有名で、FIDO2やU2F規格に対応します。セキュリティが高く、フィッシング耐性に優れますが、購入費用と紛失リスクに注意が必要です。

SMS認証

携帯電話のSMSにコードが届く方式です。一部リージョンのみで利用でき、手軽ですが盗聴やSIMスワップのリスクがあるため、セキュリティ面では劣ります。

選び方のポイント

セキュリティ優先ならハードウェアトークン。フィッシング対策に強いです。
コストと利便性なら認証アプリ。複数端末でのバックアップができるアプリ（例：Authy）を検討してください。
SMSは緊急用や補助として想定してください。しかし、主要手段にするのは推奨しません。

導入時の実務的注意点

バックアップ方法（リカバリーコードや予備デバイス）を用意し、紛失時の手順を定めてください。したがって、運用ルールを文書化して周知すると運用が安定します。

MFA設定後の注意点とトラブルシューティング

MFAデバイス紛失時の対処

MFAデバイスを紛失したら速やかに対応してください。ルートアカウントの場合はAWSサポートに連絡して解除手続きを依頼します。IAMユーザーは管理者にMFA解除を依頼し、新しいデバイスを登録します。本人確認が必要なため、アカウントIDや登録情報を用意しておくと手続きが早く済みます。

環境変数やプロファイルの競合

複数プロファイルを使う場合は明確に分離してください。環境変数（AWS_ACCESS_KEY_ID等）が設定されているとプロファイルが無視されることがあります。トラブル時は一旦環境変数をクリアし、named profile（~/.aws/credentials）を指定して動作確認してください。

MFAトークンの有効期限と更新

MFAで発行されるセッションはデフォルトで12時間です。必要ならstsのDurationSecondsやロールのセッション期間で調整できます。期限切れは認証エラーに直結するので、長時間のバッチ処理では定期的に再発行する仕組みを入れてください。

よくあるトラブルと対処例

トークンが無効：端末の時刻がずれていないか確認し、時刻同期を行ってください。
MFA登録できない：管理者権限で再登録を試行、ブラウザのキャッシュをクリアするのも有効です。
認証に失敗する：環境変数やプロファイルの指定ミス、session tokenの有効期限切れを確認します。

運用の注意点

バックアップ用のMFA方法を検討し、複数管理者で解除手順を共有してください。普段から手順書を用意するとトラブル対応がスムーズになります。

まとめとおすすめ

要点の振り返り

AWSのMFAはアカウント保護の基本です。ルートアカウントだけでなく全てのIAMユーザーに設定することで、不正アクセスのリスクを大きく下げられます。コンソールだけでなくCLIやCI/CDでの利用方法も押さえて運用全体を守りましょう。

今すぐのおすすめ設定

ルートアカウントにハードウェアキー（可能なら）を設定する
全IAMユーザーに仮想MFA（AuthyやGoogle Authenticator）またはハードウェアを必須化する
重要操作はMFA付きのロールで実行する（例：管理系API呼び出し）

運用面でのおすすめ

予備デバイスの登録と紛失手順を文書化する
CLIや自動化用には短期の一時的認証（STS）を利用する
組織レベルでMFAの強制化と監査（CloudTrail/AWS Config）を行う

最後に

MFAは導入が簡単で効果が大きい対策です。まずは全ユーザーにMFAを必須化し、運用ルールと監査を整えることをおすすめします。

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

user