2023年8月1日发(作者：)

实验⼆——数据库安全性定义与检查数据库安全性定义与检查⼀、 实验题⽬数据库安全性定义与检查⼆、 实验内容和要求安全性实验包含两个实验项⽬，其中1个为必修，1个为选修。⾃主存取控制实验为设计型实验项⽬，审计实验为验证型实验项⽬。两个实验的实验⽬的和内容如下：1. 掌握⾃主存取控制权限的定义和维护⽅法。2. 定义⽤户、⾓⾊，分配权限给⽤户、⾓⾊，回收权限，以相应的⽤户名登录数据库验证权限分配是否正确。选择⼀个应⽤场景，使⽤⾃主存取控制机制设计权限分配。3. 掌握数据库审计的设置和管理⽅法，以便监控数据库操作，维护数据库安全。4. 打开数据库审计开关。以具有审计权限的⽤户登陆数据库，设置审计权限，然后以普通⽤户登录数据库，执⾏相应的数据操纵SQL语句，验证相应审计设置是否⽣效，最后再以具有审计权限的⽤户登录数据库，查看是否存在相应的审计信息。三、 实验步骤（⼀） ⾃主存取控制实验实验定义⽤户、⾓⾊，分配权限给⽤户、⾓⾊，回收权限，以相应的⽤户名登录数据库验证权限分配是否正确。选择⼀个应⽤场景，使⽤⾃主存取控制机制设计权限分配。实验重点：定义⾓⾊，分配权限和回收权限。实验难点：实验⽅案⼆实现权限的再分配和回收。1. ⽅案⼀采⽤SYSTEM超级⽤户登录数据库，完成所有权限分配⼯作，然后⽤相应⽤户名登陆数据库以验证权限分配正确性；1.1. 查看SYSTEM超级⽤户‘root’的权限SYSTEM超级⽤户root含有所有的权限；1.2. 定义⽤户与删除⽤户使⽤CREATE USER进⾏⽤户的创建，使⽤IDENTIFIED BY语句设定⽤户的登陆密码。使⽤SHOW GRANTS FOR语句来进⾏⽤户权限的检查，结果如下，新创建的⽤户U1没有任何权限。删除⽤户的语句为DROP USER <⽤户名>，如下：注：对创建数据库模式⼀类的数据库对象的授权由管理员在创建⽤户时指定，未指定时默认为CONNECT权限，⽆法创建模式和基本表（因为没必要创建基本表因此这⾥默认使⽤CONNECT权限）。1.3. 定义⾓⾊、给⾓⾊授权与⾓⾊权限收回使⽤CREATE ROLE语句来进⾏⾓⾊的创建，使⽤GRANT语句来将权限给予⾓⾊；使⽤SHOW GRANTS来展⽰⾓⾊的权限：使⽤REVOKE语句可以收回赋予给ROLE的权限：可以看到此时INSERT权限从ROLE中回收；1.4. 赋予⽤户权限（授予权限与授予⾓⾊）授权可以通过两种⽅式，分别为直接授权以及授予⾓⾊，其中⾓⾊是权限的集合；执⾏第11条语句后，观察U1⽤户的权限：执⾏第12条语句后，观察U1⽤户的权限：1.5. 验证权限分配是否正确我们已知将R1⾓⾊（含UPDATE权限）以及权限SELECT赋予给了U1⽤户；此时登录⽤户U1进⾏测试：由于我们仅给U1对于student表的相关权限，因此⽤户U1仅能看到表student的信息，其余表都是透明的；1.5.1. 验证权限是否分配正确U1⽤户具有权限SELETE、⾓⾊R1，分别验证如下；① SELECT验证② ⾓⾊R1验证由于⾓⾊R1中仅含有UPDATE权限，因此直接验证即可：由于⾓⾊R1中仅含有UPDATE权限，因此直接验证即可：然⽽此时出现错误如下：可以看到，UPDATE权限并没有给⽤户U1！经过仔细的查找资料，最终在⼿册中找到原因，MySQL的⾓⾊创建后是需要进⾏激活，然后⾥⾯的权限才可以使⽤！因此，进⾏⾓⾊R1的激活（需要使⽤⾓⾊的⽤户激活）此时我们再次进⾏更新：同时可以看出更新操作成功！1.5.2. 验证⽤户是否会越权我们的U1仅仅含有SELECT与UPDATE权限，因此，如果进⾏插⼊与删除将会⽆法执⾏；① INSERT从结果可以看出U1没有插⼊权限！② DELETE从结果可以看出U1没有删除权限！③ 建表正如刚才所提的，创建的⽤户默认为CONNECT模式，该模式下我们的⽤户⽆法创建模式、基本表。⽆法创建，可以看出⽤户U1的数据库模式正常。1.6. 权限回收测试U1此时含有R1⾓⾊（含UPDATE权限），以及SELETE权限；① 回收R1⾓⾊中的UPDATE权限：需要超级⽤户进⾏再次进⾏更新年龄操作：此时⽤户U1进⾏UPDATE将不会成功：② 回收权限SELECT再次使⽤SELECT操作：2. ⽅案⼆采⽤SYSTEM⽤户登录数据库创建三个部门经理⽤户，并分配相应的权限，然后分别⽤三个经理⽤户名登录数据库，创建相应部门的USER, ROLE，并分配相应权限。根据实际情况，使⽤Mysql的⼀个⽰例数据库employees，其中包含多个表，是⼀个公司员⼯数据库的简单⽰例（但有⼤量数据），我们下⾯仅仅使⽤其中的salaries（⼯资表），employees（员⼯表）；我们假设有两个部门，财务部（后⾯缩写为Finance）专门管理⼯资表，有修改⼯资的权限；⼈事部（HR）管理员⼯表，有删除员⼯、加⼊员⼯、更新员⼯信息的权限；2.1. 创建部门经理⽤户这⾥因为部门经理需要创建⽤户，因此需要创建⽤户的权限；给与创建⽤户的权限有两种⽅式，⼀种是在创建⽤户时使⽤With DBA模式，DBA模式下的⽤户为超级模式（书中介绍的⽅法），另⼀种⽅法是在创建⽤户后，使⽤Grant语句更新该⽤户的权限列表中的Create_user_priv权限。如图，使⽤的更改权限⽅法，相⽐超级模式DBA安全⼀些。2.2. 创建⾓⾊并⾓⾊授予部门经理如图，将插⼊、更新⼯资表的权限给与⾓⾊R_FIN后给财务部门经理FINANCE，将插⼊、更新、删除员⼯表的权限给⾓⾊R_Hr后给与⼈事部门经理HR；为了使得该权限可以由经理赋给⽤户，需要将上with grant option选项。展⽰两者此时权限：同样的，注意激活两个⾓⾊！2.3. 部门经理创建相应的⽤户两个部门分别创建⼀个普通Hr_U、Fin_U；2.4. 部门经理给与⾃⼰创建的⽤户权限其中，Fin_U对表salaries拥有SELECT、INSERT权，但是没有DELETE权，且UPDATE的权利仅能在字段salary上；Hr_U拥有对employees的SELECT、INSERT、DELETE以及UPDATE字段first_name、last_name的权限。检查最后两个⽤户的权限：2.5. 检查权限① Employees—HR_U检查（SELETE正常）（UPDATE字段正常）（DELETE正常）（INSERT正常）给予的权限均正常；当我们越权更新（不能更新的字段）会失败。② Salaries—FIN_U检查除了我们给予的权限外，还有其它的操作是⽆权进⾏的：更新to_date、delect、select employees表都是⾮法的；2.6. 回收权限这⾥直接将经理的权限进⾏回收：此处回收update；此时，HR将⽆法将update给与HR_U：此时权限正常；由于我们刚开始HR给HR_U权限的⽅式为直接授权，此时HR_U的update权限并没有被拿⾛！（⼆） 审计实验打开数据库审计开关。以具有审计权限的⽤户登陆数据库，设置审计权限，然后以普通⽤户登录数据库，执⾏相应的数据操纵SQL语句，验证相应审计设置是否⽣效，最后再以具有审计权限的⽤户登录数据库，查看是否存在相应的审计信息。mysql本⾝并没有操作审计的功能，需要采⽤general log⽅法记录sql操作。⽹上的插件都是基于MySQL5.7版本的，由于我使⽤的是最新版8.21所以不是使⽤插件，⽽是使⽤mysql8.x提供的general log来实现审计功能。但是开启它有以下⼏个缺点⽆论sql有⽆语法错误，只要执⾏了就会记录，导致记录⼤量⽆⽤信息，后期的筛选有难度。Sql并发量很⼤时，log的记录会对io造成⼀定的印象，是数据库效率降低。⽇志⽂件很容易快速膨胀，不妥善处理会对磁盘空间造成⼀定影响。1. 查询审计配置情况2. 暂时打开全局审计3. 找到审计⽂件:ProgramDataMySQLMySQL Server 8.0Data⽬录下；4. Testdb数据库中的student表测试进⾏四种SELECT查询后观察log⽂件：可以观察到审计⽂件中的记录。5. 关闭审计

2023年8月1日发(作者：)

实验⼆——数据库安全性定义与检查数据库安全性定义与检查⼀、 实验题⽬数据库安全性定义与检查⼆、 实验内容和要求安全性实验包含两个实验项⽬，其中1个为必修，1个为选修。⾃主存取控制实验为设计型实验项⽬，审计实验为验证型实验项⽬。两个实验的实验⽬的和内容如下：1. 掌握⾃主存取控制权限的定义和维护⽅法。2. 定义⽤户、⾓⾊，分配权限给⽤户、⾓⾊，回收权限，以相应的⽤户名登录数据库验证权限分配是否正确。选择⼀个应⽤场景，使⽤⾃主存取控制机制设计权限分配。3. 掌握数据库审计的设置和管理⽅法，以便监控数据库操作，维护数据库安全。4. 打开数据库审计开关。以具有审计权限的⽤户登陆数据库，设置审计权限，然后以普通⽤户登录数据库，执⾏相应的数据操纵SQL语句，验证相应审计设置是否⽣效，最后再以具有审计权限的⽤户登录数据库，查看是否存在相应的审计信息。三、 实验步骤（⼀） ⾃主存取控制实验实验定义⽤户、⾓⾊，分配权限给⽤户、⾓⾊，回收权限，以相应的⽤户名登录数据库验证权限分配是否正确。选择⼀个应⽤场景，使⽤⾃主存取控制机制设计权限分配。实验重点：定义⾓⾊，分配权限和回收权限。实验难点：实验⽅案⼆实现权限的再分配和回收。1. ⽅案⼀采⽤SYSTEM超级⽤户登录数据库，完成所有权限分配⼯作，然后⽤相应⽤户名登陆数据库以验证权限分配正确性；1.1. 查看SYSTEM超级⽤户‘root’的权限SYSTEM超级⽤户root含有所有的权限；1.2. 定义⽤户与删除⽤户使⽤CREATE USER进⾏⽤户的创建，使⽤IDENTIFIED BY语句设定⽤户的登陆密码。使⽤SHOW GRANTS FOR语句来进⾏⽤户权限的检查，结果如下，新创建的⽤户U1没有任何权限。删除⽤户的语句为DROP USER <⽤户名>，如下：注：对创建数据库模式⼀类的数据库对象的授权由管理员在创建⽤户时指定，未指定时默认为CONNECT权限，⽆法创建模式和基本表（因为没必要创建基本表因此这⾥默认使⽤CONNECT权限）。1.3. 定义⾓⾊、给⾓⾊授权与⾓⾊权限收回使⽤CREATE ROLE语句来进⾏⾓⾊的创建，使⽤GRANT语句来将权限给予⾓⾊；使⽤SHOW GRANTS来展⽰⾓⾊的权限：使⽤REVOKE语句可以收回赋予给ROLE的权限：可以看到此时INSERT权限从ROLE中回收；1.4. 赋予⽤户权限（授予权限与授予⾓⾊）授权可以通过两种⽅式，分别为直接授权以及授予⾓⾊，其中⾓⾊是权限的集合；执⾏第11条语句后，观察U1⽤户的权限：执⾏第12条语句后，观察U1⽤户的权限：1.5. 验证权限分配是否正确我们已知将R1⾓⾊（含UPDATE权限）以及权限SELECT赋予给了U1⽤户；此时登录⽤户U1进⾏测试：由于我们仅给U1对于student表的相关权限，因此⽤户U1仅能看到表student的信息，其余表都是透明的；1.5.1. 验证权限是否分配正确U1⽤户具有权限SELETE、⾓⾊R1，分别验证如下；① SELECT验证② ⾓⾊R1验证由于⾓⾊R1中仅含有UPDATE权限，因此直接验证即可：由于⾓⾊R1中仅含有UPDATE权限，因此直接验证即可：然⽽此时出现错误如下：可以看到，UPDATE权限并没有给⽤户U1！经过仔细的查找资料，最终在⼿册中找到原因，MySQL的⾓⾊创建后是需要进⾏激活，然后⾥⾯的权限才可以使⽤！因此，进⾏⾓⾊R1的激活（需要使⽤⾓⾊的⽤户激活）此时我们再次进⾏更新：同时可以看出更新操作成功！1.5.2. 验证⽤户是否会越权我们的U1仅仅含有SELECT与UPDATE权限，因此，如果进⾏插⼊与删除将会⽆法执⾏；① INSERT从结果可以看出U1没有插⼊权限！② DELETE从结果可以看出U1没有删除权限！③ 建表正如刚才所提的，创建的⽤户默认为CONNECT模式，该模式下我们的⽤户⽆法创建模式、基本表。⽆法创建，可以看出⽤户U1的数据库模式正常。1.6. 权限回收测试U1此时含有R1⾓⾊（含UPDATE权限），以及SELETE权限；① 回收R1⾓⾊中的UPDATE权限：需要超级⽤户进⾏再次进⾏更新年龄操作：此时⽤户U1进⾏UPDATE将不会成功：② 回收权限SELECT再次使⽤SELECT操作：2. ⽅案⼆采⽤SYSTEM⽤户登录数据库创建三个部门经理⽤户，并分配相应的权限，然后分别⽤三个经理⽤户名登录数据库，创建相应部门的USER, ROLE，并分配相应权限。根据实际情况，使⽤Mysql的⼀个⽰例数据库employees，其中包含多个表，是⼀个公司员⼯数据库的简单⽰例（但有⼤量数据），我们下⾯仅仅使⽤其中的salaries（⼯资表），employees（员⼯表）；我们假设有两个部门，财务部（后⾯缩写为Finance）专门管理⼯资表，有修改⼯资的权限；⼈事部（HR）管理员⼯表，有删除员⼯、加⼊员⼯、更新员⼯信息的权限；2.1. 创建部门经理⽤户这⾥因为部门经理需要创建⽤户，因此需要创建⽤户的权限；给与创建⽤户的权限有两种⽅式，⼀种是在创建⽤户时使⽤With DBA模式，DBA模式下的⽤户为超级模式（书中介绍的⽅法），另⼀种⽅法是在创建⽤户后，使⽤Grant语句更新该⽤户的权限列表中的Create_user_priv权限。如图，使⽤的更改权限⽅法，相⽐超级模式DBA安全⼀些。2.2. 创建⾓⾊并⾓⾊授予部门经理如图，将插⼊、更新⼯资表的权限给与⾓⾊R_FIN后给财务部门经理FINANCE，将插⼊、更新、删除员⼯表的权限给⾓⾊R_Hr后给与⼈事部门经理HR；为了使得该权限可以由经理赋给⽤户，需要将上with grant option选项。展⽰两者此时权限：同样的，注意激活两个⾓⾊！2.3. 部门经理创建相应的⽤户两个部门分别创建⼀个普通Hr_U、Fin_U；2.4. 部门经理给与⾃⼰创建的⽤户权限其中，Fin_U对表salaries拥有SELECT、INSERT权，但是没有DELETE权，且UPDATE的权利仅能在字段salary上；Hr_U拥有对employees的SELECT、INSERT、DELETE以及UPDATE字段first_name、last_name的权限。检查最后两个⽤户的权限：2.5. 检查权限① Employees—HR_U检查（SELETE正常）（UPDATE字段正常）（DELETE正常）（INSERT正常）给予的权限均正常；当我们越权更新（不能更新的字段）会失败。② Salaries—FIN_U检查除了我们给予的权限外，还有其它的操作是⽆权进⾏的：更新to_date、delect、select employees表都是⾮法的；2.6. 回收权限这⾥直接将经理的权限进⾏回收：此处回收update；此时，HR将⽆法将update给与HR_U：此时权限正常；由于我们刚开始HR给HR_U权限的⽅式为直接授权，此时HR_U的update权限并没有被拿⾛！（⼆） 审计实验打开数据库审计开关。以具有审计权限的⽤户登陆数据库，设置审计权限，然后以普通⽤户登录数据库，执⾏相应的数据操纵SQL语句，验证相应审计设置是否⽣效，最后再以具有审计权限的⽤户登录数据库，查看是否存在相应的审计信息。mysql本⾝并没有操作审计的功能，需要采⽤general log⽅法记录sql操作。⽹上的插件都是基于MySQL5.7版本的，由于我使⽤的是最新版8.21所以不是使⽤插件，⽽是使⽤mysql8.x提供的general log来实现审计功能。但是开启它有以下⼏个缺点⽆论sql有⽆语法错误，只要执⾏了就会记录，导致记录⼤量⽆⽤信息，后期的筛选有难度。Sql并发量很⼤时，log的记录会对io造成⼀定的印象，是数据库效率降低。⽇志⽂件很容易快速膨胀，不妥善处理会对磁盘空间造成⼀定影响。1. 查询审计配置情况2. 暂时打开全局审计3. 找到审计⽂件:ProgramDataMySQLMySQL Server 8.0Data⽬录下；4. Testdb数据库中的student表测试进⾏四种SELECT查询后观察log⽂件：可以观察到审计⽂件中的记录。5. 关闭审计