请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

   思科 CCO 登录 推荐
 找回密码
 立即注册

搜索
热搜: 邮件服务器
查看: 938|回复: 1

【原创】给DevOps“加持”安全(1)

[复制链接]
发表于 2019-6-20 10:38:21 | 显示全部楼层 |阅读模式
如今,以Netflix、Etsy、Flickr为代表的各个公司,都持续以更少的时间、更快地发布出新的功能。他们的成功秘诀就是用到了“DevOps”。这是一种交付软件的新方法,它专注于持续集成、持续交付、和消除工程与运营团队之间的障碍,从而加快发布速度、并降低风险。DevOps如今已广泛地被银行、保险公司、政府和许多重监管的行业组织所采用。
虽然DevOps被大多数软件团队所熟知,但是很少有团队真正实践并维护着与之相称的安全控制。像Uber和eBay之类存储着大量个人敏感信息的组织,虽然运用DevOps简化了开发和运营,推进了功能开发的速度,但由于将安全隐患置于了次位,因此也遭遇过一些重大的违规事件。
当然,也有不少的公司在运用DevOps“快速前行”的同时,保持着高标准的信息安全。我们对此总结出了如下图所示的6条基本原则。

第一部分:安全策略即代码
目前,在那些成功地将DevOps的速度与安全性结合的团队中,最重要的特性是:他们运用代码来指定各种安全策略。
DevOps的基石是“基础架构即代码(infrastructure ascode)”,也称“不可变基础架构”。运营者运用代码来声明其基础架构的需求,从而取代了手工管理与配置服务器与软件的旧模式。这种方法能够有效地抑制那些已被手动配置的服务器“独角兽(unicorn)”们进一步扩散,进而造成在其出现故障时,却无人知晓如何进行重建这一尴尬局面。更重要的是:它还能支持自动化扩容,以及预测如何将新生成的功能部署到不同的测试与生产环境之中。代表这种基础架构的代码会与应用程序代码一样被检入到源代码的控制之中,进而可以实现版本控制、比较和保护。
那些安全实践经验较为丰富的DevOps团队,可以通过采用“基础架构即代码”的模型来管理其应用程序的安全性。他们在新的应用或微服务中,用代码来声明其安全策略的各种需求。例如,下面的一小段安全政策,就是一个用Conjur政策语言(请参考https://www.conjur.org/reference/policy.html)编写的、提供货币换算服务的微服务:
  - !policy
    id:currency-converter
    body:
    -&variables
      -!variable
        id:currency-database/password
       annotations:
         description: Currency values DB password
    - !groupsecrets-users
    - !permit
     resource: *variables
     privileges: [ read, execute ]
      role:!group secrets-users
  - !grant
    role:!group currency-converter/secrets-users
    member:!host currency-app-host
可见,它的语法是人类可读、且易于理解的。即:该代码允许授予了货币转换服务(currency-converter)权限,去访问一个存储着各种货币值的数据库密码。该政策是完全独立且可不限重复的,既不依赖于外部因素,也不会被未来的解释方式所左右。它完全可以被检入到源代码的控制中,作为应用代码的一部分被予以内部实现。
那些日常管理着数千个应用相关权限的安全人员,可以通过该“安全策略即代码”模型,将自身的团队能力提升到一个新的水平,并能使得自己的工作更具可预测性。而这些恰是过去那些需要手动配置与应用相关的安全权限所无法企及的。
可见,“安全策略即代码”对于创建高效的安全DevOps流程是至关重要的。没有它,我们后面将要谈到的安全DevOps各个方面都将无法实现。

第二部分: 职责分离
令人遗憾的是,在许多软件团队中,开发人员和操作人员还肩负着安全的职责,他们需要维护服务的相关帐户、定义各种安全控制、控制对于敏感数据的访问等。这些无疑增加了他们已有的且“满满的”工作量。

职责分离是速度的动因
大多数关于职责分离的文章都会提到它在防止利益冲突和欺诈方面的好处,以及如何通过它来减少任何人超额拥有其本该拥有的基本权力。然而从另一个角度来看,高绩效的DevOps团队则会将职责分离视为一种机会,他们籍此来保证团队成员仅专注于自己最擅长的工作,并能够根据每个人的能力来适当优化团队整体的工作流程。
成熟的团队具有明确的角色和清晰的职责分工。安全和监督由专门的安全人员来负责,开发人员会专注于编写代码,而操作人员则确保生产环境架构能健康运营。每个职能团队之间的接口“传递”已被编入到了安全策略之中。即:开发人员创建安全策略声明其应用程序或服务所需要的权限->安全人员随即审核并批准相关的代码更改->操作人员确保应用程序的部署、并能够按照预期运行
职责结合:一种痛苦的反模式
当任何一种开发、安全和运营角色被组合在一起时,组织将不可避免地会出现由单一角色所带来的巨大风险。对于开发者来说,他们通常无法意识到自己在生产系统中可能所拥有的权限,因此也就无法预知自己的某种疏忽会给组织带来的危害程度。例如:去年某公司的初级工程师在其入职的第一天,就意外地删除了该公司的生产数据库。而发生这种情况的原因,正是因为他被赋予了在生产系统中的所有权限。
就其所拥有的访问权限而言,这位不幸的开发人员在其完全不知的情况下,同时扮演着运营人员的角色。因此,问题的根源不在他的身上,而来自其雇主:他们没有将职责分离,没能在源头防范此类情况的发生。
每种角色的责任
开发人员:
·        能够编写代码和测试案例,而不必担心意外地触碰生产环境。
·        与运营人员交流其应用所涉及到的主机需求。
·        与安全人员交流其应用所涉及到的安全需求。
运营人员:
·        执行并实现应用程序有关主机(虚机)的需求。
·        保证生产环境的可用性。
安全人员:
·        针对开发人员的应用需求授予相关权限。
·        确保系统范围内,各种安全措施的落实与到位。
正如企业采用DevOps模式并不意味着开发人员需要承担运营角色那样,采用“DevSecOps”也并非意味着开发人员必须成为安全专家。因此,高绩效的组织应当学会避免出现“快速推进却时常犯错”的行动状态。他们需要的应当是“在知晓不会犯错的基础上快速推进”的各司其职模式。
第三部分:专注工作流与速度
DevOps的核心概念是产生可持续的、平稳的工作流程。为了实现此目标,DevOps团队需要通过创建各种CI/CD管道、持续进行小而频繁的代码变更、端到端的部署、并采用类似基于微服务的系统架构,以获取上文提到的快速推进。

建模和优化安全的工作流程
看板(Kanban)是一个专注于流程和开发速度的工作系统。其核心是将工作的各个阶段可视化,即:随着项目在不同阶段的推进,各个状态的可视化会有助于分解出其中出现的缓慢步骤、识别出瓶颈、并优化其速度。
一个长期面临发布延迟的组织可能会发现:安全审查阶段在自己的系统中花费的时间较长。其原因通常在于:安全审查开始得比较晚,并且所涉及的量又比较大。换句话说:太多的东西会被一下子被“甩到”安全审查团队的面前。
那些经验丰富的组织一般会“将安全放到左边”(在可视化看板中,一般假设工作流程从左边开始,想右边流动)。这就意味着:安全团队会越早介入新版本/功能的开发,就越好。同时,如果他们在整个开发周期的早期阶段,就能揭示出重大的安全问题,那么就可以防止后期出现延迟交付的情况。
为速度加固微服务
微服务架构给安全团队提供了许多好处,尤其是那些专注于其自身发布速度的团队。
我们继续以前面 “货币换算”的微服务为例。如果安全团队只需要检查并授权该应用去访问单个数据库的话,那么还是相对较为简单的。但是如果该功能被置于一个庞大的且拥有数百万行代码的应用体系之内时,那么安全团队就可能需要对许多方面的变化进行梳理,以查找出对他们来说非常重要的审查内容。同时,如果该庞大的应用在版本上经历了许多实质性的变更,则会将审查变得更困难。毕竟,只让安全团队检查几十行的安全策略代码,和让他们检查上千行代码相比还是容易得多的。
如果新的版本不需要修改任何权限,那么对于已经注册的微服务代码进行持续升级还是能保持快速的。相反如果需要在庞大的应用中退役或关停某个微服务,则需要考虑到其所涉及的各种耦合关系和代码层面的规模。
传统团队在经历了瀑布式开发之后,常趋向于进行“爆炸式(big-bang)”发布应用。而一旦应用出现了质量问题,则不得不迅速叫来安全人员进行代码审查。如此,安全团队所面临的往往是累积了成上千次变更后的应用代码,和来自业务方面为了应用能早日上线的不断施压。
因此,那些保持持续交付的大型团队,会将他们的代码库分解成多个微服务来实现。同时他们也会邀请安全团队运用各种专业的、精细化的模型来进行各种安全审查,以有助于加快发布进度、并提高可视性。
端到端简化流程
DevOps引入了“尽早实现端到端”的概念。这是一种降低交付风险、并提高预估信心的简单方法。对于团队成员来说,他们能够越快地将新服务“连接管道”,就能够越快地获知如何顺利地去构建部署流程,以及应对频繁的升级和更新。同时,一些未完全实现的功能标志可以被隐藏地部署到生产环境之中,等到新的功能完善了,再向用户全面展示和开放。
这种方法同样也能够很好地降低服务中的安全变更风险,特别是当团队采用了“安全策略即代码”的原则后。例如,一项新的服务需要访问内部CRM数据库和支付网关,那么该团队的首要任务就是为该服务构建出一个CI/CD管道,然后等基本连接构建好之后,再将该管道升至0.1版本。
如此,该服务的权限就已经通过了审查,一旦完成部署,它将以“预先注册”的方式去访问生产环境中的各种敏感资源。可见,这样便消除了后续版本的部署风险,开发人员可以在后期去创建并实现剩余的功能。同时,安全团队也提前获知了服务的权限与安全的设置需求。
小结
高效的DevOps团队应当能够通过如下方式,来实现高速且流畅的工作流程:
·        使用看板视图来发现开发周期中的瓶颈,并优化它们。
·        “将安全放到左边”,让安全团队尽早参与到开发周期之中,从而尽早发现相关的安全问题。
·        使用“安全策略即代码”的方法让开发、安全和运营团队进行高效且明确的沟通。
·        将大型应用分解为更小的微服务,每个微服务都要有自己的安全策略。
·        尽可能减少大批量的变更,使安全团队能够持续、少量、可预知地进行安全审查。
·        尽早实现“端到端”模式,以降低组件和模块的持续升级所带来的风险。
无论您的公司有着上百位开发人员,还是只有较小规模的团队,上述安全开发的流程原则都会给您带来帮助。

【原标题】DevOps Security atScale   (作者: Brian Kelly)
原文链接:https://www.conjur.org/blog/2017/12/19/security-at-scale.html  


  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2019-6-20 10:48:10 | 显示全部楼层
感谢版主分享,谢谢~
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver | 思科社区  

GMT+8, 2019-9-19 15:21 , Processed in 0.100791 second(s), 36 queries .

京ICP备09041801号-187

版权所有 :copyright:1992-2019 思科系统  重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表