Требования к архитектуре информационных систем и их компонентам для обеспечения безопасности функционирования
4 ноября 2017
Рубрика: Обзоры и мнения.
Автор: Б. Шкляревский.

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

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

Основу проекта любой ИС составляют методологии, технологии и инструментальные средства проектирования (CASE-средства). Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ (жизненный цикл).

Технология проектирования — совокупность трех составляющих:

  • пошаговая процедура — последовательность технологических операций проектирования;
  • критерии и правила, используемые для оценки результатов выполнения технологических операций;
  • нотации (графических и текстовых средств), используемые для описания проектируемой системы.

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

Технология проектирования, разработки и сопровождения ИС должна:

  • поддерживать ЖЦ ПО;
  • обеспечивать достижение целей разработки ИС с требуемым качеством и в установленное время;
  • давать возможность выполнения крупных проектов в виде подсистем, т.е. разбивать проект на составные части, разрабатываемые группами исполнителей с последующей интеграцией составных частей. Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
  • обеспечить возможность ведения работ по проектированию отдельных подсистем несколькими специалистами. Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
  • обеспечивать минимальное время получения работоспособной ИС. Речь идет о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта внедрение идет последовательно по отдельным подсистемам;
  • предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
  • обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
  • быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

  • стандарт проектирования;
  • стандарт оформления проектной документации;
  • стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

  • набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
  • правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов, набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм и т.д.;
  • требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т.д.;
  • механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проект­ной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т.д.

Стандарт оформления проектной документации должен устанавливать:

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

Стандарт интерфейса пользователя должен устанавливать:

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

RAD-методология разработки приложений

Одним из подходов к разработке ПО является, получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 компонента:

  • небольшую команду программистов (от 2 до 10 человек);
  • короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
  • повторяющийся цикл, при котором разработчики запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком в процессе разработки.

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

Жизненный цикл ПО по методологии RAD состоит из фаз:

  • анализа и планирования требований;
  • проектирования;
  • построения;
  • внедрения.

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

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

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

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

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

Простота и управляемость ИС в целом и защитных средств в особенности. Только в простой и управляемой системе можно проверить согласованность конфигурации различных компонентов и осуществлять централизованное администрирование. В этой связи важно отметить интегрирующую роль Web-сервиса, скрывающего разнообразие обслуживаемых объектов и предоставляющего единый, наглядный интерфейс. Соответственно, если объекты некоторого вида (например, таблицы базы данных) доступны через Интернет, необходимо заблокировать прямой доступ к ним, поскольку в противном случае система будет уязвимой, сложной и плохо управляемой.

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

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

В зависимости от характеристик объекта разработки, на ее выполнение выделяются ресурсы различных видов. Их величины значительно влияют на технико-экономические показатели, качество и технологическую безопасность всего проекта ИС. В результате сложность программ и баз данных, а также доступные ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов разработки, на достигаемое качество и безопасность ИС. При этом следует учитывать, что каждый вид ресурсов в реальных условиях в той или иной степени ограничен.

Целесообразно разделять ресурсы, необходимые для непосредственного решения основных функциональных задач ИС, и ресурсы, требующиеся для обеспечения безопасности функционирования БД. Соотношение между этими видами ресурсов в реальных ИС зависит от сложности и состава решаемых функциональных задач, степени их критичности и требований к безопасности всей информационной системы. В различных ИС ресурсы на обеспечение надежности и безопасности могут составлять от 5–20% до 100–300% от ресурсов, используемых на решение функциональных задач, то есть в особых случаях могут превышать последние в 2–4 раза.

Наиболее общим видом ресурсов, используемых при создании ИС, являются допустимые финансово-экономические затраты или сметная стоимость разработки. При анализе безопасности этот показатель может применяться или как вид ресурсных ограничений, или как оптимизируемый критерий.

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

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

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

Аппаратурная оснащенность разработки конкретной ИС определяется, прежде всего, ресурсами и другими характеристиками реализующей и технологической ЭВМ.

Тип реализующей ЭВМ, ее ресурсы определяют возможность размещения на ней создаваемых и БД и средств обеспечения безопасности.

Тип технологической ЭВМ ограничивает номенклатуру и характеристики средств автоматизации разработки, доступных при создании ИС. Кроме того, должна быть обеспечена возможность размещения на технологической ЭВМ баз данных проектируемой ИС. В результате необходимые ресурсы технологической ЭВМ, как правило, значительно превышают ресурсы реализующей ЭВМ и объем создаваемых БД.

Для размещения средств обеспечения информационной безопасности ИС в реализующей ЭВМ необходимы програм­мная и информационная избыточности в виде ресурсов внешней и внутренней памяти ЭВМ. Кроме того, для функционирования средств защиты необходима временная избыточность — дополнительная производительность ЭВМ. Эти виды избыточности вычислительных ресурсов при обеспечении технологической безопасности используются для:

  • генерации тестовых наборов или хранения тестов для контроля работо­способности и целостности БД при функционировании ИС;
  • оперативного контроля и обнаружения дефектов исполнения программ и обработки данных при использовании ИС по прямому назначению;
  • реализации процедур анализа выявленных дефектов и оперативного восстановления вычислительного процесса, программ и данных (рестарта) после обнаружения аномалий функционирования ИС;
  • накопления и хранения данных о выявленных дефектах, сбоях и отказах в процессе исполнения программ и обработки данных.

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

  1. Генерация страниц по запросу. Системы такого типа работают на основе связки «Модуль редактирования — База данных — Модуль представления». Модуль представления генерирует страницу с содержанием при запросе на него, на основе информации из базы данных. Информация в базе данных изменяется с помощью модуля редактирования. Страницы заново создаются сервером при каждом запросе, что в свою очередь создает дополнительную нагрузку на системные ресурсы. Нагрузка может быть многократно снижена при использовании средств кэширования, которые имеются в современных Web-серверах.
  2. Генерация страниц при редактировании. Системы этого типа — суть программы для редактирования страниц, которые при внесении изменений в содержание сайта создают набор статических страниц. При таком способе в жертву приносится интерактивность между посетителем и содержимым сайта.
  3. Смешанный тип. Как понятно из названия, сочетает в себе преимущества первых двух. Может быть реализован путем кэширования — модуль представления генерирует страницу один раз, в дальнейшем она в несколько раз быстрее подгружается из кэша. Кэш может обновляться как автоматически, по истечении некоторого срока времени или при внесении изменений в определенные разделы сайта, так и вручную по команде администратора. Другой подход — сохранение определенных информационных блоков на этапе редактирования сайта и сборка страницы из этих блоков при запросе соответствующей страницы пользователем.

С учетом вышесказанного можно сделать вывод, что широта охвата и используемость сети Интернет, а значит и Web-приложений (систем управления контентом), носит колоссальный характер.

Однако современное Web-приложение это не только совокупность файлов, расположенных на Web-сервере, это набор программного обеспечения, необходимого для полноценной работы Web-приложения и включающего в себя:

  1. Систему управления контентом (CMS) — непосредственно само Web-приложение.
  2. Web-сервер — необходимый для работы Web-приложения и взаимодействия с браузерами клиентов.
  3. Сервер СУБД — необходимый для хранения данных Web-приложения.
  4. HTTP Прокси-сервер — необходимый для уменьшения нагрузки на Web-сервер.
  5. FTP-сервер — необходимый для удаленного доступа к файлам и скриптам Web-приложения.
  6. Почтовый сервер — необходимый для получения и отправки почтовых сообщений клиентам (пользователям).

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

Литература:

  1. Глухих М. И., Ицыксон В. М. Программная инженерия. Обеспечение качества программных средств методами статического анализа. СПб.: Изд-во Политехн. ун-та, 2011. 150 с.
  2. Марков А. С., Миронов С. В., Цирлов В. Л.Выявление уязвимостей программного обеспечения в процессе сертификации // Известия Южного федерального университета. Технические науки. 2006. Т. 62, №7. С. 82–87.
  3. Марков А. С., Фадин А. А., Цирлов В. Л.Концептуальные основы построения анализатора безопасности програм­много кода // Программные продукты и системы. 2012. №2.

Автор: Богдан Шкляревский, врио начальника отдела нормативно-методологического обеспечения Центра информационной безопасности и содействия в обеспечении общественного порядка Министерства по развитию информационных технологий и коммуникаций Республики Узбекистан

Orphus system
Подписывайтесь на канал infoCOM.UZ в Telegram, чтобы первыми узнавать об ИКТ новостях Узбекистана
В Telegram
В WhatsApp
В Одноклассники
ВКонтакте