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

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

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

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

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

@wanguorui123 乱来起来了

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

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

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

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

@wanguorui123 别搞哦

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

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

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

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

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

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

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

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

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

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

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

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

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

还有个比较好的方法：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Block level 加密不就搞定了

信封加密?

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

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

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

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

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

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

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

@wanguorui123 Base64 是加密方式? emmmm

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

base64 只是编码 逃)

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

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

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

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

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

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

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

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

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

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

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

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