数据库加密都有什么方式？

[Heebe]

数据库因各种原因泄露，然后就会把客户信息给泄露了。 很想知道大企业，如何维护这些数据的，对所有的私密内容加密存储吗？还是有什么其他的方案？

各位，防人的事情我们放一下。我们从技术的角度来说这个问题，怎么样才能最有效率去实现这个想法。

发现大家还是比较选择规避责任，而不是如何去实现。
我打算在一个小型的项目中实践一下，一来这个小项目的私密性非常重要，二来我觉得自己能做多一点事情来为自己和对方换来一些保障还是很开心。
over , thank you.

[qwerthhusn]

数据库因各种原因泄露。我感觉应该做的是防止数据泄露吧。

[wanguorui123]

用第三方工具把敏感字段加密成 Base64 文本存到数据库

[wanguorui123]

全部加密成本太高了同时不利于开发和调试。

[gwy15]

@wanguorui123 你是对加密有什么误解还是对 base64 有什么误解

[Pythondr]

@wanguorui123 乱来起来了

[Pythondr]

没有全字段加密的，生产中只会对敏感字段加密，比如用户密码之类的字段

[cmdOptionKana]

加密没用，因为数据库是要使用的，使用必须解密，因此内鬼可以在解密后的阶段获取数据。

重点是管人，管好这一点：谁能接触到数据。

[wanguorui123]

@gwy15 产品传入明文 -> 第三方加密工具（加密系统、工具、专用的加密机） -> 返回二进制密文数据 -> 产品编码成 Base64 文本 存入对应的字段即可。第三方工具需要产品创建秘钥。同时所有敏感数据全部加密才能达到不泄漏的目的。

[haosamax]

@wanguorui123 别搞哦

[wanguorui123]

@gwy15 加密防不了产品自己泄漏数据，但是基本上可以防止外人泄漏

[liuxey]

难道不是应该解决第一句话吗？

[crazytudou]

全部加密要付出多少成本？有这成本还不如拿来防止泄露，这样事情多简单

[yaxianzhi]

无论多绝密的信息，最终还是原数据存在数据库里，针对这些表建更精细的权限着重保护；原始表脱敏后作为对外业务表，可以用一般的表或者视图；这是一种思路

[Heebe]

@cmdOptionKana 对称加密，用的时候再逆转。加密规则+数据库同时到手才能得到真实数据。

[Heebe]

@wanguorui123 第三方是不可取的。但是你提醒了我可以写一个加密 C++库，规则写的人知道，运营再固定一个密码。感觉不错。

[Heebe]

@liuxey 这个太难解决了，这万一像那微 x 的那个突然发疯，啥都有可能。

[FragmentLs]

理论上现阶段性能上一般情况达到不可逆的加密才有意义...自己写的可逆加密感觉意义不大

[wanguorui123]

@Heebe 自己写也可以，但是效率和安全性都需要评估，同时秘钥如果运维知道也无济于事，还有线上的请求日志运维也知道，内部人员根本防不了！

[wanguorui123]

@Heebe 如果是大公司，应该分散管理，而不是单纯的考虑如何防止数据泄露。

[cmdOptionKana]

@Heebe 数据库最大的作用是检索，如果不在数据库内解密，就无法检索。

你说的 “用的时候再逆转” 这种方法，等于没有数据库，只有文件名和加密后的文件（类似于一堆设置了密码的 word、Excel 文件）。

[Buges]

何必加密那么麻烦，在没人看的用户协议里加一句“如数据泄露给第三方我们不承担责任”就完了呗🐶

[wanguorui123]

还有个比较好的方法：

