ユーザー認証ログのセキュリティモニタリング、何のために何をやる？：クラウドセキュリティモニタリングのベストプラクティス（5）

クラウド／クラウドネイティブのログをセキュリティの観点でモニタリングするベストプラクティスを紹介する本連載。第5回は、さまざまな認証サービスのセキュリティモニタリングについて解説する。

» 2023年10月26日 05時00分公開

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

＊本連載では、Datadogのホワイトペーパーよりベンダー中立的な部分を抜粋し、＠ITの表記ルールに合わせるために改変を加えています。（編集部）

　ユーザー向けのWebアプリケーションを実行している場合、ユーザーが安全にログインできるように、何らかの形態の認証フローを実装していることが多いだろう。また、目的やユーザーグループ別に、幾つかのシステムや認証方法を使い分ける場合もある。

　例えば、従業員は会社が提供するGoogleアカウントで管理されるOAuthベースの認証で社内のサービスにログインし、顧客はユーザー名とパスワードや自分のGoogle認証情報を使用してシステムにログインすることがある。全ての認証イベントを記録、監視、分析する能力は、セキュリティの脅威を特定し、コンプライアンスのために顧客の記録を管理する上で重要な鍵となる。

　これらのさまざまなソースや環境で発生する認証ログは、出力するフォーマットもバラバラで、異なるチームによって管理されている場合がある。また、Google、Okta、Auth0などの異なるサードパーティーのサービスが認証に使用されている場合もあり、このような環境で全ての認証アクティビティを効果的に分析することは難しいかもしれない。

　アプリケーションが十分な情報を含む認証ログを、標準的で簡単に解析できる出力フォーマットに定義しておくと、全ての認証ログに対して複雑な分析を簡単に行うことができる。例えば、ログインに最も多く失敗しているユーザーやIPアドレスはすぐに特定できる。あるいは、ログインソース（ユーザー名、Okta、Google Workspaceなど）や認証フロー（パスワード、OAuth、SAML）の傾向を追跡することも可能だ。ログを標準化することの第2のメリットは、コンプライアンス対策のために特定のユーザーの認証イベントを迅速に監査または削除することが容易になる点にある。

　本稿では、以下のトピックについて説明する。

認証ログを管理および出力するフォーマットを定義したときのベストプラクティス
認証イベントによって特定できるセキュリティの重大な脅威

認証ログを管理および出力するフォーマットを定義したときのベストプラクティス

　認証イベントから有用な情報を最大限に引き出すためには、以下を行う必要がある。

全ての認証フローにおいて全ての情報を必ず記録する
必要となる可能性がある全ての情報を含むログを出力する
ログが標準化されており、簡単に解析できる出力フォーマットであることを確認する

あらゆる情報を記録する

　従業員が、会社から提供されたGoogleの認証情報を使用してログインする場合など、社内で管理している認証フローのイベントは記録されているはずである。しかし、例えば企業がアプリケーションでアカウントを作成し、自社で管理していないGoogle認証情報でログインすることを許可している場合には、これらのログは収集されていない可能性が高い。全ての認証アクティビティを可視化するには、アプリケーションレベルで全てのログインフローのイベントを記録する必要がある。これにより、全てのログを記録でき、あらゆる認証をモニタリングできるようになる。また、この方法では、記録する認証イベントや収集するデータをより詳細に制御することが可能である。

必要となる可能性のある十分な情報をログに含める

　認証イベントについて必要となる可能性がある全てのデータがログに含まれていなければ、ログは役に立たないことがある。

　上記のログからは、認証イベントにおける「ユーザー」（John Doe）と「実行した操作」（logged in）、「ログインした日時」（2020-01-01 12:00:01）が分かるが、「どのように」（例えば、Johnはユーザー名とパスワードを使ったのか、それともGoogleアカウントでログインしたのか）、「どこで」（例えば、JohnはどのIPアドレスからログインしたのか）などの情報は得ることができない。また、ログインの失敗を示す別のログイベントも必要だ。このデータがなければ、例えば、どんな場所からログインしたのか、また、ログイン方法の傾向を監視したり、認証に対する潜在的な攻撃を特定したりすることができない。次に、これらの情報が含まれるログを見てみよう。

