没有互联网吗?没有问题。使用x射线与气隙-第二部分
如何在气隙环境中保护软件

与软件供应链攻击在上升,执行DevSecOps在气隙环境中的最佳实践是必须的。为了确保组织内部网络的安全,将内部网络与外部网络分离的趋势越来越明显。本质上是创建一个与公共互联网隔离的封闭环境。
气隙解决方案提供了更严格的安全要求,但这还不够。您的软件开发人员、CI流程和部署管道所使用的第三方依赖关系也必须被扫描,以查找安全漏洞和许可证违规!
如何?结合一个安全漏洞解决方案等JFrog x光,允许您保护您的气隙环境,并排除在内部开发环境中使用的所有易受攻击的工件。
我们的上一篇文章展示了如何使用一些工具和脚本,继续完成这些任务在气隙环境中访问远程依赖项.这篇文章将介绍在开发环境中保护软件和维护严格安全策略的步骤和最佳实践。
示例设置:使用外部DMZ
下面的设置显示了一个使用外部DMZ的示例解决方案,其中安装了JFrog Xray来扫描远程依赖项以查找漏洞。JFrog Xray也安装在内部,为您的软件包提供持续扫描,保护您的组织在未来免受任何潜在的漏洞。

在气隙解决方案中使用x射线的最佳实践
- 内部和DMZ都必须安装Xray。不仅仅是DMZ。这将确保连续扫描对于您的工件,保护它们不受未来可能出现的任何新漏洞的影响,这些漏洞是针对已经“批准”的依赖项的。
- 区分在内部和DMZ中配置的策略和监视;对于DMZ上的依赖项解析,您可能有一个全局策略,但是对于特定的产品/版本,在内部环境上有一个更严格的方法。
- 使用JFrog CLI用最新的漏洞情报更新您的内部x射线数据库,以防您完全处于空档状态。
- 数据库同步必须自动完成,定期(使用调度程序),最好是每天。
- 此外,同步过程(即使是在线的)应该定期监控,以确保它没有被破坏。
- 使用重复的登台环境,允许您在生产中实现气隙流的所有流程之前测试它们。
- DMZ应该由SecOps管理,如有需要,可以忽略特定的违规、打补丁、测试和提升易受攻击的依赖项。
*关于如何轻松机载JFrog x射线>>的最佳实践
实现示例:基于身份气隙环境的存储库管理过程
对于企业公司来说,大型开发团队分布在世界各地,基于身份的解决方案正在成为事实上的标准方法。下一代气隙环境是基于识别关于请求的所有内容。更具体地说,跟踪:
- 内部环境中不可用的外部第三方依赖项的请求者。
- 如果基于公司的政策不允许使用这些依赖项,则批准/不批准这些依赖项。
下图描述了在基于身份的气隙解决方案中选择、组织和下载第三方依赖项的过程。所有这些都在工件管理的上下文中,特别是在高度规范和安全的环境中。

在气隙环境中管理软件二进制文件安全性的过程
步骤解释
- 开发人员Kermit声明了一个新的第三方依赖项,并尝试构建他的项目。
- Kermit收到' 404 Not Found ',这个依赖在内部Artifactory的Curated Repository中不可用。
- Webhook请求被发送给一个“自助服务管理流程”。
- 打开代表此请求的票务#1(通过ServiceNow / Jira或其他票务系统)。
- 请求被发送到外部Artifactory,以便在DMZ Artifactory中下载这个依赖项。
- DMZ从internet提取依赖项。
- x射线扫描依赖关系。
- 漏洞是通过网络钩子报告的。
如果没有创建违例:
- 一号票已售完。
- Kermit得到通知,现在可以从策划库,然后访问打开库它在扫描后有那个依赖项可用。
如果产生了违例:
- Ticket #2被创建,表示限制该依赖项使用的x射线违反。
- Kermit得到通知,现在有一个违规限制了他使用这个依赖项,SecOps将对其进行审查。
- Kermit在Sandbox环境上测试他违反的依赖,以了解他是否可以使用它(也许他的开发不需要这个脆弱的函数?),并向SecOps提供证据,证明它是有效的,应该被批准。
- 科米特在他的测试结果和对依赖性的研究完成后更新了2号票。
- SecOps工程师收到关于2号票的通知。
如果被违反的工件被SecOps批准:
- SecOps批准并发送webhook。
- 依赖项从开放存储库拉到托管存储库。
- 2号票已经卖完了。
如果违反的工件没有被SecOps批准:
- Kermit得到通知,SecOps已经审查并决定不批准使用被违反的依赖项。
使用此解决方案的好处
- 提供必要的审计过程
- 为组织设置基础设施以扩大规模
- 允许轻松地将SecOps团队合并到流程中
- 为开发人员提供了方便,因为该过程是自动的,并且对他们隐藏(他们只需要下载他们的依赖项,其他一切都为他们处理)
请记住,此解决方案需要实现强大的自动化,并需要一个高度敬业的SecOps团队来正确处理进站票据。
