浅谈Oracle数据库多种安全性措施 (浅谈Orign和Olympus的差异)

Oracle的安全措施主要有三个方面，一是用户标识和鉴定;二是授权和检查机制;三是审计技术(是否使用审计技术可由用户灵活选择);除此之外，Oracle还允许用户通过触发器灵活定义自己的安全性措施。

一、用户标识和鉴定

在Oracle中，最外层的安全性措施是让用户标识自己的名字，然后由系统进行核实。Oracle允许用户重复标识三次，如果三次未通过，系统自动退出。

二、授权与检查机制

Oracle的权限包括系统权限和 操作系统的安全机制彼此独立，数据字典在Oracle的安全性授权和检查以及审计技术中起着重要作用。

【编辑推荐】

oracle 启动必须开启什么进程

2、startup mount dbname安装启动，这种方式启动下可执行：数据库日志归档、数据库介质恢复、使数据文件联机或脱机，重新定位数据文件、重做日志文件。 执行“nomount”，然后打开控制文件，确认数据文件和联机日志文件的位置，但此时不对数据文件和日志文件进行校验检查。 3、startup open dbname先执行“nomount”，然后执行“mount”，再打开包括Redo log文件在内的所有数据库文件，这种方式下可访问数据库中的数据。 4、startup，等于以下三个命令startup nomountalter database mountalter database open5、startup restrict约束方式启动这种方式能够启动数据库，但只允许具有一定特权的用户访问非特权用户访问时，会出现以下提示：ERROR：ORA-: ORACLE 只允许具有 RESTRICTED SESSION 权限的用户使用6、startup force强制启动方式,当不能关闭数据库时，可以用startup force来完成数据库的关闭,先关闭数据库，再执行正常启动数据库命令7、startup pfile=参数文件名带初始化参数文件的启动方式先读取参数文件，再按参数文件中的设置启动数据库

Oracle数据库安全性设计？大家给点建议

Oracle数据库安全性设计建议一、 什么是安全的系统安全性建设是一个长期并且卓绝的工作。 作为一个符合标准的企业级系统，我们认为税务系统应该具备以下的安全性特点： 高可用性 对敏感数据的访问控制能力。 监测用户行为的审计能力。 用户帐号管理的有效性和扩充性二、 从哪些方面作安全性检查一个企业级系统的安全性建设并不仅仅局限于软件技术方面的设置和控制，甚至我们可以说，技术仅仅位于一个补充和提高现有安全性的地位上。 通常，应该按照重要性依次进行如下的安全性检查。 物理层面的控制控制物理接触是系统安全性建设的第一步，也是最会有成效，最应该优先执行的一步。 权威安全研究显示，70% 的信息系统数据损失和攻击都是由“内部人”（即具备某种系统及其数据访问权限的用户）造成和发起的。 比如，授权人员才可以进入机房，管理人员的密码不要记录在显眼的地方，离开个人终端锁定屏幕，等等，这些建议看上去似乎比较琐碎。 但是如果缺少了这些意识，即使我们运用了再好的安全性技术，再复杂的数据分离技术，当一个人可以接近需要保护的服务器，当一个人可以通过窃取的密码接近需要保护的数据，那么一切的安全性建设都将是一个摆设。 千里之堤，毁于蚁穴。 一个牢固的堤坝不会因为外界洪水的冲击而倒塌，却会崩坏于隐藏在自身内部的蛀虫。 所以，最佳的方法是不要让蚂蚁靠近堤坝。 安全性流程建设实施安全性建设之后，必须要有一个详细周密而且行之有效的流程控制（Process Control）。 其中行之有效是我们应该注意的。 有时候会听到抱怨，在增强了安全性建设的系统中，维护人员由于分工过细，导致整个系统的应变能力下降，维护成本提高，管理效率降低。 以前一个人可以在10分钟内作好的修改，现在却要途经3，4个人之手，耗时1－2天还不一定能够做完。 过犹不及，建立一个符合企业自身需求的安全性流程是我们应该优先考虑的。 普遍性的安全性措施不仅仅是Oracle数据库系统，作为一个具有领先性的IT系统，都应该包括以下的安全性措施。 1． 只安装需要的软件每个软件都有缺陷，对于Oracle数据库软件来说，自定义安装，只选取需要的组件，少作少错，这一点在安全性方面显得尤为重要，一个具有潜在安全性漏洞的组件，如果它没有被安装。 那它就不会影响整个系统。 2． 锁定或者失效默认用户对于Oracle数据库系统来说，安装的时候会有一系列的默认用户生成，应该在数据库安装完毕之后，经过功能筛选，锁定或者失效这些用户。 3． 修改可用用户的默认密码不能锁定或者失效的用户，必须修改默认密码。 比如具有SYSDBA权限的SYS用户和具有DBA权限的SYSTEM用户，都应该修改默认密码。 至于密码长度和复杂性的有效控制在后面将会谈到。 4． 限制操作系统存取权限Oracle数据库系统是依存在操作系统之上的，如果操作系统被人侵入，那么通过修改配置文件等一系列方法，Oracle数据库的安全性也将荡然无存。 5． 定期更新厂家推出的安全性补丁随着时间的推移，厂家通常会推出一系列的安全性补丁来弥补现有系统的安全隐患。 对于Oracle数据库而言，应该定期查看以下网址来获取Oracle公司最新的安全性警告和解决方案。

关系数据库有哪几种完整性

