質問の言い回しに苦労しました。 「 [〜#〜] gdpr [〜#〜] に準拠するにはどうすればよいですか?」しかし、それはおそらく広すぎる質問です。クライアントが望んでいるのはデータベース暗号化です。
フロントエンド(Javascript)、バックエンド(Ruby、Python、PHPなど)、およびデータベース(PostgreSQLなど)の典型的なサイトを考えてみましょう。これは、単一ページのアプリでも、従来のアプローチ(MPA)でもかまいません。ほとんどの場合、データベースとバックエンドは同じサーバー上にあります。
私にはそれは努力する価値がないように思えます。通常、秘密はサーバー上にのみ保持できます。誰かがデータベースにアクセスした場合、その秘密を見つけることができるでしょう。おそらくアクセスがSQLの脆弱性を介して取得されない限り、ほとんどは今日のフレームワークでなくなっています。またはそう信じています。
では、GDPRに準拠するようにデータベースを暗号化することには意味がありますか?どこに秘密を守るべきか?データベースを暗号化することの欠点は何ですか?暗号化する情報は何ですか?より良いアプローチはありますか?
私は法律の詳細にあまり詳しくありませんが、理解しているように、個人情報を保持し、一般データ保護規則(GDPR)に準拠するためにデータベースの暗号化が必要であることを示すものは何もありません。
一方、適切な暗号化手段を使用すると、プライバシーへの影響と違反があった場合の通知要件が多少軽減されます。
(3)次のいずれかの条件が満たされている場合、第1項に記載されているデータ主体への通信は要求されないものとする。
a)管理者が適切な技術的および組織的な保護対策を実施しており、それらの対策が個人データ侵害の影響を受けた個人データ、特に、個人データにアクセスする権限のない人物がそのデータを理解できなくなった場合に適用されました。暗号化として;
暗号化により、データ侵害の影響を大幅に軽減できます。たとえば、2015年にPatreonが侵害され、15 GBのデータを制御できなくなりました。彼らの功績として、Patreonは強力なbcryptハッシュを使用してパスワードを保護し、二次暗号化手段を使用して社会保障番号や税務情報などの機密情報を保護していました。
彼らが情報を暗号化していなければ、侵害の影響(Patreonとユーザーの両方にとって)はかなり悪化していたでしょう。
攻撃者がとにかくキーにアクセスできるという懸念がある場合、そのリスクを軽減するために実行できるいくつかの手順があります。
最終的に、ハードウェアセキュリティモジュール(HSM)を使用しない限り、キーの保護は基本的に攻撃者とのシェルゲームのようなものです。キーを保護しておくための合理的に効果的な方法の1つは、サーバーにキーを保存しないことです。これに対する私のお気に入りのソリューションの1つは、Azure KeyVaultサービスです。
キーをサーバーの永続的なストレージに入れず、メモリからの使用のみを目的として取得することにより、攻撃者がキーを取得することをかなり困難にします。キーにアクセスするには、キーを保存する必要がありますが、間接層を追加すると、攻撃者にとって困難になります。