ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

? Поэтапное восстановление ("холодный" резервный центр[218]) – этот способ можно использо­вать в тех сферах бизнеса, где можно обойтись без ИТ-услуг в течение определенного периода времени, например, 72-х часов. При использовании данного способа заказчику предоставляется свободный компьютерный зал на заранее оговоренной территории, стационарный центр[219] или мобильная компьютерная комната, доставляемая на место расположения компании, - мобиль­ный центр[220]. Такой компьютерный центр должен быть снабжен электропитанием, кондиционером, сетевыми коммуникациями и телефонной связью. Данный способ может быть предостав­лен по договору с внешним поставщиком. Кроме того, необходимо отдельное соглашение с по­ставщиком, гарантирующее быструю доставку ИТ-компонент. Общее преимущество такого под­хода состоит в том, что эти средства восстановления доступны всегда. Кроме того, для стацио­нарного и мобильного компьютерного центра преимущества и недостатки различаются и зави­сят от таких аспектов, как:

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

? Время – стационарные залы доступны лишь на определенное время.

? Задержка – в любом случае доставка необходимого компьютерного оборудования занимает оп­ределенное время.

? Сеть – часто возникают трудности с предоставлением нужных телекоммуникационных средств. Оборудование передвижной станции можно подсоединить к сети в основном использу­емом здании.

? Промежуточное восстановление ("теплый" резерв[221]) – данный способ обеспечивает доступ к ана­логичной операционной среде, в которой можно восстановить обычное предоставление услуг в те­чение короткого промежутка времени (от 24 до 72 часов). Существует три варианта этого способа:

? Внутренний (совместное устранение неисправности): применим в тех случаях, когда бизнес рас­полагается на нескольких площадках или имеет выделенную среду тестирования, которую мож­но использовать в качестве рабочей среды. Данный способ обеспечивает полное восстановление при минимальных затратах времени на переключение. В организациях с несколькими распреде­ленными системами часто используется один из вариантов этого подхода, когда на каждой сис­теме резервируется часть требуемых мощностей. Мониторинг таких свободных мощностей осу­ществляется Процессом Управления Мощностями (аналогично варианту использования взаим­ных соглашений – см. выше).

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

? Мобильный: в данном варианте готовая к работе инфраструктура размешается в трейлере, кото­рый используется как компьютерный зал и оборудован устройствами контроля за окружающей средой, такими как кондиционеры. У ИТ-организации должно быть место для парковки такого трейлера. В специально выделенных пунктах на некотором расстоянии от основного здания должны быть предусмотрены источники электропитания, телекоммуникационные каналы и хранилище данных. Преимуществами такой версии являются быстрое время реагирования и близость к месту расположения компании. Данный способ доступен только для ограниченного числа технических платформ. Некоторые крупные поставщики оборудования предлагают не­сколько трейлеров со стандартными конфигурациями аппаратного обеспечения. В согласован­ный момент времени, например, раз в год, такой трейлер направляется к месту расположения бизнеса для проверки Плана восстановления. Кроме того, такая процедура позволяет произве­сти тестирование перехода[222] на новую версию операционной системы.

? Немедленное восстановление ("горячий" старт, "горячее" восстановление[223]) – данный способ обеспечивает немедленное или очень быстрое восстановление работы менее чем за 24 часа путем предоставления идентичной рабочей среды и зеркального отображения данных, а возможно, и ра­бочих процессов. Последний вариант обычно разрабатывается при тесном взаимодействии с Про­цессом Управления Доступностью.

