Architektur-Übersicht¶

TCM365 folgt einer modernen N-Tier-Schichtenarchitektur, die auf Multi-Vendor-Erweiterbarkeit, Tenant-Isolation und operationale Sicherheit ausgelegt ist. Diese Seite bietet einen High-Level-Ueberblick über das Plattform-Design. Detaillierte Vertiefungen sind für jede Schicht verfügbar.

Systemarchitektur¶

graph TB
    subgraph Client["Client Layer"]
        FE["Vue 3.5 + Vite 7 + Pinia 3 + Tailwind CSS<br/>55 Views | 106 Components | 28 Services | 10 Stores"]
    end

    subgraph Gateway["API Gateway Layer"]
        GW["NestJS 10 (Express)<br/>Helmet | CORS | Rate Limiting | Swagger/OpenAPI<br/>AllExceptionsFilter | AuditLog Interceptor"]
    end

    subgraph Auth["Authentication / Authorization"]
        AU["JWT Strategy | Local Strategy (bcrypt)<br/>JwtAuthGuard | RolesGuard | PermissionsGuard<br/>SUPER_ADMIN > TENANT_ADMIN > WORKFLOW_MANAGER > VIEWER"]
    end

    subgraph Business["Business Logic Layer - 36 Feature-Module"]
        CORE["Core: Snapshots | Diff | Rollback | Baselines"]
        MON["Monitors: Drift Detection | Anomaly Detection | Custom Probes"]
        SEC["Security: CA What-If | Email Security | Zero Trust | Copilot Readiness"]
        COMP["Compliance: NIS2 Incidents | Risk | Change Mgmt | BC/DR"]
        VEND["Vendor: VendorAdapterRegistry | M365Adapter | ZscalerAdapter | AtlassianAdapter"]
        OPS["Ops: Scheduler | Notifications | Reports | AI Analysis"]
        ADM["Admin: Users | Groups | Settings | Audit Log | Data Viewer"]
    end

    subgraph Data["Data Access Layer"]
        DA["TypeORM 0.3 (Repository)<br/>35 Entities (UUID PKs) | 32 Migrations<br/>BaseEntity Pattern | STI (VendorTenant)"]
    end

    subgraph External["External API Layer"]
        GRAPH["GraphService (1.704 Zeilen)"]
        UTCM["UtcmService (1.438 Zeilen)"]
        ZIA["ZscalerZiaClient"]
        ZPA["ZscalerZpaClient"]
        ATLJIRA["AtlassianJiraClient"]
        ATLCONF["AtlassianConfluenceClient"]
        ATLADM["AtlassianAdminClient"]
    end

    subgraph DB["Database Layer"]
        PG["PostgreSQL 15<br/>Row-Level Security | Schema-per-Tenant<br/>tcm_admin (BYPASSRLS) | tcm_app (respects RLS)"]
        RD["Redis 7 (Optional)<br/>Rate Limits | Locks | Cache"]
    end

    subgraph APIs["Vendor APIs"]
        MSGRAPH["Microsoft Graph API"]
        UTCMAPI["UTCM Snapshot Job API"]
        ZIAAPI["Zscaler ZIA REST API"]
        ZPAAPI["Zscaler ZPA REST API"]
        ATLAPI["Atlassian Cloud REST APIs"]
    end

    FE -->|"HTTP/REST (JWT Bearer)"| GW
    GW --> Auth
    Auth --> Business
    Business --> Data
    Business --> External
    Data --> PG
    Data --> RD
    GRAPH --> MSGRAPH
    UTCM --> UTCMAPI
    ZIA --> ZIAAPI
    ZPA --> ZPAAPI
    ATLJIRA --> ATLAPI
    ATLCONF --> ATLAPI
    ATLADM --> ATLAPI

Architekturprinzipien¶

1. Multi-Vendor-Erweiterbarkeit¶

TCM365 abstrahiert vendor-spezifische Logik hinter dem VendorAdapter-Interface. Jede Vendor-Interaktion -- von Snapshot Capture über Drift Detection bis Rollback -- geht durch dieses Interface, sodass neue Vendor ohne Änderung des Kernplattform-Codes hinzugefügt werden können.

Siehe: Multi-Vendor-Architektur

2. Drei-Schichten Tenant-Isolation¶

Datenisolation wird auf drei unabhängigen Schichten durchgesetzt:

Wenn eine einzelne Schicht kompromittiert wird, schützen die anderen beiden weiterhin die Tenant-Daten. Siehe: Sicherheitsarchitektur

3. Module-per-Feature¶

Jede Geschaeftsfaehigkeit ist in einem NestJS-Modul mit eigenem Controller, Service, DTOs und (wo zutreffend) Entities gekapselt. Module kommunizieren über NestJS Dependency Injection statt direkter Imports, was die Kopplung gering haelt.

Siehe: Backend-Architektur

4. Vendor-agnostischer Kern¶

Der Plattformkern (Snapshots, Diff, Baselines, Compliance, Reports) arbeitet auf vendor-agnostischen Datenstrukturen. Vendor-spezifische Details werden an der Adapter-Grenze aufgeloest, sodass die Geschaeftslogik sauber und über alle Vendor wiederverwendbar bleibt.

5. Defense in Depth¶

Sicherheit ist geschichtet: JWT-Authentifizierung, rollenbasierte Zugriffskontrolle, berechtigungsbasierte Autorisierung, Tenant-Isolation (drei Schichten), Per-Tenant-Verschlüsselung, Audit Logging, CORS, Helmet und Rate Limiting. Kein einzelner Mechanismus ist die einzige Verteidigungslinie.

Komponenten-Ueberblick¶

Backend (NestJS 10)¶

Das Backend ist eine Node.js/TypeScript-Anwendung auf dem NestJS-Framework mit 36 Feature-Modulen. Es stellt eine REST API auf Port 8000 mit JWT-basierter Authentifizierung bereit.

Siehe: Backend-Architektur

Frontend (Vue 3.5)¶

Das Frontend ist eine Single-Page Application auf Basis von Vue 3, die in der Entwicklung von Vite und in der Produktion von Nginx bereitgestellt wird. Es kommuniziert mit dem Backend ausschliesslich über die REST API.

Siehe: Frontend-Architektur

Datenbank (PostgreSQL 15)¶

PostgreSQL dient als primaerer Datenspeicher mit erweiterten Sicherheitsfeatures wie Row-Level Security und Schema-per-Tenant-Isolation.

Siehe: Datenbank-Architektur

Cache (Redis 7 - Optional)¶

Redis bietet verteiltes Caching, Rate Limiting und Lock-Koordination. Bei Nichtverfuegbarkeit degradiert das System automatisch auf In-Memory-Alternativen.

Datenfluss: Snapshot Capture¶

Der folgende Ablauf zeigt einen typischen Snapshot Capture Flow und wie die Komponenten interagieren:

sequenceDiagram
    participant User as Benutzer
    participant FE as Frontend
    participant Guard as JwtAuthGuard
    participant Ctrl as SnapshotController
    participant TAS as TenantAccessService
    participant Svc as SnapshotService
    participant Reg as VendorAdapterRegistry
    participant Adapter as VendorAdapter
    participant DB as PostgreSQL
    participant Audit as AuditLogInterceptor
    participant Notify as NotificationService

    User->>FE: Klick "Neuer Snapshot"
    FE->>Guard: POST /api/v1/snapshots
    Guard->>Guard: JWT validieren
    Guard->>Ctrl: Anfrage weitergeleitet
    Ctrl->>Ctrl: DTO validieren
    Ctrl->>TAS: Org-Level-Zugriff prüfen
    TAS-->>Ctrl: Zugriff erlaubt
    Ctrl->>Svc: Snapshot erstellen
    Svc->>Reg: VendorAdapter aufloesen
    Reg-->>Svc: M365Adapter, ZscalerAdapter oder AtlassianAdapter
    Svc->>Adapter: capture(tenant, options)
    Adapter-->>Svc: CaptureResult
    Svc->>DB: Snapshot-Daten speichern (Tenant Schema)
    Svc-->>Ctrl: Snapshot erstellt
    Ctrl-->>Audit: Audit-Eintrag erfassen
    Ctrl-->>Notify: Benachrichtigung senden (falls konfiguriert)
    Ctrl-->>FE: 201 Created

Deployment-Architektur¶

Entwicklung¶

Browser --> Vite Dev Server (:5173) --proxy--> NestJS (:8000) --> PostgreSQL (:5432)
                                                              --> Redis (:6379)

Produktion (Docker)¶

Browser --> Nginx (:80/:443)
              |
              +--> /api/* --> NestJS Container (:8000)
              |                  |
              |                  +--> PostgreSQL Container (:5432)
              |                  +--> Redis Container (:6379)
              |                  +--> Azure Key Vault
              |                  +--> Azure Blob Storage
              |
              +--> /* --> Vue Static Assets (served by Nginx)

Azure Produktion¶

Browser --> Azure App Service (Frontend)
              |
              +--> Azure App Service (Backend API)
                      |
                      +--> Azure Database for PostgreSQL
                      +--> Azure Cache for Redis
                      +--> Azure Key Vault
                      +--> Azure Blob Storage

Vertiefende Seiten¶