不正アクセスの中でも、アカウントへの不正ログインはもっとも基本的な攻撃になります。
なぜならログイン画面はどのサービスでも公開されていることが多く、
最近は外部サイトから流出したパスワードリストを使ったCredential Stuffingといった攻撃も行われます。
そのため、アカウントへの不正ログインは、攻撃者にとってはどのサイトでも共通の攻撃ができる比較的安易な攻撃方法となります。

この問題への根本的な対策は難しいですが、KARTEでも実装している多要素認証やアカウントロック機能といった対応が考えられます。
一方で、このような攻撃が実際に行われているかを監視する仕組みは、直接的な対策とは別途必要になります。

なぜなら、対策に抜け道がある可能性や外的要因で攻撃が突発的に発生する可能性があり、それに気付く仕組みと組み合わせることが重要となるためです。

KARTEではログのモニタリングにDatadogを使っているため、Datadogを使い不正ログインなどのモニタリングを実装していくことにしました。

Datadogで不正ログインのモニタリングの実装方針

元々部分的に不正ログインのモニタリングの仕組みを実装していましたが、網羅性をもっと強化する方法を検討していました。
そこで、Datadogが用意している不正ログインなどのモンタリングテンプレートをベースにして、あらためて不正ログインのモニタリングの仕組みを作り直すことにしました。

モニター認証ログによるセキュリティ対策

このテンプレートでは、Datadogの標準属性と呼ばれるスキーマにあわせたCustom Attributeをログと一緒に送る必要があります。

たとえば、ログに紐づくユーザーIDはusr.idというフィールドに入れて送るといった命名規則がある程度決まっています。
この名前は独自に決めても問題ないですが、先ほども述べたようにテンプレートを利用するには、スキーマに合わせた方が楽になります。

そのため、今回はDatadogの標準属性に合わせる形式でログを送り、そのログを使ってアラートやモニタリング用のダッシュボードを作成することにしました。

ログイン成功/失敗のログを実装

ログインの成功時と失敗時に、Datadogの標準属性のCustom Attributeを含めるように実装します。
具体的には、次のようなAttributeを実装することにしました。

詳細は次のドキュメントでも解説されています。

モニター認証ログによるセキュリティ対策

Datadogへのログの送信方法は色々ありますが、KARTEでは社内で利用する共通のロガーライブラリがあるため、共通のロガー経由で送ることにしました。

ログの収集とインテグレーション

たとえば、次のようなイメージでログイン成功と失敗のログをメッセージと一緒にCustom AttributesをDatadogに送っています。

// ログイン成功時のログ
logger.info("_check_and_login: login_successful", {
  usr: {
    id: user.id
  },
  evt: {
    category: "authentication",
    name: "authentication",
    outcome: "success",
  },
  network: {
    client: {
      ip: req.ip // expressのreq.ip
    }
  }
});
// ログイン失敗時のログ
logger.error(new Error("_check_and_login: login_failure"), {
  usr: {
    id: user.id
  },
  evt: {
    category: "authentication",
    name: "authentication",
    outcome: "failure",
    reason: "ログイン失敗の理由" // ここはDatadogの標準属性にはないが必要な情報なので入れています
  },
  network: {
    client: {
      ip: req.ip // expressのreq.ip
    }
  }
});

しかし、社内で利用しているロガーでは、第二引数のCustom Attributesをcustomというプロパティにまとめてから送信するという仕組みになっていました。

Datadogに送信されるJSONログは次のようなイメージです。

{
  timestamp: "2022-07-22T06:54:48.787Z",
  status: "info",
  message: "_check_and_login: login_successful",
  custom: {
    usr: {
      id: "example@example.com",
    },
    evt: {
      category: "authentication",
      name: "authentication",
      outcome: "success",
    },
    network: { client: { ip: "127.0.0.1" } },
  }
}

customプロパティにまとめているのは、DatadogのCustom Attributesには予約語が存在し、名前が衝突してしまうのを避けるためです。
そのため、custom.usr.idとして送信したものをusr.idにマッピングする必要があります。

Datadog PipelineでCustom Attributesのマッピングをする

Datadogにはパイプラインという仕組みがあります。
パイプラインでは、ログを取り込む際にCustom Attributesを別の名前にマッピングしたり、不要なログを取り込まないように無視できます。

パイプラインを使いcustomプロパティを必要なDatadogの標準属性へとマッピングできます。

パイプラインページではStandard Attributesという専用のタブも用意されていて、デフォルトでいくつかのAttributeは登録されています。
今回は、このStandard Attributesにusr.idなどを追加し、custom.usr.idをusr.idマップする設定を追加しました。

Datadogのstandard-attributesの画面

DatadogのStandard Attributesの画面

をにマッピングする設定

custom.usr.idをusr.idにマッピングする設定]

これでパイプライン設定後に送られたログに関しては、custom.usr.idを送ったらusr.idへとマッピングされるようになります。

ログを使った不正ログインのアラートを設定する

ここまでで、ログインの成功や失敗のログとCustom Attributesが送信されるようになりました。
このログを使い不正ログインに関連するアラートを設定していきます。

