急急急！java项目如何加密的问题

[一米阳光zw]

求助各路大神帮忙给一些意见，哪怕是无法实现也希望说说实现不了的理由，感激不尽。
需求：在局域网的环境下将项目部署到用户的服务器上，数据库和项目全部安装在用户服务器上，要求用户不能随意访问数据库里面的资源，但是项目内可以任意访问数据。他说如果无法实现加密也可以也一个脚本什么的在每次查询数据库时检测脚本是否存在也行，但是现在mybaties框架自动查询数据，他说的那种加密不就是自己骗自己吗？
最近CTO向我提了该需求，我也是欲哭无泪。其实项目刚启动的时候就讨论了这个问题，他的回答是使用加密狗加密，当时他说行我也没多想，最近随着对这个加密狗的深入了解发现这东西只能加密单机软件，Java语言的spring框架软件无法加密。现在再问他这个问题他只说，我不管，你帮我搞定他！第一次提问，还望各位大佬不吝赐教

[weixin_40290083]

1、任何用户只要通接触到服务器，那么就能够访问到数据库,当然前提是知道用户名和密码。即使是远程连接也可以（如linux下的SSH，windows的远程桌面），尽管这两种访问是远程连接，但是相当于本地操作服务器。也就意味着不可能绝对达到不能访问数据库。 2、CTO所说的加密是在数据传输上的加密还要数据库中数据的加密。无论哪一种加密都可以的service层或者action中对数据进行加解密。无非就是在持久化之前把数据加密，以密文的方式存放到数据库中，这样别人通过非法手段访问到数据库也是加密的数据。或者就是查询到后对数据进行加密，这样在网上传输时数据是加密的。如果使用的是web方式也就意味者解密要通过js进行解密。无论是哪一种方法加解密就要耗费更多的时间和服务器资源、存储资源。 3、使用防火墙，定义严格的策略，只允许客户机访问应用程序的端口（如HTTP的80端口）。甚至可以将数据库服务和应用服务分开在不同的服务器上，在防火墙上定义只允许应用服务访问数据库对应的端口，其它的任何IP不允许访问任何端口。定义客户机允许访问应用服务的应用端口，其它不允许访问。 总而言之，如果能接触到服务器，那么服务器上的数据就是不安全的。这个属于物理防护和公司的安全管理了。即使是数据加密了也有被破解的可能。

[cwmlow]

你的意思项目外不可以随意访问数据是指什么？（比如工具直连数据库这种？） 那看来加解密数据库连接配置文件是不行了，因为连接数据库的前提是得知道用户名和密码。照你这描述对其下功夫并没什么实际意义，因为用户还是会知道用户名和密码。 那只能从数据加密下功夫了。数据库里存的数据都是经过加密方法的数据。这样用户直接访问数据库看到的也是一堆密文形式的数据。 在项目内访问数据必须经过你服务端的解密方法返回明文数据。 当然 加密方法和解密方法都得存在你服务端，客户端想要获得正常数据只能经过服务端。 不知我是否理解了楼主的意思？？

[一米阳光zw]

引用 1 楼 weixin_40290083 的回复:

1、任何用户只要通接触到服务器，那么就能够访问到数据库,当然前提是知道用户名和密码。即使是远程连接也可以（如linux下的SSH，windows的远程桌面），尽管这两种访问是远程连接，但是相当于本地操作服务器。也就意味着不可能绝对达到不能访问数据库。
2、CTO所说的加密是在数据传输上的加密还要数据库中数据的加密。无论哪一种加密都可以的service层或者action中对数据进行加解密。无非就是在持久化之前把数据加密，以密文的方式存放到数据库中，这样别人通过非法手段访问到数据库也是加密的数据。或者就是查询到后对数据进行加密，这样在网上传输时数据是加密的。如果使用的是web方式也就意味者解密要通过js进行解密。无论是哪一种方法加解密就要耗费更多的时间和服务器资源、存储资源。
3、使用防火墙，定义严格的策略，只允许客户机访问应用程序的端口（如HTTP的80端口）。甚至可以将数据库服务和应用服务分开在不同的服务器上，在防火墙上定义只允许应用服务访问数据库对应的端口，其它的任何IP不允许访问任何端口。定义客户机允许访问应用服务的应用端口，其它不允许访问。

总而言之，如果能接触到服务器，那么服务器上的数据就是不安全的。这个属于物理防护和公司的安全管理了。即使是数据加密了也有被破解的可能。

首先感谢回答问题。加解密确实是需要消耗更多的资源，如果能达到目的但这也是没有办法的事情，毕竟需求是最重要的，先达到目的再来考虑效率优化的问题；第三点将数据库服务器和应用服务器分开的话还是治标不治本，因为CTO并没有打算将我们重要资源放在我们这里管理的意思，他只想一次性全部卖出去，也以为服务器不需要维护，启动后能用几十年。我们安装的时候可以制定策略，他们后期自己还是可以修改的，jar文件在他那边相当于他可以直接看到我的代码，再严谨的加密他也可以模仿，似乎行不通

[一米阳光zw]

引用 2 楼 cwmlow 的回复:

