Enterprise Sitecore xDB Security with MongoDB

This will form the second part in a two-post set outlining some of what we learnt whilst implementing xDB and Mongo for a client with enterprise grade availability and security requirements which dictated that a

The first post dealt with configuring Mongo and Sitecore to use a replica set for high availability.

In this post I'll review some of the options for meeting security requirements around the Mongo implementation for xDB.

Security

For this project, we had some quite stringent privacy requirements covering some of the types of data that were being stored in the analytics system.  These boiled down to ensuring that only authorised accounts could access the system and view information.  In my opinion the authentication/authorisation approach we've taken should be considered for any xDB installation as a good practice, however the explicit encryption requirements that we had to meet are probably a step further than a lot of organisations will want to go.


Authentication/Authorisation

MongoDB includes the capability to manage users and role based security.  Similar to how one would define a specific user to access a SQL database (and not use "sa"!), we wanted to ensure that we had a user with only the appropriate access level required for Sitecore to connect to the Mongo databases.

We started by creating a root user, that we could use to perform full administrative functions.  In Mongo each user is associated with a particular database, and we created the root user in the admin database:
use admin
db.createUser({user:”root”, pwd:”[insertPwdHere]”, roles:{role:”root”,db:”admin”}})
We then created a "Sitecore" user, in the admin database also, that we can use to have Sitecore connect to xDB with only permissions to access the various databases that Sitecore uses.  We define the inbuilt readWrite role for each:

db.createUser({user:”sitecore”, pwd:”[insertPwdHere]”,
roles:[ {role:”readWrite”,db:”analytics”},
{role:”readWrite”,db:”tracking_live”},
{role:”readWrite”,db:”tracking_history”} ]})
For our particular installation, we ended up needing to create permissions for the following Mongo databases that Sitecore creates, although depending on which modules you use this may vary:

  • analytics
  • tracking_live
  • tracking_history
  • ecm_dispatch
  • config
  • sessions
  • sessions_shared

Encryption in transit and at rest

For this particular installation, we had a requirement for analytics data to be encrypted in transit and at rest.

MongoDB supports SSL connections in it's enterprise edition (you can actually also compile your own copy of the open source with SSL enabled).  SSL is configured through the /etc/mongod.conf file:
sslMode=allowSSL
sslCAFile=ca.cert.pem
sslPEMKeyFile=/usr/local/mongodb/etc/[machinename].pem
Whilst this setup appears to be correct, we are still working through some issues with SSL connectivity which appear to relate to the C# Mongo driver.

Unfortunately there is no inbuilt functionality to support encryption at rest for Mongo databases, even in the enterprise edition.  We elected to address this requirement by hosting the Mongo database files on encrypted storage.

Other considerations

Although we haven't chosen to make use of them at this point, the Enterprise version of Mongo contains a couple of other security related capabilities which may be of use in enterprise scenarios.

  • It can support authentication of clients using Kerberos so that usernames and passwords don't need to be stored in configuration files.
  • It also supports auditing of user and application access to Mongo.

Sitecore configuration

Sitecore configuration strings needed to be updated to support both authentication accounts and SSL.  The connection string format used to connect to Mongo using a specific user account is as follows:
mongodb://[user]:[password]@server1,server2,server3/[database]?replicaSet=sitecoreReplSer&authSource=admin
The user and password defined with access to the database it entered as a part of the connection string as shown, the rest of the details are the same as outlined in my high availability configuration post, except that we specify in the authSource parameter the database where we created the user account.  This allows us to create a single account which has access to the multiple databases Sitecore uses.

 To also enable SSL connectivity, an additional parameter should also be appended to the above connection string:
&ssl=true

Conclusion

I hope the details in this series of two posts has helped you set up your Sitecore xDB Mongo servers to achieve a more stable and secure xDB environment to house your analytics data.

Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

Setting up TDS to work with Azure DevOps

Sitecore - multi-site or multi-instance?