一、背景

本文将针对互联网安全企业实践的相关知识，收集整理归纳，以对IT安全有了解和认识。

二、知识汇总

2.1、安全建设思考

第一个阶段通常是救火，优先解决业务痛点，同时做一些基础的“保命”工作，来降低安全事件发生的概率，快速找到可能导致内外网安全入侵的安全隐患并修复，比如无线安全、VPN远程访问、弱口令、服务器后门等。这

第二个阶段是体系化建设阶段。过了救火期，可以稍微喘口气，进行有序的安全建设。主要精力是在基础安全建设，比如安全老三样、堡垒机、双因素、VPN之类的。这个阶段还互联网不了，因为团队里基本上不具备开发能力，主要是以商业安全设备为主，外加少量的安全工具自研，提升运维的效率；这个阶段也可以考虑参考ISO27001体系出台三、四级的管理规范，并推动落地，这样确保从源头解决问题，否则你永远处在擦地板的过程，因为水桶有洞，水在不断滴出来，擦一次是干净了，过一会儿又流出来了。

第三个阶段属于安全的高阶阶段，商用系统可能并不能很好地满足需求，所以就需要大量自研工具来解决实际问题，有能力的话安全大数据和APT也可以考虑进来。

第四个阶段进入安全的智能级别，智能的检测、阻断、响应代表公司安全未来的方向。

一个全生命周期内的数据安全措施：

2.2、系统安全架构

系统安全架构应该至少包含三个主要的维度:

第一个就是系统自然的技术堆栈，这个在IT技术里面，任何一下系统的技术堆栈都是天然存在的。我们最常见的系统分层架构，有客户端或者浏览器、APP，下面有运行的代码，它可能运行在中间件服务器上，再下面可能是数据库、操作系统、服务器、网络和基础设施，这是一个最简单的分层方式；

第二个维度是业务流程视角，这个业务流程视角，其实和安全这个课题是没有太大关系的，它更多是关注业务功能实现。比如说支付业务有支持业务的流程，网购有网购业务的流程，理财业务有理财的流程，它是随着系统差别，实现不同的业务目标；

第三个维度安全视图，比如客户端、应用、中间件、DB都有不同的保护机制。在另外一个维度就是业务流程，业务的每个模块也需要不同的保护机制，这些保护机制最后贯穿成一个网状的结构， 如何选择合适的保护机制对它进行保护，那就需要第三个轴安全技术构成三维视角，在安全的机制里面其实它分为2类：第一类是系统自身的防护；第2类是对业务系统的保护。

2.3、安全经验

1）安全首先要做到监管合规，满足一定的安全的等级；其次，身份管理，这个人是谁，在我的系统里面有什么样的权限，授予他可以访问哪些数据。第三个是数据保护，数据保护目前仍是很多企业最关心和最担心的问题，因为全球90%的企业都认为自己可能有数据泄漏方面的风险。另外一块是日志，记录和监控可以协助发现未经经授权的安全事件，有助于确定安全措施有意义的改进，以保护您的公司的机密信息。我们在构建技术保障体系的时候，建议按分层原则，每个层次上都需要考虑相应的保护机制。

2）我们在选购数据中心边界防火墙时，要拆分考虑业务的增长，确保满足业务正常的Scal Out方式横向扩容。对于中心端产品的容量，如果是互联网公司，建议按当前量，放大5至10倍考虑，因为业务的增长往往是倍数成长，非常吓人，不能总是出现性能瓶颈；关于测试，这里指实际环境测试。实验室不全面，如果条件允许，时间、人充足，测试当然没有坏处。如果时间紧、人手不足的情况下，就选择性地进行测试，比如性能类产品首次选择使用时，最好先测试一下。

3）“隐私保护”和“数据安全”：

两者是两个完全不同的概念，隐私保护对于安全专业人员来说是一个更加偏向合规的事情，主要是指数据过度收集和数据滥用方面对法律法规的遵从性，对很多把自身的盈利模式建立在数据之上的互联网公司而言，这个问题特别有挑战。

数据安全是实现隐私保护的最重要手段之一。数据安全并不是一个独立的要素，而是需要连同网络安全、系统安全、业务安全等多种因素，只有全部都做好了，才能最终达到数据安全的效果。

2.4、安全运维

1）两个重要概念

Due care中文通常翻译成适度关注或应用的注意；在信息安全领域，Due care实际上是说一个企业要制定各种各样的策略、规程和标准等，用来对企业信息资产的保护，也就是企业应该做的事情。

Due diligence翻译成适度勤勉或是尽职调查；在信息安全领域，本过程要保证Due care要做的那些事情一直保持在最新状态。

举个例子说明。你要外出时，做了两个动作：

1、想着手机会不会电不够用呢，不够用怎么办；

2、随手把充电宝装口袋了。

1>是你的思想活动，有没有“想”就属于Due care，也可能会顺手查看手机电量。想过之后，可能会觉得电够用不带充电宝，也可能会觉得不够用而带上充电宝，这都不重要，重要的是你“想没想”，有没有检查手机电量的意识（这根弦）。

2>是你的实际动作。如果你觉得电不够用带了充电宝，但没检查充电宝是否有电，或忘了充电线，那就是没做到Due diligence。也就是说虽然采取了相应的动作，但没达到预期的效果。

对于安全来说，需要想到，如果没有采取这个措施，可能存在怎样的安全风险，为了降低风险，采取了一定的行动，并且要确保这个行动是有效的、而且一定要真实的执行。

2）三思而后行三步工作法

IT系统会有各种各样的变更，如发布、升级、割接、改造等。变更是最容易引发系统故障的操作，为了降低变更对系统的影响，我们推进三思而行的三步工作法。做变更之前先问自己三个问题，首先我是这项工作的合适人选吗？其次我有能力执行这个任务吗？最后我能控制整个变更吗？

当三个问题得到的答案是肯定的，再去申请执行这个变更。如果任何问题的答案有迟疑，会和自己的主管协商，制定最佳方案，包括变更失败的回退计划；通过这一举措，大大降低了变更造成的业务影响。

3）安全视野不同

研发：通常关注的是HTTP xxx返回值相关问题、延迟、扩展性、代码重用、Deadline、KPI、需求变更、框架、形式源、功能如何实现、以及代码质量等问题，最主要关注代码有没有bug；

运维：通常关注HTTP 4xx及5xx错误、性能、可靠性、对阀值进行预警、监控图断崖、是否出现异常，最关心别出故障；

安全：更多关注的是1-7层上我的防护措施会不会被绕过，然后就是各种漏洞，开源框架的、编程语言的，代码里的、逻辑上存在的各种安全漏洞公交站，传输过种中以及存储过程中的漏洞，bug的修复，更高级的漏洞利用方式。找出各种高、中、低危漏洞。除此之外还在时刻关注无线渗透、弱口令、0day、彩虹表、各种马、注入、后门等。

4）安全运维自动化

1>Anti-DDOS：

DDOS防护里，可利用自研DDoS攻击看板，实时了解受攻击情况，与运营商BGP联动，实现被攻击IP一键丢黑洞。快速释放被攻击带宽；云端防护是必须要借助的，因为现在的攻击量太大了，需要云清洗能力。如下所示：

上图中的DDoS攻击看板，分成了三个状态，第一块是谁正在被攻击，第二块是哪些被攻击系统正在引流，第三块显示哪些被引流的系统正在做流量清洗，正在做流量清洗的系统，需要特别关注业务的运行情况，确保业务得到保护。

2>交换机封IP：

3>基于VPN的链路容灾

上述案例是一个基于VPN的链路容灾系统设计，这里面做的自动化有几块。一个是全国有几百家汽车站需要与总部系统通讯，如果采购商用VPN系统造价很高，那我们在某宝上买了Netgear的路由器，安装Openwrt开源固件提供VPN服务，大约节省80多万元成本。在这个设计里的专利部分是设计了一套全冗余的结构，冗余的程度达到就算任何一个机房的链路坏了、设备坏了甚至其中1个IDC全部crash，我的这套系统仍然是可以持续运行。

对于VPN的管理，可自研开发VPN管理工具，实时监控VPN隧道存活情况。

4>防火墙自动化

上图案例中的拓扑图展示的一些较大规模互联网公司或企业典型的防火墙部署示意图，体现了边界防护、重要业务系统隔离保护、办公与生产隔离的一些保护需求。

组织可自研防火墙运维管理系统，扑计算，通过计算路由，生成防火墙拓扑，判断出一个策略需求，经过哪几台防火墙。策略查询2个功能，一是用户自助查询2点间的防火墙策略；二是申请策略时后台会自动判断是否已有策略支持，如果有的话，会返回消息告诉用户说已经有策略了，无须申请。

策略生成模块，抽象策略对象，判断策略申请是增删改哪种场景生成相应的工艺。工单对接是指如何与企业中的变更管理工单管理系统对接。自动化不能逾越流程，反而要严格遵循流程。在工单对接环节会重点强调。其它工具，VPN管理、改密码、审批关系维护、墙元素查询，都非常有价值，极大提升运维工作效率。

5>流量保护

全站HTTPS是目前互联网的主流趋势，它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的，比如电信运营商内部偶有舞弊现象，各种导流劫持插广告（当然也可以存数据，插木马），甚至连AWS也被劫持DNS请求，对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好，攻击者也可以不通过正面渗透，而是直接复制流量，甚至定向APT（黑客以窃取核心资料为目的，针对客户所发动的网络攻击和侵袭行为，是一种蓄谋已久的“恶意商业间谍威胁”）。

另外，有了HTTPS也不一定就安全。HTTPS本身也有各种安全问题，比如使用不安全的协议TLS1.0、SSL3，采用已经过时的弱加密算法套件，实现框架安全漏洞如心脏滴血，还有很多的数字证书本身导致的安全问题。

全站HTTPS会带来的附带问题是CDN和高防IP。因CDN回源时没有使用加密，即用户浏览器到CDN是加密的，但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商，这对于没有完全自建CDN的公司而言也是一个很大的安全隐患，所以后来衍生出了Keyless CDN技术，无需给出自己的证书就可以实现CDN回源加密。

广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步，对应的解决方案是跨IDC流量自动加密、TLS隧道化。

6>业务安全

用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全，只要账号泄露（撞库&爆破）到达一定数量级，把这些账号的数据汇总一下，就必定可以产生批量数据泄露的效果。

第二个问题是反爬，爬虫的问题存在于一切可通过页面、接口获取数据的场合，大概1小时爬个几百万条数据是一点问题都没有的，对于没有彻底脱敏的数据，爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术，培育了不少黑产和数据获取的灰色地带。

7>UUID

UUID最大的作用是建立中间映射层，屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID，但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据，因为实名制，手机号越来越能代表个人标识，且一般绑定了各种账号，更改成本很高，找到手机号就能对上这个人，因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候，这个原本用于程序检索的数据结构也一下子变成了个体识别数据，也都需要纳入保护范畴。

8>前台业务处理

很多企业的应用架构中，只有在业务逻辑最开始处理的部分设置登录态校验，后面的事务处理不再会出现用户鉴权，进而引发了一系列的越权漏洞，另外还包括各种K/V、RDS（关系型数据库）、消息队列等等，RPC没有鉴权导致可任意读取的安全问题。

绝大多数互联网公司都用开源软件或修改后的开源软件，这类开源软件的特点是基本不带安全特性，或者只具备很弱的安全特性，以至于完全不适用于海量IDC规模下的4A模型（认证、授权、管理、审计）。外面防御做的很好，而在内网可以随意读写，这可能是互联网行业的普遍现状了，主要矛盾还是鉴权颗粒度和弹性计算的问题。

对于业务流的鉴权模型，本质上是需要做到Data和App分离，建立Data默认不信任App的模型，而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。

数据安全服务化访问：

服务化并不能认为是一个安全机制，但安全却是服务化的受益者，这里来温习一下当年Bezos在Amazon推行服务化的一纸号令：

1）所有团队今后将通过服务接口公开他们的数据和功能。
2）团队必须通过这些接口相互通信。
3）不允许使用其他形式的进程间通信：不允许直接链接，不允许直接读取其他团队的数据存储，不支持共享内存模式，无后门。唯一允许的通信是通过网络上的服务接口调用。
4）他们使用什么技术并不重要。HTTP，Corba，Pubsub，自定义协议 - 无关紧要。贝索斯不在乎。
5）所有服务接口无一例外都必须从头开始设计为可外部化。也就是说，团队必须规划和设计能够将接口展示给外部开发人员。没有例外。
6）任何不这样做的人都会被解雇。

服务化的结果在安全上的意义是必须通过接口访问数据，屏蔽了各种直接访问数据的途径，有了API控制和审计就会方便很多。

内网加密：就是在后台的组件之间的数据传输都要加密；，譬如Goolge的RPC加密和Amazon的TLS。对于私有协议，如果不含有标准TLS（SHA256）以上强度的加密，或者只是信息不对称的哈希，可以认为都不算合理加密。

数据库审计：数据库审计/数据库防火墙是一个入侵检测/防御组件，是一个强对抗领域的产品，在数据安全方面它的意义也是明显的：防止SQL注入批量拉取数据，检测API鉴权类漏洞和爬虫的成功访问。此外，对数据库的审计还有一层含义，是指内部人员对数据库的操作，要避免某个RD或DBA为了泄愤，把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件，通过这个组件，可以审计、控制危险操作。

9>数据存储

数据存储之于数据安全最大的部分是数据加密。业界的普遍问题是不加密，或者加密了但没有使用正确的方法：使用自定义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有权限，漏洞利用也有权限。

10>访问和运维

角色分离:研发和运维要分离，密钥持有者和数据运维者要分离，运维角色和审计角色要分离。特权账号须回收，满足最小权限，多权分立的审计原则。

运维审计：堡垒机（跳板机）是一种针对人肉运维的常规审计手段，随着大型IDC中运维自动化的加深，运维操作都被API化，所以针对这些API的调用也需要被列入审计范畴，数量级比较大的情况下需要使用数据挖掘的方法。

工具链脱敏：典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中，通常由于运维和安全的监控系统包含了全站用户流量，对用户Token和敏感数据需要脱敏，同时这些系统也可能通过简单的计算得出一些运营数据，譬如模糊的交易数目，这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件，因此都是需要注意的数据泄漏点。

生产转测试：生产环境和测试环境必须有严格定义和分离，如特殊情况生产数据需要转测试，必须经过脱敏、匿名化。

11>后台数据处理

数仓安全:以Hadoop为代表的开源平台本身不太具备很强的安全能力，因此在成为公有云服务前需要做很多改造。公司比较小的时候可以选择内部信任模式，不去过于纠结开源平台本身的安全，但在公司规模比较大，数据RD和BI分析师成千上万的时候，内部信任模式就需要被抛弃了，这时候需要的是一站式的授权&审计平台，需要看到数据的血缘继承关系，需要高敏数据仍然被加密。在这种规模下，工具链的成熟度会决定数据本地化的需求，工具链越成熟数据就越不需要落到开发者本地，这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化，尽可能避免人工操作。

对于数据的分类标识、分布和加工，以及访问状况需要有一个全局的大盘视图，结合数据使用者的行为建立“态势感知”的能力。因数仓是最大的数据集散地，因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态：放逐+检测型 or 隔离+管控型。

匿名化算法: 匿名化算法更大的意义其实在于隐私保护而不在于数据安全，对数据安全的意义体现在，匿名化可能在于减少数据被滥用的可能性，以及减弱数据泄漏后的影响面。

堡垒机：堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法，这种方法跟VDI类似，比较厚重，使用门槛不高，不适合大面积普遍推广。

12>其他数据安全考虑

防止下游数据沉淀:首先，所有被第三方调用的数据，如非必要一律脱敏和加密。如果部分场景有必要查询明细数据，设置单独的API，并对账号行为及API查询做风控。

其次如果自身有云基础设施，公有云平台，可以推动第三方上云，从而进行（1）安全赋能，避免一些因自身能力不足引起的安全问题；（2）数据集中化，在云上集中之后利于实施一站式整体安全解决方案（数据加密，风控，反爬和数据泄露检测类服务），大幅度降低外部风险并在一定程度上降低作恶和监守自盗的问题。

反爬：这里主要是针对公开页面，或通过接口爬取的信息，因为脱敏这件事不可能在所有的环节做的很彻底，所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘，最终形成一些诸如用户关系链，经营数据或辅助决策类数据，造成过度信息披露的影响。

数据销毁数据销毁主要是指安全删除，这里特别强调是，往往数据的主实例容易在视野范围内，而把备份类的数据忽略掉。 如果希望做到快速的安全删除，最好使用加密数据的方法，因为完整覆写不太可能在短时间内完成，但是加密数据的安全删除只要删除密钥即可。

基础统一：账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础，但能体现为优势的部分：基础架构统一，应用架构统一，如果这两者高度统一，数据安全建设能事半功倍。

5）安全运维能力

数据分级分类，即数据识别：

特权操作识别：特权操作的来源则是各类业务、系统日志。以往大家关注的焦点可能是类似于数据库dump之类的操作行为，但特权不仅只是这些内容，还包括一些敏感业务操作行为，例如查询用户的订单记录，在某些场景下也是敏感操作。

敏感人群识别：掌握敏感数据，且容易受到外部诱惑，这是要识别的对象。例如外包、待离职人员、合作伙伴等。另外要提的是，黑产、竞对也都会有意识的打入内部渗透，当这些人伪装后应聘成功，带来的泄漏影响面极大，传统的背调对这种问题无能为力，这就需要有更好的方法识别。

数据收口及检测：

数据保护的一个重点是要对数据出口进行集中化，分散点过多则会导致管理成本急剧提升。在数据的流向上，越早对数据进行统一集中管理，效果越佳，成本也越低。

检测能力是数据安全的核心，也是数据驱动数据安全的一个落地性体现。

上图是一个典型UEBA（用户实体行为分析）的框架。通过分析检测数据中人类行为的模式，实现威胁洞察。其特点在于关注人、设备、行为，通过关联分析、基线模型、罕见度等模型发现风险。

安全风险：

衡量安全工作的好坏，要看风险的收敛程度。要实现风险收敛，是一个数据化运营的工作。在数据安全上可参考的关键指标有：规模泄漏绝对值、人均泄漏数据量、主动发现率、收敛率等。围绕核心指标，还会有一些分解，例如功能覆盖率、场景覆盖率、误报率、收敛时长、数据覆盖率等。

盘点风险—风险量化—关注核心：

先知道自己面临哪些风险，这部分参考业界有各种bad case，但企业自身也会有相对独特的业务风险场景，在解决好通用问题的基础上，需要挖掘业务场景数据风险，且能够从数据趋势上发现风险。

其次对风险进行量化，业务飞快发展的前提下，哪些风险是暂时可忍受的，哪些会产生致命打击，需要有量化指标来衡量。最后则是对核心风险的关注，不同阶段有不同核心，对核心风险的监控和收敛，需要有数据能力来保障。

参考文献

1、互联网企业数据安全体系建设
2、大型互联网公司数据安全实践
3、互联网企业安全运维实践
4、

cs