前言
作者：武天旭，注册信息安全专家，CSDN安全博客专家。
我本科毕业后的第一家公司是安全行业内非常有名的一家乙方公司，但入职后我才发现，乙方的工作并不是我想象的类型，同时它的离职率也非常高，原因就不多说了，仅仅两年后我也对它说了拜拜（其中一年还是实习）。2018年7月，我有幸来到我的前东家，一个后来在美股上市的公司。彼时公司整体规模已经接近600人，且业务处于疯狂膨胀发展中，但公司安全部才刚刚成立，安全工作处于一切都还没有开始的阶段，于是我非常幸运的从0参与了整个公司的安全体系建设。两年后的今天，我来到我现在的东家，负责公司的安全部，主导公司的安全架构设计和体系建设，因此开始分享自己的甲方安全体系建设思路与建设经验。
在第二家公司我整整干了两年，在这两年的职业生涯里，最大的收获就是练就了自己的全局观。要站在一个更高的角度看待甲方安全，首先要知道甲方安全有哪些方向以及每个安全方向都做什么，要知道安全的每个方向都做什么最好的办法就是动手去做，在这两年的职业生涯中，我撸过硕博论文落地，写过代码，做过合规，搞过渗透，填过问卷，玩过运营……在整个团队中属于做的最杂的，承接了许多无聊到别人不愿意做的工作，但是我却从中学习到了别人学习不到的东西，那就是甲方安全的整体画像。
两年后，公司已经有接近2000人的规模，而我选择了离开，去了一家年轻且富有前景的公司，做了安全部主管，顺利通过试用期并拿到了高绩效，在这里，我将带着我的团队，承载我的愿景，开启新的征程！
我设计的企业安全体系架构
经过一年的不懈努力，我和我的团队基本完成了公司信息安全体系的初步建设，虽然这其中还有些许不足，同时也还有很多更高级的东西需要安全团队未来有实力之后才能去做，但作为一个小团队，我认为我们是一支优秀的安全团队！
在公司信息安全体系初步建设完成的背景下，我决定将它分享出来与大家共同探讨学习，欢迎大家提出宝贵建议！
我设计的安全体系架构分为六大块：安全开发体系、安全防御体系、数据安全体系、隐私合规体系、资产管理体系、安全管理体系，六大体系共同构成了完整的信息安全体系。
安全架构
企业数据安全体系建设总结
一
数据安全体系介绍
数据安全是以数据为中心而展开一系列安全措施，是实现隐私保护的最重要手段之一，广义上的数据安全体系是指所有与数据相关的安全措施的总和，但为了避免内容的臃肿与冗余，这里的数据安全体系采用狭义概念，仅仅只设计了数据安全独有的一些要素，因此，它并不是一个独立的板块，而是需要与其他安全体系协同才能达到数据安全的效果。对于跟数据安全弱相关的其他要素，在其他安全体系中已有相关介绍，这里就不再详细论述了。
在实践中，我是按照数据的生命周期来建设数据安全体系的，具体分为数据安全管理规范、数据采集、数据传输、数据存储、数据处理、数据流转、数据销毁等七个方面。整体建设思路和一般的数据安全建设路线是一致的，本篇我将逐一展开论述。
实际上，在数据安全体系的具体建设过程中，可能出于不同场景下的考量，实施的内容也和各种文献中的理论略有不同，本文仅在此抛砖引玉供大家参考。
二
数据安全管理规范
为什么要先撰写《数据安全管理规范》呢？我们知道，不同的工程师水平不同，对于同一件事情的处理方式也不同。而在数据安全体系建设过程中，常常需要对数据实施方案进行这样或那样的评估，若没有一个锚定基准，非常容易造成安全性能参差不齐的局面。《数据安全管理规范》的编写主要是为了明确数据安全体系建设过程中的一些标准，这也是建设数据安全体系的第一步。
《数据安全管理规范》的内容一定要符合企业的实际情况，内容可以自行定义，一般包括数据生命周期中各环节的实施规范、数据分类分级参考、不同级别数据的处理措施等。在实际的数据安全实施过程中，安全部门人员可以参考该规范来评估数据生命周期中的各个需求，从而平衡数据安全实施的安全水准，避免出现安全性能参差不齐的情况。
三
数据采集
通常情况下，公司的某个产品要新增一个采集的数据类型，肯定是伴随着一个新功能或旧功能优化出现的，不管是哪种形式，每一个功能的变动都必须按照规定的流程开展，而这个流程的开端往往都是由产品设计人员先提出产品设计需求，前面在安全开发体系建设一文中有过论述，安全部门此时需要对该需求进行安全评审。
那么在数据安全实施中，安全部门首先要对该方案中采集的数据进行合规评估，评估的内容包括：
最小化数据采集：最小化采集即该功能是否必须要采集这个数据。在实践中，若一个功能所采集的数据类型有很多，且都是必须要采集的数据，此时就只能都做采集；若一个功能所采集的数据并不是这个功能所必需的数据，但该数据并不敏感，也可以继续采集，若该数据是个人敏感数据，要不要继续采集就要斟酌斟酌了。
个人信息主体告知：目前各种数据隐私相关的法律法规均有规定，在收集用户个人数据时，应该告知个人信息主体。那么，当决定要采集一个数据的时候，安全部门就需要评估该操作是否要告知信息主体，一般情况下，如果是个人信息，都是需要告知个人信息主体的，告知的方式就是在用户使用到该功能时提醒或隐私政策中通知；如果不是个人信息，则无需告知，例如一件商品的销售量等之类的聚合数据。
数据安全风险评估：数据安全风险评估主要是评估所采集数据的风险级别。根据《数据安全管理规范》，需要对数据进行分类分级，不同级别的数据需要有不同的防护方式。因此，安全部门需要评估所采集的数据处于哪一级别，后续应该采取怎样的安全处置措施等。
除了数据采集的合规评估外，在数据采集这一步还应当有一些安全技术措施以保障数据采集的安全，例如：
数据完整性安全：数据完整性主要在于确保采集的数据是没有被篡改过的，如果采集的数据被篡改过，那么不仅所采集的数据将失去原有的价值，同时还可能带来一系列的安全风险。在实践中，常见的保障数据完整性的方式是使用签名验证，服务端校验客户端的sign、token、key和pwd等参数，只要数据有被篡改，就会导致校验失败，由于这些参数背后的生成算法是未知的，因此这些参数的具体值很难被伪造。
爬虫：爬虫本质上是一套实现高效率下载的程序，可以通过遍历网络内容，按照指定规则提取所需的网页数据，是一个高效的数据采集方式。但爬虫使用不当会带来极大的法律风险，一般情况下，合规使用爬虫的方式是，在使用爬虫爬取个人信息时要征求用户同意，在用户同意后方可进行爬取；在爬取商业数据时，不应存在搭便车等行为，也不可分流被爬网站的用户、降低被爬网站的竞争优势，否则会被认定构成不正当竞争，染上法律风险。
反爬虫：我们不去乱爬别人的数据，不代表别人不会爬取我们的数据，公开的核心数据若被竞争对手爬走并利用，可能会极大的降低我方的竞争优势。常见的反爬虫技术有通过User-Agent来限制对方爬虫、通过IP地址池来限制对方爬虫、通过JS脚本来限制对方爬虫、通过robots.txt来限制对方爬虫等。限制我方数据被爬虫爬取，非常有助于公司保持独有的竞争力。
四
数据传输
在完成数据采集之后，接下来就是数据传输了，如果将数据比作是火车的话，那么在这里，我们要保障的就是铁轨的安全，铁轨的安全有两块，一块是铁轨本身的安全，另一块是铁轨岔路口的安全。在实践中，我将数据传输的安全也分为两块，一块是传输安全，另一块是链路安全。
数据传输安全
全站全链路HTTPS：我们知道，HTTP协议是一个基于请求与响应、无状态的、应用层的协议，它的设计初衷是为了提供一种发布和接收HTML页面的方法，后来被证明是不安全的，之后人们对HTTP协议进行了安全改造，将HTTP加上TLS协议构建成了可进行加密传输、身份认证的网络协议，HTTPS协议主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现了互联网传输安全保护。在实践中，应当对企业内所有站点的所有链路均使用HTTPS协议，不应再使用单纯的HTTP协议。
TLS安全：除了要做到全站全链路使用HTTPS协议外，HTTPS协议本身的安全性也是需要重视的，过去的SSL协议的三个版本均被发现存在安全缺陷，已经不再推荐使用了，而新生代的TLS协议的早期版本也被发现存在安全缺陷，目前最新的TLS版本是TLS1.3，但该版本基本不常用，最常用的安全版本是TLS1.2，同时为了兼容其他不同服务，也会支持TLS1.1，TLS1.1以下的版本均不建议支持。
数据链路安全
CDN安全：CDN即内容分发网络，它是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。一般情况下，使用CDN的常见问题是在回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的，如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言是一个很大的安全隐患。在实践中，常见的安全做法是使用keyless技术，即把证书统一放置于远程服务器管理，这样就可以规避被窃听的风险。实际上，我们在实施中直接使用了阿里云的安全CDN服务。
DNS安全：DNS即域名系统，它是一个将域名和IP地址相互映射的分布式数据库，通过该映射能够更方便地访问互联网。常见的DNS安全问题有DNS欺骗、DNS缓存中毒、DNS劫持、DNS泛洪攻击等等。在实践中，防范DNS的安全风险主要是防范DNS的DDOS攻击和其他衍生安全威胁，如木马、钓鱼、恶意软件等。实际上，我们在实施中直接使用了阿里云的安全DNS服务，一站式提供了DNS的抗DDOS能力和DNS防火墙。
五
数据存储
在完成数据采集和数据传输之后，接下来就是数据存储了。这里的数据存储主要是指云服务的生产数据存储，数据不仅要做到存储安全，还要防止泄露，因此，本节我将从云存储安全和数据防泄露两个方面来对数据存储展开论述。
云存储安全
敏感数据加密存储：首先我们要明确一点，数据加密存储后在使用时是需要解密的，而加解密这个过程是会消耗性能的，因此，出于性能消耗的考量并不是所有数据存储都需要加密，在此前的安全防御体系建设以及本篇的数据采集一节中也有说明，数据在收集完之后要先进行打标，存储时只对打标的敏感数据做加密存储。在实践中，可以开发一个加解密套件，让所有入库或出库的数据均先通过该加解密套件，这样一来，所有入库的数据会自动完成加密，所有出库使用的数据会自动完成解密，从而保持数据库中的数据是加密存储的。需要注意的是，数据加密存储应当使用安全的加密算法，不应使用过时的加密算法。
统一密钥管理系统KMS：数据加密会涉及到密钥相关的问题，比如密钥的生成、传输、保存、泄露等，如何保护好密钥就成了这其中非常重要的一个部分。一般常见的不安全的做法是密钥本地化，这会导致密钥分散在各个代码或配置文件中，缺乏统一管理，造成开发、维护成本巨大，而且导致密钥容易泄露。而安全的做法则是使用统一密钥管理系统，该系统可以轻松创建和管理密钥，同时提供对密钥的保护，避免密钥泄漏，从而有更多精力专注于实现业务场景。在实践中，我们在实施中直接使用了阿里云的统一密钥管理系统。
数据防泄露
云数据防泄露：云数据防泄露的原理和一般数据防泄露的原理是一致的，也是首先进行敏感数据的识别以锁定要保护的对象，具体的方式主要是通过内置算法规则和自定义敏感数据识别规则，对存储的数据库类型数据以及非数据库类型文件进行整体扫描、分类、分级。之后进行细粒度的数据审计，即审计用户的终端信息、使用工具、数据信息、返回结果等，全场景还原用户行为轨迹，为此后追踪溯源数据的访问行为奠定基础。最后对数据泄露进行检测与防护，即通过智能化检测模型分析内外账号对敏感文件的访问行为，实现对敏感数据访问的异常检测，同时为相关部门人员提供安全告警。在实践中，我们在实施中直接使用了阿里云的数据安全产品。
办公数据防泄露：办公数据防泄露我在安全防御体系建设一文中已经有过详细论述了，简单讲就是采购一套DLP设施，给所有办公终端都安装上监控客户端，并收集公司所有部门的数据，之后对收集的数据进行分类分级，以及关键词提取并编制成安全防护策略，在防护策略配置生效后，使用有监控客户端的办公终端外发触发防护策略的敏感信息就会被记录。此后只需做好安全运营工作就可以了，安全运营工作主要有两块，一块是监控客户端的掉线情况，对于长期掉线的员工要进行回访，另一块是每天的外发事件审计，对于频繁外发敏感信息的员工要进行思想教育。
六
数据处理
实际上，在数据安全生命周期中，数据存储与数据处理通常是并行开展的，两者之间并没有严格的孰先孰后的界限，在实践中，数据处理一般包括数据访问、数据脱敏、数据打标、数仓处理等。接下来我将逐一对这些点展开论述。
数据访问
特权账号管理：特权账号的管理我在安全防御体系建设一文中有过详细介绍，简单讲就是不同敏感级别的特权账号需要按不同的保管方式来进行保管，在数据安全管理中，特权账号就是指数据库的超级管理员账号，这个账号由运维部门来保管即可，特权账号可以对子账号授权到库表列，而子账号只能查询自己被授权的数据，同时也可以创建拥有其他权限的子管理账号，这样以来，数据库的账号权限管理就基本成型了。
多权分立管理：多权分立主要是为了避免超级账号过度使用的问题，可以想象，如果只有超级账号和用户账号两种分类，介于超级账号权限和用户账号权限之间的业务需求开展就成了问题，如果使用用户账号则没有权限，如果使用超级账号又会造成超级账号滥用，因此，就需要超级账号来创立一些子管理账号，为不同的子管理账号分配不同的管理权限，常见的多权分立主要有研发角色和运维角色的分离，运维角色和审计角色的分离等。此后，对于要执行哪些业务需求只需要使用这些子管理账号来实施就可以了。
API访问数据库数据：API访问数据库即指数据的服务化，通俗了讲就是屏蔽了各种直接访问数据的途径，必须通过API接口访问数据。有了API接口控制，在进行权限管理以及安全审计时就会方便很多，同时造成的安全风险也更小。这和所有服务器必须通过堡垒机登录，不能直接连接服务器是一样的道理。在实践中，安全部门在此所扮演的角色通常是需求方，即安全部门提出该需求，技术部门将自己的数据访问和功能接口化，当所有部门都实现了接口化时，其他各种直接访问数据的途径就可以屏蔽掉了。
数据脱敏
此处的数据脱敏与常规意义上的数据脱敏在受众应用上有所不同，常规意义上的脱敏是指对外应用的脱敏，主要目的是防止敏感信息泄露、撞号和爬虫，脱敏的对象是应用中公开的敏感信息，这个我会在之后进行论述。而此处的脱敏则是指对内应用的脱敏，包括对外应用的测试环境等，主要目的是防止内部人员泄露信息，脱敏的对象是日志中的敏感数据以及测试数据等。
一般情况下，这里常见的脱敏目标主要是Debug日志中的敏感数据、监控日志中的敏感数据、生产转测试的敏感数据等。在实践中，对内应用的敏感数据脱敏首先要检测系统中的敏感信息，这里可以选择从Log中获取，也可以从JS前端获取，两个方案各有优劣，从Log中获取要看公司整体上对日志的规范，不然每个系统一种日志，对接周期长工作量大。从前端JS获取比较轻量化，但要考虑性能对业务的影响。检测的目的是持续发现敏感信息变化，因为在内部复杂环境中，系统会不断的改造升级，如果缺少持续监控的手段，会变成运动式工程，无法保证持续性。
检测之后要做的事情，就是进行脱敏处理了。脱敏过程需要与业务方沟通明确好，哪些字段必须强制完全脱敏，哪些是半脱敏。在应用系统权限建设比较规范的情况下，可以考虑基于角色进行脱敏，例如业务风控人员，是需要查看银行卡信息的，此时可以根据角色赋予免疫权限，但客服人员则不需要查看完整信息，需要进行强制脱敏。在免疫和脱敏之间，还有一层半脱敏，是指在需要的时候，可以点击查看完整数据，但点击动作会被记录。
就脱敏整体而言，应该有一个全局视图。每天有多少敏感信息被访问到，有多少信息未脱敏，未脱敏的原因是什么。这样可以整体追踪变化，目标是不断降低敏感信息访问率，当视图出现异常波动，则代表业务产生了变化，需要追踪事件原因。
数据打标
数据打标一般是和数据的分类分级挂钩的，在数据完成采集之后，就需要对采集到的数据进行分类分级，并对特定类型和特定级别的数据进行打标，打标主要是为了方便后续对数据的一些操作，通过前述我们知道，不管是数据加密还是数据脱敏，出于性能消耗的考虑都只对敏感数据开展，那么系统是如何知道哪些数据是敏感数据呢，就是依据这里的打标，对所有敏感数据打上标之后，系统在进行数据的加密或脱敏时，只对打了标的数据进行就可以了。
在实践中，数据打标有两个需要注意的地方，第一个是覆盖率与准确度，即数据统计范围要尽可能覆盖所有数据，降低未知数据盲区；同时对敏感数据的判断要能够尽可能准确，例如一个11位数字的字符串，它可能是手机号，也可能就是单纯的字符串而已，此时是否能将真正的手机号判定出来并对其进行打标，就是准确率的一个考验了。第二个是数据类型和敏感等级，即数据的分类分级，在完成数据的分类分级后，根据实际需求，只对特定类型和特定级别的数据进行打标就可以了。
数仓处理
数据仓库加密：数据仓库加密实际和本文第五节所讲的敏感数据加密存储是一样的，只对打标的敏感数据进行加密存储，此处就不再多说了。
敏感数据流转链路安全：这里的敏感数据主要是指数据仓库中的敏感数据，在实践中，可以设置一个数据申请审批流程，同时部署一个阿里云远程云桌面，任何人要调取数据仓库中的数据时，都应当先提交数据申请流程，申请流程中应当明确本次具体需要哪些数据，在申请流程审批通过后，数据仓库管理员将对应的数据发送到部署的阿里云远程云桌面中创建的加密目录下，之后将加密目录地址和密码发送给数据申请人，数据申请人根据密码去该云桌面进行数据的查看和处理，在保障数据安全的前提下，数据使用完成后进行删除。
匿名化：数据匿名化指的是用于去除或模糊一个或多个数据存储库的一个或多个属性值的计算机制，使得数据存储库的结果视图不能够识别个人的敏感信息或将个人与敏感信息相关联。目标是让其他人无法推断特定的个人与特定的数据集相关。在实践中，常见的匿名化算法是K匿名算法，K匿名算法通过扰动和泛化的方法发布精度较低的数据，使得每一个准标识符都至少对应k条记录，这样就不能唯一识别，从而保护了用户的隐私。具体读者可以阅读网络上的相关技术介绍，此处就不多做讲解了。
七
数据流转
数据流转也是数据安全生命周期的一部分，它不同于数据传输，数据流转主要是指数据的共享、传播等等。在实践中，我将数据的流转分为技术安全和合规安全两部分，下面将逐一展开论述。
技术安全
数据水印：这里的数据水印主要是为了在数据泄露时进行溯源定责。在不影响数据使用的前提下，数据水印通过对原数据添加伪行、伪列、对敏感数据脱敏并植入标记等方式进行水印化处理，水印数据具有高可用性、高透明无感、高隐蔽性等特点，不易被外部发现破解。如果出现信息泄露，则可以从泄露的数据中提取水印标识，通过读取水印标识编码，追溯该泄露数据的流转流程，并定位到泄露单位及责任人，实现数据泄露的精准溯源定责。
展示脱敏：此处的脱敏主要是指对外应用的脱敏，目的是为了防止敏感信息泄露、撞号和爬虫，脱敏的对象是应用中公开的敏感信息。在实践中，对外应用的脱敏可以分层来对待。默认情况下，对于银行卡号、身份证号、手机号、地址等关键信息应强制脱敏，以****替换关键位置，这样即使被撞库或者爬虫，也获取不到相关信息，从而保护用户的数据安全，同时还能防止敏感数据泄露。但总有用户需要看到自己或修改自己的完整信息，这时就需要分层保护了，分层保护主要是根据常用设备来判断，如果是常用设备，则可以无障碍的点击后显示，如果非常用设备，则推送一个强验证。
传输加密：这里的传输加密有两层含义，一个是对传输的数据进行加密，即在发出请求数据包时，除了请求头信息之外，对于请求体的所有数据均应进行加密处理，同样的，对于返回包也一样，除了返回头信息之外，对于返回体的所有数据均应进行加密处理。第二块是传输通道加密，即本篇前文所述的使用基于TLS安全版本的HTTPS协议，除此外，还可以使用SSL Pinning技术，将证书强绑定，从而实现传输通道的安全。
合规安全
第三方法律条款：在实践中，数据在流转、共享或传播时，合规是必须要关注的一个点。通常情况下，不管是我方是作为数据所有者还是数据处理者，我方都应该和数据上下游企业签订相关的数据委托协议或其他安全协议，以此来保证数据的转让安全和处理安全，在真正发生安全风险的时候，可以规避掉一部分责任。
隐私政策声明：除了欧盟GDPR，国内相关法律也有规定，收集的用户数据在转让给第三方时，应当告知用户转让给了哪些第三方，为什么转让给这些第三方，同时还应征求用户同意，在用户同意之后才能将用户数据转让给相关第三方。数据转让给第三方的场景有很多，例如，很多公司没有支付牌照，在进行财务操作时需要将银行卡号转让给第三方银行，此时就构成了用户数据转让。在实践中，一般是通过修改隐私政策，增加第三方信息以及转让数据的用途，之后让用户重新阅读隐私政策来征求用户的同意。
数据跨境合规：数据跨境有两种场景，一种是在国外有开展具体业务，收集相关用户数据，但公司总部只有一个，这时候就必须要让数据跨境传输，我前东家就是这样的跨国企业，这种场景下遵守当地的法律法规是必须的，具体可以阅读我撰写的合规类博客，此处就不再多说了。另一种场景是国外没有任何业务，但因为其他一些原因，需要将国内的数据存放到国外，这个时候最重要的是选择目标存放国，在实践中，一般情况下不要选择经济发达的国家，因为经济发达的国家法律也完善，不知道啥时候就触碰哪条法律了，此时可以选择一些经济不发达的地方，例如菲律宾、越南等。
八
数据销毁
数据销毁是数据安全生命周期的最后一步，数据销毁的安全在于两方面，一方面是数据本身的安全销毁，另一方面是数据存储介质的安全销毁。
数据销毁：在实践中，销毁云服务器中的数据时，除了删除原始的数据外，还应当删除备份的数据，最后下线该服务器，数据就算销毁了。而对于本地数据，除了删除本地存储的数据和备份数据外，还应当对数据存储介质进行低级格式化或填充，让数据无法恢复，从而实现数据的安全销毁。
介质销毁：在实践中，云服务器的数据存储介质无法销毁，只须下线就可以了。对于本地数据的存储介质，应当对其进行细致评估，如果该介质存在一定价值，只需要对该介质进行低级格式化或填充即可，如果要销毁的数据至关重要，而存储该数据的介质的价值却很低，可以考虑执行物理销毁，即将该存储介质砸碎即可。
九
总结
数据安全是安全体系中重要的一环，要做的事情非常多也非常重要，同时它也是一个深度关联其他安全模块的模块，只有这些模块全部都做好了，才能最终达到数据安全的效果。以上我所论述的只是数据安全中的一部分基础内容，在此抛砖引玉供大家参考，不管现实与理论有多少差距，只有基于实际的、适合自己的、能落地的方案，才是最好的方案。
未完待续
原文始发于微信公众号（安世加）：技术干货 | 企业安全体系架构实践之道（六）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论