Config as Code am Endpunkt: die letzte Schicht, die per Klick verwaltet wird

Der Endpunkt wird weiterhin über eine Konsole verwaltet, in der jemand ein Häkchen setzt und niemand hinterher rekonstruieren kann, wer es wann und warum gesetzt hat.

Was Config as Code am Endpunkt konkret heißt

Die Gerätekonfiguration liegt als deklarative Datei in der Versionsverwaltung der Organisation und wird von deren eigener Pipeline angewendet. Nicht als Export aus einem Werkzeug, nicht als Sicherung, nicht als Dokumentation neben dem eigentlichen Zustand. Die Datei ist der Zustand.

Daraus folgen drei Dinge, die sich in der Konsolenwelt nur nachbauen lassen: eine einzige Quelle der Wahrheit, ein Freigabepfad mit zweitem Augenpaar, und ein Änderungsprotokoll, das der Organisation gehört statt beim Hersteller zu liegen.

Warum das in regulierten Umgebungen mehr ist als Bequemlichkeit

Änderungsführung

Wer darf was ändern, wer hat freigegeben, wann wurde es wirksam: In einem Repository sind das Eigenschaften des Verfahrens, nicht Fragen an die Erinnerung eines Administrators. Das bildet gesetzliche Pflichten zur Änderungsführung ohne Zusatzwerkzeug ab und lässt sich auf die IT-Grundschutz-Bausteine ORP.4 und OPS.1.1.5 abbilden.

Prüfbarkeit

Ein Prüfer fragt nicht, ob eine Einstellung gesetzt ist. Er fragt, seit wann, auf welcher Grundlage und wer sie geprüft hat. Diese drei Antworten stehen im Verlauf des Repositories, ohne dass jemand sie im Nachhinein herstellt.

Wiederherstellbarkeit

Ein Zustand, der als Datei existiert, ist reproduzierbar. Nach einem Fehlgriff, nach einem Personalwechsel, in einer zweiten Umgebung, für einen Prüfstand. Ein Konsolenzustand ist das nicht, auch wenn er exportierbar ist.

Nachweise entstehen, statt zusammengesucht zu werden

Entscheidend ist nicht die Datei, sondern die Schnittstelle dahinter. Wenn jede Funktion über eine dokumentierte API erreichbar ist und die Konsole selbst nur ein Client dieser API ist statt ein privilegierter Weg daran vorbei, sind Konfiguration, Richtlinie und Compliance-Zustand maschinell lesbar und schreibbar.

Das ist der Unterschied zwischen einem Audit bestehen und sechs Wochen lang eines vorbereiten. Der Bericht wird erzeugt, nicht geschrieben. Und er ist zum Zeitpunkt der Prüfung aktuell, nicht zum Zeitpunkt der letzten manuellen Erhebung.

Git, YAML und SQL sind einstellbar

Eine Verwaltung, die eine Apple-Flotte über Repository und Pipeline führt, braucht Fähigkeiten, die ihre IT bereits hat oder zu Marktpreisen einstellen kann. Eine proprietäre Suite verlangt produktspezifische Spezialisten, die knapp und teuer sind. In einem Umfeld, in dem Personal die bindende Beschränkung ist und nicht das Lizenzbudget, ist das weniger eine Frage der Präferenz als des Haushalts.

Was das von der Verwaltungsebene verlangt

• Eine vollständige API, über die alles erreichbar ist, was auch die Konsole kann.
• Deklarative Zielzustände statt imperativer Kommandofolgen, damit die Datei den Zustand beschreibt und nicht den Weg dorthin.
• Artefakte, die sich sinnvoll versionieren lassen: lesbar im Diff, stabil in der Reihenfolge, ohne generierte Kennungen, die sich bei jedem Export ändern.
• Maschinenlesbarer Compliance-Zustand, abrufbar ohne Klickstrecke.
• Betrieb im eigenen Haus ohne Funktionsverlust, wenn die Umgebung das verlangt.

Diese fünf Punkte sind der Prüfstein. Ein Werkzeug, das eine API anbietet, aber die Konsole als eigentlichen Pfad behält, erfüllt sie nicht: Was dort per Klick möglich ist und per API nicht, wird früher oder später per Klick gemacht.

Wo die Grenzen liegen

Nicht jede Einstellung ist deklarativ abbildbar. Apples Declarative Device Management deckt einen wachsenden, aber nicht vollständigen Teil ab, der Rest bleibt Kommando und Skript. Nutzerinteraktion lässt sich ohnehin nicht wegdeklarieren: Zustimmungen, Wiederherstellungsschlüssel und Erstanmeldung bleiben Ereignisse mit Menschen darin.

Organisatorisch kommt hinzu: Wer die Pipeline kontrolliert, kontrolliert die Flotte. Die Rechte an Repository und Pipeline sind ab diesem Punkt sicherheitsrelevant und gehören entsprechend geführt. Ein Repository ersetzt außerdem keine Ownership-Definition, es macht sichtbar, dass sie fehlt. Und Ausnahmen brauchen weiterhin ein Verfahren, der Unterschied ist nur, dass sie als Abweichung im Diff auftauchen statt als stiller Sonderfall im Gerät.

Wo das heute ausgeliefert wird

Am konsequentesten setzt derzeit Fleet Device Management diesen Ansatz um: Gerätekonfiguration als versionierte Dateien mit GitOps-Workflow, eine API, an der die Konsole selbst hängt, Abfragen des Gerätezustands über SQL, quelloffen und ohne Funktionsverlust im Eigenbetrieb bis hin zum netzgetrennten Aufbau.

Etablierte Verwaltungsebenen wie Jamf Pro, Omnissa Workspace ONE und Microsoft Intune bieten APIs, über die sich Teile davon nachbauen lassen, und es gibt Werkzeuge, die Konfiguration als Code darüberlegen. Der Unterschied liegt darin, ob der Ansatz die Voreinstellung ist oder eine Disziplin, die gegen das Werkzeug durchgehalten werden muss. In regulierten Umgebungen entscheidet das über die Nachweisführung, weil eine Disziplin unter Zeitdruck nachgibt und eine Voreinstellung nicht.

Für klassifizierte Umgebungen kommt eine zweite Bedingung dazu: Die Verwaltungsebene muss nach MDM-TS zertifiziert sein und souverän betrieben werden. Wie beides zusammenhängt, steht auf der indigo-Seite.