Security Best Practices
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.
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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot