13.2 配置文件加解密
如果没有加密配置,那么一些只有运维人员能看见的东西,开发人员也可以看见,在网上“删库跑路”的段子,可能就会变成真的了,所以这时要加密
13.2.1 常见加密方案
13.2.1.1 不可逆加密
不可逆加密,就是理论上无法根据加密后的密文推算出明文的加密。
像加密的框架 Shiro(MD5、SHA) 、Spring Security 都是采用这种方式
一般用在密码加密上,常见的算法如 MD5 消息摘要算法、SHA 安全散列算法
13.2.1.2 可逆加密
可逆加密,是可以根据加密后的密文推断出明文的加密方式;
可逆加密一般又分为两种:对称加密和非对称加密;
①对称加密
对称加密指加密的密钥和解密的密钥是一样的
常见的对称加密有 DES -> 3DES -> AES 并随顺序强度逐渐升级
②非对称加密
非对称加密就是加密的密钥和解密的密钥不一样,加密的叫做公钥,可以告诉任何人,解密的叫做私钥,只有自己知道;比如 Github 的验证、支付宝的支付开发,一对多的场景一般用非对称加密,常见的算法教 RSA
13.2.2 对称加密
JDK 中有专门用于加密的 JCE,但是是长度受限制的,需要从 Oracle 官网下载一个不限长度的 JCE。大概受贸易战影响了加密算的知识产权,北美(美国、墨西哥、加拿大)可以使用的
- 1.下载不限长度的 JCE
- 2.解压完之后这样
打开 readme.txt ;说明中windows java-home是 jdk 中的 jre 目录
然后把压缩文件中的US_export_policy.jar
和local_policy.jar
复制到windows java-home\lib\security下:
- 3.配置完 JCE 在 config-server 中配置 bootstrap.properties
# 密钥
encrypt.key=javaboy
- 4.启动 config-sever 服务,并准备好 POSTMAN 界面,启动服务后我们在 Endpoints 的 Mapping 中有很多请求路径:
其中 /encrypt/status 打开可以看见加密的运行状态,显示 OK:
- 5.POSTMAN 加密一个明文,我随便写的 dev123456,是 post请求,
- 6.把密文替换 client1-dev.properties 中的值,并推送到远程 git 仓库中:
- 7.启动 config-client 服务,依照之前配置访问 config-sever 中 dev 对应的接口
http://localhost:8082/hello
:
可以看到是密文,竟然不是明文,client-client 应该能看见明文才对,要不不知道什么意思;试想一下 client1-dev.properties 文件中javaboy=c05e020a1bf6eeebba751a6b4b3d0179c92c450853979c3814ecdf6dd30da29e
; config-sever 怎么能区分值是密文还是普通的字符串呢,应该要加一个标识才对,是的,要加上(cipher)
前缀:
javaboy=(cipher)c05e020a1bf6eeebba751a6b4b3d0179c92c450853979c3814ecdf6dd30da29e
这样就知道是密文了,config-server 会解密,然后 config-client 访问就能拿到明文了
- 8.再次提交到 Git 仓库
-
- 重启 config-client服务,再次访问接口:
天呐,还是没解密,原来我把 {} 写成 () 了,修改后再次提交 git 仓库,重启 config-client 后重新访问接口http://localhost:8082/hello
:
- 重启 config-client服务,再次访问接口:
这样就成功了,这就是 Spring Cloud Config 的对称加密。
- 10.其他思考
如果访问 config-server 服务,直接访问配置文件发现已经是解密之后的文件了:
这样会不会是不安全的,其实不用担心,我们可以吧 config-server 服务再整合上 Spring Security,这样就不能随便访问这个地址,起到了安全的作用;