数据安全管理 学习笔记

一、数据安全整体框架

• 制度层是实施数据安全管控的基础和依据。只有提前发布清晰严谨的《数据安全管理办法》及相关流程，企业才能明确数据安全中的团队职能和员工义务，员工才能知晓并遵循数据操作的正确处理方式，安全团队才有可能正常开展数据安全管控工作。制度层最重要的工作是明确分类分级、授权审批和违规惩戒。
  • 分类分级有助于区分建立不同强度的安全管控措施，避免无差别管控导致的资源浪费和效率低下。分类分级没有特定的标准和要求，可以根据企业的实际情况自由安排和调整，但是必须注意避免划分过粗或过细。过粗的分类分级可能导致数据匹配不合理的管控措施，对敏感度较低的数据启用相对严格的管控措施会浪费资源或影响效率，对敏感度较高的数据启用相对宽松的管控可能引发安全事故。而过细的分类分级则可能导致审批流程和管控体系异常复杂烦琐，甚至可能出现无法落地执行的情况。
  • 授权审批用于约束权限的分配和使用，避免不必要的权限以及数据滥用引发安全风险。授权审批必须遵循“权限最小化”原则，审批节点至少应该包含数据申请者上级负责人、数据操作者上级负责人和数据所属团队负责人，数据密级越高，审批节点也应该随之增加管理层级越高的负责人。数据授权审批不仅需要关注相关数据申请的合理性和必要性，而且必须同时考虑原始数据是否在加密或脱敏后依然可以满足业务需求，最大限度降低敏感数据明文泄露的可能性。
  • 违规惩戒可以确保《数据安全管理办法》及相关流程的准确执行，同时对违规及恶意行为形成一定程度的威慑。违规惩戒的落地形式是建立《数据安全管理罚则》，需要针对不同密级以及是否造成实际影响两种情况制定不同的惩罚标准。对于相对较高密级的数据违规及恶意行为，必须采取严厉的惩罚措施，因为这类问题发现成本较高，而且难以判断是否会产生持续性影响，所以应该通过更大的威慑尽可能减少事故。另外，违规惩戒应该避免把“是否主观故意”这类无法客观评判的因素作为区别对待的条件。

• 技术层是保障数据安全的方法和措施。数据安全既在很大程度上依赖基础安全和业务安全，同时又具有自己独立的技术体系和方法论。数据安全团队不需要执行具体的基础安全和业务安全工作，这些应该在明确目标和需求后协调推进相应团队落地执行，而数据安全团队应该将更多的精力集中在自己的技术措施上。
  • 访问控制确保只有获得授权的人才可以访问指定的数据。目前主流的信息系统和工具都已经提了相对完善的访问控制功能，因此可以在网络、操作系统、数据库、应用系统和文件等多个不同的层面进行混合实施，这样可以在一定程度上避免某一环节的疏漏导致的整体控制彻底失效。需要注意的是，如果备份文件和开发测试等非生产环境中包含有敏感数据，那么也应该采取同等强度的访问控制措施。对于移动存储、纸张等介质中的敏感数据，应该通过保险箱等物理安全措施进行保护。
  • 加密脱敏确保即使数据被非授权访问，也无法读取或篡改数据内容。加密和脱敏可以发生在数据处理、存储或传输等任意环节，在不同的业务场景下应该采用不同的加密算法和脱敏方案。选择加密算法和脱敏方案时，首先必须确保满足业务需求，不能因为盲目追求安全牺牲业务的可用性；其次应该避免采用不安全的算法和方案，比如DES、RC4、RSA1024等；最后还需要关注性能损耗，一般情况下非对称加密与对称加密的性能存在数量级的差异。
  • 安全清除确保被删除的数据无法还原，减少设备返厂维修、员工办公设备遗失等情况下的敏感数据泄露风险。在执行文件删除操作时，磁盘并不会真正地清除数据，而是仅仅标记相关区域可以覆盖新的内容。因此，如果磁盘等具有相同删除机制的存储设备未执行安全清除操作，那么未被再次覆盖的磁盘区域的已删除数据就可能被恢复，从而导致数据泄露的可能性。安全清除的机制一般是在相应磁盘区域反复覆盖多次干扰数据。
  • 备份恢复确保数据丢失或被篡改的情况下，可以恢复到某个时间节点之前的状态，而不至于业务被彻底破坏。在很多企业中，与备份相关的职能归属运维团队，在这种情况下，安全团队必须重点关注包含敏感数据的备份文件是否满足相应密级的安全管控要求。为了避免备份文件出现异常导致故障甚至灾难发生后无法恢复业务，必须定期执行恢复测试和演练，及时发现有问题的备份文件和操作流程。
  • 异常监控确保未经授权的数据操作得以及时发现和控制，可以通过操作行为和网络流量两种途径进行监控。操作行为监控主要依赖基础安全工作中部署的操作审计工作，不同的是数据安全异常监控更为关注包含特定敏感数据的文件或数据字段，尤其涉及用户个人信息的查询和资金数据的修改必须严格监视与验证。网络流量监控重点关注异常的请求源IP和大流量，从中挖掘不符合预期的访问行为和大规模数据导出事件。如果条件允许，也可以直接通过网络流量分析具体数据操作行为，这种方法在数据库操作监控中比较常见，但不适用于通过ssh等加密协议执行的数据操作。

