实验3：数据库安全性定义与检查

实验3.1实体完整性实验

（1）实验目的

掌握实体完整性的定义和维护方法。

（2）实验内容和要求

定义实体完整性，删除实体完整性。能够写出两种方式定义实体完整性的SQL语句：创建表时定义实体完整性、创建表后定义实体完整性。设计SQL语句验证完整性约束是否起作用。

（3）实验重点和难点

实验重点：创建表时定义实体完整性。

实验难点：有多个候选码时实体完整性的定义。

 

（3.1.1）单个候选码的完整性定义：

 


			
-- ----------------------------

			
-- Table structure for food

			
-- ----------------------------

			
DROP TABLE IF EXISTS `food`;

			
CREATE TABLE `food` (

			
  `food_id` int(10) NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT '美食ID',

			
  `food_name` varchar(20) NOT NULL COMMENT '美食名称',

			
  `food_num` int(10) NOT NULL COMMENT '美食被多少篇游记提到',

			
  `city_id` int(10) NOT NULL COMMENT '城市ID',

			
-- 单个候选码 定义表时创建。

			
--  PRIMARY KEY (`food_id`)

			
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

			
 
			
		
 

（3.1.2）多个候选码的完整性定义：

在表定义完成后创建：

alter table user add constraint p_key primary key(id,name)；



 


			
-- ----------------------------

			
-- Table structure for food

			
-- ----------------------------

			
DROP TABLE IF EXISTS `food`;

			
CREATE TABLE `food` (

			
  `food_id` int(10) NOT NULL AUTO_INCREMENT COMMENT '美食ID',

			
  `food_name` varchar(20) NOT NULL COMMENT '美食名称',

			
  `food_num` int(10) NOT NULL COMMENT '美食被多少篇游记提到',

			
  `city_id` int(10) NOT NULL COMMENT '城市ID',

			
-- 多个候选码 定义表时创建。

			
PRIMARY KEY (`food_id`,’food_name’)

			
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

			
 
			
		
（3.1.3）在表创建完成后，定义实体完整性

 

sql语句格式如下：

alter table 表名
add constraint 主键名称 primary key (字段)

在上述例子中：

添加完整性约束：

alter table food add constraint p_key primary key(food_id,food_name);

删除完整性约束：alter table table_name drop primary key;

（3.1.4）对主键定义的检查

user表已有数据





 

实验3.2 参照完整性实验 

（1）实验目的

掌握参照完整性的定义和维护方法。

（2）实验内容和要求

定义参照完整性，定义参照完整性的违约处理，删除参照完整性。写出两种方式定义参照完整性的SQL语句：创建表时定义参照完整性、创建表后定义参照完整性。

（3）实验重点和难点

实验重点：创建表时定义参照完整性。

实验难点：参照完整性的违约处理定义。

（3.2.1）创建一个参照完整性

在创建表单时定义参照完整性：

CONSTRAINT 约束名称 FOREIGN KEY (字段名) REFERENCES  表单名 (字段名)

 


			
-- ----------------------------

			
-- Table structure for food

			
-- ----------------------------

			
DROP TABLE IF EXISTS `food`;

			
CREATE TABLE `food` (

			
  `food_id` int(10) NOT NULL AUTO_INCREMENT COMMENT '美食ID',

			
  `food_name` varchar(20) NOT NULL COMMENT '美食名称',

			
  `food_num` int(10) NOT NULL COMMENT '美食被多少篇游记提到',

			
  `city_id` int(10) NOT NULL COMMENT '城市ID',

			
PRIMARY KEY (`food_id`,’food_name’),

			
CONSTRAINT con_key FOREIGN KEY (city_id)  REFERENCES  city (city_id)

			
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

			
 
			
		
（3.2.2）定义一个参照完整性的检查

--检查约束
alter table food check constraint con_key;

（3.2.3）创建表后的定义和删除操作

定义外键：

alter table food add constraint con_key FOREIGN KEY(city_id) REFRENCES city(city_id);

删除外键：

alter table food drop con_key;

 

实验3.3 用户自定义完整性实验 

（1）实验目的

掌握用户自定义完整性的定义和维护方法。

（2）实验内容和要求

针对具体应用语义，选择NULL/NOT NULL、DEFAULT，UNIQUE、CHECK等，定义属性上的约束条件。

（3）实验重点和难点

实验重点：NULL/NOT NULL, DEFAULT。

实验难点：CHECK。

 


			
CREATE TABLE `spot` (

			
  `spot_id` int(10) NOT NULL AUTO_INCREMENT COMMENT '景点ID',

			
  `spot_name` varchar(20) NOT NULL COMMENT '景点名称',

			
  `city_id` int(10) NOT NULL COMMENT '城市ID',

			
  `spot_lat` double(10,6) NOT NULL COMMENT '景点经度',

			
  `spot_lng` double(10,6) NOT NULL COMMENT '景点纬度',

			
  `spot_num` int(10) NOT NULL DEFAULT '0' COMMENT '景点被访问次数',

			
  `spot_ticket` varchar(255) DEFAULT NULL COMMENT '景点门票',

			
  `spot_timeref` varchar(20) DEFAULT NULL COMMENT '景点用时参考',

			
  `spot_opentime` varchar(255) DEFAULT NULL COMMENT '景点开放时间',

			
  `spot_conference` varchar(255) DEFAULT NULL COMMENT '关联景点',

			
  PRIMARY KEY (`spot_id`)

			
) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=utf8;
			
		
（3.3.1）用户自定义完整性约束示例：

 

（3.3.2）定义CHECK约束

定义表时的定义的CHECK约束：

constraint ck_age check (id<10);

constraint ck_tel check (LENGTH（tel）=11)；

定义表后新增的CHECK约束：



但是在结果检查中发现Mysql中的CHECK语句存在无效化：



上网查找资料后发现Mysql中的CHECK语句是会被忽略的，所以一般用触发器或者数量较少时用枚举来限定数据。

例子：

（1）触发器

DELIMITER $$

CREATE TRIGGER TestField1_BeforeInsert BEFORE INSERT ON user

FOR EACH ROW

BEGIN

IF NEW.id > 0 THEN

SEca = 0;

END IF;

END$$

又因为id是主键，id等于0已有的情况下，语句都会插入不成功。

（2）枚举

create table user (sex enum('男','女'),b int,id int,primary key(id));

这样子表单sex只允许插入’男’或者’女’。

WEP ：最古老的的无线安全标准，早已被破解

WPA/WPA2：较复杂，需要单独架一台认证服务器，比较昂贵，所以一般不推荐，

WPA-PSK/WPA2-PSK：是上面标准的简化版本，安全性较高，而且设置也相对较简单呢，所以推荐一般小企业或家用。



 

定义
定义访问权限集是一项分配至责任层的可选的安全功能，是对Oracle 11i应用产品弹性域安全性定义的功能扩展，对总帐管理模块的一些内容进行安全性定义和权限分配的集合，以控制不同的责任对一些内容的访问权限，如成批分配、经常性日记帐公式和财务报表生成器 (FSG) 组件。系统预置了一个“超级用户定义访问权限集”（不可修改）。如下图：

目的
· 为用户或用户组分配对特定定义的访问权限。
· 为用户或用户组指定可以对受保护定义执行的活动。
例如，可以保护 FSG 报表，允许一些用户修改报表定义，一些用户只能查看报表定义，而另一些用户可以修改、查看和提交报表。
说明
权限分配：通过为用户分配对定义访问权限集的以下一项或多项权限，可以控制哪些用户拥有定义的访问权限：
·         使用：允许用户在流程或报表中使用定义，如“FSG 报表组件”、“经常性日记帐”和“成批分配”定义。它还允许用户使用定义创建另一个定义，如使用经常性日记帐创建成批分配集或使用 FSG 报表组件创建 FSG 报表。
如果用户只具有定义的“使用”权限，该用户将无法查看或修改定义。例如，如果用户只具有“成批分配”定义的“使用”权限，该用户可以在“生成成批分配日记帐”窗口中使用“成批分配”生成日记帐，但是不能在“定义成批分配”窗口中查看或修改定义。
·   查看：允许用户查看定义。
如果用户只具有定义的“查看”权限，该用户将无法使用或修改定义。如果“自动复制”是为该特定定义提供的一项功能，用户将无法使用“自动复制”创建定义的副本。该权限允许用户根据现有定义创建定义，但是不能更改原始定义。
·   修改：允许用户查看和修改定义。“修改”权限自动包括“查看”权限。
如果用户只具有定义的“修改”权限，该用户将无法使用该定义。
注：一个或多个定义访问权限集可以分配给一个或多个责任。如果一个用户拥有多个分配了保护相同定义的多个定义访问权限集的责任，他/她将获得该定义的所有权限综合后的权限。
 使用：
要使用定义访问权限集安全性，请执行以下操作：
1.创建定义访问权限集。
2.  将其分配给一个或多个责任。
3.  创建定义。
4.  在其各自的窗口中保护定义，然后使用相应的权限将其分配给定义访问权限集。
适用内容范围：
以下列示了Oracle 应用产品可设置定义访问权限集的类型。
 
注：定义访问权限集和数据访问权限集是相互独立的。例如： GL-用户（分配的定义访问权限集）可以定义经常性日记账，只有在其配置文件：GL：数据访问权限集可以访问创建该日记帐的平衡段或管理段的情况下，才可以创建相应的日记帐
前提条件：
勾选定义的类型‘启用安全性’
关联-报表
定义访问权限集报表
可以使用以下可从“提交请求”窗口中提交的报表之一查看定义访问权限集和受保护定义的列表：
·         定义访问权限集列表：此报表列出已经分配至特定定义访问权限集的所有定义及其权限。
·         按用户列出的定义访问权限：此报表列出已经分配至特定用户的定义访问权限集的受保护定义及其权限。
定义步骤：
   以FSG列集的安全性为例，进行定义并分配至相应的责任。
  举例如下：定义访问权限集test1222，指定FSG列集：Monthly Actual的权限为‘查看’‘修改’，将其分配至SH GL用户，则SH GL用户不能使用FSG列集：Monthly Actual，  只能查看和修改。
1.       定义访问权限集
路径：设置à财务系统à定义访问权限集à定义
注：1.此时‘定义类型’和‘定义名称’虽然为黄色栏位（Oracle定义为可输入区域），但此二栏不能手工输入，待定义类型安全性定义和权限分配完成后此二栏位自动产生。
    2.权限区域的‘使用’‘查看’‘修改’栏位由‘定义类型’（比如FSG列集）分配的安全性权限更新。二权限区域同步更新。
1.        分配至责任
   路径：设置à财务系统à定义访问权限集à分配


来自：http://blog.itpub.net/298600/viewspace-625141/

如何定义一个PRG是否安全？


  
PRG是将一个从{0,1}s中随机 抽取的字符串k映射到{0,1}n上的算法。


当然，由于{0,1}s的数量(2^s)远远小于{0,1}n的数量(2^n)，PRG又是一一映射，因此G(k)只是{0,1}n的极小一部分。 

因此，如果G(k)的分布和真正的{0，1}n上的均匀分布无法分辨(indistinguishable)，就称 PRG是一种安全的算法。因为在这种情况下，G(k)的每一位和其他位都是独立的，无法根据几位推测出另一位。



如何让G(k)伪装成{0,1}n上的均匀分布？

检验标准：找不到对于G有效的分辨算法A。

何为分辨算法A？


  
判断一个{0,1}n是否是随机生成的




 $$\begin{equation}
A(x)=\left\{
\begin{aligned}
1 & & {A \ think \ x \ is \ random}\\ 
0 & & {A \ think \ x \ is \ not \ random}\\
\end{aligned}
\right.
\end{equation}$$ 


何为有效的分辨算法？

衡量指标：advantange 

$Adv(A,G)=|P(A(x: x \in G(k)))-P(A(x: x \in 0,1n))|$ 

$Adv(A,G) \in [0,1]$ 

越靠近0，说明分辨算法A越难将经过G加密的key和随机生成的{0，1}n分辨开来。 

越靠近1，越容易分辨，说明A对于G这种PRG是有效的。 

绝对安全的PRG，是找不到能够将其和均匀分布分辨开来的这样的算法A的。



是否存在这样绝对安全的PRG？

布吉岛。 

存在绝对安全的PRG=>P!=NP

某个PRG是安全的，当且仅当它是不可预测的

回顾定义： 

安全：不存在能够将其与均匀分布分辨的方法 

不可预测：无法从前i位推测第i+1位 

可预测=>不安全的证明： 

如果一个PRG是可预测的，那么存在某个整数i（1<=i<=n）和某种算法A，使得第1,2,……i位可以预测第i+1位，即：
 $$P(A(x|_{1,2,3……i})=x_{i+1})=1/2+\epsilon \\ \epsilon \ is \ non-neg$$  

那么，存在相应的分辨算法B，能够将这个PRG映射之后的G(k)和普通的均匀分布分辨出来： 

 $$\begin{equation}
B(x)=\left\{
\begin{aligned}
1 & & {if \ B(x|_{1，2，……i })}=x_{i+1}\\ 
0 & & {else}\\
\end{aligned}
\right.
\end{equation}$$  

直观地理解：B算法根据A算法的结果决定自己的输出。如果A算法成功预测，则当前的{0,1}n来自一个人工制造的PRG可能性更大；反之，更可能来自均匀分布。 

于是：$P(B(G(k))=1)=1/2+\epsilon$   ，而对于随机生成的字符串r，由于$x_{1,2,……,i}和x_{i+1}独立，因此A(x_{1,2……,i})与x_{i+1}独立，所以$$P(B(r)=1)=1/2$ 

两者相差$\epsilon$，这不是一个可以忽略的量。于是B就是那个可以把G(k)和r分辨的算法。 

直观地理解：如果存在一个足够好的预测算法A，就存在一个足够好的分辨算法B。 

如果不存在一个足够好的分辨算法B，就不存在一个足够好的预测算法A。 

不安全->不可测: 

描述：如果一个{0,1}n，对于$\forall i \in [1,n],都无法通过x|_{1,2,……i}预测x_{i+1}$，那么也不存在一个算法能够证明这个01串是来自PRG制造还是随机生成的。 

证明：略。