CloudTAK-Server-Deployment-Leitfaden: TAK-Infrastruktur für taktische Operationen aufbauen

CloudTAK ist der webnative Nachfolger des veralteten Java-basierten TAK-Servers — eine Node.js-Anwendung, die das ATAK- und WinTAK-Ökosystem ohne clientseitige Java-Installation oder komplexes Keystore-Management in jeden Browser bringt. Während der Legacy-TAK-Server eine schwergewichtige Java-EE-Anwendung für Garnison-Rechenzentren war, ist CloudTAK container-first, REST-nativ und lässt sich auf einer einzelnen Cloud-VM in unter einer Stunde deployen. Dieser Leitfaden beschreibt den vollständigen Weg vom nackten Server zu einer gehärteten, produktionsreifen TAK-Infrastruktur — einschließlich der Integration des TAKpilot-KI-Kopiloten von Corvus Intelligence.

Was ist CloudTAK und wie unterscheidet es sich vom Legacy-TAK-Server

Der Legacy-TAK-Server (im Community-Ökosystem auch als FreeTAKServer verbreitet) wurde als Java-EE-Anwendung gebaut, die CoT-Föderierung über TCP/TLS und ein nachträglich hinzugefügtes, eingeschränktes REST API bot. Der Betrieb erfordert Java 11 oder höher, einen Java-Keystore (.jks) zur Zertifikatsverwaltung sowie entweder einen Tomcat-Container oder eine eigenständige JAR-Bereitstellung. Allein die Zertifikatsbereitstellung — CA, Serverzertifikat und clientspezifische Zertifikate generieren und jeweils in den richtigen Keystore importieren — kostet einen Erstanwender erfahrungsgemäß mehrere Stunden und ist eine häufige Ursache von Deployment-Fehlern.

CloudTAK beschreitet einen anderen Architekturweg. Der Server ist in TypeScript/Node.js geschrieben, speichert Daten in PostgreSQL mit der räumlichen PostGIS-Erweiterung und stellt alle Funktionen über ein REST API mit OpenAPI-Dokumentation bereit. Die Web-Oberfläche ist ein vollwertiger TAK-Client — Bediener ohne ATAK-fähige Android-Geräte können das taktische Lagebild in jedem Browser einsehen und damit interagieren. Die TLS-Zertifikatsverwaltung verwendet Standard-PEM-Dateien statt Java-Keystores und ist damit kompatibel mit Let's Encrypt und Standard-PKI-Werkzeugen.

Webnатiver TAK-Client — Bediener auf Laptops, vorgeschobenen Gefechtsständen und SOC-Workstations greifen ohne ATAK- oder WinTAK-Installation auf das Lagebild zu.
REST API als Grundlage — CoT-Empfang, Datenpaketverwaltung, Benutzerverwaltung und Föderationskonfiguration sind API-gesteuert und ermöglichen Automatisierung und Integration mit externen Systemen.
Container-first-Deployment — eine einzelne Docker-Compose-Datei startet den vollständigen Stack; keine Java-Runtime, kein Tomcat, keine Keystore-Konfiguration.
Volle ATAK/WinTAK-Kompatibilität — bestehende ATAK- und WinTAK-Clients verbinden sich mit CloudTAK identisch wie mit dem Legacy-TAK-Server auf Port 8089 TCP/TLS. Keine clientseitigen Änderungen erforderlich.

Voraussetzungen: Infrastruktur, Domains und Ports

Stellen Sie vor dem Deployment von CloudTAK sicher, dass folgende Voraussetzungen erfüllt sind.

Serveranforderungen

Ein minimales Deployment, das bis zu 100 gleichzeitige ATAK-Clients unterstützt, benötigt:

2 vCPUs, 4 GB RAM, 20 GB SSD (Betriebssystem + Container + Datenbank)
Ubuntu 22.04 LTS oder RHEL 9 (getestete Distributionen)
Docker Engine 24+ und Docker Compose v2
Statische öffentliche IP-Adresse oder DNS-A-Record, der auf den Server verweist

Für 500+ gleichzeitige Clients oder hochfrequente CoT-Umgebungen (UAV-Feeds, Drohnenschwärme mit 1-Hz-Melderate) skalieren Sie auf 4–8 vCPUs und 8–16 GB RAM. PostgreSQL-I/O wird bei größerer Last zum Engpass — verwenden Sie NVMe-SSD oder einen verwalteten Datenbankdienst statt gemeinsamem Storage.

Portanforderungen

Port	Protokoll	Zweck
`8089`	TCP/TLS	CoT-Streaming — ATAK- und WinTAK-Client-Verbindungen
`8443`	HTTPS	Web-UI, REST API, WebSocket-Feeds
`8446`	HTTPS	TAK-Daten-Feeds und Missionspakete
`9000`	TCP/TLS	Föderation mit anderen TAK-Server-Instanzen (falls verwendet)

TLS-Zertifikat

Beschaffen Sie vor dem Deployment ein TLS-Zertifikat für den Hostnamen, mit dem sich ATAK-Clients verbinden werden. Legen Sie fullchain.pem und privkey.pem in /opt/cloudtak/ssl/ ab, bevor Sie fortfahren. Optionen: Let's Encrypt (kostenlos, automatische Erneuerung per certbot), Organisations-PKI (für geschlossene Netze oder Certificate Pinning) oder kommerzieller CA.

Schritt-für-Schritt Docker-Compose-Deployment

Erstellen Sie die Verzeichnisstruktur und kopieren Sie die TLS-Zertifikate:

mkdir -p /opt/cloudtak/{ssl,data,logs}
cd /opt/cloudtak
cp /etc/letsencrypt/live/tak.yourdomain.com/fullchain.pem ssl/
cp /etc/letsencrypt/live/tak.yourdomain.com/privkey.pem ssl/

Erstellen Sie /opt/cloudtak/.env mit den Umgebungsvariablen:

# /opt/cloudtak/.env
CLOUDTAK_DOMAIN=tak.yourdomain.com
CLOUDTAK_VERSION=latest

# PostgreSQL
POSTGRES_DB=cloudtak
POSTGRES_USER=cloudtak
POSTGRES_PASSWORD=change_this_strong_password_32chars

# TLS
SSL_CERT_PATH=/ssl/fullchain.pem
SSL_KEY_PATH=/ssl/privkey.pem

# Sicherheit
CLOUDTAK_ADMIN_PASSWORD=change_this_admin_password
CLOUDTAK_JWT_SECRET=generate_64_char_random_string_here
CLOUDTAK_MTLS=false          # Auf true setzen, sobald Client-Zertifikate ausgestellt sind
CLOUDTAK_AUDIT_LOG=true

# Performance
DB_POOL_MAX=20
CLOUDTAK_COT_RATE_LIMIT=100  # Max. CoT-Ereignisse/Sek. pro Client
COT_RETENTION_HOURS=72       # Tracks 72 Stunden vorhalten

Erstellen Sie /opt/cloudtak/docker-compose.yml:

version: '3.9'
services:
  postgres:
    image: postgis/postgis:15-3.3
    container_name: cloudtak-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - cloudtak-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
  cloudtak:
    image: ghcr.io/tak-ps/cloudtak:${CLOUDTAK_VERSION}
    container_name: cloudtak
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "8089:8089"   # CoT-Streaming (ATAK/WinTAK-Clients)
      - "8443:8443"   # HTTPS Web-UI + REST API
      - "8446:8446"   # TAK-Feeds + Missionspakete
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
      DOMAIN: ${CLOUDTAK_DOMAIN}
      SSL_CERT: ${SSL_CERT_PATH}
      SSL_KEY: ${SSL_KEY_PATH}
      ADMIN_PASSWORD: ${CLOUDTAK_ADMIN_PASSWORD}
      JWT_SECRET: ${CLOUDTAK_JWT_SECRET}
      MTLS: ${CLOUDTAK_MTLS}
      AUDIT_LOG: ${CLOUDTAK_AUDIT_LOG}
      DB_POOL_MAX: ${DB_POOL_MAX}
      COT_RATE_LIMIT: ${CLOUDTAK_COT_RATE_LIMIT}
      COT_RETENTION_HOURS: ${COT_RETENTION_HOURS}
    volumes:
      - ./ssl:/ssl:ro
      - ./data/cloudtak:/data
      - ./logs:/var/log/cloudtak
    networks:
      - cloudtak-internal
      - cloudtak-external
networks:
  cloudtak-internal:
    driver: bridge
    internal: true
  cloudtak-external:
    driver: bridge

Starten Sie den Stack mit docker compose up -d und verfolgen Sie die Logs mit docker compose logs -f cloudtak. Bei erfolgreichem Start erscheint CloudTAK listening on :8089 (CoT), :8443 (HTTPS), :8446 (feeds). Rufen Sie https://tak.yourdomain.com:8443/admin auf und melden Sie sich mit dem Admin-Passwort aus der .env-Datei an.

Konfiguration: Datenpakete, Benutzer und Föderation

Client-Datenpakete generieren

ATAK- und WinTAK-Clients verbinden sich mit CloudTAK durch den Import eines Datenpakets — einer .zip-Datei, die Serveradresse, Port, TLS-Zertifikat und Zugangsdaten vorkonfiguriert. Pakete lassen sich über die Admin-Oberfläche generieren: Admin → Verbindungen → Paket generieren, oder über das REST API:

curl -s -X POST https://tak.yourdomain.com:8443/api/package/generate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"username":"operator01","callsign":"ALPHA-1","team":"Red","role":"Team Member"}' \
  -o operator01-connection.zip

Laden Sie das .zip auf das ATAK-Gerät (via USB, ATAK-Paketimporter oder MDM). ATAK verarbeitet das Paket und stellt automatisch eine TCP/TLS-Verbindung zu Port 8089 her.

Benutzerverwaltung

CloudTAK unterstützt drei Authentifizierungsmodi, die unabhängig voneinander konfiguriert werden können:

Lokale Konten — über das Admin-API verwaltet. Geeignet für kleine Deployments oder isolierte Netze ohne vorhandenen Verzeichnisdienst.
LDAP / Active Directory — Konfiguration über die Umgebungsvariablen LDAP_URL, LDAP_BIND_DN und LDAP_BASE_DN. Benutzer authentifizieren sich mit ihren bestehenden Domain-Zugangsdaten.
Zertifikatsbasiert (mTLS) — jedes Client-Gerät besitzt ein eindeutiges, von der Deployment-CA signiertes Client-Zertifikat. CLOUDTAK_MTLS=true setzen und CA_CERT_PATH angeben. Dies ist der bevorzugte Modus für operative Umgebungen.

Föderationsverbindungen

Die Föderation erlaubt zwei CloudTAK-Instanzen (oder CloudTAK und Legacy-TAK-Server) den bidirektionalen Austausch von CoT-Ereignisströmen. Konfiguration über das REST API:

curl -s -X POST https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"HQ-TAK-Server","address":"tak.hq.example.mil","port":9000,"protocol":"tls","ca_cert":"/ssl/hq-ca.pem","bidirectional":true}'

Föderierte Ereignisse fließen in beide Richtungen: Einheiten am Remote-Server erscheinen auf Ihrer CloudTAK-Karte und umgekehrt. Die Föderation verwendet gegenseitiges TLS — tauschen Sie CA-Zertifikate mit dem Gegenseiten-Administrator aus, bevor Sie die Verbindung konfigurieren.

Härtung: TLS-Pinning, Firewall, Authentifizierung und Audit-Logging

Hinweis zur operativen Sicherheit: Eine CloudTAK-Instanz mit Standard-Zugangsdaten, selbstsigniertem Zertifikat und offenen Ports stellt eine erhebliche nachrichtendienstliche Gefährdung dar. Jedes CloudTAK-Deployment, das operative Einheiten versorgt, muss die nachfolgenden Härtungsschritte abschließen, bevor Feldgeräte verbunden werden.

TLS-Certificate-Pinning

Certificate Pinning schränkt Clients darauf ein, nur Zertifikate einer bestimmten CA zu akzeptieren, und verhindert so Man-in-the-Middle-Angriffe. Setzen Sie im Datenpakeт-Generator "pin_ca": true — dadurch wird der CA-Fingerabdruck in das ATAK-Verbindungsprofil eingebettet.

Firewall-Regeln

# Beispiel iptables-Regeln — IP-Bereiche an Ihr Deployment anpassen
# CoT (8089) nur aus bekannten ATAK-Geräte-IP-Bereichen erlauben
iptables -A INPUT -p tcp --dport 8089 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8089 -j DROP

# HTTPS (8443) aus Ops-Mitarbeiter-Subnetzen erlauben
iptables -A INPUT -p tcp --dport 8443 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -j DROP

# Feeds (8446) nur von ATAK-Geräten erlauben
iptables -A INPUT -p tcp --dport 8446 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8446 -j DROP

# Föderation (9000) nur von bekannten Peer-TAK-Servern
iptables -A INPUT -p tcp --dport 9000 -s 198.51.100.0/32 -j ACCEPT
iptables -A INPUT -p tcp --dport 9000 -j DROP

# Regeln persistieren
iptables-save > /etc/iptables/rules.v4

Audit-Logging

Bei CLOUDTAK_AUDIT_LOG=true schreibt CloudTAK strukturierte JSON-Audit-Ereignisse nach /var/log/cloudtak/audit.log. Jeder Eintrag erfasst: Zeitstempel, Client-IP, Benutzername (oder Zertifikats-CN bei mTLS), Ereignistyp (auth, connection, cot_ingest, package_download) und Ergebnis (Erfolg/Fehler). Leiten Sie diese Logs per Filebeat oder Fluentd an Ihr SIEM weiter — Authentifizierungsfehler und unbekannte Verbindungsquellen sollten Alarme auslösen.

Integration des TAKpilot-KI-Kopiloten

TAKpilot ist der KI-Kopilot von Corvus Intelligence für TAK-basierte taktische Operationen. Er läuft als Node.js-Mikrodienst neben CloudTAK, abonniert den CoT-Ereignisstrom über das WebSocket API von CloudTAK, führt KI-Inferenz durch (Bedrohungsmusteranalyse, Verhaltensanalyse, Routenoptimierung, SIGINT-Korrelation) und veröffentlicht die Ergebnisse als CoT-Ereignisse zurück, die auf allen verbundenen ATAK/WinTAK-Clients und in der CloudTAK-Weboberfläche erscheinen.

TAKpilot zum Docker-Compose-Stack hinzufügen

Ergänzen Sie folgende Service-Definition in Ihrer bestehenden docker-compose.yml unter services::

  takpilot:
    image: ghcr.io/corvus-intelligence/takpilot:latest
    container_name: takpilot
    restart: unless-stopped
    depends_on:
      - cloudtak
    environment:
      # CloudTAK-Verbindung
      CLOUDTAK_API_URL: https://cloudtak:8443
      CLOUDTAK_WS_URL: wss://cloudtak:8443/api/events
      CLOUDTAK_API_TOKEN: ${TAKPILOT_CLOUDTAK_TOKEN}

      # TAKpilot-API-Schlüssel (von Corvus Intelligence ausgestellt)
      TAKPILOT_API_KEY: ${TAKPILOT_API_KEY}

      # KI-Inferenz-Konfiguration
      TAKPILOT_THREAT_DETECTION: "true"
      TAKPILOT_PATTERN_OF_LIFE: "true"
      TAKPILOT_ROUTE_OPTIMIZATION: "true"
      TAKPILOT_SIGINT_CORRELATION: "false"   # Aktivieren, wenn SIGINT-Feed angeschlossen

      # Ausgabe: KI-Ergebnisse als CoT-Ereignisse zurück an CloudTAK veröffentlichen
      TAKPILOT_COT_OUTPUT: "true"
      TAKPILOT_COT_CALLSIGN_PREFIX: "AI-"
    networks:
      - cloudtak-internal

Ergänzen Sie die .env-Datei um zwei neue Variablen:

# TAKpilot (API-Schlüssel unter https://corvusintell.com/takpilot/ anfordern)
TAKPILOT_API_KEY=your_takpilot_api_key_here
TAKPILOT_CLOUDTAK_TOKEN=generate_via_cloudtak_admin_api

Generieren Sie den TAKPILOT_CLOUDTAK_TOKEN über das CloudTAK-Admin-API:

curl -s -X POST https://tak.yourdomain.com:8443/api/token \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "takpilot-service",
    "scopes": ["cot:read", "cot:write", "events:subscribe"]
  }' | jq -r '.token'

Starten Sie den Stack mit docker compose up -d neu. TAKpilot verbindet sich mit dem WebSocket-Feed von CloudTAK und beginnt innerhalb von Sekunden, KI-abgeleitete CoT-Ereignisse zu veröffentlichen. KI-Ergebnisse erscheinen auf der ATAK-Karte mit dem Rufzeichen-Präfix AI- und sind so von bodengemeldeten Tracks unterscheidbar.

Performance-Tuning: Verbindungen, Track-Retention und Rate-Limiting

Setzen Sie DB_POOL_MAX auf 20–30 % der erwarteten gleichzeitigen Client-Anzahl. Erhöhen Sie max_connections in PostgreSQL entsprechend. CLOUDTAK_COT_RATE_LIMIT liegt standardmäßig bei 100 Ereignissen/Sek. — erhöhen Sie auf 500–1000 für UAV-Integration. COT_RETENTION_HOURS standardmäßig 72; erhöhen Sie bei forensischen Wiedergabeanforderungen.

Häufige Probleme und Fehlerbehebung

ATAK-Client zeigt sofort „Connection Failed". Prüfen Sie, ob Port 8089 offen ist: nc -zv tak.yourdomain.com 8089. Bei Verbindungsablehnung ist der Port blockiert. Bei Timeout lauscht der Dienst nicht — prüfen Sie docker compose ps und docker compose logs cloudtak | grep 8089.

TLS-Zertifikat von ATAK abgelehnt. ATAK prüft, ob CN oder Subject Alternative Name (SAN) des Serverzertifikats mit dem Hostnamen im Verbindungsprofil übereinstimmt. Überprüfen Sie den SAN mit: openssl x509 -in ssl/fullchain.pem -text | grep -A1 "Subject Alternative".

Datenbankverbindungspool erschöpft (Fehler: "remaining connection slots reserved"). Erhöhen Sie DB_POOL_MAX in .env und max_connections in postgresql.conf. Starten Sie beide Dienste neu. Überwachen Sie mit: docker exec cloudtak-postgres psql -U cloudtak -c "SELECT count(*) FROM pg_stat_activity;".

CoT-Ereignisse erscheinen am Server, aber nicht bei ATAK-Clients. Fast immer ein Zeitabweichungsproblem. CoT-Ereignisse tragen einen stale-Zeitstempel-Schwellenwert — liegt die Serveruhr mehr als 5 Minuten vor dem Client, werden Ereignisse als veraltet verworfen. Stellen Sie sicher, dass NTP auf Server und Clients konfiguriert ist: timedatectl status.

TAKpilot veröffentlicht keine KI-Ereignisse. Prüfen Sie die TAKpilot-Logs: docker compose logs takpilot. Häufige Ursachen: ungültiger API-Schlüssel (Corvus-Intelligence-Support kontaktieren), falsch konfigurierte CLOUDTAK_API_URL (Container-Dienstname cloudtak statt externem Hostnamen verwenden) oder unzureichende Token-Berechtigungen (Token muss den Scope cot:write besitzen).

Hoher Speicherverbrauch nach mehreren Tagen. Track-Akkumulation im Speicher ist die häufigste Ursache. Prüfen Sie, ob COT_RETENTION_HOURS sinnvoll gesetzt ist und der PostgreSQL-Bereinigungsjob läuft. Status des Bereinigungsjobs über das CloudTAK-Admin-API prüfen: GET /api/admin/jobs. Bei Bedarf manuell auslösen: POST /api/admin/jobs/cleanup.