各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 208期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

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

话题抢先看

1. 如何保证Docker镜像安全性，并避免恶意镜像的使用？

2. “虚拟机已死，容器才是未来”，虚拟机相比，目前Docker的安全性是否真的更好？

3. 类似Redis、Kafka之类的应用日志和操作日志，相关合规标准里面没有明确，最终是否需要存储？

4. 云桌面控制开发的安全中，如何解决大量的互联网更新需求？

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

A1：

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

A2：

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

A3:

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

A4：

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

A5：

容器隔离的风险主要是容器逃逸和容器安全配置不正确，例如共享了主机的关健目录。

A6：

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

A7：

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

A8：

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

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

A9：

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

A10：

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

A11：

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

A12：

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

A13：

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

A14：

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

A15：

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

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

A16：

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

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

A1：

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

A2：

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

A3：

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

A4：

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

A5：

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

A6：

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

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

A1：

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

A2：

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

A3：

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

A4：

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

A5：

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

A6：

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

A7：

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

A8：

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

A9：

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

A10：

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

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

A1：

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

A2：

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

A3：

A4：

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

A5：

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

A6：

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

FreeBuf 观点总结

Docker在现今的网络安全领域中正发挥着重要作用，镜像安全不容忽视。经过本期话题的交流，总结下来需要从只使用可信的镜像源、定期更新镜像、构建自己的镜像、实施访问控制和使用安全容器等方面来保证Docker镜像的安全性。同时，可以通过禁止使用未知来源的镜像、使用安全扫描工具和配置安全策略等多种措施来避免恶意镜像的使用。至于Docker与虚拟机的优劣，讨论认为各有千秋，Docker提高了高全风险的门槛，但同样也带来了管理更复杂、检测与修复难等挑战，需要更加辩证地看待。

在本期其他话题讨论中，Redis、Kafka之类的应用日志和操作日志是否需要存储？如果是涉及重要业务最好进行存储，如果数据量过大，可通过选择其中重要信息及操作的日志进行归档；在关于云桌面控制开发安全的讨论中，对于大量的互联网更新需求，可以尝试通过敏捷开发、持续集成与持续交付等方式解决。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf2022，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。