Skip to Content

Security best practices for administrators, project builders, and integration specialists

Introduction

This document is for administrators, project builders, and integration specialists who integrate Jitterbit with other products, such as Salesforce, NetSuite, and other endpoints. When working with your projects, build with security foremost.

Note

Integration project methodology contains useful information for an integration project PM.

Before deploying projects, you should have completed a recent audit of your company's security infrastructure and procedures. A security audit is a structured, validated evaluation of your company's information system security. The security audit measures how your company's security conforms to a set of established, industry-standard criteria, which include policies, procedures and requirements.

Note

Security audit and compliance information:

This is not a complete list. Other resources may be available through your organization's security and compliance specialist.

If you operate under any regulatory requirements, such as US FAA or FDA, ensure your security setup is in compliance with these requirements.

Security and data protection regulations

There are important governmental regulations you may be subject to, depending on where you operate your business or where your customers live and work. These regulations deal with data privacy for which you, along with Jitterbit are responsible.

Note

The following regulations require Jitterbit, its technology partners, and you to implement and maintain reasonable or appropriate administrative, physical, and technical safeguards. These laws and regulations afford specific privacy rights that you must adhere to. In addition, each has specific reporting timeframes and requirements.

United States of America state and federal regulations:

European Union and European Economic Activity Zone regulations:

  • GDPR (General Data Protection Regulation) gives control to individuals in the EU (European Union) and EEA (European Economic Area). It requires businesses to ensure that their processes that handle personal data must be designed and implemented with safeguards to protect data. These businesses must also disclose their data collection, use, and retention policies.

Cloud agents and private agents

When you run an integration, Jitterbit connects your data through the agents you configured. Agents can be cloud agents or private agents and agents exist in groups. Groups are sets of agents in the same Environment, which provide high availability. This means that if one group goes down and is unavailable, another can take its place and continue with your work. Cloud agent group is a set of agents maintained and managed by Jitterbit in the cloud. Private agent groups are maintained and managed by you, using your own servers or instances within your firewall or hosted virtually on private clouds. By running private agents, your sensitive business data will remain within your managed networks.

Note

Which agent type to use?

  • Use cloud agent groups when you want to run your integration in the cloud and you need the scalability that cloud agent groups offer.
  • Use private agent groups when you want to – or must – run integrations on your premises.

Cloud agent groups

Cloud agents are maintained and managed by Jitterbit. Jitterbit cloud agents are multi-tenant and are locked down. Data that flows through is transient and only remains on the agent to complete processing. You can't control or configure the Jitterbit cloud agent group or its agents as you can with your private agent groups.

When the Jitterbit cloud agent group performs an integration, it connects directly with the application that requires data integration. It then reads and posts data to these applications. If you use persistent storage as part of your project, it will remain on the agent for 24 hours. Data persisting in the Jitterbit cloud agent group is stored in encrypted Amazon S3 buckets that are not directly user accessible. Each integration stores data in its environment's bucket. For detailed information on Amazon S3 network security and best practices, see Amazon S3 Security.

If you have a regulatory requirement that restricts data from residing in the cloud or outside geographic boundaries, use a private agent group instead.

Private agent groups

Because you manage and control private agents, you control their security. When you use private agents, data doesn't leave your servers. If you use a private cloud, you choose where your integration runtime environment operates and you control which network your business data travels and resides in.

Private agents authenticate and communicate with Harmony over HTTPS. Private agents 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. Security is your responsibility when using private agents.

Jitterbit provides advice and best practice recommendations for hosting private agent code in System requirements for private agents.

Note

If you are using private agent groups, review the information under Security and data protection regulations.

Secure endpoints with private agents

There are many methods you can use to secure endpoints including:

  • Use a VPN (Virtual Private Network) along with encryption.
  • Network allowlists can control who is allowed access to your network. To use allowlisting with private agents, see Allowlist information.
  • Make sure any drivers and plugins you use are up to date and tested.

Organizations and environments

Different users and groups will need different access levels to access your Organizations and Environments. A user doesn't need the same access level as a developer or an administrator. For example, a developer in your organization may need Execute and Write permissions to the API Manager to create and edit security profiles, create and edit APIs, and access certain functionality in Management Console. The day-to-day user doesn't require these elevated permissions. Think about users and groups and what they do. Limit access so that users can only use what they need to perform their tasks.

