GDPR：C＃での暗号化されたログ
ログファイルに含まれている可能性のある個人データを保護する手段として、ログファイルを暗号化するという提案が広まっています。
私が見たことがないのは、優れたリファレンス実装です。これは、これを必要とする企業がいくつあるかを考えると驚くべきことです。
私たちの特定のケースでは、公開鍵暗号化を使用して、ファイルを生成する（弱く保護された）システムでファイルを読み取れないようにし、ファイルを確認できる本社に送り返す必要があります。
これまでに見た中で最も良い提案は、「log4netを使用しますが、BouncyCastleのRFC3852ストリーミング実装を使用して独自のアペンダーを作成する」ことです。誰かがそれについて進歩を遂げていますか？
技術的には、ログメッセージの暗号化は非常に簡単です。 Serilogのようなものを使用すると、単純に カスタムシンク を作成できます。
ただし、ログ全体をブラインド暗号化するだけでは、ログの有用性が制限される可能性があります。 [〜＃〜] elk [〜＃〜] のようなものを使用してログを一元化している場合、暗号化したログのフィールド/部分に基づいて検索することはできません（たとえば、マシン名を暗号化すると、ログがどこから来たのかさえわかりません！）。
あなたが本当に扱っている種類の情報がGDPRの対象となる個人を特定できる情報である場合は、それを吸い上げる必要があるかもしれませんが、すべてを包括的に暗号化するのではなく、ログから機密情報のみを暗号化するように努めます...より洗練されたシンクが必要になりますが、ログデータの機能が低下しにくくなります。
私はコメンテーターの何人かに同意します。個人データをログファイルに含めることはできません。 GDPRは暗号化に関するものではありません。個人データを暗号化するだけでは、GDPRに準拠しているとは限りません。個人から「忘れる」（消去する権利）リクエストを受け取った場合、ログファイル内の個人データはどうなりますか？または「データを変更する」（修正する権利）？
ただし、個人データをログに記録する必要がある場合は、情報をハッシュして、ハッシュされたバージョンをログに保存することもできます。その場合、検索文字列からハッシュを計算することで、ログ内の特定のデータを見つけることができます。
質問の公開鍵暗号化の部分に関連して、以下を参照してください： https://aws.Amazon.com/kms または https://Azure.Microsoft.com/en- us/services/key-vault /