- 障害を事前に検知するには、何をすべきですか？
- Auth0 の運用状況に関するデータをどのように取得できますか？
- Auth0 は、Auth0 サービスに予定されている変更に関する情報を提供していますか？
- Auth0 からの重要なお知らせをどのように確認できますか？
- Auth0 の限られたデータ保持期間を超えて保持し、分析できるようにするには、Auth0 のログデータをどのように扱うべきですか？
- アプリケーションのピーク負荷によってレート制限やその他のエラーが発生していないかを確認するには、Auth0 のログをどのようにスキャンできますか？
- ユーザー向けに本番環境レベルのメール配信を行うには、どのメールサービスを使用すべきですか？ 本番環境で Auth0 の標準メールプロバイダーを使用できますか？
- ファイアウォールを設定する必要はありますか？ また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか？
- 新しい組織をどのようにプロビジョニングしますか？
- 顧客が自分の組織用 を構成できるように、セルフサービスのプロビジョニングを提供する必要がありますか？
サービスステータス
Auth0 のステータスダッシュボードと Auth0 の稼働状況ダッシュボードでは、Auth0 サービスの現在および過去のステータスを、人が見てわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの最初の手順として、現在障害が発生していないかを運用担当者がステータスダッシュボードで確認する必要があります。パブリッククラウドのステータスページでは障害通知を購読することもできるため、Social Providers など、依存しているサードパーティの外部サービスのステータスも確認することを推奨します。こうした情報をすぐに確認できる状態にしておくと、問題のトラブルシューティング時に考えられる原因をすばやく切り分けるのに役立ち、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最優先項目とすべきです。 パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (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 からダッシュボード管理者に送信されます。こうしたメッセージを受け取る必要がある人がダッシュボード管理者になっていることを確認してください。
Dashboard の通知
Auth0 は随時、お客様の テナント に関する重要なお知らせを送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に表示され、内容の重要度に応じて、登録済みの Auth0 Dashboard 管理者にメールでも送信されます。定期的にダッシュボードにログインし、上部のベルアイコンを確認して、重要なお知らせが届いていないか確認するようにしてください。あわせて、Auth0 からのメールにも変更内容や必要な対応に関する重要な情報が含まれている場合があるため、速やかに確認してください。変更履歴
Auth0 は、サービスの変更に関する情報を Auth0 の変更履歴で提供しています。変更内容を把握できるよう、Auth0 の変更履歴を定期的に確認する習慣をつけることをおすすめします。問題を調査するサポートチームにとっては、最近の変更が関係している可能性がないかを判断するうえで、変更履歴の確認が役立つ場合があります。特に、それが破壊的変更である場合は重要です。また、開発チームも、有益な新機能を見つけるために変更履歴を確認するとよいでしょう。組織のプロビジョニング
組織をプロビジョニングする際に必要な作業は、組織がシステム内でどのように表現されているかによって異なります。ここでは少し立ち止まって、それらの組織のユーザーがアプリケーションとどのように関わるのかを検討することが重要です。IAM システムで組織をどのように設定すべきかを判断するには、複数組織アーキテクチャ を参照してください。 組織をプロビジョニングする際は、次の点を考慮する必要があります。- 自身のアプリケーション設定やデータベースに、その組織を追加する必要があります
-
Auth0 の設定を変更する必要があります。これには、以下の一部またはすべてが含まれます。
- 一意のテナントを作成する
- データベース接続を追加する (組織ごとにユーザーを分離している場合)
-
この組織向けのエンタープライズ接続を追加する
- これには、その組織と連携して既存の設定を更新するか、レガシー組織でない場合は Auth0 テナント向けの設定を追加する作業が含まれます。
- その組織の管理者をプロビジョニングする
- ミスを避けるため、新しい組織を簡単にプロビジョニングできるように、組織管理者ポータル を作成するとよいでしょう。
組織管理者ポータル
組織管理者ポータルとは、管理者が組織の作成、変更、削除を行えるようにするためのポータルです。必要な作業は、自社システムと Auth0 テナントの両方で複数発生します。このポータルは、データストアや設定にアクセスできるよう、通常は自社システム内に用意する必要があります。一方で、Auth0 には Auth0 Management API が用意されているため、自社システムで変更を行うのと同時に、Auth0 テナントにも変更を反映できます。 新しい組織を作成する方法には、大きく 2 つのアプローチがあります。どちらを選ぶかは、新しい組織をデプロイするまでにどれくらい時間がかかっても許容できるかに大きく左右されます。- Auth0 テナントへのライブ更新: 新しい組織をリアルタイムで作成できるようにしたい場合は、Auth0 Management API を使って Auth0 テナントに直接変更を加える方法が適しています。これにより、変更をリアルタイムで反映でき、新しい組織の追加もすぐに有効になります。
- リポジトリを変更して再デプロイする: CI/CD pipeline の一部として Deploy CLI (またはカスタム CLI) を活用している場合は、変更をリポジトリに直接プッシュしてから、新しいデプロイを開始する方法のほうが適しているかもしれません。こちらは少し時間がかかる場合がありますが、バージョン履歴を管理しやすく、以前のバージョンを再デプロイして変更を戻せるという利点があります。