简体   繁体   English

使用maven central解决依赖关系(企业网络内部)是否安全?

[英]Is it safe to use maven central to resolve dependencies (inside a corporate network)?

I'm currently having some problems at work, where the BitDefender antivirus suite that is deployed on everyone's computers is blocking access to Maven Central. 我目前在工作中遇到一些问题,在每个人的计算机上部署的BitDefender防病毒套件阻止了对Maven Central的访问。

Firstly, we are not a software shop, there are only really 2 people in the company that need to access jars from Maven Central, so the problems we come up against are not really common to the whole company. 首先,我们不是软件商店,公司中只有2个人需要从Maven Central获取罐子,所以我们遇到的问题对整个公司来说并不常见。

I have spoken with the IT Manager, and whilst he did not want to allow jars to be accessed from just any location on the internet, he did add an exception to the BitDefender policies to allow jars from Maven Central to be accessed and downloaded (our build tool is Gradle by the way). 我曾与IT经理谈过,虽然他不想允许从互联网上的任何位置访问罐子,但他确实在BitDefender政策中添加了一个例外,允许访问和下载来自Maven Central的罐子(我们的构建工具顺便说一下Gradle)。 All okay, apart from there are still some jars which we cannot successfully access from Maven Central. 一切都还好,除了还有一些我们无法从Maven Central成功访问的罐子。

I get the impression that he is leaning towards having to specifically add new exceptions to the BitDefender policies for any new jars we are having troubles with, commenting that "By way of information, we will probably need to continue to tweak and tune these settings given the inherently dubious nature of the way these code updates and packages use the HTTP protocol." 我得到的印象是,他倾向于必须为我们遇到麻烦的任何新罐子专门为BitDefender政策添加新的例外,评论说“通过信息,我们可能需要继续调整和调整这些设置给定这些代码更新和包使用HTTP协议的方式本质上是可疑的。“

Now, my thoughts are that there clearly must be safe and secure means of accessing any required jars, at the very least any jars from Maven Central. 现在,我的想法是,至少必须有安全可靠的方式来访问任何所需的罐子,至少来自Maven Central的任何罐子。 Surely this is how major software shops work, right? 当然这是主要软件商店的工作方式,对吧? These industry standard build tools surely do not make 'inherently dubious use of the HTTP protocol', right? 这些行业标准构建工具肯定不会“固有地使用HTTP协议”,对吧?

So, my question is how do software shops and the like approach the issue of network security, whilst still enabling their developers to access the jars they require to do their jobs? 所以,我的问题是软件商店等如何处理网络安全问题,同时仍然允许他们的开发人员访问他们完成工作所需的罐子? Is there any useful information I could look to that address' the security aspect of accessing jars from remote repositories such as Maven Central via build tools? 是否有任何有用的信息可以通过构建工具来解决从远程存储库(如Maven Central)访问jar的安全问题? Anything I could go back to the IT Manager with to argue the case of how/why we should have less restricted access? 我可以回到IT经理那里讨论如何/为什么我们应该减少限制访问的情况?

All help/comments is much appreciated! 所有帮助/评论非常感谢!

Here's what we do at my company, and I work for a very large company where security is intense. 这就是我们在公司所做的工作,我在一家安全性很强的大公司工作。

We CANNOT link to the maven central repository, BUT there is a whole team dedicated to ensuring that any and all possible software tools are available via an "in-house" repository in our network. 我们无法链接到maven中央存储库,但是有一个团队致力于确保通过我们网络中的“内部”存储库提供任何和所有可能的软件工具。

If there is a technology I need for my project, I check if it is in the in-house repo. 如果我的项目需要一项技术,我会检查它是否在内部回购中。 If not, I can request that it is included. 如果没有,我可以要求包含它。

Based on the info you provided that you do not have a big software department, I would recommend doing something similar to what we are doing here in setting up a repo within the company network with whatever technologies you currently need. 根据您提供的信息,您没有大型软件部门,我建议您在公司网络中使用您目前需要的任何技术设置回购,这与我们在此做的类似。 This is also nice because you can add technologies as needed as the years progress and your software team grows (possibly). 这也很好,因为您可以根据需要随着年份的进展添加技术,并且您的软件团队可能会增长(可能)。

