機能

Sensitive Data Masking

機密データがユーザーとログに届く前にマスクします — バックエンドから外に出た後ではなく。

TR7 Sensitive Data Maskingはデータ漏洩リスクをアプリケーションコードだけに任せません。レスポンスボディ、ログフィールド、クッキー値にまたがる個別の保護層を提供し、機密情報が制御なしにユーザー、ブラウザ、ログシステムに到達する可能性を低減します。 レスポンスボディのマスキングでは、正規表現または文字列マッチングに基づいてデータをマスク、完全置換、またはHTMLタグで補足できます。オペレーター定義のパターンはカード番号、ID番号、メールアドレス、電話番号、組織固有の機密データ形式をカバーします。 ログ側ではIPマスキング、クッキー側ではAES-256-GCMベースのクッキー暗号化が独立した保護層として機能します。その結果、レスポンスだけでなく、セッションデータとログ保持プロセスもデータ漏洩の観点からより管理された状態になります。 結果として:TR7は機密データを単一のポイントではなく、レスポンスボディ・ログ・クッキー層にまたがって処理し、データ漏洩防止をアプリケーションコードから独立したプラットフォームポリシーへと変えます。

3
マスキング戦略:マスク文字、完全置換、HTMLタグ挿入
3
データ漏洩層:レスポンスボディ、ログIP、クッキー暗号化
5
マスクパラメーター:文字、オフセット、最小出現回数、除外文字、大小文字感度

アプリケーションコードで機密データが見落とされると、漏洩はすでにユーザー画面とログシステムに到達しています。

機密データのマスキングは、ほとんどの組織でアプリケーションチームに任されています。しかしモダンなアーキテクチャでは、数十のマイクロサービス、異なるチーム、異なるリリースサイクル、レガシーアプリケーションが同時に稼働しています。あるサービスで忘れられたカード番号、IDフィールド、メールリスト、セッショントークンが本番レスポンスやログに含まれてしまうことがあります。

このリスクは外部ユーザー画面に限りません。デバッグログ、アクセスログ、SIEMレコード、エラートラッキングシステム、サポートチームがアクセスするレコードもすべて機密データを含む可能性があります。データがログシステムに入ると、保持ポリシー、バックアップ、アクセス制御によって削除が困難になります。

一部のセキュリティソリューションは機密データの検出のみを行うか、ログレベルのマスキングのみを行います。しかしレスポンスボディ内でユーザーに返されたデータが手付かずのままであれば、実際の漏洩は続きます。単純な置換アプローチもすべてのシナリオに十分ではありません — 時には末尾4桁のみを表示すべきであり、時には完全マスキングが必要であり、時には特定の文字を除外する必要があります。

正しいアプローチは機密データ保護をアプリケーションコードに依存しないエッジポリシーにすることです。レスポンスボディ、ログIP情報、クッキーコンテンツはそれぞれ、正規表現、文字列マッチング、マスク文字、オフセット、最小出現回数などの柔軟なマスキングコントロールで個別に処理すべきです。

TR7 Sensitive Data Maskingはこのモデルを提供します。ユーザーとログに届く前にプラットフォームレベルで機密データをマスクし、データ漏洩リスクを低減します。

私たちのアプローチ

TR7はレスポンスボディマスキング、ログIPの匿名化、クッキー暗号化、検出シグナルを組み合わせて機密データ保護を適用します。

データがエッジから出る前にレスポンスボディをマスク

TR7は文字列または正規表現マッチングを使用してレスポンスボディの機密フィールドをマスクまたは置換できます。バックエンドサービスは変更されないまま、ユーザーに返されるコンテンツがエッジで管理されます。

ログレベルのIPマスキングによりレコードの露出を低減

ipMaskルールによりログ内のクライアントIP情報をマスクできます。このアプローチはデータ保持とコンプライアンスプロセスにおける個人データの可視性低減に役立ちます。

クッキー暗号化によりクライアント側のセッションデータを保護

cookieEncryptionルールは選択したクッキー値をAES-256-GCMで暗号化できます。クッキーコンテンツはユーザー側では読み取り不能になり、一方でプラットフォームはリクエストフローで必要な箇所でそれらの値を管理できます。

機密データ検出が攻撃と漏洩シグナルを生成

テスト用カード番号などの既知の機密データパターンをセキュリティシグナルとしてキャプチャできます。これらの検出により、スコアリング・ログ・インシデントレビューワークフローでデータ漏洩の可能性が可視化されます。

機能一覧

Sensitive Data Maskingはレスポンスボディ、ログ、クッキー層にまたがる異なるデータ保護戦略を一括提供します。

modifyResponseルールがレスポンスボディのコンテンツをマスクおよび置換