你的意思项目外不可以随意访问数据是指什么？（比如工具直连数据库这种？）
那看来加解密数据库连接配置文件是不行了，因为连接数据库的前提是得知道用户名和密码。照你这描述对其下功夫并没什么实际意义，因为用户还是会知道用户名和密码。
那只能从数据加密下功夫了。数据库里存的数据都是经过加密方法的数据。这样用户直接访问数据库看到的也是一堆密文形式的数据。
在项目内访问数据必须经过你服务端的解密方法返回明文数据。
当然 加密方法和解密方法都得存在你服务端，客户端想要获得正常数据只能经过服务端。
不知我是否理解了楼主的意思？？

感谢作答。
是的，可以这么理解，目的就是只能通过项目访问数据库

[cwmlow]

引用 3 楼 zw一米阳光 的回复:

[quote=引用 1 楼 weixin_40290083 的回复:] 1、任何用户只要通接触到服务器，那么就能够访问到数据库,当然前提是知道用户名和密码。即使是远程连接也可以（如linux下的SSH，windows的远程桌面），尽管这两种访问是远程连接，但是相当于本地操作服务器。也就意味着不可能绝对达到不能访问数据库。 2、CTO所说的加密是在数据传输上的加密还要数据库中数据的加密。无论哪一种加密都可以的service层或者action中对数据进行加解密。无非就是在持久化之前把数据加密，以密文的方式存放到数据库中，这样别人通过非法手段访问到数据库也是加密的数据。或者就是查询到后对数据进行加密，这样在网上传输时数据是加密的。如果使用的是web方式也就意味者解密要通过js进行解密。无论是哪一种方法加解密就要耗费更多的时间和服务器资源、存储资源。 3、使用防火墙，定义严格的策略，只允许客户机访问应用程序的端口（如HTTP的80端口）。甚至可以将数据库服务和应用服务分开在不同的服务器上，在防火墙上定义只允许应用服务访问数据库对应的端口，其它的任何IP不允许访问任何端口。定义客户机允许访问应用服务的应用端口，其它不允许访问。 总而言之，如果能接触到服务器，那么服务器上的数据就是不安全的。这个属于物理防护和公司的安全管理了。即使是数据加密了也有被破解的可能。

首先感谢回答问题。加解密确实是需要消耗更多的资源，如果能达到目的但这也是没有办法的事情，毕竟需求是最重要的，先达到目的再来考虑效率优化的问题；第三点将数据库服务器和应用服务器分开的话还是治标不治本，因为CTO并没有打算将我们重要资源放在我们这里管理的意思，他只想一次性全部卖出去，也以为服务器不需要维护，启动后能用几十年。我们安装的时候可以制定策略，他们后期自己还是可以修改的，jar文件在他那边相当于他可以直接看到我的代码，再严谨的加密他也可以模仿，似乎行不通 [/quote] 不理解你们的想法，既然项目整个打包给卖给甲方。你所说维护以及后续二次开发都由甲方接手来做，那为何还提出这个奇怪的需求。。

[一米阳光zw]

引用 5 楼 cwmlow 的回复:

[quote=引用 3 楼 zw一米阳光 的回复:]
[quote=引用 1 楼 weixin_40290083 的回复:]
1、任何用户只要通接触到服务器，那么就能够访问到数据库,当然前提是知道用户名和密码。即使是远程连接也可以（如linux下的SSH，windows的远程桌面），尽管这两种访问是远程连接，但是相当于本地操作服务器。也就意味着不可能绝对达到不能访问数据库。
2、CTO所说的加密是在数据传输上的加密还要数据库中数据的加密。无论哪一种加密都可以的service层或者action中对数据进行加解密。无非就是在持久化之前把数据加密，以密文的方式存放到数据库中，这样别人通过非法手段访问到数据库也是加密的数据。或者就是查询到后对数据进行加密，这样在网上传输时数据是加密的。如果使用的是web方式也就意味者解密要通过js进行解密。无论是哪一种方法加解密就要耗费更多的时间和服务器资源、存储资源。
3、使用防火墙，定义严格的策略，只允许客户机访问应用程序的端口（如HTTP的80端口）。甚至可以将数据库服务和应用服务分开在不同的服务器上，在防火墙上定义只允许应用服务访问数据库对应的端口，其它的任何IP不允许访问任何端口。定义客户机允许访问应用服务的应用端口，其它不允许访问。

总而言之，如果能接触到服务器，那么服务器上的数据就是不安全的。这个属于物理防护和公司的安全管理了。即使是数据加密了也有被破解的可能。

首先感谢回答问题。加解密确实是需要消耗更多的资源，如果能达到目的但这也是没有办法的事情，毕竟需求是最重要的，先达到目的再来考虑效率优化的问题；第三点将数据库服务器和应用服务器分开的话还是治标不治本，因为CTO并没有打算将我们重要资源放在我们这里管理的意思，他只想一次性全部卖出去，也以为服务器不需要维护，启动后能用几十年。我们安装的时候可以制定策略，他们后期自己还是可以修改的，jar文件在他那边相当于他可以直接看到我的代码，再严谨的加密他也可以模仿，似乎行不通
[/quote]
不理解你们的想法，既然项目整个打包给卖给甲方。你所说维护以及后续二次开发都由甲方接手来做，那为何还提出这个奇怪的需求。。[/quote]
只是想看下网有是否有什么好的建议