Крючков Основы учёта,контроля 2007

•вопросы защиты информации;

•доступность;

•интерфейс;

•используемую СУБД.

Требования должны быть составлены в измеряемой, конкретной форме. Например, время доступа к таблице равно 2 секундам. Число пользователей, число клиентов, число транзакций в сутки. Необходимо учесть требования стандартов, отчетность. Мы рассматривали примеры таких требований при разборе конкретных программных продуктов и СУиК CoreMAS и E/Z MAS.

После проведения описанных процедур, разработчики должны выбрать из возможных решений единственное, оптимальное. Один из способов выбора – экспертные оценки. Группа экспертов оценивает различные ключевые требования, задавая им рейтинги и оценивая в этих рейтингах альтернативы. Строится таблица параметров. Перемножается рейтинг на оценку и суммируется. Результат выделяет предпочтительные варианты. Затем оцениваются возможные риски срыва разработки.

Наконец, переходим к последнему этапу фазы планирования проекта – созданию спецификации требований к программному обеспечению (SRS). В результате выполнения этого этапа будет создан документ, описывающий основные требования к ПО. На основании этого документа в дальнейшем будет осуществляться проектирование основных программных составляющих проекта. Степень официальности SRS зависит от размеров и важности проекта. Спецификация должна содержать:

•функциональные требования;

•требования к данным;

•технические требования;

•решения;

•проблемы;

•рекомендуемые решения.

Проектирование программного обеспечения

После составления SRS разработчик переходит к этапу непосредственного проектирования программного обеспечения. Результатом этого этапа должна быть созданная база данных: определена

411

структура всех таблиц со связями и средствами, обеспечивающими целостность информации (триггеры, ограничения, сохраняемые процедуры) и Описание проекта программного обеспечения

(Software Design Description – SDD) – подробный документ о струк-

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

Рассмотрим процесс проектирования программного обеспечения и некоторые методики, применяемые при этом. На этапе проектирования должны быть созданы:

•проект архитектуры, который устанавливает соотношения между главными структурными компонентами системы;

•процедурный проект, обеспечивающий преобразование главных структурных компонентов в процедурное описание программного обеспечения, в результате чего создается исходный текст программы;

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

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

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

•должны быть идентифицированы все структуры данных и операции, проводимые с ними;

•при создании программы должен быть создан и использован глоссарий данных;

•последовательная детализация данных – данные низкого уровня откладываются на следующую стадию проектирования,

•структуры данных должны быть известны только тем модулям, которые их непосредственно используют;

•должны быть созданы библиотеки структур данных и связанных с ними функций;

•язык программирования должен поддерживать абстрактные типы данных.

При разработке архитектуры программы первоочередная задача – разработать модульную структуру и показать соотношения между

412

различными модулями. Разработка архитектуры программы сочетает разработку структуры программы с разработкой данных посредством интерфейса между модулями.

Процедурная разработка проводится после того, как устанавливается программная структура (архитектура) и структура данных. Два основных метода используются при процедурной разработке – использование блок–схем и условного языка проектирования (псевдокода).

Испытание программного обеспечения

После того, как ПО спроектировано, наступает этап непосредственного кодирования. После проделанной ранее работы это уже не вызывает труда. Данный этап занимает небольшую часть в общих трудозатратах. Практика США показывает, что затраты на написание кодов пренебрежимо малы по сравнению с проектированием и проверкой работоспособности программы. После написания кодов мы подходим к новому этапу – этапу испытания программного обеспечения.

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

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

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

413

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

Ввод СУиК в эксплуатацию

Часто этот этап называют «развертывание». Специалисты США этот этап считают очень важным. Выделяют следующие принципы, которые способствуют гладкому протеканию процесса.

•Осознание важности раннего и тщательного планирования процесса развертывания. Особенно это важно для среды клиент/сервер. Учет предстоящего развертывания на этапе проектирования и тестирования позволит избежать многих болезненных проблем, когда спроектированная и тщательно тестированная система

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

•Следует понимать, что развертывание – планируемый процесс и он не должен нарушать нормальное функционирование предприятия.

•За развертывание должен отвечать один человек.

Приводится следующий пример, который демонстрирует сложности развертывания. Фирма Мицубиси в Калифорнии развертывала некий программный проект. Планировалось провести процесс в течение года. Получилось – два. Расходы на развертывание системы Oracle примерно в 3 раза превысили стоимость разработки программного обеспечения.

Какие проблемы сопровождают развертывание? Выделим основные.

414

•Расходы на сетевое оборудование, СУБД и т.п.

•Отсутствие стандарта на оборудование и ПО компьютеров на стороне клиента.

•Обучение персонала новым стандартам пользовательского интерфейса.

•Ввод ПО, изменяющего привычные стандарты работы.

•Недружелюбный пользователь.

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

Этапы развертывания:

•Аналитическая фаза. Начинается параллельно разработке требований и продолжается все время до начала внедрения. На этой фазе необходимо определить:

– уровень подготовки пользователей, наличие аппаратных средств и ПО;

– требования к параметрам доступной компьютерной техники;

– требования к операционной среде, по контролю доступа и безопасности;

– необходимость преобразования существующих данных;

– роли, обязанности и расходы фазы сопровождения;

– решить вопросы о приобретении нового оборудования и ПО и

олицензионных правах.

•Фаза построения. В этой фазе приобретается оборудование и ПО. Испытываются системы преобразования данных. Готовятся руководства пользователя, по эксплуатации и т.п.

•Обучение – очень важный этап. В США ему уделяют большое внимание. Важно провести обучение своевременно. При ранней подготовке навыки могут забыться, при поздней – пользователь отторгает нововведения. Требуются достаточно большие затраты – подготовка курсов, учебного матобеспечения.

•Фаза развертывания. Выпускаются все документы, проводится обучение, преобразовываются данные, система начинает функционировать.

415

• Завершающий этап. Передаются полномочия на обслуживание системы.

Обслуживание, сопровождение и вывод из эксплуатации

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

Для обслуживания системы требуется определенный штат персонала. Он включает в себя: системных администраторов, администраторов баз данных, специалистов по защите, администраторов сетей, операторов.

Под сопровождением понимается деятельность разработчика по исправлению ошибок, модернизации и развитию системы после ее поставки потребителю. Очень важный вид деятельности. По аналитическим оценкам в США предприятия тратят на сопровождение ПО 70 % бюджета, выделенного на ПО. И только 30 % идет на новое ПО. Выделяют следующие типы сопровождения:

•корректирующее (аварийное и неаварийное);

•адаптивное (новые аппаратные и программные средства при изменении условий);

•усовершенствование;

•профилактическое.

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

Если расходы на поддержание системы превышают прибыль, приносимую системой, то пришло время выводить ее из эксплуата-

416

ции. Обычно при этом существующая система заменяется аналогичной, но более современной.

Список литературы

1.Стандарт отрасли. Оснащение программно–аппаратное систем учета и контроля ядерных материалов. Общие требования. ОСТ 95 10537–97.

2.Веске Дж. Л., Гандерлоу М., Чипмен М. Access и SQL. Руководство разработчика: Пер. с англ. М.: Лори, 1997.

3.Fedorov A., Francis B., Harrison R. et al. Professional Active Server Pages 2.0/ Wrox Press Ltd, 1998.

4.Гостехкомиссия России. Министерство Российской Федерации по атомной энергии. Руководящий документ. Требования по защите от несанкционированного доступа к информации в автоматизированных системах учета и контроля ядерных материалов. М., 1997.

5.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–1–2001. Информационная технология. Методы и средства обеспечения безопасности критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель.

6.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–2–2001. Информационная технология. Часть 2.

7.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–2–2001. Информационная технология. Часть 3.

8.Пискарев А.С., Шеин А.В. О состоянии и перспективах использования Общих критериев оценки безопасности информационных технологий в России для оценки применяемых в СУиК программных средств. – Материалы 5 международного рабочего семинара «Разработка Федеральной автоматизированной информационной системы учета и контроля ядерных материалов России», г. Новоуральск, Свердловской обл., 26–30 мая 2003 г.

9.Федосеев В.Н., Мизин П.П., Шанин О.И. Проблемы и перспективы развития СУиК ЯМ в России с точки зрения системного программного обеспечения. – Материалы 7 международного рабочего семинара «Разработка Федеральной автоматизированной информационной системы учета и контроля ядерных материалов России», г. Звенигород, 11–15 сентября 2006 г.

