基本的な財務データの保存
Mintやynabのような予算作成アプリに似たプロジェクトに取り組んでいます。私は Plaid apiを使用します。これは、アカウント/ルーティング番号などを抽象化します。したがって、アクセスして保存しようとするのは、アカウント名、残高、タイプ、およびトランザクションデータ（金額、場所、名前、タイプ、日付、カテゴリ）。
また、ユーザーの名前とメールも保存します。名前とメールを暗号化すれば「十分」だと思っていましたが、それでも少し不安です。だから、ここに私の質問があります：
- どれだけ暗号化する必要がありますか？
- それを暗号化する最良の方法は何ですか？私が本当に元に戻すことができるのはメールだけです。
- 最高の記憶媒体は何ですか？私はpostgresを使用するつもりでしたが、このデータを格納するためのより良い方法があるかもしれません。
ヒント、トリック、リファレンスなど、何でもよろしくお願いします。
まず第一に、これはあなたがいる国とその法律に依存します。財務データを処理するため、すべてのユーザーデータを暗号化することをお勧めします。
データの暗号化に関する混乱を避けるために、以下に説明するように、一般に2つの対処方法があります。私がこれを取り上げた理由は、私の経験では、セキュリティコンサルタントとして「データベースは暗号化されている」と言われているためです。
ただし、さらにいくつか質問することにより、データベース自体のデータは暗号化されず、データベースが実行されているディスクであることがわかります。
1。ディスク暗号化
このタイプの暗号化は、1つ以上の物理マシンが停止している（おそらくオフになって盗まれた）場合にデータが盗まれるのを防ぎます
2。データベースの暗号化
このタイプの暗号化は、データベース自体のデータを保護します。たとえば、攻撃者がデータベースを（部分的に）ダンプできる場合、レコードは暗号化され、基本的に攻撃者にとって役に立たないものになります。
ここでの唯一の課題は、暗号化キーをどこに保存するかです。このキーは、アプリケーションサーバーとデータベースサーバーのどちらかと同じディスク（構成ファイルなど）に配置しないでください。
暗号化キーを読み取るには、「ボールト」メカニズムをお勧めします。 Googleの「暗号鍵保管庫」は、実装可能ないくつかのソリューションにつながるはずです。
どのくらい暗号化する必要がありますか？
私の意見では、財務データ自体は間違いなく暗号化である必要がありますが、これは規制や会社のポリシーにも依存します。私は次のポリシーを使用する会社にいます。
「個人の識別に使用できるすべてのレコードは機密データと見なされます」
例：社会保障番号、銀行口座番号など。
暗号化する最良の方法は何ですか？
私の経験では、ほとんどの場合、対称鍵暗号化が使用されています。
最高の記憶媒体は何ですか？
ほとんどのオープンソースデータベースは列の暗号化をサポートしているため、Postgresもサポートしています。