　このログからはイベントの詳細が確認でき、複雑な分析をより簡単に行うことができる。アプリケーションレベルで全ての認証イベントログを記録することで、このレベルの情報を確実にログに追加することが可能だ。

解析しやすい標準的な形式をログで使用する

　全ての認証イベントの詳細なログを収集していても、全ての情報が分かりやすい文字列として記載されていなければ、解析したり必要なログを検索したりすることは困難だ。この場合には、= をセパレータとして使用して、キーと値が対になった形式でアプリケーションからログを出力させることができる。この形式を使用すると、解析ツールが簡単にログを処理できるようになる。上記のログを例に見てみよう。

　これをキーと値が対になった形式で記録すると、次のようになる。

　これで、解析ツールは以下のJSONとして解析できる。

　全ての認証ログで同じ出力フォーマットを使用することにより、これらの属性を使用してログデータを簡単にスライスして必要な情報を正確に表示できる。例えば、どのユーザー（usr.id）が、ログインに最も多く失敗しているか（evt.outcome:failure）を簡単に確認することができる。また、キーと値が対になった形式であれば、ログに簡単に独自の属性を追加することも可能だ。例えば、各ログにreCAPTCHA v3スコアを追加して、スパムbotが活動していないかどうか特定できる。もう1つの重要なことは、スペースが含まれる可能性のある属性値は引用符で囲むことだ。これにより、全ての値を簡単に解析して、完全に把握することができる。

　ログの属性に標準的な命名規則を使用することで、ログの収集元にかかわらず全てのログを検索してデータを集約できる。認証ログには以下の標準的な属性を含んでいることが望ましい。

usr.id
evt.category
evt.name
evt.outcome
network.client.ip

usr.id

　この属性から、認証を要求しているユーザーが特定できる。usr.idの値は、データベースでユーザーを識別するために使用する場合がある一意の識別子ではなく、ユーザー名やメールアドレスを指定するようになっていることを確認する必要がある。また、データベースにユーザー名がない場合でも、一意のユーザー名を含めるようにする必要がある。これにより、ログインに失敗しているユーザーIDを追跡でき、攻撃を検出できる。

evt.category

　これをauthenticationに設定すると、他の多くのイベントログから認証イベントだけを簡単に検索できる。

evt.name

　evt.nameには、SAML（evt.name="saml"）またはOAuth（evt.name="google oauth"）を使用したGoogleのログインであったかどうかなど、認証のソースと認証方法に関するより詳細な情報を把握できる。

evt.outcome

　この属性には、successまたはfailureのいずれかの値を設定する必要がある。この属性を使用すると、使用している全てのアプリケーションについて、ログイン失敗のパターンを簡単に検索できる。

network.client.ip

　これは認証を要求しているユーザーやクライアントのIPアドレスである。この情報を記録することで、リクエストの発生元を把握できる。

認証ログを使用して一般的なセキュリティ脅威を検出する

　認証ログから重要なデータを収集して解析することで、潜在的なセキュリティ脅威を検出できる。例えば、短時間にあるユーザーが何度もログインに失敗している場合、ブルートフォース攻撃を受けている可能性がある。何度かログインに失敗した後にログインに成功している場合は、アカウントが乗っ取られた恐れがあるため、速やかに調査する必要がある。

　ログから簡単に特定できる他の一般的な認証攻撃手法には、クレデンシャルスタッフィング攻撃がある。クレデンシャルスタッフィング攻撃とは、盗み出されたログイン認証情報を利用して組織の実際のユーザーアカウントにアクセスする攻撃だ。幾つもの usr.idの値が全て同じnetwork.client.ipから発信されているログインを確認することで、このタイプの攻撃が検出できる。