概要

秘密鍵やAPIトークンなどの機密情報が含まれやすい場所として、ソースコードを管理するリポジトリがあります。
PLAIDでは、ソースコードへの機密情報のハードコードは原則として禁止していて、Secretlintを使い機密情報のコミットを検出しています。

リポジトリ以外の場所にも機密情報は含まれることがあります。
たとえば、KARTEはさまざまなSaaSと連携しているため、連携するSaaSのAPIを利用するためのAPIトークンなどをデータベースなどに保持しています。
これらのAPIトークンは、お客さんがプロジェクトに対して設定でき、トークンもお客さんの環境のものを利用するケースもあります。

オプション一覧 | CX（顧客体験）プラットフォーム KARTE（カルテ）

データベースに保存されたトークンなどは、ソースコードにハードコードされてるわけではなく、サーバアプリケーションがデータベースを読み書きして利用します。
多くの場合、データベースから読み出したデータは変数などに入れて扱いますが、コード上のある変数に機密情報が入ってるかは変数名などからはわからない場合があります。
そのため、サーバアプリケーションでデバッグのためにこれらの変数の中身をログに出力すると、データベースから読み出した機密情報や個人情報がログへと意図せずに含まれてしまうことがあります。

また、データベースだけではなく、HTTPリクエストにも機密情報が含まれている可能性があります。
そのため、HTTPリクエストをそのままログに出すと機密情報がログに入ってしまうことがあります。
たとえば、次のようにpasswordパラメータというような機密情報が入っていそうな変数をログに出す人は少ないはずです。

const express = require('express')
const app = express()
app.post('/login', (req, res) => {
  const password = req.params.password;
  console.log(password);
});

しかし、次のような req というようなリクエストオブジェクトそのものをログに出した場合も問題があります。
expressのRequestオブジェクトにはHTTPのリクエストヘッダも含まれているため、ヘッダにauthorization: Bearer $tokenのようなトークンも含まれる可能性があります。
また、さまざまなMiddlewareでreqが拡張されるため、他にもログには出してはいけない情報が含まれている可能性があります。

const express = require('express')
const app = express()
app.post('/hello', (req, res) => {
  console.log(req);
});

このように、オブジェクトのような情報の塊をログに出力すると、意図せず機密情報がログへと漏れてしまうことがあります。
一方でログはデバッグに必要となるため、ログを全く出力しないというのは難しいです。
そのため、意図せずログに出てしまった機密情報を検知し、その状態をすぐ修正できることが重要です。

ログに機密情報が漏れることでの影響

ログはデバッグするのに有用ですが、機密情報はデバッグするのには必要ありません。
ログにAPIトークンや秘密鍵といった情報が含まれていた場合に、その機密情報がデバッグに必要なことは極めて稀なことです。
実際に必要だとしても、生のデータとして扱うことはほぼないでしょう。

また、ログを見るのは開発者の一部とはいえ、ログに機密情報が含まれると起きる問題はあります。

たとえば、ログを管理するサービス(Datadogなど)に対して不正アクセスが発生した場合に、ログに機密情報が含まれていると影響範囲が広くなってしまいます。
ログに含まれている機密情報(APIトークンなど)を使い、別のサービスへの不正アクセスの横展開ができてしまう可能性があるためです。

それ以外にも、ログに機密情報があるかわからないと、ログの閲覧権限を権限をもっと細かくしようとしたときに大変になります。
これは、ログに機密があるかわからないため、単純にログをみられる人を絞るという対応しかできなくなり、将来的な開発の体験を悪くします。

そのため、ログに機密情報が意図せず含まれている状態を放置してしまうのは問題があります。

Datadogのセンシティブデータスキャナーを使いログの監視を実装する

KARTEでは、ログの集約にDatadogを利用しています。
KARTEでは、数年前からログに機密情報が含まれていた場合にアラートを飛ばし、その都度ログに機密情報を出さないように修正するという対応をしていました。
当時の仕組みでは、ログに対して単純な文字列マッチングを行い、そのままアラートを飛ばして、人間が確認するという単純な仕組みでした。

今回、Datadogに追加されたSensitive Data Scanner(センシティブデータスキャナー)という機能に、このログに機密情報が含まれていた時のアラートを出す仕組みを移行しました。

センシティブデータスキャナーでは、ログに対して正規表現でマッチングを行い、マッチしたログに対して指定したタグ(key=valueの任意の値)をつけるという仕組みとなっています。
センシティブデータスキャナーで特定のタグをつけ、特定のタグが付いたものに対してアラートを設定するという2段階の仕組みへと変化させました。

