作为一种架构模式，云原生架构通过若干原则来对应用架构进行核心控制。这些原则可以帮助技术主管和架构师在进行技术选型时更加高效、准确，下面将展开具体介绍。服务化原则在软件开发过程中，当代码数量与开发团队规模都扩张到一定程度后，就需要重构应用，通过模块化与组件化的手段分离关注点，降低应用的复杂度，提升软件的开发效率，降低维护成本。如图 1，随着业务的不断发展，单体应用能够承载的容量将逐渐到达上限，即使通过应用改造来突破垂直扩展（Scale Up）的瓶颈，并将其转化为支撑水平扩展（Scale Out）的能力，在全局并发访问的情况下，也依然会面临数据计算复杂度和存储容量的问题。因此，需要将单体应用进一步拆分，按业务边界重新划分成分布式应用，使应用与应用之间不再直接共享数据，而是通过约定好的契约进行通信，以提高扩展性。图 1 应用服务化扩展服务化设计原则是指通过服务化架构拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保证迭代的稳定性。同时，服务化架构采用的是面向接口编程方式，增加了软件的复用程度，增强了水平扩展的能力。服务化设计原则还强调在架构层面抽象化业务模块之间的关系，从而帮助业务模块实现基于服务流量（而非网络流量）的策略控制和治理，而无须关注这些服务是基于何种编程语言开发的。有关服务化设计原则的实践在业界已有很多成功案例。其中影响最广、最为业界称道的是 Netflix 在生产系统上所进行的大规模微服务化实践。通过这次实践，Netflix 在全球不仅承接了多达 1.67 亿订阅用户以及全球互联网带宽容量 15% 以上的流量，而且在开源领域贡献了 Eureka、Zuul、Hystrix 等出色的微服务组件。不仅海外公司正在不断进行服务化实践，国内公司对服务化也有很高的认知。随着近几年互联网化的发展，无论是新锐互联网公司，还是传统大型企业，在服务化实践上都有很好的实践和成功案例。阿里巴巴的服务化实践发端于 2008 年的五彩石项目，历经 10 年的发展，稳定支撑历年大促活动。以 2019 年“双 11”当天数据为例，阿里巴巴的分布式系统创单峰值为每秒 54.4 万笔，实时计算处理为每秒 25.5 亿笔。阿里巴巴在服务化领域的实践，已通过 Apache Dubbo、Nacos、Sentinel、Seata、Chaos Blade 等开源项目分享给业界， 同时，这些组件与 Spring Cloud的集成 Spring Cloud Alibaba 已成为 Spring Cloud Netflix 的继任者。虽然随着云原生浪潮的兴起，服务化原则不断演进、落地于实际业务，但企业在实际落地过程中也会遇到不少的挑战。比如，与自建数据中心相比，公有云下的服务化可能存在巨大的资源池，使得机器错误率显著提高；按需付费增加了扩缩容的操作频度；新的环境要求应用启动更快、应用与应用之间无强依赖关系、应用能够在不同规格的节点之间随意调度等诸多需要考虑的实际问题。但可以预见的是，这些问题会随着云原生架构的不断演进而得到逐一解决。弹性原则弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。优秀的弹性能力不仅能够改变企业的 IT 成本模式，使得企业不用再考虑额外的软硬件资源成本支出（闲置成本），也能更好地支持业务规模的爆发式扩张，不再因为软硬件资源储备不足而留下遗憾。在云原生时代，企业构建 IT 系统的门槛大幅降低，这极大地提升了企业将业务规划落地为产品与服务的效率。这一点在移动互联网和游戏行业中显得尤为突出。一款应用成为爆款后，其用户数量呈现指数级增长的案例不在少数。而业务呈指数级增长会对企业 IT 系统的性能带来巨大考验。面对这样的挑战，在传统架构中，通常是开发人员、运维人员疲于调优系统性能，但是，即使他们使出浑身解数，也未必能够完全解决系统的瓶颈问题， 最终因系统无法应对不断涌入的海量用户而造成应用瘫痪。除了面临业务呈指数级增长的考验之外，业务的峰值特征将是另一个重要的挑战。比如，电影票订票系统下午时段的流量远超凌晨时段，而周末的流量相比工作日甚至会翻好几倍；还有外卖订餐系统，在午餐和晚餐前后往往会出现订单峰值时段。在传统架构中，为了应对这类具有明显峰值特征的场景，企业需要为峰值时段的流量提前准备大量的计算、存储及网络资源并为这些资源付费，而这些资源在大部分时间内却处于闲置状态。因此，在云原生时代，企业在构建 IT系统时，应该尽早考虑让应用架构具备弹性能力，以便在快速发展的业务规模面前灵活应对各种场景需求，充分利用云原生技术及成本优势。要想构建弹性的系统架构，需要遵循如下四个基本原则。按功能切割应用一个大型的复杂系统可能由成百上千个服务组成，架构师在设计架构时，需要遵循的原则是：将相关的逻辑放到一起，不相关的逻辑拆解到独立的服务中，各服务之间通过标准的服务发现（Service Discovery）找到对方，并使用标准的接口进行通信。各服务之间松耦合，这使得每一个服务能够各自独立地完成弹性伸缩，从而避免服务上下游关联故障的发生。支持水平切分按功能切割应用并没有完全解决弹性的问题。一个应用被拆解为众多服务后，随着用户流量的增长，单个服务最终也会遇到系统瓶颈。因此在设计上，每个服务都需要具备可水平切分的能力，以便将服务切分为不同的逻辑单元，由每个单元处理一部分用户流量，从而使服务自身具备良好的扩展能力。这其中最大的挑战在于数据库系统，因为数据库系统自身是有状态的，所以合理地切分数据并提供正确的事务机制将是一个非常复杂的工程。不过，在云原生时代，云平台所提供的云原生数据库服务可以解决大部分复杂的分布式系统问题，因此，如果企业是通过云平台提供的能力来构建弹性系统，自然就会拥有数据库系统的弹性能力。自动化部署系统突发流量通常无法预计，因此常用的解决方案是，通过人工扩容系统的方式，使系统具备支持更大规模用户访问的能力。在完成架构拆分之后，弹性系统还需要具备自动化部署能力，以便根据既定的规则或者外部流量突发信号触发系统的自动化扩容功能，满足系统对于缩短突发流量影响时长的及时性要求，同时在峰值时段结束后自动缩容系统，降低系统运行的资源占用成本。支持服务降级弹性系统需要提前设计异常应对方案，比如，对服务进行分级治理，在弹性机制失效、弹性资源不足或者流量峰值超出预期等异常情况下，系统架构需要具备服务降级的能力，通过降低部分非关键服务的质量，或者关闭部分增强功能来让出资源，并扩容重要功能对应的服务容量，以确保产品的主要功能不受影响。国内外已有很多成功构建大规模弹性系统的实践案例，其中最具代表性的是阿里巴巴一年一度的“双11”大促活动。为了应对相较于平时上百倍的流量峰值，阿里巴巴每年从阿里云采买弹性资源部署自己的应用，并在“双 11”活动之后释放这一批资源，按需付费，从而大幅降低大促活动的资源成本。另一个例子是新浪微博的弹性架构，在社会热点事件发生时，新浪微博通过弹性系统将应用容器扩容到阿里云，以应对热点事件导致的大量搜索和转发请求。系统通过分钟级的按需扩容响应能力，大幅降低了热搜所产生的资源成本。随着云原生技术的发展，FaaS、Serverless 等技术生态逐步成熟，构建大规模弹性系统的难度逐步降低。当企业以 FaaS、Serverless 等技术理念作为系统架构的设计原则时，系统就具备了弹性伸缩的能力，企业也就无须额外为“维护弹性系统自身”付出成本。可观测原则与监控、业务探活、APM（Application Performance Management，应用性能管理）等系统提供的被动能力不同，可观测性更强调主动性，在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次 App 点击所产生的多次服务调用耗时、返回值和参数都清晰可见，甚至可以下钻到每次第三方软件调用、SQL 请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况，并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验。随着云计算的全面发展，企业的应用架构发生了显著变化，正逐步从传统的单体应用向微服务过渡。在微服务架构中，各服务之间松耦合的设计方式使得版本迭代更快、周期更短；基础设施层中的 Kubernetes 等已经成为容器的默认平台；服务可以通过流水线实现持续集成与部署。这些变化可将服务的变更风险降到最低，提升了研发的效率。在微服务架构中，系统的故障点可能出现在任何地方，因此我们需要针对可观测性进行体系化设计，以降低 MTTR（故障平均修复时间）。要想构建可观测性体系，需要遵循如下三个基本原则。数据的全面采集指标（Metric）、链路跟踪（Tracing）和日志（Logging）这三类数据是构建一个完整的可观测性系统的“三大支柱”。而系统的可观测性就是需要完整地采集、分析和展示这三类数据。指标，指标是指在多个连续的时间周期里用于度量的 KPI 数值。一般情况下，指标会按软件架构进行分层，分为系统资源指标（如 CPU 使用率、磁盘使用率和网络带宽情况等）、应用指标（如出错率、服务等级协议 SLA、服务满意度 APDEX、平均延时等）、业务指标（如用户会话数、订单数量和营业额等）。链路跟踪，链路跟踪是指通过 TraceId 的唯一标识来记录并还原发生一次分布式调用的完整过程，贯穿数据从浏览器或移动端经过服务器处理，到执行 SQL 或发起远程调用的整个过程。日志，日志通常用来记录应用运行的执行过程、代码调试、错误异常等信息，如 Nginx 日志可以记录远端 IP、发生请求时间、数据大小等信息。日志数据需要集中化存储，并具备可检索的能力。数据的关联分析让各数据之间产生更多的关联，这一点对于一个可观测性系统而言尤为重要。出现故障时，有效的关联分析可以实现对故障的快速定界与定位，从而提升故障处理效率，减少不必要的损失。一般情况下，我们会将应用的服务器地址、服务接口等信息作为附加属性，与指标、调用链、日志等信息绑定，并且赋予可观测系统一定的定制能力，以便灵活满足更加复杂的运维场景需求。统一监控视图与展现多种形式、多个维度的监控视图可以帮助运维和开发人员快速发现系统瓶颈，消除系统隐患。监控数据的呈现形式应该不仅仅是指标趋势图表、柱状图等，还需要结合复杂的实际应用场景需要，让视图具备下钻分析和定制能力，以满足运维监控、版本发布管理、故障排除等多场景需求。随着云原生技术的发展，基于异构微服务架构的场景会越来越多、越来越复杂，而可观测性是一切自动化能力构建的基础。只有实现全面的可观测性，才能真正提升系统的稳定性、降低 MTTR。因此，如何构建系统资源、容器、网络、应用、业务的全栈可观测体系，是每个企业都需要思考的问题。韧性原则韧性是指当软件所依赖的软硬件组件出现异常时，软件所表现出来的抵御能力。这些异常通常包括硬件故障、硬件资源瓶颈（如 CPU 或网卡带宽耗尽）、业务流量超出软件设计承受能力、影响机房正常工作的故障或灾难、所依赖软件发生故障等可能造成业务不可用的潜在影响因素。业务上线之后，在运行期的大部分时间里，可能还会遇到各种不确定性输入和不稳定依赖的情况。当这些非正常场景出现时，业务需要尽可能地保证服务质量，满足当前以联网服务为代表的“永远在线”的要求。因此，韧性能力的核心设计理念是面向失败设计，即考虑如何在各种依赖不正常的情况下，减小异常对系统及服务质量的影响并尽快恢复正常。韧性原则的实践与常见架构主要包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、多 AZ（Availability Zone，可用区）的高可用、单元化、跨区域（Region）容灾、异地多活容灾等。下面结合具体案例详细说明如何在大型系统中进行韧性设计。“双 11”对于阿里巴巴来说是一场不能输的战役，因此其系统的设计在策略上需要严格遵循韧性原则。例如，在统一接入层通过流量清洗实现安全策略，防御黑产攻击；通过精细化限流策略确保峰值流量稳定，从而保障后端工作正常进行。为了提升全局的高可用能力，阿里巴巴通过单元化机制实现了跨区域多活容灾，通过同城容灾机制实现同城双活容灾，从而最大程度提升 IDC（Internet Data Center，互联网数据中心）的服务质量。在同一 IDC 内通过微服务和容器技术实现业务的无状态迁移；通过多副本部署提高高可用能力；通过消息完成微服务间的异步解耦以降低服务的依赖性，同时提升系统吞吐量。从每个应用的角度，做好自身依赖梳理，设置降级开关，并通过故障演练不断强化系统健壮性，保证阿里巴巴“双11”大促活动正常稳定进行。随着数字化进程的加快，越来越多的数字化业务成为整个社会经济正常运转的基础设施，但随着支撑这些数字化业务的系统越来越复杂，依赖服务质量不确定的风险正变得越来越高，因此系统必须进行充分的韧性设计，以便更好地应对各种不确定性。尤其是在涉及核心行业的核心业务链路（如金融的支付链路、电商的交易链路）、业务流量入口、依赖复杂链路时，韧性设计至关重要。所有过程自动化原则技术是把“双刃剑”，容器、微服务、DevOps 以及大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，也提高了软件技术栈的复杂度，加大了组件规模，从而不可避免地导致了软件交付的复杂性。如果控制不当，应用就会无法体会到云原生技术的优势。通过 IaC、GitOps、OAM、Operator 和大量自动化交付工具在 CI/CD（持续集成 /持续交付）流水线中的实践，企业可以标准化企业内部的软件交付过程，也可以在标准化的基础上实现自动化，即通过配置数据自描述和面向终态的交付过程，实现整个软件交付和运维的自动化。要想实现大规模的自动化，需要遵循如下四个基本原则。标准化实施自动化，首先要通过容器化、IaC、OAM 等手段，标准化业务运行的基础设施，并进一步标准化对应用的定义乃至交付的流程。只有实现了标准化，才能解除业务对特定的人员和平台的依赖，实现业务统一和大规模的自动化操作。面向终态面向终态是指声明式地描述基础设施和应用的期望配置，持续关注应用的实际运行状态，使系统自身反复地变更和调整直至趋近终态的一种思想。面向终态的原则强调应该避 免直接通过工单系统、工作流系统组装一系列过程式的命令来变更应用，而是通过设置终态，让系统自己决策如何执行变更。关注点分离自动化最终所能达到的效果不只取决于工具和系统的能力，更取决于为系统设置目标的人，因此要确保找到正确的目标设置人。在描述系统终态时，要将应用研发、应用运维、基础设施运维这几种主要角色所关注的配置分离开来，各个角色只需要设置自己所关注和擅长的系统配置，以便确保设定的系统终态是合理的。面向失败设计要想实现全部过程自动化，一定要保证自动化的过程是可控的，对系统的影响是可预期的。我们不能期望自动化系统不犯错误，但可以保证即使是在出现异常的情况下，错误的影响范围也是可控的、可接受的。因此，自动化系统在执行变更时，同样需要遵循人工变更的最佳实践，保证变更是可灰度执行的、执行结果是可观测的、变更是可快速回滚的、变更影响是可追溯的。业务实例的故障自愈是一个典型的过程自动化场景。业务迁移到云上后，云平台虽然通过各种技术手段大幅降低了服务器出故障的概率，但是却并不能消除业务本身的软件故障。软件故障既包括应用软件自身的缺陷导致的崩溃、资源不足导致的内存溢出（OOM）和负载过高导致的夯死等异常问题，也包括内核、守护进程（daemon 进程）等系统软件的问题，更包括混部的其他应用或作业的干扰问题。随着业务规模的增加，软件出现故障的风险正变得越来越高。传统的运维故障处理方式需要运维人员的介入，执行诸如重启或者腾挪之类的修复操作，但在大规模场景下，运维人员往往疲于应对各种故障，甚至需要连夜加班进行操作，服务质量很难保证，不管是客户，还是开发、运维人员，都无法满意。为了使故障能够实现自动化修复，云原生应用要求开发人员通过标准的声明式配置，描述应用健康的探测方法和应用的启动方法、应用启动后需要挂载和注册的服务发现以及配置管理数据库（Configuration Management Data Base，CMDB）信息。通过这些标准的配置，云平台可以反复探测应用，并在故障发生时执行自动化修复操作。另外，为了防止故障探测本身可能存在的误报问题，应用的运维人员还可以根据自身容量设置服务不可用实例的比例，让云平台能够在进行自动化故障恢复的同时保证业务可用性。实例故障自愈的实现，不仅把开发人员和运维人员从烦琐的运维操作中解放了出来，而且可以及时处理各种故障，保证业务的连续性和服务的高可用性。零信任原则基于边界模型的传统安全架构设计，是在可信和不可信的资源之间架设一道墙，例如，公司内网是可信的，而因特网则是不可信的。在这种安全架构设计模式下，一旦入侵者渗透到边界内，就能够随意访问边界内的资源了。而云原生架构的应用、员工远程办公模式的普及以及用手机等移动设备处理工作的现状，已经完全打破了传统安全架构下的物理边界。员工在家办公也可以实现与合作方共享数据，因为应用和数据被托管到了云上。如今，边界不再是由组织的物理位置来定义，而是已经扩展到了需要访问组织资源和服务的所有地方，传统的防火墙和 VPN 已经无法可靠且灵活地应对这种新边界。因此，我们需要一种全新的安全架构，来灵活适应云原生和移动时代环境的特性，不论员工在哪里办公，设备在哪里接入，应用部署在哪里，数据的安全性都能够得到有效保护。如果要实现这种新的安全架构，就要依托零信任模型。传统安全架构认为防火墙内的一切都是安全的，而零信任模型假设防火墙边界已经被攻破，且每个请求都来自于不可信网络，因此每个请求都需要经过验证。简单来说，“永不信任，永远验证”。在零信任模型下，每个请求都要经过强认证，并基于安全策略得到验证授权。与请求相关的用户身份、设备身份、应用身份等，都会作为核心信息来判断请求是否安全。如果我们围绕边界来讨论安全架构，那么传统安全架构的边界是物理网络，而零信任安全架构的边界则是身份，这个身份包括人的身份、设备的身份、应用的身份等。要想实现零信任安全架构，需要遵循如下三个基本原则。显式验证对每个访问请求都进行认证和授权。认证和授权需要基于用户身份、位置、设备信息、服务和工作负载信息以及数据分级和异常检测等信息来进行。例如，对于企业内部应用之间的通信，不能简单地判定来源 IP是内部...

