Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

Как обезопасить компанию от взломов? Ответом служит словосочетание «корпоративная мобильность».

Корпоративная мобильность – это подход к работе, при котором сотрудники могут выполнять свою работу из любого места, используя различные устройства и приложения [2].

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

Самой большой формой представления корпоративной мобильности считается решение MDM – Mobile device management.

Mobile device management (MDM) – это тип ПО, используемое ИТ-департаментом для мониторинга, управления и обеспечения безопасности корпоративных мобильных устройств сотрудников, используемых в организации, с разными мобильными операторами связи на различных мобильных операционных системах. Исследовательская фирма «Гартнер» дает определение MDM как «набор продуктов и сервисов, позволяющий организациям использовать и поддерживать корпоративные приложения на мобильных устройствах, таких как планшеты и смартфоны, включая возможность частного пользования, для внедрения новых регулирований и поддержки нужного уровня контроля ПО на различных платформах» [3].

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

Основная суть MDM: на мобильное устройство ставится агент, на который сервер отправляет профили/команды. Более безопасным решением является локальное развертывание.

Проанализировав все возможные события, стало понятно, что основными выгодами от использования MDM являются:

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

По данным исследования IDС Russia [4]:

  • доля корпоративных пользователей, использующих удаленный доступ, возросла с 30% (2014) до 52% (2019);
  • более 60% бизнес-пользователей считают, что им необходим доступ ко всем рабочим ресурсам с мобильных устройств;
  • у более чем 86% российских компаний есть стратегия поддержки мобильности сотрудников;
  • экономия рабочего времени благодаря использованию удаленного доступа к ИС, в среднем составляет до 25%;
  • продуктивность сотрудников, имеющих возможность работать удаленно, повышается на 10-30%;
  • более 75% российских компаний разрешают использовать личные мобильные устройства в работе (концепция BYOD).

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

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

Задачи:

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

Объект: управление мобильными устройствами.

Предмет: технологии управления мобильными устройствами.

Работа представлена на страницах текста и состоит из введения, трех глав, заключения и списка использованных источников.

ГЛАВА 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Постановка задачи

В одной транснациональной/крупной компании (далее Компании) поставлена задача корпоративной мобильности – обеспечить сотрудников смартфонами/планшетами для предоставления безопасного управляемого удаленного доступа к своей защищенной инфраструктуре. Количество сотрудников, которым необходим доступ, начинается от 10000 человек. Основные сотрудники являются членами центрального аппарата управления Компании. Произошла закупка корпоративных мобильных устройств/планшетов компании Samsung и Apple.

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

Архитектура системы позволит получить доступ к ресурсам Компании независимо от местоположения работника.

Два бизнес-процесса, которые должна обеспечивать система:

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

Наша система управления мобильными устройствами должна включать в себя три роли взаимодействия с ней: администратор управления мобильными устройствами, администратор ИБ, пользователь.

Функции администратора управления мобильными устройствами (далее МУ):

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

Функциями администратора ИБ являются:

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

Пользователь может получить МУ и начать работать с ним.

Применим навыки моделирования и построим диаграмму вариантов использования. Она представлена на рисунке 1.[6]

https://lh6.googleusercontent.com/Y-E6L0FWl6eQcPOackdeD7uh5oX3_2OQXBQ6q5bstOOR9ebivz1dIjqSU6UFuiRbhc0PNw0rvd55PotaFIDCV49jVc-BxiWxKPrLcupcnMhtOrYd_smD4a8LsC9lTdSQJFFKfU_6

Рисунок 1. Диаграмма вариантов использования

1.2 Предъявление требований к системе MDM

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

Функциональные требования

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

  • возможность установки ПО на МУ;
  • предоставление защиты от удаления агента MDM (при его наличии), либо обеспечение надежного удаления корпоративных данных при удалении агента, либо другой надежный способ сохранения контроля над корпоративными данными при выходе МУ из-под управления;
  • обеспечение управления системными компонентами ОС МУ:
    • доступ к камере;
    • доступ к предустановленному браузеру;
    • доступ к Bluetooth;
    • доступ к мобильной передаче данных;
    • доступ к Wi-Fi;
  • обеспечение удалённой блокировки МУ;
  • предоставление возможности дистанционного удаления данных с МУ (полного или только корпоративных данных);
  • предоставление возможности настройки параметров доступа в сеть Интернет сотового оператора;
  • предоставление корпоративного «магазина приложений»;
  • предоставление возможности по обновлению приложений через корпоративный «магазин приложений»;
  • предоставление возможности по ограничению (условному) использования «магазина приложений» (в зависимости от пользователя, типа устройства и т.д.);
  • предоставление возможности по настройке параметров приложений на МУ;
  • предоставление возможности политикой настроить доступ с устройства к корпоративному ящику электронной почты пользователя;
  • обеспечение простой регистрации устройств в MDM при помощи портала самостоятельной регистрации, без привлечения администратора/службы поддержки, самостоятельно пользователем, без необходимости создания учетной записи Google Play или App Store;
  • обеспечение настройки пароля на устройство с заданными параметрами сложности;
  • обеспечение удаленного сброса пароля на устройстве;
  • обеспечение автоматической блокировки устройства после заданного периода неактивности пользователя;
  • обеспечение возможности настройки автоматического удаления данных после заданного количества неправильных вводов пароля на устройство;
  • обеспечение возможности настройки требований периодической смены пароля на устройство;
  • обеспечение сохранения истории паролей, отсутствие возможности использования определенного количества ранее используемых паролей;
  • обеспечение централизованного сбора системных событий с МУ:
    • смена SIM (совместно с разделением SIM-карт на корпоративные и некорпоративные);
    • установка/удаление приложений;
    • состояние батареи (% заряда, подключение зарядного устройства);
  • выполнение установки приложений администратором и самостоятельно пользователем;
  • выполнение удаления приложений администратором и самостоятельно пользователем;
  • поддержка ролевой модели управления МУ;
  • обеспечение возможности поиска устройств по следующим критериям:
    • по пользователю устройства;
    • по уникальным идентификаторам устройства;
    • по корпоративным приложениям, установленным на устройстве;
  • обеспечение функционала управления компонентами смартфонов и ПППК:
    • отключение камеры;
    • блокировка возможности подключения к беспроводным сетям;
    • управление возможностью подключения внешних периферийных устройств;
  • инвентаризация МУ, включая определение уникальных идентификаторов устройства и его местоположения;
  • применение разных политик в зависимости от местоположения устройства;
  • наличие запроса на подтверждение согласия пользователя с «условиями управления МУ»;
  • обеспечение возможности периодического повторного согласия пользователя с «условиями управления МУ»;
  • определение фактов программного взлома устройств (jailbreak, root), а также предоставление возможности блокировки доступа подобных устройств;
  • резервное копирование списка установленных приложений МУ на сервер БД и их восстановление при повторном подключении;
  • создание отчетов, детализация которых достаточна для проведения анализа работы удаленных пользователей;
  • создание отчета «Инвентаризация МУ по различным критериям» с возможностью выгрузки данных в файл формата ПО Microsoft Excel. Содержание отчета:
    • уникальные данные МУ;
    • дата и время последнего подключения;
    • местоположение МУ;
    • информация о пользователе МУ;
    • перечень установленных приложений;
    • версии приложений и ОС;
    • признак корпоративности МУ;
  • создание отчета «Активные в настоящий момент МУ». Содержание отчета:
    • уникальные данные МУ;
    • информация о пользователе устройства;
    • местоположение МУ.

Требования информационной безопасности

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

Общие требования:

  1. Уровень конфиденциальности обрабатываемой информации – конфиденциальная.
  2. Проведение процедуры оценки соответствия требованиям ИБ.

Требования к интеграции:

  1. Аутентификация и авторизация посредством службы каталога Active Directory.
  2. Интеграция с существующими системами обеспечения ИБ (SIEM[1], MaxPatrol[2]).

Требования регуляторов:

  1. Применение сертифицированных средств защиты информации.
  2. Соответствие требованиям к автоматизированным системам класса 1Г[3].

Функциональные требования:

  1. Ролевая модель разграничения доступа.
  2. Разные сетевые интерфейсы/порты для доступа администраторов и пользователей.
  3. Протоколирование действий пользователей.
  4. Контроль целостности компонентов и конфигурации.
  5. Шифрование канала передачи данных и данных, сохраняемых на МУ.

1.3 Анализ существующих решений

Из требований были сформированы группы критериев для оценки решений.

Таблица 1. Группы критериев

Группа критериев

Примечание

1

Общие требования к архитектуре (серверная часть)

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

2

Требования по безопасности

3

Требования к системе MDM

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

Включает блокирующий критерий на использование привилегированного доступа к устройству (jailbreak, root)

4

Требования к лицензированию

Среди представленных на рынке производителей в области управления мобильными устройствами лидирующие позиции занимают представленные в квадрате Гартнера[4] на рисунках 2 и 3. В рамках импортозамещения рассмотрены и предложения отечественных производителей. Перечислим их всех: Citrix XenMobile, VMware AirWatch, НИИ СОКБ SafePhone, SAP Afaria, MobileIron, Symantec, IBM MaaS360, Microsoft Intune, GOOD Technology.

https://pirit.biz/assets/images/72/image001.png

Рисунок 2. Квадрат Гартнера 2017 г.

https://www.mobile-mentor.com/wp-content/uploads/2018/07/2018-400x422.jpg

Рисунок 3. Квадрат Гартнера 2018 г.

Из перечисленных в шорт-лист на сравнение не попали следующие решения:

  • MobileIron, по причине отсутствие представителя в России;
  • Symantec, по причине прекращения поддержки продукта;
  • IBM MaaS360, по причине, что это «облачное» решение, которое входит в стоп-лист требований Информационной Безопасности;
  • Microsoft Intune, по причине, что это «облачное» решение, которое входит в стоп-лист требований Информационной Безопасности;
  • GOOD Technology, по причине отсутствие представителя в России.

Таким образом, остались следующие продукты: Citrix XenMobile, VMware AirWatch, SafePhone, SAP Afaria.

Рассмотрим методику оценки:

  • соответствие одному из пунктов ФТТ на одной из приоритетных платформ (Apple iOS, Google Android) – 1 балл;
  • если ФТТ не реализовано, но находится в подтверждённом производителем (вендором) плане доработок – 0,7 балла;
  • соответствие ФТТ на платформах Tizen (платформы с малым приоритетом) – 0,01 балла.

К суммарной оценке применялся понижающий коэффициент вендора K = 1* KR , где коэффициент импортозамещения KR = 0,6 + R*0,1, где R = 1, если это российская система и R=0, если нет.

В таблице 2 представлен сравнительный анализ продуктов по функциональным требованиям. Выяснили, что по функционалу MDM выигрывает XenMobile, по безопасности – SafePhone.

Таблица 2. Сравнительный анализ по функциональным требованиям

Производитель, продукт

Архитектура

Mdm

Безопасность

Gui

Интеграция

Отчёты в mdm

Сумма

KR

Итог

Максимально

5

89

62

8

7

55

226

0,7

158,2

Citrix, XenMobile

5

79

20

7

6

43

160

0,6

96

Vmware, AirWatch

5

78

16

8

7

45

159

0,6

95,4

SAP, Afaria

5

76

20

6

4

36

147

0,6

88,2

НИИ СОКБ, SafePhone

5

75

54

7

6

35

182

0,7

127,4

В таблице 3 представлено соответствие требованиям по информационной безопасности. Самым защищенным продуктом стал SafePhone.

Таблица 3. Соответствие требованиям по информационной безопасности

Производитель, продукт

Общий % соответствия требованиям безопасности

Наличие сертификатов регуляторов в области ИБ

Citrix, XenMobile

32%

Нет

Vmware, AirWatch

26%

Нет

НИИ СОКБ, SafePhone

87%

Да

SAP, Afaria

32%

Да

Следующим критерием стали требования к лицензионным политикам. Лидерами вышли вендоры VMware и НИИ СОКБ.

Таблица 4. Сравнительный анализ по требованиям к лицензионной политике

КРИТЕРИЙ

ТРЕБОВАНИЕ

ВЕНДОР

Citrix

VMware

НИИ СОКБ

SAP

1

База расчета стоимости (количество пользователей, обороты и т.п.)

•Количество пользователей;
• По ядрам CPU

ДА

ДА

ЧАСТИЧНО

ДА

2

Схема оплаты лицензий

После начала ОПЭ

НЕТ

НЕТ

ДА

ЧАСТИЧНО

3

Схема продления лицензий (срок лицензии)

Бессрочная

ДА

ДА

ДА

ДА

4

Срок гарантийной поддержки ПО

1й год после даты приобретения

НЕТ

ДА

ДА

ДА

5

Схема техподдержки лицензий ПО

По требованию

ЧАСТИЧНО

ДА

ДА

ДА

6

Максимальный % за ежегодную техподдержку лицензий ПО

Не более 20%

НЕТ

НЕТ

ДА

ДА

7

Количество конкурентных и пользовательских лицензий

50% - пользовательских, 50% - конкурентных

ДА

ДА

НЕТ

НЕТ

8

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

Обязательные услуги отсутствуют

ЧАСТИЧНО

ДА

ДА

ДА

9

Лицензирование части ПО

Только нужная Компании функциональность

НЕТ

ДА

ЧАСТИЧНО

ДА

10

Использование тестовых лицензий

Да

ДА

ДА

ДА

ДА

11

Круг лиц, которым может быть предоставлена сублицензия

Аффилированные лица

ДА

ДА

ДА

НЕТ

12

Территория действия лицензий

Весь мир

ДА

ДА

ДА

ЧАСТИЧНО

13

Право на изменение прикладного кода

Да

НЕТ

ДА

НЕТ

НЕТ

14

Право на изменение исходного кода

Да

НЕТ

НЕТ

НЕТ

НЕТ

15

Право делать копии ПО

Да

ЧАСТИЧНО

ДА

ДА

ДА

16

Право на адаптацию ПО

Да

ДА

ДА

ДА

ДА

17

Является ли Вендор моно-поставщиком на территории РФ

Нет

ДА

ДА

ДА

НЕТ

18

Какая партнерская сеть в РФ по продаже лицензий и выполнению работ

3 и более партнера

ДА

ДА

ДА

ДА

19

Возможность предоставления статуса Партнера для внутреннего ИТ-Интегратора

Да

ДА

ДА

ДА

ДА

итог

68%

84%

84%

74%

