互联网企业数据安全体系建设与帐号管理趋势
2010-08-11 16:29:48 
阿炯
互联网企业数据安全体系
国内互联网帐号管理趋势
系统管理制度之三权分立
中国网络安全审查认证和市场监管大数据中心正式挂牌
互联网企业数据安全体系
一、背景
Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。虽然媒体上发表了很多谴责的言论，但实事求是地讲，Facebook面临是一个业界难题，任何一家千亿美元的互联网公司面对这种问题，可能都没有太大的抵抗力，仅仅是因为全球区域的法律和国情不同，暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私，在安全领域中，数据安全这个子领域也重新被提到了一个新的高度，所以笔者就借机来说一下数据安全建设。
二、概念
这里特别强调一下，“隐私保护”和“数据安全”是两个完全不同的概念，隐私保护对于安全专业人员来说是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。有些公司甚至把自己定义为数据公司，如果不用数据来做点什么，要么用户体验大打折扣，要么商业价值减半。GDPR即将实施，有些公司或将离场欧洲，就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司，他们很大程度上并不能真正代表用户意愿，而只是因为自家没有数据或缺少数据，随口说说而已。
数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到，数据安全并不是一个独立的要素，而是需要连同网络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最终达到数据安全的效果。所以本文尽可能的以数据安全为核心，但没有把跟数据安全弱相关的传统安全体系防护全部列出来，对于数据安全这个命题而言尽可能的系统化，又避免啰嗦。另外笔者也打算在夏季和秋季把其他子领域的话题单独成文，譬如海量IDC下的入侵防御体系等，敬请期待。
三、全生命周期建设
尽管业内也有同学表示数据是没有边界的，如果按照泄露途径去做可能起不到“根治”的效果，但事实上以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施：
四、数据采集
数据泄露有一部分原因是用户会话流量被复制，尽管有点技术门槛，但也是发生频率比较高的安全事件之一，只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。
流量保护
全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告当然也可以存数据，插木马，甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制流量，甚至定向APT，最终只是看操纵流量后达到目的的收益是否具有性价比。
HTTPS是一个表面现象，它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的，同时，也不是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题，比如使用不安全的协议TLS1.0、SSL3，采用已经过时的弱加密算法套件，实现框架安全漏洞如心脏滴血，还有很多的数字证书本身导致的安全问题。
全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数据，原因是CDN回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言也是一个很大的安全隐患，所以后来衍生出了Keyless CDN技术，无需给出自己的证书就可以实现CDN回源加密。
广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案是跨IDC流量自动加密、TLS隧道化。
业务安全属性
在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全，只要账号泄露撞库&爆破到达一定数量级，把这些账号的数据汇总一下，就必定可以产生批量数据泄露的效果。
第二个问题是反爬，爬虫的问题存在于一切可通过页面、接口获取数据的场合，大概1小时爬个几百万条数据是一点问题都没有的，对于没有彻底脱敏的数据，爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术，培育了不少黑产和数据获取的灰色地带。
UUID
UUID最大的作用是建立中间映射层，屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID，但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据，因为实名制，手机号越来越能代表个人标识，且一般绑定了各种账号，更改成本很高，找到手机号就能对上这个人，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候，这个原本用于程序检索的数据结构也一下子变成了个体识别数据，也都需要纳入保护范畴。
五、前台业务处理
鉴权模型
在很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出现用户鉴权，进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种K/V、RDS关系型数据库、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。
在数据层只知道请求来自一个数据访问层中间件，来自一个RPC调用，但完全不知道来自哪个用户，还是哪个诸如客服系统或其他上游应用，无法判断究竟对当前的数据对象是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型认证、授权、管理、审计。外面防御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题，关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》，其中提到Google的方法是内网RPC鉴权，由于Google的内网只有RPC一种协议，所以就规避了上述大多数安全问题。
对于业务流的鉴权模型，本质上是需要做到Data和App分离，建立Data默认不信任App的模型，而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。
服务化
服务化并不能认为是一个安全机制，但安全却是服务化的受益者。我们再来温习一下当年Bezos在Amazon推行服务化的一纸号令：
1所有团队今后将通过服务接口公开他们的数据和功能。
2团队必须通过这些接口相互通信。
3不允许使用其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不支持共享内存模式，无后门。唯一允许的通信是通过网络上的服务接口调用。
4他们使用什么技术并不重要。HTTP，Corba，Pubsub，自定义协议 - 无关紧要。贝索斯不在乎。
5所有服务接口无一例外都必须从头开始设计为可外部化。也就是说，团队必须规划和设计能够将接口展示给外部开发人员。没有例外。 6任何不这样做的人都会被解雇。
服务化的结果在安全上的意义是必须通过接口访问数据，屏蔽了各种直接访问数据的途径，有了API控制和审计就会方便很多。
内网加密
一些业界Top的公司甚至在IDC内网里也做到了加密，也就是在后台的组件之间的数据传输都是加密的，譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多，所以这里是比较考验工程能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言，这个需求可能有点苛刻了，所以笔者认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算？如果私有协议里不含有标准TLSSHA256以上强度的加密，或者只是信息不对称的哈希，笔者认为都不算。
数据库审计
数据库审计/数据库防火墙是一个入侵检测/防御组件，是一个强对抗领域的产品，但是在数据安全方面它的意义也是明显的：防止SQL注入批量拉取数据，检测API鉴权类漏洞和爬虫的成功访问。
除此之外，对数据库的审计还有一层含义，是指内部人员对数据库的操作，要避免某个RD或DBA为了泄愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。
六、数据存储
数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结：“AWS所有的新服务，在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。
HSM/KMS
业界的普遍问题是不加密，或者加密了但没有使用正确的方法：使用自定义UDF，算法选用不正确或加密强度不合适，或随机数问题，或者密钥没有Rotation机制，密钥没有存储在KMS中。数据加密的正确方法本身就是可信计算的思路，信任根存储在HSM中，加密采用分层密钥结构，以方便动态转换和过期失效。当Intel CPU普遍开始支持SGX安全特性时，密钥、指纹、凭证等数据的处理也将以更加平民化的方式使用类似Trustzone的芯片级隔离技术。
结构化数据
这里主要是指结构化数据静态加密，以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密持久化，另外除了数据库外，数仓里的加密也是类似的。比如，在 Amazon Redshift 服务中，每一个数据块都通过一个随机的密钥进行加密，而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥，这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的技术，不再展开。
文件加密
对单个文件独立加密，一般情况下采用分块加密，典型的场景譬如在《互联网企业安全高级指南》一书中提到的iCloud将手机备份分块加密后存储于AWS的S3，每一个文件切块用随机密钥加密后放在文件的meta data中，meta data再用file key包裹，file key再用特定类型的data key涉及数据类型和访问权限加密，然后data key被master key包裹。
文件系统加密
文件系统加密由于对应用来说是透明的，所以只要应用具备访问权限，那么文件系统加密对用户来说也是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题，即使去机房拔一块硬盘，或者从一块报废的硬盘上尝试恢复数据，都是没有用的。但是对于API鉴权漏洞或者SQL注入而言，显然文件系统的加密是透明的，只要App有权限，漏洞利用也有权限。
七、访问和运维
在这个环节，主要阐述防止内部人员越权的一些措施。
角色分离
研发和运维要分离，密钥持有者和数据运维者要分离，运维角色和审计角色要分离。特权账号须回收，满足最小权限，多权分立的审计原则。
运维审计
堡垒机跳板机是一种针对人肉运维的常规审计手段，随着大型IDC中运维自动化的加深，运维操作都被API化，所以针对这些API的调用也需要被列入审计范畴，数量级比较大的情况下需要使用数据挖掘的方法。
工具链脱敏
典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中，通常由于运维和安全的监控系统包含了全站用户流量，对用户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出一些运营数据，譬如模糊的交易数目，这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件，因此都是需要注意的数据泄漏点。
生产转测试
生产环境和测试环境必须有严格定义和分离，如特殊情况生产数据需要转测试，必须经过脱敏、匿名化。
八、后台数据处理
数仓安全
目前大数据处理基本是每个互联网公司的必需品，通常承载了公司所有的用户数据，甚至有的公司用于数据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能力，因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式，不去过于纠结开源平台本身的安全，但在公司规模比较大，数据RD和BI分析师成千上万的时候，内部信任模式就需要被抛弃了，这时候需要的是一站式的授权&审计平台，需要看到数据的血缘继承关系，需要高敏数据仍然被加密。在这种规模下，工具链的成熟度会决定数据本地化的需求，工具链越成熟数据就越不需要落到开发者本地，这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化，尽可能避免人工操作。
对于数据的分类标识、分布和加工，以及访问状况需要有一个全局的大盘视图，结合数据使用者的行为建立“态势感知”的能力。因为数仓是最大的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态：放逐+检测型 or 隔离+管控型。
匿名化算法
匿名化算法更大的意义其实在于隐私保护而不在于数据安全关于隐私保护部分笔者打算另外单独写一篇，如果说对数据安全有意义，匿名化可能在于减少数据被滥用的可能性，以及减弱数据泄漏后的影响面。
九、展示和使用
这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方，都可能是数据泄露的重灾区。
展示脱敏
对页面上需要展示的敏感信息进行脱敏。一种是完全脱敏，部分字段打码后不再展示完整的信息和字段，另一种是不完全脱敏，默认展示脱敏后的信息，但仍然保留查看明细的按钮API，这样所有的查看明细都会有一条Log，对应审计需求。具体用哪种脱敏需要考虑工作场景和效率综合评估。
水印
水印主要用在截图的场景，分为明水印和暗水印，明水印是肉眼可见的，暗水印是肉眼不可见暗藏在图片里的识别信息。水印的形式也有很多种，有抵抗截屏的，也有抵抗拍照的。这里面也涉及很多对抗元素不一一展开。
安全边界
这里的边界其实是办公网和生产网组成的公司数据边界，由于办公移动化程度的加深，这种边界被进一步模糊化，所以这种边界实际上是逻辑的，而非物理上的，它等价于公司办公网络，生产网络和支持MDM的认证移动设备。对这个边界内的数据，使用DLP来做检测，DLP这个名词很早就有，但实际上它的产品形态和技术已经发生了变化，用于应对大规模环境下重检测，轻阻断的数据保护模式。
除了DLP之外，整个办公网络会采用BeyondCorp的“零信任”架构，对整个的OA类应用实现动态访问控制，全面去除匿名化访问，全部HTTPS，根据角色最小权限化，也就是每个账号即使泄露能访问到的也有限。同时提高账号泄露的成本多因素认证和检测手段，一旦检测到泄露提供远程擦除的能力。
堡垒机
堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法，这种方法跟VDI类似，比较厚重，使用门槛不高，不适合大面积普遍推广。
十、共享和再分发
对于业务盘子比较大的公司而言，其数据都不会是只在自己的系统内流转，通常都有开放平台，有贯穿整个产业链的上下游数据应用。Facebook事件曝光其实就属于这类问题，不开放是不可能的，因为这影响了公司的内核—-赖以生存的商业价值。所以这个问题的解决方案等价于：
1、内核有限妥协为保障用户隐私牺牲一部分商业利益；
2、一站式数据安全服务。
防止下游数据沉淀
首先，所有被第三方调用的数据，如非必要一律脱敏和加密。如果部分场景有必要查询明细数据，设置单独的API，并对账号行为及API查询做风控。其次如果自身有云基础设施，公有云平台，可以推动第三方上云，从而进行1安全赋能，避免一些因自身能力不足引起的安全问题；2数据集中化，在云上集中之后利于实施一站式整体安全解决方案数据加密，风控，反爬和数据泄露检测类服务，大幅度降低外部风险并在一定程度上降低作恶和监守自盗的问题。
反爬
反爬在这里主要是针对公开页面，或通过接口爬取的信息，因为脱敏这件事不可能在所有的环节做的很彻底，所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘，最终形成一些诸如用户关系链，经营数据或辅助决策类数据，造成过度信息披露的影响。
授权审核
设置专门的团队对开放平台的第三方进行机器审核及人工审核，禁止“无照经营”和虚假三方，提高恶意第三方接入的门槛，同时给开发者/合作方公司信誉评级提供基础。
法律条款
所有的第三方接入必须有严格的用户协议，明确数据使用权利，数据披露限制和隐私保护的要求。像GDPR一样，明确数据处理者角色和惩罚条约。
十一、数据销毁
数据销毁主要是指安全删除，这里特别强调是，往往数据的主实例容易在视野范围内，而把备份类的数据忽略掉。如果希望做到快速的安全删除，最好使用加密数据的方法，因为完整覆写不太可能在短时间内完成，但是加密数据的安全删除只要删除密钥即可。
十二、数据的边界
数据治理常常涉及到“边界”问题，不管你承不承认，边界其实总是存在的，只不过表达方式不一样，如果真的没有边界，也就不存在数据安全一说。
企业内部
在不超越网络安全法和隐私保护规定的情况下，法律上企业对内部的数据都拥有绝对控制权，这使得企业内部的数据安全建设实际上最后会转化为一项运营类的工作，挑战难度也无非是各个业务方推动落地的成本。但对规模比较大的公司而言，光企业内部自治可能是不够的，所以数据安全会衍生出产业链上闭环的需求。
生态建设
为了能让数据安全建设在企业内部价值链之外的部分更加平坦化，大型企业可能需要通过投资收购等手段获得上下游企业的数据控制权及标准制定权，从而在大生态里将自己的数据安全标准推行到底。如果不能掌控数据，数据安全也无从谈起。在话语权不足的情况下，现实选择是提供更多的工具给合作方，也是一种数据控制能力的延伸。
十三、ROI和建设次第
对于很多规模不大的公司而言，上述数据安全建设手段可能真的有点多，对于小一点公司即便什么事不干可能也消化不了那么多需求，因为开源软件和大多数的开发框架都不具备这些能力，需要DIY的成分很高，所以我们梳理一下前置条件，优先级和ROI，让数据安全这件事对任何人都是可以接受的，当然这种情况其实也对应了一些创业空间。
基础
账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础，但能体现为优势的部分：基础架构统一，应用架构统一，如果这两者高度统一，数据安全建设能事半功倍。
日志收集
日志是做数据风控的基础，但这里面也有两个比较重要的因素：
办公网络是否BeyondCorp化，这给数据风控提供了极大地便利。
服务化，所有的数据调用皆以API的形式，给日志记录提供了统一的形式。
数据风控
在数据安全中，“放之四海皆准”的工作就是数据风控，适用于各类企业，结合设备信息、账号行为、查询/爬(读)取行为做风控模型。对于面向2C用户类，2B第三方合作类，OA员工账号类都是适用的。具体的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。
作者简介
赵彦，现任美团集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。加盟美团前，曾任华为云安全首席架构师，奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是Ph4nt0m Security Team的核心成员，互联网安全领域第一代资深从业者。
国内互联网帐号管理趋势
帐号是一个你使用服务的必备品，帐号数量(用户数)也是比流量更能够衡量一个网站影响力的指标，所以帐号资源一直被大量网站看作命根子。多年之前国外就支持Email作为网站帐号，从2005年出现OpenID，再到2008年、2009年Facebook Connect的大红大紫。他们的目的是解放用户，一个Email、一个Facebook、一个Google帐号你就能够登陆所有网站，不需要重复记忆多 个密码、多个密码保护资料。
关于帐号的开放中国一直被边缘，所幸现在已经看到了一些不错的趋势。这些改变第一要感谢国外的优秀榜样，例如Google和Facebook；第二要感谢那些创业网站们，以创业者的姿态为互联网帐号开放作出了自己的贡献，例如鲜果、例如豆瓣。这些趋势很多是伴随着微博出现，能被称为趋势是因为越来越多大站开始学习，这些趋势包括开放式邮箱登陆、手机号登陆、OPenID、多帐号关联、帐号自由更改。
趋势一：开放式邮件登陆
即支持其他网站的Email帐号登陆，伴随着微博的出现，目前新浪、搜狐、网易均以支持以其他竞争对手的Email地址作为微博帐号，并且也能够作为全站通行证使用。腾讯QQ已经支持绑定Email帐号，并且可以用Email登陆微博。这意味着用户不需要为了使用服务再去单独注册一个帐号、多出一个邮箱，只需要使用你已有的Email帐号即可轻松注册。各家的整合程度有差异，例如网易通行证输入默认只提示自家邮箱，但是你仍然可以手动输入其他邮箱帐号(例如Gmail)进行登陆。
趋势二：手机号登陆
使用手机号作为帐号有三个用途，第一可以直接使用手机号进行登陆，第二是方便密码找回，第三是方便密码找回，保障帐号安全。目前国内门户的整合力度并不一样，例如网易、迅雷均支持绑定的手机登陆，而新浪腾讯则只支持服务绑定和安全功能。另外目前手机号大多数只属于一个附属帐号，也就是说大多数情况下你不能直接使用手机号进行注册，而只能绑定已有帐号。
趋势三：OPenID
很多朋友可能会困惑，OPenID功能与上面的邮件、手机登陆有什么区别，应该说功能有重叠的部分，但是OPenID更强大，它不仅可以共享帐号名称，还可以提供各种用户信息，当然这部分信息可以由你自己进行设定。最著名的OPenID案例就是Facebook Connect，你可以授权某网站获取你的Facebook资料、好友甚至更多信息，注册但不仅仅是注册，更像是一个更大意义上的数据共享。国内有涉及到 这一块的包括豆瓣、人人网、新浪微博，但是做的深度都不一样，大多数停留在浅层的登陆功能。
趋势四：多帐号关联
这里面的典型案例是微软的Windows Live，它能够支持多个Live ID的无缝切换。这种功能的意义在于方便拥有多个帐号的用户，例如我有多个网易通行证帐号，其中一个是邮箱注册的通行证，一个是用Gmail注册的通行证。如果我需 要查收网易邮箱邮件的时候我需要一个帐号，而当我登陆网易微博的时候需要切换到Gmail注册的通行证。当然还有一种情况是同一网站的多个帐号。现在国内大网站都没有涉及这个部分，都属于犹抱琵琶半遮面，明知道会有这一步但是却扭扭捏捏不愿意跨出去。
趋势五：帐号自由更改
帐号自由更改包括两个部分，第一是注销，第二是修改。
帐号的自由注销可以有效保护用户的选择自由和隐私安全，也可以对ID比较敏感的新用户更多选择空间，保护有限的帐号资源；帐号修改是让用户在不丢失 数据的情况下平滑迁移帐号，例如我之前的微博帐号是a@a.com，现在我的电子邮箱换成b@b.com，那么自然希望ID在安全的基础上能够自由修改。
门户基本没有这项功能，同样是在犹豫不决，认为用户只要注册了就是自己的，其他都是扯蛋。豆瓣、鲜果都可以自由更换帐号，人人网也可以做到，但是无法更改为已注册帐号。例如之前人人网帐号为A，我想要换成帐号B但是当时没有修改帐号的功能，或者我没有找到这个功能，所以我重新注册了帐号B；两天后我发现了这个功能，所以成功注销了帐号B，想要把帐号A更改为帐号B，但是系统告诉我不能这样做，这属于功能的完成度不高。
系统管理制度之三权分立
三权的理解：配置，授权，审计
三员的理解：系统管理员，安全保密管理员，安全审计员
三员之三权：废除超级管理员；三员是三角色并非三人；安全保密管理员与审计员必须非同一个人。
BMB20-2007中提出的系统管理员、安全保密管理员和安全审计员是3类岗位或角色，并不是指3个人，可以是多人。各涉密信息系统应该根据实际情况，配备合理数量的安全保密管理人员，以满足系统安全保密管理的需要。
一、“三员”职责
系统管理员：主要负责系统的日常运行维护工作。包括网络设备、安全保密产品、服务器和用户终端、操作系统数据库、涉密业务系统的安装、配置、升级、维护、运行管理；网络和系统的用户增加或删除；网络和系统的数据备份、运行日志审查和运行情况监控；应急条件下的安全恢复。
安全保密管理员：主要负责系统的日常安全保密管理工作。包括网络和系统用户权限的授予与撤销；用户操作行为的安全设计；安全保密设备管理；系统安全事件的审计、分析和处理；应急条件下的安全恢复。
安全审计员：主要负责对系统管理员和安全保密员的操作行为进行审计跟踪、分析和监督检查，及时发现违规行为，并定期向系统安全保密管理机构汇报情况。
二、“三员”配置要求
1、系统管理员、安全保密管理员和安全审计员不能以其他用户身份登录系统;不能查看和修改任何业务数据库中的信息；不能增删改日志内容。
2、涉密信息系统三员应由本单位内部人员担任，要求政治上可靠，熟悉涉密信息系统管理操作流程，具有较强的责任意识和风险防控意识；并签署保密承诺书。
3、系统管理人员和安全保密管理人员可由信息化部门专业技术人员担任，对于业务性较强的涉密信息系统可由相关业务部门担任；安全审计员根据工作需要由保密部门或其他能胜任安全审计员工作的人员担任。
4、同一设备或系统的系统管理员和安全审计员不能由同一人兼任，安全保密管理员员和安全审计员不得由同一人兼任。
三、“三员”权限管理流程
当用户需要使用涉密信息系统时，应该首先在本部门提出书面申请，该部门主管领导批准后，根据实际情况对此用户在系统中的权限进行说明，并将整个情况报本单位的保密工作机构备案。
系统管理员收到用户书面申请后，根据该部门主管领导审批结果和本单位保密工作机构的核准认可，在系统中为该用户生成标识符，创建用户账号。
安全保密管理员收到用户书面申请后，根据保密工作机构的审核结果，配置相应权限，并激活账号。至此，该账号才能使用。当用户工作变动或权限发生变化时，由用户所在部门主管领导书面通知安全保密管理员，并报单位的保密工作机构备案。安全保密管理员接到通知后，根据变更结果注销用户账号或进行权限调整。
安全审计员要定期查看与系统管理员、安全保密管理员相关的审计日志，当发现有用户账号增加、删除和用户权限变化的情况时，及时查阅相关手续文件，以确定系统管理员、安全保密管理员的操作是否经过授权和批准。
在实际工作中，通过类似上述的管理流程，使3类安全保密管理人员各司其职，充分发挥作用，再加上完善的安全保密审批监督机制，就能深入贯彻安全保密管理措施，全面实现系统的安全保密目标。
四、涉密信息系统提供“三员”权限划分等安全保密防护措施
(一)“三员”等权限设置
系统管理员、安全保密管理员和安全审计员是否能够发挥实效作用，除了人员设置和管理到位外，还取决于系统使用的业务应用系统和安全保密产品是否提供相应的管理员账号，以及权限划分和审计日志功能。因此，在设计开发业务应用系统和安全保密产品时，应充分考虑该方面的需求，为使用人员提供相应功能。
管理员角色划分
1)、系统管理员
1.负责系统参数，如流程、表单的配置、维护和管理
2.负责用户的注册、删除，保证用户标识符在系统生命周期的唯一性
3.负责组织机构的变动调整，负责与用户权限相关的各类角色的设置
2)、安全保密管理员
1.负责人员涉密等级和职务等信息调整和用户权限的分配
2.负责保管所有除系统管理员以外的所有用户的ID标志符文件，安全保密管理员不能以其他用户身份登录系统
3.不能查看和修改任何业务数据库中的信息
4.负责用户审计日志以及安全审计员日志的查看，但不能增删改日志内容
3)、安全审计员
1.负责监督查看系统管理员、安全保密管理员和安全审计管理员的操作日志，但不能增删改日志内容
2.负责定期备份、维护和导出日志
在应用系统设计过程中应避免超级用户，即该用户具有完全的资源访问权限。对于普通用户的权限，应按照最小授权原则进行划分，将其权限设定在完成工作所需的最小授权范围内。
(二)安全审计功能
审计功能主要记录系统用户业务操作的过程，为安全保密管理员和安全审计员判断用户操作的合法性提供依据。
1.审计范围。包括：审计功能的启动和关闭，用户的增加、修改和删除以及权限变更，系统管理员、安全保密管理员、安全审计员和用户所实施的各种操作，包括查阅、备份、维护和导出审计日志
2.审计记录内容。应包括事件发生的时间、地点、类型、主体、客体和结果(开始、结束、失败、成功等)
3.审计事项管理。审计事项管理是指对核心业务操作、需要进行审计的事件的定义和管理，配置和定义所有可能需要审计的事项或操作
4.审计策略配置。审计策略配置是指审计事项和审计人员之间的关联、设置关系，也就是设置哪些关键人员的哪些关键操作事项需要审计；而且根据国家标准要求，用户的增加和删除、权限的变更、系统管理员、审计管理员、安全管理员和用户所实施的操作必须审计，因此根据审计内容审计分为两类强制审计和可配置审计。
5.审计信息的存储。系统应设计充足的审计记录存储空间，且当存储空间将满时能及时进行告警，必须对已存储的审计记录进行保护，能检测或防止对审计记录的修改和伪造，记录应至少保存三个月。
中国网络安全审查认证和市场监管大数据中心正式挂牌
2023年12月25日，中国网络安全审查认证和市场监管大数据中心（下称网数中心）正式挂牌成立。
根据中央编办批复，中国网络安全审查技术与认证中心更名为中国网络安全审查认证和市场监管大数据中心，整建制划入市场监管总局信息中心，同时划入竞争政策与大数据中心部分职能。主要职责是承担网络安全审查与认证相关标准研究和技术支撑、市场监管信息化建设、大数据分析应用、智慧监管建设等工作。
具体来说，网数中心的主要职责是：
依据《网络安全法》《数据安全法》《个人信息保护法》《网络安全审查办法》及国家有关强制性产品认证法律法规，承担网络安全审查技术与方法研究、网络安全审查技术支撑工作；在批准范围内开展与网络安全相关的产品、管理体系、服务、人员认证和培训、检验检测等工作；参与研究拟订市场监管信息化发展规划，协助指导全国市场监管系统信息化建设、管理和应用推广工作；承担市场监管业务应用系统和总局政务信息系统建设、运维及技术保障工作；承担市场监管行业标准组织协调工作，承担全国统一的市场监管信息化标准体系的建立完善工作；负责市场监管大数据中心建设、管理和运行维护工作，支撑智慧监管建设；受委托承担市场监测技术支撑工作；开展网络安全认证、市场监管信息化与大数据分析应用、智慧监管等领域的国际合作与交流。
国内互联网帐号管理趋势
系统管理制度之三权分立
中国网络安全审查认证和市场监管大数据中心正式挂牌
互联网企业数据安全体系
一、背景
Facebook数据泄露事件一度成为互联网行业的焦点，几百亿美元市值瞬间蒸发，这个代价足以在地球上养活一支绝对庞大的安全团队，甚至可以直接收购几家规模比较大的安全公司了。虽然媒体上发表了很多谴责的言论，但实事求是地讲，Facebook面临是一个业界难题，任何一家千亿美元的互联网公司面对这种问题，可能都没有太大的抵抗力，仅仅是因为全球区域的法律和国情不同，暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私，在安全领域中，数据安全这个子领域也重新被提到了一个新的高度，所以笔者就借机来说一下数据安全建设。
二、概念
这里特别强调一下，“隐私保护”和“数据安全”是两个完全不同的概念，隐私保护对于安全专业人员来说是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。有些公司甚至把自己定义为数据公司，如果不用数据来做点什么，要么用户体验大打折扣，要么商业价值减半。GDPR即将实施，有些公司或将离场欧洲，就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司，他们很大程度上并不能真正代表用户意愿，而只是因为自家没有数据或缺少数据，随口说说而已。
数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到，数据安全并不是一个独立的要素，而是需要连同网络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最终达到数据安全的效果。所以本文尽可能的以数据安全为核心，但没有把跟数据安全弱相关的传统安全体系防护全部列出来，对于数据安全这个命题而言尽可能的系统化，又避免啰嗦。另外笔者也打算在夏季和秋季把其他子领域的话题单独成文，譬如海量IDC下的入侵防御体系等，敬请期待。
三、全生命周期建设
尽管业内也有同学表示数据是没有边界的，如果按照泄露途径去做可能起不到“根治”的效果，但事实上以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施：
四、数据采集
数据泄露有一部分原因是用户会话流量被复制，尽管有点技术门槛，但也是发生频率比较高的安全事件之一，只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。
流量保护
全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告当然也可以存数据，插木马，甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制流量，甚至定向APT，最终只是看操纵流量后达到目的的收益是否具有性价比。
HTTPS是一个表面现象，它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的，同时，也不是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题，比如使用不安全的协议TLS1.0、SSL3，采用已经过时的弱加密算法套件，实现框架安全漏洞如心脏滴血，还有很多的数字证书本身导致的安全问题。
全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数据，原因是CDN回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言也是一个很大的安全隐患，所以后来衍生出了Keyless CDN技术，无需给出自己的证书就可以实现CDN回源加密。
广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案是跨IDC流量自动加密、TLS隧道化。
业务安全属性
在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全，只要账号泄露撞库&爆破到达一定数量级，把这些账号的数据汇总一下，就必定可以产生批量数据泄露的效果。
第二个问题是反爬，爬虫的问题存在于一切可通过页面、接口获取数据的场合，大概1小时爬个几百万条数据是一点问题都没有的，对于没有彻底脱敏的数据，爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术，培育了不少黑产和数据获取的灰色地带。
UUID
UUID最大的作用是建立中间映射层，屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID，但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据，因为实名制，手机号越来越能代表个人标识，且一般绑定了各种账号，更改成本很高，找到手机号就能对上这个人，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候，这个原本用于程序检索的数据结构也一下子变成了个体识别数据，也都需要纳入保护范畴。
五、前台业务处理
鉴权模型
在很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出现用户鉴权，进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害，还包括各种K/V、RDS关系型数据库、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。
在数据层只知道请求来自一个数据访问层中间件，来自一个RPC调用，但完全不知道来自哪个用户，还是哪个诸如客服系统或其他上游应用，无法判断究竟对当前的数据对象是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型认证、授权、管理、审计。外面防御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题，关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》，其中提到Google的方法是内网RPC鉴权，由于Google的内网只有RPC一种协议，所以就规避了上述大多数安全问题。
对于业务流的鉴权模型，本质上是需要做到Data和App分离，建立Data默认不信任App的模型，而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。
服务化
服务化并不能认为是一个安全机制，但安全却是服务化的受益者。我们再来温习一下当年Bezos在Amazon推行服务化的一纸号令：
1所有团队今后将通过服务接口公开他们的数据和功能。
2团队必须通过这些接口相互通信。
3不允许使用其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不支持共享内存模式，无后门。唯一允许的通信是通过网络上的服务接口调用。
4他们使用什么技术并不重要。HTTP，Corba，Pubsub，自定义协议 - 无关紧要。贝索斯不在乎。
5所有服务接口无一例外都必须从头开始设计为可外部化。也就是说，团队必须规划和设计能够将接口展示给外部开发人员。没有例外。 6任何不这样做的人都会被解雇。
服务化的结果在安全上的意义是必须通过接口访问数据，屏蔽了各种直接访问数据的途径，有了API控制和审计就会方便很多。
内网加密
一些业界Top的公司甚至在IDC内网里也做到了加密，也就是在后台的组件之间的数据传输都是加密的，譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多，所以这里是比较考验工程能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言，这个需求可能有点苛刻了，所以笔者认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算？如果私有协议里不含有标准TLSSHA256以上强度的加密，或者只是信息不对称的哈希，笔者认为都不算。
数据库审计
数据库审计/数据库防火墙是一个入侵检测/防御组件，是一个强对抗领域的产品，但是在数据安全方面它的意义也是明显的：防止SQL注入批量拉取数据，检测API鉴权类漏洞和爬虫的成功访问。
除此之外，对数据库的审计还有一层含义，是指内部人员对数据库的操作，要避免某个RD或DBA为了泄愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。
六、数据存储
数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结：“AWS所有的新服务，在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。
HSM/KMS
业界的普遍问题是不加密，或者加密了但没有使用正确的方法：使用自定义UDF，算法选用不正确或加密强度不合适，或随机数问题，或者密钥没有Rotation机制，密钥没有存储在KMS中。数据加密的正确方法本身就是可信计算的思路，信任根存储在HSM中，加密采用分层密钥结构，以方便动态转换和过期失效。当Intel CPU普遍开始支持SGX安全特性时，密钥、指纹、凭证等数据的处理也将以更加平民化的方式使用类似Trustzone的芯片级隔离技术。
结构化数据
这里主要是指结构化数据静态加密，以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密持久化，另外除了数据库外，数仓里的加密也是类似的。比如，在 Amazon Redshift 服务中，每一个数据块都通过一个随机的密钥进行加密，而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥，这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的技术，不再展开。
文件加密
对单个文件独立加密，一般情况下采用分块加密，典型的场景譬如在《互联网企业安全高级指南》一书中提到的iCloud将手机备份分块加密后存储于AWS的S3，每一个文件切块用随机密钥加密后放在文件的meta data中，meta data再用file key包裹，file key再用特定类型的data key涉及数据类型和访问权限加密，然后data key被master key包裹。
文件系统加密
文件系统加密由于对应用来说是透明的，所以只要应用具备访问权限，那么文件系统加密对用户来说也是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题，即使去机房拔一块硬盘，或者从一块报废的硬盘上尝试恢复数据，都是没有用的。但是对于API鉴权漏洞或者SQL注入而言，显然文件系统的加密是透明的，只要App有权限，漏洞利用也有权限。
七、访问和运维
在这个环节，主要阐述防止内部人员越权的一些措施。
角色分离
研发和运维要分离，密钥持有者和数据运维者要分离，运维角色和审计角色要分离。特权账号须回收，满足最小权限，多权分立的审计原则。
运维审计
堡垒机跳板机是一种针对人肉运维的常规审计手段，随着大型IDC中运维自动化的加深，运维操作都被API化，所以针对这些API的调用也需要被列入审计范畴，数量级比较大的情况下需要使用数据挖掘的方法。
工具链脱敏
典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中，通常由于运维和安全的监控系统包含了全站用户流量，对用户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出一些运营数据，譬如模糊的交易数目，这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件，因此都是需要注意的数据泄漏点。
生产转测试
生产环境和测试环境必须有严格定义和分离，如特殊情况生产数据需要转测试，必须经过脱敏、匿名化。
八、后台数据处理
数仓安全
目前大数据处理基本是每个互联网公司的必需品，通常承载了公司所有的用户数据，甚至有的公司用于数据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能力，因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式，不去过于纠结开源平台本身的安全，但在公司规模比较大，数据RD和BI分析师成千上万的时候，内部信任模式就需要被抛弃了，这时候需要的是一站式的授权&审计平台，需要看到数据的血缘继承关系，需要高敏数据仍然被加密。在这种规模下，工具链的成熟度会决定数据本地化的需求，工具链越成熟数据就越不需要落到开发者本地，这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化，尽可能避免人工操作。
对于数据的分类标识、分布和加工，以及访问状况需要有一个全局的大盘视图，结合数据使用者的行为建立“态势感知”的能力。因为数仓是最大的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态：放逐+检测型 or 隔离+管控型。
匿名化算法
匿名化算法更大的意义其实在于隐私保护而不在于数据安全关于隐私保护部分笔者打算另外单独写一篇，如果说对数据安全有意义，匿名化可能在于减少数据被滥用的可能性，以及减弱数据泄漏后的影响面。
九、展示和使用
这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方，都可能是数据泄露的重灾区。
展示脱敏
对页面上需要展示的敏感信息进行脱敏。一种是完全脱敏，部分字段打码后不再展示完整的信息和字段，另一种是不完全脱敏，默认展示脱敏后的信息，但仍然保留查看明细的按钮API，这样所有的查看明细都会有一条Log，对应审计需求。具体用哪种脱敏需要考虑工作场景和效率综合评估。
水印
水印主要用在截图的场景，分为明水印和暗水印，明水印是肉眼可见的，暗水印是肉眼不可见暗藏在图片里的识别信息。水印的形式也有很多种，有抵抗截屏的，也有抵抗拍照的。这里面也涉及很多对抗元素不一一展开。
安全边界
这里的边界其实是办公网和生产网组成的公司数据边界，由于办公移动化程度的加深，这种边界被进一步模糊化，所以这种边界实际上是逻辑的，而非物理上的，它等价于公司办公网络，生产网络和支持MDM的认证移动设备。对这个边界内的数据，使用DLP来做检测，DLP这个名词很早就有，但实际上它的产品形态和技术已经发生了变化，用于应对大规模环境下重检测，轻阻断的数据保护模式。
除了DLP之外，整个办公网络会采用BeyondCorp的“零信任”架构，对整个的OA类应用实现动态访问控制，全面去除匿名化访问，全部HTTPS，根据角色最小权限化，也就是每个账号即使泄露能访问到的也有限。同时提高账号泄露的成本多因素认证和检测手段，一旦检测到泄露提供远程擦除的能力。
堡垒机
堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法，这种方法跟VDI类似，比较厚重，使用门槛不高，不适合大面积普遍推广。
十、共享和再分发
对于业务盘子比较大的公司而言，其数据都不会是只在自己的系统内流转，通常都有开放平台，有贯穿整个产业链的上下游数据应用。Facebook事件曝光其实就属于这类问题，不开放是不可能的，因为这影响了公司的内核—-赖以生存的商业价值。所以这个问题的解决方案等价于：
1、内核有限妥协为保障用户隐私牺牲一部分商业利益；
2、一站式数据安全服务。
防止下游数据沉淀
首先，所有被第三方调用的数据，如非必要一律脱敏和加密。如果部分场景有必要查询明细数据，设置单独的API，并对账号行为及API查询做风控。其次如果自身有云基础设施，公有云平台，可以推动第三方上云，从而进行1安全赋能，避免一些因自身能力不足引起的安全问题；2数据集中化，在云上集中之后利于实施一站式整体安全解决方案数据加密，风控，反爬和数据泄露检测类服务，大幅度降低外部风险并在一定程度上降低作恶和监守自盗的问题。
反爬
反爬在这里主要是针对公开页面，或通过接口爬取的信息，因为脱敏这件事不可能在所有的环节做的很彻底，所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘，最终形成一些诸如用户关系链，经营数据或辅助决策类数据，造成过度信息披露的影响。
授权审核
设置专门的团队对开放平台的第三方进行机器审核及人工审核，禁止“无照经营”和虚假三方，提高恶意第三方接入的门槛，同时给开发者/合作方公司信誉评级提供基础。
法律条款
所有的第三方接入必须有严格的用户协议，明确数据使用权利，数据披露限制和隐私保护的要求。像GDPR一样，明确数据处理者角色和惩罚条约。
十一、数据销毁
数据销毁主要是指安全删除，这里特别强调是，往往数据的主实例容易在视野范围内，而把备份类的数据忽略掉。如果希望做到快速的安全删除，最好使用加密数据的方法，因为完整覆写不太可能在短时间内完成，但是加密数据的安全删除只要删除密钥即可。
十二、数据的边界
数据治理常常涉及到“边界”问题，不管你承不承认，边界其实总是存在的，只不过表达方式不一样，如果真的没有边界，也就不存在数据安全一说。
企业内部
在不超越网络安全法和隐私保护规定的情况下，法律上企业对内部的数据都拥有绝对控制权，这使得企业内部的数据安全建设实际上最后会转化为一项运营类的工作，挑战难度也无非是各个业务方推动落地的成本。但对规模比较大的公司而言，光企业内部自治可能是不够的，所以数据安全会衍生出产业链上闭环的需求。
生态建设
为了能让数据安全建设在企业内部价值链之外的部分更加平坦化，大型企业可能需要通过投资收购等手段获得上下游企业的数据控制权及标准制定权，从而在大生态里将自己的数据安全标准推行到底。如果不能掌控数据，数据安全也无从谈起。在话语权不足的情况下，现实选择是提供更多的工具给合作方，也是一种数据控制能力的延伸。
十三、ROI和建设次第
对于很多规模不大的公司而言，上述数据安全建设手段可能真的有点多，对于小一点公司即便什么事不干可能也消化不了那么多需求，因为开源软件和大多数的开发框架都不具备这些能力，需要DIY的成分很高，所以我们梳理一下前置条件，优先级和ROI，让数据安全这件事对任何人都是可以接受的，当然这种情况其实也对应了一些创业空间。
基础
账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础，但能体现为优势的部分：基础架构统一，应用架构统一，如果这两者高度统一，数据安全建设能事半功倍。
日志收集
日志是做数据风控的基础，但这里面也有两个比较重要的因素：
办公网络是否BeyondCorp化，这给数据风控提供了极大地便利。
服务化，所有的数据调用皆以API的形式，给日志记录提供了统一的形式。
数据风控
在数据安全中，“放之四海皆准”的工作就是数据风控，适用于各类企业，结合设备信息、账号行为、查询/爬(读)取行为做风控模型。对于面向2C用户类，2B第三方合作类，OA员工账号类都是适用的。具体的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。
作者简介
赵彦，现任美团集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。加盟美团前，曾任华为云安全首席架构师，奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是Ph4nt0m Security Team的核心成员，互联网安全领域第一代资深从业者。
国内互联网帐号管理趋势
帐号是一个你使用服务的必备品，帐号数量(用户数)也是比流量更能够衡量一个网站影响力的指标，所以帐号资源一直被大量网站看作命根子。多年之前国外就支持Email作为网站帐号，从2005年出现OpenID，再到2008年、2009年Facebook Connect的大红大紫。他们的目的是解放用户，一个Email、一个Facebook、一个Google帐号你就能够登陆所有网站，不需要重复记忆多 个密码、多个密码保护资料。
关于帐号的开放中国一直被边缘，所幸现在已经看到了一些不错的趋势。这些改变第一要感谢国外的优秀榜样，例如Google和Facebook；第二要感谢那些创业网站们，以创业者的姿态为互联网帐号开放作出了自己的贡献，例如鲜果、例如豆瓣。这些趋势很多是伴随着微博出现，能被称为趋势是因为越来越多大站开始学习，这些趋势包括开放式邮箱登陆、手机号登陆、OPenID、多帐号关联、帐号自由更改。
趋势一：开放式邮件登陆
即支持其他网站的Email帐号登陆，伴随着微博的出现，目前新浪、搜狐、网易均以支持以其他竞争对手的Email地址作为微博帐号，并且也能够作为全站通行证使用。腾讯QQ已经支持绑定Email帐号，并且可以用Email登陆微博。这意味着用户不需要为了使用服务再去单独注册一个帐号、多出一个邮箱，只需要使用你已有的Email帐号即可轻松注册。各家的整合程度有差异，例如网易通行证输入默认只提示自家邮箱，但是你仍然可以手动输入其他邮箱帐号(例如Gmail)进行登陆。
趋势二：手机号登陆
使用手机号作为帐号有三个用途，第一可以直接使用手机号进行登陆，第二是方便密码找回，第三是方便密码找回，保障帐号安全。目前国内门户的整合力度并不一样，例如网易、迅雷均支持绑定的手机登陆，而新浪腾讯则只支持服务绑定和安全功能。另外目前手机号大多数只属于一个附属帐号，也就是说大多数情况下你不能直接使用手机号进行注册，而只能绑定已有帐号。
趋势三：OPenID
很多朋友可能会困惑，OPenID功能与上面的邮件、手机登陆有什么区别，应该说功能有重叠的部分，但是OPenID更强大，它不仅可以共享帐号名称，还可以提供各种用户信息，当然这部分信息可以由你自己进行设定。最著名的OPenID案例就是Facebook Connect，你可以授权某网站获取你的Facebook资料、好友甚至更多信息，注册但不仅仅是注册，更像是一个更大意义上的数据共享。国内有涉及到 这一块的包括豆瓣、人人网、新浪微博，但是做的深度都不一样，大多数停留在浅层的登陆功能。
趋势四：多帐号关联
这里面的典型案例是微软的Windows Live，它能够支持多个Live ID的无缝切换。这种功能的意义在于方便拥有多个帐号的用户，例如我有多个网易通行证帐号，其中一个是邮箱注册的通行证，一个是用Gmail注册的通行证。如果我需 要查收网易邮箱邮件的时候我需要一个帐号，而当我登陆网易微博的时候需要切换到Gmail注册的通行证。当然还有一种情况是同一网站的多个帐号。现在国内大网站都没有涉及这个部分，都属于犹抱琵琶半遮面，明知道会有这一步但是却扭扭捏捏不愿意跨出去。
趋势五：帐号自由更改
帐号自由更改包括两个部分，第一是注销，第二是修改。
帐号的自由注销可以有效保护用户的选择自由和隐私安全，也可以对ID比较敏感的新用户更多选择空间，保护有限的帐号资源；帐号修改是让用户在不丢失 数据的情况下平滑迁移帐号，例如我之前的微博帐号是a@a.com，现在我的电子邮箱换成b@b.com，那么自然希望ID在安全的基础上能够自由修改。
门户基本没有这项功能，同样是在犹豫不决，认为用户只要注册了就是自己的，其他都是扯蛋。豆瓣、鲜果都可以自由更换帐号，人人网也可以做到，但是无法更改为已注册帐号。例如之前人人网帐号为A，我想要换成帐号B但是当时没有修改帐号的功能，或者我没有找到这个功能，所以我重新注册了帐号B；两天后我发现了这个功能，所以成功注销了帐号B，想要把帐号A更改为帐号B，但是系统告诉我不能这样做，这属于功能的完成度不高。
系统管理制度之三权分立
三权的理解：配置，授权，审计
三员的理解：系统管理员，安全保密管理员，安全审计员
三员之三权：废除超级管理员；三员是三角色并非三人；安全保密管理员与审计员必须非同一个人。
BMB20-2007中提出的系统管理员、安全保密管理员和安全审计员是3类岗位或角色，并不是指3个人，可以是多人。各涉密信息系统应该根据实际情况，配备合理数量的安全保密管理人员，以满足系统安全保密管理的需要。
一、“三员”职责
系统管理员：主要负责系统的日常运行维护工作。包括网络设备、安全保密产品、服务器和用户终端、操作系统数据库、涉密业务系统的安装、配置、升级、维护、运行管理；网络和系统的用户增加或删除；网络和系统的数据备份、运行日志审查和运行情况监控；应急条件下的安全恢复。
安全保密管理员：主要负责系统的日常安全保密管理工作。包括网络和系统用户权限的授予与撤销；用户操作行为的安全设计；安全保密设备管理；系统安全事件的审计、分析和处理；应急条件下的安全恢复。
安全审计员：主要负责对系统管理员和安全保密员的操作行为进行审计跟踪、分析和监督检查，及时发现违规行为，并定期向系统安全保密管理机构汇报情况。
二、“三员”配置要求
1、系统管理员、安全保密管理员和安全审计员不能以其他用户身份登录系统;不能查看和修改任何业务数据库中的信息；不能增删改日志内容。
2、涉密信息系统三员应由本单位内部人员担任，要求政治上可靠，熟悉涉密信息系统管理操作流程，具有较强的责任意识和风险防控意识；并签署保密承诺书。
3、系统管理人员和安全保密管理人员可由信息化部门专业技术人员担任，对于业务性较强的涉密信息系统可由相关业务部门担任；安全审计员根据工作需要由保密部门或其他能胜任安全审计员工作的人员担任。
4、同一设备或系统的系统管理员和安全审计员不能由同一人兼任，安全保密管理员员和安全审计员不得由同一人兼任。
三、“三员”权限管理流程
当用户需要使用涉密信息系统时，应该首先在本部门提出书面申请，该部门主管领导批准后，根据实际情况对此用户在系统中的权限进行说明，并将整个情况报本单位的保密工作机构备案。
系统管理员收到用户书面申请后，根据该部门主管领导审批结果和本单位保密工作机构的核准认可，在系统中为该用户生成标识符，创建用户账号。
安全保密管理员收到用户书面申请后，根据保密工作机构的审核结果，配置相应权限，并激活账号。至此，该账号才能使用。当用户工作变动或权限发生变化时，由用户所在部门主管领导书面通知安全保密管理员，并报单位的保密工作机构备案。安全保密管理员接到通知后，根据变更结果注销用户账号或进行权限调整。
安全审计员要定期查看与系统管理员、安全保密管理员相关的审计日志，当发现有用户账号增加、删除和用户权限变化的情况时，及时查阅相关手续文件，以确定系统管理员、安全保密管理员的操作是否经过授权和批准。
在实际工作中，通过类似上述的管理流程，使3类安全保密管理人员各司其职，充分发挥作用，再加上完善的安全保密审批监督机制，就能深入贯彻安全保密管理措施，全面实现系统的安全保密目标。
四、涉密信息系统提供“三员”权限划分等安全保密防护措施
(一)“三员”等权限设置
系统管理员、安全保密管理员和安全审计员是否能够发挥实效作用，除了人员设置和管理到位外，还取决于系统使用的业务应用系统和安全保密产品是否提供相应的管理员账号，以及权限划分和审计日志功能。因此，在设计开发业务应用系统和安全保密产品时，应充分考虑该方面的需求，为使用人员提供相应功能。
管理员角色划分
1)、系统管理员
1.负责系统参数，如流程、表单的配置、维护和管理
2.负责用户的注册、删除，保证用户标识符在系统生命周期的唯一性
3.负责组织机构的变动调整，负责与用户权限相关的各类角色的设置
2)、安全保密管理员
1.负责人员涉密等级和职务等信息调整和用户权限的分配
2.负责保管所有除系统管理员以外的所有用户的ID标志符文件，安全保密管理员不能以其他用户身份登录系统
3.不能查看和修改任何业务数据库中的信息
4.负责用户审计日志以及安全审计员日志的查看，但不能增删改日志内容
3)、安全审计员
1.负责监督查看系统管理员、安全保密管理员和安全审计管理员的操作日志，但不能增删改日志内容
2.负责定期备份、维护和导出日志
在应用系统设计过程中应避免超级用户，即该用户具有完全的资源访问权限。对于普通用户的权限，应按照最小授权原则进行划分，将其权限设定在完成工作所需的最小授权范围内。
(二)安全审计功能
审计功能主要记录系统用户业务操作的过程，为安全保密管理员和安全审计员判断用户操作的合法性提供依据。
1.审计范围。包括：审计功能的启动和关闭，用户的增加、修改和删除以及权限变更，系统管理员、安全保密管理员、安全审计员和用户所实施的各种操作，包括查阅、备份、维护和导出审计日志
2.审计记录内容。应包括事件发生的时间、地点、类型、主体、客体和结果(开始、结束、失败、成功等)
3.审计事项管理。审计事项管理是指对核心业务操作、需要进行审计的事件的定义和管理，配置和定义所有可能需要审计的事项或操作
4.审计策略配置。审计策略配置是指审计事项和审计人员之间的关联、设置关系，也就是设置哪些关键人员的哪些关键操作事项需要审计；而且根据国家标准要求，用户的增加和删除、权限的变更、系统管理员、审计管理员、安全管理员和用户所实施的操作必须审计，因此根据审计内容审计分为两类强制审计和可配置审计。
5.审计信息的存储。系统应设计充足的审计记录存储空间，且当存储空间将满时能及时进行告警，必须对已存储的审计记录进行保护，能检测或防止对审计记录的修改和伪造，记录应至少保存三个月。
中国网络安全审查认证和市场监管大数据中心正式挂牌
2023年12月25日，中国网络安全审查认证和市场监管大数据中心（下称网数中心）正式挂牌成立。
根据中央编办批复，中国网络安全审查技术与认证中心更名为中国网络安全审查认证和市场监管大数据中心，整建制划入市场监管总局信息中心，同时划入竞争政策与大数据中心部分职能。主要职责是承担网络安全审查与认证相关标准研究和技术支撑、市场监管信息化建设、大数据分析应用、智慧监管建设等工作。
具体来说，网数中心的主要职责是：
依据《网络安全法》《数据安全法》《个人信息保护法》《网络安全审查办法》及国家有关强制性产品认证法律法规，承担网络安全审查技术与方法研究、网络安全审查技术支撑工作；在批准范围内开展与网络安全相关的产品、管理体系、服务、人员认证和培训、检验检测等工作；参与研究拟订市场监管信息化发展规划，协助指导全国市场监管系统信息化建设、管理和应用推广工作；承担市场监管业务应用系统和总局政务信息系统建设、运维及技术保障工作；承担市场监管行业标准组织协调工作，承担全国统一的市场监管信息化标准体系的建立完善工作；负责市场监管大数据中心建设、管理和运行维护工作，支撑智慧监管建设；受委托承担市场监测技术支撑工作；开展网络安全认证、市场监管信息化与大数据分析应用、智慧监管等领域的国际合作与交流。