Security Overview

RoboMQ has the mission to provide a highly secure and reliable integration service. This includes maintaining the confidentiality of its customers’ information and ensuring that customers’ information will be available when it is needed. To achieve this we use proven, tested, best-in-class security tools, technologies, practices and procedures.

RoboMQ routinely audits and manages the security of its services and applies security best practices and updates so that customers/tenants can focus on building and scaling their integration applications. RoboMQ applies security controls at every layer of the system architecture including physical and service layer and interfaces. RoboMQ also isolates each customer tenants and deploys security updates within its systems at the operating system as well dependencies and libraries as the as necessary without any service interruption. A rolling upgrade approach is followed to make the updates transparent to customers.

In addition, the RoboMQ platform is designed for stability, massively parallel processing and scale, and inherently mitigates common issues that lead to outages while maintaining guaranteed delivery and eventual consistency which are characteristics of messaging oriented middleware (MOM).

For security inquiries, please contact legal@robomq.io or contact us via our support channels and/or associated account management teams.

Security Assessments and Compliance

 

Data Centers

RoboMQ is hosted on public cloud infrastructure from Amazon Web Services (AWS), Microsoft Azure  and Google Cloud Platform . You can read further about AWS, Azure and Google security and certifications here:

aws.amazon.com/security/

cloud.google.com/security/

azure.microsoft.com/security/

RoboMQ utilizes server infrastructure, network layers, service components and technologies within these data centers for security protections at multiple layers and against multiple threats. Providing data centers continually manage risk and undergo recurring assessments to ensure compliance with industry standards.

PCI Compliance

RoboMQ uses PCI-compliant cloud infrastructure providers AWS, Google Cloud and Softlayer. These data center operations are PCI Service Provider Level 1 compliant. This is the most stringent level of certification available.

On request, RoboMQ does provide tenant specification PCI assessments and audits, of needed. The general measure broadly cover the PCI requirements for all or most customers.

Data Center Security

Physical Security

RoboMQ utilizes ISO 27001 and FISMA certified data centers managed by Amazon, Google Cloud and Softlayer. These cloud providers have many years of experience in designing, constructing, and operating large-scale data centers. Data centers are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. All visitors, contractors and personnel are required to present identification and are signed in and continually escorted by authorized staff.

The cloud providers only provides data center access and information to employees who have a legitimate business need for such privileges. Every data center employee undergoes multiple and thorough background security checks before hire. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee. All physical and electronic access to data centers by employees is logged and audited routinely.

For more details on specific measure for each providers, please refer to below links:

 

Fire Detection and Suppression

Advanced automatic fire detection and suppression equipment has been installed in the data centers to reduce risk. The fire detection system utilizes smoke detection sensors in all data center environments, mechanical and electrical infrastructure spaces, chiller rooms and generator equipment rooms. These areas are protected by either wet-pipe, double-interlocked pre-action, or gaseous sprinkler systems. These systems are actively managed by the cloud service providers Amazon, Google Cloud and Softlayer.

Power

The data center electrical power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, and seven days a week. Uninterruptible Power Supply (UPS) units provide back-up power in the event of an electrical failure for critical and essential loads in the facility. Data centers use on-site generators to provide backup power for the entire facility.

Climate and Temperature Control

Climate control is required to maintain a constant operating temperature for servers and other hardware, which prevents overheating and reduces the possibility of service outages. Data centers are conditioned to maintain atmospheric conditions at optimal levels. Monitoring systems and data center personnel ensure temperature and humidity are at the appropriate levels.

Data Center Management

Data center staff monitor electrical, mechanical and life support systems and equipment so issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.

Network Security

Firewalls

Firewalls are utilized to restrict access to systems from external networks and between systems internally. By default all access is denied and only explicitly allowed ports and protocols are opened based on business and system need. RoboMQ systems and components operate in their own Virtual Private Cloud (VPC) over the cloud provider’s infrastructure. LDAP bases role assignment and Security groups restrict access to only the ports and protocols required for a system’s specific function to mitigate risk.

Host-based firewalls restrict applications and end customer programs from establishing localhost connections over the loopback network interface to further isolate customer tasks. Virtual Private Cloud (VPC), subnet configurations and firewalls also provide the ability to further limit inbound and outbound connections as needed.

DDoS (Distributed Denial of Service) attack Mitigation

RoboMQ infrastructure provides DDoS mitigation techniques including connection rate throttling to maintaining multiple backbone connections and internal bandwidth capacity that exceeds the Internet carrier supplied bandwidth. We work closely with our providers to quickly respond to events and enable advanced DDoS mitigation controls when needed.

Spoofing and Sniffing Protections

Managed firewalls prevent IP, MAC, and ARP spoofing on the network and between virtual hosts to ensure spoofing is not possible. Packet sniffing is prevented by infrastructure including the hypervisor which will not deliver traffic to an interface which it is not addressed to. RoboMQ utilizes application and task isolation, operating system restrictions, and TLS encrypted sessions to further ensure risk is mitigated at all levels.

Port Scanning prevention

Port scanning is prohibited and every reported instance is investigated by our infrastructure providers. When port scans are detected, they are stopped and access is blocked.

Data Security

Data in Transit

RoboMQ uses SSL/TLS to secure data in transit and role based access control using LDAP for account authorization. During the SSL/TLS handshake, the client and RoboMQ service negotiate encryption keys and certificates with each other before any application data or messages are exchanged. This ensures encrypted data sent by the client or customer application can only be decrypted by the service, and vice versa. SSL certificates are updated on a regular basis or in the event of a security advisory from external security centers.

Data at Rest

For most interaction of customer applications using RoboMQ data is in transit. The messages are delivered to the destined applications and only specific value added product store any information in the cloud. Data storage components inherit the security measures described in this document including strict physical data center and system security and network isolation. Messages and payloads can be encrypted for additional security of data at rest. Messages within dedicated clusters are isolated and segmented for each customer or tenant. The trial and the test tenants are physically located on separate clusters than the production tenants.

Message Queues

Each process or application using RoboMQ uses messages queues or set of message queues running within the RoboMQ customer tenant within its own isolated environment and cannot interact with other Message Queues, Microservices or other areas of the system. This restrictive operating environment isolates security and stability issues at the task level. These self-contained Microservices using as Docker containers isolate processes, memory, and the file system while host-based firewalls restrict applications from establishing local and inbound network connections.

Hardware Decommissioning/Data Scrubbing

Decommissioning hardware is managed by our infrastructure providers using a process designed to prevent customer data exposure. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices followed by individual cloud service providers

System Security

System Configuration

RoboMQ maintains separate environments or clusters for the component of its systems including the main website, Messaging fabric, Messaging Dashboard, other analytics and visual components, and microservices runtime environment for customer processes. RoboMQ uses continuous integration practices and maintains test, staging and production environments for all its systems.

System configuration and consistency is maintained through standard, up-to-date images, docker containers and configuration and change control software, and by replacing systems with updated deployments. Systems are deployed using the most current docker and code components which are routinely updated with configuration changes and security updates and run through a suite of pre-production tests and validation before deployment.

System Access

System access is limited to RoboMQ privileged staff and requires ssh keys for identifying trusted computers along with usernames and passwords. RoboMQ follows strict policies on system access through checks and balances, management supervision and training of its staff.

Application Security

System components undergo penetration tests, vulnerability assessments, and source code reviews to assess the security of our application interface, architecture, and services layers.

Vulnerability Management

Our vulnerability management process is designed to remediate risks without customer interaction or system downtime. RoboMQ is notified of vulnerabilities through internal and external assessments, system patch monitoring, and third party mailing lists and services. Upon notification, vulnerabilities are reviewed to determine its impact to RoboMQ’s environment and components used, and assigned to the appropriate team for resolution.

RoboMQ deploys images (both VM as well as Docker containers) to cloud servers and uses configuration management tools to create, update, scan, and validate these images and containers. Run-time access to OS and system-level functions is restricted from outside access and no outside files or programs can run or be stored outside of systems and the containers of RoboMQ. New components products and features are deployed with the latest updates, security fixes, and platform configurations and are put into production as soon as they pass all functional, load, pre-production, and system tests. Existing systems can be decommissioned on the fly and replaced with new systems with no interruption of service. This process allows RoboMQ to respond quickly and keep the service operating environments up-to-date.

Data and System Redundancy and Backup

All databases containing system and customer data are fully redundant as well as fully backed up on a daily basis to secure, access-controlled, and redundant storage facilities. System binaries and images and other service components are also individually backed up in the same manner and to the same degree. Each system component or image can be restored from backups as may be necessary.

In addition and in advance of standard backup practices referenced above, RoboMQ’s system infrastructure scales and provides fault tolerant by automatically taking failed instances off-line and replacing them with new instances. Our data persistence layer will switch between redundant fully current databases without loss or disruption of messages or tasks in the event of a node or zone failure.

Disaster Recovery

RoboMQ maintains redundancy within each component and each layer to prevent single points of failure. RoboMQ utilizes multiple zones and multiple data centers for all system components, persists and replicates data across, and offers services in multiple data centers including automatic DNS failover for added geographic resiliency. The RoboMQ platform is deployed across multiple data centers all running the most current system images that provides a realtime migration capability in case of datacenter local issues and failures.

Customer Data Retention and Destruction

Customer messages that have been consumed and processes are immediately deleted. RoboMQ like any leading Message Oriented Middleware(MOM) provides destructive reads. RoboMQ is primarily and for most purposes a stateless data transfer integration platform.

Service Incident Reviews

RoboMQ reviews system and service incidents immediately after incidents to understand the root cause, impact to customers, and improve the platform and processes. We keep an internal knowledge base with a record of all previous service incidents and their fixes so that we can be sure to resolve the issue quickly should it arise again.

Customer Best Practices

Encrypt Data in Transit

Enable HTTPS and other protocols over SSL for applications and SSL database connections to protect sensitive data transmitted to and from applications. We recommend strong security mechanism for the end applications and third party applications that are integrated using RoboMQ.

Encrypt Data at Rest

Customers with sensitive data can encrypt messages to meet their data security requirements. Data encryption can be deployed within clients sending and receiving messages using industry standard encryption and the best practices for your language or framework.

Maintain Secure Account Access

To prevent unauthorized account access use a strong passphrase for your RoboMQ user/tenant account and make use of RoboMQ’s LDAP driven role-based access control (RBAC) model to control fine grained access to messaging fabric(queues and exchanges) and management, operations analytics dashboards. Credentials, tokens and project ids should be distributed to the team but not displayed publicly or in version control systems.

Make Use of error management and notifications

Logging errors and triggering alerts can be critical for troubleshooting and investigating issues. RoboMQ provides error management and notification over email, SMS or phone calls while using the platform. Sensitive data should not be logged for the privacy and confidentiality purposes. Even of the sensitive data is accidentally logged, the protection mechanism are in place to prevent access of such for any person or system other than authorized system or the person for the customer or the tenant.

Extend usage best practices to Third-Party Solutions

Applications or Microservices using RoboMQ platform may choose to use third party services for added functionality such as Amazon’s S3, email service provider, other API providers, or other service providers. Be mindful of the access methods and data shared with these providers and their security practices as you would be with RoboMQ. Where possible, use separate distinct and restrictive credentials within RoboMQ platform for providing access to the third party systems.