Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Лекции - Технология построения защищенных информационных систем - файл 1.doc


Лекции - Технология построения защищенных информационных систем
скачать (5609.5 kb.)

Доступные файлы (1):

1.doc5610kb.14.12.2011 05:58скачать

содержание

1.doc

  1   2   3   4   5   6   7   8   9   ...   13
Конспект лекций

по дисциплине "Технология построения защищенных автоматизированных систем"

Содержание


I.Часть. Общий подход к построению АС. 4

1.Введение. 4

1.1.Принципы системного подхода при создании сложных систем. 4

1.2.Основные проблемы современных проектов. 5

1.3.Современные тенденции в программной инженерии. 8

2.Нормативно-методическое обеспечение создания АС. 9

2.1.Особенности разработки требований к ПО. 9

2.2.Нормативно-методическое обеспечение создания АС. 9

3.Стандарт жизненного цикла АС. 9

3.1.Основные процессы жизненного цикла АС. 11

3.2.Вспомогательные процессы жизненного цикла АС. 17

3.3.Организационные процессы жизненного цикла АС. 19

4.Модели жизненного цикла АС. 20

4.1.Каскадная модель жизненного цикла АС. 20

4.2.Итерационная модель жизненного цикла АС. 21

4.3.Эволюционная модель жизненного цикла АС. 23

5.Оценка процессрв создания АС. 23

5.1.Понятие зрелости процессов создания АС. 23

5.2.Модель оценки зрелости CMM. 24

6.Общие принципы проектирования АС. 26

6.1.Структурный подход к анализу и проектированию АС. 26

6.2.Визуальное моделирование. 27

7.Методология IDEF. 28

7.1.Обзор методов IDEF. 28

7.2.Метод IDEF0. 29

7.3.Метод IDEF3. 34

7.4.Метод IDEF1. 37

8.Методология eEPC. 39

8.1.Обзор метода eEPC. 39

^ II.Часть. Особенности построения ЗАС. 40

9.Постановка проблемы комплексного обеспечения информационной безопасности АС. 40

10.Особенности проектирования на современном уровне и синтез КСИБ. 47

10.1.Особенности проектирования СЗИ. 47

10.2.Синтез КСИ. 49

10.3.Типовая структура комплексной системы защиты информации от несанкционированного доступа. 50

11.Методы и методики проектирования КСИБ от НСД. 51

11.1.Концептуальные основы построения защиты информации от несанкционированного доступа в вычислительной системе. 51

11.2.Основы проектирования КСИБ от несанкционированного доступа. 54

12.Методы и методики оценки качества КСИБ. 56

12.1.Метод оценки уязвимости информации Хоффмана. 56

12.2.Метод экспертных оценок. 59

13.Аттестация АС по требованиям безопасности. 59

13.1.Положение по аттестации объектов информатизации по требованиям безопасности информации. 59

Порядок проведения аттестации и контроля 62

13.2.Классификация автоматизированных систем и требования по защите информации. 65

14.Особенности эксплуатации КСИБ на объекте защиты. 66

14.1.Основные меры защиты информации. 66

14.2.Основные требования и рекомендации по защите служебной тайны и персональных данных. 68

14.3.Основные рекомендации по защите информации, составляющей коммерческую тайну. 69

14.4.Порядок обеспечения защиты конфиденциальной информации при эксплуатации АС. 70

15.Модели защиты информации. 71

15.1.Основные модели защиты информации. 71

15.2.Реализация ядра безопасности. 72

16.Реализация системы управления доступом. 75

16.1.Особенности выбора СКУД для конкретных объектов. 75

16.2.Основные компоненты СКУД. 76

16.3.Типовые варианты СКУД. 80

Литература. 85



  1. ^

    Часть. Общий подход к построению АС.

  1. Введение.

    1. Принципы системного подхода при создании сложных систем.


Система – совокупность взаимодействующих компонентов и связей между ними.

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

ИС – совокупность:

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

- средств и методов сбора хранения анализа обработки и передачи информации зависящих от специфики области применения;

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

ИС как АС – это совокупность следующих составных частей:

- система БД;

- прикладное ПО;

- персонал;

- организационно методическое (нормативное) обеспечение;

- технические средства.

Проект – временное предприятие, осуществляемое с целью создания уникального продукта или услуги.