Расчет интегральной оценки показан на рисунке 4. Он состоит из оценок соответствия функциональным требованиям, требованиям ИБ, требованиям лицензионной политики, стоимости по отношению к аналогам.

Рисунок 4. Расчет интегральной оценки

Воспользовавшись таблицами выше, сделаем расчет интегральной оценки. Наглядный расчет приведен в таблице 5. Самый высокий процент (63%) получил продукт SafePhone .

Таблица 5. Обоснование выбора подсистемы управления мобильными устройствами

Показатель соответствия

Citrix XenMobile (США)

Vmware AirWatch (США)

SAP Afaria (Германия)

НИИ СОКБ SafePhone (Россия)

1

Функциональные требования

46%

47%

37%

50%

2

Требования по безопасности

32%

26%

32%

87%

3

Лицензионная политика

68%

84%

Н / Д

84%

4

Удельная стоимость (на 5 лет, на 1 устройство)

10 014 р.

12 680 р.

Н / Д

7 500 р.

5

Наличие лицензий продукта в Компании

Нет

Нет

Нет

Нет

6

Наличие компетенций поддержки продукта в ИК Сибинтек

Да

Да

Да

Нет

7

Интегральная оценка

42%

40%

28%

63%

Выводы по первой главе

Мы смогли утвердить задачу – заняться внедрением решения MDM. Выяснили, что нужно определиться с требованиями, чтобы выбрать нужное нам MDM-решение. Прочитав литературу и пообщавшись с экспертами, были предъявлены функциональные требования и требования информационной безопасности. Также нужно было предъявить требования к лицензированию и стоимости продукта на одного сотрудника. Главными требованиями ИБ стали возможности удаленного сброса данных на мобильном устройстве и разворачивание локального решения, а не облачного. Определившись с требованиями, мы выбрали самые инновационные решения по квадрату Гартнера, не забыв и о российских решениях. В результате анализа выяснилось, что лучшим решением для внедрения оказалось российское MDM-решение SafePhone.

ГЛАВА 2 ПРОЕКТИРОВАНИЕ ВНЕДРЕНИЯ

2.1 Определение порядка внедрения

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

Рисунок 5 является эталонным представлением этапов внедрения.

Рисунок 5. Этапы внедрения

Определим, какие есть активности в компании в части корпоративной мобильности. Выяснилось, что есть ряд приложений, разрабатываемых под нужды компании, которые устанавливаются на личные и корпоративные мобильные устройства. Их установка никак не оптимизирована, администраторы ставят приложения вручную. Таких приложений насчиталось 15. Из основных это: «Система электронного документооборота», «Президентский мониторинг», «WorksPad R». На установку каждого приложения администратор затрачивает до 10 минут. Если нужно установить приложение на весь отдел численностью 50 человек, при условии того, что с каждым пользователем нужно договариваться заранее, то администратор может потратить на данную операцию до одного рабочего дня.

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

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

2.2 Пилотная эксплуатация решения

Для оценивания решения, т.е. выполняет ли SafePhone все заявленные требования, было принято решение провести пилотную эксплуатацию решения.

Необходимо определиться с СУБД. В качестве СУБД на выбор предоставляется решение Oracle и PostgreSQL. Посмотрим на график популярности СУБД в мире за последние 6 лет, он представлен на рисунке 6.

Рисунок 6. График популярности СУБД

Как видно на рисунке 7, за последний год популярность PostgreSQL возросла на 78 пунктов, во многом, благодаря развитию продукта, а Oracle постепенно падает рейтинге. Теперь рассмотрим их с технической точки зрения.

Рисунок 7. Изменение рейтинга популярности СУБД за последний год

Расскажем, в чем разница между Oracle и PostgreSQL, используя таблицу 6. [7]

Таблица 6. Сравнение СУБД Oracle и PostgreSQL

Основание сравнения Oracle vs PostgreSQL

Oracle

PostgreSQL

Общая стоимость

Цена приобретения и поддержки продукта для Oracle database высока, и нам нужно платить дополнительно за каждую дополнительную функцию, которая имеет высокую цену.

Поскольку PostgreSQL является открытым исходным кодом, плата за приобретение и поддержку продукта не взимается. Мы можем получить все доступные функции базы данных PostgreSQL бесплатно.

Поддержка

Поддержка клиентов Oracle database не бесплатна, она составляет почти четверть стоимости лицензии и ежегодно увеличивается на 3-5 %.

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

Производительность

Производительность баз данных Oracle больше обусловлена ее техническим превосходством. База данных Oracle обеспечивает больше транзакций в секунду, чем PostgreSQL.

Меньшее количество транзакций в секунду

Безопасность

Oracle database имеет большую безопасность или расширенную безопасность, но нам нужно приобретать дополнительные лицензии на функции, защищающие базу данных.

PostgreSQL имеет хорошую поддержку безопасности, но не столь продвинутую, как Oracle.

Масштабируемость

