データベースのデータを暗号化する必要がありますか？
私にはクライアントがあり、患者のケア、患者の管理、相談、履歴、カレンダーなど、基本的にはすべてについてWebアプリケーションを実行します。
問題は、これが機密データ、患者の病歴などであることです。
クライアントはデータベースレベルでデータを暗号化することを主張していますが、これはWebアプリのパフォーマンスを低下させると思います。 （しかし、私はこれについて心配する必要はありません）
私は健康問題に関するデータ保護に関する法律を読みました（ポルトガル）が、これについてはあまり具体的ではありません（これについて彼らに質問しただけで、彼らの返答を待っています）。
次の link を読みましたが、データベース内のデータを暗号化するかどうかにかかわらず、私の質問は異なります。
データの暗号化で予想される1つの問題は、キーが必要になることです。これはユーザーパスワードである可能性がありますが、ユーザーパスワード（12345など）がわかっていることと、保存する必要があるキーを生成することは誰でも知っています。どこかに、これは、プログラマ、dba、それにアクセスできるものは何でも、これについての考えですか？
ユーザーパスワードにランダムなソルトを追加しても、私はいつでもそれにアクセスできるため、問題を解決できず、データを復号化できません。
私はこれに関する法律を個人的にチェックします。データを暗号化する必要がある場合は、暗号化する必要があります。
ただし、ガイダンスを受け取っていない場合は、患者とそのデータの間のリンクを保護することを目指します。つまりほとんどの場合、データベース全体のテーブルで使用されるPatientIDがあります。 PatientIDは患者を特定せず、患者の病歴のみを特定します。ただし、PatientIDをRua deSãoBernardo Lisbonに住んでいるJoe Bloggsとして特定するには、これを可能であれば別のDB。患者の個人情報にTDEを使用し、Webアプリケーションのキーを使用してTDEを暗号化することを検討してください。
患者を特定する手段のないその医療データの盗難は非常に恥ずかしいことですが、それ以上のものになることはまずありません。文字通り、この匿名化された医療データを使用する オンラインコンテスト があります。
患者の個人情報から医療データを分離します。堅牢なロールのセットを使用して、スタッフを必要なものだけに制限します。患者に直接対応する必要がある医療スタッフ（最前線の看護師および医師）を除いて、誰も両方にアクセスすることはできません。受付係は患者の個人情報のみを必要とし、ラボのスタッフは医療記録と患者IDのみを必要とし、外科看護師は現在の病状と名のみを必要とします。
ロールの各セットを識別したら、Webアプリケーションだけでなく、データベースや追加のセキュリティ層にもそれらを実装することを目指します。
はい、データベースを暗号化する必要があります。
保存されたデータ（「保存データ」）の基本的な暗号化は一般に認められたセキュリティ原則であり、個人情報や健康情報を保護する法律が国にある場合は、おそらく法律で義務付けられています。
SQL Server 2008を使用しているため、MicrosoftのTDEを使用しています。 MySQLのサードパーティソリューションがあるか、おそらく一般的なボリューム暗号化アプローチ（TrueCryptなど）が機能する可能性があります（ただし、データベースでの使用が認定されているものを使用したいと思います）。
適切に行われれば、パフォーマンスへの影響は小さいはずです。
ちなみに、（機密情報の分離に関して）あなたが言及したリンクは、基本的なデータベース暗号化に加えて考慮すべきものです。
編集：上記の暗号化はボリュームを暗号化します。誰かがハードドライブを盗んだとしても、データが暗号化されていることに気づくでしょう。ただし、誰かがデータベースでクエリを実行すると、暗号化されていないデータが表示されます（そのため、OPはこれについて説明したくありませんでしたが、情報の分離について述べました）。
この推奨事項は、実行する必要がある最低限のことを意味していることに注意してください。法的助言が必要な場合は、もちろん他の場所を調べる必要があります。安全なコードを書くことについてより詳細な議論が必要な場合は、本 Writing Secure Code から始めます。
クライアントが求めていること、そして法律が何であれ、しばらくは無視します...
いいえ、おそらくデータを暗号化すべきではありません。そうすると、簡単に検索できなくなります。たとえば、姓をどのように検索しますかlike 'Smith%'すべての名前エントリが暗号化されている場合？できなければ、時間の経過に伴う患者の血圧をどのようにグラフ化しますかselect .... from.... where patient_id = N？
明らかに、サーバーが適切に保護されていること、ネットワーク接続が保護されていること、ユーザーインターフェイスが適切に保護されていることを確認する必要があります（セッションタイムアウトを含め、ユーザーはコンピューターを使用する人にアクセスを残して離れることができません）。データベースのバックアップを暗号化することもできます。サーバーが配置されている部屋を物理的に保護します。ただし、ライブデータは暗号化しません。
説明：これは、OPが要求していたことは、実際にデータベースのデータを暗号化することであると想定しています。データベースが常駐するファイルシステムではありません。
このようなセキュリティ問題を決定する前に、脅威モデルを評価する必要があります。何を防御しているのかがわからなければ、どのような対策を講じても価値はほとんどありません。
さて、このコンテキストで心配することができるいくつかの事柄があります：
- 攻撃者がデータに物理的にアクセスする（データセンターに侵入する、バックアップテープを盗むなど）
- 生のデータベースへの読み取りアクセスを取得する攻撃者
- アプリケーションを侵害する攻撃者（例： SQLインジェクション、バッファオーバーランなど.
最初のシナリオでは、サーバーがヘッドレスであれば、データベースとすべてのバックアップを暗号化されたボリュームに保存することで機能します。サーバーまたはテープを盗むと、ディスクレベルの暗号化を解除する必要があります。
2番目のシナリオでは、データベースデータの暗号化が役立ちますが、必要なキーまたはパスフレーズをどこにも保存していない場合のみです。
3番目のシナリオでは、すべてが攻撃が発生するコンテキストに依存します。たとえば、XSSまたはCSRF攻撃である場合、攻撃者は正当なユーザーができることは何でもでき、データの暗号化はまったく役に立ちません。
したがって、脅威モデルは攻撃者であり、ログイン資格情報を見つけて外部からデータベースサーバーへのログインを管理するか、データベースサーバーへのルートアクセスを取得することにより、生データベースへの読み取りアクセス権を取得します。典型的な方法は、最初にWebサーバーでシェルアクセスを取得することです。その後、攻撃者は構成ファイルからアクセス資格情報を読み取り、データベースに接続できます。
追加の考慮事項は、特にPHPなどのステートレス実行モデルを備えたプラットフォームを使用している場合は、キーとパスフレーズをどこに保持するかです。理想的には、必要に応じて顧客にパスフレーズを入力させ、それをメモリにのみ保存するか、クライアント側で復号化を実行することをお勧めします（ただし、これは多くの場合実行可能ではありません）。ステートレスプラットフォームでは、通常、ステートはセッション、memcache、データベース、またはフラットファイルを使用して運ばれます。しかし、これらすべては、ステートフルなWebアプリケーション自体のメモリに状態を保持するよりもはるかに脆弱です。これを回避することは鶏と卵の問題です。永続化する前に状態を暗号化すると、安全に覚えなければならない別の秘密が作成されてしまうからです。クライアントのパスフレーズを覚えて、それを必要とする各リクエストと共に送信することは、そのとき最も恐ろしい解決策ではないでしょう。 XSSリークがあり、通常の予防策（httpsのみを提供する、すべてのcookieをhttponlyと安全に設定するなど）を行う必要がある場合、クライアントは依然として脆弱ですが、これらはいずれにしても問題です。
CakePHPのような効果的なMVCフレームワークを使用して慎重にWebアプリケーションを開発する場合。 ZendまたはRailsの場合、データモーダルレベルで暗号化を有効または無効にできるはずです。
たとえば、CakePHPには、データを暗号化するModalの動作の例がいくつかあります。プロセスをコントローラーとビューに対して透過的にする。
これを行う場合、インデックスに関する問題やその他の技術的なデータベースの問題を無視します。これを構成可能なオプションとして使用できるようにする必要があります。
さらに、暗号化を後で有効にするか、運用サーバーでのみ有効にします。暗号化されたデータは、開発中にデバッグして操作することが困難であり、特定の列でのみ実行できます。
はい、データベースを暗号化する必要があります。
これは個人情報であり、機密情報であるため、間違いなくそうすべきであると確信しています。
パスワードから、セッション用にのみ保存する暗号化キーを取得できます。この方法では、パスワードはどこにも保存されず、誰も（DBAを含む）がそれを知ることはできません。 DBを直接表示しようとする人は誰でも、意味不明なものを見てしまいます。これを破壊する唯一の方法は、セッションの乗っ取りを経由することですが、ここではセッションも安全であると想定しています。