50
Таким образом формируется пирамида на самом нижнем уровне которой
находится физический сервер (Bare Metal), на нем установлен гипервизор, на
гипервизор устанавливаются операционные системы, в операционные системы
устанавливается программное обеспечение.
Необходимость разнесения OTRS и базы данных на разные виртуальные
машины (VM) продиктована инженерами технического отдела и обусловлено
необходимостью более гибко управлять ресурсами VM с базой данных.
В требованиях к аппаратному обеспечению для OTRS указано следующее:
Мы рекомендуем использовать машины, с процессором, как минимум 2 ГГц Xeon
или совместимых CPU, 2 Гб ОЗУ и 160 Гб свободного пространства на жестком
диске. В соответствии с этим было создано две виртуальные машины, в которые
отдано по 2 ядра CPU, 4Gb оперативной памяти и по 160Gb дискового
пространства.
Почтовый сервер работает так же в среде виртуализации. В роли Mail
Transfer Agent используется Exim, в роли IMAP и POP3 используется Dovecot,
авторизация пользователей организована через локальную MySQL базу данных.
51
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта можно представить в виде структуры,
определяющую последовательность осуществления процессов и задач,
выполняемых на протяжении жизненного цикла ИС.
Весь жизненный цикл автоматизации включает в себя несколько этапов:
Предварительный анализ.
По его завершению у архитекторов проекта должно появиться детальное
техническое задание, одобренное всеми вовлеченными сторонами
Проектирование
На этом этапе должна появиться документация, детально описывающая
архитектуру решения, все программные, аппаратные комплексы и
принципы внутреннего взаимодействия компонентов.
Реализацию
Результатом можно считать работающий продукт.
Тестирование
Цель этого этапа — проверка работающего продукта в реальных условиях
для выявления недочетов в логике работы или стабильности.
Внедрение
После завершения всех предыдущих этапов работ, система должна быть
передана заказчику и запущена в работу.
Каскадная модель предполагает строго последовательную реализацию
перечисленных этапов. Иными словами подразумевается, что работа по
каждому этапу должна быть завершена полностью, после чего можно
переходить к следующему.
При кажущейся простоте и логичности, строгость каскадной модели
подразумевает 100% качество выполнение каждого этапа, что в реальной жизни
крайне маловероятно. Как следствие, недочеты начинают проявляться на
последующих этапах и заставляет команду остановить разработку, вернуться у
52
предыдущему циклу для внесения корректировок в документацию и запустить
цикл разработки по новой с обновленными данными.
Так же к недостаткам этой модели относят сложность параллельной работы
над одним проектом нескольких групп разработчиков и сложность управления
всем проектом. Резюмируя сказанное можно утверждать, что чем больше проект,
тем сложней его будет разрабатывать по каскадной модели.
Существует еще спиральная модель жизненного цикла, предполагающая
итерационный процесс разработки информационной системы. Разработка
ведется итерациями, которые представляют собой законченный цикл разработки
с выпуском работающего прототипа. После этого проводится тестирование,
выявление недочетов и возврат к следующей итерации разработки.
Использование спиральной модели позволяет не останавливать разработку
при выявлении недочетов – их можно будет исправить позднее.
По личным наблюдениям могу утверждать, что в реальной жизни
большинство проектов начинают реализовываться по каскадной модели, но
после начала работы и внесения нескольких правок в документацию переходят к
спиральной.
Преимущества спиральной модели:
Более простое и быстрое внесение изменений в проект
Несколько групп программистов могут работать параллельно независимо
друг от друга, общение разрабатываемых модулей обычно реализуется
через внутренний API, который обычно разрабатывается так же
автономной группой.
Упрощение управления проектом и координацией групп
Итерационный подход дает возможность совершенствовать процесс
разработки — анализ, проводимый в конце каждой итерации, позволяет
проводить оценку того, что должно быть изменено в организации
разработки, и улучшить ее на следующей итерации.
К недостаткам системы относят отсутствие четкого разграничения этапов,
поэтому часто используется временные рамки, ограничивающие каждую
итерацию. По этой причине появляются обновления приложений в Google Play
каждый месяц или чаще без особых видимых нововведений.
53
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В нашем процессе автоматизации есть все необходимые вводные данные.
Мы знаем какие заявки и по каким каналам могут поступить, знаем каким
образом их надо учесть и обработать у нас есть готовая информационная
система, для обработки всей этой информации.
Тем не менее, маршруты прохождения заявки, сформированные на этапе
анализа, довольно просты и потребуют корректировки при настройке логики
работы системы. Так же будет требоваться постепенная адаптация логики
работы программы к реалиям работы.
Много времени придется уделить обучению персонала, поскольку
неподготовленному человеку, привыкшему работать только с электронной
почтой, будет сложно перестроиться на логику работы внедряемой системы. В
некоторых случаях, возможно, придется прибегнуть к административному
ресурсу.
Предложенная доработка IVR телефонной станции в моменты
максимальной загрузки может сыграть злую шутку – оператор может не
успевать закрывать созданные заявки и в итоге может перестать это делать
вовсе. В итоге, в конце рабочего дня получит замусоренный интерфейс системы
с однообразными заявками, что может вынудить его закрыть их все с какой-то
стандартной отпиской.
Ни один честный разработчик более-менее сложной информационной
системы не может дать стопроцентную гарантию отсутствия в ней ошибок.
Более того, в лицензии AGPL V3 под которой выпускается OTRS, отдельно это
оговаривается. Возможно, мы их встретим и придется с ними мириться до
следующего обновления либо исправлять самостоятельно.
54
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Для данной информационной системы будет использовано несколько
уровней защиты.
Разграничение прав пользователей:
Уровень администратора на гипервизоре.
Этому пользователю доступны возможности создания, удаления и
управления электропитанием всех виртуальных машин на гипервизоре. Как
следствие, этот уровень доступа получают только самые опытные инженеры,
администрирующие площадку
рис 2-1. Интерфейс управления гипервизором Proxmox
Root доступ к виртуальной машине.
Понятие характерно для всех unix-like систем и предоставляет
неограниченный уровень доступа к операционной системе. Необходим для
инсталляции, первоначальной настройки и изменения конфигурации системы.
Его аналогом в системах Windows можно назвать пользователя System от имени
которого работают системные процессы и обладающим уровнем выше чем
привычный Administrator.
55
После установки операционной системы, root доступ к ней можно получить
только через панель управления гипервизором и через ssh по сети,
авторизовавшись сначала как простой пользователь, затем повысив свой уровень
через команду su. Осознавая потенциальную опасность, доступ к панели
гипервизора и ssh разрешен исключительно внутри одного управляющего Vlan с
определенных ip адресов из офисной подсети инженеров. Доступ к ssh
ограничивается отдельным сетевым интерфейсом виртуальной машины и так же
разрешается только из определенной сети инженеров.
Бытует мнение, что для ограничения доступа достаточно пользоваться
встроенным в операционную систему Firewall. Отчасти это верно, но часто
взломы систем происходят из-за невнимательности инженеров неверно
настроивших правила сетевого фильтра. Поэтому в компании используется схема
сегментации сетевого трафика, при которой описываются несколько классов
трафика:
1.
трафик, связанный с управлением гипервизорами
2.
трафик управления серверами
3.
трафик управления виртуальными машинами
4.
трафик управления сетевым оборудованием
5.
трафик доступа к сервисам виртуальных машинами
6.
офисный трафик
7.
клиентский трафик
8.
Voip трафик
9.
и т. д.
У каждого класса должно быть выделено свойство — необходим ли доступ
во внешние сети или будет замкнут внутри изолированного сегмента. IP адреса
для каждого класса группируются в один или группу vlan (VLAN — Virtual Local
Area Networ, виртуальная локальная сеть. Технология, применяемая на 2-м уровне
сетевой модели OSI и позволяющая разграничивать трафик различных локальных
сетей на одном коммутаторе. Трафик из одного vlan в другой попасть не может,
если это не указано принудительно) и настраиваются соответствующие правила
на сетевом оборудовании.
56
В TCP модели unix-like систем используется функция bind() для привязки
TCP сокета процесса к конкретному ip адресу и порту системы. Это означает, что
запущенный на сервере сервис с несколькими сетевыми картами будет принимать
подключения не со всех сетевых интерфейсов, а только с определенных. Для веб
сервера Apache этим управляет директива «Listen», в конфигурационном файле
sshd - «ListenAddress».
Так доступ к управлению гипервизором может быть осуществлен только с
рабочих машин инженеров из определенной офисной сети к определенному
сетевому интерфейсу хоста. Значит все гипервизоры должны иметь сетевой
интерфейс в этом vlan, в этом же vlan должны находиться рабочие станции
инженеров. Невозможность перехода трафика из одного vlan в другой
обеспечивает гораздо больший уровень безопасности чем настраиваемый
фаерволл на каждом сервере за счет исключения возможности ошибки
системного администратора.
Аналогичным образом в компании настраивается доступ к управлению
сетевым оборудованием, voip и так далее.
Как «клиентский трафик» мы классифицируем трафик самого сервиса для
предоставления услуг, т.е основной задачи ради которой этот сервис был поднят.
В соответствии с описанными правилами, наша виртуальная машина с OTRS
будет иметь два сетевых интерфейса — в сети управления и в сети, которая
маршрутизируется глобально. Список сетевых интерфейсов виртуальной машины
показан на рисунке 2-2.
57
рис 2-2. Список сетевых интерфейсов виртуальной машины
На скриншоте видны 3 сетевых интерфейса машины:
Loopback — локальный адрес системы. К нему невозможно подключиться
снаружи
eth0 — адрес в локальной сети управления
eth1 — адрес в публичном сегменте сети провайдера
рис 2-3. Привязка сервисов (daemons) к сетевым интерфейсам
На рисунке 2-2 показаны существующие сетевые интерфейсы на
виртуальной машине, на рис. 2-3 — привязка определенных демонов (от Daemon
— компьютерной программы в системах класса UNIX, запускаемой самой
системой и работающей в фоновом режиме без прямого взаимодействия с
пользователем. Далее для конкретизации будет использоваться именно этот
термин, как наиболее точно описывающей конкретную программу) к конкретным
58
сетевым интерфейсам. Здесь можно увидеть несколько демонов, необходимых
для работы системы:
master — почтовый сервер Postfix, принимающий соединения только на
внутреннем интерфейсе 127.0.0.1
httpd — это демон Apache2. Он привязан к внешнему ip адресу, доступному
с ip адресов автономной системы провайдера
sshd — демон ssh, обеспечивающий доступ к операционной системе по
протоколу ssh. Привязан только к внутреннему сетевому интерфейсу.
Поскольку OTRS является программой, написанной на языке Perl, следует
учесть возможность взлома с внешнего интерфейса. Т.е. возможна ситуация, при
которой злоумышленник может обнаружить и использовать уязвимость самого
кода OTRS, что может позволить ему загрузить на сервер программный код и
запустить на выполнение для получения доступа к системе.
Методика минимизации рисков в этом случае разработана давно и
применяется на всех unix-подобных операционных системах.
Администрацией адресного пространства Интернет (IANA) для HTTP
трафика закреплен порт по умолчанию под номером 80. Порты ниже 1024 в unix
системах не разрешается использовать непривилегированным пользователям,
поэтому что бы демон httpd мог открыть TCP сокет на 80-м порту необходимо его
запустить на исполнение от имени пользователя root. Для дальнейшей работы
такой уровень доступа является излишним и небезопасным, поэтому запущенный
демон порождает несколько своих потомков с помощью системного вызова fork()
а сам выполняет роль только координатора потомков, передавая входящее
соединение сразу им. Порожденные демоны будут работать от
непривилегированного пользователя apache, возможность записи на диск для
которого жестко регламентирована правами доступа к файловой системе. При
этой модели даже обнаружив брешь в защите программы, злоумышленник не
сможет загрузить свой код на сайт, а тем более запустить его на выполнение.
59
Рис 2-4. Иерархия процессов web сервера apache
На рис2-4 виден мастер-демон httpd, запущенный от имени root и 6 его
потомков, запущенных от имени непривилегированного пользователя apache.
Количеством потомков можно управлять.
Тем не менее, на всякий случай, на внутренних интерфейсах виртуальных
машин применяются фильтры, исключающий возможность установки любых
исходящих соединений. Т.е. можно к этому хосту подключиться по ssh, но нельзя
с этого хоста подключиться куда-то в другое место.
Третий уровень доступа — backup
Необходим для создания резервных копий виртуальной машины.
Фактически он имеет возможность только запустить скрипты резервного
копирования или восстановления в работающей системе.
В компании разработаны регламенты по созданию и восстановлению
виртуальных машин и процесс выглядит следующим образом:
1.
Базовая операционная система устанавливается из шаблона для
выдерживания максимальной унификации всех настроек.
2.
Назначаются уникальные ip адреса для интерфейса управления (ssh) и
сервиса (публичный)
3.
Необходимое программное обеспечение устанавливается не вручную, а с
помощью ansible скриптов. Ansible — система управления
конфигурациями, позволяющая автоматизировать большинство работ на
unix системах.
Скрипт установки виртуальной машины с mysql выглядит следующим
образом: