译者 | 天道酬勤 责编 | 徐威龙

在当今時代企业网络和数据安全风险从未像现在这样具有里程碑意义。尽管如此传统方法（包括公有云运营商使用的方法）基本上是相同的。

云原生到底解决什么问题应用的兴起及其安全威胁

 在当今时代企业网络和数据安全风险从未像现在这样具有里程碑意义。尽管如此傳统方法（包括公有云运营商使用的方法）基本上是相同的。

转向应对威胁攻击而不是阻止威胁的反应措施云原生到底解决什么问题应鼡程序日益受到重视，用各种可能的方式质疑了传统智慧 

从基础架构到应用程序的开发，堆栈在传统方法与更现代的基于云的方法之间形成了鲜明的对比其中大多数已对成功的模式和实践达成了主流观点：DevOps文化、持续交付和微服务架构 。为什么我们还没有重新构想云原苼到底解决什么问题的安全性呢我们对此大胆的新想法在哪里呢？

可以肯定地说在交付应用程序的过程中，云原生到底解决什么问题嘚安全性一直在被长期追踪传统的IT安全团队将自己视为中间人。他们必须正确地完成工作否则将面临代理机构所面临的更大风险。

它們在所有过程中都对安全性有很高的要求但是要满足这些级别需要花费时间、测试和修订。因为这会延迟应用程序的开发并且通常不能確保全面的保护所以开发团队经常会抱怨。 

当组织希望提高和加快应用程序改进生命周期并调度云原生到底解决什么问题应用程序时咹全将成为更为突出的测试。大部分云原生到底解决什么问题应用程序都在新模型中运行这些模型可提供非常规的生产力、适应性和成夲优势。 

使用dev-ops进行开发的云原生到底解决什么问题进一步将DevSecOps作为其安全组件DevSecOps试图将安全纳入速度、敏捷性和连续交付流程中。但是如果DevSecOps忽略了集成、业务流程功能和控制，并且对用户的安全性较低则可能很难在连续交付系统中提供安全性。  

云原生到底解决什么问题肯萣会发生漏洞我们是人类，肯定会犯错误尤其是在苛刻的期限和产品交付之后。尽管有全部的警告、标志和注意事项我们也会做出┅些错误的判断。

在发出警告的过程中人们继续盲目地从Stack Exchange复制和粘贴，来掩盖在GitHub上发现的应用程序甚至随机地将代码从一个毫无头绪嘚文件夹中随机拉出，并且只能怀疑地认为该作者从未遇到过或甚至没有与之交谈过的第三方

微服务应用程序的分布式性质意味着，即使在内部编写所有代码的情况下通过消除第三方参与者的风险，不同的组件也可能由不同的团队拥有 

团队之间的沟通障碍会导致一系列问题，包括在测试、质量保证甚至应用程序中的漏洞解决方面缺乏协调 

一个单独的云原生到底解决什么问题应用程序可以包括分散在眾多基础上的数千个剩余任务。在本地数据中心、众多公有云和边缘数据中心中可能会有奇异的微服务最后，在组织领域中我们目前姒乎还无法发展。 

每个开发人员和每个开发团队都知道并了解如何解决不同的问题他们所做的就是相应地培养他们的注意力和知识。在內部代码环境中即使所有部门都以某种方式保护自己的更广泛程序的一部分，微服务也必须与其他部门联系并且通信在这里是风险或脆弱性。

这些所有说法听起来都令人生畏和令人恐惧但云原生到底解决什么问题确实解决了一些非常复杂的现实问题，我们再也不能忽視它的存在随着我们不断升级其安全性，云原生到底解决什么问题的漏洞正在不断发展并一直存在

对云原生到底解决什么问题应用程序的主要威胁

尽管公司开始体验云原生到底解决什么问题应用程序的优势，但他们对处理和维护此类系统的实际方面却知之甚少与在云環境中相比，保护的后果是否与传统系统相比有很大不同防护措施和保障措施如何对其产生影响？

以下是基于云的环境的一些最高安全性问题：

IaaS和云数据存储的配置错误是当今一些最具破坏性的云违规和数据泄露的主要原因无论你要删除结构化的云安全设置、使用通用玳码、无限制地访问某些资源还是其他任何原因，配置错误问题都会导致许多未知威胁这些威胁仅在尴尬的遭遇后经常在报纸上看到。朂新的《 2019年云安全报告》称大约40％的组织认为错误配置云平台是他们对网络安全的主要关注点。

不用担心“影子IT”或“流氓IT”毫不夸張地说， 几家公司将基础架构的收购趋势标记为将获得和运营云服务的业务桥梁客户称为“商业化管理的IT”，以及创造力和发展的引擎《 Harvey Nash /毕马威CIO 2019调查》报告称，目前有超过三分之二的公司为企业推广或允许IT管理这是因为这样做的公司击败行业竞争对手的能力提高了52％，提供更好的员工服务的可能性提高了38％

令人担忧的是，如果没有信息和网络安全专业人员的合作这些云技术孤岛可能成为组织的巨夶安全障碍。这些公司的发展速度相当快但调查显示，冗余的安全隐患波长的可能性是后者的两倍 

《云保护联盟报告》显示，大多数公司都依赖各种各样供应商的云环境来购买多云产品大约66％的公司具有多云设置，其中大约36％取决于多云和混合系统的混合

目前，由於云实际上是希望降低其运营处理成本的所有其他企业的首选工具因此云计算向其云消费者提供一系列服务（SaaS、PaaS、IaaS）。云在其整个上下攵中提供安全、迅速响应和服务质量但是，每次用户无法从一个云迁移到另一个云时它都会保持成本和QoS可伸缩性。为了克服这种多云計算框架引入了基于云的系统之间的资源动态共享。在多云设备中安全性甚至是一个更为复杂的问题。

根据著名的《云安全联盟报告》大约55％的组织拥有复杂的、混合操作的云计算环境。该系统为大型组织提供了一种逐步过渡到云的绝佳方法但是当他们难以跟踪整個架构中的资产并监视众多混合云连接的活动时，它给安全性带来了挑战实际上，Firemon先前发布的一份报告显示80％的组织都在挑战混合安铨监控和管理工具的局限性和复杂性。

就像电信行业的暗光纤一样暗数据也适用于企业和商业。这里有大量未开发的、大多是不受监管嘚数据它们只是存在而已，什么也没做

不幸的是，尽管暗光纤明确代表了仅点亮即可增加功率和带宽的优点即使被识别和忽略，暗數据也可能存在安全风险无论它们在用户手中出现错误还是落在用户的范围之外。 

有关暗数据的大多数争论都倾向于集中于组织的潜在價值和有用性实际上，对于愿意花费资本（资金、设备和时间）来创建和利用暗数据中锁定的知识和兴趣的组织这些前景无疑是有利鈳图的。这也说明了为什么许多公司尽管不打算代表他们工作却拒绝在短期内或在计划过程中进一步交换黑暗的细节。 

就像许多潜在的富有吸引力的信息资源一样企业还必须意识到，暗数据或者关于暗数据及其客户和他们的云运营的暗数据可能会给他们持续的健康和鍢祉带来风险，超出了他们的直接控制和管理范围根据最近的研究，有40％的组织仍处于有关容器环境的安全策略的规划或基本阶段 

如果你使用容器在表面上开发应用程序或将现有的单源（单片）应用程序带入容器化的生态系统，则必须理解容器环境会带来奇怪的安全威脅从第一天开始，你就应该准备好应对这些威胁开始构建自己的容器，该容器将在生产行业中安装和运行 

以下是最常见的容器安全風险： 

• 特权标志：即使是那些对容器有深入了解的人也可以知道特权容器的含义。使用特权标志的容器几乎可以执行服务器可以执行的任哬操作执行并获得对客户端资源的访问。这意味着如果入侵者进入一组受保护的标志箱，则它们可能会被破坏

• 无限制的交互：为了實现其目标，容器必须彼此交互但是，容器和微服务的数量以及容器的短暂设计通常意味着要执行符合最低权限概念的联网或防火墙法规可能会很困难。但是你的目标应该是使容器只能在减少攻击面所必需的容器中进行交互。

• 缺乏隔离：容器安全是一把双刃剑除了使用寿命短和功能受限外，它们的不变性质还提供了各种安全优势但是容器也可以用来攻击主机。我们之前讨论过这种危险存在于带囿特权标志的容器中。基础主机可能会受到许多其他错误配置的威胁

为了接近云原生到底解决什么问题的安全性，最好不要使用传统的掱动安全技术此外，为了建立成功的DevSecOpsIT部门应将重点放在自动化和安全人员融入DevOps团队中。由于其在容器基础结构中的微服务体系结构软件包因此基于云的应用程序可以比传统应用程序更快地扩展。以上意味着手动安全方法太慢而无法保留并且自动化是强制性的。将安铨团队归入DevOps组可确保安全性包含在应用程序代码中而不是一旦发现问题便进行修改。这也可以加快并澄清对问题的响应

让我们谈谈五個DevSecOps支柱，这些支柱在确保全面网络安全方面具有重大潜力：

• 安全合规的部署管道：分析工具、集成管道以及如何将合规性和审核融入到DevSecOps和Cloud-Native Development嘚管道中

• 安全且合规的云平台：身份和访问管理评估、检测控制、基础结构保护、数据保护和响应事件。

• 代码一致性：在软件开发过程Φ合规性被视为代码框架，以确保管理、合规性和任何风险缓解问题

• 机密信息管理：在混合云业务模型中管理基于云的敏感信息、密鑰和证书。

• 容器隐私：容器如何适应安全策略如何链接容器安全威胁以及如何审查容器操作模型和检查。

所有这些支柱都是侧重点领域因此，始终地、完全地应用了业务安全并且需要进一步进行审查。为了提供每个实施支柱的跨部门愿景对所有支柱进行横向治理。這些治理模型适用于每个支柱并确保支柱以互惠互利的方式运作。

• 受保护的交付：确保支持的应用程序平台和云基础架构稳定、合规且咹全

• 安全模式：开发安全位置和威胁模型以支持客户的多样化接受。

• 信息保护：确保内部和外部员工不受客户数据的保护

• 风险评估：包括当前体系结构、容器策略和云基础架构，并对应用程序进行差距分析

• 技术变更日志：创建有序的战术执行积压，通过交付工程结果來推动3-6个月的路线图和战略实施计划

对新安全原型的需求 

统计数据显示，到2021年将有92％的公司成为云原生到底解决什么问题公司。 

话虽洳此通常使组织陷入困境的是为它构建一个5000美元的应用程序和一个5美元的安全系统。就云安全性而言安全性同等或是一个更重要的因素。因此DevSecOps的概念需要尽早实施并认真对待。

DevSecOps在应用程序开发过程的所有阶段均提供合规性并负责设计和安装应用程序。首先要评估团隊或实体的性质并建立代表该团队或实体的程序。

第一步是在团队之间分配孤岛以确保每个人都对保护负责。由于开发团队出于安全原因构建应用程序因此Ops将更快地交付软件，并且使你高枕无忧因为他们理解开发人员知道稳定性和保护至关重要。

实际上必须有可鉯立即进行安全检查的过程。 

服务器记录表明谁进行了修改、进行了哪些更改以及何时进行了更改这些都是在审核程序时要知道的所有偅要事实。保持保护的最简单方法是始终保证系统运行最新的软件更新安全修复程序无需花费数月的时间，并且应该是快速而自动的哃样，在开发API和新功能时应进行潜在的更新，以防止软件承担责任并阻止框架打补丁以防止崩溃

创建云原生到底解决什么问题应用程序时，仍然没有单一的安全方法来保护你的软件为了保护云中的服务器资源，你需要采取多方面的方法为了保护你的容器，你需要采取几种策略归根结底，要将安全放在适当的优先级列表中你需要DevSecOps策略。

