Perimeter security addresses security at the periphery of any private network, right where it connects to the public Internet. Firewalls and other elements of the perimeter protection infrastructure enforce access control policies that govern which information enters and leaves the network.
We install and configure the following elements of the perimeter protection infrastructure:
- System firewall
- Reverse proxy server
- Load balancer
Perimeter protection policies
- We use only SSL connections.
- We open only port 443 for inbound traffic.
- We terminate SSL connections on the last element of the perimeter protection infrastructure: the load balancer.
- For inbound and outbound emails, we use a trusted enterprise-level third-party service, with manually-configured spam filters.
Authentication and Access Control
The user must be authenticated to access any of the resources within Integrator, including but not limited to:
- Elements of the interface
- Functions, such as the ability to create flows and connections, run flows, etc.
- API endpoints
We use JWT-based security, which is completely stateless and does not use sessions or cookies.
Two-factor authentication adds an extra layer of security on top of your username and password when logging into Etlworks by requiring verification of the login through a second linked device, such as Google Authenticator.
Integrator implements role-based access control (RBAC). In Role-Based Access Control, access decisions are based on an individual's roles and responsibilities within the user base.
In Integrator, each user can be assigned only one role.
The following roles are available:
- Administrator - has full control over data, can create, edit, delete flows, connections, and formats. Manages users.
- Editor - equal to "Administrator", except that they cannot manage users.
- Executor - equal to "Editor", except that they cannot create, edit, or delete and don't have access to connections and formats.
- Viewer - can only view flows, schedules and execution statistics.
- API User - sees nothing and is only used for authenticating API calls to Integrator's API endpoints, such as the HTTP Listener API.
- Strong passwords are enforced.
- JWT tokens are short-lived and automatically expire.
- The user registration is an invitation-based. New users must complete the registration in Etlworks Integrator after receiving an invite by email.
- It is required to have a real email address in order to sign up for the service or create a new user.
We encrypt all sensitive information transmitted to and stored on our servers.
Encryption during transmission
Since only SSL connections to Integrator's back end are allowed, inbound and outbound traffic is automatically encrypted.
Encryption of secure credentials
In Integrator, all passwords, access keys, and other secure credentials are encrypted by a strong encryption algorithm with a 512-bit private key.
Encryption of files
In Integrator, you can configure flows to store all files in the encrypted archive. This policy is not enforced.
Encryption of JWT tokens
In Integrator, JWT tokens are hashed using a strong encryption algorithm with a 512-bit private key.
Protection for the API endpoints
All API endpoints in Integrator, including the private ones, are protected by short-lived JWT tokens.
When you subscribe to our service we ask you to enter contact information, such as a valid email address. We keep it in our database, which is completely isolated from the Internet.
When you place an order with us, we redirect you to our payment gateway provider, where you will continue entering sensitive/credit information over a secure SSL connection.
We don't store credit card information on our servers.
Application Data and Credentials
Our data protection policy is very simple - typically we don’t have access to your data at all unless you opt-in to store it on our servers.
- Passwords and other secure credentials - we always encrypt them.
- Data files that you decide to store on our servers - you have an option to store data in password-protected archive files.
Data protection policies
- We never send passwords and other secure credentials to a web browser, so there is no way to view them anywhere in Integrator.
- Each client has its own, private and isolated space.
- We monitor and regularly install security patches for all elements of the infrastructure, including our core operating system.
Application security encompasses measures taken throughout the code's life-cycle, to prevent gaps in the security policies of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance or database of the application.
Static code analysis for security vulnerabilities
Every build of Integrator triggers an automatic run of the static code analyzer, which is configured to identify the maximum number of potential security exploits to the code.
Potentially, security vulnerabilities can prevent the completion of a build. If a build is not successful, manual intervention is required, followed by analyzing and fixing the vulnerabilities on a case-by-case basis.
Continuous Integration (CI) and Continuous Deployment (CD)
Every commit to the version control triggers the running of unit tests, and every build of Integrator triggers the running of a comprehensive set of unit and integration tests. About 30% of all tests are dedicated to security.
Any error in any of the tests causes a build to fail. All bugs in the code, as identified by the tests, must be fixed before the build can continue.
Scheduled, bug-free builds will be automatically deployed to designated environments. The deployment is atomic - all or nothing - and must be manually scheduled after the application passes the quality control in the staging environment.