腾讯 QQ 第十五声明、 [不可抗力及其他免责事由]
15.2 在法律允许的范围内，腾讯对以下情形导致的服务中断或受阻不承担责任：
（ 1 ）受到计算机病毒、木马或其他恶意程序、黑客攻击的破坏。
（ 2 ）用户或腾讯的电脑软件、系统、硬件和通信线路出现故障。
（ 3 ）用户操作不当或用户通过非腾讯授权的方式使用本服务。
（ 4 ）程序版本过时、设备的老化和 /或其兼容性问题。
（ 5 ）其他腾讯无法控制或合理预见的情形。

[GavinFlying]

@Heebe 密码学第一课--不要“自创”加密算法

[Heebe]

@GavinFlying 这个有道理。但是现在 AES、DES 这些都基本自带了，技术倒是容易实现。

[summic]

参考这篇
《使用 SQL Server 2016 的 Always Encrypt 功能防止系統管理員讀取私密性資料》
https://www.uuu.com.tw/Public/content/article/19/20190805.htm

[singerll]

数据分级，数据脱敏，数据加密，三个都要有

[luanluan]

我公司做加密机的 有兴趣吗？ 透明加密方式，应用加密都可以实现

[yankebupt]

为了避免争议我就不 @ 4 楼了
为什么都不想加密，因为谁拿着密码谁就得为数据安全负全责。

参考为什么次等信用卡都要求用户自己输密码……先把盗刷责任甩个一干二净再说。

2 楼那个看起来很可以但有可能是临时工想要脱罪想出的最后办法。

[deplives]

2 楼那个把 b64 算作加密的是故意的么

[wanguorui123]

@deplives 用第三方加密组件加密转成成 Base64 存在数据库

[hantsy]

使用专门的安全服务，比如 Vault

[deplives]

@wanguorui123 您这语言表达能力没谁了

[BIAOXYZ]

LZ，我给你一些关键词 [CryptDB，FHE(fully homomorphic encryption)] 你可以沿着搜索一下。不过目前这种（密码学上）安全数据库性能太差，还无法在现实中实用起来。另外，25 楼里提到的 MS SQL Server 的 Always Encrypted （是的，那个文章本身标题也没有把特性名字打对，是 Encrypted ），就是参照 CryptDB 的，不过只实现了部分特性。

[Elietio]

碰到过做 IM 的，消息文本双重 BASE64 加密，然后还要写模糊查询去匹配，简直醉了

[akira]

@cmdOptionKana 用户敏感信息 一般不需要参与检索吧

[areless]

@GavinFlying 过去大量通讯兵在通讯领域的加密方法均为自创，简单的字符加减位以及密码字典等等。随心而行。并不太会使用密码学里的那些对称算法啊，非对称算法。那却是加密使用的鼎盛期。我建议还是可以“自创”的，毕竟最后在某些地方看到“自创”的加密方式都会略感惊讶，原来几百年前人家就这样搞。

[akira]

@areless 你也说是过去了。 密码学的算法 是有数学保证的，自创的话，大部分人的数学能力并不足以保证

[mamba]

可以做存储层的加密
搭配反向代理的形式做访问控制

[qile1]

我到时遇到不少数据库加密的，一直纳闷他们是怎么做到的，丁香园有个 app 数据库就是 sqlite 加密的，内容看不到，不知道他们怎么搞的

[aneureka]

@qile1 #39 用药助手吧... 前两天刚扒 确实被加密了

[nifury]

https://ieeexplore.ieee.org/document/6544835?reload=true
印象中看过类似的 paper，好不容易又找到了

[abcdabcd987]

@cmdOptionKana 使用加密的数据库不一定要先经过解密，比方说 CryptDB
http://people.csail.mit.edu/nickolai/papers/raluca-cryptdb.pdf

[fakeman]

最近也想搞个这样的，可惜找不到关键字
能想到这么用的，keepass 应该算是

[alphatoad]

Block level 加密不就搞定了

[a3587556]

信封加密?

[barbery]

最麻烦的是加密的字段需要查询，这个加密就得不偿失了

[dilu]

前公司是这样的，非对称加密，私钥在加密服务那里，如果想解密只能内网请求带上项目和 key 解密

[ganning]

加密的内容需不需要解密？

[cmdOptionKana]

@abcdabcd987 这种技术并不完善，更像一个试验品，安装使用复杂，要注意的事情也多，局限性也大，攻击手段也被研究和公开了。看这里 https://www.cnblogs.com/JHSeng/p/11141300.html

[fancy111]

没什么方案，数据库信息本身就是能调用出来的，能做的就是防止泄露和不放一个篮子里。大公司被脱裤的还少吗？

[sockpuppet9527]

歪个楼： 如果盘数据加密的话，可以看看 spdk opal bdev.硬件层协议做加密，用户态驱动数据读写。适合多中断小数据读写场景

[dingyaguang117]

敏感信息加密后入库， 单独有个加解密服务

[l4ever]

@wanguorui123 Base64 是加密方式? emmmm

[qile1]

@aneureka 那有啥思路吗？我也想把自己的数据简单加密下

[jtwor]

base64 只是编码 逃)

[Heebe]

@akira 是的，我觉得大家都忽略了这点。如果需要检索，那就没有加密的必要。就像没有谁会去检索密码一样。所以，加密数据本身就是忽略检索需求。

[Heebe]

@l4ever 他只是表达错误。意思是 byte 转 base64，用于存储。实际 byte 的处理，才是加密的关键。

[JamesMackerel]

加密字段需要查询的话，目前在网上别的地方看到的一个方案是做一个冗余字段，在里面放一个 原文加盐后 Hash 的值，查询的时候就查这个字段。但是假如遇到了碰撞，那就真的不知道怎么办了。

[Heebe]

@JamesMackerel 方式可以，但是效率太低，而且准确性差。所以我们前提是忽略检索需求，再想想😄。

[wanguorui123]

@l4ever 用第三方加密工具把敏感字段加密后编码成 Base64 文本存到数据库

[loginbygoogle]

移动端可以看看 wcdb，微信开源的数据库，基于 SQLCipher

[atuocn]

@areless 通常没有受过训练的人，自创的加密方法熵太低，“字符加减位以及密码字典”象这种密码，带有明显的统计特征，破译起来太容易。

[ToBeHacker]

把鉴权做好吧，在内容上搞加密不是自己为难自己么

[wangxiyu191]

目前见过有实现的最安全 /甩锅甩的最干净的：所有加密 key 全部都只由用户掌握，全链路 SGX/TrustZone/...。数据丢了要不然是用户的锅（秘钥泄露），要不然是处理器厂商的锅（处理器后门 /漏洞）。服务商就算是想看也是看不到数据的。
那么问题来了，你相信 Intel/AMD/ARM/...么？
顺带安利个类似操作的数据库： https://help.aliyun.com/document_detail/144156.html

[cwyalpha]

管好网络和系统安全，做好堡垒机

[qyvlik]

要分清几个概念：
1. 编码（如 Base64, Base58, urlencode, hex ）
2. HASH(如 md5, SHA-256)
3. 加密（一般包含对称加密，非对称加密）
帖子题目讨论的是 "数据库加密都有什么方式"，那么用到的加密一般是 对称加密和非对称加密这两大类算法，例如 AES、DES 为常用的对称加密算法，非对称加密算法 常见的有 RSA，加密数字货币用到的椭圆曲线等等。
在进行实践操作的时候，一般是进行组合使用：
例如大多数加密算法库，明文是字节数组，密文也是字节数组，会采用 base64 或者 hex 对密文进行编码，便于调试和保存。
再例如使用在业务上会多次使用 AES 配合不同密码进行加密，或者再加一层 RSA 进行处理。
剩下参考 这个帖子的回复 https://www.v2ex.com/t/644725#reply6

[gaius]

看严格程度了，可以用对称 /非对称加密，数据库存加密后的结果，也可以再冗余脱敏后的结果