? Комбинации способов – часто План на случай чрезвычайных обстоятельств[224] включает в себя бо­лее дорогой способ восстановления, который используется до активизации более дешевого вари­анта. Например, трейлер, оборудованный как передвижной вычислительный центр (мобильный "горячий" старт), может служить временным решением до тех пор, пока не приедет мобильный центр и не будут доставлены новые главные сервера[225] (передвижной «холодный" старт). Нормаль­ная работа будет возобновлена после восстановления здания и установки в нем новых главных компьютеров.

13.4.5. Организация процесса и планирование внедрения

После того, как определена стратегия бизнеса и сделан выбор одного из перечисленных способов восстановления, необходимо переходить к реализации Процесса Управления Непрерывностью ИТ-сервисов и разработки детальных планов для использования выбранных средств восстановления. Реализацией процесса ITSCM должна заниматься специальная группа. Ее организация может вклю­чать в себя назначение руководителя (Руководитель на случай кризисной ситуации[226]), координацию работ и формирование восстановительных команд каждого сервиса.

На самом высоком уровне должен быть разработан общий план, охватывающий следующие вопросы:

? План экстренного реагирования;

? План оценки повреждений;

? План восстановления работы;

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

? План руководства на случай кризисной ситуации и связь с общественностью (PR).

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

? План размещения и оказания услуг;

? План по вычислительным системам и локальным сетям;

? План по телекоммуникациям (доступ и каналы связи);

? План обеспечения безопасности (целостность данных и сетей);

? План по персоналу;

? Финансовые и административные планы.

13.4.6. Применение превентивных мер и способов восстановления

Этот этап заключается в практическом воплощении определенных ранее превентивных мер и спосо­бов восстановления. Превентивные меры по уменьшению степени воздействия предпринимаются совместно с деятельностью в рамках Процесса Управления Доступностью и могут включать:

? Использование бесперебойных источников питания и резервных источников электропитания;

? Использование отказоустойчивых систем[227];

Использование удаленных систем хранения данных и RAID-массивов и т. д.

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

? ведение переговоров со сторонними организациями по вопросам удаленных средств восстановле­ния;

? поддержка и оснащение средств восстановления;

? закупка и установка резервного аппаратного обеспечения (неактивированные договоры);

? управление неактивированными ("дремлющими") договорами.

13.4.7. Разработка планов и процедур восстановления

Планы должны быть разработаны в деталях и стать официальными документами, т. к. Планы восста­новления требуют поддержки, и все изменения в них должны согласовываться заинтересованными сторонами. Эта информация также должна доводиться до сведения всех участников. Основные проб­лемы связаны с изменениями в инфраструктуре и Изменениями Уровней Сервиса. Например, пере­ход на новую платформу среднего класса[228] может привести к тому, что не будет эквивалентного обору­дования в резервном центре "теплого", внешнего старта. По этой причине Процесс Управления Кон­фигурациями играет важную роль в мониторинге базисных конфигураций с учетом Плана восстанов­ления. В плане также должны быть определены процедуры, необходимые для его выполнения.

План восстановления

План восстановления должен включать все виды деятельности по восстановлению бизнес-активно­сти и ИТ-услуг:

? Введение – описание структуры плана и предполагаемых средств восстановления.

? Обновление – описание процедур и соглашений по поддержке актуальности плана и отслежива­нию изменений в инфраструктуре.

? Маршрутный лист – план делится на разделы, каждый из которых определяет действия, выпол­няемые конкретной группой специалистов. Маршрутный лист показывает, какие разделы плана должны быть направлены в каждую группу.

? Начало восстановления – описание времени и условий начала действия плана.

? Классификация чрезвычайных обстоятельств – если в плане дается описание процедур на слу­чай различных чрезвычайных обстоятельств, то они должны быть описаны с точки зрения их серьезности (незначительные, среднего уровня серьезности, серьезные), длительности (день, неде­ля, месяцы) и уровня повреждений (незначительные, ограниченные, серьезные).

? Разделы для участвующих групп специалистов – план должен быть разделен на шесть разде­лов – по количеству областей действия и закрепленных на за ними групп специалистов:

? Администрация – как и когда вводить план в действие, какие руководители и специалисты уча­ствуют в нем, где находиться центр управления?

? ИТ-инфраструктура – аппаратное и программное обеспечение, телекоммуникационные сред­ства, включенные в систему восстановления и соответствующие процедуры, а также неактивированные ("дремлющие") договоры на закупку новых ИТ-компонентов.

? Персонал – персонал, необходимый для работы в резервном центре, возможно, средства транс­портировки и размещение персонала, если резервный центр расположен удалено от основного месторасположения.

? Безопасность – инструкции по защите от краж, пожаров и взрывов, как в основном здании, так и на удаленной площадке, а также информация о внешних хранилищах, таких как склады и подвалы.

? Площадки восстановления – информация о договорах, персонале с указанием конкретных функ­ций, системе безопасности и транспорте.

? Возврат к нормальным условиям – процедуры восстановления нормальной инфраструктуры (например, здания), условия, при которых начинают действовать эти процедуры и соответству­ющие неактивированные ("дремлющие") контракты.

Процедуры

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

? инсталляцию и тестирование технических средств и сетевых компонентов;

? восстановление приложений, баз данных и других данных.

Эти и другие необходимые процедуры должны прилагаться к Плану восстановления.

13.4.8. Начальное тестирование

Начальное тестирование – критически важный аспект процесса ITSCM. Тесты следует проводить в начале работы, потом после проведения значительных изменений и затем, как минимум, один раз год. ИТ-подразделения отвечают за тестирование эффективности планов и процедур в отношении ИТ-элементов. Тесты могут проводиться с предварительным объявлением или без него.

13.4.9. Обучение и осведомление

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

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

13.4.10. Анализ и аудит

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

13.4.11. Тестирование

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

13.4.12. Управление Изменениями

Процесс Управления Изменениями играет важную роль в поддержании актуальности Планов восста­новления. Необходимо проводить анализ воздействия любого изменения на План восстановления.

13.4.13. Обеспечение гарантий[230]

Обеспечение гарантий работоспособности процесса означает проверку соответствия качества про­цесса (процедур и документации) бизнес-потребностям компании.

13.5. Управление Процессом

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

13.5.1. Отчеты для руководства

В случае возникновения чрезвычайной ситуации предоставляются отчеты о причинах и последстви­ях чрезвычайной ситуации и действиях по ее разрешению. Любое выявленное при этом слабое мес­то будет учтено в Планах по улучшению сервисов.

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

13.5.2. Критические факторы успеха и ключевые показатели качества

Успех Процесса Управления Непрерывностью ИТ-сервисов зависит от следующих факторов:

? наличия эффективного Процесса Управления Конфигурациями;

? поддержки процесса всеми в компании;

? наличия современных эффективных инструментальных средств;

? проведения специального обучения для всех участников данного процесса;

? регулярного тестирования плана восстановления без предварительного уведомления.

Ключевыми показателями качества являются:

? количество выявленных ошибок в планах восстановления;

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

? стоимость процесса.

13.5.3. Функции и роли

Задачи Руководителя Процесса Управления Непрерывностью ИТ-сервисов состоят во внедрении и обеспечении поддержки процесса ITSCM для постоянного выполнения всех требований по Управ­лению Непрерывностью Бизнеса (ВСМ) и представлении функций ИТ-сервисов в рамках процесса ВСМ.

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

Таблица 13.1. Примеры видов ответственности в рамках Процесса Управления Непрерывностью ИТ-сервисов

13.6. Проблемы и затраты

13.6.1. Затраты

Основные затраты, связанные с реализацией Процесса Управления Непрерывностью следующие:

? затраты времени и средств на инициацию, разработку и внедрение процесса ITSCM.

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

? переходящие затраты на поддержку выбранных способов восстановления, такие как плата по Внешним Договорам по "горячему" старту, затраты на организацию тестирования и плата за пери­од поддержания в готовности средств восстановления.

? повторяющиеся операционные расходы на тестирование, аудит и корректировку планов.

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

13.6.2. Проблемы

При внедрении данного процесса могут возникнуть следующие проблемы:

? Ресурсы – организация должна предоставить дополнительные мощности проектной команде для разработки и тестирования плана.

? Серьезность намерений (обязательства) – ежегодные расходы на процесс должны быть включе­ны в бюджеты организации, для чего требуется твердое намерение руководства поддерживать Процесс Управления Непрерывностью ИТ-сервисов.

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

? Оценка потерь – некоторые потери, такие как потеря репутации, нельзя измерить в денежном вы­ражении.

? Составление бюджета – не всегда удается добиться понимания необходимости в дорогих средст­вах восстановления функциональности, иногда происходит сокращение Планов восстановления.

? Отсутствие обязательств со стороны бизнес-руководителя – это ведет к неудаче в разработке процесса ITSCM, хотя заказчик может полагать, что все необходимое сделано.

? Постоянное откладывание – это бывает в тех случаях, когда отсутствует большинство составля­ющих процесса и, как следствие этого, реализация процесса постоянно откладывается. В таких случаях на вопрос о Процессе Управления Непрерывностью ИТ-сервисов даются ответы: "Да. Мы встречается по этому вопросу на следующей неделе", "Мы собирается создать комиссию специ­ально по данному вопросу" и тому подобное.

? Черный ящик – это бывает в тех случаях, когда поставщик ИТ-услуг отказывается от ответствен­ности, а также прекращает управлять готовностью процесса: "Кто-то еще этим занимается". Пос­кольку организация затратила много средств или передала часть своих операций поставщику, ру­ководство надеется, что затраченные деньги обеспечат возможность восстановления или же что у поставщика есть планы, которые помогут восстановить бизнес после чрезвычайной ситуации.

? ИТ-подразделение – в своей работе должно руководствоваться действительными пожеланиями и требованиями бизнеса, а не своими предположениями.

? Знание бизнеса – важно, чтобы бизнес поддерживал разработку процесса ITSCM путем опреде­ления основных направлений работы.

? Отсутствие осведомленности в компании – необходимо, чтобы вся организация знала о значимо­сти процесса ITSCM. Без информирования персонала и его поддержки процесс обречен на неудачу.

Глава 14 Управление Доступностью

14.1. Введение

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

Несколько часов простоя компьютера могут иметь серьезные последствия для бизнеса и репутации компании на рынке, особенно сейчас, когда Интернет превращается в электронный вариант рынка. В этом электронном мире конкурентов друг от друга отделяет простое нажатие на клавишу «мыши». В этой связи особенно важным фактором становится степень удовлетворенности заказчиков. Эта одна из причин, почему в настоящее время вычислительные системы должны быть доступны 24 часа в сутки семь дней в неделю.

14.1.1. Основные понятия

На рис. 14.1 схематично представлены базовые понятия процесса Управления Доступностью.

Рис. 14.1. Концептуальные понятия процесса Управления Доступностью (источник: OGC)

Доступность

Высокий Уровень Доступности означает, что заказчик имеет практически постоянный доступ к ИТ-сервису благодаря сокращению времени простоя и быстрому восстановлению предоставления услуг. Уровень Доступности определяется с помощью метрик. Доступность сервиса зависит от:

? сложности ИТ-инфраструктуры;

? надежности компонентов;

? способности быстро и эффективно реагировать на сбои;

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

? качества и границ компетенции процессов операционного управления.

Надежность[231]

Надежность, в контексте данного процесса, означает доступность сервиса в течение согласованного периода времени без каких-либо сбоев. Эта концепция включает в себя понятие устойчивости[232]. На­дежность сервиса будет возрастать, если предпринимать превентивные меры против возникновения простоев. Надежность сервиса является статистическим показателем и определяется сочетанием следующих факторов:

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

? способность сервиса или его компонентов эффективно функционировать, несмотря на сбой одной или нескольких подсистем (устойчивость);

? профилактическое обслуживание для предотвращения простоев.

Обслуживание[233]

Понятия "обслуживание" и "способность к восстановлению"[234] предполагают выполнение работ по обеспечению функционирования сервиса и его восстановлению после сбоев, а также проведение профилактического обслуживания и регламентных (плановых) проверок, а именно:

? принятие мер по предотвращению сбоев;

? своевременное обнаружение сбоев;

? проведение диагностики, включая автоматическую самодиагностику компонентов;

? ликвидация сбоев;

? восстановление функционирования после сбоя;

? восстановление сервиса.

Предоставление сервиса внешними поставщиками[235]

Данное понятие относится к договорным обязательствам внешних поставщиков сервиса (подрядчи­ки, сторонние организации). Договорами определяется поддержка, которая будет обеспечена серви­сам, поставляемым внешними организациями (аутсорсинг). Поскольку это только часть ИТ-серви­са, данный термин не относится к общей доступности сервиса. Если подрядчик несет ответствен­ность за сервис в целом, как это бывает, например, при заключении договора хозяйственного обеспе­чения, тогда термины "Предоставление сервиса" и "доступность" будут синонимами. Для эффективного Управления Доступностью необходимо знание бизнеса и ИТ-среды. Важно по­нять, что доступность нельзя просто "купить": доступность должна закладываться на самых ранних этапах разработки и внедрения. В конечном счете доступность зависит от сложности инфраструкту­ры, надежности компонентов, профессионализма ИТ-организации и ее подрядчиков и от качества самого процесса.

14.2. Цели процесса

Целью Процесса Управления Доступностью является обеспечение рентабельного и согласованного Уровня Доступности ИТ-сервиса, который поможет бизнесу в достижении поставленных целей. Такое определение цели процесса означает, что потребности заказчика (бизнеса) должны соответст­вовать тому, что могут предложить ИТ-инфраструктура и организация. Если имеется расхождение между спросом и предложением, тогда Процесс Управления Доступностью должен предложить вы­ход из такой ситуации. Более того, данный процесс гарантирует оценку достигнутых Уровней Дос­тупности и их дальнейшее совершенствование в случае необходимости. Это означает, что в рамках процесса выполняются как проактивные, так и реактивные виды деятельности. При разработке про­цесса следует исходить из следующих предпосылок:

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

? Высокая степень доступности не означает отсутствие сбоев. Управление Доступностью в основ­ном отвечает за профессиональное реагирование на такие нежелательные ситуации.

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

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

14.2.1. Преимущества использования процесса

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

? создание единой точки контактов по вопросам доступности продуктов и услуг и наличие одного человека, отвечающего за эти вопросы;

? гарантируется соответствие новых продуктов и услуг предъявляемым к ним требованиям и согла­сованному с заказчиком стандарту доступности;

? Уровень Затрат поддерживается на приемлемом уровне;

? постоянный мониторинг стандартов доступности и их совершенствование по мере необходимости;

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

? уменьшение количества отказов в доступе к системам и сокращение периода недоступности сервиса;

? смещение акцентов с исправления дефектов на улучшение сервиса;

? простота обоснования добавочной стоимости для ИТ-организации.

Процесс Управления Доступностью связан со следующими процессами ITIL.

Управление Уровнем Сервиса

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

Управление Конфигурациями

Процесс Управления Конфигурациями располагает информацией об инфраструктуре и может пре­доставлять ценную информацию Процессу Управления Доступностью.

Управление Мощностями

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

Управление Непрерывностью Сервиса

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

Управление Проблемами

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

Управление Инцидентами

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

Управление Безопасностью

Процесс Управления Доступностью тесно связан с Процессом Управления Безопасностью, в кото­ром основными вопросами являются:

? Конфиденциальность;

? Целостность;

? Доступность.

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

Управление Изменениями

Процесс Управления Доступностью информирует Процесс Управления Изменениями о вопросах обслуживания новых услуг и их элементов и инициирует проведение изменений, обусловленных во­просами доступности. Процесс Управления Изменениями информирует Процесс Управления Дос­тупностью о содержании Перспективного Плана Изменений (FSC).

14.3. Процесс

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

Рис. 14.2. Входы и выходы Процесса Управления Доступностью (источник: OGC)

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

Входами для Процесса Управления Доступностью являются (рис. 14.2):

? требования бизнеса к доступности;

? оценка влияния на все бизнес-процессы, поддерживаемые ИТ;

? требования к доступности, надежности и обслуживанию ИТ-компонентов инфраструктуры;

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

? данные о конфигурациях услуг и их компонентах и данные мониторинга;

? достигнутые Уровни Сервиса в сравнении с согласованными уровнями для всех услуг, оговорен­ных в соглашении о предоставлении сервиса.

Выходы:

? критерии разработки архитектуры для обеспечения доступности и восстановления новых и улуч­шаемых ИТ-услуг;

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

? гарантии доступности, надежности и обслуживания компонентов инфраструктуры, необходимые для предоставления ИТ-сервиса;

? отчеты о достигнутых Уровнях Доступности, надежности и обслуживания;

? требования к мониторингу доступности, надежности и обслуживания;

? план обеспечения доступности[236] для проведения проактивного улучшения ИТ-инфраструктуры.

14.4. Виды деятельности

В рамках Процесса Управления Доступностью выполняется ряд ключевых видов деятельности, свя­занных с планированием и мониторингом, а именно:

? Планирование

? определение требований к доступности сервиса;

? проектирование систем для достижения требуемого Уровня Доступности;

? проектирование систем для достижения требуемой способности восстановления[237];

? вопросы безопасности;

? управление обслуживанием;

? разработка Плана Доступности.

? Мониторинг

? проведение измерений и составление отчетов.

Ниже дается описание основных видов деятельности.

14.4.1. Определение требований к доступности сервиса

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

? ключевые бизнес-функции;

? согласованный период простоя ИТ-сервиса;

? количественная оценка требований к доступности сервиса;

? количественная оценка воздействия незапланированного простоя на бизнес-функции;

? рабочие часы заказчика;

? соглашения об "окнах" для планового обслуживания.

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

14.4.2. Проектирование систем для достижения требуемого Уровня Доступности

Следует как можно раньше выявить различные виды уязвимости, влияющие на доступность. Это позволит избежать неоправданно высокой стоимости разработки, незапланированных расходов на более поздних этапах, наличия Единой точки сбоя[238] (SPOF), дополнительных затрат по счетам поставщиков и задержек с выпуском релизов

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключить с поставщиками эффективные договоры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента[239] (CFIA – см. раздел 14.4.9) для вы­явления отказов, вызванных наличием SPOF, методика CCTA по анализу и Управлению Рисками[240] (CRAMM – см. главу "Управление Непрерывностью ИТ-сервиса") и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучший путь – попытаться внести соответствующие усовершенствования в проект. В обеспечении соответствия стандартам мо­жет помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или изменение процесса проекти­рования.

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

14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания

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

14.4.4. Ключевые вопросы безопасности

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

Среди вопросов могут быть следующие:

? определение лиц, имеющих право доступа в защищенные области;

? определение видов авторизации.

14.4.5. Управление Обслуживанием

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

Обслуживание следует проводить в такие периоды, когда степень его воздействия на предоставле­ние услуг является минимальной. Это значит, что необходимо заранее определить цели обслужива­ния, период его проведения, и какие работы при этом будут выполняться (для этого можно исполь­зовать метод Анализа влияния отказа компонентов – CFIA[241]). Такая информация об обслуживании очень важна для Процесса Управления Изменениями и для других процессов.

14.4.6. Проведение измерений и составление отчетов

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

? Если вы не измеряете, вы не можете управлять.

? Если вы не измеряете, вы не можете улучшать.

? Если вы не измеряете, вам, вероятно, все равно.

? Если вы не можете влиять, то не стоит и измерять.

Цикл жизни инцидента включает в себя следующие этапы:

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

? Обнаружение: поставщик сервиса проинформирован о сбое. Инцидент получает статус "Сообще­но". Затраченное на это время известно как время обнаружения.

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

? Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.

? Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфи­гурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.

На рис. 14.3 показаны периоды времени, которые поддаются измерению.

Рис. 14.3. Измерение доступности (источник: OGC)

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

В Процессе Управления Доступностью, как правило, используются следующие метрики:

? Среднее время ремонта (Mean Time to Repair – MTTR): среднее время между возникновением сбоя и восстановлением сервиса, также известное как "простой". Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сер­виса, как способность восстановления[242] и обслуживаемость[243].

? Среднее время между сбоями (Mean Time Between Failures – MTBF): среднее время между восстановлением после одного сбоя и возникновением другого, также известное как "период рабо­тоспособного состояния" (uptime). Данная метрика относится к надежности сервиса.

? Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI): среднее время между двумя последовательными инцидентами. Данная метрика пред­ставляет собой сумму двух метрик MTTR и MTBF.

Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбо­ев или было несколько серьезных нарушений в работе.

В отчеты о доступности сервиса могут быть включены следующие метрики:

? Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;

? общее время работоспособного состояния и время простоя;

? количество сбоев;

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

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

14.4.7. Разработка Плана Обеспечения Доступности

Одним из основных результатов процесса является План Доступности[244]. Это долгосрочный План Обеспечения Доступности Сервиса на несколько последующих лет, он не является Планом Внедре­ния Процесса Управления Доступностью.

План – это живой документ. В начале он должен дать описание текущей ситуации, а затем в него можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а так­же предложения по вводу новых услуг и их обслуживанию. Для составления полного и точного пла­на необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управле­ние Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Раз­работкой Приложений (напрямую или через Процесс Управления Изменениями).

14.4.8. Инструментальные средства

Для достижения эффективности Процесс Управления Доступностью должен использовать ряд ин­струментальных средств следующего назначения:

? определение времени простоя;

? фиксация исторической информации;

? создание отчетов;

? статистический анализ;

? анализ воздействия.

Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта ин­формация может храниться в специальной Базе Данных Процесса Управления Доступностью.

14.4.9. Методы и методики

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

Анализ влияния отказа компонентов (CFIA)[245]

Данный метод предполагает использование матрицы доступности стратегических компонентов и их ролей в каждой услуге. При разработке такой матрицы очень полезной может оказаться база данных CMDB.