• 审计层用于检查和监督数据安全管控的可靠性，及时发现和纠正相关的问题和偏差。审计层与数据安全管理框架中的每一层都紧密相关：制度层是审计层开展工作的主要依据，但是审计层又可以反向推进制度层的优化和完善，同时对意图违反制度的员工形成威慑；技术层为审计层提供主要的证据和工具，但是审计层也可以揭露技术层的缺陷和不足；情报层则可成为审计层的重要输入和补充。审计层主要包含合规性、合理性和安全性3种类型的审计工作。
  • 合规性审计主要负责外部监管要求和内部管理制度的符合及遵循情况。外部监管要求主要来源于经营地区的法律法规和行业标准，法律法规比如中国的《网络安全法》、欧盟的GDPR和美国的CCPA等，行业标准包括等级保护、PCI DSS等，合规性审计必须确保企业内部无论制度规范还是实际操作都能够满足正常经营必须达到的监管要求。内部管理制度合规性审计则主要关注企业内部实际操作是否与制度规范要求一致。
  • 合理性审计主要负责授权审批和实际操作是否与业务需求相匹配。授权审批的常见问题是权限审计及分配不符合“权限最小化”原则，这种情况下理论上应该同时追究申请人和审批人的责任，但是这种理想化的授权和追责方案在实际情况中很难全面落地推行，因此这类审计和追责可以考虑限定在适量的高密级数据范围内开展。实际操作的常见问题是不必要的数据传输和导出，比如一些完全可以线上完成计算的统计类需求，但是在实际操作过程中把具体信息导出到个人设备进行运算，等等。同样，与数据安全相关的审计操作也可以考虑限定在高密级数据范围。
  • 安全性审计主要负责与数据直接相关的安全风险的排查和整改。数据的安全性审计工作主要包括3个部分。一部分是基于基础或业务安全风险的攻击或遍历，这些工作可以协调相关安全团队进行检测和处置。另一部分是数据安全技术的自身缺陷，比如采用了强度不足的加密算法、有缺陷的脱敏方案等，这些可以通过建立与常见场景关联的安全基线和checklist来检查和减少。还有一部分是针对数据的恶意行为，相关的审计工作内容与行为监控相似，但与行为监控相比周期性更强而且挖掘程度更全面更深入。
• 情报层是数据安全管控的最后一道防线，其目标在于尽可能发现那些已经发生的数据泄露事件，及时响应并最大限度降低事故影响。基于当前的数据安全发展情况，无论制度层、技术层和审计层如何严格管控，都无法绝对杜绝数据泄露的可能性，因此情报层就成了数据安全管理框架中不可或缺的一环。数据安全的情报工作可以从泄露监测、威胁情报和舆情监控3个方向入手。
  • 泄露监测主要通过技术手段对一些具备典型特征的敏感数据进行监测，在技术实现上主要是爬虫和正则匹配。泄露监测不可能也不需要针对所有的互联网应用展开检索，对大部分企业而言，关注好企业内部交流和文档系统、GitHub和GitLab等公开的代码仓库、主流的暗网交易站点、具备检索条件的云存储服务和一些常见行业交流社区就可以了。
  • 威胁情报是泄露监测的重要补充，通过充分借助外部资源，可以更广更全地监测数据泄露事件。威胁情报主要有两种来源，一种是依赖SRC，面向公众有偿收集与所属企业相关的数据泄露信息，另一种是采购威胁情报服务，由第三方专业公司或机构代为搜集和筛选相关信息。通常前者成本更低，信息更为及时，但是全面性和准确性相对较低，连续性也缺乏保障，而后者则恰恰相反。
  • 舆情监控一般由公关团队负责，安全团队需要提前与公关团队建立信息同步和应急协作流程，与数据泄露相关的舆情监控工作必须成为其中的一部分。与泄露监测和威胁情报不同，舆情监控的信息搜集阶段重点关注舆论影响而不是具体的数据内容，但是热度较高的数据安全舆情事件通常对应严重的数据安全事故，数据安全团队必须跟进相关问题的核实与整改，并且为公关团队提供后续处置所需的信息和技术支持等。

 

二、数据安全管理流程

数据安全管理流程是制度层的落地形态，应该覆盖企业内部任何与数据操作相关的行为，包括但不限于数据生命周期中产生、存储、使用、传输、外发、披露和销毁环节的安全控制。

为了便于推进和执行，数据安全管理流程可以划分为《数据安全管理办法》《部门数据安全管理细则》和《数据安全管理罚则》3个部分。

• 《数据安全管理办法》作为数据安全管理的总纲性文件，明确原则性要求，在整个企业范围内适用。考虑到不同的团队可能存在独特的工作模式和管理需求，还应该允许各个团队在不违背《数据安全管理办法》的前提下根据自己的实际情况制定相应的《部门数据安全管理细则》，仅在制定部门内部适用。
• 《数据安全管理罚则》用于明确违规操作的惩戒措施，它可以作为《数据安全管理办法》的一部分，也可以加入《员工手册》《员工行为准则》等其他制度文档中。
• 《数据安全管理办法》至少应该包含适用范围、职责定义、数据分类、数据分级、管理要求、技术要求、审计要求和例外处置等内容，根据企业制度编制风格的差异，也可以考虑增加制度目标、术语定义、惩戒措施、培训要求和其他附则，等等。

 

