IAMログインの背後では、すべてのチェックはユーザーと同じ経路を辿らなければなりません：アプリ、アイデンティティプロバイダー、MFA、そして戻る。[ /caption]
あなたの稼働時間チェックはアプリケーションが正常だと言っています。一方で、アイデンティティプロバイダーがタイムアウトしているため、誰もログインできません。Identity and Access Management（IAM）認証の背後にある任意のアプリケーションにとって、ログインは製品の一部であり、ログイン画面で停止するモニターは誤った対象を監視しています。基本ルールは、IdP（アイデンティティプロバイダー）がベンダーに属していても、認証をユーザー向けアプリケーションコードとして扱うことで、ユーザーは「アプリは稼働中だがログインはできない」という部分的障害としては決して体験しないからです。彼らにとっては製品が単に消えているのです。
認証済みアプリケーションはクラシックなシンセティックモニタリングの盲点です。単純なHTTPチェックは公開ログインページから正常な200ステータスを取得しますが、SSOリダイレクトチェーン、MFAチャレンジ、または背後のトークン交換が壊れている場合があります。サインインしたユーザーが見るものを確認する唯一の方法は、認証情報や二要素認証を含む全てのフローをスクリプトし、スケジュールで実行することです。
ここで本ガイドが回答する質問が浮上します：SSOリダイレクトチェーンをどのようにスクリプト化するか、自動化を阻止するために設計されたMFAコードにどう対処するか、認証情報はどこに置いて漏洩を防ぐか、そして遅いログインがアプリケーションの問題かアイデンティティプロバイダーの問題かをどう見極めるか？
Identity and Access Management（IAM）とは？
Identity and Access Managementは、誰がどのリソースにアクセスできるかを決定し、サインイン時にそれを検証するポリシーとサービスの枠組みです。実際には、Okta、Microsoft Entra ID、Auth0、Pingなどの中央のアイデンティティプロバイダー（IdP）が多くのアプリケーションの認証をシングルサインオン（SSO）を通じて処理し、通常はSAMLまたはOpenID Connect上で、多要素認証（MFA）がその上に重ねられます。プロトコルの仕組みを深く理解したい場合は、弊社の関連記事 アイデンティティ管理認証の仕組み をご覧ください。監視の目的において、最も重要な特性は、ログイン経路があなたが完全に管理していないシステムを横断し、それぞれがアプリケーションとは独立して障害を起こす可能性があるということです。
認証済みアプリケーションが監視しにくい理由
IAM保護されたアプリケーションが公開ページよりも監視が難しい理由は4つあります。
ログイン画面が単純なチェックを阻害する。 HTTPの稼働監視はログインページがレンダリングされることのみを確認できます。ユーザーが実際に利用する全ては認証の背後にあるため、サインインフローやアプリケーション自体の障害は誰かが苦情を言うまで見えません。
フローが複数の関係者にまたがる。 単一のサインインは、あなたのアプリケーション、IdP、MFAサービス、しばしばトークンエンドポイントに触れ、それぞれが独自のドメイン、DNS、TLS、インフラを持っています。アプリケーションが完全に正常でも、サードパーティのIdP障害によって全員がログイン不能になることがあります。この依存性の問題はSSOを利用するアプリケーション一般にも見られます。
SSOはページではなくリダイレクトチェーンである。 SAMLやOAuth/OIDCフローはブラウザを2〜3のドメイン間で行き来させ、アサーションや認可コードを交換し、その間にセッションクッキーを設定します。JavaScriptを実行せずにリダイレクトを追わないリクエストレベルのツールは、各段階でフローを誤って報告します。
MFAはスクリプト対策のために存在する。 ワンタイムコード、プッシュ通知、CAPTCHAは意図的に自動化に敵対的です。監視はIdPのポリシーエンジンと協調しなければならず、そのための計画が必要で、単なる稼働時間チェックでは成し遂げられません。
スクリプト化前にSSOリダイレクトチェーンを把握する
何かを記録する前に、開発者ツールを開いたブラウザでログインを一度手動で行い、すべての段階をメモします。典型的なSP（サービスプロバイダー）発行のフローはこうです：ユーザーがアプリケーションをリクエストし、IdPへリダイレクトされ、IdPログインページが表示され、認証情報が送信され、MFAチャレンジが現れ、IdPがSAMLアサーションを投稿するかOAuth認可コードをコールバックURLに返し、アプリケーションがそれをセッションに交換し、最初の認証済みページが読み込まれます。
SSOチェーンの各段階は明確な障害ポイントであり、それぞれが独自の監視チェックポイントを必要とします。[ /caption]
そのチェーンの各段階は、IdPのドメインのDNS解決、コールバックURLの証明書期限切れ、IdPページの遅延レンダリング、タイムアウトするトークン交換など、固有の障害ポイントです。書き留めた段階がスクリプトのチェックポイントとなり、後でタイミングを分割する境界になります。
あなたのものかベンダーのものかをドメインで区別してください。その区別がアラートをルーティングする判断となります：IdPドメインの障害はアイデンティティチームかベンダーのステータスページへ、コールバックの障害はあなたのアプリケーションチームに通知します。OAuthをAPIにも利用している設計なら、トークンエンドポイントには独自のリクエストレベルのチェックを設けるべきです。詳細はJWTトークンとOAuthトークンエンドポイントの監視をご参照ください。
このドメインマップは、IdPのステータスページがあなた自身の監視の代わりにならない理由も示しています。緑色の「All Systems Operational」横断旗はベンダーのサービスが世界的に稼働していることを意味しますが、あなたのテナントのSAML設定やコールバックURLの証明書、ユーザーとログインページ間のネットワーク経路については何も言っていません。ユーザーが実際尋ねている質問に答えるのは、エンドツーエンドのスクリプトだけです。
認証済みログインフローをステップバイステップでスクリプト化する方法
ステップ1：専用の監視アカウントを作成する。 監視専用のサービススタイルのテストユーザーをIdPにセットアップします。最小権限、実際の顧客データにはアクセスしない、ログインが監査ログで簡単に識別できる svc-synthetic-monitor のような名前を付けます。
ステップ2：ログインをマルチステップのブラウザトランザクションとして記録する。 EveryStep のようなリアルブラウザスクリプティングツールを使い、アプリケーションURLを開き、IdPへのリダイレクトを追い、認証情報を入力して送信し、認証済みページに到達するまでの完全なシーケンスをキャプチャします。リアルブラウザはJavaScriptを実行し、クロスドメインのリダイレクトを辿り、ユーザーのブラウザと同様にクッキーを扱うため重要です。
ステップ3：スクリプトを完成させる前にMFA戦略を決める。 オプションとトレードオフは次のセクションで説明します。意図的に選択してください。MFAがキャッシュされていたという理由だけで動作するスクリプトは、後で任意のタイミングで失敗します。
ステップ4：サインインしたユーザーだけが見られる何かでアサートする。 URL到達だけではログインの証明になりません。ダッシュボードの見出しやアカウント名の表示などのコンテンツアサーションでログイン後要素を検証します。多くの失敗したログインはスタイリングされたエラーページにリダイレクトしHTTP 200を返すため、アサーションだけがそれを検知します。
ステップ5：ログインの1タスク先までスクリプトを拡張する。 レコードを開く、検索をする、レポートを読み込むなど。認証が成功しても背後のアプリケーションが壊れているのは実際の故障モードであり、追加の1ステップでカバーします。構造はWebトランザクション監視と同じで、ユーザーの各操作が1ステップで、そのすべてが測定されます。
ステップ6：ステップごとの閾値とアラートを設定する。 各ステップに独自の時間予算を割り当て、アラートルールに失敗を組み込みます。「ログインが遅い」だけでなく「MFAステップが閾値を超えた」と通知されるようにします。
ステップ7：ユーザーがいる場所から実行する。 公開SaaSアプリケーションの場合は外部ロケーションから。IdPやアプリ階層がパブリックインターネットから到達できない内部アプリケーションの場合はネットワーク内のプライベートエージェントから。
シンセティックスクリプトでのMFAおよびOTPの取り扱い
MFAはほとんどの認証済み監視プロジェクトが停滞するポイントです。なぜなら二要素認証の目的は、スクリプトが自然に持つパスワードだけでは不十分なことだからです。運用可能な戦略が4つあり、どれを使うかはMFAステップのどれだけを実際に試験したいか、そしてセキュリティチームが例外をどれほど厳しく管理しているかによります。
| 戦略 | 仕組み | トレードオフ | 最適なケース |
|---|---|---|---|
| 条件付きアクセス免除 | 監視用IPからのサインインでIdPポリシーがMFAをスキップ | MFAステップ自体は未テスト；厳格なIP範囲指定が必要 | ネットワークベースポリシーをサポートするIdPチーム |
| TOTPシードをスクリプトに埋め込む | テストアカウントが認証アプリに登録し、スクリプトはシードを保管し実行時に現在コードを計算 | シードは保持すべき秘密であり、セキュアに保管しローテーション必要 | 実MFAステップの完全な試験・計測に利用 |
| メールやSMSでOTPを取得 | スクリプトがテスト用メールボックスやSMSエンドポイントをポーリングし一時コードを入力 | 遅く配送依存のため誤報が多い | メールかSMSコードのみを提供するアプリ向け |
| アプリパスワード／バイパスコード | 対話式チャレンジを回避する固定副資格情報 | 最も弱く、多くのIdPで廃止中 | より良い方法がないレガシーアプリ用 |
TOTPアプローチはIdPが許可する場合のデフォルトにふさわしいです。時間ベースコードは共有シードと文書化されたアルゴリズムから生成されるため、スクリプトは実行時に有効なコードを作成し、実際のチャレンジを通過でき、つまりMFAステップをスキップせずに計測できます。このパターンの詳細な解説はOTP保護されたWebアプリケーションの監視方法をご覧ください。
どの戦略を選んでも、監視アカウントのみに限定してください。MFA免除やバイパスコードを単一の最小権限テストユーザーより広く適用すると、監視の便宜が攻撃対象面になります。セキュリティチームの承認を得て、免除はポリシーレビューに記録されるべきです。
監視用認証情報の安全管理
ログイン監視は有効な資格情報のセットがスケジュールで実行されるものであり、他のサービス資格情報と同様に注意深く取り扱うべきです。
人間のアカウントを借りてはならない。 実アカウントはスクリーンショットや録画に実データを露出し、パスワード変更で監視が壊れ、誰も帰属できないアクセスでセキュリティログを汚染します。代わりに作成するアカウントは影響範囲を考慮しなければなりません：もしこの認証情報が漏洩したら、無効化されるまで何ができるか？正しい答えは退屈なものです—管理者権限なし、顧客レコードなし、持続可能なトークン発行不可。
秘密はセキュアに保管する。 パスワード、TOTPシード、クライアントシークレットはDotcom-MonitorのSecure Vaultなどの暗号化ストレージに格納し、スクリプトは実行時に参照すべきです。スクリプトのテキストに入れてはいけません。そうするとエクスポートや履歴、画面共有で漏洩します。ログ、スクリーンショット、ビデオキャプチャにもマスキングを拡充してください。
スケジュールでローテーションし、カレンダーに組み込む。 資格情報ローテーションは良い習慣であり、期限切れのテストアカウントパスワードは最も一般的な誤ログインアラートの原因です。スクリプトではなくボールトのエントリをローテーションし、IdPの強制有効期限ポリシーの前にリマインダーを設定しましょう。
シンセティックログインを識別可能にする。 明確な名前のアカウントと既知の送信元IPにより、セキュリティチームは監視を認証情報詰め込み攻撃と区別でき、利用状況分析からそのセッションを除外し、使用数の膨張を防ぎます。
セッション期限切れ、トークン更新、再ログインのロジック
セッションは認証済み監視が静かに腐敗するポイントです。相反する2つの振る舞いが問題を引き起こします：キャッシュされたセッションを再利用する監視はログインをまったくテストせず、半分期限切れのセッションを引き継ぐ監視は、実際のユーザーが見せなかった方法で障害が発生します。
両方を防ぐルールはこれです：毎回のスケジュール実行はクリーンなブラウザセッションから始める、前回の実行からのクッキーやトークンは持ち越さない。クリーンな状態はフルリダイレクトチェーン、認証情報送信、MFAを各サイクルで強制し、IdPの障害が次回の実行で表面化し、有効なクッキーの背後に隠れません。
セッションの持続性もテストする価値がありますが、意図的かつ別々に行うべきです。もしアプリがサイレントトークン更新でサインイン状態を維持しているなら、アクセストークン寿命が切れた後のステップまで含む長いトランザクションを作成し、最後にユーザーがサインイン状態にあることをアサートします。更新失敗はユーザーが途中でログインページに戻されることで現れ、本スクリプトが再現する症状と一致します。
APIレイヤーでは、ブラウザなしでトークン発行を監視できます：OAuthトークンエンドポイントに対するリクエストレベルのチェックは、トークンが各サイクルで発行され有効化されていることを検証します。Dotcom-MonitorのOAuth API監視はこのフローを処理し、ブラウザレベルのスクリプトと組み合わせて、「IdPがトークンを発行できない」と「アプリがトークンを利用できない」を分離するのに役立ちます。
ステップごとのタイミング：認証済みフローが遅くなる場所
「ログインに9秒かかった」は具体的に何秒かはわかりません。9秒はどこで費やされたのでしょう？認証済みフローは少なくとも2組織をまたがるため、モニターの価値は先にマッピングした境界で合計を分割することに依存します：初期リダイレクト、IdPページレンダリング、認証情報検証、MFAチャレンジ、アサーションまたはトークン交換、最初の認証済みページの読み込み。
スクリプト化されたブラウザステップはまさにその分割を提供します。各ステップは独立して測定され、それぞれのウォーターフォールリクエストを伴います。単一実行を目視する代わりに、各ステップの正常範囲のベースラインを取り、ステップレベルで逸脱時にアラートを出すことで、一段階の劣化でもエンドツーエンドの合計が許容内に見えていても目立ちます。
ステップごとのタイミングは議論をルーティング判断に変えます。IdPページレンダリングが2倍になったらタイムスタンプ付きでアイデンティティベンダーにチケットを送る。ポストコールバックのページ読み込みが2倍になったらアプリケーションチームへ。分割がなければ双方がお互いを指さし合います。
さらに鋭利にするなら、各ステップにマッピングした日から所有者タグを付けましょう：アプリ所有（コールバックURL、セッション作成、最初の認証済みページ）、IdP所有（ログインページレンダリング、認証検証、トークン交換）、ポリシー所有（MFAチャレンジ、条件付きアクセス決定、同意プロンプト）、ネットワーク所有（DNS、TLS、プロキシ、プライベートエージェントの到達可能性）。「ポリシー所有ステップが変化した」というアラートは事案引き継ぎを開き、議論ではなく素早い対応を促します。
ステップレベルのベースラインは、二値のアップ/ダウンチェックが全く捉えられない「じわじわ悪化する障害モード」も検知します：1秒から5秒に1か月かけて悪化するMFAサービスは障害アラートを起こしませんが、すべてのログインを劣化させ、ステップタイミングのトレンドラインで明確に見えます。ログインフローをログインページの監視と同様に監視し、ステップごとのデータにSSO境界のどちら側が問題かを知らせてもらいましょう。
まとめ
IAM保護されたアプリケーションを監視することは、認証経路をアプリケーションの一部として監視することを意味します。なぜなら、ユーザーにとってそうだからです。実用的なレシピはこうです：SSOリダイレクトチェーンをマップし、専用の最小権限アカウントでマルチステップのリアルブラウザトランザクションとしてフルログインをスクリプト化し、MFAはスコープを限定した免除または保管されたTOTPシードで慎重に対処し、すべての秘密を暗号化ストレージに保管し、毎回クリーンなセッションから開始し、各段階でタイミングを分割して障害を最初のアラートで適切なチームにルーティングします。
こうすれば、ログイン画面は盲点ではなくなります。IdPが遅延していることをヘルプデスクより前に知り、障害が自分のものかベンダーのものかを見分けられ、そのいずれかを証明するステップごとの記録が手に入ります。
ログイン画面の背後を監視しよう
EveryStepを使って、リアルブラウザのシンセティックモニタリングトランザクションとしてフルのSSOログインをスクリプト化し、認証情報を保管し、フローのすべてのステップを計測しましょう。無料トライアルを開始してください。
