web-dev-qa-db-ja.com

SQL Serverのエンドツーエンドの暗号化オプション

TDEなどのSQL Serverのデータベース暗号化オプションに精通しており、バックアップ/バックアップの場所が暗号化され、適切に保護されていることを確認しています。

エンドツーエンドの暗号化のオプションを詳細に要求する新しいクライアントのためにいくつかの作業を行っています。つまり、データベースサーバーからアプリケーションサーバーに送信されるデータが途中で暗号化されたままであり、傍受（または解釈）できないようにします。 ）あらゆる種類のパケット監視。

データベースへの接続を暗号化するためにSSL証明書を使用することについては知っていますが、これはめったに構成したことはありません。これがエンドツーエンドの暗号化に適切なオプションであるかどうかは本当にわかりません。SQLServerだけを使用してこれを構成することはできません。

私の考えでは、アプリケーションの端に、またはこのようなエンドツーエンドの暗号化を可能にするネットワークルートに何かがある必要がありますか？

ネットワークセキュリティに関する私の知識は、基本的にファイアウォールルールと一般的なルーティングに限定されているため、さらに調査するか、実践するために利用できるオプションを探しています。

この質問は意見に基づいているため、締め切られるので注意します。したがって、SQL Server自体（またはDBAの権限）内で、データのエンドツーエンドの暗号化を構成するための確かなオプションを求めています。

sql-serversql-server-2014sql-server-2016encryption
3
Molenpad

SQLサーバーの常に暗号化された機能。これは、エンドツーエンドの暗号化を提供するように設計されたクライアント側の暗号化テクノロジです。つまり、クライアントアプリケーションのドライバーでデータを暗号化します。つまり、データはクライアントとSQLサーバー間のネットワーク上で暗号化され、SQLサーバーのメモリ内で暗号化され、ディスク上で暗号化されます。正しく実装されていれば、SQLサーバーマシンの管理者権限を取得した侵入者（およびデータがクラウドにある場合はクラウド管理者）からデータを保護することもできます。

大まかに言えば、Always Encryptedは次のセキュリティ保証を提供します。プレーンテキストデータは、ColumnMasterKey（証明書/ AKVキー/ HSMベースのキーなど）にアクセスできるエンティティにのみ表示されます。

詳しく説明するには、次のシナリオを検討してください。

2つのマシンを考えてみましょう：

  • MachineA：SQL Serverが実行されているマシン
  • MachineT：クライアントマシン。

2人のユーザーを検討する

  • UserA（これは技術的にはユーザーのグループにすることもできますが、簡単にするために単一ユーザーのシナリオを検討します）：管理者は誰ですか- MachineA、SQLサーバーを管理し、SQLサーバー上のSysAdminです。ただし、serAはMachineTにアクセスできず、serAはマシン上のSQL Serverに保存されている暗号化されたデータを復号化できませんA（暗号化されたデータ、この回答のコンテキストでは、SQL ServerのAlways Encrypted機能を使用して暗号化されたデータです）。

  • UserT（これは技術的にはユーザーのグループにすることもできますが、簡単にするために単一ユーザーのシナリオを検討します）：信頼できるユーザーであり、アクセス権がありますMachineTにアクセスすると、データベースのすべてのデータにアクセスできますdb SQL ServerのMachineAでホストされています。また、serTは信頼できるため、暗号化されたデータを復号化できる必要があります。

MachineAで実行されているSQL Serverがdatabase dbおよびtable t。

私たちの目標は、テーブルtに属する列を保護することです。たとえば、ssnColとすると、serT = ssnColを平文で表示できるはずです。

上記の目標は、次の手順で達成できます。

  • serTログインMachineT。
  • serT SSMSをMachineTで開きます。
  • serT SQL Serverに接続MachineA
  • serT暗号化ssnColテーブルtの この記事 のEncrypt columns (configure Always Encrypted)セクションで説明されている手順を使用
  • この手順の後、列ssnColが暗号化されます。

serTが上記の方法でssnColを暗号化すると、2つのキーが生成されます

  • [〜＃〜] cmk [〜＃〜]：CMK別名列マスターキーは、CEK/sの暗号化に使用されるキーです。このキーはMachineTのWindows証明書ストアに保存されます。
  • [〜＃〜] cek [〜＃〜]：CEK別名列暗号化キーは、暗号化に使用されるキーですssnCol =、このキーは暗号化された形式でSQL ServerのMachineAに保存され、プレーンテキストのどこにも保持されません。

したがって、ssnColを復号化するには、CEKが必要ですが、CEKを復号化するには、CMKが必要です。

CMKはmachineTのWindows証明書ストアにあるため、serTのみがCMKにアクセスし、CEKを復号化してssnColを復号化できます。

serAはmachineAの管理者であり、SQL ServerのSysAdminでもありますが、彼/彼女はCMKにアクセスできないため、serAです。プレーンテキストでssnColにアクセスできません。これを確認するには、MachineAからSSMSを使用して、serAとしてログインし、クエリssnColを実行します。

他にご不明な点がありましたら、コメント欄にご記入ください。回答いたします。

3
Nikhil Vithlani - Microsoft

あなたは正しいです; SSLは、移動中のデータの暗号化をサポートする公式の手段です。

Microsoft SQL Serverは、SSL（Secure Sockets Layer）を使用して、SQL Serverのインスタンスとクライアントアプリケーションの間のネットワークを介して送信されるデータを暗号化できます。 SSL暗号化はプロトコル層内で実行されます（ technet ）

常に暗号化は少し深いです。クライアントアプリケーションでデータを暗号化してbefore送信し、暗号化されていない方法で保存することはありません。したがって、Always Encryptedを介して暗号化されたデータは、転送中および静止中に「安全」です（暗号化されたデータとして保存されます）が、パケット自体はネットワークレベルで暗号化されません。 （ MSドキュメント ）

したがって、DBAやレポート作成者が平文データ（クレジットカード番号や社会保障番号など）を表示できないようにする場合は、Always Encryptedがそのレベルのセキュリティを実現するための可能なツールです。

ただし、パケット監視ツールでデータベースのユーザー名とパスワードを確認したくない場合、またはDBからアプリケーションに移動するときにクリアテキストデータを確認したくない場合は、SSLを使用する必要があります。

3
CaM

TDE（2008年以降）は保存時の暗号化でした。つまり、適切なセキュリティ管理なしにDBを他の場所に復元しようとすると、不可能でした。サードパーティのツールを使用して動いているデータを盗聴することもできますが、これは SSLセキュリティ 、または [〜＃〜] ipsec [〜＃〜] 。

SQL 2016の導入により、 Always Encrypted が有効になり、検討する必要があるかもしれません。それは基本的に、静止状態および動作中のデータを暗号化します。

2
S4V1N