web-dev-qa-db-ja.com

オープンソースで安価な「保管データ」暗号化ソリューション

そこで、データベースの暗号化に関するいくつかのオプションを調査しています。最良のオプションは商用（TDE）です。オープンソースの実装を探しています。 MySQLとMariaDBの最近のリリースには、保存データ機能があります。

MariaDB
https://mariadb.com/kb/en/mariadb/why-encrypt-mariadb-data/

MySQL 5.7.11にはInnoDBテーブルスペース暗号化が付属しています
https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html

この実装（企業にとって）で重要なのは、これらがPCI-DSS/HIPAAなどに準拠しているかどうかです。

MariaDBから：

MariaDB file_key_managementプラグインは、ファイル内のキーの設定を有効にします。キーファイルはシステムの起動時に読み取られ、実行時に追加のアクセスは必要ありません。暗号化のセキュリティは、キーファイルへのアクセス制限によって異なります。鍵ファイル自体を暗号化して、保護を強化することができます。

私の観点からは、これは起動（およびOSの再起動）中にキーの復号化を提供することを意味しますか？したがって、システムを（再）起動するときは常に、このキーを手動で提供する必要があるということですか。このキーをサーバー自体で読み取り可能にすると、そもそも保存データ暗号化の使用が無効になります。

MySQL 5.7.11以降

MySQLの非エンタープライズエディションのInnoDBテーブルスペース暗号化機能は、暗号化キー管理にkeyring_fileプラグインを使用しますが、これは規制コンプライアンスソリューションとしては意図されていません。 PCI、FIPS、その他のセキュリティ標準では、キーボルトまたはハードウェアセキュリティモジュール（HSM）の暗号化キーを保護、管理、保護するためにキー管理システムを使用する必要があります。

MySQL Enterprise Editionはkeyring_okvプラグインを提供します。これには、Oracle Key Vault（OKV）と連携して暗号化キー管理を提供するKMIPクライアント（KMIP v1.2）が含まれています。 OKVなどの安全で堅牢な暗号化キー管理ソリューションは、セキュリティとさまざまなセキュリティ標準への準拠に不可欠です。他の利点の中でも特に、キーコンテナーを使用すると、キーが安全に保管され、失われることがなく、承認されたキー管理者だけが知ることができます。キーコンテナーは、暗号化キーの履歴も保持します。

今、私はこれをセキュリティ基準に準拠させることができるのかと思っています。この保存データを使用する場合、rootまたはmysqlユーザーはメモリから暗号化キーを読み取ることができるため、キーにアクセスできますか？

mysqlmariadbencryptiontransparent-data-encryptionhsm
4
paradoxical81

V 5.7.20以降、（無料）Perconaは 保存時のデータ暗号化 を（無料）リモートHashiCorp Vaultサーバーに保存されたキーを使用して提供します。ドキュメントをたどるのは本当に簡単ではありませんが、私でもそれを実行することができました。

（残念ながら、クライアントデータベースごとに1つのキーを持つという私の要件には対応していません）

1
FrenchieFred

保存データ

ここに用語の問題があるかもしれません。 保存データ暗号化 は通常、

  1. ストレージ暗号化
  2. ピアツーピアや他の形式の使用時のデータ暗号化ではありません。

提案されている暗号化の形式については、RDBMS固有のソリューションはテストされていないため、これらのRDBMS固有のソリューションには近づかないことをお勧めします PostgreSQLの提案

ストレージ暗号化は、ファイルシステムレベルまたはブロックレベルで実行できます。 Linuxファイルシステムの暗号化オプションには eCryptfs およびEncFSが含まれますが、FreeBSDはPEFSを使用します。ブロックレベルまたはフルディスク暗号化オプションには、Linuxではdm-crypt + LUKS、FreeBSDではGEOMモジュールのgeliおよびgbdeが含まれます。 Windowsを含む他の多くのオペレーティングシステムがこの機能をサポートしています。

このメカニズムは、ドライブまたはコンピューター全体が盗まれた場合に、暗号化されていないデータがドライブから読み取られるのを防ぎます。ファイルシステムがマウントされている場合、オペレーティングシステムはデータの暗号化されていないビューを提供するため、これはファイルシステムがマウントされている間の攻撃から保護しません。ただし、ファイルシステムをマウントするには、暗号化キーをオペレーティングシステムに渡すための何らかの方法が必要です。キーは、ディスクをマウントするホストのどこかに保存されている場合があります。

基本的に、さまざまなオペレーティングシステムとファイルシステムの抽象化レイヤーは、保存されているデータの暗号化を処理するための、より適切にテストされた方法を提供します。

はい、それはあなたが鍵を持っていることを意味します。はい、つまり、キーが危険にさらされた場合、データを読み取ることができます。しかし、データベースが危険にさらされ、キーではない場合、データは安全です。そして、それが保存データである理由です。

したがって、通常はルートが所有するキーを格納します。 rootに安全な場所をマウントさせ、postgresユーザーにアクセスを許可します。明らかに、PostgreSQLはデータにアクセスする必要があり、データを復号化する方法を知っている必要があります。

現在、他のユーザーがマシン上にいる場合、postgresユーザーでない限り、データにアクセスできません。さらに、キーにアクセスできません。また、データを危険にさらしたり、暗号化された物理的なバックアップを盗んだりしても、キーがなければデータにアクセスできません。

1
Evan Carroll