Oracle database предлагает четыре сокета standard edition для масштабируемости, но для проектов с высокой нагрузкой нам нужно купить enterprise edition.

PostgreSQL предлагает поддержку масштабируемости для бесплатных расширений затрат, таких как прокси-сервер от Skype, выделяющий информацию в кластерах баз данных, кластерные решения для хранения данных на основе PostgreSQL.

Обновления

Oracle database выпускает обновления один раз в два-три года с изменением качества с учетом спроса на рынке.

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

Обработка большого объема данных

Oracle database enterprise edition эффективно обрабатывает большой объем данных, чем PostgreSQL на основе других равных условий и типов машин.

База данных PostgreSQL эффективно обрабатывает большой объем данных, что повышает производительность от 10 до 30 процентов на машинах с большими объемами памяти.

Получается, что PostgreSQL является более лучшим решением, чем Oracle во многих случаях, будучи открытым исходным кодом, обладающей совместимостью с другими СУБД и простотой использования с большим сообществом разработчиков.

Необходимо определиться с ОС, на которой будет развернута СУБД PostgreSQL. Основным камнем преткновения являлось требование информационной безопасности Компании – ОС должна быть сертифицирована и не должна быть open-source. Мы выяснили, что Astra Linux обладает нужными сертификатами, а также содержит в себе защищенную СУБД PostgreSQL, которая подходит под наши нужды. Операционная система специального назначения «Astra Linux Special Edition» предназначена для создания на ее основе автоматизированных систем в защищенном исполнении, обрабатывающих информацию до степени секретности «совершенно секретно» включительно. Имеет сертификат ФСТЭК от 27.01.2012 г. № 2557. [8].

Однако, вендор предлагал для установки СУБД лишь следующие ОС: SUSE Linux Enterprise Server 12 SP3, Centos 7. Поэтому было принято решение протестировать установку на ОС Astra Linux.

Для введения пилотной эксплуатации было принято решение развернуть все компоненты, за исключением СУБД, на одном сервере. ОС для установки компонентов также была выбрана из списка обладающих сертификацией ФСТЭК, это SUSE Linux Enterprise Server 12 SP3.

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

  • виртуальная машина с ОС Astra Linux и СУБД PostgreSQL: CPU: 64-разрядный процессор, 8 ядер по 2,4 ГГц, RAM: 64 ГБ, HDD: 200 ГБ;
  • виртуальная машина с ОС SUSE Linux Enterprise Server 12 SP3: CPU: 64-разрядный процессор, 16 ядер по 2,4 ГГц, RAM: 32 ГБ, HDD: 80 ГБ.

Представим архитектурную схему пилотной эксплуатации, она указана на рисунке 11. По ней мы видим, как пользователи подключаются через VPN-канал к серверу SafePhone test-mdm.rn.sud.

В следующем пункте опишем основные особенности работы ПО SafePhone, взаимодействие серверных компонентов с администраторами и пользователями.

Введя пилотную эксплуатацию, был выявлен ряд проблем, которые предстоит решить при внедрении в промышленной эксплуатации:

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

Рисунок 8. Добавление пользователей

  • неудобное добавление версий ОС. Изначально не указано ни одной версии ОС, каждую версию нужно добавлять вручную (см. Рисунок 9);

Рисунок 9. Добавление версий ОС

  • нет интеграции организационно-штатной структуры со службой каталогов Active Directory. Приходится все организационные подразделения также добавлять вручную (см. Рисунок 10).

Рисунок 10. Организационно-штатная структура

C:\Users\Admin\Desktop\Иплом\Тестовый ландшафт.png

Рисунок 11. Архитектурная схема пилотной эксплуатации

Эксперимент с установкой на Astra Linux был признан удачным, система запустилась и в пилотной эксплуатации показала, на что она способна – помочь администраторам оптимизировать их рабочие процессы.

2.3 Описание работы SafePhone

Для начала введем понятие сущностей, существующих в ПО SafePhone.

  • сервер SafePhone. Сервер предназначен для настройки политик ИБ, сбора инвентаризационной информации и событий МУ iOS и Android. Кроме того, на нём размещается общий для МУ iOS и Android веб-портал самостоятельной регистрации пользователей SafePhone. Обеспечивает возможность управления МУ Android, МУ iOS. Предназначен для приёма данных от МУ, регистрации данных МУ в БД PostgreSQL и отправки МУ команд управления;
  • клиент SafePhone iOS. Клиент состоит из профиля управления и клиентского ПО SafePhone. Профиль управления – это конфигурационный профиль ОС iOS, который определяет параметры сервера MDM, клиентом которого является сама ОС iOS. Клиентское ПО SafePhone предназначено для реализации функций, не предусмотренных стандартным протоколом управления ОС iOS – выявление фактов программного взлома МУ iOS (jailbreak), регистрации данных о батарее МУ (уровень и признак подключения к зарядному устройству) и его географическом расположении по данным GPS;
  • клиент SafePhone Android. Приложение, функционирующее в операционной среде Android и наделённое необходимыми полномочиями для управления МУ. Реализует функции управления МУ Android. Для обеспечения возможности оперативного управления постоянно подключен к серверу SafePhone.
  • Сервер БД . Централизованное хранилище данных SafePhone.