modifyResponseルールはレスポンスフェーズ中に実行され、レスポンスボディ内のマッチしたデータを処理できます。modifyTypeの値はmask、replace、htmlTagに設定できます。maskモードは文字を隠し、replaceモードは値全体を置換し、htmlTagモードはレスポンスに制御されたHTMLまたはスクリプトを追加します。この柔軟性はデータの隠蔽だけでなく、レスポンス変換が必要なシナリオもカバーします。

正規表現と文字列マッチングによりオペレーター定義の機密データパターンをサポート

TR7はmatcherおよびmatcherTypeフィールドを通じてリテラル文字列または正規表現でマッチングできます。オペレーターは国民ID番号、IBAN、カード番号、電話番号、メールアドレス、組織固有のデータ形式に対して独自パターンを定義できます。事前構築されたPIIカタログはなく、管理はオペレーターが定義するパターンに依存します。このアプローチは異なる国や業界の形式に等しく柔軟に対応します。

マスク文字・オフセット・最小出現回数設定により誤検知を軽減

maskCharによりマスク文字を選択でき、1文字として検証されます。maskOffsetは先頭または末尾から何文字を表示するかを制御し、0に設定するとマッチ全体がマスクされます。maskFromはマスクが適用される前の最小出現回数を設定します。これらの設定によりユーザー体験と誤検知リスクがより管理しやすくなります。

部分マスキングにより末尾4桁表示などのコンプライアンス対応シナリオをサポート

カード番号やアカウント参照などのデータでは、すべてを隠すのではなく末尾数文字のみを表示することが望ましい場合があります。TR7はこの動作をmaskOffsetで設定できます。例えば末尾4桁を表示したまま残りの文字をマスクすることが可能です。これにより、サポートや顧客確認フローでの使い勝手を保ちながらデータ漏洩リスクを低減します。

replaceモードにより機密値を安全なテキストで完全置換

replaceモードでは、マッチしたデータが設定された置換値で完全に置き換えられます。これは機密値をアスタリスクでマスクする代わりに固定ラベル、空値、組織標準のプレースホルダーに置き換えることを好むチームに適しています。replaceアプローチはレスポンス形式を維持する必要がある場合は注意して使用すべきです。オペレーターはパターンごとにマスキングまたは置換戦略を独立して選択できます。

ボディマスキングはストリーミングおよびチャンクレスポンスにも対応

TR7はレスポンスボディ処理中にチャンクまたはストリーミングレスポンスをマスキングパイプラインに含めることができます。これによりシングルチャンクのボディを前提とせずにモダンアプリケーションでのデータ保護が実現します。ボディ処理はバッファ制限と合わせて計画する必要があります。非常に大きなレスポンスでは、パフォーマンス、メモリ、マスキングスコープをサービスのニーズに合わせて調整すべきです。

レスポンスボディサイズ制限により制御されたパフォーマンス管理が可能

レスポンスボディマスキングはデフォルト16KBの制限内で動作するよう計画できます。必要に応じてインターフェースから制限を引き上げることができますが、数百メガバイトでのマスキング判断はパフォーマンスへの影響と対比して評価すべきです。この制限はエッジレベルのデータ保護とトラフィックパフォーマンスのバランスを取るのに役立ちます。オペレーターは重要なサービスでスコープを意図的に設定します。

クッキー暗号化により選択したクッキー値をAES-256-GCMで保護

cookieEncryptionルールはクッキーコンテンツがクライアント側で読み取り可能なまま残ることを防ぐために使用します。選択したクッキー値をAES-256-GCMで暗号化できます。このルールは繰り返しの競合を防ぐためプールごとに1回使用するよう設計されています。そのためセッションやスティッキークッキーのデータはユーザーにとって意味のあるコンテンツとして不可視になります。

IPログマスクによりレコードレベルでクライアントIP情報を匿名化

ipMaskルールはログフィールドのクライアントIP情報をマスクするのに役立ちます。この機能はGDPRや同様のプライバシー規制に関連するデータ保護要件を持つ環境でログ保持リスクを低減します。アプリケーショントラフィックを継続させながらレコード側の個人データの可視性を制限できます。セキュリティとコンプライアンスチームはログの詳細レベルとプライバシー要件を合わせて管理します。

テストカード番号検出により漏洩とテスト分離シグナルを生成

TR7は既知のテスト用クレジットカード番号パターンをセキュリティシグナルとしてキャプチャできます。この検出はマスキングルールとして機能する必要はなく、スコアリング、ログ、インシデントレビューシグナルとして使用できます。これによりテストまたは開発データが本番レスポンスに漏れ込んでいることが早期に可視化されます。運用チームはデータ漏洩または誤った環境使用の観点からこのシグナルを確認できます。

運用上の深み

機密データマスキングはレスポンスフィルター動作、正規表現処理、マスクパラメーター、クッキー暗号化、IPマスキング、ボディ制限と共に運用されます。

01

レスポンスフィルター動作

各modifyResponseルールはレスポンスボディに対して個別のフィルターとして実行できます。マッチしたコンテンツはマスキングまたは置換を経てレスポンスに書き戻されます。この処理はレスポンスフェーズで行われるため、リクエスト側のルールとは個別に評価する必要があります。

