質問: webポータルで個人データを復号化および暗号化するための概念 問題:名前、住所など、プレーンテキストでデータベースに保存されている部分的な個人データを顧客に提供する小さなwebポータルを提供します。ここで、データベース内の個人データを暗号化するための安全な概念が必要です。暗号化は問題ありませんが、データの復号化をどのように処理するのですか? 1.)サーバー側:問題は中間者を回避する方法です(キー交換、常にログイン時??)2。)クライアント側:実装方法であり、キーを長期的に保存する機会があります。クライアント側...応答ありがとうございます。挨拶
回答: データベースに暗号化されたコンテンツとエンドツーエンドの暗号化を保存させることは、実行可能なアプローチではないことがよくあります。問題は、誰が平文の内容にアクセスできるかということです。例えば。 webアプリの場合: サーバーは、暗号化されたコンテンツと、復号化を実行してコンテンツにアクセスするためのjavascriptソフトウェアを提供します。 ユーザーはパスワードを入力し、そこから(対称)暗号化キーが取得されます。 ユーザーは、プレーンテキストデータにアクセスして変更できます。 変更が加えられた場合、データは再度暗号化され、サーバーに送り返されます。 これには2つの大きな問題があります。 パスワードまたは暗号化キーをサーバーに認識させないでください。サービスにパスワードが必要な場合は、暗号化キーの取得に同じパスワードを使用しないでください。したがって、別のログインメカニズムまたは2つのパスワードが必要です。いずれにせよ、これはシステムを複雑にします。 megaファイルホスティングサービスと比較してください。 1password。 クライアントの復号化ソフトウェアは、プレーンテキストのコンテンツにアクセスできます。しかし、誰がこのソフトウェアを提供しますか? webサイトの場合、サーバーにアクセスできる人なら誰でもバックドアを挿入できます。 whatsappでのエンドツーエンド暗号化に対する批判の中には、現在のバージョンがバックドアされていなくても、アプリの更新メカニズムを使用して将来的に暗号化をバックドアする可能性があることも指摘されています。 3番目の問題は、サーバーがプレーンテキストにアクセスできないため、クライアントで処理を行う必要があることです。これは、レコード間の関係をモデル化するデータベースや、クライアントデバイスでは単純に実行できない特別な処理(ビデオトランスコーディングなど)など、多くの種類の処理では実行できません。4番目の問題は、メタデータがまだ平文で保存されている場合、コンテンツの暗号化の価値が限られていることです。例えば。 whatsappはメッセージの内容を暗号化しますが、オンラインプレゼンス(オンライン/最後に表示されたもの)が全世界に漏洩する可能性があります。したがって、ここで暗号化を適用するだけでは、プライバシーを尊重するサービスは得られません。あなたの質問を動機付ける本当の問題はgdprコンプライアンスです。 gdprは、暗号化されたストレージなどの技術的機能を義務付けることではありません。代わりに、gdprでは、データ主体の個人データを保護するための賢明なプロセスが必要です。このプロセスの結果は、通常、適切な組織的および技術的対策になります。暗号化は適切な手段の1つですが(トランスポート暗号化は事実上必須です)、保存時の表面的な暗号化は役に立ちません。組織的な対策には、データにアクセスできるユーザーに関するポリシー、不正アクセスからサーバーを保護するための物理的なセキュリティ対策、データプロセッサとの契約などがあります。コードレビューと脆弱性チェッカーの実行も合理的な手段です。したがって、「omgはすべてのデータを暗号化する必要がある」という結論にジャンプするのではなく、一歩下がってgdprコンプライアンスチェックリストに目を通し、データプライバシー影響評価を準備する方がよい場合があります。大まかに: 個人データを処理する目的は何ですか? この処理のためにどのような種類の個人データを収集する必要がありますか? このデータはどのような法的根拠の下で処理されますか?例えば。同意、正当な利益、いくつかの契約の必要性、その他の法的義務。 正当な利益の場合:データ主体の利益は、データを処理するための私の利益を上回っていますか? このデータを保護するために適切な組織的および技術的対策は何ですか?仮名化のようないくつかの手段はまた、正当な利息分析のバランスを変える可能性があります! この処理に関する透明性のある情報をデータ主体に提供し、彼らの権利を通知していますか?