Цель проектирования – создание системы, которая:

- удовлетворяет заданным (возможно неформальным) функциональным спецификациям;

- согласовано с ограничением, накладываемым оборудованием;

- удовлетворяет явным и неявным требованиям по эксплуатационным качествам и потреблению ресурсов;

- удовлетворяет явным и неявным критериям дизайна продукта;

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

К заинтересованным лицам относятся:

- заказчики, которые финансируют проект или приобретают продукт для решения каких то бизнес-задач;

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

- аналитики требований, которые пишут требования и отдают их разработчикам;

- разработчики, которые создают, разворачивают и поддерживают продукт;

- тестеры, которые определяют соответствие поведения АС желаемым;

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

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

- сотрудники правового отдела;

- сотрудники отдела продаж и маркейтинга.

    1. ^

      Основные проблемы современных проектов.


В конце 60-х годов прошлого века в США было отмечено явление под названием «software crisis» (кризис ПО). Это выра­жалось в том, что большие проекты стали выполняться с отста­ванием от графика или с превышением сметы расходов, разра­ботанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потре­бителей.

Аналитические исследования и обзоры, выполняемые в пос­ледние годы ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Например, результаты исследований, выполненных в 1995 г. компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разра­боткой ПО, выглядели следующим образом:

  • только 16,2% завершились в срок, не превысили запланиро­ванный бюджет и реализовали все требуемые функции и возможности;

  • 52,7% проектов завершились с опозданием, расходы превы­сили запланированный бюджет, требуемые функции не бы­ли реализованы в полном объеме;

  • ^ 31,1% проектов были аннулированы до завершения;

Для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

В 2007 г. процентное соотношение трех перечисленных кате­горий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).

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

  • нечеткая и неполная формулировка требований к АС;

  • недостаточное вовлечение пользователей в работу над про­ектом;

  • отсутствие необходимых ресурсов;

  • неудовлетворительное планирование и отсутствие грамот­ного управления проектом;

  • частое изменение требований и спецификаций;

  • новизна и несовершенство используемой технологии;

  • недостаточная поддержка со стороны высшего руководства;

  • недостаточно высокая квалификация разработчиков, отсут­ствие необходимого опыта.

В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что множество про­ектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Иордона, одного из ведущих мировых специалистов в данной области, утвердилось название «death march», буквально — «смертельный марш». Под ним пони­мается такой проект, параметры которого отклоняются от нор­мальных значений, по крайней мере, на 50%. По отношению к проектам создания АС это означает наличие одного или более из следующих ограничений:

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

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

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

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

Однако основная причина всех проблем заключается в ответе на вопрос: является ли проектирование АС ремеслом, инженер­ной дисциплиной или чем-то средним?

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

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

Почему же идеология проб и ошибок так глубоко проникла в разработку ПО? Для ответа на этот вопрос необходимо понять, что разработка ПО изначально является проектированием и не имеет признаков строительства или производства. Это утверж­дение трудно принять, но оно может быть легко обосновано. Все хорошо понимают, что такое проектирование, где оно заканчива­ется и где начинается строительство или производство. Рассмот­рим два следующих аргумента:

1. Граница между проектированием и строительством всегда четко обозначена чертежом. Проектирование включает в себя все операции, необходимые для создания чертежа, а строительство охватывает все операции, необходимые для создания продуктов по этому чертежу. В идеальном случае чертеж должен определять создаваемый продукт во всех подробностях, что, конечно же, бы­вает очень редко. Тем не менее, целью чертежа является настоль­ко подробное описание конструируемого продукта, насколько это возможно. Описывает ли проект архитектуры программной системы создаваемый продукт «во всех подробностях»? - Нет. Проект архитектуры предназначен для описания существенных, но, безусловно, не всех подробностей программной системы. По­этому очевидно, что проект архитектуры не является чертежом. Все подробности программной системы описываются только кодом на языке высокого уровня, который, таким образом, являет­ся чертежом программы. А поскольку все операции, ведущие к созданию чертежа, являются проектированием, то и вся разра­ботка ПО должна считаться проектированием.

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






Утверждается

Согласуется

Принимается к действию

Функциональные качества

+







Ресурсы




+




Время







+