10.Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного досту-

417

па к информации. Показатели защищенности от несанкционированного доступа к информации. М., 1992.

11.Зегжда Д.П., Ивашко А.М. Основы безопасности информационных систем. М.: Горячая линия – Телеком, 2000.

12.Руссинович М., Соломон Д. Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мас-

тер класс./ Пер. с англ. – 4–е изд. М.: Издательско–торговый дом «Русская редакция», 2005.

13.Уинкуп С. Microsoft SQL Server™ 6.5 в подлиннике: Gер. с

англ. СПб.: BHV – Санкт–Петербург, 1998.

14.Андреев А.Г. и др. Windows SQL Server 2000. Русская версия

/Под общ. ред. А.Н. Чекмарева и Д.Б. Вишнякова. С–Пб.: БХВ, 2003.

15.Шмидт В. Microsoft Visual Basic 5.0 – М.: ABF, 1997.

16.Иванова Е.Б., Вершишнин М.М. Java 2, Tnterprise Edition.

Технология проектирования и разработки. С–Пб.:, 2003.

17.Посполит А.В. Visual Studio.NET: разработка приложений баз данных. СПб.: БХВ – Санкт–Петербург, 2003.

18.Коннэлл Дж. Visual Basic 6. Введение в программирование баз данных: Пер. с англ. М.: ДМК, 2000.

19.Сеппа Д. Microsoft ADO.NET: Пер. с англ. М.: Издательско– торговый дом «Русская редакция»; 2003.

20.Ерыгин А.И., Кушнарев М.С. Интеграция систем учета и контроля ядерных материалов. Проблемы и перспективы. – Материалы 7 международного семинара «Разработка Федеральной автоматизированной системы учета и контроля ядерных материалов России». Звенигород, 11–15 сентября 2006 г.

21.Румянцев А.Н. От учета и контроля – к управлению. Компьютерная СУиК ЯМ, радиоактивных веществ и радиационных источников РНЦ «Курчатовский институт» – система КИ–МАКС // Новости Фис. Информационный бюллетень, №5, 2004.

22.Кондаков В.В. Компьютеризированные системы учета и контроля ядерных материалов: Учеб. пособие. М.: МИФИ, 2001.

23.Кондаков В.В., Ожерельев С.А. Опыт эксплуатации и перспективы развития системы учета и контроля ядерных материалов МИФИ – Материалы 7 международного семинара «Разработка Федеральной автоматизированной системы учета и контроля ядерных материалов России». Звенигород, 11–15 сентября 2006 г.

418

ГЛАВА 8 ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ КОМПЬЮТЕРИЗИРОВАННЫХ СУиК ЯМ

8.1. Защищенные системы обработки информации

При проектировании и эксплуатации автоматизированных систем учета и контроля ядерных материалов (АСУиК ЯМ) одним из основных вопросов является обеспечение сохранности циркулирующей в них информации и ее защиты от несанкционированного доступа (НСД). Приоритетность вопросов обеспечения информационной безопасности определяются тем, что информация, для обработки которой создаются СУиК ЯМ, является предметом государственной тайны. Потеря, искажение или хищение этой информации как в результате умышленных действий, так и вследствие объективных причин может привести к тяжелым последствиям. Поэтому отраслевой стандарт, регламентирующий вопросы программно – аппаратного оснащения СУиК ЯМ [1], требует, чтобы система защиты информации являлась неотъемлемой частью АСУиК ЯМ. На всех этапах функционирования СУиК ЯМ защита информации должна быть обеспечена применением комплекса мероприятий по предотвращению утечки информации или исключению воздействия на нее по техническим каналам, по предупреждению преднамеренных программно–технических воздействий с целью нарушения целостности информации в процессе ее обработки, передачи и хранения или нарушения работоспособности технических средств.

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

419

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

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

Таким образом, защищенная система обработки информации [2], в частности компьютеризированная СУиК ЯМ, должна удовлетворять следующим трем требованиям:

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

•успешно противостоять угрозам безопасности, действующим в определенной среде;

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

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

420