Крупным корпоративным заказчикам, использующим систему DIRECTUM, также требуется мобильный доступ, но серьёзным препятствием на пути применения мобильных технологий встает вопрос обеспечения информационной безопасности.
Так получилось и у нас с одним из Заказчиков, который хотел использовать приложение HopUp для DIRECTUM, но служба ИБ поставила ряд условий по обеспечению защиты передаваемых данных.
Для достижения цели нам пришлось серьёзно погрузиться в вопрос обеспечения информационной безопасности на мобильных устройствах, и с помощью наших давних партнеров из «Ассоциации руководителей служб информационной безопасности» и «НИИ СОКБ» мы поставленные нам условия выполнили и готовы поделиться наработками с сообществом DIRECTUM Club и с партнерами, которые продвигают на рынке мобильные приложения.
Для обеспечения информационной безопасности при использовании мобильных устройств необходимо применение как организационных, так и технических методов. Организационными методами как правило являются:
Но мы на них подробно останавливаться не будем, потому что это тема для целой отдельной статьи, скажу лишь что в рамках соблюдения условий этого проекта нам нужно было нейтрализовать следующие угрозы:
Конечно реализовать нейтрализацию всех этих угроз в рамках нашего приложения нам не под силу и мы разрабатывали решение совместно со специалистами по ИБ из компаний наших партнеров.
Мы выработали 3 варианта обеспечения ИБ, отличающихся степенью защиты.
Минимально необходимыми требованиями к обеспечению ИБ являются:
Данные требования реализованы в нашем приложении HopUp для DIRECTUM по умолчанию – взаимодействие между клиентскими приложениями и серверной частью происходит с шифрованием всех передаваемых данных симметричным алгоритмом шифрования с 256 битным ключом (AES-256).
Минимальный набор требований устраивает очень многих Заказчиков, но к сожалению, не всех. Поэтому нами были разработаны ещё два решения.
Данный вариант помимо шифрования трафика по ГОСТ-овым алгоритмам предусматривает передачу данных по VPN каналам связи поверх беспроводных интерфейсов Wi-Fi или GPRS/ Edge/ 3G/ LTE.
Данное решение требует развертывания Программно-аппаратного комплекcа ViPNet Coordinator и использования на мобильных устройствах ViPNet Client и схема работы решения в таком случае будет следующей:
Но даже данный вариант решения не удовлетворил нашего Заказчика, поэтому мы проработали решение с еще более глубокой степенью обеспечения информационной безопасности мобильного приложения HopUp.
В данном варианте обеспечения безопасности MDM-система SafePhone обеспечивает защиту устройства по принципу контейнера («песочницы»). Функции защиты осуществляются с помощью установленного на мобильном устройстве приложения SafePhoneClient, которое пользователь не может ни остановить, ни удалить.
При этом реализуются следующие основные функции:
Система управления SafePhone имеет сертификат соответствия ФСТЭК России № 3005 от 24.10.2013г.
Архитектура решения становится более сложной, более дорогой, но обеспечивает нейтрализацию всех приведенных выше угроз благодаря:
Успешное применение данного решение было подкреплено нами получением соответствующего сертификата.
Теперь информационная безопасность больше не является преградой для использования в корпоративном секторе мобильного приложения HopUp для DIRECTUM.
"шифрование всего передаваемого контента по алгоритму AES-256." я правильно понимаю, что вы имеете ввиду HTTPS?
Нет, не правильно понимаете.
Все данные до их отправки шифруются симметричным алгоритмом шифрования с длинной ключа 256 бит - это и есть AES-256. При этом вам никто не мешает дополнительно использовать HTTPS.
В принципе решение самодостаточно для использования его по открытым каналам связи.
Поддержу вопрос Михаила.
Все данные до их отправки шифруются симметричным алгоритмом шифрования
А как клиент и сервер обмениваются ключами шифрования?
Пока обмена ключами нет (прорабатываем этот вопрос, чтобы сам процесс обмена был также безопасен).
Ключи генерируются на лету на основе нескольких динамических параметров.
Каких именно по понятным причинам озвучивать не буду.
То есть со временем планируется реализовать свой вариант SSL.
Ключ зашит в приложениях, код которых легко можно получить декомпиляцией (.NET, Java). Само приложение доступно публично.
Какие меры предпринимаются, чтобы хоть как-то усложнить задачу получения ключа злоумышленниками?
С интересом прочитал заметку. Особенно стала любопытна реализация шифрования в варианте 1, так как самому приходилось с такими задачами сталкиваться.
Положа руку на сердце, давайте признаемся - никакой динамической генерации ключей нет :) Они заданы статически и лежат на виду. Для выяснения этого нужно 5 минут и совсем немного знаний об Android.
Вижу добавление случайных данных к сообщениям, чтобы при передаче одного и того же содержимого зашифрованная часть сообщения не была одной и той же. Часто ли у вас полностью повторяется значение свойства "Data" в SOAP? Думаю, нет, так что и выгода от передачи в каждом пакете случайных 20 символов непонятна. Любопытно, для чего выбираете их из ограниченного набора, а не просто случайные байты?
Кстати, для улучшения производительности я бы посоветовал при обращении к шифрованию и расшифрованию не инициализировать каждый раз keySpec и ivSpec. Это позволит расходовать чуть меньше заряда батареи, да и фрагментацию памяти уменьшит.
В завершение хочу добавить позитивную нотку. Меня впечатляет форма подачи материала и общий позитивный настрой статьи :)
Станислав, Михаил!
Да действительно уточнил у разработчиков - динамические ключи планировались, но не реализовывались. Одной из причин как раз и явилась бесполезность (т.к. вскрыв исходный код можно легко понять как именно генерируется ключ).
Коллеги, именно по этим причинам мы и предлагаем сейчас Заказчикам 3 варианта.
Большинство удовлетвориться вариантом 1, а тем кому нужен уже совершенно другой уровень информационной безопасности мы предлагаем 2-ой и 3-ий варианты.
Очень интересная тема. Валерий, не рассматривали, как вариант, использование CheckPoint? Если да, то можете ли поделиться результатами изысканий?
Руслан, с CheckPoint не пробовали работать, потому что по условиям Заказчика решения по ИБ должны были быть строго российской разработки со всеми сертификатами. А у вас есть с CheckPoint какой-то опыт работы?
Руслан, Check Point это набор программно-аппаратных средств для организации инфраструктуры сетевого взаимодействия, и не ограничивается одним конкретным примером развертывания и зависит от требований конкретной организации и закупленного ПО.
К примеру для организации VPN, Check Point предоставляет решения Check Point Mobile VPN и IPSec VPN, применение которых в Android сводится к использованию Capsule VPN (пруф: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk84141). Capsule VPN обеспечивает перенаправление всего трафика системы через настроенный VPN-туннель. Соответственно отладку VPN на Check Point можно организовать "подручными средствами". К примеру через подключение RDP (http://densotac.com/remoteaccess/android/).
Но также, Вы можете легко проверить работу и решений DIRECTUM, к примеру Jazz 1.2 позволяет подключиться к системе без необходимости приобретения серверной лицензии, а дистрибутив сервера входит в поставку DIRECTUM. Как говорится - всё необходимое под рукой.
Не могу не отметить, что использование ГОСТ-алгоритмов в Check Point (настройка), скорее всего, на мобильных устройствах может вызвать проблемы .
Руслан, в дополнении хочу отметить, что Check Point предоставляет богатую документацию по организации использования мобильных устройств в сети организации (общая информация, примеры развертывания), а так же позволяет интегрироваться с MDM-решениями (подробнее), но, к сожалению, среди MDM-вендоров нет представителей из России.
Насколько мне известно Check Point предоставляет сертифицированные решения: пруф 1, пруф 2.
Руслан, нам предоставилась возможность проверить работу мобильных решений на CheckPoint. Об этом упомянули в статье Настройка VPN для работы DIRECTUM Jazz.
Авторизуйтесь, чтобы написать комментарий