今までは、ログに対して特定の文字列を含んでいるかというアラートを設定している1段階(直接的)な仕組みでした。
この仕組みでも問題はある程度見つけられていましたが、柔軟性に欠ける部分があります。

今回、センシティブデータスキャナーで2段階の仕組みを作ることで、アラートの仕組みにも柔軟性が生まれ、またログの権限管理への応用ができるようになりました。

この記事では、センシティブデータスキャナーの基本的な仕組みから、ログに含まれてる機密情報のグルーピングの設計方法、アラートの設定などについて紹介します。
Datadogのセンシティブデータスキャナーとセキュリティシグナルを利用して、次のことを達成するのが目的です。

Datadogに機密情報がログとして残ることを防ぐ
仮にログに機密情報が入った場合に、機密情報を含んでいる可能性があるログを検知できるようにする
- 検知したログは人がトリアージして、次からログに出力しないようにコードを修正する
ログに機密情報があることで、ログを見れる人を絞るといった権限管理の意味を無くしてしまうのを防ぐ
- ログにGCPの強い権限のトークンなどが記載されていると、ログを見れる権限よりも上の権限を取得できるなど
ログの閲覧にロールベースのアクセス制御（RBAC）に加え、属性ベースのアクセス制御（ABAC）を導入できる余地を作る

Datadogのセンシティブデータスキャナーとは

Datadogでは、センシティブデータスキャナーという機能が利用できます。
センシティブデータスキャナーは、ログにセンシティブなデータ(機密情報)が含まれているかをスキャンし、もし含まれている場合は該当するログに対してタグ(key-valueな値)を設定できる機能です。

具体的にはDatadogのセンシティブデータスキャナーは、次のような機能を持っています。

ログに対して正規表現でマッチできる
マッチしたログに対して、タグを付与する
マッチしたログに対して、部分的に置換などのマスク処理をする

たとえば、次のような秘密鍵にマッチするルールを作成しています。

ルールのサンプル

このルールの項目はそれぞれ次のような意味合いです。

Define Regex to match: ログにマッチする正規表現
- 秘密鍵っぽい文字列にマッチする正規表現として次を設定しています。
- -----BEGIN\s?(DSA|RSA|EC|PGP|OPENSSH|[A-Z]{2,16})?\s?PRIVATE KEY(\sBLOCK)?-----[\s\S]+----
- Regex testerで実際にどのようなデータへマッチするかをテストできます
Scan the entire event or a portion of it: ログ全体 OR ログの特定のAttributeにマッチするかを選択
- ログ全体にマッチするパターンとログの特定のAttributeだけにマッチするかを選択できます
Update matching events
- Add tagsでマッチしたときに付与するタグを指定できます
- Define action on matchでマッチしたときのアクションを指定できます
  - マッチした部分の置換、先頭/末尾の一部をマスキング、ハッシュ化を選択できます

これによって、ログに秘密鍵っぽい文字列が含まれる場合には、そのログにはsensitive_data_category:credentialsとsensitive_data:private_keyのタグが付与されます。
また、Partial Redactというアクションによって末尾の32文字が*****という文字列に置換されます。
注意点として、センシティブデータスキャナーのアクションでログをマスキングすると、後からマスキング前のログを見ることはできなくなります。

これはセンシティブデータスキャナーが、ログを取り込む段階で処理するためです。
Datadogではログコンフィギュレーションにログを処理するパイプラインが設定できます。
センシティブデータスキャナーはこのパイプラインの一部分となるため、取り込まれたログはマスキング後のものとなります。

センシティブデータスキャナーのライブラリ

1つずつ機密情報に対するルールを作って行っても良いですが、Datadogではライブラリという形で、著名なケースに対する正規表現とタグがセットになったものが用意されています。

たとえば、GitHubトークンにマッチするライブラリは次のような形で提供されています。

GitHub Tokenのライブラリ

2021年ごろからのGitHubトークンはghpなどのprefixが決まっており、またトークンの長さの決まっているいます。
そのため、\bgh[opsu]_[0-9a-zA-Z]{36}\bのような正規表現は、かなりの確率でGitHubトークンにマッチします。

Behind GitHub's new authentication token formats | The GitHub Blog

Datadogのライブラリでは、GitHubトークンのように確度が高いものもありますが、誤検知が多いものもライブラリとして用意されています。
たとえば、AWSのアクセストークンにマッチするライブラリは次のようになっています。