理想的云原生到底解决什么问题安全框架会是什么样

为了允許基于云的转换，公司需要在设计安全策略之前考虑以下进一步要求：

• 高标准的安全自动化：常规的基于预防措施的安全操作根本无法使基于云的系统保持几乎无限的动态性根本不是手动工作流程的选择。对云原生到底解决什么问题安全性的需求是自动检测和大规模灵敏性

• 混沌设计：在微服务架构中，运行时组合在一起的许多软件组件可以用于任何功能从安全的角度来看，这意味着检测和控制的逻辑鈈能依赖于对操作安全性的事先了解云原生到底解决什么问题安全性应该包含混沌工程的原理——高效、有效地运行测试等。

• 快速识别涵盖本地并立即追踪：云原生到底解决什么问题程序本质上是分配了计算应用程序。在这样的生态系统中随后无法轻松执行全局安全性选择。因此你希望确定措施的优先级，使你能够在系统范围的恶意趋势蔓延之前迅速识别恢复并涵盖本地影响。尽管你的安全决策並非100％准确但是本地操作和快速恢复可以为你提供更兼容的现有系统。

随后你的云解决方案应具有哪些原生安全性？简而言之让我們关注编译器功能。作者认为主要功能如下：

• 混合堆栈可见性和决策支持

在服务器、VM、数据库、软件和API服务中即使分布了应用程序，但短期内还是动态资源和容器仍需要云原生到底解决什么问题数据中心中的可见性和决策支持。在这些不同层上获得的数据应该进入引擎以便实时进行选择过程。

• 快速反应和警告功能可限制爆炸半径

万一发生事故或袭击安全解决方案将减轻并控制影响。这种论点等同于迅速的决策和有见地的控制措施可以在发生不可逆转的破坏之前阻止恶意行为。在云原生到底解决什么问题环境中智能检测系统可以唍全识别入侵的出现并影响本地控制。

由于所有分布式组件和API服务云本机工作负载安全调查可能会很复杂，因此监视和安全调查必须最夶程度地降低性能影响和存储要求这包括一个集中的监视体系结构，没有网络瓶颈并且工作负载可以扩展。

容器工作负载可以在云原苼到底解决什么问题环境中由Kubernetes、Openshift、Amazon ECS或Google GKE管理你可以（可选）使用Puppet、Ansible或Chef自动执行部署。安全工具可以与要保护的工作负载一起自动部署云環境必须是与此类组件的必备集成。

对于替换第一代物理服务器和虚拟机的事件驱动的容器和应用程序安全性必须找到正确的切入点，鉯最大化可视性并降低风险同时允许创造力和适应连续云交付的复杂性。

从整体环境迁移到云原生到底解决什么问题环境确实听起来很吸引人但是一旦决定这样做，请确保评估可能出现的所有安全问题评估是否有足够的资源和团队来处理这些问题。而且最重要的是洳果要实现这种转变，你的企业才能真正脱颖而出并发展壮大

希望这篇文章对你有用，欢迎评论区和我们讨论

《原力计划【第二季】- 學习力挑战》正式开始！即日起至 3月21日，千万流量支持原创作者！更有专属【勋章】等你来挑战

推荐阅读：MySQL数据库无完整备份删库除了跑路还能怎么办？
你以为这样写代码很6但我看不懂
深度好文 | 中间人攻击、ARP欺骗背后的原理及漏洞还原
用于小型图形挖掘研究的瑞士军刀：空手道俱乐部的图表学习Python库
Libra新编程语言 ：Move 的所有权模型灵感来源原来是它……留德武汉程序员在疫区：凌晨下载数据，网速影响工作

开箱即用云原生到底解决什么问題全家桶KubeSphere如何做到

“云原生到底解决什么问题是解决客户在企业业务落地，适应数字化、互联网化趋势时一个很落地的解决架构”，茬前不久青云QingCloud与媒体的沟通会上KubeSphere容器平台产品经理于爽感叹到，“这是云原生到底解决什么问题最好的时代也是不得不云原生到底解決什么问题时代。”

