微软资深工程师：聊聊合规要求对系统设计的影响

《微软资深工程师：聊聊合规要求对系统设计的影响》要点：
本文介绍了微软资深工程师：聊聊合规要求对系统设计的影响，希望对您有用。如果有疑问，可以联系我们。

作者:虞雷

编辑:Gary

Compliance,中文通常翻译为合规性,是软件和云计算领域频繁提到的一个概念.在很多国家和地区,一些特定行业和政府部门,对使用的 IT 设施,软件和服务都制定了各种基于数据安全考虑的规范.我们有时候听到一些术语,比如信息安全等级,可信云认证、FISMA、HIPAA、DPD 和最新的 GDPR 等都是与合规性相关的.

作为云计算平台或者通用软件服务的提供商,在开发和运维过程中不同的应用场景都不可避免的涉及到合规的问题.国内云计算的主要玩家,阿里巴巴、腾讯和华为,近年来开始向国际市场进军,随之遇到的合规问题会显得更加复杂.而国内市场本身,随着 IT 和互联网环境的日趋成熟,外加政府云项目的推广,合规性的相关问题也会更加突出.

部分工程师可能觉得这个话题和技术设计没有最直接的关系,不会对系统架构产生特别大的影响,而更多的是公司市场或者法律团队要操心的问题.但事实上因为合规要求所带来的需求会在很多方面影响到系统设计.

举个例子,一些系统中直接使用用户名来作为用户的唯一标识,在内部逻辑中也没有将用户名映射到其他的 ID 或者 hash.在生成一个和某用户关联的 URL 给第三方使用的时候,由于应用场景对 PII 的规定用户名不能被泄露,所以就必须采取额外措施对用户名进行加密等处理.而加密常常涉及到密钥的管理、部署和更迭,无形当中就增加了开发和运维的工作量,同时还影响了运行效率.

尽管不同国家和地区,不同行业,有不同的规范,但就一般商业软件和云计算平台而言,仍然有一些方法和实践是可以通用的.在适当的情况下借鉴这些经验可以很大程度上规避由于合规性带来的风险和额外工作量.在大型系统设计的初期,尤其企业级应用,应尽早把合规纳入设计的考虑问题之列.一些针对个人用户的网站,因为涉及到金融和支付的功能,也可以考虑参考一些类似的设计理念和注意事项,同样做到对个人客户负责.在这里我根据自己多年的行业经验,和各位简单聊一聊这个不是那么有趣,可能稍稍有点严肃的技术话题.

用户身份认证

谈合规性首先要谈到安全和身份认证.对于现代互联网和软件应用来说,基于 web 的用户认证方式是每个系统设计要解决的首要问题.云计算平台的提供商,尤其是 PaaS 层,往往是认证方式的实现者,需要提供完善和健壮的用户认证解决方案.

明文密码和 token

基于 web services 的 API 可以很简单地实现 Basic Authentication,即客户端用 HTTP 协议的 Authorization 头(header)来发送 base64 编码过的用户名和密码.因为 web services 大多数是无状态的,所以基本上要求每个请求都包含用户名和密码.这样的认证方式最简单,但要求服务器端全程 SSL 加密.而且因为整个过程的所有请求都带有密码,所以密码被泄露风险较高.举个例子,如果负责运维的工程师用诊断工具看到了 Authorization 头的内容,那么他就获取了用户的原始密码.

很多应用场景禁止使用 Basic Auth,例如 PCI DSS 规范就要求使用基于 token 的用户验证方式.在 Authorization Server 和 Resource Server 分离的情况下,应尽量使用基于 OAuth 2.0 的模式来完成用户认证,这样避免用户密码在没有必要的情况下被传递到 Resource Server 上去.

Multi-Factor Authentication

一些公司和组织由于业务数据的敏感性,规定终端用户至少需要两种以上的认证方式进行登陆.经常听到的 FISMA 规范就有相关条款,要求组织职员和云服务提供商的运维人员都要遵守.除传统密码以外,电话,短信,USB 密钥等都可以作为其他的认证方式.

对于认证方式的提供者来说,在系统设计时候将各种物理认证方式的抽象化就显得比较关键,易于从基本的用户名密码扩展到其他认证方式.

URL 中的信息

URL 很容易被客户端和服务器端的各个部件记录下来,尤其各种 web server 和 proxy 的 log 基本都在记录 URL,包括浏览器的历史记录.因此诸如用户 access token 等敏感信息不建议使用 URL 来传递.即便 access token 会过期,在 TTL 内被泄露仍可能造成重大损失,例如被用来执行删除操作. 对于 web services 和一些认证协议,Authorization 头是比较推荐的 token 载体.

同样的道理,在进行 web 界面认证流程的时候,应该尽量使用 POST 而不是 GET 来传递原始 access token.一些认证系统为此专门使用相对复杂的浏览器端 JavaScript POST 来代替简单的 302 重定向,就是为了避免将 token 放在 URL 里.

个人可识别信息

前面的例子提到行业里经常使用的一个术语 Personally Identifiable Information,即个人可识别信息,简称 PII,相关术语还有 Linked PII、OII 等.很多条文规范,例如 HIPAA,对用户的隐私和 PII 信息的保密做了相关规定.这类信息包括用户名、姓名、电子邮件、电话等,从在大多数系统中虽然不是用户核心数据,但仍然可以被挖掘和恶意使用,造成个人和企业的损失.

ID 影射

前面的例子提到,使用用户自己创建的用户名,或者填写的电子邮件,手机号等来作为系统内部使用的唯一标识在很多情况下并不是理想的选择.一方面这类型的 ID 是可更改的,甚至是可以重复的,另一方面这些 ID 本身就很容易关联到用户的真实身份,无法满足合规性的需求.

大型分布式系统大多都有 shard 的概念,如果基于 web 的应用协议在一个相对扁平 URL 的反向代理之内,那么在进行多方 web 跳转时候,有的系统设计可能需要借助用户的 ID 来重新定位原先的 shard 和节点.这种情况下就需要保证所生成的回调 URL 中不能有可识别的用户 PII 信息.

新用户创建以后,系统应该分配不可人为识别的用户标识,比如 UUID 或者 sequence number 等,然后系统内部逻辑应该围绕其进行设计.这样的标识因为不能直接关联用户,需要通过某种可控的查找过程才能映射到可以识别用户身份的信息,所以不属于 PII 的类型.开发人员在使用此类型标识时候就有更灵活的空间.

诊断工具和系统日志

在如今的云计算时代,运维和诊断的工作基本上是由开发人员负责的.这些工程师可能属于 IaaS 和 PaaS 的云服务提供商,也可能属于 SaaS 的提供商.对于开发和运维人员来说,获取尽量多的用户信息,会让工作变得更加容易,但这其实与合规的要求是矛盾的.很多规范都不允许云服务提供商的工程师在默认情况下能直接接触到客户的 PII 信息.

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!