Jitterbit Harmony is hosted on AWS cloud infrastructure. Jitterbit chose AWS as it provides a platform that addresses Jitterbit Harmony's scalability and availability, and many of its security requirements.
The IT infrastructure that AWS provides is designed, managed, and third-party audited in alignment with security best practices and a variety of IT security standards. See Amazon Web Services: Overview of Security Processes for a description of core AWS security services.
In addition, integration projects deployed on Jitterbit Harmony can be configured to meet several industry-specific regulations and standards, including:
- Health Insurance Portability and Accountability Act (HIPAA)
- General Data Protection Regulation (GDPR)
- Cloud Security Alliance (CSA)
- SOC 1 Type 1 and Type 2
- SOC 2 Type 1 and Type 2
- SOC 3 Type 1 and Type 2
- ISO 27017, 27001
Physical and Environmental Security¶
Jitterbit Harmony is deployed across AWS managed data centers. More information on AWS physical security can be found at AWS Data Centers – Our Controls.
Business Continuity Management¶
Jitterbit Harmony leverages AWS's infrastructure to provide very high levels of availability. AWS has designed its systems to tolerate system or hardware failures with minimal impact.
High Availability and Fault Tolerance¶
Data centers are built in clusters in various global regions. In case of failure, built-in processes reroute customer data traffic away from the affected area to avoid downtime affecting your data. Core applications are deployed in an N+1 configuration, so if a data center failure occurs, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.
Jitterbit Harmony is deployed across three independent and geographically-distinct clouds (each with a primary and secondary region): NA East and NA West; EMEA East and EMEA West; APAC East and APAC West, with three data centers (availability zones) in each region.
Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk floodplains; specific flood zone categorization varies by region. In addition to discrete UPS and onsite back-up generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple Tier-1 transit providers.
This provides high levels of resiliency for Jitterbit Harmony, as it can tolerate most failure modes, including natural disasters or system failures without shutdown.
In the United States, in case of a widespread catastrophic outage, Jitterbit can also route all traffic destined for the affected data center to a data center on the opposite coast.
Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
AWS only provides data center access and information to employees and contractors who have a legitimate business need for such privileges. 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 AWS employee. All physical access to data centers by AWS employees is logged and audited routinely.
Jitterbit's Operations and Customer Support teams work to identify any issues that may impact Jitterbit Harmony users. They monitor Jitterbit Harmony's API usage, databases, services, messaging infrastructure, and Jitterbit Cloud Agent Groups. The Jitterbit Support and Operations teams provide global coverage to detect any critical issues and manage the impact and resolution of those incidents.
Jitterbit Harmony's infrastructure is supported by the Amazon Incident Management team, which employs industry-standard diagnostic procedures to drive resolution during business-impacting events. Staff operators provide 24/7/365 coverage to detect incidents and to manage the impact and resolution.
Jitterbit implements various methods of internal communication at a global level to coordinate all critical communication across Jitterbit's Operations, Customer Support, Engineering, QA, and Service teams. These teams have a presence across the US, Asia, and Europe. Our employees understand their individual roles and responsibilities and know when to communicate significant events in a timely manner.
Jitterbit has standard daily meetings among the various teams, which include team managers and company officers, to highlight any known issues and ensure that there are no bottlenecks within the organization preventing fast resolution.
Jitterbit Harmony resides within the AWS network, which has been architected to provide the level of security and resiliency required for Jitterbit Harmony to support high trust and service levels.
Jitterbit Harmony is geographically dispersed, with a fault-tolerant architecture supported in all core services. Jitterbit Harmony relies on AWS world-class network infrastructure that is carefully monitored and managed. This includes:
Secure Network Architecture¶
Network devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services.
Specifically, AWS provides the following services to Jitterbit and Harmony:
Jitterbit Harmony infrastructure components run in separate AWS Virtual Private Clouds. Each stack is an isolated network. Most services run in a private subnet. Only TLS endpoints and a bastion host (for Jitterbit management) are exposed to the Internet. Backend users connect to the stack through the bastion host, which restricts access to stack components and logs activity for security review.
All stack hosts run mandatory inbound firewalls configured in deny-all mode. HTTP, HTTPS, and SSH ports are opened only as necessary.
Distributed Denial of Service (DDoS) Protection and Mitigation
- Jitterbit Harmony's Virtual Private Cluster (VPC)-based approach means that no backend infrastructure is directly accessible from the Internet. As such, Harmony components cannot be targeted directly for a DDoS attack. AWS perimeter controls are in place (and tested) and are designed to prevent and detect DDoS attacks. Response teams and supporting processes are in place on behalf of all AWS clients.
- Jitterbit Harmony TLS endpoints include an AWS Elastic Load Balancer, which only supports valid TCP requests, meaning DDoS attacks such as UDP and SYN floods do not reach the Harmony application layer.
- We acknowledge that no control set is perfect. Should Jitterbit need extra capacity to deal with a potential DDoS attack, we can instantly scale our technology stack.
AWS tools and teams monitor and block unauthorized port scanning. Because Harmony's cloud infrastructure is private and all hosts are protected by robust firewalls, port scanning is generally ineffective.
Spoofing and Sniffing
AWS configures their network and hosts to prohibit sending traffic with a source IP or MAC address other than its own. The AWS hypervisor is configured to disallow the delivery of any traffic to a host the traffic is not addressed to. This means that any host trying to run in promiscuous mode will not be able to sniff traffic intended for other hosts.
Man-in-the-Middle (MITM) Attacks
All of the Jitterbit Harmony APIs are available via TLS protected endpoints, which provide server authentication.
Intrusion Detection and Prevention
AWS applies IPS and IDS controls for all hosted environments. Jitterbit has deployed its own IPS tool to prevent and detect anomalous and malicious activity.
Network and Host Vulnerability Scanning
AWS scans the Internet-facing network and Jitterbit scans Harmony's private network systems regularly. AWS and Jitterbit are jointly responsible for host security. AWS and/or Jitterbit remediate adverse findings without customer intervention or downtime.
AWS regularly penetration tests their infrastructure. Annually, Jitterbit also engages a third-party security service firm to do a penetration test of the Harmony infrastructure. For both AWS and Jitterbit, any penetration test findings are remediated immediately.
Secure Harmony Hosts
AWS provides Jitterbit with secure hardware (server/hosts) and operating systems. AWS uses the Center for Internet Security (CIS) Configuration Benchmark for the operating systems and versions.
For all operating systems:
- Automated configuration management tools install bare operating systems from "gold" images.
- Password logins for hosts are disabled. SSH root keys are not permitted.
- No unauthorized user SSH keys are permitted on hosts by default. Jitterbit internal workforce user access is configured only on a per-user basis, and only when necessary to provide developer or customer support.
- Non-default SSH ports are used.
- Host security updates are automated.
- All host ports are opened only via allowlist.
The only external communication possible with Jitterbit Harmony is via HTTPS using Transport Layer Security (TLS), a cryptographic protocol designed to protect against eavesdropping, tampering, and message forgery.
Network Monitoring and Protection¶
Jitterbit Harmony leverages AWS utilization of a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity.
Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system, so alarms are quickly and reliably communicated to operations personnel.
Jitterbit Operations and Support teams work with Engineering to handle any incidents or issues related to Jitterbit-developed software or infrastructure. All critical issues are identified and discussed during daily calls among the teams. Postmortems are documented after any significant operational issue, regardless of external impact, and root cause analysis (RCA) reports are drafted so the root cause is captured, and corrective and preventative actions are put in place.
Jitterbit leverages AWS security-monitoring tools to help identify and resolve DDoS attacks, including distributed, flooding, and software/logic attacks. In addition to this, Jitterbit employs its own tools, monitoring and detection system with the ability to reroute to another region if needed.
Jitterbit Harmony gains the benefits of the AWS network, which provides significant protection against traditional network security issues as described in the Secure Network Architecture section.
Secure Design Principles¶
Jitterbit Harmony's development process follows secure software development best practices. Formal design reviews, code scans, and vulnerability scans validate that Jitterbit software is designed and developed to prevent error messages from transmitting sensitive information and ensure that software services reject unauthorized access and misuse.
Routine, emergency, and configuration changes to existing Jitterbit Harmony infrastructure are authorized, logged, tested, approved, and documented in accordance with industry norms for similar systems. Updates to Jitterbit Harmony's infrastructure are done to minimize any impact on the customer and their use of the services. The Jitterbit Trust site provides a public-facing dashboard that lists any outages and periods of system performance degradation, as well as scheduled maintenance and software releases.
Jitterbit Engineering applies a systematic approach to managing change so that changes to customer-impacting services are thoroughly reviewed, tested, approved, and well-communicated. The change management process is designed to avoid unintended service disruptions and to maintain the integrity of service to the customer. Changes deployed to production environments are:
- Reviewed: Peer reviews of the technical aspects of a change are required.
- Tested: Changes being applied are tested by a separate QA team to ensure they will behave as expected and not adversely impact performance.
- Approved: All changes must be authorized in order to be rolled out by Engineering, QA, and Customer Support.
When possible, changes are scheduled during regular change windows. Emergency changes to production systems that require deviations from standard change management procedures are associated with an incident and are logged and approved as appropriate.
Jitterbit Harmony runs inside a Virtual Private Cluster (VPC) and includes the following services within each region:
- Elastic Load Balancer (ELB) that ensures requests to Jitterbit Harmony services and APIs scale and are highly available together with the Apache Tomcat Cluster where Jitterbit Harmony services run. The number of nodes per cluster scales dynamically as request volumes scale up and down.
- Caching Server Cluster for managing user sessions. This cluster is designed with built-in redundancy to ensure that a user's session is not affected, switching to another node when needed.
- MQ Broker Network that manages requests for agents. This ensures that there is a highly available redundant network among Jitterbit Harmony and all agents.
- Relational Database Server with near real-time asynchronous replication across regions. This ensures that all project designs and activity data are available across regions in the event that an entire region becomes unavailable.
AWS services are architected to work efficiently and securely with all AWS networks and platforms. Each service provides extensive security features to protect sensitive data and applications.
Amazon Elastic Compute Cloud (Amazon EC2) Security¶
Jitterbit Harmony makes extensive use of AWS Elastic Compute Cloud (EC2), which provides resizable computing capacity using server instances in AWS's data centers.
Multiple Levels of Security¶
Jitterbit Harmony leverages the security within Amazon EC2 provided via the virtual instance OS firewall. External API access is only available on the Jitterbit Harmony HTTPS servers. All other services are protected behind the firewall.
Jitterbit Harmony Amazon EC2 currently utilizes a highly customized version of the Xen hypervisor, taking advantage of paravirtualization (in the case of Linux guests). Because paravirtualized guests rely on the hypervisor to provide support for operations that normally require privileged access, the guest OS has no elevated access to the CPU. The CPU provides four separate privilege modes: 0 through 3, called rings. Ring 0 is the most privileged and 3 is the least. The host OS executes in Ring 0. However, rather than executing in Ring 0 as most operating systems do, the guest OS runs in a lesser-privileged Ring 1 and applications in the least-privileged Ring 3. This explicit virtualization of the physical resources leads to a clear separation between guest and hypervisor, resulting in additional security separation between the two.
Each Jitterbit Harmony Virtual EC2 instance is controlled by the Jitterbit Operations team. All Jitterbit Harmony instances are hardened and utilize certificate based SSHv2 to access the virtual instance. All key pairs are generated by Jitterbit Operations in order to guarantee that they are unique, and not shared outside Jitterbit Operations.
Load Balancing Security¶
Amazon Elastic Load Balancing (ELB) is used to manage traffic on a fleet of Amazon EC2 instances. ELB has all the advantages of an on-premises load balancer, plus several security benefits:
- Takes over the encryption and decryption work from the Amazon EC2 instances and manages it centrally on the load balancer.
- Provides a single point of contact, and also serves as the first line of defense against attacks on your network.
- Supports end-to-end traffic encryption using TLS (Transport Layer Security, previously SSL) on those networks that use Secure HTTP (HTTPS) connections. When TLS is used, the TLS server certificate used to terminate client connections can be managed centrally on the load balancer, rather than on every individual instance.
- Supports creation and management of security groups associated with your Elastic Load Balancing, when used in an Amazon VPC, to provide additional networking and security options.
Jitterbit Harmony uses Amazon S3 for file data storage. This data includes transformation schemas, database drivers, plugins and in certain cases, temporary and log files.
Jitterbit Harmony uses the Amazon S3 Encryption Client to encrypt data before uploading to Amazon S3. Amazon S3 uses one of the strongest block ciphers available: 256-bit Advanced Encryption Standard (AES-256). With Amazon S3, every protected object is encrypted with a unique encryption key. This object key itself is then encrypted with a regularly rotated master key. Amazon S3 provides additional security by storing the encrypted data and encryption keys in different hosts.
Data Durability and Reliability¶
Amazon S3 is designed to provide 99.999999999% durability and 99.99% availability of objects over a given year. Objects are redundantly stored on multiple devices across multiple facilities in an Amazon S3 region. To help provide durability, Amazon S3 PUT and COPY operations synchronously store customer data across multiple facilities before returning SUCCESS. Once stored, Amazon S3 helps maintain the durability of the objects by quickly detecting and repairing any lost redundancy. Amazon S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, Amazon S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data.