I hope I have provided some insight/ideas. 我希望我提供了一些见解/想法。

These industry standard build tools surely do not make 'inherently dubious use of the HTTP protocol', right?

I would be really really surprised if any of these tools (specially Maven) does anything dubious. 如果任何这些工具(特别是Maven)做任何可疑的事情,我真的会感到非常惊讶。 The code is open, out there and I am sure people would have already figured out if it was doing anything malicious. 代码是开放的,在那里,我相信人们已经知道它是否做了任何恶意的事情。

Talking specifically about Maven Central, all the jars deployed in Maven Central need to be signed with a GPG key. 特别谈到Maven Central,Maven Central中部署的所有罐子都需要用GPG密钥签名。 Also the files are secured with an SHA checksum to ensure they are not modified. 此外,文件还使用SHA校验和进行保护,以确保它们不会被修改。 You can read a detailed Readme for process of deploying jars to maven central here which lists all the mandatory requirements for deploying jars to Maven Central. 您可以在此处阅读详细的自述文件,了解将jar部署到maven central的过程,其中列出了将jar部署到Maven Central的所有必需要求。

https://docs.sonatype.org/display/Repository/Central+Sync+Requirements https://docs.sonatype.org/display/Repository/Central+Sync+Requirements

A Repository Manager will always help you as you ensure that the files are downloaded only one time, and then served locally. Repository Manager将始终帮助您,确保文件只下载一次,然后在本地提供。 So you only need to hit the Maven Central in case you add a dependency which is missing in the local repository. 因此,只需添加本地存储库中缺少的依赖项,您只需要访问Maven Central。 A commercial version of Nexus repository manager has ability to verify the jar against its signature to ensure that it was not modified. 商业版的Nexus存储库管理器能够根据其签名验证jar,以确保它未被修改。

I think its safe to access Maven Central, as there are adequate security measures being employed to ensure integrity of data. 我认为可以安全地访问Maven Central,因为采用了足够的安全措施来确保数据的完整性。

Please note though that if you happen to access any other Third Party repositories, it may not necessarily be safe to do that. 请注意,如果您碰巧访问任何其他第三方存储库,则可能不一定安全。

All in all I am sure its about getting those jar files downloaded. 总而言之,我确信它是关于下载这些jar文件的。 Even if you are not using Maven, you will have to download them from somewhere also ensuring you pull down all the transitive dependencies manually and ensure integrity by manual verification of checksum. 即使您没有使用Maven,也必须从某个地方下载它们,同时确保手动下载所有传递依赖项并通过手动验证校验和来确保完整性。 Maven is simply automating the whole process for you. Maven只是为您自动完成整个过程。 In addition to that, it centralizes all of these libraries and serves it through a single server, unlike when you download them manually from various servers. 除此之外,它集中了所有这些库并通过单个服务器提供服务,这与从各种服务器手动下载它们不同。

Its always a difficult situation when security considerations clash with development needs. 当安全考虑因素与发展需求相冲突时,它始终是一个困难的局面 In one of the former companies I worked with we solved the Maven repository issue by using a repository manager which had the necessary permissions to fetch the jars from the external repositories. 在我曾与之合作的一家公司中,我们使用存储库管理器解决了Maven存储库问题,该管理器具有从外部存储库获取jar的必要权限。 I highly recommend such a tool because it also reduces the dependency on the external repo. 我强烈推荐这样的工具,因为它还减少了对外部仓库的依赖。 You can still build your SW even if the external repo is not reachable at the moment. 即使目前无法访问外部存储库,您仍然可以构建SW。

Of course, there is still the possibility to abuse it. 当然,仍有可能滥用它。 This is something you can only overcome by building up mutual trust between the involved groups. 这是您只能通过在相关群体之间建立相互信任来克服的。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM