SQL Server 错误日志是否可以加密？
我们的 SQL Server 最近有一个内存转储，它把它扔进了错误日志。虽然转储对于确定问题绝对有用，但它让我想知道该转储对可能有权访问服务器但不一定是 SQL Server 的用户的可见性。
我知道 TDE 保护静态数据、日志和备份文件，但潜在的敏感信息可能会通过内存转储暴露——尤其是如果它是由恶意来源故意设计的。
转储的内容类似于：
02f59f10 70b50b54 00000101 000000a2 00650073 T..p........s.e.
02f59f20 00760072 00720065 0027003d 006f006c r.v.e.r.=.'.l.o.
02f59f30 00610063 0068006c 0073006f 00270074 c.a.l.h.o.s.t.'.
02f59f40 0054003b 00750072 00740073 00640065 ;.T.r.u.s.t.e.d.
02f59f50 0043005f 006e006f 0065006e 00740063 _.C.o.n.n.e.c.t.
02f59f60 006f0069 003d006e 00720074 00650075 i.o.n.=.t.r.u.e.
02f59f70 0041003b 00700070 0069006c 00610063 ;.A.p.p.l.i.c.a.
02f59f80 00690074 006e006f 004e0020 006d0061 t.i.o.n. .N.a.m.
如果可能的话，我想通过加密 SQL Server 错误日志来主动预防可能的数据泄露，以减少故意内存转储将敏感数据暴露给非授权用户的可能性。
没有“打开错误日志加密”的选项，因此您需要在较低层使用加密，例如 bitlocker 或类似的磁盘加密实用程序。
如果他们可以访问服务器，那么他们就可以访问 SQL Server。没有两种方法。
TDE 在这里无济于事，如果源已经可以登录到服务器，一般来说全盘加密也无济于事——无论是否可以访问 SQL Server。
任何可以登录服务器的人都可以读取内存。某些权限可能不会被锁定，并且可以附加调试器。其他途径也存在，我不会在这里进入，但如果他们有访问权限，那就已经太晚了。
我完全理解，你应该积极主动，荣誉！遗憾的是，SQL Server 内部确实没有任何原生功能可以执行此操作。通过 3rd 方解决方案对其进行加密可能会导致其他问题。
我会说最好的事情是确保没有人可以访问服务器以及谁可以访问 SQL Server。轶事证据：我曾经能够在“锁定”的服务器上看到一堆数据，因为有一个共享具有“所有人”的读取权限。
虽然确实没有加密 SQL 错误日志的本机选项，但您应该能够将域证书应用于日志所在的文件夹，将证书添加到虚拟服务帐户或分配给服务的服务帐户，如果它们不同，则向需要查看该文件夹的任何人授予权限和证书访问权限。该功能称为 EFS，即加密文件服务，它是 Windows 操作系统的一部分。任何试图打开加密文件夹中的文件的人如果没有使用该证书的权限，都会收到错误消息。