作者|陈建锋
来源|尔达 Erda 公众号

软件研发是一个复杂的工程,不仅需要进行软件的设计、开发、测试、运维,还涉及到大量的人力、物力管理。今天讨论的主角 - “安全”,在软件研发中是一个极易被忽视的主题,但相比代码 Bug 而言,安全问题一旦出现,破坏力更大甚至是致命的。

下面先给大家举些例子感受一下。

5 月 7 日,Colonial 油管(其管道为美国东海岸供应 45% 的汽油、柴油、航空燃料)遭遇了历史上最大的勒索软件攻击,在当地时间 5 月 8 日被迫全线关闭,迟至 5 月 16 日才恢复“正常运营”。

6 月 30 日某滴低调赴美上市。7 月 9 日网信网通报“某滴 25 款 APP 存在严重违法违规收集个人信息问题”。7 月 10 日国家互联网信息办公室发布关于《网络安全审查办法(修订草案征求意见稿)》公开征求意见的通知。征求意见稿包括了“掌握超过 100 万用户个人信息的运营者赴国外上市,必须向网络安全审查办公室申报网络安全审查。”

为什么安全是一个困难


安全问题和代码 Bug 一样,普遍存在于软件的全生命周期之中。计算机安全协会(CSI)曾对企业、政府机关、金融机构、医疗机构、大学等进行调研,征询他们是怎么被安全威胁影响到的。在其收到的 522 份专业反馈答案惊人的一致,“来自内部”… 而且占比高达 80%。所以不必懊恼,很多时候你只是那 80% 里面的一份子而已。

《CSI Computer Crime & Security Survey》:http://i.cmpnet.com/v2.gocsi.com/pdf/CSIsurvey2008.pdf

软件相关的安全问题表现和解决方式繁多。常见的安全问题非常零散:

  1. 如何合理的分配权限并高效管理
  2. 如何保障代码权限和质量
  3. 如何安全的对公网提供 Open API
  4. 如何使用 HTTPS 安全传输协议
  5. 如何保证隐私数据安全
  6. 如何快速发现并修复安全漏洞

作为一个软件研发平台,遇到的安全挑战就更复杂了:

  1. 多租户隔离:平台之上的多个项目、多个企业的资源如何托管才能做到既有效隔离,又高效共享?
  2. 依赖管理:而今万物互联,如何管理好外部依赖(例如云数据库、三方系统登录信息)避免关键认证信息泄露、防止付费服务被滥用导致资损?
  3. 微服务管理:成千上万的微服务如何进行安全漏洞扫描?成百上千的域名如何管理避免大门敞开?

在很多项目中,安全都是一个独立的团队负责,安全工作往往是在软件研发基本完成后才开始。这样的合作方式会导致安全问题暴露较晚,修复付出的成本非常高,而且跨团队的鸿沟也增加了协同成本甚至文化冲突。在当下敏捷模式为主的研发项目中,此种组织架构亟待升级。

安全是企业客户最重视的事情,没有之一,它是企业的生命线,强调再多都无可厚非。在我们所服务的每一位客户心中,任何安全问题的修复都是第一优先级。

综上所述,在 DevOps 、微服务和云原生盛行的当下,因循守旧的边缘化安全无疑会掣肘软件的生产速度和产品质量。那破解之道在何处呢?

破解之道 DevSecOps


早在 2012 年 Gartner 就提出了 DevSecOps 理念,它是一种糅合了开发、安全、运维的全新模式。2016 年,Gartner 进一步发布《DevSecOps: How to Seamlessly Integrate Security into DevOps》报告,强调“需要将安全集成到 DevOps 链路上同时保持敏捷研发”。RSA Conference 从 2017 年开始设置 DevSecOps 研讨专题,讨论主题涵盖了从技术实践到文化融合。

-《DevOpsSec: Creating the Agile Triangle》:
https://www.gartner.com/en/documents/1896617/devopssec-creating-the-agile-triangle

