Database as a service

On this page

21RISK uses MongoDB as the underlying database for our application code. We don't host MongoDB in-house, but use the Database-as-a-Service (DBaaS) MongoDB Atlas . When developing locally, we use a local mongodb instance. When investigating issues in production, we either:

• Investigate the issue in our stage environment
• Restore production data to the stage cluster

We use a dedicated instance in MongoDB, running MongoDB version 7 , but utilize the MongoDB rapid release feature to auto-upgrade the MongoDB version.

The maximum oplog size is configured to 4000MB . The minimum TLS protocol version is configured to be TLS 1.2 and above .

MongoDB Backups

Our backup policy is 3-fold:

• MongoDB Atlas Cloud backup - full snapshot backup of all data.
• Continous Cloud backup - point in time restore backup.
• Multi region backups - geographical redundancy backup.

The full snapshot backup policy:

The point in time restore policy is configured to a restore window of 1 day.

Backup restore procedures

To restore a production backup, we follow this procedure:

1. Navigate to the production clusters page in MongoDB Atlas
2. Go to the Backup list, and choose the restore button for the decided backup
3. In the target cluster we then choose between production or stage.
4. After a good cup of cooffee, the backup is restored.

To monitor the database for anomities, we utilize the MongoDB Metrics, Profiler and auto generated recommendations.

MongoDB Encryption

TLS (Transport Encryption)

TLS is configured to minimum version 1.2, and all network traffic is encrypted. You can read more about TLS here .

Encryption at rest

All our data in MongoDB Atlas is encrypted as rest, as this is default at MongoDB.

Authorization and Roles

Access to our production environment in MongoDB Atlas is configured with a SCRAM user, using the MongoDB atlasAdmin role. We have specific users configured with limited access to dev/stage/review-apps to enforce the principle of least privilege.

MongoDB CUECs

'In their SOC 2 report, MongoDB explicitly mention that “Complementary user entity controls are not required, or significant, to achieve the service commitments and system requirements…”

However, we would like to re-emphasize some of the security features that we have adopted, related to database as service (and some that are WIP).

• When we develop locally, we are running a local mongodb database. This is important from a security perspective, because it means that we don’t need to connect to any database running at MongoDB Atlas. In other words, we don’t need to distribute credentials to a freelancer, if they “just” need to do some work on the codebase.
• If we need to share access to one of our database environments in MongoDB Atlas (dev/stage/prod), we do this through Doppler.
• We are currently looking into a new feature from Doppler that enables auto-rotation of secrets (also in production). WIP
• We make sure to always run the latest supported version of Node.js. Using the latest version of Node.js is crucial because it provides the most recent security patches, feature enhancements, and performance optimizations, ensuring your application's robustness and efficiency.
• We make sure to always run with the latest version of the MongoDB Node.js driver; it ensures optimal compatibility with newer versions of MongoDB databases, and it provides the latest security updates, enhancements, and bug fixes. The regular updates to the driver can also introduce new features and optimizations, thereby improving the performance and efficiency of your application's interaction with MongoDB.
• We don’t utilize any of the other MongoDB Atlas features like charts, Atlas Data APIs. The fact that MongoDB is open-source, makes it really flexible in disaster and recovery plans, as the database can run on almost any OS and hardware. Read more here.
• We only give admin-access to MongoDB atlas for the relevant personal at 21RISK: