Mdm-система

Как выполнить требования ГОСТ Р 57580 по обеспечению безопасного удаленного доступа с мобильных устройств, не запрещая их использования

Об обязательности требований ГОСТР57580 для финансовых организаций, порядке их внедрения иметодах оценки соответствия написано множество статей, дано много рекомендаций, сделано немало комментариев. Согласно требованиям ЦБ, до 01.01.2021 необходимо не только обеспечить соответствие требованиям стандарта, но ипредоставить регулятору отчет обэтом соответствии. На российском рынке существует немало квалифицированных аудиторских компаний, оказывающих услуги финансовым организациям, но доказательство соответствия порой превращается вполемику встиле: Не читал, но осуждаю!.

Мы хотим поделиться практическим опытом реализации одного из восьми процессов, именованным вГОСТе как Процесс8. Защита информации при осуществлении удаленного логического доступа сиспользованием мобильных (переносных) устройств.

Базовый состав мер по защите информации от раскрытия имодификации при осуществлении удаленного доступа

ЗУД.1. Определение правил удаленного доступа и перечня ресурсов доступа, к которым предоставляется удаленный доступ

Правила несложные: удаленный доступ должен предоставляться по запросу при наличии служебной необходимости; ни одному работнику не должен предоставляться удаленный доступ ко всем ресурсам, только доступ кограниченному числу ресурсов, необходимых для работы. Реализация этой организационной меры подтверждается нормативными документами, определяющими порядок предоставления удаленного доступа политика удаленного доступа, ссылающаяся на общую политику ИБ, шаблоны заявок на предоставление доступа ит.д.

ЗУД.2. Аутентификация мобильных (переносных) устройств удаленного доступа

Мобильные устройства не проходят аутентификацию сами по себе. За них это делают мобильные приложения, спомощью которых осуществляется удаленный доступ. Пользователь мобильного приложения должен проходить аутентификацию при удаленном доступе путем ввода пароля от учетной записи, предъявления пользовательского сертификата ит.п.

ЗУД.3. Предоставление удаленного доступа только с использованием мобильных (переносных) устройств доступа, находящихся под контролем системы централизованного управления и мониторинга (системы Mobile Device Management, MDM)

На мобильных устройствах должны применяться политики безопасности по крайней мере вобъеме меры ЗУД.10, атакже должен осуществляться мониторинг этих устройств на предмет выявления признаков программного взлома (root, jailbreak), чтобы скомпрометированные устройства не могли получить доступ вкорпоративную сеть. Для этого нужно использовать системы централизованного управления мобильностью. Внастоящее время их принято называть EMM-системами (от англ. Enterprise Mobility Management управление корпоративной мобильностью), но во времена разработки ГОСТ чаще использовался термин MDM (Mobile Device Management управление мобильными устройствами). Вчасти реализации мер ГОСТР57580 это одно ито же, поэтому далее используется термин MDM.

Реализация меры заключается втом, что на все мобильные устройства, скоторых осуществляется удаленный доступ, должен быть установлен MDM-клиент. Также необходимо регулярно проверять, какие устройства удаленно подключаются ккорпоративным ресурсам, чтобы не допустить ситуации, когда личный смартфон сотрудника без контроля иуправления со стороны MDM получает доступ вкорпоративную сеть. Например, такое может произойти, если пользователь сам поставил себе VPN-клиент сдоменной авторизацией или настроил доступ сличного устройства без MDM квнутренней электронной почте по MS ActiveSync, который остался доступен из интернета вопреки реализации меры ЗУД.6.

Мера обязательна для первых двух уровней защиты, для третьего ее реализация необязательна, хотя мы рекомендуем использовать MDM всегда. Системы управления мобильными устройствами не только компенсируют риски ИБ, но исокращают затраты IT на техническую поддержку мобильных устройств ворганизации.

ЗУД.4. Реализация защиты информации от раскрытия и модификации, применение двухсторонней взаимной аутентификации участников информационного обмена при ее передаче при осуществлении удаленного логического доступа

Меру можно рассматривать как усиление или конкретизацию меры ЗУД.2. Аутентификация мобильных приложений иинформационных ресурсов, ккоторым они получают удаленный доступ, должны быть взаимной. Например, сервер проводит аутентификацию клиента по логину ипаролю или по сертификату, амобильное приложение (клиент) проверяет сертификат сервера. Поскольку вбольшинстве случаев для информационного обмена используется протокол HTTPS, реализация этой меры не составляет большого труда.

Базовый состав мер по защите внутренних вычислительных сетей при осуществлении удаленного доступа

ЗУД.5 Идентификация, двухфакторная аутентификация и авторизация субъектов доступа после установления защищенного сетевого взаимодействия, выполнения аутентификации, предусмотренной мерами ЗУД.2 и ЗУД.4

В дополнение креализации мер ЗУД.2 иЗУД.4 нужно осуществлять авторизацию учетных записей работников (проверять наличие уних полномочий для удаленного доступа). Обычно эта мера реализуется спомощью назначения учетным записям ролей и/или включения их вгруппы безопасности, взависимости от которых учетным записям разрешается обращение ктем или иным информационным ресурсам.

Кроме того, финансовой организации следует использовать двухфакторную аутентификацию. Здесь умобильных устройств есть своя особенность. Если на мобильном устройстве настроена биометрия для доступа кмобильному устройству, аутентификацию нельзя считать двухфакторной, потому что пользователь всегда предъявляет только один фактор или биометрию, или пароль, но не то идругое вместе.

Еще одно расхожее заблуждение при смешении факторов иэтапов: если пользователь сначала вводит пароль доступа кустройству, апотом вводит пароль доступа кприложению это двухэтапная, но не двухфакторная аутентификация, потому что фактор используется тот же (пароль).

На практике можно считать двухфакторной аутентификацией процесс, когда пароль для доступа кмобильному устройству дополняется биометрией при доступе кприложению. Подойдут также одноразовые пароли, токены ит.д. Влюбом случае второй фактор придется реализовывать вприложениях, спомощью которых осуществляется удаленный доступ. Ограничиться настройками мобильных ОС не получится, потому что встроенная аутентификация однофакторная.

ЗУД.6 Запрет прямого сетевого взаимодействия мобильных (переносных) устройств доступа и внутренних сетей финансовой организации на уровне выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем.

Для удаленного доступа кресурсам финансовой организации необходимо всегда использовать VPN, втом числе при использовании Wi-Fi-сетей финансовой организации. Мера обязательна для первых двух уровней защиты. Для третьего уровня защиты реализация меры необязательна.

Практическая рекомендация по реализации организовывать доступ кMDM напрямую через интернет без использования VPN. Всистеме MDM не содержатся конфиденциальные данные финансовой организации иканал управления, как правило, шифруется встроенными средствами. Дополнительная защита канала управления спомощью VPN не только излишняя, но иприводит ктому, что мобильные устройства остаются без управления изащиты, если VPN-шлюз недоступен или пользователь выключил VPN на устройстве.

ЗУД.7 Реализация доступа к ресурсам интернета только через информационную инфраструктуру финансовой организации после установления защищенного сетевого взаимодействия, выполнения аутентификации, предусмотренной мерами ЗУД.2 и ЗУД.4

Для минимизации угрозы фишинга иограничения доступа кскомпрометированным веб-ресурсам мобильные устройства должны обращаться кинтернету так же, как ирабочие станции внутри периметра финансовой организации через системы URL-фильтрации, потоковые антивирусы идругие средства защиты трафика. Мобильные VPN-клиенты могут быть настроены так, чтобы весь исходящий трафик мобильного устройства направлялся вкорпоративную сеть. Но пользователь может выключить VPN внастройках мобильного устройства, даже если такой возможности не предоставляет интерфейс VPN-приложения. Запретить это можно только на устройствах Android при помощи MDM-политик. Для устройств iOS остается только контролировать подключения на VPN-шлюзе. Если устройство не подключено кVPN-шлюзу, но подключено кMDM, то это значит, что пользователь выключил VPN.

Мера обязательна креализации для первого ивторого уровней защиты информации. Для третьего уровня защиты мера необязательна.

ЗУД.8 Контентный анализ информации, передаваемой мобильными (переносными) устройствами в интернет с использованием информационной инфраструктуры финансовой организации

