Datenbank-Architektur¶

TCM365 verwendet PostgreSQL 15 als primäre Datenbank mit TypeORM 0.3 als ORM-Schicht. Das Datenbankdesign umfasst 35 Entities, Single Table Inheritance für Multi-Vendor-Support, Row-Level Security für Tenant-Isolation und Per-Tenant-Schemas für Data-Plane-Trennung.

Technology Stack¶

Entity-Ueberblick¶

TCM365 definiert 35 TypeORM Entities in sechs funktionalen Kategorien. Alle Entities erweitern eine gemeinsame BaseEntity, die UUID-Primärschlüssel und Zeitstempel bereitstellt.

BaseEntity-Pattern¶

Jede Entity erbt von der gemeinsamen BaseEntity:

// backend-js/src/common/entities/base.entity.ts
import { PrimaryGeneratedColumn, CreateDateColumn, UpdateDateColumn } from 'typeorm';

export abstract class BaseEntity {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @CreateDateColumn({ name: 'created_at' })
  createdAt: Date;

  @UpdateDateColumn({ name: 'updated_at' })
  updatedAt: Date;
}

Entity-Katalog¶

Kern-Entities¶

Vendor Tenant-Hierarchie (Single Table Inheritance)¶

Siehe den Abschnitt Single Table Inheritance (STI) weiter unten für Details.

Configuration Management Entities¶

Operations Entities¶

Anomaly Detection Entities¶

KRITIS/NIS2 Compliance Entities¶

Infrastruktur-Entities¶

Single Table Inheritance (STI)¶

Die vendor_tenants-Tabelle verwendet TypeORMs Single Table Inheritance-Pattern mit einer vendor-Diskriminatorspalte, um mehrere Vendor-Typen in einer Tabelle zu unterstützen.

STI-Struktur¶

vendor_tenants Tabelle
├── id (uuid, PK)
├── vendor (varchar) ─── Diskriminator: 'microsoft' | 'zscaler' | 'atlassian'
├── name (varchar)
├── org_id (uuid, FK → internal_tenants)
├── created_at (timestamp)
├── updated_at (timestamp)
│
├── [Microsoft-spezifische Spalten]
│   ├── tenant_id (varchar, nullable)
│   ├── domain (varchar, nullable)
│   ├── connection_type (varchar, nullable)
│   ├── enabled_workloads (jsonb, nullable)
│   ├── write_credentials (jsonb, nullable)
│   └── granted_permissions (jsonb, nullable)
│
├── [Zscaler-spezifische Spalten]
│   ├── zia_cloud (varchar, nullable)
│   ├── zia_api_key (varchar, nullable)
│   ├── zia_admin_username (varchar, nullable)
│   ├── zia_admin_password (varchar, nullable)
│   ├── zpa_customer_id (varchar, nullable)
│   ├── zpa_client_id (varchar, nullable)
│   ├── zpa_client_secret (varchar, nullable)
│   └── zpa_cloud (varchar, nullable)
│
└── [Atlassian-spezifische Spalten] (v2.5.0)
    ├── oauth_access_token (text, nullable)
    ├── oauth_refresh_token (text, nullable)
    ├── oauth_token_expires_at (timestamp, nullable)
    ├── site_id (varchar, nullable)
    ├── site_url (varchar, nullable)
    ├── site_name (varchar, nullable)
    └── guard_tier (varchar, nullable)

TypeORM-Implementierung¶

// Basis-Entity
@Entity('vendor_tenants')
@TableInheritance({ column: { type: 'varchar', name: 'vendor' } })
export class VendorTenant extends BaseEntity {
  @Column()
  name: string;

  @ManyToOne(() => InternalTenant)
  @JoinColumn({ name: 'org_id' })
  organization: InternalTenant;
}

// Microsoft Child-Entity
@ChildEntity('microsoft')
export class M365VendorTenant extends VendorTenant {
  @Column({ name: 'tenant_id', nullable: true })
  tenantId: string;

  @Column({ nullable: true })
  domain: string;

  @Column({ name: 'enabled_workloads', type: 'jsonb', nullable: true })
  enabledWorkloads: string[];
}

// Zscaler Child-Entity
@ChildEntity('zscaler')
export class ZscalerVendorTenant extends VendorTenant {
  @Column({ name: 'zia_cloud', nullable: true })
  ziaCloud: string;

  @Column({ name: 'zia_api_key', nullable: true })
  ziaApiKey: string;
  // ... weitere ZIA/ZPA-Spalten
}

// Atlassian Child-Entity (v2.5.0)
@ChildEntity('atlassian')
export class AtlassianVendorTenant extends VendorTenant {
  @Column({ name: 'site_id', nullable: true })
  siteId: string;

  @Column({ name: 'site_url', nullable: true })
  siteUrl: string;

  @Column({ name: 'guard_tier', nullable: true })
  guardTier: string;
  // ... weitere OAuth- und Site-Spalten
}

Row-Level Security (RLS)¶

PostgreSQL Row-Level Security stellt sicher, dass Anwendungsabfragen nur Daten zurueckgeben, die zur Organisation des authentifizierten Benutzers gehören -- selbst wenn Anwendungsebenen-Checks umgangen werden.

Zwei-Rollen-Architektur¶

RLS-Policy-Pattern¶

-- RLS auf tenant-scoped Tabellen aktivieren
ALTER TABLE snapshots ENABLE ROW LEVEL SECURITY;

-- Policy: Benutzer sehen nur Daten ihrer Organisation
CREATE POLICY tenant_isolation ON snapshots
  USING (org_id = current_setting('app.current_org_id')::uuid);

