Scope

• The Security Architecture includes
  • Secure Communication
    • Certificate Management: Create and deploy certificates for secure 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 by a responsible person
• Wording
  • The term Deployment applies to a situation that a configuration is transferred from JOC Cockpit to a Master.
  • 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 and Agents.

Secure Communication

Network Connections

• Network connections between components use the HTTPS protocol.
• Such connections are secured by
• Connections are established in one direction only.

Certificate Management

Certificate Creation

Certificate Deployment

Certificate Life Cycle

Certificate Creation

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

Certificate Revocation

• Certificates are revoked by deploying updated certificates.
• Support for Certificate Revocation Lists (CRL) can be added at a later point in time if such demand occurs.
  • The Java architecture and certificate types allow implementation of a CRL.

Secure Configuration

• 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-reputability of deployments.
• JOC Cockpit offers different security levels for deployment tasks.

Security Levels

Security Level Low: Implicit Signing

• Any configuration objects are automatically signed by JOC Cockpit. This tasks is performed automatically when deploying objects.
• This mechanism is easy to use as signing operations are performed implicitly without user interaction.
• At the same time there is no certainty about who deployed objects as any user who is authorized to deploy objects can use the respective deploy functionality from a single mouse click.

Security Level Medium: Individual Signing

• 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 by a DBA or system administrator.

Security Level High: External Signing

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