В дополнение кмере ЗУД.7 уточняется, что для защиты трафика мобильных устройств должны применяться средства контентного анализа. Как иЗУД.7, мера обязательна только для первых двух уровней защиты информации.

ЗУД.9 Реализация и контроль информационного взаимодействия внутренних вычислительных сетей финансовой организации и мобильных (переносных) устройств в соответствии с установленными правилами и протоколами сетевого взаимодействия

В значительной степени это техническая реализация меры ЗУД.1. Пользователи должны получать доступ только кразрешенным ресурсам. Ограничение информационного взаимодействия должно быть реализовано спомощью настройки правил межсетевого экранирования. Правила должны быть настроены по принципу белого списка запрещать все, кроме явно разрешенного. Причем серверные компоненты информационных ресурсов должны быть доступны не целиком, атолько по тем протоколам ипортам, которые нужны для информационного обмена сприложениями на мобильных устройствах.

Базовый состав мер по защите информации от раскрытия имодификации при ее обработке ихранении на мобильных (переносных) устройствах

ЗУД.10 Применение системы централизованного управления и мониторинга (MDM-системы)

Меру необходимо реализовывать для первого ивторого уровней защиты информации. На третьем уровне защиты ее реализация является рекомендуемой, но необязательной. Мера предъявляет всовокупности 12 требований ксистемам MDM.

Шифрование ивозможность дистанционного удаления информации, полученной врезультате взаимодействия синформационными ресурсами финансовой организации

Современные мобильные устройства содержат встроенные средства шифрования. Все устройства сОС Android7 ивыше по умолчанию шифруют свои данные. Для устройств сОС Android6 иниже можно включить шифрование спомощью MDM, но доля таких устройств невелика. На устройствах сiOS шифрование включается автоматически, когда пользователь устанавливает пароль для доступа кустройству, поэтому достаточно спомощью MDM запретить доступ кустройству без пароля.

Дистанционное удаление данных смобильных устройств является базовой функцией любой MDM-системы. Ее используют, если пользователи сообщают опотере или краже мобильных устройств. Функцию дистанционной очистки устройств также используют при подготовке устройства, когда оно передается от одного пользователя другому, например при увольнении. Издесь есть важный нюанс.

Для защиты устройств от кражи Apple иGoogle предлагают пользователям настроить функцию Find My Device, которая после сброса устройства кзаводским настройкам не даст использовать его повторно, если пользователь не введет пароль от своей учетной записи. Первым эту функцию реализовал Apple, что сократило число краж iPhone иiPad внесколько раз.

Представьте, что сотрудник не выключил функцию Find My Device ирешил уволиться. Перед увольнением сотрудника администраторы удаленно сбросили устройство кзаводским настройкам иотдали его на склад, пока оно не понадобится новому сотруднику. Через месяц поступает заявка на подготовку этого устройства, его включают, но не могут настроить, потому что пароль от учетной записи уволенного сотрудника неизвестен, аего самого уже ислед простыл. Остается только списывать устройство как сломанное.

Есть три способа не столкнуться сэтой проблемой:

1. запрещать сотрудникам использовать функцию Find My Device;

2. требовать обязательного отключения функции Find My Device на устройстве до увольнения сотрудника;

3. использовать корпоративные аналоги функции Find My Device всоставе MDM-систем.

Аутентификация пользователей на устройстве доступа

С помощью MDM нужно настроить требование кналичию пароля на мобильных устройствах, чтобы устройство, например, оставленное сотрудником на столе, не смог использовать никто другой. Разнообразие политик безопасности всовременных мобильных операционных системах позволяет потребовать теоретически сколь угодно сложный пароль: например, 27-символьный пароль, вкотором должны содержаться буквы верхнего инижнего регистров, цифры испецсимволы.

Практическая рекомендация: достаточно настроить запрет использования простых паролей, содержащих повторяющиеся символы (1111, 2222) или восходящие/убывающие последовательности символов (1234, 9876), атакже ограничить число ошибок ввода пароля, чтобы сотрудники могли использовать удобные цифровые пароли длиной в46символов ипри этом вероятность подбора пароля оставалась низкой.

На мобильных устройствах превышение числа ошибок ввода пароля приводит ксбросу устройств кзаводским настройкам, ане кблокировке учетной записи, как это реализовано на рабочих станциях сWindows или macOS. Обычно после пятой ошибки мобильная операционная система начинает увеличивать интервалы между вводами пароля, чтобы пользователь наконец убедился втом, что забыл пароль, исмог обратиться кадминистратору MDM, чтобы тот сбросил ему пароль удаленно. Мы рекомендуем устанавливать возможность совершить 810ошибок при вводе пароля.

Блокировка устройства по истечении определенного промежутка времени неактивности пользователя, требующая выполнения повторной аутентификации пользователя на устройстве доступа

Пользователь может настроить мобильное устройство так, что пароль доступа кнему нужно будет вводить только после перезагрузки. Сточки зрения безопасности это не очень сильно отличается от отсутствия пароля. Чтобы исключить это, нужно спомощью MDM настроить максимальное время неактивности пользователя до блокировки сеанса. Рекомендуется устанавливать от одной до трех минут.

Управление обновлениями системного ПО

Обновления мобильных ОС содержат обновления безопасности, поэтому важно устанавливать их своевременно. Техническая возможность устанавливать обновления мобильных ОС есть только на устройствах сAndroid10 ивыше ина Android-устройствах производства Samsung спомощью сервиса Samsung E-FOTA One. На других устройствах технической возможности своевременно установить обновление ОС нет.

В то же время часто возникает необходимость решить обратную задачу запретить или хотя бы отложить обновление мобильной ОС. Запрет или отсрочка обновления необходимы, например, чтобы разработчики смогли адаптировать мобильные приложения для новой версии ОС. Минорные обновления внутри одной мажорной версии ОС, например сAndroid8.1 на Android8.2, обычно не требуют доработки приложений, но при мажорном обновлении ciOS13 на iOS14, например, они могут понадобиться. Запретить обновление ОС можно только на Android-устройствах Samsung, на других устройствах его можно только отложить.

Управление параметрами настроек безопасности системного ПО устройств доступа

Современные мобильные ОС содержат сотни политик безопасности, которые можно разделить на несколько основных групп.

Управление доступом кинтерфейсам записи ипередачи данных, включая камеру, микрофон, Wi-Fi, мобильный интернет, Bluetooth, режим мобильной точки доступа, когда мобильное устройство предоставляет доступ кмобильному интернету по Wi-Fi, Bluetooth или USB ит.д. Политики этой группы могут применяться во время проведения совещаний или для исключения утечки файлов смобильного устройства сиспользованием Bluetooth.

Ограничение встроенных функций ОС. Самая большая группа по числу возможных политик. Из них наиболее востребованными являются: запрещение загрузки Android-устройства вбезопасном режиме, вкотором непрерывная работа средств защиты информации может быть нарушена пользователем, атакже запрещение использования внешних накопителей (SD-карт), которые могут быть применены для несанкционированного копирования данных финансовой организации. На iOS рекомендуется запрещать пользователям устанавливать конфигурационные профили, спомощью которых они могут изменить действующий набор политик безопасности.

Иногда требуется запретить пользователям сбрасывать устройства кзаводским настройкам, чтобы их умышленные или случайные действия не могли нарушить непрерывность бизнес-процессов финансовой организации. При этом уадминистратора MDM сохраняется возможность выполнить сброс дистанционно вцелях обеспечения информационной безопасности.

Ограничение сервисов телефонии, включая полный или частичный запрет голосовых вызовов или прием/передачу коротких сообщений. Может применяться во время совещаний, переговоров, чтобы пользователи мобильных устройств, например, не отвлекались на входящие сообщения ивызовы.

Управление составом иобновлениями прикладного ПО

Использование MDM-системы позволяет упростить распространение приложений на мобильные устройства финансовой организации, обеспечивая их централизованную установку, обновление иконфигурацию. Кроме того, финансовой организации может потребоваться запретить отдельные приложения, мешающие пользователям или отвлекающие их от работы, игры, социальные сети ит.д. Вотдельных случаях мобильные устройства спомощью систем MDM превращают втак называемые цифровые киоски, на которых доступно только одно или несколько разрешенных мобильных приложений.

С точки зрения информационной безопасности необходимо запретить установку мобильных приложений из непроверенных источников, атакже при необходимости впринципе запретить пользователям устанавливать мобильные приложения, распространяя их только из доверенного MDM-хранилища. Более подробно эти запреты рассмотрены ниже, вописании реализации меры ЗУД.11.

Невозможность использования мобильного (переносного) устройства врежиме USB-накопителя, атакже врежиме отладки

Запрет доступа кфайлам мобильного устройства по USB защищает от утечки данные финансовой организации. Вто же время, если эти данные зашифрованы, то их выгрузка смобильного устройства взашифрованном виде не приведет ккомпрометации.

Режим отладки позволяет устанавливать на мобильные устройства приложения вобход системы MDM ипубличных каталогов Google Play иApp Store. Этой возможностью вполне реально воспользоваться, например, когда мобильное устройство сдается перед переговорами. Режим отладки нужен только разработчикам приложений, рядовым пользователям он не требуется, поэтому его следует запретить.

Для iOS режима отладки нет, но при наличии ноутбука под macOS сустановленным XCode изнании пароля доступа кустройству возможна несанкционированная установка на него приложения по USB. Для защиты от этого нужно перевести iOS-устройство врежим supervised иустановить спомощью MDM запрет подключения мобильного устройства ко всем рабочим станциям, кроме той, которую использовал администратор для перевода устройства вsupervised-режим. Этот же запрет ограничит доступ кфайлам iOS-устройства по USB.

Управление ключевой информацией, используемой для организации защищенного сетевого взаимодействия

MDM-системы позволяют автоматизировать выпуск иобеспечить централизованную доставку на мобильные устройства цифровых сертификатов. Сертификаты выписываются на удостоверяющем центре финансовой организации имогут применяться для аутентификации доступа мобильных устройств кWi-Fi-сетям или внутренней электронной почте. Кроме того, эти сертификаты могут применяться для аутентификации доступа кVPN-сети, если используемое VPN-решение использует такой способ аутентификации. Ключевое ограничение этой технологии заключается втом, что она оказывается несовместимой сотечественной криптографией. Удостоверяющие центры, реализующие алгоритмы ГОСТ-шифрования, не содержат прикладных интерфейсов (API), для того чтобы внешняя MDM-система могла выпустить на них сертификат. Если VPN-решение использует симметричную криптографию без цифровых сертификатов, то управление ключевой информацией обычно полностью сосредоточено внутри решения VPN. Вэтом случае MDM-система тоже не может помочь дополнительно автоматизировать или упростить этот процесс.

Возможность определения местонахождения мобильного устройства

MDM-системы позволяют не только управлять смартфонами ипланшетами, устанавливая на них политики безопасности имобильные приложения, но иосуществлять мониторинг корпоративных мобильных активов. Одной из самых востребованных функций мониторинга является определение местонахождения мобильных устройств. Его используют для решения нескольких задач:

• поиск утерянных устройств. Вэтом случае, как правило, их дистанционно блокируют, после чего производят поиск по последним полученным от устройства координатам;

• применение политик безопасности взависимости от местоположения устройства, например запрет использования камеры вофисах финансовой организации;

• контроль выполнения трудовых обязанностей полевого персонала, например фиксация фактов отклонения движения инкассаторов от регламентного маршрута или непосещения подконтрольных отделений супервайзерами;

• выявление фактов утечки инсайда. Данные оместоположении мобильных устройств всовокупности синформацией окоммуникациях абонентов позволяют выявлять нежелательные социальные связи ипредотвращать утечку инсайда.

Регистрация смены SIM-карты

Необходимо фиксировать факты извлечения исмены SIM-карты мобильного устройства. Делается это для защиты данных при потере или краже устройства. Если устройство украдут, то первое, что сним сделают, это извлекут SIM-карту, чтобы устройство нельзя было отследить. Поэтому дополнительно рекомендуется настроить автоматическую блокировку устройства при извлечении SIM-карты спомощью MDM.

Запрет переноса информации воблачные хранилища данных, расположенные вобщедоступных сетях (например, iCIoud)

С помощью доступа коблачным резервным хранилищам пользователи могут случайно или преднамеренно допустить утечку конфиденциальных данных финансовой организации. Защититься от этого можно несколькими способами.

1. Запретить доступ кiCloud, DropBox, Яндекс Диск, Google Drive идругим аналогичным сервисам. Спомощью встроенных политик безопасности мобильных ОС можно запретить только доступ кiCloud для iOS ирезервное копирование на серверы Google для Android. Доступ костальным сервисам можно ограничить только спомощью запрета наличия на мобильных устройствах соответствующих мобильных приложений.

2. Хранить данные на мобильном устройстве взашифрованном виде. Вэтом случае неважно, как икуда смобильного устройства будут выгружены данные. Если они зашифрованы, то утечки не будет. Достаточно обеспечить неизвлекаемость ключа шифрования смобильного устройства.

Обеспечение возможности централизованного управления имониторинга при смене SIM-карты

Требование скорее относится кинформационной инфраструктуре финансовой организации. Смена SIM-карты может повлиять на возможность централизованного управления лишь водном случае если доступ ксерверу системы MDM возможен только сопределенных SIM-карт. Такое возможно, если финансовая организация приобрела усотового оператора специальный тариф, врамках которого трафик скорпоративных SIM-карт маршрутизируется вкорпоративную сеть. Чтобы не терять возможность управления при замене такой SIM-карты на другую, нужно обеспечить доступность сервера системы MDM из интернета. Это позволит осуществлять непрерывное управление мобильными устройствами вне зависимости от работоспособности идоступности VPN-шлюза иустановленной вмобильном устройстве SIM-карты.

ЗУД.11 Обеспечение защиты мобильных (переносных) устройств от воздействий вредоносного кода

На рабочих станциях вирусы обычно содержатся вфайлах, которые при открытии эксплуатируют одну из уязвимостей операционной системы или установленных вней приложений. На мобильных устройствах запустить отдельный файл нельзя, можно запустить только приложение. Поэтому большинство вирусов представляют собой модифицированные версии привычных приложений, которые при установке вобход официальных каталогов Google Play иApp Store, например, могут несанкционированно собирать данные финансовой организации.

Рекомендуем несколько проверенных способов защиты от этого.

1. Запретить пользователям устанавливать приложения на мобильные устройства иустанавливать все приложения централизованно спомощью MDM, предварительно проверяя дистрибутивы приложений спомощью антивируса.

2. Запретить пользователям устанавливать приложения из непроверенных источников. Тогда на мобильных устройствах будут только проверенные приложения, установленные спомощью MDM или из официальных каталогов Google Play иApp Store.

3. Установить на мобильные устройства антивирус ввиде отдельного приложения или всоставе приложения MDM. Вэтом случае все файлы иприложения на мобильном устройстве будут проверяться на наличие вредоносного кода. Это позволить проверять на наличие вирусов приложения, устанавливаемые пользователями из Google Play.

Для iOS антивирусов не бывает. Ни одно приложение на iOS не может получить доступ кфайлам других приложений, поэтому разработать антивирус для iOS невозможно. Врезультате на iOS можно использовать только первые два способа реализации меры ЗУД.11.

ЗУД.12 Стирание информации конфиденциального характера с мобильных (переносных) устройств средствами, обеспечивающими полную перезапись данных, при осуществлении вывода мобильных (переносных) устройств из эксплуатации, а также при необходимости их передачи в сторонние организации, между работниками и (или) структурными подразделениями финансовой организации

Если сотрудник увольняется или корпоративное мобильное устройство сдается времонт, настоятельно рекомендуем стереть на мобильном устройстве информацию, чтобы защитить свои корпоративные данные. Когда мобильное устройство сбрасывают кзаводским настройкам, на нем стирается ключ шифрования данных, и,даже если злоумышленнику удастся снять полный образ памяти устройства, он ничего не сможет сним сделать. Стирание только ключа шифрования данных позволяет сделать сброс кзаводским настройкам максимально быстрым. Оперативно перезаписать несколько сотен гигабайт данных нельзя, поэтому перезапись данных на современных мобильных устройствах не используется.

Надеемся, что статья окажется полезной не только для компаний, которые проходят аудит на соответствие ГОСТР57580, но идля всех компаний, которые активно используют мобильные устройства всвоих бизнес-процессах.

В управлении яблочными устройствами есть своя начинка специфика. Например, невозможно разработать приложение, которое управляло бы устройством. Функции управления доступны только самой iOS. Нельзя запретить пользователю отключаться от управления. После supervise нельзя восстановить данные из резервной копии. И так далее.

Под катом расскажем, как устроено управление iOS и каких корпоративных сервисов Apple не хватает в России.

Как устроено управление iOS?

Когда в компании используется больше десятка мобильных устройств, у админов пропадает желание настраивать их вручную ставить приложения, настраивать Wi-Fi, почту, VPN и т.д. В этом случае помогают системы управления мобильностью, одну из которых мы производим уже десять лет. Поэтому далее будем делиться своим практическим, порой горьким опытом управления корпоративными устройствами.

Основная специфика iOS устройств это их владельцы. Как правило, это люди занятые, требовательные, во всем разбирающиеся, но не всегда технически подготовленные. Одним словом, топ-менеджеры. Осложняют ли эти особенности процесс управления iOS устройствами?

Если не считать мелочей, типа устройство более одного раза в чужие руки не отдам, виноваты все, кроме меня, поощрение это отсутствие наказания, то не осложняют.

Еще одна особенность iOS устройств это предлагаемые Apple механизмы управления IOS-устройствами:

1. На устройство нужно установить конфигурационный профиль, в котором определяются параметры подключения к серверу управления. Профиль можно установить с использованием браузера, почты, мобильного приложения или MacBook.

2. При установке профиля устройство регистрируется на сервере управления. При этом устройство сообщает серверу токен, по которому сервер может обратиться к устройству через APNS (Apple Push Notification Service).

3. Когда серверу управления нужно доставить на устройство команду, он уведомляет об этом устройство с помощью APNS.

4. Получив уведомление, устройство обращается к серверу за командой, выполняет её и сообщает серверу результат.

Сервер управления должен реализовать протокол управления Apple и отправлять уведомления о командах управления через APNS. Без уведомлений и APNS эта схема не работает. iOS устройство за командами само не придёт. Не барское это дело. Компании, как правило, не в восторге от необходимости предоставлять корпоративным серверам доступ к внешним интернет-ресурсам. Но в случае с управлением iOS устройствами альтернативы нет. При этом нужно открыть HTTPS и DNS порты всей подсети 17.0.0.0/8.

Несмотря на то, что управлять iOS устройствами с помощью приложения нельзя, у нас и других разработчиков систем управления мобильностью все же имеются мобильные клиенты для iOS.

С помощью нашего клиентского приложения пользователь сможет зарегистрироваться в SafePhone и установить корпоративные приложения с сервера своей компании без App Store.
Например, клиент самописного ЭДО или персонализированная BI отчётность для руководителей.

Клиент SafePhone также контролирует наличие признаков программного взлома (jailbreak). При взломе в iOS песочницы различных приложений больше не защищают их приватные данные.
В системе после jailbreak могут появиться приложения, которые имеют полный доступ к файлам на устройстве. Поэтому важно автоматически удалять корпоративные приложения и их данные с iOS устройств, если обнаружен jailbreak.

Ещё клиент управления можно использовать для сбора информации о местоположении устройств. В SafePhone можно настроить график рабочего времени для отдельных подразделений и сотрудников. Опрос координат устройств будет вестись строго по этому графику.

Какие есть ограничения?

Изменить технологию управления iOS устройствами нельзя, поэтому необходимо учитывать следующие ограничения.

Пользователь может в любой момент отключить iOS устройство от управления, и сервер управления может об этом не узнать. Apple требует, чтобы пользователь мог самостоятельно удалить конфигурационный профиль, в котором указаны параметры подключения iOS к серверу управления. При удалении профиля устройство однократно отправляет серверу сообщение об отключении. Если в этот момент устройство не имеет доступа в интернет, сообщение до сервера управления так и не дойдет.

С точки зрения компании отключение iOS устройства от управления обычно не является большой проблемой, потому что при этом с устройства удаляются все корпоративные приложения и настройки. Всё, что компания не хочет потерять или разгласить, будет удалено вместе с возможностью управления.

Следующий блок ограничений связан с supervised режимом работы iOS. Это специальный режим, в котором доступно большее число команд и политик управления. При этом по мере выхода новых версий iOS существующие команды и политики начинают требовать supervised режима.
Поэтому мы рекомендуем переводить все корпоративные iOS устройства в этот режим.
Но есть нюанс.

Чтобы перевести iOS устройство в supervised режим, нужно подключить его кабелем к MacBook и перепрошить с помощью приложения Apple Configurator 2. Если перепрошивка выполняется до передачи устройства пользователю, далее проблем не будет. Но если компания приняла решение переводить корпоративные устройства в supervised режим после того, как выдала их пользователям, проблем не оберешься.

В supervised режиме нельзя восстановить данные из резервной копии, которая была сделана до включения этого режима. В этом ключевая проблема. Начиная с перевода устройства в supervised режим, история его резервных копий начинается заново. Если в резервной копии были данные, которые нужны пользователю для работы, он потеряет к ним доступ. Поэтому важно переводить iOS устройства в supervised режим как можно раньше. И в первую очередь устройства топов...

Чего не хватает в России?

Ключевой корпоративный сервис Apple Business Manager до сих пор недоступен в России. Надеемся, что следом за предустановленными российскими приложениями на iOS устройствах придёт и его черед.

С помощью Apple Business Manager можно управлять устройствами буквально с первого включения. Если компания и её устройства зарегистрированы в Business Manager, то настройки подключения устройств к корпоративному серверу управления сообщаются устройствам сразу при их активации. Эти устройства активируются сразу в supervised режиме и можно сделать так, что пользователь не сможет удалить настройки управления, т.е. устройства всегда будут находиться под управлением.

Второй важной функцией Apple Business является возможность покупки приложений для бизнеса. Сейчас российские компании не могут централизованно купить приложения в App Store.
Если пользователям для работы нужны платные приложения, обычно их покупают сами пользователи, а потом транжира-работодатель возвращает денежку с грустью в глазах.
С появлением Apple Business Manager российские компании смогут цивилизованно покупать софт для iOS, а потом с помощью систем управления распространять на корпоративные устройства купленные лицензии.

Часть российских компаний уже пользуются Apple Business Manager, но для этого они используют свои зарубежные представительства. Зарубежное представительство может зарегистрироваться в Apple Business Manager и добавить в него все корпоративные iOS устройства, включая российские. Создавать европейский филиал ради доступа к Business Manager, наверное, перебор.
Но если он уже создан, подключайте свои устройства через него.

Остались вопросы?

Если у вас остались вопросы по использованию iOS устройств в вашей компании, напишите нам на sales@niisokb.ru или оставьте комментарий к статье.

Мы будем вам признательны и обязательно ответим.

Уважаемые коллеги, всем доброго дня.

В данной статье хочу поделитьсясобственным опытом знакомства с MDM решением компании Юнидата (UniData). Попытаюсь сделать акцент на конкретные трудности и особенности платформы, с которыми столкнулся при переходе с SAP MDM на ЮниДата MDM.

Предыстория проекта

К моменту старта проекта по переходу на UniData MDM в Компании уже примерно 5 лет функционировала корпоративная система управления нормативно-справочной информацией (КСУ НСИ) на базе SAP MDM. Проект внедрения SAP MDM был по-настоящему успешным и эксплуатация системы практически не создавала проблем.

В КСУ НСИ велись два общекорпоративных справочника:

• материально-технических ресурсов, работ и услуг (МТРиУ), 200000 записей

• контрагентов, 40000 записей

Применялась модель централизованного ведения НСИ с единой точкой ввода через механизм заявок от пользователей. MDM выступал мастер-системой для ряда информационных систем Дочерних обществ, обслуживающих различные бизнес-процессы (бухгалтерский и налоговый учет, планирование и централизованные закупки, техническое обслуживание и ремонт оборудования и другие).

