开源&廉价的rest数据加密解决方案

Question

因此，我正在探索有关数据库加密的一些选项。最好的选择是商业(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/ HIPAA等？

来自MariaDB：

MariaDB file_key_management插件允许配置文件中的键。密钥文件在系统启动时读取，运行时不需要额外的访问。加密的安全性取决于对密钥文件的访问限制。密钥文件本身可以加密，提供额外的保护层。

在我看来，这将意味着在启动(和操作系统重新启动)期间提供密钥解密？因此，每当我们(重新)启动一个系统，这是否意味着我们需要手动提供这个密钥？在服务器本身上具有此密钥可读性将首先避免使用数据就地加密。

在MySQL 5.7.11+中

非企业级MySQL版本中的MySQL表空间加密特性使用keyring_file插件进行加密密钥管理，而不是作为法规遵从性解决方案。诸如PCI、FIPS等安全标准要求使用密钥管理系统来保护、管理和保护密钥库或硬件安全模块(HSM)中的加密密钥。MySQL企业版提供了keyring_okv插件，它包括一个KMIP (KMIPv1.2)，它与Oracle (OKV)一起工作，提供加密密钥管理。安全和健壮的加密密钥管理解决方案(如OKV )对于安全性和遵守各种安全标准至关重要。除其他优点外，使用密钥库可以确保密钥被安全地存储，永不丢失，并且只有经过授权的密钥管理员才知道。密钥库还维护加密密钥历史记录。

现在我想知道，这是否符合安全标准？使用此数据时，root用户或mysql用户是否可以访问密钥，因为他们可以从内存中读取加密密钥？

Answer 1

Data-at-

这里可能有一个术语问题。数据即时加密通常意味着

1. 存储加密
2. 不是点对点加密，也不是任何其他形式的数据加密。

关于所建议的加密形式，我建议远离那些RDBMS特定的解决方案，因为它们比PostgreSQL建议的其他选项更少测试。

存储加密可以在文件系统级或块级执行。Linux文件系统加密选项包括eCryptfs和EncFS，而FreeBSD则使用PEFS。块级或全磁盘加密选项包括Linux上的encryption + LUKS和FreeBSD上的GEOM模块geli和gbde。许多其他操作系统都支持这一功能，包括Windows。如果驱动器或整个计算机被盗，此机制将防止从驱动器中读取未经加密的数据。在安装文件系统时，这并不能防止攻击，因为在安装时，操作系统提供了数据的未加密视图。但是，要挂载文件系统，需要某种方式将加密密钥传递到操作系统，有时密钥存储在安装磁盘的主机上。

本质上，不同的操作系统和文件系统抽象层提供了一种更好的测试方法来处理rest数据加密。

是的，那意味着你有一把钥匙。是的，这意味着如果密钥被泄露，就可以读取数据。但是，如果您的数据库被破坏，而不是密钥，数据是安全的。这就是为什么它是静止的数据。

因此，您通常存储根用户拥有的密钥。让根挂载安全的位置，并让postgres用户访问它。显然，PostgreSQL需要访问数据，并且必须知道如何解密数据。

现在，如果机器上有其他用户，除非他们是postgres用户，否则他们无法访问数据。而且，他们无法访问密钥。如果他们真的设法破坏数据，甚至窃取物理加密的备份，他们无法访问没有密钥。

Answer 2

那么，您希望为您的业务关键应用程序和数据提供免费的解决方案吗？MySQL提供了一个免费的解决方案，但是密钥文件存储在数据所在的相同位置。PostgreSQL还提供了一个自由解并对整个分区/磁盘进行加密，但是当服务器受到攻击时，它不能提供一个安全的解决方案，因为用户可以读取已安装的磁盘及其数据。这是一个风险，所以您应该将加密密钥存储在一个安全的地方。我想问题是这个安全的地方在哪里，谁会不花钱保护它。我的看法是，你找不到这样的解决办法。