運用を確立するには、事業継続に必要な、拡張性があり、測定・定量化可能な運用を支えるインフラを構成・整備する必要があります。Auth0 では、これには補助サービス (メールプロバイダーなど) の設定、デプロイ環境向けサービスの監視、異常な状況の検出、本番環境で問題が発生した際に迅速かつ円滑に復旧するための準備が含まれます。
効果的な運用体制を確立することは、成功している顧客にとって大きな成果につながっています。ワークフローを検討する際は、次のような点を考慮してください。
障害を事前に検知するには、何をすべきですか？
Auth0 の運用状況に関するデータをどのように取得できますか？
Auth0 サービスに関連する Auth0 のセキュリティ情報には、どのように対応すべきですか？
Auth0 は、Auth0 サービスに予定されている変更に関する情報を提供していますか？
Auth0 からの重要なお知らせをどのように確認できますか？
Auth0 のログデータを分析し、Auth0 の限られたデータ保持期間を超えて保持するには、どのように扱うべきですか？
アプリケーションのピーク負荷がレート制限やその他のエラーを引き起こしていないかを確認するには、Auth0 ログをどのように調査できますか？
ユーザーへの本番規模のメール配信を支えるには、どのメールサービスを使用すべきですか？本番環境で Auth0 の標準メールプロバイダーを使用できますか？
ファイアウォールを構成する必要はありますか？また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか？
新しい組織をどのようにプロビジョニングしますか？
顧客が独自の組織用 IdP
Auth0 は、Auth0 サービスの稼働を監視 する機能と、Auth0 のサービスステータス に関する情報を提供しています。さらに、Auth0 はセキュリティ関連の情報や、Auth0 サービスに予定されている変更に関する情報を、さまざまな通知 を通じて提供しています。Auth0 のログ サービスも、レート制限や過剰な負荷によって発生する制約を含め、運用上の異常を追跡して特定するための幅広い機能を提供します。
Auth0 には、統合を迅速化するためのメール配信サービスが標準で用意されています。ただし、これらのサービスは本番環境での大規模利用を想定したものではなく、メール配信に関する特定のサービスレベルや保証も提供しません。ベストプラクティスとして推奨されており、多くの顧客が採用しているのは、独自のメールサービスプロバイダー を構成することです。
また、Auth0 との統合や Auth0 の拡張機能の利用を支えるために、インフラストラクチャ の構成を変更する必要がある場合もあります。たとえば、内部または外部のインフラストラクチャにコールバックを提供する必要がある場合 (例: Actions、Rules、Hooks で外部 API 呼び出しを行う必要がある場合や、既存のレガシー ID ストレージを活用するためにカスタムデータベーススクリプトを使用する必要がある場合) は、ファイアウォール設定を構成する必要があることがあります。
システム内で組織をどのように表現するかが決まったら、次に組織自体をどのようにプロビジョニングするかを検討する必要があります。詳細については、組織のプロビジョニング を参照してください。
さらに、多くの顧客は、顧客側の組織管理者が独自のIdP を構成できるセルフサービス機能を提供するために、1 つ以上のセルフサービスポータルを開発しています。
Auth0 のステータスダッシュボード と Auth0 の稼働状況ダッシュボード では、Auth0 サービスの現在および過去のステータスを、人が確認しやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの第一段階として、運用担当者がステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは、障害通知を購読する機能も提供されています。また、Social Providers など、依存しているサードパーティの外部サービス のステータスも確認することを推奨します。こうした情報をすぐに確認できるようにしておくことで、問題のトラブルシューティング時に原因の切り分けを迅速に進めやすくなります。また、この情報は、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最上位に置くべきものです。
ベストプラクティス Auth0 および依存サービス (Social Providers など) のステータスを確認する方法に関する情報は、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最上位に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0 のステータスページで購読を設定することを推奨します。 パブリッククラウドサービスで障害が発生した場合、Auth0 は Root Cause Analysis (RCA) を実施し、その結果を Auth0 のステータスページに公開します。Auth0 は障害発生後、根本原因の特定に加え、寄与要因の分析や同様の問題の再発防止策の検討を含む徹底的な調査を行うため、RCA 文書の公開までに数週間かかる場合があります。
Auth0 は、サインアップ時のウェルカムメール、メールアドレスの確認、漏えいしたパスワード、パスワードのリセットなどのイベントに応じて、ユーザーにメール を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理をさらに高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに送信容量が制限されたテスト用メールプロバイダーが用意されていますが、本番環境で使用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまでは、メールテンプレートのカスタマイズは機能しません。
ベストプラクティス デフォルトの Auth0 メールプロバイダーは、本番環境で必要な量のメール送信やメールテンプレートのカスタマイズに対応していません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。 Auth0 で実行されるカスタムコード (Action、Rule、Hook、またはカスタムデータベーススクリプトなど) からお使いのネットワーク内のサービスを呼び出す場合、または 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 のセキュリティ情報 を定期的に確認してください。
ベストプラクティス ベストプラクティスとして、Auth0 のセキュリティ情報 ページを定期的に確認し、影響を受けるセキュリティ情報がある場合は、推奨される対応を実施してください。 Auth0 は、サービスの変更に関する情報を Auth0 の変更ログ で提供しています。変更を把握するため、Auth0 の変更ログを定期的に確認することを習慣にしてください。問題を調査するサポートチームにとっては、特にそれが破壊的変更 である場合、最近の変更が関連している可能性があるかどうかを判断するうえで、変更ログの確認が役立つことがあります。開発チームも、有用な新機能を特定するために変更ログを確認するとよいでしょう。
組織をプロビジョニングする際に必要な作業は、自社のシステム内で組織をどのように表現しているかによって異なります。少し立ち止まって、それらの組織のユーザーがアプリケーションをどのように利用するのかを検討するとよいでしょう。IAM システム向けに組織をどのように構成するかを判断するには、Multiple Organization Architecture を参照してください。
組織をプロビジョニングする際は、次の点を考慮する必要があります。
自社のアプリケーション設定やデータベースに組織を追加する必要があります
Auth0 の設定を変更する必要があります。これには、次の一部またはすべてが含まれます。
一意のテナントを作成する
データベース接続を追加する (組織ごとにユーザーを分離している場合)
この組織用のエンタープライズ接続を追加する
これには、その組織と連携して既存の設定を更新することや、レガシー組織でない場合は Auth0 テナント用の設定を追加することが含まれます。
組織の管理者をプロビジョニングする
ミスを防ぐため、新しい組織をより簡単にプロビジョニングできるように、組織管理者ポータル を作成するとよいでしょう。
組織管理者ポータルは、管理者が組織を作成、変更、削除できるポータルです。実施が必要な作業は、自社のシステム側と Auth0 テナント側の両方に複数あります。このポータルは、データストアや設定にアクセスする必要があるため、自社のシステム内に用意することになる可能性が高いでしょう。ただし、Auth0 では Auth0 Management API が提供されているため、自社のシステムで変更を行うのと同時に、Auth0 テナントにも変更を反映できます。
新しい組織を作成する主な方法は 2 つあります。どちらを選ぶかは、新しい組織を利用可能にするまでにどれだけ時間がかかっても許容できるかに大きく左右されます。
Auth0 テナントへのライブ更新 : 新しい組織をリアルタイムで作成できるようにしたい場合は、Auth0 Management API を使用して Auth0 テナントに直接変更を加える方法が適しているでしょう。これにより変更がリアルタイムで反映され、新しい組織をすぐに有効化できます。
ライブ更新には、検討すべき点がいくつかあります。問題を回避するために、直列で実行しなければならない操作があります。たとえば、接続でクライアントを有効にする操作や、Application にコールバック URL を追加する操作です。Management API で、一覧全体を取得し、新しい値を追加したうえで一覧全体を再送信する必要がある操作は、並行する 2 つの操作によって値の一方が上書きされるのを防ぐため、直列で実行する必要があります。
リポジトリを変更して再デプロイする : CI/CD パイプライン の一部として Deploy CLI (またはカスタム CLI) を利用している場合は、変更をリポジトリに直接 push し、その後で新しいデプロイを開始する方法のほうが適していることもあります。こちらは多少時間がかかることがありますが、バージョン履歴を残せることや、以前のバージョンを再デプロイして変更をロールバックできることといった利点があります。
ベストプラクティス 組織ごとに必要な項目専用のリポジトリを別に用意しておくと、他の共通コンポーネントを再デプロイせずに済むため、ミスのリスクを抑えられます。 Auth0 の接続 を使うと IdP の設定は簡単になりますが、顧客の組織の IdP をオンボーディングするには時間がかかることがあります。特に、定期的に新規顧客の組織へ販売している場合や、既存の組織で必要な IdP が変わる場合はなおさらです。そのため、多くのお客様は、顧客側の組織管理者が自分で IdP を設定できるセルフサービスポータルを構築する価値があると判断しています。これにより、自社の IT 部門の負荷を軽減できます。これを実現するために必要な接続管理機能 は、Auth0 Management API で提供されています。
推奨戦略の詳細を確認できるよう、ダウンロードして参照できる PDF 形式の計画ガイドを提供しています。
B2B IAM プロジェクト計画ガイド 多くの B2B プラットフォームでは、顧客ごとに組織単位で何らかの分離やブランディングを実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに当てはまる場合は、このような環境向けのガイダンスやベストプラクティスに目を通すことをお勧めします。
複数組織アーキテクチャ 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム