認証ログを観測しよう

安全なユーザー認証プロセスは、ECサイトで商品を購入したり、SNSやメールを利用したりする際に個人情報を保護するために重要です。皆さまのサービスを含め、ウェブで提供されているほとんどのサービス・アプリケーションにはユーザーが安全にログインできるようなユーザー認証プロセスが含まれています。あなたのサービスにユーザーがログインするのに問題が発生している場合、できるだけ早く見つけて修正する必要があります。

認証プロセスは常に深刻なリスクを抱えています。例えば、悪意のあるユーザーがあなたのサービスを危険に晒す方法を探しているかもしれません。セキュリティ侵害は一つ起きると運営企業に数億円単位の損害をもたらすことすらあります。

だからこそ、ユーザーの認証フローを監視し、ログを取ることが次の二つの観点から重要です。ひとつ目はログから異常をプロアクティブに検出する事でサーバーサイドに行った変更と突き合わせてみる事。ふたつ目は記録を残しサーバーアプリケーションが危険にさらされているかどうか後から監査できるようにするためです。

では、認証フローのログをどのようにとり、観測するのが良いのでしょう。この記事では以下について説明します。

• ログインのモニタリングと認証ログがなぜ重要なのか
• 認証フローをどのようにロギングするか、認証ログに何を含めるべきか
• 認証ログがどのような問題を見つけて、解決するのに役立つか
• 認証用サードパーティツールに存在する脆弱性の発見方法

次のスクリーンショットは、New Relicのようなオブザーバビリティプラットフォームがどのようにログを観測するのかを示しています。 New Relicを利用すればそのログがログイン試行なのか、繰り返し発生している内部エラーなのか、などのパターンを可視化し観測することができます。

認証ログを使用したログインモニタリングの価値

New Relicのオブザーバービリティプラットフォームとしてのモニタリングに関するスタンスはシンプルです；"可能な限りサービス内、すべてのアプリケーションを観測するべきである" というものです。この「すべてのアプリケーション」には内部で発生する認証フローに関連するログも含まれます。
New Relic APM の言語エージェントを利用すればサーバーアプリケーションに導入するだけで認証に関連するものを含むすべてのログ、イベントを自動的に記録し始めることが可能です。

ログインのフローは、多くのサービスで一般的なユーザー体験の一部です。ユーザー認証が必須のサービスでは、最も重要なインタラクションはユーザーがログインをした後でしか発生しません。
これは一般ユーザー向け、社内向けどちらのサービスにも当てはまります。社内向けサービスの場合、ログイン処理に問題があれば生産性やセキュリティが損なわれるリスクがあります。

多くの企業ではOAuthやSAMLなど、ユーザーのグループごとに異なる認証システムを採用している場合があります。OktaやAuthO, Googleなど外部の認証サービスを利用している場合もありますし、企業によってはカスタム認証・認可ソリューションを開発言語向けのライブラリを活用し作成していたりもします。

そして認証フローにおいてはフロントエンドアプリケーションにおいて他のサイトやナビゲーションバー、コンポーネントに依存することにより複雑になっています。複雑な認証フローと認証システムを扱っていれば、どこか一つに問題があれば連鎖的に下流の認証フロー処理に影響を及ぼす可能性が常にあります。

それでは、これらのフローで発生するログを適切に記録しモニタリングするにはどうすればよいでしょう。

認証を監視するためのアプローチは以下の通りです：

• まだ設定していない場合は、アプリケーションログ管理を設定します。ログ管理が初めての場合は「ログ管理を始めよう」をご覧ください。ログ管理は、アプリケーションへの計装と必要に応じたNew Relicへのログ転送設定で構成されています。繰り返しになりますが、認証そのものに関連するかどうかに関係なく、アプリケーション内のすべてのイベントをログに記録することをお勧めします。唯一の例外はシステムの外部に記録したくない、個人情報などセンシティブなデータですが、それら機密データをマスクする方法は用意されています。

• 認証ログに、ログを出力した認証サービスを識別できる属性が含まれるか確認してください。基本的にNew Relicはこれを自動的に処理しますが、独自に実装したソリューションや識別可能な属性を自動的に追加しないプラットフォームを使用している場合は、JSONのような標準化された形式を使用し（必要に応じて認証ログをカスタマイズして）、可視化や分析に役立つデータを付与しましょう。New Relicでは、データをより良く整理するためにタグも使用できます。

• ログは、APMやInfrastructureなど他の関連するテレメトリーデータとのコンテキストの中でより有用性が高まります。New Relicのようなオブザーバビリティプラットフォームを使用していれば、自動的にパターンを検出する機能を使用してログ内の異常なパターンを検出できます。

• New RelicのVulnerability Managementのような脆弱性管理ツールを使用することで、クリティカルな脆弱性やCVE（Critical Vulnerabilities and Exposures）が発生したらすぐに検出できます。ログインに関連するツールのCVEは、大規模なデータ侵害やシステムへの不正アクセスを引き起こす可能性があります。

