标签: transparent-data-encryption

在修补或升级 TDE 加密数据库时，是否应该考虑任何注意事项？在职责分离的情况下，执行补丁或升级过程的人员是否需要访问 TDE 加密数据库的密钥或证书，或者可以在没有密钥的情况下修补数据库。答案很重要，因为我们是一家合法商店，希望应用程序管理员加密数据库并将数据库维护功能外包给 dba，以便在无法访问“应用程序数据”的情况下修补和升级数据库。你能解释一下吗？

这是我第一次使用 TDE，所以希望我没有做任何可怕的错误。

我正在尝试将我的 TDE 数据库从一台服务器移动到另一台服务器。我在新服务器的主数据库上创建了一个主密钥。然后我使用以下命令从备份中恢复了我的证书：

CREATE CERTIFICATE MyServerCert
FROM FILE = 'CertBackupFile'

当我最初创建它时，我没有私人加密密钥，所以我只是用密码对其进行了加密。

现在，当我尝试恢复 TDE 的备份时，出现以下错误

Msg 15507, Level 16, State 1, Line 2
A key required by this operation appears to be corrupted.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

我试过查看 create 语句，但看不到我可以在哪里输入原始密码。此外，当我查看原始服务器上的 sys.certificates pvt_key_encryption_type_desc = ENCRYPTED_BY_MASTER_KEY 时，但在新服务器上显示 NO_PRIVATE_KEY。所以我认为我在创建时做错了。

谁能指出我正确的方向来解决这个问题？

所以我正在探索一些有关数据库加密的选项。最好的选择是商业（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 插件允许在文件中配置密钥。密钥文件在系统启动时读取，运行时不需要额外访问。加密的安全性取决于对密钥文件的访问限制。密钥文件本身可以加密，提供额外的保护层。

从我的角度来看，这意味着在启动（和操作系统重新启动）期间提供密钥解密？那么每当我们（重新）启动系统时，这是否意味着我们需要手动提供此密钥？使该密钥在服务器本身上可读将首先阻止静态数据加密的使用。

在 MySQL 5.7.11+ 中

MySQL 非企业版中的 InnoDB 表空间加密功能使用 keyring_file 插件进行加密密钥管理，这并不是一个合规解决方案。PCI、FIPS 等安全标准要求使用密钥管理系统来保护、管理和保护密钥库或硬件安全模块 (HSM) 中的加密密钥。

MySQL 企业版提供 keyring_okv 插件，其中包括一个 KMIP 客户端 (KMIP v1.2)，可与 Oracle Key Vault (OKV) 配合提供加密密钥管理。OKV 等安全可靠的加密密钥管理解决方案对于安全性和遵守各种安全标准至关重要。除其他好处外，使用密钥保管库可确保密钥安全存储、永不丢失，并且只有授权密钥管理员知道。密钥保管库还维护加密密钥历史记录。

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

我已经从我的服务器中删除了透明数据加密 (TDE)，删除了密钥并将数据库切换到Simple，缩小了日志，然后又回到Full。

LOG 备份现在和完整备份一样更小，但在删除 TDE 后，主 mdf 文件的大小仍然相同。

这是正常的吗？有没有办法让这些恢复到 TDE 之前的状态？

我知道 MDF 文件将保持相同的大小，直到您缩小它们，但我原以为内部可用空间会显着增加，但事实并非如此。TDE 似乎使它们的大小增加了一倍。

公平警告，我对使用 DB 进行加密非常陌生。现在，在服务器之间备份/恢复数据库的过程中，我们使用以下语句来交换证书：

ALTER DATABASE ENCRYPTION KEY REGENERATE 
    WITH ALGORITHM = AES_256 
    ENCRYPTION BY SERVER CERTIFICATE....

这工作得很好，但问题是通过此语句更改证书所需的时间。我注意到更改大于 100GB 的 DB 的证书可能需要一个多小时。

有没有更快的方法来更改任何人都知道的 TDE 证书？

假设我们有一个生产系统，其中有几个使用 TDE 加密的数据库和一个自生成的证书。

我们经常需要使用这个数据库并更新我们的非生产系统。此过程涉及备份源数据库、将其恢复到预生产状态、混淆个人数据和许多其他项目。

这里的关键事实是预生产系统具有生产的加密证书副本

我正在寻找使此过程更安全的方法 - 我对预生产环境中的证书不满意。有没有另一种方法可以：

1. 永远不要在任何地方保存未加密的备份
2. 不允许将个人数据从生产传播到非生产系统？

我在数据库上禁用了 TDE，完成后我删除了它的数据库证书。后来我对 node2 执行了手动故障转移，并运行了再次启用 TDE 的步骤。然而，加密状态停留在状态 2，进度为 0%。

错误日志显示：

数据库的数据库加密扫描已中止。重新发出 ALTER DB 以恢复扫描。

每次我重新发出更改语句以打开加密时，它都会显示相同的错误。如果我尝试关闭加密，我会收到一个错误，指出加密过程正在进行中并且无法关闭。

我读了这个问题，但是当我尝试删除证书时，它给了我一个错误，表明证书正在使用中。

SQL Server 2016 TDE：“DB_name”的数据库加密扫描已中止

启用 TDE 加密后，我的数据库备份文件 .bak 比以前大 3 倍。有没有办法改善这种情况？这是因为压缩对加密文件的效率不高吗？

我创建了一个主密钥，然后创建了一个证书并加密了我的数据库。

CREATE MASTER KEY ENCRYPTION
BY PASSWORD='A Very Strong Password';
GO

CREATE CERTIFICATE foo
WITH 
SUBJECT='Database Encryption for Multi';
GO

USE mydatabase
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE foo;
GO

ALTER DATABASE mydatabase SET ENCRYPTION ON;
GO

如何更改主密钥密码？

谢谢

我想知道（更好的想法/最佳实践......）我可以用什么来加密我的数据。

我过去曾使用过 TDE，但我真的不喜欢它。因为如果证书和服务器出现问题，我将无法恢复备份。

我在一次又一次的测试中进行测试，我只是不安全。

还有哪些其他选项可以保护我的数据库/数据/备份文件？

我也尝试过屏蔽数据，但是 1）它用于 sql server 2016+（现在我们使用的是 2012）。和 2）它只是创建了另一列，数据被屏蔽，原始数据仍然存在。

这项任务的好选择是什么？

我想保护我的备份，所以没有人可以在另一台服务器上“窃取和恢复”它，我想防止数据被窃取。

我已经在使用登录和 ETC 的良好安全措施。只有我有 sa 通行证，我创建了一个函数，它每个月都会更改通行证，等等。