-《DevSecOps: How to Seamlessly Integrate Security into DevOps》:
https://cdn2.hubspot.net/hubfs/1958393/White_Papers/devsecops_how_to_seamlessly__315283.pdf

DevSecOps 之道


首先是思想的破立,DevSecOps 确立了安全前置(Shift Left)的基本共识,安全应该是嵌入到现有的整个软件研发运维流程体系,需要开发、测试、运维、安全团队共同努力来实现软件价值。

其次是技术的支撑,需要完善的工具链保证链接在 DevOps 流程之中的任何一个安全接入点都是高度自动化、稳定可靠且安全的。嵌入的方式应该保证高效和平滑,不能因为流程的增加而拖累软件研发的效率。

再次是团队的融合,DevSecOps 提倡的不仅是局限于技术上的共建和创新,而是要将安全人员融入每一个研发组织,将安全意识和安全问题的快速解决集成到软件交付过程中。

最后是以人为本的文化及组织建设,人的行为自始至终就与数据、威胁、风险、隐私及管理等因素交织在一起,需要能够平衡技术框架和管理策略的新安全技术文化,打造或者转型 DevSecOps 组织。

接下来,我们介绍一下 Erda 在 DevSecOps 上的实践。

Erda 的 DevSecOps 实践


Erda 作为企业级软件研发平台,在设计之初就考虑到企业对安全的高要求,从技术和管理两个角度充分注重落地 DevSecOps。

技术侧


首先,我们从技术侧 Erda 平台提供了很多技术能力帮助研发团队快速地让软件具备安全能力。

1)持续集成流水线

Erda Pipeline 内置了 Sonar Action 对代码进行质量检查。对检查出来的质量问题可以创建“缺陷”,进入项目协同流程,进而来跟踪修复情况。

Pipeline Action 还拥有灵活的扩展能力,可以集成第三方安全公司的付费服务对代码质量、安全漏洞、配置泄露进行检查。

2)部署资源限制


Erda 基于云原生技术支持应用配置 CPU、Memory 的配额,很好的限制单个微服务可以使用的资源量。进一步,Erda 还支持项目配置资源配额。这样,既可以在多个项目共享集群的时候避免相互占用,又能够督促项目组合理评估资源,并在受限后及时清理避免滥用。

3)API 网关

Erda 提供的 API 网关实现了丰富的 API 防护策略,具体信息如下所示:

  1. IP 拦截:支持配置 API 的用户来源 IP 黑/白名单来拒绝/允许某些来源 IP 的请求;同时支持 CC 防护,对来源 IP 的请求限速。
  2. 服务负载保护(限流):按照配置的服务最大吞吐,对请求服务的流量去峰填谷,确保到达后端服务的请求速率在限定吞吐内。当接收到的请求超过吞吐速率时,会根据超过的程度计算惩罚延时,若惩罚延时小于最大额外延时,则增加惩罚延时后再将请求发送给服务;若惩罚延时超过最大额外延时,则立即拒绝请求。
  3. 跨站防护:开启跨站防护功能,会在用户登录成功后种下 CSRF Token,配合前端改造,对所有请求带上 CSRF Token;网关在收到请求后,会对 CSRF Token 进行校验,确认是属于当前用户的 Token,才会将请求正常转发给后端。
  4. 开放鉴权:在面向合作伙伴开放 API 场景下提供丰富的 AuthN 插件进行鉴权,包括 OAuth2 、Key Auth、HMAC Auth。可以对调用方进行授权管理,配置授权范围。
  5. 调用方审计:监控调用方的流量,分析热点 API,统计错误率。

4)域名治理

  1. Erda 的 API 网关提供域名转发能力,可以收敛一个项目中的多个微服务域名。
  2. Erda 提供企业级的全域名统筹管理,可以快速查询域名并切入到对应的微服务应用进行管理。
  3. Erda 默认提供全站 HTTPS 服务并开启 HTTP 强转。同时也支持自定义域名及证书配置。

