Security and compliance
This topic describes how Acquia Cloud, building on Amazon Web Services (AWS) and Drupal, provides a secure environment for your websites. It includes the following sections:
- Acquia Cloud and the shared responsibility model
- Amazon AWS Control Environment
- Physical security
- Customer segregation
- System access controls
- OS and LAMP stack security patch management
- Antivirus upload scanning
- File system encryption
- SSL and HTTPS
- Data and physical media destruction
- Acquia Search
- Critical: One day
- High: 7 days
- Medium: 30 days
- Low: 90 days
- All paid sites on Acquia Cloud can use SSL.
- Dedicated load balancers are not required.
- Customers may use their own certificate from any SSL vendor.
- Acquia supports all valid SSL certificates: single-domain, multi-domain (UCC/SAN), wildcard, Extended Validation, or even self-signed.
- This feature is available to all customers.
- Read more about this feature.
Security in the cloud is a shared responsibility between the service provider and the customer. Acquia Cloud provides a secure platform where Acquia customers may build and manage world-class, highly secure Drupal sites. Acquia manages, monitors, and secures the environment where our customer websites run including the operating system and LAMP (Linux, Apache, MySQL, PHP) stack and network layers of Acquia Cloud. Additionally, Acquia provides tools, support, and resources that enable our customers to maintain secure Drupal websites.
Customers have numerous responsibilities in regards to the security of the sites they host with Acquia Cloud. Customers must understand what data they intend to collect and store in their Drupal website and ensure that risks and compliance requirements are addressed, which correlates to the importance and sensitivity of that data. Customers must ensure that security is addressed during the development lifecycle of their Drupal site including ensuring that secure development best practices are followed and that security testing is conducted as part of the change process. Customers must ensure that the security controls that are deployed to the Drupal site are in line with the risk and the mission of the website. Depending on the customer's requirements and preference, either a third-party developer, Acquia, or the customer's staff may be responsible to ensure that account provisioning and account management controls are managed, both in the Drupal site and in the Acquia management platform.
Acquia Cloud is built within Amazon's AWS data centers and uses Amazon's Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) and Elastic Block Store (EBS) services. Amazon personnel do not have logical access to Acquia Cloud hosts or applications nor to the data of any Acquia Cloud customers hosted on Acquia Cloud platforms.
To maintain the high level of security it provides to its customers, Amazon does not disclose all the details about network topology, physical locations, and AWS-specific security procedures to the public. Acquia Cloud leverages Amazon's certifications and attestations including ISO27001:2005, SSAE16 SOC 1, SOC 2, SOC 3, and PCI-DSS ROC to provide assurance to Acquia and its customers to the security of the infrastructure, network, and physical security layers of Acquia Cloud. Amazon shares certification information about the AWS control environment with strategic partners such as Acquia under nondisclosure agreements (NDAs), and thus Acquia cannot release this information to any unauthorized party. Acquia is committed to maintaining a high degree of transparency and trust with its customers, so Acquia makes as much information available to its customers that it can legally and safely disclose.
To find more information regarding the security and compliance of Amazon AWS, see or contact Acquia http://aws.amazon.com/security/.
Amazon's AWS data centers follow and enhance best practices in data center physical security. The exterior physical security is military grade. Personnel who enter the data center are authorized and verified by a government issued ID, a two-factor authentication at each entrance point. Each entrance is monitored by video surveillance, and all access is logged and audited. All visitors and contractors must present identification and are signed in and continually escorted by authorized staff. Amazon AWS does not permit guests, customers, or strategic partners, such as Acquia, to either tour or inspect its data center. Therefore, Acquia cannot facilitate any type of physical inspection of AWS hosting facilities for customers.
Acquia maintains some infrastructure on its premises, for example, IP phone switches and LAN equipment, but this equipment is not used to either host customer websites or to store sensitive customer information. Acquia cooperates with customers both to provide tours and inspections of Acquia office facilities and to meet with Acquia management and security specialists to discuss Acquia Cloud's control environment.
Acquia Cloud Enterprise provides independent, logically separate environments for each customer site. Each component (web servers and databases) of the customer's technology stack in Acquia Cloud Enterprise is provisioned on unique, logically distinct servers with the exception of the load balancers. Independent load balancers are optional to Acquia Cloud Enterprise customers at an additional cost. Within Acquia Cloud, Acquia manages host-based firewall policy (IPTables), which provide network isolation between logically distinct customer environments within Acquia Cloud.
Acquia limits privileged access both to the information on the customer servers under its management and to the servers themselves strictly to its full-time operations and support teams. Network layer controls ensure that privileged access is always enforced through secure bastion hosts, using encrypted tunnel through non-standard ports. Authentication requires a two-factor authentication: the SSH key and a time-generated, one-time passcode. Each privileged user's password-protected SSH key is stored on an encrypted volume. All access attempts via SSH are logged and retained for audits.
Customers may provision non-privileged user accounts to the customer's web nodes via the Acquia web-based UI and APIs. The Acquia platform gives customers the ability to create named users and upload those users' SSH public keys, which are deployed to the customer's web servers, enabling non-privileged access via SSH.
Acquia manages access to the cloud environment’s Apache docroot directory using version control; there is no write access to this directory. Acquia customers provision non-privileged access to their Acquia Cloud web nodes through Acquia's web-based Acquia Cloud management interface. The Acquia platform provides site administrators with the ability to add non-privileged users' accounts and SSH keys, which are then deployed to the customer's Acquia Cloud web nodes.
Acquia’s security and operations teams subscribe to relevant security notification feeds, including Ubuntu security notices and US-Cert. When a patch or update has been published at the operating system layer or specific to a software component, the patch and vulnerability is reviewed to determine if it's relevant to the Acquia Cloud environment. If so, Acquia's information security manager opens a tracking ticket assigned to the operations team. The operations team deploys the patch to the preproduction environment both to determine if service restarts are required and to verify that the patch does not introduce system errors. The update is scheduled for deployment to production. If the patch or update requires a service restart that may affect customers, a notification is sent to Acquia Cloud customers notifying them of the impending maintenance.
Acquia uses a central management platform to deploy security patches across all Acquia Cloud server instances. Acquia currently has standardized on Ubuntu 10.04 LTS Lucid as its supported Linux distribution.
Acquia has a formal risk-rating system based on factors such as likelihood, impact, and severity and deploys patches according to the following schedule:
Acquia installs ClamAV on all Acquia Cloud web servers. ClamAV is an open source (GPL) antivirus engine designed for detecting Trojans, viruses, malware and other malicious threats. To enable ClamAV virus scanning on files as they are uploaded to your Drupal website, install, enable, and configure the ClamAV Drupal module, which connects to the ClamAV executable on your Acquia Cloud server. For more information, see Enabling virus scanning for file uploads.
You can use a couple of options to enable encryption at rest. Customers may choose to have their EBS-based file system encrypted. Volumes are encrypted with Linux Unified Key Setup (LUKS) using AES and SHA-256. This option does entail a negative performance impact.
Alternatively, you can implement Drupal modules that enable the encryption of fields that contain confidential information within the database. For more information, see encrypting and decrypting content in Drupal.
You should configure SSL certificates on the primary domain name to provide SSL security for authentication functions on customer sites and for any secure transactions taking place.
Acquia Cloud Professional: Customers can enable SSL entirely on their own via the "SSL" page on the Cloud UI. SSL support costs $30/mo. That does not include the SSL certificate, which customers must provide themselves. Note that in Acquia Cloud Professional, users cannot use SSL on a bare domain name, such as https://mysite.com. It must be in the form https://www.mysite.com ("www" can be anything).
Acquia Cloud Enterprise: Customers should submit a support ticket asking for SSL to be enabled. SSL support is free for up to two sites. Customers must provide their own certificate. For customers who need to use a bare domain name, for example, http://mysite.com instead of https://www.mysite.com, Acquia still offers the old-style version of SSL exactly as it always has. This option isn't available in Acquia Cloud Professional.
Customer confidential information is never stored outside of the AWS infrastructure for extended periods of time or on physical media, such as a CD or removable USB media.
Customer data would only be transferred outside of Amazon's EC2 environment if it was needed to help solve a customer’s problem, and local problem resolution steps were required. After this problem was rectified, the files would be purged. In practice, customer-sensitive information is never stored on laptops, mobile devices, or physical media outside of the protections AWS provides.
Paper media isn't used at Acquia's offices for printing sensitive information, because there is never a need to transfer database information to paper.
When a customer cancels service with Acquia, the customer's servers are terminated, and the website data is deleted. Hard drives and other storage media are never removed from the data centers before the data has been sanitized, so that the data cannot be recovered. When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual“) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. If a hardware device is unable to be decommissioned using these procedures, the device will be degaussed or physically destroyed in accordance with industry standard practices.
The Acquia Cloud environment ensures that the appropriate level of logging is implemented at the application (Drupal), web server (Apache), load balancing (nginx), database (MySQL-Percona), and operating system layers (Linux) necessary for analysis and investigation in the case of an incident or issue. Each layer of the stack logs to the local environment in real time. Logs are backed up to S3 storage daily and retained for three months.
Acquia Search is hosted on a shared infrastructure with logical separation between each customer's data. Each customer site's index data is segregated unto itself in separate data files and directories. Each customer site is provisioned with a separate account ID and key; the authorization to the search infrastructure only allows each individual site to access its own search data. An HMAC signature is included both in the request and the response to ensure proper authorization and the integrity of the content. Additionally, the session between the application server and the search server is encrypted over SSL if available.