When enabling MongoDB Authentication post-set up, it’s important to do the following things if you want to avoid downtime.

Introduction: Productivity versus Security

Organizations must strike a balance between enabling employees to be productive and efficient while ensuring that access to sensitive information and resources is adequately protected. 

On one hand, productivity is crucial for organizations to remain competitive and achieve their goals. Employees need access to various systems, data, and tools to perform their tasks efficiently. Restricting access too much or implementing overly stringent security measures can hinder productivity and impede workflow.  

On the other hand, permission security is necessary to safeguard sensitive information, prevent unauthorized access, and mitigate the risk of data breaches or other security incidents. Organizations need to implement access controls, user permissions, and authentication mechanisms to ensure that only authorized individuals can access specific resources. These security measures help protect confidential data, intellectual property, and other critical assets from unauthorized use or disclosure.

Finding the right balance between productivity and permission security involves careful consideration and risk assessment.

Background: DB Access That is Not Authorized or Authenticated

When using a VPN or VPC, it’s easy to think that you don’t need any authentication or ways to enable authorization. After all, it is a private network. And, when it comes to productivity, manual provisioning takes time and needs constant oversight. It’s easy to see why so many companies choose to forgo security in favor of productivity. 

However, as these companies grow, they need to implement security measures and be compliant–all without interrupting productivity.

Method for Access Control: Adding User Passwords Post Set-up

For the many companies that didn’t set up authorization in MongoDB at the very beginning, it’s not too late. Setting it up after transitioning to the cloud is not impossible, but it does take some know-how. 

• Identifying Your Users
  • To be able to identify who the user is, you first need the connection string to get the username and password for your database user. If there is none, you can create a new database user to obtain these credentials. 

• Enabling Authorization in MongoDB
  • MongoDB does not enable access control by default. DBAs can enable authorization using the –auth or security.authorization setting. When you enable authentication, this also automatically enables client authorization. Enabling access control on a MongoDB deployment enforces authentication. With access control enabled, users and applications are required to identify themselves and can only perform actions that adhere to the permissions granted by the roles assigned to their user.

• Enabling MongoDB Authentication
  • Enabling authentication in MongoDB is necessary for user passwords to be recognized and read. But once you enable it, you’re breaking the way that everything works today, such as accessing MongoDB without a username or password.

Problem: MongoDB Authentication Breaking the Way Everything Works.

It’s not only people who need to access MongoDB to be affected; it’s also applications. So, in effect, none of the applications can access that MongoDB either.

Enabling authorization post-set up will break how teams work unless it’s done smartly.

How We Solved the Transition to MongoDB Authentication

It’s important to run the mongoDB with TransitiontoAuth enabled, which allows for accepting of  both authenticated and unauthenticated connections. Clients connected to the mongoDB during the transition state can perform read, write, and administrative operations on any database, so it’s important to remember to disable the feature after transitioning. 

This transition puts the company in an in-between state that allows access two ways: ones with user password connection strings and ones without. So, essentially you’re not really restricting any access because you can access it also without the user password. However, you are now starting to log and can therefore see who  hasn’t moved to using a password yet.

Conclusion: When in transit mode you should start working with Apono

Without Apono, it’s necessary for companies to create their own users and their own policies to these. But with Apono, they don’t need to do that. They can ask for what they need, and it’s automatically granted. How? When someone asks permission for a user, Apono goes inside the Mongo, creating a policy that will fit those needs, and giving the requestor a user. Then that user can be utilized to connect the model when the authentication is turned off.