一个人的安全部之大话企业数据安全保护

*本文原创作者：liong03，本文属FreeBuf原创奖励计划，未经许可禁止转载

先简单自我介绍一下，其实，我是一个信息安全工程师，也是一个人的“安全部”……

近期看到一些朋友问数据安全保护怎么弄，刚好为某企业简单规划过，很多前辈大佬都有介绍过数据安全，突然想用一种不一样的姿势来分享，通过一些文字条框再结合一些故事案例来思考。

目录架构

一、设计思路

数据安全也是一个整体的体系，环环相扣，说说对数据安全保护的构思吧。一张图胜过千言万语，如果不行，那就三张：

数据安全防护六“不”曲：

全面的网络安全防护：

二、数据安全威胁

简单做了一个数据安全威胁/风险脑图：

三、规划内容

3.1 访问控制

涉及数据相关的访问控制需要进行网络隔离、用户进行细粒度授权、访问进行认证，访问控制涉及对象包括操作系统、数据库、中间件、应用程序甚至网络设备等访问，还是简单点说吧：

（一）网络控制，主要通过 ACL来实现，对源地址、目的地址、源端口、目的端口和协议的访问进行控制。

1）仅限运维技术负责人有权限访问生产服务器及业务数据接触到客户数据，应用系统的发版均需要经过运维人员配合才能进行发版。

2）网络边界或区域之间根据访问控制策略设置访问控制规则：

a. 网络边界部署交换机和防火墙进行访问控制策略；

b. 一些端口或ACL也可通过主机自带防火墙进行访问控制，访问控制策略尽量采用就近原则；

c. 访问控制策略采用白名单形式，默认情况下除允许通信外受控接口拒绝所有通信，如远程登陆端口、数据库端口、中间件端口进行访问控制，尽量避免端口暴露非信任区域，可以通过VPN进行跨区域安全通信。

网络访问控制通常是最熟悉的人去弄，为了让网络管理员知道配置的需求，一般都会弄一个模板表，当然事前还会进行一些调研，如：

（二）权限控制，基于角色的权限访问控制：

1）根据管理用户的角色分配权限，实现管理用户的权限分离，仅授予管理用户所需的最小权限，尽量在权限之间形成相互制约的关系；（通常情况：仅公司技术负责人才有权限访问生产服务器及业务数据库接触到客户数据，关键数据均是加密后的密文，同时对数据的维护操作进行了监控与审计）。

2）由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；

3）权限控制实现文件、数据库表级、记录或字段级的访问控制；

4）及时删除或停用多余的、过期的账户，避免共享账户的存在。如长期未登陆用户使用系统，如超过三个月未登陆系统，应对帐号进行长期锁定。

（三）防数据库误删

1）不要在任何时候使用rm –rf * ，他会永久删除文件，建议给“rm”命令添加个“垃圾桶”，而不是永久删除；

2）改写rm命令，防止误操作；

3）删除命令尽量脚本化，并把将执行的脚本命令、需要删除的对象进行描述发给第三者审核通过，数据库操作时不要饮酒，重要的是要开心。

太枯燥了，来个故事吧（瞎编的）：

1）某次信息泄露事件应急分析，查看日志，发现某黑阔半夜不睡觉的，用了好几个管理员账号也包括已离职人员的，竟然成功登陆了某后台，后台里面是有很多信息数据的，整理了下日志信息：

询问IP所属本人，都不是他本人操作，然后对IP所在电脑进行病毒查杀，发现一堆可疑文件：

丢到情报平台分析，发现好几个木马病毒，其中竟然有与大名鼎鼎“冰河木马”相似：

运行程序后，生成了1个小文件和几个看起来像系统进程，然后查看网络流量发现连接了一个国外IP的8086端口，应该就是木马远控端的IP地址：

大致的分析结果：

1）黑阔放了马在网上，然后某人下载后被远控了；

2）中马后，黑阔通过内网探测、浏览器或查看邮件啥啥的，找到了某后台的一些管理员账号和密码（当然了默认密码）；

3）某黑阔是喜欢半夜不睡觉的，登陆后台进行了一些不可描述的信息数据操作。

这里有几个问题：某IP为什么能访问后台、那些账号的权限有多大、账号密码是怎么泄露的、离职人员的账号为什么未清除、为什么会下载木马、下载了木马为什么没有发现、为什么有默认密码。这里就涉及一些访问控制、权限控制、病毒防范以及安全意识等等了，所以数据安全还是不能单独来看。

有时候不抓，可能是因为

3.2 身份认证

（一）身份认证可分为两种认证方式，单点登录和双因素认证。

