# Lokale Agent-Gateways mit macOS MDM

Ein lokales Agent-Gateway sollte wie eine sicherheitsrelevante Desktop-Anwendung verteilt werden, nicht wie ein System zur Weitergabe gemeinsamer Geheimnisse. MDM verwaltet die signierte Anwendung, ihre Version, ihren Startzustand und ihre Entfernung. Der Entwickler verwaltet die Zugangsdaten, die er in einem lokalen Tresor ablegt, sowie die Freigaben, die einem Agenten Aktionen mit diesen Zugangsdaten erlauben.

Diese Trennung ist mehr als saubere Administration. Wenn die IT API-Schlüssel über MDM verteilt, wird jeder kompromittierte Teil der Verwaltungsebene, jeder Inventarexport, jedes Deployment-Skript und jedes Konfigurationsprofil zu einer möglichen Quelle für Geheimnisverlust. Wenn ein Agent den Schlüssel selbst erhält, gehören jedes Log, jedes Tool-Protokoll, jeder Shell-Verlauf und jede Prompt-Grenze zur Angriffsfläche des Geheimnisses. Ein Gateway soll genau diese Zugangsdaten aus dem Agent-Prozess heraushalten. Diese Architektur darfst du beim Rollout nicht wieder aufheben.

Für eine Flotte verwalteter Macs würde ich daher so vorgehen: ein überprüfbares App-Paket verteilen, es im richtigen Benutzerkontext starten, Releases über Ringe ausrollen, jeden Entwickler seine eigenen Zugangsdaten lokal registrieren lassen und Geräte in einer Reihenfolge ausmustern, die zuerst den Zugriff entfernt und erst danach die Hardware löscht.

## MDM sollte das Gateway verteilen, nicht die Berechtigungen des Entwicklers

MDM sollte wissen, welcher Mac die freigegebene Anwendung besitzt und welche Version darauf läuft. Es sollte nicht zum Tresor für persönliche API-Tokens, private SSH-Schlüssel oder eingefügte Zugangsdaten-Dateien werden.

Oft werden zwei getrennte Dinge vermischt, weil beide «Konfiguration» heißen. Eine App zu installieren ist Flottenkonfiguration. Einer Person oder einem Agenten die Berechtigung zu geben, eine Produktions-API aufzurufen, ist delegierte Autorität. Das Erste gehört in MDM. Das Zweite gehört in einen lokalen, vom Benutzer kontrollierten Tresor mit einer klaren Freigabegrenze.

Diese Unterscheidung wirkt sich direkt auf das Onboarding aus. Dein MDM-Workflow kann das Gateway installieren, bevor der Entwickler seinen Editor öffnet. Der erste Start muss den Entwickler trotzdem auffordern, seinen eigenen Tresor zu erstellen oder zu entsperren und nur die Zugangsdaten hinzuzufügen, die er verwenden darf. IT kann die freigegebenen Zugangsdaten-Typen und erforderlichen Dienstkonten dokumentieren. Sie sollte jedoch nicht das geheime Material sammeln, um es später wieder zu verteilen.

Auch beim Offboarding bleibt diese Trennung ehrlich. Das Entfernen einer verwalteten App widerruft kein Cloud-Token, das vor Monaten in ein Profil kopiert wurde. In einem lokalen Tresor kann der Benutzer eine Zugangsdaten direkt entfernen, während der Dienstverantwortliche das Token an seiner Quelle widerruft. So hast du zwei unabhängige Wege, den Zugriff zu beenden, statt eines fragilen Bereinigungsskripts.

Bei Sallyport ist diese Aufteilung bewusst gewählt: Die App bewahrt API- und SSH-Schlüssel in ihrem verschlüsselten lokalen Tresor auf und führt HTTP- oder SSH-Aktionen selbst aus, statt Zugangsdaten an den verbundenen Agenten weiterzugeben. Das Deployment muss diese Eigenschaft erhalten.

Ein sinnvoller MDM-Eintrag für das Gateway enthält nur betriebliche Fakten:

- Seriennummer oder Verwaltungskennung des Geräts
- zugewiesener Deployment-Ring und App-Version
- Paketbeleg und Ergebnis der Installation
- primärer Supportverantwortlicher und Ablaufdatum einer Ausnahme
- ob die App erforderlich, optional oder zur Entfernung vorgemerkt ist

Füge keine Geheimnisnamen, Token-Werte, Pfade zu privaten Schlüsseln oder Freigabeverläufe in dieses Inventarfeld ein. Diese Angaben geben entweder sensible Zusammenhänge preis oder erwecken den falschen Eindruck, MDM könne den Arbeitszugriff eines Benutzers rekonstruieren.

## Das Paket ist der Deployment-Vertrag

Ein signiertes Installationspaket ist das Artefakt, das einen wiederholbaren Rollout für eine Flotte ermöglicht. Ein in einem Chat weitergereichtes Disk-Image, ein in «Downloads» entpacktes ZIP-Archiv oder ein Skript, das ein App-Bundle nach `/Applications` kopiert, ist kein Deployment-Vertrag.

Die Deployment-Dokumentation von Apple besagt, dass Pakete, die über die Geräteverwaltung installiert werden, eine Signatur tragen müssen, die das Gerät prüfen kann. Sie empfiehlt außerdem eigenständige Anwendungen. Dadurch entfallen bei der gewöhnlichen App-Bereitstellung eigene Installationsskripte. Das ist auch hier sinnvoll. Skripte vervielfachen mögliche Fehler, laufen mit schwer verständlichen Berechtigungen und bleiben oft noch lange bestehen, nachdem sich die Anwendung geändert hat.

Erstelle für jede veröffentlichte Version ein Release-Artefakt. Verwende einen Dateinamen mit Versionsnummer, bewahre die Prüfsumme im Release-Eintrag auf und verlange in jedem Ring dasselbe Paket. Ein Ring sollte die Nutzung desselben Builds testen, nicht eine nicht nachvollziehbare Variante, die für jede Gruppe neu zusammengestellt wurde.

Prüfe ein Paket vor dem Upload in MDM sowie die installierte App auf einem sauberen Test-Mac. Diese Befehle liefern eine sinnvolle Mindestprüfung:

```sh
pkgutil --check-signature Sallyport.pkg
spctl -a -vv -t install Sallyport.pkg
```

Der erste Befehl sollte einen signierten Installer und eine gültige Signaturkette ausweisen. Der zweite sollte das Paket für die Installation bewerten. Prüfe nach der Bereitstellung auch das App-Bundle:

```sh
codesign --verify --deep --strict --verbose=2 /Applications/Sallyport.app
spctl -a -vv /Applications/Sallyport.app
```

Betrachte einen grünen MDM-Status nicht als Beweis dafür, dass das richtige Binary einsatzbereit ist. MDM kann melden, dass das Paket installiert wurde, obwohl ein späteres Login-Element, ein Hintergrundhelfer, eine Berechtigung oder eine Anforderung an die Benutzersitzung die App an sinnvoller Arbeit hindert. Paketprüfung und Funktionstest beantworten unterschiedliche Fragen.

Halte das Paket unkompliziert. Es sollte die Anwendung am erwarteten Ort installieren, während der Nachinstallation kein zweites ausführbares Programm herunterladen und keine Zugangsdaten oder benutzerspezifischen Einstellungen schreiben. Wenn ein Paket ein umfangreiches Nachinstallationsskript braucht, damit das Produkt funktioniert, frage dich, ob das App-Design oder die Paketgrenze falsch gewählt ist. Für dieses Skript zahlst du bei jedem macOS-Upgrade und jeder Untersuchung eines Sicherheitsvorfalls.

Die installierte App sollte sich als App entfernen lassen, nicht im Rahmen einer forensischen Untersuchung. Apple weist darauf hin, dass ein von einem Paket nach `/Applications` installiertes App-Bundle vom Geräteverwaltungsdienst verwaltet und einzeln entfernt werden kann. Das ist ein weiterer Grund, zentrale Dateien nicht über beliebige Verzeichnisse zu verstreuen.

## Die App in der Sitzung des Entwicklers starten

Ein Gateway, das eine lokale Freigabe verlangt oder Zugriff auf einen benutzergeschützten Tresor braucht, muss im Kontext des angemeldeten Benutzers laufen. Ein Root-Daemon ist kein Ersatz für diesen Kontext.

Hier machen Teams einen vorhersehbaren Fehler. Sie sehen «immer aktiv» und greifen zu einem LaunchDaemon, weil er vor der Anmeldung startet und die Abmeldung des Benutzers überlebt. Danach stellen sie fest, dass der Daemon keine Benutzerfreigabe zuverlässig anzeigen, nicht den erwarteten Benutzer-Schlüsselbund oder biometrischen Autorisierungsweg nutzen kann und mehr Berechtigungen angesammelt hat, als die Aufgabe benötigt.

Apple zieht diese Grenze klar. Ein Login-Element startet, wenn sich der Benutzer anmeldet, und läuft in dessen Sitzung. Ein LaunchAgent läuft ebenfalls für den angemeldeten Benutzer. Ein LaunchDaemon läuft auf Systemebene, kann vor der Anmeldung starten und läuft als Root. Apple beschreibt Login-Elemente außerdem als passend für eine benutzerorientierte App, die während der Sitzung aktiv bleiben soll.

Für ein Gateway in der Menüleiste ist ein verwaltetes Login-Element oder der eigene unterstützte Mechanismus der Anwendung für Login-Elemente normalerweise die richtige Wahl. Die App sollte starten, nachdem der Benutzer den Schreibtisch erreicht hat, sichtbar genug bleiben, damit der Entwickler ihren aktiven Zustand erkennen kann, und beim Abmelden stoppen. Verstecke keine Sicherheitsgrenze in einem Prozess, den Benutzer nicht prüfen oder beenden können.

Wenn MDM das Startverhalten erzwingen muss, verwende Apples verwaltete Nutzlast für Login-Elemente, statt eine eigene plist per Skript zu kopieren. Die Nutzlast `com.apple.loginitems.managed` kann einen Anwendungspfad und die Option angeben, ob die App verborgen werden soll. Apples Referenz zur Geräteverwaltung beschreibt die Struktur der Nutzlast und unterstützt sie unter macOS.

Eine beispielhafte Nutzlast sieht so aus. Ersetze Kennungen und Pfad durch deine eigenen veröffentlichten Werte und erzeuge UUIDs mit deinen üblichen Werkzeugen für Profile.

```xml
\u003cdict\u003e
  \u003ckey\u003ePayloadType\u003c/key\u003e
  \u003cstring\u003ecom.apple.loginitems.managed\u003c/string\u003e
  \u003ckey\u003ePayloadIdentifier\u003c/key\u003e
  \u003cstring\u003edev.example.agent-gateway.login-item\u003c/string\u003e
  \u003ckey\u003ePayloadUUID\u003c/key\u003e
  \u003cstring\u003eREPLACE-WITH-UUID\u003c/string\u003e
  \u003ckey\u003ePayloadVersion\u003c/key\u003e
  \u003cinteger\u003e1\u003c/integer\u003e
  \u003ckey\u003eAutoLaunchedApplicationDictionary-managed\u003c/key\u003e
  \u003carray\u003e
    \u003cdict\u003e
      \u003ckey\u003ePath\u003c/key\u003e
      \u003cstring\u003e/Applications/Sallyport.app\u003c/string\u003e
      \u003ckey\u003eHide\u003c/key\u003e
      \u003cfalse/\u003e
    \u003c/dict\u003e
  \u003c/array\u003e
\u003c/dict\u003e
```

Der Fehler, den dies verhindert, ist banal, aber teuer: Das Paket wird installiert, die App erscheint in `/Applications` und der Entwickler nimmt an, dass das Gateway seinen Agenten schützt. Tatsächlich wurde es nach der Anmeldung nie gestartet. Der MCP-Shim kann daher eine Anfrage nicht abschließen oder der Benutzer sieht die Freigabekarte nicht. Deine Registrierungsprüfungen müssen eine tatsächliche Benutzeranmeldung testen, nicht nur die Installation durch den MDM-Agenten.

Ein LaunchDaemon hat weiterhin legitime Einsatzbereiche, sollte aber aus dem Pfad des Tresors herausgehalten werden. Verwende ihn nur, wenn du erklären kannst, warum der Job ohne grafische Sitzung laufen muss und warum Root erforderlich ist. «Wir wollten es zuverlässig machen» ist keine ausreichende Begründung. Eine Anwendung in der Benutzersitzung kann zuverlässig sein, ohne sich als Maschinendienst auszugeben.

## Update-Ringe sollten echte Entwicklerarbeit testen

Update-Ringe funktionieren, wenn jeder Ring eine andere betriebliche Frage beantwortet. Sie scheitern, wenn sie zu einer höflichen Methode werden, jedes Update für immer aufzuschieben.

Verwende zuerst einen kleinen internen Ring. Nimm Personen auf, die die App paketieren, die MDM-Konfiguration verantworten und Probleme auf Entwickler-Workstations beheben. Ihre Aufgabe ist es, Installationsfehler, fehlerhaftes Startverhalten, unerwartete Berechtigungsabfragen und Upgrade-Pfade von der bisherigen Produktionsversion zu erkennen.

Der nächste Ring sollte Entwickler mit unterschiedlichen Tools und Zugriffsmustern umfassen. Nimm jemanden auf, der über einen Agenten HTTP-APIs nutzt, jemanden mit SSH, jemanden, der häufig das Netzwerk wechselt, und jemanden mit einem normalen verwalteten Konto ohne lokale Administratorrechte. Du suchst Unterschiede in der tatsächlichen Nutzung, nicht eine Gruppe von Enthusiasten, die jede unausgereifte Stelle verzeiht.

In der Produktion wird die Version zum Standard. Halte nur für einen konkreten Grund eine kleine Notfall-Haltegruppe zurück, mit Verantwortlichem und Ablaufdatum. «Diese Person ist beschäftigt» ist keine Deployment-Richtlinie. So werden nicht unterstützte Versionen dauerhaft.

Behandle den Rollout als Zustandsmaschine, nicht als Kalenderritual:

1. Installiere das signierte Paket im internen Ring und bestätige die Prüfung von Paket und Anwendung.
2. Lass jeden Testbenutzer sich ab- und wieder anmelden und bestätige, dass das Gateway in seiner Sitzung startet.
3. Führe harmlose echte Aktionen über den Agent-Pfad aus, darunter eine HTTP-Anfrage und einen SSH-Befehl, sofern diese Kanäle im Umfang enthalten sind.
4. Verschiebe nach der Prüfung von Fehlern, Support-Tickets und Rollback-Anforderungen dasselbe Paket in den Pilotring.
5. Veröffentliche es erst dann in der Produktion, wenn der Upgrade-Pfad der vorherigen Version funktioniert, nicht nur eine frische Installation.

Definiere Erfolg nicht als «Die MDM-Konsole meldet installiert». Erfolg ist eine Kette beobachtbarer Ereignisse: Der Paketbeleg ist vorhanden, die signierte App besteht die Prüfung, die App startet nach der Anmeldung, der Entwickler kann seinen eigenen Tresor entsperren, der Agent erreicht den lokalen Shim und eine erlaubte Aktion liefert ein Ergebnis.

Lege das Rollback vor dem Rollout fest. Bei einem gewöhnlichen App-Update sollte Rollback bedeuten, das vorherige signierte Paket erneut zu verteilen, die Zuweisung der erforderlichen Version zurückzusetzen und zu prüfen, ob die frühere Anwendung ihren lokalen Zustand sicher lesen kann. Es sollte nicht bedeuten, dass Entwickler Apps zwischen Ordnern verschieben und der Support raten muss, welchen Build sie verwenden.

Apples deklarative App- und Paketverwaltung kann Pakete auf unterstützten überwachten Macs als erforderlich oder optional definieren. Die deklarative App-Verwaltung hat Vorrang vor einem überlappenden Installationsbefehl. Sende nicht zwei Verwaltungsmechanismen an dasselbe Ziel und hoffe, dass das Gerät die gewünschte Variante auswählt. Lege für jeden Ring die steuernde Methode fest und dokumentiere sie.

## Ein separater Tresor verändert Onboarding und Wiederherstellung

Ein Tresor pro Entwickler macht den ersten Start zu einem Sicherheitsritual und nicht zu einem Fehler in der Automatisierung. Der Benutzer muss entscheiden, welche Zugangsdaten auf diesen Mac gehören, und das Gerät muss bestätigen, dass der Benutzer sie entsperren kann.

Genau darum geht es. Das lokale Agent-Gateway kann eine Anfrage von Claude Code oder einem anderen MCP-fähigen Agenten empfangen. Der Agent sollte die Zugangsdaten jedoch niemals im Klartext oder als scheinbaren Platzhalter erhalten, den er später missbrauchen kann. Das Gateway sollte stattdessen die HTTP- oder SSH-Aktion ausführen und nur das Ergebnis zurückgeben.

Bei Sallyport ist die feste Entscheidungskette hilfreich, weil sie eine Richtliniensprache vermeidet, die jedes Team lernen und prüfen müsste. Ein gesperrter Tresor verweigert jede Aktion. Ein neuer Agent-Prozess erhält standardmäßig eine Sitzungsfreigabe, während eine für Einzelaufruf-Freigaben markierte Zugangsdaten bei jeder Verwendung nachfragt. Diese Kontrollen sind unterschiedlich. Schulen deine Entwickler deshalb darin, sie für unterschiedliche Situationen einzusetzen.

Verwende die Tresorsperre, wenn der Laptop unbeaufsichtigt ist oder der Entwickler seine Arbeit beendet hat. Nutze die Sitzungsfreigabe, um einen neu gestarteten Agent-Lauf zu identifizieren, bevor er größere Freiheiten erhält. Verwende die Einzelaufruf-Freigabe für Zugangsdaten, bei denen jede Nutzung menschliche Aufmerksamkeit verdient, etwa ein Produktionsverwaltungstoken oder eine sensible SSH-Identität.

Fordere Entwickler nicht auf, alle Zugangsdaten mit einer Einzelaufruf-Freigabe zu schützen, nur weil das sicherer wirkt. Wiederholte Abfragen führen dazu, dass Menschen automatisch freigeben, ohne zu lesen. Platziere die zusätzliche Hürde dort, wo eine falsche Anfrage erheblichen Schaden verursachen könnte, und belasse gewöhnliche Zugangsdaten für risikoarme Entwicklung unter der Sitzungsgrenze. Freigabeermüdung ist ein Designfehler, kein Beweis für ein sicherheitsbewusstes Team.

Auch die Wiederherstellung braucht klare Grenzen. IT kann die Gateway-App neu installieren und den verwalteten Startzustand reparieren. IT kann und sollte den Inhalt des Tresors eines Entwicklers nicht aus einem MDM-Eintrag wiederherstellen. Wird ein Mac ersetzt, sollte der Entwickler neue Zugangsdaten über das Quellsystem beziehen oder dem genehmigten Prozess der Organisation zur Migration von Zugangsdaten folgen. Das kann unbequem sein. Es ist trotzdem sicherer, als eine Flottenverwaltungsdatenbank als Backup-Tresor für Produktionstokens zu behandeln.

Dokumentiere vor der Bereitstellung die Zuständigkeiten:

| Ereignis | Entwickler | IT oder Endpoint-Team | Dienstverantwortlicher |
| --- | --- | --- | --- |
| Einrichtung eines neuen Macs | Entsperrt den Tresor und fügt autorisierte Zugangsdaten hinzu | Installiert App und Login-Konfiguration | Erteilt die anfängliche Berechtigung |
| Agent verhält sich unerwartet | Widerruft die Sitzung und sperrt den Tresor | Bestätigt Geräte- und App-Zustand | Widerruft die Zugangsdaten bei Bedarf |
| App-Update schlägt fehl | Meldet sichtbares Verhalten und Version | Repariert die Paketzuweisung oder führt ein Rollback durch | Normalerweise keine Aktion |
| Austausch des Geräts | Beschafft neue Zugangsdaten oder nutzt eine genehmigte Migration | Mustert den alten Mac aus und stellt den neuen bereit | Rotiert oder erteilt den Zugriff erneut |

Diese Tabelle verhindert den schlimmsten Supportanruf beim Rollout: Ein Entwickler sagt «Mein Agent hat den Zugriff verloren», der Endpoint-Support sagt «Die App ist installiert» und der Dienstverantwortliche nimmt an, jemand habe ein Geheimnis wiederhergestellt, das niemand jemals besitzen sollte.

## Inventar und Aktionsnachweise beantworten unterschiedliche Fragen

Das MDM-Inventar zeigt, ob die verwaltete Anwendung ein Gerät erreicht hat. Es kann nicht feststellen, was ein KI-Agent nach der Installation angefordert hat, welche Autorität die Aktion freigegeben hat oder welcher API-Aufruf ausgeführt wurde.

Halte diese Aufzeichnungen getrennt und verknüpfe sie bei Bedarf. Der MDM-Eintrag sollte Hardwareidentität, Verwaltungszustand, zugewiesene App-Version, Installationszeitpunkt und Entfernungsstatus liefern. Der Audit-Trail des Gateways sollte Sitzung, einzelne Aktion und Prüfergebnis enthalten. Wenn du beides in einer Tabelle zusammenführst, gibst du entweder dem Endpoint-Team zu viele betriebliche Details oder lässt den Ermittlern im Sicherheitsvorfall die benötigten Nachweise fehlen.

Sallyport erfasst Agent-Läufe in einem Sitzungsjournal und einzelne Aktionen in einem Aktivitätsjournal. Beide werden aus einem verschlüsselten, hashverketteten Audit-Log erzeugt. Der Befehl `sp audit verify` prüft die Kette offline über den Chiffretext und benötigt den Tresorschlüssel nicht. Ein Ermittler kann daher prüfen, ob der Datensatz verändert wurde, ohne die Geheimnisse des Benutzers zu öffnen.

Verwende für einen Vorfall oder eine Release-Prüfung ein einfaches Verfahren:

```sh
sp audit verify
```

Ein nützliches Ergebnis besteht aus einer eindeutigen Bestätigung oder einem Fehler und anschließend dem geprüften Bereich, zum Beispiel:

```text
Audit chain: valid
Records checked: 184
First record: 2026-07-01T14:22:09Z
Last record: 2026-07-22T09:15:44Z
```

Die genauen Felder hängen von der installierten Befehlsversion ab. Speichere daher die Rohfassung zusammen mit App-Version und Gerätekennung. Kopiere nicht den Inhalt des Tresors, den Prompt-Verlauf des Agenten oder einen unabhängigen Terminalverlauf eines Entwicklers, nur weil du ein Audit-Ergebnis sammelst.

Diese Trennung verbessert auch den alltäglichen Support. Zeigt die MDM-Konsole die erwartete Version, während der Entwickler meldet, dass eine Aktion abgelehnt wurde, prüfe den lokalen Zustand und den Freigabepfad des Gateways. Enthält der Audit-Eintrag eine Aktion, während MDM keinen aktuellen Installationseintrag hat, untersuche einen veralteten Geräteeintrag, einen kürzlich ausgemusterten Mac oder eine nicht verwaltete Installation. Jedes System hat eine begrenzte Aufgabe. Lass es diese Aufgabe gut erfüllen.

## Die Ausmusterung eines Geräts beginnt mit dem Zugriff, nicht mit dem Löschen

Wenn ein Mac den Besitzer wechselt, verloren geht oder das Unternehmen verlässt, beende zuerst seine Zugriffsbeziehung, bevor du ihn löschst oder aus dem Eigentum der Organisation entlässt. Das Löschen bereinigt die Festplatte. Es beweist nicht, dass Cloud-Zugangsdaten, aktive Agent-Sitzungen oder Gerätezuweisungen korrekt behandelt wurden.

Bei einer normalen Rückgabe im Unternehmen gehst du in dieser Reihenfolge vor:

1. Identifiziere das Gerät, den zuletzt zugewiesenen Benutzer, den MDM-Eintrag und die Frage, ob es noch Kontakt aufnimmt.
2. Widerrufe aktive Gateway-Sitzungen und lasse den Dienstverantwortlichen Zugangsdaten rotieren oder widerrufen, die andernorts noch verwendbar sein könnten.
3. Entferne die verwaltete Anwendung oder markiere sie zur Entfernung, falls der Mac lange genug online bleibt, um den Befehl zu empfangen.
4. Bewahre die nach deinen Aufbewahrungsregeln erforderlichen Verwaltungs- und Audit-Nachweise auf.
5. Lösche den Mac über den genehmigten Rückgabe- oder Neuzuweisungsprozess der Organisation.

Entlasse einen Mac nicht allein deshalb aus Apple Business Manager, weil ein Mitarbeiter das Unternehmen verlässt. Die Entlassung ist eine Eigentumsentscheidung für Hardware, die verkauft wurde, unwiederbringlich verloren ist oder nicht mehr unter deiner Kontrolle steht. Apple warnt, dass dieser Schritt über den üblichen Zuweisungsweg nicht rückgängig gemacht werden kann, eine künftige MDM-Zuweisung verhindert und nach der Entlassung ein Löschen und Wiederherstellen erfordert. Außerdem sollte ein zur Reparatur eingeschicktes Gerät nicht entlassen werden, weil ein Ersatzgerät möglicherweise nicht zu Apple Business Manager zurückkehrt.

Bei einem neu zugewiesenen Firmen-Mac behältst du die organisatorische Registrierung bei, löschst das Gerät und registrierst den nächsten Benutzer nach dem Standardprozess. Bei einem privat erworbenen Gerät unter einem Benutzerregistrierungsmodell entfernst du die Verwaltung nach der vereinbarten Richtlinie, bestätigst, welche verwalteten Apps und Einstellungen verschwinden, und lässt den Entwickler seine eigenen Zugangsdaten vor der Übergabe entfernen. Apple weist darauf hin, dass die Aufhebung der Registrierung bei benutzerregistrierten Geräten verwaltete Apps und Inhalte entfernen kann, während persönliche Apps und Einstellungen erhalten bleiben.

Ein verlorener Mac braucht einen schnelleren Ablauf. Widerrufe zuerst Zugangsdaten und Sitzungen, da das Gerät möglicherweise nie wieder online kommt. Nutze anschließend die Kontrollen deiner Geräteverwaltung und den Widerrufsprozess des Dienstverantwortlichen. Auf das Eintreffen eines Befehls zur App-Entfernung zu warten, ist keine Eindämmung.

## Der Rollout ist erfolgreich, wenn er langweilig bleibt

Der beste Rollout eines lokalen Gateways verursacht wenig Aufregung, weil jede Grenze klar ist. Das MDM-Team verteilt eine signierte App und verwaltet ihren Lebenszyklus. Der Entwickler bewahrt Zugangsdaten in einem lokalen Tresor auf und sieht, wann ein Agent eine Berechtigung anfordert. Der Dienstverantwortliche erteilt und widerruft Zugriff an der Quelle. Der Audit-Trail zeichnet Aktionen auf, ohne zu einer Sammlung von Geheimnissen zu werden.

Beginne mit dem Test, der die meisten falschen Annahmen aufdeckt: Registriere einen sauberen verwalteten Mac, melde dich als normaler Entwickler an, installiere das Produktionspaket über MDM, melde dich ab und wieder an, füge lokal eine unkritische Zugangsdaten hinzu, führe eine harmlose Agent-Aktion aus, prüfe den Audit-Eintrag, entferne anschließend die App und wiederhole den Ablauf mit einer frischen Registrierung. Wenn diese Sequenz undokumentierte Handarbeit, ein verstecktes Root-Skript oder eine kopierte Zugangsdaten-Datei benötigt, korrigiere den Rollout, bevor du hundert weitere Geräte hinzufügst.