【问题标题】:Should I encrypt the entire database, or just fields within? [duplicate]我应该加密整个数据库,还是只加密其中的字段? [复制]
【发布时间】:2018-05-29 08:26:11
【问题描述】:

我们在确保遵守刚刚生效的新 GDPR 方面落后,我目前正在考虑为我们的电子商务网站加密存储在我们数据库中的数据。我意识到加密不是强制性的,但我认为这将是一个有用的附加安全性。

我的问题是:静态加密整个数据库以及使用我自己的加密存储值是否有任何优点/缺点?这是你会做的事情,还是你认为这些方法中的一种就足以为个人数据提供良好的安全性?

我的理论是,使用我们的 PHP 脚本在存储和检索值时对它们进行加密可以保护我们,如果有人以某种方式获取了我们的数据库备份 - 并且如果有人获得对数据库的访问权限,表加密将保护我们自己。

我一直在研究这个:Innodb Tablespace Encryption

这应该用于加密整个数据库表。然后,我希望使用 PHP 的 openssl_encrypt 函数手动加密发送到数据库的任何个人数据。

如有任何建议,我们将不胜感激。 非常感谢!

【问题讨论】:

  • 我目前没有时间正确回答这个问题,但是:除非您已经知道自己在做什么,否则只需“加密”,因为您可以这样做很少值得花费时间和成本开销。您需要建立一个威胁模型。你在加密什么?可能的妥协领域是什么?然后努力解决这些问题,而不仅仅是空白的人工混淆数据。
  • 注意:如果您“在确保遵守新的 GDPR 方面落后”,那么像“”那样做额外不必要的事情是完全不明智和低效的我意识到加密不是强制性的,”。继续修复您的 GDPR,不要增加额外的工作量。
  • 我很欣赏你的想法 Martin 并且我同意,当其他一切都完成并就位时,我会考虑这样做。但我想在开始之前提出这个问题以获得一些见解。

标签: php mysql encryption tablespace


【解决方案1】:

我认为这里的一个好的经验法则是对您知道以后不需要执行搜索的个人身份信息进行加密。这在您的服务的可用性和确保您的用户信息安全的努力之间保持平衡。

例如,用户 ID 和他们的电子邮件将是愚蠢的加密。然而,用户的名字、姓氏和实际地址将是很好的候选者。您不太可能对这些信息进行查找。

更高的安全信息可能需要更深入的方法。为此,您可以从用户密码中派生一个加密密钥,并使用该密钥对信息进行加密。这样做的好处是,即使您的数据库服务器您的 API 服务器都受到威胁,攻击者也无法检索此信息。缺点是您需要用户在需要使用此信息的任何时候输入他们的密码。

【讨论】:

  • 我想补充一点,可以搜索加密数据,但它需要额外的 散列 数据表,然后像使用密码一样匹配散列 (@987654321 @;-))。设置起来很麻烦,而且处理器/数据开销很大,但可以做到。电子邮件地址也是被盗数据中最有价值的实体之一。
  • @Martin 是的,我读过有关在实践中使用类似方法的信息。设置起来有点费力,但相对有效。我在回答中说加密电子邮件字段很愚蠢,因为我认为它会绑定到用户帐户并且需要登录。您认为值得使用您详述的散列方法来促进电子邮件地址的加密吗?
  • 哦,你的回答很好,我不想贬低你的帖子——但我想简单地澄清一下,使用哈希表搜索加密数据是可能的——但正如我表示开销很大。
  • 回答您的评论;这取决于加密保护的对象;但通常是的——散列电子邮件地址是一个非常好的主意,因为它们是许多自动黑客的黄金目标。因此,当有人使用电子邮件/密码登录时,会比较两个字段或添加第三个字段以限制要检查的目标行。 (例如,电子邮件的域被保留)。无论如何我应该工作!尽情享受:-)
  • @Martin 感谢您的意见。我不住在受 GDPR 影响的国家,所以我没有花时间去研究它。我希望类似的立法也将在这里生效,所以我必须跟上时代!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-07-24
  • 1970-01-01
  • 2019-01-29
  • 1970-01-01
相关资源
最近更新 更多