🔑 パスワード変更
使用したブレークグラスユーザーのパスワードを即座に変更し、新しい認証情報を封印して金庫に保管。
📌 結論：SAMLが使えなくても「予備の鍵」でAWSにログイン！
SAMLフェデレーションに障害が発生しても慌てない！
事前に作成した「ブレークグラスユーザー（緊急用IAMユーザー）」で
AWSマネジメントコンソールにログインできます✨
事前に作成した「ブレークグラスユーザー（緊急用IAMユーザー）」で
AWSマネジメントコンソールにログインできます✨
事前準備
IdPに依存しない
専用IAMユーザーを
事前に作成・保管
専用IAMユーザーを
事前に作成・保管
2人体制
承認者と実行者の
デュアルコントロールで
不正使用を防止
デュアルコントロールで
不正使用を防止
監視と記録
使用時は即通知
全操作をログ記録
事後に監査レポート
全操作をログ記録
事後に監査レポート
🏢 オフィスビルの「非常口」で例えると超わかりやすい！
SAMLフェデレーション = 社員証で入館できる自動ドア
ブレークグラスユーザー = 金庫に保管された非常口の物理キー
通常の入館
（SAMLフェデレーション）
🎫 仕組み：
社員証をかざすと、認証システムが「この人は社員」と確認→自動ドアが開く
社員証をかざすと、認証システムが「この人は社員」と確認→自動ドアが開く
✨ メリット：
1枚の社員証で複数ビルに入れる、退職したら即アクセス停止
1枚の社員証で複数ビルに入れる、退職したら即アクセス停止
⚠️ 弱点：
認証システムが故障したら...誰もビルに入れない！
認証システムが故障したら...誰もビルに入れない！
⚡
非常口の鍵
（ブレークグラス）
🗄️ 仕組み：
認証システムとは別に、物理的な鍵を金庫に厳重保管
認証システムとは別に、物理的な鍵を金庫に厳重保管
✨ 特徴：
認証システムが故障しても入館可能、使用時は必ず記録
認証システムが故障しても入館可能、使用時は必ず記録
🛡️ セキュリティ：
普段は絶対使わない！緊急時だけの「最後の手段」
普段は絶対使わない！緊急時だけの「最後の手段」
IdP障害発生！
➡️
金庫を開ける
➡️
封筒を開封
➡️
鍵でログイン
➡️
緊急対応
💥 実際に起きるIdP障害パターン
😱 主要IdP別の障害事例
🔵
Okta
- 認証サーバーの全面停止
- SSL証明書の期限切れ
- 設定変更ミスによる認証エラー
- DDoS攻撃による応答遅延
🟦
Azure AD (Entra ID)
- リージョン障害での認証不可
- 条件付きアクセスポリシーの誤設定
- テナント設定の破損
- 同期エラーによるユーザー消失
🟢
OneLogin
- APIエンドポイントの障害
- SAML証明書のローテーション失敗
- MFA連携サービスの停止
- ディレクトリ同期の失敗
🏢
オンプレAD FS
- サーバーハードウェア故障
- ネットワーク障害での到達不能
- 証明書の更新忘れ
- データセンター障害
📰 実際の大規模障害事例
2022年、大手IdPプロバイダーで約4時間の認証サービス停止が発生。数千社の企業が影響を受けた。
09:00
認証エラー発生開始
09:30
全ユーザーログイン不可
10:00
ブレークグラス発動組は復旧作業開始
13:00
IdPサービス復旧
💡 ブレークグラスを用意していた企業は10:00から対応開始、用意していなかった企業は13:00まで何もできなかった
🏗️ マルチアカウント環境での設計
AWS Organizations環境でのブレークグラス配置
管理アカウント
Organizations管理
セキュリティアカウント
監査・ログ集約
本番アカウント
ワークロード実行
開発アカウント
開発・テスト
管理アカウント
✅ 必須
Organizations全体の管理権限を持つため、ブレークグラスユーザーの配置が絶対に必要。
- • SCP変更・解除が可能
- • 他アカウントへのアクセス復旧
- • Organizations設定の修正
セキュリティアカウント
✅ 推奨
監査ログの確認やセキュリティ対応のため、独立したブレークグラスを配置。
- • CloudTrailログの確認
- • GuardDutyアラート対応
- • セキュリティインシデント調査
本番ワークロードアカウント
⚠️ 検討
本番環境の緊急対応が必要な場合は配置を検討。管理アカウントからのAssumeRoleでも対応可能。
- • 直接アクセスが必要な場合のみ
- • EC2障害対応など
- • 管理アカウント経由も選択肢
開発・サンドボックス
❌ 不要
緊急性が低いため、通常は不要。管理アカウントからのアクセスで十分。
- • IdP復旧まで待機可能
- • 管理コスト削減
- • 攻撃対象面の縮小
👥 デュアルコントロール（2人制）設計
🔐 1人では開けられない「2重の鍵」
承認者（Approver）
セキュリティ責任者/マネージャー
保有するもの
🗝️
金庫の鍵
📋
承認権限
＋
実行者（Executor）
インフラ担当/オンコール担当
保有するもの
📱
MFAトークン
🛠️
技術スキル
＝
2人揃って初めてアクセス可能
内部不正の防止
単独犯行が不可能になり、共謀のハードルが大幅に上がる
相互チェック
承認者が作業内容を確認、実行者が承認の正当性を確認
監査証跡の強化
「誰が承認し、誰が実行したか」が明確に記録される
知識の分散
1人に依存せず、複数人が手順を把握している状態を維持
🛡️ SCPとブレークグラスの関係
Service Control Policy からの除外設計
⚠️ 問題：SCPで全ユーザーの権限を制限していると、ブレークグラスユーザーも制限されてしまう！
💡 解決策：SCPの条件（Condition）でブレークグラスユーザーを除外する
SCP（制限ポリシー）
特定リージョンのみ許可
特定サービスを禁止
特定サービスを禁止
➡️
Condition追加
ブレークグラスユーザーは
この制限を適用しない
この制限を適用しない
➡️
緊急時フルアクセス
ブレークグラスユーザーは
制限なしで操作可能
制限なしで操作可能
// SCP例：ブレークグラスユーザーを除外
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllExceptAllowedRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
// 許可リージョン以外を拒否
"StringNotEquals": {
"aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
},
// ただし、ブレークグラスユーザーは除外
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:user/breakglass-*",
"arn:aws:iam::*:role/BreakGlassRole"
]
}
}
}
]
}
⚖️ 緊急アクセス手段の比較
どの方法を選ぶべき？
| 比較項目 | 🔑 ブレークグラス IAMユーザー |
🏠 ルートユーザー | 🔐 IAM Identity Center 緊急アクセス |
|---|---|---|---|
| IdP依存 | |||
| 権限制御 | |||
| 監査対応 | |||
| AWSベストプラクティス | |||
| マルチアカウント対応 | |||
| 推奨シナリオ | IdP完全障害時 管理アカウント緊急対応 |
アカウント回復 請求関連の緊急対応 |
IdP部分障害時 通常の緊急対応 |
💡 推奨：3層構造での緊急アクセス設計
1️⃣ 第1層（通常緊急）：IAM Identity Center緊急アクセス（IdP部分障害時）
2️⃣ 第2層（中度緊急）：ブレークグラスIAMユーザー（IdP完全障害時）
3️⃣ 第3層（最終手段）：ルートユーザー（アカウント回復、請求問題）
📋 実際に使える緊急対応手順書
🚨 ブレークグラス発動手順
以下の手順書を印刷して金庫に保管し、緊急時にすぐ参照できるようにしてください。
年に1回は訓練で実際に使用し、有効性を確認すること！
1
障害確認と承認取得
⏱️ 目安: 5-15分
- SAML/IdP障害であることを確認（IdPステータスページを確認）
- 他の認証手段（VPN経由、別ブラウザ等）でログイン試行
- ブレークグラス発動の必要性を判断
- 承認者（セキュリティ責任者）に連絡し、口頭で承認を取得
- 承認者の氏名、承認日時、理由を記録
重要: 承認者不在時の代理承認者リストを事前に定めておくこと
2
認証情報の取得
⏱️ 目安: 5-10分
- 承認者が金庫の鍵を使用して金庫を開錠
- 封印された封筒を取り出し、開封日時を記録
- 封筒からID/パスワードの紙とMFAトークンを取り出す
- 封筒の開封を写真で記録（証拠保全）
3
ログインと緊急対応
⏱️ 状況による
- AWSコンソールにIAMユーザーとしてログイン
- URL: https://[アカウントID].signin.aws.amazon.com/console
- ブレークグラスユーザー名とパスワードを入力
- MFAトークンのコードを入力
- 必要最小限の緊急対応のみを実施
- 実施した操作をすべて記録（スクリーンショット推奨）
重要: 緊急対応以外の操作は絶対に行わないこと。必要な作業のみ！
4
クローズ処理
⏱️ 目安: 30分
- すべての作業完了後、コンソールからログアウト
- ブラウザのキャッシュとCookieをクリア
- パスワードを即座に変更（新しいパスワードを新封筒に）
- MFAトークンを金庫に戻す
- 新しい封筒を封印し、金庫に保管
- 使用報告書を作成し、関係者に共有
📝 使用後の事後対応フロー
🔄 ブレークグラス使用後にやるべきこと
即時
(0-1時間)
(0-1時間)
1時間以内
📢 関係者への通知
セキュリティチーム、経営層、監査担当に使用を報告。Slackやメールで速報を共有。
24時間以内
📋 使用報告書の作成
以下を含む詳細な報告書を作成：
- 使用日時、承認者、実行者
- 使用理由（障害の詳細）
- 実施した操作の一覧
- CloudTrailログの抜粋
1週間以内
🔍 監査ログのレビュー
CloudTrailログを詳細にレビューし、実施した操作に不審な点がないか確認。第三者によるレビューを推奨。
1ヶ月以内
📊 振り返りと改善
インシデントの振り返りミーティングを実施し、手順書の改善点を洗い出し。次回に向けた改善策を実施。
👁️ 監視・アラート設定の詳細
🔔 リアルタイム検知と通知
ブレークグラス
ログイン
ログイン
コンソールログイン
➡️
CloudTrail
API記録
➡️
EventBridge
イベント検知
➡️
SNS
通知配信
➡️
アラート
即時通知
メール通知
SNSトピックに登録したメールアドレスに即座に通知。セキュリティチーム全員のメーリングリストを登録推奨。
Slack通知
AWS ChatbotまたはLambda経由でSlackの#security-alertsチャンネルに投稿。@channelでメンション。
PagerDuty
高優先度アラートとしてオンコール担当者に電話・SMS通知。24時間365日対応が必要な場合。
Teams通知
Microsoft Teams Webhookを使用してセキュリティチームのチャンネルに通知。Office 365環境向け。
🎓 年次訓練計画
📅 定期的な訓練で「いざ」に備える
机上訓練（年2回）
所要時間: 1-2時間- 手順書の読み合わせ
- 役割分担の確認
- 連絡先リストの更新確認
- 想定シナリオの討議
- Q&Aセッション
実地訓練（年1回）
所要時間: 2-3時間- 実際に金庫を開けて封筒を取り出す
- テスト用ブレークグラスでログイン実施
- 簡単な操作（EC2一覧表示等）を実行
- パスワード変更と再封印
- 報告書作成の練習
動作確認（四半期）
所要時間: 30分- MFAトークンの電池残量確認
- 金庫の鍵の動作確認
- 連絡先リストの有効性確認
- 監視アラートのテスト発報
新人教育（随時）
所要時間: 1時間- ブレークグラスの目的説明
- 手順書の共有
- 役割と責任の説明
- 過去の使用事例の共有
- 質疑応答
❓ よくある質問（FAQ）
🤔 ブレークグラスに関するQ&A
Q1.
ブレークグラスユーザーは何人必要？
A. 最低2人（メイン + バックアップ）を推奨します。
理由：
理由：
- 1人だとその人が不在時に対応できない
- 2人体制でデュアルコントロールが可能
- 多すぎると管理が煩雑になり、セキュリティリスクが増加
Q2.
パスワードはどのくらいの頻度で変更すべき？
A. 「使用後は即座に」＋「年1回の定期更新」が基本です。
- 使用後: 必ず即座に変更（漏洩リスク軽減）
- 定期更新: 年1回、訓練のタイミングで変更
- 変更時: 新パスワードは新しい封筒に入れて封印
Q3.
MFAはソフトウェアトークンでもいい？
A. ハードウェアトークン（YubiKey等）を強く推奨します。
理由：
理由：
- ソフトウェアMFA（スマホアプリ）は個人のデバイスに依存
- 担当者が退職・異動時にMFAも移行が必要
- ハードウェアトークンは金庫に保管でき、担当者変更の影響を受けない
- 物理的に分離保管することでセキュリティが向上
Q4.
ルートユーザーとブレークグラスユーザーの違いは？
A. 権限範囲と使用シナリオが異なります。
- ルートユーザー: アカウントの「神様」。請求情報変更、アカウント解約など、ルートでしかできない操作用。最後の最後の手段。
- ブレークグラスユーザー: 緊急対応用の「管理者」。必要な権限のみ付与でき、監査ログで追跡可能。IdP障害時の一般的な緊急対応用。
Q5.
ブレークグラスユーザーにはどの権限を付与すべき？
A. 「緊急対応に必要な最小限」が原則です。
推奨する権限例：
推奨する権限例：
- IAM: ユーザー・ロールの作成・変更（SAML復旧用）
- EC2: インスタンスの起動・停止・再起動
- CloudWatch: ログ・メトリクスの閲覧
- CloudTrail: 監査ログの閲覧
- 請求情報へのアクセス（ルートユーザーの役割）
- Organizations管理（管理アカウントのブレークグラスのみ）
💰 導入・運用コスト
📊 ブレークグラス設計にかかる費用
| 項目 | 初期費用 | 年間費用 | 備考 |
|---|---|---|---|
| 🔑 ハードウェアMFAトークン | ¥5,000〜15,000/個 | ¥0 | YubiKey等。2個推奨 |
| 🗄️ 耐火金庫 | ¥20,000〜100,000 | ¥0 | 既存金庫があれば不要 |
| ✉️ 開封検知封筒 | ¥500〜1,000/10枚 | ¥1,000 | 年間使用量による |
| 👥 訓練工数 | - | 4〜8時間 × 人件費 | 年2回の訓練想定 |
| 📝 手順書作成 | 8〜16時間 × 人件費 | 2〜4時間 × 人件費 | 年次更新含む |
| ☁️ AWS監視設定 | ¥0 | ¥100〜500/月 | CloudWatch、SNS費用 |
| 合計目安 | ¥30,000〜130,000 | ¥10,000〜50,000 + 工数 | 規模により変動 |
💡 コスト対効果：IdP障害で4時間ダウンした場合のビジネス損失と比較してください。
ほとんどの場合、ブレークグラス導入コストは「保険」として非常に安価です！
🎓 まとめ
予備の鍵を用意
IdPに依存しない
専用IAMユーザーを
事前に作成
専用IAMユーザーを
事前に作成
2人体制で管理
承認者と実行者の
デュアルコントロールで
不正使用を防止
デュアルコントロールで
不正使用を防止
物理的に保管
金庫 + 封印封筒で
認証情報を
厳重に管理
認証情報を
厳重に管理
定期的に訓練
年に1〜2回は
実際の手順を訓練
手順書を最新化
実際の手順を訓練
手順書を最新化