续上文，等保2.0涉及的PostgreSQL数据库上

应对登录的用户分配账户和权限

针对这个测评项，首先我们要搞清楚postgresql数据库的相应权限问题

在postgresqll数据库中，认为用户就是一个相应的role，PostgreSQL使用角色的概念管理数据库访问权限。一个角色可以被看成是一个数据库用户或者是一个数据库用户组，这取决于角色被怎样设置。角色可以拥有数据库对象（例如，表和函数）并且能够把那些对象上的权限赋予给其他角色来控制谁能访问哪些对象。此外，还可以把一个角色中的成员资格授予给另一个角色，这样允许成员角色使用被赋予给另一个角色的权限。

1.系统权限

1.1 role属性

可以认为是这个用户所具有的系统权限.

• LOGIN --具有登录权限
• SUPERUSER --超级用户,具有所有系统权限,除了登录验证
• CREATEDB --创建数据库权限
• CREATEROLE --创建role权限
• PASSWORD --设置密码

1.2 修改属性

创建test角色

create role test login;

alter role test createdb createrole password '****@123';

alter role test nocreatedb nocreaterole superuser;

通过psql程序登录可使用\du命令列出现有角色，以及相应的角色权限

2.role成员权限

role membership（role成员）为了管理上的方便，我们可以创建一个role group，然后可以将各用户或者有特殊权限的role组织在一起，各个role就是这个role group的membership.

role group 是不带login的role，因为pg使用role来表示所有的角色、用户、用户组，所以不要混淆，创建语句都是create role.

2.1 继承role group

1）直接继承

我们创建一个用户，两个角色，分别有直属一个表的查询权限create role jack login inherit;create role r1;create role r2;

然后创建对应的表

授予查询权限

进行grant授权，使jack成为r1，r2的membership

测试角色切换

jack 继承了r1,r2的权限

2）间接继承

移除membership

可以使用revoke group_role from role1,…命令

此时，r1属于r2，然后jack又属于r1

关闭r1的继承

alter role r1 noinherit;

然后再尝试访问tab，发现tab2无法访问取消继承权限后，r1也无权限访问

移除后将无权限

注意：授权不能形成回路

3）系统权限任何时候都不会主动继承

系统权限不会继承，只有主动set才生效

使用set命令后，该会话会具有group_role的临时系统权限，且会被认为是group_role角色，创建的表之类的均为set role的权限

重新开启会话后，无权限

三种方式还原到最初的jack角色：

综上所述：角色属性login、superuser、createdb和createrole可以被认为是一种特殊权限，但是它们从来不会像数据库对象上的普通权限那样被继承。要使用这些属性，你必须实际set role到一个有这些属性之一的特定角色。

4）角色删除

删除role，role下有权限或者是对象属于此role，则删除不了

移除掉相关权限关联后进行删除，然后涉及到r1的成员或者是group_role自动释放

5）role总结

• pg中的role包含了用户，角色，角色组，成员等所有含义，如使用create role来创建
• 一个role可以成为多个role的成员，根据role的inherit属性来决定是否集成其他role的各种权限
• 继承关系不能形成回路
• 删除role需要先清理此role关联的各种权限

3.等保查看相应点

查看当前数据库内有哪些角色，可通过工具进行查看

个人认为，针对之一个条款，不管权限分配是否合理，只要给用户分配权限了就算符合

这条条款主要是为了防止匿名用户的登录，像NTP匿名登录那种

至于权限是否合理，已在后面的最小权限，管理用户的权限分离，访问控制粒度的地方体现，应在那些条款内去判断，所以对于之一条我们只要看他是否为用户分配了相应的账户和权限即可。

应重命名或删除默认账户，修改默认账户的默认口令

1.默认角色

可以通过工具进行查看

PostgreSQL提供一组默认角色， 他们可以访问特定的、通常需要的特权功能和信息。 管理员可以将这些角色 GRANT 给用户和/或其环境中的其他角色， 为这些用户提供对指定功能和信息的访问权限。请注意，每个默认角色的特定权限可能会因为将来添加额外的功能而发生变化。 管理员应监控发行说明以进行更改，如下图：

角色	允许的权限
pg_read_all_settings	阅读所有配置变量，即使那些通常只对超级用户可见的配置变量。
pg_read_all_stats	阅读所有pg_stat_*视图并使用各种统计相关的扩展，甚至那些通常只对超级用户可见的扩展。
pg_stat_scan_tables	执行可能对表进行可能需要很长时间ACCESS SHARE锁定的监视功能。
pg_signal_backend	给其他后端发送信号(比如: 取消查询、终止)。
pg_monitor	读取/执行各种监视视图和函数。 此角色是pg_read_all_settings、?pg_read_all_stats和?pg_stat_scan_tables的成员。

pg_mointor、pg_read_all_settings、pg_read_all_stats和pg_scan_tables角色旨在允许管理员轻松配置角色以见识数据库服务器。他们授予一组通用权限，允许角色读取通常仅限于超级用户的各种有用的配置设置，统计和其他系统信息。应小心授予这些角色，以确保只在需要执行所需监视的情况下才会使用这些角色。管理员可以使用grant命令给这些用户授予访问权限：grant pg_signal_backend to admin_user;上述的的默认角色默认都是不可登录的。

2. 等保查看相应点

默认账户为postgres，查看其是否设置禁止登录，或将其重命名在psql的程序下可以通过\du命令查看，无法登录将有cannot login字样