数据库安全机制.docx

数据库安全机制.docx

《数据库安全机制.docx》由会员分享，可在线阅读，更多相关《数据库安全机制.docx（18页珍藏版）》请在冰豆网上搜索。

数据库安全机制

1.1数据库安全机制

数据库安全机制是用于实现数据库的各种安全策略的功能集合，正是由这些安全机制来实现安全模型，进而实现保护数据库系统安全的目标。

数据库系统的安全机制如下图：

1.1.1用户标识与鉴别

用户标识是指用户向系统出示自己的身份证明，最简单的方法是输入用户ID和密码。

标识机制用于惟一标志进入系统的每个用户的身份，因此必须保证标识的惟一性。

鉴别是指系统检查验证用户的身份证明，用于检验用户身份的合法性。

标识和鉴别功能保证了只有合法的用户才能存取系统中的资源。

由于数据库用户的安全等级是不同的，因此分配给他们的权限也是不一样的，数据库系统必须建立严格的用户认证机制。

身份的标识和鉴别是DBMS对访问者授权的前提，并且通过审计机制使DBMS保留追究用户行为责任的能力。

功能完善的标识与鉴别机制也是访问控制机制有效实施的基础，特别是在一个开放的多用户系统的网络环境中，识别与鉴别用户是构筑DBMS安全防线的第1个重要环节。

近年来一些实体认证的新技术在数据库系统集成中得到应用。

目前，常用的方法有通行字认证、数字证书认证、智能卡认证和个人特征识别等。

通行字也称为“口令”或“密码”，它是一种根据已知事物验证身份的方法，也是一种最广泛研究和使用的身份验证法。

在数据库系统中往往对通行字采取一些控制措施，常见的有最小长度限制、次数限定、选择字符、有效期、双通行字和封锁用户系统等。

一般还需考虑通行字的分配和管理，以及在电脑中的安全存储。

通行字多以加密形式存储，攻击者要得到通行字，必须知道加密算法和密钥。

算法可能是公开的，但密钥应该是秘密的。

也有的系统存储通行字的单向Hash值，攻击者即使得到密文也难以推出通行字的明文。

数字证书是认证中心颁发并进行数字签名的数字凭证，它实现实体身份的鉴别与认证、信息完整性验证、机密性和不可否认性等安全服务。

数字证书可用来证明实体所宣称的身份与其持有的公钥的匹配关系，使得实体的身份与证书中的公钥相互绑定。

智能卡〔有源卡、IC卡或Smart卡〕作为个人所有物，可以用来验证个人身份，典型智能卡主要由微处理器、存储器、输入输出接口、安全逻辑及运算处理器等组成。

在智能卡中引入了认证的概念，认证是智能卡和应用终端之间通过相应的认证过程来相互确认合法性。

在卡和接口设备之间只有相互认证之后才能进行数据的读写操作，目的在于防止伪造应用终端及相应的智能卡。

根据被授权用户的个人特征来进行确证是一种可信度更高的验证方法，目前已得到应用的个人生理特征包括指纹、语音声纹〔voice-print〕、DNA、视网膜、虹膜、脸型和手型等。

1.1.2访问控制

1.1.2.1概述

访问控制的目的是确保用户对数据库只能进行经过授权的有关操作。

在存取控制机制中，一般把被访问的资源称为“客体”，把以用户名义进行资源访问的进程、事务等实体称为“主体”。

传统的存取控制机制有两种，即DAC〔DiscretionaryAccessControl，自主存取控制〕和MAC〔MandatoryAccessControl，强制存取控制〕。

近年来，RBAC〔Role-basedAccessControl，基于角色的存取控制〕得到了广泛的关注。

1.1.2.2数据访问级别和类型

DBMS中的安全系统必须具有伸缩性以便为各种数据级别授权。

数据级别有以下几种：

整个数据库、单个关系表〔所有行和所有列〕、关系表中特定列〔所有行〕、关系表中的特定行〔所有列〕以及关系表的特定行和特定列。

数据的所有访问模式和类型如下：

●插入或建立。

在文件中添加数据，不销毁任何数据。

●读取。

用户可通过应用程序或数据库查询，将数据从数据库复制到用户环境。

●更新。

编写更新值。

●删除。

删除和销毁特定数据库对象。

●移动。

移动数据对象，但没有读取内容的权限。

●执行。

使用执行需要的权限，运行程序或过程。

●确认存在性。

确认数据库是否存在特定数据库对象。

1.1.2.3任意控制〔DAC〕

采用该方法以假设干种指派模式授予各个用户访问特定数据项的权限或权力。

基于权限说明，用户能以读取、更新、插入或删除模式随意访问数据项。

建立数据库对象的用户自动得到此对象的所有访问权限，包括将此对象的权限再授予他人。

在授予或撤消访问权限时，有两种主要级别：

数据库对象：

数据项或数据元素，一般是基本表或视图

用户：

可以用一些授权标识符识别的单个用户或用户组

授权通常都是在这两种级别上进行。

1.授权

DBMS提供了功能强大的授权机制，它可以给用户授予各种不同对象〔表、视图、存储过程等〕的不同使用权限〔如Select、update、insert、delete等〕。

在用户级别，可以授予数据库模式和数据操纵方面的以下几种授权，包括：

创建和删除索引、创建新关系、添加或删除关系中的属性、删除关系、查询数据、插入新数据、修改数据、删除数据等。

在数据库对象级别，可将上述访问权限应用于数据库、基本表、视图和列等。

2.数据库角色

如果要给成千上万个雇员分配许可，将面临很大的管理难题，每次有雇员到来或者离开时，就得有人分配或去除可能与数百张表或视图有关的权限。

这项任务很耗时间而且非常容易出错。

即使建立SQL过程来帮助，也几乎需要时时去维护。

一个相对特别简单有效的解决方案就是定义数据库角色。

数据库角色是被命名的一组与数据库操作相关的权限，角色是一组相关权限的集合。

因此，可以为一组具有相同权限的用户创建一个角色，使用角色来管理数据库权限可以简化授权的过程。

先创建一个角色，并且把需要的许可分配给角色，而不是分配给个人用户，然后再把角色分配给特定用户。

当有新的雇员到来时，把角色添加给用户就提供了所有必要的权限。

授权管理机制如图4-3所示。

1.1.2.4强制控制〔MAC〕

强制访问控制模型基于与每个数据项和每个用户关联的安全性标识（SecurityLabel）。

安全性标识被分为假设干级别：

绝密（TopSecret）、机密（Secret）、秘密（Confidential）、一般（Public）。

数据的标识称为密级（SecurityClassification），用户的标识称为许可级别证（SecurityClearance）。

在电脑系统中，每个运行的程序继承用户的许可证级别，也可以说，用户的许可证级别不仅仅应用于作为人的用户，而且应用于该用户运行的所有程序。

当某一用户以某一密级进入系统时，在确定该用户能否访问系统上的数据时应遵守如下规则：

●当且仅当用户许可证级别大于等于数据的密级时，该用户才能对该数据进行读操作。

●当且仅当用户的许可证级别小于或等于数据的密级时，该用户才能对该数据进行写操作。

第二条规则说明用户可以为其写入的数据对象赋予高于自己许可证级别的密级，这样的数据被写入后用户自己就不能再读该数据对象了。

这两种规则的共同点在于它们禁止了拥有高级许可证级别的主体更新低密级的数据对象，从而防止了敏感数据的泄露。

1.1.2.5基于角色的存取控制〔RBAC〕

RBAC在主体和权限之间增加了一个中间桥梁——角色。

权限被授予角色，而管理员通过指定用户为特定角色来为用户授权。

从而大大简化了授权管理，具有强大的可操作性和可管理性。

角色可以根据组织中的不同工作创建，然后根据用户的责任和资格分配角色，用户可以轻松地进行角色转换。

而随着新应用和新系统的增加，角色可以分配更多的权限，也可以根据需要撤销相应的权限。

RBAC核心模型包含了5个基本的静态集合，即用户集〔users〕、角色集〔roles〕、特权集 〔perms〕〔包括对象集〔objects〕和操作集〔operators〕〕，以及一个运行过程中动态维护的集合，即会话集〔sessions〕，如图1-1所示。

用户集包括系统中可以执行操作的用户，是主动的实体；对象集是系统中被动的实体，包含系统需要保护的信息；操作集是定义在对象上的一组操作，对象上的一组操作构成了一个特权；角色则是RBAC模型的核心，通过用户分配〔UA〕和特权分配〔PA〕使用户与特权关联起来。

RBAC属于策略中立型的存取控制模型，既可以实现自主存取控制策略，又可以实现强制存取控制策略。

它可以有效缓解传统安全管理处理瓶颈问题，被认为是一种普遍适用的访问控制模型，尤其适用于大型组织的有效的访问控制机制。

1.1.2.6视图机制

几乎所有的DBMS都提供视图机制。

视图不同于基本表，它们不存储实际数据，数据库表存储数据，视图好象数据库表的窗口，是虚拟表。

当用户通过视图访问数据时，是从基本表获得数据，但只是由视图中定义的列构成。

视图提供了一种灵活而简单的方法，以个人化方式授予访问权限，是强大的安全工具。

在授予用户对特定视图的访问权限时，该权限只用于在该视图中定义的数据项，而未用于完整基本表本身。

因此，在使用视图的时候不用担忧用户会无意地删除数据或者给真实表中添加有害的数据，并且可以限制用户只能使用指定部分的数据，增加了数据的保密性和安全性。

1.1.3数据库加密

1.1.3.1概述

由于数据库在操作系统中以文件形式管理，所以入侵者可以直接利用操作系统的漏洞窃取数据库文件，或者篡改数据库文件内容。

另一方面，数据库管理员〔DBA〕可以任意访问所有数据，往往超出了其职责范围，同样造成安全隐患。

因此，数据库的保密问题不仅包括在传输过程中采用加密保护和控制非法访问，还包括对存储的敏感数据进行加密保护，使得即使数据不幸泄露或者丧失，也难以造成泄密。

同时，数据库加密可以由用户用自己的密钥加密自己的敏感信息，而不需要了解数据内容的数据库管理员无法进行正常解密，从而可以实现个性化的用户隐私保护。

对数据库加密必然会带来数据存储与索引、密钥分配和管理等一系列问题，同时加密也会显著地降低数据库的访问与运行效率。

保密性与可用性之间不可防止地存在冲突，需要妥善解决二者之间的矛盾。

数据库中存储密文数据后，如何进行高效查询成为一个重要的问题。

查询语句一般不可以直接运用到密文数据库的查询过程中，一般的方法是首先解密加密数据，然后查询解密数据。

但由于要对整个数据库或数据表进行解密操作，因此开销巨大。

在实际操作中需要通过有效的查询策略来直接执行密文查询或较小粒度的快速解密。

一般来说，一个好的数据库加密系统应该满足以下几个方面的要求。

①足够的加密强度，保证长时间且大量数据不被破译。

②加密后的数据库存储量没有明显的增加。

③加解密速度足够快，影响数据操作响应时间尽量短。

④加解密对数据库的合法用户操作〔如数据的增、删、改等〕是透明的。

⑤灵活的密钥管理机制，加解密密钥存储安全，使用方便可靠。

1.1.3.2数据库加密的实现机制

数据库加密的实现机制主要研究执行加密部件在数据库系统中所处的层次和位置，通过比照各种体系结构的运行效率、可扩展性和安全性，以求得最正确的系统结构。

按照加密部件与数据库系统的不同关系，数据库加密机制可以从大的方面分为库内加密和库外加密。

〔1〕库内加密

库内加密在DBMS内核层实现加密，加／解密过程对用户与应用透明，数据在物理存取之前完成加／解密工作。

这种方式的优点是加密功能强，并且加密功能集成为DBMS的功能，可以实现加密功能与DBMS之间的无缝耦合。

对于数据库应用来说，库内加密方式是完全透明的。

库内加密方式的主要缺点如下。

—对系统性能影响比较大，BMS除了完成正常的功能外，还要进行加／解密运算，从而加重了数据库服务器的负载。

—密钥管理风险大，加密密钥与库数据保存在服务器中，其安全性依赖于DBMS的访问控制机制。

—加密功能依赖于数据库厂商的支持，DBMS一般只提供有限的加密算法与强度可供选择，自主性受限。

〔2〕库外加密

在库外加密方式中，加／解密过程发生在DBMS之外，DBMS管理的是密文。

加／解密过程大多在客户端实现，也有的由专门的加密服务器或硬件完成。

与库内加密方式相比，库外加密的明显优点如下。

—由于加／解密过程在客户端或专门的加密服务器实现，所以减少了数据库服务器与DBMS的运行负担。

—可以将加密密钥与所加密的数据分开保存，提高了安全性。

—由客户端与服务器的配合，可以实现端到端的网上密文传输。

库外加密的主要缺点是加密后的数据库功能受到一些限制，例如加密后的数据无法正常索引。

同时数据加密后也会破坏原有的关系数据的完整性与一致性，这些都会给数据库应用带来影响。

在目前新兴的外包数据库服务模式中，数据库服务器由非可信的第三方提供，仅用来运行标准的DBMS，要求加密解密都在客户端完成。

1.1.3.3数据库加密的粒度

一般来说，数据库加密的粒度可以有4种，即表、属性、记录和数据元素。

不同加密粒度的特点不同，总的来说，加密粒度越小，则灵活性越好且安全性越高，但实现技术也更为复杂，对系统的运行效率影响也越大。

〔1〕表加密

表级加密的对象是整个表，这种加密方法类似于操作系统中文件加密的方法。

即每个表与不同的表密钥运算，形成密文后存储。

这种方式最为简单，但因为对表中任何记录或数据项的访问都需要将其所在表的所有数据快速解密，因而执行效率很低，浪费了大量的系统资源。

在目前的实际应用中，这种方法基本已被放弃。

〔2〕属性加密

属性加密又称为“域加密”或“字段加密”，即以表中的列为单位进行加密。

一般而言，属性的个数少于记录的条数，需要的密钥数相对较少。

如果只有少数属性需要加密，属性加密是可选的方法。

〔3〕记录加密

记录加密是把表中的一条记录作为加密的单位，当数据库中需要加密的记录数比较少时，采用这种方法是比较好的。

〔4〕数据元素加密

数据元素加密是以记录中每个字段的值为单位进行加密，数据元素是数据库中最小的加密粒度。

采用这种加密粒度，系统的安全性与灵活性最高，同时实现技术也最为复杂。

不同的数据项使用不同的密钥，相同的明文形成不同的密文，抗攻击能力得到提高。

不利的方面是，该方法需要引入大量的密钥。

一般要周密设计自动生成密钥的算法，密钥管理的复杂度大大增加，同时系统效率也受到影响。

在目前条件下，为了得到较高的安全性和灵活性，采用最多的加密粒度是数据元素。

为了使数据库中的数据能够充分而灵活地共享，加密后还应当允许用户以不同的粒度进行访问。

1.1.3.4加密算法

加密算法是数据加密的核心，一个好的加密算法产生的密文应该频率平衡，随机无重码，周期很长而又不可能产生重复现象。

窃密者很难通过对密文频率，或者重码等特征的分析获得成功。

同时，算法必须适应数据库系统的特性，加／解密，尤其是解密响应迅速。

常用的加密算法包括对称密钥算法和非对称密钥算法。

对称密钥算法的特点是解密密钥和加密密钥相同，或解密密钥由加密密钥推出。

这种算法一般又可分为两类，即序列算法和分组算法。

序列算法一次只对明文中的单个位或字节运算；分组算法是对明文分组后以组为单位进行运算，常用有DES等。

非对称密钥算法也称为“公开密钥算法”，其特点是解密密钥不同于加密密钥，并且从解密密钥推出加密密钥在计算上是不可行的。

其中加密密钥公开，解密密钥则是由用户秘密保管的私有密钥。

常用的公开密钥算法有RSA等。

目前还没有公认的专门针对数据库加密的加密算法，因此一般根据数据库特点选择现有的加密算法来进行数据库加密。

一方面，对称密钥算法的运算速度比非对称密钥算法快很多，二者相差大约2~3个数量级；另一方面，在公开密钥算法中，每个用户有自己的密钥对。

而作为数据库加密的密钥如果因人而异，将产生异常庞大的数据存储量。

因此，在数据库加密中一般采取对称密钥的分组加密算法。

1.1.3.5密钥管理

对数据库进行加密，一般对不同的加密单元采用不同的密钥。

以加密粒度为数据元素为例，如果不同的数据元素采用同一个密钥，由于同一属性中数据项的取值在一定范围之内，且往往呈现一定的概率分布，因此攻击者可以不用求原文，而直接通过统计方法即可得到有关的原文信息，这就是所谓的统计攻击。

大量的密钥自然会带来密钥管理的问题。

根据加密粒度的不同，系统所产生的密钥数量也不同。

越是细小的加密粒度，所产生的密钥数量越多，密钥管理也就越复杂。

良好的密钥管理机制既可以保证数据库信息的安全性，又可以进行快速的密钥交换，以便进行数据解密。

对数据库密钥的管理一般有集中密钥管理和多级密钥管理两种体制，集中密钥管理方法是设立密钥管理中心。

在建立数据库时，密钥管理中心负责产生密钥并对数据加密，形成一张密钥表。

当用户访问数据库时，密钥管理机构核对用户识别符和用户密钥。

通过审核后，由密钥管理机构找到或计算出相应的数据密钥。

这种密钥管理方式方便用户使用和管理，但由于这些密钥一般由数据库管理人员控制，因而权限过于集中。

目前研究和应用比较多的是多级密钥管理体制，以加密粒度为数据元素的三级密钥管理体制为例，整个系统的密钥由一个主密钥、每个表上的表密钥，以及各个数据元素密钥组成。

表密钥被主密钥加密后以密文形式保存在数据字典中，数据元素密钥由主密钥及数据元素所在行、列通过某种函数自动生成，一般不需要保存。

在多级密钥体制中，主密钥是加密子系统的关键，系统的安全性在很大程度上依赖于主密钥的安全性。

1.1.3.6数据库加密的局限性

数据库加密技术在保证安全性的同时，也给数据库系统的可用性带来一些影响。

〔1〕系统运行效率受到影响

数据库加密技术带来的主要问题之一是影响效率。

为了减少这种影响，一般对加密的范围做一些约束，如不加密索引字段和关系运算的比较字段等。

〔2〕难以实现对数据完整性约束的定义

数据库一般都定义了关系数据之间的完整性约束，如主／外键约束及值域的定义等。

数据一旦加密，DBMS将难以实现这些约束。

〔3〕对数据的SQL语言及SQL函数受到制约

SQL语言中的Groupby、Orderby及Having子句分别完成分组和排序等操作，如果这些子句的操作对象是加密数据，那么解密后的明文数据将失去原语句的分组和排序作用。

另外，DBMS扩展的SQL内部函数一般也不能直接作用于密文数据。

〔4〕密文数据容易成为攻击目标

加密技术把有意义的明文转换为看上去没有实际意义的密文信息，但密文的随机性同时也暴露了消息的重要性，容易引起攻击者的注意和破坏，从而造成了一种新的不安全性。

加密技术往往需要和其他非加密安全机制相结合，以提高数据库系统的整体安全性。

数据库加密作为一种对敏感数据进行安全保护的有效手段，将得到越来越多的重视。

总体来说，目前数据库加密技术还面临许多挑战，其中解决保密性与可用性之间的矛盾是关键。

1.1.4审计

“审计”功能是DBMS到达C2以上安全级别必不可少的一项指标。

因为任何系统的安全措施都是不完美的，蓄意盗窃、破坏数据的人总是想方设法打破控制。

审计通常用于以下情况：

●审查可疑的活动。

例如：

当出现数据被非授权用户所删除、用户越权操作或权限管理不正确时，安全管理员可以设置对该数据库的所有连接进行审计，和对数据库中所有表的操作进行审计。

●监视和收集关于指定数据库活动的数据。

例如：

DBA可收集哪些表经常被修改、用户执行了多少次逻辑I/O操作等统计数据，为数据库优化与性能调整提供依据。

对DBA而言，审计就是记录数据库中正在做什么的过程。

审计记录可以告诉你正在使用哪些系统权限，使用频率是多少，多少用户正在登录，会话平均持续多长时间，正在特殊表上使用哪些命令，以及许多其他有关事实。

审计能帮助DBA完成的操作类型包括：

●为管理程序准备数据库使用报表（每天/周连接多少用户，每月发出多少查询，上周添加或删除了多少雇员记录）。

●如果疑心有黑客活动，记录企图闯入数据库的失败尝试。

●确定最繁忙的表，它可能需要额外的调整。

●调查对关键表的可疑更改。

●从用户负载方面的预期增长，规划资源消耗。

审计功能把用户对数据库的所有操作自动记录下来放入审计日志〔AuditLog〕中。

审计日志一般包括以下内容：

●操作类型〔如修改、查询等〕。

●操作终端标识与操作人员标识。

●操作日期和时间。

●操作的数据对象〔如表、视图、记录、属性等〕。

●数据修改前后的值。

DBA可以利用审计跟踪的功能，重现导致数据库现状的一系列事件，找出非法存取数据的人、时间和内容等。

审计通常比较费时间和空间，所以DBMS往往都将其作为可选特征，允许DBA根据应用对安全性的要求，灵活地打开或关闭审计功能。

审计功能一般主要用于安全性要求较高的部门。

审计一般可以分为用户级审计和系统级审计。

用户级审计是任何用户可设置的审计，主要是针对自己创建的数据库或视图进行审计，记录所有用户对这些表或视图的一切成功和〔或〕不成功的访问要求以及各种类型的SQL操作。

系统级审计只能由DBA设置，用以监测成功或失败的登录要求、监测Grant和Revoke操作以及其他数据库级权限下的操作。

1.1.5备份与恢复

一个数据库系统总是防止不了故障的发生。

安全的数据库系统必须能在系统发生故障后利用已有的数据备份，恢复数据库到原来的状态，并保持数据的完整性和一致性。

数据库系统所采用的备份与恢复技术，对系统的安全性与可靠性起着重要作用，也对系统的运行效率有着重大影响。

1.1.5.1数据库备份

常用的数据库备份的方法有如下3种。

〔1〕冷备份

冷备份是在没有终端用户访问数据库的情况下关闭数据库并将其备份，又称为“脱机备份”。

这种方法在保持数据完整性方面显然最有保障，但是对于那些必须保持每天24小时、每周7天全天候运行的数据库服务器来说，较长时间地关闭数据库进行备份是不现实的。

〔2〕热备份

热备份是指当数据库正在运行时进行的备份，又称为“联机备份”。

因为数据备份需要一段时间，而且备份大容量的数据库还需要较长的时间，那么在此期间发生的数据更新就有可能使备份的数据不能保持完整性，这个问题的解决依赖于数据库日志文件。

在备份时，日志文件将需要进行数据更新的指令“堆起来”，并不进行真正的物理更新，因此数据库能被完整地备份。

备份结束后，系统再按照被日志文件“堆起来”的指令对数据库进行真正的物理更新。

可见，被备份的数据保持了备份开始时刻前的数据一致性状态。

热备份操作存在如下不利因素。

—如果系统在进行备份时崩溃，则堆在日志文件中的所有事务都会被丧失，即造成数据的丧失。

—在进行热备份的过程中，如果日志文件占用系统资源过大，如将系统存储空间占用完，会造成系统不能接受业务请求的局面，对系统运行产生影响。

—热备份本身要占用相当一部分系统资源，使系统运行效率下降。

〔3〕逻辑备份

逻辑备份是指使用软件技术从数据库中导出数据并写入一个输出文件，该文件的格式一般与原数据库的文件格式不同，而是原数据库中数据内容的一个映像。

因此逻辑备份文件只能用来对数据库进行逻辑恢复，即数据导入，而不能按数据库原来的存储特征进行物理恢复。

逻辑备份一般用于增量备份，即备份那些在上次备份以后改变的数据。

1.1.5.2数据库恢复

在系统发生故障后，把数据库恢复到原来的某种一致性状态的技术称为“恢复”，其基本原理是利用“冗余”进行数据库恢复。

问题的关键是如何建立“冗余”并利用“冗余”实施数据库恢复，即恢复策略。

数据库恢复技术一般有3种策略，即基于备份的恢复、基于运行时日志的恢复和基于镜像数据库的恢复。

〔1〕基于备份的恢复

基于备份的恢复是指周期性地备份数据库。

当数据库失效时，可取最近一次的数据库备份来恢复数据库，即把备份的数据拷贝到原数据库所在的位置上。

用这种方法，数据库只能恢复到最近一次备份的状态，而从最近备份到故障发生期间的所有数据库更新将会丧失。

备份的周期越长，丧失的更新数据越多。

〔2〕基于运行时日志的恢复

运行时日志文件是用来记录对数据库每一次更新的文件。

对日志的操作优先于对数据库的操作，以确保记录数据库的更改。

当系统突然失效而导致事务中断时，可重新装入数据库的副本，把数据库恢复到上一次备份时的状态。

然后系统自动正向扫描日志文件，将故障发生前所有提交的事务放到重