Technical and organisational data protection measures

General information

Order data processing

applies within the framework of the General Data Protection Regulation (GDPR). We will conclude a contract with you for data processing in accordance with the General Data Protection Regulation (GDPR).

Duty to provide information

Persons affected by data processing have the right to request information about what data is stored about them and how this data is secured.

Regular monitoring of compliance with the regulations

As customers, you are responsible for regularly checking whether the applicable regulations are being complied with by your contractual partners.

Controlling

Admission control

Admission control measures ensure that unauthorised persons cannot physically access the data processing devices.

The devices (servers, switches, hard drives, …) are operated in German data centres by third parties.

We require the following measures for each of these data centres:

• Video surveillance (outdoor facilities, indoor rooms and rack corridors)
• Two-factor authentication for access (for example, personal password and transponder card) with logging of access.
• 24-hour security services with linked alarm system
• Separate physical security zones for
  • general areas
  • data centre infrastructure and
  • customer-accessible areas
• Separately locked racks with the ability to use customised locks and keys.

Physical access to the data processing equipment may only be carried out by cusy administrators who can delegate physical access to other persons (for example data centre employees).

Entry control

Entry control measures ensure that unauthorised third parties cannot use the data processing systems.

The machines managed by cusy can be accessed for administration purposes in various ways: SSH, web interfaces etc. For this purpose, we use a standardised scheme for identifying and authorising users. Management access to the systems must be via encrypted communication channels.

The identification and authorisation of customer applications that are not managed by the cusy infrastructure do not fall under cusy’s security responsibility. Our customers are obliged to ensure the security of their applications themselves.

Users must be identified with personal access data so that actions can be traced back to an individual person. The disclosure of login information to other persons is therefore prohibited. Depending on the applicability, the login data can be either a user name and a cryptographic measure (for example a private/public key scheme) or a password.

Users with a cusy account must manage their password securely: Passwords must not be compromised if a device is accessed without authorisation (logically or physically). Please note the following points, for example

• Home directory on a notebook
• Keychain or password manager software
• Backups
• USB sticks
• Smartphones.

Strongly encrypted storage of passwords is permitted and even recommended.

All hardware machines have emergency root logins that may only be used by cusy administrators if regular authentication does not work correctly. Such uses are monitored and must be documented.

All privileged actions must be securely logged. For machines based on our current platform, this is achieved through a local logging journal that cannot be manipulated by normal users. In addition, the system logs are transmitted to a central log server at the same location, where the logs are analysed and monitored.

SSH logins must be performed with SSH keys. Password authentication is not permitted and is prevented by the system configuration. Successful SSH logins to computers are logged, unsuccessful SSH login attempts are not. Too many unsuccessful SSH login attempts automatically lead to blocking via firewall rules.

Access control

Access control measures protect against access by unauthorised personnel.

Users are managed centrally and automatically authorised for all relevant systems, including the proper revocation of access rights.

cusy uses an authorisation-based concept to separate application maintenance tasks from privileged administrative tasks, such as customer software updates or database access from operating system updates or configuration changes.

Privileged administrative access is generally not granted to customers. In cases where another person is required to solve a problem, a joint session must be set up between the administrator and the other person (for example, with Screen).

Technically, there are three ways to perform privileged access:

• Using a user account that has been granted login and wheel authorisations for a specific project. This requires the user to log in with their SSH key and also enter their password for access to privileged operations.
• Using a user account that is a member of the global group of cusy administrators that grants access to all machines within the cusy infrastructure.
• Root logins for emergencies (see above in entry-control_).

Authorised and unauthorised access to privileged processes is logged and evaluated on a central log host within the same location.

cusy manages a number of authorisations that enable users to perform application maintenance and other semi-privileged tasks, such as access to service user accounts or database administration rights. Authorisations are granted to individual users by the customer at the customer’s request.

All authorisation assignments are traceable and explicitly documented: their effects are documented in the configuration code and their assignments are documented in the configuration database. A comprehensive list of users and their authorisations can be created on request.

Group accounts are generally not allowed to perform privileged administrative operations in order to ensure the traceability of actions.

Passwords for hardware machines that grant access to root accounts and IPMI controllers are stored as copies in a strongly encrypted password manager.

Transfer control

Transfer control measures ensure that data that is stored or transferred is protected against unauthorised reading, copying, modification or deletion. In addition, the locations for an intended transfer must be documented.

All private data transmitted beyond the boundaries of a machine must use an authenticated and encrypted communication channel (see below for exceptions). Data paths through which sensitive information can be transmitted include

• Application data (for example, database content) that is transferred from or to users via standardised encrypted protocols, such as SCP/SFTP or https.
• Persistent data that is stored on storage servers. Storage traffic is not encrypted for performance reasons. The storage servers are connected to the application servers via a private network.
• Backups are transferred either via an encrypted communication channel or via the private storage network to backup servers at the same location.
• In addition to the application data, a system can generate data at runtime that contains sensitive information, such as log files. These usually do not leave the machine on which they were generated.

Input control

Input control measures ensure that the input, modification and deletion of data is documented, whereby it must at least be possible to see who has worked on which data and when.

The security of data entry, modification and deletion is generally part of the customer application. Our customers must ensure that the entry, deletion and removal of data is handled in accordance with the applicable data protection laws.

However, as part of maintenance work, it may be necessary for cusy administrators to enter, change or delete data records at a low technical level in order to ensure the continued operation of the overall system. This only happens after we have informed the affected customers and documented this in our task management.

Log files maintained by cusy are automatically rotated by the infrastructure with reasonable retention periods.

Changes to the cusy user directory (such as SSH keys) can be made by our support team, provided they have been documented in advance.

Order control

Order control measures ensure that data is only processed in accordance with the client’s orders.

cusy ensures that all measures carried out by system administrators are covered by a contract or order with the customers affected by the measure. This can be based on comprehensive maintenance contracts or specific support requests.

Individual change requests should be tagged with a corresponding ticket in the cusy task management for tracking requests. Other means of documentation to control changes are possible, such as explanatory commit messages in a version control system.

The measures taken are communicated to the customer as required.

Availability control

Availability measures ensure that data is not accidentally destroyed or lost.

The availability of resources that depend on the data centre’s facilities is delegated to the data centre.

Hardware is selected by cusy with the help of professional equipment and providers. cusy enables standard procedures to increase the availability of individual components (for example RAID storage, redundant power supplies, replacement components).

Our customers’ data is regularly backed up according to cusy’s backup plan. The restoration of previous states can be carried out by administrators on request. In addition, there is an emergency plan in which failure scenarios and our preventive and recovery measures are described in detail.

Separation control

Data that is collected for different purposes must also be processed separately.

To separate the data of different customers, cusy enables virtualisation: both virtual machines (to separate the execution context) and to separate the storage ensure that customers can only access the data that belongs to them. Within a single machine, access to different files and processes is possible via standard UNIX authorisations.

Machines (both virtual and physical) are separated into two separate access rings:

• Ring 0 machines perform infrastructure tasks. They process data from multiple customers. Only administrative access is permitted on such machines. Examples include VM hosts and storage servers.
• Ring 1 machines process data for individual customers and are only accessible to the associated users. Examples are customer VMs.

All resources that logically belong together (for example VMs, storages etc.) are bundled into projects that share the same accounts and authorisations.