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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В то же время часто возникает необходимость решить обратную задачу — запретить или хотя бы отложить обновление мобильной ОС. Запрет или отсрочка обновления необходимы, например, чтобы разработчики смогли адаптировать мобильные приложения для новой версии ОС. Минорные обновления внутри одной мажорной версии ОС, например с Android 8.1 на Android 8.2, обычно не требуют доработки приложений, но при мажорном обновлении c iOS 13 на iOS 14, например, они могут понадобиться. Запретить обновление ОС можно только на 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)

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

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

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

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

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

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

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

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