- 不具合を積極的に検出するには、どうしたら良いでしょうか？
- Auth0の操作上のステータスに関するデータは、どのようにしたら取得できるでしょうか？
- Auth0サービスに関連するAuth0のセキュリティ情報については、どのように対応したら良いでしょうか？
- Auth0には、Auth0サービスでは近い将来予定されている変更に関する情報は用意されていますか？
- Auth0から送られてくる重要なお知らせは、どのように確認したら良いでしょうか？
- Auth0ログデータを利用して、その内容を分析したり、Auth0で制限されているデータ保持期間よりも長く保存するには、どうしたら良いでしょうか？
- Auth0ログをスキャンして、アプリケーション内のピーク負荷がレート制限やその他のエラーを引き起こしていないかどうかを見極める方法を教えてください。
- ユーザーに送信するメール数に対応するには、どのメールサービスを使用したら良いでしょうか？現在の本番環境で、すぐに使用できるAuth0のメールプロバイダーは利用可能ですか？
- ファイアウォールを構成したり、Auth0からの情報を受け取る必要がある社内サービス用（カスタムデータサービス、Webサービス、メールサービスなど）に、どのファイアウォールポートを開くのかを知る必要がありますか？
- 新しい組織をどのようにプロビジョニングしますか？
- お客様ご自身で組織のを構成出来るようにするために、お客様に対してセルフサービスプロビジョニングを提供する必要がありますか？
サービスステータス
Auth0ステータスダッシュボードと、Auth0アップタイムダッシュボードには、人が解読可能な形式で、Auth0サービスの現在そして過去のステータスが表示されます。監視アラートが発動した場合、運営スタッフはトラブルシューティングの第一歩として、停電が発生していないか、ステータスダッシュボードを確認する必要があります。パブリッククラウドステータスページでは、契約している電力会社の停電に関する通知も確認することができます。また、ソーシャルプロバイダーなど、利用しているサードパーティの外部サービスのステータスも併せて確認することを推奨しています。こうした便利な情報を活用することで、問題のトラブルシューティングにあたる際に、考えられる原因を迅速に取り除くことができます。また、開発者だけでなく、ヘルプデスク要員にとっては、トラブルシューティング時において確認すべきチェックリストの最初の項目として役立ちます。ベストプラクティス
Auth0および依存するサービス（ソーシャルプロバイダーなど）の状態を確認する方法に関する情報は、開発者とヘルプデスクスタッフにとって、トラブルシューティングチェックリストのトップに来るべきです。Auth0のステータスページで利用登録し、ステータスの更新通知を受け取るようにセットアップすることをお勧めします。メールプロバイダーのセットアップ
Auth0は、会員登録、メール検証、侵害されたパスワード、パスワードリセットのイベントに関するメールをユーザーに送信します。イベントの種類ごとにメールテンプレートをカスタマイズしたり、メール処理を詳細に設定したりすることも可能です。Auth0には、テスト用のメールプロバイダーが用意されており、基本テスト用の機能は制限されています。本番での使用には、メールプロバイダーを独自にセットアップする必要があります。メールテンプレートのカスタマイズは、独自のプロバイダーを確立するまで有効になりません。ベストプラクティス
デフォルトのAuth0メールプロバイダーは、大量のメールの送信やメールテンプレートのカスタマイズに対応していません。運用環境にデプロイする前に独自のメールプロバイダーを設定するようにしましょう。インフラストラクチャ
ファイアウォール
Auth0で実行するカスタムコードでネットワーク内のサービスを呼び出す場合（Action、Rule、Hook、またはカスタムデータベーススクリプトなど）、または、Auth0でオンプレミスSMTPプロバイダーを構成した場合は、Auth0からのインバウンドトラフィックを許可するようにファイアウォールを構成しなければならないことがあります。ファイアウォールの通過を許可するIPアドレスは、各地域特有のものであり、内のRules、Hooks、カスタムデータベーススクリプト、およびメールプロバイダーの構成画面に表示されています。ロギング
イベントのロギングに加え、ログのスキャニングにおいて、Auth0にはイベントの異常を特定するために豊富な機能が用意されています（詳細に関しては、「ログドキュメンテーション」を参照してください）。Auth0ログの標準的なログ保存期間は、サブスクリプションレベルによって決まります。最短で2日間、最長で30日間の保存期間となります。Auth0サポートを活用して、外部のロギングサービスと統合することで、ログを外部で保存したり、組織全体にログアグリケーションを提供することもできます。ベストプラクティス
ログデータを外部のログ分析サービスに送信するには、ログストリーミングソリューションをぜひご活用ください。データの長期保存とログデータに対する高度な分析を可能にします。レート制限とその他のエラー
Auth0には、レート制限を超過すると報告されるエラーに独自のエラーコードを用意しています。ログの自動スキャンをセットアップしてレート制限エラーを確認する必要があります。こうすれば、ユーザーに影響が及ぶ前に、レート制限を超過しそうなアクティビティへ事前に対処することが可能です。また、Auth0では、他の種類のエラーに対するエラーコードも公開している、認証エラーに関するログだけでなく、Auth0 コールからのエラーをスキャンするのにも役立ちます（Management APIエラーコードは、Management API Explorer内の各コールの下に表示されます）。ベストプラクティス
ルール内からユーザープロファイル情報を取得するためにManagement APIを呼び出すことは、レート制限の発生の一般的な原因になります。なぜなら、そのようなAPIはすべてのログインと定期的なセッションチェックを呼び出すからです。監視
Auth0の実装を監視するためのメカニズムを構築する必要があります。構築することで、サポートまたはオペレーションチームは、先を見越してサービス停止に対処する上で必要な情報を適時受け取ることができます。Auth0にはモニタリングエンドポイントが用意されており、ご使用のモニタリングインフラストラクチャーに組み込むことができます。モニタリングエンドポイントは、サービスをモニタリングして消費に適切に対処するために開発されました。エンドポイントからは、Auth0に関するデータのみが提供されるという点に留意しておく必要があります。ユーザーのログイン能力を確認する上で必要不可欠である、完全なエンドツーエンドのモニタリングについては、合成トランザクションのモニタリングをセットアップすることを推奨しています。合成トランザクションのモニタリングをセットアップすることで、モニタリングの粒度が増し、Auth0とは無関係の停止状態に加え、性能の低下を検出できるようになりますので、これまで以上に積極的に対応することが可能になります。ベストプラクティス
代理ログイントランザクションを送信できる機能をセットアップすることで、認証のエンドツーエンドのモニタリングが容易になります。これはリソース所有者パスワード付与と権限のないテストユーザーを組み合わせて使用する簡単なアプリケーションで行うことができます。Auth0レート制限ポリシーについてもご確認ください。通知
Auth0からは数種類の通知が発せられます。通知には、テナントやプロジェクトに影響を与える可能性がある重要な情報が記載されているため、見落とさないように注意する必要があります。Auth0によって、予見的なセキュリティ通知など、操作に関する告知がダッシュボード管理者に送信されます。これらのメッセージを受け取るべき人がダッシュボード管理者になっていることを確認してください。
ダッシュボード通知
適時、Auth0からテナントに関連する重要なお知らせが送られてくることがあります。サービスに関するこれらのお知らせは、Auth0 Dashboardに届きます。お知らせする内容の重要度に応じて、Auth0 Dashboardに登録されている管理者にメールで通知されます。Dashboardには定期的にログインし、画面上部のベルアイコンで重要なお知らせが届いていないかを確認してください。また、Auth0からのメールは適時に確認する必要があります。メールには、対処すべき変更や実行すべきアクションに関する重要な情報が記載されている場合があります。Auth0のセキュリティ情報
Auth0では、複数のセキュリティ関連のテストを定期的に実行します。何らかの問題が見つかった場合は、事前に特定した上で、セキュリティ関連の変更を行う必要があるお客様に通知します。Auth0製品は拡張性を備えていますが、Auth0では影響が及ぶすべてのお客様を特定することは難しいため、Auth0セキュリティ情報を定期的に確認する必要があります。ベストプラクティス
定期的にAuth0 「セキュリティ情報」ページを確認し、セキュリティ情報の影響を受けている場合には、推奨される対策を講じることがベストプラクティスです。変更ログ
Auth0では、Auth0変更ログ内でサービスの変更に関する情報を確認できます。変更内容を把握しておくために、Auth0変更ログは定期的に確認しておく必要があります。問題をリサーチするサポートチームは、最新の変更が関連しているかを判断する上で、変更ログを確認することが有効な場合があります。特に、破壊的変更の場合には有効です。開発チームも、変更ログを確認して、有益と思われる新しい機能を特定したいと考えるはずです。組織をプロビジョニングする
ベストプラクティス
あるOrganizationをプロビジョニングする際に行う必要があることは、システム内でOrganizationがどのように存在しているかによります。これらのOrganizationのユーザーがどのようにアプリケーションとやり取りするようになるかを考慮するために時間が必要になるかもしれません。「Organizationの複数アーキテクチャ」をチェックして、あなたのIAMシステムでOrganizationを構成する方法を決定してください。組織のプロビジョニングでは、以下を考慮する必要があります。- 独自のアプリケーションの構成とデータベースの両方または片方に組織の追加が必要になります。
-
使用しているAuth0の構成を変更する必要があります。これには、以下の一部またはすべてが含まれます。
- 一意のテナントを作成する
- データベース接続を追加する（組織ごとにユーザーを分離する場合）
-
この組織にエンタープライズ接続を追加する
- これには、レガシー組織でない場合に、組織について、既存の構成を更新するか、Auth0テナントに構成を追加する作業が含まれます。
- 組織の管理者をプロビジョニングする
- 間違いを防ぐために、組織管理者ポータルを作成して、新しい組織をプロビジョニングしやすくすることをお勧めします。
組織管理者ポータル
組織管理者ポータルでは、管理者が組織の作成、編集、削除を行えます。独自のシステムとAuth0テナントの両方で、複数の作業を実行する必要があります。このポータルは、システム内のデータストアと構成にアクセスできるよう、独自のシステム内に必要となる可能性があります。ただし、Auth0はAuth0 Management APIを提供しているため、独自のシステム内で変更を行うと同時に、変更内容をAuth0テナントに反映することができます。 新しい組織を作成するには、主に2つの方法があります。どちらを選択するかは、新しい組織がデプロイされるまでに、どれだけの時間的な余裕があるかに依存します。- Auth0テナントにライブで更新 ：新しい組織をリアルタイムに作成したい場合には、Auth0 Management APIを使って、Auth0テナントを直接変更することをお勧めします。変更内容がリアルタイムで反映されるため、新しい組織の追加も即座に反映されます。
ライブアップデートには、いくつか考慮すべき点があり、一連の操作を順番に行うことで問題の発生を防がなければなりません。たとえば、接続でクライアントを有効にすること、アプリケーションにコールバックURLを追加すること、などです。Management APIで行う操作のうち、リスト全体を取得してそれに新しい値を追加し、リストを再発行するものは、必ず2つの操作を順番に実行しなければなりません。2つの操作が同時に行われると、いずれかの値が上書きされてしまうためです。
- リポジトリを変更してデプロイし直す ：CI/CDパイプラインの一部としてDeploy CLI（またはカスタムCLI）を活用している場合には、変更内容をリポジトリに直接プッシュしてから、新しいデプロイメントを始める方が好ましいかもしれません。多少時間がかかりますが、バージョン履歴や、以前のバージョンをデプロイし直して変更を取り消せるなどの利点があります。