Пример матрицы CFIA на рис. 14.4 показывает, что Конфигурационные Единицы, которые для мно­гих услуг помечены символом "X", являются важными элементами ИТ-инфраструктуры (анализ по горизонтали) и что услуги, часто отмечаемые символом "X", являются комплексными и подверже­ны сбоям (анализ по вертикали). Этот метод также можно применять для изучения степени зависи­мости от сторонних организаций (усовершенствованный метод CFIA).

X – сбой/дефект означает, что услуга недоступна

А – безотказная конфигурация

В – безотказная конфигурация, с переключением

" " – нет воздействия

Рис. 14.4. Матрица CFIA (источник: OGC)

Анализ дерева неисправностей[246] (FTA)

Анализ дерева неисправностей используется для определения цепочки событий, приводящих к сбою ИТ-сервиса. Для каждой услуги изображается отдельное дерево с использованием символов Буля. Дерево анализируется снизу вверх. Метод FTA выделяет следующие события:

? Основные события: входы на схеме (обозначены кружочками), такие как отключение электропи­тания и ошибки операторов. Эти события не исследуются.

? Результирующие события: узловая точка на схеме, появившаяся в результате объединения двух более ранних событий.

? Условные события: события, которые происходят только при определенных условиях, таких как отказ кондиционера.

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

Рис. 14.5. Анализ дерева дефектов/сбоев (источник: OGC)

События можно объединять с логическими операциями, такими как:

? операция AND (И): результирующее событие произойдет, если будут присутствовать все входы одновременно;

? операция OR (ИЛИ): результирующее событие произойдет, если будет иметь место один или не­сколько входов;

? операция XOR (Исключающее ИЛИ): результирующее событие произойдет, если будет иметь место только один вход/причина;

? операция Inhibit (Запрет): результирующее событие произойдет, если не будут выполнены вход­ные условия.

Метод Анализа и Управления Рисками[247] (CRAMM)

Данный метод рассматривался в главе, посвященной Управлению Непрерывностью ИТ-сервиса.

Расчеты доступности сервиса

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

Рис. 14.6. Формула доступности (источник: OGC)

Достигнутое время работоспособности системы равно разнице между согласованным временем ра­ботоспособности и случившемся временем простоя. Например: если была достигнута договорен­ность о 98% доступности сервиса в рабочие дни с 7.00 до 19.00 и в течение это периода был двухчасо­вой отказ сервиса, то достигнутое время работоспособности (процент доступности) будет равен:

(5x12- 2)/(5х 12) х 100%= 96,7%

Анализ простоев системы[248] (SOA)

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

Характеристики метода SOA:

? широкая сфера действия: он не ограничивается инфраструктурой и охватывает также процессы, процедуры и аспекты корпоративной культуры;

? рассмотрение вопросов с точки зрения заказчика;

? совместная реализация метода представителями заказчика и ИТ-организации (команда метода SOA).

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

Пост технического наблюдения[249] (ТОР)

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

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

14.5. Контроль процесса

14.5.1. Составление отчетов

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

? время обнаружения;

? время реагирования;

? время ремонта;

? время восстановления;

? оценка успешности использования соответствующих методов (CFIA, CRAMM, SOA);

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

Некоторые метрики можно задать для каждой услуги, команды или области инфраструктуры (сети, вычислительного центра и рабочей станции).

14.5.2. Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха Процесса Управления Доступностью сервиса являются:

? наличие у бизнеса четко определенных целей и пожеланий в отношении доступности сервиса;

? налаженный Процесс Управления Уровнем Сервиса для обеспечения формализации соглашений;

? одинаковое понимание сторонами понятий доступности и простоя;

? понимание как бизнесом, так и ИТ-организацией преимуществ Управления Доступностью.

Об эффективности и рациональности Процесса Управления Доступностью свидетельствуют такие показатели эффективности, как:

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

? продолжительность простоев;

? частота возникновения простоев.

14.5.3. Функции и роли

В организации может быть назначена роль Руководителя Процесса Управления Доступностью для того, чтобы планировать и поддерживать процесс. Задача Руководителя процесса состоит в следующем:

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

? обеспечение разработки ИТ-сервисов, при которой достигнутые Уровни Сервиса (в Плане Дос­тупности, Надежности, Обслуживания и Способности к Восстановлению) будут соответствовать согласованным уровням;

? составление отчетов;

? оптимизация доступности ИТ-инфраструктуры с целью обеспечения рентабельного улучшения сервиса, предоставляемого бизнесу.

14.6. Проблемы и затраты

14.6.1. Проблемы

Большинство проблем данного процесса связано с организационными вопросами. Среди возможных проблем могут быть следующие:

? руководство распределяет ответственность за доступность сервисов по нескольким направлени­ям – между линейными руководителями, руководителями процессов. Каждый руководитель от­вечает за свое направление, что приводит к отсутствию общей координации;

? ИТ-руководство не понимает той добавочной стоимости, которую дают Процессы Управления Инцидентами, Проблемами и Изменениями;

? существующий Уровень Доступности считается достаточным;

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

? у руководителя процесса нет достаточных полномочий.

Даже если имеется достаточная поддержка со стороны руководства, проблемы все равно могут воз­никать по следующим причинам:

? недооценка необходимых ресурсов;

? недостаток эффективных инструментальных средств измерения и составления отчетов;

? недостаточный Уровень Зрелости других процессов, таких как Управление Уровнем Сервиса, Уп­равление Конфигурациями и Управление Проблемами.

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

При нерациональном использовании Процесса Управления Доступностью могут возникнуть следу­ющие проблемы:

? трудности при определении соответствующих стандартов доступности;

? трудности в руководстве и координации внешних и внутренних поставщиков;

? трудности при определении и сравнении стоимости доступности и недоступности;

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

? несоответствие стандартам доступности может привести к невозможности достижения поставлен­ных бизнес-целей;

? может понизиться Уровень Удовлетворенности Заказчика.

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

14.6.2. Затраты

Затраты на процесс состоят из:

? затрат на внедрение процесса;

? затрат на персонал;

? затрат на устройства;

? затрат на инструментальные средства измерения и составления отчетов.

Для улучшения показателей доступности необходимо уже на ранних этапах определить необхо­димый Уровень Инвестиции в этот процесс. Всегда должен выполняться анализ рентабельности, так как обычно улучшение доступности связано с ростом затрат. Найти оптимальное решение этой проблемы — важная задача Процесса Управления Доступностью. Как показывает опыт, оп­тимальное решение можно найти, используя разумные ресурсы без крупных дополнительных ин­вестиций.

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

Такая ситуация может иметь следующие последствия для:

? снижение производительности;

? уменьшение оборота бизнеса и прибыли;

? затраты на восстановление;

? возможные претензии третьих сторон и т. д.

Перечисленные ниже аспекты трудно представить в количественном выражении, тем не менее они очень важны:

? потеря престижа и заказчиков;

? потеря репутации и доверия;

? потеря мотивации персонала и удовлетворенности работой.

Процесс Управления Доступностью может помочь ИТ-организации избежать этих потерь и достичь поставленных целей путем предоставления заказчикам необходимых услуг по приемлемой и обос­нованной цене.

Глава 15 Управление Информационной Безопасностью

15.1. Введение

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

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

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

Процесс Управления Информационной Безопасностью способствует интеграции аспектов безопас­ности в ИТ-организацию с точки зрения поставщика услуг. Сборник практических рекомендаций по Управлению Информационной Безопасностью (BS 7799) дает руководство для разработки, введе­ния и оценки мер безопасности.

15.1.1. Основные понятия

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

? Конфиденциальность – защита информации от несанкционированного доступа и использования.

? Целостность – точность, полнота и своевременность информации.

? Доступность – информация должна быть доступна в любой момент предварительного согласо­ванного временного интервала. Это зависит от непрерывности работы систем обработки инфор­мации.

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

15.2. Цели процесса

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

Процесс Управления Информационной Безопасностью имеет две цели:

? выполнение требований безопасности, закрепленных в SLA и других требованиях внешних дого­воров, законодательных актов и установленных правил;

? обеспечение базового Уровня Безопасности, независимого от внешних требований.

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

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

15.2.1. Преимущества использования процесса

Информационная безопасность не является самоцелью; она должна служить интересам бизнеса и организации. Некоторые виды информации и информационных услуг являются для организации более важными, чем другие. Информационная безопасность должна соответствовать Уровню Важ­ности Информации. Безопасность планируется путем соблюдения баланса между мерами безопас­ности, ценностью информации и существующими угрозами в среде обработки. Эффективное ин­формационное обеспечение с адекватной защитой информации важно для организации по двум причинам:

? Внутренние причины: эффективное функционирование организации возможно только при нали­чии доступа к точной и полной информации. Уровень Информационной Безопасности должен соот­ветствовать этому принципу.

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

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

15.3. Процесс

Организации и их информационные системы меняются. Стандартные шаблоны, такие как Сборник практических рекомендаций по Управлению Информационной Безопасностью (Code of Practice for Information Security Management), статичны и недостаточно соответствуют быстрым изменениям в ИТ. По этой причине деятельность, ведущаяся в рамках Процесса Управления Информационной Безопасностью, должна постоянно пересматриваться в целях обеспечения эффективности Процесса. Управление Информационной Безопасностью сводится к никогда не прекращающемуся циклу пла­нов, действий, проверок и актов. Виды деятельности, проводимые в рамках процесса Управления Информационной Безопасностью или в других процессах под контролем Управления Информаци­онной Безопасностью, описываются ниже.

Рис. 15.1. Процесс Управления Информационной Безопасностью (источник: OGC)

