【入門編】Sentryで個人情報（PII）の流出を防ぐ！機密データをフィルタリングするスクラブ設定 – 運用監視・オブザーバビリティ活用バイブル

こんにちは！開発現場の最前線で、日々コードと向き合っていると、避けて通れないのが「エラー」との戦いですよね。

「ユーザーから『画面が真っ暗になった』と言われたけれど、手元の環境では再現しない……」
そんな絶望的な状況を救ってくれるのが、エラートラッキングツールの「Sentry（セントリー）」です。

Sentryを導入すれば、世界中のユーザーのブラウザやサーバーで起きたエラーを、発生した瞬間に、しかも「どのコードの何行目で起きたか」まで丸裸にして教えてくれます。これをマスターすれば、毎日のデバッグ作業が劇的に楽になりますよ。

しかし、ここで一つ、絶対に避けて通れない極めて重要な問題があります。
それは、「エラーログに、ユーザーのパスワードやクレジットカード番号、セッション用のアクセストークンがうっかり混入してSentryのサーバーに飛んでしまうリスク」です。

もしこれが起きたらどうなるでしょう？ デバッグどころか、大惨事（個人情報の漏洩・GDPR等の法律違反）を引き起こし、会社やあなたのキャリアを揺るがすセキュリティインシデントになりかねません。

今回は、Sentryの導入の基礎から、絶対に機密データを流出させないための「スクラブ（データ洗浄）設定」の神髄まで、優しく丁寧にお伝えしていきますね。

—

1. エラーログに機密データが混入する恐ろしいリスク

まずは、Sentryが一体どういうものなのか、そしてなぜ機密データが混入してしまうのかをイメージしましょう。

Sentryの役割と「HelloWorld」のセットアップ

Sentryは、アプリケーションで例外（エラー）が発生した際、そのスタックトレース（エラーまでの足取り）や、当時のユーザーの操作環境、入力データをクラウド上のダッシュボードに送信してくれるツールです。

例えば、Node.js（Express）環境であれば、数行のコードで簡単に連携できます。まずは基本のセットアップを見てみましょう。

// 1. Sentry SDKのインポート
const Sentry = require(“@sentry/node”);

// 2. 初期化（プロジェクトのDSNを設定する）
Sentry.init({
dsn: “https://examplePublicKey@o0.ingest.sentry.io/0”,
tracesSampleRate: 1.0, // パフォーマンス計測のサンプリングレート
});

// ここで「HelloWorld」的なエラーを起こしてみます
try {
throw new Error(“こんにちは、Sentry！これがテストエラーです！”);
} catch (e) {
// Sentryにエラーを送信
Sentry.captureException(e);
}

たったこれだけで、Sentryのダッシュボードには美しいエラーレポートが届きます。これがSentryの強力な「HelloWorld」です。

なぜ機密データが混入するのか？

問題は、エラーをキャッチしたときに「その瞬間、ユーザーが入力していたデータ」や「HTTPリクエストのヘッダー」をSentryが親切心で一緒に送ろうとしてしまうことにあります。

例えば、ユーザー登録やログインAPIでバリデーションエラーや予期せぬクラッシュが起きたとします。その際、リクエストボディ（POSTされたデータ）がそのままエラーコンテキストに含まれていると……。

{
“request”: {
“url”: “https://api.example.com/login”,
“data”: {
“username”: “tako_suke”,
“password”: “SuperSecretPassword123!”, // ← あああ！パスワードが生で入っている！
“credit_card”: “4111-2222-3333-4444” // ← クレジットカード番号まで！
}
}
}

Sentryは非常に高機能ゆえに、こうしたデバッグに便利な情報まで自動収集しようとします。だからこそ、「開発者が見たいエラー情報」と「外に出してはいけないプライバシー情報」を明確に切り分ける門番が必要なのです。

—

2. `beforeSend`フックを使用したデータの動的マスキング方法

ここで登場するのが、Sentryの最も強力なセキュリティ機能の一つである`beforeSend`フック（コールバック関数）です。

`beforeSend`は、エラーイベントがあなたの手元のコードからSentryのクラウドへ飛び立つ「まさにその瞬間」に割り込み、「このデータを送信する前に、中身を書き換えて（または破棄して）いいよ」と許可を与えてくれるフックポイントです。

これを使って、動的にデータをマスキング（スクラブ）してみましょう。

const Sentry = require(“@sentry/node”);

Sentry.init({
dsn: “https://examplePublicKey@o0.ingest.sentry.io/0”,

// beforeSendフックの定義
beforeSend(event, hint) {
// eventオブジェクトの中に、送信されるすべてのエラーデータが入っています

// 例：リクエストのデータ（POSTボディなど）が存在する場合の処理
if (event.request && event.request.data) {
// パスワードを隠す（マスキングする）
if (event.request.data.password) {
event.request.data.password = “[FILTERED]”;
}
// クレジットカード番号を隠す
if (event.request.data.credit_card) {
event.request.data.credit_card = “[FILTERED]”;
}
}

// もし特定の機密エラーで、絶対に送信したくない場合は null を返すと破棄されます
// if (event.message && event.message.includes(“SuperSecretError”)) {
// return null;
// }

// 加工したイベントオブジェクトを返却すると、これがSentryに送信されます
return event;
},
});

この`beforeSend`を挟むだけで、Sentryのサーバーには `password: “[FILTERED]”` としか届かなくなり、機密情報の流出を根元から断つことができます。

—

3. パスワードやアクセストークンなどの機密キーを自動除外するベストプラクティス

先ほどのように、キー名（`password`など）を一つずつ手動でチェックしていく方法も悪くありませんが、アプリが巨大化するにつれてキーの種類も増え、書き漏らしのリスキーな「穴」が生まれてしまいます。

現場のプロとして、より堅牢でスマートな「再帰的マスキング・ベストプラクティス」を授けましょう。
オブジェクトの階層が深くなっても、特定のブラックリストに一致するキーを自動的にすべて `[FILTERED]` に置き換える汎用関数を用意するのがセオリーです。

const Sentry = require(“@sentry/node”);

// マスキングしたい機密キーのブラックリスト（正規表現や完全一致で定義）
const SENSITIVE_KEYS = [‘password’, ‘secret’, ‘token’, ‘authorization’, ‘credit_card’, ‘ssn’];

/

  • オブジェクトを再帰的に走査し、機密情報をマスキングする関数

/
function scrubSensitiveData(obj) {
if (!obj || typeof obj !== ‘object’) {
return obj;
}

// 配列の場合は要素ごとに処理
if (Array.isArray(obj)) {
return obj.map(item => scrubSensitiveData(item));
}

// オブジェクトの場合はキーを走査
const sanitized = {};
for (const key of Object.keys(obj)) {
// キー名がブラックリストに含まれているか判定（大文字小文字を区別しない）
const isSensitive = SENSITIVE_KEYS.some(sensitiveKey =>
key.toLowerCase().includes(sensitiveKey)
);

if (isSensitive) {
sanitized[key] = “[FILTERED]”;
} else {
// ネストされたオブジェクトや配列を再帰的に処理
sanitized[key] = scrubSensitiveData(obj[key]);
}
}
return sanitized;
}

Sentry.init({
dsn: “https://examplePublicKey@o0.ingest.sentry.io/0”,
beforeSend(event) {
// リクエストデータを丸ごとスクラブ関数に通す！
if (event.request) {
event.request = scrubSensitiveData(event.request);
}
// ユーザー情報（emailやIPアドレスなど）が含まれる場合もここで保護可能
if (event.user) {
event.user = scrubSensitiveData(event.user);
}
return event;
},
});

このアセットをプロジェクトの初期化ファイルに組み込んでおけば、今後新しい機能を追加して、万が一新しい入力項目（例：`api_secret_key`など）が増えたとしても、自動的にSentryの手前でフィルタリングされます。これで夜もぐっすり眠れますね。

—

4. プライバシーポリシーやセキュリティ要件（GDPR等）への準拠

最後に、なぜここまで厳格にデータスクラブを行う必要があるのか、コンプライアンスの観点から少しだけお話させてください。

欧州のGDPR（一般データ保護規則）や、カリフォルニア州消費者プライバシー法（CCPA）をはじめとする昨今のセキュリティ要件では、個人情報（PII: Personally Identifiable Information）の取り扱いに非常に厳しい目が向けられています。

  • ユーザーのメールアドレス
  • IPアドレス
  • 電話番号
  • 位置情報
  • 認証トークンやパスワード

これらはすべて「個人情報」または「機密データ」とみなされます。これらが自社以外のサードパーティ（Sentryのクラウドサーバーなど）に暗号化されずに送信・保存された場合、それだけで法令違反となり、巨額の罰金や企業の社会的信用の失墜につながる恐れがあります。

Sentryのプロジェクト設定側でも防御を固める

コードレベルでの`beforeSend`対策に加え、Sentryのダッシュボード側（プロジェクト設定）でも多重の防御を行うのがプロの作法です。

1. IPアドレスの収集をオフにする
Sentryのプロジェクト設定（`Security & Privacy`項目など）において、「IPアドレスを保存しない（Store IP Addresses）」設定を有効にします。これにより、EU圏などのユーザーのIPアドレスがSentry側に残らなくなります。
2. データの保持期間を適切に管理する
不要に古いエラーログや個人情報が含まれてしまったログが長期間残らないよう、データのローテーション・削除ポリシーを定めておきましょう。

—

まとめ

今回は、Sentryを用いたエラートラッキングの基本と、最も重要で誰もが一度はハマる「個人情報・機密データの流出を防ぐスクラブ設定」について解説しました。

  • Sentryは開発の強い味方だが、機密データ（パスワードやトークン）を誤って送信するリスクがある。
  • `beforeSend`フックを実装し、送信直前のデータをインターセプトする。
  • ブラックリスト方式と再帰的処理を組み合わせることで、どんなに複雑なオブジェクトでも自動でマスキングできる。
  • GDPRなどのセキュリティ要件を見据え、コードとダッシュボードの両面でプライバシーを守る。

オブザーバビリティ（可観測性）を高めることは、システムを健全に保つために不可欠ですが、それは「ユーザーの信頼とプライバシーを守る」という大前提があって初めて成り立つものです。

この設定をマスターすれば、セキュリティ事故の恐怖におびえることなく、思い切りアグレッシブに開発とデバッグを進められるようになりますよ。明日の開発から、ぜひあなたのプロジェクトに取り入れてみてくださいね！

スポンサーリンク
タイトルとURLをコピーしました