Teamscale Docs

Appearance

Security Measures for Teamscale Deployment ​

We at CQSE take security of your data and source code very seriously.

Most Importantly

In an on-premise deployment of Teamscale, none of your data leaves your own networks. Teamscale will never connect to remote servers unless you configure it to do so.

All required network connections to and from Teamscale can and should be encrypted.

The goal of this article is to give a short overview of all security-relevant aspects of Teamscale and its integration into your infrastructure. We link to additional documentation in several places for a more detailed explanation.

Scope of This Article ​

This article only deals with the security measures around the Teamscale server application. For information about our security policies and processes, please refer to the Technical and Organizational Security Measures .

Teamscale can be installed on your own servers (on-premise) or used as a service in the cloud. Most security measures apply to both scenarios. If you install Teamscale on your own servers, you are of course responsible to apply suitable security measures to the host operating system and operating environment of all the installed tools, which is outside the scope of this article. For users of our cloud offering, a dedicated section below provides more information about additional Security Measures for Teamscale Cloud.

Deployment and Permissions ​

There are two deployment modes, both of which use the least possible privileges. When installed as an operating system service, Teamscale does not require root or administrative privileges. When running Teamscale as a Docker container, the Teamscale process does not run as root inside the Docker container. Additionally, the container is self-contained, i.e. all required services are included in the container image.

Updates and Security Fixes ​

We provide new Teamscale versions on a regular basis:

  • Major releases with new features: every 6 weeks
  • Patch releases with bug and security fixes: at least every week for at least the latest two major releases

For severe security issues, such as Log4Shell, we often provide fixed versions within a single day.

Security Measures in the Teamscale Server Application ​

Authentication ​

We recommend you configure LDAP, Active Directory or Single sign-on as your authentication provider. In this case, human users log into Teamscale with their LDAP credentials. Credentials are forwarded to and verified by the LDAP server/SSO/Active Directory.

Technical users authenticate themselves in Teamscale with an access token. Tokens can be revoked and regenerated in Teamscale.

Authorization ​

Teamscale has a fine-grained permission model including permission management with roles and rights for both technical and human users.

Naturally, access to Teamscale projects can be granted selectively, enabling you to effectively segregate sensitive information and control which groups of people can see and modify what.

Logging ​

Teamscale’s log files are stored on-disk and must be secured with the host operating system’s permission system by you.

Some log files can also be accessed via Teamscale's web interface by Teamscale administrators. Access to these is secured by Teamscale’s permission management system.

The following security-related events are logged by Teamscale:

  • failed login attempts (passwords are not logged, of course)
  • invalid API requests (access tokens are not logged, of course)

By default, logs are rotated regularly.

SSL/TLS ​

Teamscale's web interface can be configured to be served via HTTPS. When running on-premise, you need to provide the required certificates and key files yourself.

However, for a productive setup, we recommend you terminate SSL yourself, e.g., by placing a reverse proxy like Nginx before Teamscale. This gives you additional flexibility and usually has better performance.

Data Encryption ​

In addition to existing disk encryption, Teamscale stores sensitive data in the internal database and any backups in an encrypted fashion. Examples include personal data of users and credentials for external systems Teamscale connects to. A custom encryption key can be provided.

Backups ​

Teamscale can be configured to automatically create backups of the configuration and all uploaded data in regular intervals. These include all information needed to restore a Teamscale instance, but not the code and ticket data obtained from third-party systems. They are stored on-disk as zip files.

Backups can be configured, so they are automatically rotated in configurable intervals.

Backups can be encrypted symmetrically. A custom encryption key can be provided.

Connections to Other Systems ​

Teamscale needs to connect to and integrate with other systems in your infrastructure. Which exact systems it requires access to depends on which features of Teamscale you intend to use.

Diagram of Connections from Teamscale to Other SystemsDiagram of Connections from Other Systems to Teamscale

For further information about these connections and their authentication mechanisms, as well as required permissions for Teamscale's technical users in these tools, see the respective part of our documentation:

Issue Trackers and Requirements Management:

Version Control Systems and Code Collaboration Platforms:

Authentication and Single sign-on (SSO):

Build and Test Environments:

IDE Plugins:

Additional Security Measures for Teamscale Cloud ​

The Teamscale instances that we run in the cloud, are subject to additional security measures. Please also refer to the Technical and Organizational Security Measures for information about our security policies and processes.

Virtual Machines for Data Separation ​

Teamscale is hosted on virtual servers and runs inside a container solution. Teamscale instances of other tenants are separated using individual virtual servers.

Encryption at Rest and in Transit ​

All data is encrypted both at rest and in transit using strong state-of-the-art encryption algorithms. Network connections are protected using TLS and all disks are encrypted as well.

Authentication ​

If you can provide an Internet facing SAML 2.0 identity provider, we can integrate with this single sign-on (SSO) solution. Alternatively, we can configure one of the other authentication providers supported by Teamscale (LDAP, Active Directory, Azure DevOps Authorization Server, OpenID Connect), if the required servers are reachable from our cloud servers. As a fallback, users and passwords can also be managed using Teamscale's built-in user management.

Backups ​

Snapshot backups of the server are created every night and stored in encrypted fashion for up to 14 days. In addition, encrypted backups of the Teamscale instance configuration and user data are created daily and kept for 7 consecutive days, 4 consecutive weeks and 3 consecutive months.

Access Management ​

Access to the cloud infrastructure is limited to a small group of dedicated administrators, who are regularly trained and instructed according to CQSE's security policies. Direct access to instances and servers is kept to the required minimum, respecting the need-to-know principle.