CC や SSN などの機密データを保存する必要がある場合、次のことを行いますか?
1) アプリケーション内で独自の暗号化ルーチンを構築し、設定ファイルのどこかに秘密鍵を定義してから、データベースに送られるデータを手動で暗号化/復号化します。
2) 組み込みの DB 機能を使用して、すべての問題をデータベースにプッシュします (ほとんどのベンダーはそれを透過的なデータベース暗号化と呼んでいると思います)。
ソリューションのトレードオフは何ですか? 独自のルーチンを作成すると、TDE と比較してパフォーマンスが低下しますか? コードの保守性、または逆に言えば DB ベンダー ロックインの問題ですか?
私はさまざまな暗号化手法を使用してきましたが、実績のある暗号化ルーチン (つまり .NET ライブラリ) を使用してアプリケーション側で暗号化する方が簡単で安全だと思います。
データベースで暗号化すると、データは暗号化されていない形式でデータベースとの間で送受信されます。これにより、アプリケーションとデータベース上の暗号化ルーチンとの間でスヌーピング/改ざんが可能になる可能性があります。アプリケーション側でキーを保存しても、データベース側で暗号化を実行する必要があります。データベースが侵害された場合、データは深刻な危険にさらされます (アプリケーションの実行中に誰かがプロファイラーを実行していると想像してください)。
アプリケーションで暗号化/復号化すると、機密データ (キーを含む) がアプリケーション サーバーの外部に公開されることはありません。すべてのデータにアクセスするには、誰かが Web サーバーとデータベース サーバーの両方を侵害する必要があります。
また、独自の暗号化ルーチンを展開しないことを強くお勧めします。ソリューションの全体的なセキュリティを低下させる間違いを犯す可能性があります。
編集：
また、あなたの決定に影響を与える別の要因を追加したかった. その暗号化されたデータに対してクエリを実行する必要がありますか? アプリケーション レベルで暗号化する場合は、データをアプリケーションに持ち込み、復号化し、そこから作業する必要があります。これは、データ セットが大きくなるにつれて非常に困難になります。一方、データベース暗号化を使用すると、アプリケーションに送り返す前にデータをフィルタリングできます。
機密データを暗号化すると、基本的に、キーにアクセスできる人だけにアクセスを制限することになります。問題は、キー管理の 1 つになります。承認された人/システムのみが、データの復号化に必要なキーにアクセスできるようにします。
もちろん、最近では簡単な標準の暗号化アルゴリズムを使用する必要がありますが、考慮すべきことは、保護する脅威、キーへのアクセスをどのように制御するか、および物理的な暗号化をどのように制御するかです。サーバーへのアクセス。
TDE を使用すると、データベースのコンテンツとそのバックアップが暗号化され、データベースの承認されたユーザーへの影響が最小限に抑えられます。そのため、有効な資格情報でデータベース サーバーにアクセスできる人は誰でも、暗号化されていないデータを見ることができます。また、DBA は通常、キーにアクセスでき、暗号化されていないデータを見ることができます。しかし、たとえば、オフサイトのバックアップを入手したサード パーティはデータにアクセスできません。これは、規制要件への準拠にとって重要な場合があります。
一方、アプリケーション層で暗号化すると、アプリケーション サーバーの管理者のみがアクセスできるキーを使用できます。たとえば、データベース サーバーとアプリケーション サーバーの管理者が離れている場合 (たとえば、異なる組織のメンバー)、これによりセキュリティが強化される可能性があります。アプリケーション サーバー キーにアクセスできない DBA は、データを表示できません。
元の投稿では、アプリケーション サーバーの構成ファイルに秘密鍵を隠すことについて話しました。一見すると、玄関の鍵をドアマットの下に隠すのと同等のセキュリティのように思えます。これを行う場合は、許可されていない人がキーにアクセスできないようにする方法を検討する必要があります。
Mayo に同意しますが、DB 内の暗号化により、システム全体のメンテナンスが簡素化される可能性があります。
アプリケーション レベルへの暗号化では、キー、キーの認証および承認フェーズ、およびデータの視覚化を管理する必要があります (Mayo の記述による)。
アプリケーション暗号化を選択した場合、開発段階だけでなく保守段階でもアルゴリズムの正確性について心配する必要があります。非回帰の単体テストを実装する必要があります。別のより優れたアルゴリズムが必要な場合があるため、暗号化アルゴリズムの変更を管理する必要があります。
また、暗号化されたデータが常に復号化されることを確認する必要があります。ソフトウェアにはバグなどがあるので、それは明らかなことではありません。失われたデータはクリアデータよりも悪いです;-)
もちろん、よく知られている暗号化ライブラリを使用することもできますが、残りのすべての作業は膨大な作業になります。
DB への暗号化は DB 内でのみ保護しますが、DB との何らかの SSL 通信の使用を検討できます。私は（確信はありませんが）TDE はこの種の安全な通信を実装していると思います。
アプリケーションは、信頼されていないエンティティであるユーザーから使用されます。アプリケーション内のデータが失われることを考慮する必要があります。なんで？アプリケーション レベルまたは DB レベルでデータの暗号化を実装しているシステムからデータを盗みたい場合は、カメラを使用してデータを取得するだけで十分です。とても簡単です！
システムのセキュリティだけでなく、機能も考慮する必要があります。多くはセキュリティであり、機能性はそれほど重要ではありません。私の考察がお役に立てば幸いです。
PCI-DSS 準拠であっても、法的責任がなくなるわけではありません...
現在、このような免除を提供している州は、ワシントン州とミネソタ州の 2 つだけです...
DBA による PCI-DSS ソリューションとしての TDE の推進 注意!
TDE は保存中のデータのみを保護し、転送中のデータやメモリ内のデータは保護しません...読み取りアクセス権を持つ人は誰でも、任意のツールを使用してすべてのデータを読み取ることができます...
私見 TDE は、堅牢なアプリケーション レベルの暗号化ソリューションと組み合わせると優れています...のメモ... 弁護士がこの根本的な欠陥を把握するまで待ってください...
セキュリティの第一人者なら誰でも、セキュリティのレイヤーが最善のアプローチであると言うでしょう....