-- Die Anwendung setzt die Session-Variable vor jeder Abfrage
SET app.current_org_id = '<user-org-uuid>';

RLS-geschuetzte Tabellen¶

RLS-Policies werden auf 18 tenant-scoped Tabellen angewendet:

Schema-per-Tenant-Isolation¶

Über RLS hinaus bietet TCM365 physische Datentrennung für Data-Plane-Tabellen durch Per-Tenant PostgreSQL-Schemas.

Schema-Namenskonvention¶

public                  -- Gemeinsame Control-Plane-Tabellen (users, groups, system_settings)
tenant_{uuid}           -- Per-Tenant Data-Plane-Tabellen (snapshots, drifts, monitors)

Beispiel: Eine Organisation mit ID a1b2c3d4-... erhält Schema tenant_a1b2c3d4.

Data-Plane-Tabellen (23 Tabellen pro Tenant-Schema)¶

Diese Tabellen werden in jedem Tenant-Schema dupliziert:

• snapshots, configuration_drifts, configuration_monitors
• workflows, workflow_executions, rollback_histories
• anomaly_baselines, anomaly_events, anomaly_metrics
• custom_probes, custom_probe_executions
• blueprints, blueprint_analyses
• incidents, risk_assessments, change_requests, change_approvals
• compliance_checks, bcdr_tests, audit_evidences
• notification_configs, reports, utcm_quota_usages

TenantSchemaManager¶

Der TenantSchemaManager-Service verwaltet den Schema-Lebenszyklus:

@Injectable()
export class TenantSchemaManager {
  // Schema erstellen, wenn eine neue Organisation hinzugefügt wird
  async createTenantSchema(orgId: string): Promise<void>;

  // Migrationen auf einem bestimmten Tenant-Schema ausführen
  async migrateTenantSchema(orgId: string): Promise<void>;

  // Schema löschen, wenn eine Organisation entfernt wird
  async dropTenantSchema(orgId: string): Promise<void>;
}

Entity-Beziehungen¶

Wichtige Beziehungen¶

erDiagram
    InternalTenant ||--o{ VendorTenant : "hat viele"
    InternalTenant ||--o{ User : "hat viele"
    InternalTenant ||--o{ Group : "hat viele"
    VendorTenant ||--o{ Snapshot : "hat viele"
    VendorTenant ||--o{ ConfigurationDrift : "hat viele"
    VendorTenant ||--o{ ConfigurationMonitor : "hat viele"
    VendorTenant ||--o{ Workflow : "hat viele"
    Snapshot ||--o{ ConfigurationDrift : "Quelle/Ziel"
    ChangeRequest ||--o{ ChangeApproval : "hat viele"
    User }o--|| InternalTenant : "gehört zu"
    User }o--o{ Group : "Mitglied von"

Migrationen¶

TCM365 hat 32 TypeORM-Migrationen, die das vollständige Datenbankschema aufbauen.

Migrations-Befehle¶

cd backend-js

# Alle ausstehenden Migrationen ausführen
npm run migration:run

# Neue Migration aus Entity-Änderungen generieren
npm run migration:generate src/database/migrations/BeschreibenderName

# Letzte angewendete Migration zurücksetzen
npm run migration:revert

Migrations-Best-Practices¶

1. Immer generieren, nie von Hand schreiben. Verwenden Sie migration:generate, um Entity-Änderungen automatisch zu erkennen.
2. Beide Richtungen testen. Stellen Sie sicher, dass up() und down() beide funktional sind.
3. Tenant-Schemas aktualisieren. Data-Plane-Tabellenaenderungen müssen auf alle tenant_*-Schemas angewendet werden.
4. snake_case für Spalten. TypeORM transformiert camelCase-Properties in snake_case-Spalten.
5. Standard nullable für neue Spalten. Vermeiden Sie das Brechen bestehender Daten mit NOT NULL-Constraints auf neuen Spalten.

DataSource-Konfiguration¶

// backend-js/src/database/data-source.ts
export const AppDataSource = new DataSource({
  type: 'postgres',
  host: process.env.DATABASE_HOST,
  port: parseInt(process.env.DATABASE_PORT, 10),
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
  database: process.env.DATABASE_NAME,
  entities: [__dirname + '/../entities/*.entity{.ts,.js}'],
  migrations: [__dirname + '/migrations/*{.ts,.js}'],
  synchronize: false,  // Niemals true in der Produktion
  logging: process.env.DATABASE_LOGGING === 'true',
});

JSONB-Spalten¶

TCM365 verwendet PostgreSQL JSONB-Spalten für flexible Metadatenspeicherung, wo Schema-Flexibilitaet benötigt wird:

Performance-Aspekte¶

Indexierungsstrategie¶

TCM365 erstellt Indizes auf häufig abgefragten Spalten:

• Fremdschluessel: Alle org_id, vendor_tenant_id, m365_tenant_id-Spalten
• Status-Spalten: status auf Snapshots, Workflows, Incidents
• Zeitstempel: created_at für Zeitbereichsabfragen
• Zusammengesetzt: (org_id, vendor_tenant_id, created_at) für tenant-scoped Zeitabfragen

Abfrage-Patterns¶

• TypeORM Repository-Methoden (find, findOne, save) statt roher Abfragen verwenden
• QueryBuilder für komplexe Joins und Aggregationen nutzen
• take und skip für Paginierung verwenden (niemals unbegrenzte Ergebnismengen laden)
• order nach Zeitstempel absteigend für Neueste-Zuerst-Abfragen anwenden

Datenbank-Diagnostik¶

TCM365 bietet integrierte Datenbankdiagnostik: