No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CloudEC V600R019C00 Security Maintenance (Enterprise On-premises, Only Conference)

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
USM-EUA

USM-EUA

Data Security Maintenance Suggestions

You are advised to perform the following operations to ensure data security in the GaussDB database and prevent data loss and illegal data accesses.

Preventing Data Loss
  • You are advised to deploy the GaussDB in HA mode. In this case, if the primary GaussDB is faulty, the standby GaussDB can take over services on the primary GaussDB in a timely manner, ensuring high-reliability database services.
  • You are advised to periodically plan physical backup and store backup files in a reliable medium. If a serious error occurs in the system, you can use the backup files to recover the system to the state at the backup point.
Preventing Illegal Data Accesses
  • You are advised to manage database users according to their permission hierarchies. A database administrator can create user accounts and grant corresponding permissions to them based on service requirements to ensure proper data access.
  • Based on product requirements, the GaussDB HA system is deployed on a trusted network with the internal IP address used. The two servers of the GaussDB HA system are preferentially connected using a network cable or an internal port in the subrack to maximally ensure the data transmission efficiency. You are advised to deploy the server and client (or program developed based on the client) of the GaussDB on a trusted network. If the servers and clients need to be deployed on an untrusted network, you must enable the SSL encryption function before starting services to ensure data transmission security. Note that enabling the SSL encryption function compromises database performance.
Preventing System Logs from Leaking Personal Data
  • You are advised to delete your personal data from debugging logs before sending the debug logs to others for analysis. During debugging, if you set the log level (log_min_messages) to DEBUGx (where x indicates the DEBUG level ranging from 1 to 5), information recorded in log files may contain your personal data.
  • You are advised to delete your personal data from system logs before sending the system logs to others for analysis. By default, if the execution of an SQL statement fails, the error information will be recorded in logs, and these SQL statements may contain personal data.
  • To prevent the system logs from recording failed SQL statements, you can set the value of log_min_error_statement parameter to PANIC. However, once the function is disabled, it is hard to locate fault causes if faults occur.

Setting Permissions for an Account

The GaussDB grants different access permissions to each user to ensure data security.

Context
By default, users of the GaussDB can be divided into system administrators and common users. For details, see Table 3-1.
Table 3-1 Users and permissions

User

Permission

System administrator

Has the highest permissions on the database as well as all system permissions and object permissions. For details, see Table 3-2.

Common user

Connects to the default database postgres of the GaussDB and accesses the default system tables and views in the database. In addition, a common user has the permission to log in to any database, the temp permission to all databases, and the execution permission to all functions. A common user can only use the CREATE/ALTER USER syntax to specify system permissions and can use the GRANT statement to specify object permissions.

Table 3-2 Permission types

Type

Description

Description

System permissions, also known as properties of a user, consist of SYSADMIN, CREATEDB, CREATEROLE, AUDITADMIN, and LOGIN. These properties can be specified when creating or modifying a user.
NOTE:
When the GaussDB is installed or the database is initialized, a system administrator is automatically generated. The administrator shares the same name with a user specified by the -U parameter. You are advised not to create another system administrator.

Description

Object permissions are special operation permissions for tables, views, indexes, sequences, and functions. These permissions include SELECT, INSERT, UPDATE, and DELETE.

Role

A role is a group of permissions. If a role consists of system permissions, these permissions cannot be granted to other users or roles.

If a role consists of object permissions, these permissions can be granted to other users or roles.

Procedure
  1. Log in to the GaussDB server as user gaussuser.
  2. If you want to establish a connection to the default database postgres whose port number is 65432. Run the following command:

    gsql -d postgres -p 65432

    For security purposes, you are advised to grant permissions to accounts listed in Table 3-3 after installing the GaussDB.
    Table 3-3 Planning rules and creation methods for different account types

    Account Type

    Account Type

    Creation Method

    System administrator

    Meaning: Account with the SYSADMIN permission.

    Planning rule: You are advised to use the current account of the system administrator instead of creating another system administrator.

    As the three types of accounts share the similar creation methods, this section uses how to create audit administrator user_audit as an example. Run the following command:

    CREATE USER user_audit WITH AUDITADMIN IDENTIFIED BY "1234@abc";

    Security administrator

    Meaning: Account with the CREATEROLE permission.

    Planning rule: You are advised to create only one security administrator with the CREATEROLE permission.

    Audit administrator

    Meaning: Account with the AUDITADMIN permission.

    Planning rule: You are advised to create only one security administrator with the AUDITADMIN permission.

    Object operator

    Meaning: By default, an object operator is an account that has no permissions, but can establish a connection to the default database postgres in the GaussDB and access the default system tables and views in the database.

    Planning rule: Create a role and add a user to the role. Then, the user has the object permission of the role.

    For example, perform the following steps if you want to create object operator user_read with the same object permission as role role1 that has the query permission on table films.
    1. Create role role1.

      CREATE ROLE role1 IDENTIFIED BY "abc@1234";

    2. Grant the permission for role role1 to query table films.

      GRANT SELECT ON TABLE films TO role1;

    3. Create object operator user_read and add it to role role1.

      CREATE USER user_read IN ROLE role1 PASSWORD "123@abcd";

Setting an Account Security Policy

For security purposes, the GaussDB provides a series of security measures, such as automatically locking and unlocking accounts, automatically invalidating accounts that have expired, manually locking abnormal accounts, and deleting accounts that are no longer used.

Procedure
Table 3-4 Account security policies

Configuration Item

Description

Configuration Method

Automatically locking and unlocking accounts

  • If the number of incorrect password attempts (failed_login_attempts) reaches the upper limit (default value: 10), the system automatically locks the account for account security protection. Smaller parameter values result in higher account security. However, if the value of this parameter is set too small, inconvenience may occur.
  • When the time during which a user is locked exceeds the preset value (password_lock_time) (default value: one day), the system automatically unlocks the user. Larger parameter values result in higher account security. However, if the value of this parameter is set too large, inconvenience may occur.
    NOTE:
    • If either value of the parameters is 0, the number of entered incorrect passwords is not restricted. Therefore, only when both of the parameters are set to positive values, the following operations can be performed: password failure check, account locking, and account unlocking.
    • The default values of the two parameters meet the security requirements. You can modify the parameters as required to improve the security level. You are advised to retain the default values.

Configure the failed_login_attempts parameter.

  1. View the configured parameter.
    POSTGRES=# show failed_login_attempts;
     failed_login_attempts
    -----------------------
     10
    (1 row)
  2. If the parameter value is not 10 in the command output, you are advised to run the following command with the parameter set to 10 (default value):

    gs_guc reload -c failed_login_attempts=10

Configure the password_lock_time parameter.

  1. View the configured parameter.
    POSTGRES=# show password_lock_time;
     password_lock_time
    -----------------------
     1
    (1 row)
  2. If the parameter value is not 1 in the command output, you are advised to run the following command with the parameter set to 1 (default value):

    gs_guc reload -c password_lock_time=1

Automatic account invalidation after expiration

  • A system administrator can set the account expiration time when creating the account. This way, when the preset duration expires, the operation permission of the account will be automatically canceled.
  • The system administrator can run the ALTER USER command to change the account expiration time to allow an expired account to be valid again.
NOTICE:

An account expiration setting function can take effect only when a password is used for authentication.

If you want to set the account expiration time of user user1 to 2012-10-12 18:00:00, run the following command:

CREATE USER user1 IDENTIFIED BY 'user123@123' VALID UNTIL 'Oct 12 18:00:00 2012 +8';

If you want to set the account expiration time of user user1 to 2012-12-12 18:00:00, run the following command:

ALTER USER user1 IDENTIFIED BY 'user123@234' VALID UNTIL 'Dec 12 18:00:00 2012 +8';

Manually locking abnormal accounts

If detecting an abnormal account that may be stolen or illegally accesses the database, an administrator can manually lock the account.

The administrator can also manually unlock the account if the account becomes normal again.

For example, if you want to manually lock and unlock user user_read, run the command in the following format:

  • If you want to manually lock the account, run ALTER USER user_read ACCOUNT LOCK.
  • If you want to manually unlock the account, run ALTER USER user_read ACCOUNT UNLOCK.

Deleting accounts that are no longer used

An administrator can delete an account that is no longer used. This operation cannot be rolled back.

When deleting an account, pay attention to the following precautions:

  • When an account to be deleted is in the active state, it will be deleted after the session is disconnected.
  • An account cannot be removed from the standby server.

For example, if you want to delete user user_write, run the command in the following format:

DROP USER user_write cascade;

Changing the Passwords for Database Accounts

To improve system security, change the default passwords of database accounts. It is recommended that the passwords be changed periodically (at a maximum interval of 90 days). The new passwords must meet complexity requirements.

Context
This section assumes that:
  • The default installation path is used for the USM-EUA.
  • The default installation path is used for the GaussDB.
  • The password to change on the Windows operating system is that for the database connection account EUA.
  • The passwords to change on the Linux operating system is those for the database administrator account gaussuser and the database connection account EUA.
The password of a GaussDB database account must meet the following requirements:
  • Contains at least three types of the following: uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), and special characters.
  • Consists of at least eight characters.
  • Must be different from the account.
  • Must be different from the password before last.
Changing the Passwords for Database Accounts on the Windows Operating System
  1. Back up the database account password configuration file.
    • Back up the jdbc.properties file in D:\EUA\EUA_OpenAS\kernel\OpenAS_Tomcat7\webapps\EUA\WEB-INF\classes.
    • Back up the proxool.xml file in D:\EUA\EUA_OpenAS\kernel\OpenAS_Tomcat7\webapps\EUA\WEB-INF\classes.
    • Back up the bme.secretkey.properties file in D:\EUA\EUA_OpenAS\kernel\OpenAS_Tomcat7\webapps\EUA\WEB-INF\conf.
  2. Open the CLI window.
  3. Go to the GaussDB database installation path.

    cd D:\EUA\EUA_GaussDB\app\bin

  4. Change the password of the database connection account EUA.

    gsql -d EUADB -U EUA -p 65432

    Enter the old password as prompted.
    Password for user EUA:

    alter user EUA identified by 'A123@abc' replace 'Change_Me';

    NOTE:

    In the preceding command, A123@abc and Change_Me are the new password and old password, respectively. They must meet complexity requirements. Otherwise, this command will fail to be executed.

    If the following information is displayed, the password is changed successfully:
    ALTER ROLE
  5. Use the encryption tool to encrypt the cipher key and generate the key value encryptedKey and the encrypted keystore password encryptedPassword.

    cd D:\EUA\EUA_OpenAS\tools\tools\encryption

    openas_encrypt_interactive.bat 0 CBC A123@abc

    The key value and keystore password similar to the following are displayed:
    encryptedKey: 65dd815e611acd31354259cd027e97a274684105aaf0afc110820ffafa732391f791a4582a890eed7475f2a3507acdf2
    encryptedPassword: dbc30b8e373e04d3c22f57440086783d96d8b10345462e610fc70c7af055fa70
  6. Open the jdbc.properties file and replace the value of bme.password with the value of encryptedPassword generated in step 5. Then save the modification and exit.
  7. Open the jdbc.properties file and replace the value of <property name="password" value= with the value of encryptedPassword generated in step 5. Then save the modification and exit.
  8. Open the jdbc.properties file and replace the value of bme.encryption.key with the value of encryptedKey generated in step 5. Then save the modification and exit.
  9. Restart the USM-EUA for the new certificate to take effect.

    net stop "EUA SERVICE"

    net start "EUA SERVICE"

Changing the Passwords for Database Accounts on the Linux Operating System
NOTE:

In a two-node cluster or disaster recovery (DR) scenario, the active node synchronizes the new password to the standby node. You only need to back up the configuration file on the standby node and use the encryption tool to encrypt the key. You do not need to perform the database account password change operations 4 and 7.

  1. Log in to the USM-EUA server as the OMUSER user.
  2. Switch to the euauser user.

    su - euauser

  3. Back up the database account password configuration file.
    1. Back up the configuration file of the EUA account.

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

      cp jdbc.properties jdbc.properties.bak

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

      cp proxool.xml proxool.xml.bak

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/conf

      cp bme.secretkey.properties bme.secretkey.properties.bak

    2. Back up the configuration file of the gaussuser account.

      su - gaussuser

      cd /home/gaussuser/gaussdb_backup/conf

      cp config_rzs.properties config.properties.bak

    NOTE:

    If the password fails to be changed, put the backup configuration file into its original path to restore the original password.

    1. Restore the configuration file of the gaussuser account.

      su - gaussuser

      cd /home/gaussuser/gaussdb_backup/conf

      cp config_rzs.properties.bak config_rzs.properties

    2. Restore the configuration file of the EUA account.

      su - euauser

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

      cp jdbc.properties.bak jdbc.properties

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

      cp proxool.xml.bak proxool.xml

      cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/conf

      cp bme.secretkey.properties.bak bme.secretkey.properties

  4. Change the password of the gaussuser user.
    NOTE:

    This step is not required on the standby node in a two-node cluster or DR scenario.

    1. Connect to the database.

      su - gaussuser

      gsql -d POSTGRES -p 65432

    2. Change the password of the gaussuser user.

      alter user gaussuser identified by 'B254@abc' replace 'Change_Me';

      If the following information is displayed, the password is changed successfully:
      ALTER ROLE
      NOTE:

      In the preceding command, B254@abc and Change_Me are the new password and old password, respectively. They must meet complexity requirements. Otherwise, this command will fail to be executed.

    3. Exit the database.

      \q

      exit

  5. Use the encryption tool to encrypt the cipher key and generate the key value encryptedKey and the encrypted keystore password encryptedPassword.

    su - euauser

    cd /home/euauser/EUA_OpenAS/tools/tools/encryption

    chmod +x openas_encrypt_interactive.sh

    sh openas_encrypt_interactive.sh 0 CBC B254@abc

    The key value and keystore password similar to the following are displayed:
    encryptedKey: 65dd815e611acd313542110820ffafa732391f791a4582a890eed7475f2a3507acdf259cd027e97a274684105aaf0afc
    encryptedPassword: dbc30b8e373e04d96d8b10345462e610fc70c7af055fa73c22f57440086783d0
  6. Modify the config_rzs.properties file.
    • Open the config_rzs.properties file and replace the value of gaussDBAPassword with the value of encryptedPassword generated in step 5.
    • Open the config_rzs.properties file and replace the value of euaKey with the value of encryptedKey generated in step 5.

    su - gaussuser

    cd /home/gaussuser/gaussdb_backup/conf

    vim config_rzs.properties

  7. Change the password of the database connection account EUA.
    NOTE:

    This step is not required on the standby node in a two-node cluster or DR scenario.

    1. Connect to the database.

      su - gaussuser

      gsql -d POSTGRES -p 65432

    2. Change the password of the database connection account EUA.

      alter user EUA identified by 'D568@abc' replace 'Change_Me';

      If the following information is displayed, the password is changed successfully:
      ALTER ROLE
      NOTE:

      In the preceding command, D568@abc and Change_Me are the new password and old password, respectively. They must meet complexity requirements. Otherwise, this command will fail to be executed.

    3. Exit the database.

      \q

      exit

  8. Use the encryption tool to encrypt the new password and generate the key value encryptedKey and the encrypted keystore password encryptedPassword.

    su - euauser

    cd /home/euauser/EUA_OpenAS/tools/tools/encryption

    chmod +x openas_encrypt_interactive.sh

    sh openas_encrypt_interactive.sh 0 CBC D568@abc

    The key value and keystore password similar to the following are displayed:
    encryptedKey: a890eed7475f2aacd31354211082065dd815e611791a4582ffafa732391f3507acdf259cd027e97a274684105aaf0afc
    encryptedPassword: af055fa73c22f5b8e37dbc302e610fc70c73e04d96d8b10345467440086783d0
  9. Open the jdbc.properties file and replace the value of bme.password with the value of encryptedPassword generated in step 8. Then save the modification and exit.

    cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

    vim jdbc.properties

  10. Open the proxool.xml file and replace the value of property name="password" value=with the value of encryptedPassword generated in step 8. Then save the modification and exit.

    cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/classes

    vim proxool.xml

  11. Open the bme.secretkey.properties file and replace the value of bme.encryption.key with the value of encryptedKey generated in step 8. Then save the modification and exit.

    cd /home/euauser/EUA_OpenAS/kernel/OpenAS_Tomcat7/webapps/EUA/WEB-INF/conf

    vim bme.secretkey.properties

  12. Restart the USM-EUA for the new password to take effect.

    su - root

    service EUAService restart

