Security Best Practices

Using HA Instances

Each RDS for SQL Server cluster or primary/standby instance can perform a failover and promote the standby node to primary if the primary node fails. This ensures high availability and service continuity and minimizes downtime and data loss.

Enabling Data Backup

When you create an RDS for SQL Server instance, an automated backup policy is enabled by default with a retention period of seven days. You can change the backup retention period as required. RDS for SQL Server instances support automated backups and manual backups. You can periodically back up your instance. If the instance fails or data is damaged, restore it using backups to ensure data reliability.

Avoiding Binding an EIP to Your Instance

Do not deploy your RDS for SQL Server instance on the Internet or in a demilitarized zone (DMZ). Instead, deploy it on a Huawei Cloud private network and use routers or firewalls to control access to your instance. To prohibit unauthorized access and DDoS attacks from the Internet, do not bind an EIP to your instance. If your instance already has an EIP, you are advised to unbind it. If you do need an EIP, configure security group rules to restrict the source IP addresses that can access your instance.

Avoiding Using the Default Port

The default port of RDS for SQL Server is 1433, which is vulnerable to malicious attacks. To avoid this risk, change the port for your DB instance.

Periodically Resetting Passwords of Database Accounts

Periodically resetting passwords is one important measure to enhance system and application security. This practice not only lowers the chances of password exposure but also helps you meet compliance requirements, mitigate internal risks, and boost your awareness of security. By doing so, you can significantly improve account security and protect sensitive data and systems from potential security threats. For details, see Resetting a Password for a Database Account.

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.

Configuring Least-Privilege Permissions for Database Accounts

RDS for SQL Server allows you to grant role-based permissions to a database account for data and command access. You are advised to 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 SQL Server has built-in accounts. They are used to provide background O&M services for DB instances. Do not use or delete them.

Avoiding Using the sysadmin Permission

The sysadmin permission in RDS for SQL Server is the highest permission. Misusing this permission can lead to security O&M failures. This could result in data corruption, inability to restore data, or difficulties in performing a primary/standby switchover.

To improve the security and stability of RDS for SQL Server, do not use the sysadmin permission. The principle of least privilege, refined permission management, and enhanced audit and monitoring can significantly reduce security risks, protect data and systems, and improve overall security management.

Enabling Forcible Encryption

Forcible encryption ensures that all data transmitted between each client and RDS for SQL Server is encrypted. In this way, data can be effectively prevented from being eavesdropped or tampered with during transmission, improving both data privacy and security. Once forcible encryption is enabled, all clients automatically communicate with RDS for SQL Server in encryption mode. Using this function eliminates the need to configure each client individually, making security management easier.

Using TDE

RDS for SQL Server uses Transparent Data Encryption (TDE) to protect data at rest by encrypting data files and backup files. Encryption in TDE is transparent to applications and meets compliance requirements. However, using TDE may affect the performance and storage space.

After TDE is enabled for an RDS for SQL Server instance, data files are encrypted and do not need to be encrypted again using disk encryption. TDE is recommended over disk encryption because disk encryption affects database and OS performance.

Configuring the Maximum Degree of Parallelism

To optimize query performance and resource utilization, you can adjust the maximum degree of parallelism of your RDS for SQL Server instance by setting max degree of parallelism. Setting this parameter to a large value can cause lock blocking, and setting it to a small value can cause insufficient resource utilization. You are advised to set it based on the resource usage and instance specifications. It is advised to set the initial value to half of the vCPUs of your DB instance or adjust the value based on the actual load. For details about how to modify a parameter, see Modifying RDS for SQL Server Instance Parameters.

Using DBSS for Full Audit

Audit logs can capture detailed records that auditors usually need to meet compliance regulations. For example, DDL audit is enabled for RDS for SQL Server instances by default to track changes in server settings, database, and table structures. In addition, you are advised to use Database Security Service (DBSS) to obtain full audit logs. The audit logs contain DML audit content and can be stored for 180 days or longer.