- 障害を事前に検知するには、何をすべきでしょうか?
- Auth0 の運用状況に関するデータをどのように取得できますか?
- Auth0 は、Auth0 サービスにおける今後の変更に関する情報を提供していますか?
- Auth0 からの重要なお知らせをどのように確認できますか?
- Auth0 の限られたデータ保持期間を超えて分析・保管できるようにするには、Auth0 のログデータをどのように扱うべきでしょうか?
- アプリケーションのピーク負荷によってレート制限やその他のエラーが発生していないかを判断するために、Auth0 のログをどのように調べればよいですか?
- ユーザー向けに本番環境で必要な規模のメール配信を支えるには、どのメールサービスを使うべきでしょうか?本番環境で Auth0 の標準メールプロバイダーを使用できますか?
- ファイアウォールを構成する必要はありますか?また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか?
サービスステータス
Auth0のステータスダッシュボードとAuth0の稼働状況ダッシュボードでは、Auth0サービスの現在および過去の状態を、人が見てわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの第一段階として、運用担当者はまずステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは障害通知の購読も可能です。また、Social Providers など、依存しているサードパーティの外部サービスのステータスも確認することをお勧めします。こうした情報をすぐ確認できるようにしておくと、問題のトラブルシューティング時に原因候補をすばやく切り分けるのに役立ちます。そのため、これらの確認事項は、開発者だけでなくヘルプデスク担当者にとっても、トラブルシューティングチェックリストの最上位に置くべきです。 パブリッククラウドサービスで障害が発生した場合、Auth0は根本原因分析 (RCA) を実施し、その結果をAuth0のステータスページに公開します。Auth0では、障害発生後に根本原因の特定、寄与要因の分析、再発防止策の検討を含む徹底的な調査を行うため、RCAドキュメントの公開までに数週間かかる場合があります。メールプロバイダーの設定
Auth0 は、サインアップ時のウェルカムメール、メールアドレスの確認、パスワード漏えい、パスワードリセットなどのイベントに応じて、ユーザーにメールを送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理を高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに送信容量が限られたテスト用メールプロバイダーが用意されていますが、本番環境で使用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまでは、メールテンプレートのカスタマイズは機能しません。インフラストラクチャ
ファイアウォール
Auth0 で実行されるカスタムコード (Action、Rule、Hook、またはカスタムデータベーススクリプトなど) からネットワーク内のサービスを呼び出す場合、または Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、Auth0 からのインバウンドトラフィック を許可するようにファイアウォールを設定する必要がある場合があります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、 の Rules、Hooks、カスタムデータベーススクリプト、メールプロバイダーの設定画面に一覧表示されています。ログ
Auth0 には、イベントをログに記録するための豊富な機能があり、さらにログをスキャンしてイベントの異常を特定することもできます (詳細はログのドキュメントを参照してください) 。Auth0 のログの標準保持期間はサブスクリプションレベルによって異なり、最短で 2 日、最長でも 30 日です。Auth0 がサポートする外部ログサービスとの連携を活用すれば、この期間を超えてログを保持できるほか、組織全体のログを集約することも可能です。 ご利用のサブスクリプションレベルにおけるログデータの保持期間を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート拡張機能を実装してください。Auth0 Marketplace では、ログストリーミングソリューションのいずれかを利用できます。 開発チームは、トラブルシューティングや、QA テストでは見つけにくい断続的なエラーの検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とするでしょう。包括的な分析機能を提供するサービスにログファイルをエクスポートすることで、利用傾向や のトリガーといったパターンの把握に役立ちます。レート制限やその他のエラー
Auth0 では、レート制限を超過したときに報告されるエラーに対して、固有のエラーコードを提供しています。ログを自動的にスキャンしてレート制限エラーを検出できるように設定しておくと、レート制限に達するアクティビティがユーザーに大きな影響を及ぼす前に、先手を打って対処できます。Auth0 は他の種類のエラーについてもエラーコードを公開しており、認証エラーに加えて、Auth0 呼び出しによるエラーについてもログをスキャンすると役立ちます (Management API のエラーコードは、Management API Explorer で各呼び出しの下に表示されます) 。監視
サービス停止に先回りして対処するために必要な情報をサポートチームまたは運用チームが適時受け取れるよう、Auth0 実装の監視の仕組みを整備する必要があります。Auth0 では、監視基盤に組み込める監視用エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすいレスポンスを返すよう設計されています。なお、これらのエンドポイントで取得できるのは Auth0 に関するデータのみです。ユーザーがログインできるかどうかを確認するうえで不可欠な、完全なエンドツーエンド監視を行うには、合成トランザクション監視を設定することをおすすめします。これにより監視をより細かい粒度で行えるようになり、Auth0 に起因しない障害やパフォーマンス低下も検知できるため、より先回りした対応が可能になります。通知
Auth0 からの通知にはいくつかの種類があり、テナントやプロジェクトに影響する重要な情報が含まれることがあるため、注意して確認してください。セキュリティに関する事前通知やその他の運用上のお知らせは、Auth0 から Auth0 Dashboard 管理者に送信されます。こうしたメッセージを受け取る必要がある担当者が Auth0 Dashboard 管理者になっていることを確認してください。