Database
The Transaction Security Broker (TSB) uses a relational database as its persistence layer. It stores the HSM User Secret, certificate metadata (for filtering and fast lookup), and the workflow state for SKA requests. Depending on the configured application profile, the database may also be used for multi-tenancy information or as an external keystore for persistent encrypted key objects.
This page describes:
- Which database systems are supported
- What the TSB database is used for
- Which tables exist and what type of information they store (including data classification)
Supported Databases
TSB supports the following relational database systems:
- MySQL
- MariaDB
- PostgreSQL
To ensure compatibility and stability of your production environment, use an LTS version that is still maintained by the respective database vendor.
Core Tables (Always Used)
TSB always requires the following information, regardless of mode:
- Encrypted HSM user secrets (permanent secret / Partition user secret)
- Certificate and public-key metadata
- Database schema and migration versioning
| Table / Area | Information Type | Used | Examples / Fields | Contains Secrets/PII? |
|---|---|---|---|---|
tskac_configuration | Encrypted HSM access credentials (permanent user secret, Partition configuration) | Yes | user.secret.encrypted, init_vector, salt | Secrets (AES/GCM encrypted, PBKDF2-HMAC-SHA512) |
tskac_request_signature | Optional request-signature authentication; typically not used because mTLS is preferred | Opt. | digest_algorithm, public_key, signature | No secrets (public keys only) |
tskac_keys | Certificate & public-key metadata (subject, issuer, algorithm, validity, etc.) | Yes | DN fields, raw_certificate, sha1/sha256 fingerprints, SAN, KU, EKU | No secrets (public keys only). PII possible (DN data) |
schema_version | Flyway migration & schema versioning | Yes | version, script_name, checksum, success | No |
Application Modes
TSB can operate in several modes. Each mode determines which database tables are used and how to classify the stored information.
| Mode | Description |
|---|---|
| Single-Tenant | 1:1 relation (1 TSB ↔ 1 HSM Partition). mTLS authentication. |
| Smart Key Attributes (Workflow Engine) | Enables quorum-based key operations via the SKA workflow engine. |
| Multi-Tenant | 1:N relation (1 TSB ↔ N HSM Partitions). JWT authentication. |
| External KeyStore | Persistent storage of encrypted key material using the HSM Partition key. |
The different modes are also explained in the REST API Configuration chapter.
Single-Tenant Tables
No additional tables are used in Single-Tenant mode, beyond the Core Tables set.
SKA Workflow Engine Tables
Used when:
- The Smart Key Attributes (SKA) workflow engine is enabled or the TSB_ENGINE license is active
- The Approver Management API is used for onboarding and managing approvers
In addition to the Core Tables, this mode stores SKA request metadata and states, and approval tasks and temporary workflow data.
| Table / Area | Information Type | Examples / Fields | Contains Secrets/PII? |
|---|---|---|---|
tskac_requests | SKA workflow requests; includes sign/decrypt/unwrap operations. Automatically cleaned via cron job. | payload, encrypted_payload, raw_request, metadata, crypto parameters | Secrets possible; PII possible |
tskac_task | Approval tasks for SKA workflow | authorization_token, public_key_hash, link to tskac_requests | Secrets (approval token) |
shedlock | Technical lock management for workflow execution | lock_until, locked_by | No |
tskac_attributes | Temporary key attributes during unwrap operations | sign, decrypt, extractable, wrap | No |
csrsignrequest_* | CSR KU/EKU attributes | extended_key_usage, key_usage | No |
tskac_standard_certificate_attributes | CSR DN subject attributes | common_name, email, organization, surname, … | PII |
tskac_partition_access_allowed_* | Allowed signing certificates (fingerprints) | certificate_fingerprint | No |
tskac_approver_management | Approver onboarding & encrypted key material | is_onboarded, one_time_password, pkcs12_data_encrypted, wrapped_decryption_key, certificate data | Secrets & PII |
Multi-Tenant Tables
Used when TSB runs in Multi-Tenant mode, using JWT-based tenant identity and authorization.
Stored information includes:
- Tenant-specific HSM access credentials
- JWT payload hashes and expiration data
- API access keys and role assignments
| Table / Area | Information Type | Examples / Fields | Contains Secrets/PII? |
|---|---|---|---|
tskac_partiton_access | HSM access credentials (encrypted) per tenant; JWT authentication | hostname, partition_name, user_secret, proxy_password, jwt_payload_hash | Secrets |
tskac_api_access_keys | API key authentication for role separation at TSB level | *_api_key, enabled | Secrets |
External KeyStore Tables
Used when TSB is configured as an external keystore, allowing cryptographic objects to be stored persistently in the database, encrypted (wrapped) using the HSM-internal Partition key.
| Table / Area | Information Type | Examples / Fields | Contains Secrets/PII? |
|---|---|---|---|
tskac_external_objects | Encrypted cryptographic objects (external keys, certificates) | external_object_data, certificate_data, algorithm, primus_key_type | Encrypted key material |