本文主要描述:
面向对象的需求分析方法论
一. 需求举例
假设,你正在参与开发一个微服务。微服务通过 HTTP 协议暴露接口给其他系统调用,其实,其他系统通过 URL 来调用微服务的接口。
二. 对案例进行需求分析
针对鉴权这个功能的开发,我们该如何做需求分析?
1. 第一轮基础分析
最简单的解决方案就是,通过用户名 + 密码来做认证。
给每个允许访问我们服务的调用方,派发一个应用名(或者叫应用 ID、AppID)和一个对应的密码(或者叫秘钥)。调用方每次进行接口请求的时候,都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后,会解析出 AppID 和密码,跟存储在微服务端的 AppID 和密码进行比对。如果一致,说明认证成功,则允许接口调用请求;否则,就拒绝接口调用请求。
2. 第二轮分析优化
因为密码是明文,暴露给了网络,所以是不安全的。
加密算法
那如果我们借助加密算法(比如 SHA),对密码进行加密之后,再传递到微服务端验证,是不是就可以了呢?
实际上,这样也是不安全的,因为加密之后的密码及 AppID,照样可以被未认证系统(或者说黑客)截获,未认证系统可以携带这个加密之后的密码以及对应的 AppID,伪装成已认证系统来访问我们的接口。这就是典型的“重放攻击”。
提出问题,然后再解决问题,是一个非常好的迭代优化方法。
借助 OAuth 的验证思路
调用方将请求接口的 URL 跟 AppID、密码拼接在一起,然后进行加密,生成一个 token。
调用方在进行接口请求的的时候,将这个 token 及 AppID,随 URL 一块传递给微服务端。微服务端接收到这些数据之后,根据 AppID 从数据库中取出对应的密码,并通过同样的 token 生成算法,生成另外一个 token。
用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致,则允许接口调用请求;否则,就拒绝接口调用请求。
3. 第三轮分析优化
不过还是有重放攻击的可能,我们可以进一步优化 token 生成算法,引入一个随机变量,让每次接口请求生成的 token 都不一样。
我们可以选择时间戳作为随机变量。我们将 URL、AppID、密码、时间戳四者进行加密来生成 token。调用方在进行接口请求的时候,将 token、AppID、时间戳,随 URL 一并传递给微服务端。
微服务端在收到这些数据之后,会验证当前时间戳跟传递过来的时间戳,是否在一定的时间窗口内(比如一分钟)。如果超过一分钟,则判定 token 过期,拒绝接口请求。如果没有超过一分钟,则说明 token 没有过期,就再通过同样的 token 生成算法,在服务端生成新的 token,与调用方传递过来的 token 比对,看是否一致。如果一致,则允许接口调用请求;否则,就拒绝接口调用请求。
4. 第四轮分析优化
但仍然有重放攻击的可能
未认证系统可以在这一分钟的 token 失效窗口内,通过截获请求、重放请求,来调用我们的接口。
开发成本
不过,攻与防之间,本来就没有绝对的安全。我们能做的就是,尽量提高攻击的成本。这个方案虽然还有漏洞,但是实现起来足够简单,而且不会过度影响接口本身的性能(比如响应时间)。
权衡安全性、开发成本、对系统性能的影响,这个方案算是比较折中、比较合理的了。
其他细节
另外,如何在微服务端存储每个授权调用方的 AppID 和密码。
最容易想到的方案就是存储到数据库里,比如 MySQL。不过,开发像鉴权这样的非业务功能,最好不要与具体的第三方系统有过度的耦合。
针对 AppID 和密码的存储,我们最好能灵活地支持各种不同的存储方式,比如 ZooKeeper、本地配置文件、自研配置中心、MySQL、Redis 等。
我们不一定针对每种存储方式都去做代码实现,但起码要留有扩展点,保证系统有足够的灵活性和扩展性,能够在我们切换存储方式的时候,尽可能地减少代码的改动。
5. 最终确定需求
到此,需求已经足够细化和具体了。看如下描述
三. 小结
针对框架、类库、组件等非业务系统的开发,其中一个比较大的难点就是:
需求一般都比较抽象、模糊,需要你自己去挖掘,做合理取舍、权衡、假设,把抽象的问题具象化,最终产生清晰的、可落地的需求定义。
需求定义是否清晰、合理,直接影响了后续的设计、编码实现是否顺畅。所以,作为程序员,你一定不要只关心设计与实现,前期的需求分析同等重要。
需求分析的过程实际上是一个不断迭代优化的过程。我们不要试图一下就能给出一个完美的解决方案,而是先给出一个粗糙的、基础的方案,有一个迭代的基础,然后再慢慢优化,这样一个思考过程能让我们摆脱无从下手的窘境。
参考《设计模式之美》-- 王争