Apply hardware and software patches. For cloud agent groups, Jitterbit is responsible for code changes. If you are using private agent groups, monitor updates and patches to your OS and application software, drivers, and plug-ins, and apply them when appropriate.

Providing secure authentication using OAuth and multi-factor authentication, such as 2FA (two-factor authentication) is critical. OAuth is discussed under security profiles in the API Manager. 2FA is discussed in Jitterbit password controls.

Keep development and testing accounts separate from production. This includes separate IDs and passwords. Remove these development and testing IDs and passwords before migrating code to production. Instead, use project variables to store information such as IDs and passwords. As a best practice, maintain separate development, testing, and production environments. You should also ensure that Personal Identifiable Information (PII) is not used in testing.

Note

If you are in a regulated industry, such as health care, or if you are subject to government regulations concerning data and data movement, review those requirements as part of your security planning.

API security

Note

For an in-depth discussion on API security, see API Manager security.

The Jitterbit API Manager supports OAuth 2.0 authentication with Google, Okta, and Salesforce as Identity Providers. NetSuite now enforces token-based authentication (TBA) for Administrator, Full Access, and other highly privileged roles as of their 2018.2 release. See NetSuite 2018.2 token-based authentication for more information and instructions. API Keys and API Secrets can be used to authenticate users with the API Manager API.

Certificates

Jitterbit can authenticate with external resources with SSL client certificates when connecting to HTTP or SOAP endpoints in Integration Studio, and with HTTP endpoints or Web services in Design Studio. Client Certificates settings can be accessed in the Harmony portal on the Management Console > Customizations > Client Certificates page.

Add certificates to a keystore

Jitterbit applications that are installed locally include a trusted keystore that contains the certificates needed for secure communication via HTTPS. For example, you would add a new certificate to the Jitterbit Java keystore if you use a proxy server and need to allow the Jitterbit local client to securely communicate through the proxy server. You can add new certificates as needed. You will also need to replace or renew certificates if they are changed. Information and instructions on adding certificates to a keystore can be found on these pages:

Connector security

When migrating your project to another environment, you want to avoid sharing private information. Start with these connector security features:

  • Project Variables: When working with Connectors, project variables can provide additional security. If you're creating scripts or transformations, use project variables for private information such as login or user IDs, passwords, access keys, and other information that must be kept secure. See Using project variables in scripts or transformations for information and procedures.

  • Configuration: Unencrypted user names and passwords are required at runtime. Use keystores and pull this information from a database stored off the agent and not called until runtime.

  • Third-party Vaults: Secure, digital online vaults are designed to protect the privacy of your data. Using data encryption, strong user authentication, and redundant storage, these vaults allow cloud storage with data security. The specific features, pricing, and instructions depend on the provider you choose.

  • IP Allowlists: In most situations you don't need to make any special network or firewall changes when private agents or Design Studio communicate with Harmony. What if your network is behind a firewall? In that case, configure your network to communicate with Harmony and use a allowlist to allow this communication. Jitterbit provides allowlisted IP addresses for each region. See Allowlist information for more information.

Log security

When thinking about logging and security, examine your business requirements. Decide on what level of logging you need and what risks are acceptable to you based on your security requirements. Jitterbit generates logs for different functions such as operations logs, Windows or Linux event logs, and API logs. Most customers use cloud logging in the Jitterbit cloud. Log data is encrypted for security. You can disable cloud logging if required.

Note

If you disable cloud logging, application logs are not written.

Cloud agents

When a cloud agent group runs an integration operation, it creates an activity log that is stored in the cloud. You view logs from the Runtime Operations page of the Management Console. These records and their details are retained for 30 days. Jitterbit supplies logging and error functions to help you create and debug scripting. WriteToOperationLog() can be used to write sensitive data to logs, but we strongly recommend against this as it can create a security issue.

Note

Though Jitterbit does not provide native support for sharing operation logs using tools such as ELK, Splunk, or Loggly, many log monitoring tools have agents that can be deployed on the same machine as the private agent. These agents then collect data based on defined rules and ingest data to the log monitoring tool.

Private agents

Using a private agent group keeps all your information within your organization and on your own servers. Disable cloud logging, to avoid sending logs to Harmony. At the end of each operation, you can use a script to send log data locally. Debug logs, transformation logs, error logs, endpoint call error logs, and more are available, and can be set in the jitterbit.conf file. See Editing the Configuration File - jitterbit.conf for settings and values.