Поршкевич_Реализация информ.технологий. Реализация информационных технологий в системах управления
 Скачать 1.2 Mb.
|
|
ГЛАВА 2. ЭТАПЫ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ СИСТЕМ 2.1. Стандарт ISO/IEC 12207 в проектировании информационных систем В 1997 году Международная организация по стандартизации – ИСО (International Organization for Standardization – ISO) и Междуна- родная электротехническая комиссия – МЭК (International Electrotech- nical Commission – IEC) создали совместный технический комитет по информационным технологиям – Joint Technical Committee (JTC1) on Information Technology. Содержание работ JTC1 определено как «стандартизация в области систем и оборудования информационных технологий (включая микропроцессорные системы)». Соответствую- щий стандарт впервые был опубликован 1 августа 1995 года под заго- ловком «Software Life Cycle Processes» – «Процессы жизненного цик- ла программного обеспечения». Национальный стандарт [ГОСТ 12207, 1999] получил название «Процессы жизненного цикла про- граммных средств». Цель разработки данного стандарта была опреде- лена как создание общих положений по организации жизненного цик- ла программного обеспечения (ПО) с целью формирования общего понимания жизненного цикла ПО всеми заинтересованными сторона- ми и участниками процесса разработки, приобретения, поставки, экс- плуатации, поддержки и сопровождения программных систем, а также возможности управления, контроля и совершенствования процессов жизненного цикла. Данный стандарт определяет жизненный цикл как структуру декомпозиции работ. Детализация, техники и метрики про- ведения работ – вопрос программной инженерии. Организация после- довательности работ – модель жизненного цикла. Совокупность моде- лей, процессов, техник и организации проектной группы задаются ме- тодологией. В частности, выбор и применение метрик оценки качест- ва программной системы и процессов находятся за рамками стандарта [ГОСТ 12207, 1999], а концепция совершенствования процессов рас- сматривается в стандарте ISO/IEC 15504 «Information Technology – Software Process Assessment» («Оценка процессов <в области> про- граммного обеспечения»). В стандарте заложенные ключевые концеп- ции рассмотрения жизненного цикла программных систем. Стандарт определяет область его применения, дает ряд важных определений 90 (заказчик, разработчик, договор, оценка, выпуск – релиз, программ- ный продукт, аттестация и т. п.), процессы жизненного цикла и вклю- чает ряд примечаний по процессу и вопросам адаптации стандарта. Стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям – группам процессов (названия представлены с указанием номеров разделов стандарта, следуя определениям на рус- ском и английском языке, определяемыми [ГОСТ 12207, 1999] и ори- гинальной версией ISO/IEC 12207, соответственно): 5. Основные процессы жизненного цикла. 5.1. Заказ. 5.2. Поставка. 5.3. Разработка. 5.4. Эксплуатация. 5.5. Сопровождение. 6. Вспомогательные процессы жизненного цикла. 6.1. Документирование. 6.2. Управление конфигурацией. 6.3. Обеспечение качества. 6.4. Верификация. 6.5. Аттестация. 6.6. Совместный анализ. 6.7. Аудит. 6.8. Решение проблем. 7. Организационные процессы жизненного цикла. 7.1. Управление. 7.2. Создание инфраструктуры. 7.3. Усовершенствование. 7.4. Обучение. Стандарт определяет высокоуровневую архитектуру жизненно- го цикла. Жизненный цикл начинается с идеи или потребности, кото- рую необходимо удовлетворить с использованием программных средств. Архитектура строится как набор процессов и связей между ними. Для моделирования реальных экономических объектов приме- няются современные программные системы. Существенно улучшают организацию создания программных систем проблемно- ориентированный подход. Он поддерживает описание системы в виде взаимодействия объектов. Проблемно-ориентированное программи- рование позволяет решить проблемы проектирования, ускорения раз- работки за счет многократного использования готовых модулей, обес- печения легкости модификации, а также предполагает единый подход к проектированию, построению и развитию системы. Основопола- 91 гающим документом в проектировании и реализации информацион- ных систем является национальный стандарт [ГОСТ 12207, 1999] «Информационная технология. Процессы жизненного цикла про- граммного обеспечения» или ГОСТ Р ИСО/МЭК 12207, 1999. Принят и введен в действие постановлением Госстандарта России от 23 де- кабря 1999 г. № 675, основан на стандартах: • ГОСТ Р ИСО 9001, 1996 «Системы качества. Модель обеспече- ния качества при проектировании, разработке, производстве, монтаже и обслуживании». • ГОСТ Р ИСО/МЭК 9126, 1993 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению». ГОСТ Р ИСО/МЭК 12207, 1999 предусматривает более конкре- тизированные стадии и этапы создания автоматизированной инфор- мационной системы (АС). Рассмотрим более подробно некоторые этапы разработки и создания информационных систем, согласуя со стандартом ГОСТ Р ИСО/МЭК 12207, 1999 (номера положений взяты из стандарта без изменения и обозначены наклонным шрифтом). 2.1.1. Основные процессы жизненного цикла. Этап заказа и поставки КИС Процесс заказа состоит из работ и задач, выполняемых заказчи- ком. Процесс начинается с определения потребностей заказчика в сис- теме, программном продукте или программной услуге. Далее следуют подготовка и выпуск заявки на подряд, выбор поставщика и управле- ние процессом заказа вплоть до завершения приемки системы, про- граммного продукта или программной услуги. 5.1.1.1. Заказчик начинает процесс заказа, описывая концепцию или потребность в заказе, разработке или модернизации системы, про- граммного продукта или программной услуги. 5.1.1.2. Заказчик должен определить и проанализировать требо- вания к системе. Требования к системе должны охватывать функцио- нальные, коммерческие, организационные и потребительские аспекты системы, а также требования безопасности, защиты и другие критиче- ские требования наряду с требованиями к проектированию, тестиро- ванию и соответствующим стандартам и процедурам. 5.1.1.6. Заказчик должен рассмотреть варианты реализации зака- за, начиная с анализа соответствующих критериев, включая рискован- ность и стоимость проекта и выгоды от каждого варианта. Анализи- руются следующие варианты: 92 a. покупка готового программного продукта, удовлетворяю- щего определенным требованиям; b. разработка программного продукта или обеспечение про- граммной услуги собственными силами; c. разработка программного продукта или получение про- граммной услуги на договорной основе; d. комбинации по перечислениям а), b), с); e. модернизация существующего программного продукта. 5.1.1.8 Заказчик должен подготовить, документально оформить и выполнить план заказа. Разработка КИС начинается с предварительного ознакомления с существующей системой для оценки целесообразности создания КИС и первого технико-экономического обоснования. Анализ предприятия начинается с уточнения целей развития и соответствующего критерия эффективности в виде конкретного показателя. На этом этапе привле- каются высококвалифицированные бизнес-аналитики, которые имеют постоянный доступ к руководству фирмы; этап предполагает тесное взаимодействие с основными пользователями системы и бизнес- экспертами. Основная задача взаимодействия – получить как можно более полную информацию о системе (полное и однозначное понима- ние требований заказчика) и передать данную информацию в форма- лизованном виде системным аналитикам для последующего проведе- ния этапа заказа. Существуют функциональный подход в обследова- нии предприятия и процессный подход. В первом случае рассматрива- ется функциональная структура предприятия и все, что связано с ав- томатизацией этой структуры. Во втором случае рассматриваются бизнес-процессы (от заявки на поставку продукции до реализации этой заявки в виде акта выполненной работы). Информация о системе может быть получена в результате устного и письменного опроса спе- циалистов аппарата управления; письменного анкетирования; наблю- дения, измерения, оценки информационных потоков предприятия; группового обсуждения; анализа задач; анализа производственных, управленческих и информационных процессов; изучения опыта раз- вития родственных предприятий. Таким образом, определяются суть данного бизнеса, перспективы его развития и требования к системе. Этапы предпроектных работ по созданию КИС. • Обследование функциональной структуры (табл. 8). 93 Таблица 8 Характеристика функций управления Наименование функций или задач Основная должностная функция Наименование операций Исполнитель Средство выполнения Трудоем- кость, (мин) Примеча- ние 1 2 3 4 5 • Обследование потоков и состава информации – разработка схе- мы документооборота предприятия, схемы информационных связей. • Обследование материальных потоков. • Анализ методов планирования и учета. • Краткая характеристика предприятия – это производственная программа, состав персонала, состав производственного обору- дования, оснащенность вычислительной техникой, концепция развития предприятия. Основным результатом диагностики яв- ляется разработка рекомендаций по проведению организацион- но-технических мероприятий для совершенствования управле- ния производством или создания ИС (табл.9). В отчете обязательно должны быть описаны: 1) ограничения, риски, критические факторы, влияющие на ус- пешность проекта (время реакции системы на запрос является заданным ограничением, а не желательным фактором); 2) совокупность условий, при которых предполагается эксплуати- ровать будущую систему: архитектура системы, аппаратные и программные ресурсы, внешние условия ее функционирования, состав людей и работ, обеспечивающих бесперебойное функ- ционирование системы; 3) сроки завершения отдельных этапов, форма сдачи работ, ресур- сы, привлекаемые в процессе разработки проекта, меры по за щите информации; Таблица 9 Разработка рекомендаций Повышение рентабельности производства Средства достиже- ния цели За счет со- вершенство- вания произ- водства За счет со- вершенство- вания управ- ления За счет улучшения ин- формационного взаи- модействия с другими организациями Задачи и проблемы для даль- нейших исследова- ний 94 4) описание выполняемых системой функций; 5) будущие требования к системе в случае ее развития; 6) сущности, необходимые для выполнения функций системы; 7) интерфейсы, распределение функций между человеком и систе- мой; 8) требования к программным и информационным компонентам ПО, список рекомендуемых для данного проекта СУБД; 9) что не будет реализовано в рамках проекта. После составления отчета необходимо дать технико- экономическое обоснование внедрения КИС. Обоснование состоит из составляющих. 1. Выбор вариантов автоматизации, оценок конкретных технико- экономических показателей повышения эффективности произ- водства и системы управления производства. 2. Обоснование комплекса объектов автоматизации. 3. Обоснование комплекса организационно-технических меро- приятий по созданию КИС. 4. Выводы и предложения по общей оценке экономической эффек- тивности и целесообразности внедрения КИС. Этап разработки. Технический проект. Программирование и тестирование. На этом этапесоставляется технический проект и осу- ществляется этап программирования. В техническом проекте опреде- ляются входные и выходные документы, разрабатываются укрупнен- ные и детализированные алгоритмы работы всей системы и каждой из подсистем, определяется состав комплекса технических средств и т. д. В технический проект по стандарту ГОСТ Р ИСО/МЭК 12207, 1999 входят положения: 5.3.6.1. Разработчик должен разработать технический проект для каждого компонента программного объекта. Компоненты программ- ного объекта должны быть уточнены на уровне программных моду- лей, которые можно программировать (кодировать), компилировать и тестировать независимо. Должно быть обеспечено распределение тех- нических требований к компонентам программного объекта между программными модулями. Технический проект должен быть докумен- тально оформлен. 5.3.6.2. Разработчик должен разработать и документально оформить технический проект внешних интерфейсов программного объекта, интерфейсов между компонентами программного объекта и между программными модулями. 5.3.6.3. Разработчик должен разработать и документально оформить технический проект базы данных. 95 5.3.6.4. Разработчик должен, при необходимости, уточнить до- кументацию пользователя. 5.3.6.5. Разработчик должен определить и документально офор- мить требования к испытаниям и программе испытаний программных модулей. 5.3.6.7. Разработчик должен оценить технический проект и тре- бования к тестированию по следующим критериям (при этом резуль- таты оценок должны быть документально оформлены): a) учет требований к программному объекту; b) внешнее соответствие спроектированной архитектуре; c) внутренняя согласованность между компонентами программно- го объекта и программными модулями; d) соответствие методов проектирования и используемых стандар- тов; e) возможность тестирования; f) возможность эксплуатации и сопровождения. 5.3.6.8. Разработчик должен провести совместный анализ с за- казчиком. Разработка технического проекта является завершающей стади- ей проектирования КИС. Работу следующего этапа выполняют спе- циалисты по техническим средствам и программисты. 5.3.7. Программирование и тестирование программных средств 5.3.7.1. Разработчик должен разработать и документально оформить следующие продукты: a) каждый программный модуль и базу данных; b) процедуры испытаний (тестирования) и данные для тестиро- вания каждого программного модуля и базы данных. 5.3.7.2. Разработчик должен протестировать каждый программ- ный модуль и базу данных, гарантируя, что они удовлетворяют уста- новленным требованиям. Результаты тестирования должны быть до- кументально оформлены. 5.3.7.3. Разработчик при необходимости должен уточнить доку- ментацию пользователя. 5.3.7.4. Разработчик должен уточнить общие требования к тес- тированию и программу сборки программных средств. 5.3.7.5. Разработчик должен оценить запрограммированные эле- менты программного объекта и результаты их тестирования по сле- дующим критериям (при этом результаты оценок должны быть доку- ментально оформлены): a) учет требований к программному объекту и проекту объекта в целом; 96 b) внешнее соответствие требованиям и проекту программного объекта; c) внутреннее соответствие между требованиями к программным модулям; d) тестовое покрытие всех модулей; e) соответствие методов программирования и используемых для них стандартов; f) возможность сборки и тестирования; g) возможность эксплуатации и сопровождения. В отчет проекта входят: • программная документация – руководство программисту, текст эксплуатационных программ, описание контрольного примера; • технологические инструкции по обработке данных; • должностные инструкции, устанавливающие права и обязанно- сти персонала в условиях функционирования КИС; • ведомость документов (перечень документов). Внедрение. Анализ функционирования КИС. Ввод КИС в экс- плуатацию представляет процесс постепенного перехода от сущест- вующих методов управления к методам автоматизированного управ- ления (или модернизация существующих автоматизированных мето- дов). Разработчиком должны быть проведены квалификационные ис- пытания программных средств. 5.3.10.1. Объекты программной конфигурации должны быть со- браны в единую систему вместе с объектами технической конфигура- ции, ручными операциями и при необходимости с другими система- ми. Собранная система должна быть испытана на соответствие уста- новленным требованиям. Результаты сборки и испытаний системы должны быть документально оформлены. 5.3.10.2. Для каждого квалификационного требования к системе должны быть разработаны и документально оформлен состав испыта- ний и контрольных примеров. Разработчик должен обеспечить, чтобы собранная система была готова к квалификационным испытаниям. 5.3.10.3. Собранная система должна быть оценена по следую- щим критериям: a) тестовое покрытие требований к системе; b) соответствие методов тестирования используемым стандартам; c) соответствие ожидаемым результатам; d) выполнимость квалификационных испытаний системы; e) возможность эксплуатации и сопровождения. 5.3.12. ввод в действие программных средств; 5.4. процесс эксплуатации; 97 5.4.2. эксплуатационные испытания; 5.4.3. эксплуатация системы. Приступать к введению КИС в эксплуатацию следует при нали- чии рабочей документации на внедряемые комплексы задач, очереди или КИС в целом; обученного персонала, принятых в эксплуатацию технических средств КИС. Работы по вводу в эксплуатацию комплек- са технических средств выполняются специализированными органи- зациями. Срок опытной эксплуатации устанавливается совместно за- казчиком и разработчиком. 5.5. Сопровождение 5.5.2.1. Персонал сопровождения должен проанализировать со- общение о проблеме или заявку на внесение изменений по их влия- нию на организационные вопросы, существующую систему и интер- фейсные связи с другими системами по следующим аспектам: a. типу (корректировка, модернизация, профилактика, адапта- ция к новым условиям); b. объему (размер изменения, стоимость, время на реализацию изменения); c. критичности (влияние на производительность, безопасность, защита). Разработчики должны привести в соответствие с этими замеча- ниями программное обеспечение. При положительных результатах опытной эксплуатации задач составляется двухсторонний акт о прие- ме КИС в промышленную эксплуатацию. 2.1.2. Вспомогательные процессы жизненного цикла КИС В данном разделе определены следующие вспомогательные процессы жизненного цикла. 6.1. документирование – формирование документов, в кото- рых нуждаются администраторы, инженеры и пользовате- ли системы или программного продукта; 6.2. управления конфигурацией – это процесс применения ад- министративных и технических процедур на всем протя- жении жизненного цикла программных средств; 6.3. обеспечение качества – это процесс обеспечения соответ- ствующих гарантий того, что программные продукты и процессы в жизненном цикле проекта соответствуют ус- тановленным требованиям и утвержденным планам; 6.4. верификация – это процесс определения того, что про- граммные продукты функционируют в полном соответст- вии с требованиями заказчика; 98 6.5. аттестация может проводиться как часть работы по обес- печению приемки программных средств; 6.6. совместный анализ – это процесс оценки состояний, про- водится в течение всего жизненного цикла договора обеи- ми сторонами; 6.7. аудит – это процесс определения соответствия требовани- ям, планам и условиям договора; 6.8. решение проблем – устранение обнаруженных несоответ- ствий. 2.1.3. Организационные процессы жизненного цикла КИС 7. Организационные процессы жизненного цикла 7.1. Администратор отвечает за управление продуктом, проек- том, работами и задачами соответствующих процессов, таких как за- каз, поставка, разработка, эксплуатация, сопровождение или вспомо- гательные процессы. 7.2. Процесс создания инфраструктуры является процессом ус- тановления и обеспечения (сопровождения) инфраструктуры, необхо- димой для любого другого процесса. Инфраструктура может содер- жать технические и программные средства, инструментальные сред- ства, методики, стандарты и условия для разработки, эксплуатации или сопровождения. 7.3. Процесс усовершенствования является процессом установ- ления, оценки, измерения, контроля и улучшения любого процесса жизненного цикла программных средств. 7.4. Процесс обучения является процессом обеспечения перво- начального и продолженного обучения персонала. Заказ, поставка, разработка, эксплуатация и сопровождение программных продуктов в значительной степени зависят от квалификации персонала. 2.2. Информационная безопасность систем управления Концентрация информации в компьютерах заставляет все более усиливать контроль в целях защиты информации на предприятии. Специалист в области безопасности информации отвечает за разра- ботку, реализацию и эксплуатацию системы обеспечения информаци- онной безопасности, направленной на поддержание целостности, при- годности и конфиденциальности накопленной в процессе управления информации. В его функции входит обеспечение физической (техни- ческие средства, линии связи и удаленные компьютеры) и логической (данные, прикладные программы, операционная система) защиты ин- 99 формационных ресурсов. Сложность создания системы защиты ин- формации определяется тем, что данные могут быть похищены из компьютера и одновременно оставаться на месте; ценность некоторых данных заключается в обладании ими, а не в уничтожении или изме- нении их. Проблема защиты компьютерных сетей от несанкциониро- ванного доступа приобрела особую остроту. Развитие коммуникаци- онных технологий позволяет строить сети распределенной архитекту- ры, объединяющие большое количество сегментов, расположенных на значительном удалении друг от друга. Все это вызывает увеличение числа узлов сетей, разбросанных по всему миру, и количества различ- ных линий связи между ними, что, в свою очередь, повышает риск не- санкционированного подключения к сети для доступа к важной ин- формации. Существует множество причин, которые могут серьёзно повлиять на работу локальных и глобальных сетей, привести к потере ценной информации. Среди них можно выделить: • несанкционированный доступ извне, копирование или измене- ние информации, случайные или умышленные действия, приво- дящие к искажению либо уничтожению данных, ознакомлению посторонних лиц с информацией, составляющей ценность; • некорректная работа программного обеспечения, приводящая к потере или порче данных из-за ошибок в ПО; • заражение систем компьютерными вирусами; • технические сбои оборудования, вызванные отключением элек- тропитания, отказом дисковых систем и систем архивации дан- ных, нарушением работы серверов, рабочих станций, сетевых карт, модемов; • ошибки обслуживающего персонала, связанные с безграмотно- стью либо халатностью персонала; • техногенные причины, связанные с результатом жизнедеятель- ности человека: это обрушения, затопления, пожары, взрывы. Универсального решения, исключающего все перечисленные причины, нет, однако во многих организациях разработаны и приме- няются технические и административные меры, позволяющие риск потери данных или несанкционированного доступа к ним свести к минимуму. Существует ряд разработок, позволяющих с высокой сте- пенью надежности идентифицировать пользователя при входе в сис- тему. Среди них, например, есть технологии, идентифицирующие пользователя по сетчатке глаза или отпечаткам пальцев. Кроме того, ряд систем используют технологии, основанные на применении спе- циального идентификационного кода, постоянно передаваемого по се- ти. Так, при использовании устройства SecureID (фирмы Security Di- 100 namics) обеспечивается дополнительная информация о пользователе в виде шестизначного кода. В данном случае работа в сети невозможна без наличия специальной карты SecureID (похожей на кредитную), ко- торая обеспечивает синхронизацию изменяющегося кода пользователя с хранящимися в базе данных. При этом доступ в сеть и работа в ней может осуществляться лишь при знании текущего значения кода, ко- торый отображается на дисплее устройства SecureID. Однако основ- ным недостатком этой и ей подобных систем является необходимость специального оборудования, что вызывает неудобства в работе и до- полнительные затраты. 2.2.1. Шифрование Одним из способов информационной безопасности является шифрование информации. Шифрование данных может осуществлять- ся в режимах On-Line и Off-Line. Остановимся подробнее на первом типе, представляющем больший интерес, здесь наиболее распростра- нены два алгоритма. Стандарт шифрования данных DES (Data Encryp- tion Standard) IBM в настоящее время является правительственным стандартом для шифрования цифровой информации. Сложный алго- ритм DES использует ключ длиной от 56 бит и более, а также 8 битов проверки на четность и требует от злоумышленника перебора от 72 квадриллионов возможных ключевых комбинаций и более, обеспе- чивая высокую степень защиты при небольших расходах. При частой смене ключей алгоритм удовлетворительно решает проблему превра- щения конфиденциальной информации в недоступную. DES техниче- ски является симметричным алгоритмом, а стандарт RSA – асиммет- ричным, то есть он использует разные ключи при шифровании и де- шифровании. Пользователи имеют два ключа и могут широко распро- странять свой открытый ключ. Открытый ключ используется для шифрования сообщения пользователем, но только определенный по- лучатель может дешифровать его своим секретным ключом. Это дела- ет ненужными секретные соглашения о передаче ключей между рес- пондентами. DES определяет длину данных и ключа в битах, а RSA может быть реализован при любой длине ключа. Чем длиннее ключ, тем выше уровень безопасности (но становится длительнее и процесс шифрования и дешифрования). Если ключи DES можно сгенерировать за микросекунды, то примерное время генерации ключа RSA – десят- ки секунд. Поэтому открытые ключи RSA предпочитают разработчики программных средств, а секретные ключи DES – разработчики аппа- ратуры. 101 Система Kerberos (Цербер) обеспечивает защиту сети от не- санкционированного доступа, базируясь на программных решениях, и предполагает многократное шифрование передаваемой по сети управ- ляющей информации. Kerberos обеспечивает идентификацию пользо- вателей сети и серверов, не основываясь на сетевых адресах и особен- ностях операционных систем рабочих станций пользователей, не тре- буя физической защиты информации на всех машинах сети и исходя из предположения, что пакеты в сети могут быть легко прочитаны и при желании изменены. Клиент/ Kerberos/ Cepвep.Kerberos имеет структуру типа кли- ент/сервер и состоит из клиентских частей, установленных на рабочие станции пользователей, серверы и Kerberos-сервера, располагающего- ся на каком-либо (не обязательно выделенном) компьютере. Kerberos- сервер, в свою очередь, делится на две равноправные части. Это сер- вер идентификации (authentication server) и сервер выдачи разрешений (ticket granting server). Следует отметить, что существует третий сер- вер Kerberos, который не участвует в идентификации пользователей, а предназначен для административных целей. Область действия Kerbe- ros распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в базе Kerberos- сервера и где все серверы обладают общим кодовым ключом с иден- тификационной частью Kerberos. Эта область не обязательно должна быть участком локальной сети, поскольку Kerberos не накладывает ог- раничения на тип используемых коммуникаций. Упрощенно модель работы Kerberos можно описать следующим образом. Пользователь (Kerberos-клиент), желая получить доступ к ре- сурсу сети, направляет запрос идентификационному серверу Kerberos. Последний идентифицирует пользователя с помощью его имени и па- роля и выдает разрешение на доступ к серверу выдачи разрешений, который в свою очередь дает «добро» на использование необходимых ресурсов сети. Однако данная модель не отвечает на вопрос о надеж- ности защиты информации, поскольку, с одной стороны, пользователь не может посылать идентификационному серверу свой пароль по сети, а с другой – разрешение на доступ к обслуживанию в сети не может быть послано пользователю в виде обычного сообщения. В обоих слу- чаях информация может быть перехвачена и использована для несанк- ционированного доступа в сеть. Для того чтобы избежать подобных неприятностей, Kerberos применяет сложную систему многократного шифрования при передаче любой управляющей информации в сети. Доступ пользователей к сетевым серверам, файлам, приложени- ям, принтерам и т. д. осуществляется по нижеописанной схеме. 102 Клиент направляет запрос идентификационному серверу на вы- дачу «разрешения на получение разрешения» (ticket-granting ticket), которое даст возможность обратиться к серверу выдачи разрешений. Идентификационный сервер адресуется к базе данных, хранящей ин- формацию обо всех пользователях, и на основании содержащегося в запросе имени пользователя определяет его пароль. Затем клиенту от- сылается «разрешение на получение разрешения» и специальный код сеанса (session key), которые шифруются с помощью пароля пользова- теля как ключа. При получении этой информации пользователь на его рабочей станции должен ввести свой пароль, и если он совпадает с хранящимися в базе Kerberos-сервера, «разрешение на получение раз- решения», то пользователь будет зарегистрирован на сервере Kerberos. Так решается проблема с защитой пароля. После того как клиент зарегистрировался с помощью идентифи- кационного сервера Kerberos, он отправляет запрос серверу выдачи разрешений на получение доступа к требуемым ресурсам сети. Этот запрос, или «разрешение на получение разрешения», содержит имя пользователя, его сетевой адрес, отметку времени, срок жизни этого разрешения и код сеанса. «Разрешение на получение разрешения» за- шифровывается два раза – сначала с помощью специального кода, ко- торый известен только идентификационному серверу и серверу выда- чи разрешений, а затем, как уже было сказано, с помощью пароля пользователя. Это не только предотвращает возможность использова- ния этого разрешения при его перехвате, но и делает его недоступным самому пользователю. Для того чтобы сервер выдачи разрешений дал клиенту доступ к требуемым ресурсам, недостаточно только «разре- шения на получение разрешения». Вместе с ним клиент посылает так называемый аутентикатор (authenticator), зашифровываемый с помо- щью кода сеанса и содержащий имя пользователя, его сетевой адрес и еще одну отметку времени. Сервер выдачи разрешений расшифровывает полученное от клиента «разрешение на получение разрешения», проверяет срок его «годности», а затем сравнивает имя пользователя и его сетевой адрес, находящиеся в разрешении, с данными, которые указаны в заголовке пакета пришедшего сообщения. Однако на этом проверки не заканчи- ваются. Сервер выдачи разрешений расшифровывает аутентикатор с помощью кода сеанса и еще раз сравнивает имя пользователя и его се- тевой адрес с предыдущими двумя значениями, и только в случае по- ложительного результата может быть уверен, что клиент именно тот, за кого себя выдает. Поскольку аутентикатор используется для иден- тификации клиента всего один раз и только в течение определенного 103 периода времени, становится практически невозможным одновремен- ный перехват «разрешения на получение разрешения» и аутентикатора для последующих попыток несанкционированного доступа к ресурсам сети. Каждый раз при необходимости доступа к серверу сети клиент посылает «разрешение на получение разрешения» многоразового ис- пользования и новый аутентикатор. После успешной идентификации клиента в качестве источника запроса сервер выдачи разрешений от- сылает пользователю разрешение на доступ к ресурсам сети, которое может использоваться многократно в течение некоторого периода вре- мени, и новый код сеанса. Это разрешение зашифровано с помощью кода, известного только серверу выдачи разрешений и серверу, к кото- рому требует доступа клиент, и содержит внутри себя копию нового кода сеанса. Все сообщение (разрешение и новый код сеанса) зашиф- ровано с помощью старого кода сеанса, поэтому расшифровать его может только клиент. После расшифровки клиент посылает целевому серверу, ресурсы которого нужны пользователю, разрешение на дос- туп и аутентикатор, зашифрованные с помощью нового кода сеанса. Для обеспечения еще более высокого уровня защиты клиент, в свою очередь, может потребовать идентификации целевого сервера, чтобы обезопаситься от возможного перехвата информации, дающей право на доступ к ресурсам сети. В этом случае он требует от сервера высылки значения отметки времени, увеличенного на единицу и за- шифрованного с помощью кода сеанса. Сервер извлекает копию кода сеанса, хранящуюся внутри разрешения на доступ к серверу, исполь- зует его для расшифровки аутентикатора, прибавляет к отметке време- ни единицу, зашифровывает полученную информацию с помощью ко- да сеанса и отсылает ее клиенту. Расшифровка этого сообщения по- зволяет клиенту идентифицировать сервер. Использование в качестве кода отметки времени обеспечивает уверенность в том, что пришед- ший клиенту ответ от сервера не является повтором ответа на какой- либо предыдущий запрос. Теперь клиент и сервер готовы к передаче необходимой информации с должной степенью защиты. Клиент обра- щается с запросами к целевому серверу, используя полученное разре- шение. Последующие сообщения зашифровываются с помощью кода сеанса. Более сложной является ситуация, когда клиенту необходимо дать серверу право пользоваться какими-либо ресурсами от его имени. В качестве примера можно привести ситуацию, когда клиент посылает запрос серверу печати, которому затем необходимо получить доступ к файлам пользователя, расположенным на файл-сервере. Кроме того, при входе в удаленную систему пользователю необходимо, чтобы все идентификационные процедуры выполнялись так же, как и с локаль- 104 ной машины. Эта проблема решается установкой специальных флагов в «разрешении на получение разрешения», дающих одноразовое раз- решение на доступ к серверу от имени клиента для первого примера и обеспечивающих постоянную работу в этом режиме для второго. По- скольку, как было сказано выше, разрешения строго привязаны к сете- вому адресу обладающей ими станции, то при наличии подобных фла- гов сервер выдачи разрешений должен указать в разрешении сетевой адрес того сервера, которому передаются полномочия на действия от имени клиента. Следует отметить также, что для всех описанных вы- ше процедур идентификации необходимо обеспечить доступ к базе данных Kerberos только для чтения. Но иногда требуется изменять ба- зу, например, в случае изменения ключей или добавления новых поль- зователей. Тогда используется третий сервер Kerberos – администра- тивный (Kerberos Administration Server). He вдаваясь в подробности его работы, следует отметить, что его реализации могут сильно отли- чаться (возможно ведение нескольких копий базы одновременно). Безопасность беспроводной сети. Стандарт IEEE 802.11 обес- печивает необходимые условия безопасности на уровне канала: • контроль над доступом к беспроводной сети; • механизм шифрования данных WEP (Wireless Equivalent Pri- vacy). WEP обеспечивает защиту пакетов данных, но не их заго- ловков (длина ключа 64 или 128 бит); • кроме того, точке доступа присваивается уникальный иденти- фикатор ESSID; • также точка доступа может хранить список доступа клиентов, которым можно подключиться к данной точке. Однако эти методы не являются серьезной защитой от профес- сионала; но большинство успешных попыток взлома сетей Wi-Fi обу- словлены халатностью обслуживающего персонала. 2.2.2. Классификация компьютерных вирусов Компьютерный вирус – это специально написанная, как прави- ло, небольшая по размерам программа, которая может внедрять свои копии в компьютерные программы, расположенные в исполнимых файлах, системных областях дисков, драйверах, документах и т. д., причём эти копии имеют способность к «размножению». Процесс внедрения вирусом своей копии в другую программу (системную об- ласть диска и т. д.) называется заражением, а программа или иной объект, содержащий вирус, – зараженным. Вирусы классифицируются по среде обитания: 105 • файловые; • загрузочные; • файлово-загрузочные; • макровирусы; • сетевые вирусы. Файловые вирусы. Большинство вирусов распространяется, заражая исполняемые файлы, т. е. файлы с расширением имени .COM и .EXE, а также оверлейные файлы (то есть вспомогательные про- граммные файлы, загружаемые при выполнении других программ). Такие вирусы называются файловыми. Вирус в заражённых испол- няемых файлах начинает свою работу при запуске той программы, в которой он находится. Загрузочные вирусы. Ещё один широко распространённый вид вирусов внедряется в начальный сектор дискет или логических дис- ков, где находится загрузчик оперативной системы, или в начальный сектор жёстких дисков, где находится таблица разбиения жёсткого диска и небольшая программа, осуществляющая загрузку с одного из разделов, указанных в этой таблице. Такие вирусы называются загру- зочными, или бутовыми (от слова boot – загрузчик). Эти вирусы начи- нают свою работу при загрузке компьютера с заражённого диска. За- грузочные вирусы всегда являются резидентными и заражают встав- ляемые в компьютер дискеты. Встречаются также файлово- загрузочные вирусы, заражающие и файлы. Некоторые вирусы умеют заражать драйверы. Вирус, находящийся в драйвере, начинает свою работу при загрузке данного драйвера из файла CONFIG.SYS при на- чальной загрузке компьютера. Редкой разновидностью вирусов явля- ются вирусы, заражающие командные файлы. Вирус в заражённых командных файлах начинает свою работу при выполнении командно- го файла, в котором он находится. Иногда вызов заражённого команд- ного файла вставляется в файл AUTOEXEC.BAT. Макровирусы написаны при помощи макрокоманд и внедря- ются в прикладные программы. Электронные таблицы содержат мак- рокоманды, в том числе и макрокоманды, автоматически выполняю- щиеся при открытии таблицы. Поэтому для них могут быть созданы вирусы, аналогичные вирусам для документов Word и Excel.Сетевые вирусы запускаются в компьютерную сеть и скачиваются оттуда вме- сте с файлом или приходят с электронной почтой. Вирусы-черви рас- пространяются по сети и саморазмножаются на жестком диске. Из се- тевых вирусов особенно известны вирусы под названием «Троянский конь», модули этих вирусов подсоединяются к нормальной програм- ме, распространяемой по сети, и забрасываются в компьютер пользо- 106 вателя. Цель вируса «Троянский конь» – воровать ценную информа- цию (пароли доступа, номера кредитных карточек и т. д.) и передавать ее тому, кто запустил этот вирус. Вирусы классифицируются по спо- собу заражения: • резидентные – оставляют свою резидентную часть, которая по- том внедряется в объекты; • нерезидентные – не заражают память компьютера. По масштабу воздействия: • неопасные; • опасные; • очень опасные. Неопасные вирусы не выполняют каких-либо действий, кроме своего распространения (заражение других программ, дисков и т. д.) и выдачи каких-либо сообщений или иных эффектов, придуманных ав- тором вируса: музыки, перезагрузки компьютера, выдачи на экран разных рисунков, блокировки или изменения функций клавиш кла- виатуры, замедления работы компьютера, создания видеоэффектов и т. д. Однако сознательной порчи информации эти вирусы не осущест- вляют. Опасные и очень опасные вирусы портят данные на дисках – или сознательно, или из-за содержащихся в вирусах ошибок, скажем из-за не вполне корректного выполнения некоторых действий. Если порча данных происходит лишь эпизодически и не приводит к тяжё- лым последствиям (например, портятся лишь COM-файлы при зара- жении, и длина этих файлов более 64000 байт), то вирусы называются опасными. Если же порча данных происходит часто или вирусы при- чиняют значительные разрушения (форматирование жёсткого диска, систематическое изменение данных на диске и т. д.), то вирусы назы- ваются очень опасными. 2.2.3. Антивирусные программы Для защиты от вирусов созданы специальные антивирусные программы, позволяющие выявлять вирусы, лечить заражённые фай- лы и диски, обнаруживать и предотвращать подозрительные (харак- терные для вирусов) действия. Разумеется, антивирусные программы надо применять наряду с регулярным резервированием данных и ис- пользованием профилактических мер, позволяющих уменьшить веро- ятность заражения вирусом. Антивирусные программы можно клас- сифицировать в соответствии с выполняемыми функциями. 107 Детекторы. Программы-детекторы позволяют обнаруживать файлы, заражённые одним из нескольких известных вирусов. Некото- рые программы-детекторы также выполняют эвристический анализ файлов и системных областей дисков, что позволяет обнаруживать новые, неизвестные программе-детектору вирусы. Многие программ мы-детекторы позволяют также «лечить» заражённые файлы или дис- ки, удаляя из них вирусы (лечение поддерживается только для виру- сов, известных программе-детектору). Ревизоры. Программы-ревизоры запоминают сведения о со- стоянии файлов и системных областей дисков, а при последующих за- пусках сравнивают их состояние с исходным. Пользователю сообща- ется при выявлении несоответствий состояний. Ревизоры можно на- строить так, чтобы они выдавали сообщения только о подозрительных изменениях. Часто программы-ревизоры позволяют также «лечить» заражённые файлы или диски, удаляя из них вирусы. Сторожа. Программы-сторожа, или фильтры, располагаются ре- зидентно в оперативной памяти компьютера, и проверяют запускае- мые файлы и вставляемые в порт компьютера носители информации, а также файлы, получаемые из компьютерной сети, на наличие виру- сов. При наличии вируса об этом сообщается пользователю. Кроме того, многие программы-сторожа перехватывают те действия, кото- рые используются вирусами для размножения и нанесения вреда, и сообщают о них пользователю. Пользователь может разрешить или запретить выполнение соответствующей операции. Программы- сторожа позволяют обнаружить многие вирусы на самой ранней ста- дии, когда вирус ещё не успел размножиться и что-либо испортить. Фаги. Для каждого вируса путем анализа его кода, способов за- ражения файлов выделяется характерная для этого вируса последова- тельность байтов. Эта последовательность называется сигнатурой данного вируса. Фаги обнаруживают сигнатуру и удаляют вирус. Всеми вышеперечисленными функциями обладает антивирусная про- грамма лаборатории Касперского. Существуют также программно- аппаратный комплекс Sherif – это одна плата и несколько программ. Российское законодательство также направлено на защиту информа- ции от злоумышленников, нарушающих закон в сфере информацион- ных технологий, – это законы № 149-ФЗ, Указ президента РФ от 28.06.1993 № 966, № 152-ФЗ, № 63-ФЗ УК РФ (см. п. 1.3.). 108 Контрольные вопросы ко второй главе 1. Что такое Стандарт ISO/IEC 12207. 1999 «Процессы жизненного цикла программного продукта (КИС)»? 2. Каковы основные процессы жизненного цикла КИС? Что представ- ляют из себя: • этап заказа и поставки; • этап разработки; • технический проект; • программирование и тестирование; • ввод в эксплуатацию; • сопровождение. 3. Вспомогательные процессы жизненного цикла КИС. • Документирование. • Управление конфигурацией. • Обеспечение качества. • Верификация. • Аудит. • Совместный анализ. • Аттестация. • Решение проблем. 4. Организационные процессы жизненного цикла КИС. • Управление. • Создание инфраструктуры. • Совершенствование. • Обучение. 17. Что такое информационная безопасность систем управления? 18. Какие виды шифрования вы знаете? 19. Дать классификацию компьютерных вирусов. 20. Какие вы знаете антивирусные программы? |