ATAK-CIV vs ATAK-MIL: den richtigen TAK-Client wählen und einsetzen

Das Team Awareness Kit erscheint in zwei Ausprägungen. ATAK-CIV ist der offene zivile Client, den jeder herunterladen und betreiben kann; ATAK-MIL ist der kontrollierte Militär-Build, der ausschließlich an autorisierte Regierungsnutzer ausgehändigt wird. Beide sehen auf dem Bildschirm nahezu identisch aus, teilen dieselbe Karten-Engine und sprechen dieselbe Cursor-on-Target-Sprache — dennoch führt die Wahl der falschen Variante oder die nachlässige Bereitstellung einer von beiden zum selben Ergebnis: ein taktisches Lagebild, das nicht federiert, Plugins, die nicht laden, oder sensible Daten auf einem Gerät, das nie für deren Verarbeitung akkreditiert war. Dieser Artikel schlüsselt auf, was sich tatsächlich zwischen den beiden Varianten unterscheidet, wann jede die richtige Wahl ist und wie die gewählte Variante flottenweit so ausgerollt wird, dass jedes Gerät im Netzwerk dasselbe vertrauenswürdige Lagebild sieht.

Zwei Builds, ein Kern

Das Wichtigste, was man über ATAK-CIV und ATAK-MIL verstehen muss, ist, dass es sich um Builds desselben Produkts handelt, nicht um zwei verschiedene Produkte. Beide stammen von derselben Codebasis ab, die vom TAK Product Center gepflegt wird. Beide rendern die Karte mit derselben Engine, beide verwenden dasselbe Plugin-Framework, und beide tauschen Lageerkennungsdaten als Cursor-on-Target-Ereignisse aus. Wer unsere Einführung in die ATAK-Plugin-Entwicklung gelesen hat, wird feststellen, dass diese Architektur unverändert für beide Varianten gilt — die API-Oberfläche, gegen die ein Plugin entwickelt wird, ist geteilt.

Was die beiden unterscheidet, ist der Vertriebskanal und der Funktionsumfang, der auf dem gemeinsamen Kern aufbaut. ATAK-CIV wird offen veröffentlicht. Es ist die Version, die von Ersthelfern, Sicherheitsteams für kritische Infrastruktur, Such- und Rettungsorganisationen, alliierten Freiwilligenverbänden und Entwicklern genutzt wird, die Plugins entwickeln und testen. ATAK-MIL ist zugangskontrolliert, wird über Regierungskanäle nur an autorisierte Nutzer verteilt und fügt Funktionen hinzu, die die zivile Version bewusst auslässt: Verarbeitung von Klassifizierungskennzeichnungen, zusätzliche kryptografische Module, Integration eingeschränkter Nachrichtenformate sowie militärspezifische Symbologie und Overlays.

Da die Divergenz additiver und nicht struktureller Natur ist, ist das mentale Modell unkompliziert: ATAK-MIL ist ATAK-CIV zuzüglich einer kontrollierten Funktionsschicht zuzüglich eines kontrollierten Vertriebskanals. Alles, was man in CIV tun kann, kann man auch in MIL tun; das Umgekehrte gilt nicht, und die Lücke wird ebenso stark durch Akkreditierung und Richtlinien wie durch Code geregelt.

Funktions- und Lizenzunterschiede

Auf der Funktionsachse konzentrieren sich die praktischen Unterschiede auf drei Bereiche. Erstens die Datenverarbeitung: ATAK-MIL versteht Klassifizierungskennzeichnungen und die damit verbundenen Workflows — Inhalte kennzeichnen, Freigabe-Vorbehalte durchsetzen und markierte Daten getrennt halten. ATAK-CIV behandelt alle Inhalte als unklassifiziert. Zweitens die Kryptografie: Der Militär-Build kann zugelassene kryptografische Module und Schlüsselverwaltungs-Integrationen einbinden, die für akkreditierte Umgebungen erforderlich sind, während ATAK-CIV auf Standard-Transportverschlüsselung — TLS zum Server — setzt, was für unklassifizierte, aber sensible Nutzung geeignet ist. Drittens Content Packs: Bestimmte Symbolsätze, Overlays und Nachrichtenformat-Integrationen sind nur mit dem Militär-Build gebündelt.

Auf der Lizenzachse geht es darum, wer die jeweiligen Builds erhalten und betreiben darf. ATAK-CIV wird unter Bedingungen vertrieben, die eine breite öffentliche Nutzung erlauben — weshalb ein ganzes Ökosystem aus Drittanbieter-Plugins und -Integrationen darum herum entstanden ist. ATAK-MIL ist auf autorisierte Regierungsnutzer beschränkt; es außerhalb dieses Kanals zu beschaffen, ist nicht rechtmäßig, und keine kommerzielle Beziehung ändert das. Für jedes nicht-staatliche Team ist die Lizenzantwort daher zugleich die Deployment-Antwort: Der einzige Client, den man rechtmäßig einsetzen kann, ist ATAK-CIV.

Interoperabilität: ein gemeinsames Lagebild

Da beide Varianten dasselbe Cursor-on-Target-Datenmodell verwenden und sich mit demselben TAK Server verbinden können, sehen ein CIV-Gerät und ein MIL-Gerät im selben Verbund gegenseitig ihre Positionen und Ereignisse. Auf der Protokollebene gibt es keine Barriere — ein von einem Gerät veröffentlichtes CoT-Ereignis ist vom anderen konsumierbar, und dasselbe gilt für die geografischen Overlays und den Chat-Datenverkehr, der über den CoT-Bus transportiert wird. Für einen tieferen Einblick in die Funktionsweise dieses Busses und seiner Datenverträge in der Praxis deckt unsere Übersicht über das Open-Source-TAK-Ökosystem den Server, die Nachrichtenformate und die Integrationen ab, die daran hängen.

Die eigentliche Einschränkung bei gemischten Deployments ist die Richtlinie, nicht das Protokoll. Ein TAK Server, der für klassifizierten Datenverkehr akkreditiert ist, lässt keine zivilen Clients zu — und das zu Recht: Ein CIV-Gerät in ein klassifiziertes Lagebild aufzunehmen, würde markierte Daten einem Client zugänglich machen, der keine Akkreditierung für deren Verarbeitung besitzt. Wenn ein Deployment tatsächlich beide Welten interoperieren lassen muss, ist die Antwort eine bewusst gestaltete Datendomain-Grenze: entweder eine Cross-Domain-Lösung, die freigegebene Inhalte nach unten bereinigt und weitergibt, oder ein separater unklassifizierter Server, der nur die freizugebende Teilmenge des Lagebilds spiegelt. Interoperabilität ist eine Deployment-Entscheidung, die man entwirft, akkreditiert und dokumentiert — kein Kontrollkästchen in der App.

Die Datendomain-Grenze gestalten

Die häufigste Architektur für gemischte CIV/MIL-Operationen betreibt zwei Server. Der klassifizierte Server verbindet die MIL-Clients und das markierte Lagebild. Ein Guard- oder Freigabeprozess überträgt nur freizugebende Tracks — typischerweise eigene Kraftpositionen und einen kuratierten Satz von Interessenpunkten — auf einen separaten unklassifizierten Server, mit dem sich die CIV-Clients verbinden. Von CIV stammende Meldungen fließen als unklassifizierte Eingaben in das klassifizierte Lagebild aufwärts. Dies hält den Fluss sensibler Daten an der Grenze unidirektional und gibt Akkreditierern einen einzigen, prüfbaren Engpass, über den sie nachdenken können, anstatt ein Viele-zu-viele-Netz von Clients auf unterschiedlichen Vertrauensebenen.

Plugin-Kompatibilität zwischen Varianten

Plugins sind der Hauptgrund, warum Teams ATAK überhaupt einsetzen, daher ist das Plugin-Verhalten zwischen den Varianten wichtig. Ein Plugin ist ein Android-Paket, das gegen eine bestimmte ATAK-SDK-Version kompiliert wird; beim Laden prüft die Host-App den deklarierten API-Level und die Signierung des Plugins gegen ihre eigenen Erwartungen. Da die Plugin-API-Oberfläche zwischen CIV und MIL derselben Version geteilt wird, lädt ein gegen das CIV-SDK gebautes Plugin in der Regel auf dem passenden MIL-Build — und umgekehrt —, sofern die Versionen übereinstimmen.

Probleme treten in zwei Situationen auf. Das erste ist eine Versionsabweichung: Ein Plugin, das gegen eine ältere oder neuere SDK als der Host gebaut wurde, wird sauber abgelehnt — weshalb das Pinnen der Client-Version über eine gesamte Flotte nicht verhandelbar ist. Das zweite ist eine Funktionsabhängigkeit: Ein Plugin, das eine Funktion aufruft, die nur im Militär-Build vorhanden ist, schlägt auf CIV fehl, und ein Plugin, das die lockerere Signierung oder Zulassungsliste eines CIV-Builds voraussetzt, kann von einem MIL-Build abgelehnt werden, der eine strengere Paketvalidierung durchsetzt. Die Disziplin, die beides vermeidet, besteht darin, jedes Zielvarianten-und-Versions-Paar als separates Build-Ziel zu behandeln — das Plugin dagegen zu kompilieren und darauf zu testen, anstatt anzunehmen, dass ein CIV-getestetes Plugin automatisch MIL-tauglich ist. Wo Signierung und Manipulationssicherheit ein Thema sind, deckt unser Leitfaden zur ATAK-Plugin-Sicherheitshärtung die Schutzmaßnahmen ab, die das Plugin unabhängig davon begleiten sollten, welche Variante es hostet.

Sicherheitsprofil und Akkreditierung

Es liegt nahe, „MIL" mit „sicher" und „CIV" mit „unsicher" gleichzusetzen, aber die Wahrheit ist differenzierter. Der App-Code ist weitgehend gemeinsam; der Sicherheitsunterschied liegt in der Infrastruktur, die jede Variante umgibt. ATAK-MIL ist dafür ausgelegt, in akkreditierten Umgebungen eingesetzt zu werden — es unterstützt zugelassene kryptografische Module, Klassifizierungskennzeichnungen und die Geräteverwaltungs- und Prüfkontrollen, die diese Umgebungen vorschreiben. Es ist jedoch nur so sicher wie die Bereitstellung, die Schlüsselverteilung und der akkreditierte Server dahinter. Ein MIL-Build auf einem nicht verwalteten Gerät mit laxem Schlüsselmanagement untergräbt genau die Kontrollen, die der Build unterstützen soll.

ATAK-CIV wiederum ist für unklassifizierte, aber sensible Operationen völlig angemessen, wenn es mit disziplinierten Praktiken kombiniert wird: TLS zu einem ordnungsgemäß konfigurierten TAK Server, gehärtete Geräte, sorgfältiges Zertifikats- und Schlüsselmanagement und erzwungenes Mobile Device Management. Die Lücke zwischen den beiden Sicherheitsprofilen dreht sich also größtenteils um die akkreditierte Begleitinfrastruktur, nicht darum, welche APK installiert ist. Ein gut geführtes CIV-Deployment kann deutlich sicherer sein als ein schlecht geführtes MIL-Deployment.

Skalierbare Deployment-Modelle

Unabhängig davon, welche Variante man wählt, ist die Deployment-Disziplin dieselbe, und sie beginnt mit einem Golden Image. Eine Flotte robuster Android-Geräte muss nachweislich identisch sein: dieselbe Client-Variante in einer gepinnten Version, dasselbe validierte Plugin-Set, das gegen genau dieses SDK gebaut wurde, dieselben Offline-Kartenpakete, dieselben Server-Verbindungsprofile und dieselbe Zertifikatsstruktur. Dieses Image wird einmal erstellt, signiert, sein Manifest dokumentiert und auf jedes Gerät übertragen. Heterogene Flotten — die von Hand, Gerät für Gerät, zusammengestellt werden — sind der Nährboden für Plugin-Versionsabweichungen und Verbindungsfehler.

Verteilung und Lebenszyklus laufen dann über Mobile Device Management. MDM überträgt das Image, rotiert Zertifikate, setzt Gerätehärtungsrichtlinien durch und ermöglicht es, ein verlorenes Gerät aus der Ferne zu sperren. Die Mechanik, dies im großen Maßstab zu tun — Registrierung, Flotten-Bereitstellung und laufendes Management — ist Gegenstand unserer ausführlichen Behandlung des ATAK-Android-Gerätemanagements, und sie gilt gleichermaßen für CIV- und MIL-Flotten. Die Variantenentscheidung ändert, was man in das Image packt; sie ändert nicht die Notwendigkeit, dieses Image als ein einziges, versioniertes, prüfbares Artefakt über die gesamte Flotte hinweg zu verwalten.

Die Validierung schließt den Kreislauf. Bevor ein Deployment als „abgeschlossen" gilt, ist von Ende zu Ende zu bestätigen, dass Clients auf dem Server erscheinen, CoT in beide Richtungen fließt, jedes gebündelte Plugin lädt und — entscheidend — das Lagebild einen Verbindungsausfall übersteht und sich wieder synchronisiert, wenn die Verbindung zurückkehrt. Ein TAK-Client, der nur bei bestehender Verbindung funktioniert, ist kein taktisches Werkzeug, und dieser Test ist derselbe, unabhängig davon, ob die Bezeichnung auf dem Build CIV oder MIL lautet.