One place for hosting & domains

      June 2021

      Encrypting Your MongoDB Data



      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.

      Encryption is the process of converting a piece of information from plaintext, the information’s original form, into ciphertext, an unreadable form that can only be read by a person or computer that has the right cipher to decrypt it. If a malicious actor were to intercept a piece of encrypted data, they wouldn’t be able to read it until they’re able to decrypt it.

      You can encrypt communications between your MongoDB instance and whatever clients or applications need access to it by configuring it to require connections that use Transport Layer Security, also known as TLS. Like it’s predecessor, Secure Sockets Layer (SSL), TLS is a cryptographic protocol that uses certificate-based authentication to encrypt data as it’s transmitted over a network.

      Note that TLS only encrypts data as it moves over a network, otherwise known as data in-transit. Even if you’ve configured Mongo to require connections to be made with TLS, the static data stored on the database server, called data at rest, will still be unencrypted. It isn’t possible to encrypt data at rest with the free Community Edition of MongoDB, but it is possible with Mongo’s paid subscription-based Enterprise Edition.

      Even with both encryption-at-rest and encryption-in-transit enabled, though, your sensitive data could potentially still be accessed by an unapproved user. Consider, for example, a scenario where you’ve deployed a sharded NoSQL document database to store data for an ice cream delivery application you’ve developed. The database management system allows you to encrypt data at rest, which you enable, and you also configure it to require encrypted TLS connections between the shards as well as any clients.

      In this example situation, when a customer places an order they’re asked to submit a few pieces of sensitive information, like their home address or their credit card number. The application then writes this information to the database in a document, like this:

      {
        "name" : "Sammy Shark",
        "address" : {
          "street" : "602 Surf Ave",
          "city" : "Brooklyn",
          "state" : "New York",
          "zip" : 11224
        },
        "phone" : "555-555-1234",
        "creditcard" : "1234567890123456"
      }
      

      This is a potential security vulnerability, since anyone who has privileges to access the database could see and take advantage of your customers’ sensitive information.

      To help mitigate this type of risk, since version 4.2 the official MongoDB drivers allow you to perform client-side field level encryption. This means that, when properly configured, an application can encrypt certain fields within a document before the data is sent to the database. Once the data has been written to the database, only applications or clients that can present the correct encryption keys will be able to decrypt and read the data in these fields. Otherwise, the data document would look similar to this, assuming the street, city, zip, phone, and creditcard fields have been encrypted on the client’s side:

      {
        "name" : "Sammy Shark",
        "address" : {
          "street" : BinData(6,"eirefi3eid5feiZae9t+oot0noh9oovoch3=iethoh9t"),
          "city" : BinData(6,"xiesoh+aiveez=ngee1yei+u0aijah2eeKu7jeeB=oGh"),
          "state" : "New York"
          "zip" : BinData(6,"CoYeve+ziemaehai=io1Iliehoh6rei2+oo5eic0aeCh")
        },
        "phone" : BinData6,"quas+eG4chuolau6ahq=i8ahqui0otaek7phe+Miexoo"),
        "creditcard" : BinData6,"rau0Teez=iju4As9Eeyiu+h4coht=ukae8ahFah4aRo="),
      }
      

      MongoDB stores encrypted values as binary data, as indicated by the BinData class labels in the previous example. The 6 in each value represents the binary subtype in which the data is stored, and indicates the kind of binary data that’s been encoded. Values that have been encrypted with Mongo’s client-side field level encryption always use subtype 6.



      Source link

      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