Mediacurrent works with a variety of customers across many verticals to build secure Drupal applications. We sometimes encounter strict hosting policies, including on-premise requirements.
One of the great benefits of decoupling Drupal from the web frontend is the ability to move Drupal’s CMS to a secured environment that is only accessible from a VPN or private network. Statically generated frontends like Gatsby further reduce vulnerabilities to provide a robust security architecture overall.
This article will outline three options for securing Drupal, two of which include hosting the CMS behind a Firewall only accessible by a user on a secured network. The third option is the more common alternative that provides some security but does not completely lock down the CMS.
All options provide added security benefits over a traditional hosted Drupal application. Let’s weigh the pros and cons of each approach.
Option 1 - Self-hosted
The first option runs completely on self-hosted hardware, which could be stood up on-premise if so desired. While this type of approach is becoming increasingly rare, there are still contracts in the government and financial space that require all self-hosted applications.
This method will keep Drupal locked down on a web server behind a firewall that only privileged CMS users can access. GitLab is a great choice when Git repositories need to be self-managed but still require robust features that GitHub, BitBucket and GitLab’s cloud offerings provide.
A Jenkins server can be stood up to handle the automation of Gatsby builds. This includes compiling the artifacts that will be deployed to the public web server on the right-hand side. For deployments, a read-only Git deploy key is a secure way of grabbing the latest Gatsby release.
Pros:
- Ability to completely lock down the CMS environment and Git repositories
Cons:
- Must maintain web servers, Gitlab server, and automation (Jenkins)
- Most expensive solution to stand up and maintain
Why you would use this solution:
- Strict security requirements
- On-premise requirements for servers
Option 2 - Self-hosted + Cloud
The second option keeps the CMS web server behind a firewall while leveraging Cloud services for the rest of the architecture. As with the first solution, only privileged users will be able to access the CMS server. In this scenario, a Cloud Git service like GitHub will host the Gatsby source files and Netlify’s static host will run the compiled website. Netlify’s CLI can be used by the webserver behind the file server to rebuild artifacts when content is updated. A Jenkins server is a good way to handle the automation of Gatsby builds.
Pros:
- Relatively straightforward to set up
- An easier solution to maintain than completely self-hosted
- Saves cost over a self-hosted solution
- Leverage great features from Netlify (High availability, A/B testing, etc.)
Cons:
-
Requires web server maintenance for CMS behind the firewall
Why you would use this solution:
- Balance security while leveraging Cloud
- A desire for CMS to be completely locked down from outside access
Option 3 - Private with Cloud
The last solution will not use a Firewall but instead obscure access to the webserver and in some cases add basic auth for additional protections. A CDN is recommended for inline images so that media is server from a service like Cloudfront instead of directly from the server. This method will leverage a Drupal managed host provider like Acquia or Pantheon.
Pros:
- Able to use image CDN for inline Media
- Can add light protections like basic auth
- No server maintenance
- Managed host providers provide enterprise support and features
Cons:
- Server is still publicly accessible, so less secure than solution behind firewall
Why you would use this solution:
- CMS does not need to be locked down
- Security through obscurity, CMS server not indexed which shields from most attacks
Inline Images
One challenge with Gatsby is that it won’t automatically handle inline images coming from Drupal’s CMS. Gatsby does convert images that are served from Drupal’s JSON:API but it does not do anything with image paths that exist in say the body Wysiwyg HTML for any particular page.
One option is to use the TUI Editor module that converts these images to Gatsby image assets: https://www.drupal.org/project/tui_editor.
Another option would be to integrate the Drupal Amazon S3 module. This can be combined with Amazon Cloudfront to serve inline images from a secure server. Whenever a file gets saved it would be pushed up to Amazon S3 through an API and then made publicly available by Cloudfront. The AmazonS3 module allows developers to rewrite image URLs to the publicly accessible URLs that will be served by Gatsby.
Your Feedback
We hope that you have found this article helpful. Want to know more? Talk to our team of experts to discuss a solution that works for your organization.
Comments or questions? Hit me up at @drupalninja