Защита мобильных устройств по 117 приказу ФСТЭК России: как читать документ и не терять волю к жизни

Привет, Хабр!

Мы вернулись через четыре года. Зимой мы уже отметились в блоге Samsung статьёй для тех, кто думает сделать свой MDM. Теперь решили возродить свой блог. Пока на три месяца, а дальше посмотрим. 

Мы всегда стараемся доходчиво объяснять сложные вещи, и поэтому начать вторую жизнь нашего блога решили с разбора свежего документа от ФСТЭК России в части защиты мобильных устройств. 

Из статьи вы узнаете, что теперь BYOD для госорганов – это не принеси (bring), а купи (buy) себе устройство для работы, и что MDM для мобильных устройств теперь нужен не меньше, чем антивирус. На самом деле даже больше. Почему? Давайте под кат!

Контекст

Есть государственные информационные системы. Сокращённо ГИС. В ним относятся Госуслуги, ЕМИАС и др. системы. ГИС нужно защищать. Как именно защищать написано в документах ФСТЭК России. Раньше для этого был 17 приказ. С 1 марта 2026 действует новый приказ – 117.

Новый 117 приказ ФСТЭК России распространяется на любые информационные системы госорганов и государственных организаций, а не только на ГИС. Это значит, что под него попадает электронная почта, СЭД. Даже СКУД на входе в детский сад.

Сам приказ не раскрывает, какие требования нужно выполнить. Требования “раскрылись” 12 апреля 2026 года ФСТЭК России в методическом документе. Аж на 184 страницы…. Документ такой большой, потому что охватывает все компоненты информационных систем от ЦОД до интернета вещей. Мы в статье попытаемся раскрыть лишь требования к защите мобильных устройств – это наша родная тема с 2010 года. 

⚠️ Achtung 

Если вы думаете, что вы не ФГУП и не государственная компания, поэтому требования 117 приказа вас не коснутся, нам придётся вас расстроить. Специалисты ФСТЭК России говорят, что возьмут этот документ за основу при обновлении требований к защите КИИ и персональных данных (ПДн). Поскольку каждый работодатель обрабатывает ПДн своих сотрудников (как минимум), то не ровен час, что эти требования коснутся большей части коммерческих организаций 🙈.

Купи себе устройство для работы или BYOD по-русски

Текст 117 приказа ФСТЭК России начинается с двух вводных разделов. Требований они не содержат, поэтому мы их пропустим. Перейдём сразу к третьему разделу с мероприятиями.

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

Защите мобильных устройств посвящён раздел 3.7. Там всё достаточно традиционно – доступ предоставлять только тем, кому он нужен, мобильные устройства нужно защищать и т.д. 

Отдельно выделим два момента.

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

Перевод автора: если у вас больше 10 мобильных устройств, должен быть MDM 🎉

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

Здесь интереснее, поэтому перевод будет гоблинским.

В мире распространена концепция BYOD. Дословно переводится как “принеси своё устройство” (bring your own device). Логика такая: компания не покупает сотрудникам телефоны, а сотрудники используют свои. На личных устройствах с помощью MDM создаётся контейнер для служебных данных. Сотрудник не может передать информацию из рабочего контейнера в личный мессенджер и так далее. При этом работодатель не имеет доступа к личным данным пользователя за пределами контейнера. Такой вот вин-вин.

Из требований 117 приказа следует, что теперь BYOD в России – это не принеси своё устройство на работу, а купи себе ещё одно. Английское сокращение то же самое (buy вместо bring), а суть другая. Почему нужно купить ещё одно устройство? Потому что иначе выполнить требования не получится. Часть требований должны выполняться средствами сертифицированной операционной системы. Вот только потребители устройства на таких ОС для себя почему-то не покупают 🤷.

Остаётся ждать, когда кто-то сертифицирует российский форк AOSP, но и в этом случае вряд ли кто-то поменяет на него свой iPhone. Поэтому остаётся только два варианта – купить себе телефон на сертифицированной ОС или не использовать личное устройство для работы. Ух, богатый выбор. 

Защита мобильных устройств

Переходим к требованиям по защите мобильных устройств. В документе их можно быстро найти по сокращению ЗМУ.

ЗМУ.1 Идентификация и аутентификация

Идентификацию и аутентификацию в документах ФСТЭК России принято сокращать как ИАФ. По этому сокращению удобно найти общие требования, которые распространяются и на мобильные устройства.

Для начала нужно разделить ИАФ на несколько категорий: 

1. ИАФ устройств. Например, MDM выписывает устройству сертификат. Устройство использует его для аутентификации в корпоративном Wi-Fi 802.1x. Примерно про это написаны две меры ИАФ.2 и ИАФ.4, но обе необязательные, поэтому их можно вынести за скобки. 

2. ИАФ доступа пользователей к мобильному устройству. Это когда вы вводите пин-код или прикладываете палец к экрану, чтобы разблокировать свой телефон. Требования к этому виду ИАФ перечислены в мере ЗМУ.1. 

3. ИАФ доступа пользователей к информационным ресурсам. Это когда вы логинитесь со своего устройства в какую-то систему. Требования к такой ИАФ перечислены в мерах ИАФ.1 и ИАФ.3. 

Далее кратко перескажем основные требования к ИАФ пользователей (не устройств). Под номерами К1, К2 и К3 зашифрованы классы систем, где К3 самый лайтовый, а К1 самый защищённый.

Итак, для входа на телефон или планшет нужно использовать пароль. Требования к этому паролю:

1. Длина 6 символов для К3. Для К2 и К1 – 10 символов. Требования к алфавиту отсутствуют, поэтому можно использовать числовые пароли (пин-коды).

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

3. Срок действия пароля – 30 дней.

4. Длина истории паролей – 12. В смысле пользователю запрещено использовать 12 своих последних паролей. 

Всё перечисленное должно быть реализовано в мобильной ОС. Настроить поможет MDM 😉

Для доступа к информационным ресурсам требования такие:

1. Для класса К3 достаточно парольной аутентификации. Пароль из 12 символов. Обязательные большие, маленькие буквы и спецсимволы. Через пять ошибок ввода блокировка устройства или учётки на 15 минут. Менять пароль каждые 90 дней. Пароль при вводе, естественно, заменять на звёздочки и не отображать. 

2. Для классов К2 и К1 – усиленная аутентификация. Здесь подойдут программные аутентификаторы или отправка кодов в пушах, SMS или flash call. Flash call – это когда одноразовым кодом являются последние цифры входящего номера. Это дешевле, чем отправлять вам SMS.

3. Для админов К1, которые зачем-то решили подключиться со служебных мобильных устройств – усиленная аутентификация с использованием “одноразового пароля, создаваемого с применением устройства аутентификации, находящегося во владении пользователя”. Тут то ли про аппаратные OTP токены, то достаточно программного OTP на личном телефоне (личный телефон, наконец, пригодился!). В любом случае кейс доступа админа с телефона достаточно редкий, чтобы на него закладываться при проектировании системы. Если админу вдруг сил нет как понадобилось подключиться с телефона, есть УПД.9, о которой мы расскажем в следующем разделе.

ЗМУ.2 Управление доступом

У управления доступом исторически есть ещё одно типовое сокращение – УПД. 

В документе УПД посвящён отдельный раздел. Большая часть перечисленных в нём требований не имеют каких-то особенностей для мобильных устройств. Требования кратко такие:

1. УПД.1 – УПД.4 – нужно выбрать модель управления доступом (ролевая, мандатная, атрибутивная), затем реализовать авторизацию с её помощью. Не забыть про принцип наименьших привилегий. Если ошибок входа много, учётку надо заблокировать.

2. УПД.5 – УПД.6 необязательные предупреждения и оповещения пользователя. Можно пропустить.

3. УПД.7 – ограничить число параллельных сеансов в системах класса К2 и К1. Для К3 делать ничего не нужно.

4. УПД.8 – заблокировать экран мобильного устройства при неактивности. 

5. УПД.9 – выделить и задокументировать действия, которые разрешены без аутентификации. Например, доступ к какой-то публичной справочной информации. Ещё в приказе упоминается документирование способов обхода мер ИАФ, когда админы восстанавливают информационную систему из пепла. Но об отсутствии аутентификации в этом случае речи скорее всего не идёт, потому что даже IPMI работает по логопасу. Тут скорее речь о том, что требования к аутентификации при “пожаре” упрощаются – если в серверной что-то гулко упало, допускается использовать служебный логопас вместо 2FA. 

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

ЗМУ.3 Обеспечение целостности

Мобильная операционная система должна контролировать собственную целостность. MDM ей в этом поможет. Например, Android сам не сможет отловить все признаки root. А если злоумышленник использует продвинутые хак-тулы типа Frida, которая может заразить приложение без root – с таким контролем целостностности точно без MDM не обойтись. 

Что ещё нужно делать:

1. Запретить функции разработки и отладки. Правда почему-то только в К2 и К1. Мы рекомендуем запрещать эти функции для всех пользователей.

2. Заблокировать мобильное устройство, если нарушена его целостность. Например, если обнаружены признаки программного взлома. Нужно только в К1. Мы в этом случае рекомендуем не просто блокировать устройство, а пытаться немедленно удалить с него все корпоративные данные и настройки. Если устройство взломали, по-хорошему нельзя доверять ни функции блокировки, ни функциям очистки данных, но всё же лучше пытаться стереть чувствительные данные, чем просто блокировать устройство.

ЗМУ.4 Защита данных

Требования к разработчикам мобильных приложений:

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

2. Не копировать данные в публичные облака. Например, не давать сотруднику добавлять в служебное приложение личные учётные записи на Яндексе или ещё в каком-то облаке, куда потенциально могут попасть резервные копии корпоративных данных.

3. Шифровать данные при передаче по ГОСТ 🚧. Не хотите использовать библиотеки ГОСТ в приложении, берите ГОСТовый VPN.

Требования к MDM и операционной системе:

1. Сбрасывать устройство к заводским настройкам после 10 ошибок ввода пин-кода. В документе требования относится только к системам класса К1. Мы рекомендуем делать это всегда. Чтобы 10 раз подряд неправильно ввести пароль, нужно еще постараться или ьтыб в малх. После пятой попытки начинаются блокировки входа по времени. Чтобы ввести пароль 10 раз неверно, нужно делать это несколько часов подряд. Любой сознательный пользователь за это время свяжется с админом MDM, чтобы тот дистанционно сбросил ему пароль.

2. Запретить резервное копирование в публичные облака. MDM может запретить службу резервного копирования или запретить пользователю добавлять на устройство личные аккаунты Mail.ru, Google и других сервисов, куда можно слить служебные данные.

ЗМУ.5 Антивирусная защита

Эксперты спорят, нужен ли мобильный антивирус или нет. ФСТЭК в этом споре не участвует. Служба требует, чтобы антивирус “наличествовал” и выявлял malware и реагировал на него. Вот только выполнить эти требования на мобильных ОС, увы, можно только формально. 

Полного доступа к диску у антивируса нет, поэтому он не сможет проверить ни системные файлы, ни содержимое песочниц приложений. По действиям при реагировании тоже есть вопросы. Допустим, антивирус определил в одном из приложений на устройство что-то вредоносное, что он сможет с ним сделать? Антивирус же не MDM – он не может удалить приложение с устройства. Только уведомить пользователя или администратора. Ну, это тоже надо.

Как именно антивирус определяет вредоносные приложения в кругах ИБ спрашивать не принято. Доступа к исполняемым файлам у антивируса в мобильных ОС обычно нет. Остаются имена пакетов и подписи разработчиков. Чтобы найти по ним malware, где-то должен быть реестр известных вредоносных приложений. Причём разработчики этих приложений не должны знать, что они находятся в этом реестре. Иначе они бы сменили и имя пакета, и свою подпись – на это хватит пары часов.

Даже если вынести упомянутые выше ограничения за скобки, то к работе антивируса на мобильных устройствах, где реализованы другие обязательные меры защиты, всё равно есть вопросы:

1. На мобильные устройства должен устанавливаться только явно разрешённый и проверенный администратором софт согласно ЗМУ.6.

2. Если какое-то нехорошее приложение как-то пробежало мимо администратора на устройство, то если выполняется требование ЗМУ.4 и приложения хранят служебные данные только у себя в песочницах, то единственный способ до них добраться – это взломать устройство. Но если его взломали, наступает контроль целостности ЗМУ.3 и устройство блокируется или очищается. 

Антивирусу при таких условиях остаётся “ловить” на устройствах вредоносные файлы в общих каталогах. Такие файлы не могут навредить мобильному устройству, потому что есть “песочницы”, контроль целостности и запрет установки приложений пользователем. Но такие файлы теоретически могут нанести вред ИТ-инфраструктуре, если пользователь их в неё отправит. Поскольку на входе в такую инфраструктуру есть потоковые сканеры типа почтового антивируса полезность поиска таких файлов на мобильных устройствах вызывает вопросы. Антивирус в этом случае – привычный ритуал. Поэтому если нет разницы и антивируса на мобильном устройстве не избежать, берите самый дешёвый. Будет дёшево и сердито.

ЗМУ.6 Контроль приложений 

Только разрешённый софт. На устройстве должен быть софт, который разрешил администратор. Другого софта на устройстве быть не должно. 

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

Мы в SafeMobile понимаем, что доступ к экрану пользователя – это чувствительная тема. Поэтому в нашем продукте можно гибко настроить, что администратор с конкретной ролью может сделать с устройством удалённо. Не все администраторы имеют доступ к этой функции. Часть админов могут получить доступ только на просмотр, часть – на подключение к экрану с подтверждением пользователя. Но только избранные и самые безгрешные доверенные админы могут подключаться к экрану без подтверждения – да, так тоже можно, но лучше этим не злоупотреблять.

Минимальные права приложений на устройстве. Для примера поделюсь личным опытом. Купил китайский телефон. Встроенное приложение “Галерея” не давало мне посмотреть снятое мной видео пока я не дал ему доступ к журналу сообщений и звонков. Безопасно ли это? Не думаю. То же самое с корпоративным софтом. Приложение при установке и в процессе работы запрашивает у операционной системы определённые полномочия – доступ к галерее, геолокации, Bluetooth и с десяток других. 

Обычно разработчики мобильного софта не заморачиваются на тему наименьших привилегий и просят “про запас” все разрешения, которые только можно получить. А вдруг в следующей версии они нам понадобятся? Тут есть два пути: первый – предъявить требования к разработчикам и потом внимательно следить за их выполнением (сложно, долго и дорого), второй – отобрать лишние полномочия у приложения с помощью MDM. Просто и быстро 👍

SafeMobile позволяет гибко управлять разрешениями. Можно как разрешать их по “белому” списку, так и запрещать по “чёрному”. У настройки разрешений с помощью MDM есть дополнительный плюс – приложение получит разрешения сразу при установке и ему не нужно будет запрашивать их у пользователя. В результате пользователь не может не дать нужное разрешение или отозвать его у приложения в процессе работы.

ЗМУ.7 Ограничение и контроль функциональности

Требование сводится к управлению интерфейсами мобильного устройства по принципу наименьших привилегий. Например, устройство должно работать только по вайфай или по проводу (например, киоск для самообслуживания или терминал электронного голосования), тогда на нём стоит заблокировать мобильную связь. Если для работы не нужен Bluetooth, запретите его и пользователь не сможет с его помощью делиться файлами с устройства. В вашем приложении есть функция фото и видео съёмки, тогда пользователю скорее всего не нужны штатная камера и галерея. Если их не будет, то пользователь на забьёт диск личными фотками и видео так, что на устройство нельзя будет установить обновление софта или ОС – так случается достаточно часто.

ЗМУ.8 Определение и контроль геопозиции

Какое отношение местонахождение устройства имеет к безопасности? Непростой вопрос. Вероятно, поэтому мера не обязательна.

ЗМУ.9 Регистрация, анализ и реагирование на события безопасности

Нужно определить события безопасности (РСБ.1) с учётом специфики мобильных ОС:

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

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

В качестве примера состава событий безопасности для мобильных устройств можете взять документ с описанием событий, которые SafeMobile передаёт в Syslog, у нас на сайте.

Дальше кто-то должен события безопасности анализировать (РСБ.2). На мобильном устройстве должно быть правильное время (РСБ.3). События безопасности нужно хранить в течение заданного времени (РСБ.4). Если событие безопасности не получилось сохранить, уведомьте админа, он разберётся (РСБ.5).

Для выполнения требования РСБ.3 рекомендуем настраивать системное время на мобильном устройстве с помощью MDM – по данным сотового оператора или корпоративного NTP-сервера.

Что такое мобильная ОС?

Завершая разбор документа, смотрим на определение мобильного устройства из Приложения 1:

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

Посмотрим, что про себя пишет Astra Linux Mobile (длину тире и кавычки-ёлочки приводим как в первоисточнике):

Astra Linux Mobile — это не отдельная операционная система, а та же Astra Linux Special Edition, функционирующая в режиме «Мобильный».

Из этого следует, что Astra Linux Mobile – это не мобильная операционная система. Значит устройства на ней нужно защищать как десктопы и ноутбуки (в терминах 117 приказа – конечные устройства). Причина простая – если на планшете полноценная ОС, то её можно и нужно защитать “по полной”, без ограничений, которые есть у мобильных ОС. 

🤔 Для справки

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

Что делать, если вам нужно защитить мобильные устройства по 117 приказу в 2026 году

Всем госкомпаниям придётся уже до конца 2026 года отчитаться во ФСТЭК России о выполнении требований. Мы понимаем, что требования вышли месяц назад и бюджета на MDM в этом году может и не быть. Поэтому с учетом нежданного снега в апреле предлагаем бесплатные годовые лицензии в проектах до 100 устройств. Проще всего воспользоваться сервисом из нашего аттестованного облака. В этом случае вам не нужно будет тратить ресурсы на сопровождение серверов MDM в вашей ИТ-инфраструктуре.

 Чтобы воспользоваться предложением, напишите нам на sales@safe-mobile.ru и сообщите менеджеру кодовую фразу “госам сто MDM бесплатно”.