常见的设置

包含模式:org/apache/**，com/acme/**排除模式:com/acme/exp-project/**

使用排除模式避免安全风险

本节解释如何使用排除模式来避免以下安全风险。

使用排除模式防止内部构件的暴露

您部署到Artifactory的任何专有构件都存储在本地存储库中，以便它们可以用于安全的和授权的内部使用。

任何通过名称搜索内部工件的人都将通过Artifactory从本地存储库中提取它。

但是，考虑一下，如果对内部工件的请求被不经意地指向，会发生什么外组织的。

关于这种情况的两个例子是:

• 在请求的工件名称中有一个简单的拼写错误
• 开发人员请求一个版本号不存在的快照。

在这种情况下，由于Artifactory没有在本地存储库中找到所请求的工件，它将继续搜索系统中定义的远程存储库。事实上，Artifactory会搜索所有在返回“Not found”之前，在系统中定义的远程存储库。

这带来了安全风险，因为对远程存储库发出的任何请求都可能被记录下来公开查询的所有细节，包括可能包含敏感业务信息的完整工件名称．

使用排除模式防止暴露内部包

代理不受信任的公共远程存储库或受到损害的存储库可能会使您暴露于恶意构件。有时，这些存储库允许任何人部署自定义包。例如，对于npm，公共存储库为npmjs，任何人都可以部署他/她拥有的任何包的任何版本。如果一个包没有所有者(以前没有人部署过它的某个版本)，任何人都可以部署它并认领它。

例如，让我们假设您有一个名为“almo-common-utils”它的源代码是公共可访问的，例如，如果它被绑定为公共可访问的产品或web应用程序的一部分，它是在Node和JFrog Artifactory中编写的，它有一组远程(代理公共存储库)，本地(用于内部共享模块)hth华体会最新官方网站和虚拟存储库。

考虑以下几点:

• 在公共存储库中，任何人都可以发布一个非作用域库，并将其命名为任何他们想要的名称。almo-common-utils”(除非名称冲突)。
• 没有名为"almo-common-utils＂在公共存储库中(因为它是一个内部公司库)，因此不存在名称冲突。
• 您有项目声明依赖在“almo-common-utils“使用版本范围。例如，指定与主要版本兼容的最新版本的范围。

这就带来了安全风险，因为攻击者可以通过预先了解库来攻击未受保护的组织。”almo-common-utils \”，正在使用的库的主要版本(假设他们知道版本3在组织中广泛使用)，以及源代码的内容。

攻击者可以克隆和修改源代码，在其中嵌入任何恶意软件，但仍然保持与原始代码的兼容性，并将其上传到存储库作为“almo-common-utils: 3.99.99”．这将创建一个内部库的版本更新劫持，当“almo-common-utils: ^ 3.0.0“是要求的，是假的”almo-common-utils从存储库中获取。

为了避免暴露内部包和内部包版本劫持，我们强烈建议采用以下方法：

• 在远程存储库上使用排除模式。在远程存储库中排除您不想在组织之外搜索的包。您可以通过前缀(来排除。.npm / almo * / * *)，按范围(.npm / @almo / *)或按姓名(.npm / almo-encoder / * *)．通过在任何公共远程存储库上设置这些排除模式，您实际上不会从公共存储库合并这些包。
• 只创建和发布有作用域的包。在公共存储库中为您的公司注册一个官方组织，以拥有您的组织的范围，并且始终只发布有范围的包。这也简化了排除模式，因为您只需要排除作用域包在远程存储库中排除正在搜索的所有包。
  
  下面是一个阻塞包的示例范围"almo”从远程存储库。
  

使用Include模式避免性能问题

在典型场景中，Artifactory将引用大型通用存储库，例如JCenter或者Maven Central来解析工件。

此外，Artifactory可以引用任意数量的附加存储库，这些存储库可以承载更专门化和特定的工件集。

如果Artifactory接收到对一组确定的工件(例如，工件的特定版本)的请求，那么它将根据其解析顺序在不同的存储库中搜索，直到找到该工件。

然而，如果Artifactory接收到对一组不确定工件的请求(例如，的所有版本maven-metadata.xml)然后它必须搜索所有直到它能够提供完整的响应为止。

在大多数情况下，组织下载的大部分工件将来自一个大型的通用存储库，但是是在不确定的请求中性能下降，因为Artifactory继续搜索所有专门的存储库才能返回响应．

本地和远程存储库

除了上述设置外，本地和远程存储库还在特定于类型的部分中为相关包类型共享以下设置。