3.1 SQL 中的完整性约束SQL把各种完整性约束作为数据库模式定义的一部分。 既有效防止了对数据库的意外破坏，提高了完整性检测的效率，又可以减轻编程人员的负担。 SQL对三种不同完整性约束的设置及检测，采取了不同的方式加以实现。 下面分别介绍。 3.1.1 实体完整性和主码实体完整性规定，主码的任何属性都不能为空，因为，概念模型中实体和联系都是可区分的，而且它们以码为唯一性标识。 如果，主码的属性值可以为空，则意味着在概念模型中存在着不以码为唯一性标识的实体。 这显然是前后矛盾的。 那么怎样保证实体完整性呢？SQL中实体完整性是通过主码来实现的。 一旦某个属性或属性组被定义为主码，该主码的每个属性就不能为空值，并且在关系中不能出现主码值完全相同的两个元组。 主码的定义是在Create Table 语句中使用 Primary Key关键字来实现的。 方法有两种：a) 在属性定义后加上关键字 Primary Key；b) 在属性表定义后加上额外的定义主码的子句：Primary Key（<主码属性名表>）说明：² 如果主码仅由一个属性组成，上述两种方法都可定义，若由两个或以上的属性组成，则只能用上述第二种方法定义了。 ² 对于候选码的说明方法，可以用Unique说明该属性的值不能重复出现。 Unique的使用与Primary Key相似。 ² 一个表中只能有一个主码定义，但可以有多个Unique说明。 ² SQL中，并没有强制为每个关系指定主码，但为每个关系指定主码通常会更好一些。 （因为主码的指定可以确保关系的实体完整性）3.1.2 参照完整性约束与外部码参照完整性是对关系间引用数据的一种限制。 即：若属性组A是基本关系R1的外码，它与基本关系R2的主码K相对应，则R1中每个元组在A上的值必须：要么取空值，要么等于R2中某元组的主码值。 一、外部码约束的说明：SQL中就是利用外部码的说明来实现参照完整性约束，限制表中某些属性的取值的。 外部码的说明也有两种方法：1、在该属性的说明后直接加上关键字”REFERENCES <表名>（<属性名>）”，其中表名称为参照关系名，属性名称为参照关系的主码。 2、在Create Table 语句的属性清单后，加上外部码说明子句，格式为：FOREIGN KEY <属性名表1> REFERENCES <表名>(<属性名表2>)上式中的属性名表1和属性名表2中属性可以多于一个，但必须前后对应。 二、参照完整性约束的实现策略前面讲了，外部码的取值只有两种情况：要么取空，要么取参照关系中的主码值。 可是当用户操作违反了这个规则时，如何保持此约束呢？SQL提供了三种可选方案：1、RESTRICT(限制策略)：当用户对表进行违反了上述完整性约束、条件的插入、删除或修改操作时，将会被系统拒绝。 2、CASCADE（级联策略）：当对参照关系进行删除和修改时，SQL所提供的一种方案。 在这种策略下，当删除或修改参照关系中某元组的主码值时，被参照关系中，那些外部码具有该值的元组也将被删除或修改，以保证参照完整性。 3、SET NULL（置空策略）：置空策略也是针对参照关系的删除或修改操作的。 在这种策略下，当删除参照关系中的某一元组或修改某一元组的主码值时，被参照关系中外码值等于该主码值的元组在该外码上的值将被置空说明：当用户不指定参照完整性的实现策略时，一般被默认为RESTRICT(限制策略)。 实现策略的说明通常被加在外部码的说明后面，格式为：ON DELETE SET NULL ON UPDATE CASCADE。 3.1.3 用户自定义完整性约束对于用户自定义完整性约束，SQL提供了非空约束、对属性的CHECK约束、对元组的CHECK约束、触发器等来实现用户的各种完整性要求。 1、非空约束：在CRETE TABLE 中的属性定义后面加上NOT NULL关键字即定义了该属性不能取空值。 2、基于属性的CHECK约束使用CHECK（检查）子句可保证属性值满足某些前提条件。 其一般格式为：CHECK（<条件>）它既可跟在属性定义的后面，也可在定义语句中另增一子句加以说明。 如：CHECK（age>=18 AND age<=65）; CHECK（sex IN (“男”,”女”)）; CHECK（dno IN(select dno from department)）;从上例中可以看出，CHECK子句的条件中还可以带子查询。 3、基于元组的CHECK约束基于元组的CHECK约束往往要涉及到表中的多个域。 所以它是元组约束。 在对整个元组完成插入或对某一元组的修改完成之后，系统将自动检查是否符合CHECK条件表达式。 若不符合条件，系统将拒绝该插入或修改操作。 基于元组CHECK约束的说明方法是在CREATE TABLE语句中的属性表、主码、外部码的说明之后加上CHECK子句。 3.1.4 约束的更新约束与数据库中的表和视图一样，可以进行增、删、改的更新操作。 为了改和删约束，需要在定义约束时对其进行命名，在各种约束的说明前加上关键字CONSTRAINT 和该约束的名称即可。 例如：在employee表的create table语句中：eno char(4) CONSTRAINT PK_employee PRIMARY KEY,dno char(4)CONSTRAINT FK_employee FOREIGN KEY REFERENCES department(dno);当对各种约束进行命名后，就可以用ALTER TABLE语句来更新与属性或表有关的各种约束。 如：ALTER TABLE employee DROP CONSTRAINT FK_employee;ALER TABLE Salary ADD CONSTRAINT RightSalary CHECK(Insure+Fund