こんにちは。IDチームのゆうすけです。
「Entra ID（旧Azure AD）が止まったら、業務が全部止まっちゃうんじゃないの？」
そんな心配の声をよく耳にします。
今回は、Entra ID障害時に慌てず対応できるよう、事前の備えや運用のコツを分かりやすくまとめてみました。
※本記事ではEntra IDを例に解説していますが、OktaやGoogle Workspaceなど他のIdPでも同じような考え方・備えが重要です。
3行まとめ
- Entra IDは99.99%の高可用性を誇りますが、障害時には業務に大きな影響が出ることがあります。
- セッションが切れて再認証が必要になったタイミングでIdP障害が発生していると、ログインできなくなります。
- 日頃から緊急アカウントの用意や手順の整備など、万が一に備えた準備が大切です。
そもそもEntra IDってどれくらい止まらないの？
まず最初にお伝えしたいのは、「Entra IDはかなり止まりにくいサービス」です。
Microsoft社では「ユーザー認証とトークン発行」については99.99%の可用性をSLAで約束していますし、世界中にデータセンターが分散しており内部的に複数のバックアップ（セカンダリレプリカ）をとっております。そのため、一箇所でトラブルが起きてもサービス全体が止まることはほとんどありません。
しかも、近年ではバックアップ認証システムも導入されていて、万が一メインの認証サービスがダウンしても、直近3日以内に同じデバイスからアクセスしたことがあるユーザーなら、バックアップ経由でアプリが使える仕組みまで用意されています。
そのため、テナントを契約しているユーザー側でのバックアップ・リストアの機能がありません。 詳細な情報は以下を参照ください。
参考情報：
https://learn.microsoft.com/ja-jp/entra/architecture/backup-authentication-system
とはいえ、「絶対に止まらない」わけではないので、備えは大事です！
(参考)2021年3月の大規模障害の振り返り
実は2021年3月頃、Azure Active Directory（現Entra ID）で約14時間半にわたる大きな障害が発生しました。
この障害では、Microsoft 365のTeamsやOneDrive、Exchangeなどのサービスはもちろん、SSO連携していた多くのサードパーティ製SaaSでも認証エラーが起きてしまい、多くのユーザーがログインできない状況に陥りました。
この出来事は、Entra IDの高い信頼性を再認識させる一方で、いざという時の備えの重要性も改めて教えてくれました。
もし障害が起きたら？どんな影響があるの？
Entra IDが止まると、SSOでつながっているSaaSや業務システムへの新規ログインができなくなります。
ただし、すでにログインしている人は「セッション」が生きていれば（セッショントークンやCookieが有効な場合は）、そのまま使い続けられるケースも多いです。
セッションが切れたタイミングで初めて影響が出るので、
「今は大丈夫だけど、明日になったら一斉に使えなくなった！」なんてことも。
※セッションが切れて、IdPへ認証しにいったタイミングでIdPの障害が発生していると、ログインができなくなります。
作業ミスによる大規模障害
Microsoft社での大規模障害以外でも管理者の作業ミスにより、IdPが利用できなくなるケースがあります。
よくあるのが、条件付きアクセスの設定ミスによる全ユーザの締め出しです。 条件付きアクセスはブラックリストでかつ、少し玄人向けのため、誤認識により全ての通信をブロックしてしまうことがあります。
例えば、MS以外のネイティブアプリのポリシーでは、要「準拠デバイス」とするとブロックされる等
そのため、不測の事態に備えて、「緊急アカウント（ブレークグラスアカウント）」を作成し、すべてのポリシーで除外することが推奨とされています。
ブレークグラスアカウントの詳細については弊社でブログ化しておりますので併せてご確認ください
https://blog.cloudnative.co.jp/24121
事前にやっておくと安心なこと
認証が停止した場合に備えた運用体制を整えることは、事業継続やセキュリティの観点から非常に重要です。事前に、具体的な運用ポイントを詳述します。
1.重要サービスの洗い出し＆優先順位付け
- どのSaaSや業務システムが「止まると困る」か、あらかじめリストアップしておきましょう。
- 「最重要」「重要」「通常」みたいに分けておくと、障害時の対応もスムーズです。
※可能であればすべてのSaaSや業務システムを洗い出し、優先順位を明文化し、関係者と共有しておけばより安全です。
2.各サービスの「SSO切り離し」手順を用意
- 万が一Entra IDが長時間復旧しない場合、 SaaS側で一時的にSSOを解除してパスワード認証に切り替える必要があります。
- 普段SSOしか使っていないと（強制SSOの場合）、パスワード情報が登録されていないため、パスワードリセットが必要になります。
- 各SaaSのSSO切り離し、パスワードリセット、ユーザでのパスワードログインまでの一連の手順を手順書にしておくことを推奨いたします。
- ユーザーへの案内文も事前用意しておくとよりスムースに対応できます。
3.セッション有効期間をチェック
- 各SaaSのセッション有効期間が短すぎると、障害発生時にすぐ影響が出てしまいます。
- 一方で、有効期限を長くしすぎるとセキュリティリスクになりますので、社内のセキュリティ部署に相談し、可能な範囲でセッション有効期間を長めにしておくと安心です。
4.管理者用の直接ログイン手段の用意
SSO障害時でも管理者が直接ID・パスワードでログインできるよう、管理者専用のローカルアカウント(SSOの強制の除外アカウント)や認証手段を事前に準備しておきます。
各サービスには、それぞれ固有の管理者専用ログイン方法が用意されています。以下にいくつかの例を記載いたします。
＜サービスごとの管理者専用ログイン方法＞
- Keeper
SSOを適用していないルートノードに管理者ユーザを2名以上設定する必要があります。 - Google Workspace（GWS）
特定のロールを持っているユーザーはSSOの対象から強制的に除外される仕様となります。 - Netskope
SSOを回避することが可能なURLがサービス側で提供されています。 SSO設定後にローカルログインする場合は、テナントURLに「/locallogin」を追加するとアクセス可能です。
例:https://<テナント名>goskope.com/locallogin - M365サービス全般
サービスがIDaaS（Entra）と密結合しており、独自の認証経路を確保することが困難です。
まとめ
Entra IDはとても堅牢なサービスですが、「絶対に止まらない」はありません。
普段から「もしもの時」を想定して、
- 緊急アカウント(ブレークグラスアカウント)の作成とポリシーでの除外
- 重要サービスの整理
- SSO切り離し手順の用意
- セッション有効期間のチェック
- 管理者用の直接ログイン手段の用意
などをしておくことで、いざという時も慌てずに対応できます。
なお、ここでご紹介した内容はEntra IDに限らず、他のIdPでも同様です。「うちは別のサービスだから大丈夫」と油断せず、どのID基盤でも“もしも”に備えておくことが大切です。
また、今回は記載していませんが、実際の障害発生時に慌てないよう、定期的に障害対応訓練やシナリオベースのシミュレーションを行い手順や自動化ツールの有効性を検証・改善を行うことを推奨いたします。
「備えあれば憂いなし」みなさんのEntra ID基盤の運用が、もっと安心・快適になることを願っています！
