作者｜陈建锋
来源｜尔达 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
软件相关的安全问题表现和解决方式繁多。常见的安全问题非常零散：
- 如何合理的分配权限并高效管理
- 如何保障代码权限和质量
- 如何安全的对公网提供 Open API
- 如何使用 HTTPS 安全传输协议
- 如何保证隐私数据安全
- 如何快速发现并修复安全漏洞
- …
作为一个软件研发平台，遇到的安全挑战就更复杂了：
- 多租户隔离：平台之上的多个项目、多个企业的资源如何托管才能做到既有效隔离，又高效共享？
- 依赖管理：而今万物互联，如何管理好外部依赖（例如云数据库、三方系统登录信息）避免关键认证信息泄露、防止付费服务被滥用导致资损？
- 微服务管理：成千上万的微服务如何进行安全漏洞扫描？成百上千的域名如何管理避免大门敞开？
在很多项目中，安全都是一个独立的团队负责，安全工作往往是在软件研发基本完成后才开始。这样的合作方式会导致安全问题暴露较晚，修复付出的成本非常高，而且跨团队的鸿沟也增加了协同成本甚至文化冲突。在当下敏捷模式为主的研发项目中，此种组织架构亟待升级。
安全是企业客户最重视的事情，没有之一，它是企业的生命线，强调再多都无可厚非。在我们所服务的每一位客户心中，任何安全问题的修复都是第一优先级。
综上所述，在 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 防护策略，具体信息如下所示：
- IP 拦截：支持配置 API 的用户来源 IP 黑/白名单来拒绝/允许某些来源 IP 的请求；同时支持 CC 防护，对来源 IP 的请求限速。
- 服务负载保护（限流）：按照配置的服务最大吞吐，对请求服务的流量去峰填谷，确保到达后端服务的请求速率在限定吞吐内。当接收到的请求超过吞吐速率时，会根据超过的程度计算惩罚延时，若惩罚延时小于最大额外延时，则增加惩罚延时后再将请求发送给服务；若惩罚延时超过最大额外延时，则立即拒绝请求。
- 跨站防护：开启跨站防护功能，会在用户登录成功后种下 CSRF Token，配合前端改造，对所有请求带上 CSRF Token；网关在收到请求后，会对 CSRF Token 进行校验，确认是属于当前用户的 Token，才会将请求正常转发给后端。
- 开放鉴权：在面向合作伙伴开放 API 场景下提供丰富的 AuthN 插件进行鉴权，包括 OAuth2 、Key Auth、HMAC Auth。可以对调用方进行授权管理，配置授权范围。
- 调用方审计：监控调用方的流量，分析热点 API，统计错误率。
4）域名治理
- Erda 的 API 网关提供域名转发能力，可以收敛一个项目中的多个微服务域名。
- Erda 提供企业级的全域名统筹管理，可以快速查询域名并切入到对应的微服务应用进行管理。
- 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 Github 地址：https://github.com/erda-project/erda
- Erda Cloud 官网：https://www.erda.cloud/