普元DevOps平台的安全可靠设计

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

引言：

普元DevOps平台覆盖从需求到运维，力求帮助团队提高工做效率、保障系统质量。在安全可靠层面，平台须要考虑自身如何跨环境且流程合规，还需保障所生产的软件的安全可靠。
本文从流程、代码、介质、环境等角度出发，重点聚焦在安全可靠建设过程当中的一些思路与技术支撑，最终造成平台级的建设方法与体系。

目录：

1. DevOps平台的安全可靠涉及哪些方面？
2. DevOps平台安全可靠的设计与实现思路
3. 普元DevOps平台的当前能力与后续计划

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

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



咱们从两方面来看平台的安全的可靠：
 

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

1、平台自身的安全可靠

平台自身来看，包含如上图四个方面：
 

1. 无单点：这里包含两个意思，平台集成的三方中间件较多，须要保障其为集群模式；再一个即便某些中间件彻底故障了，也不能影响整个DevOps平台的运行
2. 数据与环境隔离：不一样项目、不一样团队的数据要保证隔离，一个项目的多套环境，多套介质一样要保证隔离
3. UI与API的权限控制：对界面的菜单、按钮进行权限控制，对后台api的访问权限进行权限控制
4. 可审计：对于什么人在何时在平台上作了什么，在动做先后资源产生了这样的变动

2、软件生产的安全可靠



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

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

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

平台自身 — 平台无单点



正如以前对无单点的描述，平台须要解决两类无单点：

好比咱们使用了jenkins，jenkins的集群是一主多从的模式，这个存在必定的单点问题（master），之间的通讯模式有两种（ssh和jnlp），在屡次测试后，最终选择的是jnlp（ssh可靠性存在问题），master单点问题则经过多套jenkins集群来部分解决；

再好比使用jira来进行项目管理，但jira这种商业产品通常不会部署集群，因此平台另外一方面要考虑的则是即便jira宕机，仍旧能够保证平台的可靠运行（因此平台还会提供工做项本地存储的模式）。



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

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



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



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



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



再有就是部署的操做，什么人审批仍是可自动执行，部署完成后由谁确认（亦或是经过自动化测试确认），这些关键事项，须要结合不一样团队的实际状况进行不一样的个性化配置。

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



需求任务的管理核心是风险识别，对进度要严格把控，一般包括四个视角：
 

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

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

关注项目积压：



关注我的积压：



今日关注与特别关注：



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



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

代码质量包括开发禁止项，代码静态扫描、提交信息合规等，之因此把开发禁止项与静态扫描分开说，主要是目前技术实现上手段区别（目前咱们的开发禁止项还不太能经过自动的静态扫描来发现）。

好比开发禁止项的一些具体细项，咱们目前仍是经过规范、设计和review来作的：
 

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

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


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

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



在介质方面，要作到安全合规，对介质中的一些介质（尤为三方介质），要快速发现其商业风险，好比license：



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

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

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

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



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

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

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

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



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

普元DevOps平台的后续计划



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

 

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


关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！