運用を確立するには、事業継続に必要な、拡張性があり、測定・定量化可能な運用を支えるインフラストラクチャを構成またはセットアップする必要があります。Auth0 では、これには補助サービス (メールプロバイダーなど) の構成、デプロイ環境向けの監視サービスの整備、異常な状況の検出、本番環境で問題が発生した際に迅速かつ円滑に復旧できるよう事前に備えることが含まれます。
効果的な運用体制の確立は、成功している顧客がその効果を実感している取り組みであり、ワークフローを検討する際には考慮すべき点がいくつもあります。
障害を事前に検知するには、何を行うべきですか。
Auth0 の運用状況に関するデータをどのように取得できますか。
Auth0 サービスに関連する Auth0 のセキュリティ情報にどのように対応すべきですか。
Auth0 は、Auth0 サービスに予定されている変更に関する情報を提供していますか。
Auth0 からの重要なお知らせをどのように確認できますか。
Auth0 の限られたデータ保持期間を超えてログデータを分析および保持できるようにするには、Auth0 のログデータをどのように扱うべきですか。
アプリケーションのピーク負荷によってレート制限やその他のエラーが発生していないかを判断するために、Auth0 ログをどのようにスキャンできますか。
ユーザーへの本番環境レベルのメール送信を支えるには、どのメールサービスを使用すべきですか。本番環境で Auth0 の標準メールプロバイダーを使用できますか。
ファイアウォールを構成する必要はありますか。また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか。
Auth0 は、Auth0 サービス運用の監視 機能と、Auth0 のサービスステータス に関する情報を提供しています。さらに、Auth0 は、Auth0 サービスに関するセキュリティ関連の情報や今後予定されている変更に関する情報を、さまざまな通知 を通じて提供しています。Auth0 のログ記録 サービスも、レート制限や過剰な負荷によって生じる制約を含め、運用上の異常を追跡して特定するための幅広い機能を提供します。
Auth0 は、標準でメール配信サービスを提供しており、統合を迅速に進めるのに役立ちます。ただし、これらのサービスは本番環境での大規模利用を想定したものではなく、メール配信に関して特定のサービスレベルや保証もありません。ベストプラクティスとして、通常は独自のメールサービスプロバイダー を構成することを推奨します。
また、Auth0 との統合や Auth0 の拡張機能の利用を支えるために、インフラストラクチャ 構成を変更する必要がある場合もあります。たとえば、内部または外部のインフラストラクチャにコールバックを提供する必要がある場合 (例: Actions、Rules、Hooks で外部 API 呼び出しを行う必要がある場合、または既存のレガシーなアイデンティティストレージを活用するためにカスタムデータベーススクリプト経由で行う場合) は、ファイアウォール設定を構成する必要があることがあります。
Auth0 のステータスダッシュボード と Auth0 の稼働状況ダッシュボード では、Auth0 サービスの現在および過去のステータスを、人が読みやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初のステップとして、運用担当者がステータスダッシュボードを確認し、現在障害が発生していないかを確認してください。パブリッククラウドのステータスページでは、障害通知を購読することもできます。また、Social Providers など、依存しているサードパーティの外部サービス のステータスも確認することを推奨します。こうした情報をすぐ参照できるようにしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ち、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最優先項目にすべきです。
ベストプラクティス Auth0 および依存サービス (Social Providers など) のステータス確認方法に関する情報は、開発者とヘルプデスク担当者の双方のトラブルシューティングチェックリストの最優先項目に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページで購読設定することを推奨します。 パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (RCA) を実施し、その結果を Auth0 のステータスページで公開します。Auth0 では、障害発生後に根本原因の特定、寄与要因の分析、再発防止策の検討を含む徹底的な調査を実施するため、RCA 文書が公開されるまでに数週間かかる場合があります。
Auth0 は、サインアップ時のウェルカムメール、メールアドレスの確認、漏えいしたパスワードの通知、パスワードリセットなどのイベントに応じて、ユーザーにメール を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理を高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに送信容量が制限されたテスト用メールプロバイダーが用意されていますが、本番環境で使用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまで、メールテンプレートのカスタマイズは機能しません。
ベストプラクティス Auth0 のデフォルトのメールプロバイダーは、本番環境に必要な規模のメール送信やメールテンプレートのカスタマイズをサポートしていません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定する必要があります。 Auth0 で実行されるカスタムコード (Action、Rules、Hooks、またはカスタムデータベーススクリプトなど) がネットワーク内のサービスを呼び出す場合、または Auth0 でオンプレミスの SMTP プロバイダーを設定している場合は、Auth0 からの受信トラフィック を許可するようにファイアウォールを設定する必要がある場合があります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、Auth0 Dashboard
Auth0 は、イベントのログ記録に加え、イベントの異常を特定するためのログスキャンについても幅広い機能を提供しています (詳細はログのドキュメント を参照してください) 。Auth0 ログの標準保持期間はサブスクリプションレベルによって異なり、最短は 2 日、最長でも 30 日です。外部ログサービスとの統合に対する Auth0 のサポートを活用することで、この期間を超えてログを保持できるほか、組織全体のログを集約することもできます。
ベストプラクティス ログストリーミングソリューションのいずれかを活用して、ログデータを外部のログ分析サービスに送信してください。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。 サブスクリプションレベルに応じたログデータの保持期間 を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート拡張機能を実装してください。Auth0 Marketplace では、ログストリーミングソリューション のいずれかを利用できます。
開発チームは、トラブルシューティングや、QA テストでは見つけにくい断続的なエラーの検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とすることがあるでしょう。包括的な分析機能を備えたサービスにログファイルをエクスポートすることで、利用傾向や Attack Protection
Auth0 は、レート制限を超過した 場合に報告されるエラーに対して、一意のエラーコードを提供しています。レート制限エラーを検出できるようにログの自動スキャンを設定し、ユーザーに大きな影響が及ぶ前に、レート制限に達しているアクティビティに事前に対処することをおすすめします。Auth0 は他の種類のエラーについてもエラーコードを公開しているため、認証エラー に加えて、Auth0 Management API Management API Explorer で各呼び出しの下に表示されます) 。
ベストプラクティス Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すことは、レート制限エラーの一般的な原因です。これは、そのような API 呼び出しがログインのたびに実行される可能性があるほか、定期的なセッションチェックでも実行されるためです。 サポートチームや運用チームがサービス停止に先回りして対処するために必要な情報を適時受け取れるよう、Auth0 実装の監視 の仕組みを整備する必要があります。Auth0 には、監視基盤に組み込める監視用エンドポイントが用意されています。これらのエンドポイントは、監視サービスで利用しやすいレスポンスを返すよう設計されています。ただし、提供されるのは Auth0 に関するデータのみです。ユーザーがログインできるかどうかを確認するうえで不可欠な完全なエンドツーエンド監視を行うには、合成トランザクション監視を設定することを推奨します。これにより監視の粒度が向上し、Auth0 に起因しない障害やパフォーマンス低下も検出できるようになるため、より先回りした対応が可能になります。
Auth0 からは複数の種類の通知が送信されます。テナントやプロジェクトに影響を与える可能性のある重要な情報が含まれているため、注意して確認してください。
事前のセキュリティ通知やその他の運用上のお知らせは、Auth0 からダッシュボード管理者に送信されます。こうしたメッセージを受け取る必要がある担当者がダッシュボード管理者になっていることを確認してください。
Auth0 は、テナントに関する重要なお知らせを随時送信することがあります。サービスに関するこれらのお知らせは Auth0 Dashboard に送信され、内容の重要度に応じて、登録済みの Auth0 Dashboard 管理者へメールアドレスでも送信されます。重要な通知を見逃さないよう、定期的に Dashboard にログインし、上部のベルアイコンを確認する習慣をつけてください。さらに、Auth0 からのメールには、対応が必要な変更や実施すべきアクションに関する重要な情報が含まれている場合があるため、速やかに確認してください。
Auth0 では、セキュリティに関するさまざまなテストを定期的に実施しており、問題が見つかった場合は、セキュリティ上の変更が必要な顧客を積極的に特定して通知します。ただし、Auth0 製品は拡張性が高いため、影響を受けるすべての顧客を Auth0 が特定できるとは限りません。そのため、Auth0 のセキュリティ情報 を定期的に確認してください。
ベストプラクティス ベストプラクティスとして、Auth0 の Security Bulletins ページを定期的に確認し、該当するセキュリティ情報がある場合は、推奨される対応を実施してください。 Auth0 は、サービスの変更に関する情報を Auth0 の変更ログ で公開しています。変更を把握するために、Auth0 の変更ログを定期的に確認することを習慣にしてください。問題を調査しているサポートチームにとっては、最近の変更が関係している可能性があるかを判断するうえで、特にそれが破壊的変更 である場合、変更ログの確認が役立つことがあります。開発チームにとっても、有用な新機能を見つけるために変更ログを確認することは有益です。
推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。
B2C IAM プロジェクト計画ガイド 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム