Security Best Practices
Security is a shared responsibility between Huawei Cloud and you. Huawei Cloud is responsible for the security of cloud services to provide a secure cloud. As a tenant, you should properly use the security capabilities provided by cloud services to protect data, and securely use the cloud. For details, see Shared Responsibilities.
This section provides actionable guidance for enhancing the overall security of using DDS. You can continuously evaluate the security status of your DDS DB instances and enhance their overall security defense by combining different security capabilities provided by DDS. By doing this, data stored in DDS DB instances can be protected from leakage and tampering both at rest and in transit.
Make security configurations from the following dimensions to meet your business needs.
- No Binding an EIP to Access DDS over the Internet
- No Using Weak Passwords
- No Using the Default Port
- Limiting the Maximum Number of DDS Connections
- Disabling IPv6
- Disabling Script Execution
- Configuring the Audit Policy
- Enabling SSL
- Enabling Disk Encryption
- Enabling Data Backups
- Configuring Monitoring by Seconds and Alarm Rules
- Upgrading the Version of a DB Instance
- Checking Roles
No Binding an EIP to Access DDS over the Internet
Do not deploy DDS on the Internet or DMZ. Instead, deploy DDS on the internal network of your company and use routers or firewalls to protect DDS. Do not bind an EIP to access DDS from the Internet. By doing so, DDS can be protected from unauthorized access and DDoS attacks. You are not advised binding an EIP to access DDS from the Internet. If necessary, you must set security group rules.
No Using Weak Passwords
When creating or changing an account password, ensure that the password meets the password complexity requirements and do not use weak passwords. By doing so, passwords can be protected from hacker and rainbow table attacks. For details about how to check for weak passwords, see Checking for Weak Passwords.
No Using the Default Port
The default port for MongoDB is 27017. If the default port is used, it is easy to be listened on, which poses security risks. You are advised to use a non-default port. For details, see Changing a Database Port.
Limiting the Maximum Number of DDS Connections
Excessive DDS connections will consumer excessive server resources, leading to sluggish response of the OPS operations (such as query, insert, update, and delete). Also, you need to set net.maxIncomingConnections to an appropriate value based on the operating system environment. If the value is greater than the maximum number of threads received by the operating system, the setting is invalid. For details, see Parameters.
Disabling IPv6
IPv6 subnets are not supported. You are advised to select an IPv4 subnet when creating a DDS DB instance.
Disabling Script Execution
If the security.javascriptEnabled parameter is enabled, JavaScript scripts can be executed on mongod, which poses security risks. If the javascriptEnabled option is disabled, the mapreduce and group commands cannot be used. If your application does not require operations such as MapReduce, you are advised to disable javascriptEnabled. For details, see Parameters.
Configuring the Audit Policy
The audit function can be used to record all database operations performed by users. Auditing logs can enhance your database security and help you analyze the cause of failed operations to improve system O&M. For details, see Audit Logs.
Enabling SSL
If SSL is not configured, data transmitted between the MongoDB client and server is in plaintext, which is vulnerable to eavesdropping, tampering, and man-in-the-middle attacks. To improve the security of data transmission, you are advised to enable SSL. For details, see Enabling or Disabling SSL.
Enabling Disk Encryption
Enabling disk encryption improves data security. For details, see "Disk Encryption" in Custom Config.
Enabling Data Backups
DDS supports automated and manual backups. You can periodically back up databases. If a database is faulty or data is damaged, you can restore the database using backups to ensure data reliability. For details, see Data Backups.
Configuring Monitoring by Seconds and Alarm Rules
DDS DB instances can be monitored by default. If the value of a metric exceeds the threshold, an alarm is triggered. The system automatically sends an alarm notification to the cloud account contact through SMN, helping you learn about the status of your DDS instance in a timely manner. Configure proper monitoring and alarm rules based on service requirements. For details, see Monitoring and Alarm Reporting.
Upgrading the Version of a DB Instance
DDS supports minor version upgrade and major version update. You can upgrade your DB instance to the latest version to add new functions, fix problems, and improve security and performance. You are advised to upgrade the version of a DB instance in a timely manner.
Checking Roles
DDS allows you to grant role-based permissions to a database account for data and command access. You are advised to create user-defined roles based on service requirements and grant the minimum permission to a database account. You can also update or delete a database user as needed.
No. |
Check Item |
Description |
---|---|---|
1 |
The user with the userAdmin role |
After the user with the userAdmin role is defined in the admin database, the user is provided with all permissions of all users. That is, the user with this role can define their own permissions on any database. |
2 |
The user with the userAdminAnyDatabase role |
After the user with the userAdminAnyDatabase role is defined, the user is provided with all permissions of all users. That is, the user with this role can define their own permissions on any database. |
3 |
The role with the anyAction action |
After the role with the anyAction action is defined, the role-based user is provided with all operation permissions on the corresponding database, which affects permission management. |
4 |
The role with the anyResource action |
After the role with the anyResource action is defined, the role-based user is provided with all resource permissions on the corresponding database, which affects permission management. |
5 |
The role with the changeCustomData action |
After the role with the changeCustomData action is defined, the role-based user is provided with the permission to modify all user-defined information in the corresponding database, which affects permission management. |
6 |
The role with the changePassword action |
After the role with the changePassword action is defined, the role-based user is provided with the permission to change the passwords of all users in the corresponding database, which affects permission management. |
7 |
The role with the createRole action |
After the role with the createRole action is defined, the role-based user is provided with the permission to create all roles in the corresponding database, which affects permission management. |
8 |
The role with the createUser action |
After the role with the createUser action is defined, the role-based user is provided with the permission to create all users in the corresponding database, which affects permission management. |
9 |
The role with the dropRole action |
After the role with the dropRole action is defined, the role-based user is provided with the permission to delete any role in the corresponding database, which affects permission management. |
10 |
The role with the dropUser action |
After the role with the dropUser action is defined, the role-based user is provided with the permission to delete any user in the corresponding database, which affects permission management. |
11 |
The role with the grantRole action |
After the role with the grantRole action is defined, the role-based user is provided with the permission to grant all role permissions to all users in the corresponding database, which affects permission management. |
12 |
The role with the revokeRole action |
After the role with the revokeRole action is defined, the role-based user is provided with the permission to revoke any role permission from any user in the corresponding database, which affects permission management. |
13 |
The role with the authSchemaUpgrade action |
After the role with the authSchemaUpgrade action is defined, the role-based user is provided with the permission to execute authschemaupgrade, which affects permission management. The authschemaupgrade command is used to modify the user authentication conversion format. |
14 |
The role with the closeAllDatabases action |
After the role with the closeAllDatabases action is defined, the role-based user is provided with the permission to run the closeAllDatabases command, which affects permission management. The closeAllDatabases command is used to close all databases and release the memory occupied by MongoDB. |
15 |
The role with the dropDatabase action |
After the role with the dropDatabase action is defined, the role-based user is provided with the permission to run the dropDatabase command to delete any database, which affects permission management. |
16 |
The role with the getParameter action |
After the role with the getParameter action is defined, the role-based user is provided with the permission to run the getParameter command to view the values of all command line options, which affects permission management. |
17 |
The role with the setParameter action |
After the role with the setParameter action is defined, the role-based user is provided with the permission to run the setParameter command to change the value of any command line option, which affects permission management. |
18 |
The role with the shutdown action |
After the role with the shutdown action is defined, the role-based user is provided with the permission to run the shutdown command to clear all database resources and stop processes, which affects permission management. |
19 |
The role with the getCmdLineOpts action |
After the role with the getCmdLineOpts action is defined, the role-based user is provided with the permission to run the getCmdLineOpts command to obtain the argv and parsed fields, which affects permission management. The argv field contains the mongod or mongos command string, and the parsed field contains all runtime options. |
20 |
The role with the internal action |
After the role with the internal action is defined, the role-based user is provided with the permission to perform all operations on the corresponding database, which affects permission management. |
21 |
The user with the readWrite role |
After the user with the readWrite role is defined, the role-based user is provided with the read permission and data modification permission on the corresponding database, which affects permission management. |
22 |
The user with the backup role |
After the user with the backup role is defined, the role-based user is provided with the insert and update permissions in the mms.bak file in the admin database, which affects permission management. |
23 |
The user with the clusterAdmin role |
After the user with the clusterAdmin role is defined, the role-based user is provided with the highest cluster management permission, which affects permission management. The role has the permissions of the clusterManager, clusterMonitor, and hostManager roles. |
24 |
The user with the clusterManager role |
After the user with the clusterManager role is defined to manage and monitor operations in a cluster, the role-based user is provided with the permission to manage local databases that are shared and replicated, which affects permission management. |
25 |
The user with the clusterMonitor role |
After the user with clusterMonitor role is defined, the role-based user is provided with the read-only permission for the monitoring tool, which affects permission management. |
26 |
The user with the dbAdmin role |
After the user with the dbAdmin role is defined, the role-based user is provided with the administrator permissions on the corresponding database, which affects permission management. |
27 |
The user with the dbAdminAnyDatabase role |
After the user with the dbAdminAnyDatabase role is defined, the role-based user is provided with the same permissions as the dbAdmin role, which affects permission management. The role applies to all databases in a cluster, and also has the listDatabases operation permission on the cluster. |
28 |
The user with the dbOwner role |
After the user with the dbOwner role is defined, the role-based user is provided with the permission to perform all database management operations, which affects permission management. This role has the permissions of the readWrite, dbAdmin, and userAdmin roles. |
29 |
The user with the hostManager role |
After the user with hostManager role is defined, the role-based user is provided with the permission to monitor and manage servers, which affects permission management. |
30 |
The user with the readAnyDatabase role |
After the user with readAnyDatabase role is defined, the role-based user is provided with the permission to read data from all databases, which affects permission management. This role also has the listdatabases operation permission on the cluster. |
31 |
The user with the readWriteAnyDatabase role |
After the user with readWriteAnyDatabase role is defined, the role-based user is provided with the permission to read data from and write data to all databases, which affects permission management. This role also has the listdatabases operation permission on the cluster. |
32 |
The user with the restore role |
After the user with restore role is defined, the role-based user is provided with the permission required for restoring backups, which affects permission management. |
33 |
The user with the root role |
After the user with root role is defined, the role-based user is provided with all operation permissions on all resources, which affects permission management. The role has the permissons of the readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabases, clusterAdmin, and restore roles. |
34 |
The user with the userAdmin role |
After the user with the userAdmin role is defined, the role-based user is provided with the permissions of all users, including their own permissions, which affects permission management. |
35 |
The user with the userAdminAnyDatabase role |
After the user with the userAdminAnyDatabase role is defined, the role-based user is provided with the permissions of all users on all databases, including their own permissions, which affects permission management. |
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