1. 首页
  2. 今日热点

DevOps平台的安全可靠设计

DevOps平台的安全可靠设计

转载本文需注明出处:微信公众号EAWorld,违者必究。

引言:

普元DevOps平台覆盖从需求到运维,力求帮助团队提升工作效率、保障系统质量。在安全可靠层面,平台需要考虑自身如何跨环境且流程合规,还需保障所生产的软件的安全可靠。

本文从流程、代码、介质、环境等角度出发,重点聚焦在安全可靠建设过程中的一些思路与技术支撑,最终形成平台级的建设方法与体系。

目录:

1. DevOps平台的安全可靠涉及哪些方面?

2. DevOps平台安全可靠的设计与实现思路

3. 普元DevOps平台的当前能力与后续计划

1. DevOps平台的安全可靠涉及哪些方面?

众所周知,现在国家对安全可靠、自主可控这些方面的要求很高,也让我们团队重新审视DevOps产品在这方面需要如何改善和演进。

DevOps平台的安全可靠设计

我们从两方面来看平台的安全的可靠:

  1. 平台自身,考虑到DevOps平台的一定特殊性(跨环境、跨部门),在自身的合规、数据隔离等方面显得尤为重要
  2. 软件生产,平台支撑了软件交付的整个过程,在生产过程的各阶段,需要对最终软件的安全可靠形成合力,尽早发现相关风险

一、平台自身的安全可靠

DevOps平台的安全可靠设计

平台自身来看,包含如上图四个方面:

无单点:这里包含两个意思,平台集成的三方中间件较多,需要保障其为集群模式;再一个即使某些中间件完全故障了,也不能影响整个DevOps平台的运行

数据与环境隔离:不同项目、不同团队的数据要保证隔离,一个项目的多套环境,多套介质同样要保证隔离

UI与API的权限控制:对界面的菜单、按钮进行权限控制,对后台api的访问权限进行权限控制

可审计:对于什么人在什么时候在平台上做了什么,在动作前后资源产生了这样的变更

二、软件生产的安全可靠

DevOps平台的安全可靠设计

软件生产过程我们则是从需求、设计开发、构建测试、发布、运维这几个阶段来梳理安全可靠的一些关键点的。

2. DevOps平台安全可靠的设计与实现思路

我们就从平台自身和软件生产两大方面,分别举例来说说安全可靠方面的一些实现思路。

平台自身 — 平台无单点

DevOps平台的安全可靠设计

正如之前对无单点的描述,平台需要解决两类无单点:

比如我们使用了jenkins,jenkins的集群是一主多从的模式,这个存在一定的单点问题(master),之间的通信模式有两种(ssh和jnlp),在多次测试后,最终选择的是jnlp(ssh可靠性存在问题),master单点问题则通过多套jenkins集群来部分解决;

再比如使用jira来进行项目管理,但jira这种商业产品一般不会部署集群,所以平台另一方面要考虑的则是即使jira宕机,仍旧可以保证平台的可靠运行(所以平台还会提供工作项本地存储的模式)。

DevOps平台的安全可靠设计

平台最终的默认部署架构则如上图,每个节点首先要解决自身的可靠方案,考虑到数据和网络的安全,像堡垒机、介质库代理模式也都在整个平台的默认部署架构中。

平台自身 — 数据与环境的隔离

DevOps平台的安全可靠设计

再来看数据与环境的隔离:

DevOps平台的安全可靠设计

比如介质库,首先各项目的介质库要隔离,一个项目的开发库、测试库、投产库同样要隔离,测试通过的介质,则通过可控的同步手段发到投产库。

DevOps平台的安全可靠设计

再比如部署引擎,什么引擎可针对什么环境进行部署操作,也是严格控制的,防止环境操作越权。

DevOps平台的安全可靠设计

再有就是部署的操作,什么人审批还是可自动执行,部署完成后由谁确认(亦或是通过自动化测试确认),这些关键事项,需要结合不同团队的实际情况进行不同的个性化配置。

软件生产 — 需求任务管理的安全可靠

DevOps平台的安全可靠设计

需求任务的管理核心是风险识别,对进度要严格把控,通常包括四个视角:

  1. 当前项目版本中的积压(backlog)情况,一个项目周期中,正常来讲时间过了50%,积压项和完成项也应差不多是1:1的状态
  2. 个人代办的风险,时刻关注团队中每个人的当前积压任务
  3. 当日工作的风险,这在每天的例会上最关注的视角
  4. 特别需求的风险,在敏捷模式下比较常态,将特殊需求调整优先级或直接置顶,并在一定时间窗口由某个人特别关注与跟踪

所以下面的一些看板模式,都是为上述的一些风险识别场景而提供的。

关注项目积压:

DevOps平台的安全可靠设计

关注个人积压:

DevOps平台的安全可靠设计

今日关注与特别关注:

DevOps平台的安全可靠设计

软件生产 — 开发测试的安全可靠

DevOps平台的安全可靠设计

这个阶段的两个核心工件是代码和介质,是需要重点保障安全可靠的。

代码质量包括开发禁止项,代码静态扫描、提交信息合规等,之所以把开发禁止项与静态扫描分开说,主要是目前技术实现上手段区别(目前我们的开发禁止项还不太能通过自动的静态扫描来发现)。

比如开发禁止项的一些具体细项,我们目前还是通过规范、设计和review来做的:

  • 禁止将大量业务数据存在会话区
  • 禁止明文传输敏感数据
  • 禁止使用XA数据源
  • 对表数据10K+的查询必须分页
  • 禁止使用非maven模式依赖三方jar
  • ……

静态扫描,在平台上则是通过集成三方工具来实现,不过相关的代码扫描工具有很多,在具体抉择时,是从下面几个维度来考虑的。

DevOps平台的安全可靠设计

目前在我们平台上集成的是sonar、fortify、checkmarx等,通过在CI流水线中定义,并将执行报告直接展示在安全质量的界面上。

在代码提交时,为保证相关提交有迹可循(解决什么问题),也为后续能够反向统计需求的一些具体开发过程,对代码提交也进行了严格控制,对不符合规范的代码提交,是无法代码入库的(hook控制)。

DevOps平台的安全可靠设计

在介质方面,要做到安全合规,对介质中的一些介质(尤其三方介质),要快速发现其商业风险,比如license:

DevOps平台的安全可靠设计

这里尤其对于一些老系统,里面的jar无法直观的看出来源、版本等,平台是需要帮助项目快速找到源信息,并建立起相关信息库。

在介质管理方面,像黑鸭、杰蛙这些公司已经在这个领域积累了很好的安全库,所以我们也在考虑与这些产品进行合作对接。

软件生产 — 发布的安全可靠

在软件发布时,通过技术保障来屏蔽发布失败的风险。考虑到不同的应用服务器或底层环境的差异,每个中间件上的实现手段则会存在一定的区别,这里以websphere上的应用发布为例:

DevOps平台的安全可靠设计

需要考虑如何备份,卸载后安装还是直接更新,是否需要重启,如何探测部署的成功或失败,失败后是否需要回退,以及如何回退,这些都需要在平台提供的websphere部署任务上可配,才能保证发布的安全可靠。

除了上述部署流程执行外,在部署之前还要有很多的探测或预执行能力,摆阔检查网络可达、脚本执行权限、进程的存活、端口的可用、配置的正确与否,这些都是平台需要内置能力。

3.普元DevOps平台的当前能力与后续计划

最后总结下我们目前在平台安全可靠上所集成的工具以及基于这些做了些什么特性。

DevOps平台的安全可靠设计

在每个阶段通过集成三方的开源或商业工具,来提供上层能力,但也避免被三方绑定,所以会对集成模型与接口进行抽象,并随着不断迭代,自己也能提供下层部分产品能力。

普元DevOps平台的后续计划

DevOps平台的安全可靠设计

后续我们还会积极与厂商合作,同时积累自己在安全、合规这些方面的基线库,并将更多的开放生态中的东西集成进来,不断提升此领域能力。


关于作者:顾伟,现任普元信息主任架构师,长期致力于IT技术研究、产品设计与开发、架构咨询等工作,擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术;对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。

来源:78站长网,欢迎分享转载,请注明出处:https://www.78zhan.com/article/1494.html

Copyright© 2011-2020 78站长网