Требования заказчика изображены в правом верхнем углу, как входные данные процесса. Эти требо­вания определяются в разделе о безопасности Соглашения об Уровне Сервиса как услуги по безо­пасности и обеспечиваемый Уровень Безопасности. Поставщик услуг доводит эти соглашения до ИТ-организации в форме Плана по безопасности, определяющего критерии безопасности или опе­рационные Соглашения об Уровне Услуг. Этот план исполняется и результаты оцениваются. Затем план и способы его реализации корректируются, о чем Управление Уровнем Сервиса сообщает за­казчику. Таким образом, заказчик и поставщик услуг вместе участвуют в формировании всего цикла процесса. Заказчик может изменить требования на основе получаемых отчетов, а поставщик услуг может скорректировать план или его реализацию на основе результатов наблюдения или поставить задачу изменения договоренностей, определенных в соглашении SLA. Функция контроля представлена в центре рисунка 15.1. Далее эта диаграмма будет использоваться при описании видов деятель­ности Процесса Управления Информационной Безопасностью.

15.3.1. Взаимоотношения с другими процессами

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

Рис. 15.2. Отношения между Процессом Управления Информационной безопасностью и другими процессами (источник: OGC)

Управление Конфигурациями

В контексте информационной безопасности процесс Управления конфигурациями имеет наибольшее значение, так как он позволяет классифицировать Конфигурационные Единицы (CI). Эта классификация определяет связи между Конфигурационными Единицами и предпринимаемыми мерами или процедурами безопасности.

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

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

Управление Инцидентами

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

Сообщения об инцидентах поступают не только от пользователей, но также от различных Процессов Управления, возможно, на основе аварийных сигналов или данных системного аудита. Крайне необходимо, чтобы Процесс Управления Инцидентами распознавал все инциденты по безо­пасности. Это требуется для инициирования соответствующих процедур для обработки таких инци­дентов. Рекомендуется включить в планы процедуры для различных типов инцидентов по безопас­ности и опробовать их на практике. Также рекомендуется согласовывать процедуру оповещения об инцидентах, связанных с безопасностью. Нередко паника возникает из-за чрезмерно раздутых слу­хов. Точно так же нередко отсутствие своевременного оповещения об инцидентах по безопасности приводит к возникновению ущерба. Желательно, чтобы все внешние сообщения, относящиеся к ин­цидентам по безопасности, проходили через руководителя Процесса Управления Информационной Безопасностью.

Управление Проблемами

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

Управление Изменениями

Виды работ, выполняемых в рамках Процесса Управления Изменениями, часто бывают тесно связа­ны с безопасностью, так как Управление Изменениями и Управление Информационной Безопасно­стью взаимозависимы. Если достигнут приемлемый Уровень Безопасности, который находится под контролем Процесса Управления Изменениями, то можно гарантировать, что этот Уровень Безопасности будет обеспечиваться и после проведения изменении. Для поддержки этого Уровня Безопас­ности существует ряд стандартных операций. Каждый Запрос на изменения (RFC) связан с рядом параметров, которые определяют процедуру приемки. Параметры срочности и степени воздействия могут быть дополнены параметром, связанным с безопасностью. Если Запрос на изменения (RFC) может оказать значительное воздействие на информационную безопасность, потребуются расши­ренные приемочные испытания и процедуры.

В Запрос на изменения (RFC) также должны быть включены предложения по решению вопросов безопасности. Они опять же должны основываться на требованиях SLA и базовом Уровне Внутрен­ней Безопасности, необходимом для ИТ-организации. Следовательно, эти предложения будут вклю­чать комплекс мер по обеспечению безопасности, основанный на Практических нормах по Управле­нию Информационной Безопасностью.

Желательно, чтобы руководитель Процесса Управления Информационной Безопасностью (а также, возможно, инспектор по безопасности от заказчика) был членом Консультативного комитета по из­менениям (Change Advisory Board – CAB).

Однако это не значит, что по всем изменениям необходимо консультироваться с Руководителем Процесса Управления Информационной Безопасностью. В нормальной ситуации безопасность должна быть интегрирована в обычный рабочий режим. Руководитель Процесса Управления Изме­нениями должен иметь возможность решать, требуется ли ему или комитету CAB входная информа­ция от Руководителя Процесса Управления Информационной Безопасностью. Точно так же руково­дитель Процесса Управления Информационной Безопасностью не обязательно должен участвовать в выборе мер для конкретных Конфигурационных Единиц затронутых Запросом на Изменения (RFC), так как для соответствующих мер уже должен существовать структурированный подход. Во­просы могут возникнуть только со способом реализации указанных мер.

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

С точки зрения безопасности Управление Изменениями является одним из наиболее важных про­цессов. Это объясняется тем, что Управление Изменениями вводит новые меры безопасности в ИТ-инфраструктуру вместе с изменениями этой инфраструктуры.

Управление Релизами

Процесс Управления Релизами осуществляет контроль и развертывание всех новых версий про­граммного и аппаратного обеспечения, оборудования для передачи данных и т. д. Этот процесс га­рантирует, что:

? используется соответствующее аппаратное и программное обеспечение;

? аппаратное и программное обеспечение тестируются перед использованием;

? внедрение надлежащим образом санкционировано с помощью процедуры изменения;

? программное обеспечение является легальным;

? программное обеспечение не содержит вирусов, и вирусы не появятся при его распространении;

? номера версий известны и зарегистрированы в Базе Данных CMDB Процессом Управления Кон­фигурациями;

? управление развертыванием будет эффективным.

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

Управление Уровнем Сервиса

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

1. Определение потребностей заказчика в области безопасности. Естественно, определение необхо­димости в безопасности является ответственностью заказчика, так как эти потребности основаны на его интересах.

2. Проверка осуществимости требований заказчика по безопасности.

3. Предложение, обсуждение и определение Уровня Безопасности ИТ-услуг в SLA.

4. Определение, разработка и формулирование внутренних требований безопасности для ИТ-услуг (Операционные Соглашения об Уровне Услуг – OLA).

5. Мониторинг стандартов безопасности (OLA).

6. Составление отчетов о предоставляемых услугах.

Управление Информационной Безопасностью предоставляет Управлению Уровнем Сервиса входную информацию и поддержку для осуществления видов деятельности с 1 по 3. Виды деятельности 4 и 5 проводятся Управлением Информационной Безопасностью. Для деятельности 6 Управление Инфор­мационной Безопасностью и другие процессы предоставляют необходимую входную информацию. Руководители Процессов Управления Уровнем Сервиса и Управления Информационной Безопасно­стью после взаимных консультаций решают, кто реально занимается проведением этих операций. При составлении соглашений SLA обычно предполагается, что существует общий базовый Уровень Безопасности (baseline). Дополнительные требования заказчика по безопасности должны четко оп­ределяться в SLA

Управление Доступностью

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

Управление Мощностями

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

Управление Непрерывностью ИТ-услуг

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

15.3.2. Раздел по Безопасности Соглашения об Уровне Сервиса

Соглашение об Уровне Сервиса (SLA) определяет договоренности с заказчиком. Процесс Управле­ния Уровнем Сервиса отвечает за соглашения SLA (см. также главу 10). Соглашение SLA является главной движущей силой всех процессов ITIL.