三、数据安全技术措施

一个处于发展初期或中期的数据安全团队可以把数据安全技术划分成访问控制、加密脱敏、安全清除、备份管理和监控审计5个主要模块进行建设和推动，它们已经可以覆盖绝大部分数据操作场景和相关风险，而且每一个模块目前都已经具备一些成熟的技术方案可以落地执行，同时又都具备一定的待提升空间与技术局限性。

访问控制很大程度上依赖基础安全和业务安全的管控工作，在物理、网络、系统、应用和数据层面都可以实施相应的访问控制措施，各个层面的不同措施既相互补充，又相互融合。常见的访问控制措施包括但不限于物理层面的隔离或上锁、网络层面的隔离或ACL、系统和应用层面的账户与权限控制、以及数据层面的权限管控。与此同时，还需要重点关注敏感数据所处系统或应用存在的安全漏洞和缺陷，避免因为它们导致访问控制策略失效。

加密脱敏在企业应用中最常见于传输、存储和提供这三大需求，其中每一类需求可以细分为若干具体场景，每种具体的场景又涉及不同加密算法、脱敏方案和注意事项。因为不同的加密算法在功能、强度和性能上各有千秋，所以必须充分结合业务需求、特性和场景选择合适的算法、协议和方案。

• • 在数据传输方向，主要涉及网络服务提供、远程网络互通、系统维护管理和文件及信息交互等类别。对于大部分的企业应用场景，实现加密传输需求并不需要自主研发，而是有很多现成的方案、工具或者协议可以使用，如果使用它们的时候需要配置人员选择具体的加密算法，那么必须注意规避比如MD5、SHA-1、RC4、DES（不含3DES）、RSA1024等已经被证明安全强度不足的弱算法。一些常见的场景及对应的加密方案、工具、协议和算法如下表所示。，对于企业自己开发的C/S架构的应用，建议传输过程使用AES+ECDHE的加密方案。其中AES算法用于加密通信数据，而AES密钥通过ECDHE算法在客户端和服务器之间安全交换。这个方案的主要优点在于客户端和服务器都不需要预置密钥，但是每个客户端和服务器之间的AES加密通信都可以使用不同的密钥，而且AES密钥不需要通过网络传输。为了进一步加强安全性，还可以使用ECDSA算法对密钥交互过程进行签名，降低遭受中间人攻击的风险。
  • 数据的加密存储主要分两大类场景，它们的主要区别是加密后是否还需要还原成原始数据。
    • 需要还原的类型很好理解，主要包括一些需要重新展示或者根据明文运行计算的敏感数据，比如企业的财务数据、核心资料、融投资计划、期权文件和薪资信息等，用户的联系方式、收货地址、账户余额、交易记录和健康状况等，都属于加密后还需要解密还原的类型。
    • 加密后不需要还原的数据一般用于验证身份和资料匹配，比如用户的登录口令、支付口令、密保答案和一些用于建立关联特征的其他数据等，如果收集用户的通讯录和当前城市仅仅是为了匹配好友，那么这些数据也应该按照不需要还原进行加密处理。
  • 数据的提供需求主要包括展示、分发和共享等场景，这些场景可能发生在企业运营的任何一个环节，包括但不限于用户和企业之间、企业内部的不同团队之间、企业与其他企业之间、企业与监管机构之间等，同时这些场景也可能涉及任何类型和任何密级的数据内容。
  • 数据的展示脱敏是安全团队非常容易产生疏忽的环节之一。部分安全团队通常习惯于把注意力集中在应用系统敏感数据的访问控制上，而忽略获得授权的账户看到的数据内容是否合理。这会导致至少两种类型的风险，一种是获得授权的员工滥用权限，比如客服人员随意查看用户个人信息、风控人员违规调阅用户银行卡号；另一种是账户权限失控引发信息泄露，比如差旅应用账户被盗后泄露完整的手机号和身份证号、利用精确距离计算用户具体地理位置，等等。解决这些问题的有效方法之一是在应用展示敏感数据时进行脱敏或混淆处理。
• 安全清除的目标是确保已经删除的敏感数据无法通过技术手段恢复还原，实现数据销毁要求。相对其他数据安全技术而言，安全清除技术很少被提及和应用，也更容易被企业所忽略，但是存储过敏感数据的介质被别有用心者获取并批量恢复的后果通常是灾难性的，而且由于相关介质一般已经离开安全管控范围，这个过程几乎无法监控和审计。要降低相关风险，数据安全团队必须严格把控介质的回收和转移环节，一些常见的场景包括但不限于：
  • 在服务器或其磁盘退役、报废或转售之前
  • 在服务器或其磁盘返厂维修之前
  • 在办公设备退役、报废或转售之前
  • 在办公设备返厂维修之前
  • 办公设备因员工因离职等原因交还公司之后
  • 为敏感数据分配专用移动存储介质，在其退役、报废或转售之前
  • 为敏感数据分配专用移动存储介质，发生故障直接报废
  • 为敏感数据分配专用移动存储介质，禁止多人共享，再次分发之前
  • 存储敏感数据的纸张、光盘等介质在使用完成或报废之后

