57
необходимые данные, чтобы не возникало недопонимания и проблем с
недостатком или искажением информации.
Рис. 7. Предлагаемые этапы стандарта
Поскольку кроме системных администраторов никто лучше не знает
инфраструктуру проекта «TopHotels», делать данное исследование необходимо
именно им, занося все результаты в соответствующие документы. В качестве
58
помощи может быть задействован технический писатель, который может помочь
оформить все документы более правильным образом.
Проектирование (разработка) включает в себя этапы и подэтапы:
• Предварительное проектирование;
o Описание реальных компонентов будущей ИС;
o Разработка, оформление и утверждение технического проекта (ТП).
• Более детальное проектирование:
o Разработка архитектуры проекта;
o Создание документации на установку программных продуктов;
o Выбор комплекса технических средств;
o разработка техно-рабочего проекта (ТРП) ИС.
Основной целью данного этапа и его подэтапов является создание рабочего
проекта и его полное проектирование на бумаге. Данный этап включает в себя
обработку входных данных, полученных на предыдущем этапе, их перенос на
техническую часть проекта. В этап могут входить предварительные тестовые
стэнды и проектные эксперименты. Окончательной целью данного этапа
является полностью готовый бумажный проект. Аналогично предыдущему
этапу, реализация должна лежать на системных администраторах.
Этап реализации проекта (производство):
• Производство ИС на основе разработанного на этапе проектирования
проекта;
• Разворачивание и настройка технических и программных средств;
• Подготовка документации и учебных материалов;
• Тестирование разработанного проекта в тестовой среде, изолированной от
продуктивной среды;
• Доработка возможных ошибок, найденных в ходе разработки, внесение
результатов в документацию, если это необходимо;
В данный этап входит разворачивание ПО, написание сценариев автоматизации
и кода, внедрение и настройка – одним словом производство проекта по
документам, сделанным на предыдущих этапах. Этап также включает стадию
тестирования, результаты которой могут уйти в проектную документацию,
которая была сделана на предыдущем этапе. Всё это разрабатывается при
помощи системных администраторов. Конечной целью данного этапа является
59
получение готовой работающей оттестированной версии проекта, готовой к
внедрению на продуктивной среде.
Этап внедрения (применение):
• Ввод разработанного решения в инфраструктуру проекта «TopHotels»;
• Обучение системных администраторов, для которых разрабатывался
данный проект автоматизации;
• написание документации по использованию, введение проекта в в
процессы работы отдела, изменение регулирующих документов и актов,
таких как служебные обязанности работников отдела итд;
Целью этапа внедрения является установка и настройка проекта в продуктивную
среду, написание документации, по которой системные администраторы будут
осуществлять свою деятельность. Это совместный запуск системы с целью
обучения на реальных задачах, доработка документации. Также в этап входит
возможные исправления неточностей скриптов и кода, которые не были учтены
во время тестирования на не продуктивной среде. Данный этап проводится
системными администраторами вместе с руководителем.
Эксплуатация и сопровождение (использование, поддержка применения):
• Эксплуатация разработанного решения;
• Сопровождение разработанного решения;
Целью данного этапа является использование разработанного проекта по
назначению, закрепления процесса автоматизации как бизнес-процесса
компании. Поскольку решение, описанное в данном дипломном проекте не
является конечным по концепции «инфраструктура как код», в процесс
эксплуатации и сопровождения также входит продолжение разработки с целью
продолжения автоматизации рутинных задач системных администраторов.
Поскольку разработчиками были системные администраторами, делая проект
для автоматизации задач своего отдела, пользователями системы на данном
этапе будут также они.
Этап перевода в категорию непригодных для применения.
Данный этап не учитывается в проекте так как для принятия решения перевода
ИС в категорию непригодных для применения, ИС должна пройти этап
использования. В данный дипломный проект не закладывается прогнозирование
критериев выполнения описываемого этапа.
60
В таблице 11 указаны выбранные стадии ЖЦ ИС.
Таблица 11
Пример стадий, их целей и основных схем решений
Стадия
жизненного цикла
Цель
Схема решений
Замысел
Определить потребности
Исследовать замыслы
Предложить жизнеспособные
решения
Вариант решения:
- выполнить
следующую стадию;
- продолжить данную
стадию;
- вернуться к
предыдущей стадии;
- приостановить проект;
- завершить проект
Разработка
Уточнить требования к системе
Создать описание решений
Создать систему
Провести верификацию и
валидацию системы
Производство
Произвести систему
Проконтролировать и испытать
Применение
Обеспечить применение
системы для удовлетворения
потребностей пользователей
Поддержка
применения
Обеспечить устойчивую
реализацию возможностей
системы
Перевод в
категорию
непригодных для
применения
Хранение, архивирование или
списание системы
61
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Выбранный в главе 2.1.1 ГОСТ Р 57193–2016 стандарт жизненного цикла
ПО покрывает основные риски, связанные с реализацией проекта. Однако в
выбранном стандарте покрытие рисков происходит поверхностно, оставляя
возможность использовать данный стандарт для множества различных
проектов[1]. Поскольку каждый проект уникален, риски у каждого из них могут
быть свои. Ниже по тесту рассматриваются возможные риски для данного
дипломного проекта.
На этапе анализа требований проекта (замысла), самыми серьезными
рисками являются:
• Возможность неправильной постановки задачи, которая, в свою очередь
может повлечь неправильный процесс бизнес анализа. На данном этапе
проекта происходит анализ имеющихся данных, статистики, анализ
пересекающихся информационных систем, системный анализ
инфраструктуры. Если данные на данном этапе будут собраны на
неверных данных, это может повлечь ошибочное проектирование и не
оправдывающее ожидания проект, который придется дорабатывать, или
отказаться от него если выделенные на него средства или трудозатраты
были потрачены впустую.
На этапе проектирования (разработки), могут возникнуть следующие проблемы:
• Неправильный анализ требований проекта, описанный в предыдущей
части данного параграфа. В случае, если проектирование проекта будет
происходить сложными, или с неправильно проанализированными
данными, на выходе может получиться решение, не удовлетворяющее
изначальным требованиям. Именно по этому для избегания данного риска,
необходимо уделять максимальное внимание правильности постановки
задачи, и правильному анализу.
На этапе реализации проекта (производства) основными рисками являются:
• Возможность возникновения проблем неправильной интерпретации
сделанных в предыдущих этапах документов. В этом случае, срок
разработки может увеличиться. Для решения данной проблемы, считается
необходимым использовать подход, который подразумевает тестирование
небольших участков автоматизируемых задач во время разработки. Это
62
поможет сразу убедиться в том, что все работает в соответствии с
проектом.
• Пропуск серьезных ошибок в конфигурации или коде проекта. В этом
случае, во время эксплуатации проекта могут возникнуть проблемы в виде
неправильно выполненной на сервере задачи и потенциально возможное
уменьшение времени доступности проекта «TopHotels» во время
выполнения рутинной задачи системного администрирования. Это также
влечет за собой возможную потерю прибыли. Для предотвращения этого
риска, тестирование должно производится с заранее продуманными
сценариями тестирования, которые предусматривают такие варианты
развития событий, используя программу методики испытаний.
На этапе внедрения (применения), основными потенциальными рисками
являются:
• На этапе внедрения существует риск неправильной конфигурации ПО в
продуктивной среде. Данный риск характеризуется потенциальной
возможностью запуска автоматизированных задач не по значению, по
ошибке или на ошибочные серверы. Проблема является аналогичной той,
что описана в рисках этапа эксплуатации. Проблема решается
аналогичным образом.
На этапе эксплуатации и сопровождения (использование, поддержка
применения) могут возникнуть следующие риски:
• Неправильное применение разработанного проекта автоматизации
системными администраторами. Например, при подготовке к запуску
задачи возможна ошибочная конфигурация файла задач, что может
повлечь случайный запуск на сервере, где выполнение этой задачи не
нужно. Это может повлечь за собой уменьшение времени доступности
проекта «TopHotels». Данная проблема решается написанием
качественной документации по разработанной системе автоматизации.
• Единая точка входа в виде системы контроля конфигурации, которая
работает на сервере. При несоблюдении политики безопасности, является
серьезной угрозой для проекта. При соблюдении – проблемой не является.
63
• Массовый запуск задач, когда это не нужно. Данная проблема решается
написанием качественной документации, обучению сотрудника и знанием
должностных обязанностей а также соблюдением политики безопасности.
64
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Важнейшим пунктом в разработке и реализации любого проекта является
аспект информационной безопасности. ГОСТ Р 57193–2016 покрывает данный
вопрос только частично[1]. Он описывает, что предохранение информации и
данных должно быть организовано таким образом, чтобы неуполномоченные
лица или системы не могли их читать или изменять, а уполномоченным лицам
или системам не было отказано в доступе к ним. Формально, данный пункт в
нескольких фразах полностью описывает основные базовые требования к
безопасности, однако для каждого проекта на стадии разработки эти требования
должны быть проработаны для каждого проекта в индивидуальном порядке.
Рассмотрим раздел политики безопасности для внутренних угроз. Каждый
системный администратор прикреплён к своему проекту (или нескольким) за
которые он ответственен, по этому считается, что он должен иметь необходимый
доступ только к тем серверам, которые он должен обслуживать. Организация
доступа системных администраторов к серверам происходит через систему
LDAP в интерфейсе GOSA, в котором руководитель системных
администраторов производит выдачу необходимых прав и групп. Данный проект
подразумевает проработку автоматизации сложной серверной инфраструктуры,
которую в конечном итоге будут использовать специалисты, хорошо
разбирающиеся в информационной безопасности. Это означает, что доступ к
системе должен быть тщательно проработан, а эти требования быть занесены в
политику информационной безопасности компании. Основные из положений,
которые позволят избежать основных часто распространяемых проблем
безопасности при доступе к узлу управления:
• Каждый системный администратор должен иметь стойкий пароль к своей
учетной записи LDAP, который состоит из минимум девяти латинских
символов, один из которых должен быть заглавным; содержит минимум
одну цифру и содержит минимум один специальный знак;
• Запрет авторизации при администрировании серверов проекта из под
пользователя root. Данный пункт принят ко всем серверам в компании и
разрабатываемый проект автоматизации инфраструры не является
исключением;
65
• Запрет смены пользователя сервера на пользователя root, если текущий
пользователь не состоит в группе sudo. Это создаст дополнительный слой
безопасности, который защитит сервер от скомпрометированного пароля
root от злоумышленника, которые имеет доступ к серверу и знает этот
пароль;
• Каждый системный администратор должен использовать свой
уникальный логин для доступа к серверам. Это обусловлено тем, что на
общих учетных записях, используемых для администрирования серверов
администраторами, может произойти утечка пароля;
• Использование только защищенного протокола SSH2. Такие протоколы,
как SSH версии 1 или Telnet не разрешаются;
• Запрет логина по паролю. Для администрирования серверов, должен быть
запрещен доступ на серверы по протоколу SSH2 используя связку логин-
пароль. Для доступа на сервер должны использоваться RSA ключи с
длинной, минимальным размером который составляет 2048 бит. Это
обусловлено тем, что даже в случае утечки пароля личной учетной записи
LDAP системного администратора, злоумышленник не получит доступ к
серверу, так как не имеет секретную часть связки ключа RSA. То есть, в
случае если пользователь подсоединяется к серверу по протоколу SSH2
при помощи пароля, эта попытка соединения будет разорвана сервером.
• Централизованное управление ключами. Как было написано выше,
каждый системный администратор имеет свою собственную учетную
запись в системе DLAP. Поскольку согласно должностным обязанностям
администратор должен администрировать серверы проекта, он должен
заходить на серверы по протоколу SSH2. Каждый администратор
генерирует на своей рабочей станции собственную пару ключей RSA,
загружая самостоятельно в личный кабинет системы GOSA. Таким
образом, все ключи централизованы в LDAP и администратору нет
необходимости каждый раз загружать их на сервер, создавая возможность
компрометации ключей. Также, загрузка ключей на сервер вручную
невозможна, так как для этого необходим ввод пароля, который запрещен
политикой безопасности, описанной ранее.
• Своевременное удаление из LDAP уволившихся сотрудников.
66
Рассмотренные выше пункты безопасности распространяются на всех
сотрудников компании и системных администраторов, занимающимися
администрированием серверов через доступ до консоли последних. С вводом
нашего проекта в работу, часть задач системных администраторов будет
автоматизирована. За этим следует, что доступ на конечные серверы им нужен
будет реже, так как автоматизируемые задачи будет запускать система
управления конфигурациями с одного соответствующего сервера. Так как
системе управления конфигурациями нужно также иметь доступ к серверам,
необходимо создать специальных пользователей в LDAP, через которые будет
осуществляться данный доступ. В таблице 12 описаны права пользователей и
групп для системных пользователей системы управления конфигурациями.
Таблица 12
Разрешения системного пользователя системы контроля конфигураций
Тип разрешения
Значение
Хождение только по ssh-ключам
Да
Использование или авторизация под
пользователем root
Не разрешать
Является sudo
Да, выполняет все команды под sudo
Отдельный пользователь для каждого
проекта компании
Да
Возможность авторизации только с
определенного адреса IP
Да
Данное распределение групп позволяет запускать задания системы управления
конфигурации с определенными разрешениями, случайно не затрагивая другие
серверы.
Защита от внешних угроз. Для обеспечении работы проекта «TopHotels»
компания арендует оптические каналы связи, связывая несколько ЦОД между
собой. Данная сеть полностью изолирована от сети Интернет и не может
допустить доступа извне, исключая компрометацию. Внешний доступ
пользователей к проекту предоставляется из Интернет, однако данные
интерфейсы всегда отдельные и не имеют маршрутизации во внутреннюю сеть.