On this page

Using HA Instances
Enabling Data Backup
Avoiding Binding an EIP to Your Instance
Avoiding Using the Default Port
Periodically Resetting Passwords of Database Accounts
Periodically Checking and Deleting Roles That Are No Longer Used
Configuring Least-Privilege Permissions for Database Accounts
Avoiding Using the sysadmin Permission
Enabling Forcible Encryption
Using TDE
Configuring the Maximum Degree of Parallelism
Using DBSS for Full Audit

Show all

Help Center/ Relational Database Service/ Best Practices/ RDS for SQL Server/ Security Best Practices

Security Best Practices

Updated on 2025-02-28 GMT+08:00

View PDF

With its powerful transaction processing capability, rich functions, and wide support for enterprise-level applications, SQL Server has earned a good reputation in the industry and has become one of the preferred relational databases among many enterprises. RDS for SQL Server is a cloud-based database service that is reliable, scalable, easy to manage, and immediately ready for use. It aims to provide customers with more efficient and secure data management solutions.

To help secure your workload on RDS for SQL Server instances, follow these best practices as needed.

Using HA Instances
Enabling Data Backup
Avoiding Binding an EIP to Your Instance
Avoiding Using the Default Port
Periodically Resetting Passwords of Database Accounts
Periodically Checking and Deleting Roles That Are No Longer Used
Configuring Least-Privilege Permissions for Database Accounts
Avoiding Using the sysadmin Permission
Enabling Forcible Encryption
Using TDE
Configuring the Maximum Degree of Parallelism
Using DBSS for Full Audit

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.

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 recommended 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.

Parent Topic: RDS for SQL Server

Previous topic: Using Extended Events

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot