Sitecore Xdb Security/Connectivity Details

What’s xDB Cloud?

As of version 7.5, Sitecore introduced a whole new chapter in its Experience Management Repertoire, which is known as xDB. xDB changed how Sitecore interacts with Customer interactions, and opened up a whole lot of opportunities, and increased scalability exponentially. The key factor in how this was done is the backend of xDB, which is MongoDB. MongoDB is a NoSql database which allows a very high throughput, allowing Sitecore to increase the speed, and scale up data read/write by crazy amounts. For enterprise level sites that get a lot of visitors, this is very good news as Sitecore steps into the world of Big Data.

Given Sitecore is built on top of the Microsoft Technology Stack, there could be some resistance from some companies to jump into a different technological area. Sitecore thought about this, and as of 8.0, they introduced xDB Cloud, a cloud based service for Sitecore to implement xDB, without having to host MongoDB themselves, or go for a cloud solution where they would have to do additional setup for processing and aggregation. This makes it easier to bridge the gap for some customers who were hesitant initially, as they don’t really have to deal with the details of adding on a different type of database to their existing infrastructure and do not need to acquire additional licensing for processing/aggregation/reporting.

This post is not really about xDB Cloud and its features, but if you are interested, there are two very good articles on this.

Firewall Security

Being a cloud service, Sitecore provisions xDB Cloud via a combination of cloud providers (Azure, Mongo Lab, and sometime AWS), so you will need to add a few firewall rules to make this work. For most hosting designs, the CD servers (which interact with Xdb Cloud), are situated in the DMZ, and according to best practices, access (both inbound and outbound) to servers in the DMZ are completely locked down, i.e. nothing is open unless otherwise specified. So one thing you will need to is give your network techs information about what firewall rules to create.

This becomes a little tricky, because xDB Cloud doesn’t connect to one endpoint, and all those endpoints are cloud based, so they are not static. A lot of the documents from Sitecore will say that you need to open outbound connectivity to the azure dynamic Ip range (as stated by http://www.microsoft.com/en-us/download/details.aspx?id=41653). However, any security conscious network department will balk at doing something like that from a DMZ server, so we need to get more specific. Below are the endpoints xDB Cloud needs, and you will need to make a firewall rule for each endpoint:

1. The Discovery service

The discovery service is the endpoint that Sitecore first connects to – to find the information for all the other assets it needs. CM and CD directly connects to the discovery service. This endpoint is located at discovery-xdb-cloud.sitecore.net, and connects on port 443, with HTTPS protocol.

2. Collections Repository

These are the main Mongo DB collections. Every deployment gets a separate set of hosts and ports. These hosts are usually set at the time of deployment and is unique to each deployment. After provisioning a new deployment, you will need to use the REST API Web Service for xDB to find your deployment information.

Some caveats – a collections repository contains three endpoints:

  1. The primary host
  2. The secondary host
  3. The arbiter

Note: protocol here is TCP/IP and TSL/SSL – more on that below.

However, the REST webservice will only tell you about the hosts and their ports, and doesn’t return any information about the arbiter. You will need open a support ticket to get the host and port of the arbiter for your deployment.

3. Reporting Service

The reporting service fetches reporting data from various data sources (for example, the collection or reporting databases) to use in Sitecore reporting applications, such as Experience Analytics. This is also unique per deployment. Also not available from the REST Webservice. You need a support ticket for this as well. This usually connects on port 443, with HTTPS protocol.

4. Search Service

The Search Service provides indexing capability and retrieval of information from the collections. Another endpoint that is unique per deployment, and needs a support ticket. This usually connects on port 443, with HTTPS protocol.

Additional Connectivity for the Collections Repositories

As noted, the connections to the collections repositories uses TCP/IP and TSL/SSL protocol. A client (Mongo Driver) communicates to MongoDB server through TCP/IP connection using SSL encryption. In order to do this, it must install an SSL cert on the local machine (which it does the first time when trying to connect) Whenever any TLS/SSL connection goes out from a windows machine based on the SSL cert installed, it checks the master revocation list location for that certificate, to make sure that certificate is still valid. Since all outbound traffic on the DMZ servers are closed by default, this specific connectivity is blocked.

For SSL-enabled MongoDB deployments, mLab/MongoLab signs all certificates certificate using a root certificate of the DigiCert Global Root CA, and so we need the certificate revocation lists for Digicert.

The URLs of CRL servers are embedded in the certificate (also listed below – but check the certificate on your machine to make sure they are the same):

CRL Distribution Points:
URL = http://crl3.digicert.com/ssca-sha2-g3.crl
URL = http://crl4.digicert.com/ssca-sha2-g3.crl

Authority Information Access
URL = http://ocsp.digicert.com
URL = http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt

Check the CRLs (Certificate Revocation Lists) and Revoked Certificates section in the following article for port information: https://www.digicert.com/util/utility-test-ocsp-and-crl-access-from-a-server.htm (lest it changes from when this post is published).

Conclusion

xDB Cloud is a very easy way to foray into Experience Analytics as offered by Sitecore, but when getting into network security of DMZ servers, there are a few hurdles to cross. This is not documented as clearly as it should be, so hopefully some of the points here will help you set your networks techs at ease, and smoothly get you all the access you need for Sitecore.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s