ИТ-организация определяет степень выполнения требований SLA, включая требования по безопас­ности. Определенные в SLA элементы безопасности должны отвечать соответствующим потребно­стям заказчика. Заказчик должен определить важность всех бизнес-процессов (см. рис. 15.3).

Рис. 15.3. Отношения между процессами (источник: OGC)

Эти бизнес-процессы зависят от ИТ-услуг; а поэтому и от ИТ-организации. Заказчик определяет требования к безопасности (требования к информационной безопасности SLA на рис. 15.3. отсутствуют) на основе анализа риска. На рис. 15.4. показано, как определяются элементы безопасности SLA.

Рис. 15.4. Составление раздела по безопасности в соглашении SLA (источник: OGC)

Элементы безопасности обсуждаются представителями заказчика и поставщика услуг. Поставщик услуг сравнивает требования к Уровню Услуг Заказчика со своим Каталогом Услуг, где описываются стандартные меры безопасности (базовый Уровень Безопасности). Заказчик может выдвигать дополнительные требования.

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

15.3.3. Раздел по Безопасности Операционного Соглашения об Уровне Услуг (OLA)

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

Пример. В Каталоге Услуг значится "управление авторизацией пользователей и частных лиц". Опе­рационное Соглашение об Уровне Услуг конкретизирует это для всех определенных услуг, предоста­вляемых ИТ-организацией. Таким образом, реализация мероприятия определяется для подразделе­ний, предоставляющих услуги UNIX, VMS, NT, Oracle и т. д.

Там, где это возможно, требования заказчика к Уровню Сервиса определяются по Каталогу Услуг, а в случае необходимости заключаются дополнительные соглашения. Такие дополнительные меры по­вышают Уровень Безопасности по сравнению со стандартным.

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

15.4. Виды деятельности

15.4.1. Контроль – политика и организация информационной безопасности

Контроль информационной безопасности, представленный в центре рисунка 15.1, является первым подпроцессом Управления Информационной Безопасностью, и относится к организации и Управле­нию Процессом. Этот вид деятельности включает в себя структурированный подход Управления Информационной Безопасностью, который описывает следующие подпроцессы: формулирование Планов по безопасности, их реализация, оценка реализации и включение оценки в годовые Планы по безопасности (планы действий). Также описываются отчеты, предоставляемые заказчику через Процесс Управления Уровнем Сервиса.

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

Внутренние правила работы (политика)[250]:

? разработка и реализация внутренних правил работы (политики), связи с другими правилами;

? цели, общие принципы и значимость;

? описание подпроцессов;

? распределение функций и ответственностей по подпроцессам;

? связи с другими процессами ITIL и их управлением;

? общая ответственность персонала;

? обработка инцидентов, связанных с безопасностью.

Организация информационной безопасности:

? структурная схема управления[251];

? структура управления (организационная структура);

? более детальное распределение ответственностей;

? учреждение Руководящего комитета по информационной безопасности[252];

? координация информационной безопасности;

? согласование инструментальных средств (например, для анализа риска и улучшения осведомлен­ности);

? описание процесса авторизации средств ИТ в консультации с заказчиком;

? консультации специалистов;

? сотрудничество между организациями, внутреннее и внешнее взаимодействие;

? независимый аудит информационных систем;

? принципы безопасности при доступе к информации третьих сторон;

? информационная безопасность в договорах с третьими сторонами.

15.4.2. Планирование

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

Входной информацией для подпроцесса планирования являются не только положения соглашения SLA, но и принципы политики безопасности поставщика услуг (из подпроцесса контроля). Приме­рами этих принципов: "Каждый пользователь должен быть идентифицирован уникальным обра­зом"; "Базовый Уровень Безопасности предоставляется всегда и для всех заказчиков".

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

Подпроцесс планирования координируется с Процессом Управления Уровнем Сервиса по вопросам определения содержания раздела по безопасности соглашения SLA, его обновления и обеспечения соответствия его положениям. За эту координацию отвечает руководитель Процесса Управления Уровнем Сервиса.

Требования по безопасности должны определяться в соглашении SLA, по возможности в измеримых показателях. Раздел по безопасности соглашения SLA должен гарантировать, что достижение всех требований и стандартов безопасности заказчика может быть проконтролировано.

15.4.3. Реализация

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

Классификация и Управление ИТ-ресурсами:

? предоставление входных данных для поддержки Конфигурационных Единиц (CI) в базе CMDB;

? классификация ИТ-ресурсов в соответствии с согласованными принципами.

Безопасность персонала:

? задачи и ответственности в описании работ;

? отбор персонала;

? соглашения о конфиденциальности для персонала;

? обучение персонала;

? руководства для персонала по разрешению инцидентов, связанных с безопасностью, и устранению обнаруженных дефектов защиты;

? дисциплинарные меры;

? улучшение осведомленности по вопросам безопасности.

Управление Безопасностью:

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

? письменные рабочие инструкции;

? внутренние правила;

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

? отделение среды разработки и тестирования от операционной (рабочей) среды;

? процедуры обработки инцидентов (осуществляемые Процессом Управления Инцидентами);

? использование средств восстановления;

? предоставление входной информации для Процесса Управления Изменениями;

? внедрение мер защиты от вирусов;

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

? правильное обращение с носителями данных и их защита.

Контроль доступа:

? внедрение политики доступа и контроля доступа;

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

? поддержка барьеров сетевой защиты (фаервол, услуги доступа по телефонной линии, мосты и маршрутизаторы);

? внедрение методов идентификации и авторизации компьютерных систем, рабочих станций и ПК в сети

15.4.4. Оценка

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

Существует три вида оценки:

? самостоятельная оценка: проводится в первую очередь линейными подразделениями организации;

? внутренний аудит: проводится внутренними ИТ-аудиторами;

? внешний аудит: проводится внешними ИТ-аудиторами.

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

Оценка также проводится как ответное действие в случае возникновения инцидентов.

Основными видами деятельности являются:

? проверка соответствия политике безопасности и реализация Планов по безопасности;

? проведение аудита безопасности ИТ-систем;

? определение и принятие мер несоответствующего использования ИТ-ресурсов;

? проверка аспектов безопасности в других видах ИТ-аудита.

15.4.5. Поддержка

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

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

15.4.6. Составление отчетов

Составление отчетов является видом деятельности по предоставлению информации из других под­процессов. Отчеты составляются для предоставления информации о достигнутых характеристиках безопасности и для информирования заказчиков о проблемах безопасности. Вопросы предоставле­ния отчетов обычно согласовываются с заказчиком.

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

Примеры регулярных отчетов и включаемых в них событий:

Подпроцесс планирования:

? отчеты о степени соответствия соглашению SLA и согласованным ключевым показателям качест­ва по вопросам безопасности;

? отчеты о внешних договорах и связанных с ними проблемах;

? отчеты об Операционных Соглашениях об Уровне Услуг (внутренние Планы по безопасности) и собственных принципах безопасности поставщика (например, по базовому Уровню Безопасности);

? отчеты о годовых планах по безопасности и планах действий.

Подпроцесс внедрения:

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

? перечень инцидентов, связанных с безопасностью и ответных мер, возможно, в сравнении с преды­дущим отчетным периодом;

