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

如前面提到,如果系统使用不可识别的内部用户 ID,那么工程师需要检查用户信息时候所依赖的工具也应使用该类型.根据一些条款,诊断工具在默认情况下应该将包含 PII 的返回字段进行清洗(scrub),例如加密或者乱序(scramble)到不可识别.当然,在需要的情况下,工程师还是可以通过申请临时权限提升来关闭 PII 清洗功能,从而看到用户的完整信息来帮助完成工作.另外在用户身份已知的情况下,比如用户提供了用户名,一般情况下用工具作反向查找获得用户的内部系统 ID 是被允许的.

通常情况下系统日志(log)里面很容易包含 PII 信息,因为开发人员希望能够尽可能详细记录用户请求的细节,让诊断工作和基于日志的数据分析变得容易.但大多数情况下一个系统的日志来自很多不同组件,而大多数日志在生成和转移过程中都是可以被负责运维的工程师直接获得的,这样就需要进行 PII 清洗.最严格的规定要求在日志生成的时候就进行 PII 清洗.可以想象,在设计日志子系统时,如果用的是有 schema 的 log 格式,就有可能需要 metadata 来标记一个字断是否属于 PII.

部署和运维

经常可以听到项目组在讨论一个新的微服务应该在哪里运行,或者一些相对较小的数据可以存放在哪里,能不能使用 Azure 和 AWS 上的那些大家熟知的 PaaS 服务,如果可以用的话怎样用.比较有经验的工程师应该能马上根据服务和数据的类型来作出判断.元数据、配置数据、用户画像数据、用户核心数据等都是不同的数据类型,按照商业价值级别还可分为 LBI、MBI 和 HBI.

代码安全

这里指的代码安全是指产品代码在从源代码控制工具(如 GitHub)到部署,再到运行的过程中,不会被个人更改和替换.一些产品的核心部分代码要求使用带有数字签名的编译文件来实现,防止被有 bin 目录访问权限的个人更改.值得一提的是,这种严格的要求甚至可能会对编程语言的选择带来影响.

一些初创型的互联网公司,代码交付和部署就是一个人手动搞定的事,轮到谁值班就谁来,被戏称为牛仔式部署(cowboy deployment)方式.尤其在使用诸如 AWS Lambda 和 Azure Functions 等 serverless computing 方案的时候,甚至可以在控制台里直接粘贴代码上去.可以想象这种部署方式是不满足合规要求的.

团队应该对最终交付代码的权限有清晰的管理制度,避免单个工程师可以对系统作较大的改动,并且尽量使用自动化工具来进行管控.需要指出的是,这样做的目的并非不信任团队成员,而是为了达到合规要求,获得相关认证所需要实施的举措.

权限提升

运维过程中不可避免地要更改配置,查看原始日志,连接到服务器终端,甚至有的时候需要更改用户数据.这些对数据安全有影响,甚至危险的操作(例如前段时间的某网站误删数据库),都应该按照一定的流程来管控.在运维人员申请权限提升时候,应该有相应的流程来审批和授权,工程师的操作也应该被记录和 audit,临时权限提升不应该超过四小时.

数据备份和保留

备份和容灾

对于云服务的提供商来说,用户数据的冗余存储和跨地域备份是基本要求.不同的云服务客户可能会根据自身需求和预算来选择高可用性和数据备份的方案,但一些规范则对跨地域存储和容灾备份有明确规定,不符合规定的提供商无法参与竞标. 另外需要注意的是,如果数据中心的地理位置跨国家和地区的话,在做跨地域设计时候,某些有合规要求的用户数据不能随便跨国家备份和 failover.

Document Retention

根据美国证监会(SEC)的 SOX 法案,上市公司的一些电子文档需要保存三年,并且要在会计和审计的时候要能够进行查询和导出操作.事实上市场上很多企业电子邮件备份解决方案就是根据这个法案的要求诞生的.这也意味着一些公司员工在删除电子邮件的时候其实并不能彻底删除数据.除第三方开发的邮件和数据备份软件外,像 Office 365 这样的企业应用产品也自身集成了这些功能.另外法案中对各种类型的用户文档的保留时长做了比较详细的规定,相应产品的功能设计也应该围绕具体条款进行.

在以个人用户数据为中心的系统中,关于备份的要求可能会影响基本存储模型的选择和设计.产生数据的企业应用,作为第一方,可以选择将备份和保留的数据存在用户的基本存储单元和 shard 里,但必须有相对应的访问控制模型来区分用户可写数据和系统数据,对用户操作进行隔离,这样保证用户无法真正改写和删除数据.而第三方的备份产品,则可能需要复制相似的用户目录结构来存储备份的数据,还要应对用户变更和重命名的情况.

除了以上讨论的几点以外,合规性要求也会对云服务的基础设施产生影响.微软数据中心对坏硬盘的销毁方式也根据数据价值级别有所区别,有的只要打孔,有的则需要把整个硬盘绞碎.除了上面讨论的内容外,还有一些非技术的相关流程,比如 FISMA 中规定了手提电脑丢失的上报时间期限等.

本文只讨论了合规性的一小部分内容,而且只涵盖了那些基本适用大多数行业的方法和实践.特定的行业还有大量特定的需求,会对系统的方方面面造成影响.总而言之,负责总体设计的工程师,应当和产品经理紧密沟通,严肃对待合规性的问题,从第一天就带入设计的考量中,避免将来产生安全问题或者法律上的纠纷.

作者介绍

虞雷 (Jason Yu),微软 Office 365 Core 部门首席软件工程师,在生态系统项目组主要负责 Connectors,Actionable Message 和 Bots 等项目的架构设计.https://www.linkedin.com/in/zeromemory

文章来自微信公众号：聊聊架构

（编辑：云计算网_宿迁站长网）

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