Разделим описание работы на 3 пункта: как взаимодействуют мобильные устройства с ОС Android, мобильные устройства с ОС iOS, администраторы со своего рабочего места.

Клиент Android SafePhone постоянно подключен к серверу SafePhone по проприетарному протоколу 50001 и получает команды в этом подключении.

На iOS подключение идет по протоколу 443. Из-за ограничений ОС используется иной механизм доставки команд управления:

После включения МУ устанавливает соединение со службой отправки push-уведомлений компании Apple (Apple Push Notification Service, далее – APNS).

Сервер SafePhone направляет в APNS запрос на отправку MDM push-уведомления в адрес МУ. МУ идентифицируется в APNS по токену, информация о котором сообщается SafePhone в процессе регистрации МУ;

МУ получает MDM push-уведомление от APNS в рамках существующей HTTPS сессии. Уведомление сообщает МУ только о факте наличия для него команды управления, но не содержит информации о самой команде и её параметрах;

МУ обращается к серверу SafePhone за командой, исполняет её и регистрирует на сервере результат выполнения.

Для обеспечения возможности установки клиентского ПО SafePhone на МУ iOS без использования на МУ учётных записей App Store требуется:

  • являться участником программы Apple Developer Enterprise Program (ADEP) или вступить в указанную программу;
  • включить учётную запись разработчика ПО SafePhone (Apple ID) в свою программу Apple Developer Enterprise Program (ADEP);
  • предоставить учётной записи разработчика ПО SafePhone, включенной в программу ADEP Заказчика, возможность сгенерировать сертификаты для подписи клиентского ПО SafePhone и издать для него сертификаты для отправки push-уведомлений.

Для администраторов есть доступ к консоли администрирования SafePhone по защищенному протоколу 8443.

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

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

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

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

Команды управления SafePhone позволяют администратору подсистемы управления мобильными устройствами:

  • управлять доступом пользователя МУ к приложениям и интерфейсам (системным компонентам), через которые возможна утечка данных: камере, браузеру, Bluetooth, мобильной передаче данных, Wi-Fi;
  • удаленно заблокировать и разблокировать МУ;
  • выполнить удаленный сброс устройства к заводским настройкам или сброс с удалением только корпоративных приложений и их данных;
  • выполнить настройку параметров доступа МУ к мобильному интернету (APN) для тех регионов, где оператор не распространяет такие настройки автоматически.

«Магазин приложений» является отдельным мобильным приложением в составе SafePhone, позволяющим пользователю устанавливать приложения из списка загруженных в SafePhone самостоятельно. Будучи отдельным приложением, магазин может быть установлен пользователю. Это позволяет контролировать доступность самостоятельной установки. Список доступных пользователю приложений может быть ограничен. При загрузке администратором управления мобильными устройствами нового приложения или новой версии приложения пользователь уведомляется об этом и может предпринять действия для обновления или установки.

SafePhone регистрирует события смены SIM-карт, установки/удаления приложений, состояние батареи при наличии связи МУ с сервером управления. На Android все события регистрируются мобильным клиентом SafePhone. На iOS мобильный клиент регистрирует только состояние батареи, остальные события регистрируются сервером управления SafePhone на основании данных периодического опроса сервером МУ.

SafePhone поддерживает ролевую модель управления МУ. Полномочия администраторов определяются их ролями. Набор прав у роли может быть произвольным, набранным при создании роли из доступных в SafePhone. В соответствии с набором прав изменяется интерфейс администратора на сервере администрирования SafePhone.

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

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

Выводы по второй главе

В ходе второй главы был определен порядок внедрения, состоящий из предпроектного обследования, пилотной эксплуатации, тестирования, проектирования, инсталляции, интеграции с корпоративными ресурсами. Предпроектное обследование показало, что можно оптимизировать работу администраторов управления мобильными устройствами в разы. Была произведена пилотная эксплуатация продукта SafePhone, которая показала, что решение соответствует заявленным требованиям, но нуждается в доработке при промышленной эксплуатации. Эксперимент с установкой ПО на Astra Linux был признан удачным настолько, что вендор в следующей версии дописал наш порядок установки. Также был описан принцип работы ПО SafePhone для понимания схем.

ГЛАВА 3 ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ПРОМЫШЛЕННОЙ ЭКСПЛУАТАЦИИ

