One place for hosting & domains

      MongoDB

      Deploying MongoDB With Redundancy



      Part of the Series:
      MongoDB Security: Best Practices to Keep Your Data Safe

      MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

      This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

      No matter what precautions you or your cloud provider take to prevent them, computers are always at risk of hardware failure. An important part of managing any computer system, not just a MongoDB installation, is to make regular backups of your important information. By taking and storing backups of your data, you can restore your application to working order if your database server crashes and your original data is lost.

      Just as you should regularly back up your MongoDB data, it’s equally important that you store those backups in a separate location from the server hosting your database. If you were to store your backups in the same data center as your database, both the database and your backups would be unavailable if the data center were to experience a failure and you wouldn’t be able to use the backups to get your application back online.

      Replication is a practice that’s similar to making backups: where making a backup involves taking a point-in-time snapshot of all the data held in a database, replication involves constantly synchronizing data across multiple separate databases. It’s often useful to have multiple replicas of your data, as this provides redundancy in case one of the database servers fails and can also improve a database’s availability and scalability, as well as reduce read latencies. In MongoDB, a group of servers that maintain the same data set through replication are referred to as a replica set.

      The official documentation recommends that any Mongo database used in a production environment be deployed as a replica set, since MongoDB replica sets employ a feature known as automatic failover. This means that if the primary fails and is unable to communicate with the secondary members for a predetermined amount of time, the secondary members will automatically elect a new primary member, thereby ensuring that your data remains available to your application or the clients that depend on it.



      Source link

      Managing Ongoing Security Concerns in MongoDB



      Part of the Series:
      MongoDB Security: Best Practices to Keep Your Data Safe

      MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

      This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

      No matter how much effort you put into hardening your MongoDB installation’s security, it’s inevitable that new vulnerabilities will arise over time. As important as it is to run Mongo with secure settings from the outset, it’s just as important to perform frequent checks and diagnostics to determine the status of your system’s security.

      For instance, you should regularly check for new updates to MongoDB to ensure that the version you’re using doesn’t have any unpatched vulnerabilities. Mongo version numbers take the form of X.Y.Z, with X referring to the version number, Y referring to the release or development series number, and Z referring to the revision or patch number. MongoDB puts out a new release roughly every year, with the latest at the time of this writing being 4.4, but they also put out new revisions and patches as needed.

      While MongoDB generally recommends that you use the latest version available to optimize security, be aware that a new release series (meaning, from version 4.4 to version 4.6) can potentially break backwards compatibility. That said, MongoDB recommends that you always upgrade to the latest stable revision of your release series (meaning, if you have version 4.4.4 installed, you should upgrade to 4.4.5 when it’s available) as these are generally backwards-compatible patches intended to fix bugs.

      One should also consider how they intend to interact with their MongoDB database and whether that will change over time. MongoDB provides several commands and methods that allow you to perform server-side execution of JavaScript functions by default. As an example, you can use the $where operator to evaluate a JavaScript expression in order to query for documents. This provides you with greater flexibility, as it allows you to express queries for which there isn’t an equivalent standard operator. However, by allowing server-side Javascript execution, you’re also exposing your database to potentially malicious expressions. Hence, MongoDB recommends that you disable server-side scripting if you don’t plan on using it.

      Similarly, MongoDB will, by default, validate all user input to ensure that clients can’t insert a malformed BSON into the database. This input validation isn’t necessary for every use case, but MongoDB recommends keeping input validation enabled to prevent your database from storing any invalid BSON documents.



      Source link

      Weighing Your MongoDB Implementation Options



      Part of the Series:
      MongoDB Security: Best Practices to Keep Your Data Safe

      MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

      This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

      Maintaining a MongoDB database and keeping it secure is no small task, but by following the recommendations highlighted throughout this series you can reduce the number of your database’s vulnerabilities. WIth that said, the subject of securing a MongoDB database goes far beyond what could be discussed in a series like this one. Attackers are becoming more sophisticated every day, meaning that a database system could still become compromised even if it had been secured with all of the recommendations and features highlighted here.

      As MongoDB has grown more popular, a number of cloud companies have launched their own managed MongoDB database service. A managed database, sometimes referred to as database-as-a-service or DBaaS, is a cloud computing service in which the end user pays a cloud service provider for access to a database.

      Unlike a self-managed database, users don’t have to set up or maintain a managed database on their own; rather, it’s the provider’s responsibility to oversee the database’s infrastructure. Likewise, the cloud provider takes on much of the responsibilities related to keeping the database secure. Oftentimes the provider will deploy the database behind a firewall they control, and may require that any remote connections be made over TLS.

      A common feature among managed database services is that they provide automatic backups as a form of disaster recovery. Many also ensure high availability and failover through automatic replication. However, as with any cloud service, by using a managed database you’re giving up much of the control that comes with the “roll-your-own” approach of overseeing all aspects of the database yourself.

      DigitalOcean now offers its own managed MongoDB service that comes with a number of helpful security features. For example, DigitalOcean Managed MongoDB Databases require connections to be made over TLS/SSL, ensuring that your data remains encrypted as it traverses the network. The data held in a Managed MongoDB Database is also encrypted at rest through the Linux Unified Key Setup, so you can rest assured that your data will be protected from unauthorized users.

      You can deploy a DigitalOcean Managed MongoDB Database with standby nodes. In the event of a failure, the service will switch data handling over to a standby node, helping to keep your data highly available. And after spinning up a MongoDB database managed by DigitalOcean, you can secure it by restricting inbound connections to specific Droplets, Kubernetes clusters, or tags. You can even spin up a Mongo database within a Virtual Private Cloud, ensuring that your data is only accessible to resources within a trusted network.

      Click here to learn more about DigitalOcean’s Managed MongoDB Databases.

      If you work for a large company that uses MongoDB, it might be helpful to hire one or more full time database administrators or an outside consultant database administrator to help you consider which of MongoDB’s security features makes the most sense for you to implement. You might even consider MongoDB’s Enterprise edition, which includes advanced security features like Kerberos authentication and built-in auditing. However, the Enterprise Edition requires a paid subscription and still requires careful administration and oversight.



      Source link