1. 单点登录：在多个业务系统中，用户只需要登录一次就可以访问所有相互信任的业务系统。使用单点登录，在带来便利的同时也会引入新的安全风险：用户仿冒和单点故障。以下措施可提高业务系统（如：某个工作台，包含了OA、后台登陆、HRM等多个应用系统）单点登陆的安全性和可用性：

a. 用户访问任何一个业务系统时，如果已经在单点登录服务器中认证成功，那么可以获取对应的权限，访问对应的界面；

b. 用户如果在其中任何一个业务系统中点击“注销”按钮后，那么不能继续访问其他业务系统，如果访问，必须重新登录；

c. 用户访问任何一个业务系统时，如果尚未在单点登录服务器中认证成功，那么需要跳转到单点登录界面，输入用户名密码，校验成功后，再回到原来的访问界面。

d. 通过备份、冗余、负载均衡、功能模块化以及提高处理性能，来防范单点故障。

2. 双因素身份认证：解决只有授权用户才能访问系统平台与服务的问题，主流的身份认证手段包括：静态密码、动态口令、密码技术或生物技术等。

（二）某系统的双因素身份认证：

a. 进行资金交易、修改个人信息或修改密码等敏感操作进行双因子认证；

b. 对后台用户在登录时采用双因子认证，如用户名/密码+手机短信验证码、用户名/密码+动态令牌或用户名/密码+Ukey等等；

c. 操作系统、数据库、网络设备登陆，采用堡垒机进行登陆统一认证和操作审计。

（三）接口认证

在工作中发现过不少接口方面的安全问题，比如接口暴露，可以任意调用，甚至修改传输包，解决方法可参考：

1. 身份认证，调用鉴权（资源范围、操作权限）；

2. 通道加密传输，如使用SSL传输；

3. 重要信息加密算法进行加密后传输；

4. 添加token校验，防止请求重放；

5. 将登陆信息等重要信息存放为SESSION，其他信息如果需要保留，可以放在COOKIE中；

6. 设置IP白名单；

7. 一些资源管理器/应用组件（如：YARN&MR、Spark、Hive、Storm、ZooKeeper、Impala），应开启认证机制。若资源管理器/应用组件支持关闭认证机制功能，需要提示，并建议在关闭认证机制功能时界面上给出告警提示。

接口认证方式不能一概而论，还要根据所在业务和场景进行设计…….

来个故事吧，搭建测试环境，某短信数据流转示意图：

一、问题现状：

a. 短信信息明文传输，也未使用SSL传输；

b. 可以任意修改短信信息；

c. 使用GET传输账号、密码及短信内容；

d. 短信服务器是在短信企业那边，也就是短信平台与短信服务器是进行了跨不信任网络传输。

二、存在的风险

外部人员调用此短信接口或直接使用以往的接口信息内容，进行修改，然后：

a. 短信诈骗；

b. 短信钓鱼；

c. 由于短信内容可以随意修改，也可以随意发给任何人，可以利用的方式太多，不一一例举。

三、测试验证

外网直接调用接口信息后不需要验证，直接篡改，再发送短信成功：

信息解码后：

http://116.58.xxx.xxx:8080/xxx/xxxx.action?cdkey=xxx-xxx-xxx-xxx&password=011xxxx&phone=189xxxxyyyy&message=奥巴嘛先生您好，户名：深圳xxxxxxxx公司，开户行:xx银行深圳xx支行，账号:xx42710xxx101665，金额为：11342000000000000000.00元。如有疑问，请联系26146182614343xxxxx，如需要开启上帝模式请联系吴证铭先生，电话：18888889999

成功收到短信：

3.3 数据加密&脱敏

（一）数据加密

在数据保存和传输的数据提供加密功能，在两个维度上提供数据安全保护：

1.机密性：采用加密的方式，确保只有拥有相应密钥的用户能够访问被保护的数据；

2.完整性：保证信息在储存和传输过程中不被查看和修改，如：使用SSL传输，并对敏感信息（如用户名、密码、重要ID值）使用加密算法+动态token验证。

在加密算法、随机数使用、加密协议的选择时需要兼顾性能考虑，需要对数据进行区分，只针对需要加密的数据进行加密处理。

常见的加密算法：

内容加密通常采用对称加密算法，数据库中常用的加密算法AES或MD5+盐；

传输通道加密通常采用非对称加密算法，如：SSL加密数据通道采用RSA（非对称加密）、VPN采用RSA、SSH key采用RSA。

注：

a. MD5加密其实是比较弱，一次MD5可以防止相对安全的密码被逆向出明文，但可顺推。

b. 单纯的MD5不是很安全，但加个固定的盐值，就能防止已有的彩虹表攻击，多次MD5更是增加了碰撞攻击的计算成本，但不能防止重放攻击。

c. 在传输过程中加动态token验证，就需要服务端加逻辑配置，可以防止重放攻击，但不能防止中间人攻击。

d. 传输通道加密可以比较有效防止中间人攻击。

（二）秘钥保护

加密技术都基于密钥的安全基础上，如果密钥泄露，就失去了安全性。实际开发中，把密钥直接写在源代码中，或者是配置文件中，线上和开发环境配置相同的密钥。这样的话，不够安全。

通过两种方案改善：

1.密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设备，对外提供加密和解密服务，用程序通过调用这个服务，实现数据的加解密。这种方法由专人维护，密钥不容易泄露，但是成本较高。

2.将加解密算法放在应用系统中，密钥则放在独立服务器中，为了提高密钥的安全性，实际存储时，密钥被切分成数片，加密后分别保存在不同存储介质中，兼顾密钥安全性的同时又改善了性能。

（三）数据脱敏

企业拥有的敏感数据，包括商业秘密、知识产权、关键业务信息、业务合作伙伴信息或用户信息等。其中涉及个人隐私的用户个人信息是信息系统中最重要最广泛的敏感信息。

个人信息：指以电子或者其他方式记录的能够单独或者与其他信息结合识别自然人个人身份的各种信息，包括但不限于自然人的姓名、出生日期、身份证件号码、个人生物识别信息、住址、电话号码等。

公民个人信息：是指以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然人活动情况的各种信息，包括姓名、身份证件号码、通信通讯联系方式、住址、账号密码、财产状况、行踪轨迹等。

个人建议：针对敏感数据，采用技术措施限制对用户信息的访问和使用。

1）确认需要查看客户个人信息的后台账号，账号权限为业务必须的权限；

2）查询客户个人信息尽量仅能查询脱敏后的信息，如电话号码、身份证号码只保留前后4位，中间内容脱敏；

3）不管是请求校验还是脱敏不要在前端进行，前端是不可靠的；

4）对于需要导出客户个人信息的后台账号，确认是否必要导出客户个人的明文信息，

a) 如无必要建议禁止导出客户明文信息；

b) 若确实必要导出客户个人信息的明文信息，建议严格限制后台账号的使用人员范围（使用人员、登录的源IP），并设置导出的信息范围，如信息条数、信息时长（如最近1个月），所有对客户信息的查询和导出有日志记录。

脱敏实现之数据脱敏系统的原理及功能：

第一步：评估数据资产的安全级别，根据不同的安全级别以及应用的数据要求，制定不同的脱敏策略。

第二步：设置脱敏任务和触发条件，触发条件如时间、某数据处理过程的调用。

第三步：触发脱敏条件后，脱敏系统将脱敏算法的执行算法包下发各节点实现数据脱敏。

数据脱敏可发生在两个阶段：

1）数据的采集阶段，实现最基本、简单的脱敏；

2）数据资产应用过程中，针对不同的应用进行实时的脱敏，应用脱敏相对较为复杂多变。

好吧，这里也来点关于秘钥和脱敏问题的故事吧，在这里讲故事，没人打我，大佬们说话又好听，超喜欢这里的感觉。

故事1、硬编码

反编译APP，找到加密方式AES/CBC/PKCS5Padding

找到秘钥：b60449ddb29221c8

测试解密成功：

刚好还有个信息遍历漏洞，现在有了秘钥，就可进行遍历了，自定义ID值，然后用秘钥加密，再去遍历，可遍历出其他人的ID值对应的用户信息：

故事2、前端脱敏

比如下面这种，看起来是脱敏的，但通过中间抓包拦截就会发现完整信息，当然了下面这个图不只是前端脱敏问题，其实也是一个遍历+前端脱敏问题，可通过遍历获取其他人完整的银行卡号和余额信息：

还有一种场景，一些网站首页会展示一些客户信息，当然展示时看到的重要信息（如：姓名、电话、姓名、身份证）是进行脱敏了，但通过抓包拦截就可以获取到完整信息：

3.4 容灾备份/恢复

（一）容灾分类：

数据级容灾：建立一个异地的数据系统，该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，至少在异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但一定是可用的。

应用级容灾：在数据级容灾基础上，在异地建立一套与本地生产系统相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当本地系统发生灾难时，异地系统可以提供完全可用的生产环境。

（二）备份策略

备份策略是备份方案核心部分，要按照数据重要程度、数据管理方式制定不同的备份策略。备份策略包括：备份对象、备份方法、备份频率、保存时限等。

如：每天数据泵备份两次，RMAN备份一次，备份保存双份，一份放本地，一份放存储。

