V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
hxndg
V2EX  ›  程序员

再谈安全开发

  •  
  •   hxndg · 2021-03-16 00:07:05 +08:00 · 404 次点击
    这是一个创建于 470 天前的主题,其中的信息可能已经有所发展或是发生改变。

    提到安全开发头头是道,真到开发的时候抓瞎了。身为一个从预研到开发的程序工程师,我来简单说说我所认识到的安全开发。由于我是单纯从开发干起,很多东西都是(我自己总结的)从开发的角度来谈的,因此难免有局限性。这个我本来是 append 到了 TLS 自动机研发, 但是想了想也可以摘出来,所以又发了一次。

    1.1 安全开发流程初期

    安全开发名字高大上,但是实际上是个苦差事,因为安全并不是水桶,而是一个气球:哪里扎破一个洞,立刻整个就崩了。因此初期把握好安全开发就很重要,我比较喜欢从下面几个方面来分析:

    • 目的是提供一款什么样子的安全产品?是提供端到端的加密?认证服务不可抵赖?秘钥管理?权限管理?安全监测?每种不同的属性对应着不同的功能。project leader 还常常需要进行产品的横向对比,从而能够保证功能的灵活性和创造性。
    • 需要保护哪些敏感信息,等级分为几种?比方说身份信息,权限信息,支付信息,爱好信息等等方面都可以被划归为敏感信息。
    • 可能遭受哪些攻击?相比上两种,这个问题是最具体的攻击,常见的攻击很多种:供应链攻击,SQL 注入
    • 可以复用哪些已有的安全工具和代码块?不要老去造轮子,要学会组合而不是创造。

    上面几个问题实际上是安全开发当中大的目标,分析好上面几个问题之后,最大的问题就来了,怎么落地?说起来也不难:

    1. 第一步 培训:培训的目的包含三个方面:使得每个参与者(不限于开发者,测试者,经理,审计....)了解产品提供的安全属性,安全准则和具体功能,尤其是要对产品经理培训使得其明白安全不是个绝对概念,是有选择倾向的,总要做出抉择;对每个参与进来的开发者培训,使得其清楚常见的安全知识,比方说对称加密的安全性由秘钥保证,hash 不是加密,什么方法提供认证功能等基础知识;对核心开发者明确产品的核心逻辑和模块的设计(不一定是高速开发者,而是让核心开发者设计),必须达成对功能和安全的共识!我们在做 TLS 自动机的时候核心就三个人,每个人都可以相互替换对面的功能,TLS1.3 新功能 REUSE 和 0-RTT 的核心逻辑也是我设计完了,争论了几次才确定的,我们的测试完全参与不到我们的培训里,因为听不懂。。。
    2. 第二步 需求和功能划分:确定需求是个很有趣,却不困难的工作。因为核心逻辑是围绕关键信息的,所以基本确定了敏感信息和核心逻辑之后,需求划分就比较简单了。但功能划分是个很麻烦的事情,一方面核心逻辑可能并不复杂,但是边界错误和细枝末节可能会出现大量问题,因此每个细微的工程都需要有人把关;另一方面,安全开发产品有很强的连续性,安全经常是成环的,因此要确保具体的代码开发者是了解开发的模块的输入 /输出 /隐喻 /保障的,因此需要保证开发者是真的懂怎么回事,而不是似是而非模棱两可。这里注意,划分功能意味着划分责任,有的开发爱甩锅,有的 QA 爱甩锅,这时候就看 project leader 的功力了。
    3. 第三步 颁发安全准则:培训了,需求确定了,功能划分了,到了写代码的时候新的问题就来了,怎么保证代码是安全的呢?针对 TLS 可以看我写过 TLS 三理念,更具体的一般是:第三方安全性,很多安全问题是由第三方安全保证的,开发工程师精力不够,找 QA 啊;函数安全;工具安全。

    多赘述一点东西:安全属性不是隔离的,端到端加密是很多功能的保证,但是奥卡姆的剃刀原则务必不要忘记,如无必要勿增实体,不要把其他层的东西放到本层来做!

    1.2 安全开发流程中

    安全开发流程中期实际上是个工程师埋头干活,抬头开会报进度的流程,这阶段的关注点在于 project leader 上。project leader 不但要对项目进度做好把握还要把握好需求变更的问题。project leader 还需要检查行为变化,细化安全规范。这就需要 project leader 能够明确安全的行为,并且能够根据具体的功能黑盒灵活的改变行为。

    坦白讲,做 TLS 自动机研发的时候,虽然复用和 0-RTT 是我负责,但是关于排期这事我没咋催,主力是我,小功能分出去的时候我会提前培训开发的同事;每天问问进度和问题;明确行为规范。所以没啥排期的变更,行为这块一开始三个核心争了很久,也很确定,所以没遇到啥大问题。

    1.3 安全开发流程后期

    安全开发流程后期实际上主要的关注点不再开发工程师上了,在于 QA 和运营人员:运营人员要执行静态检测和动态监测; QA 要执行模糊测试,输入测试等多种功能,这都不是问题。问题在于:project leader 和开发者要在开发前期和开发后期以高度透明的角度,参与 QA 的测试 CASE 制定!换言之 QA 和开发必须都审核过测试 CASE,从而避免出现什么“现实不可能发生,测试不全面”的扯皮。

    此外,需要记录开发过程当中遇到的实际问题和 BUG,并且将这些问题归类,加入到安全规范中。一方面能够给工程师提供具体的案例分析,另一方面能够很明确的细化规范和经验。实际上关于 0-RTT 的 DDOS 攻击我在分析 OPENSSL 的时候虽然想到了但是没明确,是后来 QA 参与进来我们才定性规定这是个问题的。

    最后,最蛋疼的收尾工作来了:

    • 如果出现问题,如何应对? project leader 需要根据具体的威胁制定针对补足方案,开发需要明确出现某种问题时,谁第一阶段参与,谁来参与追责。
    • 如果在具体的安全规范出现问题,依据什么原则,听谁的?
    • 开发和测试当中的资料归档在哪里?值得商榷的行为和安全保证的细节必须高度透明的写出来,并且能够被明确归档。
    • 可复用的工具,代码和属性是哪些?哪些应当成为标准组件?这些(第三方,第一方)工具,代码安全吗?实际上这里我最直接想到的就是 HKDF-EXTRACT & HKDF-EXPAND,一个安全并且规范化的灵活伪随机码产生工具。实际上这个工作是需要一线开发工程师一起参与的。

    1.4 遇到的安全开发中的问题

    简单说说我们在开发过程当中遇到的一些实际问题:

    • 人力不充足:人员短缺的问题很蛋疼,核心三人组是又订规范,又商量行为,光研究 RFC 就花了很久,更别提给其他人培训了。虽然能力增加了不少,但是确实很蛋疼。
    • 需求的变更:我对需求变更实在是太烦了,小的需求比方说拓展的支持还好说,解析的时候多花点功夫即可。如果大的属性变了,那排期就得大变。
    • 项目周期紧:这个对我们来说还好,虽然我们设计阶段功夫很多,但是设计好了我们的开发还是很快的。

    结尾

    实际上,从某种意义来说,安全开发是个文档>开发的过程,惊不惊喜,意不意外?

    目前尚无回复
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2827 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 12:15 · PVG 20:15 · LAX 05:15 · JFK 08:15
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.