作者：雄安新区首席网络安全顾问 陆宝华
从上个世纪八十年代，美国军方出台第一个计算机系统的安全标准以来，无论是哪个标准体系，都是把数据作为资产来进行保护的，这当然是对的。资产放在保险柜中，相对来说是最安全的，但是将数据仅仅作为资产来进行保护，这只看到了数据的当前价值，而忽略了数据的未来价值。数据的当前价值，会随着时间的推移，逐步的贬值。这是从资本的价值推演过来的。实际上，数据的自然增值并不多见，但是贬值往往经常出现，如一个涉密的数据，当这个数据解密后，它的价值也就不存在了。
将数据作为生产要素，如同将资金作为资本而进行投放，使其能够增值。当然，数据与资本还是有相当大的区别的，数据可以复制，而资本不能。
把数据作为生产要素，其安全风险也增大了，并且会比较复杂。那么把数据作为生产资料，是不是数据的资产属性就完全的丧失了呢？也是不尽然的。如资金在没有作为投资资本之前，资金还不是资本，对资金的保险柜式的保护还是非常有意义的，另一方面，在作为资本时，他仍有资金的属性。同样道理，数据在没有作为生产要素之前，它仍然具有资产的属性。
无论是作为资产，还是作为生产要素，对数据保护的总体策略是：保证对数据正确的授权操作都是没有问题的。
这一策略包含了三层含义，一是对数据的操作要经过授权；二是授权机制是正确的；三是授权机制要有保障。
从这三层含义我们进行分析，授权，和授权机制的保障对于资产也好，还对于生产要素也好，是一致的。但是对于授权的正确性，数据作为资产，和作为生产要素，存在的区别是比较大的。
一、作为资产的保护思想
作为资产时，正确的授权应该考虑这样的一样因素：
1.1主体操作授权
对一个主体的操作授权，不应该构成对其他主体合法权益的侵害。这一点并不是完全可以做到的，我们往往在对主体的授权时忽略了这一点，如对于C2级这样的操作系统，存在超级用户，而超级用户则会有超级的权力，并且他的操作行为，他是可以删除的。还有，在一些云平台，运维人员的授权往往为了维护上的方便，授予的权力过大。
所以要执行最小授权的原则，所谓最小授权，就是根据该主体所要完成的任务，来确定其相应的权力，不能超出完成任务的权力。
1.2分权制衡的原则
对某一主体的授权，不应该将利益相关的任务交由一个人来完成，也不能由两个利益有关联的主体共同来完成利益相关的任务。对任何的授权行为都要有相应的监督机制，并且这个监督机制是不能被操作人员所破坏的。
1.3符合被保护客体的安全需求
1.3.1安全属性的要求
我们知道，数据的安全属性有机密性（不泄露给未授权的主体或其它实体）、完整性（不被未授权的改变）和可用性（保证授权人使用）。在这三个属性中，机密性和完整性是可用性的基础。一个数据被破坏了，那么它的可用性自然也就消失了，同样一个数据泄露之后，我们再使用，也会导致严重的后果。可用性的另一个基础是，系统的可用性。所以，从保护数据本体的角度来看，我们只要保护了数据的机密性和完整性就够了。在国际标准《CC》（ISO--15408）中，对用户数据的保护策略中，也只提到了保护数据的机密性和完整性。
强调数据的安全属性，是想告诉相关的人员，不同的数据具有不同的安全属性要求，同时不同的安全属性，其保护策略是不一样，甚至是冲突的。本文，不想就数据安全属性与保护策略进行详细的讨论，这本来是一个老话题。只举一个例子，在等级保护的要求中，有一条功能要求：“剩余信息”的保护，这一条要求包含两个方面：一是用户数据在删除后，不能恢复，无论是在内存中还是在外部存储器中；另一方面是当一个用户从系统应用中退出后，下一个用户不应该查看到前一个用户的所有操作信息，包括他的登录帐户和相应的认证信息。对于后一个方面，是属于TSF（安全功能）数据，与用户数据的安全属性无关，我们不讨论。对于前一个方面来说，用户数据删除之后，是不能被恢复的。
对于保护数据的机密性来说，这一条非常重要，一个机密数据被删除后，又能被其他人恢复出来，那么数据肯定就泄密了。
但是对数据的完整性来说，这一条是有害的，当一个数据被误删除之后，如果利用回滚技术（或者是恢复工具）进行恢复，那么就没有损失，但是如果采取的“剩余信息”保护策略，每个删除都相当于“粉碎”，那么再恢复就没有可能了。完整性就被破坏掉了。
应当说，所有的数据，都需要进行完整性保护，但是并不是所有的数据都需要机密性保护，对于需要机密性保护的数据，要从访问控制策略上优先执行，因为机密性还有一个实时性的问题，一旦数据泄露了，那么，再想补救就来不及了。而数据的完整性保护对实时性的要求并不强烈，所以，我们是可以补救的。
对于机密性保护访问控制策略，必须执行BLP模型，即便是自主保护类的，也只能采用属主型，而不能采用层次型或混合型。
对数据的完整性保护访问控制策略则可以使用Biba模型，或者是其他的完整性保护模型。同时，对于完整性保护强度要求较高的数据还要考虑，完整性校验技术的使用。
再说明一下，BLP模型与Biba模型，在访问控制策略上是相反的。
在等级保护过程中，本来基于数据安全属性的访问控制是等级保护的核心，但是在十余年的等级保护的实践中，这一核心被相当多的人给忘记了。
1.3.2安全形态的要求
这里包含了形与态两个方面，形态不同保护的方法是不同的，尽管保护策略需求相同，但实现的方法则是不同的。
形就是指数据的类型，主要是看数据是结构化数据还非结构化数据，还是半结构化数据，对于结构化的数据保护，操作系统、关系型数据库都提供了相应的保护机制（我们先不说这些机制的可靠性）。而对于非结构化数据、半结构化数据，系统层面还没有给出一个相应的保护机制，这就需要我们用打补丁的方式，来实现我们的访问控制策略。
态是指数据当前所处的状态，笔者把数据分为三种状态，一种是静态的，这是保存在外部存储器上的数据；另一种是动态的，是在信道中的数据，这个信道即包括了计算机主机之间的通信信道，也包括了在计算机内部的从外部存储器到内部存储器之间调用时的信道；第三种状态是暂态（笔者自定义的），是指数据在内存当中，是正在处理的数据。
在这三种状态中，安全的需求是不一样的，保护的方法也是不一样。
对于静态数据，我们防范的是非授权的访问，包括打开、复制、传输、读取、写入等等操作。计算环境中的访问控制策略，是能够解决这一问题，只要我们能够从基于属性的访问控制入手，这一问题解决并不难。
信道中的数据保护，对于计算机主机之间的通信信道，我们主要防范的是数据被窃听，被插入，重放等。我们可以用加密、数据完整性校验等手段来解决。对于计算机内部信道，也有信息流控制手段（尽管我们用得不多，许多标准中也没有强调）。
对于暂态数据，我们要防范的则是木马等间谍软件的窃听和复制。一些木马程序，自身是需要保护的，所以在许多情况下它是不活跃的，但是监听内存则是这一类间谍软件最方便的窃取方法。并且在数据从静态到暂态的过程，还可能被木马程序诱导，重要的数据被钓鱼。
1.3.3安全强度的要求
安全强度的要求是由资产自身的价值所决定的，这也是等级保护的基本思想。当年某位大专家就质问，对于云来说，还需要等级保护吗？给定几级？实际上他没明白资产价值的不同，保护强度应该不同这样浅显的道理。等级保护2.0已经较好的回答了这一问题。
等级保护的定级，就是依据数据的资产属性这一点，当然也有系统的服务功能要求。根据这些被保护对象一旦发生安全问题后，会侵害哪些客体（公民、法人自身的利益；公众利益和社会秩序；国家安全），会侵害到何种程度，来确定相应的信息（数据）和信息系统与基础信息网络的安全等级，对于今天这样的网络环境来说，是应当扩展到一切网络。同时，从我国的第一部网络安全的标准《计算机信息系统安全等级划分准则》（GB17859--1999）就强调了不同的安全强度需求，要按不同的安全等级进行保护的思想。
1.4时效性
任何一个保护策略不应该是一劳永逸的，必须根据系统的变化、数据本身的变化，系统所面对的应用人员和维护人员的变化也要进行变化。
比如一个明确宣布解密了的数据，就不应该进行机密性的保护，至少机密性保护的强度要比原来没解密之前要降低；
一些人员完成的相应的任务之后，就不应该存在相应的授权，特别是对于维护人员的变岗，应急响应人员在完成的应急响应任务之后，测试（包括渗透测试）人员在完成了测试之后都应该解除授权。
系统的变更，也会带来授权的变化。
等等。
二、数据作为生产要素的保护思想
笔者在2016年为贵阳搞大数据安全时，曾经思考过一些问题，如对于数据挖掘，原来的基于数据安全属性的访问控制机制失效了，可是如果没有相应的访问控制机制，原数据不仅会被挖掘，同时也可能原材料都被复制了。
真正对这个问题比较系统思考的是全知科技（杭州）有限责任公司的方兴先生，他明确提出了数据作为“生产资料”的保护需求和方法。
中共中央、国务院2020年3月30日公开发布了《关于构建更加完善的要素市场化配置体制机制的意见》（以下简称《意见》），在意见的第六章中就数据作为生产要素提出了明确意见。这不能不说是对传统将数据作为“资产”进行保护的思想的一个挑战。
作为生产要素的数据，即有劳动资料的属性，即在生产过程中要运用的物质资料和物质条件，同时也是劳动对象，即对数据本体进行加工和再生产。
数据作为生产要素的保护，其保护的总体思路仍然是“保证正确的授权操作”。但是，如何能做到“正确的授权”是需要下一番功夫的。
2.1数据的生产场景分析
数据作为生产要素形成产品可以分为两大类，一类是将数据作为物质资料和物质条件生产的实体类产品；而另一类则是再生的数据类产品，所以组合后可能会有四种基本情况：
一是输入数据，数据不改。数据直接服务于生产，包括对传统产业的改进，或者是直接作用某一种传统的产品。而这种产品的产出，并不会对数据产生任何的改变。在这样的情况下，数据仍然是资产的属性，不过是对数据的直接应用罢了。
二是输入数据，数据改变。数据应用到生产，作用于某种产品，同时根据生产过程中的反馈，导致数据也要发生修改。从这一点来说，数据仍然可以考虑其资产的属性，等于是修改数据的权限，赋予了生产过程。生产过程是主体，可以利用智能的手段，或者人工的手段对数据进行修改。
三是输入老数据，生成新数据。要通过对原有数据综合、分析、挖掘等，生产出新的数据（包括预测分析、语义引擎、聚类、分类、统计、可视化、描述性分析、诊断性分析、指令性分析等的结果），而这些新的数据带来的价值的增殖。
在这种情况下，对原有数据就不能简单只看到数据的资产属性了，原有的数据，既有其资产的属性，也有作为生产原料的属性，同时还有劳动对象的属性，其保护思路是要改变的。而新生产出来的数据，则仍然具有资产的属性。
四是数据共享与协同，数据共享不产生新的数据产品，也不会生产出其他的产品，但是可以避免重复性的工作，提高了效率，降低的费用。社会成本的降低也应该认为是增值价值的，减少投入就是收益。此时的数据仍然是资产的属性。
我们重点讨论第三种情形下的，“授权的正确性”
2.2数据本身的安全需求分析
不同的生产目的，会导致对源数据和数据生产后的产品，所面临的风险是不同的，授权操作的正确性与这些生产场景是密切相关的：
从风险分析的观点出发，与风险相关的三个基本因素是：资产的价值、威胁和脆弱性。
2.2.1数据资产价值分析
数据的价值，决定了需要对这个数据进行保护的安全强度（等级）。
作为生产要素的数据，在安全赋值时，既要考虑数据的当前价值，还要考虑这些数据的增殖效应，而这个增殖效应是未来的。并且这个增殖效应是有不确定性的，由于运用这些作为“资料和条件”的劳动力（或劳动力团队）的知识水平、分析判断能力、使用的加工工具等因素的不同，增殖的结果往往会不同，其价值当然也不相同。
并且这个价值的评估，不应该简单仅仅依赖于数据的保密性、完整性，还要考虑这个增殖的结果本身的其他价值，比如对国计民生的意义，对国防的意义等。如何来衡量这个未来的价值，虽然需要结合到具体的数据集群，劳动力集群等进行分析评估，但是最终应该给出一个相应指导方法来才行。
在将数据作为资产来保护时，我们是对单个数据进行赋值的，而对于作为生产要素的数据往往是一个数据集群，单个数据的价值并没有那么大。
数据的增值价值，还体现在共享这些数据劳动力（或者是劳动力团队）中。有一种说法，数据越共享，产生的价值越大。我们先不讨论这一命题，需要分析的是，数据共享出去以后，共享团队所产生的增殖价值，对当前团队的意义是什么，对当前团队的利益是增加，还是受到侵害。这就不可能不涉及到共享范围和对共享对象的评估问题了。
2.2.2数据威胁分析
作为风险的第二个因素，是对威胁的分析，威胁源与应用的场景是密不可分的。对于作为资产进行的保护，我们可以用隔离的办法，将相当一部分威胁源隔离出去。而对于作为生产要素的数据来说，这种隔离是不容易实现的。并且由于共享团队的加入，会导致威胁源的攻击入口增加。
2.2.3数据脆弱性分析
作为风险的第三个要素，是自身的脆弱性问题。对于传统的结构化数据保护，由于数据的量小，一般一台独立的服务器，及这台服务器上的操作系统、数据库和应用程序所构成的计算环境，可以提供对这个数据的基本保护（授权机制）。但是对于作为生产要素的数据，会有大量的非结构化数据，而这些数据首先是“量”大，某些应用数据已经达到TB级别，未来可能会达到PB级甚至更高，此时，一台服务器及相关的计算环境是无法对这个数据进行基本保护的。同时，生产的过程，数据处于流动状态，动态化，多用户都构成了相应的脆弱性。
我们对数据作为生产要素存在的风险，应该说认识还是初步的。更多更细的问题，还没有认识到。
2.3数据技术衍生的安全风险
数据用于生产，是可能“生产”安全风险，主要是利用已知条件，推导出未知因素。主要是两大方面，一是个人隐私的泄露问题，另一类是敏感信息的泄露。
利用已知推导未知是大数据的普遍的分析方法，这也是一个生产过程。
利用导航定位数据为一个人的活动进行画像，并不是一件困难的事情；通过手机联系人的关联，很容易分析一个人的朋友圈等。如果这些仅仅是为了商业利益，并且有适度的管控，问题还不大。但是，如果被恶意利用，就可能导致重大的安全问题。有人说，“把大数据利用得最好的是诈骗犯”是有一定的道理的。
同样利用已知的公开数据，是有可能推导出一个机构的未知数据的，如果是这个机构的敏感数据，那么对这个机构来说威胁就大了。
2.4负信任的问题
【参考资料1】中，提出了负信任的问题，这是一个针对近期被炒的“零信任”概念所提出的，笔者并不认为“零信任”是新理念，而认为是在新包装下的正确安全理念的回归。可这个回归，仍然还是将数据作为资产保护的基础。
负信任的提出者认为：零信任体系是我信任我赋权的主体对象，但我无法信任当前登录的这个用户就是我相信的那个主体，因此我需要结合很多维度的信息来识别对象，比如结合登录设备指纹，用户的登录方式，同时根据登录场景和工作需求给与用户最小化的授权，并在以后各自变化中持续验证这个主体对象。负信任是对零信任的进一步深化。
而“负信任”是因为在生产过程中，从效率和成本角度，我们很难将生产交给完全可信的主体对象去完成，很多时候我们必须依赖不那么可信的人来完成我们生产的过程，也就是我必须给予不可信任的对象权限去完成生产，我确定了你是你，但我还是无法相信你，我又不得不用你，因此要以一种“监工”的身份，对主体对象的行为遵从性进行监督，同时还要观察数据对象的各自状态变化来确认安全状态。
数据作为生产资料的情形下，负信任的问题是我们必须面对的。在零信任条件下，我们还可以建立起一个主体对应一个客体的细粒度的依据数据属性授权访问控制机制，而在生产的情形下，这种细粒度的访问是做不到的。
如在数据的挖掘过程中，一个主体面向的是一个数据集群，而不是一个单一的数据客体。这个数据集群，虽然各个客体都有自己强调的安全属性，但是为了挖掘的实现，我们不能依赖于这些数据的属性，而必须将这些数据一块交给一个挖掘主体。而这个主体，正常情况下所关注的，应该是这个数据集群中的某些具有特征信息的量，而不是每个数据客体中的全部。
同样，对于一个数据集群，所面对的也不是完成某一任务的单独的一个主体，单一任务就可能面向多个主体，同时还可能面向多个任务。
在这样的条件下，提出“负信任”的概念是有合理性的。
三、结语
在第二章，虽然给出了数据作为生产要素的情形下，影响到“正确授权操作”的各个因素，但是并没有给出正确授权的系统方法。目的是将这个砖抛出，引发大家的思考，一同来解决这个问题。
参考资料
【参考资料1】方兴《数据流动时代大数据风险如何管控》
(https：//mp.weixin.qq.com/s/GPSUEvT7lrP1wIJld-ySrg)
声明：本文来自工业菜园，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