近期想讲一些我看到企业安全最严重威胁和运营痛点，不出意外，这会是一个系列，前面几篇先说问题，后面再说解决方案，讲到的所有观点和案例，都是通过实践而来，会基本覆盖我的核心安全观。每天只写1000字左右，没写完的痛点拆开写，文章后面附上一张我们给客户的安全意识墙面小贴士。 以往，不管是安全甲方还是乙方，安全工作都是围绕应用跟操作系统去做，比如WAF、IPS、SDL等，解决的都是系统跟应用的问题，所以应用跟操作系统的漏洞越来越少。而唯独只有我跳出来做一家公司解决人的问题，因为在近年我通过渗透测试服务发现，最大的问题不在于系统和应用，而在于人，一切问题都源自于人，人的行为和意识错误导致漏洞频出，今天就说说员工的行为难管控的问题。   员工行为难管控体现在如下几个方面，有没有发生过此类事件可自行对号： 1、滥用云笔记及网盘（重灾区）将vpn密码、wifi密码、服务器密码、阿里云或运营后台密码...记录在个人云笔记、网盘、icloud，技术岗位的人最爱干这事，而且这个行为一旦犯了就会导致企业被直接入侵，什么waf、ips在这种情况下都是摆设。互联网企业的员工，基本上70%以上的员工都会用这些东西，特别是权限多的研发、运维岗位，在以往给客户实施渗透测试服务时，通过这种方式屡试不爽，越是大公司在这块威胁越大，为什么？因为员工多啊，总有X一样的队友。如果员工在公司办公，则能在路由上就能对这些云服务进行禁止访问，但是有几个员工不会把电脑带回家办公呢？这种情况下很难限制员工的行为。 来看看乌云上的案例。a、极客学院某员工印象笔记 b、豌豆荚某员工印象笔记 2、将公司代码存储在Github、oschina、Bitbucket等。    这个行为是研发岗位常犯的错误，稍微大一点的互联网企业几乎无一幸免，可以去乌云网搜索一下“github”看看结果。这些泄露的代码有什么危害呢？代码里面包含的邮箱密码、数据库密码，一旦被搞渗透的人拿到，直接登陆企业邮箱，翻到VPN密码，连接数据库，轻轻松松就能把数据库给拖掉，这样的案例太多太多。 a、金立员工将代码存放到github。  3、员工企业邮箱与外部个人账号密码一致。 密码通用的习惯，据经验大概95%以上的人都这么干，在早之前曝光的网易5亿的会员数据泄露等此类事件，曝光的任何一份数据其实在N年前就已经在地下流传，只是有的人不多，民间有的人甚至将国内知名企业都入侵了个遍，手上偷回来的数据达大几十亿条。试想，中国网民才多少，也就意味着，你只要一出生，别人手里就拿着你的信息，你只要一上网，别人就知道你密码是多少！永远都不要在这些人面前谈隐私两个字，人家只会在心里呵呵一下。一个技术岗位的员工，像研发、运维、测试、安全，或者非技术岗位的客服、运营，员工入职的时候，交接文档有没有？交接文档里面有什么？服务器密码、后台地址密码、阿里云密码等等，不仅有，还注释的清清楚楚、明明白白。另外技术岗位基本都有VPN权限，邮件列表里面一搜“VPN”，密码妥妥的，就算没有，随便编个理由给网络负责人发个申请VPN的邮件，一会儿的时间妥妥的给你把VPN开通好。 今日结束，期待明日，敬请关注微信公众号【互联网安全与创业】。企业安全墙面小贴士： 本文始发于微信公众号（互联网安全与创业）：企业安全痛点之员工行为难管控（一）

随着容器、微服务等新技术日新月异，开源软件成为业界主流形态，软件行业快速发展。但同时，软件供应链也越来越趋于复杂化和多样化，软件供应链安全风险不断加剧，针对软件供应链薄弱环节的网络攻击随之增加，软件供应链成为影响软件安全的关键因素之一。近年来，全球针对软件供应链的安全事件频发，影响巨大，软件供应链安全已然成为一个全球性问题。全面、高效地保障软件供应链的安全对于我国软件行业发展、数字化进程推进具有重要意义。近日，在由中国信通院指导、悬镜安全主办的中国首届DevSecOps敏捷安全大会（DSO 2021）现场，《软件供应链安全白皮书（2021）》（以下简称“白皮书”）正式发布。本白皮书着重分析了软件供应链安全，梳理了软件供应链的安全现状，透过现状全面剖析软件供应链的安全风险及面临的安全挑战，有针对性地提出如何对软件供应链的安全风险进行防范与治理，系统阐述了软件供应链安全的防护体系及软件供应链安全的应用实践以供参考，最后白皮书结合现在软件供应链安全的发展趋势进行了全面的分析及展望。由于篇幅有限，仅摘选本报告“软件供应链安全治理”及“软件供应链应用实践”两部分进行分享。 图：《软件供应链安全白皮书》封面一、软件供应链安全治理目前，业界已充分认识到造成网络安全事件出现的主要原因之一，是由于软件开发者在开发过程中对开发工具、开发团队、开发生命周期和软件产品自身管理不当，致使软件存在着安全缺陷，破坏或影响最终用户的信息安全。 通过推进针对软件生命周期进行全流程安全管控的落地实践，有助于从软件生命周期的源头保障软件供应链安全。通过建立软件开发过程中保证软件供应链安全的体系化方法，为软件开发过程中尽可能避免和消除软件的安全缺陷、保证软件供应链安全奠定重要基础。从软件安全开发生命周期角度分析软件供应链安全的应用实践方法，主要有以下几个阶段。1、体系构建阶段SDL 软件安全开发生命周期 微软在21世纪初期的软件产品开发实践中，意识到无法通过技术层面彻底解决软件面临的安全风险。因此，微软尝试从流程和管理的角度解决这个问题，并探索在各个软件开发环节中加入安全过程、把控安全风险，确保每个环节交付到下一环节的交付物都安全可控。于是，针对传统的瀑布式模型微软提出了“SDL 软件安全开发生命周期” 这一概念。 软件安全开发生命周期（SDL），是一个在帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。SDL将软件开发生命周期划分为7 个阶段（如图所示），并提出了 17 项重要的安全活动，旨在将安全集成在软件开发的每一个阶段，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。SDL更侧重的是软件开发的安全保障过程，旨在开发出安全的软件产品。  图 1 SDL 软件安全开发生命周期在 SDL 的 7 个阶段中（如图 1所示），SDL 要求前 6 个阶段的 16 项安全活动，为开发团队必须完成的安全活动。同时，SDL 认为开发团队应该保持灵活性，以便选择更多合适的安全活动，如人工代码分析、渗透测试、相似应 用程序的漏洞分析，以确保对某些软件组件进行更高级别的安全分析。SDL 重视各种工具的使用，重心在从需求阶段到测试阶段的工具集，如威胁建模、静态源代码分析等工具。SDL 的 7 个阶段主要的含义如下： 培训：针对开发团队进行安全意识与能力的培训，以确保 SDL 能有效实施并落地，同时针对新的安全问题与形势 持续提升团队的安全能力； 需求：通过安全需求分析，定义软件产品安全实现过程中所需要的安全标准和相关要求； 设计：通过分析攻击面，设计相对应的功能和策略，降低和减少不必要的安全风险。同时通过威胁建模，分析软 件的安全威胁，提出缓解措施； 实施：按设计要求，实现对应功能和策略，以及缓解措施涉及的安全功能和策略。同时通过安全编码和禁用不安 全的 API，减少实施时导致的安全问题，尽量避免引入编码级的安全漏洞，并通过代码审计等措施来确保安全编码规范的实行； 验证：通过安全测试检测软件的安全漏洞，并全面核查攻击面，各个关键因素上的威胁缓解措施是否得以验证； 发布：建立相应的响应计划，进行最终安全检查，确认所有安全活动均完成后将最终版本发送给客户； 响应：当出现安全事件与漏洞报告时，及时实施应急响应和漏洞修复。在此过程中新发现的问题和安全问题模式，可用于 SDL 的持续改进过程中。DevSecOps DevSecOps 是一种全新的安全理念和模式，由 DevOps 的概念延伸和演变而来。其核心理念是安全是整个 IT 团队 每个人的责任，需要贯穿从开发到运营整个业务生命周期每一个环节才能提供有效保障。 DevSecOps 覆盖编码阶段、测试阶段、预发布阶段、发布阶段、线上运营阶段，强调自动化与平台化，由 CI/CD 平台推动整个开发和运营流程自动化。DevSecOps 依赖于 DevOps 流程工具链（如图 2 所示），将威胁建模工具、安全编码工具、安全测试工具、容器安全检测工具、基线加固工具、漏洞管理工具等自动化工具无缝集成到 DevOps 流程中，进而实现开发 - 安全 - 运营一体化。 图 2 DevSecOps 工具链很多企业在向 DevSecOps 转型时，会发现很多传统的安全工具在集成性和实用性上都难以满足 DevSecOps 的需求， 因此，在 DevSecOps 的不同阶段需要采用不同的 DevSecOps 安全工具（如图 3 所示），这些安全工具主要的共同特点是高度自动化以及可集成性。图 3 DevSecOps 安全工具在不同阶段的自动化程度在软件供应链中每个阶段都在面临不同的安全风险，为了更好的对软件供应链进行风险治理，在 DevSecOps 模式 下，安全开发工具链需要尽量覆盖软件生命周期中的所有阶段（如图 4 所示）。 图 4DevSecOps 模式下软件生命周期除了以上所提到的工具之外，在 DevSecOps 的应用实践过程中，还有一些更为前瞻性的安全工具，具体可参考 DevSecOps 敏捷安全技术金字塔（如图 5所示）。该金字塔在《2020 DevSecOps 行业洞察报告》中首次被提出， 目前已发展到 2.0 版本。其描述了一组层次结构，金字塔底部是基础性技术，越上层的技术对 DevSecOps 实践成 熟度的要求越高。图 5 DevSecOps 敏捷安全技术金字塔 V2.0 版DevSecOps 敏捷安全技术金字塔的不断升级，是为了给业界更好的预测和参考，关于 DevSecOps 敏捷安全技术...

全文共8537字，阅读大约需要17分钟。摘要：云原生应用究竟和传统应用有何不同，安全风险上有何变化？本文将从传统应用风险、应用架构变革带来的风险、云计算模式带来的风险三个维度进行介绍。一.  概述随着云计算技术的不断发展，上云已经不再是一种选择，而是一种共识，是企业数字化转型的必要条件。在相应实践过程中，传统应用存在升级缓慢、架构臃肿、无法弹性扩展及快速迭代等问题，于是近年来云原生的概念应运而生，凭借着云原生弹性、敏捷、资源池和服务化等特性，解决了业务在开发、集成、分发和运行等整个生命周期中遇到的问题。云原生环境中，应用由传统的单体架构转向微服务架构，云计算模式也相应的从基础设施即服务（Infrastructure as a Service，IaaS）转向为容器即服务（Container as a Service，CaaS）和函数即服务（Function as a Service，FaaS）。应用架构和云计算模式的变革是否会导致进一步的风险，这些风险较之传统应用风险又有哪些区别？在讲述云原生应用具体风险前，首先列举以下三个观点，这些观点有助于大家更好地理解本文所讲述的内容。观点一 云原生应用继承了传统应用的风险和API的风险云原生应用源于传统应用，因而云原生应用风险也就继承了传统应用的风险。此外，由于云原生应用架构的变化进而导致应用API交互的增多，可以说云原生应用中大部分交互模式已从Web请求/响应转向各类API请求/响应 ，例如RESTful/HTTP、gRPC等，因而API风险也进一步提升。观点二 应用架构变革将会带来新的风险由于应用架构变革，云原生应用遵循面向微服务化的设计方式，从而导致功能组件化、服务数量激增、配置复杂等问题，进而为云原生应用和业务带来了新的风险。观点三 计算模式变革将会带来新的风险随着云计算的不断发展，企业在应用的微服务化后，会进一步聚焦于业务自身，并将功能函数化，因而出现了无服务器计算（Serverless Computing）这类新的云计算模式，进而引入了Serverless应用和Serverless平台的新风险。综上所述，可以看出云原生应用带来的风险是不容小觑的。本文将从传统应用风险、应用架构变革带来的新风险、云计算模式变革带来的新风险三个维度分别进行介绍，希望可以引发大家更多的思考。二. 传统应用面临的风险云原生应用风险可以参考传统应用风险。传统应用风险以Web应用风险为主，主要包括注入、敏感数据泄露、跨站脚本、使用含有已知漏洞的组件、不足的日志记录和监控等风险。此外，云原生环境中，应用的API交互模式逐渐由“人机交互”转变为“机机交互”，虽然API大量出现是云原生环境的一大特点，但本质上来说，API风险并无新的变化，因而其风险可以参考现有的API风险，主要包括安全性错误配置、注入、资产管理不当、资源缺失和速率限制等风险。有关传统应用风险和API风险的更多细节可以分别参考OWASP组织在2017和2019年发布的应用十大风险报告和API十大风险报告。三.  应用架构变革带来的新风险3.1 云原生应用带来的新风险云原生应用面临的新风险主要体现在：新应用架构的出现。新应用架构遵循微服务化的设计模式，通过应用的微服务化，我们能够构建容错性好、易于管理的松耦合系统，与此同时，新应用架构的出现也会引入新的风险，为了较为完整地对风险进行分析，本文将以信息系统安全等级三要素，即机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）作为导向介绍应用架构变化带来的新风险。机密性受损的风险典型的如信息泄露风险，攻击者可通过利用资产脆弱性和嗅探、暴力破解等攻击方式窃取用户隐私数据，从而造成信息泄露风险。完整性受损的风险典型的如未授权访问风险，攻击者可通过利用资产脆弱性和中间人攻击等行为绕过系统的认证授权机制，执行越权操作，从而造成未授权访问的风险。可用性受损的风险典型的如系统被拒绝服务的风险，一方面，攻击者可通过畸形报文、SYN泛洪等攻击方式为目标系统提供非正常服务，另一方面，系统供不应求的场景也会导致系统遭受拒绝服务风险。本小节接下来的内容，将以信息泄露、未授权访问、拒绝服务为例，分别介绍上述三类风险。3.1.1   数据泄露的风险 云原生环境中，虽然造成应用数据泄露风险的原因有很多，但都离不开以下几个因素：应用漏洞：通过资产漏洞对应用数据进行窃取。密钥不规范管理：通过不规范的密钥管理对应用数据进行窃取。应用间通信未经加密：通过应用间通信未经加密的缺陷对传输中数据进行窃取，进而升级到对应用数据的窃取。3.1.1.1 应用漏洞带来的风险应用中存储的数据多是基于API进行访问，若应用中某API含有未授权访问漏洞，例如Redis未授权访问漏洞，攻击者便可利用此漏洞绕过Redis认证机制，访问到内部数据，进而导致了敏感信息泄露的风险。传统单体应用架构下，由于API访问范围为用户到应用，攻击者只能看到外部进入至应用的流量，无法看到应用内部的流量，所以针对恶意使用API漏洞进行数据窃取造成的损失范围通常是有限的。反观微服务化应用架构，当单体应用被拆分为若干个服务后，这些服务会根据业务情况进行相互访问，API访问范围变为服务到服务（Service to Service），若某服务因API漏洞导致攻击者有利可图，那么攻击者将会看到应用内部的流量，这无疑为攻击者提供了更多的攻击渠道，因而针对数据泄露的风险程度而言，微服务架构相比传统单体应用架构带来的风险更大。此外，随着服务数量达到一定规模，API数量将不断递增，进而扩大了攻击面，增大了数据泄露的风险。3.1.1.2 密钥不规范管理带来的风险在应用的开发过程中，开发者常疏于对密钥的管理从而导致数据泄露的风险，例如开发者将密钥信息、数据库连接密码等敏感信息硬编码在应用程序中，从而增大了诸如应用程序日志泄露、应用程序访问密钥泄露的风险。传统单体应用架构中，开发者常将配置连同应用一起打包，当需要修改配置时，只需登录至服务端进行相应修改，再对应用进行重启便可实现，这种单个集中式配置文件的存储方式从密钥管理风险的角度上讲是相对可控的。微服务应用架构中，应用的配置数量与服务数量的逐渐增多是成正比的，例如微服务应用中会存在各种服务、各种数据库访问、各种环境变量的配置，且各配置支持动态调整。同时，微服务应用架构对服务的配置管理也提出了更高的要求，例如代码与配置可分离、配置支持分布式、配置更新的实时性、配置可统一进行治理等，因而微服务下的配置管理更加复杂，对运维人员的要求更高，密钥管理的难度也在不断提升，最终会造成更大的数据泄露风险。3.1.1.3 应用通信未经加密带来的风险如果应用采用HTTP协议进行数据传输，那么HTTP页面的所有信息将都以纯文本形式进行传输，并且默认不提供任何加密措施。因而在数据传输过程中易被攻击者监听、截获和篡改，典型的攻击流程为攻击者通过Fiddler、Wireshark等抓包工具进行流量监听，截获传输的敏感信息（例如数据库密码、登录密码等），最后攻击者根据自身意图对敏感数据进行篡改并发送至服务端，进而导致数据泄露的风险。传统单体应用架构中，由于网络拓扑相对简单，且应用通信多基于HTTP/HTTPS，因而造成的数据泄露风险多是因为采用了HTTP协议。微服务应用架构中，网络拓扑相对复杂，因遵循分布式的特点，应用间的通信不仅采用HTTP/HTTPS协议，还采用gRPC等协议，由于gRPC协议默认不加密，因而将会导致攻击面的增多，为数据泄露带来了更多的风险。3.1.2  未授权访问的风险云原生环境中，应用未授权访问的风险多是由于应用自身漏洞或访问权限错误地配置导致。3.1.2.1 应用漏洞带来的风险应用漏洞是造成未授权访问的一大因素。未授权访问漏洞非常之多，较为常用的如Redis、MongoDB、Jenkins、Docker、Zookeeper、Hadoop等应用都曾曝光过相关漏洞，例如Docker曝出的Docker Remote API未授权访问漏洞，攻击者可通过Docker Client或HTTP请求直接访问Docker Remote API，进而对容器进行新建、删除、暂停等危险操作，甚至是获取宿主机shell权限。再如MongoDB未授权访问漏洞，该漏洞造成的根本原因在于MongoDB在启动时将认证信息默认设置为空口令，从而导致登录用户可通过默认端口无需密码对数据库进行任意操作并且可以远程访问数据库。从漏洞成因的出发点来看，认证及授权机制的薄弱是其主要原因，在单体应用架构下，应用作为一个整体对用户进行认证授权，且应用的访问来源相对单一，基本为浏览器，因而风险是相对可控的，微服务应用架构下，其包含的所有服务均需对各自的访问进行授权，从而明确当前用户的访问控制权限，此外，服务的访问来源除了用户外还包含内部的其他服务，因而在微服务架构下，应用的认证授权机制更为复杂，为云原生应用带来了更多的攻击面。3.1.2.2 访问权限错误配置带来的风险由于运维人员对用户的访问权限进行了错误配置，进而会增大被攻击者利用的风险。例如，运维人员对Web应用访问权限进行相应配置，针对普通用户，运维人员应只赋予其只读操作，若运维人员进行了错误的配置，例如为普通用户配置了写操作，那么攻击者便会利用此缺陷绕过认证访问机制对应用发起未授权访问攻击。传统应用架构中，应用由于设计相对单一，其访问权限也相对单一，几乎只涉及用户对应用的访问权限这一层面，因此对应的访问权限配置也相对简单。因为访问权限配置简单的特点，用户身份凭据等敏感信息常存储在应用的服务端，一旦攻击者利用配置的缺陷对应用发起未授权访问入侵，就有可能拿到所有保存在后端的数据，从而造成巨大风险。微服务应用架构下，由于访问权限还需涉及服务对服务这一层面，因此将会导致权限映射关系变得更加复杂，相应的权限配置难度也在同步增加，例如一个复杂应用被拆分为100个服务，运维人员需要严密地对每个服务赋予其应有的权限，如果因疏忽导致为某个服务配置了错误的权限，攻击者就有可能利用此缺陷对服务展开攻击，若该服务中包含漏洞，进而可能会导致单一漏洞扩展至整个应用的风险。所以如何对云原生应用的访问权限进行高效率管理成为了一个较难的问题，这也是导致其风险的关键因素。3.1.3 被拒绝服务的风险被拒绝服务是应用程序的面临的常见风险。造成拒绝服务的主要原因包括两方面，一方面是由于应用自身漏洞所致，例如ReDoS漏洞、Nginx拒绝服务漏洞等，另一方面是由于访问需求与资源能力不匹配所致，例如某电商平台的购买API由于处理请求能力有限，因而无法面对突如其来的大量购买请求，导致了平台资源（CPU、内存、网络）的耗尽甚至崩溃。这种场景往往不带有恶意企图，而带有恶意企图的则主要以ACK、SYNC泛洪攻击及CC（Challenge Collapsar）等攻击为主，其最终目的也是应用资源的耗尽。3.1.3.1应用漏洞带来的风险应用漏洞可以导致应用被拒绝服务，那么具体是如何导致的呢？以ReDoS（Regular expression Denial of Service）漏洞为例，ReDoS为正则表达式拒绝服务，攻击者对该漏洞的利用通常是这样的一个场景，应用程序为用户提供了正则表达式的输入类型又没有对具体的输入进行有效验证，那么攻击者便可通过构造解析效率极低的正则表达式作为输入进而在短时间内引发100%的CPU占用率，最终导致资源耗尽，甚至应用程序崩溃的风险。3.1.3.2访问需求与资源能力不匹配带来的风险此处以CC攻击举例，其攻击原理通常是攻击者通过控制僵尸网络、肉鸡或代理服务器不断地向目标主机发送大量合法请求，从而使正常用户的请求处理变得异常缓慢。传统Web场景中，攻击者利用代理服务器向受害者发起大量HTTP GET请求，该请求主要通过动态页面向数据库发送访问操作，通过大量的连接，数据库负载极高，超过其正常处理能力，从而无法响应正常请求，并最终导致服务器宕机。在微服务应用架构下，由于API数量会随着服务数量的递增而递增，因而可能将会导致单一请求生成数以万计的复杂中间层和后端服务调用，进而更容易引起被拒绝服务的风险，例如若微服务应用的API设计未考虑太多因单个API调用引起的耗时问题，那么当外部访问量突增时，将会导致访问需求与资源能力不匹配的问题，使服务端无法对请求作出及时的响应，造成页面卡死的现象，进而会引起系统崩溃的风险。3.2 云原生业务带来的新风险云原生应用业务风险和云原生应用风险有何区别？云原生应用风险主要是Web应用风险，即网络层面的风险，而云原生应用业务风险无明显的网络攻击特征，多是利用业务系统的漏洞或规则对业务系统进行攻击来牟利，从而造成一定的损失。此外，与传统应用架构中的业务风险不同，微服务应用架构中，若服务间的安全措施不完善，例如用户授权不恰当、请求来源校验不严格等，将会导致针对微服务业务层面的攻击变得更加容易，例如针对一个电商应用，攻击者可以对特定的服务进行攻击，例如通过API传入非法数据，或者直接修改服务的数据库系统等。攻击者可以绕过验证码服务，直接调用订单管理服务来进行薅羊毛等恶意操作。攻击者甚至可以通过直接修改订单管理和支付所对应的服务系统，绕过支付的步骤，直接成功购买商品等。综上，应用微服务化的设计模式带来的业务风险可包含两方面，一方面是未授权访问风险，典型场景为攻击者通过权限绕过对业务系统的关键参数进行修改从而造成业务损失，另一方面则是API滥用的风险，典型的是对业务系统的薅羊毛操作。3.2.1 未授权访问的风险在云原生业务环境中，造成未授权访问风险的原因，可以大致分为业务参数异常和业务逻辑异常两方面，为了更为清晰的说明上述异常如何导致未授权访问的风险，这里以一个微服务架构的电商系统举例说明。如图1所示：图 1某电商系统流程图3.2.1.1业务参数异常带来的风险API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于0等。若API对相应参数的监测机制不完善，那么攻击者便可通过输入异常参数导致业务系统受到损失。例如在图1所示的电商系统中，若商品价格只在商品介绍服务中进行校验，而未在订单管理和支付服务中进行校验，那么攻击者则可以通过直接调用订单管理和支付服务的API将订单价格修改为0元或者负值，从而给业务系统造成损失。3.2.1.2业务逻辑异常带来的风险相比于前一类异常，此类异常一般较为隐蔽。攻击者采用某些方法使API调用的逻辑顺序出现异常，包括关键调用步骤缺失、颠倒等。例如在图1所示的电商系统中，攻击者可以利用漏洞绕过支付的步骤直接提交订单。这样就会出现业务逻辑关键步骤缺失的情况，进而会为业务系统带来损失，例如验证码绕过异常就属于业务逻辑异常的一种。3.2.2 API滥用的风险针对此类风险，通常指的是攻击者对业务系统的薅羊毛操作，风险成因则是由于业务频率异常所致，这里以电商系统举例说明。业务频率异常主要指针对一个或一组API的频繁调用。业务系统往往通过图形验证码的方式来避免机器人刷单的操作。例如在图1所示的电商系统中，攻击者可以绕过验证码所对应的服务，直接对订单进行操作，进而实现机器刷单，对电商进行薅羊毛。四. 云计算模式变革带来的新风险作为一种新的云计算模式，Serverless具备许多特性，典型的主要有输入源的不确定性、服务器托管云服务商、供应商锁定等，这些特性可能会给Serverless带来新的风险。此外，由于Serverless最终呈现的还是多个函数组成的应用，且被Serverless提供的服务端运行，因此Serverless风险还应包括Serverless应用的风险及Serverless平台的风险。最后Serverless因购买、部署成本低、函数访问域名相对可信等将会使Serverless面临被滥用的风险。4.1 Serverless特征带来的风险4.1.1  输入源不确定带来的风险Serverless函数是由一系列事件触发的，如云存储事件（S3、Blobs和其他云存储）、流数据处理（如：AWS Kinesis）、通知（如：SMS、电子邮件、IoT）等，鉴于此特性，我们不应该把来自API调用的输入作为唯一攻击面。此外，我们不再控制源到资源间的这条线，如果函数被邮件或数据库触发，将无处可设置防火墙或任何其他控制措施来验证事件源。可见输入源的不确定性将可能导致一定的风险。在传统应用程序开发中，开发者根据自身实践经验，在数量有限的可能性中可判定出恶意输入来源，但Serverless模式下函数调用是由事件源触发，输入来源的不确定性限制了开发者的判定。例如当函数订阅一个事件源后，该函数在该类型的事件发生时被触发，这些事件可能来源于FaaS平台，也可能来源于未知的事件源，对于来源未知的事件源可以被标注为不受信任。在实际应用场景中，如果开发者没有良好的习惯对事件源进行分类，则会经常导致将不受信任的事件错认为是FaaS平台事件，进而将其视为受信任的输入来处理，最终带来了风险。 具体地，输入来源的不确定性会为Serverless应用带来注入的风险，与传统应用相同的是，注入攻击过程与并无太大区别，不同的是攻击向量的变化，传统应用中用于注入攻击的向量通常指攻击者可以控制或操纵应用输入的任何位置，但Serverless应用由于输入的不确定性因而带来了更大的攻击面。4.1.2 服务托管云服务厂商带来的风险传统应用中，例如Web应用常部署在本地/远程服务器上，关于服务端的操作系统漏洞修补、网络拓扑的安全、应用在服务端的访问日志及监控等均需要特定的运维人员去处理，而Serverless的服务器托管云服务商的特点将导致开发者无法感知到服务器的存在，实际上开发者也无须对服务器进行操作，只需关注应用本身的安全即可，服务器的安全则交由云厂商管理Serverless的这一特征实际上降低了安全风险。4.1.3  供应商锁定带来的风险“供应商锁定”是指用户依赖特定供应商提供的产品及服务，并且在不产生实质性转换成本或运营影响的情况下无法使用其他供应商的云服务，在Serverless中，“供应商锁定”是目前存在的一大问题，例如用户选择AWS作为应用的运行环境，由于一些原因，该应用需迁移至Microsoft Azure平台，但“供应商锁定”的问题导致无法轻易的将之前运行的应用及使用的相应资源如S3存储桶等平滑迁移至Microsoft Azure平台中，进而导致企业面临应用转换成本的风险。4.2 Serverless应用风险Serverless应用属于云原生应用，其应用本身与传统应用基本是相同的，唯一区别是应用代码编写需要参照云厂商提供的特有代码模版，而传统应用通常没有这个限制。Serverless应用属于云原生应用，云原生应用又源于传统应用，因而传统应用面临的风险几乎可以全面覆盖Serverless应用风险，关于风险分析部分可以参考之前传统应用风险的内容，更详细的内容可以参考OWASP组织在2017年发布的Serverless应用十大风险报告。4.3 Serverless平台风险Serverless平台主要指FaaS平台，目前主流的FaaS平台分为两种类型，一种是面向公有云提供商的FaaS平台，常见的有AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等，另一方面则是面向私有云的FaaS平台，此类以开源项目居多，且均支持在Kubernetes上进行部署，常见的有Apache OpenWhisk、Kubeless、OpenFaaS、Fission等。类似在IaaS平台上运行虚机、PaaS平台上运行操作系统和应用，FaaS平台较之上述平台的主要区别为其运行的是一个个Serverless函数。FaaS平台自身负责云环境地安全管理，主要包括数据、存储、网络、计算、操作系统等。4.4 Serverless被滥用的风险Serverless被滥用具体是指攻击者通过恶意构建Serverless函数并利用其充当整个攻击中的一环，这种方式可在一定程度上规避安全设备的检测。导致Serverless被滥用的原因主要包括以下几点：1. 云厂商提供Serverless函数的免费试用近些年，各大云厂商为了用户体验，均对用户提供免费的Serverless套餐，包括每月免费的函数调用额度，这种方式虽然吸引了更多的用户去使用Serverless函数, 但也使得攻击者的攻击成本大幅降低。2. 用户部署Serverless函数的成本低由于Serverless服务端托管云厂商的机制，故用户只需实现函数的核心逻辑，而无须关心函数是如何被部署及执行的，利用这些特点，攻击者可以编写对其有利的Serverless函数并能省去部署的成本。3. Serverless函数访问域名可信当用户部署完Serverless函数后，需要通过触发器去触发函数的执行，通常用户使用云厂商提供的API网关作为触发器，创建API网关触发器之后，云厂商会为用户提供一个公网的域名，用于访问用户编写的Serverless函数。需要注意的是，该公网域名通常是云厂商域名相关的子域名，因而是相对可信的，鉴于此，攻击者可以利用函数访问域名的可信去隐藏其攻击资产，躲避安全设备的检测。五. 总结本文详细分析了云原生应用面临的风险，可以看出，云原生应用相比传统应用面临的风险主要为应用架构变革及新的云计算模式带来的风险，而针对应用本身的风险并无较大变化，因而对云原生应用架构和无服务器计算模式的深度理解将会有助于了解整个云原生应用安全。参考文献 https://owasp.org/www-project-top-ten/ https://owasp.org/www-project-api-security/  https://netflixtechblog.com/starting-the-avalanche-640e69b14a06  https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project  https://github.com/apache/openwhisk  https://github.com/kubeless/kubeless 

传统数据中心的架构并非为了保护现代云应用而建。我们现在正在经历一次应用开发的“复兴期”，组织正在改变应用的开发和运行方式。▶ 公有云上的应用随着企业加速他们的云端迁移，应用正在越来越快地在公有云平台完成开发。公有云让开发者在应用的开发和部署上有更多的灵活性。结构就产生了以下的变化：虚拟机或者基于用例的应用基于容器的应用不急于服务器的应用▶ 基于业务的应用不仅仅应用的部署位置发生了改变，应用的开发方式也发生了变化——或者说现在的应用是从业务出发进行开发了。越来越多的应用通过被详细定义的API进行微服务沟通的方式开发。这些API通常是远程或者外部的。这就意味着一个应用可以用多种方式达成一个工作，包括：通过Twilio发送信息通过AWS S3储存和追溯图像通过Mailchimp发送电子邮件通过 Snowflake储存和追溯整排数据通过Datadog记录日志（图片来自DarkReading）▶ 一种新类型的流量应用位置的改变（公有云）和应用开发方式的改变（基于服务）就带来了一种新的流量：应用发起的向SaaS、PaaS和公网的连接。一般而言，应用连接指向的服务终端一般都会基于一个完全限定域名（fully qualified domain name, FQDN）或者URL进行识别，而在解析的时候会被转化成成百上千的IP地址。这些IP地址列表是动态的。同时，云服务商的本地安全控制，比如ACL、安全组、路由表等，都是基于IP地址的。因此，如果要稳定地使用这些公有云的各类连接，安全控制必须要允许连接指向任何IP地址——这就会造成攻击面远远超过企业愿意承受的大小。在企业完全开发这些控制之前，通向外部的传输被限制在一部分安全名单中的IP地址和IP范围。因此，如果一个应用或者计算资源遭到攻击，它能传输的范围依然会被限制在一部分安全目标内。但是现在，如果这些针对出口流量能够连接到任何IP地址，一个被攻陷的应用用例会造成以下的结果：成为C2服务器的一部分，并且进行恶意活动，如传播恶意软件、挖矿、终端运作、DDoS攻击等。从VPC中窃取数据。毫无疑问，企业需要针对这些由应用和机器发起的出口流量有更好的管理和控制。简而言之，企业必须有一个完整安全策略图谱，可以直接用于应用和DevOps团队；图谱不应该过于复杂，或者需要安全团队对每个应用和场景都来回进行协助。▶ 安全从可视化起步鉴于人们无法按保护自己看不见的东西，企业该如何获得公有云里出口流量的可视化能力呢？在以前的数据中心世界，网络安全解决方案有一条清晰的边界进行划分。这些结构往往会有一个定义明确的解决方案，通过占据所有流量必经之路的方式达成可视化效果。（图片来自DarkReading）但是，公有云是没有一个明确的边界的。任何资源都能在一键之中暴露到公网上，无论是一个公开安全组规则，或者是ACL、公开路由表条目、接口的公共IP地址——任何一个或是几个的组合。想要在公有云中找到一个必经之路不仅仅是困难而已，在某些时候，这根本就不可能做到。举个例子，当应用发起连接到外部地址的时候，第一步是解析目标的DNS。在公有云，没有任何资源可以接入该流量——因为一般都是由云服务商处理DSN解析。因此，任何设计用于传统数据中心的运营方案，在公有云中都毫无作用。这就是传统网络监控和安全厂商无法提供一个同时有公有云可视化和实现能力的完整解决方案的原因。 （图片来自DarkReading）▶ 基于准确的假设解决可视化和控制问题毫无疑问，应用开发和架构的未来在公有云——甚至对很多组织而言，这不是未来，这就是当下。在新环境中保护数据、应用和服务对企业防范数据泄露和经济损失而言至关重要。传统的数据中心解决方案都是基于了大量不再现实的假设而创建的，在公有云中毫无办法。企业必须基于准确的假设，在公有云时代针对云端，开发和实现从云端诞生的解决方案。数世点评：摸清家底只是安全防范的第一步——摸清家底以后，家里发生了什么，对外在进行怎样的交互是新的挑战。云端的复杂化境、安全边界的模糊、以及攻击面的扩大无不对云端可视化能力提出了极大的挑战——而挑战往往也带来了新的机遇。云端的安全可视化能力会逐渐成为企业关注的焦点。关键词：安全可视化；云安全管理▶ 相关文章2021顶级云访问安全供应商【调查】大型云服务提供商比企业自身更安全云原生带来的云安全机遇云安全风险为何转向身份与授权？多云战略的杀手锏：云不可知 云原生业务艰难维系安全 本文始发于微信公众号（数世咨询）：为何安全可视化对公有云安全如此重要？