网络安全、数据安全是当下互联网环境中十分重要的命题，那么在云计算场景下，我们要如何保证数据安全？在本篇文章里，作者便介绍了云计算数据安全的解题思路、数据分布式存储等方式或方案的可行性，一起来看看吧。
前言
自70年代人们通过电话线连接局域网开始，网络安全的威胁就随之诞生了。彼时，即便是在IBM的DES加密协议、McAfee的杀毒软件、Avast的VPN服务等强大的安全系统保护下，网络犯罪的行为仍不断演变，以至于今天的勒索软件、恶意软件以及数据非法滥用等，对个人、企业和政府带来了各种风险隐患，甚至巨大经济损失。
(相关资料图)
体现在企业财税管理层面，涉税数据作为全新生产要素，不仅是税务机关的征管资源，也是助力企业数字化转型的重要驱动力，其安全性、隐私性和产权管理等，是数据交换共享、价值挖掘的必要前提。尤其是在“数电票”时代，虽然纳税人可以享受更便利的涉税服务，但同时也面临着数据安全流转和自主可控的挑战。
根据相关政策趋势，税局可能会指定第三方电子发票服务平台为纳税人提供“数电票”基础和相关增值服务，他们通过云服务平台为大量纳税人提供服务，从而加速“数电票”的推广。但是，一个纳税人因收票业务往往会使用多个平台，如此让本身就分散化、多地部署的云平台，又因业务数据的不集中、不受控等，再加上第三方平台本身的监管成本很高，导致这种服务模式下的涉税数据安全性管控非常困难。
一、云计算架构的利与弊
纵观软件架构的发展历程，最开始是桌面软件，后来发展为C/S（客户端/服务器端）架构，虽然它的两层结构具有安全的存取模式、响应速度快、擅长处理大量数据等优势，但是因系统维护、升级的成本高昂，难以进一步的数据拓展，更难与其他系统交互，故此通用性较差，仅适用于小型的局域网。
随着互联网高速发展，C/S架构已无法满足全球网络的开放、互联、共享的新要求，于是就改进为B/S模式，即浏览器/服务器结构。即便B/S架构的具有零客户端、低成本、分布式强、开发简单、维护方便等诸多优势，但仍然无法完全替代C/S架构，尤其是在响应速度和图形计算方面，往往花费很大的成本和努力，也难以达到C/S架构的效果。
随着服务端计算和处理的数据越来越多，作为B/S架构的进一步改进和延伸，云计算架构通过IaaS基础设施服务、PaaS平台服务、SaaS软件服务，为不同的租户提供按量付费的灵活性方案。尽管云计算架构的优势更加显著，比如价格低廉、部署快捷、扩展性强、功能丰富、操作方便、开箱即用等，但仍然无法遮掩异构系统的数据互联互通（云服务商之间存在数据壁垒，扩展阅读：《》）、数据滥用（利用用户数据产生的收益是云服务商的收入来源之一，扩展阅读：《》）、数据加密等方面的不足。
那么，除了多平台数据壁垒和用户数据主权丧失的弊端外，云计算架构的数据安全保护又存在怎样的难题呢？
二、云计算数据安全的解题思路
随着软件架构的进化和升级，数据安全的概念也在信息化和数字化的高速发展中发生了变化，其大致可分为三个阶段：从早期的数据库和文件系统安全，到数据生命周期的安全，以及现在我们常谈的数据基础设施和数字化业务流程的数据安全（数据采集、传输、存储、使用、交换、销毁等全周期的保护）。
所以，作为当前数字化业务发展的主要载体，云计算下的数据安全变得尤为重要。因为它的数据分散在不同的机器和存储设备中，包括服务器、个人电脑以及无线传感器网络和智能手机等移动设备，其数据安全比传统信息系统更为复杂。
云计算的数据安全首要问题是数据隐私、数据保护、数据可用性、安全传输[1]，这些环节无一不依赖密码算法和密码协议等网络信任体系来构建基础，并基于密码的保密性、完整性、认证性和可用性等基础功能，实现数据所有权、使用权，让数据安全可靠、自主可控地流转。
但是在实践中，由于云租户对密码应用的需求多样化，采购密码服务的意识不足，导致运营商对密码资源的投入积极性不高，尤其是面临分散化、多地化部署的情况，各节点建设各自的商用密码管理系统，不仅重复建设造成资金、人员和设备的严重浪费，也造成了认证上无法实现互联互通。
总体来说，云计算场景应用商用密码的两大特点[2]：一是密码支撑能力不足，主要体现为专业设备和技术人员专业能力方面，使其发展不均衡，商用密码的效用没有发挥出来，更不用说未来扩增的业务量支撑力了；二是传统的密码基础设施技术架构体系难以支撑新业务快速发展，亟需要构建一种新模式下的密码云服务架构，为云平台所有业务系统提供多租户的密码服务。
为此，我们提出了一种数据分布式存储和应用的方式，通过建立一个由各类密码设备和基础密码服务单元组成（包括云服务器密码机、签名验签服务器、CA认证系统、数据加密系统、密钥管理系统等，以支撑虚拟化的密码原始服务能力）的统一基础密码计算服务中心（下文简称：中心），一是避免各个云服务平台的重复建设，弥补参差不齐的数据安全基础设施，二是建立租户和云服务提供商之外的第三方监管机制，既能提供可见性来保障数据的完整性，也一定程度监督云服务商对租户数据的滥用，避免现在普遍存在的监守自盗现状。
三、分布式方案的可行性
无论以上描述的现状，还是当前普遍存在的云服务商对租户数据监守自盗的现象，导致租户愈加不信任云提供商，而云服务商也几乎不可能消除潜在的内部威胁，因此用户直接将他们的敏感数据直接存储在云上是非常危险的。即便是在加密措施下，云服务商仍面临密钥管理问题，无法支持查询、并行修改、细粒度授权等复杂需求。
此时，有人提出了“同态加密”体系[3]，即保证密文代数运算结果与加密后的明文运算结果一致，整个过程不需要解密数据。理论上，该技术确实可以解决云端数据与数据操作的机密性问题，但是该加密系统涉及计算非常复杂，储存成本也非常高，离真正的应用还很遥远。
不过，数据的分布式存储却是云计算的一种很有前途的方案。为保护数据和确保完整性，将数据分成几部分，通过数据块的加密后单独存储在多个云或云数据库中，以此增强针对不同类型攻击的安全性。[5]
该研究成果与云服务的分布式方案的理念如出一辙。不管是刻意将数据分成多个部分来实现最大的安全性，还是因业务需求造成的数据分散在多个云服务平台，这些数据块都将经过加密生成密文进行流转和存储，而密钥存储、调用、更新、迁移等服务都由中心的密钥管理系统处理。如此，只有用户才真正拥有数据的各项权利，云服务平台只会在授权的情况下才能使用，并且是不可见的。
在此方案中，你会发现一个关键点：建设和管理中心的角色必须是有公信力的、权威性的、不涉及利益冲突的监管机构，或者是其唯一授权单位。体现在电子发票的云服务平台，自然是国家税务总局本身或者唯一授权了。
四、电子发票服务平台的实践
前言中已经大致介绍了“数电票”时期将仍可能会继续采用第三方电子发票服务平台的模式，为纳税人提供发票的基础和增值服务。显然，所有第三方平台都建设各自的商用密码管理系统是不现实的，从监管和推广的角度看，怎么取得用户信任第三方平台，不会对隐私数据的滥用，是亟待解决的问题。为此，国家税务总局在指定一些第三方服务平台的同时，也不得不委派相关部门管理监督。
由此，在完全不改动现有系统的基础上，建议税局指定一个超级第三方为统一基础密码计算服务中心，为各个平台提供统一的密码服务（比如封装API、可信身份认证、密钥管理、数据加密、数据分析等），通过全生命周期的加密方式，让第三方平台无法碰数据，同时也担任用户和第三方平台之外的监管机制，以确定谁可以使用或者谁更改了数据，保障数据的隐私性和完整性。最重要的是，在安全的基础上，中心可以提供更多“数电票”的基础设施，能够加快“数电票”的推广，并且构建了一个开放的应用生态，从而为纳税人提供更好的税收服务。
当然，数据安全治理体系仅靠技术支撑是无法实现的，中心还需要健全的安全管理体系，以及成熟的安全运营体系[5]。如此就要求这个中心要推动建立数据安全的标准，以此规范流通在各方、不同业务场景的数据，从而避免敏感数据的泄露。同时也要依据相关法律，界定数据权属问题，让数据有序且可控地流转。
不得不承认，在当前的复杂环境下，只有背靠一个超级公信力的“中心”，才能做到去中心化。该方案本质就是通过分布式构建一个去中心化的第三方电子发票服务平台体系，并提供统一的基础密码计算服务，有效降低云服务的安全设施投入成本和规范云服务商的数据利用，从而建立服务商与消费者的信任关系，让更多数据和信息传输到云上，以实现可信的数据共享、促进数据资源高效利用。
参考文献：
1. 孙云川 张俊生 熊永平 朱光宇 云计算中的数据安全和隐私
2. 彭浩楠 唐明环 查奇文 王伟忠 王聪 云计算场景商用密码应用研究
3. Gentry C. A fully homomorphic encryption scheme [Ph.D. thesis] 2009 Stanford University
4.Pagano F., Pagano D. Using in-memory encrypted databases on the cloud Proceedings of the 1st IEEE International Workshop on Securing Services on the Cloud (IWSSC ’11) September 2011 30 -37
5.雷蕾. 数据安全现状与发展趋势研究[J]. 信息通信技术与政策, 2022,48(10):69-74.
本文由 @不见悲秋客 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
责任编辑：
标签：
