Page History

...

• Certificates are created
  • either from a CA indepndently 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 and Agents a keystore and truststore is created that holds the required certificates.
  • Keystores and truststores can be forwarded to Masters and Agents by any suitable means, e.g. file transfer, SSH, transportable disks etc.
  • Keystores and truststores can be imported to Masters and Agents by use of a shell script.

...

• Configurations include any deployable objects that are used for job execution with Agents, such as workflows, jobs etc.
• Basically the deployment of jobs that include e.g. calls to OS commands, scripts and binaries, to any Agents should be considered a code injection to a remote machine that requires authentication and authorization.
• Therefore a configuration is required to be signed by a responsible person:
  • this guarantees that workflows, jobs etc. are authorized for deployment by individuals who are in charge of this task.
  • this guarantees non-repudiability reputability of deployments.
• JOC Cockpit offers different security levels for deployment tasks.

...

• Thie 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.

Secure Roll-out

• A roll-out includes to transfer configuration objects between environments, e.g. from development to test and to production.
• 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 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: affected configuration objects are downloaded to a single archive file (.zip, .tar.gz)
  • to sign the downloaded configuration objects:should the 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.