1) 日常备份每日进行三次备份，数据泵每天两次备份， RMAN每天一次备份。

a. 数据泵每天备份2次，时间为中午xx点xx分，晚上xx开始

b. RMAN晚上xx点xx分，凌晨xx点；

c. 数据泵备份完成后会传输到指定存储设备，本地存一份，存储存一份，共保存两份，保证系统发生故障时能够快速恢复。

d. 在进行数据表的截断、删除之前，进行备份，避免误操作之后的措手不及。

2) 月备份

a. 每月月末对所有数据文件进行离线备份，拷贝到备份介质中，并另行备份一份存放至xx。

3) 临时备份

a. 临时备份采用数据泵备份。

4) 备份保存时限

a. 数据泵备份保存一个月备份，RMAN备份保存x天。

（三）备份运行和恢复演练

1)   必须定期巡检和维护备份系统及时发现并排除故障隐患，保证备份系统的正常运转。

2)   对于核心系统和关键系统，每半年进行备份介质可用性检查，确保库存介质可用。

3)   必须保证核心系统每季度进行的恢复测试顺利完成，检查备份可用性。关键系统至少每半年进行恢复测试。

4)   需要实施系统恢复时要按照备份恢复管理流程申报、审批，按照备份恢复方案进行系统恢复。

5)   个人做好对自己的资料文件根据需要进行备份，但必须做好备份的信息安全保护工作。

6)   数据备份应遵循“内容完备、安全保密、落实到人、定点存放、定期检验”的工作原则，切实保证备份数据的机密性、完整性和可用性。

这里真没什么故事好讲，百度一下会更丰富。还是来个简单的容灾/备份的网络构想图吧：

3.5 安全审计

尽量通过部署日志审计系统，实时监视网络各类操作行为及攻击信息。根据设置的规则，智能的判断出各种风险行为，对违规行为进行报警等。

日志的分类包括：应用系统日志、操作系统日志、数据库日志、网络设备日志和信息安全设备日志。每一类日志记录中应记录以下基本内容：事件发生的日期和时间、事件描述，操作者信息，导入、导出、成功和失败操作。

（一）应用系统日志

客户访问门户网站时，应对登录行为、业务操作以及系统运行状态进行记录与保存，保证操作过程可追溯、可审计。并确保业务日志数据的安全。日志记录应满足如下安全要求：

1. 记录关键业务操作日志：应记录关键业务操作的日志，例如登录成功与失败、关键业务办理、敏感数据查询、敏感数据导入与导出等。

2. 记录应用系统运行日志：应记录应用系统的启停、异常、资源使用情况等。

3. 敏感数据模糊化：禁止在业务日志中记录服务密码等敏感信息。如果确实需要记录敏感信息，则应进行模糊化处理。

4. 防止业务日志欺骗：如果在生成业务日志时需要引入来自非受信源的数据，则应进行严格校验，防止欺骗攻击。

5. 业务日志安全存储与访问：禁止将业务日志保存到网页目录下，确保业务日志数据的安全存储并严格限制业务日志数据的访问权限。应对业务日志记录进行签名来实现防篡改。日志记录应在线至少保存半年，离线保存1年。

应用系统日志分析，不同的系统日志特征不一样，所以也不好去介绍（有机会再写写安全应急），在做应急分析时，有时候是需要去模拟操作分析出操作特征，再去对日志进行分析。

好吧，还是讲个故事吧：

1）模拟登陆操作，获取登陆成功的跳转信息：

GET /admin/basics/mainHTTP/1.1
     Host: xxxx.com
    xxxxxxxxx…………………..
   Referer:https://xxxx.com/admin/manage/login
   Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxxxxxx
   Connection: close

2）然后筛选日志中/admin/basics/main，发现某黑阔也是半夜不睡觉的，成功登陆了某后台：

查看了下IP是外省浙江的，当然了这种IP基本不是真实源，不会用代理的黑阔不是好黑阔。

3）看看他在干吗

在看page=1和page=2等等

测试了下这个page=是什么，他大爷，在查其他用户个人信息啊（勿惊，问题不大，只是故事，大家都是做安全的，混口饭吃不容易）：

（二）WINDOWS系统日志

做日志审计，前提是要开启相应的日志审计策略，默认的日志信息是很少的，开启日志审计时还需要注意，如果全部开启，日志信息可能巨庞大，会有很多无用日志，所以最好是先确定是需要开启哪些审计策略。

关于日志信息如何审计，审计哪些，这里做了一个简单的win2008常用审计事件ID（win7与win2008的日志事件ID没什么区别）：

手工查看日志：

1）这是在爆破账号密码啊：

2）访问445端口的筛选：

（三）UNIX系统日志