ApsaraDB for MongoDB is developed based on the Apsara distributed operating system and a high-reliability storage engine, and is compatible with the MongoDB protocol. ApsaraDB for MongoDB uses a multi-node architecture to ensure high availability, and supports elastic scaling, disaster recovery, backup and restoration, and performance optimization.
ApsaraDB for MongoDB provides a variety of security hardening features to secure user data, including but not limited to the features described in the following topics:
Access control
Database account authentication and IP whitelists are used to implement access control and protect data security on ApsaraDB for MongoDB.
Database accounts
To log on to an ApsaraDB for MongoDB instance, you must pass the username and password authentication.
After an ApsaraDB for MongoDB instance is created, an initial root account is created by default. You can either specify the password for the root account when you create an instance or reset the password after you create an instance. For more information about how to specify the password, see (Optional) Reset a password.
The root account has all permissions on an ApsaraDB for MongoDB instance. You can log on to the database as the root user to add, delete, or grant permissions to other accounts.
IP whitelists
ApsaraDB for MongoDB allows you to configure IP whitelists for each ApsaraDB for MongoDB instance to implement network access control.
The default whitelist of an ApsaraDB for MongoDB instance contains 127.0.0.1, which indicates that the instance is inaccessible from all IP addresses. You can add IP addresses to a whitelist in one of the following ways:
Network isolation
ApsaraDB for MongoDB supports Virtual Private Cloud (VPC) and the classic network. We recommend that you use VPC because it is more secure.
VPC
VPC allows ApsaraDB for MongoDB to implement advanced network access control. VPC and IP address whitelists greatly improve the security of ApsaraDB for MongoDB instances.
A VPC allows you to build an isolated network environment in Alibaba Cloud. You can resolve resource conflicts by customizing route tables, IP addresses, and gateways in VPCs.
A VPC is a private network environment that completely isolates your network packets by using underlying network protocols. You can connect your data center to Alibaba Cloud by using a leased line or a VPN, and use the customized CIDR block of an ApsaraDB for MongoDB instance in a VPC to resolve resource conflicts. This way, you can access the ApsaraDB for MongoDB instance from both your data center and Alibaba Cloud Elastic Compute Service (ECS).
ApsaraDB for MongoDB instances deployed in a VPC can be accessed only by the ECS instances in the same VPC. If necessary, you can apply for a public IP address to allow access requests from the Internet (not recommended). For example, you can allow access requests from elastic IP addresses (EIPs) of ECS instances and the Internet egress of your data center.
For more information about VPCs, see What is a VPC?
Classic network
Cloud services in the classic network are not isolated. Unauthorized access to cloud services is blocked only by security groups or whitelists. We recommend that you select VPC, which provides increased security.
Data encryption
This topic describes the data encryption features in ApsaraDB for MongoDB.
SSL
ApsaraDB for MongoDB provides Secure Sockets Layer (SSL). You can prevent man-in-the-middle attacks by using the server root certificate to verify whether the destination database is an ApsaraDB for MongoDB instance. ApsaraDB for MongoDB also allows you to enable and update SSL certificates for servers to ensure data security and validity. For more information about how to set SSL, see Configure SSL encryption for an instance.
Important
Although ApsaraDB for MongoDB can encrypt the connection between an application and a database, SSL cannot run properly until the application authenticates the server. In addition, SSL consumes extra CPU resources and affects the throughput and response time of ApsaraDB for MongoDB instances to a certain degree. The specific impact varies depending on the number of user connection times and the data transfer frequency.
TDE
ApsaraDB for MongoDB provides Transparent Data Encryption (TDE). TDE adopts the Advanced Encryption Standard (AES) algorithm. The key for TDE is encrypted and stored by KMS.
After TDE is enabled for an ApsaraDB for MongoDB instance, the data of the specified database or collection is encrypted before being written to any device such as an HDD, SSD, or PCIe card, or to any service such as OSS. Therefore, data files and backups of the instance are all in ciphertext. For more information about how to set TDE, see Configure TDE for an instance.
Backup and restoration
ApsaraDB for MongoDB can automatically create backups to ensure data integrity and reliability.
Backup
For data integrity and reliability purposes, databases require regular automatic backups to ensure that the data in the databases can be restored in the event of exceptions.
ApsaraDB for MongoDB provides the following backup methods:
Snapshot-based backup: The state of disk data at a specific point in time is retained. This method allows data in a database to be restored within minutes.
Physical backup: Physical database files of an ApsaraDB for MongoDB instance are backed up. This method provides faster backup and restoration compared with logical backup.
Logical backup: The mongodump tool is used to store operation records of databases in a logical backup file. This method restores data in the form of playback commands during restoration.
Restoration
Data restorability is essential to ensure the reliability of database O&M.
ApsaraDB for MongoDB provides the following restoration methods:
References
The backup and restoration methods that are supported vary based on the configurations of your ApsaraDB for MongoDB instance. For more information about the backup and restoration methods that are supported by ApsaraDB for MongoDB instances, see the following topics:
Instance disaster recovery
ApsaraDB for MongoDB provides a variety of disaster recovery solutions.
Multi-zone instances
Alibaba Cloud provides cloud computing services for multiple regions around the world. Each region contains multiple zones. Faults are isolated between different zones within the same region. Network latency is low between different zones within the same region.
An ApsaraDB for MongoDB single-zone instance runs on two physical servers within the same zone. All racks, air conditioners, circuits, and networks in the zone are redundant to ensure high availability. ApsaraDB for MongoDB provides service availability that goes beyond the limits of physical servers by using the asynchronous or semi synchronous replication mode and an efficient primary/secondary failover mechanism.
To provide higher availability than single-zone instances, ApsaraDB for MongoDB also supports multi-zone instances. Multi-zone instances are deployed on physical servers within different zones. When one zone fails, services can be switched over to another zone in a short period of time. The entire switchover process does not require changes to application code.
Note
Each time you trigger a primary/secondary failover for an instance, the instance may be disconnected for no more than 30 seconds. We recommend that you perform this operation during off-peak hours and make sure that your applications can automatically re-establish a connection.
For more information about how to create multi-zone instances, see Create a multi-zone replica set instance and Create a multi-zone sharded cluster instance.
For more information about how to migrate instances to different zones within the same region, see Migrate an instance to a different zone.
Cross-region disaster recovery instances
ApsaraDB for MongoDB multi-zone instances provide disaster recovery across different zones within the same region. To improve availability, ApsaraDB for MongoDB also supports cross-region data disaster recovery. For example, you can replicate data from ApsaraDB for MongoDB Instance A in the China (Hangzhou) region to ApsaraDB for MongoDB Instance B in the China (Shanghai) region by using a data synchronization tool such as MongoShake. Instance B is a self-contained instance that has its own endpoints, account, and permissions. Instance B can be used to recover data and read data in the region where the instance resides.
For more information about how to replicate ApsaraDB for MongoDB instance data by using MongoShake, see Use MongoShake to perform one-way synchronization between ApsaraDB for MongoDB instances.
Instance A serves as a primary instance, and Instance B serves as a secondary instance. If Instance A fails due to an unexpected event such as a natural disaster in the region where Instance A resides, Instance B can be used as the primary instance. Cross-region data disaster recovery is implemented by modifying database connection configurations in your application to forward requests to Instance B.
Note
We recommend that you deploy the same geo-disaster recovery application on Instance A and Instance B to minimize the network instability and latency associated with cross-region access.
If Instance B is used as the primary instance, you must run the kill command to disable the MongoShake service. This way, data replication from Instance A to Instance B is stopped and possible problems are prevented.
Version maintenance
ApsaraDB for MongoDB provides new database versions on a regular basis, and you can upgrade your databases to the latest version.
ApsaraDB for MongoDB provides new database versions on a regular basis.
The database upgrade is optional and is triggered only after you restart ApsaraDB for MongoDB instances. For more information, see Upgrade the major version of an instance and Update the minor version of an instance.
When the ApsaraDB for MongoDB team determines that your version has major security risks, the team notifies you of scheduled upgrades.
Typically, the upgrade process is completed within 5 minutes. During the upgrade, several database service interruptions may occur.
Service authorization
Without your authorization, Alibaba Cloud after-sales team and ApsaraDB for MongoDB development team can only view information about resources, fees, and performance of your ApsaraDB for MongoDB instances. The information includes the time when an ApsaraDB for MongoDB instance is purchased and expires and its CPU, memory, and storage usage.
To allow Alibaba Cloud after-sales team and ApsaraDB for MongoDB development team to view more information about your instances to help you troubleshoot issues, you can grant permissions to them.
Only with your authorization can Alibaba Cloud after-sales team and ApsaraDB for MongoDB development team view or modify configurations about your ApsaraDB for MongoDB instances during the specified time period. For example, you can authorize them to view the IP address whitelist and audit logs of an ApsaraDB for MongoDB instance.
Alibaba Cloud after-sales team and ApsaraDB for MongoDB development team never proactively modify connection information of your ApsaraDB for MongoDB instances, including the instance endpoint and the database account and password.
Elastic Compute Service (ECS)
Lingma
