データベース内のデータを暗号化する必要がありますか？

私にはクライアントがあり、そのために、患者のケア、患者の管理、相談、履歴、カレンダーなど、基本的にはすべてに関するWebアプリケーションを作成します。

問題は、これが機密データ、患者の履歴などであるということです。

クライアントはデータベースレベルでデータを暗号化することを主張しますが、これはWebアプリのパフォーマンスを低下させると思います。（しかし、私はこれについて心配するべきではありません）

私は健康問題に関するデータ保護に関する法律を読んだことがありますが（ポルトガル）、これについてあまり具体的ではありません（これについて質問したばかりで、彼らの応答を待っています）。

次のリンクを読みましたが、私の質問は異なります。データベース内のデータを暗号化すべきかどうか。

データの暗号化で予測される問題の1つは、キーが必要になることです。これはユーザーパスワードかもしれませんが、ユーザーパスワードがどのようになっているか（12345など）を知っており、保存する必要のあるキーを生成しますどこかで、これは、プログラマー、dba、それにアクセスできるものは何でも、これについての考えを意味しますか？

ランダムソルトをユーザーパスワードに追加しても、私はいつでもアクセスでき、データを復号化できるため、問題は解決しません。

私は個人的にこれに関する法律を確認します。データを暗号化する必要がある場合は、暗号化する必要があります。

ただし、ガイダンスが得られない場合は、患者とそのデータの間のリンクを保護することを目指します。PatientIDつまり、データベース全体のテーブルで使用されている可能性が高いでしょう。 PatientID患者を特定するのではなく、患者の病歴のみを特定します。しかし、PatientIDRua deSãoBernardo Lisbonに住むJoe Bloggs を特定するために、可能であれば別のDBに保管します。患者の個人情報にTDEを使​​用し、Webアプリケーションのキーを使用してTDEを暗号化することを検討してください。

患者を特定する手段のない医療データの盗難は非常に恥ずかしいことですが、それを超えるものはほとんどありません。この匿名化された医療データを使用する文字通りのオンラインコンテストがあります。

患者の個人情報から医療データを分離します。堅牢な役割セットを使用して、スタッフを必要なものだけに制限します。患者に直接対処する必要がある医療スタッフ（最前線の看護師と医師）を除き、誰も両方にアクセスすることはできません。受付係は患者の個人情報のみを必要とし、実験室スタッフは医療記録と患者IDのみを必要とし、手術看護師は現在の病状と名のみを必要とします。

ロールの各セットを特定したら、Webアプリケーションだけでなく、データベースと追加のセキュリティレイヤーにもロールを実装することを目指します。

はい、データベースを暗号化する必要があります。

保管データ（「保管中のデータ」）の基本的な暗号化は、一般に認められたセキュリティ原則であり、個人情報や健康情報を保護する法律がある場合はおそらく法律で義務付けられています。

SQL Server 2008を使用しているため、MicrosoftのTDEを使​​用しています。MySQLにはサードパーティのソリューションがあるかもしれませんし、おそらくは一般的なボリューム暗号化アプローチ（TrueCryptなど）が機能するかもしれません（データベースでの使用が認定されているものが欲しいのですが）。

適切に行われれば、パフォーマンスへの影響は小さくなります。

ところで、あなたが言及したリンク（機密情報の分離に関して）は、基本的なデータベース暗号化に加えて考慮する必要があるものです。

編集：上記の暗号化はボリュームを暗号化します。誰かがハードドライブを盗むと、暗号化されたデータが見つかります。ただし、誰かがデータベースでクエリを実行すると、暗号化されていないデータが表示されます（だから、OPがこれについて話し合いたくなかったとしても、情報の分離について言及しました）。

この推奨事項は、最低限行うべきことを意味していることに注意してください。法的なアドバイスが必要な場合は、もちろん他の場所を調べる必要があります。セキュリティで保護されたコードの記述に関するより詳細な議論が必要な場合は、「安全なコードの記述」から始めます。

このようなセキュリティの問題を決定する前に、脅威モデルを評価する必要があります。何に対して防御しているのかわからない場合、あなたがとる対策はほとんど価値がないでしょう。

ここで、このコンテキストで心配できることがいくつかあります。

• データに物理的にアクセスする攻撃者（データセンターへの侵入、バックアップテープの盗用など）
• 未加工のデータベースへの読み取りアクセス権を取得する攻撃者
• SQLインジェクション、バッファオーバーランなどにより、アプリケーションを侵害する攻撃者

最初のシナリオでは、サーバーがヘッドレスであれば、データベースとすべてのバックアップを暗号化されたボリュームに保存する必要があります。サーバーまたはテープを盗む場合、ディスクレベルの暗号化を解除する必要があります。

2番目のシナリオでは、データベースデータの暗号化が役立ちますが、必要なキーまたはパスフレーズをどこにも保存しない場合に限ります。

3番目のシナリオでは、すべてが攻撃が発生するコンテキストに依存します。たとえば、XSSまたはCSRF攻撃の場合、攻撃者は正当なユーザーができることを何でも行うことができ、データの暗号化はまったく役に立ちません。

したがって、脅威モデルは、ログイン資格情報を見つけて外部からデータベースサーバーへのログインを管理するか、データベースサーバーへのルートアクセスを取得することにより、未加工のデータベースへの読み取りアクセスを取得する攻撃者です。典型的な方法は、最初にWebサーバーでシェルアクセスを取得することです。攻撃者はそこから、構成ファイルからアクセス資格情報を読み取り、データベースに接続できます。

さらに考慮すべき点は、特にPHPなどのステートレス実行モデルを備えたプラットフォームを使用している場合、キーとパスフレーズを保持する場所です。理想的には、必要に応じて顧客にパスフレーズを入力してもらい、それをメモリのみに保持するか、さらに良いことに、クライアント側で復号化を行います（しかし、これは実行できないことがよくあります）。ステートレスプラットフォームでは、通常、状態はセッション、memcache、データベース、またはフラットファイルを使用して伝達されます。しかし、これらはすべて、ステートフルWebアプリケーションのメモリに状態を保持するよりもはるかに脆弱です。これを回避することは、鶏と卵の問題です。なぜなら、状態を永続化する前に暗号化すると、安全に覚えておく必要がある別の秘密を作成したからです。クライアントのパスフレーズを覚えて、それを必要とする各リクエストと一緒に送信することは、最も恐ろしい解決策かもしれません。

クライアントが何を求めているか、法律が何であれ、しばらく無視します...

いいえ、おそらくデータを暗号化するべきではありません。使用すると、簡単に検索できなくなります。たとえば、like 'Smith%'すべての名前エントリが暗号化されている場合、どのように姓を検索しますか？あなたができない場合、時間の経過とともに患者の血圧をどのようにグラフ化します select .... from.... where patient_id = Nか？

明らかに、サーバーが適切に保護されていること、ネットワーク接続が保護されていること、ユーザーインターフェイスが適切に保護されていることを確認する必要があります（ユーザーがコンピューターを使用するすべてのユーザーにアクセスできないようにセッションタイムアウトを含む）。データベースのバックアップを暗号化することもできます。サーバーが置かれている部屋を物理的に保護します。しかし、ライブデータは暗号化しません。

明確化：これは、OPが求めていたのは実際にデータベース内のデータを暗号化することであると仮定しています。データベースが存在するファイルシステムではありません。

CakePHPのような効果的なMVCフレームワークを使用して、Webアプリケーションを慎重に開発する場合。ZendまたはRailsを使用すると、データモーダルレベルで暗号化を有効または無効にできるはずです。

たとえば、CakePHPには、データを暗号化するModalの動作の例がいくつかあります。プロセスをコントローラーとビューに対して透過的にする。

これを行う際に、インデックス作成に関する問題やその他の技術的なデータベースの問題を無視します。これを構成可能なオプションとして使用できるようにする必要があります。

さらに、後で暗号化をオンにするか、実稼働サーバーでのみオンにします。暗号化されたデータは、開発中にデバッグおよび操作することが難しく、特定の列でのみ実行できます。

はい、データベースを暗号化する必要があります。

これは個人情報および機密情報であるため、間違いなくそうすべきだと確信しています。

パスワードから、セッションでのみ保存する暗号化キーを導出できます。そうすれば、パスワードはどこにも保存されず、誰もパスワードを知ることができないため、誰も（DBAを含む）知ることができません。DBを直接表示しようとする人はだらだらと見ているでしょう。これを破壊する唯一の方法は、セッションハイジャックを経由することですが、ここでもセッションが安全であると仮定しています。

クライアントがDBの暗号化を要求するのはなぜですか？彼があなたにデータを保護するように頼むならば、私は同意するでしょう、しかし彼はすでに暗黙の実装を念頭に置いています。ですから、彼が何について話しているのかを正確に知らない限り、彼は私の観点から流行語を投げているだけです。

また、文字通りすべての主要なDBMSがセキュリティを適切に考慮し、おそらくあなたよりも優れていると確信しているため、DBを暗号化することは非常に役に立たないと思います。DBMSを介してDBにアクセスするには、資格情報が必要です。暗号化されたDBの場合、これらの資格情報も必要になり、データを復号化するには、すでに持っていると思われる資格情報が必要になります。

この考え方に従って、DBMSでセキュリティを処理し、ユーザー入力からdbアクセスまでクレデンシャルを保護するよう努力することを提案します。強力なパスワードと定期的な変更を強制することもできます。