Security Best Practices

Configuring the Maximum Number of Connections to a DB Instance

The max_connections parameter specifies the maximum number of concurrent connections to a DB instance. Setting this parameter to a larger value may cause the RDS for PostgreSQL instance to request more System V shared memory or semaphore, which can exceed the limits allowed by the OS's default configuration. Set max_connections depending on your workload. For details, see Instance Usage Guidelines.

Configuring the Timeout for Client Authentication

The authentication_timeout parameter specifies the maximum duration allowed to complete client authentication, in seconds. This parameter prevents clients from occupying a connection for a long time. The default value is 60 (unit: second). If client authentication is not complete within the specified period, the connection is forcibly closed. Using this parameter can enhance the security of your RDS for PostgreSQL instance.

Configuring SSL and Cryptographic Algorithms

Use SSL for TCP/IP connections to encrypt all data transmitted between clients and servers, preventing data leakage and tampering and maintaining data integrity. After an RDS for PostgreSQL instance is created, SSL is enabled on the server by default. However, whether you can connect to the instance over SSL also depends on the client configuration. For details, see Configuring SSL Encryption. You are advised to use TLSv1.2 or later and the EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EDH+aDSS+AESGCM:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!SRP:!RC4 cryptographic algorithm. For details, see SSL Connection.

To configure the TLS protocol and cryptographic algorithm, use the parameters ssl_min_protocol_version and ssl_ciphers.

Configuring Password Encryption

Passwords must be encrypted. When you use CREATE USER or ALTER ROLE to change a password, the password is stored in a system catalog after being encrypted by default. scram-sha-256 is recommended for password encryption. To change the password encryption algorithm, change the value of password_encryption.

The MD5 option is used only for compatibility with earlier versions. New DB instances use scram-sha-256 by default.

The modification of password_encryption takes effect only after the password is reset.

Configuring Appropriate pg_hba Rules

Appropriate pg_hba rules are crucial to ensure the security of RDS for PostgreSQL instances. You are advised to allow only necessary users and hosts to access your DB instance from specific IP addresses or subnets, and periodically review and update the pg_hba file to ensure that the rules meet your workload requirements. For details, see Modifying pg_hba.conf.

Disabling the Backslash Quote

The backslash_quote parameter specifies whether a single quotation mark (') in a string can be replaced by a backslash quote (\'). The preferred, SQL-standard way to represent a single quotation mark is by doubling it (''). If client-side code does escaping incorrectly then an SQL-injection attack is possible. You are advised to set backslash_quote to safe_encoding to reject queries in which a single quotation mark appears to be escaped by a backslash, preventing SQL injection risks.

Periodically Checking and Deleting Roles That Are No Longer Used

Check whether all roles are mandatory. Every unknown role must be reviewed to ensure that it is used properly. If any role is no longer used, delete it. To query roles, run the following command:

SELECT rolname FROM pg_roles;

Revoking All Permissions on the public Schema

In PostgreSQL, the public schema allows all users to create and access objects by default. To enhance database security, revoke these default privileges. Following the principle of least privilege, grant only the USAGE privilege and necessary object privileges to specific users or roles. This helps prevent unauthorized access and improve overall system security. To revoke the default privileges from all users, run the following command as user root:

revoke all on schema public from public;

Setting a Proper Password Validity Period for a User Role

When creating a role, you can use the VALID UNTIL keyword to specify when the password of the role becomes invalid. If this keyword is ignored, the password will be valid permanently. You are advised to change the password periodically, for example, every three months. To configure a password validity period, run the following command:

CREATE ROLE name WITH PASSWORD 'password' VALID UNTIL 'timestamp';

To check whether a password validity period is configured, run the following command:

SELECT rolname,rolvaliduntil FROM pg\_roles WHERE rolsuper = false AND rolvaliduntil IS NULL;

Using Data Encryption Workshop (DEW) to Manage Database Passwords

When users use RDS for PostgreSQL instances, different user passwords are scattered across multiple applications. This increases the risk of mismanagement, password leakage, or loss. You are advised to use DEW to manage RDS for PostgreSQL database passwords. For this purpose, you can create secrets on Cloud Secret Management Service (CSMS) of DEW.

Configuring the Log Level to Record SQL Statements That Cause Errors

The log_min_error_statement parameter specifies which SQL statements that cause errors can be recorded in server logs. The SQL statements of the specified level or higher are recorded in logs. Valid values include debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, and panic. log_min_error_statement must be set to the value error or higher. For details, see Log Reporting.

Configuring Least-Privilege Permissions for Database Accounts

RDS for PostgreSQL allows you to grant role-based permissions to a database account for data and command access. It is recommended that administrators should create database accounts and configure least-privilege permissions for the accounts. If any account permission does not meet the role requirements, update the account permission or delete the account. RDS for PostgreSQL has some built-in accounts, which are used to provide background O&M services for DB instances and cannot be used or deleted by users.

Enabling Data Backups

When you create an RDS instance, an automated backup policy is enabled by default with the retention period set to seven days. You can change the backup retention period as required. RDS for PostgreSQL support automated backups and manual backups. You can periodically back up instances. If an instance fails or data is corrupted, use backups to restore it to ensure data availability. For details, see Data Backups.

Enabling Database Audit

By using the PostgreSQL Audit extension (pgAudit) with your RDS for PostgreSQL instance, you can capture detailed records that auditors usually need to meet compliance regulations. For example, you can use pgAudit to track changes made to specific databases and tables, as well as record users who make such changes and many other details. pgAudit is disabled by default. Enable it as required. For details, see Using pgAudit.

Do not bind EIPs to RDS for PostgreSQL instances for direct Internet access.

Deploy RDS for PostgreSQL instances inside a Huawei Cloud internal network, not on the Internet or in a demilitarized zone (DMZ). Secure them with routers or firewalls instead of using EIPs for direct Internet access. This approach helps prevent unauthorized access and DDoS attacks. If your instance already has an EIP, unbind it. If you do need an EIP, configure security group rules to restrict the source IP addresses that can access your instance.

Updating the Database Version to the Latest

For PostgreSQL versions that are no longer maintained by the PostgreSQL community, the RDS for PostgreSQL product lifecycle will be released accordingly. Using an earlier version may pose security risks. Running the software of the latest version can protect the system from certain attacks. You can upgrade the minor version or the major version of your DB instance as required.

Configuring the Delay for Account Authentication Failures

By default, RDS for PostgreSQL instances have a built-in auth_delay extension. auth_delay causes the server to stop for a short period of time before an authentication failure message is returned, making it more difficult to crack the database password. To configure the delay for account authentication failures, change the value of the auth_delay.milliseconds parameter (which indicates the number of milliseconds to wait before reporting an authentication failure) by referring to Modifying Parameters of an RDS for PostgreSQL Instance. The default value of this parameter is 3000.

Deploying Primary/Standby Instances Across AZs

To ensure high availability and effective failover, deploy a primary/standby instance across AZs. This configuration enables an automatic failover to the standby instance in another AZ if the primary AZ fails, reducing downtime and ensuring business continuity.

Enabling Critical Operation Protection

The RDS console supports critical operation protection. With this function enabled, to enhance security of your data and configurations, the system requires your identity to be authenticated before critical operations like deleting an instance can be performed. To enable this function, enable Multi-Factor Authentication (MFA) on Identity and Access Management (IAM). For details, see Critical Operation Protection.

Changing the Default Port

If you create an RDS instance using a well-known default port, attackers may be able to infer information about your database and use the port information together with other data to launch attacks on your RDS instance. To reduce this risk, change the default database port. For details, see Changing a Database Port.

Enabling Disk Encryption

You are advised to enable disk encryption when purchasing a DB instance. Disk encryption improves the database security. Disk encryption does not encrypt backup data stored in Object Storage Service (OBS). For details, see the description about disk encryption in Buying an RDS for PostgreSQL DB Instance.

Using Point-in-Time Recovery (PITR) for Data Restoration

You can restore instance data to a specific point in time using existing backups. During the restoration, the system downloads the most recent full backup before that time point from Object Storage Service (OBS) to the target DB instance and restores data from the backup. PITR enhances RDS's ability to securely respond to data loss or corruption. For details, see PITR: Restoring a DB Instance to a Point in Time.

Interconnecting with Log Tank Service (LTS)

RDS can upload error logs and slow query logs to LTS. You can configure the log retention period in LTS. LTS helps you quickly process and analyze logs. For details, see Log Reporting.