共计 4823 个字符，预计需要花费 13 分钟才能阅读完成。
前言
近年来，云原生架构被宽泛的部署和应用，业务容器化部署的比例逐年进步，对于突发重大破绽等 0day 安全事件，往往给平安的应急带来重大的挑战。例如前段时间广受影响的重大破绽的暴发，能够说是云原生架构下平安建设和平安经营面临的一次大考。
本文将以该高危任意代码执行破绽作为案例，分享云原生架构下的平安建设和平安经营的思考。
破绽处理回顾
破绽暴发后，第一工夫关注的肯定是攻击者是否利用破绽攻打业务零碎，能够通过哪些形式施行攻打。对于容器环境，从攻打视角来看，通常能够有以下几种入侵路径。
图 1
1）通过容器主机施行攻打。这种通常是因为主机配置问题引起，例如对公网凋谢并且未开启认证的 Docker RemoteAPI，或者是未开启认证的 Kubernetes API Server。
2）通过软弱的容器施行攻打。这种类型攻打次要以容器环境中部署应用程序的脆弱性作为攻打突破口。
3）通过投毒的镜像施行攻打。次要通过对公共仓库中的镜像进行投毒，当镜像被拉取运行时，即可执行相干的攻打操作。
攻击者能够做什么？
本次 log4j2 破绽的影响，次要是体现在第二种攻击方式上，也就是攻击者会通过受影响的应用程序，利用破绽对容器化的利用施行攻打。
一旦第一步破绽利用胜利，接下来就会依照通常的浸透攻打逻辑，一方面在主机执行恶意程序；另一方面通过横向挪动，扩充攻打范畴，这里的横向挪动既会波及主机层面的容器逃逸，也包含东西向网络层面的挪动攻打。
如何疾速响应处理？
云原生架构下，在破绽的应急响应上，总体思路和传统安全事件的应急是统一的。首先须要对破绽的原理以及可能被利用的形式进行剖析，确定修复和缓解计划，同时制订相干平安产品的防护规定，实现对破绽利用的检测和拦挡，最初就是井井有条的进行破绽的修复和处理。
在容器环境中，具体能够梳理出如下的一些要害操作步骤：
- 首先，须要确定现有业务的受影响范畴。例如：确定仓库中所有受破绽影响的镜像，确定受影响的线上业务；
- 其次，降级相干平安产品的防护策略。例如通过 WAF 规定以及防火墙规定等实现对破绽利用的攻打进行肯定水平的暂时性拦挡；必要时降级运行时检测策略，一旦入侵胜利，能够疾速的发现并进行处理。
- 最初，就是修复破绽，降级到官网公布的修复版本。
为什么不容易
平安应急或者平安经营的效率，很大水平上依赖平安能力的建设。上述处理步骤，相对来说是现实状况下的一种处理流程，或者是须要在一套欠缺的平安能力建设根底之上才能够轻松施行的处理流程。
依据腾讯云在 2021 年 11 月份公布的《腾讯云容器平安白皮书》显示，以后云原生用户在平安能力的建设上堪称是参差不齐，像镜像破绽扫描、主机平安加固以及集群监控审计等根底平安能力，落地部署的比例也仅仅只有 50% 左右，甚至有 7% 的用户在云原生的应用时没有任何平安能力的部署。
图 2
因而，在这样的现状下，面对 log4j2 这样的 0day 破绽，在应急处理上，难免会呈现各种顾此失彼的问题。
管制影响范畴
对于破绽的处理，首先就是管制破绽影响范畴。因为破绽的修复须要肯定的工夫周期，像 log4j2 这种应用范畴如此之广的组件，甚至有预测，破绽影响将会继续很长一段时间，因而管制新的影响资产减少也是非常重要的。
这里次要体现在两个方面：
（1）避免蕴含破绽镜像的入库。CI 集成以及镜像入库等阶段，须要严格进行安全检查，避免破绽的引入。
（2）避免蕴含破绽镜像的运行。在新的服务启动运行时，须要检测相干镜像是否蕴含破绽，对于未通过平安检测的镜像，要严格阻止其启动运行。
怎么确定受影响范畴
1）辨认所有受到破绽影响的镜像
在确定业务的受影响范畴时，如果部署了容器镜像平安扫描的能力，平安厂商通常会在第一工夫更新破绽库或检测规定，用户能够间接通过对镜像仓库的所有镜像进行扫描发现受影响的镜像。
如果没有部署镜像平安扫描，腾讯云容器平安服务 提供 7 天的收费试用，用户能够通过其中的镜像扫描性能，对镜像资产进行排查。最差状况下，用户能够应用开源的镜像扫描工具（例如 Clair/Anchore/Trivy 等）进行问题排查，然而有一点须要留神，应用开源工具前，要确保破绽库或者检测规定曾经蕴含了对指标破绽的检测。
2）辨认受影响的运行工作负载
当确定了受影响的镜像后，就须要依据这个列表确定受影响的线上业务。如果咱们的日常平安经营做的足够欠缺，实践上这个列表跟受影响的业务列表应该是统一的。或者是咱们须要部署相应的平安能力，实现镜像资产到线上业务资产的映射。
如果这些都没有的话，就须要一一集群的检索以后应用的镜像，判断其是否受到影响，例如能够应用“kubectl describe pods –all-namespaces| grep image”这种最粗犷的指令获取集群运行业务所应用的所有镜像。
到这里咱们发现，如果仓库中镜像的数量太多，其实也能够采纳另一种思路，先应用相似“kubectl describe pods –all-namespaces| grep image”这样的命令，一一集群查问到所有线上业务应用的镜像，而后对于这些镜像定向的进行破绽检测。
怎么修复
面对破绽的暴发，所有人都心愿能充沛理解这个破绽，并在第一工夫应用对应的补丁解决问题。可怜的是：一方面，软件开发和测试须要工夫周期，破绽的修复不会那么快；另一方面，在微服务架构下，受影响的镜像可能会十分多，这同样给破绽的修复带来很大的挑战。
因而，在破绽修复的同时，咱们能够通过倡议的缓解措施进行缓解，例如，对于 log4j2 破绽，能够增加 jvm 启动参数：
-Dlog4j2.formatMsgNoLookups=true 进行临时的缓解。
然而，在云原生架构下，应用程序的启动命令以及运行参数等信息，都是间接打包在镜像中，这样又回到前文提到的问题，如果受影响的镜像数量十分宏大的时候，这种长期的缓解措施在施行起来也将面临重大的挑战。
在云原生架构下，咱们看到能够有几种针对破绽的缓解性操作：
（1）批改线上运行环境
咱们能够通过 kubectl edit pod…命令，批改线上服务 Pod 的运行参数，实现破绽的缓解。针对批量的运行参数批改，咱们也推出了一个开源的工具。
值得注意的是，上述处理形式在批改完参数之后，会主动重启服务，用户在应用时，需评估相应的重启危险。
图 3
（2）利用破绽个性缓解
以 log4j2 为例，这是个近程任意代码执行的破绽，简略来说，就是在打印日志时，如果发现日志内容中蕴含关键词 ${，那么这个外面蕴含的内容会当做变量来进行替换，导致攻击者能够任意执行命令。
因而在进行破绽缓解时，能够利用破绽的这一个性，将缓解指令通过破绽传进去，实现利用破绽来缓解破绽的成果。
这种办法针对不同的破绽，不具备普适性。
（3）破绽利用的阻止
后面两种操作，都是从破绽自身登程，通过缓解形式，使得破绽不能被利用。另外一种缓解措施就是一旦前述缓解措施生效或被绕过，能够在破绽利用的要害门路上，进行操作的拦挡，从而达到破绽缓解的成果。
这种操作对平安能力有肯定的依赖，一方面，平安能力须要可能检测出破绽利用的行为，另一方面，须要可能精准的对过程行为进行阻断。尤其是对于 log4j2 这种任意代码执行的破绽，破绽利用的检测对平安能力有着较高的要求。
通过上述几种长期缓解措施后，接下来咱们须要做的就是，联合线上环境应用的镜像以及业务重要性和优先级等因素，井井有条的将受影响的组件降级至官网公布的稳固修复版本。
云原生架构下平安经营的挑战和劣势
从上述破绽处理的过程咱们能够发现，云原生架构下在破绽的处理修复上，容器环境既面临肯定的挑战，同时也有着肯定的劣势。
挑战
1）镜像数量大。一方面，因为 log4j2 自身就是利用范畴很广的组件，而且在微服务架构下，利用又会进行很多细粒度的微服务拆分，因而在仓库中会受影响的镜像会波及到很多个 Repositories；另一方面，因为 DevOps 等麻利开发流程的应用，镜像仓库中的每一个镜像又会有很多个版本（每个 Repository 有很多个 Tags）。因而，在破绽处理的过程中会发现，扫描进去的受影响镜像数量微小。
2）僵尸镜像。所谓的僵尸镜像，其实能够了解为存储在仓库中的旧版本镜像，或者过期镜像，曾经简直不会再被运行应用。如果对仓库中的镜像没有很好的管理机制，这种僵尸镜像的数量也会十分大。这种景象其实也很好了解，DevOps 带来业务疾速的迭代，天然就会产生大量的过期镜像。
在惯例的平安经营中，这些僵尸镜像原则上是应该及时被革除的（不须要思考备份回滚的问题，代码仓库会有），这种革除操作不仅仅是须要笼罩镜像仓库，同样实用于主机上的僵尸镜像。
3）不可变基础设施。云原生架构的一个典型特色就是不可变的基础设施，所谓的不可变基础设施，是指一旦部署了服务之后决不允许被批改。如果须要以任何形式更新、修复或批改某些内容，则须要批改绝对应的镜像，构建全新的服务镜像来替换旧的须要扭转的服务镜像，通过验证后，应用新的镜像重新部署服务，而旧的则会被删除。
这种个性，给咱们针对线上业务在进行破绽缓解的时候带来了很大的不便。一方面体现在批改利用的运行参数和环境变量等信息上；另一方面体现在这种缓解措施的批改，会引发运行时平安的再次告警，因为这种操作违反了不可变基础设施的要求，不是失常的业务操作流程。
劣势
• 资产可视化，疾速定位。资产问题始终是平安建设和平安经营中重要的问题，同时也是最让人头疼的问题。云原生架构很好的解决了资产的问题，通过 Kubernetes 等编排平台以及镜像仓库等组件，能够让咱们疾速的进行资产梳理、问题定位。
• 流程自动化，疾速失效。Kubernetes 等编排平台提供了一整套的业务自动化治理计划，包含配置管理、服务编排、工作治理等。因而，对于破绽的修复能够实现疾速散发和对应的灰度降级等。
• 平安左移，疾速管制。可能在 CI/CD 等多个环节进行平安左移检测，镜像入库前的检测，阻止蕴含破绽镜像推送到仓库，升高增量危险；在运行时进行准入检测，对于蕴含破绽危险的镜像，阻止其启动运行，减小线上环境新增裸露面。
• 微服务架构。在微服务架构下，利用间绝对独立，这给破绽修复带来的益处，一方面，针对某个镜像的破绽修复，影响范畴小，进步破绽修复效率；另一方面，微服务架构下，服务性能繁多，很多反复的性能会造成独立服务，这样减小了修复数量。
这次破绽的暴发，给咱们在云原生平安建设和经营上敲响了警钟，以该事件作为切入点，企业在云原生架构的落地过程中，须要零碎全面的思考平安能力的建设和经营了。咱们将在下一篇文章中，联合本身实际，零碎的分享咱们对于云原生架构下平安建设和平安经营的思考。
对于腾讯容器平安服务（TCSS）
腾讯容器平安服务（Tencent Container SecurityService, TCSS）提供容器 资产治理、镜像平安、集群平安、运行时入侵检测 等平安服务，保障容器从镜像构建、部署到运行时的全生命周期平安，帮忙企业构建容器平安防护体系。
腾讯从 2018 年 9 月 30 日启动全面云原生上云策略，至今曾经有数千万外围规模。容器平安服务产品团队联合业内最大规模容器集群平安治理经营教训打磨产品，推动行业标准及标准的编写制订，并首发《腾讯云容器平安白皮书》，对国内容器环境平安现状进行剖析总结，助力云原生平安生态的标准化和衰弱倒退。
对于咱们
即刻关注【腾讯云原生】公众号，回复“虎虎生威”，支付腾讯定制红包封面~
福利：
①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~
②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。
③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》
③公众号后盾回复【光速入门】，可取得腾讯腾讯云专家 5 万字精髓教程，光速入门 Prometheus 和 Grafana。