AWSトークンのライブラリ

このライブラリでは、(aws|AWS|amazon).{0,19}\b[A-Za-z0-9/+]{40}\bという正規表現でAWSのアクセストークンを検知しようとしています。
これは、aws_access_token=<token>のようなものを意図した正規表現となっていると推測できます。

https://github.com/awslabs/git-secrets/blob/b9e96b3212fa06aea65964ff0d5cda84ce935f38/git-secrets#L239
- 📝 AWSが提供するgit-secretsの正規表現を参考にしていると推測できます

この正規表現はAWSのアクセストークンの対してではなく、AWSっぽい設定のトークンっぽい文字列に対してマッチするという形なので誤検知が起きやすいです。

具体的には、https://example.s3.ap-northeast-1.amazonaws.com/action/123454321234565432123456/45421234123452342/123414561/index.jsのようなS3のURLもトークンとして誤判定します。
また、<token>部分が暗号化されていても、トークンとして検知されてしまいます。

このように、Datadogのセンシティブデータスキャナーで提供されるライブラリは色々なサービスの典型的なものが用意されています。
一方で、ライブラリの正規表現の精度はバラバラという特徴があります。

センシティブデータスキャナーのダッシュボード

センシティブデータスキャナーはログに対してログを付与しますが、そのタグに基づいたダッシュボードのテンプレートが用意されています。

公式のドキュメントからの引用ですが、ライブラリを使うなどしてセンシティブデータスキャナーを設定すると次のようにその結果を一覧できるダッシュボードが提供されています。

ダッシュボードのサンプル

このダッシュボードでは、ルールごとのマッチ件数(機密情報が含まれているとされているか)、サービスごとのマッチ率、Geo IPを使ったどの国からのリクエストでマッチしているかなどが一覧されます。

重要なのは、ルールごとのマッチ件数ですが、この情報はsensitive_data_category:<種類>とsensitive_data:<名前>のタグに基づいています。
ライブラリで追加できるルールには、この2つのタグがデフォルトで設定されています。

そのため、独自のルールを追加する場合も、sensitive_data_category:<種類>とsensitive_data:<名前>のタグは設定した方が良いでしょう。

センシティブデータスキャナー != アラート

ここで重要なのが、Datadogのセンシティブデータスキャナーそのものは、機密情報のアラートをする機能ではないという点です。
センシティブデータスキャナーが行うのは、あくまでログにタグをつけてマスキングするところまでです。

そのため、機密情報を含むログ出力がされたことに対するアラートは、センシティブデータスキャナーがつけたタグに基づいてアラートを別途設定する必要があります。
また、先ほども紹介したようにセンシティブデータスキャナーのライブラリは、GitHubトークンのようにそのままアラートしても大丈夫なような精度が高いものから、AWSアクセストークンのように誤検知が起きやすい精度の低いものが混在しています。
AWSアクセストークンのようなものは正規表現でマッチできるような形式が決まっていないため、正確に検知できません。

このような場合にセンシティブデータスキャナーでマッチしたからといってそのままアラートとして通知してしまうと、誤検知だらけとなって疲弊してします。
センシティブデータスキャナーの検証を進めていく中でこのような問題が見えたため、そもそも機密な情報とは何かというその設計を考えていくことから開始しました。

センシティブデータスキャナーで検知する"機密情報"のデータ設計

"機密情報"といっても、そのデータの取り扱いのレベルはさまざまです。
ログへ漏れた場合に、ローテーションしないといけないトークンもありますし、仮にログに漏れても大きな問題はないデータもあります。
また、個人情報やクレジットカード番号のような取り扱いに注意が必要なデータもあります。

このように "機密情報" と言ってもデータの種類によって扱いが異なるため、それぞれをラベリングしていく必要があると考えました。

以前、「継続的なセキュリティ対策をするために脅威分析をしました」でも紹介していた脅威のリスクを評価する場合には、攻撃難易度と影響度の2つの属性を使ったマトリクスでその脅威をラベリングしていました。

同じように、機密情報もそのデータの"機密性"とそのデータが漏れたときの"影響度"の2つの属性でラベリングしようと考えました。
しかし、あくまでルールは正規表現でマッチしているだけであるため、マッチしたデータ自体が誤検知であるという問題が出てきます。
このような場合、"機密性"/"影響度"の2つの属性だけでアラートを設計すると、精度が低いルールでは誤検知のアラートが大量に発生してしまいます。

そこで、3つ目の属性として"精度"という概念を追加し、"機密性"/"影響度"/"精度"の3つの属性で、そのデータをどう扱うかを考えることにしました。

具体的には、次のようにNotionのテーブルでデータ(ルール)ごとに、Precision(精度)/Severity(影響度)/Confidentiality(機密性)を評価していきます。

センシティブデータの設計

先ほども例にあげた、GitHubトークンは正規表現での誤検知が少ないため、精度は "High" としています。
GitHubトークンが流出すると、ソースコードが漏洩し、また開発者に対してマルウェアを仕込むような攻撃へとつながるため、Severity(影響度)はHighです。また、KARTEではトークンはSecret Managerなどを使い暗号化して扱うため、そのままのトークンを見る人は該当のトークンを作成した人などの極一部です。そのため、Confidentiality(機密性)は、社員の中でも特定の人だけが扱うべきデータであるのでHighとなっています。

まとめるとGitHubトークンは次のような評価になりました。

Precision(精度): High
Severity(影響度): High
Confidentiality(機密性): High

次にこの評価を基にして、アラートやマスキングの対応方法を決めます。

センシティブデータスキャナーで検知したデータに対するアラートの設定

対応方法は、次の3つ(3段階)を用意しています。
基本的には、チャンネルごとのSlackチャンネルが用意されており、どのチャンネルに通知されるかで対応方法が変わるという形になっています。

アラート対応:
- sensitive_handling:alertのタグをつける
- #sec-alert(チャンネル名は仮) に通知されるので、必ず対応する
- PrecisionがHighで、Severity/ConfidentialityがMedium以上はアラート対応
トリアージ:
- sensitive_handling:triageのタグをつける
- #sec-notification(チャンネル名は仮) に通知される
- 確認して問題なかったら、Security Signalsのexcludeで除外パターンを設定する
- PrecisionがMediumの場合は、トリアージの対象にできる
- できるだけ、ミスマッチを減らして精度をあげていく
- 精度が上がってきたら "アラート対応" へ移行する
監視対象:
- sensitive_handling:monitoringのタグをつける
- #sec-notification-dev(チャンネル名は仮) に普段と傾向が異なるときに通知がくるので確認する
- anomaly検知を設定して、普段と傾向が異なるときに通知される
- ノイズが多いため、ミスマッチはある程度許容
- 量による監視

アラート対応

精度が高く(High)、影響度や機密性が高いデータは "アラート対応" としています。
これは誤検知がある程度少なく、実際に対応した方がいいデータであるためです。

アラートにはセキュリティシグナルを使い、sensitive_data:* sensitive_handling:alertのタグを含むログが1つ以上ある場合に、通知を飛ばすという設定にしています。
セキュリティシグナルの使い方については、Datadogを使った不正ログインのモニタリングの実装も参照してください。

アラート対応

トリアージ

精度がほどほど(Medium)だが、影響度や機密性が高いデータは "トリアージの対象" としています。
これは、たまに誤検知もあるが、データとしてログに漏れると良くないデータを対象としています。
セキュリティシグナルを使うことで、センシティブデータスキャナーでマッチしたログに対して、追加で除外パターンを指定してからの通知が実現できます。

具体的には、次のようにsensitive_data:* sensitive_handling:triageのタグを含むログから、suppression queryを指定するなどで特定のパターンを除外できます。

トリアージ

監視対象

最後の "監視対象" は、AWSアクセストークンのような誤検知がかなり多いデータです。
基本的に機密な情報は1つでもログに出ていると問題があります。
"機密情報"をログに出力するのを全て止められるのが理想ですが、現実には誤検知の問題などもあります。
全てを通知すると、それはノイズだらけになって本当に対応するべき問題までも隠してしまいます。

そのため、Datadogのanomaly検知を使い、普段とは異なる傾向となったときに通知するという仕組みを導入しています。

具体的には、Detection methodsをanomalyにし、sensitive_data:* sensitive_handling:monitoringのタグを含むログに対してアラートを設定します。

監視対象のアラート

これによって、精度が低いデータに対してもアラートを設定して "監視対象" にするということが実現できます。

センシティブデータスキャナーで検知したデータに対するマスキング

センシティブデータスキャナーでは、正規表現にマッチしたデータに対してマスク処理ができます。

ルールの精度が低いが、そのデータそのものに影響度は高いといった情報もあります。
たとえば、AWSのアクセストークンがこの典型的なケースです。

先ほども紹介したようにAWSのアクセストークンに対する正規表現の精度は低いです。
一方で、AWSのアクセストークンが漏洩すると、影響範囲も広いため、通常はそのアクセストークンを扱える人は限られるはずです。
そのため、AWSのアクセストークンは、次のような評価になりました。

Precision(精度): Low
Severity(影響度): High
Confidentiality(機密性): High

このようなケースでは、アラートをしてしまうと過剰なアラートとなる問題があります。
一方で、万が一ログにAWSのアクセストークンが露出してしまうのも問題があります。

このようなケースでは、アラートは異常を検知した時のみ行い、ログ自体はマスキングするという対応をしています。

このマスキングするかしないかもデータごとに決めています。
具体的には次のような方針を作って、データ処理方法を決めています。

全体マスキング: 完全に置換しても問題ないものは全体置換する
部分マスキング: 基本的には末尾12文字をマスキングする
- Severity または ConfidentialityがHighならマスキング対象とする
なし: 特に何もしない

AWSのアクセストークンは、Severity と ConfidentialityがどちらもHighだったので部分マスキングするという方針になります。

これによって、仮に本当にAWSのアクセストークンがログに漏れても、そのデータはマスキングされているため有効なトークンにはなりません。
一方で、部分的にマスキングされているので、無関係のログがマスキングされる可能性もあります。
しかし、部分的なマスキングであるため、デバッグが不可能になるケースは少ないです。

このバランスは、セキュリティと開発体験の良さのトレードオフの関係にあります。
そのため、状況によってちょうどいいバランスを模索していく必要があります。

検知ができない機密情報を検知する

ここまでで、"機密情報"が何かという定義がはっきりしたもの対しては、センシティブデータスキャナーでルールを作り、セキュリティシグナルでアラートを設定できました。

一方で、これができるのは"機密情報"にマッチする正規表現が書けるという前提があります。
そのため、任意の文字列を扱えるパスワードや想定してないAPIトークンは検知できません。

機密情報がログとして残ることを防ぐのが目的であるため、これらに対して何らかの対処が必要です。
全てを検知するのは難しいですが、機密情報を含む情報の特性を使って検知パターンを増やすなどの方法をいくつか実装したので紹介します。

ログインパスワードの検知

ログインパスワードがログに残されるのは問題です。
大きなサービスでもログに生のパスワードが出てしまうケースはあります。

通常パスワードはハッシュ化してから、データベースに保存しますが、リクエスト時にそのままのパスワードを送っている可能性があります。
アプリケーションの実装ミスなどで、このリクエストに含まれるパスワードがログに出力されていると問題があるため、これをカナリアトークンを使って検知します。

カナリアトークンとは、通常入り得ないような特別な意味をもつようなものをリクエストなどに埋め込んでおく方法です。
生のログインパスワードは、通常はログ出力されることはないので、特別なパターンのログインパスワードを用意しておけば、カナリアトークンとして利用できます。

Botなどから定期的に管理画面にログインのリクエストを送り、このBotがログインするときに利用するパスワードをカナリアトークンにできます。

仕組みは単純で、センシティブデータスキャナーにBotのログインパスワードにマッチする正規表現を書くだけです。
仮に、Botのログインパスワードがログに出ていたら、他のユーザーのログインパスワードもログに出ている可能性があると判断できます。

機密情報を含みやすいオブジェクトを検知する

機密情報が何かという定義は、機密情報の種類が無限にあるため難しいです。
一方で、機密情報が入りやすいオブジェクトというのはある種のパターンがあります。

たとえば、プロジェクトの設定情報を含むようなオブジェクトは、設定情報にはAPIトークンが入る可能性は高いと言えます。
この場合に、APIトークンにマッチする正規表現を書くのは難しい場合がありますが、"プロジェクトの設定情報を含むようなオブジェクト"に対する正規表現は書ける場合があります。

具体的な例として、expressのrequestとresponseオブジェクトがあります。
expressのrequestとresponseオブジェクトは、さまざまなmiddlewareが拡張するため、このオブジェクト自体に機密情報が含まれやすいです。
たとえば、express-sessionはreq.userにセッション情報を含みますし、req.headersにはCookieの情報が含まれています。
そのほかにも、responseはres.localsというプロパティにテンプレート向けの値が含まれます。これは個人情報なども入りやすいです。

