This article is shared from the Huawei Cloud Community " GaussDB (DWS) 3A Security Capabilities ", author: yd_281561943.
1 Introduction
- Applicable version: [8.0.0 (and above)]
Database security refers to the technology that protects databases to prevent unauthorized users from stealing, tampering with, and destroying data information in the database. Database security technology can be simply divided into three A’s:
- Authentication: Authentication solves the problem of who is allowed in (entry)
- Authorization: Authorization to solve the problem of what can be done (work)
- Audit: Audit solves the problem of what has been done (monitoring)
2. Authentication——Authentication
Connection authentication solves the problem of whether users can log in to the database. This product supports the following authentication methods:
- Host-based authentication: The server checks the configuration file based on the client's IP address, user name and the database to be accessed to determine whether the user has passed the authentication.
- Password authentication: including encrypted password authentication for remote connections and non-encrypted password authentication for local connections.
- Certificate authentication: This mode requires SSL connection configuration and the client needs to provide a valid SSL certificate, and no user password is required.
- Third-party authentication: ldap, oneaccess, etc.
These methods all need to configure the "pg_hba.conf" file, pg_hba.conf file format, pg_hba consists of several lines of HBA records:
The meaning of an HBA record is which users (USER) are allowed, from which IP addresses (ADDRESS), in which connection type (TYPE), in which authentication method (METHOD), and to which databases (DATABASE) to connect.
During authentication, the records in the hba file are checked from bottom to bottom for each connection request. If the current record matches, it is returned. The order of HBA records is very critical. This logic of hba is very important and should not be changed easily, otherwise it will cause very serious problems.
Case: Problems caused by hba logic changes
There was a problem with the ldap connection. During the upgrade process, the records in the pg_hba.conf file were sorted, causing the order of the ldap configuration lines before and after the upgrade to change to the end of the sha256 configuration line. Due to the sequential traversal mechanism of pg_hba.conf, after the upgrade, the ldap user incorrectly matches the sha256 configuration line and the connection fails.
In order to solve the problems caused by the order change, the first version of the modification plan is to place the ldap judgment logic at the beginning of the loop traversal: first look at the authentication type. If it is ldap authentication, judge whether the method field of the configuration line is ldap. If not, jump to The next line is until the method is found to be ldap.
Under this version of the modification plan, ldap authentication connections match all ldap hba records. When the user connects to the database, the connection can be successful, but the business cannot be performed, and an error message is reported: "Invalid username/password, login denied.". The reason is that when internal nodes execute statements, authentication between nodes will be performed. The authentication type is trust and no password will be provided. After modification, only ldap records will be matched, and the ldap method requires a password, thus reporting an error.
Before and after the upgrade, the locations of the ldap and sha256 configuration lines are as follows:
Before upgrading: host all @/etc/ldap/ldap_user 0.0.0.0/0 ldap ldapserver=xxx.xxx.xxx.xxx ldapport=xxx ldapprefix="CN=" ldapsuffix="OU=test_dmj_group,DC=com" host all all 0.0.0.0/0 sha256 After upgrade: host all all 0.0.0.0/0 sha256 host all @/etc/ldap/ldap_user 0.0.0.0/0 ldap ldapserver=xxx.xxx.xxx.xxx ldapport=xxx ldapprefix="CN=" ldapsuffix="OU=test_dmj_group,DC=com"
TYPE : type is one of four types: local, host, hostssl, and hostnossl.
Respectively:
local: Only unix domain socket connections are allowed.
host: allows TCP/IP connections and can match SSL and non-SSL connection requests.
hostssl: Allows TCP/IP connections and only matches SSL connection requests.
hostnossl: Allow TCP/IP connections and only match non-SSL connection requests.
DATABASE : You can use all to represent all databases, or you can specify databases explicitly by separating them with commas.
USER : You can use all to represent all users, or you can specify users explicitly by separating them with commas. Can be the name of a specific database user or a group name preceded by +. The + mark actually means "match any role that belongs directly or indirectly to this role", whereas a name without the + mark only matches that specific role.
ADDRESS : The address that the declaration record matches and allows access to. When type is local, it means local connection and no IP address needs to be specified.
METHOD : Authentication methods include trust, reject, md5, sha256, ldap, cert, oneaccess, etc.
trust: whitelist, allowing connections unconditionally.
Reject: blacklist, unconditionally rejects connections.
md5: pg's password authentication method is not safe.
sha256: Password authentication for gaussdb.
ldap: Use LDAP for third-party authentication.
cert: Client certificate authentication mode. This mode requires SSL connection configuration and requires the client to provide a valid SSL certificate. No user password is required.
oneaccess: Use oneaccess for third-party authentication.3.Authorization——Authorization
Permissions indicate whether a user's operations on a database object are allowed. Permissions in GaussDB (DWS) include three scenarios: system permissions, data object permissions, and user permissions.
3.1 System permissions
3.1.1 Separation of powers
By default, system administrators with the SYSADMIN attribute have the highest authority on the system. In actual business management, in order to avoid high risks caused by excessive concentration of rights of system administrators, separation of powers can be set up, and the system administrator's CREATEROLE attribute and AUDITADMIN attribute permissions are given to the security administrator and the audit administrator respectively.
3.1.2 System permission authorization
System permissions are also called user attributes, including SYSADMIN, CREATEDB, CREATEROLE, AUDITADMIN and LOGIN.
System permissions can be authorized when creating or modifying roles or users. In the option of the CREATE/ALTER ROLE/USER user_name [WITH] option statement, the following fields can be set to implement system permission authorization.
SYSADMIN | NOSYSADMIN
Determine whether a new role is a "system administrator". The role with the SYSADMIN attribute has the highest authority on the system. The default is NOSYSADMIN.
AUDITADMIN | NOAUDITADMIN
Define whether the role has audit management attributes. The default is NOAUDITADMIN.
CREATEDB | NOCREATEDB
Determines whether a new role can create databases. The new role does not have permission to create databases. The default is NOCREATEDB.
CREATEROLE | NOCREATEROLE
Determines whether a role can create new roles (that is, execute CREATE ROLE and CREATE USER). A role with CREATEROLE permissions can also modify and delete other roles. The default is NOCREATEROLE.
LOGIN | NOLOGIN
Only roles with the LOGIN attribute can log in to the database. A role with the LOGIN attribute can be considered a user. The default is NOLOGIN.3.2 Data object permissions
Data objects include tables and views, designated fields, databases, functions, schemas, etc. Operations such as creating, adding, deleting, modifying, and querying them are data object permissions. The authorization syntax format is: GRANT [privileges] ON [objects] TO [users], and the permission revocation syntax format is REVOKE [privileges] ON [objects] FROM [users].
3.3 User permissions
3.3.1 User rights authorization
Grant the permissions of one role or user to one or more other roles or users. An authorized role or user has the permissions of the authorized role or user. When WITH ADMIN OPTION is declared, the authorized user can grant the permission again to other roles or users, and revoke all permissions inherited by the role or user. When an authorized role or user is changed or revoked, the permissions of all users who inherit the role or user permissions will be changed accordingly. The syntax format is GRANT role TO user.
3.3.2 Preset roles
GaussDB (DWS) provides a set of preset roles, named starting with "gs_role_". These preset roles have some fixed permissions. When some users need to perform related operations, they only need to grant the preset roles to the users. The current preset roles of GaussDB (DWS) are as follows:
4.Audit——Audit
Auditing refers to recording the user's login and exit as well as the behavior and operations in the database after login, so that the database security administrator can use these log information to find out the user, time and content of illegal operations.
4.1 Set audit configuration items
To enable the database to audit a certain function, you need to turn on the audit main switch (audit_enabled) and the corresponding audit item switch (audit_operation_exec). Both support dynamic loading. Modifying the value of this configuration item during database operation will take effect immediately. No need to restart the database.
There are two points to note. First, if you audit ddl operations, you need to configure audit_system_object to audit the ddl operations of a specific object. Second, if you audit a transaction, whether the operations within the transaction are audited depends on whether the specific configuration items are configured. Parameter control of audit items:
4.2 View audit logs
The audit query command is pgxc_query_audit:
select * from pgxc_query_audit(timestamptz startime,timestamptz endtime,audit_log);
startime and endtime respectively represent the start time and end time of the audit record. audit_log represents the new physical file path of the audit log being viewed. When audit_log is not specified, the audit log information connected to the current instance is viewed by default. The audit query results are as follows:
postgres=# create table t1(id int);
ERROR: relation "t1" already exists
postgres=# select * from pgxc_query_audit('2021-03-21','2021-03-30') order by endtime desc limit 1;
-[ RECORD 1 ]---+--------------------------------
starttime | 2021-03-21 11:49:41.643+08
end time | 2021-03-21 11:49:41.652+08
operation_type | ddl
audit_type | ddl_table
result | failed
username | perfadm
database | postgres
client_conninfo | gsql@[local]
object_name | t1
command_text | create table t1(id int);
detail_info | relation "t1" already exists
transaction_xid | 0
query_id | 1062177
node_name | cn_5001
thread_id | 139916885260032@669613657906735
local_port | 6000
remote_port |
5. Other data warehouse security technologies
Data security display: data desensitization, row-level access control.
Data security storage: data storage encryption, transparent encryption.
Click to follow and learn about Huawei Cloud’s new technologies as soon as possible~