2022年安全架构总结以及2023安全方向展望

（特此声明：此研究仅仅是个人研究行为，获取的信息也是公开情报获取）。

其实很多安全架构都是一点点的“进化”、升级迭代。从应用微隔离到全链路数据追踪到全程票据，都是安全架构的演进。应用微隔离主要解决的是大内网的网络横向移动的入侵爆炸半径R的范围，数据安全全链路追踪是为了看见和掌握数据流动的安全，最终的全称票据，让企业的核心数据访问全程带上访问凭证，让数据泄露的范围降低到最低，真正从安全架构层面、应用层面来解决对应的数据外泄风险。

针对全程票据的设计细节，本篇文章也进行最核心部分的设计思路透出，让更多企业可以在核心、关键的核心基础设施应用和系统上展开落地。核心票据的架构图如下：首先从用户终端开始登录，这个时候有各种对应的身份验证手段，包括QR扫码、OAuth2认证、账号密码认证等；认证通过之后到凭证验证服务器验证凭证有效性，验证有效性之后，反馈对应的Ticket票据给到用户终端；用户终端使用Ticket票据来访问对应的中间链路的服务器，包括中间件、应用服务后台等，最终携带着Ticket票据访问核心数据服务器，核心数据服务器根据Ticket的权限和来源颁发最终登录用户自己可以访问的范围内的数据反馈到客户端，最终完成整个全程票据访问的全链路隐私和数据安全保护访问过程。

首先通过SDK的方式进行接入，例如PB（Protobuf）的描述部分是（过滤了部分字段，只保留最核心的PB模块）；通过统一的RPC接入平台，携带对应的VerifyTicketReq的请求来进行中心化验证，看整个票据是否具有对应的权限。本实例是最简单的一种实现，例如某些电商场景、支付场景还有对应的关系链，需要首先验证对应的A和B的关系链之后，才可以通过A具有B的票据，才能访问B的一些数据；另外对于票据的设计也根据业务的场景有所不同，例如票据体包含了唯一的UUID Request ID用户来跟踪请求，鉴权体（根据业务的不同和场景的不同有所不同，例如员工的、用户的等不同形式），鉴权方式采用什么样的方式进行鉴权，是支付关系？还是单用户场景等；加密方式，采用什么样的加密算法。过于复杂的一些设计后续如有兴趣的可以单独讨论沟通细节，相信这个落地趋势会在国内的关键基础设施和高安全等级的系统逐步开始规划、设计和落地。

message VerifyTicketReq{    optional string busiessprefix = 1;          // 业务描述    optional uint32 judgediffuin = 2;           // 验证票据    .......
}
message VerifyTicketResp{    optional int32 ret = 1;    optional string err_code = 2;}

云安全的最终宿命还是最终解决客户的数据安全问题而生的。云安全发展了这么多年，从最开始的关注云产品安全（虚拟化逃逸、多租户隔离、越权等）和云上租户的安全（提供云上安全的纯净度，让整个云上客户享受云安全的福利，普惠云安全）到后来发展到关注云上数据安全（包括发展如日中天的云数据安全中心、云上分类分级、云DLP等等能力），再到现在和未来2-3年要发展的Privacy By Design默认隐私安全。这些路径的发展，其实也是有一根核心主线的。这个主线就是云上的看见能力不断提升。

上图是微软新发布的隐私安全产品Priva，今天不重点介绍微软家的产品。今天还是重点看一下Privacy By Design的一个发展方向的探讨。首先在数据源方面，支持包括终端、大数据、应用日志之外，还应用扩展到“混合”办公的多个领域，包括IM聊天工具例如微信、Microsoft Teams、钉钉等；邮件的附件和内容体；云存储例如云盘、OSS、钉盘、企业微信盘、Micrsoft SharePoint等内容管理平台；另外一个问题就是这些数据除了看见存在哪里？是否合理的存储？是否有加密策略？是否流动过程是安全的之外，还可以针对SaaS导致的数据共享泛滥的问题进行解决。终局也就是说未来云上、线下、混合云、多云的各个领域的数据理论上是都会看见、保护、运营的闭环的。在未来2-3年，越来越多的云产品会支持发现个人隐私保护方面的发现能力、数据流动、数据权限开放过大而导致数据泄露的场景的覆盖。也就是说未来，企业上云之后个人隐私数据会第一时间知道在哪里保存的？保存的是否是合规的？是否有数据滥用外泄的风险？想想这样的隐私安全保护，客户的信任和数据安全风险的治理是不是上了一个更高的台阶？让Privacy By Design成为云的默认安全属性。

PS：（构建这样的看见能力，当然是需要客户进行授权的，通过授权的方式来获取对应的企业的相关数据，未来云操作透明、云审计公开、云运维可全程自证会成为构建Trust Cloud的必经之路）。