そのため、expressのrequestとresponseオブジェクトそのものがログに出力されている場合、そこには機密情報が含まれている可能性が高いと判断できます。
expressのrequestとresponseをログに出力すると関数や内部的なプロパティなども含まれたデータがログとして出てきます。

<ref *1> IncomingMessage {    
    _readableState: ReadableState {      objectMode: false,
      highWaterMark: 16384,
      buffer: BufferList { head: null,
      tail: null,
      length: 0 },
      ...
      [Symbol(kOutHeaders)]: ...    },
    _events: [Object: null prototype] { end: [Function: clearRequestTimeout] },
    _eventsCount: 1,
    _maxListeners: undefined,
    socket: ...
    'cookie', ''
    trailers: {},
    rawTrailers: [],
    aborted: false,
    upgrade: false,
    url: '/test',
    method: 'POST',
    statusCode: null,
    statusMessage: null,
    client: Socket {      
      connecting: false,
      on: [Function: socketListenerWrap],
      addListener: [Function: socketListenerWrap],
      prependListener: [Function: socketListenerWrap],
      _paused: false,
      _httpMessage: [ServerResponse],
      _peername: [Object],
      [Symbol(async_id_symbol)]: 31875,
      [Symbol(kHandle)]: [TCP],
      [Symbol(kSetNoDelay)]: false,
      [Symbol(lastWriteQueueSize)]: 0,
      [Symbol(timeout)]: null,
      [Symbol(kBuffer)]: null,
      [Symbol(kBufferCb)]: null,
      [Symbol(kBufferGen)]: null,
      [Symbol(kCapture)]: false,
      [Symbol(kBytesRead)]: 0,
      [Symbol(kBytesWritten)]: 0,
      [Symbol(RequestTimeout)]: undefined    },

この中で特徴的なデータとして[Symbol(kOutHeaders)などがあるため、これにマッチする正規表現を書けば、expressのrequestとresponseにマッチできます。
expressのrequestとresponseオブジェクトがログに出ているからといって、機密情報が出ているとはいえませんが、これを監視する価値はあります。
そのため、これらの機密情報が含まれやすいものも監視対象としてて、異常検知したときにログを調査するようにしています。

expressのreq/res

このアイデアは、水道の水質チェックの仕組みを参考にしています。
水道の水質チェックの基準には、”大腸菌が検出されないこと”というルールがあります。

大腸菌そのものは無害なものが多いです。
しかし、大腸菌が水に含まれている状態というのは、その水はふん尿で汚染されている可能性が高いことを示しています。
このような汚染された水の場合は、別の病原菌もいる可能性が高く危険となっています。

本当に問題となる病原菌を検出するには工夫が必要ですが、大腸菌の検出方法は確立されています。
この汚染された水の参考に、機密情報そのものを定義するのは難しいが、機密情報を含むやすい場所を検知するという方法を導入しています。

まとめ

この記事では、センシティブデータスキャナーの基本的な仕組みから、ログに含まれてる機密情報のグルーピングの設計方法、アラートの設定などについて紹介しました。
Datadogのセンシティブデータスキャナーとセキュリティシグナルを利用して、次のようなものを実装しました。

センシティブデータスキャナーを使ったログに含まれる機密情報の検知
機密情報を"機密性"/"影響度"/"精度"の3つの属性でカテゴライズ
カテゴライズしたデータごとにアラートなどの対応方針を決める
"機密性"/"影響度"が高いものに関しては、マスキング処理を行う
定義できない(正規表現が書けない)機密情報も、機密情報を含みやすい場所を検知することで監視する

その他にも、今回紹介できなかったセンシティブデータスキャナーのユースケースとして、次のようなものもあります。

ログに機密データが出てしまった場合の止血処理
- マスキング処理の追加は簡単で反映が早いため、アプリケーションを修正するまでの間のログから機密情報を取り除けます
ログの権限管理への応用
マスキング処理のサーバサイド移行

センシティブデータスキャナーはログへのタグを付与だけを行い、アラートは別の仕組みで行います。
途中に除外ルールなどを追加するといった柔軟性のある設計ができるため、誤検知が多いログの監視には有用です。

CX（顧客体験）プラットフォーム「KARTE」を運営するPLAIDでは、ログに含まれる機密情報の検知の設計から運用までを考えて実装していくエンジニアを募集しています。
詳しくは、弊社採用ページをご覧ください。

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

機密情報が間違ってログ出力されたことを検知する仕組みを、Datadogのセンシティブデータスキャナーで作る