Essay Sample on NoSQL Database: MongoDB

Database Management forms one of the essential elements in the development of software and systems since they serve as avenues from which a system’s data can be stored, sorted as well and analyzed (Tomoda, Isoda, & Ushijima, 2019). A database can be relational or non-relational, depending on the nature of the implemented functionalities. Relational databases also referred to as SQL databases, use pre-defined or static schemas, are best suited for complex queries, and are vertically scalable. Relational databases, however, are not suitable for hierarchical data storage (Malik, Burney & Ahmed, 2020). Following such reasons, several companies and organizations in the current age have embraced the use of non-relational databases, “NoSQL.” This is the trend following reasons such as NoSQL databases can handle unstructured data, developers who don’t understand the Structured Query Language can easily use NoSQL, the database can be used in distributed systems, and they are horizontally scalable (Malik, Burney & Ahmed, 2020).

Is your time best spent reading someone else’s essay? Get a 100% original essay FROM A CERTIFIED WRITER!

Order now

NoSQL databases also offer better performance than relational databases if implemented effectively. This research paper focuses on MongoDB as one of the NoSQL databases, mostly in use in the current age. MongoDB is a document-based non-relational database that can be utilized for the storage of high-volume data (Bradshaw, Brazil & Chodorow, 2019). Unlike traditional relational databases that use tables and rows for data storage, MongoDB uses documents and collections. A group of MongoDB documents forms a collection; usually, a document is a set of key-value pairs. The research paper discusses various aspects in relation to MongoDB, including access control, encryption, user authentication, protection against injection, and support for auditing and testing.

Access Control

Access control is an essential element in database security in the sense that it controls access to sensitive data in the database. That’s is only authorized users can access certain data. Arguably, access control entails two major elements: authentication and authorization. Authentication serves as a method that verifies the identity of the user to access a resource in the database. Authorization, on the other hand, determines whether such a user should be allowed to access the particular resource. Access control, therefore, guarantees the security of files and resources in a database. MongoDB uses the RBAC (Role-Based Access Control) model for access control (Singh, 2019). The model only allows users access to resources and functions based on their roles in the given system or organization set up. Therefore in the Role-Based Access control model, a user’s access to operations and resources is determined by their roles: the user has no access to resources and operations outside their role assignments.

To use access control in MongoDB, one has to enable authorization through a setting: usually, the security.authorization or –auth setting since it is not always enabled by default. Users then have to authenticate themselves once access control has been enabled. As pointed earlier, the RBAC models involve granting one or more roles to the user. Usually, a user’s roles grant them the privilege to perform specific operations on a given resource in the database (Singh, 2019). Privileges entail a specified resource, and specific operations allowed on the resource. Privilege could be as well inherited hence the name “Inherited privileges.” Inherited roles could be the case when a role consists of one or more other roles in its definition. Roles can also be built-in or user-defined: built-in roles are those that are commonly used in a database system and are usually default. User-defined roles are created and modified to provide desired privileges to the user.

Granularity in RBAC is well-defined in the sense that different users can be granted different roles and privileges. In line with this, a new user can be created for each application or use case in the database. For instance, two users could be created for a web application, one with the least privileges that only involves running the application and the other for business analytics. The role assigning in the case creates isolated privileges for different users and therefore allows granular control of the system and database. From a security perspective, there can be the misuse of privileges if too much of them is given to users. The Role-Based Access Control model, therefore, requires due diligence, especially when assigning roles to users. Following such reasons, there are several best practices associated with accessing control that would help in implementing the Role-Based Access Control model.

Initially, one has to understand each role with its minute details since a better understanding of the roles guarantees a more accurate assignment of privileges to these roles. When assigning privileges to users, it is advisable for the principle of the least privilege, which involves only assigning relevant basic roles to users with which they can get their job done. The third best practice is the creation of a new MongoDB user for every single use case or application in the database. It is also good to create a resource that helps users to understand information security fundamentals. Security requirements should be made clear to employees as well as the consequences that can befall them should they bridge the security requirements.

Often times, employees leave an organization for various reasons; it is a good practice to revoke access for such users as soon as possible to prevent any unauthorized access. MongoDB also has an additional feature that enables client source filtering: this feature allows the administrator to filter connections base on their addresses and ranges for the Internet Protocol (Singh, 2019). It also helps the administrator to have better control over who can access the database and system.

In conclusion, the Role-Based Access control model in MongoDB makes it possible to define access control in the database. The granularity here is well-defined by the fact that each user has their roles and privileges well defined.

Encryption

This is yet another important step in database security. An encrypted message or cipher-text is one presented in the form of secret codes that conceal the true meaning of the original message: such a message can only be accessed by a specific key. MongoDB provides native encryption that is effective for database security (Chellappan & Ganesan, 2020). Normally, data in the database could be in motion or static: that is data-in-motion and data-at-rest, respectively. These data requires encryption to prevent external interference from unauthorized users. Encryption in MongoDB involves a series of actions. Initially, a master key is generated for the whole database, after which unique keys are generated for each database. At this point, the data is now encrypted with the already generated database keys. Finally, the entire database is now encrypted with the master key generated earlier.

Encrypting Data in Transit

Data transactions between a server application and MongoDB can be done through SSL or TLS (Bharti). The former is an acronym for Secure Socket Layer while the latter is an acronym for Transport Layer Security. SSL and TLS are the most common encryption protocols used for secure data transfer between systems. The basic idea involves encryption of the connections to mongos and mongod instances to ensure that the network traffic is only readable by the client it is intended for. MongoDB uses TLS/SSL alongside certificates either self-signed or issued by the certificate authorities: usually PEM files. It is, however, advisable to use certificates issued by the certificate authority since they are more secure as compared to self-signed certificates.

Encrypting data-at-rest

For this type of encryption, MongoDB introduced a native option for the WiredTiger storage engine since version 3.2 (Chopade & Pachghare, 2020). In this case, the data stored can only be accessed by a decryption key that decodes the data into a readable format. The AES256-GCM cipher algorithm is the commonly used algorithm in MongoDB (Pascal, 2020). The algorithm uses a single unique secrete key for both encryption and decryption of data. One has to turn on encryption using the FIPS mode: the mode ensures that compliance and high standards are met by encryption. At the storage level, TDE (Transparent Data Encryption) is used to encrypt all files in the database. Each time a file is encrypted, a unique private key is generated: these keys are to be later encrypted using a master key.

Key Management

Management of keys is a very crucial element in database security. As discussed earlier in this section, MongoDB keys can be master keys or individual database keys (Siriah, Deshpande & Asudani, 2018). Database keys can be stored alongside the encrypted data since they are internal to the server: these keys can only be paged in an encrypted format to disk. Master keys are usually not internal to the server, and therefore under no circumstance can they be paged to disk. MongoDB provides that the master keys be stored in a different server; it could be by third party enterprise key management solutions.

MongoDB supports two types of key management options through its encrypted storage engine. The first option can be done over KMIP: an acronym for Key Management Interoperability Protocol. The protocol enables integration with a third-party key management appliance, and it is always the recommended key management option for MongoDB (Horowitz & Nilsson, 2020). The second option provides for key management using a key file: it is also referred to as Local key Management.

In conclusion, MongoDB provides native encryption procedures, presents it as a robust DBMS that can help in securing data both in transit and in storage. The WiredTiger storage engine is the most recommended encryption procedure since it provides for better database performance as well as security and scalability.

User Authentication

Authentication in a database is verifying the client that is trying to connect to the database (Sathyadevan et al., 2015). When the client requires access, MongoDB requires them to authenticate themselves to determine their access. Although authorization and authentication seem to be closely related, authorization is different from authentication. Authentication verifies the identity of the user, while authorization determines the access to resources for the client. For authentication as a user, password, username, and the authentication database associated with the user must be provided. MongoDB supports several authentication mechanisms that users can use to verify identity. The mechanisms are Salted Challenge Response Authentication Mechanisms (SCRAM), MongoDB-CR, lightweight Directory Access Protocol (LDAP) authentication, Kerberos authentication, etc.

Salted Challenge Response Authentication Mechanisms (SCRAM-SHA-1).

Salted Challenge Response Authentication Mechanism is the most default mechanism that is used for authentication in MongoDB (Balasubramanian, 2020). The Salted Challenge Response Authentication Mechanism uses a simple format that is based on text usernames and passwords, which are given through channel protected layer security. On Salted Challenge Response Authentication Mechanism, MongoDB verifies the given client details against the authentication database client’s password and username. The client, together with the details that serve to identify the client is created in the authentication database. enge Response Authentication Mechanism are per-user random salts, tunable work factor that i...