在讲解数据安全大图之前，还是简单讲一下今年对数据安全的一个理解，由于今年的工作内容的原因和平时的一些演练角度来看，国内外做数据安全的方式上还是各有不同的。例如咨询行业、制造业比较关注终端的数据泄露，通过Symantec、McAfee、ForcePoint等产品来做对应的知识产权的保护，对于文档、等非结构化的数据做DLP防泄露；例如在国外云厂商很多做数据安全的，例如Google提供SaaS化的DLP API的能力来整合数据安全产品；Azure推出Priva+Purview来评估云上的数据安全和隐私保护；Azure同时也推出了MIP相关的信息保护产品线，用来保护自己生态内庞大的文档、邮件等数据流转、个人隐私相关的治理；另外还有越来越多的企业为了可以实现"数据不落地"的理念慢慢往RBI、VDI方向上走；云上也针对用户的数据安全提出来了机密计算、可信计算、隐私计算等领域；数据安全是一个很庞大的体系，其实很多数据安全的解决方案都是根据实际的业务场景演化而来的。所以啰里啰嗦这么多，还是要提一嘴，上面的数据安全体系大图并不一定是最好的、最理想的数据安全体系，适合自己业务场景的，能解决自己企业数据安全风险的架构才是最适合自己的，别人的只能拿来做一些参考而已。

好了，不多啰嗦，开始分解这个大图。

1、数据治理框架：这个不用过多的描述，相信大家比我更清楚的理解行业监管需求、国家法律法规、企业业务要求等；这里有两点要说一下，很多时候数据安全事件的处理和处置很难以奏效，或者有些时候很难在企业内部形成一致，其实这个时候红线、规范就非常重要了，红线设计的好坏直接影响到安全的信誉，以及安全在企业内部的阻力等问题，好的红线设计可以让安全水位得到质的提升，在设计安全红线的要充分考虑业务部门的感受，尤其是红线导致的奖罚措施也比较重要，要得到业务部门的充分理解和认可也是一件挺不容易的事情；第二个就是红蓝对抗，在对抗过程中会发现各种各样的安全问题，这些安全漏洞，就成为了企业数据安全治理方向的指引明灯，尤其一些企业目前建设了紫军、数据窃取蓝军、数据高仿真等岗位和角色，针对数据安全风险角度有了更多的输入，这样更有利于数据安全顶层设计的一些建设和输入；

2、数据安全治理体系：企业安全制度制定的主要目的是有法可依，有章可循，先定好企业内部规范，在处理很多事件上会省不少解释成本。企业制度包括数据安全总章、数据分类分级标准、个人信息保护规范、数据跨境治理规范、外包管理等等内容；这里的企业安全规范治理制定的好坏的唯一评价标准，就是后续的巡检能否落地，企业的规范如果仅仅是一堆废纸，那也就失去了本来定义的价值。所以好的企业安全规范，是可以通过安全巡检能力来持续的、自动化的、不间断的验证能力和规范的水位的，例如定义了企业制度是没有终端安全不入网、DLP策略的有效性验证、数据分类分级的自动化验证、自动化的验证数据外发渠道策略是否有效、验证云盘上传可以发现，另外可以通过数据蓝军、紫军来构建“日日练”的效果。有了规范制度，也能巡检对应的安全水位了，下面要做的就是针对出现的各种问题的交付SOP了，例如数据外发策略失效了，那对应的处置手段、升级手段到底是什么？我见过好的SOP是非常详细的，可操作性极高的，而且明显可以让一线的人按照手册就可以快速解决的；最后通过不断的优化来完善整个数据安全治理体系的运转；

3、构建数据安全能力层：通过威胁情报、数据泄露CASE输入、数据安全风险评估角度，分析出对应的数据安全风险，其实数据安全风险也会随着时间的推移而变化；有了这些输入之后，就开始构建对应的能力和解决方案，包括数据发现（分类分级、全覆盖等可参考下面的【2022总结-Privacy By Design】的思路来进行覆盖）->数据异常检测和保护->数据防泄漏；另外还有一层非常重要的身份层，可以参考【2022年总结-端到端身份防御架构落地】章节。

4、数据安全运营：针对构建的安全能力，需要对应的数据安全运营手段来不断地分层运营，包括数据安全事件的处置、溯源，数据安全能力的推进等；

5、度量指标：有了运营的持续运转，需要良好的度量指标体系来衡量整个数据安全的水位，这些指标是非常关键的，包括运营指标、能力指标、响应指标等各个维度的数据；数据安全度量体系是驱动整个数据安全良性运转的重要“北极星”指标，有了这些指标才能更加良好地推进数据安全往前发展。