? определение тенденций возникновения инцидентов;

? состояние программы оповещения.

Подпроцесс оценки:

? отчеты об эффективности подпроцессов;

? результаты аудиторских проверок, анализа и внутренних оценок;

? предупреждения, определение новых угроз.

Специальные отчеты:

Для сообщений об определенных в соглашении SLA инцидентах, связанных с безопасностью, по­ставщик услуг должен иметь прямой канал связи с представителем заказчика (возможно, инспекто­ром информационной безопасности предприятия) через Руководителей Процессов Управления Уровнем Услуг, Управления Инцидентами или Управления Информационной Безопасностью. Должна быть также определена процедура для связи в особых случаях. За исключением особых обстоятельств, отчеты передаются через Процесс Управления Уровнем Услуг.

15.5. Контроль процесса

15.5.1. Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха являются:

? полное понимание необходимости процесса со стороны руководства и его привлечение к процессу;

? привлечение пользователей к разработке процесса;

? точное определение и разделение ответственностей.

Показатели эффективности Процесса Управления Информационной Безопасностью соответствуют таким же показателям Процесса Управления Уровнем Сервиса в той степени, в которой последние связаны с затрагиваемыми в SLA вопросами безопасности.

15.5.2. Функции и роли

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

15.6. Проблемы и затраты

15.6.1. Проблемы

Следующие аспекты имеют существенное значение для успешной реализации Процесса Управления Информационной Безопасностью:

? Понимание необходимости процесса (понимание со стороны участников): меры безопасности редко встречают быстрое положительное понимание со стороны персонала; чаще встречается сопро­тивление, а не одобрение. Пользователи возмущаются потерей определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются существенными для их работы. Это объясняется тем, что привилегии дают им определенный статус. Поэтому необходима специаль­ная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать пример ("разъяснять курс" и "вести за собой"). При отсутствии инцидентов по безопасно­сти у руководства может возникнуть искушение сократить расходы на Управление Безопасностью.

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

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

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

? Управление Изменениями: часто при проведении изменений ослабевает качество оценки соответ­ствия базовому Уровню Безопасности.

? Амбиции: при желании организации делать все сразу часто возникают ошибки. В случае введения Процесса Управления Информационной Безопасностью реализация технических мер гораздо ме­нее важна по сравнению с организационными мерами. Изменение организации требует поэтапно­го подхода и занимает длительное время.

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

? Чрезмерные надежды на технологию "неприступной крепости": угрозы безопасности систем все чаще возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с первым примером атак Denial of Service (DoS). В то время как защита информации с использова­нием традиционного подхода "неприступной крепости" сохраняет свое значение, также приобре­тает важность подхода "встречных атак" при возникновении нарушений безопасности. Организа­ция должна иметь возможность быстро направить ресурсы в место возникновения дефекта до то­го, как он сможет выйти из-под контроля.

15.6.2. Затраты

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

Приложение А. Фирма "Quick Couriers" ("Быстрые курьеры")

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

Транспорт в Амстердаме в настоящее время так перегружен, что предоставление курьерских услуг с помощью автофургонов стало затруднительным. Поэтому после окончания учебы трое друзей Джейн, Джон и Питер решили заняться курьерскими услугами на велосипедах и открыли фирму Quick Couriers (QC). Фирма QC доставляет посылки в центр города, используя для этого велосипе­ды.

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

Джейн является ответственной за бухгалтерию, выписывание счетов, обработку заказов и поддерж­ку деловых связей. Фирма Quick Couriers закупила программные приложения для бухгалтерии и Процесса Управления Взаимоотношениями.

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

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

Недавно три друга произвели анализ положения своей фирмы и определили свою концепцию и вну­тренние правила работы (policy). Концепция заключается в следующем: "Фирма Quick Couriers должна стать синонимом быстрой доставки в центре Амстердама и окружающих районах". Для реа­лизации этого фирма начала рекламную компанию и увеличила наем курьеров. Было запланировано оснащение курьеров пейджерами или мобильными телефонами. Был также сделан запрос о цене Интернет-системы, которой могли бы пользоваться заказчики для подачи заявок на курьеров и от­слеживания доставки своих посылок. Другим рассматриваемым вариантом было расширение биз­нес-операций путем открытия еще одного офиса в Гааге или Роттердаме. Кроме того, друзья решили, что для будущего компании критическое значение имеет постановка их бизнеса на более профессио­нальную основу. Поэтому они определили области, требующие особого внимания.

А.1. Управление Конфигурациями

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

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

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

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

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

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

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

Вопросы:

1. Что послужило причиной для разработки этого процесса?

2. Кто вовлечен в процесс, кроме самого Питера?

3. Сделайте набросок сферы действия (scope) и степени детализации (level of detail) базы данных. Какие атрибуты конфигурационных единиц (CI) имеют значение для Питера?

4. Что используется для мониторинга состояния? Для чего нужно хранить историю состояний (sta­tus history)?

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

6. Как будет Питер заполнять базу данных?

7. Как может Питер обеспечить актуальное состояние базы данных?

8. Какие отчеты Питер будет предоставлять Джейн?

А.2. Управление Инцидентами и Служба Service Desk

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

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

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

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

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

Вопросы:

1. Что вызвало развитие Службы Service Desk?

2. Какой тип Службы Service Desk первоначально использовался для данного процесса?

3. Какая информация об инциденте существенна при обработке обращения (звонка)?

4. Приведите примеры категорий и приоритетов.

5. Кому может позвонить Джон, если он не в состоянии решить проблему?

6. Эффективная связь с ремонтной мастерской имеет существенное значение. Какой термин исполь­зуется для этого в библиотеке ITIL?

7. Как может фирма Quick Couriers убедиться в том, что обращения по инцидентам не пропущены, и кто отвечает за это?

8. Оказывается ли в данном случае поддержка бизнес-операциям (Business Operations support)? Ес­ли да, объясните как.

9. Какие информационные каналы к другим системам хотели бы вы создать, и с какой целью?

10. Какой отчет должен Джон представлять Питеру и Джейн?

A.3. Управление Проблемами

Благодаря базам RoutePlan для разработки маршрутов, TelLog для регистрации звонков и ConFig для регистрации инвентаря улучшился сервис и уменьшилась рабочая нагрузка. Фирма Quick Couriers теперь имеет тридцать курьеров на маршрутах, а Джон и Джейн поженились, и свадебной "машиной", конечно же, был велосипед-тандем.

Джон теперь использует базу RoutePlan для планирования маршрутов. Привлекаемый к работе сту­дент отвечает на телефонные звонки и может решить большую часть инцидентов с помощью предос­тавляемой Джоном документации. При возникновении новой проблемы, студент обращается за по­мощью к Питеру, Джону или Джейн, и затем документирует решение так, чтобы его можно было легко отыскать в следующий раз. Если курьер задерживается в пути из-за проблемы с велосипедом, студент из службы Service Desk отправляет запасную деталь на этот маршрут со следующим курье­ром. Если курьер не может справиться с проблемой, Питер доставляет ему другой велосипед на трейлере.