47
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Модель жизненного цикла - структура, содержащая процессы, действия и задачи,
которые осуществляются в ходе разработки, функционирования и сопровождения
программного продукта в течение всей жизни системы, от определения требований
до завершения ее использования.
Требования, предъявленные к внедряемой системе в условиях жестких
ограничений, накладываемых фактором оборонного предприятия, были таковыми:
1) Создать электронную версию журнала заявок, полностью повторяющую
таблицу последней;
2) Обеспечить возможность печати таблицы, для подшивки в журнал заявок;
3) Обеспечить доступность и актуальность данных с любого рабочего места,
подключенного к сети;
4) Использовать только имеющиеся вычислительные мощности;
5) Не использовать базы данных, кроме текстовых, для обеспечения
возможности проверки содержимого файлов DLP системой;
6) Не использовать дополнительного ПО на серверах предприятия;
7) Внедрение осуществить собственными силами, в порядке собственной
инициативы;
8) Внедрение системы не должно повлечь за собой любые риски, или затраты;
9) Специалисту по ИБ обеспечить проверку исходного кода на закладки;
10) (Правка ведущего специалиста по безопасности и технологиям) Не
использовать крупные текстовые файлы, для обеспечения быстродействия
DLP системы. Использовать кодировку Windows-1251;
Всеми этапами разработки и внедрения информационной системы занимался
непосредственно я, контролем и проверкой занимался специалист по
информационной безопасности.
ГОСТ 34.601-90. Стандарт распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. В нём содержится описание работ на
каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей
степени соответствуют каскадной модели жизненного цикла.
ISO/IEC 12207:2008. Стандарт распространяется на процессы и организацию
жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не
содержит описания фаз, стадий этапов.
48
Custom Development Method (СDM) разработка прикладных информационных
систем под заказ - конкретный материал, детализированный до уровня заготовок
проектных документов, рассчитанных на использование в проектах с применением
Oracle. Степень адаптивности CDM ограничивается следующими моделями
жизненного цикла:
1) Классическая (предусмотрены все работы, задачи и этапы);
2) Быстрая разработка (Fast Track);
3) Облегченный подход (в случае малых проектов и возможности быстро
прототипировать приложения).
Rational Unified Process (RUP) предлагает модель разработки, состоящую из:
1) Начало;
2) Исследование;
3) Построение;
4) Внедрение.
Каждая фаза может быть разбита на этапы, в результате которых выпускается
версия для внутреннего или внешнего использования. Прохождение через четыре
основные фазы называется циклом разработки, каждый цикл завершается
генерацией версии системы. Если после этого работа над проектом не
прекращается, то полученный продукт продолжает развиваться и снова минует те
же фазы. RUP расчитан на создание и сопровождение моделей, но не бумажных
документов, процесс привязан к использованию конкретных средств
моделирования, а также конкретной технологии проектирования и разработки.
Microsoft Solution Framework (MSF) похожа на RUP, она включает в себя
следующие фазы:
1) Анализ;
2) Проектирование;
3) Разработку;
4) Стабилизацию.
Microsoft Solution Framework предполагает использование объектно-
ориентированного моделирования и ориентирована на разработку бизнес
приложений.
Microsoft Solutions Framework - это сбалансированная технология, ориентированная
на малые проектные группы или единственного разработчика. MSF не накладывает
ограничений на используемый инструментарий и содержит рекомендации весьма
общего характера. Однако, эти рекомендации могут быть использованы для
построения конкретного процесса, соответствующего потребностям разработчика.
49
Microsoft Solutions Framework была выбрана мной как наиболее сбалансированная
технологиея, ориентированная на малые проектные группы или единственного
разработчика. Microsoft Solutions Framework содержит рекомендации весьма
общего характера, но несмотря на это, эти рекомендации могут быть использованы
для построения конкретного процесса, соответствующего потребностям
разработчика.
Основным преимуществом MSF является итерационная модель одновременно с
уточняющими вехами (аналог каскадной модели).
Модель процессов включает следующие основные фазы процесса разработки:
1) Выработка концепции (Envisioning);
2) Планирование (Planning);
3) Разработка (Developing);
4) Стабилизация (Stabilizing) – обеспечение стабильной работы;
5) Внедрение (Deploying).
Кроме этого существует большое количество промежуточных вех, которые
показывают достижение в ходе проекта определенных результатов и разделяют
большие сегменты работы на меньшие, обозримые участки.
Стандарт ЖЦ ИС MSF является наиболее удобным для применения в данном
дипломном проекте.
Существуют следующие основные модели жизненного цикла:
1) Прототип;
2) Каскадная модель;
3) Спиральная модель.
Прототип – это действующий компонент ИС, реализующий отдельные функции и
внешние интерфейсы. Каждая итерация соответствует созданию фрагмента или
версии ИС, на ней уточняются цели и характеристики проекта, оценивается
качество полученных результатов и планируются работы следующей итерации.
Каскадная модель предусматривает последовательное выполнение всех этапов
проекта в строго фиксированном порядке. Переход на следующий этап означает
полное завершение работ на предыдущем этапе. Требования, определенные на
стадии формирования требований, строго документируются в виде технического
задания и фиксируются на все время разработки проекта. Каждая стадия
завершается выпуском полного комплекта документации, достаточной для того,
чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью изображены на рисунке 8:
50
Рисунок 8. Каскадная схема разработки.
Спиральная модель основана на PDCA (Plan Do Сheck Аct). При использовании
этой модели ИС создается в несколько интераций методом прототипирования.
Основная проблема спирального цикла — это определение момента перехода на
следующий этап. Для ее решения необходимо ввести временные ограничения на
каждый из этапов жизненного цикла. Переход осуществляется в соответствии с
планом, даже если не вся запланированная работа закончена. План составляется на
основе статистических данных, полученных в предыдущих проектах, и личного
опыта разработчиков. На рисунке 9 представлено графическое изображение
спиральной модели жизненного цикла ИС.
Рисунок 9. Спиральная модель жизненного цикла ИС
51
Я буду использовать спиральную модель жизненного цикла информационной
системы, так как мне в последствии предстоит сопровождение и доработка ИС, и
эта модель, как нельзя лучше позволяет учитывать пожелания пользователей и
рекомендации специалистов ИБ, включая их в новые версии.
Существуют четыре основные стратегии внедрения системы:
1) Параллельная стратегия - когда одновременно работают старая (ручная) и
новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему;
2) Скачок - это резкий переход от старой системы к новой без дополнительных
проверок и с полным отказом от старой системы;
3) Пилотный проект - наиболее часто используемая стратегия - это тактика
скачка, но применяемая к ограниченному числу процессов. Область
применения стратегии - небольшой участок деятельности. Такой подход
снижает риск и наиболее надежен;
4) Узкое место - это малая часть производственного процесса. При
использовании подхода «узкое место» план внедрения выполняется только
для узкого места и для людей, работающих в нем.
В данном случае будет применена «Параллельная стратегия». Так как будет
производится переход к автоматизированной системе для регистрации и обработки
заявок Областью применения внедрения будет отдел ИТ, при этом существующая
система журнала учёта заявок будет использоваться параллельно, до окончания
тестирования и полного перехода.
Несмотря на ограничения, накладываемые техническим заданием, обусловленные
спецификой предприятия и его бюрократической машиной, система прошла хоть и
небольшое, но тестирование и уже используется.
52
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Классификация информационно технических рисков помогает предупредить, или
предотвратить несогласованность работы, не упустив при этом значительного
риска. Классификация рисков может являться произвольной. Категории рисков
могут друг с другом пересекаться, при этом нужно учесть все предполагаемые
риски. Пример категории рисков отображен в Таблице 4.
Таблица 4. Примерные категории рисков
Категория
Показатель
Пример
Технологический
Ненадежная, или не
отвечающая потребностям
аппаратная или программная
ИС
Сбой в работе коммутатора.
Сбой в работе веб-сервера.
Безопасность
Повреждение или кража
аппаратных средств, или
данных,
несанкционированное
использование данных.
Утечка данных на оптических
дисках, дискетах и тому
подобное.
Брутфорс паролей. DDOS атаки.
Правовой риск
Отсутствие регламента
использования
, несоблюдение
внутреннего режима на
предприятии.
Применение взломанного
программного обеспечения.
Инсталяция несовместимого
программного обеспечения.
Человеческий
фактор
Человеческий фактор,
сокращение сотрудников
отвечавших за поддержку
ИС.
Недостаточная квалификация
персонала.
Инфраструктурный
Сбои в электроснабжении.
Модернизация сети
приводящая к недоступности
доступа на некоторых узлах.
Недоступность доступа к ИС.
53
При оценке риска возможно использование качественного анализа, тогда уровень
риска будет являться соотношением вероятности инцидента к его воздействию на
работу. Структура показана в таблице 5.
Таблица 5. Структура оценки рисков.
Вероятность возникновения
Высокая
Один раз за месяц, либо чаще.
Средняя
От одного до десяти случаев в год.
Низкая
Один раз за год, либо меньше.
Воздействие на работу
Высокое
Простой более чем на сутки.
Среднее
Простой от часа до смены.
Низкое
Простой менее, чем на час.
Уровень риска показан в таблице 6.
Таблица 6. Определение уровня рисков.
Воздействие
Вероятность
Высокое Среднeе Низкое
Высокая
Чрезвычайная
Высокая
Средняя
Средняя
Высокая
Средняя
Низкая
Низкая
Средняя
Низкая
Низкая
Снижение рисков, это уменьшение вероятности возникновения инцидента, или
уровня его воздействия на работу. Предпринимаемые меры сильно отличаются и
определяются срочностью, связанной с уровнем рисков. Смотри таблицу 7.
Таблица 7. Предпринимаемые меры, связанные с уровнем рисков.
Уровень
риска
Предпринимаемые действия
Чрезвычайный
Требуется срочное вмешательство ответственного сотрудника.
Руководитель отдела информационных технологий должен быть
уведомлен о текущей ситуации и предпринимаемым мерам, для её
разрешения.
54
Высокий
Ответственный за сопровождение информационной системы
сотрудник, должен заняться восстановлением работоспособности,
устранением ошибок к
ода ИС, или устранением неисправностей в
аппаратной или программной части.
Средний
Ответственный за сопровождение информационной системы
сотрудник, должен заняться восстановлением работоспособности,
оптимизацией кода ИС, или устранением неисправностей в
аппаратной или программной части.
Низкий
Допустимый уровень риска, который не требует вмешательства.
При необходимости возможно произвести оценку повторно.
Детализированная оценка рисков и дополнительных мер по их снижению включает
изменения изменения регламента пользования ИС, повышение квалификации
сотрудников, резервирование баз, создание образов дисков, введение в
эксплуатацию резервного оборудования, пересмотр политики безопасности
паролей, переработка или дополнение документации информационной системы.
Ответственному сотруднику необходимо изучать возможности возникновения
рисков и оценивать эффективность работы над снижением риска. Данные
мероприятия должны осуществляться ответственным за эксплуатацию
сотрудником на постоянной основе.
Так как информационная система уже внедрена мной на предприятии и
эксплуатируется на данный момент на тестовой основе несколькими отделами,
оценка рисков на этапах разработки и внедрения здесь неприменима,
предварительная оценка же на этапе эксплуатации, оценивается мной как низкая по
нескольким показателям:
1) Отсутствуют финансовые риски эксплуатации, связанные с тем что на всех
этапах, используются уже имеющиеся аппаратные и программные
мощности, а поддержка в работоспособном состоянии аппаратной части
связана не столько с поддержкой ИС, как с постоянной поддержкой всех
серверов постоянным штатом сотрудников отдела ИТ;
2) Сбои в электропитании, во всяком случае кратковременные (час и менее)
исключены, так как серверная оборудована восьми киловатным
стабилизатором напряжения IEK СНИ1-10 КВА и тремя источниками
бесперебойного питания IPPON Renova RT 3000. Таким образом
производится стабилизация напряжения, защита от пониженного и
повышенного напряжения оборудования и автономное питание серверов,
маршрутизаторов и коммутаторов сроком до часа;
3) Технологический фактор риска сокращен до минимума постоянной работой
по обслуживанию аппаратной составляющей на предприятии постоянным
штатом сотрудников отдела ИТ;
55
4) За соблюдением правовых рисков следят два специалиста по
информационной безопасности отдела ИТ;
5) Утечка данных сведена к минимуму, как работой специалистов по
информационной безопасности отдела ИТ, специалистов ИБ управления
безопасности, и самое основное отсутствием в заявках хоть какой-то
информации представляющей ценность для инсайдера, например;
6) Базы данных реплицируются, сама ИС имеет дистрибутив с инструкцией для
развертывания, позволяющей быстро создать резервную версию сервера.
7) Единственная наибольшая вероятность риска – это человеческий фактор,
связанный, например, с уходом ответственного за разработку, внедрение и в
последствии поддержку (то есть меня) с занимаемой должности, или
сокращением, что в свою очередь означает отсутствие поддержки и
доработки ИС в перспективе.
56
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации.
Организационно-правовыми средствами обеспечения информационной
безопасности и защиты информации на предприятии в частности в отношении
использования информационных систем является регламент использование ИС, за
разработку которого отвечает РСО (Режимно-Секретный Отдел), так же
подчиняющийся УБ, совместно с ООТ (Отдел Организации Труда).
Защитой информации в филиале занимается УБ (Управление Безопасности), под
начальством которого и находится отдел ИТ (Информационных технологий),
разработкой нормативно-правовых и организационно-распорядительные
документов, регламентов, процедур, должностных инструкции и т.д., занимается
РСО (Режимно-Секретный Отдел), так же подчиняющийся УБ, совместно с ООТ
(Отдел Организации Труда), за соблюдение режима на предприятии отвечает ОВБ
(Отдел Внутренней Безопасности), в нашем отделе ИТ, полное название которого
ОИБиТ (Отдел Информационной Безопасности и Технологий) двое из
сотрудников, по совместительству, обеспечивают ИБ (Информационную
Безопасность), отдельных штатных единиц для этого нет. Итак, за «внешнюю»
безопасность отвечает сотрудник ОИБиТ должность которого звучит как –
Ведущий специалист по безопасности, информационным технологиям и
противодействию иностранной разведке второй формы допуска к государственной
тайне, это самый высокий допуск в нашем отделе, равный допуску, собственно
начальника УБ, остальные же сотрудники, в том числе я имеют третью форму
допуска к государственной тайне. За «внутреннюю» безопасность отвечает
специалист по безопасности и информационным технологиям.
Из мер защиты хищения информации за которую отвечает специалист по
безопасности и информационным технологиям можно выделить политики домена,
запрещающие установки устройств USB и использование USB накопителей,
рабочие места подвергаются периодической выборочной проверке сотрудниками
ОИБиТ или РСО.
В «закрытой» сети (без доступа в Интернет, физически разделенной с открытой
сетью и содержащей коммерческую тайну) также работает DLP система,
клиентская часть которой установлена на каждое рабочее место и может работать
автономно, синхронизируясь с серверной частью в момент последующего
подключения к сети, серверная часть занимается сбором данных с клиентов,
анализом содержимого сетевых папок и анализом трафика в сети. Наименование
DLP системы я разгласить не могу, но это могут быть, например, системы
FalconGaze или Стахановец. Так же DLP собирает периодические снимки рабочих
экранов клиентов, периодическим выборочным анализом которых занимаются
РСО, ОВБ и ОИБиТ.