アプリケーションバックエンドは、デバッグモードのときに機密の顧客データを潜在的にログに記録することが期待されていますか？
私が顧客に名前、住所、電話番号などのデータを入力するように求めるWebサイトで作業しているとき、明らかに保護する必要のある顧客データ。
私はそのようなデータをログに記録しないように最善を尽くしています（通常と安全の2つのレベルのログがあり、そのためにセキュリティで保護されたログ領域を使用します）。またはトレースモード。これらのログはすべてサーバー側で発生します。クライアントはそれを制御できません。
現在の実装では、通常のリリースモードではINFO、WARNING、またはERRORのログレベルではそうしませんが、DEBUG/TRACEレベルではその情報の一部がログにリークされる可能性があります。これはほとんどのWebサイトサーバーで予想される動作ですか？それとも、DEBUG、TRACEモードの場合でも、このようなリークを制限する必要がありますか？ （C++アプリケーションはリリースモードでコンパイルされていることに注意してください。この場合の「デバッグ」は、ソフトウェアにデバッグコードがまだ残っているかどうかではなく、ログレベルを参照します。）
アプリケーションが別のコンピューターまたはサードパーティシステムのデータをログに記録している可能性があることに注意してください。ログへのセキュリティワイズアクセスは、データが確実に存在するWebサイトサーバーアプリケーションまたはデータベースへのアクセスとは無関係です。ただし、一部の人々は、データベースを備えたコンピューターよりもログコンピューターのセキュリティ要件が低いと想像できます...
これは素晴らしい質問です！私はまた、高感度データを処理するc ++製品の開発者でもあり、このジレンマにほぼ毎日直面しています。
本番システムがアラームをスローし始めたとき（特に、パフォーマンスや構成に関連するもの、ソフトウェアの動作に問題があると考えられる場合）は、問題を診断するために一時的にスタックトレースレベルのデバッグを有効にする必要があります。これらのログには、必然的に機密情報が含まれます。トランザクションに関与するIPアドレスまたはユーザー、場合によってはデータの一部などに名前を付けます。多くの場合、お客様は明白な理由でこれらのログを提供することに抵抗を感じています。硬いです。
実際にサーバーを実行している管理者は、データの機密性のレベルと、それを処理するときに守らなければならない政府または業界のセキュリティポリシーを知っています（たとえば、政府、財務、健康のデータにはすべて特別なルールがあります）。ソフトウェアが機密ログを生成する能力を持っているのは当然ですが、管理者は、ログを生成、保存する方法、時期、場所を完全に制御する必要があります。
あなたができるいくつかのこと：
- 機密情報（場合によっては）を含むすべてのエラーメッセージを正しいログレベル（INFO、WARNING、ERROR、DEBUG、TRACEなど）に正しく分類するように十分注意してください。
- 機密情報の種類が各ログレベルに含まれていることについて、ドキュメントで明確にしてください。詳細を記述すればするほど、セキュリティ志向の管理者は自分の仕事を適切に実行できるようになります。
- ソフトウェアのデフォルト設定でDEBUG/TRACEログレベルがオフになっていること、および管理者がオンにするために一連の警告を実行する必要があることを確認します（つまり、誤って行うことはできません）。
- DEBUG/TRACEレベルのログを別のログストリーム（別の「安全な」ログについて言及している）に送信し、デフォルトでローカルストレージに保存することにより、安全なゾーンの外に「誤って」出荷したり、標準ログ。
- DEBUG/TRACEログからすべての生データ、ユーザー名、IPアドレスなどを一意のプレースホルダーでマスクする方法を知っている編集ツールを使用して製品を出荷します（各一意のユーザー名/ IPは一意のA、B、..、AAによってマスクされます） 、など）。多くの場合、実際のユーザー名/ IP /データは関係ありませんが、問題を診断するための鍵は、エラーがタイプXのデータでのみ発生すること、またはIPアドレスA（およびAのみ）が常に要求を常に3回送信することなどです。 。このようにして、管理者は、これらのログをセキュアゾーンから移動する必要がある場合に、機密情報が漏洩することはないと確信できます（たとえば、デバッグのためにログを送り返します）。
結論：ソフトウェアにデバッグ目的で機密情報を記録する機能があることは公平だと思います-誤動作している製品システムをデバッグする必要があるときに後で感謝します！ しかし「偶然」をオンにすることを可能な限り困難にします。管理者を信頼してセキュリティ要件を把握し、仕事を簡単にします。
私は90年代後半からペネトレーションテスターとして働いており、多くのアプリケーションを見てきました。アプリケーションがユーザー識別データをログに記録することはまれではありません。ほとんどの開発者は、ログへのアクセス権を持つユーザーを信頼できると宣言しているため、ロギングを制限しません。
これが問題になるかどうかは、ビジネスケースと目的のセキュリティレベルによって異なります。私の専門家の意見では、パスワードのログは許可されていません。必要に応じて、最初の文字と長さを記録できます。しかし、それ以上はありません。さもなければ、動いている間および休憩中にパスワードを暗号化したいという欲求を危うくします。
高セキュリティ環境では、これはユーザー名、名前、住所、銀行口座番号などの他のデータにも適用される場合があります。