^ Под сопровождением в общем случае понимается внесение из­менений в эксплуатируемую АС в целях исп­равления обнаруженных ошибок (корректирующее сопровожде­ние), повышения производительности и улучшения эксплуатаци­онных характеристик системы (совершенствующее сопровожде­ние), а такжеадаптации к изменившейся или изменяющейся сре­де (адаптирующее сопровождение).
При этом более 50% общего объема работ по сопровождению приходится на совершенствую­щее сопровождение. В общих затратах различных организаций и предприятий на ПО доля затрат на сопровождение составляет от 60% до 80% (эта доля является максимальной для крупных госу­дарственных учреждений и частных компаний), и величина этих затрат продолжает расти. Негативными последствиями такого роста являются: 1) неудовлетворенность пользователей из-за большого времени, затрачиваемого на внесение изменений в ПО; 2) снижение качества ПО и 3) сокращение объема новых разрабо­ток в будущем, поскольку все большее количество разработчиков вынуждено переключаться на сопровождение. Так, по оценкам компании Hewlett-Packard, в 1994 г. от 60% до 80% ее разработчи­ков были заняты сопровождением ПО, а в отчетах федеральных служб США ранее отмечалось, что на сопровождение уходит от 50% до 80% рабочего времени программистов. Перечисленные тенденции отражены на рис. В.1.

Первоначально, в 1960 - 1970 гг., в понятие сопровождения ПО входило только исправление ошибок и устранение мелких замечаний пользователей.




1955 1970 1970 2000



Аппаратура Разработка Сопровождение

Рис. В.1. Тенденции изменения соотношения стоимости аппаратуры и ПО

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

По мере развития новых технологий стало ясно, что суммар­ные затраты на сопровождение и создание новых версий могут значительно превосходить затраты на разработку первой версии ПО. Действительно, если разработка первой версии сложного ПО продолжается 3 года, а последующая его эксплуатация и соз­дание версий происходит в течение 10 лет, то можно ожидать, что суммарные затраты на этих интервалах времени соизмери­мы. Даже при предположении, что сопровождением и разработ­кой новых версий будет занята половина специалистов, осуще­ствивших создание первых версий, суммарные затраты на эти работы превысят первичные. Опыт последних лет показво многих случаях для развития версий необходимо практически такое же число специалистов, которое разработало первую вер­сию ПО.
    1. ^

      Современные тенденции в программной инженерии.


В начале 2001 г. ряд ведущих специалистов в области програм­мной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайс-мит, Кент Бек и др.) сформировали группу под назва­нием Agile Alliance. Слово agile (быстрый, ловкий, стремитель­ный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сфор­мулированных ими в документе «Манифест быстрой разра­ботки ПО» (Agile Alliance's Manifesto) и заключающихся в следу­ющем:

  • индивидуумы и взаимодействия между ними ценятся выше процессов и инструментов;

  • работающее ПО ценится выше всеобъемлющей документа­ции;

  • сотрудничество с заказчиками ценится выше формальных договоров;

  • реагирование на изменения ценится выше строгого следо­вания плану.

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

Для характе­ристики таких проектов Алистер Коберн ввел два параметра - критичность и масштаб.

Критичность определяется последстви­ями, вызываемыми дефектами в АС, и может иметь один из че­тырех уровней:

  • С - дефекты вызывают потерю удобства;

  • D - дефекты вызывают потерю возместимых средств (мате­риальных или финансовых);

  • Е - дефекты вызывают потерю невозместимых средств;

• L - дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участву­
ющих в проекте:

  • от 1 до 6 человек - малый масштаб;

  • от 6 до 20 человек — средний масштаб;

  • свыше 20 человек — большой масштаб.


По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критич­ностью (С или D). Общие принципы оценки технологий в таких проектах заключаются в следующем:

  • интерактивное общение лицом к лицу— это самый дешевый и быстрый способ обмена информацией;

  • избыточная «тяжесть» технологии стоит дорого;

  • более многочисленные команды требуют более «тяжелых» и формальных технологий;

  • большая формальность подходит для проектов с большей критичностью;

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

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

  • потеря эффективности в некритических видах деятельности вполне допустима.
  1.   1   2   3   4   5   6   7   8   9   ...   13



    Скачать файл (5609.5 kb.)

    Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации