Дипломная работа: Автоматизация приема и обработки заявок отделом техподдержки Богородском филиале АО "НПО "Прибор"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
17
1.1.3. Программная и техническая архитектура ИС предприятия
Для организации программной архитектуры ИС предприятия будет использована
уже имеющаяся модель, так как я не имею права ни на изменение структуры сети,
ни на установку дополнительного программного обеспечения, или даже создания
баз данных, не зависимо от того, что MS SQL и Postgresql на предприятии
используется, но каждая база данных, установка программного обеспечения, либо
операционных систем должна быть согласована с управлением безопасности
филиала, управлением безопасности головного предприятия, отделом
информационных технологий головного предприятия, которые в свою очередь
согласовываются с АО «НПК «Техмаш» и не должны содержаться в списке
запрещенных ОС или ПО, государственной корпорации Ростех, должны
содержаться в списке рекомендованных ОС или ПО государственной корпорации
Ростех и/или министерства связи. И естественно не может идти речи о закупке
программного обеспечения, так как всё что связано с темой автоматизация — это
статья расхода, не относящаяся к расходам из запланированного бюджета отдела,
это отдельная статья, которая у нас может быть связана исключительно с
выполнением госзаказа. За семь лет работы на оборонном предприятии я убедился,
что сложившаяся здесь бюрократическая ситуация напоминает фразу из фильма
«Девушка без адреса»: «Над нашей конторой есть ещё одна контора, которая
главнее нашей…». При всём этом никто не запрещает использовать в своих нуждах
то, что имеется для автоматизации собственно работы отдела, где я и работаю, если
при этом это не вызовет затрат вовсе, а согласовывать практически ничего не
придётся. От себя добавлю, что сделать можно что угодно, главное знать, как
вертеться в этой замшелой бюрократии, где все только и норовят отпинать от себя
и не брать ответственность.
Итак, автоматизировать я буду приём заявок от пользователей, который в данный
момент выглядит как рукописная запись в строку журнала учета заявок под
роспись. Для этого необходимо организовать доступ к подаче и просмотру
поданных заявок, то есть к серверной части всех участников всех имеющихся
подсетей. На предприятии рабочие места условно можно разделить на четыре
группы:
1) Рабочие места с доступом к сети Интернет
2) Рабочие места с доступом к закрытой сети
3) Рабочие места без доступа к сети
4) Секретные, аттестованные рабочие места
Сети (так как они физически разделены) можно разделить на две группы:
1) Сеть с доступом в Интернет
2) Закрытая сеть, содержащая коммерческую тайну
18
Сети физически разделены, а для переноса информации между ними, согласно
распоряжению Техмаша используются пронумерованные CD-R диски, записанные
с финализацией сессии, которые в конце дня должны быть уничтожены.
Для упрощения передачи данных используется сетевая папка между NAS
серверами, при этом каждый из NAS подключен к своей сети (с Интернетом или
закрытой), а подключение между ними выполнено как кроссовер подключение к
отдельным внутренним интерфейсам серверов, а в отсутствии трансляции пакетов
или маскарадинга сервера «видят» друг друга, но не могут попасть в «соседнюю»
сеть. Доступ к сетевой папке предоставлен только сотрудникам отдела ИТ и со
стороны закрытой сети дополнительно контролируются DLP системой,
наименование которой я не имею права разглашать, но принцип работы
применительно к этой сетевой папке сводится к сканированию на совпадение, по
ключевым словам, паттернам и на соответствие цифровым отпечаткам созданных и
изменённых файлов. Такими системами являются, например, FalconGaze или
Стахановец. Эта сетевая папка и передача файлов через нее и будут являться
основной составляющей написанной мной системы, это позволит видеть
актуальные статусы заявок участникам обоих сетей.
Так как филиал состоит из нескольких площадок, расположенных в разных частях
города, а специалистом по безопасности поставлено ограничение на использование
системы в пределах внутренней сети, без доступа из вне придётся позаботится о
объединении ЛВС площадок. Стоит отметить, что закрытая сеть уже объединена
посредством криптошлюзов, модель (опять-таки условно) АПКШ Континент IPC-
100, туннелированием IPIP, и статической маршрутизацией. А вот сеть с доступом
в Интернет не объединена и учитывая меньшие требования к безопасности (так как
не содержит закрытой информации) может быть объединена посредством
имеющихся в наличии аппаратных или программных средств, дабы пользователи
удаленной площадки могли видеть свои заявки на только локально доступном
сервере. Главное условие, поставленное специалистом по безопасности не менять
адресность, а для обеих сетей это 192.168.222.xxx, с разницей лишь в последних
числах от одного до ста девяноста девяти для первой площадки и от двухсот на
второй. Объединение было запланировано давно, но из-за очень большой цены
разрешенных к использованию криптошлюзов и при этом отсутствии в сети
информации с хотя бы коммерческой тайной от них отказались, а так как большая
часть сетевого оборудования находится под запретом (например, оборудование D-
Link), то от аппаратного решения я отказался сразу, уж слишком часто выходят
запреты и рекомендации.
Для объединения я решил воспользоваться программным простым решением VPN
на канальном уровне с использованием мостов. За основу были взяты два сервера
установленные на обеих площадках мною около трех лет назад в качестве прокси
серверов на Squid3 на недавно вышедшем тогда Debian 8 Jessie, тогда я уже
19
использовал их для объединения локальных сетей, но в рамках одной площадки,
когда одно здание было подключено к сети Интернет посредством модема
провайдера Ростелеком, а другое посредством радио канала провайдера Флекс.
Теперь с приходом оптики по территории площадки необходимость в этом отпала,
но повторить, теперь с удаленной площадкой не составит труда и так как ни
Debian, ни в частности использованный мной VTun, ни тем более bridge-utils не
запрещены к использованию, то для объединения достаточно обосновать его
необходимость и автоматизация в любом виде, будет здесь что ни на есть валидна.
Для объединения я выбрал интерфейс tap - канальный уровень, так как tun работает
на сетевом уровне модели OSI, следовательно, дополнительно нуждается в
статической маршрутизации, хотя бы на самом сервере, а так как на данный
момент мои сервера стали резервными, уступив место рекомендованным к закупке
РосТех ИКС (Интернет контроль сервер) серверам, то далеко не всем клиентам
являются шлюзом по умолчанию, то и статической маршрутизацией на клиенте
тоже, что весьма трудоёмко и неудобно. Тут стоит отметить, что ИКС серверы
имеют очень удобный и простой веб интерфейс для создания VPN (Virtual Private
Network) туннелей IPIP и GRE, однако они так же работают на сетевом уровне
модели OSI, следовательно, нуждаются в статической маршрутизации, и если не
являются стандартным шлюзом, то и маршрутизации на клиенте, что крайне
неудобно. Решение же с VTun, кроме того, что оно простое и стабильное может
эмулировать Ethernet устройство и при объединении его мостом с реальным
Ethernet интерфейсом и последующей трансляции пакетов и маскарадинга,
настроенного в фаерволе, способно организовать «бесшовную» работу сети, как
если бы (условно) обе площадки были подключены к одному и тому же сетевому
коммутатору, при этом указание шлюза по умолчанию не нужно, ведь оперируем
на канальном уровне.
Прочие настройки по причине содержания внешних адресов я продемонстрировать
не могу, но по этой конфигурации общий принцип понятен.
На этом этапе объединение площадок закончено, и я хочу подытожить сказанное
выше:
1) Существует две сети, физически разделенные между собой, при этом между
NAS серверами (на них же располагаются БД), подключенными к разным
сетям есть общая сетевая папка, доступная только для сотрудников отдела
ИТ для обмена информации между сетями. Эта папка в последствии будет
использована для хранения там заявок, дабы пользователи из обеих сетей
смогли видеть актуальные данные, вне зависимости где они подали заявку и
где просматривают (в пределах внутренней ЛВС).
2) Существует две площадки, ЛВС которых объединены посредством VPN, в
случае с закрытой сетью лицензированным ФСБ и ФСТЭК аппаратно-
20
программным комплексом (в связи с содержанием информации
представляющей как минимум коммерческую тайну), другая открытая с
наличием доступа в сеть Интернет не содержащая ценных данных
объединена простым, но стабильным программным решением.
3) Третье это немаловажное для меня – огромная ограниченность в связи с
прохождением практики (и работы) на оборонном предприятии по
внедрению системы автоматизации заявок, в частности запрет на
использование базы данных (который в итоге не стал проблемой с
использованием текстовой базы), и разработка с нуля, дабы специалист по
безопасности мог удостовериться в отсутствии «закладок» и разрешить
тестирование и внедрение на заводе.
В заключение этой главы скажу, что оба сервера Apache в обеих сетях уже были
настроены мною еще много лет назад, единственное, что я обновил PHP до
актуальной 7.2.6 версии.
Ниже на рисунке 2 отображено общее представление программной архитектуры и
далее сноски и комментатии к нему.
21
Головное предприятие АО
«НПО «Прибор» г. Москва
Криптошлюз
3
Соболь
Криптошлюз
3
Соболь
Прокси
2
VTun
ПК
пользователей
1
Браузер
ПК
пользователей
1
Браузер
Прокси
2
VTun
Криптошлюз
3
Соболь
ПК
пользователей
1
Браузер
ПК
пользователей
1
Браузер
NAS сервер (сервер БД)
6
DLP Сервер
5
DLP
Веб-сервер
4
Apache 2.4
PHP 7.2.6
Веб-сервер
4
Apache 2.4
PHP 7.2.6
Сетевое
хранилище
NAS сервер(сервер БД)
6
Сетевое
хранилище
Производственная площадка филиала №2
.
Производственная площадка филиала №1
Рисунок 2. Представление программной архитектуры на предприятии.
Сеть Интернет
ethernet
ethernet
IPIP
IPIP
tap
http
http
ethernet
smb/cifs
smb/cifs
bridge
bridge
ethernet
ethernet
ethernet
ethernet
http
smb/cifs
ethernet
Источник: https://baza.diplomsite.ru/previewfile/1972