Конфигурация системы включала в себя портал (тонкий клиент, GUI) для работы с заявками пользователей, толстый клиент для настройки модели данных и других операций, специализированный инструментарий для экспорта и импорта данных и другие компоненты.

В системе была реализована достаточно сложная модель ведения данных, большой атрибутивный состав справочников. Система классификации и кодирования состояла из иерархических и фасетно-иерархических (онтологических) классификаторов и их связей (мэппинг), для записей было предусмотрено кодирование по системе свойств и значений, развит инструментарий в части управления качествомданных.

В целом состав данных и функционал системы можно назвать достаточно типовым для крупного бизнеса в сфере промышленного производства.

В силу разных причин перед Компанией встала задача импортозамещения системы SAP MDM с полным сохранением существующей функциональности.

В рассмотрение брались все самые распространенные отечественные решения, из которых, в силу различных причин,отсеялисьвсе, кроме Unidata MDM.

В пользу Unidata сыграл западный опыт (в дальнейшем авторитетное международное аналитическое агентствоGartner даже включило Unidata в свой "Магический квадрант"), универсальность решения (рассматривались и смежные проекты внедрения MDM под другие данные с иными моделями ведения), основа технологического стека на свободном ПО с открытым исходным кодом и лицензионная политика, в которой метрикой выступило количество справочников.

Перейду к конкретике, все дальнейшее сравнение и ожидания от функциональности платформы будут опираться на решение SAP MDM. Условно разделю выявленные проблемы на 3 блока:

Архитектурные особенности и базовая функциональность

• Отсутствие понятия "легитимное состояние записи".

  После создания черновика заявки на добавление или изменение записи, изменения сразу же отображаются в справочнике. Например, пользователь добавил запись или внес в нее изменения (мог даже не подать заявку, а просто сохранить как черновик), изменения сразу же отображаются в справочнике и видны всем пользователям. Как следствие данные искажаются и рассинхронизируются с версиями в локальных системах-получателях, что путает пользователей, появляется вероятность внесения дублей, некорректно работают проверки, отборы и возникает ряд других трудностей и неудобств.

  Отображение еще не согласованных заявок как записей в справочн

• Ведение классификаторов без бизнес-процесса как часть модели данных.

  Под классификатором понимаются иерархические (древовидные) структуры - таксономии. В платформе жестко зашита парадигма, в которой классификатор относится к модели данных и меняется только под ролью администратор в отдельном интерфейсе. Следствие такого подхода, - классификаторы невозможно вести через механизм заявок (BPM).
  

• Изначально одним из плюсов платформы нам виделась работа с данными в одном интерфейсе (в отличие от SAP MDM, где данные велись в 2 интерфейсах - "тонком" и "толстом" клиентах), как выяснилось от чего хотели уйти к тому и вернулись.

  Интерфейс редактирования классификатора

• Множественная классификация.

  В системе безальтернативно реализована модель данных, предусматривающая множественную классификацию, при которой одной записи можно присвоить несколько классов одного классификатора. Как правило, для большинства справочников МТР множественная классификация не допускается на уровне методологии.
  Следствием такой реализации является отсутствие понятия "переклассификация" при использовании стандартной пакетной операции загрузки или пакетной модификации в интерфейсе (update) существующих записей справочника. Если вместо указанного класса привести ссылку на другой класс, то существующий класс при загрузке и модификациив интерфейсе не заменяется, а добавляется как второй.

  Отображение множественной классификации записи справочника в табличной форме

• Нет сортировки по полям с классификацией и отбора неклассифицированных записей, выбора нескольких классов.

  Инструментарий отборов и сортировки по классам записей справочника также вызывает вопросы. Сортировка по классам, отбор пустых и нескольких классов не реализованы.
  Например, двойная сортировка записей в табличной форме является крайне эффективным инструментом выявления некорректной классификации, выбивающиеся классы бросаются в глаза, но в данной MDM данный подход на практике не реализуем.

• Правила качества нельзя задавать на шаги бизнес-процесса.

  В платформе есть достаточно мощный инструментарий - правила качества (ПК), который позволяет задавать всевозможные правила валидации, проверки и обогащения данных. При этом архитектурой платформы не предусмотрена возможность задавать ПК на шаг бизнес-процесса, такую задачу можно решить только трудоемкой разработкой (в кастомизационной части кода). На простых формализованных справочниках такой подход приемлем, но на более сложных справочниках, таких как справочник МТР, требовать от пользователя знания тонкостей ведения данных на мой взгляд некорректно, для этого и существует специализированная служба НСИ.
  При этом важно отметить, что данный подход еще и не позволяет реализовывать понятие "Черновик" заявки как запись с любым уровнем заполнения атрибутов, при попытке сохранить заявку в стадии "черновик" пользователь должен заполнить все обязательные данные и пройти все проверки и валидации.

  Сверху пример табличной формы в SAP MDM, снизу те же данные в ЮниДата (транспонированы в строки)z

• Не задаются ограничения длины строки на атрибуты (поля).

  В модели данных не предусмотрена возможность ограничить длину (максимально возможное количество символов) в атрибутах (полях) справочника. Используется ограничение через правила качества, что вызывает существенные неудобства. В поле можно вносить сколько угодно символов, ПК при сохранении обрезает наименование, из-за этого приходится подгонять данные, не всегда получается это сделать с первой итерации. В SAP MDM реализация гораздо более удобная - при вставке из буфера текст подрезается до максимально возможной длины, при вводе с клавиатуры по достижению максимальной длины дальнейший ввод блокируется.

  Форма настройки атрибутов

• Нет настроек для создания типовых предустановленных фильтров, отражающих срезы для работы с заявками.В платформе отсутствует возможность создавать и задавать настройками в моделиданных для разных ролей фильтры, отражающие типовые срезы для работы с заявками. Например, ответственному за распределение заявок в работу экспертам необходимо видеть все поступившие, но не распределенные заявки, инициатору заявок необходимо видеть заявки, которые вернулись ему для устранения замечаний, эксперту все заявки, находящиеся у него в работе и т.д.
  Данный инструментарий реализован во всех зрелых MDM-решениях, нужен для стандартизации и упорядочения процесса обработки заявок, снимает много вопросов со стороны пользователей и позволяет гибко реагировать на изменения в BPM. В рамках нашего проекта платформа была доработана и сущность "Предустановленный фильтр" была впервые введена, однако настроек по отдельным ролям для него нет, то есть пользователи видят все предустановленные фильтры, даже если для них они не предназначены, а сама разработка одного предустановленного фильтра не относится к настройке системы, тарифицируется в более чем в 10 человеко-дней.

  Предустановленные фильтры для заявок

• Персональные настройки хранятся в кэше браузера.

  В системе не реализовано хранение персональных настроек на сервере, как следствие после некоторых изменений системы приходится очищатькэш, после релизов настройки сбрасываются. C учетом текущего гибридного режима работы, работа в системе осуществляется как с рабочих компьютеров, так и удаленно с персональных, по прямой ссылке браузера и через виртуальное приложение в Citrix со своими независимо хранимыми настройками. Гораздо более удобным вариантом было бы хранить персональные настройки на сервере, как это было реализовано в SAP MDM.

• Отсутствует развитой инструментарий выгрузки и загрузки данных.

• В платформе не предусмотрены развитые штатные средства для пользовательской выгрузки и загрузки справочников. Выгрузка осуществляется только в Excel в одном немодифицируемом системном формате, без возможности настройки атрибутного состава (полей), все ссылочные данные представлены в виде id на вспомогательные справочники и классификаторы, выгрузка ограничена пакетами в 50000 записей, выгрузка с учетом фасетно-иерархической классификации не реализована в принципе.
  Например, для того чтобы выгрузить весь справочник МТРиУ и привести его в понятный для пользователя форматпотребуется потратить несколько часов на выгрузку 5 фрагментов основного справочника, всех вспомогательных справочников и классификаторов, потом свести воедино все фрагменты основного справочника, удалить лишние атрибуты, через id подтянуть значения из вспомогательных справочников, в ручных операциях с учетом особенностей Excel весьма вероятно допустить ошибку. В SAP MDM выгрузка из толстого клиента осуществляется в файлы разных форматов, с настройкой полей, в атрибуты вспомогательных справочников указываются истинные значения, а не их id, скорость выгрузки 250 записей в секунду.
  C загрузкой процесс такой же непростой, для загрузки новых записей придется отключить репликацию, остановить правила качества, сначала загрузить часть информации для получения внешнего id, потом выгрузить загруженные данные, подтянуть внешний id в исходный загрузочный файл, потом вторым проходом догрузитьклассификацию, запустить репликацию, правила качества. На практике на дозагрузку 150 записей уйдет не менее 2 часов времени и операцию можно проводить только в технологическое окно, пользователи параллельно не могут создавать новые записи. В пакете инструментов SAP есть Import Manager и Syndicator позволяющие быстро и эффективно делать пользовательское карты загрузки, в один проход прогружать справочники, выбирая любой ключ для загрузки, и получать всевозможные выгрузки.

  Пример стандартной выгрузки из системы, связи и классификация приведены в отдельных вкладках

• Бизнес-процесс (BPM) для заявок - кастомизационная часть кода.

  В платформе не предусмотренавозможность настраивать некоторые или все бизнес-процессы через модуль BPM. По каким-то неизвестным мне причинам не удалось без программирования реализовать достаточно типовой процесс для 4 основных ролей: Инициатор заявки, ЭкспертНСИ, Старший эксперт НСИ, Куратор, с шагами: черновик, подан в обработку, в обработке, направлен на уточнение, возвращен с уточнения, направлен куратору, возвращен куратором, завершен, отклонен. Если один из основных блоков MDM реализован таким образом это вызывает вопросы о зрелости решения.

• Нет ограничений на пакетные операции для пользователей.

  Ролевая модель в системе не позволяет настроить ограничения на пакетные операции. Любой пользовательсистемы может запускать любые пакетные операции. В целом с ролевой моделью в контексте прав пользователей на различные действия натолкнулись на кучу ограничений платформы.

• Нет ограничений на отображение заявок для пользователей.

  Любой пользователь системы видит любые заявки в системе без всяких ограничений. Например, если пользователь имеет права на справочник контрагентов, то он все равно будет видеть все заявки и по другим справочникам, не смотря на то, что сами справочники он не видит и не может редактировать заявки. В нашем случае в SAP MDM также была реализована настройка видимости заявок пользователей только в рамках своего дочернего общества, платформа ЮниДата такое сделать не позволяет.

• Права на редактирование атрибутов заявки не задаются на шаг бизнес-процесса или тип операции.

  Например, атрибут "базовая единица измерения" не должен меняться у уже созданной записи, но задать в системе такое ограничение прав нет возможности.

• Проблемыс поисковыми возможностями.

  В платформе реализован поиск по справочникам на движке Elasticsearch. В интерфейсе представлена возможность поиска как по всем полям одновременно (атрибут "Ключевое наименование"), так и по отдельным полям.
  Первая проблема заключается в том, что нет возможности настроить поиск по сочетанию только требуемых содержательных полей (а не всех). Для решения такой проблемы можно только отключить поиск по отдельным полям в принципе, а не в совокупности с другими. На практике получается, что поиск по всем полям фактически не применим, так как в справочнике много атрибутов создающих фон. Например, ищем контрагента вводя ИНН, а находим запись, у которой ИНН другой, а ИНН из поискового запроса похож на код записи в локальной системе. Также стоит отметить что этот поиск выводится по умолчанию как основной в самом верху формы, и пользователю надо еще догадаться, что есть поиск по отдельным атрибутам.
  Вторая существенная проблема, что поиск по отдельным полям нельзя сочетать с поиском по всем полям, это хоть как-то могло решить первую обозначенную проблему.
  Третья проблема, выявленная в эксплуатации, поиск из коробочного решения никаким образом не учитывает взаимное расположение терм в поисковом запросе. Это крайне негативно влияет на результаты поиска по отдельным специфическим поискам. Например, поиск по обозначениям ТУ, возьмем для примера распространенные "ТУ 16.К71-310-2001" на кабели, Elasticsearch разбирает этот запрос на выражение типа '%ТУ%' and '%16%' and '%К71%' and '%310%' and '%2001%', то есть игнорирует символы разделителей (точки, дефисы) и их взаимное расположение, в результате из 200000 записей справочника выводится более 55000 найденных записей, кабелей с запрошенными ТУ на первых страницах нет (в самых релевантныхрезультатах), хотя в справочнике их сотни и поиск по "%ТУ 16.К71-310-2001%" сразу бы их нашел.
  Четвертая проблема в том, что некоторые поисковые запросы не просто не выводятся в топ, а не находятся в принципе. Например, в справочнике есть ряд приборов серии "Метран-300", поиск по данной серии, один в один входящей в наименование выводит почему-то только одну запись, также поиск по разным атрибутам выводит разные результаты. Например, в поле 1 и поле 2 есть точное соответствие поисковому запросу, поиск по полю один выведет одно количество, поиск по полю 2 другое количество.Пятая проблема, просили реализовать поиск с учетом латиницы и кириллицы, одинаковых по написанию. С учетом того, что решение идет в рамках "импортозамещения", была надежда, что отечественная компания уделить внимание проблеме с символами национального алфавита. Можно понять, когда западные компании игнорируют проблемы аборигенных нелатинских языков, но в русскоязычных справочниках это постоянная проблема, отечественный разработчик, который "в материале" мог бы понять важность проблемы и решить ее.
  Также обращались по возможностям настройки поиска в части применения кавычек. В современных поисковых системах давно уже используется полезный механизм точного поиска (содержит), путем заключения поискового запроса в кавычки, снова куча проблем и отказ в реализации.
  В SAP MDM аналогичный поиск настраивается по сочетанию полей и комбинируется с запросами по отдельным полям, реализован проще, но тем не менее дает релевантный результат. В целом этот ключевой модуль вызывает много вопросов, сложилось впечатление, что у разработчика нет компетенций в вопросе поисковых алгоритмов, предметную область справочников они не знают, предлагают нам самостоятельно ознакомиться с алгоритмами Elasticsearch и сказать какой алгоритм задать, проблема не решается уже более 3 месяцев. Очевидно слабое место системы.

  Слева форма поиска по умолчанию, справа с раскрытым меню поиска по группам атрибутов

• Нет возможности добавления атрибутов заявки.

  Платформа не позволяет гибко добавлять дополнительные атрибуты (поля), относящиеся к заявке, а не записи справочника.
  Например, в нашем случае таким транзакционным заявочным атрибутом выступал атрибут "Назначение заявки", в котором выбиралась цель ее заявления из небольшого вспомогательного справочника, исходя из которой применялись те или подходы к обработке заявки. Из-за данного ограничения в нашем случае практически полностью была дискредитирована идея внесения этого атрибута, так как основной механизм создания новой заявки это клонирование существующей записи, а при клонировании такженет настройки задать исключения, то есть какие атрибуты клонировать, а какие нет, тем самым у заявки он почти всегда предзаполнени пользователю нет нужды его осознанно заполнять.

  Общий вид карточки заявки

• Отсутствие возможности настраивать обязательность заполнения по триггерной логике.

  В системе не предусмотрена настройка обязательности заполнения атрибутов по триггерной логике (когда обязательность заполнения атрибута зависит от заполнения другого атрибута). Например, комментарий является обязательным при отправлении заявки на уточнение, а при публикации нет, в системе такое настроить нельзя, в итоге реализован "костыль", подставляющий пробел.

• Нередактируемые атрибуты никак визуально не отличаются от других полей.

  Устоявшееся и удобное решение, когда поля, не подлежащие редактированию представляются в интерфейсе отличными от других полей (как правило, используется бледная заливка или цвет шрифта) не реализовано в платформе. Также были проблемы с блокированием таких полей на ввод данных, в итоге даже пришлось скрыть такой атрибут, так как пользователи постоянно пытались его редактировать.

  Код КСУ НСИ формируется автоматически и не подлежит редактированию

• В системе не предусмотрена фильтрация заявокпо операциям создание/изменение/удаление/восстановление.

  В системе не предусмотрена фильтрация по какому-либо атрибуту (полю) или иной способ отбора заявок по типамопераций, осуществляемым в заявке (создание/изменение/удаление/восстановление записи). Например, в нашей практике запросы на изменение выполняются в приоритетном порядке, вычленять такие заявки глазами из общего пула крайне неудобно. По умолчанию в табличной форме они ничем визуально друг от друга не отличаются (в нашем случае мы реализовали доработку выделения запросов на изменение особым шрифтом, только это и спасает).

• Нет возможности настраивать для записей классификаторов и вспомогательных справочников применимость в других справочниках.

  Простыми словами, для записи справочника или узла классификатора невозможно задать признак, отвечающий за его отображение и возможность выбора (ссылки на него) в других справочниках. Например, MDM выступает мастер-системой для справочника единиц измерения, часть единиц измерения используется в сугубо специфических прикладных бизнес-процессах (например, для оценки технического состояния оборудования в системе ТОРО), такие специфические ЕИ хотелось бы заблокировать для применения в справочнике МТРиУ, где используются только учетные и закупочные ЕИ, но настроить такое стандартными средствами возможности нет. Деление на отдельные справочники однотипных сущностей также не целесообразно.

• Проблемы с разделением на понятия запрос на изменение и запрос на добавление записи.

  В системе некорректно реализовано понятие запрос на изменение и добавление при использовании функции клонировании, когда пользователь находит запись справочника, создает ее копию, вносит изменения и направляет ее надобавление в справочник. Такой сценарий система отрабатывает как запрос на изменение, хотяречь идет о добавлении новой записи по мотивам существующей.

• Сырая проработка фасетно-иерархических классификаторов.

  Сложилось впечатление, что фасетно-иерархические (онтологические) классификаторы появились в системе совсем недавно и никто из разработчиков толком не изучал пользовательский опыт и методологию применения таких классификаторов. Есть ряд конкретных замечаний: в системе невозможно привязывать одно свойство (атрибуткласса)к нескольким узлам классификации, сортировка свойств только по алфавиту, нет возможности добавления дополнительных параметров атрибута (например, параметр для сортировки, атрибут "Единица измерения" для свойств с числовыми характеристиками, псевдоним и т.д.),значения свойств добавляются только в отдельном интерфейсе администратора (в SAP MDM реализована функция добавления отсутствующих значений на лету, из формы кодирования записи), не оптимизирован интерфейс отображения свойств (ширина отображения названий атрибутов не регулируется, одно название свойства растягивается на несколько строк по одному слову, получается огромная зона, чтобы пролистать ее до основных атрибутов записей приходится много прокручивать).

  Отображение названия свойства в карточке записи: слева ЮниДата, справа SAP MDM

• У пользователя, обрабатывающего заявки нет возможности выбора механизма изменения - через заявку или прямые изменения.

  В платформе пользователю, ответственному за обработку заявок не предоставляется возможность выбора механизма изменения записей - через заявку или напрямую. В SAP MDM в тонком клиенте были реализованы заявки, в толстом можно было вносить изменения напрямую, в зависимости от конкретной цели и масштаба изменений активно использовались оба механизма. Прямые изменения использовались в основном для массовых изменений, в том числе чтобы не искажать статистику по реально поступившим и обработанным запросам.

• Запрос на изменение инициируется путем редактирования карточки записи.

  В системе реализован следующий механизм формирования запросов на изменение, - пользователь находит в справочнике запись, которую хочет изменить, сразу же в карточке записи в интерфейсе справочника без нажатия каких-либо функциональных кнопок начинает редактировать любой атрибут записи. После нажатия кнопки "сохранить" формируется черновик запроса, в верхнем углу при этом появляется надпись, что запись "на согласовании", далее пользователь должен перейти в интерфейс обработки заявоки отправить заявку на согласование. Реализация спорная, функциональная заметная кнопка "Изменить запись" был бы более понятна пользователям. Практика показала, что в примерно четверти случаев пользователи путают запрос на изменение с запросом на добавление по подобию существующей позиции (клонированием), просто начинают вводить в похожую запись требуемые им данные.

• Заявка декомпозирована на задачи.

  Особенностью системы является своеобразный механизм работы с заявками пользователей - заявки представлены в декомпозированном виде как отдельные задачи. Фактически под каждый шаг создается отдельный системный объект - задача, и пользователи работают именно с задачей. Для процессов ведения данных типа нашего эта дополнительная системная сущность только избыточно нагружает и усложняет модель данных и запутывает пользователей.

  Декомпозиция заявок на задачи, в примере 1 запись, 3 заявки на нее, состоящие из 7 задач.

Эргономика и интерфейспользователя

• Основной тип отображения данных Плитка.

  В платформе реализован весьма спорный и неинформативный вариант отображения записей и заявок - плиточное представление. Из такой плитки осуществляется переход в карточку записи или заявки. До недавнего времени это был единственный вариант представления записей и заявок. В рамках текущего проекта в платформу включили табличное представление, однако большинство функциональных кнопок(выделение заявок, пагинация, обновление страницы) остались в плиточной части интерфейса.

• Неудобная фильтрация и поиск заявок и записей, поисковые формы не хранятся в персональных настройках, их нельзя задавать в системных настройках.В системе реализован принцип единого интерфейса для обработки заявок пользователей и поиска по справочникам, то есть заявки на разные справочники и записи попадают в один универсальный интерфейс, без возможности разделить потоки на разные более специализированные интерфейсы. Эта универсальность серьезноухудшает эргономику отборов и фильтрации заявок и записей. Реализуется принцип раскрытия поисковых атрибутов, когда атрибуты для поиска появляются только после выбора ключевого значения (например, справочника). На практике Эксперт (Data Steward) вынужден при каждом входе персонализировать отображаемые атрибуты для поиска, так как в пользовательских настройках это не сохраняется.Настройка положения поисковых атрибутов в форме поиска не предусмотрена, операторы поиска также не настраиваются (безальтернативно задано "точное соответствие", хотя преимущественнотребуется "содержит"). Все это очень напоминает сказку про кощея, "На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке заяц, в зайце утка, в утке яйцо, в яйце игла, смерть Кощея". Ситуацию не изменяет и права на справочники, даже если у пользователя права на один справочник, каждый раз он должен его выбирать, настраивать нужные ему атрибуты и операторы. На мой взгляд это серьезный просчет, правильнее было бы одновременно поддерживать 2 стратегии - специализированную, выделение заявок по отдельным справочникамв отдельные интерфейсы, где все нужные атрибуты отображены по умолчанию и универсальную, один общий интерфейс, где можно смотреть все заявки, так как зачастую, либо есть специализация у пользователей и экспертов или поток заявок по некоторым справочникам пренебрежимо мал, чтобы жертвовать эргономикой в самой массовой части ради них.Сама поисковая форма имеет вертикальную ориентацию, что на мой взгляд также неудачное решение, если бы она располагалась горизонтально, все атрибуты помещались в один экран не было бы необходимости использовать прокрутку.

  

  Форма поиска по заявкам, выбор справочника (МТРиУ, изображение слева) приводит к появлению в самом низу поисковой формы возможности отбора по атрибутам данного справочника (изображение справа)

• Не настраиваетсярасположение блока атрибутов классификации.

  В карточке записи расположение блока с классификаторами выведено наверх и возможность управлять их положением не предусмотрена. Не для всех справочников такое решение хорошее, например, в справочнике Контрагентов используется классификатор ОКВЭД 2, заполнение которого необязательное, только по запросу пользователя, выводить такой атрибут в самый верх карточки нецелесообразно, как неключевой.
  Также стоит отметить, что наименования классов выводятся прописными буквами, а иногда регистр букв имеет значение (особенно когда задействованы аббревиатуры), перенастроить это возможности нет.
  В системе не предусмотрена возможность копирования кода и наименования класса из соответствующих атрибутов, то есть информацию при необходимости приходится перебивать, решение сомнительное.

  Верхняя часть карточки записи

• При назначении заявок не обновляется их перечень.

  Не проработана функциональность обновления перечня заявок с сохранением фокуса (последнего местоположения). Когда заявок становится много возникает задача анализа поступивших заявок с переходом по страницам, если в процессе анализа возникает необходимостьвзять заявку в работу, то после взятия система перекидывает на первую страницу, приходится снова возвращаться к месту, где остановился при взятии заявки в работу. При назначении заявки через пакетную операцию (одной или нескольких) фокус сохраняется, но при этом не происходит автоматического обновления перечня заявок, приходится нажимать кнопку обновить один или несколько раз, чтобы дождаться назначения. Не обновлять перечень заявок не получается, так как в системе реализован постраничныйвывод заявок, соответственно переход на следующую страницу это обновление, и какая-та часть следующей страницы перейдет на предыдущую тем самым выпадет из анализа. В SAP MDM применяется более удобное решение - заявки исчезают из пула при назначении, фокус сохраняется, а вместо страниц используется динамическая загрузка (когда достигается низ выборки, подгружается следующий фрагмент).

• В заголовки вкладок браузера не выводятся названия открытых разделов.

  Как правило, сценарий, когда пользователь работает только в одной вкладке системы не самый распространенный. Практика показывает, что для роли Эксперт (Data Steward) нужно около 3-4 вкладок под различные операции. В SAP MDM на вкладках браузера выводился заметный заголовок открытого раздела интерфейса, ориентироваться очень удобно. В решении Юнидата все вкладки неразличимы, а так как интерфейс работы с заявкой во вкладке "Запись" не отличается от карточки записи в справочнике, нередко пользователи начинают редактировать существующую запись справочника, случайно подавая запрос на изменение вместо запроса на добавление.

  Наименования вкладок портала SAP, отображаемые в браузере

• Нет возможности добавить несколько документов одним действием.

  В системе не предусмотрено добавление нескольких документов одним действием. Данную особенность нельзя назвать критичной для работы, тем не менее для пользователя такая функция стала привычной. Неудобная реализация данной функции демотивирует пользователей предоставлять всю документацию, если она представлена в нескольких файлах. В целом сложилось впечатление, что методики UX анализа практически не применяются при проектировании данной системы.

• Не проработаны текстовые поля для редактирования.

  Редактирование любого текстового атрибута сопряжено с рядом существенных неудобств, особенно для длинных текстовых полей.
  Во-первых, высота формы динамическая, что хорошо, но при этом высота атрибута не фиксируется по содержимому, а отображается в карточке с одной высотой при просмотре, а при входе изменяется на другую, получается анализируешь поле, видишь фрагмент который хочешь подправить, пытаешь его выделить, а фокус перескакивает на другой фрагмент.
  Во-вторых, постоянно всплывает форма вывода информации о содержимом атрибута, например, задумался на секунду и все, всплылаогромная форма и закрыла часть атрибута.
  В-третьих,чтобы начать редактировать атрибут в него надо войти, нажав плюсик или нажав мышью в поле, такая реализация исключает возможность вставки исторической информации из буфера обмена. Например, популярная у нас в практике программа Punto Switcher позволяет следить за 30 последними скопированными данными и вставлять их, вызывая форму выбора, система не позволяет вставить такие данные, что сильно мешает.

  Всплывающее окно при редактировании текстовогоатрибута

• Повышенная трудоемкость ввода данных в атрибуты(поля).

  Согласно проведенным сравнительным испытаниям ввод одних и тех же заготовленных данных в систему UniData MDM занял на 75-100 % больше времени (в зависимости от кейса), чем в SAP MDM. После оптимизации как пользовательскогоинтерфейса (UI), так и производительности системы, удалось снизитьзначение до 50 %.

• В форме выбора узла классификатора нет кнопки "раскрыть все".

  В форме выбора узла классификатора нет возможности раскрыть все уровни, что зачастую вызывает неудобства, для раскрытия каждого уровня нужно жать кнопку "Еще".

  Форма поиска и выбора узла классификатора для раскрытия всех уровней нужно нажать кнопки "еще" 4 раза.

• В системе не предусмотрено хранение атрибуты "Отчество" для пользователя.

  Причины понятны, продукт начинал свое движение на западе, тем не менее в России все-таки обращение просто по имени не принято, вызывает определенный дискомфорт при попытке связаться с пользователем. Напомню, решение продвигается как импортозамещающее.

  Администрирование и доработки.

• Проблемы с передачей данных в системы-получатели.

  С первого дня эксплуатации и по настоящий момент наблюдаются постоянные проблемы с передачей записей в системы-получатели, пользователи регулярно обращаются в службу поддержки с обращениями, что их заявка была отработана, но в их локальную систему изменения не реплицировались. Трудно сказать, в чем причина, за все время эксплуатации SAP MDM проблемы были точечными и быстроустранимыми, здесь же проблема на протяжении нескольких месяцев.

• Модуль подписки и публикации (PubSub) не позволяет задавать id сообщения на пакет записей.

  Например, в нашем ландшафте есть "тяжелая" система-получатель, настройки которой позволяет принимать 1 пакет раз в 4 минуты. SAP MDM позволяет формировать пакеты по несколько записей, в Юнидата MessageID задается на запись, а не пакет. На практике это выливается в проблему прогрузки достаточно массовых изменений через интеграционную шину, например, чтобы передать в упомянутую систему изменения по 1000 записей понадобится 4000 минут.В самом модулеPubSub нет возможности важных для работы атрибутов (например, основного идентификатора, применяемого в системе, так как с GUID мы не работаем, исполнителя для понимания в чьей сфере ответственности задача по исправлению ошибки, нет расшифровок ошибок от систем-получателей, они только в почтовых сообщениях и еще ряд неудобств).

  Интерфейс модуля подписки и публикации

• Качество программного кода.

  В целом судить о качестве кода проблематично, так как это интеллектуальная собственность разработчика, закрытая для пользователя, однако косвенно некоторые вопросы всплывали, например, для переименования сущностей в системе необходимо вносить изменения во все экранные формы, где они используются. В более зрелых решениях переименование сущностей как правило осуществляется через единую точку (например, в БД), с помощью аналогичных подходов осуществляется поддержка нескольких языков.

• Трудоемкость доработок на 30-50 % выше аналогичных в SAP MDM.

  В данном пункте стоит упомянуть, что поддержка SAP MDM осуществлялась своими силами, а поддержка платформы Юнидата осуществляется через подрядчика, возможно это накладные расходы, формируемые подрядчиком, тем не менее факт таков, трудоемкость в человеко-часах как правило выше на 30-50 % чем в SAP MDM.

Выводы*

Конечно было бы несправедливым сказать, что система абсолютно плоха и не проработана, в ней есть свои плюсы, например, реализация на базе свободно распространяемого программного обеспечения, современный дизайн и лицензионная политика, где метрикой выступает количество основных справочников (в терминологии платформы реестров), что позволяет безболезненно подключать новые системы-получатели без оглядки на количество пользователей и увеличение числа заявок.

Будет уместным добавить, что часть описанных замечаний будет устранена в относительно ближайшей перспективе. Также вероятно, что часть проблем возникла из-за наличия промежуточного звена между заказчиком и разработчиком, в связи с этим приношу свои извиненияза возможные неточности, которые могут быть вызваны "испорченным телефоном" или малым опытом работы с платформой со стороны специалистов подрядчика.

Сложилось общее впечатление, что при разработке данной системы за расчетный случай брались иные справочники и модели их ведения. Выглядит все так, будто на изначально заложенные сильно упрощенные универсальные модели пытаются накрутить более сложные модели и они не очень хорошо вписываются в архитектуру. UX-дизайн является слабым местом, в то время, когда в мире давно уже наметился тренд на интуитивно понятную реализацию, когда обучающие материалы практически не нужны, разработчик все сильно усложнил, без инструкций хорошо знающий свой бизнес-процесс пользователь никогда не разберется.

Сказывается и малая практика внедрения данной платформы под задачи ведения промышленных справочников МТР. Насколько я понял, помимо нашей Группы компаний, чуть раньше, подобный проект стартовал в ОАО "РЖД", других аналогичныхвнедрений не было. Предстоит еще много внедрений и доработок, чтобы по функциональности и удобству приблизиться к SAP MDM или иной зрелой системе.

Резюмируя, посоветовал бы не спешить с внедрением данной платформы, а если все-таки решились, то дотошно прописывать в техническомзадании все требования, даже если кажется, что некоторые из них должны быть в любой MDM системе по умолчанию.

Александр Черевичин, специалист НСИ.

*Мнение автора может не совпадать с мнением Заказчика (работодателя).