Первая часть статьи доступна по ссылке:

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

   Управление мобильными устройствами и приложениями (MDM) позволяет  применять разнообразные политики безопасности для мобильных устройств, таких как смартфоны и планшеты. Цель этих политик заключается в установлении уровней безопасности адекватных для обеспечения безопасной обработки корпоративных и персональных  данных при подключении к сетевым ресурсам предприятий, корпораций и банков. Пример такого подхода предложен в ПЗ, опубликованном в документе [5].

   Этот ПЗ предоставляет базовый набор функциональных требований безопасности (SFR) для системы MDM, которая является объектом оценки (ОО). МDМ - система является лишь одним из компонентов развертывания корпоративных мобильных устройств. Другие компоненты, такие как платформы мобильных устройств, которые обеспечивают соблюдение политик безопасности, а также сервера управления доступом к сети, находятся вне области данного документа. МDМ - агент, который находится в центре внимания этого ПЗ, установлен на мобильном устройстве, как приложение или является частью его ОС. МDМ - aгент устанавливает защищенное соединение с MDM-сервером и управляется администратором безопасности.  Магазин приложений (MAS) сервера для загрузки и установки приложения всего предприятия организуется централизованно. МDМ - aгент должен тесно взаимодействовать  или быть частью платформы мобильного устройства для установления политики безопасности и выполнения запросов о состоянии устройства. Мобильное устройство, в свою очередь, имеет свои собственные требования безопасности, указанные в мобильном и базовом ПЗ [6,7] на предмет которых мобильное устройство должно быть оценено либо одновременно  или до оценки МDМ - агента. Если МDМ - агент является частью ОС мобильного устройства, агент может представлять несколько интерфейсов (API) для настройки мобильного устройства, таких как локальный интерфейс и интерфейс удаленного доступа. Агенты, соответствующие этому профилю должны по крайней мере  предложить интерфейс с доверенным каналом, который является частью МDМ - системы. Совместимые агенты могут также предложить другие API, а также новые аспекты конфигурации этих приложений.

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

•        анализ функциональной спецификации, спецификации интерфейсов,   эксплуатационной документации;

•        независимое тестирование;

•        наличие проекта верхнего уровня;

•        анализ стойкости функций безопасности;

•        поиск разработчиком явных уязвимостей;

•        контроль среды разработки;

•        управление конфигурацией.

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

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

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

В заключение отметим проблемы безопасности, связанные с многообразием API  современных ОС.

Практически все операционные системы, включая мобильные (UNIX, Windows, OS X, Android, iOS,Windows Phone и т. д.) имеют API в качестве множества системных вызовов, с помощью которых пользователи (программисты) могут создавать приложения для этих операционных систем. В индустрии программного обеспечения общие стандартные API для стандартной функциональности имеют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов (в том числе и для злоумышленников). С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности  – написание «промежуточных» API (API графических интерфейсов), создание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой, введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах и т. д.

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

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

Основными проблемами существующих многоуровневых систем API, таким образом, являются:

• Сложность переноса программного кода с одной системы API на другую (например, при смене ОС);
• Потеря функциональности при переходе с более низкого уровня на более высокий, т.к. каждый уровень API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

Список использованных источников

1. Сафин, Л.К. Исследование информационной защищённости мобильных приложений / Л.К. Сафин, А.В. Чернов, Я.А. Александров, К.Н. Трошина // Вопросы кибербезопасности. – 2015. - №4 (12). – С. 28 – 36.

2.  Common Criteria for Information Technology Security Evaluation, Part (1,2,3): Introduction and General Model, CCMB-2012-09-(001,002, 003) Version 3.1 Revision 4, September 2012.

3. Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, CCMB-2012-09-004, Version 3.1, Revision 4, September 2012.

4. Бетелин, В.Б. Профили защиты на основе «Общих критериев». Аналитический обзор/ В.Б. Бетелин, В.А. Галатенко, М.Т. Кобзарь, А.А. Сидак, И.А. Трифаленков// Бюллетень JET INFO – 2003.

5. Extended Package for Mobile Device Management Agents Version 2.0 /3.1, PP_MDM_AGENT_v 2.0//NSA, 2014-12-31.

6.Protection Profile for Mobile Device Fundamentals Version 2.0 /3.1, PP_MD_v2.0//NSA, 2014-09-17.

7. Protection Profile for Mobile Device Management Version 2.0 /3.1, PP_MDM_v2.0//NSA, 2014-12-31.

      МНОО  «МАИТ», г. Минск.

Отправить статью в социальные сети, на печать, e-mail и в другие сервисы: