Logical Security and Architecture¶
Logical security is comprised of all the security measures taken within the Jitterbit Harmony software. This section describes the following:
- System Architecture
- Major Components
- Harmony Users, Organizations, and Roles
- Harmony Environments and Access Control
- Harmony Data Storage
- Harmony Security Topologies
Jitterbit enables users to design, test, deploy, run, and manage their Jitterbit integration projects. Using Jitterbit Harmony, customers can run their Jitterbit integration processes completely in the cloud without the need to procure or manage any software or the infrastructure required to operate it. Those who choose to deploy Jitterbit Harmony platform either on-premises or in a hybrid mode have the flexibility to run their integration processes by deploying private agents behind the firewall, thereby obtaining greater control on where their data flows.
Jitterbit recognizes that customers have a need for their integration processes to communicate with applications that operate behind corporate firewalls for various security and regulatory compliance reasons.
Jitterbit Harmony's system architecture caters to both scenarios: integration processes can run completely in the cloud or can run behind corporate firewalls to ensure that business data does not get exposed to the cloud. Users can also employ hybrid models where some integrations run in the cloud such as development and others for example in production can run behind corporate firewalls.
While the system simplifies the provisioning, deployment, and management of integration projects it also offers users the flexibility to run their integration operations using detachable Private Agent Groups. These are self-contained subsystems that can be installed behind corporate firewalls or on dedicated private clouds.
The separation of integration designs, which are stored on Jitterbit Harmony, from integration runtime that occurs on Agent Groups, enables customers to control access and flow of sensitive business data.
The various major components of the Harmony system architecture, and how they address security requirements, are described below.
Harmony Cloud Platform¶
Jitterbit Harmony includes multi-tenant databases, files, services, and a service-messaging infrastructure that are used to deploy, manage, and run integration projects. Jitterbit Harmony runs on Amazon Web Services (AWS). AWS provides a best-in-class, secure hosting platform that excels at providing core services to Jitterbit, such as:
- Data center security
- Physical security
- Environmental security
- Network security
- Host hardening
- High availability
- Fault tolerance
- Disaster recovery
Jitterbit develops and improves its applications by using sound software-development lifecycle (SDLC) practices such as:
- Identifying vulnerabilities from outside sources to drive change and code improvement.
- Applying hardware and software patches. Jitterbit is responsible for code changes and Amazon Web Services (AWS) is responsible for providing hardware patches; our virtual environment allows us to apply changes without any downtime.
- Providing secure authentication and logging capabilities.
- Removing development accounts, IDs, and passwords from production environments.
- Adhering to strict change management practices for code updates as well as patches.
- Separating test and development environments from production.
- Maintaining separation of duties between development and support staff.
- Ensuring that Personal Identifiable Information (PII) is not used in test environments.
- Removing test and development IDs before migrating code to production.
- Performing regular code review.
- Documenting code changes.
- Engaging senior developer input and approval for all code changes.
- Completing functionality and regression testing before release to production.
- Maintaining backout procedures to preserve high availability and integrity.
- Following secure coding practices according to an SDLC policy and addressing the security training needs for the development team.
- Checking for security flaws as prescribed by the Open Web Application Security Project (OWASP), such as injection flaws, buffer overflows, cryptographic errors, error handling, etc.
- Assessing for vulnerabilities on every release.
- Conducting annual penetration testing.
Before a user can start their work, they must authenticate with Jitterbit Harmony using their Jitterbit Harmony user account credentials; password strength, complexity and attributes, such as two-factor authentication, are customizable so that customers can match the requirements of their security policy. When single sign-on (SSO) is enabled, these requirements are instead managed by the Identity Provider. All communication with Jitterbit Harmony occurs over HTTPS (greater than TLS1.2).
Once authenticated, Jitterbit Harmony identifies all the organizations and environments that this user has access to. Jitterbit Harmony provides the user with a list of the integration assets they can work on and allows the user to create a new project in any environment where they have sufficient privileges. Privileges are role-based and selectable/configurable per environment per organization. Common roles include Administrator, User, and Read Only.
Jitterbit Harmony stores all projects deployed in a multi-tenant design repository. Jitterbit backs up these projects and the system nightly. All backups are encrypted with a Federal Information Processing Standard (FIPS 140-2) algorithm. This project repository is built on a multi-tenant database architecture, which provides logical partitioning of projects by organization and, in most instances, by environment. Specifically, Harmony isolates and secures customer projects by:
- Secure database architecture — Includes separated database and separated schema architecture.
- Secure connections or tables — Uses trusted database connections.
- Encryption — Obscures critical data so that data remains inaccessible to unauthorized parties even if they come into possession of it.
- Filtering — Uses an intermediary layer between a tenant and a data source that acts like a sieve, making it appear to the tenant as though its data is the only data in the database.
- Access control lists — Determines who can access data in the application and what they can do with it.
Projects typically contain credentials such as username and password used to connect to various endpoints. This information is encrypted within the multi-tenant repository.
The repository is replicated across two regions. Each database is also backed up and can be restored, if needed, by the Jitterbit Operations team.
Customers do not have any direct access to this repository. The various Jitterbit Harmony platform components, such as the Studio and Cloud Agents, use APIs to access the repository. Once authenticated and access control is validated, all communication with the repository is done through various API layers. In addition to controlling edge API access via HTTPS and server-side sessions, APIs must validate user access control through environment-based and Role-Based Access Control (RBAC) lists. These lists ensure that users can only view, act upon, and change the system based on the permissions granted by an organization administrator (user with Admin permission). In addition, audit trail granularity is configurable per customer.
The Jitterbit Harmony rotating activity database stores runtime status information as well as logs of running operations of all Jitterbit users.
The activity database is built on a multi-tenant architecture, and while activity data for all users resides in the same database, there is logical segmentation by organization and environment applied through a software access control layer and unique encryption keys to ensure that users can view only the activities that they have access to.
The activity database is replicated across AWS Regions and Availability Zones to ensure high availability and is backed up if there is a need for it to be restored.
Access to the activity database is provided by a set of APIs. The activity log uses similar APIs and access control list (ACL) infrastructure as the project repository.
Jitterbit Harmony includes a set of file services used to store files, such as schemas, and customizations. All files are stored in AWS S3 service and can be accessed only through Jitterbit Harmony's software and cannot be accessed directly.
To support integrations from a variety of endpoints, Jitterbit Harmony stores various types of schemas, such as WSDL, XSD, JTR, and DTDs.
To support integrations from a variety of database endpoints, Jitterbit Harmony stores various JDBC and ODBC drivers. Jitterbit also provides a framework where customers can customize the Jitterbit operations using plugins.
Certified secure plugins are available on Cloud Agents. For customers that run Private Agents, customers can use customer-created plugins to achieve efficient, plug-and-play environments. In this private security model, customers are responsible for applying reasonable administrative and technical controls for the plugins they create for their private agent(s).
The Jitterbit Harmony Studio exposes the richest set of functionalities for creating, configuring, and testing Jitterbit integration projects. Jitterbit Harmony Studio is available in two versions:
- Design Studio: Design Studio is a standalone thick client that can be installed on a Windows or Mac workstation. It requires access to the Internet on the workstation or laptop that it runs on. Communication through corporate proxy servers is fully supported, as well as IP allowlisting to ensure corporate VPN adherence if or when required.
- Cloud Studio: Cloud Studio provides a platform- and location-independent browser-based design experience. Supporting the current versions of Chrome, Firefox, Safari. and Edge browsers, and using a modern technology stack, Cloud Studio integrates seamlessly with the Harmony platform for true cloud-based design, deployment, and monitoring of integrations.
Design Studio and Cloud Studio leverage Jitterbit Harmony security features including single sign-on (SSO) and user roles and permissions. Both products use the Harmony Cloud, running on the same platform with the capability to manage the same projects.
Cloud Agent Group¶
Harmony Cloud Agents are services, known as Backend as a Service (BaaS), designed to process and service client needs on an ad-hoc basis. They perform all of their work in an event-driven fashion, thereby eliminating the need for any setup, configuration, or management traditional with "always-on" server systems that sit behind applications.
Jitterbit provides its customers the option to run all their integrations in the cloud by providing a scalable, fault-tolerant, clustered Agent Group fully maintained and managed by Jitterbit.
To enhance security and protect privacy, Jitterbit Cloud Agents are coded to ensure that locally processed data is not persistent; it is used for the minimal time necessary to complete the intended process, then purged.
When the Jitterbit Cloud Agent Group performs an integration, it will directly connect with the application that requires data integration. It will then read and post data to these applications. Customers can also choose to persist their business data in temporary files for speed and efficiency especially when processing bulk data.
Data persisted in the Jitterbit Cloud Agent Group is stored in encrypted Amazon S3 buckets that are only accessible to the agent group. Each integration stores data in its environment's bucket.
For customers that need applications to reside within their firewall, or for users that perform integrations under strict regulatory compliance that forbids data to either travel outside a given geographical boundary or reside in the cloud, Jitterbit recommends using a Private Agent Group.
Private Agents and Private Agent Group¶
Jitterbit provides the flexibility for customers to provision and manage their own Agent Groups and Private Agents (formerly known as Local Agents) within their corporate firewall or virtual private clouds. This allows customers to choose where their integration runtime environment operates and lets them control which network their business data travels and resides in. By using Private Agent Groups for integrations, companies can ensure that their sensitive business data never flows through the Jitterbit Harmony platform.
Jitterbit Harmony Agents belonging to Private Agent Groups authenticate and communicate with Jitterbit Harmony over HTTPS. Private Agent Groups deployed behind corporate firewalls can be configured to communicate via a corporate proxy server. There are no additional networking requirements, such as opening ports within corporate firewalls.
Private Agent code is created with the same coding rigor as Harmony code.
While Private Agent Groups cater for stringent security requirements, the user or customer is responsible for installing and managing their Private Agents. In the Cloud Agent Group, Jitterbit Harmony provides out-of-the-box high availability and scalability on-par with what is expected from a serverless technology. However, in Private Agent Groups, the security and scalability for Private Agents is a customer responsibility (although high availability is still ensured by the Jitterbit platform whenever more than one agent is used within a Private Agent Group). Jitterbit provides some best practice advice for hosting Private Agent code in System Requirements for Private Agents.
Runtime Messaging Services¶
Communication among various Jitterbit components, such as the Jitterbit Harmony Studio, Cloud Agents, and Jitterbit Harmony, is achieved by using a set of secure runtime messaging services based on the Java Messaging Services (JMS) API included in the Java Platform. These APIs are internal to Jitterbit components, and customers do not have any access to these APIs.
The Jitterbit Cloud Agents include listeners to the JMS messaging service. All agents that listen for requests strongly authenticate and are provided an authorized session in the Jitterbit Harmony messaging network. They can only listen to requests for their particular Agent Groups or that are made to them directly via Jitterbit Harmony. Messages are never sent to agents; agents always pick them up over HTTPS. This enables agents to run behind corporate firewalls and to remain protected without the need for opening ports that would allow incoming traffic from the Internet.
Harmony Management Console¶
The Jitterbit Harmony Management Console communicates with Jitterbit Harmony through a well-defined set of management APIs. APIs are created using the same secure coding rigor as Harmony itself, as described above in the Harmony Studio section. All users of these APIs must be authenticated with Jitterbit Harmony and all communication is transmitted securely over HTTPS.
All the management functions provided via the Management Console are further controlled by an access control layer model defined for each environment. As a result, any user using the Management Console will be able to see only the data for which they have access permission. Access controls are applied to any and all functions, including searching for operations, running operations, viewing logs, etc.
Jitterbit Harmony Data Loader is a free product within the Salesforce AppExchange that provides useful integration features targeted toward Salesforce customers. Data Loader allows customers to move data in and out of Salesforce to flat files or databases. The Data Loader product is coded with the same coding rigor as Harmony.
The Data Loader installs a custom Private Agent on the same machine where the Data Loader client is installed. For every environment one Private Agent is installed. Data Loader is not meant for scalable, highly available projects; rather, it is intended for desktop/laptop users.
Data Loader has been deployed in a production version of Jitterbit Harmony since the summer of 2013. It has been adopted by thousands of users and has been used to test the security, scalability, and availability of Jitterbit Harmony.
Harmony Users, Organizations, and Roles¶
In order to access Jitterbit Harmony, a user must register their user account. Every Jitterbit Harmony user created within Jitterbit Harmony has their own personal, role-based account and login credentials where personal integration tools and projects are stored securely.
In addition, every organization has a role called Administrator whose Admin permission allows access to all assets belonging to that organization. Administrators can add new roles to the organizations and invite other Jitterbit Harmony users to join when they need to work in teams to design, build, test, and manage their integration projects.
For more information on authentication, see the Harmony Studio section.
Harmony Environments and Access Control¶
All projects deployed to Jitterbit Harmony are deployed to environments. Environments represent a given state of an integration project. Many projects exist in various stages within different environments (e.g. a common project lifecycle configuration might have three environments: development, test, and production.) A project can exist in different states within each environment.
Organization administrators (users with Admin permission) manage access to each environment using a role-based access strategy. For example, users in the developer role may have read, execute and write privileges in the development environment, but only read access to the test environment and no access to the production environment.
The access levels for an environment include:
- View Logs: Allows a user to view logs under a particular environment but provides no visibility nor control over projects under it. This can be used to allow users to fully support but not affect projects deployed to critical environments such as production.
- Agent Install: Allows a user to install agents but provides neither control nor visibility outside of this function. This can be used to allow administrators within and outside the company to establish additional connectivity without any impact to the projects or even knowledge of the platform.
- Read Access: Allows a user to read a project from a given environment. This can be used to share project templates with various users or to allow them to view but not affect projects.
- Execute Access: Provides read access and allows users to run operations within a given environment. This is a common access control for test environments and is often granted to users who need to support an integration as they will need to both test and run/execute tasks ad-hoc.
- Write Access: Allows full control to a given environment. Users belonging to a role with write access can read, test, run, and change projects within that particular environment.
Harmony Data Storage¶
The following describes the type of information stored in Jitterbit Harmony:
When a user registers and subscribes to Jitterbit Harmony they must provide the following information, which is stored in the project repository: first name, last name, email, and phone number. Company, company address, and company website can be provided but are optional.
In order to run and manage an integration project, a user must deploy the project to Jitterbit Harmony. The project stores design and implementation details to instruct Agent Groups what activities they need to perform. This includes the following:
- Integration operations that describe what a unit of integration will do. For example, synchronize all changes to customer data in the CRM system with customer data in the ERP system.
- Transformations and scripts that describe how that data is transposed from the source system to the target system. This includes any validation rules or data manipulation required to transfer the data successfully.
- Interfaces that describe the various source and target object structures. These interfaces can be simple text structures or complex XML, JSON, or EDI object representations.
- Connections and endpoints that are used as sources or targets. While these can be hard-coded values, including system addresses and credentials, they can also be referenced through variables that can be stored in internal databases for customers that implement their own credential vaults.
- Schedules and notifications that determine when batch operations need to run and what to do in the event of successful and failed outcomes.
- API endpoints that inform agents and Agent Groups how to expose APIs so that external system events can call and invoke Jitterbit integrations.
Persistent data is secured at rest with:
- Access control lists
- FIPS 140-2 encryption and unique per customer encryption keys
Persistent cloud data is secured in transit with:
- TLS (Transport Layer Security) encryption
Integration Activity Log¶
When an Agent Group runs an integration operation, it synchronizes its logs to the Jitterbit Harmony multi-tenant rotating activity log. This includes the following information:
- Status: The state of an operation (e.g. pending, running, successful, failed).
- Agent: Which agent in the Agent Group ran the operation.
- Timing: When the operation run was submitted, started, and completed.
- Submitted By: Who submitted the request to run the operation.
- Records Processed: The number of records processed from the source system and how many records were posted to the target.
- Message: Any additional information that is relevant for troubleshooting a failed outcome, or summary information that a user explicitly tells Jitterbit to write to the log using the internal function
The activity log data is stored in the cloud on a rotating daily partitioned system. The activities for each day are captured in that day's partition and each partition is dropped after 31 days. Activity log data older than 31 days is permanently removed.
Each agent can generate additional data that can either be accessed via Jitterbit Harmony or can be stored on local file storage devices, such as file shares and SFTP, and accessed from within a firewall. These are detailed logs, which include:
- Debug logs
- Files of successful records processed
- Files of failed records processed
The Agent Groups and agents do not automatically synchronize these with Jitterbit Harmony, as they typically include confidential business data. By using their own storage devices, customers can secure their data within their firewall or on their own private cloud infrastructures.
These logs are useful for detailed troubleshooting and auditing purposes. By default, an Agent Group will store this for one to 14 days. The Agent Group can be configured to clean up this data at other intervals.
Test Data That Flows Through Jitterbit Harmony¶
In addition to data stored in Jitterbit Harmony, business data can flow through the cloud platform during integration design. This non-persistent test data flows when performing functions such as:
- Load source data: Brings sample data into a transformation tree to assist a user in identifying elements in an interface and testing transformations.
- Test transformation: Shows the transformed target result for a given set of data that is loaded.
- Test transformation function or script: Allows a user to test functions and scripts that could include a database select statement or view variable values returned from a web service API.
- Test web service call and test operation: Allows the user to run an integration and view all results on the screen.
The Jitterbit design services enforce a limit of 100 KB on all test data, thereby limiting this in-the-cloud data type to a very small subset.
Harmony Security Topologies¶
Any integration project or service, including APIs, can be deployed with the security topologies described below. Depending on the immediate and/or specific environmental needs, you should employ the topology that meets your organization's data requirements and governance policies. These deployment architectures, with associated security topologies, are summarized as follows and detailed in this section:
- Cloud: On the Jitterbit Harmony cloud, where the system and scale are completely managed by Jitterbit.
- Private (On-Premises, Local): On an on-premises server or private cloud, where the system is self-hosted and managed locally.
- Hybrid: In a hybrid mode, where particular portions of the system are self-hosted, and the rest is managed by Jitterbit.
Furthermore, Jitterbit allows any number of combinations and locations for its components, as well as allows swapping the deployment options ad hoc in different situations. This flexibility leads to these benefits:
- Greatest processing performance: Performance can be enhanced by using edge processing, where agents are located next to where the data resides.
- Ease of management: Remote management is available even for private/local deployments.
- Security and privacy: All processing is performed by the agents directly without exposure to outside parties beyond the immediate source and target connections.
Full Cloud Deployment Security Topology¶
Customers who need to perform integrations where all their data sources are accessible via the cloud can deploy their projects to Jitterbit Harmony environments and run their projects on the Jitterbit Harmony Cloud Agent Group.
Here, the Jitterbit-operated multi-tenant public Cloud Agent Group will access customer business data directly over the Internet using HTTPS. Jitterbit Agents within this Agent Group will process business data and post it to any required target system. The data will flow within the Jitterbit network using HTTPS.
All data mentioned above will persist in Jitterbit Harmony's secure operating environment for a brief period of time.
Hybrid Deployment Security Topology¶
In a hybrid deployment scenario, particular portions of the system are self-hosted, and the rest is managed by Jitterbit. For example, you may not want to expose databases and apps to any cloud systems, including Jitterbit, if your organization's requirements do not allow for data to reside in the cloud (outside the firewall) due to privacy and regulatory concerns.
In this case, the Jitterbit Private Agents reside behind the firewall, while the API Gateway is in the Jitterbit Harmony cloud. The Agent requests the information through the messaging layer and puts the payload from the apps and data sources back to the gateway via payload. Customers can limit what gets stored in the logs to prevent this data from reaching the Jitterbit Harmony cloud.
Private Deployment Security Topology¶
In most enterprise integration scenarios, the Agent Group has to access internal as well as cloud applications. Here, users would deploy their projects to Jitterbit environments, install their own Private Agent Groups within their networks that have access to their applications, and then manage those Agent Groups provisioned via the Jitterbit Harmony platform.
This topology enables users to provision and manage their Agent Groups using Jitterbit Harmony, but the Agent Group and any sensitive business data that is processed or persists resides within their network. In this topology, the Private Agent Group can run on Windows or Linux physical or virtual server environments (see System Requirements for Private Agents for further information).