Control de apps en macOS 27: bloquear o permitir apps en Mac gestionados

Con macOS 27 puede decidir qué apps tienen permiso para ejecutarse en sus Mac gestionados. Puede bloquear unas pocas o permitir solo las que usted elija.

Es una capacidad nueva de Apple, anunciada en la WWDC26. Appaloosa la admite desde el primer día de macOS 27. En este artículo le contamos cómo funciona y cómo configurarla.

Qué añade realmente macOS 27

La nueva declaración de Apple es com.apple.configuration.app.settings. En el Mac incluye dos claves que nos interesan aquí: AllowedBinaries y DeniedBinaries. Una dice "solo esto puede ejecutarse", la otra dice "esto no puede ejecutarse nunca". La aplicación de la regla pasa por el framework Endpoint Security, así que el bloqueo llega en el momento de la ejecución y no en el de la instalación.

Hay tres cosas que lo hacen mejor que lo que teníamos antes.

• Es declarativo. El Mac guarda la regla y la aplica por su cuenta, en lugar de esperar a que el servidor envíe un comando y confiar en que llegue. Si ese modelo le resulta nuevo, nuestra entrada del glosario sobre DDM explica la mecánica.
• La coincidencia se hace con la firma de la app, no con un nombre o un bundle ID que cualquiera puede editar. Renombrar Torrent.app como Notes.app no sirve de nada.
• Bloquea de verdad. Las apps dejan de abrirse, y una app que ya estaba en ejecución cuando llega la regla se cierra.

El payload antiguo, com.apple.applicationaccess.new, queda obsoleto en macOS 27. De momento sigue funcionando en sistemas anteriores, pero Apple ya ha dejado claro hacia dónde va esto. Si quiere la referencia completa de las claves, lea las novedades de gestión de apps de la WWDC26 en la guía Apple Platform Deployment.

Conviene ser preciso con el alcance: esto no es despliegue de apps. Estas listas no instalan ni eliminan nada. Le dicen a macOS qué puede abrir, y nada más. El despliegue sigue donde siempre ha estado, en el catálogo de apps, del lado del mobile application management.

Cómo identifica macOS una app

Las dos listas describen una app con los mismos cinco campos. Los tres primeros responden a "qué app". Los dos últimos solo acotan esa respuesta, y por eso cada fila necesita al menos uno de los tres primeros. Una ruta por sí sola no identifica nada.

Estos valores se leen de una instalación real con codesign, que viene incluido en macOS:

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

Identifier es su Signing ID, TeamIdentifier es su Team ID y CDHash es su CDHash. Las líneas Authority le indican de dónde viene la app, que es lo que expresa el campo Signing state. Una app firmada con Developer ID Application corresponde a DeveloperID, una app del App Store corresponde a AppStore.

Hay dos casos en los que la gente tropieza. Las apps de Apple devuelven TeamIdentifier=not set, así que ahí codesign no le da nada aprovechable. Las listas aceptan en su lugar el valor literal *APPLE*, y se combina con el Signing ID: *APPLE* más com.apple.iCal. Sobrevive a las actualizaciones del sistema, cosa que un CDHash no hace.

El otro caso son los web clips. Todos comparten un mismo Signing ID, com.apple.Safari.WebApp. Si lo bloquea, ningún web clip del Mac volverá a abrirse. Y si usa una lista de permitidas sin incluirlo, las webapps que despliega desde Appaloosa tampoco se abrirán.

Bloquear una lista de apps

Es el caso que de verdad necesita la mayoría de los equipos. En la tarjeta Blocked applications (aplicaciones bloqueadas), añada una fila por cada app que quiera frenar, rellene al menos un Signing ID, un Team ID o un CDHash, y guarde.

Una app bloqueada deja de abrirse. Todo lo que no ha puesto en la lista sigue funcionando exactamente igual que antes. Esa asimetría es justo la gracia: quita tres cosas, no concede seiscientas.

El Team ID suele ser la granularidad adecuada. Bloquear un Signing ID tumba una app; bloquear el Team ID tumba todo lo que publica ese proveedor, incluido el helper al que le cambiarán el nombre la próxima primavera. Vaya app por app solo cuando de verdad quiera que el resto del catálogo del proveedor siga disponible.

Permitir solo una lista

La tarjeta Allowed applications (aplicaciones permitidas) va en sentido contrario y es mucho más estricta. En cuanto contiene una sola fila, todas las apps que no están en la lista dejan de funcionar. Safari. Mail. Ajustes del Sistema. Las apps de Apple no tienen trato de favor.

Aquí las filas necesitan al menos un Team ID o un CDHash. macOS no acepta un Signing ID por sí solo en esta lista, y eso pilla desprevenida a mucha gente porque la tarjeta de bloqueadas sí lo acepta.

Una tarjeta vacía significa que no hay restricción, no que "no se permite nada". Déjela vacía salvo que de verdad quiera fijar el Mac a un conjunto conocido de apps.

Y si una app acaba por lo que sea en las dos tarjetas, gana el bloqueo. No se ejecutará, con lista de permitidas o sin ella.

Mantener vivas las apps que despliega

Debajo de la lista de permitidas hay una opción, Always allow applications deployed from Appaloosa in addition to the list above (permitir siempre las aplicaciones desplegadas desde Appaloosa además de la lista anterior), activada por defecto. Corresponde a la clave AlwaysAllowManagedApps de Apple y le ahorra listar a mano cada app gestionada. Desactívela solo cuando el Mac deba ejecutar estrictamente lo que ha escrito y nada más.

En su configuración Default (la configuración por defecto) cada fila lleva un candado. Al bloquear una fila con el candado, se copia a sus otras configuraciones de macOS y estas ya no pueden editarla. Las configuraciones que la heredan muestran la fila, pero no pueden cambiarla ni borrarla. Así consigue una base común para toda la flota sin volver a teclearla en cada sede.

Qué ve el usuario

Nada, hasta que intenta abrir algo que no debería. Entonces macOS muestra una alerta. No hay fallo silencioso, ni un icono rebotando eternamente en el Dock sin explicación.

Avise a su equipo de soporte antes de activar esto. La alerta dice que la app está bloqueada, pero no dice quién la ha bloqueado ni por qué, y un usuario que ayer usaba esa app tan tranquilo va a abrir un ticket. Una nota interna breve es mejor que tres días de confusión.

Cinco trampas que conviene conocer

Las apps del sistema tienen efectos secundarios. La mayoría de los binarios del sistema siguen permitidos pase lo que pase, pero los que sí puede bloquear pueden llevarse otras funciones por delante. Bloquee el App Store y sus usuarios pierden también la posibilidad de aceptar los términos que exigen las compras por volumen, lo que rompe sin hacer ruido su distribución VPP.

Las apps de Apple Business Manager también necesitan permiso para abrirse. Asignar la licencia de una app mediante Apple Business Manager e instalarla no dice nada sobre si puede ejecutarse. Si usa una lista de permitidas estricta, licenciar y permitir son dos decisiones distintas.

El CDHash cambia con cada compilación. Es el campo más preciso y también el más frágil. La próxima actualización de Chrome trae un CDHash nuevo y su regla deja de coincidir sin avisar. Úselo para una herramienta interna con versión fijada, donde ese es el comportamiento que busca. Para todo lo demás, Team ID.

Vacío no significa bloqueado. Lo repito porque es lo que provoca la llamada a las 2 de la madrugada: una tarjeta de permitidas vacía no restringe nada.

No pruebe primero en su propio Mac. Ponga un equipo de sobra en una configuración de pruebas. Una lista de permitidas estricta que se olvidó de Ajustes del Sistema es una tarde bastante molesta.

Disponible en Appaloosa desde el primer día

Las dos tarjetas están en la pestaña Applications (aplicaciones) de una configuración de macOS, junto al resto de sus ajustes de gestión de Mac. Requieren macOS 27 o posterior. Los dispositivos que siguen en macOS 26 las ignoran, así que puede configurarlas ya y dejar que la regla entre en vigor a medida que los equipos se actualicen.

Al añadir, editar o eliminar una fila, las listas actualizadas se envían a todos los dispositivos de la configuración. Los detalles de configuración y el recorrido campo por campo están en el artículo de soporte sobre el control de aplicaciones en dispositivos macOS (en inglés).

Algo que no ha cambiado con macOS 27: iPhone y iPad usan bundle IDs en lugar de firmas para las claves equivalentes, así que las reglas que escribe para los Mac no se pueden trasladar. Si gestiona ambos, trátelos como políticas separadas. Nuestra página de gestión de iOS y iPadOS cubre esa parte.

FAQ

¿Bloquear una app la elimina del Mac?

No. La app se queda en el disco, simplemente no se abre. Estas listas controlan la ejecución, no la instalación. Eliminar software es una acción de despliegue y se gestiona aparte.

Mi antiguo perfil de restricción de apps sigue funcionando. ¿Tengo que migrar?

Hoy no, pero vaya planificándolo. El perfil com.apple.applicationaccess.new queda obsoleto en macOS 27. Obsoleto significa que Apple ha dejado de invertir en él y que tarde o temprano dejará de respetarlo, así que pase las reglas que le importan a las nuevas listas mientras todavía puede permitirse probar con calma.

¿Tengo que permitir explícitamente las apps de Apple?

Sí, si usa la lista de permitidas. Safari, Mail y Ajustes del Sistema se bloquean como cualquier otra app cuando no están en ella. Añádalas con el Team ID *APPLE* y el Signing ID de la app, que sigue coincidiendo tras las actualizaciones del sistema. Para entender cómo encajan las piezas de la gestión de Apple, consulte nuestra entrada del glosario sobre MDM para macOS.