Оценив преимущества и недостатки результатов пилотного решения, было принято решение промышленную эксплуатацию разнести на максимально возможное количество серверов, тем самым при падении одного сервера остальная часть решения продолжает работать. В результате серверов оказалось 5: сервер БД, сервер управления iOS, сервер управления Android, сервер портала регистрации, сервер администрирования. Расскажем о каждом сервере подробнее:

  • сервер управления iOS SafePhone. Обеспечивает возможность управления МУ iOS, предназначен для настройки политик, сбора инвентаризационной информации и событий МУ iOS.
  • сервер управления Android SafePhone. Обеспечивает возможность управления МУ Android, предназначен для приёма данных от МУ, регистрации данных МУ в БД PostgreSQL и отправки МУ команд управления.
  • сервер портала регистрации мобильных устройств. На нём размещается общий для iOS и Android веб-портал самостоятельной регистрации пользователей SafePhone.
  • сервер администрирования SafePhone. Предназначен для управления клиентами SafePhone iOS и Android из браузера АРМ Администратора управления мобильными устройствами.
  • сервер СУБД PostgreSQL. Централизованное хранилище данных SafePhone.

Чтобы предусмотреть возможность управлять устройствами всегда, когда интернет на устройстве включен, необходимо, чтобы сервер управления Android и сервер управления iOS были опубликованы во внешний DMZ, имели внешний IP-адрес.

На рисунке 12 представлена логическая схема системы управления мобильными устройствами. Остановимся на нем. Первым делом, мобильные устройства должны получить одно из двух VPN-соединений (CheckPoint или ViPNet), подключиться и через VPN-соединение попасть на портал регистрации. После регистрации в SafePhone мобильное устройство получает приложение-агент, при помощи которого мобильное устройство начинает управляться. Как говорилось выше, сервера управления iOS и Android вынесены во внешний DMZ.

C:\Users\knikitushkin\Desktop\АЕСиГОСТ.png

Рисунок 12. Логическая схема MDM для МУ

Администраторы получают доступ по 22 порту к каждому серверу и 8443 порту к серверу администрирования.

Пилотное решение дало понять, что мы используем нужную ОС, СУБД. На них же и остановимся в промышленной эксплуатации. ОС Astra Linux с СУБД PostgreSQL и остальные серверы SUSE Linux Enterprise Server 12 SP3.

Мы выяснили, что в вендорской документации по установке и развертыванию отсутствует требования к 10 тысячам устройств (см.рисунок ниже).

Рисунок 13. Требования вендора на 1000 пользователей

Получается, что на одного пользователя на полгода данных требуется 51.2 МБ.

Проведя расчеты, что система будет рассчитана на 10 тысяч устройств и более в дальнейшем, было принято решение назначить место для размещения БД объемом 3 ТБ.

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

Таблица 7. Характеристики виртуальных машин для промышленной эксплуатации

Сервер портала регистрации устройств

Виртуальная машина с характеристиками:

CPU: 64-разрядный процессор, 16 ядер по 2,4 ГГц.

RAM: 32 ГБ.

HDD: 40 ГБ

ОС: SUSE Linux Enterprise Server 12 SP3

ПО: SafePhone

Сервер управления iOS SafePhone

Виртуальная машина с характеристиками:

CPU: 64-разрядный процессор, 16 ядер по 2,4 ГГц.

RAM: 32 ГБ.

HDD: 40 ГБ

ОС: SUSE Linux Enterprise Server 12 SP3

ПО: SafePhone

Сервер управления Android SafePhone

Виртуальная машина с характеристиками:

CPU: 64-разрядный процессор, 16 ядер по 2,4 ГГц.

RAM: 32 ГБ.

HDD: 40 ГБ

ОС: SUSE Linux Enterprise Server 12 SP3

ПО: SafePhone

Сервер администрирования SafePhone

Виртуальная машина с характеристиками:

CPU: 64-разрядный процессор, 4 ядра по 2,4 ГГц.

RAM: 8 ГБ.

HDD: 80 ГБ

ОС: SUSE Linux Enterprise Server 12 SP3

ПО: SafePhone

Сервер СУБД PostgreSQL

Виртуальная машина с характеристиками:

  • CPU: 64-разрядный процессор, 8 ядер по 2,4 ГГц.
  • RAM: 64 ГБ.

HDD: 3 ТБ

ОС: Astra Linux Special Edition

СУБД: PostgreSQL 9.6

Определим порядок инсталляции серверных компонентов:

Установка Astra Linux с СУБД PostgreSQL, установка ПО, развертывание схемы базы данных.

Установка SUSE Linux Enterprise Server 12 SP3 и роли сервера администрирования, тестирование запуска консоли администратора.

Генерация сертификатов для работы с МУ под управлением iOS.

Установка SUSE Linux Enterprise Server 12 SP3 и роли сервера портала регистрации, тестирование запуска портала регистрации.

Установка SUSE Linux Enterprise Server 12 SP3 и роли сервера управления iOS, тестирование подключения мобильного устройства с ОС iOS.

Установка SUSE Linux Enterprise Server 12 SP3 и роли сервера управления Android, тестирование подключения мобильного устройства с ОС Android.

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

