精华内容
下载资源
问答
  • 数据库安全性控制及控制流程和常用方法

    千次阅读 多人点赞 2020-04-25 14:34:09
    数据库的安全在当今社会是非常重要的,数据库存储了很多数据,一旦数据库的安全性发生了差错,就会导致数据的丢失,或是被不法分子盗取数据

    在这里插入图片描述

    Hi,我是无丶味,这篇博客是我对数据库安全性的一些总结以及记录一下我的学习。
    记得养好好习惯:先赞后看

    数据库安全性控制

    非法使用数据库的情况

    ①编写合法程序绕过数据库管理系统及其授权机制
    ②直接或编写应用程序执行非授权操作
    ③通过多次合法查询数据库从中推导出一些保密数据

    计算机系统的安全模型

    在这里插入图片描述
    系统根据用户标识鉴定用户身份,合法用户才准许进入计算机系统
    数据库管理系统还要进行存取控制,只允许用户执行合法操作
    操作系统有自己的保护措施
    数据以密码形式存储到数据库中

    数据库管理系统安全性控制模型

    在这里插入图片描述

    数据库安全性控制流程及常用方法:

    ①用户标识和鉴定

    用户身份鉴别方法:
    1.静态口令鉴别
    2.动态口令鉴别
    3.生物特征鉴别
    4.智能卡鉴别

    ②存取控制

    常用存取控制方法:

    自主存取控制

    通过 SQL 的GRANT 语句和REVOKE 语句实现
    用户权限组成:数据对象、操作类型
    定义用户存取权限:定义用户可以在哪些数据库对象上进行哪些类型的操作
    定义存取权限称为授权

    关系数据库系统中的存取权限
    在这里插入图片描述

    强制存取控制

    强制存取控制规则
    (1)仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应的客体
    例如银行的高管可以看到别人的帐户余额,而不能修改余额
    (2)仅当主体的许可证级别小于或等于客体的密级时,该主体才能写相应的客体
    例如银行的员工可以修改余额,但不能看到余额

    强制存取控制(MAC)是对数据本身进行密级标记,无论数据如何复制,标记与数据是一个不可分的整体,只有符合密级标记要求的用户才可以操纵数据。
    实现强制存取控制时要首先实现自主存取控制
    原因:较高安全性级别提供的安全保护要包含较低级别的所有保护
    自主存取控制与强制存取控制共同构成数据库管理系统的安全机制
    在这里插入图片描述
    先进行自主存取控制检查,通过自主存取控制检查的数据对象再由系统进行强制存取控制检查,只有通过强制存取控制检查的数据对象方可存取。

    ③视图

    ④审计

    ⑤数据加密

    防止数据库中数据在存储和传输中失密的有效手段

    加密的基本思想
    根据一定的算法将原始数据—明文(Plain text)变换为不可直接识别的格式­—密文(Cipher text)

    加密方法:
    1.存储加密
    2.传输加密

    存储加密:
    ①透明存储加密
    内核级加密保护方式,对用户完全透明
    将数据在写到磁盘时对数据进行加密,授权用户读取数据时再对其进行解密
    数据库的应用程序不需要做任何修改,只需在创建表语句中说明需加密的字段即可
    内核级加密方法: 性能较好,安全完备性较高
    ②非透明存储加密
    通过多个加密函数实现

    传输加密

    链路加密:
    在链路层进行加密
    传输信息由报头和报文两部分组成
    报文和报头均加密

    端到端加密:
    在发送端加密,接收端解密
    只加密报文不加密报头
    所需密码设备数量相对较少,容易被非法监听者发现并从中获取敏感信息

    其他安全性保护
    推理控制:
    处理强制存取控制未解决的问题
    避免用户利用能够访问的数据推知更高密级的数据

    常用方法:
    基于函数依赖的推理控制
    基于敏感关联的推理控制

    隐蔽信道:
    处理强制存取控制未解决的问题

    数据隐私保护:
    描述个人控制其不愿他人知道或他人不便知道的个人数据的能力
    范围很广:数据收集、数据存储、数据处理和数据发布等各个阶段

    授权:授予与回收

    1.GRANT
    GRANT语句的一般格式:

     GRANT <权限>[,<权限>]... 
           ON <对象类型> <对象名>[,<对象类型> <对象名>]TO <用户>[,<用户>]...
           [WITH GRANT OPTION];
    

    语义:将对指定操作对象的指定操作权限授予指定的用户

    谁可以发出GRANT
    1.数据库管理员
    2.数据库对象创建者(即属主Owner)
    3.拥有该权限的用户

    接受权限的用户 :
    1.一个或多个具体用户
    2.PUBLIC(即全体用户)

    WITH GRANT OPTION子句:
    指定:可以再授予
    没有指定:不能传播

    不允许循环授权
    在这里插入图片描述

    把查询Student表权限授给用户U1
    
          GRANT   SELECT 
          ON   TABLE   Student 
          TO   U1;
    
    把对Student表和Course表的全部权限授予用户U2和U3
    
          GRANT ALL PRIVILIGES 
          ON TABLE Student,Course 
          TO U2,U3;
    
    把查询Student表和修改学生学号的权限授给用户U4
      
    	  	GRANT UPDATE(Sno), SELECT 
    		ON TABLE Student 
    		TO U4;
    

    2.REVOKE
    授予的权限可以由数据库管理员或其他授权者用REVOKE语句收回
    REVOKE语句的一般格式为:

        REVOKE <权限>[,<权限>]... 
        ON <对象类型> <对象名>[,<对象类型><对象名>]FROM <用户>[,<用户>]...[CASCADE | RESTRICT];
    

    把用户U4修改学生学号的权限收回
    
    		REVOKE UPDATE(Sno)
    		ON TABLE Student 
    		FROM U4;
    

    数据库管理员:
    拥有所有对象的所有权限
    根据实际情况不同的权限授予不同的用户

    用户:
    拥有自己建立的对象的全部的操作权限
    可以使用GRANT,把权限授予其他用户

    被授权的用户:
    如果具有“继续授权”的许可,可以把获得的权限再授予其他用户
    所有授予出去的权力在必要时又都可用REVOKE语句收回

    数据库角色

    数据库角色:被命名的一组与数据库操作相关的权限
    角色是权限的集合
    可以为一组具有相同权限的用户创建一个角色
    简化授权的过程
    1.角色的创建

    CREATE  ROLE  <角色名> 
    

    例:

    创建一个角色 R1:
     CREATE  ROLE  R1;
    

    2.给角色授权

     GRANT  <权限>[,<权限>]ON <对象类型>对象名  
     TO <角色>[,<角色>]
    使用GRANT语句,使角色R1拥有Student表的	SELECTUPDATEINSERT权限
           GRANT SELECT, UPDATE, INSERT 
        	 ON TABLE Student 
        	 TO R1;
    

    3.将一个角色授予其他的角色或用户

    GRANT  <角色1>[,<角色2>]TO  <角色3>[,<用户1>][WITH ADMIN OPTION]
    
    
    将这个角色授予王平,张明,赵玲。使他们具有角色R1所包含的全部权限
        	 GRANT  R1 
        	 TO 王平,张明,赵玲;
    

    该语句把角色授予某用户,或授予另一个角色

    授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION

    指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色

    一个角色的权限:直接授予这个角色的全部权限加上其他角色
    授予这个角色的全部权限

    4.角色权限的收回

    REVOKE <权限>[,<权限>]ON <对象类型> <对象名>
    FROM <角色>[,<角色>]
    可以一次性通过R1来回收王平的这3个权限
         	  REVOKE  R1 
         	  FROM 王平;
    

    用户可以回收角色的权限,从而修改角色拥有的权限
    REVOKE执行者是
    角色的创建者
    拥有在这个(些)角色上的ADMIN OPTION

    在这里插入图片描述

    展开全文
  • java安全编码指南之:Mutability

    万次阅读 2020-09-03 09:20:15
    文章目录简介变对象和不变对象创建mutable对象的拷贝为mutable类创建copy方法不要相信equals不要直接暴露修改的属性public static ...所以它的安全性没有保证。 而不变类型对象就是说,对象一旦创建之后,其内

    简介

    mutable(可变)和immutable(不可变)对象是我们在java程序编写的过程中经常会使用到的。

    可变类型对象就是说,对象在创建之后,其内部的数据可能会被修改。所以它的安全性没有保证。

    而不可变类型对象就是说,对象一旦创建之后,其内部的数据就不能够被修改,我们可以完全相信这个对象。

    虽然mutable对象安全性不够,但是因为其可以被修改,所以会有效的减少对该对象的拷贝。

    而immutable对象因为不可改变,所以尝试对该对象的修改都会导致对象的拷贝,从而生成新的对象。

    我们最常使用的String就是一个immutable对象。

    那么可变性在java的安全编码中的最佳实践是怎么样的呢? 一起来看看吧。

    可变对象和不可变对象

    知道了可变对象和不可变对象的不同之处之后,我们看一下怎么才能判断这个对象是可变对象还是不可变对象呢?

    首先,最简单的一点就是,不可变对象创建之后就不能够被修改,所以不可变对象里面基本上没有setXXX之类的方法,而可变对象提供了setXXX这些可以修改内部变量状态的方法。

    看一个例子java.util.Date是一个可变对象,而java.time.LocalTime是不可变对象。

    看下他们的方法定义有什么区别呢?

    首先是Date,我们可以看到在其中定义了很多setXXX方法。

    而在LocalTime中,我们基本上看不到setXXX方法。

    同时不可变对象的字段基本上都是final的,防止被二次修改。

    第二,不可变对象一般来说是不可继承的,在java中就是以final关键字做限定的:

    public class Date
    public final class LocalTime
    

    第三,不可变对象一般会隐藏构造函数,而是使用类似工厂模式的方法来创建对象,这样为实例的创建提供了更多的机动性。

    创建mutable对象的拷贝

    那么如果我们想使用mutable对象,又不想被别人修改怎么办呢?

    简单的办法就是拷贝一份要使用的对象:

    public class CopyOutput {
                private final java.util.Date date;
                ...
                public java.util.Date getDate() {
                    return (java.util.Date)date.clone();
                }
            }
    

    这里大家还要注意深拷贝和浅拷贝的问题。

    为mutable类创建copy方法

    既然要为mutable对象创建拷贝,那么相应的mutable类也需要提供一个copy方法来协助拷贝。

    这里需要考虑一个深拷贝和浅拷贝的问题。

    不要相信equals

    我们知道在HashMap中怎么去查找一个key呢?先去找这个key的hash值,然后去判断key.equals方法是否相等,考虑下面这种情况:

    private final Map<Window,Extra> extras = new HashMap<>();
    
            public void op(Window window) {
                Extra extra = extras.get(window);
            }
    

    op方法接收一个Window对象,然后将其当成key从HashMap中取出对应的value。

    如果,这个时候,我们有一个类A继承了Window,并且hash值和equals都和另外一个Window对象B相同,那么使用A这个key可以获取到B这个key存储的数据!

    怎么解决这个问题呢?

    Java中有一个特别的HashMap:IdentityHashMap,这个Map的key和value比较是用==而不是equals方法,所以可以有效的避免上面出现的问题。

    private final Map<Window,Extra> extras = new IdentityHashMap<>();
    
            public void op(Window window) {
                Extra extra = extras.get(window);
            }
    

    如果没有这样的Map可用,那么可以使用不可变对象作为key或者使用Window的私有变量,从而恶意攻击者无法获得这个变量。

    public class Window {
                /* pp */ 
                class PrivateKey {
                    Window getWindow() {
                        return Window.this;
                    }
                }
                final PrivateKey privateKey = new PrivateKey();
    
                private final Map<Window.PrivateKey,Extra> extras =
                     new WeakHashMap<>();
                ...
            }
    
            public class WindowOps {
                public void op(Window window) {
                    // Window.equals may be overridden,
                    // but safe as we don't use it.
                    Extra extra = extras.get(window.privateKey);
                    ...
                }
            }
    

    不要直接暴露可修改的属性

    如果一个可变类中的某个属性确实需要暴露被外部使用,那么一定要将这个属性定义为private,并且使用wrapper方法将其包装起来。

    如果直接暴露出去,那么基本上就没有权限控制可言,任何程序只要能够拿到你这个对象,就可以对属性进行修改。考虑下下面的应用方式,我们在修改state的方法中加入了一个参数校验和权限控制。

    public final class WrappedState {
                // private immutable object
                private String state;
    
                // wrapper method
                public String getState() {
                    return state;
                }
    
                // wrapper method
                public void setState(final String newState) {
                    this.state = requireValidation(newState);
                }
    
                private static String requireValidation(final String state) {
                    if (...) {
                        throw new IllegalArgumentException("...");
                    }
                    return state;
                }
            }
    

    public static fields应该被置位final

    同样的,如果你是一个类变量,当然不希望这个变量会被任何人修改,那么需要将其置位final。

    public class Files {
                public static final String separator = "/";
                public static final String pathSeparator = ":";
            }
    

    public static final field 应该是不可变的

    如果类变量是public static final的,那么这个变量一定要是不可变的。

    有人会问了,都定义成了final了,是不是就已经不可变了?

    其实不然,比如我们定义了一个final的List,虽然这个list不能变化,但是list里面的值是可以变化的。我们需要将可变变量修改为不可变变量,如下所示:

    import static java.util.Arrays.asList;
            import static java.util.Collections.unmodifiableList;
            ...
            public static final List<String> names = unmodifiableList(asList(
                "Fred", "Jim", "Sheila"
            ));
    

    如果使用JDK9中引入的of()或者ofEntries()方法,可以直接创建不可修改的集合:

    public static final List
    <String> names =
     List.of("Fred", "Jim", "Sheila");
    

    本文已收录于 http://www.flydean.com/java-security-code-line-mutability/

    最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现!

    欢迎关注我的公众号:「程序那些事」,懂技术,更懂你!

    展开全文
  • 数据库的安全性、完整性、并发控制和恢复from: http://bbs.chinaunix.net/viewthread.php?tid=188100 为了保证数据库数据的安全可靠性和正确有效,DBMS必须提供统一的数据保护功能。数据保护也为数据控制,主要...

    数据库的安全性、完整性、并发控制和恢复

    from: http://bbs.chinaunix.net/viewthread.php?tid=188100


        为了保证数据库数据的安全可靠性和正确有效,DBMS必须提供统一的数据保护功能。数据保护也为数据控制,主要包括数据库的安全性、完整性、并发控制和恢复。

    一、 数据库的安全性
    数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。计算机系统都有这个问题,在数据库系统中大量数据集中存放,为许多用户共享,使安全问题更为突出。
    在一般的计算机系统中,安全措施是一级一级设置的。
    在DB存储这一级可采用密码技术,当物理存储设备失窃后,它起到保密作用。在数据库系统这一级中提供两种控制:用户标识和鉴定,数据存取控制。
    在ORACLE多用户数据库系统中,安全机制作下列工作:
    l 防止非授权的数据库存取;
    l 防止非授权的对模式对象的存取;
    l 控制磁盘使用;
    l 控制系统资源使用;
    l 审计用户动作。

    数据库安全可分为二类:系统安全性和数据安全性。
    系统安全性是指在系统级控制数据库的存取和使用的机制,包含:
    l 有效的用户名/口令的组合;
    l 一个用户是否授权可连接数据库;
    l 用户对象可用的磁盘空间的数量;
    l 用户的资源限制;
    l 数据库审计是否是有效的;
    l 用户可执行哪些系统操作。

    数据安全性是指在对象级控制数据库的存取和使用的机制,包含:
    l 哪些用户可存取一指定的模式对象及在对象上允许作哪些操作类型。
    在ORACLE服务器上提供了一种任意存取控制,是一种基于特权限制信息存取的方法。用户要存取一对象必须有相应的特权授给该用户。已授权的用户可任意地可将它授权给其它用户,由于这个原因,这种安全性类型叫做任意型。

    ORACLE利用下列机制管理数据库安全性:
    l 数据库用户和模式;
    l 特权;
    l 角色;
    l 存储设置和空间份额;
    l 资源限制;
    l 审计。

    1. 数据库的存取控制
    ORACLE保护信息的方法采用任意存取控制来控制全部用户对命名对象的存取。用户对对象的存取受特权控制。一种特权是存取一命名对象的许可,为一种规定格式。
    ORACLE使用多种不同的机制管理数据库安全性,其中有两种机制:模式和用户。模式为模式对象的集合,模式对象如表、视图、过程和包等。第一数据库有一组模式。
    每一ORACLE数据库有一组合法的用户,可存取一数据库,可运行一数据库应用和使用该用户各连接到定义该用户的数据库。当建立一数据库用户时,对该用户建立一个相应的模式,模式名与用户名相同。一旦用户连接一数据库,该用户就可存取相应模式中的全部对象,一个用户仅与同名的模式相联系,所以用户和模式是类似的。

    用户的存取权利受用户安全域的设置所控制,在建立一个数据库的新用户或更改一已有用户时,安全管理员对用户安全域有下列决策:
    l 是由数据库系统还是由操作系统维护用户授权信息。
    l 设置用户的缺省表空间和临时表空间。
    l 列出用户可存的表空间和在表空间中可使用空间份额。
    l 设置用户资源限制的环境文件,该限制规定了用户可用的系统资源的总量。
    l 规定用户具有的特权和角色,可存取相应的对象。

    每一个用户有一个安全域,它是一组特性,可决定下列内容:
    l 用户可用的特权和角色;
    l 用户可用的表空间的份额;
    l 用户的系统资源限制。

    1) 用户鉴别:
    为了防止非授权的数据库用户的使用,ORACLE提供二种确认方法
    操作系统确认和相应的ORACLE数据库确认。
    如果操作系统允许,ORACLE可使用操作系统所维护的信息来鉴定用户。由操作系统鉴定用户的优点是:
    l 用户可更方便地连接到ORACLE,不需要指定用户名和口令。
    l 对用户授权的控制集中在操作系统,ORACLE不需要存储和管理用户口令。然而用户名在数据库中仍然要维护。
    l 在数据库中的用户名项和操作系统审计跟踪相对应。

    ORACLE数据库方式的用户确认:ORACLE利用存储在数据库中的信息可鉴定试图接到数据库的一用户,这种鉴别方法仅当操作系统不能用于数据库用户鉴别时才使用。当用户使用一ORACLE数据库时执行用户鉴别。每个用户在建立时有一个口令,用户口令在建立对数据库连接时使用,以防止对数据库非授权的使用。用户的口令以密码的格式存储在数据库数据字典中,用户可随时修改其口令。

    2) 用户的表空间设置和定额
    关于表空间的使用有几种设置选择:
    l 用户的缺省表空间;
    l 用户的临时表空间;
    l 数据库表空间的空间使用定额。

    3) 用户资源限制和环境文件
    用户可用的各种系统资源总量的限制是用户安全域的部分。利用显式地设置资源限制;安全管理员可防止用户无控制地消耗宝贵的系统资源。资源限制是由环境文件管理。一个环境文件是命名的一组赋给用户的资源限制。另外ORACLE为安全管理员在数据库级提供使能或使不能实施环境文件资源限制的选择。
    ORACLE可限制几种类型的系统资源的使用,每种资源可在会话级、调用级或两者上控制。在会话级:每一次用户连接到一数据库,建立一会话。每一个会话在执行SQL语句的计算机上耗费CPU时间和内存量进行限制。对ORACLE的几种资源限制可在会话级上设置。如果会话级资源限制被超过,当前语句被中止(回滚),并返回指明会话限制已达到的信息。此时,当前事务中所有之前执行的语句不受影响,此时仅可作COMMIT、ROLLBACK或删除对数据库的连接等操作,进行其它操作都将出错。
    在调用级:在SQL语句执行时,处理该语句有好几步,为了防止过多地调用系统,ORACLE在调用级可设置几种资源限制。如果调用级的资源限制被超过,语句处理被停止,该语句被回滚,并返回一错误。然而当前事务的已执行所用语句不受影响,用户会话继续连接。

    有下列资源限制:
    l
    为了防止无控制地使用CPU时间,ORACLE可限制每次ORACLE调用的CPU时间和在一次会话期间ORACLE调用所使用的CPU的时间,以0.01秒为单位。
    l 为了防止过多的I/O,ORACLE可限制每次调用和每次会话的逻辑数据块读的数目。
    l ORACLE在会话级还提供其它几种资源限制。

    每个用户的并行会话数的限制;
    会话空闲时间的限制,如果一次会话的ORACLE调用之间时间达到该空闲时间,当前事务被回滚,会话被中止,会话资源返回给系统;
    每次会话可消逝时间的限制,如果一次会话期间超过可消逝时间的限制,当前事务被回滚,会话被删除,该会话的资源被释放;
    每次会话的专用SGA空间量的限制。
    用户环境文件:
    用户环境文件是指定资源限制的命名集,可赋给ORACLE数据库的有效的用户。利用用户环境文件可容易地管理资源限制。要使用用户环境文件,首先应将数据库中的用户分类,决定在数据库中全部用户类型需要多少种用户环境文件。在建立环境文件之前,要决定每一种资源限制的值。例如一类用户通常不执行大量逻辑数据块读,那就可将LOGICAL-READS-PER-SESSION和LOGICAL-READS-PER-CALL设置相应的值。在许多情况中决定一用户的环境文件的合适资源限制的最好的方法是收集每种资源使用的历史信息。

    2. 特权和角色
    1) 特权:特权是执行一种特殊类型的SQL语句或存取另一用户的对象的权力。有两类特权:系统特权和对象特权。
    系统特权:是执行一处特殊动作或者在对象类型上执行一种特殊动作的权利。ORACLE有60多种不同系统特权,每一种系统允许用户执行一种特殊的数据库操作或一类数据库操作.
    系统特权可授权给用户或角色,一般,系统特权全管理人员和应用开发人员,终端用户不需要这些相关功能.授权给一用户的系统特权并具有该
    系统特权授权给其他用户或角色.反之,可从那些被授权的用户或角色回收系统特权.
    对象特权:在指定的表、视图、序列、过程、函数或包上执行特殊动作的权利。对于不同类型的对象,有不同类型的对象特权。对于有些模式对象,如聚集、索引、触发器、数据库链没有相关的对象特权,它们由系统特权控制。
    对于包含在某用户名的模式中的对象,该用户对这些对象自动地具有全部对象特权,即模式的持有者对模式中的对象具有全部对象特权。这些对象的持有者可将这些对象上的任何对象特权可授权给其他用户。如果被授者包含有GRANT
    OPTION 授权,那么该被授者也可将其权利再授权给其他用户。

    2) 角色:为相关特权的命名组,可授权给用户和角色。ORACEL利用角色更容易地进行特权管理。有下列优点:
    l 减少特权管理,不要显式地将同一特权组授权给几个用户,只需将这特权组授给角色,然后将角色授权给每一用户。
    l 动态特权管理,如果一组特权需要改变,只需修改角色的特权,所有授给该角色的全部用户的安全域将自动地反映对角色所作的修改。
    l 特权的选择可用性,授权给用户的角色可选择地使其使能(可用)或使不能(不可用)。
    l 应用可知性,当一用户经一用户名执行应用时,该数据库应用可查询字典,将自动地选择使角色使能或不能。
    l 专门的应用安全性,角色使用可由口令保护,应用可提供正确的口令使用权角色使能,达到专用的应用安全性。因用户不知其口令,不能使角色使能。
    一般,建立角色服务于两个目的:为数据库应用管理特权和为用户组管理特权。相应的角色称为应用角色和用户角色。
    应用角色是授予的运行一数据库应用所需的全部特权。一个应用角色可授给其它角色或指定用户。一个应用可有几种不同角色,具有不同特权组的每一个角色在使用应用时可进行不同的数据存取。
    用户角色是为具有公开特权需求的一组数据库用户而建立的。用户特权管理是受应用角色或特权授权给用户角色所控制,然后将用户角色授权给相应的用户。
    数据库角色包含下列功能:
    l 一个角色可授予系统特权或对象特权。
    l 一个角色可授权给其它角色,但不能循环授权。
    l 任何角色可授权给任何数据库用户。
    l 授权给一用户的每一角色可以是使能的或者使不能的。一个用户的安全域仅包含当前对该用户使能的全部角色的特权。
    l 一个间接授权角色(授权给另一角色的角色)对一用户可显式地使其能或使不能。
    在一个数据库中,每一个角色名必须唯一。角色名与用户不同,角色不包含在任何模式中,所以建立一角色的用户被删除时不影响该角色。
    ORACLE为了提供与以前版本的兼容性,预定义下列角色:CONNENT、RESOURCE、DBA、EXP-FULL-DATABASE和IMP-FULL-DATABASE。

    3. 审计
    审计是对选定的用户动作的监控和记录,通常用于:
    l 审查可疑的活动。例如:数据被非授权用户所删除,此时安全管理员可决定对该
    数据库的所有连接进行审计,以及对数据库的所有表的成功地或不成功地删除进行审计。
    l 监视和收集关于指定数据库活动的数据。例如:DBA可收集哪些被修改、执行了多少次逻辑的I/O等统计数据。
    ORACLE支持三种审计类型:
    l 语句审计,对某种类型的SQL语句审计,不指定结构或对象。
    l 特权审计,对执行相应动作的系统特权的使用审计。
    l 对象审计,对一特殊模式对象上的指定语句的审计。
    ORACLE所允许的审计选择限于下列方面:
    l 审计语句的成功执行、不成功执行,或者其两者。
    l 对每一用户会话审计语句执行一次或者对语句每次执行审计一次。
    l 对全部用户或指定用户的活动的审计。
    当数据库的审计是使能的,在语句执行阶段产生审计记录。审计记录包含有审计的操作、用户执行的操作、操作的日期和时间等信息。审计记录可存在数据字典表(称为审计记录)或操作系统审计记录中。数据库审计记录是在SYS模式的AUD$表中。


    二、 数据完整性

    它是指数据的正确性和相容性。数据的完整性是为了防止数据库存在不符合主义的数据,防止错误信息输入和输出,即数据要遵守由DBA或应用开发者所决定的一组预定义的规则。ORACLE应用于关系数据库的表的数据完整性有下列类型:
    l 在插入或修改表的行时允许不允许包含有空值的列,称为空与非空规则。
    l 唯一列值规则,允许插入或修改的表行在该列上的值唯一。
    l 引用完整性规则,同关系模型定义
    l 用户对定义的规则,为复杂性完整性检查。
    ORACLE允许定义和实施上述每一种类型的数据完整性规则,这些规则可用完整性约束和数据库触发器定义。
    完整性约束,是对表的列定义一规则的说明性方法。
    数据库触发器,是使用非说明方法实施完整性规则,利用数据库触发器(存储的数据库过程)可定义和实施任何类型的完整性规则。

    1. 完整性约束
    ORACLE利用完整性约束机制防止无效的数据进入数据库的基表,如果任何DML执行结果破坏完整性约束,该语句被回滚并返回一上个错误。ORACLE实现的完整性约束完全遵守ANSI
    X3。135-1989和ISO9075-1989标准。
    利用完整性约束实施数据完整性规则有下列优点:
    l 定义或更改表时,不需要程序设计,便很容易地编写程序并可消除程序性错误,其功能是由ORACLE控制。所以说明性完整性约束优于应用代码和数据库触发器。
    l 对表所定义的完整性约束是存储在数据字典中,所以由任何应用进入的数据都必须遵守与表相关联的完整性约束。
    l 具有最大的开发能力。当由完整性约束所实施的事务规则改变时,管理员只需改变完整性约束的定义,所有应用自动地遵守所修改的约束。
    l 由于完整性约束存储在数据字典中,数据库应用可利用这些信息,在SQL语句执行之前或由ORACLE检查之前,就可立即反馈信息。
    l 由于完整性约束说明的语义是清楚地定义,对于每一指定说明规则可实现性能优化。
    l
    由于完整性约束可临时地使不能,以致在装入大量数据时可避免约束检索的开销。当数据库装入完成时,完整性约束可容易地使其能,任何破坏完整性约束的任何新行在例外表中列出。
    ORACLE的DBA和应用开始者对列的值输入可使用的完整性约束有下列类型:
    l NOT NULL约束:如果在表的一列的值不允许为空,则需在该列指定NOT NULL约束。
    l
    UNIQUE码约束:在表指定的列或组列上不允许两行是具有重复值时,则需要该列或组列上指定UNIQUE码完整性约束。在UNIQUE码约束定义中的列或组列称为唯一码。所有唯一完整性约束是用索引方法实施。
    l PRIMARY KEY约束:在数据库中每一个表可有一个PRIMARY KEY约束。包含在PRIMARY
    KEY完整性约束的列或组列称为主码,每个表可有一个主码。ORACLE使用索引实施PRIMARY KEY约束。
    l FOREIGN
    KEY约束(可称引用约束):在关系数据库中表可通过公共列相关联,该规则控制必须维护的列之间的关系。包含在引用完整性约束定义的列或组列称为外来码。由外来码所引用的表中的唯一码或方码,称为引用码。包含有外来码的表称为子表或从属表。由子表的外来码所引用的表称为双亲表或引用表。如果对表的每一行,其外来码的值必须与主码中一值相匹配,则需指定引用完整性约束。
    l
    CHECK约束:表的每行对一指定的条件必须是TRUE或未知,则需在一列或列组上指定CHECK完整性约束。如果在发出一个DML语句时,CHECK约束的条件计算得FALSE时,该语句被回滚。

    2. 数据库触发器
    ORACLE允许定义过程,当对相关的表作INSERT、UPDATE或DELETE语句时,这些过程被隐式地执行。这些过程称为数据库触发器。触发器类似于存储的过程,可包含SQL语句和PL/SQL语句,可调用其它的存储过程。过程与触发器差别在于调用方法:过程由用户或应用显式执行;而触发器是为一激发语句(INSERT、UPDATE、DELETE)发出进由ORACLE隐式地触发。一个数据库应用可隐式地触发存储在数据库中多个触发器。
    在许多情况中触发器补充ORACLE的标准功能,提供高度专用的数据库管理系统。一般触发器用于:
    l 自动地生成导出列值。
    l 防止无效事务。
    l 实施复杂的安全审核。
    l 在分布式数据库中实施跨结点的引用完整性。
    l 实施复杂的事务规则。
    l 提供透明的事件记录。
    l 提供高级的审计。
    l 维护同步的表副本。
    l 收集表存取的统计信息。
    注意:在ORACLE环境中利用ORACLE工具SQL*FORMS也可定义、存储和执行触发器,它作为由SQL*FORMS所开发有应用的一部分,它与在表上定义的数据库触发器有差别。数据库触发器在表上定义,存储在相关的数据库中,在对该表发出IMSERT、UPDATE、DELETE语句时将引起数据库触发器的执行,不管是哪些用户或应用发出这些语句。而SQL*FORMS的触发器是SQL*FORMS应用的组成,仅当在指定SQL*FORMS应用中执行指定触发器点时才激发该触发器。
    一个触发器由三部分组成:触发事件或语句、触发限制和触发器动作。触发事件或语句是指引起激发触发器的SQL语句,可为对一指定表的INSERT、 UNPDATE或DELETE语句。触发限制是指定一个布尔表达式,当触发器激以时该布尔表达式是必须为真。触发器作为过程,是PL/SQL块,当触发语句发出、触发限制计算为真时该过程被执行。

    3. 并发控制
    数据库是一个共享资源,可为多个应用程序所共享。这些程序可串行运行,但在许多情况下,由于应用程序涉及的数据量可能很大,常常会涉及输入/输出的交换。为了有效地利用数据库资源,可能多个程序或一个程序的多个进程并行地运行,这就是数据库的并行操作。在多用户数据库环境中,多个用户程序可并行地存取数据库,如果不对并发操作进行控制,会存取不正确的数据,或破坏数据库数据的一致性。
    例:在飞机票售票中,有两个订票员(T1,T2)对某航线(A)的机动性票作事务处理,操作过程如图所示:
    数据库中的A111100
    T1 READ A A:=A-1 WRITE A
    T2 READ A A:=A-1 WRITE A
    T1工作区中的A110000
    T2工作区中的A 11000

    首先T1读A,接着T2也读A。然后T1将其工作区中的A减1,T2也采取同样动作,它们都得0值,最后分别将0值写回数据库。在这过程中没有任何非法操作,但实际上多出一张机票。这种情况称为数据库的不一致性,这种不一致性是由于并行操作而产生的。所谓不一致,实际上是由于处理程序工作区中的数据与数据库中的数据不一致所造成的。如果处理程序不对数据库中的数据进行修改,则决不会造成任何不一致。另一方面,如果没有并行操作发生,则这种临时的不一致也不会造成什么问题。数据不一致总是是由两个因素造成:一是对数据的修改,二是并行操作的发生。因此为了保持数据库的一致性,必须对并行操作进行控制。最常用的措施是对数据进行封锁。

    1) 数据库不一致的类型
    l 不一致性
    在一事务期间,其它提交的或未提交事务的修改是显然的,以致由查询所返回的数据集不与任何点相一致。
    l 不可重复读
    在一个事务范围内,两个相同查询将返回不同数据,由于查询注意到其它提交事务的修改而引起。
    l 读脏数据
    如果事务T1将一值(A)修改,然后事务T2读该值,在这之后T1由于某种原因撤销对该值的修改,这样造成T2读取的值是脏的。
    l 丢失更改
    在一事务中一修改重写另一事务的修改,如上述飞机票售票例子。
    l 破坏性的DDL操作
    在一用户修改一表的数据时,另一用户同时更改或删除该表。

    1) 封锁
    在多用户数据库中一般采用某些数据封锁来解决并发操作中的数据一致性和完整性问题。封锁是防止存取同一资源的用户之间破坏性的干扰的机制,该干扰是指不正确地修改数据或不正确地更改数据结构。
    在多用户数据库中使用两种封锁:排它(专用)封锁和共享封锁。排它封锁禁止相关资源的共享,如果一事务以排它方式封锁一资源,仅仅该事务可更改该资源,直至释放排它封锁。共享封锁允许相关资源可以共享,几个用户可同时读同一数据,几个事务可在同一资源上获取共享封锁。共享封锁比排它封锁具有更高的数据并行性。
    在多用户系统中使用封锁后会出现死锁,引起一些事务不能继续工作。当两个或多个用户彼此等待所封锁数据时可发生死锁。

    2) ORACLE多种一致性模型。
    ORACLE利用事务和封锁机制提供数据并发存取和数据完整性。在一事务内由语句获取的全部封锁在事务期间被保持,防止其它并行事务的破坏性干扰。一个事务的SQL语句所作的修改在它提交之后所启动的事务中才是可见的。在一事务中由语句所获取的全部封锁在该事务提交或回滚时被释放。
    ORACLE在两个不同级上提供读一致性:语句级读一致性和事务级一致性。ORCLE总是实施语句级读一致性,保证单个查询所返回的数据与该查询开始时刻相一致。所以一个查询从不会看到在查询执行过程中提交的其它事务所作的任何修改。为了实现语句级读一致性,在查询进入执行阶段时,在注视SCN的时候为止所提交的数据是有效的,而在语句执行开始之后其它事务提交的任何修改,查询将是看不到的。
    ORACLE允许选择实施事务级读一致性,它保证在同一事务内所有查询的数据

    4) 封锁机制
    ORACLE自动地使用不同封锁类型来控制数据的并行存取,防止用户之间的破坏性干扰。ORACLE为一事务自动地封锁一资源以防止其它事务对同一资源的排它封锁。在某种事件出现或事务不再需要该资源时自动地释放。
    ORACLE将封锁分为下列类:
    l
    数据封锁:数据封锁保护表数据,在多个用户并行存取数据时保证数据的完整性。数据封锁防止相冲突的DML和DDL操作的破坏性干扰。DML操作可在两个级获取数据封锁:指定行封锁和整个表封锁,在防止冲突的DDL操作时也需表封锁。当行要被修改时,事务在该行获取排它数据封锁。表封锁可以有下列方式:行共享、行排它、共享封锁、共享行排它和排它封锁。
    l DDL封锁(字典封锁)
    DDL封锁保护模式对象(如表)的定义,DDL操作将影响对象,一个DDL语句隐式地提交一个事务。当任何DDL事务需要时由ORACLE自动获取字典封锁,用户不能显式地请求DDL封锁。在DDL操作期间,被修改或引用的模式对象被封锁。
    l 内部封锁:保护内部数据库和内存结构,这些结构对用户是不可见的。

    5) 手工的数据封锁
    下列情况允许使用选择代替ORACLE缺省的封锁机制:
    l 应用需要事务级读一致或可重复读。
    l 应用需要一事务对一资源可排它存取,为了继续它的语句,具有对资源排它存取的事务不必等待其它事务完成。
    ORACLE自动封锁可在二级被替代:事务级各系统级。
    l 事务级:包含下列SQL语句的事务替代ORACLE缺省封锁:LOCK TABLE命令、SELECT…FOR UPDATE命令、具有READ
    ONLY选项的SET TRANSACTIN命令。由这些语句所获得的封锁在事务提交或回滚后所释放。
    l 系统级:通过调整初始化参数SERIALIZABLE和REO-LOCKING,实例可用非缺省封锁启动。该两参数据的缺省值为:
    SERIALIZABLE=FALSE
    ORW-LOCKING=ALWAYS

    4. 数据库后备和恢复
    当我们使用一个数据库时,总希望数据库的内容是可靠的、正确的,但由于计算机系统的故障(硬件故障、软件故障、网络故障、进程故障和系统故障)影响数据库系统的操作,影响数据库中数据的正确性,甚至破坏数据库,使数据库中全部或部分数据丢失。因此当发生上述故障后,希望能重新建立一个完整的数据库,该处理称为数据库恢复。恢复子系统是数据库管理系统的一个重要组成部分。恢复处理随所发生的故障类型所影响的结构而变化。

    1) 恢复数据库所使用的结构
    ORACLE数据库使用几种结构对可能故障来保护数据:数据库后备、日志、回滚段和控制文件。
    数据库后备是由构成ORACLE数据库的物理文件的操作系统后备所组成。当介质故障时进行数据库恢复,利用后备文件恢复毁坏的数据文件或控制文件。
    日志,每一个ORACLE数据库实例都提供,记录数据库中所作的全部修改。一个实例的日志至少由两个日志文件组成,当实例故障或介质故障时进行数据库部分恢复,利用数据库日志中的改变应用于数据文件,修改数据库数据到故障出现的时刻。数据库日志由两部分组成:在线日志和归档日志。
    每一个运行的ORACLE数据库实例相应地有一个在线日志,它与ORACLE后台进程LGWR一起工作,立即记录该实例所作的全部修改。在线日志由两个或多个预期分配的文件组成,以循环方式使用。
    归档日志是可选择的,一个ORACLE数据库实例一旦在线日志填满后,可形成在线日志的归档文件。归档的在线日志文件被唯一标识并合成归档日志。
    回滚段用于存储正在进行的事务(为未提交的事务)所修改值的老值,该信息在数据库恢复过程中用于撤消任何非提交的修改。
    控制文件,一般用于存储数据库的物理结构的状态。控制文件中某些状态信息在实例恢复和介质恢复期间用于引导ORACLE。

    2) 在线日志
    一个ORACLE数据库的每一实例有一个相关联的在线日志。一个在线日志由多个在线日志文件组成。在线日志文件填入日志项,日志项记录的数据用于重构对数据库所作的全部修改。后台进程LGWR以循环方式写入在线日志文件。当当前的在线日志文件写满后,LGWR写入到下一可用在线日志文件当最后一个可用的在线日志文件的检查点已完成时即可使用。如果归档不实施,一个已填满的在线日志文件一当包含该在线日志文件的检查点完成,该文件已被归档后即可使用。在任何时候,仅有一个在线日志文件被写入存储日志项,它被称为活动的或当前在线日志文件,其它的在线日志文件为不活动的在线日志文件。
    ORCLE结束写入一在线日志文件并开始写入到另一个在线日志文件的点称为日志开关。日志开关在当前在线日志文件完全填满,必须继续写入到下一个在线日志文件时总出现,也可由DBA强制日志开关。每一日志开关出现时,每一在线日志文件赋给一个新的日志序列号。如果在线日志文件被归档,在归档日志文件中包含有它的日志序列号。
    ORACLE后台进程DBWR(数据库写)将SGA中所有被修改的数据库缓冲区(包含提交和未提交的)写入到数据文件,这样的事件称为出现一个检查点。因下列原因实现检查点:
    l
    检查点确保将内存中经常改变的数据段块每隔一定时间写入到数据文件。由于DBWR使用最近最少使用算法,经常修改的数据段块从不会作为最近最少使用块,如果检查点不出现,它从不会写入磁盘。
    l 由于直至检查点时所有的数据库修改已记录到数据文件,先于检查点的日志项在实例恢复时不再需要应用于数据文件,所以检查点可加快实例恢复。
    虽然检查点有一些开销,但ORACLE既不停止活动又不影响当前事务。由于DBWR不断地将数据库缓冲区写入到磁盘,所以一个检查点一次不必写许多数据块。一个检查点保证自前一个检查点以来的全部修改数据块写入到磁盘。检查点不管填满的在线日志文件是否正在归档,它总是出现。如果实施归档,在LGWR重用在线日志文件之前,检查点必须完成并且所填满的在线日志文件必须被归档。
    检查点可对数据库的全部数据文件出现(称为数据库检查点),也可对指定的数据文件出现。下面说明一下什么时候出现检查点及出现什么情况:
    l 在每一个日志开关处自动地出现一数据库检查点。如果前一个数据库检查点正在处理,由日志开关实施的检查点优于当前检查点。
    l
    初始化参数据LOG-CHECKPOINT-INTERVAL设置所实施的数据库检查点,当预定的日志块数被填满后(自最后一个数据库检查点以来),实施一数据库检查点。另一个参数LOG-CHECKPOINT-TIMEOUT可设置自上一个数据库检查点开始之后指定秒数后实施一数据库检查点。这种选择对使用非常大的日志文件时有用,它在日志开头之间增加检查点。由初始化参数所启动的数据库检查点只有在前一个检查点完成后才能启动。
    l 当一在线表空间开始后备时,仅对构成该空间的数据文件实施一检查点,该检查点压倒仍在进行中的任何检查点。
    l 当DBA使一表空间离线时,仅对构成该表空间的在线文件实施一检查点。
    l 当DBA以正常或立即方式关闭一实例时,ORACLE在实例关闭之前实施一数据库检查点,该检查点压倒任何运行检查点。
    l DBA可要求实施一数据库检查点,该检查点压倒任何运行检查点。

    检查点机制:当检查点出现时,检查点后台进程记住写入在线文件的下一日志行的位置,并通知数据库写后台进程将SGA中修改的数据库缓冲区写入到磁盘上的数据文件。然后由CKPT修改全部控制文件和数据文件的标头,反映该最后检查点。当检查点不发生,DBWR当需要时仅将最近最少使用的数据库缓冲区写入磁盘,为新数据准备缓冲区。
    镜象在线日志文件:为了安全将实例的在线日志文件镜象到它的在线日志文件ORACLE提供镜象功能。当具有镜象在线日志文件时,LGWR同时将同一日志信息写入到多个同样的在线日志文件。日志文件分成组,每个组中的日志文件称为成员,每个组中的全部成员同时活动,由LGWR赋给相同的日志序列号。如果使用镜象在线日志,则可建立在线日志文件组,在组中的每一成员要求是同一大小。
    镜象在线日志的机制:LGWR总是寻找组的全部成员,对一组的全部成员并行地写,然后转换到下一组的全部成员,并行地写。
    每个数据库实例有自己的在线日志组,这些在线日志组可以是镜象的或不是,称为实例的在线日志线索。在典型配置中,一个数据库实例存取一个ORACLE数据库,于是仅一个线索存在。然而在运行ORACLE并行服务器中,两个或多个实例并行地存取单个数据库,在这种情况下,每个实例有自己的线索。

    3) 归档日志
    ORACLE要将填满的在线日志文件组归档时,则要建立归档日志,或称离线日志。其对数据库后备和恢复有下列用处:
    l 数据库后备以及在线和归档日志文件,在操作系统或磁盘故障中可保证全部提交的事务可被恢复。
    l 在数据库打开时和正常系统使用下,如果归档日志是永久保持,在线后备可以进行和使用。
    如果用户数据库要求在任何磁盘故障的事件中不丢失任何数据,那么归档日志必须要存在。归档已填满的在线日志文件可能需要DBA执行额外的管理操作。
    归档机制:决定于归档设置,归档已填满的在线日志组的机制可由ORACLE后台进程ARCH自动归档或由用户进程发出语句手工地归档。当日志组变为不活动、日志开关指向下一组已完成时,ARCH可归档一组,可存取该组的任何或全部成员,完成归档组。在线日志文件归档之后才可为LGWR重用。当使用归档时,必须指定归档目标指向一存储设备,它不同于个有数据文件、在线日志文件和控制文件的设备,理想的是将归档日志文件永久地移到离线存储设备、如磁带。
    数据库可运行在两种不同方式下:NOARCHIVELOG方式或ARCHIVELOG方式。数据库在NOARCHIVELOG方式下使用时,不能进行在线日志的归档。在该数据库控制文件指明填满的组不需要归档,所以一当填满的组成为活动,在日志开关的检查点完成,该组即可被LGWR重用。在该方式下仅能保护数据库实例故障,不能保护介质(磁盘)故障。利用存储在在线日志中的信息,可实现实例故障恢复。
    如果数据库在ARCHIVELOG方式下,可实施在线日志的归档。在控制文件中指明填满的日志文件组在归档之前不能重用。一旦组成为不活动,执行归档的进程立即可使用该组。
    在实例起动时,通过参数LOG-ARCHIVE-START设置,可启动ARCH进程,否则ARCH进程在实例启动时不能被启动。然而DBA在凭借时候可交互地启动或停止自动归档。一旦在线日志文件组变为不活动时,ARCH进程自动对它归档。
    如果数据库在ARCHIVELOG方式下运行,DBA可手工归档填满的不活动的日志文件组,不管自动归档是可以还是不可以。

    4) 数据库后备
    不管为ORACLE数据库设计成什么样的后备或恢复模式,数据库数据文件、日志文件和控制文件的操作系统后备是绝对需要的,它是保护介质故障的策略部分。操作系统后备有完全后备和部分后备
    l
    完全后备:一个完全后备将构成ORACLE数据库的全部数据库文件、在线日志文件和控制文件的一个操作系统后备。一个完全后备在数据库正常关闭之后进行,不能在实例故障后进行。在此时,所有构成数据库的全部文件是关闭的,并与当前点相一致。在数据库打开时不能进行完全后备。由完全后备得到的数据文件在任何类型的介质恢复模式中是有用的。
    l 部分后备
    部分后备为除完全后备外的任何操作系统后备,可在数据库打开或关闭下进行。如单个表空间中全部数据文件后备、单个数据文件后备和控制文件后备。部分后备仅对在ARCHIVELOG方式下运行数据库有用,因为存在的归档日志,数据文件可由部分后备恢复。在恢复过程中与数据库其它部分一致。

    5) 数据库恢复
    l 实例故障的恢复
    当实例意外地(如掉电、后台进程故障等)或预料地(发出SHUTDOUM
    ABORT语句)中止时出现实例故障,此时需要实例恢复。实例恢复将数据库恢复一故障之前的事务一致状态。如果在在线后备发现实例故障,则需介质恢复。在其它情况ORACLE在下次数据库起动时(对新实例装配和打开),自动地执行实例恢复。如果需要,从装配状态变为打开状态,自动地激发实例恢复,由下列处理:
    (1) 为了解恢复数据文件中没有记录的数据,进行向前滚。该数据记录在在线日志,包括对回滚段的内容恢复。
    (2) 回滚未提交的事务,按步1重新生成回滚段所指定的操作。
    (3) 释放在故障时正在处理事务所持有的资源。
    (4) 解决在故障时正经历一阶段提交的任何悬而未决的分布事务。
    l 介质故障的恢复
    介质故障是当一个文件、一个文件的部分或一磁盘不能读或不能写时出现的故障。介质故障的恢复有两种形式,决定于数据库运行的归档方式。
    l 如果数据库是可运行的,以致它的在线日志仅可重用但不能归档,此时介质恢复为使用最新的完全后备的简单恢复。在完全后备执行的工作必须手工地重作。
    l 如果数据库可运行,其在线日志是被归档的,该介质故障的恢复是一个实际恢复过程,重构受损的数据库恢复到介质故障前的一个指定事务一致状态。
    不管哪种形式,介质故障的恢复总是将整个数据库恢复到故障之前的一个事务一致状态。如果数据库是在ARCHIVELOG方式运行,可有不同类型的介质恢复:完全介质恢复和不完全介质恢复。
    完全介质恢复可恢复全部丢失的修改。仅当所有必要的日志可用时才可能。有不同类型的完全介质恢复可使用,其决定于毁坏文件和数据库的可用性。例:
    l 关闭数据库的恢复。当数据库可被装配却是关闭的,完全不能正常使用,此时可进行全部的或单个毁坏数据文件的完全介质恢复。
    l
    打开数据库的离线表空间的恢复。当数据库是打开的,完全介质恢复可以处理。未损的数据库表空间是在线的可以使用,而受损耗捕空间是离线的,其所有数据文件作为恢复的单位。
    l
    打开数据库的离线表间的单个数据文件的恢复。当数据库是打开的,完全介质恢复可以处理。未损的数据库表空间是在线的可以使用,而所损的表空间是离线的,该表空间的指定所损的数据文件可被恢复。
    l 使用后备的控制文件的完全介质恢复。当控制文件所有拷贝由于磁盘故障而受损时,可进行介质恢复而不丢失数据。
    不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库,使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用,决定于需要不完全介质恢复的情况,有下列类型:基于撤消、基于时间和基于修改的不完全恢复。
    基于撤消恢复:在某种情况,不完全介质恢复必须被控制,DBA可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组(在线的或归档的)已被介质故障所破坏,不能用于恢复过程时使用,所以介质恢复必须控制,以致在使用最近的、未损的日志组于数据文件后中止恢复操作。
    基于时间和基于修改的恢复:如果DBA希望恢复到过去的某个指定点,不完全介质恢复地理想的。可在下列情况下使用:
    l 当用户意外地删除一表,并注意到错误提交的估计时间,DBA可立即关闭数据库,恢复它到用户错误之前时刻。
    l
    由于系统故障,一个在线日志文件的部分被破坏,所以活动的日志文件突然不可使用,实例被中止,此时需要介质恢复。在恢复中可使用当前在线日志文件的未损部分,DBA利用基于时间的恢复,一旦有将效的在线日志已应用于数据文件后停止恢复过程。
    在这两种情况下,不完全介质恢复的终点可由时间点或系统修改号(SCN)来指定。
     

     

    展开全文
  • 信息安全性与保密性

    千次阅读 2019-08-20 17:37:27
    安全性与保密性设计 信息安全,具体地说就是保证信息的保密性、完整性、真实性、占有性。 保密性是指系统中的信息必须按照该信息拥有者的要求保证一定的秘密性,不会被未经许可的第三方非法获取。系统必须阻止一切...

    安全性与保密性设计

    信息安全,具体地说就是保证信息的保密性、完整性、真实性、占有性。 保密性是指系统中的信息必须按照该信息拥有者的要求保证一定的秘密性,不会被未经许可的第三方非法获取。系统必须阻止一切对秘密信息的非授权访问或泄露。

    完整性是指系统中的信息应当安全、准确、有效,要求数据不能被非法改动或删除。完整性是信息安全的最基本要求。为了实现完整性,可以借助本章讲述的数字签名、加密等措施,从而有力地保护数据的完整。

    真实性是指对信息的发送者身份的确认或系统中有关主体的身份确认,这样可以保证信息的可信度。信息的真实性可以通过数字签名、公钥加密等方式来实现。

    占有性是指要保护信息赖以存储的节点、介质、载体等不被盗用或窃取。保护信息占有性的方法有使用版权、专利、商业秘密性,提供物理的或逻辑的存取限制方法,维护和检查有关窃取文件的记录等。

    加密和解密

    加密和解密的过程大致如下:首先,信息的发送方准备好要发送信息的原始形式,叫作明文。然后对明文经过一系列变换后形成信息的另一种不能直接体现明文含义的形式,叫作密文。由明文转换为密文的过程叫作加密。在加密时所采用的一组规则或方法称为加密算法。 接收者在收到密文后,再把密文还原成明文,以获得信息的具体内容,这个过程叫作解密。解密时也要运用一系列与加密算法相对应的方法或规则,这种方法或规则叫作解密算法。在加密、解密过程中,由通信双方掌握的参数信息控制具体的加密和解密过程,这个参数叫作密钥。密钥分为加密密钥和解密密钥,分别用于加密过程解密过程

    在加密和解密的过程中,如果采用的加密密钥与解密密钥相同,或者从一个很容易计算出另一个,则这种方法叫作对称密钥密码体制,也叫作单钥密码体制。反之,如果加密和解密的密钥并不相同,或者从一个很难计算出另外一个,就叫作不对称密钥密码系统或者公开密钥密码体制,也叫作双钥密码体制

    对称密钥加密算法

    对称密钥加密算法有多种,例如, DES(Data Encryption Standard,数据加密标准)、 IDEA (International Data Encryption Algorithm,国际数据加密算法)、 Skipjack、 3DES、 GDES、 New DES、 Lucifer、 FEAL N、 LOKI 91、 RC4、 RC5 等。

    DES 算法的过程,简单来说,就是把要加密的明文分成 64 位的数据段作为输入,再使用根据 64 位密钥变化生成的 52 个子密钥,对输入的数据段依次进行初始置换、 16 轮迭代、逆初始置换,然后得到 64 位密文。

    IDEA 是一种加密强度很高的加密算法,迄今为止还没有出现对该算法的有效攻击。 IDEA 算法对数据的处理是以 64 位为单位的,在加密前把要加密的明文按每 64 位作为一个数据段进行分割然后分别加密。

    非对称密钥加密算法

    非对称密钥加密算法有多种,例如, RSA、背包密码、 McEliece、 Diffe Hellman、 Rabin、Ong Fiat Shamir、零知识证明的算法、椭圆曲线、 EIGamal 等。这里主要介绍 RSA 的加密原理。

    数字签名与数字水印

    散列函数是一种公开的数学函数。散列函数运算的输入信息也可叫作报文。散列函数运算后所得到的结果叫作散列码或者叫作消息摘要。散列函数具有如下一些特点:

    (1)不同内容的报文具有不同的散列码,而一旦原始报文有任何改变,哪怕改变一位信息,则通过散列函数计算后得到的散列码也将完全不同。这样,这个散列码就好比是这个报文所特有的“指纹”。

    (2)散列函数是单向的,即求解某一个报文的散列码非常容易,但是根据散列码来倒推原始报文是非常困难的。

    (3)对于任何一个报文,无法预知它的散列码。

    (4)散列码具有固定的长度,不管原始报文的长度如何,通过散列函数运算后的散列 码都具有一样的长度。例如, MD5(Message Digest Algorithm 5,消息摘要算法第 5 个版本)

    展开全文
  • 数据库的安全性

    千次阅读 2018-11-17 13:22:34
    数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏 。 系统安全保护措施是否有效是数据库系统主要的性能指标之一。 数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、...
  • IPv6的安全性

    千次阅读 2019-09-25 14:29:55
    IPv6的安全性 IPv6的优势及特点 扩展地址空间及应用。IPv6设计之初主要是解决互联网迅速发展使IPv4地址空间将被耗尽问题,以免影响整个互联网的进一步扩展。由于IPv4采用32位地址长度,大约只有43亿个地址,而...
  • 1.数据库安全性概述 (1)为什么要研究数据库的安全性? 问题的提出: 数据库的一大特点是数据可以共享 数据共享必然带来数据库的安全性问题 数据库系统中的数据共享不能是无条件的共享 例: 军事秘密、国家机密、...
  • 数据库安全性

    万次阅读 多人点赞 2018-05-19 19:24:10
    数据库的数据保护主要包括数据的安全性和完整性。 一、安全性概述 数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或损坏。系统安全保护措施是否有效是数据库系统的主要技术指标之一。 ...
  • 2019中国信息安全自主可控行业政策盘点及网络安全行业分析一、盘点中国信息安全自主可控行业政策法规二、中国网络安全行业产品分类全景图**三、国产化信息技术网络安全自主可控行业现状深度剖析****1、信息战凸显...
  • 证书有效性验证、根证书

    千次阅读 2019-03-29 15:37:10
    一、 数字证书的有效性验证主要从三个方面: (1)数字证书有效期验证 (2)根证书验证 (3)CRL验证 1、数字证书有效期验证 就是说证书的使用时间要在起始时间和结束时间之内。通过解析证书很容易得到证书的...
  • 提高微服务安全性的11个方法

    千次阅读 多人点赞 2020-12-21 08:41:47
    原文发表于kubernetes中文社区,为作者原创翻译,原文地址 更多kubernetes文章,请多关注kubernetes中文社区 目录 为什么选择微服务?...6.通过交付流水线验证安全性 7.降低攻击者的速度 8.使用Docker Rootl..
  • 数据安全-访问控制

    千次阅读 2018-10-17 16:14:44
    数据安全-访问控制访问控制的应用场景访问控制的概念访问控制的三要素访问控制与身份认证的关系访问控制的类型自主访问控制强制访问控制常用安全模型-BLP安全模型(Bell-Lapadula security model)安全模型-BLP安全...
  • hadoop安全性问题

    千次阅读 2014-05-28 16:55:16
    意味着不仅要安全有效地控制离开自有网络的数据,还必须做好网络内部的数据访问控制。依据数据的敏感程度,我们可能要确保数据分析师能看到的数据是可以让他们分析的数据,并且必须明白发布这些数据及其分析结果可能...
  • 【数据库系统设计】数据库安全性

    千次阅读 2020-04-04 22:46:24
    数据库安全性4.1 数据库安全性概述4.1.1 数据库的不安全因素4.2 数据库安全性控制4.2.1 用户身份鉴别4.2.2 存取控制4.2.3 自主存取控制方法4.2.4 授权:授予与回收4.2.5 数据库角色4.2.6 强制存取控制方法4.3 视图...
  • Docker安全性(二)——带来了新的安全功能给Docker Docker,红帽和开源社区正在共同努力,使Docker更安全。当我看到安全容器中,我期待防止容器内的进程主机,我也期待来保护彼此的容器。与Docker,我们使用的是分 ...
  • 计算机网络安全重要

    千次阅读 2019-02-04 11:44:08
    摘 要:伴随着计算机技术和网络技术的拓展及普及,计算机网络在人们学习、教育、工作和生活等多方面起到了不容忽视的作用,...故而计算机网络安全重要成为社会讨论的热点话题。本文试从计算机网络安全技术的概念、...
  • 数据库-数据库安全性

    千次阅读 2019-09-02 23:46:10
    这篇博客内容有些琐碎繁杂,我整理的时候有很多上课时老师没有讲的,但我自己在看的时候看了看...数据库安全性 1、数据库安全性概述 1)、数据库的不完全因素 2)、安全标准简介 2、数据库安全性控制 1)、用户...
  • 【吐血整理】数据库的安全性

    千次阅读 多人点赞 2020-04-05 12:10:02
    本文主讲 数据库的安全性,欢迎阅读~ ????目录一、数据库安全性概述二、数据库安全性控制1. 用户标识与鉴别2. 存取控制3. 自主存取控制方法4. 授权与回收5. 数据库角色6. 强制存取控制方法三、视图机制四、审计...
  • 如何做好网站的安全性测试

    万次阅读 2013-08-29 09:11:26
    安全性测试并不最终证明应用程序是安全的,而是用于验证所设立策略的有效性,这些对策是基于威胁分析阶段所做的假设而选择的。 一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身
  • 大型网站核心要素之前我们介绍了4个,今天讲讲这最后一个:安全性,从互联网诞生开始,安全威胁就一直伴随着网站的发展,各种web攻击和信息泄露也从未停止,那么我们今天就从下面这几点谈谈网站架构的安全性:网站...
  • 浅谈Docker隔离性和安全性

    千次阅读 2015-05-29 00:28:46
     相信很多开发者都默认Docker这样的容器是一种沙盒(sandbox)应用,也就是说他们可以用root权限在Docker中运行随便什么应用,而Docker有安全机制能保护宿主系统。比如,有些人觉得Docker容器里面的进程跟虚拟机...
  • 第九章数据库安全性  一、选择题 1. 以下( D)不属于实现数据库系统安全性的主要技术和方法。 A. 存取控制技术 B. 视图技术 C. 审计技术 D. 出入机房登记和加锁 2. SQL中的视图提高了数据库系统的...
  • ArcGIS 技术目前广泛应用于商业环境和机密环境中的安全性解决方案。Esri 将继续对产品进行配置和测试,以便轻松集成到企业安全解决方案 - 通常与其他提供/启用安全性功能的产品协同工作。其中包括针对数据保密性和...
  • CCSK云安全认证-M3-管理云计算的安全性和风险

    万次阅读 多人点赞 2020-03-07 23:57:27
    CCSK-M3-管理云计算的安全性和风险一.云计算安全治理与风险管理1.1 治理1.2 云治理工具二. 企业风险管理2.1 企业风险管理2.2 服务模式和部署方式的影响2.3 云风险管理的工具三.法律问题,合同和电子举证四.合规和...
  • 系统安全性之十大措施

    万次阅读 2017-10-19 11:34:50
     用户密码采用MD5加密,这是一种安全性非常高的加密算法,是普遍使用广泛应用于文件验证,银行密码加密等领域,由于这种加密的不可逆性,在使用10位以上字母加数字组成的随机密码时,几乎没有破解的可能性。...
  • 数据库系统概论——第四章 数据库安全性 数据库安全性:保护数据库以防止不合法使用所造成的数据泄露、更改或破坏 系统安全保护措施是否有效是数据库系统主要的性能指标之一。 一、数据库安全安全性概论 1. 数据库...
  • 一、本章要点 1)加密和解密、身份认证(数字签名、密钥、...2)系统的访问控制技术、数据的完整性、数据与文件的加密、通信的安全性、系统的安全性设计。 二、信息系统安全体系 信息安全的5个要素:机密性、完整性、
  • 如何保障系统安全性

    千次阅读 2016-10-21 19:53:34
    怎么保证系统的安全性 1. MD5加密用户密码 用户密码采用MD5加密 2. COOKIES加密 保存COOKIES时,对保存于COOKIES中的数据采用了以MD5加密为基础,加入随机加密因子的专用型改进加密算法。COOKIES中保存的数据不...
  • 怎么保证系统的安全性

    千次阅读 2018-10-13 15:19:51
    最近在完善一个后台管理系统,上级的需求是安全,安全,再...本系统用户密码采用MD5加密,这是一种安全性非常高的加密算法,是普遍使用广泛应用于文件验证,银行密码加密等领域,由于这种加密的不可逆性,在使用1...
  • web安全性考虑的几方面

    千次阅读 2015-11-16 16:17:17
    随着存在安全隐患的Web应用程序数量的骤增,Open Web Application Security Project (开放式Web应用程序安全项目,缩写为OWASP)总结出了现有Web应用程序在安全方面常见的十大漏洞,以提醒企业及其程序开发人员尽量...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 360,008
精华内容 144,003
关键字:

安全性有效性可控性