「MFAさえあれば安泰」という幻想を捨てる ― クラウド時代の要塞化戦略
現場でインシデント対応をしていると、「MFAを導入しているから大丈夫だと思っていた」という言葉を何度聞かされたかわからない。しかし、残念ながら現代の攻撃者は、SMSやプッシュ通知ベースのMFAをいとも簡単に突破する。
特にクラウド環境において、コンソールアクセスやAPI操作の保護は、単なる「設定」ではなく「生存戦略」だ。今回は、レガシーなMFAの限界を超え、攻撃者が最も嫌う「フィッシング耐性」を備えた防御アーキテクチャについて、現場の知見を共有する。
—
1. なぜ「プッシュ通知」や「SMS」は破られるのか
攻撃者が好んで使う手法が「MFA疲労（MFA Fatigue）」と「中間者攻撃（AiTM）」だ。
- MFA疲労: 深夜に執拗なプッシュ通知を送りつけ、ユーザーが誤って承認ボタンを押すまで繰り返す。
- AiTM（Adversary-in-the-Middle）: 攻撃者がリバースプロキシを介したフィッシングサイトを構築し、ユーザーからセッションクッキーを直接盗み出す。この手法では、従来のOTP（ワンタイムパスワード）やプッシュ通知は、攻撃者がリアルタイムで横取りするため無力化される。
だからこそ、我々が目指すべきはFIDO2/WebAuthnによる「フィッシング耐性」を持つ認証だ。これには秘密鍵がハードウェア内に隔離され、ブラウザがオリジンを厳密にチェックするため、偽サイトに誘導されても認証が成立しない。
—
2. クラウドインフラ（AWS）におけるIAM保護の鉄則
AWS環境において、rootユーザーや特権IAMユーザーへのアクセスは、以下のIAMポリシーで「MFAなしの操作を拒否する」のが最低ラインだ。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptIfMFAIsPresent",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}*解説：このポリシーは、MFAが認証されていない状態での全操作を拒否する強力なガードレールだ。インフラコード（Terraform/CDK）に組み込み、最初から「MFAなしでは何もできない」環境を作ることが重要だ。*
—
3. アプリケーション層での実装：WebAuthn導入のヒント
Webアプリケーションで独自に認証を組む場合、FIDO2対応のライブラリ（simplewebauthnなど）を使うのが鉄則だ。生のJavaScriptで実装しようとせず、定評のあるSDKを使いこなすことが脆弱性を生まないコツである。
以下は、クライアントサイドで認証器を呼び出す際のシンプルな概念コードだ。
// WebAuthnの認証開始フロー
async function authenticateUser() {
// サーバーから取得したチャレンジ
const challenge = Uint8Array.from('...server_challenge...', c => c.charCodeAt(0));
const publicKeyOptions = {
challenge: challenge,
allowCredentials: [{
id: Uint8Array.from('...credential_id...', c => c.charCodeAt(0)),
type: 'public-key',
}],
userVerification: 'required', // 生体認証などを必須にする
};
try {
// ブラウザの認証APIを呼び出す
const assertion = await navigator.credentials.get({ publicKey: publicKeyOptions });
// この assertion をサーバーに送信して検証する
} catch (err) {
console.error("認証失敗: フィッシングの可能性も考慮して適切にログを残す", err);
}
}—
4. 現場のシニアエンジニアからの「泥臭い」助言
技術的な設定以上に重要なのが、以下の「運用の盲点」だ。
1. アクセスキー（API Key）の保護: コンソールにMFAをかけても、環境変数に置かれたアクセスキーが漏洩すれば即ゲームオーバーだ。APIアクセスには可能な限り「一時的な認証情報（IAMロール）」を使用し、ハードコードは絶対に禁止する。
2. 監査ログの監視: MFAバイパスを試みる攻撃者は、必ず「認証失敗の連続」という痕跡を残す。AWS CloudTrailやAzure MonitorでConsoleLoginの失敗ログを監視し、しきい値を超えたらSlackに通知を飛ばす仕組みを、今日中に構築してほしい。
3. セッション寿命の短縮: 攻撃者は盗んだセッションクッキーの有効期限が切れるまで攻撃し続ける。IAMのセッション期間を短く設定（例：最大1〜2時間）するだけで、被害を最小限に抑えることができる。
最後に
セキュリティとは「一度設定して終わり」の静的なものではない。攻撃手法は日々進化している。今日紹介したFIDO2への移行とIAMのガードレール設定は、あくまでスタートラインだ。
システムを預かるエンジニアとして、常に「もし自分の認証情報が今この瞬間に盗まれたら、何が起きるか？」を問い続けてほしい。その想像力こそが、堅牢なシステムを作るための最強のセキュリティツールだ。
もし実装で詰まったら、焦らずに公式のドキュメントと、信頼できるライブラリのソースコードを読み込んでくれ。近道はないが、正しい道を踏めば必ず守れる。
コメント