• 数据备份和恢复职能涉及不同的部门和岗位，在大部分企业，服务器及生产数据一般由运维部门主导，办公设备及员工数据则多由IT部门负责。数据安全团队不需要参与备份恢复的具体执行工作，但是必须评估与备份恢复相关的策略风险和操作风险，并且针对其执行过程开展合规性审计。数据安全在备份恢复中重点关注的内容包括但不限于：
  • 备份操作是否按备份策略执行
  • 重要数据是否具备合理的异地备份机制
  • 备份文件是否按原始数据密级进行保护和管理
  • 是否按要求执行恢复测试
  • 恢复测试环境及相关数据是否按原始数据密级进行保护和管理
  • 恢复测试环境及相关数据是否按原始数据密级进行销毁
• 监控审计直接决定数据安全管控体系是否能够正常运转，没有惩戒威慑的管理要求在大部分企业几乎不可能准确落地和执行。监控审计工作在数据安全管理框架中分布于技术层、审计层和情报层，但是在技术实现上他们高度相似而且相互融合。数据安全监控审计可以通过商业产品也可以通过自主研发实现。一些可用于数据安全监控审计的产品或工具包括不限于下面几个。
  • DLP（data loss prevention，数据防泄露）系统。目前市面上主要存在两种类型的DLP产品，一类基于主机，另一类基于网络，这两类技术可以独立实施，也可以根据数据防控需求混合部署。数据库审计系统。对于读写比较频繁的业务，一般不建议直接开启数据库系统的审计功能，因此导致的性能损耗很难被数据库管理员接受，甚至很容易引发系统异常。基于流量分析或代理的数据库审计系统可以避免这个问题，但是如果数据库审计系统以串联结构部署，那么必须确保其本身具备足够的性能和可靠的bypass机制，避免因为数据库审计系统的问题导致业务中断或异常。
    • 基于主机的DLP系统可以实现的功能相对较多，比如透明加密、输出控制、行为监控、水印标记等，无论从监测、控制、审计还是溯源取证等方面都能发挥较好的作用，但是因为需要在每一台主机上安装专用客户端，员工对其感知较强，因此实施推进的阻力通常相对较大。
    • 基于网络的DLP系统直接分析和处理网络通信，一般部署在网络边界，因此实施和管控过程对用户更加透明，推进和落地也相对容易一些。但是其监控和防护能力受限于网络通信，通常对加密通信、非主流协议或文件无能为力。
  • 堡垒机。通过部署堡垒机并严格限制办公环境到生产、测试环境的网络连通性，可以确保相关操作被有效监控和记录。
  • 上网行为管控系统。针对员工在办公环境的泄密行为，上网行为管控系统可以实现一定程度的监控和防护，它主要通过三方面发挥作用：日志分析系统。在日志合理开启和采集的前提下，日志分析系统可以实现多种监控和审计，数据安全也是其中之一。在使用日志分析系统执行数据安全监控和审计之前，必须明确标识与敏感字段相关的系统、账户、文件和字段等信息，并尽可能实现精准监控和审计，避免产生过多的安全告警和异常提示，防止必须关注的重点信息被淹没和忽略。实施日志分析系统的另一个常见问题是因为脱敏不当导致日志中包含有大量敏感信息，比如业务日志中的手机号码、操作日志中的账户口令等，这会导致日志分析系统本身成为数据泄露的风险点。因此，日志分析系统必须严格落实脱敏要求，如果因为特殊原因无法实施脱敏，那么日志分析系统本身应该按照采集和存储敏感数据的最高密级进行数据安全管控。
    • 首先是只允许获得授权的员工访问互联网，确保外部人员或无授权的员工无法将数据发送到互联网
    • 第二点是限制可以访问的互联网服务（如网盘等），降低病毒木马等恶意程序进入办公环境的风险，同时减少数据外发的渠道
    • 第三点是监控部分上网行为和外发文件，但是该功能不适用于加密通信和非主流协议。
  • 信息爬虫和威胁情报。情报层工作主要通过爬虫、SRC和威胁情报服务来实现，在技术实现上并不复杂。信息爬虫可以分为模糊匹配和精确匹配两种：对于类似“公司名称”“公司名称+password”和“公司名称+手机”这种泛指信息的模糊匹配，应该合理控制检索范围，关注GitHub、GitLab、暗网交易平台这类高风险站点即可，否则可能产生海量告警导致无法跟进；对于类似于云主机AccessKeyId这种具体信息的精确匹配，则可以扩大检索范围，尽可能及时发现泄露情况。