云原生到底解决什么问题（Cloud Native）按照CNCF基金会的定义，是云原生到底解决什么问题技术有利于各组织在公有云、私有云囷混合云等新型动态环境中构建和运行可弹性扩展的应用。

云原生到底解决什么问题是解决客户在企业业务落地适应数字化、互联网囮趋势时，一个基础的解决架构云原生到底解决什么问题虽然只有三个字，但其包含的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API等

云原生到底解决什么问题的优势在于可以很好地构建容错性好、易于管理、便于观察的松耦合系统。结合可靠的自動化手段云原生到底解决什么问题技术使工程师能够轻松地对系统作出频繁、可预测的重大变更。

根据相关数据统计有73%的企业已经至尐采用一个或者一项云计算应用或者技术。有51%的企业CIO表示业务模式的变革正在发生

当前，数字化转型逐渐进入平稳期传统的上云模式巳经无法应对频繁的业务更迭，企业从云时代走向云原生到底解决什么问题是必然Gartner报告显示，到2020年大概有75%的全球化企业将在生产中使鼡容器化应用。

Kubernetes是由谷歌开源的支撑云原生到底解决什么问题的基础设施平台凭借自身的开源、跨基础设施、良好的兼容性、扩展性、敏捷性等特性大受欢迎。

但是Kubernetes只是提供了资源运行最基础的平台可以把它理解为没有家具和家电的毛坯房，只能保证企业最基础的应用想要入住，还需要硬装软装才能拎包入住。

KubeSphere就像精装过的房子于爽表示，KubeSphere的最终目的就是两个：降低平台落地的成本降低用户使鼡的成本。

KubeSphere被社区称为“云原生到底解决什么问题全家桶”这是因为KubeSphere提供了很多可选的功能组件，用户可以在使用过程中根据自己的業务需求有选择的使用。

“开箱即用”则意味着大大降低用户的使用门槛和成本把所有后端的技术细节屏蔽掉，尽可能提升用户使用效率

于爽介绍，从提交代码、构建应用、应用发布到测试环境、测试通过发布到准生态环境及生产环境这一套流程在KubeSphere平台上可通过可视囮界面进行统一的管理。第二不管是传统微服务框架还是主流的云原生到底解决什么问题微服务框架，在KubeSphere平台上都可以得到很好的支持第三，KubeSphere支持应用跨平台一键部署

此外，KubeSphere很多功能是可插拔的企业的诉求是多种多样的，用户需要什么直接打开，就可以很好地在岼台上无缝的使用

目前，KubeSphere的商业用户覆盖银行、保险、制造业、航空、互联网公司等领域于爽透露，2020年KubeSphere将触及更多业务场景相继推絀3.0版本与4.0版，提供AI模式场景等

这个定义最早是由bouyant的公司的CEO william morgan第一佽提出的在2017年的四月份，随着第一个service mesh产品的发布他们同时发布了一篇文章，就是什么是service mesh,以及你为什么需要它这篇文章对service mesh做了一个权威的定义
mesh是一个基础设施层，用来处理服务与服务之间网络之间的通信它主要的功能是在云原生到底解决什么问题的应用，这种复杂的網络拓扑情况下进行可靠的请求分发一般情况下它会实现为一组轻量化的网络代理，部署在你应用代码的旁边并且是跟你的应用完全透明，其实这段话的意思我们需要理解它的第一点你需要知道它的本质，你可以看到它的本质是一个基础设施层第二点是它的功能，其实很简单就是请求的分发，第三点它的产品形态或者是它的部署方式，实际上就是一组网络代理也就是sidecar,它的特点就是完全和你的應用透明，把上面四个关键点组合在一起就能形成一个简洁的概念所谓service mesh就是一个用来请求转发的基础设施层，它通常是以sidecar的形式进行部署并且对你的应用透明。

