静态和或AES_ENCRYPT加密

静态和或AES_ENCRYPT加密,第1张

静态和/或AES_ENCRYPT加密 静态加密

静态加密是指不使用/访问或更新数据库时的数据。移动中的加密就像

TLS
是将数据( 来自数据库
)从服务器传输到服务器到浏览器,再到服务器,再到浏览器等。在大多数情况下,如果认真处理并以 认为正确的态度处理TLS,则TLS是非常好的
选择需要做更多的事情,而不是最低限度的东西 才能真正实现它的真实性。

一个典型的例子是人们在自己的域上从LetsEncrypt获得TLS证书,然后突然觉得他们所有的东西都是安全的。但是 他们不加密会话或cookie,
因此在防御中留下了巨大的潜在漏洞。

不要使用MySQL的内置加密系统。

我对此压力还不够。MySQL中的内置加密系统不适用于实际的安全数据保护。

请在详细信息中阅读我对一个非常类似问题的回答(
我不想简单地复制/粘贴 )。

好吧,那么,因为您坚持....在这里:


我一直都理解 不要使用 MySQL内置的加密功能,因为静态数据加密(在SQL中)的重点是,如果服务器受到威胁,则数据的风险不会那么大。

MySQL内置功能的问题在于,它不适用于数据从“ 静止 ”状态传入/传出的 时间
,因此任何数据的纯文本都可以记录在MySQL日志(以及存储系统中的其他位置)中,例如查询查询未加密,因此您可以从众多查询中获得

count
结果,并在加密之前/之内推断出列值。您可以在此处了解更多信息。

关于加密,您应该使用一些经过考验的库,例如defuse / php-
encryption。

从我自己对此主题的研究中所读到的内容来看,Magnus提供的去碎片化/ php加密的链接是防止MySQL曾经导致您破坏数据的最佳方法之一,因为它永远不会让MySQL程序/服务器曾经看到过数据的纯文本值。

-答案于2017年5月7日发布。


此外比尔Karwin的回答同样的问题,提出了一些有价值的额外的见解:

+1为Martin的答案,但我会添加一些有关其价值的信息。

MySQL
5.7已经为InnoDB表空间实现了静态加密(https://dev.mysql.com/doc/refman/5.7/en/innodb-
tablespace-encryption.html)。

据报道,MySQL
8.0还将对InnoDB重做日志和撤消日志文件(https://dev.mysql.com/doc/refman/8.0/en/innodb-
tablespace-encryption.html)进行静态加密。

这仍然留下未加密的查询日志和二进制日志。为此,我们将不得不等待将来的MySQL版本。

为什么要花这么长时间?MySQL安全工程负责人在上个月[2017年4月]在Percona
Live会议上的一次飞鸟式会议上表示,他们非常谨慎地实施加密权。这意味着既要实现加密功能,又要实现密钥安全性和密钥轮换以及其他用途。要做到这一点非常复杂,他们不希望实现某些东西会变得过时并且会使每个人的加密数据库无效。

-答案于2017年5月7日发布。

收盘点:

安全性很复杂。如果您想正确地进行 *** 作并对洋葱皮有信心,那么您需要做很多事情(请参见下面的项目符号);但您需要做的第一件事是:

  • 定义要防范的对象

说真的
对于那些想要窃取您的纯文本名称和地址的人,想要接管您的服务器的人,以及仅仅因为垃圾数据而要浪费数据的人,您需要采取不同的策略。您可以一直保护自己不受所有人的迷惑,从概念上讲,这是不可能的*;因此,您需要定义最可能的攻击者,然后确定如何最好地减轻攻击者的攻击。

对于MySQL而言,有一些明确的建议:

  • 将SQL和PHP保留在同一服务器上。不要远程访问MySQL数据。

  • 排除对SQL的外部访问(因此

    localhost

  • 混淆表名和列名;如果有人闯入您的数据并且您

    HDTBJ^BTUETHNUYT
    位于该列下,
    username
    那么他们知道此乱码可能是用户名,因此他们在尝试破坏您的加密方面有一个很好的开始。

  • 重要提示 :真正锁定表访问;设置许多MySQL用户,每个用户只有最基本的特权即可执行所需的工作;您希望用户读取表( ),并且仅读取某些表;用户写入某些表,但无权访问其他表。它是关注点分离,因此,如果MySQL上的任何一个用户受到威胁,都将受到影响。您并不会自动丢失其中的所有数据。

  • 使用PHP加密服务。将加密密钥存储在完全独立的位置;例如,有一台仅用于备份的服务器,您只能访问该服务器以获取加密密钥,因此,如果您的PHP / MySQL服务器受到威胁,则有一定的空间可以切断并锁定Key服务器,这样您就可以限制损害。如果密钥服务器也有备份,那么实际上您并不会受到严重影响( 取决于具体情况 )。

  • 设置许多观察程序和电子邮件通知程序,以准确告诉您某些进程何时运行以及哪些服务器用户(不是人员而是程序)在做什么。因此,您可以了解为什么意外的进程在凌晨5点开始运行,以尝试测量MySQL表的大小。WTF?

  • 即使您的MySQL AES_ENCRYPT数据不在数据库中处于静止状态,也很有可能“嗅探”您的数据,但是如果网站受到威胁(或更糟糕的是,PHP代码不安全),那么定时攻击就可以解决通过定时查询查找获得数据内容,并返回数据包。

  • 安全是一个黑洞。在某些时候,您可能会想“做完了,我做够了”。没有人拥有全面的安全性,一些非常敬业的组织拥有 足够的 安全性。您需要先确定自己愿意走多远,然后再走远。


  • 为什么不可能? 因为要始终保护您的数据不受所有威胁的影响,它就必须像哈希一样不可读,不可用。哈希始终不受所有人的保护。但是哈希永远不会散列。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5063030.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-11-16
下一篇 2022-11-16

发表评论

登录后才能评论

评论列表(0条)

保存