独自の認証ログに含めるべきデータ

New Relicのプラットフォームのエージェントを使用すれば、サードパーティのソフトウェアをインストールしたり維持したりすることなく、自動的にアプリケーションイベントをログに記録します。しかし、自分で認証ログをゼロから書く場合は、以下のデータを含めるべきです：

• Who（誰が）：ユユーザーがあなたのアプリケーションにログインした場合、ログでユーザーを識別する必要があります
   
• What(何を)：ユーザーが何を行ったのか、例えばログインに成功したのか失敗したのか、行動を記録する必要があります
   
• When(いつ)：すべてのログにはタイムスタンプを含めるべきです。認証ログも例外ではありません
   
• How(どのように)：どのログインサービスが使用されたのかを記録します。これはアプリケーションが複数のログインサービスを使用している場合特に重要です
   
• Where(どこで)：ログにはユーザーのIPアドレスを含めるべきです。これにより、特定の地域に偏って問題が発生しているのか特定ができます

これらの情報を構造化して記録することをおすすめします。構造化されパース可能なログであれば解析しフィルタリングと検索をより容易に実行できます。

6/15/2024 15:34:03: Log in user ‘Albert Einstein’ success

上記のような構造化されていないログではWhenとWhoは含まれますが、When, Howなど重要な情報が欠落してしまっています。また、JSONのようなフォーマットに則っていないため問題が発生した際動線を分析するのが困難です。

6/15/2024 15:34:03: { actionType: ‘logIn’, service: ‘rails bcrypt’, user: ‘Albert Einstein’, ip: 1.1.1.1 result: ‘success’ }

対して上記のような構造化されたログではどうでしょうか。見ての通りデータは`actionType`や`service`のようなキーと値のペアに整理されています。これにより、特定のキーによるログデータのフィルタリングや検索が容易になります。特定のサービスでフィルタリングして各サービスのパフォーマンスを確認したり、`actionType`でフィルタリングして`logIn`アクションのレイテンシーやエラーレートを特に見るなど、様々なことが可能になります。

カスタムログのフォーマット作成や出力に手間をかけたくない場合も、New Relicを使えば環境内すべてのサービスを自動的に計装し、コンテキスト内のログ出力；Logs in Context をセットアップ可能です。

標準化された認証ログレポートを使用し、見つけることができる可能性のあるもの

認証フローの観測を実施し、特定のパターンで検出トレンドや発生数を監視しましょう。以下のような問題を検出するのに役立ちます：

• セキュリティ上の脅威：例えば、ログイン試行やログイン失敗の回数が急増しているかもしれません。また、DoS攻撃の場合、ログイン試行が通常より減少している可能性があります
   
• ログインエラー：エラーの急増やログイン失敗の増加は、ログインプロセスにエラーがあることを示す可能性があります。サインインページへの訪問や成功ページやエラーページへのリダイレクトを含むプロセスの各ステップでログを確保することで、プロセスのどこで問題が発生しているのかを正確に特定することができます
   
• ログインの傾向：ページのレイテンシから時間経過による合計サインイン数まで、ログインデータの傾向を分析します
   
• 法令遵守/コンプライアンスのためのデータ管理：データコンプライアンスの目的で、セキュリティデータなどのログデータを長期間保存する必要があるかもしれません。セキュリティインシデントはしばしば数ヶ月後になって初めて明らかになることが多く、必要に応じてアーカイブされたログデータを確認することができます

New Relicを使用すれば、ログインフローを含むアプリケーション全体の監視を数分で自動的に開始し、事前に作成されたダッシュボードを使用してデータを視覚化し分析することができます。

サードパーティ認証ツールの脆弱性監視

自分で認証のための独自ソリューションをゼロから開発しているプロダクトもあるかもしれません。しかし、セキュリティと認証はその分野の専門家である企業に任せるのが最善ですからサードパーティのツールを使用することの方が一般的です。サードパーティツールは便利で、より安全であることが多い反面、大きなデメリットもあります。

サードパーティのツールに対する観測性は独自のそれと同じではなく、信頼されている企業でもセキュリティ侵害に直面することがあります。クローズドソースであれば動作方法は見えませんし、メンテナンス状況などもわからない状態でサードパーティのツールの脆弱性に対しどのように対処すればよいのでしょうか？

そのためには認証ツールを含む外部ライブラリ全体のセキュリティリスクを継続的に評価する必要があります。New RelicのVulnerability Managementを使用すれば、サードパーティのライブラリを継続的に、独自実装されたアプリケーション脆弱性と同時に評価できます。Snyk、Lacework、GitHub Dependabot、AWS Security Hub、Aquasec TrivyなどのセキュリティツールをNew Relicと統合する事で脆弱性の死角を減らす事が可能になります。

まずは、New RelicのVulnerability Management のドキュメント をご覧ください。