...

• The Security Architecture includes
  • Secure Communication
    • Certificate Management: Create and deploy certificates for secure network communication between components.
    • Life Cycle Management: Create, update and delete certificates and deploy changes to components.
  • Secure Configuration
    • Configurations include workflows, jobs and related objects.
    • Such objects are digitally signed and deployed by a responsible person.
  • Secure Operation
    • Access Management: Authentication and Authorization via LDAP Directory Service.
    • Credential Management: Use of a Credential Store for confidential data.
• Wording
  • The term Deployment applies to a situation that a configuration is transferred from JOC Cockpit to a MasterController.
  • The term Roll-out applies to a situation that a configuration is transferred between environments, e.g. from dev to test and to prod. Within the respective target environment a Deployment is performed to transfer configuration objects to Masters Controllers and Agents.

Security Architecture

...

• Certificates are created
  • either from a CA independently from JS7
    • This applies to users of JS7 who require high security levels and therefore operate a CA on their own.
  • or directly from the JS7 JOC Cockpit
    • This applies to users of JS7 who prefer a modest security level without the effort of maintaining a CA.
    • The JOC Cockpit implements
      • a Root CA and Intermediate CA to create certificates for JS7 components.
      • deployment capabilities to prepare the security configuration for JS7 components, i.e. to generate keystores and truststores that are added the respective certificates.
• Certificates can be maintained with JOC Cockpit should no individual CA be in place.
  • Private Keys and Certificates are stored with the JS7 database.
  • A user interface is available for any operations on certificates, such as creating, updating and deleting certificates.
• Certificates are prepared for deployment:
  • For each JS7 component such as Masters Controllers and Agents a keystore and truststore is created that holds the required certificates.
  • Keystores and truststores can be forwarded to Masters Controllers and Agents by any suitable means, e.g. file transfer, SSH, transportable disks etc.
  • Keystores and truststores can be imported to Masters Controllers and Agents by use of a shell script.

...

• To deploy configuration objects includes to transfer e.g. workflows and jobs to a Master Controller in a given environment.
• This step can be simplified for e.g. development environments when frequent changes occur to configuration objects and deployments are performed with a single mouse click.
• This step can be more complex if a sharing of responsibilities is included, e.g. to roll-out configuration objects from a development environment to a test or production environment. This situation is called a roll-out and is explained with the subsequent chapter.
• A secure deployment matches security requirements in a given environment. Therefore the JOC Cockpit can be operated in different Security Levels.
  • Security Levels "low" and "medium" allow simplified deployment and are suitable for environments with modest security requirements.
  • Security Level "high" takes more effort and is targeted towards organisations with more elaborate security requirements.
• Security Levels are put in place during installation of JOC Cockpit. Each instance of JOC Cockpit can be operated in one of the Security Levels only. There is no fallback from a Security Level "high" to a "medium" or "low" security level. Changing the Security Level requires to reinstall JOC Cockpit.

...

• Configuration objects are signed individually with the private key of the user. This applies within the scope of permissions used in JOC Cockpit to authorize individual accounts for deploying configuration objects.
• This mechanism is similar to implicit signing except for the fact that the private key stored with the current user's profile is used.
• Consider that similar to implicit signing all private and public keys of users are stored in a database and therefore are accessible to a DBA or system administrator.

Image RemovedImage Added

Security Level High: External Signing

• The security level requires any configuration objects to be exported and to be signed individually outside of JOC Cockpit.
• This guarantees that at no point in time JOC Cockpit has any knowledge about the private key used for signing.
• Security has a price: there is some effort to export a configuration, to sign it and to import the signed configuration.

Image Modified

Secure Roll-out

...

• Steps for a roll-out include
  • that roll-out might include shared responsibilities, e.g being performed by an individual that is different from the person who managed the configuration, e.g.
    • a developer would create workflows and jobs in a development environment and deploy them to Masters and Controllers and Agents in that environment.
    • an application manager would perform some quality assurance and pick up configurations from a development environment for roll-out to a test environment
    • a release manager would authorize roll-out from a test environment to a production environment.
  • to export a configuration the affected configuration objects are downloaded to a single archive file (.zip, .tar.gz)
  • to sign the downloaded configuration objects should Security Level High be in place including the tasks
    • to transfer the downloaded archive to a secure environment, e.g. a computer that is separated from the network.
    • to extract the archive to disk and to use a program that applies to company standards to sign the files included with the archive. This step includes that the user's private key is used to sign files. As a result for each file extracted from the archive a signature file is created.
    • to add the extracted files and the signature files to an archive file.
  • to transfer the archive with signed files to the target environment. This includes to use any means for file transfer such as copying between servers, use of SCP, SFTP etc.
  • to import the archive with signed files to JOC Cockpit in the target environment.
• The final step includes to deploy the imported signed configuration objects to the target environment.
  • This task can be performed by the same individual who signed and transferred the archive file or this can require a separate role in JOC Cockpit to be authorized to deploy in the target environment.

...

• Access Management includes access to JOC Cockpit and to the REST Web Service. This applies to users who access the JOC Cockpit GUI and to scripts and applications that directly access the REST Web Service.
• The JobScheduler Master Controller is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
• JobScheduler Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler MasterController. No default authentication is provided.

...