macOS 27 App-Kontrolle: Apps auf verwalteten Macs sperren oder erlauben

Mit macOS 27 legen Sie fest, welche Apps auf Ihren verwalteten Macs laufen dürfen. Sie können einzelne Apps sperren oder nur die zulassen, die Sie ausgewählt haben.

Die Funktion ist neu von Apple und wurde auf der WWDC26 angekündigt. Appaloosa unterstützt sie ab dem ersten Tag von macOS 27. Dieser Artikel erklärt, wie sie funktioniert und wie Sie sie einrichten.

Was macOS 27 tatsächlich Neues bringt

Apples neue Deklaration heißt com.apple.configuration.app.settings. Auf dem Mac enthält sie zwei Schlüssel, um die es hier geht: AllowedBinaries und DeniedBinaries. Der eine sagt „nur diese dürfen laufen“, der andere „diese dürfen nie laufen“. Durchgesetzt wird das über das Endpoint Security Framework. Die Sperre greift also beim Ausführen und nicht bei der Installation.

Drei Dinge machen das besser als alles, was wir bisher hatten.

• Es ist deklarativ. Der Mac kennt die Regel und wendet sie selbst an, statt darauf zu warten, dass der Server einen Befehl schickt, der hoffentlich ankommt. Wenn das Modell neu für Sie ist: Unser Glossareintrag zu DDM erklärt die Mechanik.
• Abgeglichen wird die Signatur der App, nicht ein Name oder eine Bundle ID, die jeder ändern kann. Torrent.app in Notes.app umzubenennen bringt nichts.
• Die Sperre ist echt. Apps starten nicht mehr, und eine App, die beim Eintreffen der Regel schon läuft, wird beendet.

Die alte Payload, com.apple.applicationaccess.new, ist in macOS 27 als veraltet markiert. Auf älteren Systemen funktioniert sie vorerst weiter, aber Apple hat deutlich gemacht, wohin die Reise geht. Wer die vollständige Schlüsselreferenz braucht, findet sie in den WWDC26-Neuerungen zur App-Verwaltung im Apple Platform Deployment Guide.

Eine Abgrenzung ist hier wichtig: Das ist keine App-Bereitstellung. Diese Listen installieren nichts und entfernen nichts. Sie sagen macOS, was es starten darf, mehr nicht. Die Bereitstellung bleibt dort, wo sie immer war, nämlich im App-Katalog des Mobile Application Management.

Wie macOS eine App identifiziert

Beide Listen beschreiben eine App mit denselben fünf Feldern. Die ersten drei beantworten die Frage „welche App“. Die letzten beiden grenzen diese Antwort nur weiter ein, deshalb braucht jede Zeile mindestens eines der ersten drei. Ein Pfad allein identifiziert nichts.

Diese Werte lesen Sie mit codesign an einer echten Installation ab. Das Tool ist Teil von macOS:

$ codesign -dvvv /Applications/Firefox.app
...
Identifier=org.mozilla.firefox
...
TeamIdentifier=43AQ936H96
...
CDHash=bb880c62979ba21924f3599b660477436cabaa96

Identifier ist Ihre Signing ID, TeamIdentifier Ihre Team ID, CDHash Ihr CDHash. Die Authority-Zeilen verraten, woher die App stammt, und genau das drückt das Feld Signing state aus. Eine App mit der Signatur Developer ID Application entspricht DeveloperID, eine App aus dem App Store entspricht AppStore.

Zwei Fälle sorgen regelmäßig für Verwirrung. Apples eigene Apps melden TeamIdentifier=not set, codesign liefert Ihnen dort also nichts Brauchbares. Die Listen akzeptieren stattdessen den Literalwert *APPLE*, den Sie mit der Signing ID kombinieren: *APPLE* plus com.apple.iCal. Das übersteht Systemupdates, ein CDHash nicht.

Der andere Fall sind Webclips. Sie teilen sich alle eine Signing ID, com.apple.Safari.WebApp. Sperren Sie diese, öffnet sich auf dem Mac kein einziger Webclip mehr. Und wenn Sie eine Erlaubnisliste ohne sie betreiben, öffnen sich auch die Web-Apps nicht, die Sie über Appaloosa bereitstellen.

Eine Liste von Apps sperren

Das ist der Fall, den die meisten Teams wirklich brauchen. Fügen Sie in der Karte Blocked applications (gesperrte Apps) pro App, die Sie stoppen wollen, eine Zeile hinzu, tragen Sie mindestens eine Signing ID, eine Team ID oder einen CDHash ein und speichern Sie.

Eine gesperrte App startet nicht mehr. Alles, was Sie nicht aufgelistet haben, funktioniert genauso weiter wie vorher. Genau um diese Asymmetrie geht es: Sie nehmen drei Dinge weg, statt sechshundert zu erlauben.

Die Team ID ist meist die richtige Granularität. Eine gesperrte Signing ID trifft eine App. Eine gesperrte Team ID trifft alles, was dieser Anbieter ausliefert, auch das Hilfsprogramm, das er im nächsten Frühjahr umbenennt. Sperren Sie nur dann pro App, wenn der Rest des Anbieterkatalogs wirklich verfügbar bleiben soll.

Nur eine Liste zulassen

Die Karte Allowed applications (erlaubte Apps) arbeitet in die andere Richtung und ist deutlich strenger. Sobald sie eine einzige Zeile enthält, funktioniert keine App mehr, die nicht in der Liste steht. Safari. Mail. Systemeinstellungen. Für Apples Apps gibt es keinen Freifahrtschein.

Zeilen brauchen hier mindestens eine Team ID oder einen CDHash. Eine Signing ID allein akzeptiert macOS in dieser Liste nicht. Das überrascht viele, denn die Sperrkarte nimmt sie an.

Eine leere Karte bedeutet keine Einschränkung, nicht „nichts ist erlaubt“. Lassen Sie sie leer, solange Sie den Mac nicht wirklich auf einen bekannten Satz von Apps festlegen wollen.

Und falls eine App doch einmal in beiden Karten landet, gewinnt die Sperre. Sie läuft nicht, Erlaubnisliste hin oder her.

Ihre bereitgestellten Apps am Leben halten

Unter der Erlaubnisliste gibt es die Option Always allow applications deployed from Appaloosa in addition to the list above (von Appaloosa bereitgestellte Apps zusätzlich zur obigen Liste immer erlauben), die standardmäßig aktiv ist. Sie entspricht Apples Schlüssel AlwaysAllowManagedApps und erspart es Ihnen, jede verwaltete App von Hand aufzulisten. Schalten Sie sie nur aus, wenn der Mac ausschließlich das ausführen darf, was Sie eingetragen haben, und sonst nichts.

In Ihrer Konfiguration Default (Standard) trägt jede Zeile ein Vorhängeschloss. Wenn Sie eine Zeile sperren, wird sie in Ihre anderen macOS-Konfigurationen kopiert und lässt sich dort nicht mehr bearbeiten. Erbende Konfigurationen zeigen die Zeile an, können sie aber weder ändern noch löschen. So bekommen Sie eine einheitliche Baseline für die ganze Flotte, ohne sie pro Standort neu einzutippen.

Was der Benutzer sieht

Nichts, bis er etwas starten will, das er nicht starten soll. Dann zeigt macOS einen Hinweis an. Kein stiller Fehler, kein App-Symbol, das ohne Erklärung endlos im Dock hüpft.

Informieren Sie Ihren Helpdesk, bevor Sie das einschalten. Der Hinweis sagt, dass die App gesperrt ist. Er sagt nicht, wer sie gesperrt hat oder warum, und ein Benutzer, der die App gestern noch problemlos genutzt hat, macht ein Ticket auf. Eine kurze interne Mitteilung ist besser als drei Tage Verwirrung.

Fünf Fallen, die Sie kennen sollten

System-Apps haben Nebenwirkungen. Die meisten System-Binaries bleiben in jedem Fall erlaubt, aber die, die sich sperren lassen, können andere Funktionen mitreißen. Sperren Sie den App Store, können Ihre Benutzer auch die Bedingungen nicht mehr akzeptieren, die der Volumenkauf braucht. Das legt Ihre VPP-Verteilung stillschweigend lahm.

Apps aus Apple Business Manager brauchen trotzdem eine Starterlaubnis. Eine App über Apple Business Manager zu lizenzieren und zu installieren sagt nichts darüber aus, ob sie ausgeführt werden darf. Mit einer strikten Erlaubnisliste sind Lizenzieren und Erlauben zwei getrennte Entscheidungen.

Der CDHash ändert sich mit jedem Build. Er ist das präziseste Feld und zugleich das fragilste. Das nächste Chrome-Update bringt einen neuen CDHash mit, und Ihre Regel greift stillschweigend nicht mehr. Nutzen Sie ihn für ein internes Tool mit festgeschriebener Version, bei dem Sie genau dieses Verhalten wollen. Überall sonst nehmen Sie die Team ID.

Leer heißt nicht abgeriegelt. Wir wiederholen es, weil genau das den Anruf um 2 Uhr nachts auslöst: Eine leere Erlaubniskarte schränkt nichts ein.

Testen Sie nicht zuerst auf Ihrem eigenen Mac. Stecken Sie ein Ersatzgerät in eine Testkonfiguration. Eine strikte Erlaubnisliste, in der die Systemeinstellungen fehlen, kostet Sie einen ärgerlichen Nachmittag.

In Appaloosa ab dem ersten Tag verfügbar

Beide Karten finden Sie im Tab Applications (Apps) einer macOS-Konfiguration, neben Ihren übrigen Einstellungen für die Mac-Verwaltung. Sie setzen macOS 27 oder neuer voraus. Geräte, die noch auf macOS 26 laufen, ignorieren sie. Sie können also jetzt konfigurieren, und die Regel greift, sobald die Rechner aktualisiert werden.

Wenn Sie eine Zeile hinzufügen, bearbeiten oder entfernen, gehen die aktualisierten Listen an jedes Gerät der Konfiguration. Die Einrichtung im Detail und alle Felder der Reihe nach finden Sie im Support-Artikel zur Anwendungskontrolle für macOS-Geräte (auf Englisch).

Eines hat sich mit macOS 27 nicht geändert: iPhone und iPad verwenden für die entsprechenden Schlüssel Bundle IDs statt Signaturen. Die Regeln, die Sie für Macs schreiben, lassen sich also nicht übertragen. Wenn Sie beides verwalten, behandeln Sie es als getrennte Richtlinien. Unsere Seite zur Verwaltung von iOS und iPadOS deckt diesen Teil ab.

FAQ

Wird eine App vom Mac entfernt, wenn ich sie sperre?

Nein. Die App bleibt auf der Festplatte, sie startet nur nicht mehr. Diese Listen steuern die Ausführung, nicht die Installation. Software zu entfernen ist eine Bereitstellungsaktion und läuft getrennt davon.

Mein altes Profil für App-Einschränkungen funktioniert noch. Muss ich migrieren?

Heute nicht, aber planen Sie es ein. Das Profil com.apple.applicationaccess.new ist in macOS 27 veraltet. Veraltet heißt: Apple investiert nicht mehr darin und wird es irgendwann nicht mehr berücksichtigen. Übertragen Sie die Regeln, die Ihnen wichtig sind, also in die neuen Listen, solange Sie noch in Ruhe testen können.

Muss ich Apples Apps ausdrücklich erlauben?

Ja, wenn Sie die Erlaubnisliste nutzen. Safari, Mail und die Systemeinstellungen werden wie alles andere gesperrt, wenn sie fehlen. Fügen Sie sie mit der Team ID *APPLE* und der Signing ID der App hinzu, das passt auch nach Systemupdates weiter. Wie Apples Verwaltungsstack zusammenhängt, lesen Sie in unserem Glossareintrag zu macOS MDM.