SBOM 为基础的云原生应用安全治理为基础的 云原生应用安全治理 董毅@悬镜安全 一瓶“牛奶”——你会喝吗? 安全的保障——成分清单和监管机构 • 成分清单用于实现可见性(透明度) • 监管机构保障成分清单的可信度 软件物料清单 • 软件物料清单(SBOM, Software Bill Of Material)是代码库中所有开放源代码和第三方组件的清单。 • SBOM能够列出管理这些组件的许可证,代码库中使用的组件的版本及其补丁程序状态。 水平/垂直越权、短信轰炸、批量注册、验 证码绕过等 合规需求、安全配置 未能满足安全合规、未建立安全基线、敏 感数据泄漏 开源组件/闭源组件 CNNVD、CNVD、CVE等 开源许可风险 自研代码 容器环境镜像风险 软件漏洞、恶意程序、敏感信息泄漏、不安全配 置、仓库漏洞、不可信镜像 容器环境 开 发 模 式 : 瀑 布 > 敏 捷 > D e v O p s 应 用 架 构 : 大 型 系 统 > > 混 源 服 务 器 : 物 理 机 > 虚 拟 化 > 容 器 化 聚焦到应用系 统风险源头 API安全性 失效的用户认证、安全性、错误配置、注入等 闭源组件 软件物料清单的描述 软件物料清单(SBOM, Software Bill Of Material)是云原生时代应用风险治理的基础设施。 特点: • 是治理第三方组件风险(开源+闭源)的必备工具; • 可深度融合于DevOps应用生产模式;0 码力 | 30 页 | 2.39 MB | 1 年前3
2.2.7 云原生技术在2B交付中的实践云原⽣技术在2B软件交付的实践 曾庆国 北京好⾬科技有限公司 技术负责⼈ ⽬ 录 2B软件交付的困局 01 云原⽣与云原⽣应⽤ 02 ⾯向交付的应⽤模型 03 2B交付版本的DevOps 04 2B软件交付的困局 第⼀部分 SaaS 服务模式⾼速发展,但⽬前⼤多数2B领域的软件 交付,依然以传统交付模式为主。 产业互联⽹升级使得2B软件服务市场需求旺盛 什么是2B软件交付 01 2B软件交付的困局 ⾯向企业⽤户交付软件价值的过程 (1)产品研发流程管理 (2)产品版本管理 (3)概念验证,POC 管理 (4)客户个性化定制(价值最⼤化的关键) (5)客户应⽤的持续交付 (6)客户应⽤⽣产稳定性保障 (SLA) 追求价值最⼤化 A. ⾼效的产品交付模式; B. ⾼效的产品定制开发模式; 微服务应⽤成为2B软件的架构主流 01. 2B软件交付的困局 64% SpringCloud Dubbo 其他微服务架构 传统架构 微服务应⽤成为2B软件的架构主流 01. 2B软件交付的困局 微服务是⽬前⼤多数B端业务的⾸选架构 组件复⽤ 按需运维 灵活定制 客户/项⽬要求 运维困难 交付困难 分布式难题 2B软件交付需求多样性 01. 2B 软件交付的困局 交付模式 定制化独⽴交付 标准独⽴交付 SaaS交付+定制交付 SaaS交付0 码力 | 31 页 | 6.38 MB | 1 年前3
中国移动磐舟DevSecOps平台云原生安全实践和研发工具支撑。助力企业产品快速创新迭代,进行 数智化化转型、实现业务价值。 • 端到端自动化交付流水线 • 开发过程自主可控 • 一键发布上磐基,实现“乘舟上云,稳如磐基” • 沉淀IT软件资产,核心代码掌控 • 提升开发交付效率 一键 上磐基 构建 打包 容器 化镜 像 自动化 部署 研发安 全扫描 需求 设计 敏捷 开发交付协同 云原生DevSecOps 安全工具链 直属单位7个。4.7万人次登录,月活2077人。 科技创新成果 中国移动作为国家级高新技术企业,在国内外行业中科技创新成果丰硕。磐舟与磐基团队重视自主创 新与生产融合,拥有多项专利、高新技术、软件著作权等研发成果,建立了领先和成熟的研发体系。 ü 可信云容器解决 方案认证 ü 2021年云安全守卫者 计划优秀案例 ü DevOps解决方案最高等 级先进级的现场认证 ü 2021年通信行业云计算领域风云团队奖 自适应安全(持续监控&响应) SEC 安全需求 业务需求进来以后从五个维度对业务需求进行安全分析 威胁分析模型 威胁资源库 安全需求基线 威胁情报库 病例库 安全开发-安全需求分析 安全需求分析通过将安全策略左移至软件开发生命周期的初始阶段,着重在需求设计环节确定关键安全要求,旨在降低风险暴露 并增强产品安全质量。安全团队针对企业内部的业务流程和场景展开威胁建模与风险识别,同时依据实际生产漏洞的运营情况完 善0 码力 | 22 页 | 5.47 MB | 1 年前3
云原生安全威胁分析与能力建设白皮书(来源:中国联通研究院)全等,应用于云原生环境,构建安全的云原生系统; (2)安全产品具有云原生的新特性,如轻/快/不变的基础设施、弹性服务 云原生安全威胁分析与能力建设白皮书 14 编排、开发运营一体化等。通过软件定义安全架构,构建原生安全架构,从而提 供弹性、按需、云原生的安全能力,提高“防护—检测—响应”闭环的效率; (3)在安全设备或平台云原生化后,提供云原生的安全能力,不仅适用于 通用云原生、5 APISIX[14] 的 RCE 漏洞、 服务网格 Istio[15] 的未授权访问或 RCE 漏洞等。 2.5 路径 4:微服务攻击 云原生安全威胁分析与能力建设白皮书 30 微服务是一种软件架构模式,把一个应用拆分成多个服务,每个服务间通过 约定的 API 接口方式进行通信,从而形成一个整体的应用系统。微服务可以部 署在不同的服务器上,也可以部署在相同的服务器不同的容器上。当前应用产生 的不同开发语言进行编写。图 9 展示了微服务场景下可能存在的攻击类型。 图 9 针对微服务进行攻击的路径分析 2.5.1API 攻击 API 是一种计算接口,定义了软件之间的数据交互方式、功能类型。随着互 联网的普及和发展,API 从早期的软件内部调用的接口,扩展到互联网上对外提 供服务的接口。调用者通过调用 API,可以获取接口提供的各项服务,而无须访 云原生安全威胁分析与能力建设白皮书 310 码力 | 72 页 | 2.44 MB | 1 年前3
23-云原生观察性、自动化交付和 IaC 等之道-高磊应用 软件环境 硬件环境 遗留系统 安装配置点 安装配置点 安装配置点 集成点 集成点 集成点 1. 交付人员学习手册文档,需要在客户 环境做“安装配置”和“与遗留系统集成” 两方面工作。 2. 安装配置:在硬件上安装软件,不乏 针对硬件特性的适配、还需要安装OS 等,最后还要在OS上安装应用,并且 还要保证应用软件依赖拓扑结构不会 出错。 3. 集成点:包括新环境的硬件、软件和 应用与遗留系统的集成,比如,监控、 背后的原因在于特定环境依赖或者运维规范问题渗透到了PaaS本身, 或者大家常说的定制化场景,如果不进行解耦就会有长期存在的矛盾。 • 为了应付定制化,客户需要等待平台研发的排期,因为平台研发需要定制 化处理定制化场景下的软件、运维工具或者规范等等,并需要不断的测试。 • 为了应付各类的环境的问题,势必要求交付人员的能力非常强,也是成本 居高不下的原因之一。 在K8s这种环境中,存在两种定制化的手段:其一是Deployment 典型的ISV交付场景,目前 大部分业务企业不具备或 者不擅长软件研发和交付 的工作,一般都委托给第 三方ISV来完成客户交付。 • 由于OAM方式的整体化交 付很好的适应了不同环境 的差异,所以ISV自动化交 付成为现实,进一步降低 了交付的成本。 标准化能力-微服务PAAS-OAM交付流程模式-场景流程 • SaaS化是一种新型的软件销售模 式,用户需要任何安装,就可以 付费使用。 • SaaS贴近业务化场景,所以具备0 码力 | 24 页 | 5.96 MB | 6 月前3
22-云原生的缘起、云原生底座、PaaS 以及 Service Mesh 等之道-高磊企业从信息化到数字化的转型带来大量的应用需求 软件组件 运行环境 部署平台 …… …… 应用丰富及架构演进带来的开发和运维复杂性 本地IDC 虚拟化 超融合 公有云 …… 测试环境 生产环境 复杂的应用软件架构,在开发、测试、运维 团队之间建成了认知的“墙”,团队间配合效 率低,故障排查慢,阻碍了软件价值的流动 无法满足用户对于业务快速研发、 私有云市场规模 645.2亿 投 入 技 术 运 维 纳 管 规 模 9%客户投入占总IT投 入的一半以上 成为主要支出方向 中心集群规模为主 部署形态多元化、多云/混合云架构成为主流 自动化 用户软件发布方 式正在向自动化 转变 容器 60%以上用户已 经在生产环境应 用容器技术 微服务 微服务架构成为 主流,八成用户 已经使用或者计 划使用微服务 Serverless Serverless技术显 展 由于历史遗留或者软件形态所限制,不可能所有的软件都可以被微服务化或被容器化,那么现在阶段来看,整个 数字化转型的一些困难就是处于在技术上的碎片化,为云原生彻底发挥对极端变化的适应性价值还有很多障碍。 在统一的K8s管理面下, 通过一种代理容器(内置 了管理虚拟机的逻辑) 来启动虚拟化Pod, 此时可以同时在统一的 容器云平台下运行微服 务化容器化或者未容器 化的传统软件了; 另一个方向是,将底层计0 码力 | 42 页 | 11.17 MB | 6 月前3
27-云原生赋能 AIoT 和边缘计算、云形态以及成熟度模型之道-高磊SLB会根据算力资源需要进行切流。 • 混合云本质是一种资源运用形式,资源 使用地位不对等,以私有云为主体。 控制台 控制台 高级能力-多云(资源角度) 调研机构Gartner公司指出,80%的内部部署开发软件现在支持云计算或云原生,不断发展的云计算生态系统使企业能够更快、 更灵活、更实时地运营,从而带来竞争压力。接受云原生和多云方法作为一种新常态,意味着企业可以避免云计算供应商锁定, 可以提供超过5个9 企业IT文化、工作流程、知识体系、工具集的总合升级 • 应用架构升级 • re-platform • re-build • re-host • 运维模式升级 • 从传统面向操作规则的运维转变为面向观测数据的自动化运维 • 重新定义软件交付模式 • 整体打包交付 • Git=Single Version Of Truth • 声明式API • 尽量采用OpenAPI作为系统集成胶水 • 重塑研发流水线 • 任何变更都提交git,有迹可循 术障碍。 OAM统一交付能力 基于OAM的软件交付理念和工具重新定义了内部的DevOps流程,实现了应用的“一键安装、多 处运行”的应用编排目标 AIOps精细化运维 依托于K8S和ServiceMesh等度量数据精确性的提升,并给予AI算法从不同维度计算应用架构运 行态势,实现基于响应的自动化运维方案,大大降低了用户使用门槛,更安全更可靠的交付 最终软件产品。 目前的重点在于底座进一步实现应用0 码力 | 20 页 | 5.17 MB | 6 月前3
24-云原生中间件之道-高磊种推荐方式。 如果在被动模式下运行IAST,那么开发测试过程 中就可以完成安全扫描,不会像DAST一样导致业 务报警进而干扰测试,同时由于污点跟踪测试模 式,IAST可以像SAST一样精准的发现问题点 SCA(软件成分分析) 有大量的重复组件或者三方库的依赖,导致安全漏洞被传递或者扩散, SCA就是解决此类问题的办法,通过自动化分析组件版本并与漏洞库相 比较,快速发现问题组件,借助积累的供应链资产,可以在快速定位的 是对第三种场景,一直以来缺少保护手段。通过加密技术建立的可信运 行环境TEE(比如IntelSGX,蚂蚁的KubeTEE等)可以保护运行中的数据和 代码,完成了安全闭环。 依赖于硬件和更高阶密码学,可以彻底阻断物理 设备以及软件的攻击,是高级的安全保障技术。 TEE是运行态主动防护的高级手段,对高安全生产 环境建议使用。 成本较高,所以要视业务场景要求取舍。 Mesh零信任 mTLS服务间访问授权,主要针对Pod层WorkLod的访问控制 量突增,尤其对于实时计算,需要资源 能够及时的扩容,以满足业务需求。尽管一些大数据管控平台尝试实现自动的扩缩容(如通过集群负载情况,进行扩 容),然而,在传统大数据平台架构下,通常需要资源申请、依赖软件安装、服务部署等一系列步骤,该过程通常比 较慢,对于集群负载的缓解,不够及时。 • 在离线分离部署及粗粒度调度无法提高资源的利用率:在传统Hadoop架构下,离线作业和在线作业往往分属不同的集 群,0 码力 | 22 页 | 4.39 MB | 6 月前3
09-harbor助你玩转云原生-邹佳Harbor-助你玩转云原生 关于我 Steven(佳) Zou(邹),VMware中国研发中心主任工程师, Harbor开源项目架构师及核心维护者,拥有十多年软件研发及 架构经验,获得PMP资格认证及多项技术专利授权。曾在HPE、 IBM等多家企业担任资深软件工程师和架构师,专注于云计算及 云原生等相关领域的研究与创新。著有《Harbor权威指南》等 书籍。 >> Email: szou@vmware 云、私有云 和混合云)构建和运行可扩展的应用程序。云原生典型技术包括容器、服务网络、 微服务、不可变基础设施和声明性API等。 v1.0 by CNCF 容器-更轻量级和灵活的虚拟化 镜像-应用软件打包与分发 OCI: https://opencontainers.org/ OCI制品(artifact):镜像,Helm Chart,CNAB,OPA bundle等等 云原生与制品管理 [2]0 码力 | 32 页 | 17.15 MB | 6 月前3
1.3 MOSN 在云原生的探索及实践2020年7月 2020年12月 2021年 MOSN 简介 — 开源社区 Committer 非蚂蚁 蚂蚁 定位:云原生网络代理平台 开源理念 社区是开源软件发展的动力 借力开源,反哺开源 持续向云原生演进 Star: 3100 Committer: 10 Contributor: 78 Corporate users: 20+ Commits:0 码力 | 36 页 | 35.61 MB | 1 年前3
共 11 条
- 1
- 2