Отключение приложения «Камера» у корпоративного мобильного устройства при нахождении на защищенном объекте. Для этого нужно было создать геозону, как на рисунке 14, создать профиль с настройкой «Запрет камеры», в настройках найти параметр «разрешить камеру», выбрать «Нет», как указано на рисунке 15. Перейти на вкладку «Условия», выбрать «Нахождения внутри геозоны», как на рисунке 16, и определиться, в каких геозонах данная настройка будет применяться. Перейти на вкладку «Назначения» и применить созданный профиль на весь отдел или сотрудника, как указано на рисунке 17.

Рисунок 14. Геозоны

Рисунок 15. Запрет камеры

Рисунок 16. Добавление условий применения профиля

Рисунок 17. Назначение профиля

Чтобы оптимизировать добавление сотрудников в организационно-штатную структуру ПО SafePhone, были разработаны скрипты для экспорта нужных параметров сотрудников из AD и импорта этих параметров в консоль администратора, указаны в Приложении 1.

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

Перечислим информационные системы, к каким мы смогли провести интеграцию:

  1. Электронная почта. При установке SafePhone-клиента стандартный почтовый клиент предложит ввести пароль, который обеспечивает автоматический доступ к электронной корпоративной почте.

Система электронного документооборота. После установки SafePhone-клиента есть возможность установить мобильное приложение системы электронного документооборота из корпоративного «магазина приложений».

Приложение «WorksPad R». Данное приложение дает возможность открывать конфиденциальную почту, просматривать и редактировать файлы, защищено криптоконтейнером. После установки SafePhone-клиента есть возможность установить мобильное приложение системы электронного документооборота из корпоративного «магазина приложений».

Приложение «Президентский мониторинг». Данное приложение, разработанное в Компании, дает возможность открывать руководителям просмотр всех ресурсов Компании. Данное приложение не опубликовано в корпоративном «магазине приложений», назначается на установку определенному кругу лиц.

Аутентификация администраторов в консоли управления SafePhone по логину и паролю из Active Directory. Нужно было внести изменения в настройки, создать LDAP-запрос.

Тестирование ПО SafePhone произошло успешно. Необходимо составить техническую документацию на передачу систему в поддержку Компании. Были разработаны следующие документы: Технический проект, регламент предоставления доступа, руководство по обеспечению непрерывности бизнеса, инструкция администратора, инструкция пользователя. Данная система вошла в промышленную эксплуатацию.

Выводы по третьей главе

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

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

ЗАКЛЮЧЕНИЕ

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

  1. Проведен анализ необходимости решения управления мобильными устройствами. Изучены требования, нужные для внедрения такого решения. Также проведен анализ существующих решений управления мобильными устройствами: Citrix XenMobile (США), Vmware AirWatch, (США), SAP Afaria (Германия), НИИ СОКБ SafePhone (Россия). Он показал, что решение SafePhone подходит для предъявленных к нему требований по функционалу и информационной безопасности.

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

Пилотная эксплуатация удовлетворила предъявленным требованиям, но показала, насколько неудобна система.

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

СПИСОК ЛИТЕРАТУРЫ

  1. Развитие стратегии мобильности и защита корпоративной информации в ОАО «МОЭК» при помощи Citrix XenMobile [Электронный ресурс] https://www.citrix.ru/customers/moscow-united-energy-company-ru.html Дата обращения: 20.08.2019
  2. Enterprise mobility [Электронный ресурс] https://searchmobilecomputing.techtarget.com/definition/enterprise-mobility Дата обращения: 20.08.2019
  3. MDM – mobile device management [Электронный ресурс] https://www.webopedia.com/TERM/M/mobile_device_management.html Дата обращения: 20.08.2019
  4. К 2019 г. половина офисных сотрудников в России смогут работать удаленно [Электронный ресурс] http://www.comnews.ru/node/86018 Дата обращения: 20.08.2019
  5. Экономика управления мобильными устройствами на основе MDM [Электронный ресурс] https://www.lanit.ru/press/smi/8012/ Дата обращения: 20.08.2019
  6. Фаулер, М. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. СПб: Символ-Плюс, 2011. - 192 с.
  7. Difference Between Oracle vs PostgreSQL [Электронный ресурс] https://www.educba.com/oracle-vs-postgresql/ Дата обращения: 20.08.2019
  8. Astra Linux® Special Edition. [Электронный ресурс] https://astralinux.ru/products/astra-linux-special-edition/ Дата обращения: 20.08.2019
  9. Шумский, А. А. Системный анализ в защите информации / А. А. Шумский, А. А. Шелупанов. М.: Гелиос АРВ, 2005. - 224 с
  10. Ищейнов, В.Я. Защита конфиденциальной информации / В.Я. Ищейнов, М.В. Мецатунян- М.: ФОРУМ, 2009. 256с.
  1. Security Information and Event Management – Система обнаружения вредоносной активности и различных системных аномалий

  2. Российская SIEM-система

  3. Один из девяти классов защищенности АС- автоматизированных систем от несанкционированного доступа к информации

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