我应该加密数据库中的数据吗？

我有一个客户，我将为此目的做一个有关患者护理，管理患者，咨询，历史记录，日历以及有关此内容的Web应用程序。

问题在于这是敏感数据，患者病史等。

客户坚持要在数据库级别加密数据，但是我认为这会降低Web应用程序的性能。（但也许我不必为此担心）

我已经阅读了有关健康问题的数据保护的法律（葡萄牙），但是对此并不十分明确（我只是问他们这个问题，我在等待他们的回应）。

我已经阅读了以下链接，但是我的问题不同，是否应该加密数据库中的数据。

我在加密数据时预见到的一个问题是，我需要一个密钥，这可能是用户密码，但是我们都知道用户密码的方式（12345等），并生成我必须存储的密钥它在某个地方，这意味着程序员dba，无论可以使用它什么，对此有何想法？

即使向用户密码添加随机盐也无法解决问题，因为我可以随时访问它，因此可以解密数据。

我将亲自检查有关法律。如果数据需要加密，则需要加密。

如果您没有得到任何指导，我将致力于保护患者及其数据之间的联系。也就是说，您很可能PatientID在整个数据库的表中使用了。 PatientID不能识别患者，仅识别患者的病史等。但是，要识别PatientID居住在里斯本圣贝尔纳多街（Rua deSãoBernardo Lisbon）的Joe Bloggs，如果可以的话，我会将其保存在单独的数据库中。将TDE用于患者的个人详细信息，并考虑使用Web应用程序中的密钥对其进行加密。

尽管无法识别患者的医疗数据被盗非常令人尴尬，但除此以外，不可能发生任何其他事情。从字面上看，在线比赛都使用了这种匿名医疗数据。

将医疗数据与患者的个人详细信息分开。使用一组强大的角色将人员限制在他们所需的范围之内。除了需要直接与患者打交道的医务人员（一线护士和医生）外，没有人可以同时使用这两者。接待员只需要病人的个人详细信息，实验室工作人员只需要病历和PatientID，外科护士只需要当前的病情和名字。

确定了每组角色后，不仅要在Web应用程序中实现它们，而且还要在数据库中实现它们以及额外的安全层。

是的，您应该加密数据库。

存储数据（“静态数据”）的基本加密是公认的安全原则，如果您所在国家/地区的法律保护个人或健康信息，则可能是法律强制要求的。

我们使用的是SQL Server 2008，因此我们使用的是Microsoft的TDE。可能有一些针对MySQL的第三方解决方案，或者也许只有一种通用的卷加密方法（例如TrueCrypt）才行得通（尽管我想拥有某种已通过认证可与数据库一起使用的方法）。

如果做得正确，对性能的影响应该很小。

顺便说一下，您提到的链接（关于敏感信息的分离）是您在基本数据库加密基础上应该考虑的。

编辑：上述加密将加密卷。如果有人要窃取硬盘驱动器，他们会发现加密的数据。但是，如果有人要在数据库上运行查询，他们会看到未加密的数据（这就是为什么我提到了信息分离的原因，即使OP不想讨论这一点）。

请注意，此建议是您应做的最低要求。如果您需要法律意见，那么您当然需要在其他地方寻找。如果您想更全面地讨论编写安全代码，那么我将从“ 编写安全代码 ”一书开始。

在决定此类安全事项之前，您应该评估威胁模型。如果不知道您要防御什么，那么您采取的任何措施可能都没有什么价值。

现在，在这种情况下，您可能需要担心一些事情：

• 攻击者可以物理访问您的数据（例如，闯入数据中心，窃取备份磁带等）
• 攻击者获得对您的原始数据库的读取权限
• 攻击者例如通过SQL注入，缓冲区溢出等危害您的应用程序。

对于第一种情况，只要服务器无头即可将数据库和所有备份存储在加密的卷上-窃取服务器或磁带将需要中断磁盘级加密。

对于第二种情况，加密数据库数据确实有帮助，但前提是您不将所需的密钥或密码短语存储在任何地方。

在第三种情况下，一切都取决于发生攻击的上下文：例如，如果是XSS或CSRF攻击，则攻击者可以执行合法用户可以执行的任何操作，并且加密数据根本没有帮助。

因此，您的威胁模型是攻击者，它可以通过找到登录凭据并设法从外部登录到数据库服务器，或者通过获得对数据库服务器的根访问权限来获得对原始数据库的读取访问权限。一个典型的途径是首先获得Web服务器上的Shell访问权限。然后，攻击者可以从那里从配置文件中读取访问凭据，然后连接到数据库。

另一个注意事项是保留密钥和密码的位置，尤其是在使用具有无状态执行模型的平台（例如PHP）的情况下。理想情况下，您可以让客户在需要时键入其密码短语，并将其仅保存在内存中，或者甚至更好地由客户端进行解密（但这通常不可行）。在无状态平台上，通常使用会话，内存缓存，数据库或平面文件来携带状态。但是，与将状态保存在有状态的Web应用程序自己的内存中相比，所有这些漏洞要脆弱得多。避免这是鸡与蛋的问题，因为如果在持久保存状态之前对状态进行加密，那么您刚刚创建了另一个必须牢记的秘密。记住客户端上的密码并将其与需要它的每个请求一起发送可能是最不可怕的解决方案；

暂时忽略客户的要求以及法律是什么...

不，您可能不应该加密数据。如果这样做，将无法轻松搜索它。例如，like 'Smith%'如果每个姓名条目都经过加密，您将如何搜索姓氏？如果不能，您将如何绘制患者的血压随时间变化的曲线图 select .... from.... where patient_id = N？

显然，您应该确保服务器受到适当保护，网络连接受到保护，并且用户界面也得到适当保护（包括会话超时，因此用户无法走开，可以访问使用计算机的任何人）。您可能还想加密数据库备份。并从物理上保护服务器所在的房间。但是我不会加密实时数据。

澄清：假设OP询问的实际上是对数据库中的数据进行加密。不是数据库所在的文件系统。

如果您使用有效的MVC框架（如CakePHP）仔细开发Web应用程序。Zend或Rails，那么您应该能够在数据模式级别启用/禁用加密。

例如CakePHP有一些用于加密数据的Modal行为示例。使过程对控制器和视图透明。

执行此操作时，请忽略有关索引的问题以及其他技术数据库问题。应该可以将此作为可配置的选项。

另外，我会在以后或仅在生产服务器上启用加密。加密的数据很难在开发过程中调试和使用，并且只能在某些列上进行。

是的，您应该加密数据库。

由于这是个人和敏感信息，因此我绝对相信。

从密码中，您可以导出仅为会话存储的加密密钥。这样，它就不会存储在任何地方，而且任何人（包括DBA）都不知道它，因为也没人知道密码。任何试图直接查看数据库的人都会发现乱码。破坏它的唯一方法是通过会话劫持，但是我在这里假设会话也是安全的。

我问自己为什么客户端为什么要求您加密数据库？如果他要您保护数据，我会同意，但是他已经有了一个隐式实现。因此，只要他不知道自己在说什么，就从我的角度出发，他只是在说些时髦的话。

我还发现对数据库进行加密非常没用，因为我坚信几乎每个主要的DBMS都会适当考虑安全性，而且可能比您更好。为了通过DBMS访问DB，您将需要凭据。如果是加密的数据库，则还需要这些凭据，而要解密数据，则需要您似乎已经拥有的那些凭据。

按照这种思维方式，我建议让DBMS处理安全性，并努力从用户输入到数据库访问的所有过程中保护凭据，还可能强制使用强密码和定期更改。