Привет! Я Ильдар Бигашев, Product Owner Ринго.
В рамках WWDC 2026, а если быть точнее, то в ролике What’s new in managing Apple devices, инженер Device Management team, Cyrus Daboo, заявляет о том, что "Declarative Device Management уже здесь" и используется в продакшене для управления парками корпоративных устройств Apple по всему миру.
Что касается классического MDM, то ранее компания Apple уже обозначала некоторые команды MDM как Deprecated, например, ScheduleOSUpdate, которая отвечает за установку обновлений macOS. Информацию об этой команде уже не найти на сайте Apple Developer | Device Management , но она все еще присутствует в репозитории Device management schema data for MDM на Github Apple. В следующей macOS 27 Golden Gate эта команда точно не будет работать, и без функционала DDM установить обновления "тихо и незаметно" не получится. В системе пока еще присутствует терминальная команда softwareupdate, но там есть нюансы, о которых можно прочитать в одной из статей, опубликованной в корпоративном блоге Ринго на Хабре.
В этой статье мы попытаемся разобраться, что такое DDM, его преимуществах перед MDM и почему переход на DDM – это вопрос времени.
Первое упоминание о DDM
Впервые Apple рассказала о DDM как новом подходе к управлению своими устройствами на WWDC 2021, но, как это часто бывает с новыми технологиями, внедряемыми яблочной компанией (вспомним тот же Secure Token), документации было немного, а потестировать было не на чем, так как вендоры MDM- и UEM-решений еще не внедрили этот функционал в свои продукты.
В чем заключаются преимущества DDM?
Если кратко, то можно обозначить следующие тезисы:
DDM позволяет избежать проблем, которые могут возникнуть при работе с профилями MDM (файлы XML с расширением .mobileconfig);
DDM добавляет новые возможности для управления устройствами Apple или совершенствует старые;
DDM снижает нагрузку на серверы MDM.
Проблемы с профилями MDM и улучшения DDM
Основная проблема связана с тем, что профиль будет установлен только будучи доставленным на управляемое устройств. Соответственно, если профиль не был доставлен по какой-либо причине, или уже в процессе установки профиля, который требует связи с сервером MDM, возникли проблемы с сетевым доступом, то такой профиль установлен не будет и его потребуется отправить на устройство повторно, что не заложено в протокол MDM "из коробки".
Также логика работы профилей зачастую приводит к так называемому "user friction", и применение некоторых критических конфигураций может пойти не по плану. Например, legacy-политика паролей, доставленная через профиль MDM, может предложить пользователям обновить пароль, но позволяет им отклонить этот запрос, оставляя устройство не соответствующим требованиям. Таким образом, отсутствие принудительного применения обновлений программного обеспечения является одной из причин существования таких инструментов, как Nudge, которые создают дополнительное давление на пользователей, чтобы те устанавливали обновления и соблюдали политики.
Эта несогласованность связана с тем, как именно macOS обрабатывает профили MDM, а не с тем, как работает ваше MDM-решение. Вендор тут ни при чем.
DDM решает эти проблемы, применяя конфигурации на системном уровне, обеспечивая соответствие без необходимости многократной отправки команд с сервера. Конкретный пример того, как DDM обрабатывает политики паролей, можно будет увидеть далее в этой статье.
Нагрузка на ваши серверы MDM
DDM далеко не всесилен: новый функционал добавляется Apple постепенно, а старый удаляется, но это определенно шаг вперед в управлении парком корпоративных устройств. DDM использует конфигурации, которые применяются на устройствах автономно и не требуют постоянного контроля со стороны сервера MDM. Если у устройства изменяется статус, то оно само свяжется с сервером MDM и передаст всю необходимую дельту. Какая именно информация передается серверу, можно посмотреть здесь.
Что из себя представляют конфигурации DDM в общих словах?
В основе DDM лежат декларации — файлы конфигураций, описывающие желаемое состояние устройства. В отличие от профилей MDM, файлов XML с расширением .mobileconfig, в формате Property List, профили DDM используют формат JSON. Переход к JSON соответствует современным стандартам данных, делая профили DDM более универсальными и простыми для интеграции в существующие рабочие процессы.
Ключевые различия между конфигурациями MDM и DDM заключаются в том, что профили MDM придерживаются статической модели: они определяют настройки и полагаются на сервер MDM для их применения на устройствах. Если что-то меняется с точки зрения конфигурации, то серверу необходимо снова отправить обновленную конфигурацию.
Конфигурации DDM, с другой стороны, используют так называемый декларативный подход, вот что это значит:
возможность применить конфигурацию автономно, без связи с сервером MDM;
устройства самостоятельно проверяют Compliance и отчитываются об этом серверу MDM без опроса со стороны последнего;
более современный подход к передаче данных: в формате JSON вместо XML.
Основные концепты DDM
Status Channel
Declarations
Status Channel
Для включения DDM требуется отправить на устройство специальную команду. При успешной обработке команды на устройстве включается функционал DDM без возможности отключения. Status — это то, что отправляет устройство на сервер для предоставления данных об устройстве. Это может быть:
общая информация об устройстве (UDID, версия OS, статус FileVault);
версия клиента DDM и поддерживаемые типы Features и Declarations;
статус установленных Declarations.
Данные о Status могут быть присланы полностью или по частям в рамках нескольких запросов. Отправка статуса устройством может быть запрошена сервером через команду MDM или отправлена устройством самостоятельно, при изменении данных на устройстве.
Declarations
Declarations — это "состояние", к которому сервер пытается привести устройство. Работает примерно также, как и с профилями MDM, но с некоторыми улучшениями. У каждой декларации есть тип (например, "com.apple.configuration.passcode.settings"), идентификатор и токен. Declarations делятся на несколько типов.
Configuration
Основная declaration (декларация), которая может содержать настройки для устройства, требования к паролям, настройки обновления OS, установку приложений и т.д.
Пример декларации настройки паролей:
{
"Type": "com.apple.configuration.passcode.settings",
"Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
"ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
"Payload": {
"RequireComplexPasscode": true,
"MinimumLength": 10,
"MinimumComplexCharacters": 1,
"MaximumFailedAttempts": 11,
"MaximumGracePeriodInMinutes": 1,
"MaximumInactivityInMinutes": 15
}
}
Политики паролей служат отличным примером различий между профилями MDM и декларациями DDM. В случае с профилями MDM применение политики паролей зависит от сервера MDM, который отправляет настройки на устройства в файлах .mobileconfig. Однако пользователи могут просто закрыть запрос на смену пароля, оставляя устройства не соответствующими требованиям. Это ограничение связано с тем, как macOS обрабатывает профили.
В DDM настройки паролей применяются на уровне системы. Устройства автономно применяют требуемые конфигурации и сообщают о своем статусе обратно в MDM. Настройки в DDM включают:
RequirePasscode: требует от пользователей установить пароль на устройстве;
RequireComplexPasscode: требует использования сложных паролей без повторяющихся или последовательных символов (например, "123" или "ABC") и содержащих как минимум один небуквенно-цифровой символ;
MinimumLength: определяет минимальное количество символов в пароле;
MaximumFailedAttempts: ограничивает количество неудачных попыток входа до блокировки устройства;
MaximumGracePeriodInMinutes: контролирует, как долго пользователи могут ждать, прежде чем устройство заблокируется после пробуждения;
MaximumInactivityInMinutes: блокирует устройство после периода бездействия.
Например, использование опции RequireComplexPasscode избавляет администраторов от необходимости задавать сложные регулярные выражения для проверки пароля. Эта встроенная функция экономит время и обеспечивает соответствие на всех устройствах.
Кстати, с помощью Configuration-декларации можно устанавливать профили и MDM. Это работает следующим образом: на устройство отправляется конфигурация, и в момент ее активации профиль будет загружаться по URL и устанавливаться на устройство.
https://github.com/apple/device-management/blob/release/declarative/declarations/configurations/legacy.yaml.
https://support.apple.com/en-ca/guide/deployment/device-management-updates-depd638aa061/1/web/1.0#dep823b439a0
Assets
Представляют собой вспомогательные данные, необходимые для конфигураций. Существует два основных варианта использования ресурсов:
большие объёмы данных: крупный элемент данных, например: изображение, шрифт;
личные данные: специфичная информация о пользователе, например, имя, адрес электронной почты, пароли для учётных записей или сертификаты.
Определенные типы Configuration-деклараций предоставляют возможность связать Asset-декларацию через идентификатор Asset-декларации. Одна Asset-декларация может использоваться во многих конфигурациях. Asset-декларация должна содержать поле HTTPS URL, по которому устройство сможет скачать данные Asset, а также данные аутентификации и метаданные (ContentType, Hash-SHA-256, Size).
Пример декларации вспомогательных данных:
{
"Type": "com.apple.asset.data",
"Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
"ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
"Payload": {
"Reference": {
"DataURL": "https://example.com/asset-data/data/test.txt",
"ContentType": "text/plain"
},
"Authentication": {
"Type": "MDM"
}
}
}
Пример декларации для сертификата:
{
"Type": "com.apple.asset.credential.certificate",
"Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
"ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
"Payload": {
"Reference": {
"DataURL": "https://example.com/asset-data/certificates/cert.pem",
"ContentType": "application/pem"
}
}
}
Activation
Вид деклараций, которые указывают логику, как и когда Configuration-декларации должны применяться к устройству.
Activation-декларация обязательно содержит список идентификаторов Configuration-деклараций.
Устройство будет пытаться атомарно применять все декларации из списка, то есть применит либо все конфигурации вместе, либо ни одной, если одна из них применится с ошибкой.
Activation-декларация может содержать Predicate-строку, из которой устройство будет понимать, стоит ли активировать связанные Configuration декларации или нет.
При несоответствии данных устройства связанные Configuration-декларации не будут применены, но могут быть применены в будущем, если данные устройства изменятся. При отсутствии Predicate-строки, Activation-декларация считается активной всегда. Несколько Activation-деклараций могут содержать один и тот же идентификатор Configuration-декларации. Если хотя бы одна Activation-декларация активна для Configuration-декларации, то последняя будет применена к устройству. Если для Configuration-декларации нет хотя бы одной связанной Activation-декларации, Configuration-декларация не будет применена к устройству.
Пример Activation-декларации:
{
"Type": "com.apple.activation.simple",
"Identifier": "04BECEFA-47B9-4F2E-8040-246509A52409",
"ServerToken": "CBE396A0-637B-438D-9F0C-EA912A5BB587",
"Payload": {
"Predicate": "@status(device.model.family) == 'AppleTV'",
"StandardConfigurations": [
"892853C1-DDD1-4562-84B9-1591A76AD42B",
"DCF869F1-09B7-4EC2-83B5-073F6FE94597"
]
}
}
Management
Декларация, которая содержит метаданные об организации и поддерживаемые возможности сервера. Пример декларации информации об организации:
{
"Type": "com.apple.management.organization-info",
"Identifier": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
"ServerToken": "E180CA9A-F089-4FA3-BBDF-94CC159C4AE8",
"Payload": {
"Name": "Example, Inc.",
"Email": "admin@example.com",
"URL": "https://site.example.com/support"
}
}
Доставка деклараций
Механизм получения деклараций DDM для устройства подразумевает два способа получения данных: общий список всех типов деклараций с сокращенными данными и получение декларации по идентификатору с расширенным списком полей.
Пример ответа общего списка деклараций:
{
"DeclarationsToken": "EB13EE2B-5D63-4EBA-810F-5B81D07F5017",
"Declarations": {
"Activations": [
{ "Identifier": "...", "ServerToken": "..." },
{ "Identifier": "...", "ServerToken": "..." },
],
"Assets": [
{ "Identifier": "...", "ServerToken": "..." }
],
"Configurations": [
{ "Identifier": "...", "ServerToken": "..." },
{ "Identifier": "...", "ServerToken": "..." },
{ "Identifier": "...", "ServerToken": "..." },
{ "Identifier": "...", "ServerToken": "..." },
],
"Management": [
{ "Identifier": "...", "ServerToken": "..." },
]
}
}
Как с этим работать?
В самых общих словах для начала работы с DDM потребуется сделать следующее:
включить поддержку DDM на устройствах;
отправить на устройства все необходимые Configuration-деклараций и Asset-деклараций;
активировать их с помощью Activation-деклараций,
При этом устройства по прежнему будут поддерживать доставку и применение профилей MDM.
Конечно же, это должно поддерживаться вашим вендором MDM, так как для работы с DDM требуется поддержка на стороне сервера MDM. Уровень поддержки у разных вендоров реализован по-разному, не все возможности внедрены на 100%, и не везде это выглядит одинаково.
Но так или иначе, переход на DDM – это вопрос времени.
Мы в Ринго прекрасно понимаем это и планируем выпустить поддержку DDM уже в этом году.
Следите за новостями в нашем Telegram-канале и блоге!