Configuring Security Certificate Authentication for the GaussDB Database Two-Node Cluster

To improve security of the GaussDB database two-node cluster, enable the two databases to authenticate each other's security certificate.

The security certificate supports encrypted data transmission for websites to ensure data confidentiality, integrity, and non-repudiation. The GaussDB database has embedded a security certificate. To fortify security, it is recommended that enterprises replace the embedded security certificate with commercial security certificates issued by CA. Additionally, enterprises should ensure that their security certificates and private key files are available only for authorized personnel.

Configuring the Two-Node Cluster Data Replication Mode (TLS)

If the database two-node cluster is deployed on an untrusted network, you are advised to enable Transport Layer Security (TLS) encrypted transmission to prevent sensitive information from being intercepted or tampered with, ensuring secure data transmission.

Background

When the TLS function is enabled, nodes (that is, nodes configured by replconninfo corresponding to nodedomain1) in data centers can use only TLS encrypted transmission.

Procedure
  1. Set TLS encryption parameters for the two-node cluster. For details, see Establishing Secure TCP/IP Connections in SSL Mode.
  2. (Optional) Disable the TLS function between nodes in the same area. For details, see Table 3-5.

    You can enable the TLS function between two-node clusters in different data centers, but not for the primary and standby nodes in the two-node cluster of a data center. Disabling the TLS function on the local trusted network improves performance of database two-node clusters.

    Suggestions:

    If the TLS function needs to be enabled only between untrusted networks in different areas and does not need to be enabled on local networks in the same area, run the gs_guc set -c localdomain_ssl_mode=0 command on all nodes.
    Table 3-5 Setting TLS parameters for nodes in the same area

    Parameter

    Description

    Setting

    Node domain-related parameters (nodedomain1 to nodedomain7)

    The parameters map the seven replconninfo values, indicating whether the corresponding nodes are located in a different area from the local nodes.

    The options are as follows:

    0: The node configured by replconninfo is a local node.

    1: The node configured by replconninfo is a remote node.

    Default value: 0

    localmode_ssl_mode

    When the TLS function is enabled, this parameter indicates whether the TLS function is enabled between nodes in the same area.

    The options are as follows:

    1: yes

    0: no

    Default value: 1

    repl_force_cert_check

    This parameter indicates forcible certificate verification. After the TLS function is enabled, the system forcibly verifies the certificates.

    The options are as follows:
    • repl_force_cert_check='repl_All_peer_cn=gauss_ca_file': The common names (CNs) are set to gauss_ca_file for all certificates. Here, gauss_ca_file is used as an example and needs to be set based on actual CNs of the certificates.
    • repl_force_cert_check='repl1_peer_cn=gauss_ca_file1;repl2_peer_cn=gauss_ca_file2;...;repl7_peer_cn=gauss_ca_file7': Different CNs are set for the certificates. Here, gauss_ca_file1 to gauss_ca_file7 are used as examples and need to be set based on actual CNs of the certificates.
      NOTE:
      • This parameter takes effect only on the primary node. To prevent the parameter from becoming invalid after a primary/standby switchover, set the parameter on both the primary and standby nodes.
      • If replX_peer_cn is not set for a certificate, the value of replconninfoX corresponding to the CN of the standby certificate is left empty.
      • If CNs are set for certificates on the primary and standby nodes but no certificate is configured on the standby node, the primary node rejects the TLS connection of the standby node and authentication of the standby node fails.
    Default value: empty, which indicates that the parameter is invalid.
    • If the standby node provides no certificate, anonymous authentication is used.
    • If the standby node provides certificates, CA certificates are verified for authentication.
  3. Restart the GaussDB for the configuration to take effect.
    • Primary node: gs_ctl restart -M primary
    • Standby node: gs_ctl restart -M standby
Establishing Secure TCP/IP Connections in SSL Mode

The GaussDB supports encryption of communication between clients and servers and between primary and standby servers in SSL mode, to ensure secure data transmission on the Internet.

Prerequisites
The formal certificates and keys for the server and client have been obtained from the Certificate Authority (CA).
Context

The GaussDB supports the TLS1.2 protocol standard. As a highly secure protocol standard, TLS1.2 authenticates bidirectional identification between the server and client using digital signatures and digital certificates, ensuring secure data transmission between the server and client.

For a test, you can use OpenSSL to generate a certificate.

SSL-related parameters control the SSL communication between the client and the primary server, as well as the SSL communication between the primary and standby servers.

Procedure

Perform the following operations on the primary server, standby server, and client, respectively. For the operations that need to be performed only on the primary server or standby server, see the description of each step.

  1. Log in to the GaussDB server as the gaussuser user.
  2. Enable the SSL authentication mode.

    gs_guc set -c ssl=on

  3. Upload the following server certificate files to the /opt/gaussdb/data directory on the primary node:
    • Primary root certificate file
    • Primary server certificate file
    • Primary server key file
  4. Upload the following client certificate files to the /home/gaussuser directory on the primary node (you also need to upload corresponding server and client certificate files to the /opt/gaussdb/data and /home/gaussuser directories respectively on the standby node):
    • Standby client certificate file
    • Standby client key file
    • Standby root certificate file
  5. Set the digital certificate parameters related to SSL authentication. For details about the requirements, see Table 3-6.
    • Set server parameters. For details about the parameters, see Table 3-7.
      gs_guc set -c "ssl_cert_file='server.crt'"
      gs_guc set: ssl_cert_file='server.crt' 
      gs_guc set -c "ssl_key_file='server.key'"
      gs_guc set: ssl_key_file='server.key'
      gs_guc set -c "ssl_ca_file='cacert.pem'"
      gs_guc set: ssl_ca_file='cacert.pem' 
      gs_guc set -c "ssl_crl_file=' '"
      gs_guc set: ssl_crl_file=' '
      gs_guc set -c "ssl_ciphers='ALL'"
      gs_guc set: ssl_ciphers='ALL'
      gs_guc set -c "repl_force_cert_check = 'repl_All_peer_cn=debug.com'"
      gs_guc set: repl_force_cert_check='repl_All_peer_cn=debug.com'
      In the preceding command, debug.com indicates the CN value in a certificate.
      NOTE:
      • You are advised to use bidirectional authentication for higher security.
      • If private key password protection is not disabled for the server after certificates are replaced, run the gs_guc -M server -K hsKd@3757 command to encrypt the stored password. For details, see How Do I Create a Self-signed Digital Certificate Using OpenSSL (Optional). In the command, hsKd@3757 indicates the private key password and needs to be replaced with private key passwords of the new certificates that must meet password complexity requirements. Do not use default private key passwords of the new certificates.
      Table 3-6 Authentication modes

      Authentication mode

      Meaning

      Setting Server Parameters on the Server Configuring These Parameters on Both the Primary and Standby Servers in an HA System

      Configuring Environment Variables on a Client

      Bidirectional authentication (recommended)

      The client verifies the server's certificate, and the server verifies the client's certificate. Connection can be set up after the verification is successful.

      Copy the certificate, key, revoked certificate, and root certificate of a server to the $GAUSSDATA directory and set the following parameters:

      • ssl_cert_file
      • ssl_key_file
      • ssl_ca_file
      • ssl_crl_file
      • ssl_ciphers

      Set the parameters according to Table 3-7 and Table 3-9.

      Set the following environment variables:

      • PGSSLCERT
      • PGSSLKEY
      • PGSSLROOTCERT
      • PGSSLCRL
      • PGSSLMODE

      Set the environment variables according to Table 3-8.

      Server authentication

      The client verifies the server's certificate, but the server does not verify the client's certificate. The server loads the certificate information and sends the information to the client. The client verifies the server's certificate according to the root certificate.

      Copy the certificate and key files of a server to the $GAUSSDATA directory and set the following parameters:

      • ssl_cert_file
      • ssl_key_file
      • ssl_ciphers

      Set the parameters according to Table 3-7 and Table 3-9.

      Set the following environment variables:

      • PGSSLROOTCERT
      • PGSSLCRL
      • PGSSLMODE

      Set the environment variables according to Table 3-8.

      Client authentication

      The server verifies the client certificate, but the client does not verify the server certificate. During the handshake phase, the client sends information about the loaded certificate to the server. The server verifies the certificate using the root certificate.

      Copy the root certificate and certificate revocation list of a server to the $GAUSSDATA directory and set the following parameters:

      • ssl_ca_file
      • ssl_crl_file
      • ssl_ciphers

      Set the parameters according to Table 3-7 and Table 3-9.

      Set the following environment variables:

      • PGSSLROOTCERT
      • PGSSLCRL
      • PGSSLMODE

      Set the environment variables according to Table 3-8.

  6. Go to the /opt/gaussdb/data and /home/gaussuser directories, modify the permission of all certificate files uploaded in 3 and 4. The following uses server key permission as an example to describe how to modify the permission. Assume that the name is server.key and it is in the /opt/gaussdb/data directory.

    The permission must be 600, the owner is gaussuser, and the owner group is dbgrp. If the permission setting does not meet requirements, the GaussDB cannot be started. Run the following commands to change the permission setting:

    cd /opt/gaussdb/data

    chown gaussuser:dbgrp server.key

    chmod og-rwx server.key

  7. On a standby server and its cascaded standby server, set the following parameters and environment variables so that the communication between the primary and standby servers and the communication between a standby server and its cascaded standby server are normal. (In this case, the standby server is equivalent to the client connected to the primary server and the cascaded standby server is equivalent to the client connected to the standby server.)
    • Set environment variables PGSSLCERT, PGSSLKEY, PGSSLROOTCERT, and PGSSLCRL according to Table 3-8.
    • Set the ssl_ciphers parameter (the default value ALL is recommended). For the encryption algorithms supported by the GaussDB, see Table 3-9.
  8. Restart the GaussDB for the configuration to take effect.

    Primary node: gs_ctl restart -M primary

    Standby node: gs_ctl restart -M standby

Reference

Set related parameters in the postgresql.conf file on the GaussDB server. For details, see Table 3-7.

Table 3-7 Server parameters

Parameter

Parameter

Value Range

ssl

Specifies whether to enable the SSL function.

  • on: enable.
  • off: disable.

Default value: off

ssl_cert_file

Specifies the certificate files for the server, including the public key. Certificates prove the legal identity of the server and the public key is sent to the peer end for data encryption.

Refer to the actual certificate name. A relative path must be used. The path depends on the data directory.

Default value: server.crt

ssl_key_file

Specifies the private key file for the server to decrypt digital signatures and data encrypted using the public key.

Refer to the name of the actual private key. A relative path must be used. The path depends on the data directory.

Default value: server.key

ssl_ca_file

Specifies the root certificate of the CA server. This parameter is optional and needs to be set only when the certificate of a client must be verified.

Refer to the name of the actual root certificate.

Default value: empty, indicating that the identities of clients are not verified.

ssl_crl_file

Indicates the certificate revocation list. If the certificate of a client is in the list, the certificate is invalid.

Refer to the actual name of the certificate revocation list.

Default value: empty, indicating that there is no certificate revocation list.

ssl_ciphers

Specifies the encryption algorithm used for SSL communication.

For the encryption algorithms supported by the GaussDB, see Table 3-9.

Default value: ALL, indicating that the peer end can use all encryption algorithms supported by the GaussDB.

Configure environment variables related to SSL authentication on the GaussDB client. For details, see Table 3-7.

Table 3-8 Client parameters

Environment Variable

Description

Value Range

PGSSLCERT

Specifies the certificate files for a client, including the public key for the client. Certificates prove the legal identity of the client and the public key is sent to the peer end for data encryption.

The absolute path of the files must be contained. An example is as follows:
export PGSSLCERT="/home/gaussdb/data/client.crt"

Default value: empty.

PGSSLKEY

Specifies the private key file for the client to decrypt digital signatures and data encrypted using the public key.

The absolute path of the file must be contained. An example is as follows:
export PGSSLKEY="/home/gaussdb/data/client.key"

Default value: empty.

PGSSLMODE

Specifies whether to negotiate with the server about SSL connection and specifies the priority of the SSL connection.

Values and meanings:

  • disable

    Trying to set up a non-SSL connection.

  • allow

    Trying to set up a non-SSL connection first, and then an SSL connection if the trial fails.

  • prefer

    Trying to set up an SSL connection first, and then a non-SSL connection if the trial fails.

  • require

    Trying to set up an SSL connection. If there is a CA file, perform the verification according to the scenario in which the parameter is set to verify-ca.

  • verify_ca

    Trying to set up an SSL connection and checking whether the server certificate is issued by a trusted CA.

  • verify_full

    Trying to set up an SSL connection, checking whether the server certificate is issued by a trusted CA, and checking whether the host name of the server is the same as that in the certificate.

Default value: require

PGSSLROOTCERT

Specifies the root certificate file for issuing client certificates. The root certificate is used to verify the server certificate.

The absolute path of the file must be contained. An example is as follows:
export PGSSLROOTCERT="/home/gaussdb/data/root.crt"

Default value: empty.

PGSSLCRL

Specifies the certificate revocation list file, which is used to check whether a server certificate is in the list. If yes, the certificate invalid.

The absolute path of the file must be contained. An example is as follows:
export PGSSLCRL="/home/gaussdb/data/root.crl"

Default value: empty.

The GaussDB supports a series of encryption and authentication algorithms with different strength for SSL transmission. You can modify ssl_ciphers in postgresql.conf to specify the encryption algorithm used by the database server. Table 3-9 lists the encryption algorithms supported by the GaussDB for SSL transmission.

Table 3-9 Encryption algorithms

Encryption Strength

Encryption Speed

Encryption Algorithm

stronger

faster

AES256-SHA

stronger

faster

DES-CBC3-SHA

stronger

faster

AES128-SHA

stronger

slower

DHE-RSA-AES256-SHA

stronger

slower

DHE-DSS-AES256-SHA

stronger

slower

EDH-RSA-DES-CBC3-SHA

stronger

slower

EDH-DSS-DES-CBC3-SHA

stronger

slower

DHE-RSA-AES128-SHA

stronger

slower

DHE-DSS-AES128-SHA

middle

faster

DES-CBC-SHA

middle

slower

EDH-RSA-DES-CBC-SHA

middle

slower

EDH-DSS-DES-CBC-SHA

NOTE:
  • Currently, the GaussDB SSL supports encryption algorithms with the encryption strength above middle.
  • The default value of ssl_ciphers is ALL, which indicates that all encryption algorithms listed in the preceding table are supported. You are advised to retain the default value, unless there are other special requirements on the encryption algorithm.
  • If multiple encryption algorithms must be specified, use semicolons to segment the algorithms.
    For example, run the gs_guc set command to set ssl_ciphers to a combination of several algorithms.
    gs_guc set -c ssl_ciphers="'AES256-SHA;DES-CBC3-SHA;AES128-SHA'"
  • If a DSS-related algorithm in the preceding table is to be used (such as DHE-DSS-AES256-SHA or EDH-DSS-DES-CBC3-SHA), a certificate file with the DSA algorithm signature must be loaded. For details about how to use OpenSSL to generate a certificate file with the DSA algorithm signature, see OpenSSL official documents.
How Do I Create a Self-signed Digital Certificate Using OpenSSL (Optional)

This section describes how to create a self-signed digital certificate using OpenSSL, which can be used in the test environment. In the customers' operating environment, use the digital certificate obtained from the CA certification center.

Example

By default, the OpenSSL component is installed in the SUSE Linux 10/11 OS. You can create a self-signed certificate using OpenSSL.

The default installation path is /usr/local/ssl.