Datadogにはセキュリティシグナルというセキュリティアラート向けの仕組みが用意されています。
セキュリティシグナルは、複数のログの組み合わせからアラートを設定できたり、ログなどに対してコンテキスト情報を付与(特定のログにSeverity:Highラベルをつけるなど)ができます。

Datadog セキュリティモニタリングが新登場 | Datadog

また、セキュリティシグナルの検出ルールには、AWSやGCPなどのビルトインのルールが用意されています。
不正ログインに関しても、いくつかのテンプレートとなる検出ルールが用意されています。

ブルートフォース攻撃
- パスワードを総当たり攻撃する手法
クレデンシャルスタッフィング攻撃
- 外部のサービスから流出したアカウント名とパスワードのリストを使って、ログインできるかを試行する攻撃手法
- パスワードリスト攻撃とも言われる

これらのテンプレートは先ほども紹介していたDatadogの標準属性が利用されています。
そのため、送るログもDatadogの標準属性の名前に合わせる(マッピングする)ことで、アラートの実装が簡単になります。

これらの用意されたテンプレートなどをベースに、次のようなルールを作成しています。

ブルートフォース攻撃(IPアドレス単位)
クレデンシャルスタッフィング攻撃
Annomalyを使った異常検知のアラート
- Detection methods: Anomaly
- @evt.category:authentication @evt.outcome:failure
- 普段とはログイン失敗の傾向が異なるなら飛ぶアラート
- Detect Security Threats With Anomaly Detection Rules | Datadog

たとえば、"ブルートフォース攻撃(IPアドレス単位)"なら次のようなルール設定になります(実際の値とは細かいところは異なります)。

ブルートフォース攻撃(IPアドレス単位)

ブルートフォース攻撃(IPアドレス単位) のルール設定

このルールでは、ログのCustom Attributesを元にログインの成功と失敗を、ログインしようとしたIPアドレスでグルーピングしています。
グルーピングした結果、"5分以内に、特定のIPアドレスからのログイン失敗が5回かつログイン成功1回" を、攻撃の成功として判定し、Severity:Highのラベルをつけてアラートを飛ばしています。
また、攻撃の予兆の検知として "5分以内に、特定のIPアドレスに関するログイン失敗が5回" を検知し、Severity:Infoのラベルをつけています。(成功はしてない)

もちろん、普通に利用しているユーザーがパスワードを何回も入力ミスしてからログインに成功するというケースもあるので、これらの値は実際のアプリケーションに合わせて調整するのが良いです。

どのアラートも目的、対応方法などの何をするべきかという説明を書き、アラートが発生したときに何をするかが明確になっていることが重要です。

これでアラートが設定できましたが、個別のアラートだけ見ても全体でどのような問題が起きてるかは分かりにくいです。
そのため、不正ログインに関連するダッシュボードを作成し、そこで起きているアラート(Signal)を一覧できるようにしています。

アラートの全体像を掴むダッシュボードを作成する

Datadogには、今回設定した不正ログインなどのアラートをまとめたダッシュボードのテンプレートが用意されています。

Security and Compliance
- IP Investigation

このダッシュボードのテンプレートを元に、実際に不正ログイン周りの運用をするためのダッシュボードを作成しています。

Datadog セキュリティダッシュボードのイメージ

Datadog セキュリティダッシュボードのイメージ(意図的にアラートを発生させている)

ダッシュボードでは、発生してるアラートをSeverity別で表示したり、ログイン全体の様子、調査方法などをまとめています。
発生したアラートからログを調査したり、そのアラートが実際に問題なのかを確認できるようにしています。

また、ダッシュボードに関連するアラートのモニターを一覧するには、モニター自体にタグを設定しておくと便利です。
たとえば、category:authentication というタグをつけておけば、tag:"category:authentication" でモニターの一覧を検索できるようになります。

おわりに

この記事では、Datadogを使い不正ログインのアラートとダッシュボードといったモニタリング方法について紹介しました。
Datadogの標準属性に従ったログを出すことで、テンプレートを使ったセットアップが簡単にできるようになっています。
一から仕組みを作ると大変ですが、テンプレートをベースにカスタムしていくことで、ある程度形になったものが簡単に作成できます。

モニター認証ログによるセキュリティ対策

また、今回はログインの成功と失敗のログを中心にして紹介しましたが、他にもアカウントへの不正アクセスのシグナルとなるものはあります。
たとえば、パスワードリセットや2要素認証などのログも、不正アクセスに関係する攻撃が発生しているかの判断材料として利用できます。
KARTEではこれらのログに対するモニタリングの追加や運用しながらのアラートの調整などを行なっています。

CX（顧客体験）プラットフォーム「KARTE」を運営するPLAIDでは、セキュリティのモニタリングの設計から運用までを考えて実装していくエンジニアを募集しています。
詳しくは、弊社採用ページをご覧ください。

セキュリティエンジニア | 募集ポジション | 株式会社プレイド

Datadogを使った不正ログインのモニタリング実装