以上提及的产品和工具可以采购商业产品，也可以基于开源工具搭建或二次开发。尽管前期建议优先考虑采购商业产品实现快速落地，但是在数据安全团队发展到一定阶段以后，还是应该综合衡量管控需求和长线成本，重新考虑采购或自研的必要性和可行性。另外，虽然上面提及工作方向已经可以覆盖大部分数据安全监控和审计需求，但是实际效果很大程度上取决于推进和执行的全面和精细程度，决不能简单地把“工具上线”作为数据安全管理的工作目标。

 

四、数据安全平台建设

相对于基础安全和业务安全，数据安全不仅在管理和技术方面结合得更为紧密，而且涉及的领域更加全面和分散。在数据安全管控体系的实际落地过程中，几乎没有人可以准确无误地记忆所有的制度要求和技术标准，数据所有者不知道自己的数据密级、数据申请者不了解授权流程、数据操作者不清楚保护措施的情况比比皆是，即使是数据安全团队的成员自己也会经常出现这样的情况。

为了确保数据安全管控体系能够准确、有效、持续地运转，就必须想办法降低各方员工的合规门槛，尽可能减少需要他们记忆和操作的环节。一个行之有效的解决方案就是建设集中管控式的数据安全平台，统一集成资产库、基线库和知识库，把各类数据审批流程固化为电子工单，尽可能通过预置规则实现敏感数据的自动识别和异常分析，甚至可以针对一些标准化场景自动检测和实施安全技术措施。

根据数据安全平台的设计目标和功能需求，系统架构可以划分为采集层、预处理层、存储层、分析层、控制层、展示层和外部接口，每层需要实现的主要功能或能力如下图所示。

采集层

采集层主要负责采集和录入与数据安全相关的信息，主要包含三类输入信息：

• 第一类是数据内容及其属性，主要关注数据的类型、路径和上下线时间
• 第二类是数据授权和操作行为，主要针对敏感数据范围
• 第三类是与数据安全相关的规则、标准、基线和经验，这些主要依赖人工录入和维护

采集层的实现途径主要有日志收集、流量分析、事件感知和一些其他输入方式。

1、日志收集

日志收集的范围包括但不限于与敏感数据相关的授权审批日志，以及业务应用系统、数据库系统和操作系统的操作日志。这些日志可能由相关系统直接生成，也可能来自其他工具或组件，比如B/S架构的应用系统如果无法直接提供操作日志，可以采集容器的get和post请求日志，另外数据库的操作日志很可能依赖独立部署的数据库审计系统，操作系统的操作日志可能来自堡垒机，等等。

日志收集的技术实现相对简单，实施推进成本相对较高，而且存在过度依赖业务方配合、无法关注数据内容等缺陷。

2、流量分析

流量分析通过镜像、重组、解析业务的网络通信，识别和提取其中的数据内容和相关的操作行为。与日志收集相反，流量分析因为涉及多种不同协议和场景所以技术实现相对复杂，但是因为网络部署业务无感知所以实施推进成本相对较低。流量分析的瓶颈在于加密流量和吞吐性能，因此传感器和探针应该尽可能部署在明文流量集中的区域，在流量过大的情况下，操作行为可以优先通过日志收集，然后通过流量分析抽样采集数据内容样本，如果性能依然无法满足采集需求，就需要考虑分布式部署传感器和探针了。

3、事件感知

数据安全事件不一定全部通过数据安全平台分析和处置，比如DLP、数据库审计系统和堡垒机等安全工具都具有独立的事件管控能力，但是数据安全平台应该实现数据安全事件的集中记录、跟进和管理，因此数据安全平台必须具备相关的事件感知能力。事件感知在实现上近似于日志收集，但是采集的内容变成了确定的数据安全事件信息，它们可能以消息告警、邮件通知、后台记录或者事件日志等不同的形式传递和存储。

4、其他输入

上面提到的3种采集方式无法满足全部的数据安全信息采集需求，还需要补充一些其他的渠道和方式，比如数据和信息爬虫、数据库抽样脚本、SRC平台、第三方威胁情报服务和舆情监控渠道，等等。另外，人工录入也是一种重要但很容易被忽略的采集方式，在需求设计时必须充分考虑好相关的需求和场景。

预处理层

数据安全平台采集的原始信息通常包含大量不同的内容和格式，如果这些原始信息直接交由分析层进行处理，那么分析层需要针对每种格式的原始信息分别建立解析规则，并且分析（尤其是关联分析）的运算效率会因为大量的无效信息和解析处理大幅降低。为了避免这类问题，合理的方式是在入库前对采集到的原始信息进行预处理。预处理层的作用分成前后两个主要步骤。

• 第一步先对采集到的原始数据执行ETL（Extract-Transform-Load，抽取-转换-加载）处理，将不同来源、不同内容、不同格式的原始数据以统一、集中、规范的形式整合到存储层的数据仓库中，并且去除其中的无效信息，为分析层实现标准化操作提供必须的前提条件。
• 第二步是针对ETL处理之后需要落库存储的采集信息实施安全控制，控制措施主要包括脱敏和加密两种方法。对于采集到的敏感数据具体内容，数据安全平台设计者首先应该考虑避开落库环节、在预处理之后直接传入分析层的可行性，比如通过流量分析或者数据库抽样脚本判断业务是否新增了敏感数据字段时，采集到的手机号、银行卡号和身份证号等数据字段是可以实时完成匹配而不需要预先存储的。如果必须落库分析和记录，那么应该优先考虑采用脱敏方法，脱敏无法满足需求时才进行加密存储。

存储层

存储层的设计和实施需要兼顾多种不同类型的信息和数据，它们至少包括：

• 经过预处理的采集信息
• 通过分析获取的异常信息
• 账户、权限、规则、基线、经验等平台数据
• 访问日志、操作日志和错误日志等平台日志信息

因为针对不同类型信息和数据的运算处理需求和方法也各不相同，因此存储层一般无法通过单一的数据结构和数据库工具实现，Hadoop、Elasticsearch、MongoDB、Redis、MySQL都是自研数据安全平台存储层的常见选项。

除了技术选型，存储层还需要关注访问控制和冗余需求。

• 在访问控制方面首先要严格限制对于数据安全平台存储敏感数据的访问和操作，其次必须采取有效措施验证信息来源和完整性，降低采集信息被恶意伪造或干扰的风险。
• 冗余需求则应该根据不同的信息或数据区分设计，对于量级巨大而且重要程度不高甚至可以接受抽样的采集信息，处于存储成本考虑可以不建立冗余措施；对于异常信息和平台数据，可以建立主从冗余并定期执行备份；对于数据安全平台操作日志等重要审计输入，还应该考虑实时转发到异地日志服务器备份存储。

分析层

分析层承担了识别数据资产、记录敏感操作、监测数据风险和检验合规符合度等一系列重要作用，其中少部分可以通过单条或单方面来源的输入信息直接分析出结果，但是更多部分需要结合各方输入关联分析才能够获得结果。

1、数据资产识别

资产识别的输入来源包括但不限于数据资产登记表、业务请求和响应内容、代码变量名称、数据表和字段名称以及数据随机抽取样本，采集方法可以是人工访谈录入、网络流量分析、信息和数据爬虫以及数据抽样脚本，等等。数

据资产登记表一般由数据安全团队维护，详细记录有每个部门拥有的数据及其密级，是数据安全平台中数据资产清单的最主要来源，但是数据资产登记表的建立和更新过于依赖员工的知识、经验和主观意识，因此难免产生疏漏或更新不及时的情况。

为了弥补人工梳理能力的不足，可以考虑通过技术手段建立敏感数据的自动识别机制。自动识别的简单实现可以通过两个方向入手：

• 一边是从数据的内容入手，通过正则表达式匹配疑似敏感数据，通过这种方式可以从业务请求响应、信息爬取结果和数据随机抽取样本中有效识别手机号、银行卡号、身份证号、经纬度以及口令散列密文等具备一定规则特征的敏感数据
• 另一边是从数据及其相关参数的命名入手，通过特定关键字检测疑似敏感字段可能出现的位置，这种方式适用于从需求文档、程序代码、数据库表名和字段名以及请求和响应参数中匹配例如“password”“card”“姓名”“联系方式”和“家庭住址”等与敏感信息强相关的名称信息，并继续跟进确认是否需要更新数据资产清单

由于数据及其命名的多样性和随机性，自动识别机制无法完全替代人工梳理和跟进工作，但是可以与之形成有力补充，并且大幅提升数据安全工作效率。

2、敏感操作记录

操作记录应该尽可能全面地覆盖各个方面，包括但不限于应用系统、数据库、数据仓库、操作系统和各种可能与数据产生关联的系统和工具。如果条件允许，数据安全团队应该长期保存这些记录，以备将来分析能力进一步提升后重新深入挖掘，或者在发生数据安全事故后溯源取证。如果在推动协调、资源投入等方面存在困难，那么可以结合资产识别输出的敏感数据清单，重点提取、记录和保存与之相关的查询和变更操作。

由于不同的系统和工具涉及不同的指令和操作方法，所以分析层必须具备提前设置好相关指令和操作的识别和解析规则。正常情况下，大部分操作可以通过特定的指令提取和记录，但是如果操作人员尝试恶意绕过监测，这种基于正常考虑的分析方法就很容易出现问题和疏漏。因此，操作分析至少还需要考虑以下情况。

• 是否存在和数据操作相关的指令别名（如Linux的alias）
• 是否存在和数据操作相关的定时任务（如Linux的crontab和at）
• 是否存在和数据操作指令相关的脚本或其他代码
• 是否存在和敏感数据相关的未知指令或操作

3、数据风险监测

风险分析是分析层的核心功能，也是数据安全监测和审计能够准确执行的重要保证。在数据安全团队发展前期，可以主要关注资产疏漏、防控缺陷、高危操作和数据泄露4种常见风险。

• 资产疏漏是指通过资产识别发现了之前安全管控没有覆盖的敏感数据，这种情况经常伴随新业务或新职能出现。资产疏漏风险分析的实现逻辑比较简单，只需要针对资产识别模块新发现的疑似敏感数据进行记录并生成告警，同时安排相关人员跟进确认即可。
• 防控缺陷的产生一般是因为没有针对敏感数据实施相应密级的安全防控措施，或者在变更过程中降低了防控标准。数据安全建设初期防控缺陷可能在任何业务任何环节出现，经过一段时间的推进整改之后，它通常会与资产疏漏风险成对出现。实现部分防控缺陷自动检测的前提是梳理数据资产清单，并且建立数据安全防控基线，然后通过对比实际防控情况和相应数据密级的防控基线确认是否存在缺陷。防控缺陷检测项包括但不限于：
  • 未按要求加密或脱敏
  • 未按要求执行访问控制
  • 未按要求设置安全相关的参数配置
