Introduction

• 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.
    • These objects are digitally signed and deployed by a responsible person.
  • Secure Operation:
    • Access Management: Authentication and Authorization via an LDAP Directory Service.
    • Credential Management: Use of a Credential Store for confidential data.
• Wording
  • The term Deployment applies to a situation when a configuration is transferred from the JOC Cockpit to a Controller.
  • The term Roll-out applies to a situation when a configuration is transferred between environments, e.g. from non-production to production environments. Within the respective target environment a Deployment is performed to transfer configuration objects to Controllers and Agents.

Security Architecture

• Download: JS7_JobScheduler_Security_Architecture.pptx
• Download: JS7_JobScheduler_Security_Architecture.pdf
• Use the links above to download the slides, if the display of the document below does not work in your browser:

Secure Communication

Network Connections

• Network connections between components use the HTTPS protocol.
• Such connections are secured by x509 certificates, optionally using mutual client and server authentication.
• Connections are established in one direction only.

Certificate Management

Certificate Preparation

Certificate Deployment

Certificate Management Life Cycle

Certificate Preparation

• 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 which the relevant certificates are added to.
• Certificates can be maintained with JOC Cockpit if an individual CA is not in place.
  • Private Keys and Certificates are stored with the JS7 database.
  • A user interface is available for operations on certificates, such as creating, updating and deleting certificates.
• Certificates are prepared for deployment:
  • A keystore and truststore to hold the required certificates is created for all JS7 components such as Controllers or Agents.
  • Keystores and truststores can be forwarded to Controllers and Agents by any suitable means, e.g. file transfer, SSH, transportable disks etc.
  • Keystores and truststores can be imported to Controllers and Agents using 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 required.
  • The Java architecture and certificate types allow implementation of a CRL.

Secure Configuration

• Configurations include all deployable objects that are used for job execution with Agents, such as workflows, jobs etc.
• The deployment of jobs to Agents can include calls to OS commands, scripts and binaries. Such deployments should be considered as a code injection to a remote machine requiring 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 of deployments.
• JOC Cockpit offers different security levels for deployment tasks.

Secure Deployment

• To deploy configuration objects to a Controller in a given environment includes transferring objects such as workflows and jobs.
• This step can be simplified for, for example, 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 sharing of responsibilities is included, for example, when rolling-out configuration objects from a development environment to a test or production environment. This situation is called a roll-out and is explained in the subsequent chapter.
• A secure deployment matches the security requirements in a given environment. Therefore the JOC Cockpit can be operated with different Security Levels.
  • "Low" and "medium" Security Levels allow simplified deployment and are suitable for environments with modest security requirements.
  • The "high" Security Level takes more effort and is targeted towards organizations with more elaborate security requirements.
• Security Levels are put in place during the installation of the JOC Cockpit. Each instance of the JOC Cockpit can be only operated at a single Security Level. There is no fallback from a Security Level "high" to a "medium" or "low" security level. Changing the Security Level requires reinstalling JOC Cockpit.

Security Level Low: Implicit Signing

• Configuration objects are automatically signed by JOC Cockpit. This task is performed implicitly when deploying objects.
• This mechanism is easy to use as signing operations are performed without user interaction.
• At the same time there is no certainty about who has deployed objects, as any user who is authorized to deploy objects can use the relevant deployment function with a single mouse click.

Security Level Medium: User based 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.
• Note that similarly 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.

Security Level High: External Signing

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

Secure Roll-out

• A roll-out includes transferring configuration objects between environments, e.g. from development to test and to production.

• Steps for a roll-out include considering:
  
  • that the roll-out might include shared responsibilities, e.g being performed by a different individual to the one who managed the configuration. For example:
    
    • a developer would create workflows and jobs in a development environment and deploy them to Controllers and Agents in that environment.
    • an application manager would perform 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.
  • that when exporting a configuration, the affected configuration objects are downloaded to a single archive file (.zip, .tar.gz)
  • that should Security Level High be in place, then signing the downloaded configuration objects will include the tasks:
    
    • transferring the downloaded archive to a secure environment, e.g. a computer that is separated from the network.
    • extracting the archive to disk and to use a program that applies to company standards to signing the files included with the archive. This step includes the user's private key being used to sign files. As a result a signature file is created for each file extracted from the archive.
    • adding the extracted files and the signature files to an archive file.
  • that the archive with signed files has to be transferred to the target environment. This includes using any means for file transfer such as copying between servers, use of SCP, SFTP etc.
  • that the archive with signed files has to be imported to JOC Cockpit in the target environment.
• The final step includes deploying the imported and 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 the JOC Cockpit to be authorized to deploy in the target environment.

Secure Operation

Access Management

• Access Management includes access to JOC Cockpit and to the REST Web Service. This applies to both users who access the JOC Cockpit GUI and scripts, and applications that directly access the REST Web Service.
• The JobScheduler 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 Controller. No default authentication is provided.

Credential Management

• Users frequently ask if JobScheduler can encrypt credentials. The answer is "no" as it makes no sense for an Open Source software to handle a symmetric key.
• There is only one way to handle passwords: not to use them.

References

• Find details in the JS7 - Secure Operation article.