An example is as follows (## indicate comment characters):

## Log in to the SUSE Linux system as user root.
gauss21:~ # cd /usr/local/ssl/misc
gauss21:/usr/local/ssl/misc # ls
CA.pl  c_hash  c_issuer  CA.sh  c_info  c_name

##Create a CA. The demoCA folder is generated in the current directory.
gauss21:/usr/local/ssl/misc # ./CA.sh -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
...........................++++++
..............++++++
writing new private key to './demoCA/private/./cakey.pem'

##Set a password for protecting the root certificate. The password must contain a minimum of four characters, for example, CBad@3597
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----

## Remember the following names, which need to be specified when generating a server certificate and a client certificate.
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:shanxi
Locality Name (eg, city) []:xian
Organization Name (eg, company) [Internet Widgits Pty Ltd]:company-A
Organizational Unit Name (eg, section) []:Unit-1
##Common Name can be randomly named.
Common Name (eg, YOUR name) []:john
## Email is optional.
Email Address []:

gauss21:/usr/local/ssl/misc # ls
CA.pl  CA.sh  c_hash  c_info  c_issuer  c_name  demoCA

## Generate the server certificate request file server.req and the server private key server.key.
gauss21:/usr/local/ssl/misc # openssl req -newkey rsa:1024 -out server.req -keyout server.key
Generating a 1024 bit RSA private key
.......++++++
..++++++
writing new private key to 'server.key'
## Set a password for protecting the server private key. The password must contain a minimum of four characters, for example, DKbs@5873
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
## The following information must be consistent with that filled when creating a CA.
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:shanxi
Locality Name (eg, city) []:xian
Organization Name (eg, company) [Internet Widgits Pty Ltd]:company-A
Organizational Unit Name (eg, section) []:Unit-1
## Common Name can be randomly named.
Common Name (eg, YOUR name) []:rose
Email Address []:
## The following attributes are optional.
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

gauss21:/usr/local/ssl/misc # ls
CA.pl  CA.sh  c_hash  c_info  c_issuer  c_name  demoCA  server.key  server.req

## Sign the generated server certificate request file. Then, the official server certificate server.crt is generated.
gauss21:/usr/local/ssl/misc # openssl ca -in server.req -out server.crt
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jul 11 12:14:23 2013 GMT
            Not After : Jul 11 12:14:23 2014 GMT
        Subject:
            countryName               = CN
            stateOrProvinceName       = shanxi
            organizationName          = company-A
            organizationalUnitName    = Unit-1
            commonName                = rose
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                66:11:DB:B1:8A:6F:A9:E8:58:C8:F8:BE:50:B4:32:BA:79:79:2B:6C
            X509v3 Authority Key Identifier:
                keyid:3E:FD:3D:16:5B:9B:44:DE:72:96:36:C7:A0:13:97:D6:9B:0E:71:30

Certificate is to be certified until Jul 11 12:14:23 2014 GMT (365 days)

## Enter y to sign the certificate.
Sign the certificate? [y/n]:y

## Enter y. The certificate is signed.
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
gauss21:/usr/local/ssl/misc # ls
CA.pl  c_hash  c_issuer  demoCA      server.key
CA.sh  c_info  c_name    server.crt  server.req
## Remove password protection for the server private key.
gauss21:/usr/local/ssl/misc # openssl rsa -in server.key -out server.key
## If password protection for the server private key is not removed, you need to use the gs_guc tool to encrypt the storage password.
gauss21:/usr/local/ssl/misc # gs_guc encrypt -M server -K Gauss@123
## In this example, the password of the server private key is DKbs@5873
Enter pass phrase for server.key:
writing RSA key

## The methods and requirements for generating a client certificate and a client private key are the same as that for generating a server certificate and a server private key.
## Generate a client certificate request file and a client private key.
gauss21:/usr/local/ssl/misc # openssl req -newkey rsa:1024 -out client.req -keyout client.key 
## Sign the generated client certificate request file. Then, the official client certificate client.crt is generated.
gauss21:/usr/local/ssl/misc # openssl ca -in client.req -out client.crt
## Remove password protection for the client private key.
gauss21:/usr/local/ssl/misc # openssl rsa -in client.key -out client.key
## If password protection for the client private key is not removed, you need to use the gs_guc tool to encrypt the storage password.
gauss21:/usr/local/ssl/misc # gs_guc encrypt -M client -K Gauss@123

## How do I generate the CA root certificate required in SSL bidirectional authentication mode?
cd /usr/local/ssl/misc/demoCA
## As shown below, the cacert.pem file is generated in the demoCA folder when creating a CA, and it is the CA root certificate.
## User PgAdmin can change the file name extension of cacert.pem to crt.
gauss21:/usr/local/ssl/misc/demoCA # ls
cacert.pem  crl        index.txt.attr  newcerts  serial
certs       index.txt  index.txt.old   private   serial.old
Configuring Client Access Authentication

Client access authentication is controlled by a configuration file (its default name is pg_hba.conf) and this file is saved in the data directory of the database. HBA is short for host-based authentication.

Context
  • GaussDB supports three authentication methods, each of which requires a pg_hba.conf file.
    • Host-based authentication: A server matches the IP address, user name, and target database of a client with those set in the configuration file to check whether the user passes authentication.
    • Password authentication: A password can be an encrypted password for remote connection or a non-encrypted password for local connection.
    • SSL encryption: SSL is used to provide a secure connection environment between a server and a client.
  • The pg_hba.conf file format is that one record occupies a row and specifies an authentication rule. An empty row or a row started with a comment character (#) will be neglected.
  • Each authentication rule consists of multiple fields separated by spaces, slashes (/), or tab characters. If a field is enclosed by quotation marks ("), it can contain spaces. A record cannot span different rows.
Procedure

The following part takes the single-server system as an example. The configuration in the HA system is the same as that in the single-server system and only needs to be implemented on the primary server.

  1. Log in to the GaussDB server as the gaussuser user.
  2. Add or adjust authentication rules in pg_hba.conf.

    Each record in pg_hba.conf can be in one of the following four formats. For parameter description of the four formats, see Configuration File Reference.

    local     DATABASE USER METHOD [OPTIONS]
    host      DATABASE USER ADDRESS METHOD [OPTIONS]
    hostssl   DATABASE USER ADDRESS METHOD [OPTIONS]
    hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]

    During authentication, the system checks connection requests with records in pg_hba.conf in sequence, so the record sequence is very important.

    The suggestions on configuring authentication rules are as follows:

    • Records placed at the front have strict connection parameters but weak authentication methods.
    • Records placed at the end have weak connection parameters but strict authentication methods.
    NOTE:

    If a user wants to connect a specified database, the user must pass the pg_hba.conf authentication and also have the CONNECT permission for the database. If you want to allow or deny a user's connection to a database, you can grant or revoke the user's CONNECT permission, which is easier than setting rules in the pg_hba.conf file.

  3. Restart database services for the configuration to take effect.

    gs_ctl restart

Troubleshooting

There are many reasons that can cause a user authentication failure, and you can view the error message returned from the server to the client to know about the exact reason. See Table 3-10 lists common error messages and solutions to these errors.

Table 3-10 Error messages

Symptom

Solution

The user does not exist:

FATAL: invalid username/password,login denied

This message indicates that your user name or password is incorrect. Retry the authentication with a correct user name and password.

The database to connect does not exist:

FATAL: database "TESTDB" does not exist

This message indicates that the database to connect does not exist. Retry the authentication with a correct database name.

No matched client record is found:

FATAL: no pg_hba.conf entry for host "10.10.10.10", user "ANDYM", database "TESTDB"

This message indicates that the server is connected but denies the connection request, for it does not find a matched record in pg_hba.conf. Contact the database administrator to add your information to pg_hba.conf.

Task Example
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
# Allows only the user specified by the -U parameter during installation to establish a connection from the local server.
local   all             all                                     trust
# IPv4 local connections:
# Allows the gaussuser user to connect to any GaussDB database from the 10.10.10.2 host and use the sha256 algorithm to encrypt passwords.
host    all           gaussuser             10.10.10.2/32            sha256
# Allows any user to connect to any GaussDB database from a host on the 10.0.0.0/8 network segment, and use the sha256 algorithm to encrypt passwords.
hostssl    all             all             10.0.0.0/8            sha256
Configuration File Reference

This section describes the parameters in the pg_hba.conf file. When you configure client access authentication, use these parameters.

Table 3-11 Parameter description

Parameter

Description

Value Range

local

Indicates that this record accepts only a Unix-domain-socket connection. If no such type of record exists, Unix-domain-socket connection is not allowed.

When GSQL is used to initiate connection from a local server and the -U parameter is not specified, such connection is called Unix-domain-socket connection.

-

host

Indicates that this record accepts either a common TCP/IP-socket connection or a TCP/IP-socket connection encrypted through SSL.

-

hostssl

Indicates that this record accepts only a TCP/IP-socket connection encrypted through SSL.

For the connection encrypted through SSL, you need to apply for a digital certificate and configure related parameters. For details, see Establishing Secure TCP/IP Connections in SSL Mode.

hostnossl

Indicates that this record accepts only a common TCP/IP-socket connection.

-

DATABASE

Specifies the database that a record matches and can access. The options are as follows:

  • all: indicates that this record matches all databases.
  • sameuser: indicates that this record matches a database if the database has the same name as the user who requests the database.
  • samerole: indicates that this record matches a database if the user who requests the database is a member of a role with the same name as the database.
  • A specific database name or a database list separated using commas.
    NOTE:
    Keywords all and replication do not match with each other. To access replication, you must use an independent record.

USER

Specifies the database users whom a record matches and can access. The options are as follows:

  • all: indicates that this record matches all users.
  • A specific database user name or a user list separated using commas.
  • Prefix+user role: indicates that this record matches any member directly or indirectly belonging to this role.
  • A file containing user names can be specified by adding an At sign (@) before the file name as the prefix. The user list in the file can be separated using commas or linefeed.

ADDRESS

Specifies the IP address range that this record matches and can access.

IPv4 and IPv6 are supported. The IP address range can be expressed in the following two formats:

  • IP address/mask length, for example, 10.10.10.0/24
  • IP address subnet mask, for example, 10.10.10.0 255.255.255.0
NOTE:
An IPv4 address matches the IPv6 connection with the corresponding address. For example, 127.0.0.1 matches IPv6 address ::ffff:127.0.0.1.

METHOD

Specifies the authentication method used for connection.

The GaussDB supports the following authentication modes. For details, see Table 3-12.

  • trust
  • reject
  • md5 (not recommended)
  • sha256
  • cert

OPTIONS

Specifies an authentication option set in the format of NAME = VALUE.

Available options depend on the authentication mode.

NOTE:
The authentication modes supported by the GaussDB do not require this parameter.
Table 3-12 Authentication modes

Authentication Mode

Description

trust

In trust mode, the GaussDB trusts only the connection initiated from the local server using GSQL without the -U parameter specified. In this case, no password is required.

The trust authentication applies to local connection of a single-user workstation, but not of a multi-user workstation. To use the trust authentication, you can use the file system permissions to control the access to the Unix-domain socket file on the server. You can use either of the following two methods to control the access:
  • Set the unix_socket_permissions and unix_socket_group parameters.
  • Set the unix_socket_directory parameter and store the Unix-domain socket file in a properly controlled directory.
NOTICE:
The setting of file system permissions can only facilitate Unix-domain socket connection, but does not control local TCP/IP connection. To ensure local TCP/IP security, the GaussDB does not allow the trust authentication for remote connections.

reject

Rejects connection unconditionally. This authentication mode is usually used for filtering some hosts.

md5

Specifies that the client must provide a MD5-encrypted password for authentication.

CAUTION:
MD5 authentication must not be used because MD5 is an insecure encryption algorithm and may cause network security risks. The GaussDB reserves MD5 authentication and password storage to facilitate use of a third-party tool (such as the TPCC test tool).

sha256

Specifies that the client must provide a SHA-256-encrypted password for authentication. The password is encrypted based on the unidirectional SHA-256 of salt (a random number sent from the server to the client) when being transmitted, enhancing the security.

cert

Forcibly uses security certificates for verification.

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100059091

Views: 16360

Downloads: 9

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next