基于安全审计思维规划缓解内网自建软件仓库的风险
好久没写关于基础设施建设运维的内容。前不久提到了基础设施迁移，有些很基础的事情确实值得重温一下，比如在内网自建软件仓库。
笔者：国际认证信息系统审计师、软考系统分析师
自建软件仓库是称职的网管都会做的事，但目的、方式各有不同。
时过境迁，现在凡事必先从网络安全审计角度，基于风险因素和防范措施，确定要先预备好如何做，而不是简单地直接做。
我把软件仓库的内容分为三种情况：操作系统的组件和更新、开源软件的版本发布、其他软件。
操作系统的组件和更新，典型如通过 Microsoft 的 WSUS （Windows Server Update Service）建立的微软产品补丁仓库，或者 Linux 发行版的 Yum/Apt Repo 仓库。
开源软件的版本发布，之所以单独列出，是因为在发行版之外，开源软件大多有其独立的版本发布机制，发布的方式也不一样：有些提供了完整的源代码及预编译软件包的 Yum/Apt 仓库，有些使用git或web下载方式发布源码及预编译的软件包，而有些仅简单地提供源码打包压缩文件下载。
其它软件不限于开源或闭源，但从版权角度只应包括免费授权、符合分发要求的软件。获得途径一般都是HTTP/HTTPS下载，极少部分还包括FTP下载。
内网部署软件仓库的必要性有很多种角度，比如从对业务运行、工作效率的促进作用去判断。但最核心的是按照信息安全CIA三要素即机密性、完整性和可用性去衡量。
机密性：使用者从内网软件仓库获得软件的过程应比从互联网直接获得软件的过程要安全。较关键的是比如不应能连接到公网的服务器可通过内网仓库获得更新。
完整性：也可理解为可靠性，即对于使用者，软件仓库内的软件是完整和可靠的，可以放心使用。
可用性：需要使用的软件可以随时和方便地获得。同时，由于避免了使用者重复下载同样的软件而耗费出口带宽或造成拥堵，还能提高网络整体的可用性。
也有些不必要的理由。比如内网只有一两台Windows服务器或者Linux服务器，这就没必要搞操作系统的仓库了，让服务器自己通过公网的可靠源头获取更新即可。又如终端电脑严格控制了用户不能自行安装使用未授权软件（使用终端控制软件、域控或者就是白名单），那么也没必要实现面向用户的软件仓库，搞好属于网络运维管理人员的自留地就行。
软件仓库的风险因素，来自于其存储的软件的获得方式、存储方式和使用方式，三种软件类型所产生的风险因素大致是相同的。
对风险因素的评估包括降低了什么风险和增加了什么风险两方面。
降低风险是比较明显的，就如在必要性分析中指出的，机密性提高了就降低了获取过程中引入其它恶意软件或获取过程被恶意利用的风险；完整性提高了就降低了获取的软件被篡改的风险；可用性提高了就降低了影响业务运行的风险，比如提高了业务运行效率，降低了带宽占用的情况等。
以上种种不一而足。但关键在于，要评估清楚增加了的风险，以及实施缓解新增风险的措施，这才是按网络安全审计的方式做好网络安全具体工作的思路。
把信息安全三项基本因素应用到软件仓库本身工作的三个主要步骤：获取、存储和提供，结合信息化的物理环境，就可以分解得到新增的风险因素以及风险因素对软件仓库内容的影响。大致如下：
机密性风险：上游来源是否可信，是否提供加密下载，本地下载服务环境是否已纳入安全管理。
完整性风险：上游来源会否被植入恶意软件，是否会因为下载不完整而依赖缺失导致打补丁失败，又或者下载不完整而导致补丁不完整而无法使用。
可用性风险：上游来源是否单一无冗余，补丁下载到本地是否及时，本地服务的物理运行环境和硬件是否可靠，存储容量是否充足，CPU资源是否满足使用要求。
注意：如果软件仓库的信息安全三因素被破坏，则软件仓库中全部软件的三因素也同时被破坏。而如果在软件仓库的运行中产生了风险，则风险会因软件仓库的使用而放大到整个内网。
要防范于未然，不先设计好缓解风险的控制措施，就不应该开展建设。读者还记得《网络安全法》第三十三条中的“三同步”要求吗？
对于在上一条发掘的风险因素，可以从整体环境以及服务的获取、存储和提供三个阶段设计如下缓解对策：
1、整体环境：纳入安全管理，执行安全加固和日常安全运维，网络安全的老司机都清楚，自不待言。
2、获取：获取是最大的风险源，机密性、完整性和可用性均产生影响，具体分解后可以有如下缓解措施，具体措施应对何种风险可以自行对号入座。
（1）获取途径
对于微软 WSUS，获取途径可靠性较高。对于开源软件，要落实主备多个来源，来源应明确位于软件官方或官方声称的镜像名单上，并通过订阅邮件列表等方式跟踪关注其变更（插一句：信息收集能力对于网络安全工作非常重要）。其它软件应确保仅从官方网站下载，除非有能力自行分析，什么反编译，反混淆，静态分析，沙盒动态分析等等。
（2）版本控制
这里指的不是软件本身的散发采取了GIT之类的版本控制系统，而是对于下载获得的软件要一律纳入版本控制管理，也即软件仓库本身同时是版本控制的仓库。
而且，还要考虑每一种软件过往的版本是被版本控制隐藏还是和现行版本一起可以被用户选择下载。这个策略一般应用在基础软件，方便选择不同的版本进行测试使用。
版本控制的目的是防备需要回滚更新或溯源更新。但并不容易实现，需要网管员熟悉版本管理软件并仔细建立存储目录结构，而且还会增加存储数据量。
相信绝大部分网管员没有实践过回滚更新和溯源更新，但从笔者的实践经验来看，这绝对是有必要的。尤其是基础软件的BUG，完全符合墨菲法则。
（3）计划编排
设定合适的时间间隔获取软件更新。不像WSUS这种集中式的软件更新发布体系的，一般都需要自行编写脚本获取更新。运行间隔一般1天一次，但对于零日漏洞比较频繁发生的软件，设置为8小时一次也是合适的。
另外要注意，需要允许网络管理员在需要应急获取更新时登录到软件仓库服务器手工进行同步，操作过程应在堡垒机的监控之下。
（4）出口带宽控制
出口带宽控制是较大规模内网必须考虑的。尤其是在软件仓库建立起步阶段，下载的数据量多以TB级计算，要合理安排带宽，当出口闲时充分利用，而忙时要主动避让。
（5）验证
验证下载的软件的方式首推恶意软件检测。恶意软件检测应包括下载后实时进行和定期更新特征库后的扫描，必要时就扔到 virustotal.com 走一转。
其次是看软件的数字签名（代码证书）。虽然证书私钥泄露的事件也经常发生，甚至像太阳风那种供应链攻击导致数字签名完全失去其意义。但如果连数字签名都有问题，这软件包就必然有问题。
验证过程可以编写脚本调用OpenSSL遍历软件包进行检查，这个不详细说了。
3、存储：属于可用性的风险，所以缓解措施均为提高可用性。
（1）提供软件仓库服务的服务器应专用而不要混合提供其它服务。
（2）使用本机存储时，需要预估足够空间并单独分区，避免爆满影响服务器运行。
（3）使用网络存储时，除需要预估空间单独分区之外，还要考虑网络存储重启期间不可用，不能同时发生软件仓库的获取过程。具体地，要在获取软件的脚本中加以判断网络存储是否可用和当不可用时的应对机制，比如押后运行。
（4）鉴于软件仓库数据量不少，备份需要明确地设定策略，比如资源充足时全面备份，资源严重不足时只备份服务运行环境而不备份仓库内的软件。
4、提供：主要涉及机密性和可用性。
（1）安全加固
下载服务自身的安全加固是否到位。比如WSUS服务是基于IIS的，是否已经完成了从操作系统到IIS的安全加固设置。如果是Linux服务器，则是从操作系统到Apache Httpd或者Nginx的安全加固设置。
具体一点，启用文件列表模块，直接提供仓库下载即可。大部分扩展模块都禁用掉，最好避免提供用户交互功能，也就是避免使用任何网页脚本语言和建立CGI。
（2）在需要时，设置高可用性架构，避免客户端集中时间获取打补丁时拖死。
（3）带宽控制，需要对远程接入用户进行带宽限制或者访问限制，避免堵塞出口。
（4）BYOD用户，需要明确BYOD管理政策，设置必要的限制，比如不允许BYOD用户自行从软件仓库中下载安装那些授权仅提供给企业组织自有设备的软件。
最后是一些和风险缓解无关的软件仓库建设配置和使用要点，读者可以自行搜索更具体的教程，此处仅做概括介绍。
1、基于Windows Server的实现
涉及知识点：Windows、IIS、WSUS（必然包括SQL Server Management Studio）、计划任务、PowerShell、Git、SVN等。
（1）微软产品：通过WSUS服务获取产品补丁，内网其他服务器和终端通过组策略设置从WSUS服务器获取补丁。
（2）非微软产品：由于使用到IIS，而WSUS不运行在80和443端口，所以可以使用IIS实现除微软产品外的软件仓库下载服务。软件的获取可以通过编写PowerShell脚本通过计划任务运行，辅助以Git、SVN、OpenSSL等进行版本控制和校验。
2、基于Linux等开源操作系统发行版的实现
涉及知识点：Linux、Yum(Dnf)/Apt、Apache Httpd 或者 Nginx、Cron、Bash Script、Git、SVN、OpenSSL等。
（1）基于软件包管理器：具备专门的 Yum 或者 Apt 软件源时，通过 yum reposync 方式获取仓库内容。
（2）其他可能得获取方式取决于来源提供。可能的情况包括有 rsync、http/https 下载、git/svn 等版本管理软件下载等。
对于 Linux 系统安装软件或应用补丁，最佳做法是使用 yum cron 自动下载，完成下载后管理员就可以收到服务器邮件通知，择机执行更新。服务器发邮件通知给管理员的设置过程前不久刚刚写过，在这里：
至于补丁或软件的部署前测试这些必要的程序就不赘述了，各种网络安全管理体系框架里面都已经有要求。
本文主要关注的是网络安全风险和缓解、控制措施。在网络安全管理中，需要正确辨识出具体风险点，并考虑实施缓解措施。
笔者平时看不少这方面的理论文章，大多数都欠缺了理论联系实际的内容。也就是说，写那些理论文章的人，都没自己动过手。
本页网址二维码：