web-dev-qa-db-ja.com

すべてのデータを暗号化するためのベストプラクティス

私は、クライアントが自分の従業員(つまり、クライアントが信頼していないジュニアI.T.の人)がデータベースに問い合わせて機密情報を取得するのを恐れているプロジェクトで作業しています。

データベースは新しいSQL Serverデータベースなので、私にはなんらかの自由があります。

少しググって、ここSQL Server 透過的データ暗号化 に着陸し、それが必要なのか、それが必要でないのかと疑問に思いました...

ユーザーがデータベースにクエリを実行できないようにするために、データベース内のすべてのテーブルのすべての列を暗号化するためのベストプラクティスは何ですか?

6
RMalke

問題は、アクセス制御に要約されます。

私が提案する最初の防御は、信頼できないユーザーへのアクセスを単に拒否することです。データベースにアクセスできない場合、データベースにクエリを実行して機密データを取得することはできません。

データベースサーバーへのアクセスを許可する必要がある場合は、ジョブタスクを実行するためにアクセスする必要があるテーブルへの読み取り権限を明示的に付与する方法を確認できます。または、現在の権限をそのままにしておき、機密データを含むテーブル内のテーブルまたは列をクエリする権限を取り消すこともできます。

このアプローチから始める理由は、暗号化にオーバーヘッドがあるためです。データの暗号化/復号化には、キー管理とCPUコストがかかります。私が理解しているように、インデックス内にある場合、暗号化されたデータとしてデータを検索するパフォーマンスコストも発生します。ソース値ではなく、暗号化された値がインデックス化されます。最終的な結果として、2013-06-11と2013-06-12は隣接するディスクの場所に格納されている可能性がありますが、いったん暗号化されると、ディスクの反対側にある可能性があり、以前はよく実行されていた単純な範囲クエリが実行されます後ろ乳首を吸います。

そうは言っても、Steve Jonesは Encryption Primer について優れたプレゼンテーションを行いました。そのコンテンツの一部と DBでは暗号化するが、キューブでは暗号化しない に関するこの記事を使用して、暗号化機能を稼働させました。

他の人がコメントや他の回答で指摘したように、TDEはその名前の一部に暗号化が含まれているにもかかわらず、データベース自体のデータを保護するつもりはありません。 TDEの目的は、バックアップを不正アクセスから保護することです。ネットワークを流れる暗号化されたパケットとは関係なく、自動的にPCIコンプライアンスを作成します。これは、オフサイトのバックアップテープが紛失、盗難、または盗まれた場合に、キーがなければユーザーが使用できないことを保証するだけです。

私が言及しなかったアクセス制御のもう1つのポイントは、物理的なアクセスです。心配するべきではないジュニア管理者がデータへのアクセスを懸念している場合は、データベースへのアクセスを拒否することに加えて、リモートデスクトップから、または物理的にログオンして、マシン自体にアクセスできないようにする基本的な原則をお見逃しなく機械。ユーザーがボックスに入ると、SQL Serverをシングルユーザーモードで再起動してアクセス制御を削除することを妨げるものは何もありません。

16
billinkc

暗号化を使用して自分の管理者/ ITからデータを保護する唯一の方法は、ユーザーが自分で復号化パスワードを入力するときがデータをクエリするたびに。アプリケーションがユーザーにパスワードダイアログを表示してから OPEN SYMMETRIC KEY ... DECRYPTION BY CERTIFICATE ... WTIHT PASSWORD ... (または同等のもの)を使用してデータ暗号化キーを開き、データが不正なアクセスから暗号的に保護されます。誰かがデータにアクセスしたとしても、復号化キーを知らず、サーバー上のどこかからキーを取得できますか?.

他のすべてのスキーム(TDEを含む)には、バックエンドエンジンによって開かれるキー階層が含まれます。これは、キーが [〜#〜] dpapiをルートとする階層に沿って保存されていることを意味しますsomewhere [〜#〜] 。これらすべてのケースで、暗号化保護ではなく、データのみのアクセス制御保護(GRANT/DENY/REVOKE)があります。これは、復号化キーがSQL Server自体にアクセス可能であり、データを復号化するためです。これらのスキームは、アクセスからではなく、メディア損失から保護します。そして、それらは非常に価値があり、そのように広く展開されています。

最初の段落に戻って、警告を理解する必要があります。

  • 許可された管理者に対してシステム上で秘密を隠すことはできません。バーを上げることができますが、管理者はalwaysを使用して、必要に応じてシークレットを取得できます。
  • 列レベルの暗号化を使用すると、データを検索できなくなります。すべてのテーブルのすべての列を暗号化すると、データをクエリできなくなります。確かに...承認されたユーザーを含むanyoneによってクエリできないことを意味します
  • アプリケーションがすべてのアクセスでエンドユーザーに復号化パスワードを要求することは、ほとんど実現可能ではありません

これら3つの間では、暗号化を導入することで得られるメリットはほとんどありません。実際に沸騰するのは、他の人が言ったことです:アクセス制御と信頼。そして audit が利用可能であり、抑止力として機能することを覚えておいてください。

10
Remus Rusanu

それは完全にあなたが必要としているものではありません。

サーバーがオンラインのままであると仮定すると、透過的であるため助けにはなりません-ジュニア管理者は「データベースにクエリを実行する」ことができ、接続してsqlステートメントを発行できる必要があります(dbサーバーが実行されている限りファイルアクセスはブロックされます)。つまり、暗号化は「機能しません」。

透過的暗号化は、誰かがデータファイルを使ってディスクを持ち出す(盗む)のに役立ちます;)

信頼されていない後輩のIT担当者をITから遠ざけてください-そのように単純です。または、少なくともデータベースの外(アクセス、パスワードが不明)。

5
TomTom