This Security Policy was last revised on February 10, 2020.
Cloud security is important for the protection of hosted information. Even small gaps in security coverage can put everything at risk, including data, customer information, uptime, and potentially a company’s reputation. A certain amount of confidence is needed when relying on third-party vendors to manage and handle your data. We want our customers to have a general understanding of what we at CloudAMQP are doing to protect the integrity of their data.
This living, continuously-updated document will give a brief introduction to the security policies at CloudAMQP. Because effective security is a team effort, our security policies are not limited to this document alone. We routinely audit and manage the security of our services and adopt best practices for our security policy.
Our internal development, operations, and processes have been constructed to provide maximum data security.
A well-built environment starts with high coding standards that guard against attempted security breaches and are accompanied by code reviews and tests. We have strict development processes and we are following specified coding standards to ensure the best security practices.
System components undergo tests (various black box and white box tests) and source code reviews to assess the security of our application interface, architecture, and service layers before we add our code into production. CloudAMQP always reviews the security of third-party applications before we are adding them to CloudAMQP services.
Server and system access is limited to a few authorized people at CloudAMQP and requires short-lived signed SSH keys and two-factor authentication. Furthermore, everyone at CloudAMQP is forced to enable two-step authentication on every cloud platform that provides it (such as AWS and Heroku). Individual authentication credentials are never shared.
CloudAMQP always applies patches when advised by the manufacturer for our servers and associated devices. Critical patches are applied within 48 hours of release.
All end-points (computers, laptops, mobile phones, etc.) use encrypted storage, secure passwords, and auto-locking mechanisms. In the case of mobile phones, only applications from trusted application stores such as the AppStore and the Google Play Store are allowed. All end-point devices are patched to the latest stable OS update and application updates. Malware and anti-virus applications are installed where applicable.
Our physical infrastructure is hosted and managed on a range of different data centers (AWS, Azure, IBM Softlayer, GCE, Rackspace, Alibaba Cloud, etc.). We rely on their flexible and secure cloud infrastructure to store data logically across multiple cloud regions and (in AWS) availability zones. The data centers ensure the utmost in data security and protection and that all data is stored in highly-secure locations. All data centers that run our solution are secured and monitored 24/7. Physical access to data center facilities is strictly limited to select cloud staff. The data centers and staff continually manage risk and undergo recurring assessments to ensure compliance with industry standards.
How specific data centers handle fire detection, power loss, climate disasters, temperature control, data center management, and other disasters can be found on the data centers' websites.
CloudAMQP provides several security capabilities and services to increase privacy. No one will be able to connect or view your RabbitMQ server as long as you take care of your connection credentials. All customer information used in the development and test environments is anonymous.
CloudAMQP uses SSL/TLS to secure data in transit. SSL certificates are updated on a regular basis or in an event of a security advisory from external security centers. You have to enable TLS/SSL to and from your application to ensure secure transit between CloudAMQP and your application (read more in section 3.3.3 TLS).
Message data and it's payload are replicated across two or more zones on all two and three-node clusters in AWS (if nothing else specified by the customer). Messages and payloads can be encrypted for additional security of data at rest.
This section describes what you can do to protect your account in the best way possible.
You are responsible for maintaining the security of your unique password and account information at all times. We recommend you to use strong passwords that rotate, which can be done from the control panel of your instance. We also recommend that everyone in the team enable two-step authentication to secure access to your account even more.
Use CloudAMQP teams to invite your co-workers to your project rather than sharing user credentials.
We want to keep you in the loop on important actions on your CloudAMQP account. Therefore we will notify you via email if we detected something unusual about recent access.
CloudAMQP does support TLS (SSL) to encrypt your data in transit. We advise that you take your own measures to protect sensitive data transmitted to and from applications. Note that TLS will only secure messages during transport. What we recommend for highly sensitive information (HIPAA, PCI, etc.) is that message bodies are encrypted on your side and that you have a shared key between your publishers and your consumers.
Amazon VPC (Virtual Private Cloud) lets you define a private network in the cloud. It’s a service that provides isolation and security and is built on deny-all-by-default security, as we have to explicitly permit inbound and outbound traffic to the instance. More information about VPC isolation in CloudAMQP can be found here: Amazon VPC Peering on CloudAMQP and information about AWS VPC, in general, can be found here: VPC Security on AWS
Google Cloud Platform VPC (Virtual Private Cloud) lets you define a private network in the cloud. It’s a service that provides isolation and security. It is built on deny-all-by-default security - as we have to explicitly permit inbound and outbound traffic to the instance. More information about VPC isolation for GCP in CloudAMQP can be found here: GCP VPC on CloudAMQP and information about GCP VPC in general, can be found here: VPC network overview on GCP.
All employees undergo pre-employment background checks and must agree to company policies before starting their employment (including confidentiality and security policies).
All new employees at CloudAMQP undergo Security Awareness Training as well as Compliance and Policy Training, to help ensure that employees understand their individual roles and responsibilities concerning data processing and controls.
During employee exit processes all login details for employees who have resigned are removed and ssh keys are rotated. All data on electronic devices used by the employee who has resigned are completely removed.
The employee who has resigned signs an agreement to not mention anything about business operations or customer detail.
We provide an ongoing yearly program of Security Awareness Training designed to keep all members of staff informed and vigilant of security risks.
A few employees at CloudAMQP are able to access the server and RabbitMQ but will not view any messages sent across our servers without permission. CloudAMQP cannot access message payloads that have been encrypted at the client level.
All electronic devices used by CloudAMQP employees have enabled disk-based encryption.
The following TOMS are conducted by 84codes AB:
No unauthorized access to data processing systems is provided. Data is stored in highly secure data centers that are monitored 24/7. Physical access to data center facilities is strictly limited to select cloud staff.
No unauthorized system usage is allowed. SSH keys are required when identifying trusted computers along with usernames and passwords. Two-step authentication is enabled on every cloud platform where it is available (platforms such as AWS and Heroku). Individual authentication credentials are not shared and SSH keys are frequently rotated. All end-points (computers, laptops, mobile phones, etc.) use encrypted storage, secure passwords, and auto-locking mechanisms.
No unauthorized reading, copying, changing or removing is allowed within the system.
Personal data is processed in dedicated systems that are not shared with other services, applications or corporate entities. Within individual systems and databases, data is segregated with logical access control. Personal data is not used for purposes other than what it has been collected for without explicit customer approval.
No unauthorized reading, copying, changing or removing during electronic transmission or transport. Data in transit is encrypted and encrypted storage is used.
Logging systems are in place to determine and record whether and by whom personal data was entered, changed or removed.
Protection against accidental damage or destruction or loss of data is in place via escalation ways and emergency plans.
No data processing under commission is allowed, according to Art. 28 of the GDPR, without corresponding instructions from the data controller via explicit contract design, formalized order management, stringent selection of the service provider, obligation to convince in advance, and follow-up inspections.
Systems and services are designed to withstand intermittent high stresses or high constant loads of processing.
The use of personnel, customer, and supplier IDs instead of names is prioritized to protect personal data.
Data encryption measures are in place to protect personal data.
Personal data is stored in redundant data storage and backups are performed on the databases on a regular basis.
Privacy management is in place to prevent the flow of important information to unauthorized individuals.
Incident Response Management plan is in place.
Data protection by default according to Art. 25 para. 2 of the GDPR.
Please feel free to contact us with any questions about this Security Policy, suggestions or concerns about any of the points outlined above at firstname.lastname@example.org