ico文件怎么生成(图书馆管理系统数据库的表)

第131期

《新技术法学研究》杂志投稿指南

王超毅 上海市联合律师事务所律师

REDHAT RHCA系统架构师

一、引言:MongoDB数据库数据泄露事件

自2016年始,互联网上出现了一波针对MangoDB数据库的勒索攻击浪潮,最新一次数据泄露事件发生在2020年,黑客们发现互联网上有大量无需身份验证即可登录的MangoDB数据库,其中一些数据库中还保存着大量高价值数据。于是黑客们把数据库中的数据进行了加密,并要求受害者支付赎金才能换回数据,有趣的是,黑客们索要的赎金通常为比特币。为此有IT人士针对MongoDB数据库撰文《Don’tuse MongoDB》的血泪控诉。

黑客攻击后索要赎金内容见下图:

ico文件怎么生成(图书馆管理系统数据库的表)

翻译如下:我把你的MongoDB数据库里的数据转走了,如果需要数据的话,请给我0.2个比特币。

那么,为什么会发生数据泄露事件,又缘何会发生针对MangoDB数据库的勒索浪潮呢?想要深入理解这一事件的来龙去脉,就必须对数据库有基本的了解。

二、漫谈数据库

记得刚学数据库那会儿,老师曾推荐一本书《漫画数据库》,日本东京大学高桥麻奈编写,并由株式会社TREND-PRO 制作漫画,是对数据库初学者非常棒的入门读物。但究竟何为数据库,对非计算机专业的读者而言仍会感到非常陌生。

简言之,数据库是一个大生态系统,涵盖了查询、索引、文件存储三大功能模块,类似我们现实中的图书馆,下面笔者就以图书馆为例做简要说明:

我们可以模拟这样的场景,某位读者想去图书馆借阅王泽鉴老师的《民法思维:请求权基础理论体系》,首先会告知图书馆管理员自己需求:我需要借阅王泽鉴老师的《民法思维:请求权基础理论体系》阅读学习,接着图书管理员会告知:请您去法学书籍阅览室XX排XX层寻找,最后该读者在法学书籍阅览室XX排XX层找到了该本书。该例中的图书馆,其实就是一个数据库,里面存储了海量的数据,并且能在查询时迅速索引到对应的数据上。

大数据时代,每天都产生海量的数据,因此数据安全越来越重要。数据库相当于整个大数据产业的基础设施,即存储数据的仓库。如果要创建一个大数据的大厦,那么数据库就像这座大厦的地基,影响数据存储的速度、查询的速度、导出的速度等等。如果数据库不牢固,那么地基不稳,大数据产业的高楼大厦也就岌岌可危了。因此,数据库的重要意义不言而喻。

三、数据库概述

作为互联网平台的核心功能组件,数据库从大类上大致可划分为两类:一是关系型数据库;二是非关系型数据库。

(一)传统关系型数据库

关系型数据库,关系型数据库是指采用了关系模型来组织数据的数据库。简单来说,关系模式就是二维表格模型。主要代表:Oracle(甲骨文)、Mysql(瑞典MySQLAB公司 开源型软件)、SQL Server(微软)。

关系模型是关系型数据库的核心理念。关系模型涵盖如下概念:表格、行、列、主键。本文将通过如下实例,用白话的方式让读者理解何为“关系模型“。仍以某图书馆为例,并假定该图书馆使用的数据库为关系型数据库。

通常情况下,图书馆数据库管理员会建立如下两张表结构:

数据库管理员建立如上两张表格,然后通过输入某位读者的信息,可以汇总并记录这位读者在该图书馆的全部信息;两张表通过读者ID进行关联,读者ID是唯一的标识,通过该标识可以查阅该位读者的全部信息。例如,数据库管理员通过输入读者ID :002,即可以查阅会员李四的信息,以及李四借阅《物权法》的情况。

该标识(读者ID)在关系型数据库中有专门的术语:主键。关系数据库通过具有唯一性特征的主键把各项数据关联在一起,确定主键后,即使诸如姓名、借阅书籍等其它项是相同的,也不会造成数据存储、查询的混乱。

简言之,关系型数据库运作逻辑,就是通过建立多张互相关联的表格,明确列和行的具体内容,确立唯一标识(主键),对大量数据做有效管理及高效查询。

(二)关系型数据库在实际应用中的问题

虽然关系型数据库已在互联网领域得到了广泛的应用,但随着互联网web2.0网站的兴起,传统的关系型数据库在应付web2.0网站,特别是超大规模和高并发的、SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题。

问题一:High performance – 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系型数据库应付上万次SQL查询请求还勉强顶得住,但是应付上万次SQL读写数据请求,硬盘就已经无法承受了。(SQL:结构化查询语言,Structured Query Language,用于存取数据以及查询、更新和管理关系型数据库使用的一种操作语言)

问题二:Huge Storage – 对海量数据的高效率存储和访问的需求

对于知名的大型SNS网站,每天大批量用户会产生海量的用户动态。大型SNS网站每日可产生上亿条用户动态,对于关系数据库来说,在海量的记录表里面进行SQL查询,效率是极其低下乃至不可忍受的。

问题三:High Scalability& High Availability- 对数据库的高可扩展性和高可用性的需求

网站应用中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,数据库往往没法像服务器那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对关系型数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移。

(三)非关系型数据库的诞生

鉴于关系型数据库存在上述问题,关系型数据库显然已无法作为大数据时代下完美的解决方案,此时非关系型数据库应运而生。而作为大数据典型开发框架的MongoDB数据库,就成了非关系型数据库的典型代表,下面本文将就MongoDB数据库作简要概述。

相较于复杂的关系型模型,MongoDB数据库的特征是什么呢?答曰:文档。关系型数据库应用中,须事先定义表结构,操作复杂,查询困难,扩展性也很差。反之,MongoDB数据库用“文档”来存储数据,操作则相对自由和灵活很多。MongoDB数据库文档就像一个大麻袋,任何类型、任何内容的数据都可以往里面装,不像关系型数据库进行数据管理需要受到表结构的严格约束。为便于读者理解,本文通过如下实例说明。

论坛网站后台数据库通常需要:访问者实名、论坛ID、论坛昵称、注册时间、发表内容、评论内容这些数据,两类数据库各自的操作逻辑如下所示:

1.使用关系型数据库管理数据需要建立如下三张表:

2.使用MongoDB数据库管理数据的操作逻辑:

(1)建立两个文档:

(2)文档的内容分别是:

文档一:张小三—数据信息

文档二:李小四—数据信息

3.以用户李小四将原评论“顶上去 11086“修改为”顶上去 10086“为例说明两类数据库的主要异同:

对比项

关系型数据库

MongoDB数据库

操作

方式

1、找到主键(即唯一标识):用户ID。

2、系统锁定并调取与用户ID有关联的三张表,进行原评论的修改工作。

调取文档:李小四—数据信息

分析

利弊

修改评论需读取三张数据表,对计算机的硬盘、内存使用消耗高。

仅仅调取与修改数据有关的文档,对计算机资源需求低。

简单总结,MongoDB数据库使用一个文档即可存储关系型数据库中3个表的信息,因此查询时不需要跨表连接,对数据修改也不需要锁定3个表,只需要锁定一个文档。基于这样的特性,其可以节省计算资源并大幅提高数据库响应速度。

四、MongoDB数据库数据泄露原因

了解数据库的基本内容之后,我们还是将视线回到本文最开头的话题,探寻下MongoDB数据库数据泄露事件的原因。

从公开报道内容看,无需身份认证可登录MongoDB数据库,是MongoDB数据库遭遇数据泄露和赎金勒索的核心原因。MongoDB数据库属于非关系型数据库,并非如传统的关系型数据库有明确的定义和非常权威的规范,多数MongoDB数据库的运维人员觉得该数据库运用很灵活,可以快速上手,不用在环境上花太多的时间,但却忽视了一个最重要的问题:数据安全。MongoDB数据库存在的风险可归结为:缺乏身份验证、缺乏权限控制、内容不加密。

1.身份验证

MangoDB数据库假设其运行在企业内网环境中,且假设内网环境是安全可靠的,因此默认未开启用户身份认证机制。所以,任何用户都可以伪装成为其他合法用户访问数据库中的数据,对数据库中的数据进行各种操作。不法分子通过这种办法,将数据拖走或加密,后对受害者实施诈骗、勒索。甚至一度出现多个黑客组织重复对一个网上公开的MangoDB数据库实施敲诈勒索的现象。

2.权限控制

不仅MangoDB数据库,其他的非关系型数据库都缺乏对每个数据库用户的权限控制,完全忽视了数据库用户之间的权限区别,导致任意用户都相当于具有超级权限的管理员用户。黑客们登陆后就拥有了操作数据库的任何权限,这对于数据库安全而言,是最危险的。

3.加密

在MangoDB数据库应用中,不仅身份验证是明文传输,所有数据均以明文形式存储,黑客们通过身份认证登录服务器后可直接查看、修改用户保存在云端的文件,容易造成数据泄露。

但让我们不得其解的是,身份验证、权限控制、加密这些安全问题并非是非常疑难复杂的技术问题。究其原因,本文认为MongoDB数据库数据泄露还是“人祸“:一是数据库应用人员安全意识薄弱;二是数据库自身设计存在缺陷。

五、该事件引发的法律分析

大数据应用需要用到多种新工具,这些新工具在诞生之初并没有把安全作为第一要素进行考虑,因此是存在安全隐患的,而工具在被大规模运用后这些安全隐患会逐步凸显出来。数据库数据泄露的责任主体究竟是谁,还得从法律角度给到一个定论。

在国内法层面,《中华人民共和国网络安全法》(以下简称:《网络安全法》),由中华人民共和国第十二届全国人民代表大会常务委员会第二十四次会议于2016年11月7日通过并公布,自2017年6月1日起施行。该法第21条、40条、42条等明确了信息网络运营者就个人信息泄露、毁损、丢失应履行的义务。

2021年4月29日,全国人大常委会公布《个人信息保护法(草案二审稿)》,第五章中的第五十一条明确了个人信息处理者的安全保护义务,结合该草案第四条,个人信息处理者的义务应覆盖个人信息收集、存储、使用、加工、传输、提供、公开等个人信息全生命周期流程。

在国际法领域,欧盟制定的《通用数据保护条例》(全称:General Data Protection Regulation,简称:GDPR)于2018年5月25日正式生效。GDPR通过一系列的要求和控制的定义来规范GDPR收集、存储、处理、保存、分享欧盟公民的个人数据。GDPR引入了具体术语来定义组织内的角色,并通过条文规范组织角色的责任:

1、CHAPTER I(Generalprovisions)Article 4 明确了“datacontroller”及“personal data breach”的定义。

2、CHAPTER I(General provisions)Article 5 明确了data controller处理个人数据应遵循的法律规范,且其必须证明具备遵循该规范的能力。

3、CHAPTER IV(Controller and processor)Section 2(Security of personal Article 32明确规定了data controller数据安全处理的一般法则,重要内容罗列如下:

(1)数据控制者衡量安全措施的适当水平时,应当特别考量应处理产生的风险,特别是在传输储存或进行其他处理时个人数据被意外或非法破坏、遗失、变更、未经授权披露或访问的风险;

(2)数据控制者和数据处理者应当采取措施,以确保在数据控制者和数据处理者授权下行动且有权访问个人数据的任何自然人,除非数据控制者向其发出指令,不能对该类数据进行处理,欧盟或欧盟成员国法律要求其处理的除外。

罗列完法律规定后,我们不妨再看一则数据泄露处罚实例。2018年 6月起英国航空公司网站发生了数据泄露事件,该事件导致约 50 万名客户的个人信息被泄露。2018年9月英国航空公司向英国数据安全监管部门——信息专员办公室(简称:ICO)通报该数据泄露事件。ICO调查后表示,数据泄露始于2018年6月,原因是英国航空公司为保护客户信息而采取的“糟糕的安全措施”。ICO专员伊丽莎白·德纳姆(Elizabeth Denham)对该事件发表意见:“用户的个人数据就是他们的私人财产,当一个组织无法保护个人数据免受盗窃和破坏时,这对用户而言绝不仅仅是不方便而已,而是私人财产的损失。法律已经列明,当组织被委托处理个人资料时,必须确保资料的安全。那些没有做好数据资料保护的企业将会面临审查。”嗣后,ICO依据GDPR对英国航空公司2018年客户数据遭泄露事件开出1.83亿英镑巨额罚单。

通过以上分析,数据库数据泄露的责任主体究竟是谁,答案也非常清楚,即控制数据的互联网运营者。

六、后记

自古至今,科技意识的产生和技术革命的迅猛发展,深刻地改变了人类的生产方式、管理方式、生活方式和思维方式,推动人类社会的加速发展。对法律人而言,科学技术对法律的影响是一个非常重要的问题。科技进步在不断满足人类自身需要的程度时,每每亦触发了社会结构的变革,并对法律制度和法律原则产生深刻的影响。因此,深入地探讨科学技术对法律制度、观念的各种影响,以及二者的价值整合,更好地理解科学技术与法律的关系,显得尤为重要。

技术普及主编:黄辉,北京交通大学计算机学院人工智能专业硕士研究生

审校:郑飞,北京交通大学法学院副教授,北京市京都律师事务所执业律师,中国政法大学法学博士

新技术法学丛书推介

发表评论

登录后才能评论