February 2, 2018

Sitecore = enterprise?

Or maybe more appropriate - how does Sitecore fit into an enterprise, compared to SharePoint?

Well, some time ago, I was involved in a project in the financial sector where Sitecore was supposed to take over a number of sites hosted in SharePoint.
During the architecting of the infrastructure, quite a few questions came up.

To set the scene, there was a LAN and a DMZ zone in place, each with its own Active Directory domain and with no trust between them. Also, likely not entirely surprising, no connections from the DMZ to the LAN was allowed, resulting in separate SQL servers in both zones.

Here's a list of some of the issues we had to deal with:

All database connections must be with Integrated Security.
Not really a problem with connectivity between Sitecore IIS servers within the respective zones, but a bit of a nut to crack with the way Sitecore's publishing is constructed with direct database connections. Due to the lack of trust between the network zones, our only option was to "downgrade" to SQL authentication.

All databases must be read-only
Sitecore is able to start up and render pages without a hitch, when the web database is read-only, meaning that only the db_datareader right is assigned to the database user (and never the db_owner ). However, the log file showed quite a number of issues, forcing us to grant special permissions on the following tables in the web database:

  • EventQueue (INSERT, UPDATE, DELETE)
  • Properties (INSERT, UPDATE)

The core database in the DMZ environment had the same requirements, but suffered from the same issues, thereby requiring a similar treatment:

  • EventQueue (INSERT, UPDATE, DELETE)
  • ClientData (INSERT, UPDATE, DELETE)
  • Properties (INSERT, UPDATE)
  • Tasks (INSERT, UPDATE)
  • History (DELETE)
  • PublishQueue (DELETE)

We did not have time to comb the Sitecore configuration to remove pipeline steps that actually require the above mentioned steps to be carried out, but such an approach would of course be much more suitable.

Admin user in the core database
As security was is incredibly important, users in the core database also had to be removed, as a part of the hardening of the DMZ environment. A somewhat smaller modification.

Removal of the /sitecore folder with some exceptions
Part of the hardening of the Sitecore delivery server is to remove as much of the /sitecore folder hierarchy as possible. Clearly, the following folders had to go:

  • /sitecore/admin (not that it mattered much, as login was made impossible by the above modification)
  • /sitecore/login (same as before)
  • /sitecore/debug (tries to set the site in debug mode, no-go)
  • /sitecore/shell (all the UI-stuff can't exist on a CD server)
  • less important folders such as /sitecore/portal, /sitecore/images, /sitecore/copyrights

The /sitecore/service folder contains a number of system error pages, which are nice to have in place. The folder also contains some endpoints for xDB and Analytics, which I have not investigated further into if they can be moved.

In the event of having Sitecore EXM installed, the /sitecore folder also contains some handlers for registering email clicks, opens, unsubscriptions etc.

Not to forget
Sitecore publishes a list of hardening points on the security hardening page which of course must be performed before going live with anything.

Next steps
It would be wonderful to be able to trim a Sitecore Content Delivery instance to a minimal footprint, by simply removing stuff instead of disabling functionality, but that's something for a different post.