企业数据安全保护规划
一、设计思路
数据安全也是一个整体的体系，环环相扣。
数据安全防护六不原则：
全面的网络安全防护：
二、数据安全威胁
企业面临的数据安全威胁/风险脑图：
三、规划内容
3.1 访问控制
涉及数据相关的访问控制需要进行网络隔离、用户进行细粒度授权、访问进行认证，访问控制涉及对象包括操作系统、数据库、中间件、应用程序甚至网络设备等访问，还是简单点说吧：
- 网络控制
主要通过 ACL来实现，对源地址、目的地址、源端口、目的端口和协议的访问进行控制。
1）仅限运维技术负责人有权限访问生产服务器及业务数据接触到客户数据，应用系统的发版均需要经过运维人员配合才能进行发版。
2）网络边界或区域之间根据访问控制策略设置访问控制规则：
- 网络边界部署交换机和防火墙进行访问控制策略；
- 一些端口或ACL也可通过主机自带防火墙进行访问控制，访问控制策略尽量采用就近原则；
- 访问控制策略采用白名单形式，默认情况下除允许通信外受控接口拒绝所有通信，如远程登陆端口、数据库端口、中间件端口进行访问控制，尽量避免端口暴露非信任区域，可以通过VPN进行跨区域安全通信。
网络访问控制通常是最熟悉的人去弄，为了让网络管理员知道配置的需求，一般都会弄一个模板表，当然事前还会进行一些调研，如：
（二）权限控制，基于角色的权限访问控制：
1）根据管理用户的角色分配权限，实现管理用户的权限分离，仅授予管理用户所需的最小权限，尽量在权限之间形成相互制约的关系；（通常情况：仅公司技术负责人才有权限访问生产服务器及业务数据库接触到客户数据，关键数据均是加密后的密文，同时对数据的维护操作进行了监控与审计）。
2）由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；
3）权限控制实现文件、数据库表级、记录或字段级的访问控制；
4）及时删除或停用多余的、过期的账户，避免共享账户的存在。如长期未登陆用户使用系统，如超过三个月未登陆系统，应对帐号进行长期锁定。
（三）防数据库误删
1）不要在任何时候使用rm –rf * ，他会永久删除文件，建议给“rm”命令添加个“垃圾桶”，而不是永久删除；
2）改写rm命令，防止误操作；
3）删除命令尽量脚本化，并把将执行的脚本命令、需要删除的对象进行描述发给第三者审核通过。
3.2 身份认证
（一）身份认证可分为两种认证方式，单点登录和双因素认证。
- 单点登录：在多个业务系统中，用户只需要登录一次就可以访问所有相互信任的业务系统。使用单点登录，在带来便利的同时也会引入新的安全风险：用户仿冒和单点故障。以下措施可提高业务系统（如：某个工作台，包含了OA、后台登陆、HRM等多个应用系统）单点登陆的安全性和可用性：
- 用户访问任何一个业务系统时，如果已经在单点登录服务器中认证成功，那么可以获取对应的权限，访问对应的界面；
- 用户如果在其中任何一个业务系统中点击“注销”按钮后，那么不能继续访问其他业务系统，如果访问，必须重新登录；
- 用户访问任何一个业务系统时，如果尚未在单点登录服务器中认证成功，那么需要跳转到单点登录界面，输入用户名密码，校验成功后，再回到原来的访问界面。
- 通过备份、冗余、负载均衡、功能模块化以及提高处理性能，来防范单点故障。
- 双因素身份认证：解决只有授权用户才能访问系统平台与服务的问题，主流的身份认证手段包括：静态密码、动态口令、密码技术或生物技术等。
（二）某系统的双因素身份认证：
- 进行资金交易、修改个人信息或修改密码等敏感操作进行双因子认证；
- 对后台用户在登录时采用双因子认证，如用户名/密码+手机短信验证码、用户名/密码+动态令牌或用户名/密码+Ukey等等；
- 操作系统、数据库、网络设备登陆，采用堡垒机进行登陆统一认证和操作审计。
（三）接口认证
在工作中发现过不少接口方面的安全问题，比如接口暴露，可以任意调用，甚至修改传输包，解决方法可参考：
- 身份认证，调用鉴权（资源范围、操作权限）；
- 通道加密传输，如使用SSL传输；
- 重要信息加密算法进行加密后传输；
- 添加token校验，防止请求重放；
- 将登陆信息等重要信息存放为SESSION，其他信息如果需要保留，可以放在COOKIE中；
- 设置IP白名单；
- 一些资源管理器/应用组件（如：YARN&MR、Spark、Hive、Storm、ZooKeeper、Impala），应开启认证机制。若资源管理器/应用组件支持关闭认证机制功能，需要提示，并建议在关闭认证机制功能时界面上给出告警提示。
接口认证方式不能一概而论，还要根据所在业务和场景进行设计…….
3.3 数据加密&脱敏
（一）数据加密
在数据保存和传输的数据提供加密功能，在两个维度上提供数据安全保护：
1.机密性：采用加密的方式，确保只有拥有相应密钥的用户能够访问被保护的数据；
2.完整性：保证信息在储存和传输过程中不被查看和修改，如：使用SSL传输，并对敏感信息（如用户名、密码、重要ID值）使用加密算法+动态token验证。
在加密算法、随机数使用、加密协议的选择时需要兼顾性能考虑，需要对数据进行区分，只针对需要加密的数据进行加密处理。
常见的加密算法：
内容加密通常采用对称加密算法，数据库中常用的加密算法AES或MD5+盐；
传输通道加密通常采用非对称加密算法，如：SSL加密数据通道采用RSA（非对称加密）、VPN采用RSA、SSH key采用RSA。
注：
- MD5加密其实是比较弱，一次MD5可以防止相对安全的密码被逆向出明文，但可顺推。
- 单纯的MD5不是很安全，但加个固定的盐值，就能防止已有的彩虹表攻击，多次MD5更是增加了碰撞攻击的计算成本，但不能防止重放攻击。
- 在传输过程中加动态token验证，就需要服务端加逻辑配置，可以防止重放攻击，但不能防止中间人攻击。
- 传输通道加密可以比较有效防止中间人攻击。
（二）秘钥保护
加密技术都基于密钥的安全基础上，如果密钥泄露，就失去了安全性。实际开发中，把密钥直接写在源代码中，或者是配置文件中，线上和开发环境配置相同的密钥。这样的话，不够安全。
通过两种方案改善：
1.密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设备，对外提供加密和解密服务，用程序通过调用这个服务，实现数据的加解密。这种方法由专人维护，密钥不容易泄露，但是成本较高。
2.将加解密算法放在应用系统中，密钥则放在独立服务器中，为了提高密钥的安全性，实际存储时，密钥被切分成数片，加密后分别保存在不同存储介质中，兼顾密钥安全性的同时又改善了性能。
（三）数据脱敏
企业拥有的敏感数据，包括商业秘密、知识产权、关键业务信息、业务合作伙伴信息或用户信息等。其中涉及个人隐私的用户个人信息是信息系统中最重要最广泛的敏感信息。
个人信息：指以电子或者其他方式记录的能够单独或者与其他信息结合识别自然人个人身份的各种信息，包括但不限于自然人的姓名、出生日期、身份证件号码、个人生物识别信息、住址、电话号码等。
公民个人信息：是指以电子或者其他方式记录的能够单独或者与其他信息结合识别特定自然人身份或者反映特定自然人活动情况的各种信息，包括姓名、身份证件号码、通信通讯联系方式、住址、账号密码、财产状况、行踪轨迹等。
个人建议：针对敏感数据，采用技术措施限制对用户信息的访问和使用。
1）确认需要查看客户个人信息的后台账号，账号权限为业务必须的权限；
2）查询客户个人信息尽量仅能查询脱敏后的信息，如电话号码、身份证号码只保留前后4位，中间内容脱敏；
3）不管是请求校验还是脱敏不要在前端进行，前端是不可靠的；
4）对于需要导出客户个人信息的后台账号，确认是否必要导出客户个人的明文信息，
- a) 如无必要建议禁止导出客户明文信息；
- b) 若确实必要导出客户个人信息的明文信息，建议严格限制后台账号的使用人员范围（使用人员、登录的源IP），并设置导出的信息范围，如信息条数、信息时长（如最近1个月），所有对客户信息的查询和导出有日志记录。
脱敏实现之数据脱敏系统的原理及功能：
第一步：评估数据资产的安全级别，根据不同的安全级别以及应用的数据要求，制定不同的脱敏策略。
第二步：设置脱敏任务和触发条件，触发条件如时间、某数据处理过程的调用。
第三步：触发脱敏条件后，脱敏系统将脱敏算法的执行算法包下发各节点实现数据脱敏。
数据脱敏可发生在两个阶段：
1）数据的采集阶段，实现最基本、简单的脱敏；
2）数据资产应用过程中，针对不同的应用进行实时的脱敏，应用脱敏相对较为复杂多变。
3.4 容灾备份/恢复
（一）容灾分类：
数据级容灾：建立一个异地的数据系统，该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，至少在异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但一定是可用的。
应用级容灾：在数据级容灾基础上，在异地建立一套与本地生产系统相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当本地系统发生灾难时，异地系统可以提供完全可用的生产环境。
（二）备份策略
备份策略是备份方案核心部分，要按照数据重要程度、数据管理方式制定不同的备份策略。备份策略包括：备份对象、备份方法、备份频率、保存时限等。
如：每天数据泵备份两次，RMAN备份一次，备份保存双份，一份放本地，一份放存储。
1) 日常备份:每日进行三次备份，数据泵每天两次备份， RMAN每天一次备份。
- 数据泵每天备份2次，时间为中午xx点xx分，晚上xx开始
- RMAN晚上xx点xx分，凌晨xx点；
- 数据泵备份完成后会传输到指定存储设备，本地存一份，存储存一份，共保存两份，保证系统发生故障时能够快速恢复。
- 在进行数据表的截断、删除之前，进行备份，避免误操作之后的措手不及。
2) 月备份
- 每月月末对所有数据文件进行离线备份，拷贝到备份介质中，并另行备份一份存放至xx。
3) 临时备份
- 临时备份采用数据泵备份。
4) 备份保存时限
- 数据泵备份保存一个月备份，RMAN备份保存x天。
（三）备份运行和恢复演练
1) 必须定期巡检和维护备份系统及时发现并排除故障隐患，保证备份系统的正常运转。
2) 对于核心系统和关键系统，每半年进行备份介质可用性检查，确保库存介质可用。
3) 必须保证核心系统每季度进行的恢复测试顺利完成，检查备份可用性。关键系统至少每半年进行恢复测试。
4) 需要实施系统恢复时要按照备份恢复管理流程申报、审批，按照备份恢复方案进行系统恢复。
5) 个人做好对自己的资料文件根据需要进行备份，但必须做好备份的信息安全保护工作。
6) 数据备份应遵循“内容完备、安全保密、落实到人、定点存放、定期检验”的工作原则，切实保证备份数据的机密性、完整性和可用性。
3.5 安全审计
尽量通过部署日志审计系统，实时监视网络各类操作行为及攻击信息。根据设置的规则，智能的判断出各种风险行为，对违规行为进行报警等。
日志的分类包括：应用系统日志、操作系统日志、数据库日志、网络设备日志和信息安全设备日志。每一类日志记录中应记录以下基本内容：事件发生的日期和时间、事件描述，操作者信息，导入、导出、成功和失败操作。
（一）应用系统日志
客户访问门户网站时，应对登录行为、业务操作以及系统运行状态进行记录与保存，保证操作过程可追溯、可审计。并确保业务日志数据的安全。日志记录应满足如下安全要求：
- 记录关键业务操作日志：应记录关键业务操作的日志，例如登录成功与失败、关键业务办理、敏感数据查询、敏感数据导入与导出等。
- 记录应用系统运行日志：应记录应用系统的启停、异常、资源使用情况等。
- 敏感数据模糊化：禁止在业务日志中记录服务密码等敏感信息。如果确实需要记录敏感信息，则应进行模糊化处理。
- 防止业务日志欺骗：如果在生成业务日志时需要引入来自非受信源的数据，则应进行严格校验，防止欺骗攻击。
- 业务日志安全存储与访问：禁止将业务日志保存到网页目录下，确保业务日志数据的安全存储并严格限制业务日志数据的访问权限。应对业务日志记录进行签名来实现防篡改。日志记录应在线至少保存半年，离线保存1年。
应用系统日志分析，不同的系统日志特征不一样，所以也不好去介绍（有机会再写写安全应急），在做应急分析时，有时候是需要去模拟操作分析出操作特征，再去对日志进行分析。
（二）WINDOWS系统日志
做日志审计，前提是要开启相应的日志审计策略，默认的日志信息是很少的，开启日志审计时还需要注意，如果全部开启，日志信息可能巨庞大，会有很多无用日志，所以最好是先确定是需要开启哪些审计策略。
关于日志信息如何审计，审计哪些，这里做了一个简单的win2008常用审计事件ID（win7与win2008的日志事件ID没什么区别）：
（三）UNIX系统日志
收集的一些日志特征：
（四）防火墙日志
收集的一些日志特征：
（五）交换机/路由器
收集的一些日志特征：
为什么这里没有介绍数据库的日志呢，因为一旦开启数据库的审计策略，数据库性能将产生巨大影响，因此建议只使用默认的审计策略。
数据库日志审计，可以参考如下：
- 部署堡垒机进行运维管理，堡垒机日志对操作者所有操作行为进行日志记录；
- 旁路部署数据库审计产品，并实现用户IP、应用服务器IP与数据库IP三层关联，对数据库的每条数据库命令的执行进行记录；
- 至于设备部署以及策略配置位置，建议就近原则。
（六）IT运维管理
通过专业的运维管理系统进行运维监控，对服务器的CPU、硬盘、内存、网络等资源的使用情况，以及系统的服务水平进行检测和告警。
（七）接口安全审计
接口的调用监控：限制访问次数、最大连接量，接口流量实时监控、异常流量告警，如短信接口、提现接口、充值接口等等；
注：比如某系统已经停用了，有漏洞也不打算补了，反正都不用了，但某天系统又重新开启还不通知安全，这时技术、管理已经失效了，所以还有监控这一道防线。
（八）日志保护
- 关键信息基础设施的运营者在运营中收集和产生的个人信息和重要数据应当在境内存储；
- 对审计进程进行保护，防止未经授权的中断；
- 审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等，如：审计记录备份到日志服务器；
- 日志信息保存至少6个月。
3.6 全面防护
设计安全防护框架，
四、APP个人隐私数据安全防护实践
一、前言
自GDPR法规在欧盟发布以来，隐私保护在国内也逐渐完善了立法和相关标准的制定，今年四部委成立APP专项治理组后，许多公司也开始对APP进行的自查和整改。我们在此项工作中，发现许多细节内容并没有多少具体实施和落地的资料可以查阅，只能逐步在摸索中进行。
APP隐私政策保护主要在以国标GB/T 35273-2017《个人信息安全规范》，APP专项治理工作组编制了《App违法违规收集使用个人信息自评估指南》作为主要标准依据，尤其是《指南》是目前官方可能唯一发布的相对比较具体的重要参考。
二、个人信息保存
个人信息保存包括数据传输和数据存储的相关要求，APP运营方应该对数据传输和存储过程，方式，以及有效时间做相关的控制，并使用如加密，匿名化等技术措施作为数据保障的基础能力。
2.1. 数据加密和匿名化技术
2.1.1. 数据加密
（1）数据传输加密：通常会使用HTTPS等安全协议进行传输
SSL/TLS系列中有五种协议：SSL v2，SSL v3，TLS v1.0，TLS v1.1和TLSv1.2；
SSLv2 是不安全的，不能使用；
TLSv1.1 和 v1.2 都没有已知的安全问题，只有 v1.2 提供了现代的加密算法；
当然也可以用其他协议传输，将传输的敏感数据内容加密。
（2）数据存储加密：线上数据加密一般会对结构化数据的某几个敏感字段家加密，比如含有个人隐私信息的字段
数据库存储加密的三种方式：
开源的加密组件，如Key Management Service（KMS），通过开发SDK或集成至数据库中间层实现自动加解密。
数据库自身功能，如Mysql加密解密函数AES_ENCRYPT()，AES_DECRYPT()；SQL Server加解密函数dbo.EncryptByPassPhrasePwd，dbo.DecryptByPassPhrasePwd。
其他商业数据加解密产品
2.1.2. 匿名化处理
匿名化处理是使用场景
- 用户注销账户，删除数据时
- 大数据平台使用数据加工
收集个人信息后，建议将数据匿名化或去标识化，并将该信息与可用于恢复识别个人的信息分开存储（一般存储至大数据平台）。数据加工时，优先使用匿名化的数据，并加强对个人信息的访问控制，这样可以很好的控制个人隐私泄露的场景。
2.2. 个人信息控制者停止运营后的处置机制
公司一般不会涉及到这种情况，但是做隐私合规时，需要这部分完善的管理制度。
- a) 及时停止继续收集个人信息的活动；
- b) 将停止运营的通知以逐一送达或公告的形式通知个人信息主体；
- c) 对其所持有的个人信息进行删除或匿名化处理。
一般来说需要建立一套管理制度，或某个管理制度建立相关条款。并对上述要求具体实施细则建立一个操作流程。
三、个人信息使用
3.1. 个人信息使用的访问控制
个人信息的访问控制，我的理解主要是针对企业内部的数据访问机制，需要遵循最小权限原则，即用最少的人访问最少的数据。
常见的场景：
- 后台系统访问和获取数据的权限控制措施，系统统一认证鉴权
- 应用系统之间数据接口的权限管控，尤其是跨业务线，跨项目的情况
- 数据提取和拷贝机制
- 大数据平台，在线数据分析
- 办公网数据管控（桌管，零信任，线上文档编辑工具）
- 兜底方案：DLP，水印，染色，审计系统
3.2. 系统后台展示方式
涉及通过界面展示个人信息的（如显示屏幕、纸面），对需展示的个人信息采取去标识化处理等措施，降低个人信息在展示环节的泄露风险。例如，在个人信息展示时，防止内部非授权人员及个人信息主体之外的其他人员未经授权获取个人信息。
这里简单的解释就是系统展示也做脱敏，当然许多场景可能不能脱敏。
3.3. 用户请求的处理机制
（1）投诉处理机制
个人信息控制者应建立申诉管理机制和申诉跟踪流程，并在合理的时间内对申诉进行响应。具体做法分为四个步骤
- 建立申诉管理制度；
- 提供了有效的申诉渠道；
- 承诺了反馈时限；
- 承诺的反馈时限内进行响应。
申诉管理制度可以是一个独立文件，也可以是和客服建立的流程机制，甚至是知识库文件，建立制度的目的是规范申诉事件的处理方法，避免出现，无人响应，应答错误等情况
有效的申诉渠道一般在隐私政策中会有说明，最好还是建立多个申诉渠道，保证申诉渠道的通畅，比如电话，在线等，在APP中建立相应入口最佳。
承诺了反馈时限原则上不能超过15日。
承诺的反馈时限内进行响应是上述所有措施有效的保障：
- 第一，建立详细的申诉受理流程，客服，安全，法务，公关等岗位进行联动。客服直接面向客户进行简单的判断和争取收集，安全部跟进确认申诉事件判断最终结果，法务和公关进行最中事件解决的方案。
- 第二，保障上述流程进行，需要建立知识库，常见问题，需要收集哪些信息告知一线客服，并进行相应培训。
- 第三，安全部的数据溯源措施，工具，以及内部承接事件的应急处置方案建立。由于有时间限制，一般从客服接单后，只有不到10天的“破案”事件，所以溯源工具和标准化作业流程很重要。
- 第四，定期演练和培训，演练和培训是保障机制流畅运行的好办法。
- 第五，对自己的队友多鼓励，不要埋怨。尤其是制度建立之初，可能会有一些不靠谱的单子发过来，这时如果一味的埋怨一线客服可能会让整个流程变得阻塞。多分析原因，逐步积累知识库和培训素材，才是让一切变好的好方法
（2）个人信息获取副本和查询信息
获取渠道确认：可以是电话申请，线上申请等
获取途径：邮寄，在线提供等
身份认证：验证身份信息，可以通过输入密码，核对**等
信息提取流程：用户需要信息的类型，建立信息提取流程
证据保存：包括用户请求证据，***据，提取过程日志或记录。
四、个人信息的共享，转让，公开
4.1. 第三方共享转让
（1） 事先开展个人信息安全影响评估，并依评估结果采取有效的保护个人信息主体的措施。
参照《信息安全技术 个人信息安全影响评估意见稿》方法，这里不详细介绍了。
（2） 向个人信息主体告知共享、转让个人信息的目的、数据接收方的类型，并事先征得个人信息主体的授权同意。
一般通过隐私政策，隐私政策弹窗
（3） 共享、转让经去标识化处理的个人信息，且确保数据接收方无法重新识别个人信息主体。
只能尽量传输去标识化信息或脱敏信息，影响正常业务的还是可以共享个人信息的，主要看业务开展的模式。要建立相关制度，比如对第三方的安全要求，共享机制，安全协议，监控措施等。
（4） 准确记录和保存个人信息的共享、转让的情况，包括共享、转让的日期、规模、目的，以及数据接收方基本情况等
一般通过数据接口传输数据需要记录数据传输的日志，日志含有日期，访问规模，额外等级该接口的使用目的和数据接收方信息。
（5） 承担因共享、转让个人信息对个人信息主体合法权益造成损害的相应责任
处理个别案件和免责声明时要注意，可能需要让法务部了解一下。
（6） 帮助个人信息主体了解数据接收方对个人信息的保存、使用等情况，以及个人信息主体的权利，例如，访问、更正、删除、注销账户等。
客服的流程，客服能够帮助客户了解第三方信息。在与第三方签订合作时，需要将次义务特别说明。
4.2. 个人信息公开披露处理
（1） 事先开展个人信息安全影响评估，并依评估结果采取有效的保护个人信息主体的措施
同上，不介绍了
（2） 向个人信息主体告知公开披露个人信息的目的、类型，并事先征得个人信息主体明示同意
在公开披露个人信息前，需要通知并获得同意
（3） 准确记录和保存个人信息的公开披露的情况，包括公开披露的日期、规模、目的、公开范围等
公开披露场景很多，所以没有确定的方式。比如通过系统公开获奖名单，一般会脱敏个人信息，并且上传系统的日志中记录此次获奖名单即可。
（4） 承担因公开披露个人信息对个人信息主体合法权益造成损害的相应责任
（5） 不得公开披露个人生物识别、基因信息
4.3. 个人信息委托处理
（1） 个人信息控制者应对委托行为进行个人信息安全影响评估
同上，不介绍了
（2） 受委托者应：
- 严格按照个人信息控制者的要求处理个人信息。受委托者因特殊原因未按照个人信息控制者的要求处理个人信息，应及时向个人信息控制者反馈；
- 受委托者确需再次委托时，应事先征得个人信息控制者的授权；
- 协助个人信息控制者响应个人信息主体提出的请求；
- 受委托者在处理个人信息过程中无法提供足够的安全保护水平或发生了安全事件，应及时向个人信息控制者反馈；
- 在委托关系解除时不再保存个人信息。
应用场景很少，没有合适的场景和案例。基本遵循两点原则：第一，最小的保存时间原则，第二，委托的授权和个人信息处理方式对信息主体有知情权和同意撤销权
（3） 通过合同等方式规定受委托者的责任和义务；对受委托者进行审计
主要是审计工作的安排，如果很重大的项目建议采用定期审计，建议聘请外部审公司可以有效转移风险。一般项目可以考虑自动化审计工具，日志分析等方式。
4.4. 跨境
跨境目前比较复杂，要遵循我国跨境传输法律并遵循当地的法律要求。我国的跨境传输指南是现在比较常用的参考。欧盟的GDPR现在要求比较严格，所以传输至欧洲需要特别注意
五、结束语
本篇针对的是服务端和公司内部的流程和机制，不仅仅是合规的需要，还是保护公司自身利益的需要。尤其是第三方数据共享时，数据流出公司防护边界，其泄露极可能影响到公司利益，并且很难排查。
本文主要从隐私要求，管理和法律方式对第三方的数据保护进行约束，公司内容防护建设也应注意对第三方的数据权限控制，并具备一定审计和溯源能力，比如使用脱敏，染色等技术。