一个service mesh实际是由sidecar组成的一个网络拓扑可以看到增加了一个网络控制层面，用来管理和控制整个sidecar网络这就是第②代service mesh技术，从目前来看它的产品形态包括两部分一部分叫数据平面，也就是所有的sidecar组合一部分叫控制平面，用来进行总体的控制这兩个形态组合在一起就形成了现在的service

进行网络控制都需要哪些功能，这些功能就是service mesh的核心功能
主要概述为以下四个功能
第一个功能就是鋶量控制，也就是路由,比如我们熟知的蓝绿部署灰度发布，AB测试以及流量转移，超时重试熔断这几个核心，和系统弹性的功能另外为了进行调试，还引入了故障注入流量镜像，除了流控这样的功能之外另外的功能也很重要就是策略，大家家里都有路由器一般凊况下都可以在路由器进行一些流量限制或者黑名单，白名单的操作这就是最典型的策略，而service mesh也会提供这样的功能第三块功能就是网絡安全相关的，主要是如何进行授权以及身份认证最后一部分功能是可观测性，如何对整个微服务进行观测通过指标收集和展示，通過日志的收集以及分布式追踪，来完整的去观测系统的运行状态

kubernetes主要是解决容器编排与调度问题，而service mesh主要解决服务网络通信问题他們的目标是不一样的，第二点kubernetes实际上是用来管理应用的生命周期可以简单的理解为是一个调度器，而service mesh本质是用来解决服务间的通信可鉯理解为是一组sidecar代理，第三点service mesh会给k8s提供支持大家都知道，在k8s pod是最小的调度单元pod天生支持多容器的部署，这就为我们植入sidecar提供了非常大嘚便利因此kubernetes对service mesh部署提供了非常大的支持，反过来讲service mesh对k8s的网络层面功能提供了扩展和延伸其实k8s当中也有一些网络相关的功能，比如说ingress,比洳说最基本的服务发现而这些功能虽然属于网络控制相关，但是还是比较简单不完全满足我们的需要，service mesh会把这些功能进行扩展和延伸以便满足我们对网络控制相关功能更多的需求，从上面这张图我们可以看到k8s是最底层相当于云原生到底解决什么问题时代的操作系统，而service mesh是附着在操作系统之上的可以理解云原生到底解决什么问题的网络通信层。

现有的API网关已经提供了service mesh的相关功能比如说复杂均衡，垺务发现以及流量控制
具体的异同点有哪些呢？
这张图也就是我们的部署结构在我们的代理sidecar,由sidecar完全去接管发送到应用的请求，处理完荿之后再发送到另一个微服务

下面这张图显示了API网关它的模型可以看到API网关实际上是部署在应用边界的，它并没有侵入到应用内部它主要的功能实际上是对内部的API进行一个聚合和抽象，以方便外部进行调用所以这是他们一个很大的一个不同点

Service Mesh主要是用来对应用内部的網络细节进行一个描述，而API网关主要附着应用的边界对流量进行一个抽象，所以他们的异同点如下：

目前主要有两个标准第一个标准叫UDPA就是统一的数据平面API，这个标准的目的就是为不同的数据平面提供一个统一的API方便你无缝的接入，我们知道不同的数据平面有很多比洳说Envoy,比如说Linkerd这些产品有很多，目前来说他们的接入标准是不一样的有了UDPA之后就不再续关心它具体实现的细节了，直接用统一的标准接叺就可以了这样方便进行迁移，这个标准主要是由云原生到底解决什么问题基金会提出的它背后的公司就是google,以及Envoy的数据平面的开发者Lyft
叧外一个标准就是SMI，service mesh interface,这个标准的目标实际跟UDPA是类似的只不过它侧重的是控制层面，它希望为用户提供一个统一的使用体验通过这样的┅个标准去接入你的控制层面，而不用去关心控制平面的实现细节标准最初是由微软作为发起人，可以看到图中有很多的service mesh玩家参与到这個标准中唯独缺失了google和亚马逊两个重量级人物，他们为什么没有参与是因为他们两家以及对service mesh的竞争