• 高危操作需要覆盖可能导致数据安全事故的指令和行为，实现难点主要在于指令本身是不存在安全或危险标签的，因此几乎不可能单纯地依赖一两条指令确认它们的风险级别，以及决定是否应该产生告警。但是，我们可以结合业务、职能和经验，综合判定操作存在风险的可能性，下面是一些综合判定后较大概率存在风险的案例。
  • 数据库管理员读取特定用户的登录口令或支付口令。
  • 应用管理员在短时间内读取大量用户手机号、通信地址等信息。
  • 没有相关职能的员工尝试读取特定用户信息，比如研发人员尝试查看用户手机。
  • 不属于备份需求的敏感数据导出和复制行为。
  • 尝试批量修改和删除重点数据的行为。
  • 不符合历史操作习惯的敏感数据行为，比如从不维护数据库的运维账号直接查询用户信息。
  • 异常的敏感数据访问尝试，比如多次的口令尝试失败、文件访问权限拒绝等。
  • 可能降低敏感数据防控水平的操作行为，包括修改权限和参数等。
  • 关闭或删除敏感数据及与系统相关的监控或日志等。
• 数据泄露是最常见也是最容易发生的数据安全事故，在不同的数据安全管理和技术条件下，数据泄露的分析和监控效果可能呈现出完全不同的效果：
  • 对于明确禁止外联、所有操作必须经过堡垒机等成熟监控和审计系统的情况，可以实现效果最优化
  • 对仅允许有限外联（禁止网盘、聊天工具等具备文件传输能力的主流互联网服务）、但是所有终端均已部署基于主机的成熟DLP产品的情况，可以实现相对较好的效果
  • 对于仅允许有限外联、但只部署了网络DLP和上网行为管理等有限能力的防泄露产品的情况，可以实现一定程度但存在明显缺陷的效果
  • 对于允许随意外联、并且缺乏监控和审计能力的情况，那么基本上只能依赖信息爬虫、威胁情报和舆情监控感知的既定泄露事件了

4、合规监测

合规检测本质上是风险分析的子集，但是因为合规工作通常由专职团队管理和推进，而且合规问题在安全风险的基础上还增加了监管风险，所以建议规划成单独的模块处理和跟进。合规监测模块可以分3个方面进行设计。

• 第一个方面是监测监管要求符合度，主要关注企业当前的管理要求和实际执行是否满足运营地区的监管要求，比如《数据安全管理办法》是否覆盖法律条款、个人信息的跨境传输是否符合当地法规要求，等等。这方面的分析很难通过程序实现自动化，而是主要依赖人工分析和录入，但是可以结合控制层的事件跟进模块实现一定程度的状态自动更新和维护。
• 第二个方面是监测不符合制度要求的违规操作，主要包括未经授权的操作和明确禁止的操作。未经授权的操作可以结合工单审批数据进行关联分析，其中类似于账户申请、上线发布这类执行指令和工单内容都比较固定的操作一般可以实现自动匹配和分析，对于其他操作，可以考虑要求在审批工单中提前填写计划执行的指令或SQL语句——这种要求仅适用于与敏感数据相关的少量操作，并不适合全面推广。明确禁止的操作则大部分可以通过正则表达式识别和判断。
• 第3个方面是监测不满足标准的技术防控措施，这方面的问题与风险分析模块中防控缺陷检测结果高度重合，区别在于风险分析完全从降低业务风险出发，合规监测则更多关注实际执行是否符合监管和制度要求。

控制层

控制层为数据安全平台提供了干涉和控制企业数据生命周期中各个环节及相关操作的核心能力。在控制层的设计和实施过程中，数据安全团队必须承认并接受技术的局限性，与其盲目地追求自动化管控和过于新潮的技术理念，不如踏踏实实地在适当自动化的同时努力提供简单实用的管理工具。

基于这点考虑，接下来从流程控制、过程控制、技术控制和权限控制4个方向实现控制层能力。

1、流程审批控制

在数据安全平台实现流程控制能力的主要手段是建立流程审批功能。流程审批电子化至少可以从两方面降低员工的数据合规门槛：

• 首先他们只需要知晓数据安全平台入口就可以完成流程填报和审批操作，不再需要记忆具体的审批环节和细节要求
• 其次数据安全平台可以根据员工申请操作的具体数据字段或类型匹配密级，自动调整后续审批环节并提醒相关的注意事项，免去了员工查询或记忆数据定级的过程。

对数据安全团队而言，建立流程审批功能有助于集中管控和审计与数据相关的操作需求和审批过程，减少员工执行错误流程的概率，同时又可以结合其他分析和控制能力实现部分数据风险监测的自动化。

2、过程控制/事件跟进

过程控制的落地方式可以是提供事件跟进的管理工具，帮助数据安全团队记录、更新、复盘、归纳和总结与数据安全相关的事件、问题和整改进展，并且在出现异常时及时提示和告警。跟进项可以是人工录入的某个具体事件，但是实际工作中更多由分析层识别和发现的问题自动触发，常见的触发问题包括但不限于以下内容。

• 识别出未记录的疑似敏感数据
• 发现恶意、违规或其他可疑操作
• 检测到不符合相应密级标准的技术防控措施
• 审计出不满足合规要求的操作或权限

与此同时，事件跟进生成的数据又可以转化成分析层的输入，从中发掘出具体问题后触发形成新的跟进项。通过事件跟进数据，至少可以分析出以下异常。

• 事件进展不符合预期
• 某类问题大范围集中出现
• 某些团队问题相对明显频发
• 管理要求或技术标准中存在的不合理项

3、技术控制/外部联动

数据安全平台可以通过联动其他系统或工具实现一定程度的技术控制自动化。

外部联动模块可以实现诸如中止操作会话、变更访问控制、纠正配置参数和清理泄露数据等部分控制工作的自动化，它的实施方式一般有两种：

• 一种是远程推送指令，目标系统接受后直接执行
• 另一种是在目标系统部署API或Agent，接收到联动需求后执行预置指令

前者相对灵活，但是数据安全平台需要集中管控大量系统和工具的账户和权限，这样容易引入新的安全风险——如果平台自身被恶意控制，那么它可能成为继续发起大范围攻击的跳板；后者只能执行提前设定好的需求和指令，但是通过合理的访问控制措施，可以大幅降低利用API或Agent执行非预期操作的风险。

尽管技术控制模块可以有效提升数据安全管控的工作效率，但是建议在数据安全团队发展初期谨慎启动相关的建设工作。由于涉及各种不同类型及不同用途的系统和工具，联动机制的调研、设计、开发、调试和推动通常比较复杂和困难，不仅需要投入大量的时间和资源，而且很容易因为某个环节的失误或故障导致业务团队对数据安全工作失去信心甚至建立敌对情绪。因此，技术控制自动化的工作应该考虑安排在数据安全团队在企业内部被基本认可，并且具备成熟的开发和运维能力之后再酌情启动。

4、账户权限控制

权限控制可以充分地结合资产识别、流程审批和外部联动模块，实现大部分常见系统中的数据授权自动化。

具体的实现逻辑是在流程审批通过之后，根据流程中申请的数据内容、权限需求和使用期限等信息，通过外部联动能力自动创建、修改、禁用和删除指定账号对于指定数据的权限。除了直接的数据审批流程，数据安全平台还应该与人力资源系统进行关联，及时跟踪员工的转岗、停职和离职等岗位变化，并且针对相关人员的数据权限及时做出告警和变更。

如果账户权限涉及加密数据，那么密钥的管理和分发工作可以放在授权环节一起执行。但是对于非永久性的加密数据授权，需要充分考虑直接分发密钥的风险和后续的密钥更新和维护成本，毕竟在大多数数据应用场景下，因为某个账户权限过期就更新密钥并重新加密所有数据的设计并不合理甚至可能不具备可行性。解决这个问题比较合理的方式是在数据密文和用户之间建立一个中间接口层，数据解密由这个中间接口层来完成，用户在流程审批结束后获得数据安全平台分配的临时令牌，中间接口层通过验证用户身份和临时令牌的有效性决定是否向用户返回解密数据。

展示层

展示层是数据安全平台中直接面向用户的部分，主要由用户界面、管理后台和推送信息三部分组成。

• 用户界面面向企业全体员工和其他相关人员，至少需要提供制度浏览、流程审批、员工知识库以及其职责范围内的事件跟进和资产查询等功能。
• 管理后台则是向数据安全团队成员提供管理工具以及平台本身的运营和维护功能，包括但不限于资产梳理、制度修订、流程配置、基线制定、规则维护、异常提示、告警配置、平台权限管理和日志展示，另外还有一些基于统计分析的结果和决策数据。
• 推送信息是管理后台的补充，它可以通过邮件、IM消息、短信或电话的方式将异常提示和告警信息及时传递给数据安全团队相关成员，以便快速启动应急响应和事件跟进，而不是需要7×24小时盯着管理后台里的数据界面。

外部接口层

接口层则是数据安全平台中面向其他系统和工具的部分，根据不同外围系统和相关团队支持力度的不同，外部接口的类型、数量和实现方式也可能存在差异。

如果外围系统相对单一或者各业务方积极配合，数据安全平台可以考虑设计一系列标准化的输入、输出接口，并推动业务方按标准传入和接收数据，这种方案有助于维持平台的简洁性并降低开发和维护成本，但是需要业务方承担一定的开发改造成本。

相反如果外围系统构成复杂或者推进阻力较大，那么数据安全平台可能需要针对不同的系统或工具定向设计和开发专用接口，这种情况下，应该优先接入那些风险更大、部署更广的系统和工具。

另外，如果企业已经部署SSO、SIEM等集中管理工具，数据安全平台也应该统一集成。