注：上期精彩内容请点击：开源软件的引入安全性；老旧漏洞为何难以修补

 话题一 

最近有消息称研究人员在数百个 Docker 容器镜像中发现了隐藏的漏洞，而这些镜像的总下载量达到了数十亿次。大家认为Docker镜像的安全性如何保证？如何避免恶意镜像的使用？

外来镜像：镜像准入，提前扫描分析完；
本地镜像：用黄金镜像自己打包，持续升级。

先测试环境跑，进去审计，出网策略先加固一波，有后门至少没机会外连。

把容器当主机就可以了，上线前漏扫，加固。

Docker镜像的安全性可以在云的出口部署一个反向代理网关去审核获取资源的安全性。

限制Docker守护进程的访问，只允许授权的用户和服务使用Docker；使用私有仓库可以确保只有授权的用户和服务可以访问镜像；定期审查镜像，确保其中不包含恶意代码或安全漏洞；使用容器镜像扫描工具自动扫描镜像中的漏洞和恶意代码，及时发现并修复问题。

使用官方镜像：这些经过安全审查的相对会比较靠谱；
定期更新镜像：利用Docker Hub或其他镜像仓库提供的自动构建机制来更新；
使用镜像签名：可以利用Docker Content Trust进行镜像签名，验证下载的镜像是否被篡改。
限制容器权限：降低恶意容器对主机的风险，可以通过Docker的cap-drop选项进行限制，或者使用read-only选项来限制容器的写访问；
监控镜像仓库：及时了解镜像更新、漏洞修复等信息，并及时采取措施；

我朋友全部都是在基础镜像上做业务镜像，基本上基础软件全部都做了一遍，Nginx、MySQL、redis 之类的全部做了一遍。

Q：有句话叫“虚拟机已死，容器才是未来”，今年刚好是Docker正式诞生的第十年，目前大家的使用场景如何？和虚拟机相比，目前Docker的安全性是否真的更好？

各有千秋，凡事辨证看待。用了容器，又会有新的安全风险出来，相对检测、修复难度提升，同时，容器本身也有容器崩溃的情况。但是，从易用性、从大小来讲，容器又比虚拟机好太多，二者没有绝对，只有合适与取舍。从容器安全角度来说，新增了容器本身的突破，可以说攻击门槛提高了，但是，镜像本身有可能被投毒，也增加了风险点。

如果从这个角度来说，容器确实安全一点，毕竟门槛在那。

容器是好，但是我们现在有个苦恼就是，为什么同样的规则策略，就传统的漏扫扫描容器，几百上千个高中危级别漏洞，直接没法用了，关键是厂家还不好好配合你弄，动静太大。

以前在内网遇到过Docker的API未授权，生产环境大丰收，一网打尽。

从管理复杂度来说，Docker、K8s对于传统安全来说是个挑战。

成本利用率高了，我这边是纯k8s场景，资源利用率更好控制了，安全性当然也有一些其他挑战，特权容器。

目前，Docker的使用场景已经从早期的单机开发和测试，发展到大规模的云原生应用部署，以及传统企业数据中心的容器化迁移。在企业应用层面，Docker提供了一系列的容器编排工具，如Kubernetes、Mesos等，可以帮助企业快速部署、扩展和管理容器化的应用。

至于安全性，Docker和虚拟机本质上是不同的技术，安全性也存在很大的不同。相比虚拟机，Docker容器更加轻量级，容器之间的隔离性更强，可以更好地保护容器内部应用程序的安全性。此外，Docker提供了一系列安全相关的功能，如容器沙箱、容器限制、容器审计等，可以更好地保护容器的安全性。

我觉得采用容器和k8s之后，安全修复更难了。之前的Rhel/Centos，好歹是10年的EOL，Yum update解烦恼。现在容器里研发责任前置了，他们得有意识的更新版本。容器外面K8s没有lts版，EOL只有一年，我相信没多少人会升级的（除非云厂商逼着升级），那么安全漏洞之类的修复，就更玄学了。

 话题二 

根据等保、金融行业标准（银行、证券），日志至少要存储半年至1年以上，且包括应用日志、系统操作日志、安全设备日志、网络日志等。但是实践过程中有一个问题，类似Redis、Kafka之类的应用日志和操作日志要不要存储呢，运维反馈他们的日志太大，且相关合规标准里面也没有明确。所以请教各位一下你们是有存么？

实际执行看业务重要程序 ，特别重要的要100%，普通业务取 1/3。

那业务重要程序包括redis的和Kafka的话也存？

如果是重要业务日常操作记录要存储，不限于存储位置 （这个完全取决于自己，像以前我们那种埋点日志都是取1/3 ，因为量太大了）。

要存的，你可以存日志索引加一些关键信息，如果有附件文件可以不存附件。

我觉得主要存负载均衡器上的Access日志和数据库的日志，而且存的时间要久一些，其他的真没必要了。除非每一条请求都有Traceid可以从头追溯到尾，无法追溯的部分，存日志就是骗自己了。

这个不是需要选择，应用你要是把Debug打开，所有服务不出一天滚动日志就爆了。把重要的信息操作，访问，重要操作打印，然后汇聚到日志服务器归档。

 话题三 

大家有用云桌面控制开发的安全吗？大量的互联网更新需求怎么解决？搞代理？

云桌面不适用频繁迭代场景。

我就好奇，成熟的云桌面开发场景是咋样的。

堡垒机后面的虚拟跳板机，虚拟跳板机再加个域，这想要啥安全？

控制都可以实现拉，问题是外网访问的需求，压不住。比如开发环境，都会去互联网下开发依赖包，这没法禁。

怎么压不住？建个本地仓库。

这怎么压？有可能会有乱七八糟的一堆，Npm、Yarn、Vscode这些外网的官网地址，这些能搞本地库？还有能搞本地库，这个库谁来维护呢？

云桌面肯定不能乱装东西。所以我觉得现在的云桌面走偏了。为了满足上线率，强行给自己挖坑，这样就不可能搞定安全。

库肯定要建，你放Git，不考虑代码泄漏么？情报部门在Git上一搜，发现源码了，顺便再曝几个接口Key，就直接凉凉。

我们部署了，苹果不能上架，很多型号不能消息通知，后端自带一个云枢SDP ，全加密，你后台什么也看不到，只能看到几十万连接。外边代理过来的攻击，查不了源。

这个问题，我觉得可以采用敏捷开发方法，以小批量迭代的方式进行开发，可以更快地响应变化和更新。此外采用持续集成和持续交付的方式，可以实现快速迭代和更新，同时确保系统稳定和安全。

 话题四 

公司使用SaaS服务上线了人事平台，云服务提供商已过了等保三级，还需要额外对人事平台做等保定级备案吗？

基础架构和网络架构是三级，但是你的系统不是，还要另外做。

SaaS如果是人家的平台，等保你不需要，你们选择的时候做好资质评估、包括持证，组织架构、数据保护方案等，如果能提供你们SoC2的外部审计报告最好；如果是自己的SaaS平台，那就需要，但不需要三级，因为对内系统人员数量到不了三级这级别，除非对外部服务。

等保和定级备案是两个东西，一个公安，一个工信部。

备案是为了能使用WEB服务，包括域名解析等。人家的服务平台不需要，自己建平台必须。

看这个应该不是自己建的，云服务商、定级和备案还是有区别的，平台只是基础和网络架构，你系统如果还需要做等保备案还是需要额外做的。

FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：

金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监