在我们面向公众的网络服务器上,我们有一个网站管理区域,可以访问:
http://www.ourapplication.com/admin
管理区域具有基本的CRUD功能,我们已将其内置到我们的Java EE应用程序中,但我们希望将此管理区域分隔到防火墙后面的其他服务器,以便只能从我们的内部网络访问它。
实现这一目标的最佳策略是什么?
答案 0 :(得分:2)
创建两个单独的Web应用程序。
没有理由通过在公共站点中使用管理代码来暴露潜在的安全漏洞,并且没有理由在内部/管理应用程序中包含所有公共功能。
答案 1 :(得分:1)
您不能选择性地从不同的服务器提供相同应用程序的部分,这是一件好事。
为管理区域创建单独的应用程序,并根据需要随时提供。 如果您确实需要或希望面向公众的Web应用程序能够访问此内容,您可以创建链接。
答案 2 :(得分:1)
在面向公众的Web服务器上,我们有一个管理区域 网站,并访问 http://www.ourapplication.com/admin
通过公共网络公开管理设施是一个真正的安全漏洞
在完成所有配置和部署后,您是否真的需要在生产中运行?如果没有则将其删除。例如。在Tomcat中建议删除manager
应用。
如果您确实需要它,请过滤访问IP
您没有提到您使用的服务器,但在Tomcat中您可以使用Valve
,或者通常可以使用Filter
这样,只有本地IP和属于您的专用网络的IP才能访问它
答案 3 :(得分:1)
您可以创建一个真正是2个独立应用程序容器的Web应用程序。例如,当我使用ant和struts时,在部署面向公众的站点时,我甚至不会在面向公众的站点中编译example.actions.admin
或example.admin.*
,尽管我选择了我想要编译和共享的模型有这个程序。我还设置了我的属性文件以连接到不同的数据库等。
然后,部署在内部网络上的管理员应用程序也排除了公共行为。我的设置是特定于Struts的,但我认为您可以将应用程序的不同部分部署到不同的服务器,同时仍然使用相同共享代码库的部件。
实际上我甚至有一个应用程序,它有第三个应用程序,它是我们从管理应用程序启动的Java Webstart应用程序。它还与管理员应用程序共享相同的模型。
从代码组织的角度来看,这是一个Java应用程序。但是从应用程序的角度来看,这些实际上是3个独立的应用程序。
现在只是因为你可以做某事......这并不意味着应该。
在我的场景中,我们在面向公众的站点中拥有的非常有限的类子集实际上是我们构建它所需要的。但是,如果没有这种谨慎,这个技巧可能会转过来并伤害你。