運用化（B2C）

運用化には、インフラストラクチャの構成やセットアップを行って、継続的なビジネスに欠かせない運用の拡張、測定や定量化に対応させることが必要です。Auth0での運用化には、対応するサービス（メールプロバイダーなど）の構成、デプロイメント用サービスの監視、異常な状況の検知、運用環境で問題が発生したときに素早く回復させるための準備などが含まれます。

成功している顧客は、合理的な運用の動作が利益に繋がることを経験から熟知しています。ワークフローを検討するときには、考慮するべきいくつかの事柄があります。

• どうすれば失敗を事前対応的に検知できるのか

• Auth0の運用ステータスにあるデータをどのようにすれば取得できるのか

• Auth0サービスに関するAuth0セキュリティ速報についてはどうすればいいのか

• Auth0サービスで近日に行われる変更の情報をAuth0は提供するのか

• Auth0からの重要な通知をどうすれば確認できるのか

• Auth0ログのデータをどのように扱えば、それを分析したり、Auth0が制限するデータ保持期間よりも長く保持したりできるのか

• Auth0ログをどのように調べれば、アプリケーションでの最大負荷がレート制限や他のエラーをトリガーするか判断できるのか

• どのメールサービスを使用すれば、ユーザーへのメールメッセージの作成量に対応できるのかそのまま使えるAuth0のメールプロバイダーは運用環境で使用できるのか

• ファイヤーウォールを構成する必要があるのか、そして、（カスタムデータベース、Webサービス、メールサーバーなど）Auth0からの通信を受け取る内部サービス用に、どのファイヤーウォールのポートを開く必要があるのか

Auth0はAuth0サービスの運用を監視する機能や、Auth0のサービスステータス情報を提供する機能に対応しています。また、Auth0は各種の通知を通して、セキュリティ関連の速報やAuth0サービスに計画されている変更の情報を提供しています。Auth0のログサービスには、レート制限や過度の負荷が原因で発生した制約など、運用上の異常を追跡や特定する機能が豊富に備わっています。

Auth0はそのままで便利に使えるメール配信サービスを提供して、速やかな統合を後押ししています。ただし、これらのサービスは運用環境での使用規模に合わせたものではなく、特定のサービスレベルを対象に提供したり、メールの配信について保証を行ったりはしません。ベストプラクティスとして、独自のメールサービスプロバイダーを構成することが推奨され、これは一般的に顧客にも受け入れられています。

Auth0との統合やAuth0の拡張性の使用に対応するには、インフラストラクチャの構成を変更する必要があるかもしれません。たとえば、内部や外部のインフラストラクチャがコールバックできるようにするには（外部APIの呼び出しをアクション、ルール、フック、または既存のレガシーストレージの利用が必要な場合はカスタムデータベース接続で行うなど）、ファイヤーウォール設定の構成が必要かもしれません。

Auth0のステータスダッシュボートと稼働時間ダッシュボートには、Auth0サービスの過去と現在のステータスが人間に読める形式で表示されます。追跡アラートが発生したら、トラブルシューティングの第1段階として、運用スタッフは必ずステータスダッシュボートで現在の停止状態を確認してください。パブリッククラウドのステータスページにも、機能停止の通知を受け取るように登録する手段があります。また、ソーシャルプロバイダーなど、依存関係にあるサードパーティーの外部サービスでもステータスを確認するようにしてください。この情報はトラブルシューティングで可能性のある原因を除外するのに役立つため、開発者やヘルプデスク担当者はトラブルシューティングのチェックリストで必ず最優先の確認事項してください。

パブリッククラウドサービスが停止すると、Auth0は根本原因分析（RCA）を行い、その結果をAuth0のステータスページで公開します。Auth0は停止後に、根本原因の特定、寄与要因、再発防止方法などを含めた徹底的な調査を行うため、RCAドキュメントの公開には数週間かかることがあります。

サインアップの歓迎、メール検証、パスワード漏洩、パスワードリセットのイベントなどについて、Auth0はユーザーにメールを送信します。イベントタイプのそれぞれにメールテンプレートをカスタマイズすることができます。また、メールの扱いを細やかにカスタマイズすることもできます。Auth0はテストメールプロバイダーを提供していますが、基本的なテスト用に機能が制限されているため、運用での使用には独自のメールプロバイダーをセットアップしなければなりません。メールテンプレートのカスタマイズは、独自のプロバイダーを確立するまで動作しません。

