George Washington University is looking to move our Drupal instance out to the cloud in the form of IaaS - a LAMP stack at AWS, Azure or some other provider. We are doing this to make our public-facing websites independent of the GW infrastructure and data centers. Our Information Security team is raising concerns about the ability to protect and harden the environment. Would people be willing to share the following information if you are running a LAMP stack in a hosted environment for your Drupal:
School:
Host Provider:
Security measures implemented:
Go Live Date:
Drupal version:
We have a full build-out of Drupal 7 and use an Installation Profile that we use to deploy sites using Aegir. We have over 300 sites and are not looking to reengineer our entire platform. I'm sure others have blazed this trail long ago and need to move my security team to a comfort zone with this methodology.
Thanks,
Mark Albert
Comments
How we did it with ee.co.uk
I work with EE - a large UK mobile phone company - and when they launched a Drupal 7 multi-site platform in Amazon AWS in 2012 they took the following basic steps to protect the codebase and data (this is all from memory from three years ago so the following is only a basic outline of what was done):
Use server-level IP restrictions to prevent access to any Drupal paths beginning /admin from IP addresses which aren't in a whitelist of addresses; so, for UW, if all the people who would be administering the site had to be based on campus (or can VPN into the campus if remote working), then you can only allow access to /admin* when coming from the xxx.xxx.xxx.xxx/32 IP range, for example.
Furthermore, serve the site on two URLs; in our case, we used e.g. http://ee.co.uk and https://admin.internal.ee.co.uk (not the actual domain name - just an example). The first URL is the public-facing web address and has public DNS records, while the second URL only exists in EE's internal DNS servers as a separate IP address.
The servers are then configured to only serve Drupal pages beginning /admin* on the https://admin.internal.ee.co.uk domain (they serve all the other Drupal pages, too - so you can log in and use the site as normal - but this is the only way to access https://admin.internal.ee.co.uk/admin/*).
We also used an encryption module to ensure that any user-submitted data in our webforms is encrypted when stored on the database.
From a content management perspective, a strict workflow permissions implementation and carefully managed user roles means only a very few selected users of the site can publish content for public viewing; in your case, I imagine you would need to be more open about who can publish to "live", although there are still ways you can use modules such as Workflow to ensure that content is reviewed by at least one person before going live.
That's just my two dimes'-worth, and isn't an exhaustive list, but hopefully it should get you up and running.
We found that Amazon AWS is very good at providing security tools which let us be confident about the security of our data, but it comes at quite a price as you start to scale for high availability (we used multiple web servers, serving reverse-proxy cached content from a cluster of Percona databases - one writeable master, and multiple read-only slaves iirc).
Hope that helps a little :)
/Alex