02

正規表現と文字列モード

matcherTypeをregexに設定するとパターンベースのマッチングが使用され、stringに設定するとリテラルマッチングが適用されます。正規表現ルールは強力ですが慎重に記述する必要があります。過度に広いまたは処理コストの高いパターンはパフォーマンスと誤検知リスクをもたらす可能性があります。

03

マスク文字の検証

maskCharは1文字として検証されます。デフォルト値はアスタリスクです。1文字要件によりマスキング出力が予測可能で一貫したものになります。

04

オフセットと出現回数制御

maskOffsetが0の場合、マッチ全体をマスクできます。高い値ではあらかじめ設定した文字数を表示させることができます。maskFrom値はマスキングが適用される前の最小出現回数を設定します。これらの設定は誤検知低減と読みやすさのバランスを取る上で特に重要です。

05

個別の保護ライン

cookieEncryption、ipMask、modifyResponseは同じパイプラインのバリアントではなく、異なるルールタイプとして動作します。レスポンスボディ、ログ、クッキー層はそれぞれ異なる動作で保護されます。この分離により各データ漏洩チャネルに適切なコントロールを選択することが可能になります。

06

ボディ制限の計画

レスポンスボディマスキングはバッファ制限内で評価されます。デフォルトの16KB制限は多くのAPIレスポンスには十分です。大きなレスポンスはインターフェースから制限を引き上げることで対応できます。大きな値でのパフォーマンス影響とメモリ使用量は個別に計画する必要があります。

利用シナリオ

銀行APIレスポンスのカード番号マスキング

銀行チームはカード番号に類似した値を正規表現でキャプチャし、末尾4桁のみが表示されるようマスクできます。バックエンドサービスを変更することなくレスポンスボディがエッジで保護されます。

医療ポータルでの身元情報の完全隠蔽

医療ポータルは国民ID番号や患者参照番号に対してオペレーター定義の正規表現パターンを記述できます。マッチしたデータは完全にマスクされ、機密情報がユーザー画面や中間システムに到達する可能性が低減されます。

ログ内のクライアントIP情報の匿名化

コンプライアンスチームはipMaskを使用してログ内のクライアントIP情報をマスクできます。これにより運用レコードストリームを保持しながらログ保持中の個人データの可視性が低下します。

クライアント側でセッションクッキーを読み取り不能に

ECサイトや金融サービスはcookieEncryptionを使用して選択したセッションまたはスティッキークッキー値を暗号化できます。クッキーコンテンツはユーザー側では意味のあるデータとして不可視になり、改ざんリスクが低減されます。

よくある質問

レスポンスボディマスキングでどのデータタイプを使用できますか?
正規表現またはリテラル文字列マッチングで定義された任意のデータ形式をマスクできます。オペレーターはカード番号、国民ID番号、IBAN、メールアドレス、電話番号、組織固有のフィールドに対して独自パターンを記述します。事前構築されたPIIカタログはなく、マスキングスコープはオペレーターが定義するパターンに依存します。
maskモードとreplaceモードの違いは何ですか?
maskモードでは、マッチした文字が選択したmaskCharで隠され、maskOffsetにより先頭または末尾の文字を表示させることができます。replaceモードでは、マッチした値が設定されたテキストで完全に置き換えられます。オペレーターはルールごとにこれら2つの戦略を独立して選択できます。
cookieEncryptionとmodifyResponseは同じパイプラインで実行されますか?
いいえ。cookieEncryption、ipMask、modifyResponseは異なるルールタイプであり、個別のパイプラインで実行されます。レスポンスボディ、ログIP、クッキー層はそれぞれ独立した動作で保護されます。各チャネルに対して適切なルールタイプが個別に選択されます。
大きなレスポンスボディに対するマスキングはどのように計画すべきですか?
デフォルトのボディバッファ制限は16KBで、インターフェースから引き上げることができます。ただし非常に大きなレスポンスでは、マスキングバッファのメモリとレイテンシーへの影響を評価する必要があります。重要なサービスではスコープとサイズ制限を意図的に設定します。
IPマスキングはログにのみ影響しますか?
はい。ipMaskルールはログフィールドのクライアントIP情報をマスクします。アプリケーショントラフィックとルーティング判定は影響を受けず、レコード側の個人データの可視性のみが低下します。
maskFromパラメーターは何をしますか?
maskFromはマスキングが適用される前にマッチが何回出現する必要があるかを定義します。例えばmaskFromを2に設定すると、1回の出現ではマスキングが適用されず、同じ値が少なくとも2回出現した場合のみルールが有効になります。この設定は誤検知リスクを低減するために使用します。

プラットフォームレベルで機密データを保護

レスポンスボディ、ログ、クッキー層にまたがるデータ漏洩防止。お客様自身のサービスでのライブセットアップをご案内します。