Page History
...
- JS7 products are easy to install out-of-the-box. However, a number of configuration items have to should be considered when operating JS7 for a secure environment.
- Secure operation is applied to the following areas:
- Connection Management
- Network Connections
- Database Connections
- Access Management
- Authentication
- Authorization
- Credentials Management
- Database Credentials
- Job Credentials
- Connection Management
- Secure operation includes users configuring JS7 products in a compliance-conformant way.
...
- This allows to operate JS7 products in different network zones. JOC Cockpit can be located in a deployment zone from which users deploy workflows. Controllers and Agents can be operated in separate more secure network zones.
- The underlying principle is to allow connections from a less secure deployment zone to more secure zones and to deny connections to go the opposite way.
- If jobs are operated on JS7 Agents that require access to the JS7 REST Web Service API then it is recommended to set up additional JOC Cockpit API Server instances. Such instances do not include the user interface but serve the REST Web Service API only. Any number of API Server instances can be set up & operated in parallel and they can be operated located close to JS7 Agents.
Network Connections
...
- Configure network connections to use HTTPS:
- Use of HTTPS includes providing valid certificates for the hosts that JS7 products are operated for. Use of self-signed certificates is acceptable if they can be verified to a trusted sourcePrivate CA-signed Certificates and Public CA-signed Certificates are both acceptable. For details see JS7 - How to create X.509 SSL TLS Certificates.
- As HTTPS is limited to secure connections, additional authentication is required. In this case, a JS7 Controller instance is configured to authenticate with an Agent in order to guarantee that the Controller instance is in fact, what it claims to be and is entitled to access the Agent.
- The JS7 - Secure Connections article explains the use of the built-in Certificate Authority and the use with external Certificate Authorities.
- For detailed instructions for configuration see:
- JS7 - JOC Cockpit HTTPS Connections, which explains HTTPS configuration for the JOC Cockpit and connection to the JS7 Controller.
- JS7 - Controller HTTPS Connections
- JS7 - Agent HTTPS Connections
- Restrict use of network interfaces:
- Consider restricting JS7 products to only listen to specific network interfaces.
- The JS7 Controller can be configured by use of the
--http_-port
and--https_-port
command line options to specify network interfaces, see the JS7 - Controller - Command Line Operation article for details. - The JS7 Agent can be configured by use of the
--http-port
and--https-port
options to specify network interfaces, see JS7 - Agent Command Line Operation. - The JOC Cockpit can be similarly configured to only use specific network interfaces, see:
...
- Using the default
root
user account that ships with the JOC Cockpit is not recommended. The default user account is intended to enable initial login only. - A fine-grained set of permissions is available that can be applied to any operation in the JOC Cockpit and in the JS7 REST Web Service API. Such permissions can freely be grouped to roles, see JS7 - Authorization.
- JS7 - Identity Services offer a number of authentication methods that can be combined for single-factor and multi-factor authentication (MFA).
- The JS7 - LDAP Identity Service can be used to establish role assignment for users based on membership in LDAP Directory Service security groups.
- The JS7 - Certificate Identity Service and JS7 - FIDO2 FIDO Identity Service can be used for MFA.
Identity Services
...
- Users can switch to one of the supported Identity Services such as
- JS7 - LDAP Identity Service,
- LDAP Directory Services can be accessed for authentication and authorization:
- users can connect by specifying their domain account.
- membership in security groups can be optionally mapped to roles managed with JOC Cockpit.
- The use of LDAP allows operation of a JOC Cockpit configuration that contains neither user account data, passwords nor user role assignments.
- This applies to any LDAP compliant product such as Microsoft Active Directory®, OpenLDAP etc.
- LDAP Directory Services can be accessed for authentication and authorization:
- JS7 - OIDC Identity Service
- OIDC offers token based authentication that includes a direct connection between the user and the Identity Provider.
- JOC Cockpit has no access to passwords in this authentication scheme.
- JS7 - Certificate Identity Service
- Client Authentication certificates can act as a replacement for passwords.
- The Identity Service can be used for single-factor authentication and for MFA.
- JS7 - FIDO2 FIDO Identity Service
- Public/private key authentication by use of a secure device eliminates the use of passwords.
- The Identity Service can be used for single-factor authentication and for MFA.
- JS7 - LDAP Identity Service,
- A number of Identity Services can be combined to be optional or required. This allows to authenticate with one Identity Service from a list of available services and it allows to force authentication with all configured Identity Services.
- Users should consider to disable the initial JOC Identity Service when more secure Identity Services are in place.
...
- Do not use passwords.
- Users frequently ask if JS7 can encrypt credentials. The answer is "no" as it makes no sense to handle a symmetric key that is in reach of the product that makes use of it. Encrypted passwords correspond to the "key under the mat". They do not provide additional security. However, they perfectly contribute to obfuscation.
- There is one way only how to securely handle passwords: not to use them.
- Use Integrated Security
- This authentication scheme is based on the fact that the account which a product is operated for has already been authenticated and therefore can access a database without specifying user/password credentials.
- This feature is available for a number of DBMS such as:
- Microsoft SQL Server®, see the JS7 - How to connect to an SQL Server database without using passwords article.
- Oracle® including support for Oracle® Wallet, see the JS7 - How to make JOC Cockpit connect to an Oracle database using Wallet® article.
- Encrypt passwords
- For details see JS7 - How to encrypt and decrypt Database Credentials.
Job Credentials
Default Configuration
- The Windows Service for the JS7 Controller and Agent runs in the system account.
- The installer allows specification of a different account and the addition of credentials for that account. The installer does not store passwords entered during installation.
- By default jobs are executed in the context of the account that the JS7 Agent is operated with.
Secure Configuration
- Use of Accounts
- It is considered a bad idea to run a JS7 Controller or Agent using a Unix root account or Windows Administrator account.
- Certainly this makes life easy when it comes to switching to other user accounts or for accessing directories and files.
- However, users should not grant more permissions to a process than required.
- Use specific user accounts to run JS7 Controllers and Agents:
- Do not use the system account (Windows) or root account (Unix).
- Create specific service accounts that are limited to the privileges that are required to execute jobs.
- There is no guarantee that such credentials will be logged by some Windows mechanism.
- Instead, use the Windows Service Panel to manually specify credentials for the service account.
- are a number of options when it comes to running jobs for different user accounts:
- In Unix environments:
- Job scripts can switch to a different user context by use of
sudo
orsu
commands.sudo
is the preferred option as this is the standard Unix tool which allows secure configuration of the accounts that are allowed to execute certain commands (sudoers
file). In additionsudo
provides reporting capabilities about the (ab)use of commands. - Find details from the JS7 - Running Jobs as a different User on Unix article.
- Job scripts can switch to a different user context by use of
- In Windows environments:
- You can use the Windows Credential Manager to safely store the credentials of the user account that a job should be executed for. The Agent will then read the credentials and will create a new process to run a job in the target user account's context. This is the preferred solution as it does not store credentials in the Agent or workflow configuration.
- Find detailed information from the JS7 - Running Jobs as a different User on Windows article.
- For all environments:
- You can run a number of Agents in parallel using different user accounts.
- In Unix environments:
- It is considered a bad idea to run a JS7 Controller or Agent using a Unix root account or Windows Administrator account.
- Use of Credentials
- Do not specify credentials for Windows Service accounts during installation:
- The graphical installer stores such credentials in binary format and forwards them to the Windows Service interface. There is no guarantee that such credentials will be logged by some Windows mechanism.
- Instead, use the Windows Service Panel to manually specify credentials for the service account.
- A credential store can be used for jobs that require credentials, for example to access a database: see the JS7 - Credential Store article for more information.
- Credentials are not provided from parameters (that could be logged in clear text), instead an interface is provided that allows on demand access to the credential store.
- This feature is available for Shell jobs and for JVM jobs, for example JS7 - JITL Database Jobs, JS7 - JITL SSH Jobs etc.
- Use the the feature of JS7 - Encryption and Decryption, for encryption of order variables and job arguments see JS7 - Encryption - Integration with Workflows - Jobs - Orders
- Do not specify credentials for Windows Service accounts during installation:
File Transfer Credentials
...
- Use the YADE Credential Store to manage credentials centrally in a store which is referenced by YADE configuration items. See the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles for more information.
- Should you use FTP connections then consider switching to use of SFTP.
- SFTP connections can be used with private/public key files - there is no need to use passwords for such connections.
...
Resources
Overview
Content Tools