Всем привет, это команда Ринго! Уже не первый год Apple публикует Deployment Guide — руководство для системных администраторов, охватывающее развертывание, настройку и управление техникой Apple. После каждой WWDC в нём появляется раздел «Что нового?», и в этом году основная повестка не про новые возможности, а про потери. В macOS 27 перестанут работать привычные MDM-команды управления обновлениями.
Разбираем ключевые изменения из What’s New for IT at WWDC26: что приходит на смену старым командам, какие декларации появились для сетевых настроек и статусов устройств и что следует проверить в инфраструктуре до массового обновления парка. Сервисы, официально недоступные для организаций, зарегистрированных в России (Apple Business Manager, Volume Purchase Program и другие), мы намеренно оставляем за скобками — говорим только про управление macOS 27.
Обновления в управлении устройствами (Device Management Updates)
Удаление MDM-команд для обновления macOS (Software Update Command Removal)
Apple разместила эту информацию в конце страницы, но, на наш взгляд, именно она заслуживает первого места, поскольку является критически важной для системных администраторов.
В macOS 27.0 перестанут работать привычные MDM-команды для управления обновлениями, если Apple не изменит свое решение:
Software Update Commands (принудительный запуск скачивания или установки ОС)
Software Update Queries (опрос компьютеров и сбор данных о доступных обновлениях)
Recommended Cadence Settings (настройка частоты автоматических проверок)
Software Update Restrictions (Deferrals и Background Security Improvements - возможность временно скрывать релизы от пользователей на срок до 90 дней)
На смену им окончательно приходит декларативное управление устройствами, и Маки на базе macOS 27.0 попросту проигнорируют старые команды. Теперь MDM-сервер один раз передает декларацию (желаемое состояние), а Mac сам планирует скачивание и установку.
Про то, как устроено управление обновлениями сегодня и какие сценарии отсрочки остаются в распоряжении администратора, мы подробно писали в отдельной статье.
Сетевые настройки (Network Configurations)
При переходе на DDM-рельсы Apple использует новые типы конфигураций. Архитектурно структура настроек разделяется на логическую часть (конфигурация) и ресурсную часть (ассеты).
Configuration-декларация описывает общие системные правила и архитектуру сети. Например: тип туннеля VPN (IKEv2 или IPsec), адреса шлюзов или правила маршрутизации трафика. Она остается статичной для группы устройств.
Asset-декларация хранит динамические или чувствительные данные, необходимые для работы конфигурации. Например: цифровые сертификаты безопасности или пароли пользователей.
Таким образом одна общая конфигурация сети на сервере MDM может ссылаться на разные персональные ассеты пользователей. При плановом обновлении SSL/TLS-сертификатов ИТ-администратору достаточно перезаписать только ассет, не затрагивая сетевую конфигурацию.
Ротация сертификата затрагивает только asset-декларацию
VPN Plugin
com.apple.configuration.network.vpn.vpn-plugin
Корпоративные VPN-клиенты подключаются к macOS двумя разными способами, и это различие важно понимать до того, как вы начнёте собирать декларацию.
Первый способ — классический: вендор поставляет системный VPN-плагин, а профиль просто указывает, какой именно плагин обслуживает это подключение. В старом payload com.apple.vpn.managed за это отвечал параметр VPNSubType, куда подставлялся идентификатор плагина. Отсюда и знакомые многим строки:
Cisco AnyConnect —
com.cisco.anyconnect.applevpn.pluginJuniper SSL —
net.juniper.sslvpn
Второй способ — современный: клиент представляет собой обычное приложение, которое устанавливает Network Extension (как правило, Packet Tunnel Provider). Системного плагина в этом случае нет, и в декларации указывается bundle identifier самого приложения, а не плагина. Перепутать эти две сущности легко, а результат один — туннель не поднимется.
Проверить идентификатор приложения можно локально:
defaults read /Applications/VPNClient.app/Contents/Info CFBundleIdentifier
Раньше сторонний VPN доставлялся на Mac конфигурационным профилем. То есть по старому каналу управления, со всеми его особенностями: профиль либо установился, либо нет, а разбираться приходилось постфактум. Теперь VPN описывается декларацией, устройство само сообщает о статусе применения, а чувствительные части (сертификаты, реквизиты) выносятся в отдельные asset-декларации и обновляются независимо.
Документация
Другие новые декларации
Apple переносит на DDM-рельсы практически весь сетевой стек, который раньше жил в профилях. Коротко о том, что за чем стоит.
com.apple.configuration.network.ikev2 — VPN IKEv2
Штатный протокол, который macOS, iOS и iPadOS поддерживают без стороннего клиента. Аутентификация по сертификатам или EAP, стабильная работа при переключении между Wi-Fi и сотовой сетью. Если у вас есть выбор, с чего начинать миграцию на декларации, начинайте отсюда: не нужно ни приложения, ни плагина, всё нативное.
com.apple.configuration.network.ipsec — VPN IPsec
Вторая ветка встроенной поддержки, исторически используется для подключения к шлюзам, работающим по схеме Cisco IPsec. Актуально там, где на периметре стоит оборудование, не поддерживающее IKEv2.
com.apple.configuration.network.always — Always On VPN
Always On VPN — режим, в котором весь IP-трафик устройства направляется через корпоративный туннель. В рамках новых DDM-конфигураций WWDC26 эта декларация не поддерживается на macOS 27. Apple указывает её только для iOS, iPadOS и visionOS.
com.apple.configuration.network.dns-proxy — DNS Proxy Network Extension
Перенаправляет все DNS-запросы устройства в приложение-провайдер, которое дальше решает, что с ними делать: фильтровать, логировать, отправлять на корпоративный резолвер. Нужен, когда DNS-фильтрация реализована сторонним решением с собственным агентом.
com.apple.configuration.network.dns-settings — Encrypted DNS
Настройка зашифрованного DNS: DNS over HTTPS или DNS over TLS. Позволяет жёстко закрепить за системой конкретный корпоративный резолвер и закрыть популярный способ обхода фильтрации — «поставлю себе публичный DoH, и никто не заметит». Здесь же задаётся, на каких сетях правило применяется, а на каких нет.
com.apple.configuration.network.relay — Network Relay
Механизм доступа к внутренним ресурсам без поднятия полноценного туннеля: устройство ходит к нужным доменам через relay-сервер, остальной трафик идёт напрямую. По идеологии это ближе к zero trust, чем к традиционному VPN, и заметно комфортнее для пользователя — нет состояния «включён/выключен». Требует поддержки со стороны вашего вендора.
Сетевые настройки — самая «живая» часть конфигурации: сертификаты ротируются, шлюзы меняются, резолверы переезжают. Пока всё это лежало в монолитных профилях, любое изменение означало переустановку профиля целиком. Разделение на конфигурацию и ассеты убирает эту зависимость.
Распространение legacy-профилей MDM с помощью деклараций (Configuration Profiles as Declarative Assets)
Переход на DDM у большинства организаций растянется на годы: часть настроек в декларациях просто ещё не существует, часть завязана на исторические payload’ы, которые никто не переписывал. Держать при этом два параллельных канала управления — профили отдельно, декларации отдельно — неудобно и плохо диагностируется.
Apple предлагает компромисс: конфигурационный профиль оборачивается в декларацию. Появляются два новых типа:
com.apple.configuration.legacycom.apple.configuration.legacy.interactive— вариант для профилей, установка которых требует участия пользователя
Сам профиль при этом не передаётся вместе с декларацией: в ней указывается URL, по которому устройство скачает .mobileconfig в момент активации.
Что это меняет на практике
Во-первых, профиль перестаёт быть «выстрелом вслепую». Декларация — это желаемое состояние, и устройство отчитывается о том, применено оно или нет, через status channel. Вы видите не «команда отправлена», а «настройка на устройстве есть».
Во-вторых, обновление профиля становится вопросом замены файла на веб-сервере, а не рассылки новой команды на весь парк.
В-третьих, появляется новая точка отказа, о которой стоит подумать заранее: URL должен быть доступен с устройства. Для парков в закрытом контуре это означает, что раздающий веб-сервер должен жить внутри периметра, и его сертификат должен удовлетворять требованиям Apple к TLS-соединениям, а требования эти как раз ужесточаются, о чём следующий раздел.
Документация
LegacyProfile | Apple Developer
Повышенные требования к сетевой безопасности (Increased Network Security Requirements)
В macOS 27 Apple повышает требования к TLS для ряда системных процессов, связанных с управлением устройствоми. Обновляются:
минимальная версия протокола — TLS 1.2;
требования к сертификатам;
требования к используемым алгоритмам шифрования.
Формулировка звучит буднично, но за ней стоит вполне конкретный риск. Если ваш внутренний сервис не проходит по новым требованиям, устройство не установит соединение — и никакой настройкой на стороне MDM это не лечится.
Список не исчерпывающий: проверяйте всё, к чему Mac обращается по HTTPS
Что стоит проверить до массового обновления парка:
Сервер MDM и все его вспомогательные сервисы. Если MDM недоступен, вы теряете не одну функцию, а управление устройством целиком.
Внутренние удостоверяющие центры. Самоподписанные сертификаты, выпущенные «как получилось» много лет назад, — главный кандидат на отказ в соединении. Смотрите на алгоритм подписи, длину ключа, наличие SAN и срок действия.
Средства инспекции трафика. SSL-инспекция на периметре подменяет сертификат своим, и требования применяются уже к нему.
Прочие сетевые устройства с веб-интерфейсами и API, к которым обращаются Mac: принт-серверы, NAS, системы печати, старые аппаратные решения, которые обновлялись последний раз при прошлом сисадмине.
Проверить конкретный хост можно прямо с Mac:
openssl s_client -connect mdm.example.local:443 -tls1_2
Для диагностики с точки зрения App Transport Security пригодится встроенная утилита:
nscurl --ats-diagnostics https://mdm.example.local
Она проверяет соединение по нескольким наборам требований и показывает, какие из них проходят, а какие нет.
Этот раздел стоит показать не только коллегам по инфраструктуре, но и вашему поставщику MDM, и специалистам по информационной безопасности — правки могут понадобиться с нескольких сторон одновременно.
Документация
Расширение возможностей DDM Status Channel (Status Reporting Enhancements)
Status channel — вторая половина декларативного управления, о которой вспоминают реже, чем о самих декларациях. Смысл в том, что устройство не ждёт опроса со стороны сервера, а само сообщает об изменении своего состояния: подписались на нужные статусы один раз — дальше получаете обновления по факту событий. Для парка в сотни устройств это разница между «опросить всех и подождать» и «узнать сразу».
Показаны три из новых групп статусов, полный список шире
Тип регистрации и состояние устройства (Enrollment and Device Health)
Тип регистрации
mdm.enrollment-type — как именно устройство зарегистрировано в MDM:
Supervised— supervised-регистрация;Device— Device Enrollment;User Enrollment— пользовательская регистрация.
От типа регистрации напрямую зависит, какие команды и ограничения вообще применимы к устройству. Раньше это приходилось выяснять косвенно, из истории регистрации на стороне сервера. Теперь тип можно получить от самого устройства — удобно и для инвентаризации, и для разбора ситуаций в духе «почему на этом Mac ограничение не сработало».
Новые статусы
mdm.is-awaiting-configuration — устройство находится на этапе Setup Assistant (Ассистент настройки) в рамках DEP. Полезно, чтобы понимать, что настройка ещё не завершена и часть операций выполнять рано.
mdm.is-return-to-service — устройство находится в режиме Return to Service, то есть проходит подготовку к передаче следующему пользователю. Документация: Use Return to Service for Apple devices
mdm.is-shared-ipad — является ли iPad устройством общего доступа.
mdm.push-magic и mdm.push-token — данные APNs, по которым сервер «будит» устройство. Это диагностический статус. Если Mac перестал реагировать на команды, вопрос почти всегда в push-канале, и теперь его параметры можно сверить, не заглядывая в логи устройства руками.
device.system.health (только iPhone и iPad) — результат проверки аппаратных компонентов: Baseband, Camera, Face ID, Touch ID, NFC, Ultra-Wideband.
Последний статус выглядит скромно, но закрывает реальную боль. При ротации устройств между сотрудниками или после ремонта в стороннем сервисе никто не проверяет вручную, работает ли на возвращённом iPhone NFC. Теперь состояние компонентов поступает в консоль автоматически.
Если же нужно разобраться, что происходит с применением деклараций на стороне самого устройства, поможет унифицированное логирование: подсистема com.apple.ManagedClient и фильтрация предикатами разобраны в нашем руководстве по команде log.
Lockdown Mode
Новый статус
security.lockdown-mode — включён ли на устройстве режим Lockdown Mode (Режим блокировки).
Это тот случай, когда один статус экономит часы разбирательств. Lockdown Mode — режим для пользователей с повышенным риском целевых атак, и он намеренно отключает часть системной функциональности, включая работу с конфигурационными профилями. Если пользователь включил его самостоятельно, устройство внешне исправно, но перестаёт принимать настройки, и админ ищет проблему где угодно, только не там. Видимый статус превращает загадку в строчку в консоли.
Документация
About Lockdown Mode — Apple Support
Настройка фильтрации веб-контента через DDM (Web Content Filter Plugin Configuration)
Новая декларация
com.apple.configuration.webcontent-filter.plugin
Фильтрация веб-контента на платформах Apple бывает двух видов. Встроенный фильтр умеет ограничивать доступ к сайтам для взрослых и работать по спискам разрешённых адресов — этого хватает для простых сценариев. Всё, что сложнее (категории, отчётность, интеграция с корпоративными политиками), реализуется сторонним решением, которое ставит в систему Network Extension типа content filter и разбирает трафик самостоятельно.
Раньше такой фильтр настраивался payload’ом com.apple.webcontent-filter в конфигурационном профиле. Теперь появляется декларация, то есть фильтр встаёт в тот же ряд, что и остальные сетевые настройки: желаемое состояние описывается один раз, устройство отчитывается о применении.
Кому это в первую очередь пригодится: образовательным учреждениям и EdTech-проектам, где ограничения на доступ к контенту не пожелание, а требование; организациям с регуляторными обязательствами по фильтрации; всем, кто использует устройства в режиме киоска или в общем доступе.
Документация
О чём ещё стоит почитать самостоятельно
В заметку не вошли разделы, которые либо касаются недоступных в России сервисов, либо тянут на отдельный материал. Оставляем их со ссылками и коротким пояснением, о чём речь:
Apple Services Updates — изменения в сервисах Apple для организаций. Ссылка
AppleCare Log Collection — сбор диагностических логов с устройства для обращений в поддержку Apple. Ссылка
Backup Restoration — после восстановления устройства из резервной копии информация о регистрации в MDM не восстанавливается. Момент, который стоит учитывать в инструкциях для пользователей.
Return to Service Enhancements — доработки процедуры подготовки устройства к передаче следующему пользователю. Ссылка
Content Caching Configuration — настройка службы кэширования контента, которая экономит внешний канал при массовых обновлениях. Ссылка
New / Additional visionOS Restrictions — новые ограничения для visionOS. Ссылка
Intelligence, Siri and Keyboard Management — управление функциями Apple Intelligence, Siri и клавиатурного ввода. Ссылка
File Provider Management — управление сторонними провайдерами файлов (облачные хранилища, интегрированные в Finder). Ссылка
Managed Migration Assistant — управляемый перенос данных на новое устройство. Ссылка
Что в итоге
Год назад, разбирая итоги WWDC 2025, мы писали, что Apple продвигает Declarative Device Management. В 2026-м это перестало быть направлением развития и стало условием работы: старые команды управления обновлениями просто перестанут отвечать, а сетевые настройки, legacy-профили и фильтрация контента переезжают на декларации.
Практический план на ближайшие месяцы выглядит так: проверить, как ваш поставщик MDM готовится к отказу от Software Update Commands; провести аудит внутренних сервисов на соответствие новым требованиям к TLS; посмотреть, какие из новых статусов имеет смысл завести в мониторинг. Первые два пункта лучше не откладывать до осеннего релиза.
Мы со своей стороны продолжаем расширять поддержку Declarative Device Management в Ринго с учётом особенностей использования устройств Apple в нашей стране.
Приглашаем на конференцию СисАдмин 2026
9 октября в московском кластере «Ломоносов» про йдет СисАдмин 2026 — конференция для системных администраторов, ИТ‑менеджеров и специалистов по поддержке инфраструктуры.
Участие бесплатное, нужно только зарегистрироваться.
Если вам есть чем поделиться с коллегами, то выступить можно бесплатно. Для этого нужно отправить заявку на доклад через форму на сайте.