5)对接云安全产品


Erda 已经成功对接大量的云厂商安全产品,例如 DDoS 防护、云防火墙、Web 应用防火墙、堡垒机、密钥管理服务等。

借力云厂商的赋能,Erda 将业务系统置身于强大的保护罩之中,并对业务系统无任何侵入。

6)私有化安全保障

Erda 已经成功实施过几十个私有化项目。针对私有化环境的安全保障,Erda 一方面提供了 VPN、JumperServer、操作系统加固等安全解决方案;另一方面,可以利旧客户环境的安全产品,包括防火墙、堡垒机、F5、WAF、安全日志审计、MFA 认证、加密存储等。

管理侧


其次,从管理侧 Erda 也提供了很多管理方法,帮助研发团队治理研发过程、规避安全问题。

1)权限管理


Erda 采用基于角色的访问控制(RBAC)实现企业级的用户权限管理,建立“企业 - 项目 - 应用”三层组织架构。以应用为中心,多个应用构成一个项目,一个企业可以建设多个项目,配备不同角色参与企业软件研发。

Erda 设定了多种研发角色,包括项目经理、研发主管等,每个角色所拥有的权限都是被平台预先设定的,严格设定了其所能完成的操作。每个 Erda 用户完成注册后并不归宿任何企业,由企业管理员将其加入企业并分配角色。同样的,由项目管理员将项目成员加入项目并设定角色,项目成员根据在项目中不同的职能,承担不同的角色(即拥有不同的功能权限),相互协作完成整个项目研发。

Erda 会记录所有的用户修改操作,支持安全合规审计。同时平台杜绝弱密码,采用盐值加密存储,并对多次登录失败进行账号冻结来防范密码暴力破解。

2)资源管理


每个企业可以使用 Erda 托管多个集群,集群间物理隔离。特别的,多个企业还可以共享一个集群,通过机器分组实现隔离。企业中的每个项目内置四套研发环境,每个环境都可以选择部署集群。

如上图所示,企业 A 管理两个集群,其下的项目一、二、三的研发环境分别分属于两个集群。企业 B 管理两个集群,其下的项目四、五分别使用一个集群。企业 C 和 D 则共享集群三,但它们使用的是两组相互隔离的机器。通过不同的隔离策略,Erda 支持了灵活的安全隔离需求,同时兼顾弹性共享的业务场景。

3)配置管理


常见的安全隐患是硬编码配置被到处拷贝。极端情况下你的账号密码会出现在 Github 上;企业甲会把埋点数据发到企业乙的友盟账号里。一旦配置泄露,企业会陷入极大的苦恼和担忧。

Erda 的最佳实践是将配置保存在平台上,工具代码通过配置名在对应的环境下受限使用。研发主管在生产环境配置了 rds-prod 插件,然后开发工程师通过 erda.yaml 引用 rds-prod 来获取数据库配置。配置信息仅研发主管知晓,对开发工程师不可见,做到最小暴露。

同样的,研发主管配置测试参数 clusterName 等,测试工程师通过参数名 ${{ config.autotest.clusterName }} 引用来进行接口测试。测试工程师也不接触具体的配置参数值。

特别强调一下,通过平台管理配置也将配置参数和研发环境绑定,避免了参数和环境错配带来的误用。

写在最后


Erda 的安全之道在于一直秉承 DevSecOps 的理念为企业提供打造高质量软件的研发平台。我们会一如既往地完善自动化工具链,推进安全前置的同时注重安全落地的柔和低侵入。Erda Cloud 作为 DevSecOps 的倡导者,我们会持续关注于人自身,从以人为本的角度平衡技术框架和管理策略,致力于构建安全且敏捷的组织文化。

如果你有任何疑问,欢迎添加小助手微信(Erda202106)加入交流群,参与交流和讨论!


erda_terminus_io
35 声望6 粉丝