Auth0で実行するカスタムコード（アクション、ルール、フック、カスタムデータベーススクリプト）がネットワーク内のサービスを呼び出す場合、または、Auth0でオンプレミスSMTPプロバイダーを構成した場合は、Auth0からのインバウンドトラフィックを許可するようにファイアウォールを構成しなければならないことがあります。ファイヤーウォールを通過できるIPアドレスは各リージョンに特有で、ルール、フック、カスタムデータベーススクリプト、Auth0 Dashboardのメールプロバイダー構成画面にリストがあります。

Auth0には、イベントのログを記録したり、異常なイベントの特定にログを調べたりするための豊富な機能が備わっています（詳細についてはログのドキュメントを参照してください）。Auth0ログの標準的な保持制限はサブスクリプションのレベルによって決定され、最も短い期間は2日、最も長い期間は30日です。Auth0は外部のログサービスとの統合に対応しているため、外部でログを保持する他にも、組織全体でログを集積することができます。

ログデータを外部のログ分析サービスに転送するには、サブスクリプションのレベルでログデータの保持期間を確認し、ログデータのエクスポート拡張機能を実装してください。Auth0 Marketplaceで提供しているログストリーミングソリューションの1つを使用することができます。

開発チームは、トラブルシューティングやQAテストでは見つけにくい断続的なエラーを検出するためにログファイルを使用できます。セキュリティチームは、フォレンジックデータが必要になるときのために、ログデータを取得しておきたいかもしれません。総合的な分析を行うサービスにログファイルをエクスポートすると、利用の傾向や攻撃防御のトリガーなどのパターンを理解するのに役立てることができます。

Auth0はレート制限の超過で報告されるエラーに一意のエラーコードを提供します。ログの自動スキャンを設定してレート制限エラーを確認し、ユーザーに影響が及ぶ前に、レート制限を超えそうなアクティビティに予見的に対処することが賢明です。Auth0は他のエラータイプのエラーコードも公開しており、認証エラーやAuth0 Management API呼び出し（Management APIのエラーコードはManagement API Explorerで呼び出しの下部に表示されます）について、ログを調べるのに役立ちます。

Auth0実装の監視メカニズムを設置して、サポートチームや運用チームが適時な情報を受け取り、サービスの停止に予見的に対処できるようにします。Auth0は監視エンドポイントを提供し、監視インフラストラクチャに組み込めるようにしています。これらのエンドポイントは、監視サービスの使用に適した応答を返すように設計されています。提供するのがAuth0についてのデータのみであることに注意してください。完全なエンドツーエンド監視は、ユーザーがログインできることを確認するには不可欠ですが、合成トランザクションをセットアップすることをお勧めします。監視がより細やかになり、Auth0に無関係な停止や性能の劣化が検知できるため、さらに予見的に対処することができます。

Auth0からの注意を払うべき通知にはいくつかの異なる種類があり、テナントやプロジェクトに影響を与えかねない重要な情報が含まれています。

Auth0は時々、テナントに関する重要な告知を送信します。サービスについてのこれらの告知はAuth0 Dashboardに送信され、告知内容の重要度によっては、登録済のAuth0 Dashboard管理者にメールで通達されます。Dashboardには定期的にログインし、画面上部のベルアイコンで重要なお知らせが届いていないかを確認してください。また、Auth0からのメールには対処が必要な変更についての重要情報が含まれていることがある、必ず適時に確認してください。

Auth0は定期的にセキュリティ関連のテストを行います。問題を発見すると、事前対処として特定し、セキュリティ関連の変更が必要な顧客に通知します。ただし、Auth0製品には拡張性があり、影響を受ける顧客をすべて特定することが不可能かもしれないため、Auth0のセキュリティ速報は定期的に確認してください。テクニカルアカウントマネージャーに連絡し、組織のセキュリティ担当者の情報が最新であることを確認してください。

Auth0はサービスに対する変更の情報をAuth0の変更履歴に記載します。Auth0の変更履歴は定期的に確認し、変更内容を理解するようにしてください。サポートチームが問題を調査するときには変更履歴を確認し、最近の変更の中でも特に互換性のない変更への関連性を判断するのに役立つかもしれません。開発チームにとっても、有益な新機能を見つけるには変更履歴が便利です。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。