Конспект_ АИС
advertisement
Администрирование информационных систем. Курс лекций Составитель Соркина В.Е. ВВЕДЕНИЕ ................................................................................................................................. 12 ЭЛЕМЕНТЫ УПРАВЛЕНИЯ ИТ .......................................................................................... 14 ОБЩИЕ ЭЛЕМЕНТЫ УПРАВЛЕНИЯ И ЭЛЕМЕНТЫ УПРАВЛЕНИЯ ПРИЛОЖЕНИЙ ............................... 15 Общие элементы управления .............................................................................................. 15 Элементы управления приложений .................................................................................... 15 ДАЛЬНЕЙШАЯ КЛАССИФИКАЦИЯ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ ИТ ................................................. 16 ИНТЕГРИРОВАННЫЕ ЭЛЕМЕНТЫ УПРАВЛЕНИЯ.............................................................................. 18 ВАЖНОСТЬ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ ИТ .................................................................................... 19 ПРОЦЕДУРА АУДИТА ИТ ..................................................................................................... 21 ЭТАП 1. ПЛАНИРОВАНИЕ АУДИТА................................................................................................. 22 ЭТАП 2. ПРОВЕДЕНИЕ СОВЕЩАНИЯ ПЕРЕД НАЧАЛОМ АУДИТА ..................................................... 22 ЭТАП 3. СБОР ДАННЫХ И ТЕСТИРОВАНИЕ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ ИТ .................................... 22 ЭТАП 4. ИСПРАВЛЕНИЕ ВЫЯВЛЕННЫХ НЕДОСТАТКОВ.................................................................. 23 ЭТАП 5. ТЕСТИРОВАНИЕ ИСПРАВЛЕННЫХ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ .......................................... 23 ЭТАП 6. ПРОВЕДЕНИЕ АНАЛИЗА И СОСТАВЛЕНИЕ ОТЧЕТА ПО РЕЗУЛЬТАТАМ АУДИТА ................ 23 ЭТАП 7. РЕАКЦИЯ НА РЕЗУЛЬТАТЫ АУДИТА .................................................................................. 23 ЭТАП 8. ПРЕДСТАВЛЕНИЕ ОКОНЧАТЕЛЬНОГО ОТЧЕТА .................................................................. 24 СПОСОБЫ ОПТИМИЗАЦИИ ПРОЦЕДУРЫ АУДИТА ........................................................................... 24 Бизнес-факторы ................................................................................................................... 25 СЛОЖНЫЕ ЗАДАЧИ БИЗНЕСА .......................................................................................................... 25 Сложность нормативно-правовой среды ......................................................................... 25 Достижение и поддержание соответствия нормативным требованиям .................. 25 Последствия несоблюдения требований ........................................................................... 26 ДЕЛОВЫЕ ВОЗМОЖНОСТИ .............................................................................................................. 26 Совершенствование процессов ........................................................................................... 26 Конкурентные преимущества ............................................................................................ 27 Интеграция ИТ и окупаемость инвестиций ..................................................................... 28 СТРУКТУРНЫЙ ПОДХОД К ЗАДАЧЕ СООТВЕТСТВИЯ НОРМАТИВНЫМ ТРЕБОВАНИЯМ ................................................................................................................................... 29 ОСНОВЫ СТРУКТУРЫ.......................................................................................................... 30 РАЗРАБОТКА ЕДИНЫХ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ ИНФОРМАЦИОННЫМИ ТЕХНОЛОГИЯМИ .......... 31 ПРЕИМУЩЕСТВА СТРУКТУРНОГО ПОДХОДА ДЛЯ ОРГАНИЗАЦИИ ................ 33 СТРУКТУРА ДЛЯ КОНКРЕТНОЙ ОРГАНИЗАЦИИ ...................................................... 34 СОПОСТАВЛЕНИЕ НОРМАТИВНЫХ АКТОВ С ТЕХНОЛОГИЧЕСКИМИ РЕШЕНИЯМИ ....................................................................................................................................... 35 СОПОСТАВЛЕНИЕ НОРМАТИВНЫХ АКТОВ С КОНТРОЛЬНОЙ СТРУКТУРОЙ ................................................................................................................................................................... 36 КАТЕГОРИИ ЭЛЕМЕНТОВ УПРАВЛЕНИЯ ......................................................................................... 37 ТЕХНОЛОГИЧЕСКИЕ РЕШЕНИЯ ПО ОБЕСПЕЧЕНИЮ СООТВЕТСТВИЯ НОРМАТИВНЫМ ТРЕБОВАНИЯМ ............................................................................................... 39 УПРАВЛЕНИЕ ДОКУМЕНТАМИ ....................................................................................................... 39 УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ ............................................................................................. 40 УПРАВЛЕНИЕ ПРОЕКТАМИ ............................................................................................................. 40 ОЦЕНКА РИСКОВ ............................................................................................................................ 41 УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ ........................................................................................................ 41 БЕЗОПАСНОСТЬ СЕТИ ..................................................................................................................... 41 УПРАВЛЕНИЕ УЗЛАМИ ................................................................................................................... 42 ПРЕДОТВРАЩЕНИЕ ЗАРАЖЕНИЯ ВРЕДОНОСНЫМИ ПРОГРАММАМИ .............................................. 42 БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ ....................................................................................................... 42 ОБМЕН СООБЩЕНИЯМИ И СОВМЕСТНАЯ РАБОТА .......................................................................... 43 КЛАССИФИКАЦИЯ И ЗАЩИТА ДАННЫХ ......................................................................................... 43 УПРАВЛЕНИЕ УЧЕТНЫМИ ДАННЫМИ............................................................................................. 44 УПРАВЛЕНИЕ ПРОВЕРКОЙ ПОДЛИННОСТИ, АВТОРИЗАЦИЕЙ И ДОСТУПОМ ................................... 44 ОБУЧЕНИЕ ...................................................................................................................................... 45 ФИЗИЧЕСКАЯ ЗАЩИТА ................................................................................................................... 45 ВЫЯВЛЕНИЕ УЯЗВИМОСТЕЙ .......................................................................................................... 45 МОНИТОРИНГ И ОТЧЕТНОСТЬ ........................................................................................................ 46 ВОССТАНОВЛЕНИЕ ПОСЛЕ СБОЕВ И ОТКАЗОУСТОЙЧИВОСТЬ ........................................................ 46 УПРАВЛЕНИЕ ОБРАБОТКОЙ ОСОБЫХ СИТУАЦИЙ И ОТСЛЕЖИВАНИЕ НЕПОЛАДОК ........................ 47 ЗАКЛЮЧЕНИЕ ................................................................................................................................. 47 ТЕХНОЛОГИЧЕСКИЕ РЕШЕНИЯ ДЛЯ УПРАВЛЕНИЯ ИТ ....................................... 48 ПРИКЛАДНОЙ ПРИМЕР ....................................................................................................... 49 НЕКОТОРЫЕ ВОПРОСЫ СБОРА И ОБРАБОТКИ ИНФОРМАЦИИ ДЛЯ ПРИНЯТИЯ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ НА ПРЕДПРИЯТИИ. ................................... 51 СИСТЕМА И ЗАДАЧИ УПРАВЛЕНЧЕСКОГО УЧЕТА ................................................. 53 ИЕРАРХИЯ СИСТЕМ УПРАВЛЕНЧЕСКОГО УЧЕТА ................................................... 55 ПРИМЕНЕНИЕ МОНИТОРИНГА ИНФОРМАЦИОННОЙ СРЕДЫ ПРЕДПРИЯТИЯ ................................................................................................................................................................... 59 ПАКЕТЫ УПРАВЛЕНИЯ ....................................................................................................... 60 ЗАДАЧИ СОЗДАНИЯ И ИСПОЛЬЗОВАНИЯ HEALTH MODEL.................................. 62 ОСНОВНЫЕ ИНСТРУМЕНТЫ ПОСТРОЕНИЯ HEALTH MODEL ........................................................... 62 ТИПИЧНАЯ HEALTH MODEL .......................................................................................................... 62 ЭТАПЫ РАБОТ ПО СОЗДАНИЮ MP ................................................................................. 63 ПОДСИСТЕМА ОТЧЕТНОСТИ СИСТЕМЫ МОНОТОРИНГА .................................. 64 АРХИТЕКТУРА ПОДСИСТЕМЫ ОТЧЕТНОСТИ .................................................................................. 64 Пакет управления веб-узлами и веб-службами................................................................. 64 Концепция.............................................................................................................................. 64 КАК ОСУЩЕСТВЛЯЕТСЯ МОНИТОРИНГ .......................................................................................... 65 Веб-узлы ................................................................................................................................ 65 Транзакции веб-приложений ............................................................................................... 65 Советы по регистрации перемещений на веб-узле........................................................... 66 Методы веб-служб .............................................................................................................. 66 ПРИМЕР ВОЗМОЖНОСТЕЙ СИСТЕМ МОНИТОРИНГА ФИРМЫ MICROSOFT SYSTEM CENTER OPERATIONS MANAGER 2007 И SYSTEM CENTER CONFIGURATION MANAGER 2007 (SCCM).ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ ................................................ 68 ДЛЯ ОПЕРАТОРА............................................................................................................................. 68 ОПТИМАЛЬНО ДЛЯ WINDOWS ........................................................................................................ 68 УПРАВЛЕНИЕ, ОСНОВАННОЕ НА ЗНАНИЯХ ............................................................... 69 СБОР ЗНАНИЙ С ПОМОЩЬЮ МОДЕЛЕЙ ........................................................................................... 69 КОМПЛЕКСНЫЙ МОНИТОРИНГ СЛУЖБЫ ................................................................. 71 АРХИТЕКТУРА ......................................................................................................................... 71 MOM 2005 И OPSMGR 2007 .................................................................................................... 73 МИГРАЦИЯ ХРАНИЛИЩА ДАННЫХ ................................................................................................ 73 НОВЫЕ ФУНКЦИИ SMS 2003 R2 И КАК БУДЕТ ВЫГЛЯДЕТЬ MICROSOFT SYSTEM CENTER CONFIGURATION MANAGER 2007 .............................................................................................................. 73 Функциональные возможности .......................................................................................... 73 Средство сканирования для выявления уязвимостей ....................................................... 73 Отчеты о 100 критических проблемах конфигурации .................................................... 73 ОБНОВЛЕНИЕ ПО (НЕ-MICROSOFT). ТЕКУЩАЯ СИТУАЦИЯ .......................................................... 74 Средство инвентаризации для пользовательских обновлений Inventory Tool for Custom Updates .............................................................................................................................................. 74 ITCU КОМПОНЕНТЫ ............................................................................................................. 75 СРЕДСТВО ПУБЛИКАЦИИ ПОЛЬЗОВАТЕЛЬСКИХ ОБНОВЛЕНИЙ ИМПОРТ, СОЗДАНИЕ И УПРАВЛЕНИЕ КАТАЛОГАМИ ОБНОВЛЕНИЙ ...................................................................................................................... 75 ITCU Схема каталогов обновлений .................................................................................... 75 ITCU.Правила выявления обновлений ................................................................................. 75 Custom Updates Publishing Tool Inventory Tool for Custom Updates Сканирование и развертывание обновлений ............................................................................................................. 76 MANAGING CUSTOM UPDATES ........................................................................................................ 76 ИТОГ (SMS2003 R2) ..................................................................................................................... 76 SYSTEM CENTER CONFIGURATION MANAGER 2007 КЛЮЧЕВЫЕ НАПРАВЛЕНИЯ РАЗВИТИЯ ............................................................................................................ 77 Простота: ............................................................................................................................ 77 Развертывание: .................................................................................................................... 77 Безопасность:....................................................................................................................... 77 Конфигурация: ...................................................................................................................... 77 SCCM 2007 НОВЫЕ ВОЗМОЖНОСТИ (АРХИТЕКТУРНЫЕ РЕШЕНИЯ) ............................................. 77 SCCM 2007 НОВЫЕ ВОЗМОЖНОСТИ (ИНВЕНТАРИЗАЦИЯ) ........................................................... 78 SCCM 2007 НОВЫЕ ВОЗМОЖНОСТИ (ВЗАИМОДЕЙСТВИЕ С КЛИЕНТАМИ И БЕЗОПАСНОСТЬ) ...... 78 SCCM 2007 НОВЫЕ ВОЗМОЖНОСТИ (SOFTWARE DISTRIBUTION)................................................ 79 SCCM2007 НОВЫЕ ВОЗМОЖНОСТИ (SOFTWARE UPDATES) ......................................................... 79 SCCM2007 НОВЫЕ ВОЗМОЖНОСТИ (OS DEPLOYMENT) .............................................................. 79 SCCM2007 СЦЕНАРИИ РАЗВЕРТЫВАНИЯ ОС .............................................................................. 80 SCCM2007 НОВЫЕ ВОЗМОЖНОСТИ (REMOTE TOOLS) ................................................................. 80 ВНЕДРЕНИЕ ИС: ЧЕРЕЗ ТЕРНИИ К ЗВЕЗДАМ .............................................................. 81 "ПРОЕКТ ВНЕДРЕНИЯ...." ............................................................................................................... 82 СИСТЕМНЫЙ ВЗГЛЯД ..................................................................................................................... 85 "ЗАМЫЛЕННЫЙ ВЗГЛЯД"................................................................................................................ 86 СЛУЖБА ПОДДЕРЖКИ ПРОЕКТОВ ................................................................................................... 87 ЗАКЛЮЧЕНИЕ ................................................................................................................................. 87 АРХИТЕКТУРА СОВРЕМЕННОЙ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ ............................................................................................................................................. 88 Аннотация: ........................................................................................................................... 88 Предисловие. ......................................................................................................................... 88 СОСТАВ АРХИТЕКТУРЫ СОВРЕМЕННОЙ ИАС................................................................................ 88 Сбор и первичная обработка данных................................................................................. 90 Извлечение, преобразование и загрузка данных ................................................................ 91 Складирование данных......................................................................................................... 91 Представление данных в витринах данных ...................................................................... 91 Анализ данных....................................................................................................................... 92 Web-портал ........................................................................................................................... 93 РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ ИАС ................................................................................................ 93 РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ ИАС НА ОСНОВЕ ПЛАТФОРМЕННО-БАЗИРОВАННОГО РЕШЕНИЯ ...... 94 ИНСТРУМЕНТЫ ДЛЯ ИЗВЛЕЧЕНИЯ, ПРЕОБРАЗОВАНИЯ, ЗАГРУЗКИ И ХРАНЕНИЯ ДАННЫХ (ETL) .. 96 ИНСТРУМЕНТЫ ДЕЛОВОГО АНАЛИЗА ................................................................................. 96 ПРОИЗВОЛЬНЫЕ ЗАПРОСЫ И РЕГЛАМЕНТИРОВАННЫЕ ФОРМЫ ОТЧЕТОВ ...................................... 96 МНОГОМЕРНЫЙ АНАЛИЗ ДАННЫХ................................................................................................. 97 РАЗВЕДКА ДАННЫХ........................................................................................................................ 97 WEB-ПОРТАЛ ................................................................................................................................. 97 РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ ИАС НА ОСНОВЕ СМЕШАННОГО РЕШЕНИЯ ..................................... 98 ОПИСАНИЕ МЕТАДАННЫХ ........................................................................................................... 102 ИНСТРУМЕНТЫ ДЕЛОВОГО АНАЛИЗА .......................................................................................... 102 ПРОИЗВОЛЬНЫЕ ЗАПРОСЫ И РЕГЛАМЕНТИРОВАННЫЕ ФОРМЫ ОТЧЕТОВ .................................... 102 МНОГОМЕРНЫЙ АНАЛИЗ ДАННЫХ............................................................................................... 102 РАЗВЕДКА ДАННЫХ...................................................................................................................... 103 ВИЗУАЛИЗАЦИЯ ИНФОРМАЦИИ ................................................................................................... 104 WEB-ПОРТАЛ ............................................................................................................................... 104 ЗАКЛЮЧЕНИЕ ............................................................................................................................... 105 ЗАЩИЩЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ ................................................. 106 ПОЧЕМУ ЗАЩИЩЕННОСТЬ? ......................................................................................................... 106 СИТУАЦИЯ ................................................................................................................................... 107 История .............................................................................................................................. 107 Защищенные технологии в целом ..................................................................................... 108 Защищенные информационные системы ........................................................................ 109 МОДЕЛЬ ЗАЩИЩЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ............................................................... 109 Цели ..................................................................................................................................... 110 Средства ............................................................................................................................. 111 ФУНДАМЕНТАЛЬНЫЕ ПРОБЛЕМЫ .............................................................................. 116 ПОЛИТИЧЕСКИЕ ВОПРОСЫ .......................................................................................................... 116 СЛОЖНОСТЬ ОБРАБОТКИ ДАННЫХ............................................................................................... 116 ИЗБЫТОЧНОСТЬ АППАРАТНЫХ СРЕДСТВ ..................................................................................... 117 МЕЖМАШИННЫЕ ПРОЦЕССЫ ....................................................................................................... 118 ИДЕНТИФИКАЦИЯ ЛИЧНОСТИ ПОЛЬЗОВАТЕЛЯ ............................................................................ 119 ЛЮДИ ........................................................................................................................................... 119 СРЕДСТВА ПРОГРАММИРОВАНИЯ ................................................................................................ 120 ФУНКЦИОНАЛЬНАЯ СОВМЕСТИМОСТЬ ........................................................................................ 121 КОНЦЕПТУАЛЬНЫЕ МОДЕЛИ........................................................................................................ 122 ИТОГИ .......................................................................................................................................... 122 ОПРЕДЕЛЕНИЕ УГРОЗЫ БЕЗОПАСНОСТИ................................................................. 126 УПРАВЛЕНИЕ РИСКАМИ ............................................................................................................... 126 Ресурсы................................................................................................................................ 127 Угрозы. ................................................................................................................................ 127 Уязвимое место. ................................................................................................................. 127 Эксплойт. ............................................................................................................................ 128 Взаимодействие между угрозами, уязвимыми местами и рисками. ........................... 129 КОНТРМЕРЫ ................................................................................................................................. 130 МНОГОУРОВНЕВАЯ ЗАЩИТА (ГЛУБОКАЯ ЗАЩИТА, DEFENSE IN DEPTH) ..................................... 130 Защита данных. ................................................................................................................. 132 Защита приложений. ......................................................................................................... 132 Защита хостов. .................................................................................................................. 132 Сетевая защита. ................................................................................................................ 133 Защита периметра. ........................................................................................................... 133 Физическая Безопасность. ................................................................................................ 133 Политики и процедуры ...................................................................................................... 134 ОБЫЧНЫЕ СПОСОБЫ НАПАДЕНИЯ И МЕРЫ ПРЕДОТВРАЩЕНИЯ ................................................... 135 Сбор информации. .............................................................................................................. 135 Ограничение способности сканировать и получать ценную информацию ................. 137 Использование технически уязвимых мест ..................................................................... 140 Налет на сеанс ................................................................................................................... 140 Предотвращение «заражения DNS» ............................................................................... 140 Атаки через строки URL .................................................................................................. 141 Атака на файл Security Accounts Manager ....................................................................... 141 Переполнение буфера. ........................................................................................................ 141 Отказ в обслуживании. ..................................................................................................... 142 Атаки через черный ход (Backdoor Attacks). ................................................................... 143 Злонамеренный код ............................................................................................................ 144 ЗАКЛЮЧЕНИЕ ............................................................................................................................... 145 ПЕРЕДОВОЙ ОПЫТ: ПРОГРАММА «ДВЕНАДЦАТЬ ШАГОВ К КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ»................................................................................... 146 VIRTUALIZATION.РАЗВЕРТЫВАНИЕ ВИРТУАЛЬНОЙ ИНФРАСТРУКТУРЫ НА СТАНДАРТНЫХ ОПЕРАЦИОННЫХ СИСТЕМАХ. РЕКОМЕНДАЦИИ IDEAS ДЛЯ ПОЛЬЗОВАТЕЛЕЙ ............................................................................................................................ 148 ОСНОВНЫЕ ПОЛОЖЕНИЯ ............................................................................................................. 148 ЭКОНОМИЧЕСКАЯ ЭФФЕКТИВНОСТЬ ВИРТУАЛИЗАЦИИ............................................................... 149 ОПЕРАЦИОННЫЕ ПРЕИМУЩЕСТВА ИСПОЛЬЗОВАНИЯ ВИРТУАЛИЗАЦИИ 150 ВИРТУАЛИЗАЦИЯ ОТДЕЛЬНОГО СЕРВЕРА ПО СРАВНЕНИЮ С ВИРТУАЛЬНОЙ ИНФРАСТРУКТУРОЙ ................................................................................................................................................................. 151 ПОЗИЦИОНИРОВАНИЕ АРХИТЕКТУР ВИРТУАЛЬНЫХ МАШИН ...................................................... 153 Основные технические аспекты виртуализации ............................................................ 154 ДОСТИЖЕНИЕ ПРЕИМУЩЕСТВ ОТ ВИРТУАЛИЗАЦИИ ПРИ ИСПОЛЬЗОВАНИИ SLES 10 И WINDOWS SERVER 2008............................................................................................................................................ 158 Основные сценарии виртуализации .................................................................................. 158 Управляемость ................................................................................................................... 159 Инструменты развертывания ......................................................................................... 160 ВЫВОДЫ IDEAS .......................................................................................................................... 161 ВИРТУАЛИЗАЦИЯ ПРИЛОЖЕНИЙ: НОВЫЕ РУБЕЖИ ............................................ 163 АННОТАЦИЯ. ................................................................................................................................ 163 ОСНОВНЫЕ ПОЛОЖЕНИЯ................................................................................................ 164 СОКРАЩЕНИЕ ЗАТРАТ НА ИТ С ПОМОЩЬЮ ВИРТУАЛИЗАЦИИ .................................................... 167 ВИРТУАЛИЗАЦИЯ УЖЕ НАШЛА ШИРОКОЕ ПРИМЕНЕНИЕ ............................................................. 167 ИСТОРИЯ РАЗВИТИЯ ТЕХНОЛОГИИ ВИРТУАЛИЗАЦИИ .................................................................. 169 ВКЛАД КОРПОРАЦИИ МАЙКРОСОФТ В ДЕЛО ВИРТУАЛИЗАЦИИ................................................... 170 ТАБЛИЦА 15. ВКЛАД КОРПОРАЦИИ МАЙКРОСОФТ В ДЕЛО ВИРТУАЛИЗАЦИИ ............................................................................................................................ 170 ПРЕИМУЩЕСТВА ВИРТУАЛИЗАЦИИ ПРИЛОЖЕНИЙ ...................................................................... 171 СРЕДСТВО ВИРТУАЛИЗАЦИИ ПРИЛОЖЕНИЙ SOFTGRID ................................... 174 SOFTGRID И SYSTEMS MANAGEMENT SERVER: ВМЕСТЕ – ЛУЧШЕ! ............................................. 176 ПРИНЦИПЫ РАБОТЫ СРЕДСТВА ВИРТУАЛИЗАЦИИ ПРИЛОЖЕНИЙ SOFTGRID .............................. 178 ПРЕИМУЩЕСТВА SOFTGRID ДЛЯ КОМПЬЮТЕРНЫХ СРЕД ПРЕДПРИЯТИЙ .................................... 180 БИЗНЕС-ЦЕННОСТЬ И ОКУПАЕМОСТЬ ИНВЕСТИЦИЙ .................................................................... 182 ЗАКЛЮЧЕНИЕ ............................................................................................................................... 184 LDAP: АРХИТЕКТУРА, РЕАЛИЗАЦИИ И ТЕНДЕНЦИИ............................................ 186 ТЕХНОЛОГИЯ LDAP .................................................................................................................... 187 АРХИТЕКТУРА LDAP .................................................................................................................. 187 КАТАЛОГ LDAP .......................................................................................................................... 188 XML И НАСТРОЙКА КАТАЛОГОВ LDAP ...................................................................................... 190 ПРАКТИЧЕСКОЕ ИСПОЛЬЗОВАНИЕ LDAP .................................................................................... 191 РЕАЛИЗАЦИИ LDAP .................................................................................................................... 192 ВЫБОР СЕРВЕРА LDAP ................................................................................................................ 193 ЭВОЛЮЦИЯ LDAP: ЧТО ДАЛЬШЕ? ................................................................................ 194 ВВЕДЕНИЕ В AD .................................................................................................................... 195 СЛУЖБЫ КАТАЛОГОВ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ ...................................................................... 195 ОТЛИЧИЯ ОТ ТРАДИЦИОННЫХ СЛУЖБ КАТАЛОГОВ ..................................................................... 196 ВОЗМОЖНОСТИ ACTIVE DIRECTORY ........................................................................................... 196 ВОЗМОЖНОСТИ И ХАРАКТЕРИСТИКИ........................................................................................... 197 ОБЩИЕ СВЕДЕНИЯ ОБ ACTIVE DIRECTORY ............................................................. 199 ЕДИНЫЙ КАТАЛОГ ....................................................................................................................... 199 ЕДИНОЕ АДМИНИСТРИРОВАНИЕ .................................................................................................. 199 МАСШТАБИРУЕМОСТЬ ................................................................................................................. 200 ИНТЕГРАЦИЯ С ОПЕРАЦИОННОЙ СИСТЕМОЙ ............................................................................... 200 ПОДДЕРЖКА ОТКРЫТЫХ СТАНДАРТОВ И СТАНДАРТНЫХ ФОРМАТОВ ИМЕН .................................................................................................................................................... 201 ПОДДЕРЖКА DNS ........................................................................................................................ 201 Создание имен, совместимых с Интернетом ................................................................ 201 Создание более легкой в управлении среды DNS ............................................................. 202 ПОДДЕРЖКА LDAP ..................................................................................................................... 203 ПОДДЕРЖКА СТАНДАРТНЫХ ФОРМАТОВ ИМЕН ........................................................................... 203 Имена RFC822 .................................................................................................................... 204 Имена LDAP URL и X.500.................................................................................................. 204 ПРОГРАММНЫЕ ИНТЕРФЕЙСЫ .................................................................................... 205 ACTIVE DIRECTORY SERVICE INTERFACES (ADSI) ...................................................................... 205 WINDOWS MESSAGING API (MAPI) ............................................................................................ 206 LDAP C API ................................................................................................................................ 207 ШИРОКИЕ ВОЗМОЖНОСТИ МАСШТАБИРОВАНИЯ .............................................. 208 ИСПОЛЬЗОВАНИЕ ДОМЕННЫХ ДЕРЕВЬЕВ И ЛЕСОВ ...................................................................... 208 ИСПОЛЬЗОВАНИЕ КОНТЕЙНЕРНОЙ СТРУКТУРЫ ДЛЯ МОДЕЛИРОВАНИЯ ОРГАНИЗАЦИИ .............. 209 ДЕТАЛИЗИРОВАННОЕ АДМИНИСТРИРОВАНИЕ ............................................................................. 209 ПОВЫШЕННАЯ БЕЗОПАСНОСТЬ ................................................................................................... 210 РАСШИРЕНИЕ СЛУЖБЫ КАТАЛОГОВ С ПОМОЩЬЮ СХЕМЫ (EXTENSIBLE SCHEMA) .................... 210 ГЛОБАЛЬНЫЙ КАТАЛОГ ............................................................................................................... 211 МНОГОУРОВНЕВАЯ РЕПЛИКАЦИЯ ............................................................................................... 211 ОБНОВЛЕНИЕ КАТАЛОГА В МНОГОУРОВНЕВОЙ СРЕДЕ ................................................................ 212 РАСПРЕДЕЛЕННАЯ СИСТЕМА ЗАЩИТЫ .................................................................... 214 ЗАЩИТА С ЗАКРЫТЫМ КЛЮЧОМ .................................................................................................. 214 ЗАЩИТА С ОТКРЫТЫМ КЛЮЧОМ .................................................................................................. 214 УТИЛИТЫ ДЛЯ АДМИНИСТРИРОВАНИЯ ................................................................... 215 АДМИНИСТРИРОВАНИЕ В СТИЛЕ «ПЕРЕТАЩИТЬ И ОСТАВИТЬ» .................................................. 215 СЦЕНАРИИ И АВТОМАТИЗАЦИЯ ................................................................................................... 215 ОБЕСПЕЧЕНИЕ ОБРАТНОЙ СОВМЕСТИМОСТИ ..................................................... 216 ЛЕГКИЙ ПЕРЕХОД С WINDOWS NT 3.51 И 4.0 ............................................................................. 216 Переход с Windows NT 4.0 на Active Directory ................................................................. 216 ЛЕГКИЙ ПЕРЕХОД ОТ СЛУЖБЫ MICROSOFT EXCHANGE .............................................................. 218 ЗАКЛЮЧЕНИЕ ....................................................................................................................... 219 NOVELL EDIRECTORY 8.7.1 ............................................................................................... 220 ОБЗОР ........................................................................................................................................... 220 СОКРАЩЕНИЕ РАСХОДОВ НА АДМИНИСТРИРОВАНИЕ ................................................................. 220 ЗАЩИТА РЕСУРСОВ ОТ НЕСАНКИОНИРОВАННОГО ДОСТУПА....................................................... 220 ПОДДЕРЖКА МУЛЬТИПЛАТФОРМЕННОСТИ И ОТКРЫТЫХ СТАНДАРТОВ ...................................... 221 МАСШТАБИРУЕМОСТЬ ДЛЯ ПОДДЕРЖКИ ВОЗМОЖНОСТЕЙ РАЗВИТИЯ БИЗНЕСА ......................... 221 Возможности ..................................................................................................................... 221 Преимущества .................................................................................................................... 221 РЕЗЮМЕ ДЛЯ РУКОВОДСТВА ........................................................................................................ 222 Сравнительный анализ отдельных функций ................................................................... 223 ОПЫТ МИРОВОЙ ПРАКТИКИ ......................................................................................................... 225 РЕАЛИЗАЦИЯ ......................................................................................................................... 226 ПОДДЕРЖКА МНОЖЕСТВА ОПЕРАЦИОННЫХ СИСТЕМ. ................................................................ 226 Преимущество NDS ........................................................................................................... 226 ОБЕСПЕЧЕНИЕ ДОСТУПА СО МНОЖЕСТВА ПЛАТФОРМ ................................................................ 226 Преимущество NDS ........................................................................................................... 226 ЕДИНОЕ ДЕРЕВО ДЛЯ ВСЕХ СЕТЕВЫХ РЕСУРСОВ ......................................................................... 227 Преимущество NDS ........................................................................................................... 227 ЭФФЕКТИВНЫЕ МЕХАНИЗМЫ ХРАНЕНИЯ ДАННЫХ ..................................................................... 227 Преимущество NDS ........................................................................................................... 228 АПРОБИРОВАННАЯ ТЕХНОЛОГИЯ МАСШТАБИРОВАНИЯ БАЗЫ ДАННЫХ ..................................... 228 Преимущество NDS ........................................................................................................... 228 ОПТИМИЗИРОВАННЫЕ ПРОЦЕССЫ ТИРАЖИРОВАНИЯ ................................................................. 228 Преимущество NDS ........................................................................................................... 229 ПОДДЕРЖКА СУЩЕСТВУЮЩЕЙ СТРУКТУРЫ СЛУЖБЫ ИМЕН ДОМЕНОВ (DNS) .......................... 229 Преимущество NDS ........................................................................................................... 230 УПРАВЛЕНИЕ......................................................................................................................... 232 ЦЕНТРАЛИЗОВАННОЕ УПРАВЛЕНИЕ НА БАЗЕ КАТАЛОГА ............................................................. 232 Преимущество NDS ........................................................................................................... 232 УПРАВЛЕНИЕ ЧЕРЕЗ ОБЪЕКТЫ «ПОДРАЗДЕЛЕНИЕ» - ORGANIZATIONAL UNITS (OU) .................. 232 Преимущество NDS ........................................................................................................... 233 НЕОГРАНИЧЕННЫЕ ВОЗМОЖНОСТИ РЕОРГАНИЗАЦИИ ДЕРЕВА КАТАЛОГА .................................. 233 Преимущество NDS ........................................................................................................... 233 ГЛОБАЛЬНОЕ ХРАНИЛИЩЕ УПРАВЛЕНЧЕСКОЙ ИНФОРМАЦИИ .................................................... 234 Преимущество NDS ........................................................................................................... 234 БЕЗОПАСНОСТЬ ................................................................................................................... 235 ИНТЕГРИРОВАННЫЕ СЛУЖБЫ АУТЕНТИФИКАЦИИ И АВТОРИЗАЦИИ ........................................... 235 Преимущество NDS ........................................................................................................... 235 ПРОЗРАЧНОЕ УПРАВЛЕНИЕ СПИСКОМ КОНТРОЛЯ ЗА ДОСТУПОМ ................................................ 235 Преимущество NDS ........................................................................................................... 236 ДИНАМИЧЕСКОЕ НАСЛЕДОВАНИЕ ПРАВ ...................................................................................... 236 Преимущество NDS ........................................................................................................... 236 СТРУКТУРИРОВАННОЕ ДЕЛЕГИРОВАНИЕ АДМИНИСТРАТИВНЫХ ПРАВ ....................................... 237 Преимущество NDS ........................................................................................................... 238 ПРИЛОЖЕНИЯ ....................................................................................................................... 239 ВОЗМОЖНОСТИ РАСШИРЕНИЯ РАСПРЕДЕЛЕННОЙ СХЕМЫ .......................................................... 239 Преимущество NDS ........................................................................................................... 239 ПОДДЕРЖКА ACTIVE DIRECTORY SERVICES INTERFACE (ADSI) ................................................. 240 Преимущество NDS ........................................................................................................... 240 ПОДДЕРЖКА СТАНДАРТНЫХ «ДОПОЛНИТЕЛЬНЫХ» ФУНКЦИЙ LDAP V3 ................................... 240 Преимущество NDS ........................................................................................................... 240 ИНТЕРФЕЙСЫ СЛУЖБЫ КАТАЛОГА, ОСНОВАННЫЕ НА СТАНДАРТАХ (ДЛЯ РАЗРАБОТЧИКОВ) ..... 241 Преимущество NDS ........................................................................................................... 241 ЗАКЛЮЧЕНИЕ ............................................................................................................................... 242 ITIL, ПРОЦЕССЫ, ПРОЕКТЫ, И ПСИХОАНАЛИЗ. .................................................... 244 ITIL - БИБЛИОТЕКА ИНФРАСТРУКТУРЫ ИТ ................................................................................ 245 РАЗВИТИЕ ITIL ............................................................................................................................ 246 УПРАВЛЕНИЕ В МАЛЫХ ИТ-ПОДРАЗДЕЛЕНИЯХ. ......................................................................... 248 ПРОЦЕССЫ. ОПРЕДЕЛЕНИЯ. ........................................................................................................ 255 SLA В ПРАКТИЧЕСКИХ ПРИМЕРАХ. ............................................................................................. 259 Определение ITIL. ............................................................................................................... 259 Открытый стандарт. ...................................................................................................... 260 Основные принципы библиотеки. ..................................................................................... 260 Область действия Библиотеки. ....................................................................................... 261 Книги Библиотеки. ............................................................................................................. 261 Философия ITIL .................................................................................................................. 265 Сертификация. ................................................................................................................... 266 Кому следует читать ITIL. ............................................................................................... 267 Выгоды от применения методологии ITIL. ..................................................................... 268 Часто Задаваемые Вопросы. ............................................................................................ 269 СПИСОК ЛИТЕРАТУРЫ ..................................................................................................... 271 Введение Планирование и решение вопросов управления всеми уровнями ITинфраструктуры призвано оказать помощь руководителям ИТ-подразделений в сфере внедрения элементов административного управления информационными технологиями на предприятии на основе структурного подхода. Введение включает следующие разделы: Элементы управления ИТ. В этом разделе описаны различные типы элементов управления ИТ, способы их взаимодействия и значение этих компонентов для соблюдения организацией нормативных требований. Процедура аудита ИТ. В этом разделе приводятся общие сведения о процедуре, используемой аудиторами в большинстве организаций для оценки степени соответствия нормативным требованиям. Бизнес-факторы. В этом разделе рассматриваются бизнес-факторы, имеющие непосредственное отношение к вопросам соответствия нормативным требованиям. В их числе проблемы сложной нормативноправовой среды, достижения и поддержания соответствия законодательным предписаниям, а также последствий их несоблюдения. Кроме того, здесь затрагиваются вопросы, касающиеся создания и совершенствования бизнес-процесса, получения конкурентных преимуществ, а также повышения уровня окупаемости инвестиций благодаря экономии времени и снижению затрат. Участники процесса административного управления ИТ это, в первую очередь, руководители ИТ-подразделений, которые несут ответственность за функционирование элементов ИТ-инфраструктуры, обеспечивающих соблюдение конфиденциальности, безопасности и надежности в соответствии с различными нормативными предписаниями. Целевая аудитория процесса административного управления включает руководителей ИТ-подразделений, которые занимают в своих организациях следующие должности: директора по информационным технологиям, обязанности которых включают развертывание и эксплуатацию ИТ-систем и ИТ-процессов; директора по информационной безопасности, ответственные за реализацию общих программ обеспечения безопасности данных и соблюдения политик информационной безопасности; финансовые директора, на которых возложены общие контрольные функции: директора по вопросам конфиденциальности, занимающиеся реализацией политик, связанных с управлением личными данными, включая политики соблюдения законов об охране конфиденциальности и защите данных; 13 должностные лица, принимающие технические решения, которые определяют технологические решения конкретных проблем ведения бизнеса; руководители по эксплуатации ИТ-инфраструктуры, отвечающие за функционирование систем и процессов, выполняющих программы соблюдения нормативных требований; разработчики архитектуры информационной безопасности, которые проектируют системы ИТ-контроля и безопасности для обеспечения уровней безопасности, соответствующих потребностям организаций; разработчики архитектуры ИТ-инфраструктур, которые проектируют инфраструктуры, способные поддерживать созданные разработчиками архитектуры информационной безопасности системы; консультанты и партнеры, занимающиеся внедрением рекомендаций по обеспечению конфиденциальности и безопасности в интересах соблюдения их клиентами нормативных требований. Кроме того, в процесс должны быть вовлечены: должностные лица, ответственные за управление рисками в масштабе организации при обеспечении соответствия нормативным актам и стандартам; руководители аудиторских групп по ИТ, занимающиеся организацией аудита ИТ-систем и снижением рабочей нагрузки на внутренних и внешних аудиторов ИТ. 14 Элементы управления ИТ Элемент управления можно определить как «устройство или механизм, с помощью которого регулируют или направляют работу машины, аппарата или системы». Организации используют элементы управления, чтобы регулировать бизнеспроцессы, включая производство, распространение, финансирование и т. д. Элементы управления позволяют организациям пресекать и исправлять нетипичное поведение, а также предотвращать либо ограничивать распространение недостатков и ошибок. Многие нормативные акты ставят перед собой цель гарантировать наличие в организациях надлежащих элементов управления. Например, HIPAA предписывает внедрение надлежащих элементов управления информационной безопасностью и конфиденциальностью для защиты данных пациентов медицинских учреждений. А SOX обязывает открытые акционерные компании в США применять элементы управления, чтобы обеспечить точность финансовой отчетности.Организации внедряют элементы управления для того, чтобы: снизить риск мошенничества; обеспечить защиту активов компании; предотвратить утечку коммерческих секретов; обеспечить соблюдение нормативных требований; повысить уровень осведомленности о состоянии бизнеса; повысить эффективность ведения бизнеса. В самом общем смысле элементы управления можно разделить на элементы управления коммерческой деятельностью и элементы управления информационными технологиями. Элементы управления обеих категорий предназначены для противодействия рискам, которым подвергается компания. Однако они различаются по способам внедрения и применения. Элементы управления коммерческой деятельностью регулируют и направляют бизнес-процессы в организации. Например, требование утверждения руководством заказов на закупки является элементом управления, предназначенным для предотвращения необоснованного расходования средств. Элементы управления коммерческой деятельностью создаются практически для всех процессов в организации — от найма сотрудников и закупок до сбыта и финансовой отчетности. Элементы управления ИТ регулируют и направляют использование в организации всех ИТ-процессов и систем. Они ориентированы на процессы, находящиеся в ведении руководителей ИТ-подразделений, включая доступность ИТресурсов, управление изменениями, создание учетных записей пользователей, вопросы безопасности и т. д. Именно об этих элементах управления пойдет речь в настоящем руководстве. 15 Общие элементы управления и элементы управления приложений Существует две категории элементов управления ИТ: общие элементы управления и элементы управления приложений. Общие элементы управления Общие элементы управления имеют отношение ко всей ИТ-инфраструктуре. Организации должны внедрить приемлемые общие элементы управления, прежде чем начать использовать элементы управления приложений. Например, если отсутствует уверенность в общей системе безопасности сервера баз данных, на котором хранятся данные системы планирования корпоративных ресурсов (ERP), можно ли доверять данным в ERP-системе, сколько бы внутренних проверок данных ни проводила сама ERP-система? Если злоумышленник может обойти элементы управления приложения из-за слабых мест в общих элементах управления, вся сеть организации оказывается под угрозой. Общие элементы управления ориентированы на многие зоны ответственности руководителей ИТ-подразделений, включая: организацию ИТ; создание политик и информирование о них; безопасность системы; эксплуатацию системы; управление изменениями; принятие необходимых мер в условиях чрезвычайных ситуаций; мониторинг; производительность Элементы управления приложений Элементы управления приложений уникальны для каждого приложения, используемого организацией для ведения бизнес-деятельности. В этом смысле элементы управления приложений являются компонентами ИТ, ответственными за применение элементов управления коммерческой деятельностью. Элементы управления приложений предназначены для уменьшения числа и степени тяжести ошибок и предотвращения или выявления злонамеренных действий, таких как мошенничество. Поскольку элементы управления приложений столь тесно связаны с бизнес-процессами, которые поддерживаются соответствующими приложениями, их часто рассматривают в качестве элементов управления коммерческой деятельностью, реализованных средствами информационных технологий. Элементы управления приложений позволяют выполнять следующие процедуры и решать следующие задачи. 16 Процедуры подготовки данных. Такие процедуры позволяют снизить риск ошибок и упущений. Например, процедуры обработки ошибок во время подготовки данных позволяют выявлять, регистрировать и исправлять специфические для этой группы данных ошибки. Проверки точности, полноты и авторизации. Такие процедуры позволяют обеспечить управление изменениями и проверку входящих данных настолько близко к месту их возникновения, насколько это возможно. Обработка данных транзакций управляется процедурными элементами, ответственными за эти проверки. Целостность обработки данных. Это позволяет обеспечить разделение обязанностей и проверку выполненной работы. В качестве примеров можно привести элементы управления для проверки итоговых значений и элементы управления обновлением главных файлов. Распространение выходных результатов. Элементы управления приложений позволяют обеспечить поддержание единообразия и выполнение политики управления. В качестве примеров можно привести элементы управления, которые определяют политику распространения выходных результатов ИТ-процессов, информируют о ней и обеспечивают ее соблюдение. Защита передачи важных данных. Процедуры для этих элементов управления позволяют обеспечивать реализацию надлежащих защитных мер для предотвращения несанкционированного доступа к важным данным и злонамеренных манипуляций с ними во время передачи. На рисунке ниже показаны отношения между различными типами элементов управления. Рис. 1. Типы элементов управления Дальнейшая классификация элементов управления ИТ Существуют два метода дальнейшей классификации элементов управления ИТ. Во-первых, их можно разделить на ручные и автоматизированные. Для ручных элементов управления требуется участие оператора, тогда как функционирование 17 автоматизированных элементов управления обеспечивается ИТ-системой. Во-вторых, их можно разделить на профилактические и сигнальные. Как ясно из названия, профилактические элементы управления ИТ служат для предотвращения нежелательных событий. Сигнальные элементы управления ИТ не предотвращают нежелательное событие, но могут его выявить и уведомить оператора или систему о необходимости реакции на него. Таким образом, можно выделить четыре типа элементов управления ИТ. Они представлены на рисунке ниже. Рис. 2. Четыре типа элементов управления ИТ Хорошим примером различных типов элементов управления ИТ и способов их функционирования является политика уровней сложности паролей. Предположим, в организации действует обусловленное нормативным актом или внутренней политикой безопасности требование, чтобы пароли имели длину не менее восьми знаков. Перечисленные ниже примеры элементов управления ИТ обеспечивают различные способы соблюдения этого требования. Ручной сигнальный. Использование элемента управления такого типа предполагает, что в организации действует сотрудник, самостоятельно устанавливающий факт нежелательного события. В этом случае организация использует ручной сигнальный элемент управления, при котором администратору придется еженедельно запускать составление отчета, чтобы обнаружить пароли короче восьми знаков. При обнаружении слишком короткого пароля администратор может принять меры, например, блокировать учетную запись или направить жалобу руководителю провинившегося пользователя. Ручные сигнальные элементы управления в целом неэффективны, поскольку требуют вмешательства оператора как для обнаружения, так и для решения проблемы. По этой причине использование таких элементов должно рассматриваться лишь в крайнем случае, когда элементы других типов недоступны. Ручной профилактический. Иногда для решения поставленной задачи бывает достаточно ручного профилактического элемента управления. В этом случае организации потребуется озвучить политику применения паролей, предписывающую всем служащим пользоваться сложными паролями, не короче восьми знаков, для доступа к корпоративной сети. Предназначение этого элемента управления — предотвращение использования коротких паролей, но для этого необходимо неукоснительное соблюдение персоналом данного требования. Автоматизированный сигнальный. Элементы управления этого типа позволяют системе автоматически выявлять нежелательные события и уведомлять соответствующих сотрудников о необходимости устранения последствий. Например, 18 автоматизированный сигнальный элемент управления может быть реализован в виде автоматизированного процесса, который выполняет поиск слишком коротких паролей и уведомляет администратора об их обнаружении. Как и в случае с ручным сигнальным элементом, при обнаружении нарушения администратор должен принять соответствующие меры. Автоматизированный профилактический. Внедрение элементов такого типа является предпочтительным, поскольку устраняется человеческий фактор в виде несоблюдения установленных требований. В этом случае организация может воспользоваться функциональными возможностями операционной системы, которая запретит пользователям задавать короткие пароли. Такой элемент управления соответствует требованиям политики паролей, а пользователям существенно труднее его игнорировать либо обойти. Следует отметить, что автоматизированные элементы управления в целом считаются более эффективными, нежели ручные, поскольку исключают участие человека. Кроме того, всегда предпочтительнее предотвращать проблемы, чем выявлять и реагировать на них. Поэтому автоматизированным профилактическим элементам управления отдается предпочтение перед тремя другими типами. Интегрированные элементы управления Одного элемента управления порой недостаточно, чтобы удовлетворить потребности компании, и может возникнуть необходимость в нескольких элементах. Если для решения конкретной задачи управления происходит объединение ряда элементов, они становятся интегрированными элементами управления. Организации часто прибегают к использованию интегрированных элементов управления, если им приходится полагаться на ручные элементы или сталкиваться с крупномасштабными рисками. Например, если провозглашенная политика паролей или ручной профилактический элемент управления, является единственным способом добиться соблюдения требований к длине пароля, полезно также внедрить ручной или автоматизированный профилактический элемент управления для осуществления контроля. Интегрированные элементы управления также полезны, если организация сталкивается со значительным риском. Например, выполнение ответственных бизнес-функций, используя устаревшую операционную систему, считается серьезной угрозой безопасности. Однако, если нет другого выхода, следует внедрить другие элементы управления для компенсации риска. В данном случае можно запретить уязвимой системе подключаться к корпоративной сети. Кроме того, можно исключить использование в системе съемных носителей, чтобы снизить опасность заражения вредоносными программами. Любого из этих элементов управления было бы недостаточно для решения проблемы, однако их сочетание может дать нужный эффект. 19 Важность элементов управления ИТ Важная роль элементов управления ИТ состоит в том, что они обеспечивают эффективные средства, позволяющие совместить как решение бизнес-задач компании, так и задачи соответствия нормативным требованиям. Руководители ИТ-подразделений могут внедрять элементы управления с целью создания надежных процессов для тестирования и совершенствования среды управления ИТ в организации. Эффективные элементы управления ИТ также предоставляют организации возможность лучше адаптироваться к меняющимся нормативным требованиям. Важно также отметить то, что аудиторы предпочитают оценивать автоматизированные элементы управления ИТ, поскольку такая оценка выполняется быстрее и позволяет более точно определить качество мер, принятых в организации для обеспечения соответствия нормативным требованиям. Благодаря этому снижаются затраты времени и финансовых средств, уменьшается вероятность сбоев при проведении аудитов ИТ. И это в дополнение к тому, что автоматизированные элементы в долгосрочной перспективе дешевле ручных. Следующий раздел посвящен методам выполнения аудита ИТ. Процедура аудита ИТ Аудиты являются ключевым компонентом процесса обеспечения соответствия нормативным требованиям. В большинстве случаев именно аудиторы определяют, соблюдает ли организация распространяющиеся на нее нормативные акты и стандарты. Например, внешние аудиторы часто определяют достаточность внутренних элементов управления в рамках аудита ежегодной финансовой отчетности во исполнение закона Сарбейнса-Оксли. Знание процедуры проверки и методов работы аудиторов позволяет руководителям ИТ-подразделений создать среду, которая соответствует требованиям и не представляет трудностей для проведения аудита. Этот раздел посвящен методам выполнения аудита ИТ. Важно понять, на что именно аудиторы обращают внимание, проверяя уровень соответствия нормативным требованиям. Они ищут свидетельства того, что: организация разработала эффективные элементы управления для обеспечения соответствия требованиям, и в проекте нет упущений; организация последовательно использует такие элементы управления, и в эксплуатации системы нет упущений. Если аудиторы не обнаружат наличия эффективной программы управления либо установят, что организация не придерживается этой программы, они отметят это в своем отчете. В большинстве случаев такой отчет представляется комитету по аудиту, чтобы выявленные недостатки получили должное внимание со стороны руководства организации. Как очевидно, предпочтительнее, чтобы в отчете не было отмечено недоработок. Ниже дано общее описание процедуры аудита. На практике может использоваться несколько иной подход. Этап 1. Планирование аудита (аудитор). Этап 2. Проведение совещания перед началом аудита (аудитор/организация). Этап 3. Сбор данных и тестирование элементов управления ИТ (аудитор/организация). Этап 4. Исправление выявленных неполадок (организация). Этап 5. Тестирование исправленных элементов управления (аудитор/организация). Этап 6. Проведение анализа и составление отчета по результатам аудита (аудитор). Этап 7. Реакция на результаты аудита (организация). Этап 8. Представление заключительного отчета (аудитор). Понимание этапов проведения аудита дает руководителям ИТ-подразделений возможность прогнозировать, что им следует ожидать от проверки. Благодаря этому можно более успешно решить задачу соответствия нормативным требованиям и оптимизировать процедуру аудита. Этап 1. Планирование аудита Для планирования проверки аудитору необходимо получить от организации список всех используемых элементов управления ИТ и документацию с описанием принципов работы каждого элемента. Такая документация должна содержать информацию о том, каким образом элементы управления снижают риски организации и обеспечивают соответствие нормативным требованиям. Аудитор таким образом устанавливает проектную эффективность элементов управления ИТ в организации. Как правило, аудиторская группа определяет, на каких элементах управления ИТ будет сосредоточено основное внимание. Рамки проверки зависят от типа проводимого аудита. При аудите соблюдения SOX, например, проверке подвергнутся основные финансовые счета и ключевые поддерживающие эту сферу приложения. На этапе планирования аудиторы также определяют области, требующие особого внимания. Соответствующее решение может основываться на слабых местах, выявленных в ходе предыдущего аудита, указаниях контрольных органов или оценках рисков предпринимательской деятельности в период проверки. Полезно заранее знать рамки аудита, чтобы наилучшим образом к нему подготовиться. Этап 2. Проведение совещания перед началом аудита Перед началом проверки аудитор и представители организации проводят совещание с целью утверждения плана аудита. Аудитор также использует эту возможность для того, чтобы определить ресурсы организации, необходимые для обеспечения проверки. Этап 3. Сбор данных и тестирование элементов управления ИТ В ходе следующего этапа аудиторы проводят тестирование, чтобы убедиться в наличии описанных в документации элементов управления и их надлежащем функционировании. Количество тестов и их специфика зависят от типа элементов и важности системы, которой они управляют. Например, администратор ИТ может продемонстрировать проверяющему, как пользователи заполняют и подают форму для получения доступа в систему. Аудитор проверяет, соответствуют ли запрашиваемые у пользователя данные нормативным и эксплуатационным требованиям. Что касается связанных с этим процессом ручных элементов управления, то аудитор определяет правильность и полноту документации о политике организации по той же методике. Аудитор также проверяет, получены ли надлежащие разрешения. Этап 4. Исправление выявленных недостатков По результатам тестирования проверяющие информируют организацию о выявленных недостатках. В некоторых случаях организация может относительно быстро их устранить. Аудиторы также могут предоставить определенное время для исправления недочетов. Этап 5. Тестирование исправленных элементов управления Затем аудиторы выполняют тестирование исправленных элементов управления ИТ. Проверяющий может признать либо не признать, что недостатки устранены должным образом. Если аудитор решит, что неполадки исправлены надлежащим образом, он не упомянет их в своем окончательном отчете. Этап 6. Проведение анализа и составление отчета по результатам аудита По завершении тестирования аудиторы составляют отчет о результатах проверки. В нем подробно описываются все упущения, обнаруженные в ходе аудита. Они могут относиться к одной из следующих категорий. Недостатки проектирования. Это случаи, когда проверяющий обнаруживает полное или частичное отсутствие элементов управления, необходимых для решения определенной задачи, либо устанавливает, что имеющиеся элементы не могут надлежащим образом выполнять свое предназначение. Примером недостатков проектирования может быть ситуация, при которой организация имеет дело с конфиденциальными данными о пользователях, такими как имя, адрес, номер паспорта, но не может представить информацию о соответствующих элементах управления и способах защиты этих данных. Недостатки эксплуатации. Проверяющий может обнаружить, что организация не использует элементы управления, предусмотренные проектом. Такая ситуация возникает, если на элемент управления составлена документация, но сам он так и не был внедрен в производственный процесс. Или же элемент был внедрен на практике, но не используется. Например, элемент управления предусматривает, что предоставление пользователям доступа к определенному важному ресурсу происходит только после утверждения соответствующего запроса вице-президентом или другим руководителем высшего звена. Если аудиторы установят, что такой доступ обычно предоставляется без надлежащего утверждения, это будет рассматриваться в качестве недостатка эксплуатации. Аудитор составляет для организации сводный отчет о недостатках управления, в котором описывается масштаб и количество недоработок, требующих устранения. Этап 7. Реакция на результаты аудита Обычно организации предоставляется возможность ответить на высказанные аудиторами претензии, в частности, либо указать обстоятельства, способные смягчить жесткость выводов, либо изложить планы устранения выявленных недостатков. Как правило, организации попытаются исправить обнаруженные недостатки в период до проведения следующего аудита. Этап 8. Представление окончательного отчета На заключительном этапе процедуры проверки аудитор представляет свой окончательный отчет. Этот отчет передается руководству ИТ-подразделения, а также группе финансового аудита (если таковая имеется) для включения в общий отчет об аудите. Кроме того, отчет может быть представлен совету директоров и соответствующей третьей стороне, например контрольным органам. Способы оптимизации процедуры аудита Существует немало способов сделать процедуру аудита более эффективной и менее обременительной. К числу этих способов относятся следующие. Сотрудничество с аудиторами с самого начала процедуры проверки. Это позволит установить ключевые области, на которых проверяющие планируют сосредоточить основное внимание. В некоторых случаях целесообразно пересмотреть приоритетные ИТ-проекты, чтобы принять меры к устранению факторов, рассматриваемых аудиторами в качестве основных рисков в производственной среде, и, таким образом, избежать упоминания недостатков по итогам аудита. Внедрение автоматизированных элементов управления везде, где это возможно. Они предпочтительнее ручных элементов, поскольку легче поддаются тестированию и проверке. Наилучшим способом оптимизации процедуры аудита ИТ и снижения затрат на его проведение является: ведение ясной и краткой документации на элементы управления ИТ и своевременное ее обновление; организация элементов управления ИТ таким образом, чтобы они были совместимы с системой, используемой аудиторами. Это обеспечит четкое взаимопонимание относительно показателей соответствия нормативным требованиям; использование преимуществ системы элементов управления ИТ, описанной в разделе 2 («Системное обеспечение соблюдения нормативных требований») настоящего руководства. Это позволит более эффективно обеспечить соответствие целому ряду нормативных актов с помощью единого набора элементов управления. Система управления может предоставить возможности для планирования с целью обеспечения эффективного управления ИТ в организации. Система связывает потребности ведения коммерческой деятельности с мероприятиями в сфере ИТ посредством последовательной модели. С помощью этой модели можно выявить ресурсы ИТ, необходимые для определения и решения задач по внедрению в организации элементов управления ИТ. Бизнес-факторы Многие компании рассматривают задачу соответствия нормативным требованиям как чрезвычайно сложную и не приносящую никакой пользы. Такой подход представляется недальновидным. Действительно, обеспечение соответствия нормативным требованиям связано с решением непростых задач, однако это предоставляет и новые возможности. В данном разделе рассматриваются трудности и благоприятные возможности для ведения коммерческой деятельности, связанные с задачей соответствия нормативным требованиям. Сложные задачи бизнеса Соответствие нормативным требованиям связано с необходимостью решения целого ряда проблем. В их числе ведение дел в сложной нормативно-правовой среде, преодоление трудностей при достижении и поддержании соответствия нормативным предписаниям, а также понимание последствий их несоблюдения. Сложность нормативно-правовой среды По мере роста количества и расширения сферы действия нормативных актов происходит последовательное усложнение нормативно-правовой среды. Это возлагает на организации и их руководителей дополнительную ответственность за исполнение растущего числа предписаний и предоставление убедительных свидетельств их соблюдения. Различаются и специфические требования разных нормативных актов, равно как и объем необходимых работ, обусловленных каждым предписанием. Определение оптимальной стратегии в этой сфере для той или иной организации предполагает тщательный анализ каждого нормативного акта. Организации обязаны приложить усилия, чтобы разобраться, каким образом нормативные акты затрагивают их деятельность, а также проявить практичность при внедрении элементов управления и бизнес-процедур с целью убедительной демонстрации соответствия нормативным требованиям. Достижение и поддержание соответствия нормативным требованиям Многие организации убедились, что достижение и последующее поддержание соответствия требованиям нормативных актов связано с известными трудностями. В частности, многие компании обнаруживают, что меры по обеспечению соответствия сложнее, требуют больше времени и финансовых затрат, чем предполагалось ранее. Эти трудности зачастую вызваны попытками добиться одновременного соответствия требованиям многочисленных разнообразных нормативных актов, даже если эти предписания затрагивают независимые друг от друга подразделения организации. После того, как компания осуществит первоначальное обеспечение соответствия нормативным требованиям, на первый план выдвигается не менее сложная задача поддержания этого соответствия с наименьшими затратами. Границы ответственности за постоянное выполнение этой работы часто остаются размытыми. Нечеткое определение сфер ответственности ограничивает способность организации к целостному восприятию задачи соответствия нормативным требованиям и может повысить риск дублирования усилий. Последствия несоблюдения требований Для многих компаний соблюдение соответствия нормативным требованиям мотивировано стремлением избежать юридических последствий обратного. Помимо финансовых, гражданско-правовых санкций и уголовного наказания эти последствия могут включать ущерб репутации организации на рынке и утрату доступа к ресурсам, необходимым для успешного ведения дел. Конкретная ситуация зависит от соответствующего нормативного акта, но в большинстве случаев несоблюдение предписаний может привести к: ощутимым штрафам (налагаются на частных лиц и на организации); лишению свободы за тяжкие нарушения; подаче судебных исков акционерами и другими заинтересованными сторонами; ограничению доступа на фондовые рынки; ограничению возможностей для ведения дел в районах действия определенных нормативных актов; усилению надзора со стороны контрольных органов; ущербу репутации компании; утрате доверия со стороны клиентов и деловых партнеров. Угроза этих последствий обеспечивает достаточную мотивацию, чтобы организации и их руководители серьезно относились к необходимости эффективных упреждающих мер по соответствию нормативным требованиям. Деловые возможности Соответствие нормативным требованиям связано не только с решением сложных задач, но и с дополнительными возможностями, которые открываются для организаций. К ним относятся возможности совершенствования бизнес-процессов, получения конкурентных преимуществ и дальнейшей интеграции ИТ в коммерческую деятельность с целью повышения окупаемости инвестиций. Совершенствование процессов Большинство нормативных актов предписывает организациям внедрение документированных и воспроизводимых процессов, снабженных надлежащими элементами управления для предотвращения ошибок и мошенничества. Автоматизированные процессы, как правило, располагают более эффективными элементами управления, нежели ручные, и аудиторы в целом больше полагаются на автоматизированные, а не на ручные процессы. Именно поэтому многие организации могут использовать необходимость соответствия нормативным требованиям для обоснования автоматизации неэффективных ручных процессов. Ключевым основанием для внедрения автоматизации процессов служит необходимость совершенствования элементов управления ИТ и способности к воспроизведению, однако дополнительное преимущество состоит в повышении эффективности процессов. Хорошим примером повышения эффективности благодаря усовершенствованному процессу является управление учетными данными. Многие аудиторы обращают внимание на отсутствие элементов управления ИТ, связанных с процедурой управления жизненным циклом учетных данных пользователей, включая создание, изменение и удаление учетных записей и профилей. Для устранения этой недоработки компании внедряют автоматизированные средства управления учетными данными. Главная цель таких средств — автоматизация элементов управления ИТ, имеющих отношение к ответственным бизнес-процессам, однако их внедрение также повышает эффективность управления учетными данными пользователей. Конкурентные преимущества Тщательное и своевременное соблюдение требований нормативных актов может предоставить компаниям конкурентные преимущества. Организации, предоставляющие услуги другим компаниям, могут получить преимущества благодаря своевременным и подтверждаемым мерам по соответствию предписаниям. Причина этого состоит в том, что организации легче пойдут на сотрудничество с компаниями, которые соответствуют нормативным требованиям, рассчитывая получить от них помощь в решении собственных задач, связанных с соответствием. Например, ощутимую пользу от этого преимущества могут получить фирмы, оказывающие ИТуслуги на условиях внешнего подряда, бюро обслуживания и компании, занимающиеся управлением медицинским страхованием. Соблюдение конфиденциальности информации является сегодня еще одним поводом беспокойства для компаний и частных лиц. Неуклонное соответствие нормативным требованиям по охране конфиденциальности также дает организациям конкурентные преимущества. Организации могут превратить соответствие требованиям нормативных актов о конфиденциальности в инструмент маркетинга, укрепления доверия и расширения клиентской базы, а также снизить уровень общей обеспокоенности по поводу нарушений конфиденциальности и хищений учетных данных. Поскольку соблюдение директивы ЕС о защите данных (EUDPD) является непременным условием для ведения дел в некоторых европейских странах, выполнение этого требования может открыть новые рынки для продуктов и услуг компании. Интеграция ИТ и окупаемость инвестиций Необходимость соответствия нормативным требованиям может помочь руководителям ИТ-подразделений добиться более тесной интеграции ИТ в деятельность организации. Нормативные акты по большей части не содержат прямых предписаний о внедрении элементов управления на основе ИТ, однако зачастую именно руководству ИТ-подразделений в конечном итоге приходится заниматься внедрением элементов управления ИТ, настоятельно рекомендуемых этими актами. Это повышает потребность в тесном сотрудничестве руководителей коммерческих и ИТподразделений для решения непростой задачи по обеспечению соответствия нормативным требованиям. Опираясь на растущее доверие со стороны руководства, руководители ИТподразделений могут продвигать другие инициативы по развитию ИТ, направленные на повышение эффективности и снижение затрат в рамках всей компании. Они, в частности, могут настаивать на приоритетности работ по разработке, обслуживанию и резервному копированию защищенных приложений. Структурный подход к задаче соответствия нормативным требованиям Этот раздел Руководства по планированию и решению задач соответствия нормативным требованиям знакомит со структурным подходом в достижении соответствия. В нем рассматриваются базовые элементы контрольной структуры и преимущества, которые такой подход предоставляет организациям, намеренным добиться соответствия контрольным показателям в сфере ИТ. Далее описан процесс, использовавшийся рабочей группой для создания примера контрольной структуры, в которой сопоставлены, с одной стороны, не содержащие жестких предписаний нормативные акты и стандарты, а с другой, конкретные технологии. Это сопоставление поможет добиться одновременного соответствия нескольким нормативным требованиям. Использование такой структуры позволит также избежать дублирования в работе по достижению контрольных показателей в сфере ИТ. Раздел включает следующие темы. Основы структуры. В рамках этой темы рассматриваются основы структурного подхода к соответствию нормативным требованиям; Преимущества использования структурного подхода для организации. Объясняются преимущества структурного подхода в решении задач соответствия предписаниям; Структура для конкретной организации. Эта тема знакомит с примером контрольной структуры управления и ресурсами, которыми пользовалась рабочая группа проекта для ее разработки. Основы структуры По мере роста числа нормативных актов и стандартов, оказывающих влияние на информационные технологии, многим организациям приходится решать непростую задачу выбора приоритетов в обеспечении соответствия требованиям многочисленных правил и предписаний. Например, деятельность зарегистрированной в США открытой акционерной компании, оказывающей финансовые услуги, должна соответствовать нескольким нормативным актам, в том числе законам Грэмма-ЛичаБлайли (GLBA) и Сарбейнса-Оксли (SOX), а также различным правилам Комиссии по ценным бумагам и биржам США. Компания, ставящая перед собой задачу добиться соответствия предписаниям нескольких нормативных актов, может пойти следующим путем: Проанализировать каждый нормативный акт. Определить потребности в элементах управления ИТ, обусловленных каждым нормативным актом. Внедрить надлежащие элементы управления. Провести аудит для определения степени соответствия нормативным требованиям. К сожалению, эти действия неэффективны, поскольку компании придется повторять их в полном объеме в связи с каждым нормативным актом. Неэффективность этой процедуры демонстрируется на приведенном ниже рисунке. Рис. 3. Неэффективные меры по обеспечению соответствия нормативным актам вне структуры Разработка единых элементов управления информационными технологиями В настоящем руководстве рекомендован иной подход к решению задачи соответствия нормативным требованиям. Вместо рассмотрения каждого нормативного акта по отдельности предложена методика одновременного анализа всех упомянутых в данном руководстве важнейших нормативных актов и стандартов, в соответствии с которыми необходимо разработать элементы управления ИТ. Многие нормативные акты и стандарты, которым должны соответствовать организации, предполагают совпадающие элементы управления. Для повышения эффективности часто целесообразно внедрить единый элемент управления, который бы обеспечил соблюдение требований сразу нескольких нормативных актов и стандартов. Например, такие нормативные акты, как HIPAA, GLBA, SOX и законы, основанные на EUDPD, требуют процедур, которые обеспечили бы контроль над действиями по запросу, созданию, предоставлению, приостановке и упразднению учетных записей пользователей. Создание единого набора элементов управления жизненным циклом учетных записей пользователей удовлетворит требования сразу всех этих нормативных актов и повысит эффективность принимаемых организацией мер. На приведенном ниже рисунке показана методика одновременного использования элементов управления информационными технологиями для обеспечения соблюдения сразу нескольких основных нормативных актов и стандартов. Рис. 4. Элементы управления ИТ одновременно обеспечивают соблюдение нескольких нормативных актов и стандартов Далее речь пойдет о том, каким образом хорошо продуманная структура соответствия нормативным требованиям поможет организациям получить дополнительные преимущества. Преимущества структурного подхода для организации Структурный подход предоставляет организациям немало существенных преимуществ в решении задачи достижения контрольных показателей соответствия нормативным требованиям. Он позволяет: интегрировать элементы управления ИТ для обеспечения соответствия нескольким нормативным актам и стандартам, таким как SOX и HIPAA, во избежание проведения отдельных аудитов; обеспечить скорейшее соответствие новым нормативным актам по мере их вступления в силу; обеспечить приоритетное финансирование только тех элементов управления ИТ, которые приносят наибольший эффект; избегать дублирования работ с целью соответствия предписаниям в различных подразделениях компании; более эффективно осуществлять обновления в отношении предписаний путем постепенного внесения изменений в имеющиеся в организации элементы управления ИТ; наладить взаимопонимание между ИТ-подразделением и аудиторами. На приведенном ниже рисунке показано, как использование контрольной структуры управления упрощает достижение соответствия нормативным требованиям. Рис. 5. Концептуальная модель контрольной структуры управления В заключительной части данного раздела рассматриваются способы использования контрольной структуры управления для получения организацией всех упомянутых преимуществ, обусловленных необходимостью соответствия нормативным требованиям. Структура для конкретной организации Рекомендуется организациям использовать модель контрольной структуры управления с целью эффективного достижения показателей соответствия нормативным требованиям. Использование такой модели позволит внести в контрольную структуру значимые нормативные акты и стандарты. Затем организация сможет более эффективно сосредоточить усилия на внедрении элементов управления ИТ по заданным в структуре требованиям, а не в соответствии с отдельными предписаниями. Кроме того, с вводом в действие новых нормативных актов и стандартов, затрагивающих организацию, их можно сопоставлять со структурой и затем сосредоточивать усилия на тех ее элементах, в которых изменились требования. Более того, в контрольной структуре можно задать значительное число разнообразных требований, связанных с элементами управления ИТ, таких как требования к безопасности индустрии платежных карт, внутренние политики и т. д. Рекомендуется использовать контрольную структуру элементов управления ИТ с целью упорядочения мер по обеспечению соответствия нормативным требованиям. Существует несколько базовых платформ, которые можно положить в основу такой структуры. К ним относятся: контрольные показатели для информационных и связанных с ними технологий, издание 4-е (COBIT 4.0) Института управления ИТ (ITGI); стандарт ISO 17799: практические правила управления информационной безопасностью 2005 года (ISO 17799); библиотека по ИТ-инфраструктурам (ITIL) управления государственной коммерческой деятельности министерства финансов Великобритании; Microsoft Operations Framework (MOF) концепция трастовых услуг Американского института дипломированных бухгалтеров-ревизоров и Канадского института дипломированных бухгалтеров (AICPA/CICA); концепция конфиденциальности Американского института дипломированных бухгалтеров-ревизоров и Канадского института дипломированных бухгалтеров (AICPA/CICA); Сопоставление нормативных актов с технологическими решениями Этот раздел посвящен сопоставлению нормативных актов с технологическими решениями. В нем представлен разработанный рабочей группой процесс преобразования не содержащих жестких предписаний нормативных актов в конкретные технологии, которые могут быть полезны для достижения соответствия нормативным требованиями в области гарантий конфиденциальности. В разделе приводятся две таблицы сопоставления элементов управления ИТ. В каждой таблице сопоставления перечислены категории технологических решений. Каждое пересечение сетки указывает, может ли технологическое решение той или иной категории обеспечить соответствие требованиям данного элемента управления ИТ к соблюдению предписаний по охране конфиденциальности. В заключение в разделе приводится прикладной пример и обобщенное описание процедуры. Раздел включает следующие темы. 1. Сопоставление нормативных актов с контрольной структурой управления. Здесь приводятся общие сведения о сопоставлении важнейших нормативных актов и стандартов с конкретными категориями технологических решений с помощью примера контрольной структуры. 2. Технологические решения по обеспечению соблюдения нормативных требований. В рамках этой темы описываются категории технологических решений, имеющие отношение к соблюдению нормативных требований. 3. Технологические решения для управления ИТ. Здесь демонстрируется, как категории контрольной структуры соотносятся с конкретными технологическими решениями. С помощью таблицы сопоставления руководители ИТ-подразделений могут определить, элементы управления ИТ какого типа им необходимо внедрить. 4. Прикладной пример. С помощью прикладного примера иллюстрируется, как конкретные нормативные акты обусловливают выбор конкретных технологических решений. Пример основан на сопоставлениях, ранее приведенных в этом разделе. 5. Заключение суммирует ключевые положения всего раздела руководства. Сопоставление нормативных актов с контрольной структурой В этом разделе рассматривается сопоставление важнейших нормативных актов и стандартов, упомянутых в настоящем руководстве, с конкретными категориями технологических решений с помощью примера контрольной структуры управления. Рабочая группа сопоставила пять нормативных актов и стандартов — SOX, GLBA, HIPAA, EUDPD и ISO 17799. Во всех случаях, когда это было возможно, группа проекта проводила сопоставление с опорой на уже имеющиеся рекомендации и инструкции уполномоченных органов и государственных организаций. Документы с этими рекомендациями и инструкциями, в данном руководстве именуемые связующими документами, получили широкое признание в среде специалистов по аудитам и нормативным предписаниям как приемлемое описание требований к управлению, изложенных в этих нормативных актах и стандартах. При сопоставлении нормативных актов с примером контрольной структуры управления использовались следующие связующие документы. Закон Сарбейнса-Оксли. Документ IT Control Objectives for Sarbanes-Oxley с изложением контрольных показателей для элементов управления ИТ применительно к этому закону, изданный ITGI и размещенный по адресу: www.itgi.org/Template_ITGI.cfm?Section=ITGI&CONTENTID=9757&TEMPLATE=/Co ntentManagement/ContentDisplay.cfm. Закон Грэмма-Лича-Блайли (GLBA). Документ Interagency Guidelines Establishing Standards for Safeguarding Customer Information с изложением межведомственных инструкций министерства финансов, управления контролера денежного обращения, управления по надзору за сберегательными учреждениями, Федеральной резервной системы и Федеральной корпорации страхования депозитов США по разработке стандартов защиты данных о клиентах, размещенный по адресу: www.ffiec.gov/ffiecinfobase/resources/info_sec/frb-sr-01-15standards_safeguard_cus_info.pdf. Закон об унификации и учете в области медицинского страхования. Документ HIPAA Administrative Simplification Regulation Text с изложением правил упрощения административных процедур, изданный управлением гражданских прав министерства здравоохранения и социального обеспечения США и расположенный по адресу: www.os.dhhs.gov/ocr/AdminSimpRegText.pdf. Директива ЕС о защите данных. Полный текст директивы Directive 95/46/EC of the European Parliament and the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, опубликованный в официальном бюллетене L 281 от 23.11.1995, стр. 0031 – 0050 и размещенный по адресу: http://europa.eu.int/eur-lex/lex/ LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML. Стандарт ISO 17799: практические правила управления информационной безопасностью 2005 года. Доступен в интернет-магазине Международного электротехнического комитета по адресу: http://domino.iec.ch/webstore/webstore.nsf/artnum/034226. Категории элементов управления В качестве краткого обзора нормативных требований каждого из пяти законодательных актов и стандартов в данном подразделе приведена таблица (см. Таблица 1)сопоставления этих нормативных актов и стандартов с категориями элементов управления в примере некоторой контрольной структуры управления. С помощью данной таблицы сопоставления можно определить, элементы управления каких категорий применимы в организации. Кроме того, в таблице отображены случаи, когда для нескольких нормативных актов и стандартов требуются элементы управления одной категории. С помощью этой таблицы руководители ИТ-подразделений могут планировать меры по обеспечению соответствия нормативным требованиям. Например, если организация должна соблюдать SOX и HIPAA, следует рассмотреть возможность внедрения элементов управления, относящихся к тем категориям, напротив которых стоят пометки в столбцах SOX и HIPAA. Более того, можно отдать приоритет тем категориям элементов управления, которые требуются для всех или нескольких нормативных актов, затрагивающих организацию. Корпорация Майкрософт вновь отмечает, что настоящее сопоставление не является источником юридических советов и рекомендаций. Для получения конкретной индивидуализированной консультации по этой сложной теме следует обратиться к юрисконсультам или аудиторам компании. Таблица 1. . Сопоставление важнейших нормативных актов и стандартов с категориями элементов управления Категории элементов управления SOX GLBA HIPAA EUDPD ISO 17799 Организационная структура X X X X X Стратегическое планирование ИТ X X X X X Планирование ресурсов ИТ Разработка политик и стандартов и информирование о них X X X X X X X X X X Разработка решений X X X X Управление рисками в области ИТ X X X X Управление изменениями X X X X Управление уровнями обслуживания X X X Управление проектами X X Категории элементов управления Управление производительностью и доступностью SOX GLBA HIPAA EUDPD ISO 17799 X X X X X Управление безопасностью и администрирование X X X X X Информирование и обучение X X X Управление конфигурациями Управление обработкой ошибок и особых ситуаций X X X X Управление данными X X X X X Управление эксплуатацией X X X X Эффективность ИТ X X Безопасность ИТ X X X Соответствие ИТ нормативным требованиям и управление ИТ X X X X X X X X X Финансовое управление Управление охраной конфиденциальности X X X X X В следующем подразделе («Технологические решения по обеспечению соблюдения нормативных требований») описываются категории технологических решений, имеющие отношение к соблюдению нормативных требований. Технологические решения по обеспечению соответствия нормативным требованиям Ниже рассматриваются категории технологических решений, касающиеся соблюдения нормативных требований. До настоящего момента в центре внимания находился вопрос, как нормативные акты обусловливают потребность в конкретных элементах управления ИТ. Теперь основное внимание будет уделено технологическим решениям, с помощью которых эти потребности можно удовлетворить. Рабочая группа создала список технологических решений и их категорий, а также провела их проверку в соответствии со стандартом ISO 17799, рекомендациями Национального института стандартов и технологий (NIST SP800) и другими платформами. В результате были выделены 19 категорий технологических решений, перечисленных ниже: управление документами; управление бизнес-процессами; управление проектами; оценка рисков; управление изменениями; сетевая безопасность; управление узлами; предотвращение заражения вредоносными программами; безопасность приложений; обмен сообщениями и совместная работа; классификация и защита данных; управление учетными данными; управление проверкой подлинности, авторизацией и доступом; обучение; физическая защита; выявление уязвимостей; мониторинг и отчетность; восстановление после сбоев и переход на другой ресурс; управление обработкой особых ситуаций и отслеживание неполадок. Управление документами Решения по управлению документами совмещают программное обеспечение и процессы, позволяющие управлять неструктурированными данными в организации. Эти данные могут существовать в различных цифровых форматах, включая документы, технические чертежи, XML-файлы, изображения, аудио- и видеофайлы. Управление документами нацелено на решение двух задач соответствия нормативным требованиям: обеспечение информирования обо всех изложенных в документах политиках, стандартах, процедурах и требованиях; обеспечение контроля за неструктурированными данными. Обе эти проблемы фигурируют в планах большинства аудиторских проверок соответствия нормативным требованиям. Решения по управлению документами могут быть как очень простыми, так и крайне сложными. Однако, поскольку элементы управления всех категорий требуют документации какого-либо рода, всем им необходимо то или иное решение по управлению документами. Управление бизнес-процессами Приложения по управлению бизнес-процессами позволяют обеспечить сквозную прозрачность и управление всеми сегментами сложных многошаговых запросов данных или транзакций, в которых задействованы различные приложения и различные пользователи в одной или нескольких организациях. С точки зрения соответствия нормативным требованиям, управление бизнеспроцессами позволяет обеспечить защиту транзакций, надежное обслуживание и доступность, а также совершенствование уровней обслуживания. В более широком плане управление бизнес-процессами представляет собой решение для обмена сообщениями, благодаря которому все вовлеченные участники поддерживают между собой связь и могут отслеживать положение дел независимо от того, где они находятся физически. Это решение чаще всего используется в крупных компаниях, на которые распространяются требования закона Сарбейнса-Оксли. Управление проектами Решения по управлению проектами позволяют использовать знания, навыки, средства и методики в отношении широкого спектра возможностей для удовлетворения требований того или иного проекта. Знания и действия в рамках управления проектами лучше всего описать, используя ряд компонентов процесса его создания. Такой процесс можно разделить на пять групп: формирование замысла, планирование, разработка, стабилизация и ввод в действие. Решения по управлению проектами используются компаниями с целью реализации проектов, обеспечения их надежного функционирования, а также соответствия нормативным требованиям. Решения по управлению проектами обеспечивают руководителей и других участников проектов дополнительными возможностями для контроля и осуществления обратной связи. Эти решения способны сократить прямые затраты, повысить уровень контроля за осуществлением проектов и эффективность всех аспектов соответствия нормативным требованиям. Оценка рисков Понятие оценка рисков имеет несколько значений. Специалисты по информационной безопасности определяют его как системный метод выявления ценных свойств системы обработки данных, угроз этим свойствам и уязвимости системы в отношении этих угроз. В контексте соответствия нормативным требованиям оценка рисков — это процесс оценки степени соблюдения требований и имеющихся в организации недостатков. Из-за меняющихся требований большинство решений по оценке рисков реализуется в форме приглашения специалистов для консультации с применением средств для выполнения оценок. Существуют также методики проведения оценок собственными силами. Важнейший этап процесса оценки — выявление активов и присвоение каждому активу предприятия качественных или количественных значений. Управление изменениями Система управления изменениями — это структурированный процесс, который требует от руководителей ИТ-подразделений рассмотрения на постоянной основе предлагаемых изменений с целью обеспечения технической и деловой готовности. Руководители ИТ-подразделений могут регулировать изменения в соответствии с потребностями и реальностями коммерческой деятельности. Например, система организации может включать базу данных, позволяющую сотрудникам принимать более взвешенные решения о будущих изменениях на основе данных истории, отражающих успехи или неудачи аналогичных изменений, предпринимавшихся в прошлом. Кроме того, управление изменениями — это структурированный процесс уведомления всех заинтересованных сторон о состоянии и наличии изменений. Этот процесс может выработать систему учета, фиксирующую, когда и какие воздействующие на состояние важнейших ресурсов действия предпринимались, чтобы выявить неполадки и обеспечить управление ресурсами. Управление изменениями — критически важный элемент соответствия нормативным требованиям, поскольку нельзя утверждать, что среда ИТ находится под контролем, если не знаешь, какие изменения были в нее внесены. Одним из наиболее эффективных способов управления изменениями является использование решения по управлению изменениями. Такое решение объединяет работу ПО, действия персонала и процессы, которые оно использует. Безопасность сети Решения по обеспечению безопасности сети составляют широкую категорию средств, предназначенных для защиты всех компонентов сетей в организациях, включая межсетевые экраны, серверы, маршрутизаторы, коммутаторы и точки доступа. Многие нормативные акты предписывают организациям принять необходимые меры для обеспечения защиты инфраструктуры ИТ. Поскольку сетевая безопасность является критически важным элементом общей информационной безопасности, она имеет существенное значение для соответствия нормативным требованиям. Проектирование сетей Периметр сети Управление узлами Решения по управлению узлами предназначены для управления операционными системами на серверах и рабочих станциях. Решения по управлению узлами также включают применение рекомендаций по безопасности на всех уровнях операционной системы каждого узла, установку самых последних обновлений и исправлений и применение безопасных методов повседневной эксплуатации. Управление узлами является фундаментальной категорией по отношению ко всем остальным важным категориям управления безопасностью, таких как конфиденциальность, целостность и доступность. Основные параметры безопасности узлов Расширенные параметры безопасности узлов Безопасность серверов и рабочих станций Предотвращение заражения вредоносными программами Решения по предотвращению заражения вредоносными программами включают решения по борьбе с вирусами, программами-шпионами, нежелательной почтой и средства обнаружения программ-маскировщиков. При отсутствии приложений для выявления, мониторинга и удаления вредоносного программного обеспечения в организации возрастает риск несанкционированного раскрытия или утери конфиденциальных данных. Недостаток таких ресурсов также создает ситуацию, при которой конфиденциальность, целостность и доступность данных в ИТ-системе организации подвергаются угрозе. Безопасность приложений Безопасность приложений сочетает высокие стандарты разработки и специальные меры по обеспечению безопасности программного обеспечения. Безопасность приложений касается использования важнейших элементов управления приложений, которым аудиторы уделяют особое внимание при проверке ответственных бизнес-систем. Она составляет значительную часть лучших практических рекомендаций и является областью особого контроля со стороны отделения компьютерной безопасности Национального института стандартов и технологий (NIST). Разработка защищенных приложений Обмен сообщениями и совместная работа Приложения для обмена сообщениями и совместной работы стали средствами первостепенной важности. Приложения для совместной работы могут быть весьма различными — от интегрированных программ для работы с документами, например Microsoft® Office, до порталов, обмена мгновенными сообщениями, программного обеспечения для интерактивных презентаций и программ для одноранговых сетей. Одним из наиболее распространенных слабых мест, выявляемых проверками соответствия нормативным требованиям, является то, что приложения для обмена сообщениями, например, программы электронной почты, делают конфиденциальную информацию доступной за пределами организации. Поскольку электронная почта получила повсеместное распространение, а служащие широко применяют ее при исполнении своих обязанностей, автоматизация решений по защите обмена сообщениями и совместной работы является существенным моментом. Программы обмена сообщениями и совместной работы обеспечивают существенное повышение производительности труда групп, занятых достижением соответствия требованиям, и вносят заметный вклад в рост общей эффективности деятельности организации. Кроме того, должна существовать возможность передачи сведений, собранных во время оценок аудиторами или внутренними ресурсами, группам, которые на практике занимаются установкой для исправления неполадок или последующим устранением недостатков. Такие решения для совместной работы, как порталы, повышают эффективность обмена данными. Классификация и защита данных Классификация и защита данных обеспечивает присвоение хранящимся в системе или передаваемым данным классификационных уровней безопасности. Решения этой категории предназначены также для защиты данных, то есть для обеспечения конфиденциальности и целостности данных во время хранения или передачи. Криптографические решения — наиболее распространенный метод защиты данных, применяемый организациями. Классификация данных имеет большое значение для соответствия нормативным требованиям, поскольку информирует пользователей о том, какие уровни обозначают относительную важность данных, как следует обращаться с этими данными, как их следует защищать и размещать. Типичной классификацией данных по уровню относительной значимости для бизнес-деятельности является: «высокий», «средний» и «низкий» уровень важности. В некоторых организациях используется военная система классификации данных: «Совершенно секретно», «Секретно», «Для служебного пользования» и без грифа секретности. Все инструкции по соответствию нормативным требованиям предписывают защиту файлов и шифрование важных данных как во время хранения, так и при передаче. Процесс решения проблем соответствия создает огромный объем важных данных, в первую очередь в неструктурированных приложениях, таких как Microsoft® Word и Excel®. Контроль и защита данных о соответствии нормативным требованиям имеет исключительное значение, поскольку они содержат полную и подробную информацию обо всех слабых и уязвимых местах организации. Управление учетными данными Организации используют в своих информационных сетях программное обеспечение и процедуры по управлению учетными данными, чтобы облегчить управление цифровыми учетными данными пользователей и их цифровыми правами. Эта категория решений соотносится со многими важнейшими категориями элементов управления в рамках обеспечения соответствия нормативным требованиям. Использование решений по управлению учетными данными является одной из самых распространенных рекомендаций консультантов по обеспечению соответствия нормативным требованиям. К примерам решений по управлению учетными данными можно отнести разработку процессов, обеспечивающих своевременную блокировку учетных записей, и процедур оценки элементов управления доступом к ресурсам данных. Конкретные примеры Управление проверкой подлинности, авторизацией и доступом Для проверки подлинности пользователя обычно требуются его имя и пароль, однако могут использоваться и иные методы подтверждения личности, такие как смарт-карта, сканирование сетчатки глаза, распознавание голоса или отпечатков пальцев. Авторизация определяет, имеет ли пользователь, личность которого уже установлена, разрешения на доступ к запрошенным ресурсам. Предоставление или запрещение доступа зависит от многих факторов, в том числе от сетевого адреса пользователя, времени суток или используемого обозревателя. Данный вид управления критически важен по отношению к ключевым принципам обеспечения безопасности — конфиденциальности, целостности и доступности. Например, большая часть функций службы каталогов Active Directory® в операционных системах Microsoft® Windows Server™ 2003/2008 предназначена для осуществления проверки подлинности, авторизации и управления доступом. Служба проверки подлинности в Интернете (IAS) представляет собой реализацию корпорацией Майкрософт сервера и прокси-сервера службы удаленной проверки подлинности RADIUS. Как и RADIUS-сервер IAS выполняет централизованную проверку подлинности соединений, авторизацию и учет многочисленных типов сетевого доступа, в том числе подключения по беспроводным и виртуальным частным сетям (VPN). Как прокси-сервер службы RADIUS IAS пересылает сообщения с данными для проверки подлинности и учета на другие RADIUS-серверы. Обучение Чтобы обеспечить хорошие результаты работы, компании важно ознакомить служащих с ключевыми вопросами безопасности и соответствия нормативным предписаниям, организовав соответствующее обучение. Оно поможет создать критически важную взаимосвязь между людьми, процессами и технологиями, благодаря которой будет функционировать программа безопасности. Решение задачи соответствия нормативным требованиям предполагает проведение обучения персонала по вопросам безопасности и соблюдения предписаний. Решения по обучению персонала по вопросам безопасности и соответствия нормативным требованиям в большинстве организаций представляют собой модификации существующих решений по обучению работе с программным обеспечением. Физическая защита Решения по физической защите обеспечивают безопасность физического доступа к системам и рабочим станциям в организации и управления ими. Физическая защита имеет большое значение для обеспечения безопасности всей ИТ-инфраструктуры в организации. Практически все атаки, в ходе которых злоумышленник получает физический доступ к серверу, приводят к раскрытию или потере ресурсов организации. Квалифицированные поставщики услуг обычно выполняют для организаций индивидуализированную доработку решений по физической защите (в том числе и обеспечение защищенного доступа с применением смарт-карт), а после внедрения предоставляют услуги по их обслуживанию. Выявление уязвимостей В решениях по выявлению уязвимостей используются средства, позволяющие выполнить тестирование информационной системы организации на наличие слабых мест. Сотрудники ИТ-подразделений должны быть осведомлены об уязвимых местах в ИТ-инфраструктуре, чтобы иметь возможность эффективно их устранить. Регулярная проверка компьютеров и серверов организации на наличие уязвимостей имеет чрезвычайно важное значение, поскольку обеспечивает управляемую платформу для выполнения бизнес-приложений. Отсутствие у руководства ИТ-подразделения информации об уязвимых местах системы означает отсутствие уверенности в том, что некоему злоумышленнику не удалось взломать защиту рабочей среды. Рабочая среда с нарушенной системой безопасности не может считаться управляемой и пригодной для выполнения бизнес-приложений в соответствии с нормативными требованиями. Мониторинг и отчетность Решения по мониторингу и отчетности позволяют собирать и анализировать данные журналов проверки подлинности и допуска в системы. (Все предлагаемые в настоящее время операционные системы включают функции ведения журналов.) Эти решения либо осуществляют сбор конкретных данных о соответствии тем или иным нормативным актам, либо используют существующие журналы, встроенные в операционные системы или пакеты программного обеспечения. Подкатегорией мониторинга и отчетности является сбор, анализ и сопоставление данных всех журналов в организации. Иногда это достигается с помощью решения инструментального типа, которое позволяет эффективнее анализировать разнообразные данные в рамках всей организации. Решение такого типа дает руководству ИТ-подразделения возможность более точно определять наличие взаимосвязей между событиями. Решения по мониторингу и отчетности включают методы проверки и контроля качества, гарантирующие обеспечение безопасности и конфиденциальности. Например, такие решения позволяют организациям обеспечить соответствие требованиям HIPAA, предписывающего аудиторам проводить оценку отдельных историй болезни. Восстановление после сбоев и отказоустойчивость В случае сбоя, вызванного естественными причинами или ошибкой пользователя, информационные системы организации должны быть как можно быстрее возвращены в работоспособное состояние. Термины восстановление после аварийного сбоя и отказоустойчивость непосредственно связаны с этим процессом. Отказоустойчивость подразумевает наличие резервных систем, постоянно функционирующих параллельно рабочим системам. Предпочтительно географически рассредоточить эти системы. Одним из способов обеспечения резервирования ресурсов является внедрение системы, по своей природе защищенной от сбоев определенных видов. К таким системам относятся, например, служба каталогов Active Directory® с несколькими хозяевами, кластерный SQL Server™, служба балансировки сетевой нагрузки Microsoft® Windows Server™ и технология службы кластеризации (MSCS). Многие нормативные акты и стандарты, в том числе HIPAA, GLBA и EUDPD, содержат требование наличия решений по восстановлению после сбоев и отказоустойчивости. Архивация и восстановление Резервные системы Информация о компонентах и решениях Майкрософт для резервирования систем содержится в следующих ресурсах. Управление обработкой особых ситуаций и отслеживание неполадок В решениях по управлению обработкой особых ситуаций и отслеживанию неполадок используются индивидуально настроенные системы, обеспечивающие сквозное управление особыми бизнес-процессами. Функциональные возможности системы практически такие же, как у бизнес-приложений, входящих в категорию управления взаимоотношениями с клиентами (CRM). Несколько нормативных актов и стандартов, включая GLBA и HIPAA, содержат прямое требование к организациям использовать решения по управлению обработкой особых ситуаций и отслеживанию неполадок. Заключение В этом разделе описаны технологические решения, используемые организациями для достижения и поддержания соответствия нормативным требованиям. Внедрение этих решений не только обеспечивает безопасность ИТинфраструктуры и ее соответствие нормативным требованиям, но и оказывает положительное воздействие на бизнес-процессы организации. Перед внедрением какого-либо из описанных решений необходимо проконсультироваться со своими юрисконсультами и аудиторами по поводу специфических потребностей организации по обеспечению соответствия нормативным требованиями. Следует также тщательно взвесить возможное воздействие этих решений на всю организацию, и не только в контексте соответствия нормативным предписаниям. Кроме того, также необходим регулярный поиск в открытых для публичного доступа ресурсах, чтобы получить дополнительные сведения по этой сложной и важной теме. В следующем подразделе («Технологические решения для управления ИТ») приводится таблица сопоставления категорий элементов управления в контрольной структуре управления с конкретными технологическими решениями. С помощью этих сопоставлений можно определить, элементы управления каких типов требуется внедрить в организации. Технологические решения для управления ИТ В приведенной ниже таблице представлены категории элементов управления и технологические решения. Чтобы воспользоваться этой таблицей, следует сначала найти категории элементов управления, которые требуется внедрить в организации. Пометки-«галочки» в столбцах указывают, с помощью какого технологического решения это можно сделать. Далее с помощью прикладного примера будет показано, как конкретные нормативные акты и стандарты обусловливают выбор конкретных технологических решений. Таблица 2 Сопоставление категорий элементов управления с технологическими решениями 49 Прикладной пример Данный пример иллюстрирует, как компания использует руководство по планированию и решению задач соответствия нормативным требованиям для более точного выяснения, какие процессы должны быть задействованы в работе по достижению соответствия нормативным предписаниям. Компания также осведомлена о преимуществах использования приведенной выше модели контрольной структуры для определения различных нормативных актов и стандартов и последующего выбора приоритетных технологических решений, с помощью которых она сможет выполнить свои обязательства по соответствию нормативным требованиям. Woodgrove National Bank является финансовой организацией со штабквартирой в Нью-Йорке, насчитывающей 5 000 служащих. Банк является открытым акционерным обществом, зарегистрированным на Нью-йоркской фондовой бирже (NYSE) и, как и многие другие финансовые организации в США, должен соблюдать требования закона Сарбейнса-Оксли. Кроме того, банк должен придерживаться требований HIPAA в отношении пособий на медицинское и стоматологическое обслуживание, которое банк выделяет своим служащим, а также инструкций GLBA, поскольку банк работает в сфере финансовых услуг. Для решения задачи соответствия перечисленным нормативным требованиям руководство поручило ведущему руководителю службы ИТ банка Хейвену Форду сделать все необходимое, чтобы ИТ-подразделение банка успешно прошло аудиторские проверки, запланированные на следующий календарный год. Хейвен Форд ставит перед собой две важные цели: добиться полного соответствия требованиям всех нормативных актов и стандартов, распространяющихся на банк, с использованием, где это возможно, элементов управления ИТ; свести к минимуму затраты времени на аудиторские проверки и воздействие этих проверок на работу ИТ-подразделения банка за счет повсеместного, где это возможно, повышения эффективности с помощью надежных элементов управления ИТ. Руководитель службы ИТ банка предпринимает следующие шаги. Проводит совещание с юристами и аудиторами банка для обсуждения намеченных им задач и определения наилучших способов их решения. Изучает Руководство по планированию и решению задач соответствия нормативным требованиям с целью поиска наиболее полезных рекомендаций. Устанавливает, что структурный подход является наиболее удобным средством решения поставленных задач. Используя таблицу сопоставления важнейших нормативных актов и стандартов с категориями элементов управления, приведенную выше в этом разделе руководства (табл. 1), знакомится с категориями необходимых банку элементов управления. Хейвен Форд сосредотачивает свое внимание на столбцах 50 таблицы, относящихся к SOX, HIPAA и GLBA. На этом примере он приходит к выводу, что для соблюдения всех трех нормативных актов, затрагивающих Woodgrove National Bank, необходимы элементы управления, относящиеся к категории «управление безопасностью и администрирование». С помощью таблицы сопоставления категорий элементов управления с технологическими решениями (Таблица 2) Хейвен Форд выясняет, каким новым технологиям банку следует уделить особое внимание. Он приходит в выводу, что для внедрения элементов управления безопасностью и администрированием потребуются технологические решения по управлению учетными данными. Изучение конкретных технологий в разделе «Технологические решения по обеспечению соблюдения нормативных требований» позволяет Хейвену Форду установить, какие именно технологии потребуются его рабочей группе для решения остальных задач по налаживанию системы управления в банке. Для поиска технологий, с помощью которых можно усовершенствовать элементы управления учетными данными и создания учетных записей и профилей пользователей, Хейвену Форд обращается к разделу о решениях по управлению учетными данными. Его особенно интересует серия материалов по управлению учетными данными и доступом, ссылки на которые имеются в разделе о решениях по управлению учетными данными. Изучив ситуацию, Хейвен Форд приходит к выводу, что рекомендации, приведенные в этих материалах, представляют собой превосходное решение для ИТ-инфраструктуры банка. Затем, он обсуждает свои выводы с юристами и аудиторами банка, которые помогают ему привести предложенный план в соответствие со специфическими потребностями и обязательствами банка, связанными с необходимостью соответствия нормативным требованиям. Хейвен Форд дорабатывает план деятельности своей рабочей группы: включает в него технологические решения, которым будет уделено особое внимание в текущем году в целях внедрения недостающих элементов управления нужных категорий и намечает стратегию их реализации. После рассмотрения и одобрения плана юристами и аудиторами банка руководитель службы ИТ выделяет часть бюджета подразделения на внедрение в банке программного обеспечения для создания инфраструктуры по управлению учетными данными. Силами рабочей группы доработанный план выполняется. В последнем подразделе кратко повторяются основные положения этого раздела руководства. Заключение Приведенные в этом разделе сопоставления показывают, как нормативные акты определяют потребность организации в конкретных элементах управления ИТ. Кроме того, они указывают, технологические решения каких типов можно использовать для удовлетворения этих потребностей в элементах управления ИТ. В заключение приводится прикладной пример использования настоящего руководства для решения задачи соответствия нормативным актам. 51 Некоторые вопросы сбора и обработки информации для принятия управленческих решений на предприятии. Существующий подход к сбору информации для принятия управленческих решений, реализованный на многих предприятиях, носит "функциональный" характер и понимается соответственно как функция от информационного окружения, т.е. существуют базы данных внутренней и внешней информации, которую собрали и порой используют для принятия решения функциональные службы. Так, например, отдел сбыта ОАО собирает информацию о контактах с клиентами, о сделках и услугах; служба маркетинга готовит обзоры тенденций рынка и изменений вкусов потребителей; технический отдел и инвестиций собирает информацию о новых производственных идеях и готовит данные и расчеты для инвестиционных проектов; производственники собирают информацию о возможностях обновления производства и совершенствования выпускаемой продукции; служба информации готовит обзоры новинок программного обеспечения и информационного оборудования; отдел кадров и соцобеспечения отслеживает изменения в составе рабочей силы и в возможностях найма. Каковы недостатки данного подхода помимо того, что на предприятии стратегическое мышление замкнуто границами этих изолированных баз данных, которые используют определенные группы сотрудников для выработки предложений о направлении развития компании и разработки стратегий, ведущих к успеху. Во-первых, эти базы данных отражают функциональный подход к деятельности предприятия, а не широкое управленческое понимание бизнеса. Вовторых, истолкование собранных данных находится под влиянием предрассудков и запретов, сковано шаблонами представлений о прежних факторах успеха. Втретьих, специалисты служб планирования, финансового обеспечения, маркетинга, информационных и других технических служб продолжают действовать исключительно как получатели и хранители информации. Таким образом, на предприятии вся информационная деятельность нацелена на одностороннее и узкое обслуживание руководства организации и редко используется для информационного обеспечения других этажей управления в целях подготовки оптимальных в целом управленческих решений. Это характерно для многих предприятий, перешедших от плановой экономики к рыночной в результате приватизации. Схема информационных потоков в такой организации представлена на Рис. 6. Рис. 6. Существующая схема организации информационных потоков: 1 - 52 управление организацией, 2-6 - подразделения организации Для организации современной бизнес-деятельности необходима такая реорганизация информационных потоков, которая обеспечивает информационную достаточность и четкость во взаимном информационном обеспечении отдельных подразделений с целью выработки оптимального для фирмы решения. Но организация такой информационной системы на современном уровне возможна лишь на основе создания современного управленческого учета, система и задачи которого изложены далее. 53 Система и задачи управленческого учета Задачи, решаемые при создании системы подготовки информации для принятия управленческих решений, находят свое отражение в управленческом учете. Перед предприятием стоит задача организации такого учета. Под управленческим учетом мы будем понимать систему выявления, сбора и агрегирования учетных данных, направленную на решение конкретной управленческой задачи. Следует отметить, что существуют различные подходы к определению понятия "управленческий учет". Русский термин "Управленческий учет" восходит к английскому термину "Managerial accounting" и к его европейскому аналогу: "контроллинг". Эти два термина не являются полностью эквивалентными и отражают два подхода к пониманию термина "управленческий учет", которые можно охарактеризовать следующим образом: первый рассматривает управленческий учет как систему сбора и интерпретации информации о затратах, издержках и себестоимости продукции, что ближе к термину "контроллинг", при этом большее внимание уделяется нормативному характеру подобной информации и ее значению для получения "внешней отчетности" предприятия. Кстати, термин контроллинг не случайно является однокоренным со словом "контроль", что подчеркивает связь учета с управлением. Упрощенно можно считать, что это расширенная система организации учета для целей контроля за деятельностью предприятия. второй подход исходит из того, что основная задача любой учетной деятельности - обеспечение управленческого персонала предприятия своевременной и полной информацией для принятия управленческих решений, и что имеет место "системнозависимый" характер учетной деятельности, то есть тесная, точнее неразрывная связь технологий учета с технологиями управления компанией в целом и/или ее частями. Такой подход соответствует понятию "Managerial accounting", который может быть переведен следующей фразой "организация учета, исходя из потребностей управления". При таком подходе к понятию "управленческий учет" относятся не только система сбора и анализа информации об издержках предприятия, но и система управления бюджетами (то есть планирования) и система оценки деятельности подразделений, то есть более управленческие, нежели бухгалтерские технологии. Существует также более узкая трактовка данного понятия, при которой под "Managerial accounting" понимается формирование специальных отчетов из имеющихся бухгалтерских данных для целей поддержки принятия решений. В данном случае необходимо понимать, что получить указанные отчеты можно только при наличии соответствующей информации в учетных регистрах. По умолчанию (!) считается, что используемая система бухгалтерского учета (западная) устроена таким образом, что такие отчеты получить возможно, ниже мы еще вернемся к вопросу о том, как должна быть для этого устроена, по нашему мнению, любая система учета (в том числе бухгалтерская) с точки зрения получения корректной информации. 54 Как в первом, так и во втором случае можно констатировать, что в современном развитии западных источников термина "управленческий учет" центр тяжести все более и более переносится на слово "управленческий", что связано с тем, что методика и технология организации учета все более и более определятся именно управленческой задачей, стоящей перед предприятием. При этом полезно вспомнить, что собственно учет и анализ издержек с целью их снижения и оптимизации является простейшей и самой очевидной формой организации управления коммерческой структурой. Однако, при решении данной задачи недостаточно для определения форм и методов учета руководствоваться только требованиями финансовой или налоговой оптимизации деятельности, а необходимо учитывать и требования технологии основной деятельности, которые, как правило, серьезно влияют на конечный результат. В частности, например, стандартные требования не учитывают необходимость регистрации времени выписки документов на отпуск товара. В то же время временной анализ деятельности отдела сбыта может позволить существенно снизить издержки за счет оптимизации количества персонала с учетом сезонности, или повысить отгрузку путем введения сменности. Или, например, управление и оперативный анализ "ликвидности" дебиторской и кредиторской задолженности - весьма эффективное средство повышения общих финансовых результатов. Но для проведения подобного анализа необходимо ввести детальные учетные регистры, в частности иметь "сквозной" учет и анализ кредиторов и дебиторов. Таким образом, в связи с необходимостью изменения учетной информации для целей управления на смену "нормативному или налоговому" учету вполне естественно приходит учет управленческий, который в действительности существовал всегда, даже в нашей коммерческой практике, правда, назывался ранее достаточно неаппетитно: "черным". Причем методика его использования точно соответствовала методике использования данных "управленческого учета": на базе черных данных принимались решения, прогнозировались финансовые результаты, а затем на основании этих же решений и результатов формировался "белый учет". 55 Иерархия систем управленческого учета В отечественной литературе практически не освящены вопросы классификации систем управленческого учета, за исключением некоторых аспектов финансового управленческого учета. В то же время создание на предприятии системы управленческого учета практически невозможно без правильной классификации процессов и технологий в соответствии с систематикой управленческого учета, что позволит выработать правильную методологию учета затрат, определения результатов деятельности подразделения, да и наконец, просто определения системы управленческой отчетности подразделения. В общем виде схема генерации управленческого учета представлена Рис. 7.[1] Рис. 7. Схема генерации управленческого учета Из рисунка видно, что в основе управленческого учета лежат три источника: технология бизнеса в целом и конкретного вида деятельности в частности; учетная политика предприятия и правила бухучета конкретного вида деятельности; нормативная база конкретного вида бизнеса. На их основе формируется собственно управленческий учет, который представляет собой систему организации, сбора и агрегирования данных о конкретной управленческой задаче. После завершения процесса формирования управленческого учета формируется "внешний интерфейс управленческого учета", состоящий из трех тесно взаимосвязанных систем (трех составных частей): 56 учета затрат (интерфейс с финансами); показателей деятельности (интерфейс с регулярным менеджментом); управленческих отчетов (интерфейс с системой принятия решений). Если "источники" управленческого учета реже подвергаются сомнению, то "составные части" очень часто забываются, будучи сведенными к единственной: системе учета затрат, чего на практике явно оказывается недостаточно, для скольнибудь сложных бизнес-систем. При этом надо отметить, что как показатели деятельности, так и управленческие отчеты могут иметь нефинансовый характер, отражая специфику деятельности подразделения. Типичным примером такого отчета служит, например отчет о движении товаров по складу, который предназначен для принятия решений о времени и размерах закупок, но может не содержать информации о ценах (информация о рекомендованных ценах закупки может прийти совсем с другой стороны - например, из отдела маркетинга или планово-экономической службы, который определяет ее исходя из рекомендованной цены продажи готового изделия и состояния рынка комплектующих). Соответственно показателем деятельности складской службы может быть некоторый коэффициент соответствия уровня запасов рекомендованному "оптимальному уровню". Такого же рода "нефинансовые", но, тем не менее, очень важные, а часто и определяющие показатели деятельности имеются практически у всех подразделений. Более того, можно утверждать, что принцип "не все измеряется деньгами" - это тоже один из принципов управления бизнесом. В соответствии с вышеприведенной схемой можно классифицировать управленческий учет, как по источникам, так и по составным частям, однако легко видеть, что объединить ту и другую систему классификации может вид бизнеспроцесса, на который должна быть наложена система управленческого учета. Очевидным является и тот факт, что в зависимости от того, в какой сфере экономики работает предприятие, его требования к видам учета и управления также будет различны. На Рис. 8 в виде диаграммы представлены требования учета и управления в зависимости от величины и способа организации предприятия [2]. 57 Рис. 8 Требования учета и управления в зависимости от величины и способа организации предприятия Реализация потребности управлять и принимать решения является доминирующей мотивацией и играет императивную роль в принятии решения о создании системы подготовки информации для принятия управленческих решений. Всякая социальная организация обладает своим внутренним движением и внутренними тенденциями развития, определяемыми в общем необходимостью для нее быть подготовленной к реализации внешних требований. Наиболее рациональной, на наш взгляд, представляется система организации информационных потоков, представленная на Рис. 9, где показана возможность передачи информации не только через руководящий орган, но и непосредственно между подразделениями. 58 Рис. 9. Диаграмма информационных потоков, модифицированной системы управления деятельностью компании: 1 - управление компанией, 2-6 подразделения компании После построения и описания бизнес - процессов, представленных на Рис. 9 переходят к автоматизации. Это связано с тем, что описание бизнес - процесса еще не означает управление им. Корпоративная информационная система (КИС) компании должна обеспечивать поддержку непрерывной регистрации транзакций, накопление статистики и обработку базы накопленных данных. Используя весь массив информации менеджеры компании смогут осуществлять оперативный контроль за функционированием продуктовых подразделений компании, анализировать события, и при необходимости усовершенствовать бизнес процессы. Например, в случае появления данных о нарушении порядка и сроков отгрузки продукции подразделениями компании, в подразделении сбыта направляется сигнал к тестированию системы логистики отгрузок продуктов, ревизии бизнес - процессов "сбыт продуктов (опт) и (розница)", выявлению "слабых мест" в протекании бизнес - процесса и их устранению. Созданная таким образом корпоративная система сбора и обработки информации позволяет избавиться от "валюнтариского" подхода к принятию управленческих решений, сделать их обоснованными рыночными условиями при их принятии и реализовать конкретных контроль последствий их реализации. 59 Применение мониторинга информационной среды предприятия 1. -Комплексный мониторинг служб за счет интегрированного наблюдения за приложениями, инфраструктурой и действиями конечных пользователей 2. Знания, накопленные группами разработчиков серверов, клиентских приложений и прикладных программ, позволяют быстрее решать проблемы 3. Интегрированное взаимодействующее решение, которое улучшает эффективность управления ИТ-средой Сокращение количества и среднего времени простоев − Непрерывный мониторинг состояния информационных систем − Оперативное оповещение специалистов о сбоях − Автоматическое выполнение корректирующих действий (там, где это возможно) − Удобные средства диагностики, выполнение заданий на удаленных серверах − Раннее обнаружение условий, предшествующих сбою − Раннее обнаружение нехватки ресурсов. Повышение уровня защищенности информационных ресурсов − Мониторинг событий безопасности − Контроль отклонения значений параметров безопасности от рекомендуемого уровня − Обнаружение отсутствующих обновлений ПО Снижение материальных и временных затрат на подготовку специалистов − Готовая база знаний по продуктам − Ведение корпоративной базы знаний − Привязка статей базы знаний к возникающим событиям Возможность быстро оценить состояние системы в целом − Средства наглядного отображения состояния − Отслеживание статуса проблем − Контроль отклонений от нормативов на время обработки событий Более точное планирование работ по развитию ИТ инфраструктуры − Всесторонний анализ накопленных данных о сбоях и их влияния на потребителей ИТ услуг − Выявление первоочередных задач − Возможность оценить результаты 60 Провайдер – источник информации. Критерий – условия отбора данных для реакции. Реакция – в качестве реакции на произошедшее событие могут быть определены различные действия – генерация SNMP трапа, запуск скрипта, создание алерта, отправка оповещения. С правилом может быть связана информация базы знаний. Пакеты управления - Определяют правила сбора и обработки информации, а также способ реакции на события Пакеты управления содержат: Описание источников данных (Providers) Правила сбора и обработки данных Группы оповещения Правила группировки компьютеров Скрипты (Scipts) и инструменты (Tasks) Базу знаний Представления данных для консоли оператора Схему классов и атрибутов для мониторинга состояния сервисов Сервисная модель любой системы мониторинга базируется на определении роли каждого сервера в IT инфраструктуре и определении модели «здоровья» для данной роли. State View обеспечивает графическое представление для моделей «здоровья». Роль сервера – например SQL Server Компоненты роли – например SQL Agent, DTC и т.д. Экземпляр - Instance Модель состояний определяется пакетами управления, средства редактирования ограничены. State View позволяет выявить с каким компонентом роли возникли проблемы и моментально перейти к изучению причин сбоя (в alerts и events view) Роли определяются для каждого управляемого узла (Per “computer” basis) Пакеты управления, например, от Microsoft: Microsoft Active Directory Microsoft Cluster Server 61 Domain Name Server Microsoft Exchange Microsoft Internet Information Services Microsoft Baseline Security Analyzer Microsoft Operations Manager Server Microsoft Systems Management Server Microsoft SQL Server Microsoft Windows Server 2000, 2003, 2008 + пакеты для MOM (ISA, FRS, …) Другие пакеты управления HP Servers − Proliant & Integrity lines − MP от HP Cisco Appliances − Jalasoft и NetIQ UNIX & Linux − NetIQ и Metilinx А также Lotus Domino, Oracle Database Server… … другие производители, которые входят в Microsoft Management Alliance 62 Задачи создания и использования Health model Документировать и приоритезировать главные известные ошибки. Документировать все индикаторы, которые позволяют определить и измерить «здоровье» системы. Документировать все известные «состояния здоровья» системы, которые потенциально могут быть на всех этапах жизненного цикла системы. Документировать процедуры определения, проверки, диагностики и восстановления для всех сбойных состояний (Product Knowledge). Определить инструменты и результаты их работы (Tasks) необходимые для определения, проверки, диагностики и восстановления из сбойных состояний. Основные инструменты построения Health model Таблицы, в которых документированы все инструменты управления, состояния «здоровья», все возможные входы и выходы состояний и связи между ними, процедуры проверки и диагностики, а также процедуры восстановления в «здоровые» состояния. Диаграмма состояний «здоровья» по каждой системе с указанием всех возможных состояний и переходов между ними. Правила мониторинга для автоматизации диагностики и восстановления. Типичная Health Model Health States – описанные состояния системы Event Groups - группы событий определяющие переходы Health State Transition Diagram - диаграмма переходов. G1 - EG9: Группы событий, определяющие переходы состояний Groups) Stopped, Full Run, Unknown, Partial Run A,B: состояния системы (Event 63 Этапы работ по созданию MP Создание компонентной модели приложения, и правил мониторинга приложения. (Role-Instance-Component, основываясь на определенной Health Model) − Определение атрибутов компьютеров − Создание компьютерных групп − Определение структуры групп правил − Определение провайдеров данных − Создание правил мониторинга − Определение автоматических корректирующих воздействий − Создание представлений данных Наполнение правил мониторинга дополнительной информацией (Product Knowledge) Дополнение набора правил необходимыми средствами диагностики (Tasks). Создание отчетов Золотое правило – следует генерировать алерты, только в тех случаях, когда необходимо вмешательство администратора приложения 64 Подсистема отчетности системы моноторинга Совершенно новая система отчетности, основанная на технологии MSSQL Reporting Services. Возможность экспорта отчета в файлы различных форматов (XLS, CSV, XML, PDF, MHT, TIFF, …). Возможность подписки на получение отчетов по электронной почте. Определения отчетов включены в пакеты управления (только для MOM версии 2005). Для самостоятельной разработки отчетов требуются компоненты Microsoft Visual Studio.NET. Архитектура подсистемы отчетности Пакет управления веб-узлами и веб-службами Мониторинг доступности и производительности веб-узлов и вебслужб Запросы HTTP к приложениям, которые находятся под наблюдением (синтетические транзакции) Сбор показателей доступности и производительности и отправка соответствующих оповещений Создание отчетов SLA по собранным показателям Синтетические транзакции Введение Транзакция Бизнес-процесс или операция, например обработка заказов или просмотр запасов Синтетическая транзакция Суррогатная, ложная или тестовая транзакция, созданная решением для управления производительностью и отправленная системе на выполнение Используется для мониторинга производительности приложений с точки зрения клиента Концепция Последовательность запросов Контейнер для индивидуальных запросов HTTP (URL-адреса и/или веб-страницы) Состоит из правила МОМ и файла последовательности запросов Файл последовательности запросов Создается с помощью мастера настройки 65 Размещается на сервере BITS с использованием протокола передачи файлов Загружается агентами МОМ для обработки ответом управляемого кода Как осуществляется мониторинг Веб-страницы и индивидуальные URL Веб-страницы состоят из базовой страницы и содержимого Изображения, сценарии, таблицы стилей, фреймы и ссылки Неявный мониторинг содержимого Предоставить URL-адрес базовой страницы и выбрать тип содержимого, которое подлежит мониторингу Преимущества: нет необходимости обновлять монитор при изменении содержимого веб-страницы Явный мониторинг содержимого Предоставить URL-адреса базовой страницы и содержимого Преимущества: для каждого URL можно настроить условия мониторинга Как осуществляется мониторинг : Веб-страницы и индивидуальные URL Неявный мониторинг содержимого Время отклика запроса накапливается Условия кода состояния наследуются URL-адресами содержимого Может использоваться для проверки ссылок Явный мониторинг содержимого Время отклика последовательности запросов накапливается Веб-узлы Веб-узел представляет собой набор веб-страниц Мониторинг каждой веб-страницы может производиться с явным и неявным включением содержимого Вручную создавать запросы HTTP проще при неявном включении содержимого Регистрировать перемещения на веб-узле проще при явном включении содержимого Время отклика последовательности запросов накапливается по всем вебстраницам Транзакции веб-приложений 66 Транзакция веб-приложения — это упорядоченная последовательность веб-страниц Для разработки используйте функцию регистрации перемещений по веб-узлу Результирующая последовательность запросов осуществляет мониторинг веб-страниц путем явного включения содержимого Возможно «преобразование» к неявному включению Каждая веб-страница отмечается как критический запрос Отслеживание количества дней, оставшихся до истечения срока действия сертификата HTTPS — отсутствие просроченных сертификатов Оценка эффекта от применения разных механизмов проверки подлинности Базовый Используется заголовок Authorization Формы Используется тело запроса Домен (встроен в Windows) Используется учетная запись MOM Action Безопасные файлы последовательности запросов и каналы связи, если данные конфиденциальные Советы по регистрации перемещений на веб-узле Осуществляется мониторинг URL-адресов HTTP и HTTPS; регистрируются только переходы на URL-адреса HTTP Создание запросов HTTPS вручную Разрешение трафика HTTP на время регистрации Записанные временные файлы cookie могут конфликтовать Удаление записанных файлов cookie из заголовка Агент МОМ не кэширует ответы, а Internet Explorer может это делать Изменить ожидаемый код состояния HTTP на 200 Автоматические перенаправления не смешиваются с зарегистрированными Методы веб-служб Веб-служба обрабатывает сообщения SOAP Протокол HTTP является предпочтительным механизмом транспортировки Упрощенное создание запросов из файла WSDL 67 Выбор одного или нескольких методов веб-служб для последовательности вызовов Предоставление заголовка и параметров для каждого вызова метода (по мере необходимости) Использование условий поиска для подтверждения наличия или отсутствия узлов XML в составе ответа Функция тестирования для проверки результатов вызова метода Подходит для динамичного вызова методов веб-служб Результаты вызова метода автоматически не передаются в качестве входных данных последующему методу Не подходит для веб-служб, использующих для проверки подлинности шифрование или маркеры сеансов Разработка настоящего клиента веб-служб и его запуск через МОМ в качестве синтетической транзакции 68 Пример возможностей систем мониторинга фирмы Microsoft System Center Operations Manager 2007 и System Center Configuration Manager 2007 (SCCM).Повышение эффективности Для оператора Единая операционная консоль с безопасностью на основе ролей Страницы обзора и интегрированные функции поиска для лучшего понимания и быстрого нахождения информации Для администратора Управление Active Directory с целью настройки обнаружения, учетных записей групп и агента Новые самонастраивающиеся пороговые значения оптимизируют оповещения в случае нарушения принятых шаблонов использования Для автора Удобное использование, настройка и создание отчетов Пакеты управления на основе XML с контролем версий Оптимально для Windows Решение проблем с помощью знаний, представлений, информационных панелей и встроенных задач Настройка параметров мониторинга через раздел My Workspace Упреждающее решение проблем с аварийными сбоями и зависаниями с помощью мониторинга исключений без применения агента Мониторинг использования, надежности и ошибок для Windows Vista, Windows ХР и Office Специальная служба для эффективной архивации журналов событий безопасности Быстрое решение проблем и снижение общей стоимости владения средой Windows 69 Управление, основанное на знаниях Знания являются ключевым компонентом OpsMgr 2007 и Dynamic Systems Initiative Знания можно найти: в документации, на электронной доске, на обычной салфетке Мы знаем, что знания хранятся у людей (разработчик приложений, ИТспециалист, cотрудники, работающие с информацией) Сбор знаний с помощью моделей Модели Помещение знаний в структуру, с которой может работать программное обеспечение Представление в формате XML Развитые взаимосвязи Структура приложения Модели основаны на схеме SDM (Systems Definition Model) Базовая технология платформы Windows Основа для продуктов System Center 70 Б Базовая модель состояния организации а з о в а я м о д е л ь с о с т о я н и я о р г а н Общее конфигурации Служба Организация SQL SVR Доступность Производительность Состояние конфигурации конфигурации конфигурации Состояние службы Windows Рис. 10 Состояние конфигурации и з а ц и и 71 Комплексный мониторинг службы Мониторинг состояния распределенных приложений вплоть до уровня оборудования Синтетические транзакции для мониторинга действий конечных пользователей Удобные шаблоны и конструкторы распределенных приложений для создания пакетов управления Архитектура Рис. 11 Полная интеграция консоли с помощью элемента управления ReportViewer Интеграция функций безопасности с безопасностью OpsMgr Сервер управления записывает собранные данные непосредственно в хранилище (без задержек, без DTS) Хранилище Содержит наборы данных для отдельных типов данных, поддерживающие автоматическое укрупнение, подготовку и оптимизацию Поддерживает несколько групп управления 72 Отчеты Понятные заголовки параметров Удивительные диаграммы Универсальность и повторное использование Пакет управления В пакете управления содержатся отчеты, их зависимости и средства локализации Пакет контролирует, какие данные отправляются в операционную базу данных, в хранилище или в оба места 73 MOM 2005 и OpsMgr 2007 Миграция хранилища данных По-настоящему актуальная тема: мы говорим о хранилищах, размеры которых в некоторых случаях превышают 2 ТБ. Более 80% объема занимают данные о производительности План переносить данные о производительности только для обнаруженных объектов с помощью средства из состава набора Resource Kit (после передачи продукта в производство) Это затрагивает саму суть отчетности: 119 отчетов MOM 2005 посвящены производительности. Миграция данных о производительности позволит клиентам использовать новые отчеты со старыми данными, а также новые способы укрупнения Новые функции SMS 2003 R2 и как будет выглядеть Microsoft System Center Configuration Manager 2007 Функциональные возможности SMS 2003 R2 содержит три инструмента: Средство сканирования для выявления (Scan Tool for Vulnerability Assessment) Средство инвентаризации для пользовательских (Inventory Tool for Custom Updates) Инструмент публикации пользовательских (Custom Updates Publishing Tool) уязвимостей обновлений обновлений Средство сканирования для выявления уязвимостей Для оценки уязвимости используется MBSA 2.0 Перед сканированием на клиентских системах развертывается MBSA 2.0 Предоставляются отчеты сканирования по типовым проблемам конфигурации ПО, определенных манифестом MBSA 2.0 Манифест неизменяемый Администрирование как в существующих средствах сканирования SMS 2003 Отчеты о 100 критических проблемах конфигурации Критические уязвимости Есть ли установленные и запущенные ненужные службы? Имеют ли общие папки надлежащие разрешения? Включен ли брандмауэр Windows? Включена ли политика надежных паролей? Включены ли незащищенные гостевые учетные записи? 74 Не слишком ли много локальных администраторов на одной машине? Vulnerability Assessment Scan Tool Обновление ПО (не-Microsoft). Текущая ситуация Как администратор сервера SMS разворачивает обновление сторонних поставщиков ПО? Сложно Определение компьютеров, нуждающихся в обновлении Определение, успешно ли прошло обновление Отсутствует масштабируемость Нагрузка по новым наборам для каждого обновления Медленное выполнение, если требуется пользовательский инструментарий Ограниченные возможности отчетов по соответствию стандартам Средство инвентаризации для пользовательских обновлений Inventory Tool for Custom Updates Позволяет выявлять и устанавливать необходимые обновления самых разных категорий для программных продуктов не-Microsoft Интегрируется в существующую инфраструктуру обновлений SMS 2003 Позволяет импортировать каталоги обновлений сторонних производителей Позволяет создавать собственные каталоги обновлений 75 ITCU Компоненты Средство публикации пользовательских обновлений (Custom Updates Publishing Tool) Создание и импорт в SMS каталогов обновлений Интегрированный в SMS сканнер Выявляет статус пользовательских обновлений на клиентских компьютерах Встроенные в SMS Web-отчеты Report on software compliance Одни и те же отчеты используются для обновлений сторонних производителей, пользовательских обновлений и обновлений Microsoft Встроенные в SMS средства развертывания обновлений Используется мастер DSUW для нстройки процесса развертывания обновлений на компьютерах, где это требуется И для пользовательских обновлений, и для обновлений сторонних производителей, и для обновлений Microsoft Средство публикации пользовательских обновлений Импорт, создание и управление каталогами обновлений Создание собственных каталогов обновлений ПО Импорт каталогов обновлений сторонних поставщиков ПО На сегодня доступны каталоги «Citrix», «Adobe», «1E» Любой поставщик ПО может обратиться в Microsoft для публикации собственных каталогов обновлений Публикация каталогов в SMS ITCU Схема каталогов обновлений Редактируемый XML-файл Разработана совместно командами разработчиков SMS, WSUS, System Center Essentials В перспективе планируется для использования и в других продуктах Microsoft Содержит в себе информацию о том, как выявить обновления и как их поставить ITCU.Правила выявления обновлений Правила выявления необходимых обновлений включают в себя: Процессорная архитектура и платформа Windows Правила для выявления файлов, данных из реестра, установленного ПО (MSI/MSP), запросы к WMI Логические комбинации всего выше перечисленного наличия 76 Custom Updates Publishing Tool Inventory Tool for Custom Updates Сканирование и развертывание обновлений Стандартный инструмент сканирования SMS выявляет наличие и необходимость установки обновлений, описанные в пользовательском каталоге Администрируются так же как и ITMU SMS пакеты, программы, объявления назначаемые на коллекции клиентов SMS Управляются из консоли администратора SMS Для развертывания используется мастер DSUW Нет необходимости дополнительного обучения администраторов Поддерживаются обновления в виде Microsoft Installer (MSI/MSP) или исполняемых из командной строки файлов *.exe Managing custom updates Итог (SMS2003 R2) SMS 2003 R2 – дополнение к SMS 2003 SP2 Средство сканирования для выявления уязвимостей Средство инвентаризации для пользовательских обновлений Инструмент публикации пользовательских обновлений Унифицированный механизм управления обновлениями с помощью SMS Custom update functionality provides SMS software update management to partners through ITCU 77 System Center Configuration Manager 2007 Ключевые направления развития Простота: Более простое проектирование и удобное развертывание Упрощенный пользовательский интерфейс с расширенными возможностями упорядочивания задач Уменьшение стоимости инфраструктуры за счет поддержки удаленных филиалов Единые процедуры для управления серверами, настольными и переносными ПК, устройствами с ОС Windows Mobile и встроенной ОС Развертывание: Единый процесс развертывания клиентской и серверной ОС Встроенные технологии Vista, включая работа с образами Оценка и планирование перехода на Windows Vista и Office 2007 Поддержка автономных носителей для полностью автономной подготовки новых машин к работе Безопасность: Интеграция с технологией Network Access Protection системы «Longhorn» Упрощенное обновление ПО благодаря шаблонам задач Безопасное управление клиентами через Интернет Безопасное сетевое кэширование состояния пользователя при развертывании операционной системы Конфигурация: Управление необходимой конфигурацией (Desired Configuration) на основе знаний с использованием System Definition Model (SDM) ИТ-политики для анализа соответствия корпоративным и нормативным требованиям Расширенное и улучшенное управление лицензиями и активами SCCM 2007 Новые возможности (архитектурные решения) Поддержка новых конфигураций: Кластерный SQL Server 2005 Именованный экземпляр SQL Server 64-bit системы сайта Системы сайта на сервере Longhorn SMS Administrator Console 78 MMC 3.0 Резервное копирование и восстановление базируется на VSS Подержка технологии Wake on LAN 2 формата передачи команды на «пробуждение» Интегрированная функциональность: Desired Configuration Monitoring Device Management OS Deployment Software Updates SCCM 2007 Новые возможности (инвентаризация) Расширяемый список аттрибутов, запрашиваемый из Active Directory AD System Discovery и AD User Discovery Обновлена инвентаризация аппаратных конфигураций Изменения Mof-файлов автоматически компилируются на клиентах Поддержка нескольких Mof-файлов Улучшена производительность Обновлен компонент Software metering Инвентаризация последних использованных программ Автоматическое создание правил Software Metering SCCM 2007 Новые возможности (взаимодействие с клиентами и безопасность) Переработана система безопасности Два режима безопасности взаимодействия клиентов с серверами SMS Mixed Mode (расширенный режим безопасности SMS 2003 с дополнениями) Native Mode (HTTPS с обязательным использованием PKI) Возможность блокировки клиентов Расширенная поддержка клиентов подключающихся через Интернет Некоторые системы сайта можно помечать для использования в Internet или Intranet Интеграция с технологией Network Access Protection: Проверка соответствия клиента политикам Карантин Динамическое изменение политик Контроль доступа к сетевым ресурсам Отслеживание соответствия политикам 79 SCCM 2007 Новые возможности (Software Distribution) Распространение ПО Окна обслуживания Интеграция с технологией «Wake on LAN» Побитовая репликация изменений пакетов Гибкая настройка повторного запуска программ Настройка интерфейса взаимодействия с пользователем Поддержка точек дистрибуции в филиалах (Branch Distribution Points) Настройка работы клиента с защищенной точкой дистрибуции SCCM2007 Новые возможности (Software Updates) Обновление ПО: Интеграция с WSUS 3.0 (обязательное требование) Политики обновления Интеграция с инструментами инвентаризации пользовательских обновлений Единый агент для всех типов обновлений Сканирование уязвимостей SCCM2007 Новые возможности (OS Deployment) Значительное расширение возможностей развертывания образов ОС Поддержка внешних носителей для образов Поддержка PXE-boot Каталог драйверов Варианты доставки образов на конечные компьютеры: С точки дистрибуции посредством SMB во время развертывания С точки дистрибуции по HTTP во время развертывания С точки дистрибуции с использованием BITS в локальный кеш клиента до начала процесса развертывания ( “download-and-execute”) С внешних носителей (сценарии Offline) CD DVD USB flash drive PXE интеграция Интеграция с Longhorn WDS PXE server Управляется как компонент SCCM 2007 (PXE Service Point) Сервер PXE настраивается на ответ «известным» или «неизвестным» клиентам Каталог драйверов 80 Каталог драйверов управляемых устройств Используется для создания одного образа на все конфигурации Может заполнять каталоги драйверов Vista Управляется компонентом Task Sequence Auto-Apply Drivers Apply Driver Package SCCM2007 Сценарии развертывания ОС Установка нового компьютера Свежая установка на новый компьютер «Зачистка и установка» Переустановка ОС на существующем компьютере с переносом пользовательских данных и настроек «С компьютера на компьютер» Установка нового компьютера с переносом пользовательских данных и настроек со старого Обновление существующей ОС Offline-установка Устновка с использованием CD, DVD, USB Установить с использованием PXE Интеграция с Windows Deployment Services SCCM2007 Новые возможности (Remote Tools) Инструмент полностью переписан Значительно улучшена производительность Основан на технологиях Vista Используемый протокол: RDP Часть функциональности от предыдущей версии: Нет необходимости спрашивать разрешения пользователя 3 уровня доступа Полный контроль Только просмотр Нет доступа «Удаленный помощник» и «Удаленный рабочий стол» также могут быть использованы 81 Внедрение ИС: через тернии к звездам Представьте себе типичный промышленный город Н-ск где-то в глубине России. Утро. Заводские гудки заставляют проснуться и бежать на работу, легкий дым не дает забыть о близлежащих заводах, ну а если вы отъедете от города, то множество бревенчатых изб вам напомнят про самобытность России. Согласитесь, это все отдает прошлым веком и не дает забыть о некогда популярной механизации. Но сейчас на дворе иной век и теперь изобретена новая панацея от всех бед - автоматизация. Как вы думаете, а она поможет нашему Н-ску? Сегодня для любого современного предприятия собственная информационная система столь значима, что сбои в ее работе могут привести к необратимым последствиям для него самого. Кроме того, бизнес-процессы и информационные технологии в современном офисе тесно взаимосвязаны, а значит, внедрение новой информационной системы необходимо рассматривать исключительно как изменение в организации работы предприятия в целом. В результате любой реинжиниринг лучше выполнять по хорошо продуманному плану, используя технологии Project Management и другие методики успешной реализации проектов, в том числе принципы формирования функциональных команд. Обычно для внедрения изменений, связанных с ИС предприятия, используется методика Джона Коттера - своеобразного гуру по вопросу управления изменениями в организациях. В своей книге "Leading Change" он выделил восемь стадий, которые необходимо пройти, чтобы добиться положительных результатов. Первая стадия, названная Коттером, - создание ощущения крайней необходимости предлагаемых интегратором изменений. И хотя каждый современный менеджер знаком с тезисом о том, что процесс повышения эффективности труда в организации - процесс бесконечный, многие руководители все же противятся нововведениям во вверенных им коллективах. Зачастую они попросту ленятся делать что-либо, если существующий уровень эффективности работы предприятия приемлем для них самих или для их руководства. Поэтому первоначальная задача интегратора новой информационной системы заключается в том, чтобы создать на предприятии своеобразную "революционную ситуацию", в рамках которой и "низы" не смогут жить по-старому, и "верхи" откажутся это делать привычным образом. Иными словами, любые изменения в организации предприятия должны быть четко аргументированы, а коллектив должен быть, как минимум, лоялен к ним или даже заинтересован в предлагаемой "революции". "Хитрость", способная заинтересовать работников организации в нововведениях, - вторая стадия внедрения изменений Коттера. Она заключается в том, чтобы вовлечь в функциональную группу (которая, собственно, и займется реинжинирингом ИС) представителей руководства компании. Это, несомненно, повысит доверие к реинженерам информационной системы со стороны коллектива 82 компании, а также в значительной степени стимулирует его к различным положительным проявлениям относительноу внедрения нововведений. После того как будет сформирована функциональная группа внедрения проектов, не мешало бы выработать совместное виденье перспектив и стратегий, которыми должен руководствоваться не только реинженер, но и его функциональная группа. На практике каждый член коллектива должен представлять конечную цель изменений, производимых консультантом. Для этого необходимо "втянуть" коллектив в разработку целей или хотя бы грамотно разрекламировать их, что вполне по силам даже начинающим интеграторам. При этом важно, чтобы осваиваемые рубежи притягивали, а не отпугивали сотрудников организации. Отношение к проекту, уже на начальной стадии его выполнения, должно быть максимально доброжелательным. Еще одна ступень правильного внедрения изменений организации по Коттеру - четвертая - касается передачи полномочий широкой группе активистов внедрения. Люди должны сообща работать над достижением общей цели, которую ранее усвоили и приняли "как свою". В конце концов, каждый член организации должен с чистой совестью сказать, что он и именно он, а не коллектив в целом, явился инициатором и подвижником "больших изменений". Впрочем, данная ступень, по мнению Коттера, является прямым следствием предыдущей. (Предыдущий шаг - члены коллектива должны видеть то же, что и "руководящая коалиция".) Из современной теория продуктивной мотивации следует: достижение краткосрочных побед - важнейший элемент успеха и поощрения функциональных команд и коллективов в целом. Ничто так не воодушевляет людей на новые победы, как достижение результата. Пусть небольшого и промежуточного, но всетаки результата. Поэтому любые положительные достижения необходимо популяризировать в коллективе, а победителей "венчать в лучах славы". Это может быть осуществлено в виде закрепления достижений и дальнейшего проведения изменений, которое в модели Коттера является следующим шагом на пути к успеху. Организация должна стабильно продвигаться к изменениям, без отстающих и особо опережающих субъектов. Это приведет к укоренению новых подходов в корпоративной культуре и изменению отношения к реинжинирингу от новаторского к "рутинному" и повседневному. В итоге, изменения должны стать чем-то само собой разумеющимся и, кроме того, быть закреплены в регламентах и процедурах компании. "Проект внедрения...." Именно такими словами, озаглавлено сотни проектов, которыми занимаются интеграторы. Впрочем, само понятие "проект" разобрать не помешает. Как правило, под термином "проект" подразумевается ограниченный во времени организационный стратегический план для создания уникального продукта или услуги, который может выполняться как одним человеком, так и коллективом. Данное определение проекта ничего не говорит о длительности выполнения работ 83 - оно может варьироваться в самых широких пределах. Неизменным остается лишь конечная цель проекта - получение прибыли или некоего стратегического результата, а также инструмент оптимизации хода выполнения работ - Project Management. Последний подразумевает использование определенных знаний, умений, средств и методов для достижения поставленных целей. Приведенное определение, позаимствованное из руководства по основам управления проектами (A Guide to the Project Management Body of Knowledge), созданного Project Management Institute, к сожалению, не отражает тех трудностей, с которыми приходится сталкиваться большинству компаний при реализации даже относительно несложных проектов. На наш взгляд, все они связаны с отсутствием у исполнителей современных знаний в области оптимального ведения проекта, а также неумения создать или организовать по-настоящему действенную функциональную команду. И если первая проблема решается достаточно просто обучением имеющегося персонала или наймом квалифицированного, то решение второй куда сложнее. Дело в том, что принцип формирования команды, принятый в нашем обществе, не правилен и преодоление стереотипов, связанных с ним, вызывает непонимание у руководства большинства компаний. Иногда дело доходит до саботажа в рядах менеджеров верхнего уровня (не являющихся владельцами компании). Не стоит забывать и об особенностях национального менталитета. К слову, они почему-то полностью нивелируют преимущества использования средств ускоренной разработки программных продуктов, зарекомендовавших себя с наилучшей стороны в западных компаниях. Только очень маленький проект может вести один человек. Фактически проведение проекта однозначно требует организации групповой работы. Из чего следует, что необходимо обладать знаниями по формированию рабочих групп знать, какие роли нужны для работы группы, уметь подбирать людей на эти роли. Для этого могут быть использованы различные методики формирования команд, для ускорения начальных стадий формирования групп, усиления мотивации работников. Эти техники произошли из области групповой психотерапии, игровой терапии, НЛП. В общем, организация групповой работы требует знаний и навыков из области управления и психологии, а также наличия лидерских качеств у руководителей. Одна из важнейших задач любого руководителя проекта или организации заключается в том, чтобы пробудить у своих подчиненных неподдельную заинтересованность к работе. В тоже время высшим пилотажем управленческой деятельности можно по праву считать способность менеджера раскрыть весь трудовой потенциал своего сотрудника, получить максимальный эффект от его пребывания в коллективе, а также взрастить полноценного лидера того или иного направления действия компании. Почти все корифеи современной школы бизнеса признают так или иначе, что работа с кадрами имеет гораздо большее значение, чем, например, стратегическое планирование или выстраивание процедур управления производственными процессами. И с этим достаточно трудно поспорить, ведь, собственно, кадрам в итоге и придется заниматься не только 84 разработкой бизнес-схем и стратегий, но и их воплощением в жизнь. Поэтому представляется весьма важным создать собственную корпоративную схему организации работы с персоналом. В общем случае управленческую работу можно поделить на три составляющих. Важнейшая из них - произведение менеджером точной оценки индивидуальных особенностей своих подчиненных. Не секрет, что у любого менеджера в ходе работы появляется собственный опытный механизм выявления и подготовки лидеров подшефного ему коллектива по тем или иным направлениям его деятельности. Кроме того, в организации формируется так называемый конвейер подготовки лидеров и ведущих специалистов (не путать с карьерной лестницей, направленной, правда, параллельно конвейеру подготовки), который является важнейшей составляющей мотивации сотрудников и базой для реализации долгосрочных планов и стратегий. Впрочем, именно конвейер подготовки лидеров из числа сотрудников персонала в большинстве случаев является наиболее слабым местом, так как ситуации, в которых на ключевые посты назначают людей, не удовлетворяющих предъявляемым к ним требованиям, имеют место сплошь и рядом. Многие управляющие (заметим, именно управляющие или владельцы компаний, а не профессиональные менеджеры) считают, что на место лидера команды должен быть поставлен человек, прекрасно исполняющий свои обязанности или приносящий большую часть дохода компании, поскольку в свое время сам управляющий был продвинут по соответствующей служебной лестнице, став на определенном этапе лидером. Понятно, что данный подход не верен или не совсем верен, так как основной чертой успешного бизнеса является его постоянное развитие. Именно поэтому лидером должен быть выбран тот работник, который сможет поднять бизнес на очередной уровень, а также не потерять (из-за отсутствия организаторских способностей) своих навыков долгосрочного и эффективного планирования работы порученного ему отдела. Лидер может и не быть начальником своего отдела, просто руководство должно оказывать всяческую поддержку (в том числе и материально-премиальную) его идеям. Само присутствие лидера-вдохновителя команды может стать неплохим мотивационным фактором для коллектива, поскольку лидер в глазах начальства и всего коллектива должен быть первым кандидатом на пост нового менеджера соответствующего отдела. Ситуация, когда в коллективе имеется два лидера, вполне возможна, однако она должна быть сведена до минимума по своей продолжительности, иначе другие сотрудники станут пассивными исполнителями чужих идей, а конкуренция между наиболее успешными сотрудниками начнет сводить их общие усилия на нет, повергнув компанию в пучину бюрократии. В этой ситуации многие менеджеры рекомендуют произвести наиболее успешного лидера в начальники отдела, в котором он был занят. Второго же лидера стоит переориентировать на новый, сходный с предыдущим круг задач, правда, не связанный с ним "политическими" нитями. Если управленческая структура компании матричная, то второй лидер 85 обычно перебрасывается на новый, затеянный им же проект, в ходе которого ему разрешается выбирать себе помощников из числа старой команды. Важно вовремя разглядеть лидера. Он может "скрываться" под "личиной" генератора идей. В крайнем случае, ему даже необязательно быть хорошим организатором, так как тандем талантливого идейного лидера и умелого менеджера может явиться куда более эффективным, чем посредственный управленец, занимающийся еще и стратегией отдела (компании). Также стоит понимать, что сотрудник, однажды возведенный на пьедестал лидера, все-таки должен контролироваться начальством. Во многих организациях для поддержания на должном уровне исполнительской дисциплины необходимо корректировать поведение даже самых высокопоставленных лиц. Руководителям на любом уровне управления следует постоянно стремиться к усовершенствованию своих сильных сторон и к искоренению недостатков. Когда у служащих есть для этого мотив, необходимые ресурсы и поддержка, они могут достичь намеченной цели, изменив свои поведенческие шаблоны и приобретая новые навыки и умения. В организации следует создать такую атмосферу, чтобы служащие с высоким лидерским потенциалом сами заботились о своем дальнейшем развитии, при этом организации не должна пускать столь важный управленческий процесс на самотек. Для этого организация должна обеспечивать работников с высоким потенциалом, получивших новое назначение и выполняющих планы своего развития, консультационной и материальной поддержкой. В любом случае, новые практические задания и назначения, требующие значительных усилий, - такие, как расширение должностных обязанностей или участие в работе целевой группы, - оказывают на людей большее воздействие, чем опыт, приобретенный в ходе тренингов. Поэтому неординарные тестовые задания должны стать для любого менеджера нормой. Правда, с точки зрения правильной мотивации, эти инициативы (прдусматривающие дальнейшее развитие служащего) должны оказывать умеренное влияние на цели его текущего рабочего задания, не добавляя излишней ответственности к имеющимся основным задачам, иначе это только отпугнет подчиненного от их выполнения. Системный взгляд Можно смело сказать, что выполняемый интегратором проект является живой системой. В нем есть много явных и неявных связей. Явные связи обусловлены логикой проекта, взаимосвязями подпроектов, формальной взаимосвязью рабочих групп. Неявные - следствие живого общения, дружбы и неприязни, личных интересов и целей вовлеченных в проект людей, целей и задач участвующих в проекте организаций, слухов, наблюдений за работой других внутри своей группы и за работой других групп, полной или неправильно понятой информации, желания или нежелания работать. Свести воедино всю эту информацию достаточно сложно, однако все-таки возможно, если прибегнуть к технике системного подхода. Этот подход разработан для упрощения картины 86 всего проекта до понимаемой схемы. Системный анализ позволяет определить, какие части системы имеет смысл выделять и как эти части связаны, как влияют друг на друга. Части системы, связи, временные задержки, влияние частей друг на друга и циклы обратной связи - вот основные составляющие таких схем. Системный анализ помогает в виде простой, часто одной, схемы охватить всю ситуацию в проекте, и, что самое главное, определить точку приложения усилий таким образом, что минимальные усилия (например, устраняющие препятствия к развитию системы) освобождают энергию системы, и система сама начинает развиваться и достигать новой ступени развития. В случае проекта - позволяет трезво оценить состояние проекта, найти препятствия продвижения проекта, определить необходимость, участок и объем вмешательства (если надо), позволяет увидеть, как можно ускорить проект без ущерба результату (если это возможно). "Замыленный взгляд" Выражения типа "взгляд со стороны", "со стороны виднее", "свежий человек" существуют не зря. При длительной работе над какой-либо проблемой в любой группе появляются стереотипы, привычки. Появляется то, чего никто не замечает, но люди задаются вопросом "почему это так?", однако толком никто ничего объяснить не может. Эти стереотипы могут касаться чего угодно: повторяющихся процедур, аргументов в спорах, объяснений проблем, отношений между людьми и группами, отношения к людям, ожиданий. Поэтому новому, порой даже случайному человеку, такие стереотипы буквально бросаются в глаза. Данная проблема на сленге специалистов называется "замыленым взглядом". Не факт, что все стереотипы вредны и всегда создают проблемы - когда они полезны, их называют добрыми традициями и они помогают сплотить коллектив. Впрочем, со стереотипным мышлением при решении разных задач необходимо бороться. Помогает обнаружить такие стереотипы либо "взгляд со стороны" (в том числе и нового человека), либо техники, позволяющие взглянуть на всю картину опять-таки не изнутри, а извне. Использование системного анализа как раз и является одной из таких техник. В общем случае также могут помочь и некоторые психологические приемы. Одним из них является диссоциация - попытка взглянуть на себя со стороны. На практике достаточно попросить своих коллег сделать фильм о том или ином участнике рабочей группы, работа которого, по вашему мнению, стала наименее креативной. Кроме того, может помочь изменение размера временного фрейма можно посмотреть на более поздние результаты достижения данной конкретной успешно достигнутой цели. Итак, для управления проектом внедрения крупной информационной системы нужно обладать большим количеством знаний навыков и методов анализа, не относящихся к области информационных технологий или предметной области. Нужно учитывать огромное количество психологических, межличностных факторов, личных качеств работников. Нужно учитывать политические факторы, организационные факторы, и это опять находится вне 87 области информационных технологий. Работая в проекте, намного труднее обнаружить тормозящие проект причины в силу привыкания к "быту" проекта это из области психологии, а не IT. Служба поддержки проектов Важнейшим моментом при реализации внедрения изменений в структуру ИС предприятия, может оказаться наличие службы поддержки проекта. Эта группа должна помочь руководителям проектов понять трудности и особенности их проектов, дать рекомендации, наметить план действий и ни в коем случае не должна оценивать проект на предмет организационных выводов. При необходимости служба поддержки проекта может также провести тренинги по построению видения целей, мотивации функциональных команд. Члены группы, службы поддержки проекта должны стать для интеграторов проектов своеобразными консультантами. Поэтому они должны проявлять знания и навыки из области управления изменениями, менеджмента, ведения проектов (в полном объеме: от создания технического задания и разбиения проекта на подзадачи до обеспечения проекта ресурсами), работы с группами (в том числе создание и подбор людей на роли в группе, приведение в рабочее состояние, оценка личных качеств лидера, мотивация, разрешение конфликтов), а также психологии. Консультанты-члены службы поддержки проекта по просьбе интегратора могут присутствовать на различных совещаниях с руководством либо коллективом предприятия, чтобы поддержать начальника внедрения проекта, если это требуется. По сути, цель службы поддержки проекта состоит в том, чтобы на профессиональном уровне осуществлять наблюдение со стороны и, если неоходимо, вмешиваться в проект. Заключение Итак, в данном обзоре перечислены типичные трудности IT-компании, внедряющей информационные системы в России. Трудности, заключающиеся в слабом учете непредметных сторон проекта. И предложен путь решения этих проблем посредством создания специальной службы, призванной выяснять реальное состояние дел на проектах и находить пути решения возникающих трудностей. Решения проблем проекта с помощью учета теории управления изменениями, налаживания групповой работы и вмешательств из области прикладной психологии 88 Архитектура современной информационно-аналитической системы Илья Волков, Илья Галахов ООО ИК СИБИНТЕК Статья опубликована в журнале "Директор ИС" №3, 2002год. Аннотация: В данной статье рассматривается архитектура современной информационноаналитической системы с точки зрения технологических процессов. Приводятся рекомендации по реализации этой архитектуры на примере различных подходов и инструментальных средств. Предисловие. В современном деловом мире в любых областях деятельности объемы информации, с которыми приходится сталкиваться организациям, просто колоссальны. И от того, в какой степени организация способна извлечь максимум из имеющейся в ее распоряжении информации, зависит успех. Залог успеха - в построении эффективной информационно-аналитической системы (ИАС). Использование в инфраструктуре предприятия информационно-аналитической системы объясняется рядом причин: стремлением к общей реорганизации бизнеспроцессов, желанием повысить качество деловой информации, необходимостью поддержки стратегического планирования и достижения высокоэффективных решений. Состав архитектуры современной ИАС Задачами любой информационно-аналитической системы являются эффективное хранение, обработка и анализ данных. В настоящее время накоплен значительный опыт в этой области. Эффективное хранение информации достигается наличием в составе информационно-аналитической системы целого ряда источников данных. Обработка и объединение информации достигается применением инструментов извлечения, преобразования и загрузки данных. Анализ данных осуществляется при помощи современных инструментов делового анализа данных. Архитектура современной информационно-аналитической системы организации в обобщенном виде представлена на Рис. 12. 89 Рис. 12. Архитектура современной информационно-аналитической системы. Разнообразие источников данных и необходимость их использования в каждом конкретном случае объясняется потребностью по-разному хранить информацию в зависимости от стоящих перед организацией задач Приведенная архитектура демонстрирует длинный путь, который проходят данные, прежде чем попасть на стол аналитику. Разнообразие источников данных и необходимость их использования в каждом конкретном случае объясняется потребностью по-разному хранить информацию в зависимости от стоящих перед организацией задач. Если попытаться классифицировать источники данных по типам и назначению, то каждый из них можно условно отнести к одной из трех групп: транзакционные источники данных, хранилища данных, витрины данных. Данные в систему могут заноситься как вручную, так и автоматически. На этапе первоначальной фиксации данные поступают через системы сбора и обработки информации в так называемые транзакционные базы данных. Транзакционных баз данных в организации может быть несколько. 90 Поскольку транзакционные источники данных, как правило, не согласованы друг с другом, то для анализа таких данных требуется их объединение и преобразование. Поэтому на следующем этапе решается задача консолидации данных, их преобразования и очистки, в результате чего данные поступают в так называемые аналитические базы данных. Аналитические базы данных, будь то хранилища данных или витрины данных, и есть те основные источники, из которых аналитик черпает информацию, используя соответствующие инструменты делового анализа. При этом информационно-аналитическая система среднего и крупного предприятия или организации должна обеспечивать пользователям доступ к аналитической информации, защищенной от несанкционированного использования и открытой как через внутреннюю сеть организации, так и пользователям сети интранет и Интернет. Таким образом, архитектура современной информационно-аналитической системы насчитывает следующие уровни: 1) сбор и первичная обработка данных; 2) извлечение, преобразование и загрузка данных; 3) складирование данных; 4) представление данных в витринах данных; 5) анализ данных; 6) Web-портал. Рассмотрим перечисленные уровни архитектуры и остановимся на примерах типовых инструментов, которые могут служить основой для построения каждого из них. Сбор и первичная обработка данных К первому уровню архитектуры ИАС относятся упоминавшиеся уже источники данных, как правило именуемые транзакционными или операционными источниками (базами) данных, являющимися частью так называемых OLTP-систем (online transactional processing). Транзакционные базы данных включают в себя источники данных, ориентированные на фиксацию результатов повседневной деятельности организации. Требования, предъявляемые к транзакционным базам данных, обусловили их следующие отличительные особенности: способность быстро обрабатывать данные и поддерживать высокую частоту их изменения, ориентированность, как правило, на обслуживание одного процесса, а не всей деятельности организации в целом. Примерами здесь могут служить базы данных, которые используются в биллинговых системах операторами сотовой связи, в автоматизированных банковских системах коммерческих и государственных банков, в Интернетмагазинах. Информация в таких базах данных ориентирована на конкретное приложение и управляется транзакциями, она сильно детализирована и часто корректируется. 91 Транзакционные базы данных отлично справляются с валом повседневной информации, которая должна рутинно обрабатываться каждый день, но не позволяют получить общую картину положения дел в организации в целом и редко могут служить источниками для проведения комплексного анализа. Итак, совокупность транзакционных источников данных образует нижнее звено архитектуры информационно-аналитической системы любой организации. В дальнейшем будем исходить из того, что ИАС предприятия строится на основе уже имеющихся на вооружении систем сбора и первичной обработки данных, включающих транзакционные источники данных. Извлечение, преобразование и загрузка данных Процесс извлечения, преобразования и загрузки данных поддерживается так называемыми ETL-инструментами (extraction, transformation, loading), предназначенными для извлечения данных из различных транзакционных источников нижнего уровня, их преобразования и консолидации, а также загрузки в целевые аналитические базы данных - хранилища данных и витрины данных. На этапе преобразования устраняется избыточность данных, проводятся необходимые вычисления и агрегирования. Трехступенчатый процесс извлечения, преобразования и загрузки должен осуществляться на основе установленного регламента. Складирование данных К третьему уровню архитектуры ИАС относятся источники данных, которые называют хранилищами данных (от англ. Data Warehouse). Хранилища данных включают в себя источники данных, ориентированные на хранение и анализ информации. Такие источники могут объединять информацию из нескольких транзакционных систем и позволяют анализировать ее в комплексе с применением современных программных инструментов делового анализа данных. Согласно определению родоначальника идеи складирования данных Б. Инмона, хранилище данных является предметно-ориентированной, интегрированной, некорректируемой, зависимой от времени коллекцией данных, предназначенной для поддержки принятия управленческих решений. Характерными особенностями хранилищ данных являются: относительно редкая корректируемость большинства данных, обновляемость данных на периодической основе, единый подход к поименованию и хранению данных вне зависимости от их организации в исходных источниках. Хранилище данных, являясь одним из главных звеньев архитектуры ИАС любой средней или крупной организации, выступает в качестве основного источника данных для всестороннего анализа всей имеющейся в организации информации Представление данных в витринах данных К четвертому уровню архитектуры ИАС относятся источники данных, называемые витринами данных (data marts), предназначенные для проведения 92 целевого делового анализа. Витрины данных строятся, как правило, на основе информации из хранилища данных, но могут также формироваться из данных, взятых непосредственно из транзакционных систем, когда хранилище данных в организации по каким-либо причинам не реализовано. По типу хранения информации витрины подразделяются на реляционные и многомерные. Витрины первого типа организуются в виде реляционной базы данных со схемой "звезда", где центральная таблица, таблица фактов, предназначенная в основном для хранения количественной информации, связана с таблицами-справочниками. Многомерные витрины организуются в виде многомерных баз данных OLAP (Online Analytical Processing), где справочная информация представляется в виде измерений, а количественная - в виде показателей. Информация в многомерной витрине данных представляется в терминах бизнеса в виде, максимально доступном конечным пользователям, что позволяет существенно снизить время на получение требуемой для принятия решений информации. С точки зрения пользователя, отличие витрин данных от хранилища данных заключается в том, что хранилище данных соответствует уровню всей организации, а каждая витрина обычно обслуживает уровень не выше отдельного подразделения и иногда может создаваться для индивидуального использования, отличаясь достаточно узкой целевой специализацией. Отличие витрин данных от транзакционных баз данных заключается в том, что первые служат для удовлетворения потребностей конечных пользователей, не являющихся профессиональными программистами: аналитиков, менеджеров разных уровней, решающих различные задачи бизнеса. Транзакционные же базы данных используются в основном операторами, отвечающими за ввод и обработку первичной информации, а не за ее анализ, нацеленный на поддержку принятия решений. Применение витрин данных, многомерных и реляционных, в сочетании с современными инструментами делового анализа данных позволяет превратить просто данные в полезную информацию, на основе которой можно принимать эффективные решения. Анализ данных К следующему уровню архитектуры ИАС организации относятся современные программные средства, именуемые инструментами интеллектуального или делового анализа данных (Business Intelligence Tools), или BI-инструменты. BI-инструменты позволяют управленческому звену организации проводить всесторонний анализ информации, помогают успешно ориентироваться в больших объемах данных, анализировать информацию, делать на основе анализа объективные выводы и принимать обоснованные решения, строить прогнозы, сводя риски принятия неверных решений к допустимому минимуму. 93 Инструменты интеллектуального анализа данных используются конечными пользователями для доступа к информации, ее визуализации, многомерного анализа и формирования как предопределенных по форме и составу, так и произвольных отчетов, создаваемых управленцем или аналитиком (без программиста). Как уже было сказано, в качестве входной информации для делового анализа выступают не столько "сырые" данные из транзакционных систем, сколько заранее обработанные данные из хранилища или представленные в витринах данных. Web-портал В настоящее время российские компании, вслед за западными коллегами, все активнее начинают внедрять у себя различные Интернет-технологии. Уже сегодня все больше специалистов, работающих не только в сфере информационных технологий, начинают понимать выгоду от использования этих решений в целях повышения эффективности своего бизнеса. Проведение интеллектуального анализа данных с применением программных решений не только в локальной среде, но и в среде интранет и Интернет, открывает аналитикам новые возможности работы с данными. Современные тенденции развития архитектуры информационноаналитической системы базируются на применении Интернет-технологий. Традиционный вид архитектуры ИАС в недавнем прошлом дополнился Webпорталом, постепенно приобретающим все более весомую роль в архитектуре ИАС. Возможность доступа к информации через привычный Web-браузер позволяет экономить на затратах, связанных с закупкой и поддержкой настольных аналитических приложений для большого числа клиентских мест. Реализация Web-портала позволяет снабжать аналитической информацией как пользователей внутри офиса, так и мобильных пользователей-аналитиков в любой точке мира, подключенных к порталу через Интернет. Реализация архитектуры ИАС Сегодня на рынке информационных технологий представлен широкий спектр инструментальных средств, предназначенных для быстрой реализации компонентов архитектуры ИАС. Использование таких инструментов позволяет не разрабатывать аналитические приложения заново, а воспользоваться готовыми современными технологиями и, следовательно, сократить время и затраты на их создание. Решение задачи обеспечения пользователей информацией в ИАС определяется в основном правильным подбором инструментов делового анализа. Но немаловажным является и выбор инструментов поддержки процессов извлечения, преобразования, загрузки и хранения данных. При реализации ИАС предприятия могут быть использованы программные решения как разных фирм-производителей - смешанные решения, так и одного производителя - платформенно-базированные решения. И в первом и во втором 94 случае имеются свои преимущества и недостатки. Поэтому выбор инструментов для архитектуры ИАС, несмотря на их многообразие, задача не из простых. На рынке не существует одного производителя, предлагающего лучшие решения всех требуемых для построения ИАС программных компонентов. Поэтому совместное использование наиболее подходящих решений от различных производителей позволяет повысить функциональную мощность ИАС. Критериями оценки инструментов могут выступать как их технические и стоимостные характеристики, так и скорость внедрения, а также уместность использования в каждом конкретном случае. Однако использование продуктов от разных производителей приводит к значительному усложнению архитектуры системы из-за разнородности инструментальных решений. Это усложнение объясняется необходимостью интегрирования не связанных друг с другом инструментальных решений. Кроме того, администрирование системы оказывается непростой задачей, учитывая несогласованность данных и метаданных, управляемых отдельными, не связанными друг с другом модулями платформ от разных производителей. Рассмотрим два подхода к реализации архитектуры ИАС: основанный на платформенно-базированном решении, представленном одним производителем, и основанный на смешанном решении, представленном несколькими производителями. Реализация архитектуры ИАС на основе платформеннобазированного решения Для начала рассмотрим вариант реализации архитектуры ИАС, когда используются компоненты одного производителя - поставщика платформы. Если пользоваться терминологией исследовательского центра Gartner, платформеннобазированное решение необходимо искать среди фирм - производителей так называемых BI-платформ (Business Intelligence Platforms). Данный сегмент рынка информационных технологий представлен 16 компаниями, приводимыми здесь в алфавитном порядке: AlphaBlox, Arcplan, CA, Comshare, Crystal, Hyperion, Info Builders, Microsoft, Microstrategy, Oracle, PeopleSoft, ProClarity, Sagent, SAP, SAS, Whitelight. Среди них выделяются следующие семь лидеров и претендентов на лидерство в данной области: Microsoft, SAS, Oracle, SAP, PeopleSoft, Info Builders, Hyperion (по материалу Gartner Research, "BI Magic Quadrants: A 'Recession-Proof' Market Challenged", 17.07.2001). Двое из перечисленных производителей, Microsoft и Oracle, в состоянии реализовать все уровни ИАС своими силами, не прибегая к инструментам третьих фирм. Решающий критерий, выделяющий этих производителей, - наличие собственной СУБД. Рассмотрим пример реализации ИАС организации инструментами Oracle. Соответствующий перечень продуктов представлен в Таблица 3. Таблица 3 95 Компоненты ИАС Назначение продукта Название продукта Анализ данных Web-портал Jracle Portal Регламентированная отчетность в Web Oracle Reports Services Произвольные запросы в Web Oracle Discoverer Многомерный анализ (OLAP) в Web Oracle JDeveloper с компонентом Oracle Business Inteligence Beans Регламентированная отчетность Oracle Reports Произвольные запросы Oracle Discoverer Многомерный анализ (OLAP), инстремет разработки клиентских мест Oracle JDeveloper с компонентом Oracle Business Inteligence Beans Извлечение знаний (data mining) Oracle Data Mining Suite Система управления многомерными витринами данных (OLAP) Oracle OLAP в сетях Интранет и Интернет в локальной сети (LAN) Извлечение, преобразование, загрузка и храниение данных многомерные Проектирование и создание многомерных витрин данных (OLAP) Витрины данных реляционные Хранилища данных СУБД для реляционных витрин данных Oracle Database Проектирование и создание реляционных витрин данных Oracle Warehouse Builder ETL - компонент для хранилища данных Oracle Warehouse Builder СУБД для хранилища данных Oracle Database Проектирование и создание хранилища данных Oracle Warehouse Builder Вкратце поясним назначение упомянутых в таблице программных продуктов с точки зрения их использования для реализации ИАС. 96 Инструменты для извлечения, преобразования, загрузки и хранения данных (ETL) Oracle Warehouse Builder - это среда для разработки и реализации хранилищ и витрин данных. Построенный на базе открытой архитектуры Common Warehouse Model, Warehouse Builder обеспечивает решение целого ряда задач. К ним относятся проектирование, создание и администрирование хранилища данных, разработка и генерация процедур извлечения, преобразования и загрузки данных из различных источников, управление метаданными и интеграция инструментальных средств доступа. Oracle Database, система управления базами данных, - основа платформенного решения компании Oracle. Oracle Database используется в качестве СУБД для хранилищ и реляционных витрин данных. Для многомерных витрин данных используется Oracle OLAP, неразрывно связанный с СУБД Oracle Database. Развиваемая до недавнего времени линейка OLAP-продуктов под названием Express в настоящее время переписывается на программном уровне под новую платформу Oracie9i и станет частью Oracle OLAP. Впервые об этом было объявлено на конференции Оracle OpenWorld 2000. Инструменты делового анализа Платформа фирмы Oracle в части инструментов для делового анализа данных отличается не столько готовыми настольными инструментальными средствами с предопределенным интерфейсом и набором функциональных возможностей, сколько наличием мощного инструментария для разработки клиентских мест конечных пользователей. Это позволяет создавать тонко настроенные аналитические приложения для каждого конечного пользователя в отдельности. Произвольные запросы и регламентированные формы отчетов За регламентированную отчетность в платформе Oracle отвечает продукт Oracle Reports - визуальное средство разработки и публикации стандартных форм отчетов. Наличие визуального интерфейса и встроенных мастеров (wizards) позволяет сократить время разработки сложных форм отчетов. Формы отчетов на базе Oracle Reports готовятся квалифицированными специалистами, а уже сформированные отчеты могут запускаться конечными пользователяминепрограммистами. За нерегламентированную отчетность отвечает продукт Oracle Discoverer инструмент для формирования произвольных форм отчетов, построения нерегламентированных запросов и анализа данных. Он обеспечивает доступ к информации, содержащейся в реляционных хранилищах и витринах данных, а также в транзакционных системах, в том числе не обязательно работающих под управлением СУБД Oracle. Для того чтобы конечный пользователь-непрограммист смог самостоятельно просматривать интересующие его срезы информации, в программном продукте используется слой метаданных, описываемый 97 разработчиком, позволяющий скрыть от пользователей сложность работы с данными на программном уровне, представив информацию на деловом языке. Многомерный анализ данных Oracle OLAP предназначен для построения аналитических систем, основанных на принципах многомерной технологии. Этот компонент позволяет хранить и обрабатывать в одной и той же базе данных реляционную и многомерную информацию. Средства Oracle9i Java OLAP API позволяют поддерживать многомерную модель, предоставляя набор математических, статистических и финансовых функций для решения задач прогнозирования, планирования, оценки ситуации и выявления тенденций. По существу, OLAP API является созданным на Java объектно-ориентированным программным интерфейсом для OLAP-запросов. Разработчикам OLAP-приложений для Web компания Oracle предлагает воспользоваться программным модулем Oracle JDeveloper с компонентом Oracle Business Intelligence Beans. Разведка данных Инструментальная среда Oracle Data Mining (прежнее название Darwin) предназначена для анализа данных методами, относящимися к технологии разведки данных. Oracle Data Mining поддерживает такие этапы технологии извлечения знаний, как постановка задачи, подготовка данных, автоматическое построение моделей, анализ и тестирование результатов, использование моделей в реальных приложениях. Web-портал Программный продукт Oracle Portal позволяет представить отдельные компоненты делового анализа данных в Web-среде как одно целое. Oracle Portal предназначен для быстрого развертывания информационного портала организации и используется в качестве готового решения. Основная цель его использования снизить объем ручного программирования за счет использования готовых компонентов информационного портала, а также визуальных интерактивных средств разработки (wizards). В рамках Oracle Portal имеется возможность самостоятельно создавать и поддерживать порталы без привлечения Webдизайнеров. Несмотря на, казалось бы, очевидные преимущества реализации ИАС на основе платформенно-базированного решения, нужно вспомнить о ряде ограничений, когда такой подход к созданию ИАС не совсем применим. Очень редко организация начинает строить ИАС с нуля. В реальных условиях желание использовать комплексное решение одной фирмыпроизводителя наталкивается на стремление сохранить уже имеющиеся наработки, представленные в виде отдельных систем, выполненных в разное время и в различных средах. При этом отказ от действующих систем зачастую невозможен, а их перевод на платформу выбранного производителя ведет к значительным затратам. 98 Кроме того, комплексное решение одного производителя на сегодняшний день СУБД-зависимое. Это объясняется тем, что основные производители программного обеспечения для ИАС стремятся к максимальной интеграции предлагаемых ими решений. Поэтому желание использовать один или несколько инструментов заставляет организацию использовать остальные продукты этого поставщика, что не всегда соответствует желанию заказчика. К примеру, инструменты делового анализа данных могут быть неразрывно интегрированы с СУБД. Не стоит также забывать о рисках: комплексное решение от одного производителя увеличивает риск, связанный с долгосрочными перспективами развития ИАС. Как известно, ставка на одну лошадь может быть слишком рискованной. Реализация архитектуры ИАС на основе смешанного решения Учитывая упомянутые нами задачи корпоративной информационноаналитической системы - объединение, хранение и анализ информации, чтобы избежать процесса трудоемкой интеграции отдельных продуктов для смешанного решения, попытаемся выделить группы программных продуктов, способные реализовать архитектуру ИАС крупными блоками. В качестве таких групп для смешанного решения могут выступать инструменты делового анализа и СУБД. В терминологии Gartner интегрированные инструменты делового анализа данных относятся к так называемым BI-пакетам (Enterprise BI Suites), образующим отдельный сегмент рынка ИТ. Этот сегмент представлен 14 компаниями-производителями: Actuate, AlphaBlox, Business Objects, Brio, CA, Cognos, Crystal, Hummingbird, Information Builders, Microsoft, MicroStrategy, Oracle, Sagent, Viador. Две компании - Cognos и Business Objects лидируют в течение ряда лет (материалы Gartner Research, BI Magic Quadrants: A 'Recession-Proof' Market Challenged, 17.07.2001). Для примера реализации смешанного решения используем инструменты делового анализа данных фирмы Cognos и СУБД фирмы Oracle. Соответствующий перечень продуктов для примера реализации ИАС на основе смешанного решения представлен в Таблица 4. Таблица 4 Компоненты ИАС Назначение продукта Название продукта Платформа Анализ данных Web-портал Upfront Регламентированная отчетность в Web Cognos Series 7 Impromptu Web Reports Произвольные запросы в Web Congos Query Многомерный анализ (OLAP) в Web PowerPlay Enterprise Server в сетях Интранет и Интернет 99 Компоненты ИАС в локальной сети (LAN) Назначение продукта Название продукта Визуализация и выявление приоритетов в Web VisualizerWeb Регламентированная отчетность и произвольные запросы Impromptu Многомерный анализ (OLAP) PowerPlay Извлечение значений (data mining) 4Thought, Soenario Визуализация и выявление приоритетов Visualizer Платформа Cognos Series 7 Единый модуль Architect описания мегаданных Извлечение, преобразование, загрузка и храниение данных многомерные Витрины данных реляционные Хранилища данных Система управления многомерными витринами данных (OLAP) PowerPlayTransformation Server Проектирование и создание многомерных витрин данных (OLAP) PowerPlayTransformer ET -компонент для многомерных витрин данных DecisionStream ET -компонент для реляционных витрин данных DecisionStream СУБД для реляционных витрин данных Oracle Database Проектирование и создание реляционных баз данных Oracle Warehouse Builder ETL - компонент для хранилища данных Oracle Warehouse Builder Cognos Series 7 Oracle9i СУБД для хранилища Oracle DataBase данных Oracle9i 100 Компоненты ИАС Назначение продукта Название продукта Проектирование и создание хранилища данных Oracle Warehouse Builder Платформа Следует отметить, что BI-пакет Cognos включает в себя набор интегрированных друг с другом BI-инструментов. Тесная интеграция программных компонентов в единую пакетную платформу достигается за счет того, что BI-инструменты объединены общими модулями описания метаданных, разграничения прав доступа, а также за счет Web-портала - единой точки входа Интернет-пользователей в среду для работы с корпоративной информацией. Полнота решения, позволяющая претендовать на более значительный по сравнению с занимаемым рынок BI-платформ, достигается использованием ETLинструмента для создания витрин данных (реляционных и многомерных). Витрины данных, многомерные и реляционные, создаются инструментами DecisionStream и PowerPlay Transformer. Для интеллектуального анализа данных используются инструмент генерации отчетов Impromptu, инструмент многомерного анализа - PowerPlay, инструменты разведки данных - Scenario и 4Thought, инструмент визуализации данных Visualizer. В качестве программного модуля для описания метаданных выступает модуль Architect - единый для всех инструментов анализа данных. Интернет-портал, помогающий мобильным пользователям подключиться к анализу корпоративной информации, организуется при помощи инструмента Upfront. Рассмотрим подробнее инструменты Cognos, отвечающие за поддержку процессов извлечения, преобразования, загрузки, хранения и делового анализа данных (Рис. 13. Пакет делового анализа Cognos). 101 Рис. 13. Пакет делового анализа Cognos Инструменты для извлечения, преобразования, загрузки и хранения данных (ETL) Аналитики редко работают с "сырыми" данными из транзакционных баз данных, предпочитая черпать информацию из витрин и хранилищ данных. Исходя из этого пакетная платформа Cognos включает также инструмент предварительной обработки информации для последующего использования, что обеспечивает законченность и полноту предлагаемого решения. При помощи инструмента DecisionStream происходит предварительная подготовка данных, то есть извлечение, преобразование и загрузка данных в аналитические источники данных (многомерные и реляционные) для эффективной работы инструментов OLAP-анализа, генераторов отчетов, инструментов разведки данных, визуализации и выявления приоритетов. DecisionStream способен подключаться к нескольким источникам информации реляционного и нереляционного формата, объединять и преобразовывать данные и на их основе создавать витрины данных в виде реляционной схемы "звезда" (например, в базе данных Oracle), а в дополнение представлять данные в виде многомерной модели, где информация представляется в виде измерений и показателей. Возможность автоматизации создания, наряду с реляционной базой данных, ее многомерной модели выгодно отличает программный продукт Cognos DecisionStream от обычных инструментов извлечения, преобразования и загрузки данных. Способность объединения разрозненных данных в единый источник хранения информации, их обработка и связанное со всем этим увеличение скорости доступа к данным делают DecisionStream незаменимым средством для информационно-аналитических систем, где требуется быстрый отклик системы на запросы пользователя в получении данных для изучения и анализа. 102 Описание метаданных Инструмент описания метаданных Cognos Architect отвечает требованиям централизованного управления метаданными, что обеспечивает интеграцию инструментов Cognos. Architect является центральным ядром создания и управления всеми метаданными и бизнес-правилами организации. Таким образом, описанные в одной модели инструмента Architect метаданные становятся доступны в любом BI-инструменте Cognos. Инструментальный модуль Architect позволяет описать доступ к источникам информации, логические бизнеспредставления, масштабы каждого аналитического приложения. Результатом унифицированного описания метаданных становится правильное и непротиворечивое представление данных во всей организации. Инструменты делового анализа Инструменты делового анализа данных компании Cognos позволяют проводить весь спектр делового анализа: строить запросы и формировать формы отчетов на реляционных данных, проводить OLAP-анализ на многомерных данных, осуществлять разведку данных (data mining), а также визуализировать информацию и выявлять приоритеты. Произвольные запросы и регламентированные формы отчетов Решения Cognos в области построения запросов и работы с отчетами позволяют обеспечить пользователей отчетами в необходимом формате и на требуемой платформе (Windows, Excel, Web). Для руководителей, принимающих решения, средства Cognos обеспечивают доступ к информации в удобной для них форме (таблицы, диаграммы, гистограммы, трехмерные графики и т. д.), а для аналитиков предоставляется возможность просматривать информацию практически любого уровня сложности, включая создание запросов, исследование данных и навигацию в Web. Таким образом, в зависимости от задач, стоящих перед конечным пользователем, подбираются соответствующие инструментальные средства. Ключевым продуктом для регламентированной отчетности выступает Cognos Impromptu, для нерегламентированных запросов - Cognos Query. Многомерный анализ данных Компания Cognos имеет в своем распоряжении фактически одно из самых лучших OLAP-решений, существующих на сегодняшний день на рынке инструментов аналитической обработки данных. Согласно результатам исследования рынка OLAP-инструментов (www.olapreport.com), компания Cognos с инструментом PowerPlay уверенно занимает вторую по величине долю мирового рынка OLAP-систем после Hyperion. Основная особенность OLAP-инструмента компании Cognos заключается в эффективной автоматизации процесса создания OLAP-приложений, что позволяет значительно сократить срок разработки для систем практически любой сложности, используя лишь внутренние людские ресурсы организации. 103 Сложность задачи и выбранная конфигурация инструмента PowerPlay определяет масштаб создаваемых OLAP-систем. С помощью инструмента PowerPlay могут разрабатываться системы для одного пользователя, группы пользователей внутри департамента, нескольких отделов, а также системы масштаба организации, пользователями которых могут быть даже сторонние лица или организации, авторизованные для работы с информацией. Решения Cognos на базе OLAP-технологии открывает Windows-, Excel- и Web-пользователям удобный доступ к представленной на их деловом языке многомерной информации, предназначенной для просмотра, формирования отчетов и проведения OLAP-анализа. Инструмент Cognos PowerPlay позволяет исследовать данные под разными углами зрения, обеспечивая многомерный анализ данных. Благодаря интеграции BI-инструметов компании Cognos многомерные данные могут быть использованы для дальнейшего изучения инструментами разведки данных, визуализации и выявления приоритетов. Разведка данных Решения Cognos в области разведки данных (data mining) помогают исследовать важные корреляции в данных, обнаруживать скрытые тенденции и строить прогнозы. Инструменты разведки данных Scenario и 4Thought помогают легко определить, какие факторы влияют на ключевые показатели бизнеса, например на прибыль, объемы продаж, лояльность целевой группы покупателей и др. Инструмент разведки данных Scenario позволяет оценить влияние различных факторов на выбранный в процессе анализа целевой показатель. Результаты анализа представляются в виде классификационных и регрессионных деревьев, именуемых также деревьями решений. При этом осуществляется поиск исключений, направленный на выявление элементов, статистически не удовлетворяющих обнаруженным характерным взаимосвязям в данных. Инструмент разведки данных 4Thought, использующий нейросетевую технологию, позволяет строить сложные нелинейные модели, устойчивые по отношению к неточным, "зашумленным" и неполным данным. 4Thought доступен даже тем менеджерам, которые детально не знакомы со статистическими методами оценки данных, и позволяет им проводить на имеющихся выборках данных анализ "что - если", строить прогнозы. Одно из достоинств инструментов Scenario и 4Thought состоит в том, что в качестве входной информации для разведки данных эти инструменты способны брать данные практически из любой аналитической многомерной базы данных: Cognos PowerCubes, Oracle Express, SAP BW, Hyperion Essbase, IBM DB2 OLAP Server, Microsoft SQL Server OLAP Services, NCR TeraCube. Обнаруженные благодаря использованию инструментов разведки данных скрытые тенденции могут служить основой для принятия квалифицированных 104 управленческих решений и, следовательно, являться предпосылкой к успешному проведению стратегического планирования. Визуализация информации Известно, что графическая информация в отличие от текстовой гораздо быстрее воспринимается человеком. Представление данных в интуитивно понятном для руководителя виде позволяет ориентироваться в больших объемах информации, отсеивая ненужную. Решения Cognos в области визуализации данных и выявления приоритетов позволяют в процессе просмотра и анализа выделить из большого объема данных лишь ключевую информацию и сделать на ней акцент. Основным инструментом Cognos для визуализации данных и выявления приоритетов в среде Windows и Web является Visualizer. Расширенный набор визуальных шаблонов представления информации - от двухмерных и трехмерных диаграмм и графиков для количественных показателей до географических карт для отображения региональных зависимостей, а также специальные семафоры и визуальные элементы, использующиеся для выявления приоритетов, позволяют сократить время на поиск требуемой информации. Результаты, полученные в процессе визуализации данных и выявления приоритетов, являются основой для принятия эффективных решений. Web-портал Инструментальные средства Cognos для Интернета позволяют пользователям подготавливать отчеты и формировать запросы к базам данных, строить прогнозы, работать с информацией по уже готовым формам отчетов, проводить полноценный OLAP-анализ многомерных данных, визуализировать информацию и выявлять приоритеты (scorecarding). Причем все перечисленные возможности по работе с информацией доступны пользователям без услуг программистов. Инструментом создания и настройки Интернет-портала для платформы Cognos является модуль Upfront. Создаваемый с помощью Upfront портал может быть интегрирован в существующий у организации портал, в интранет и/или экстранет-решения (B2B), а также использован отдельно. Создание Web-портала осуществляется настройкой среды публикации и не требует программирования. Таким образом, модуль Upfront предоставляет администраторам централизованное управление через настраиваемый интерфейс, а конечным пользователям, находящимся в пределах или вне сетевого экрана (firewall), - единую точку входа, через которую осуществляется доступ к информации, имеющей различные форматы представления. При этом любой пользователь, имеющий установленный Интернет-браузер и доступ к корпоративной информации, получает возможность работать с заранее подготовленными формами отчетов по реляционным или многомерным данным, а также самостоятельно формировать и публиковать отчеты для личного или совместного использования. Помимо возможности манипулирования реляционными данными и OLAP-анализа, пользователям 105 доступен инструмент визуализации данных и выявления приоритетов. Upfront интегрирован с OLAP-инструментом PowerPlay, генератором отчетов Impromptu Web Reports, генератором Cognos Query и инструментом визуализации и выявления приоритетов Visualizer Web. Кроме того, в портале без дополнительных настроек сохраняется возможность работать с документами в привычных для пользователя форматах Excel, Word, PDF. Заключение Итак, при реализации ИАС на основе смешанного решения, чаще всего используемого на практике, водоразделом по поставщикам может служить деление продуктов по принципу принадлежности к уровням архитектуры ИАС. При этом группа инструментов анализа данных может быть независимой от группы инструментов извлечения, преобразования, загрузки и хранения, то есть каждая из этих групп может быть представлена отдельным производителем. Инструменты второй группы целесообразно выбирать от поставщиков СУБД, а инструменты делового анализа - от поставщиков, специализирующихся на спектре инструментов делового анализа данных. Очевидно, что при выборе программных средств для реализации ИАС в каждом конкретном случае нужно искать некое сбалансированное решениекомпромисс. При этом окончательное решение, какой из двух подходов использовать, платформенно-базированный или смешанный, остается за директором информационной службы и обычно осуществляется с привлечением консультантов на основе оценки технико-экономических показателей. 106 Защищенные информационные системы Приведенный ниже документ является пересмотренной версией документа о концепции защищенных информационных систем (Trustworthy Computing), опубликованного в январе 2002 года. Эта версия вобрала в себя множество ценных замечаний, полученных нами с тех пор, как увидел свет первоначальный документ. Большое спасибо всем, кто предложил свои идеи и помощь. Почему защищенность? В то время как многие технологии, в которых используется вычислительная техника, продемонстрировали свою необычайную надежность и защищенность — компьютеры помогли людям долететь до Луны и вернуться обратно, они управляют важнейшими системами авиаперевозок с миллионами рейсов в год и ежедневно переводят триллионы долларов по всему земному шару — в общем и целом компьютеры не достигли того уровня, чтобы люди были готовы явным или неявным образом доверить им свою жизнь. Многие не хотят доверять сегодняшним компьютерным системам свою личную информацию, например, финансового или медицинского характера, поскольку их все сильнее беспокоит уровень защищенности и надежности этих систем, которые, по их мнению, представляют собой существенный риск для общества. Если использование компьютеров действительно распространится на все стороны жизни — и тем самым реализуется беспредельный потенциал информационных технологий — то нам придется сделать компьютерную экосистему1 достаточно защищенной, чтобы люди не волновались из-за ошибок и неустойчивости в ее работе, как это происходит сегодня. Защищенность — широкое понятие, и, чтобы сделать что-то защищенным, помимо основательной работы инженеров нужна и социальная инфраструктура. Все системы отказывают время от времени, но юридическая и коммерческая практика, в рамках которой они существуют, могут компенсировать тот факт, что ни одна технология никогда не будет безупречной. Таким образом, это не только борьба за то, чтобы сделать программное обеспечение защищенным. Поскольку компьютеры в какой-то степени уже утратили доверие людей, нам предстоит преодолеть существующее положение дел, когда нередко случаются отказы и сбои машин, программ и систем. Нам необходимо будет убедить людей, что системы, программы, службы, люди и компании вместе взятые вышли на новый уровень готовности к работе, надежности и конфиденциальности. Нам придется преодолеть ощущение незащищенности, которое люди сейчас испытывают по отношению компьютерам. 1 Здесь под экосистемой понимается совокупность субъектов компьютерной сферы (государство, коммерческие компании, органы стандартизации, пользователи), действия которых должны совместно обеспечить возможность создания защищенных информационных систем. 107 Концепция «Защищенные информационные системы» включает целый ряд действий, которые необходимо предпринять для того, чтобы люди, используя устройства на базе компьютеров и программного обеспечения, чувствовали себя так же комфортно, как сегодня при использовании устройств, питающихся от электрической сети. Этот процесс может занять 10—15 лет — как для ИТиндустрии, так и для всего общества. Это подразумевает коренные перемены не только в том, каким образом мы пишем и распространяем программы, но и в том, как наше общество видит использование компьютеров в целом. Есть текущие проблемы, требующие решения, и есть фундаментальные вопросы для исследований. Есть шаги, которые могут и должны предпринимать отдельные люди и компании, но есть и проблемы, которые могут быть решены только совместными усилиями консорциумов, исследовательских сообществ, государств и всего мира в целом. Ситуация История Обществу довелось пережить ряд крупных технологических скачков, сформировавших его культуру: аграрная революция, открытие обработки металлов, промышленная революция, появление электричества, телефонной связи, телевидения и, конечно же, микропроцессоров, благодаря которым возникли персональные компьютеры. Каждый из этих скачков в корне изменял образ жизни, работы, общения и развлечений миллиардов людей. До сих пор в развитых странах персональные компьютеры применялись лишь для решения офисных задач. (Более крупные компьютерные системы также произвели революцию в сфере производства.) Тем не менее, неуклонное совершенствование технологий и снижение цен означает, что технологии на базе персональных компьютеров в конечном итоге станут строительными блоками на работе и дома у каждого человека, а не только специалистов, работающих в офисе. Прогресс в ИТ-индустрии за последние четверть века напоминает первые десятилетия развития электричества. Впервые электричеством стали пользоваться в 80-х годах XIX века мелкие предприятия с большими затратами труда, где для повышения производительности можно было использовать способность электрической энергии к распределению (например, один источник мог снабжать энергией несколько электромоторов в разных частях завода). На ранней стадии развития электричество в доме было настоящей роскошью, и в богатых домах его использовали в основном в электрических лампах. Было также и немало сомнений по поводу безопасности электричества в целом и электрических устройств в частности. Электричество ассоциировалось с молнией, смертоносной природной силой, и не было никаких гарантий, что некондиционные устройства не принесут смерть своим владельцам. В период 1900—1920 годов все изменилось. Жители городов и быстрорастущих предместий получали все более широкие возможности доступа кразличным видам энергии, и конкуренция со стороны нефти и газа снизила цены 108 на электричество. Увеличение числа электрических устройств, облегчающих труд людей, например, пылесосов и холодильников, означало, что зависимость домашних хозяйств от электричества постепенно росла. Маркетинговые кампании производителей электричества и появление знаков соответствия стандартам (например, создание Лаборатории по технике безопасности в Соединенных Штатах) ослабили тревоги потребителей. Технология не была совершенно безопасной и надежной, но в какой-то момент в начале XX века стала безопасной и надежной в достаточной степени. В компьютерной области мы еще не вышли на эту стадию: мы пока на уровне промышленного использования электричества в XIX веке. Компьютерам еще предстоит затронуть и улучшить каждую сторону нашей жизни — но это обязательно случится. Трудно предсказать в подробностях, какое воздействие в конечном итоге окажут компьютеры, — точно так же, как трудно было предвидеть последствия появления электричества, водоснабжения, газа, телеграфной и телефонной связи, воздушных полетов и любых других новшеств. Чтобы компьютеры достигли того уровня, когда люди будут так же рады иметь в любом устройстве микропроцессор, как они доверяют электричеству, необходимо добиться такой же относительной защищенности. «Относительной» — поскольку стопроцентной защищенности никогда не достигнет ни одна технология: напряжение в сети скачет и исчезает, прорываются водопроводы и газопроводы, рвется телефонная связь, самолеты терпят катастрофу и так далее. 2 Защищенные технологии в целом Все общепринятые технологии — такие как электричество, автомобили или телефоны — вошли в нашу повседневную жизнь и пользуются доверием, поскольку они почти всегда готовы к работе, когда мы в них нуждаемся, они делают то, что нам от них нужно, и работают так, как и было обещано. Почти любой человек в развитом мире может купить новый телефон и включить его в телефонную розетку, не волнуясь о том, будет он работать или нет. Для нас само собой разумеется, что, сняв трубку, мы услышим гудок, а когда дозвонимся, то сможем слышать собеседника. Мы исходим из того, что ни сосед, ни страховой агент с нашей улицы не смогут подслушать разговор или получить список тех, кому мы звонили. И мы, как правило, предполагаем, что телефонная компания будет предоставлять услуги и взимать за них плату согласно своим обязательствам. Усилия инженеров, практика бизнеса и регулирование в совокупности создали ситуацию, когда люди воспринимают телефонную службу как должное. Можно выделить три общих качества, которые, по мнению большинства людей, должны присутствовать в любой защищенной технологии: безопасность, безотказность и деловая добросовестность (т. е., добросовестность организации, предоставляющей технологию). Эти категории, а также их проявление в области использования компьютеров, будут более подробно рассмотрены ниже. 109 Защищенные информационные системы Компьютерные устройства и информационные службы смогут распространиться действительно повсеместно, когда они станут настолько надежными, что о них можно будет просто забыть. Другими словами, к тому времени, когда компьютеры начнут проникать почти во все сферы нашей жизни, мы должны иметь возможность им доверять. При этом методы создания компьютеров и методы, которыми мы сегодня создаем службы на основе компьютеров, по сути, не настолько сильно изменились за последние 30—40 лет. Но это должно произойти. Модель защищенных информационных систем Нам не удалось найти существующую классификацию, которая могла бы послужить моделью для обсуждения вопросов в области защищенных информационных систем. И хотя существует множество разнообразных концепций защищенности, каждая из них охватывает только узкую область. Например, есть концепции доверия в операциях электронной коммерции и взаимного доверия между системами удостоверения личности, и есть анализы восприятия компьютеров в обществе; однако подлинно эффективный подход должен объединять различные аспекты: и с инженерной точки зрения, и с точки зрения политики в этой области и пользователей. При этом даже лишь с инженерной точки зрения наша задача шире, чем, например, в моделях SysTrust/SAS702, которые имеют дело только с крупными онлайновыми системами. Во-первых, есть сама техника. Она должна быть достаточно надежной, чтобы мы могли встраивать ее во всевозможные устройства — другими словами, она не должна отказывать чаще, чем другие сравнимые по важности технологии в нашей жизни. Затем, есть программное обеспечение, работающее на этой технике: считают ли люди его настолько же надежным? И, наконец, существуют компоненты-службы, которые также во многом зависят от программного обеспечения. Это особенно сложная проблема, поскольку сегодня мы должны обеспечивать надежность комплексных, глубоко взаимосвязанных (а иногда и интегрированных) систем. Поскольку защищенность — понятие сложное, полезно проанализировать задачу создания защищенных информационных систем с нескольких различных точек зрения. Мы зададим три уровня, на которых будем описывать различные точки зрения на проблему защищенности: цели, средства и исполнение. 2 Лаборатория по технике безопасности (Underwriters’ Laboratories, UL; www.ul.com (EN)) — основанная в 1894 году в США независимая организация, тестирующая устройства на соответствие собственным стандартам безопасности. Сертифицированные устройства могут помечаться одним из знаков соответствия стандартам, внешний вид и описание которых приводятся по адресу www.ul.com/mark (EN). 110 Рис. 14 Цели Цели описывают защищенность с точки зрения пользователя. Вот главные вопросы: готова ли технология к работе, когда это необходимо? Находится ли при этом в безопасности моя конфиденциальная информация? Делает ли технология то, что от нее ожидается? И всегда ли правильно поступают люди, которые владеют и управляют бизнесом, предоставляющим эту технологию? Вот цели, которые должны быть достигнуты для реализации защищенных информационных систем: Таблица 5 Цели Основания для пользователя считать систему защищенной Безопасность Информация и операции пользователя остаются конфиденциальными и находятся в безопасности. Безотказность Пользователь может быть уверен, что продукт выполнит свои функции тогда, когда это потребуется. 111 Цели Основания для пользователя считать систему защищенной Деловая добросовестность Поставщик продукта проявляет ответственность и готовность помочь. Цели, связанные с защищенностью, охватывают как рациональные ожидания в области функционирования систем — т. е. то, чего можно достичь инженерными и технологическими мерами, — так и более субъективные оценки работы, возникающие как результат репутации, предубеждений, отзывов знакомых и личного опыта. В связи с каждой из этих целей, хотя и в различной степени, возникают вопросы из области инженерных задач, практики бизнеса и восприятия в обществе. Для пояснения терминов приведем примеры, касающиеся целей: 1. Безопасность. Моя личная информация не оказывается раскрытой без разрешения. Вирусы не заражают мой ПК и не приводят его в негодность. Взломщик не может привести мою систему в нерабочее состояние или несанкционированным образом изменить мои данные. 2. Безотказность. Когда я устанавливаю новую программу, мне не нужно беспокоиться, будет ли она правильно работать с существующими приложениями. Я могу читать свою почту, когда захочу, например, щелкнув ссылку Hotmail на msn.com. Я никогда не получаю сообщений «Система недоступна». Календарь не теряет внезапно все запланированные встречи. 3. Деловая добросовестность. Когда я сообщаю моему провайдеру услуг3 о проблеме, он реагирует быстро и эффективно. Средства Как только цели намечены, мы можем взглянуть на проблему с точки зрения ИТ-индустрии. Средства — это принципы делового и инженерного характера, используемые, чтобы достичь целей; это болты и гайки защищенной службы. В то время как цели по большей части ориентированы на конечного пользователя, средства — это внутренние принципы в рамках компаний. Считайте, что цели — это ответ на вопрос, что осуществляется, а средства — как осуществляется. 3 Провайдер услуг — компания, предоставляющая в данном регионе разного рода ИТуслуги, например, доступа в интернет, системной интеграции и т. п. 112 Таблица 6 Средства Деловые и инженерные принципы, позволяющие поставщику систем добиваться достижения целей Защищенность Предприняты шаги для защиты конфиденциальности, целостности и готовности к работе данных и систем. Конфиденциальность Данные о пользователе никогда не собираются и не передаются другим людям и организациям без его согласия. Конфиденциальность достигается в случае сбора, хранения и использования информации в соответствии с «Принципами честного использования информации» (Fair Information Practices). Готовность к работе Система доступна и готова к использованию при необходимости. Управляемость Систему легко установить и ей легко управлять — с учетом ее размера и сложности (масштабируемость4, эффективность и экономичность рассматриваются как элементы управляемости). Точность Система правильно выполняет свои функции. Результаты расчетов не содержат ошибок, и данные защищены от потери и повреждения. Удобство использования С программным обеспечением легко работать, и оно отвечает потребностям пользователя. 4 Масштабируемость — способность системы эффективно справляться с увеличением объемов данных и вычислительных мощностей в рамках существующей архитектуры и принципов работы. 113 Средства Деловые и инженерные принципы, позволяющие поставщику систем добиваться достижения целей Готовность помочь Компания берет на себя ответственность за проблемы и предпринимает меры по их устранению. Клиентам оказывается помощь в планировании приобретения продукта, его установке и работе с ним. Прозрачность Компания открыто ведет свои дела с клиентами. Ее побуждения ясны, она держит свое слово, и клиенты знают, какова их роль в операциях и взаимодействиях с компанией. Вот некоторые примеры: 1. Защищенность. Система может быть спроектирована так, чтобы использовать шифрование по алгоритму triple-DE5 для важных данных, например паролей, перед сохранением их в базе данных и протокол SSL6 — для передачи информации по интернету. 2. Конфиденциальность Такие технологии и стандарты, как P3P (Platform for Privacy Preferences — «Платформа для индивидуальных настроек конфиденциальности»), позволяют пользователям быть в курсе того, как собираются и используются их данные, и управлять этим процессом. В то же время Microsoft установила ясные принципы обеспечения конфиденциальности и ряд правил, которым следует в своей работе. 3. Готовность к работе. Операционная система выбирается по принципу максимизации среднего времени между отказами (Mean Time Between Failures, MTBF). Для служб должны быть определены и объявлены задачи функционирования, стандарты и правила обеспечения работоспособности системы. Triple-DES — алгоритм шифрования, при котором сообщение три раза подряд шифруется по алгоритму DES с разными ключами, что увеличивает стойкость шифра по сравнению с обычным алгоритмом DES. 5 SSL (Secure Sockets Layer) — протокол передачи данных по интернету с использованием шифрования с открытым ключом. Шифрование с открытым ключом — класс криптографических методов, использующих двуключевые шифры. Сообщения, зашифрованные открытым ключом, можно расшифровать только при помощи связанного с ним секретного ключа. А подлинность сообщений, подписанных секретным ключом, можно проверить с помощью открытого ключа. 6 114 4. Управляемость. Система проектируется настолько самоуправляющейся, насколько это целесообразно. Предусматривается возможность установки исправлений и программных обновлений при минимальном участии пользователя. 5. Точность. Схема системы включает в себя RAID-массив7, достаточную избыточность и другие средства для уменьшения потерь и повреждений данных. 6. Удобство использования. Интерфейс пользователя не запутан и интуитивен. Предупреждения и окна диалога полезны, а сообщения хорошо сформулированы. 7. Готовность помочь. Контроль качества продукта проводится, начиная с самых ранних стадий. Руководители ясно дают сотрудникам понять, что надежность и безопасность важнее, чем богатый набор функций или дата начала поставок. Службы постоянно находятся под наблюдением, и предпринимаются меры, если их работа в чем-то не соответствует поставленным задачам. 8. Прозрачность. Контракты между компаниями составляются как соглашения, ведущие к взаимной выгоде, а не ради возможности извлечь максимальную краткосрочную прибыль для одной из сторон. Компания открыто и честно ведет диалог со всеми своими акционерами. Исполнение — это то, каким образом действует организация, чтобы воплотить в жизнь составляющие, необходимые для защищенной информационной системы. Здесь есть три аспекта: установки, реализация и подтверждения. Установки — это корпоративные и законодательные принципы, задающие требования к проектированию, созданию и поддержке продукта. Реализация — это бизнес-процесс, претворяющий в жизнь заданные установки. Подтверждения — это механизм, при помощи которого мы удостоверяемся, что реализация привела к осуществлению установок. Вот примеры: Установки Внутренние правила, принципы, директивы и критерии эффективности. Контракты и обязательства перед клиентами, включая Соглашения об уровне сервиса (Service Level Agreements, SLAs). Корпоративные, отраслевые и нормативные стандарты. Государственные законы, правила и нормы. Реализация Анализ рисков. Методы разработки, включая проектирование, кодирование, составление документации и тестирование. Теоретическое и практическое обучение. RAID (Redundant Array of Independent Disks) — дисковый массив. Метод восстановления ошибок жесткого диска, основанный на том, что два или более жеских дисков работают параллельно. 7 115 Характер ведения бизнеса. Методы маркетинга и продаж. Методы работы, включая развертывание, сопровождение, продажу и поддержку, а также управление рисками. Воплощение установок и разрешение споров. Подтверждения Внутренняя оценка. Аккредитация третьими сторонами. Внешний аудит. Эту проблему можно решить, только работая в двух параллельных направлениях. Первое направление — это текущие проблемы, то, о чем люди читают и беспокоятся каждый день. Мы должны заняться известными насущными проблемами и укрепить известные слабые места. Таким образом мы также сможем узнать о более фундаментальных проблемах. Мы должны быть как можно лучше осведомлены о том, что происходит на самом деле, а также о том, что мы можем и что не можем исправить в рамках существующих систем. Частично тревога пользователей вызвана тем, что в настоящее время использование персональных компьютеров распространяется на те сферы, которые прежде не вызывали беспокойства. Проще всего сосредоточить внимание на таких областях, как банки и банковские услуги, где подобные проблемы хорошо известны и имеют давнюю историю. Хотя предстоит проделать много работы по постепенному улучшению существующих систем, эти усилия не решат фундаментальных проблем, некоторые из которых описаны в следующей главе. Компьютерной индустрии необходимо выявить и решить самые насущные проблемы и постепенным образом внедрить эти решения в уже имеющиеся огромные системы. Предстоит долгий технологический цикл замены, в ходе которого важная инфраструктура, от которой зависит общество, постепенно замещается новыми улучшенными компонентами. Раз эти системы уже существуют, люди не могут просто выбросить их в окно и начать с нуля. Таким образом, мы должны выявить слабые места в наиболее важной инфраструктуре и имеющихся системах, а затем в первую очередь обновить их, обеспечив при этом построение новых систем на основе разумных принципов. 116 Фундаментальные проблемы Политические вопросы Когда какая-то технология становится неотъемлемой частью жизни общества, то общество начинает принимать большее участие в ее развитии и управлении ею. Так было с железными дорогами, телеграфной и телефонной связью, телевидением, энергетикой и т. п. Сегодня общество только начинает уделять внимание тому факту, что оно в значительной степени зависит от компьютеров. Мы вступаем в эру конфликта между предпринимательской энергией, порождающей новшества, и потребностью общества осуществлять регулирование критического ресурса невзирая на риск подавления конкуренции и изобретательности. Это осложняется тем фактом, что социальные нормы и связанные с ними правовые модели меняются медленнее, чем технологии. ИТиндустрия должна найти подходящее равновесие между потребностью в регулирующей системе и собственными стремлениями как отрасли, сформировавшейся без регулирования и опирающейся на стандарты де-факто. Многие современные проблемы надежности инфраструктуры — это на самом деле политический вопрос. Недавний энергетический кризис в штате Калифорния во многом был вызван плохо проведенной приватизацией. Малая зона покрытия и плохое обслуживание у операторов сотовой связи в США частично обусловлены директивой Федеральной комиссии США по связи (Federal Communications Commission, FCC) не предоставлять общефедеральных лицензий. Вопросы политики часто выходят за границы государств, как мы видим на примере борьбы за введение глобальных стандартов для технологий мобильной связи третьего поколения. Существующие пользователи эфира (часто это военные) в разных странах занимают разные полосы частот и отказываются их освобождать, затрудняя отыскание единого диапазона в мировом масштабе. Сложность обработки данных Мы являемся свидетелями появления сверхкрупных компьютерных систем, построенных на основе слабых связей между службами, машинами и прикладными программами. Неожиданные (и самые разные) проявления в работе таких систем представляют собой все большую, долгосрочную угрозу. Архитектура, основанная на разнообразии, устойчива, но при этом функционирует на грани хаоса. Это справедливо для всех сверхкрупных систем, начиная от природных, например погодных условий, до созданных человеком, например рынков и единой энергосистемы. Все ранее созданные нами сверхкрупные системы — энергосистема, телефонные сети — проявляли внезапное непредсказуемое поведение. Вот почему в 1965 году отказала энергосистема, и было обесточено все восточное побережье Соединенных Штатов, и вот почему время от времени целые города отключаются от телефонной сети, стоит кому-нибудь установить программное исправление на единственном 9 117 коммутаторе. Дело в том, что сложность системы превзошла способность любого отдельного человека — и любой отдельной организации — понимать все ее взаимосвязи. Сегодня существуют чрезвычайно защищенные и безопасные компьютерные системы, но по большей части это отдельные системы специального назначения, которые тщательно проектируются и затем работают изолированно. Мы на самом деле не знаем, что случится, если мы динамически свяжем друг с другом миллиарды — а возможно, и триллионы — интеллектуальных и зависящих друг от друга устройств, обладающих архитектурой и программным обеспечением множества разных типов и поколений. С ростом мощности компьютеров — как в отношении объема хранимых данных, так и в отношении скорости вычислений — соответственно возрастают абсолютный размер и сложность программного обеспечения. Это проявляется во многом, начиная от того, как вы администрируете эти машины, и заканчивая тем, как вы узнаете, что они сломались, как вы их ремонтируете и как вы расширяете их возможности. Все эти моменты в конечном итоге влияют на то, воспринимают ли люди такую систему как защищенную. Избыточность аппаратных средств У нас пока нет действительно хороших экономичных и широко используемых механизмов создания сверхнадежных аппаратных средств. Тем не менее, при сохранении существующих темпов развития, возможно, когданибудь самым обычным явлением станет кристалл, на котором будет находиться свыше 200 млн транзисторов. В какой-то момент окажется целесообразным организовать их в четыре параллельные системы, которые будут избыточны, а значит, более устойчивы к сбоям. Возможно, себестоимость подобной избыточности в отдельном компоненте окажется приемлемой. Подобным же образом производитель компьютеров или конечный пользователь могут решить, что необходимо установить два жестких диска меньшего объема для дублирования данных, значительно повысив тем самым стойкость системы на случай выхода диска из строя. Возможно, скоро у нас появятся новые архитектурные подходы к живучести компьютерных систем, но в ее основе всегда лежит избыточность. А значит, за эту избыточность придется платить. Поэтому людям фактически придется снова решать: сэкономить ли деньги, но потенциально столкнуться с большим числом отказов? Либо потратить больше денег, повысить сложность системы и ее администрирование, чтобы решить соответствующие вопросы безопасности, конфиденциальности и технологической достаточности, тем самым устранив проблемы? 118 Межмашинные процессы Отличительная черта использования веб-сервисов — вычисления 8 на периферии сети. Приложения peer-to-peer станут правилом, и данные будут обрабатываться и храниться распределенным образом. Администрирование подобной системы потребует сложных межмашинных процессов. Данные будут содержать собственное описание. Машины будут слабосвязанными, самонастраивающимися и самоорганизующимися. Они будут сами себя администрировать, чтобы соответствовать централизованно заданным политикам. Веб-приложения предстоит проектировать с учетом работы в асинхронном мире. Персональный компьютер знает, где находятся его периферийные устройства, поскольку необходимые связи уже заданы (пользователем или программным обеспечением) в какой-то момент в прошлом. Если что-то нарушает эту синхронность, программы иногда просто зависают. Улучшенная поддержка устройств plug-and-play9 в Windows XP, а также архитектуры «горячего подключения» типа USB10 и IEEE 139411 прокладывают путь к подлинно «асинхронному» ПК, но такого рода зависимости временами еще встречаются. В интернете, однако, устройства появляются и исчезают, и время отклика меняется в широких пределах. Устойчивым веб-системам требуется динамическое обнаружение и автоматическая настройка. Если вы принимаете идею о том, что все является асинхронным и слабосвязанным, вы получаете еще больше возможностей для отказов. Для каждого потенциального взаимодействия вы должны держать в уме возможность, что на самом деле его не произойдет, поскольку интернет — это всего лишь система с «максимальными усилиями»: если вы щелкаете ссылку и ничего не получаете, то вы щелкаете снова. Поэтому все компьютерные системы необходимо перепроектировать с учетом восстановления при сбоях в ходе взаимодействий. Peer-to-peer — модель обмена информацией, когда устройства, подключенные к сети, могут напрямую связываться друг с другом, и каждое может выступать как в качестве клиента, так и в качестве сервера. 9 Peer-to-peer — модель обмена информацией, когда устройства, подключенные к сети, могут напрямую связываться друг с другом, и каждое может выступать как в качестве клиента, так и в качестве сервера. 10 USB (Universal Serial Bus) — Plug-and-Play («подключи и работай») — принцип и спецификация быстрого подключения к компьютеру дополнительного оборудования и самоконфигурирования системы. Поддерживается всеми современными операционными системами, BIOS и аппаратными средствами. Операционная система обнаруживает вновь подключенное усройство, опрашивает его, оценивает предъявляемые им требования к системе, определяет и выполняет оптимальные установки для каждого устройства.универсальная последовательная шина. Стандарт для обмена данными по недорогой шине между персональными компьютерами и периферийными устройствами. 11 IEEE 1394 — высокоскоростной (400 Мбит/сек) интерфейс с возможностью «горячего» подключения устройств. 8 119 Идентификация личности пользователя В связи с проблемой создания защищенных информационных систем иногда поднимаются вопросы, касающиеся идентификации личности пользователя. Идентификация личности не фигурирует в модели в явном виде, поскольку пользователь не ожидает, что компьютерная система будет ее определять. Тем не менее, личность пользователя — это ключевое понятие, в соответствии с которым предоставляются те или иные услуги. Идентификация личности (проверка подлинности клиента, аутентификация) должна быть устойчива к взлому, чтобы можно было с большей надежностью предпринимать действия на основе полученной информации о пользователе (проверка полномочий12, авторизация). Поэтому пользователи ожидают, что их персональные данные будут защищены от нежелательного использования. Описать, что такое личность, сложно в принципе, но это особенно сложно в электронной среде. Мы используем рабочее определение, что личность представляет собой совокупность неизменных составляющих из числа отличительных характеристик, по которым человек (или предмет) может быть узнан или которыми он известен. Личность — понятие расплывчатое и контекстно-зависимое, поскольку эти «обрывки»-составляющие находятся в самых разных местах в электронной, физической и эмоциональной форме. Какая-то часть личности «принадлежит» пользователю, но в значительной степени личность «определяется» другими людьми, будь то юридически (государством или компаниями) или в порядке неформального узнавания в обществе. В проблему идентификации личности упираются многие элементы защищенности информационных систем. Пользователи беспокоятся о компьютерной конфиденциальности частично из-за того, что они понимают, что казалось бы несвязанные составляющие их личности могут легче быть собраны в одно целое, когда фрагменты находятся в электронном виде. Лучшее свидетельство тому — растущая в обществе боязнь мошенничества с кредитными картами и «кражи личностей», поскольку операции в Интернете более прозрачны и анонимны по сравнению с офлайновыми операциями, хотя оба эти преступления столь же возможны в физическом мире. Пользователи ожидают, что их персональная информация, включая составляющие их личности, не будет раскрываться без особого на то разрешения. Люди Управлять очень крупными компьютерными сетями уже непросто и со временем становится лишь сложнее. Масштабность трудностей маскируется При подключении клиента (человека либо программы) к системе производится «проверка подлинности» (authentication), т. е. клиент с помощью пароля удостоверяет, что он тот, за кого себя выдает. После успешного подключения под некоторым именем при попытке клиента выполнить какие-то действия производится «проверка полномочий» (authorization), т. е. определение, имеет ли право клиент с данным именем на данные действия. 12 120 тем, что пока мы, как правило, нанимаем для этого специалистов. Недостатки машин, сетей, методов управления, инструментов и самих приложений часто смягчаются талантливыми системными администраторами, напряженная работа которых в какой-то степени компенсирует тот факт, что компоненты систем не всегда функционируют так, как ожидается или как хотелось бы. Многие системные сбои, привлекающие много внимания, происходят из-за сложности систем. Люди допускают ошибку в администрировании, не устанавливают пакет исправлений или неправильно настраивают брандмауэр , и простой сбой превращается в катастрофу. Существует очень сильная зависимость от операторов-людей, которые должны делать то, что нужно, изо дня в день. Знающих администраторов уже не хватает, и мы продолжаем сдавать позиции. Хуже того, потребности в администрировании выходят за рамки сферы деятельности профессиональных ИТ-менеджеров. С одной стороны, мы пришли к ситуации, когда даже лучшим операторам приходится трудно: системы меняются слишком быстро, чтобы люди успевали с этим разобраться. С другой стороны, массовое распространение компьютеров в конце концов породит необслуживаемые системы, которые люди будут носить с собой или держать в машине или дома. Поэтому нам нужно предоставить людям более простые возможности, которые обеспечат надлежащее функционирование системы при минимальном вмешательстве человека. Мы должны стремиться к ситуации, когда люди, принимающие решения, смогут задать политику и распространить ее на тысячи машин, не прилагая при этом существенных усилий по написанию программ, переключению рычагов или нажатию кнопок на администраторских пультах. ИТ-индустрия может подойти к проблеме различными путями. Может быть, на самом деле следует совершенно иначе писать программы? Необходимы ли в принципе системные администраторы? Или нам следует разрабатывать машины, которые смогут администрировать другие машины без постоянного вмешательства человека? 15 Средства программирования При каждом из этих подходов требуются новые виды программного обеспечения. По мере того, как абсолютное число машин и их сложность растет, процесс администрирования начинает сталкиваться с проблемой нехватки обученных людей и их возможностей. Поэтому сообществу разработчиков средств программирования необходимо задуматься о создании более подходящих способов написания программ. Людям, традиционно размышляющим над тем, как управлять компьютерами, предстоит подумать о том, как расширить возможности компьютеров по самоорганизации и самоуправлению. Нам нужно продолжать совершенствование средств программирования, потому что сегодня программирование слишком подвержено ошибкам. Однако 121 существующие средства не обеспечивают адекватной поддержки, поскольку остается ряд уровней абстракции, требующих непосредственного управления. Другими словами, проектировщику приходится не только учитывать архитектуру системы и вопросы платформ и библиотек, но также и все остальное — от производительности, локализации и удобства сопровождения до структур данных, многопоточности и управления памятью. Слабо поддерживается параллельное программирование: большинство управляющих конструкций строятся последовательно, и весь процесс также носит последовательный характер. И это только на стадии разработки; на этапе развертывания становится все труднее проверять сложные взаимодействия систем, версий и широкого спектра операционных сред. Кроме того, все большее распространение получают инструменты, предлагающие усовершенствованные функции разработки более широким слоям пользователей, но не помогающие новичкам и неопытным пользователям писать хороший код. Есть также вопросы из области долгосрочного функционирования: например, инструменты не поддерживают выход технологий из употребления или изменение тенденций, касающихся возможностей устройств, объемов хранения, скорости и т. п. Подумайте о колоссальных усилиях, затраченных на Проблему-2000 из-за того, что программисты 60-х и 70-х годов не ожидали, что их код все еще будет использоваться на машинах, намного превосходящих возможности машин того времени. Функциональная совместимость Рост интернета продемонстрировал, что стандартные технологии — от TCP/IP до HTTP — необходимый элемент для создания крупномасштабных, многоцелевых компьютерных систем, способных приносить людям пользу и завоевывать их внимание. (Подобные же стандарты, введенные техническими средствами или посредством регулирования, или тем и другим способом одновременно, принесли успех и многим другим технологиям — от железных дорог до телевидения.) Очевидно и неизбежно, что функционально совместимые системы еще долгое время будут направлять развитие индустрии высоких технологий. Однако функциональная совместимость ставит перед ИТ-индустрией уникальный ряд проблем с точки зрения технологий, регулирующих норм и практики бизнеса. Существующие «защищенные» информационные системы, например, сеть управления воздушным движением, очень сложны и в большой степени зависят друг от друга, но в то же время они разработаны для специальных задач, редко модифицируются и строго контролируются из единого центра. Остается открытым вопрос, может ли распределенная, гибкая и динамическая компьютерная система с нефиксированной организацией — построенная на функционально совместимых технологиях — когда-либо достичь такого же уровня безотказности и защищенности. Функциональная совместимость также ставит определенную проблему с точки зрения ответственности и доверия, поскольку все труднее найти того, кто 122 отвечает за недостатки. Если в сегодняшнем Интернете — построенном на принципах децентрализации и коллективного управления — произойдет какойто массированный сбой, кто будет нести ответственность за это? Одна из важных причин, по которым люди не склонны доверять интернету, состоит в том, что они не могут с легкостью определить, кто отвечает за его недостатки: кого вы будете винить за катастрофическое нарушение работы сети или за крах системы доменных имен? Если мы хотим создать и использовать полностью функционально совместимую (и взаимозависимую) систему, которой люди смогут доверять, мы должны ясно определиться, кто за что отвечает. Концептуальные модели Что касается защищенных информационных систем, мы сталкиваемся с фундаментальной проблемой: информатике недостает теоретических основ. Компьютерная безопасность — сама по себе лишь один из компонентов защищенной информационной системы — как правило, рассматривается как подраздел безопасности коммуникаций, которая основана на криптографии. Криптография имеет прочную математическую основу, но явно не подходит для решения проблем защищенных информационных систем. Как заметил один из разработчиков корпорации Microsoft Джим Каджийя (Jim Kajiya): «Это все равно, как если бы мы строили паровые двигатели, не понимая основ термодинамики». Компьютерное научное сообщество пока не нашло альтернативного подхода; мы застряли на криптографии. Возможно, исследования в области вычислительной комбинаторики или какой-то другой информационной теории, изучающей фундаментальную природу передачи информации, или исследования в области компьютерных взаимодействий могли бы в конечном итоге частично предоставить нам такую альтернативу. Но сегодня это всего лишь предположения. Компьютерная система защищена лишь настолько, насколько защищено ее самое слабое звено. И слишком часто слабым звеном оказывается человек: проектировщик, создающий плохое решение под напором сложности, администратор, неправильно настроивший систему, бизнесмен, предпочитающий предложить новые функции в ущерб надежности, или техник службы сопровождения, ставший жертвой мошенников, использующих «социальную инженерию» . Взаимосвязь информационных технологий и социологии станет важной сферой для исследований в области защищенных информационных систем. До сих пор взаимообмен между этими областями едва ли имел место. 17 Итоги Реализация концепции «Защищенных информационных систем» необходима не только для благополучия ИТ-индустрии, но и для нашей экономики и общества в целом. Защищенные информационные системы — это многосторонний комплекс вопросов. Все вместе они подчинены трем целям: безопасности, безотказности и деловой добросовестности. Каждая из этих целей заслуживает внимания. 123 Хотя существует работа, которую важно выполнить в короткие сроки, остаются и сложные проблемы, требующие фундаментальных исследований и сдвигов в области высоких технологий. Производители оборудования и программного обеспечения, а также учебные и государственные исследовательские институты должны совместно взяться за решение этих проблем. Процесс поддержания безопасности среды в две взаимосвязанные фазы: «Добейтесь безопасности» и «Оставайтесь в безопасности». При внедрении безопасности существует множество областей, которые вы должны спроектировать и применить. Диаграмма показывает широкий спектр этих областей, заштрихованные области описываются в настоящем руководстве. Разработка и Разработка и внедрение Разработка и Разработка ITвнедрение блокировки внедрение политики глубинной сервера антивирусной безопасности стратегии (Server стратегии защиты Lockdown) Разработка и внедрение стратегии резервирования и восстановления Стратегия управления патчами Разработка и внедрение стратегии аудита и стратегии обнаружения взлома Разработка плана реакции на происшествие Рис. 15 Зоны безопасности Диаграмма показывает шаги, необходимые для достижения безопасности сервера («Добейтесь безопасности»), и чтобы обеспечить его работу в том же направлении («Оставайтесь в безопасности»). Также она показывает, каким образом главы данного руководства помогут вам достигнуть этих целей. 124 Установить самые свежие сервисные пакеты и «hot fix’ы» Определение угрозы безопасности Определить риски своей безопасности Блокировать сервер в тестовом окружении Политики групп и безопасность серверов, основанная на их роли Сохранилась ли функциональность серверной роли? нет Изменить групповую политику блокировки да Добейтесь безопасности Применить к рабочим серверам Оставайтесь в безопасности Использовать hfnetchk для поиска недостающих патчей нет нет Управле ние патчами Регулярно просматривать журнал аудита Не установлены нужные патчи? да Загрузить и испытать патчи в тестовой среде Установить патчи на рабочие сервера Рис. 16 Блок-схема процедуры защиты Аудит и обнаружение инцидентов и реагирование на инцидент Обнаружен вероятный инцидент? да Следовать процедуре реагирования на инцидент 125 Примечание: Данная диаграмма не показывает каждое действие, которое включено в процедуру «Оставайтесь в безопасности», к примеру запуск антивирусных программ ими создания резервных копий. Вместо этого здесь показаны задачи, подробно описанные в данном руководстве. Данное руководство используется как часть вашей общей стратегии безопасности, но не как руководство, охватывающее все аспекты создания и поддержки безопасной среды. 126 Определение угрозы безопасности Одновременно с развитием IT систем развиваются и угрозы безопасности, с которыми им приходится сталкиваться. Если вы собираетесь эффективно защищать вашу среду от нападения, вы должны четко понимать те опасности, с которыми вы, вероятно, столкнетесь. При определении угрозы безопасности вы должны обратить внимание на два основных фактора: 1) Типы нападений, с которыми вы, вероятно, столкнетесь, и 2) Где эти нападения могут произойти. Большинство организаций пренебрегают вторым фактором, предполагая что серьезное нападение может происходить только извне (в основном через соединение с Интернет). В исследовании Службы безопасности и компьютерных преступлений, совместно проведенном Институтом компьютерной безопасности (CSI) и Федеральным Бюро Расследований США 31 % респондентов отметили свои внутренние системы как наиболее частый объект нападения. Тем не менее, множество компаний могут просто не осознавать, что нападения изнутри происходят, главным образом потому, что их никто не отслеживает и не контролирует. В этой главе, мы рассматриваем типы нападений, с которыми вы можете столкнуться. Также будут рассмотрены некоторые шаги, как делового так и технического характера, следуя которым вы сможете минимизировать угрозу вашей среде. Управление рисками Не существует такой вещи, как полностью безопасная и одновременно работоспособная IT-среда. Когда вы исследуете вашу среду, вы должны оценить риски, с которыми сталкиваетесь, определить приемлемый уровень риска и сохранить его на этом уровне или ниже. Риски уменьшаются путем увеличения степени безопасности вашей среды. Общее правило: чем выше уровень безопасности в организации, тем дороже она обходится, и тем более вероятно, что функциональные возможности будут сокращены. Оценив потенциальные угрозы, вам вероятно захочется снизить ваш уровень безопасности в пользу увеличения функциональных возможностей и понижения стоимости. В качестве примера рассмотрим компанию по обслуживанию кредитных карточек, которая применить систему защиты от мошенничества. Если мошенничество стоит компании 3 миллиона долларов в год, а внедрение и обслуживание системы предотвращения мошенничества стоит 5 миллионов долларов в год, не существует никакой прямой финансовой выгоды в установке системы. Тем не менее, компания может нести косвенные потери, стоящие гораздо больше, чем 3 миллиона, например потеря репутации и доверия клиента. Поэтому, на самом деле, вычисления гораздо более сложные. Иногда дополнительные уровни безопасности оборачиваются более сложными системами для пользователей. Онлайновый банк может использовать 127 многочисленные уровни идентификации для своих пользователей каждый раз, когда они хотят получить доступ к своему счету. Однако, если идентификационный процесс является слишком сложным, некоторые клиенты не захотят использовать систему, которая потенциально могла стоить больше, чем нападения, которым мог подвергнуться банк. Чтобы понять принципы управления рисками, вы должны уяснить некоторые ключевые термины, используемые в процессе управления рисками. Они включают в себя: ресурсы, угрозы, уязвимые места, эксплуатации и контрмеры. Ресурсы. Ресурс - это любой объект вашей среды, который вы пытаетесь защитить. Это могут быть данные, приложения, серверы, почтовые программы и даже люди. Цель защиты состоит в том, чтобы предотвратить ваши ресурсы от нападения. Важная часть управления рисками заключается в том, чтобы оценить значимость ваших ресурсов – ведь вы бы не стали использовать стандартные дверные замки и домашнюю сигнализацию, чтобы охранить королевские драгоценности. Точно так же ценность ваших ресурсов может определить соответствующий уровень безопасности. Угрозы. Угроза - это человек, место или вещь, которые имеют возможность получить доступ к ресурсам и причинить вред. В таблице показаны различные типы угроз с примерами. Таблица 7 :Угрозы компьютерной среде Тип угрозы Природная и физическая Непреднамеренные Намеренные Примеры Огонь, вода, ветер, землетрясение Сбой электропитания Неинформированные сотрудники Неинформированные клиенты Атакующие Террористы Промышленные шпионы Правительства Злонамеренный код Уязвимое место. Уязвимое место - это место, где ресурс наиболее восприимчив к нападению, слабости определенного рода. Категории уязвимости показаны в следующей таблице Таблица 8: Уязвимые места в компьютерной среде. Вид уязвимого места Физические Примеры Незапертые двери 128 Вид уязвимого места Природные Оборудование и программное обеспечение Носители Связь Человек Примеры Неисправная система пожаротушения Устаревшая антивирусная программа Электрическое воздействие Незашифрованные протоколы Незащищенные процедуры службы поддержки Примечание: Так как все организации разные, вышеперечисленные примеры угроз и уязвимых мест могут быть неприменимы к вашей организации,. Эксплойт. Ресурс, может оказаться доступным для угрозы, использующей уязвимость в вашей окружающей. Данный тип нападения известен как "эксплуатация". Эксплуатация ресурсов может быть достигнута многими способами. Наиболее распространенные примеры приведены в следующей таблице. Таблица 9: Эксплуатация в компьютерной среде. Тип эксплойта Примеры Эксплойты технической Нападение при помощи грубой силы уязвимости Переполнение буфера Заведомо неверная конфигурация Атаки воспроизведения (Replay Attacks) Атака сессии (Session Hijacking) Сбор информации Идентификация адреса Идентификация операционной системы Сканирование портов Зондирование сервиса и приложения Сканирование уязвимых мест Анализ ответа Подсчет пользователей Утечка при беспроводной связи Социотехника (обманное получение паролей) Отказ в обслуживании Физические повреждения Изъятие ресурсов Модификация ресурсов Насыщение ресурса Когда потенциальная угроза использует уязвимые места нападения на ресурс, последствия могут быть очень серьезными. Нижеследующая таблица показывает некоторые из результатов эксплуатации, с которыми вы можете столкнуться, и их примеры. Таблица 10: Результаты эксплойтов. Результат эксплойтов Примеры 129 Результат эксплойтов Потеря конфиденциальности Потеря целостности Потеря доступа Примеры Неразрешенный доступ Повышение прав Заимствование прав идентификации Повреждение данных Дезинформация Отказ в обслуживании или кража Взаимодействие между угрозами, уязвимыми местами и рисками. Каждая угроза и уязвимое место, обнаруженные в пределах вашей организации, должны быть квалифицированы и ранжированы по типу: низкая, средняя или высокая. Ранжирование может различаться как между организациями, так и в пределах одной организации. Например, угроза землетрясений выше для офисов, находящихся возле эпицентра, чем где-либо в другом месте. Точно так же уязвимость физического повреждения оборудования будет очень высока для организации, производящей высокочувствительную и хрупкую электронику, в то время как строительная компания может иметь более низкий уровень уязвимости. Примечание: Помощь в работе 1: Таблица анализа угрозы может быть использована, чтобы помочь вам оценить угрозы и степень их возможного воздействия на вашу организацию. 130 Уровень риска в вашей организации увеличивается с уровнем угрозы и уязвимости. Это показано в следующей диаграмме. Рис. 17.Матрица риска Контрмеры Контрмеры применяются с целью противодействия угрозам и уязвимости, сокращая риск вашей среды. Например, организация, производящая хрупкую электронику для обеспечения безопасности может применить физические контрмеры: улучшение фундамента здания или добавление смягчающих удар механизмов. Эти контрмеры уменьшают вероятность, что землетрясение может причинить физический ущерб их оборудованию. Остаточный риск состоит в том то, что остается после того, как все контрмеры применены, чтобы уменьшить угрозу и уязвимость. Многоуровневая защита (глубокая защита, Defense in Depth) Чтобы уменьшить риск в вашей среде и защитить свои ресурсы от внешних и внутренних угроз, вы должны использовать стратегию «глухой обороны». Термин «глухая оборона» (иногда также используют «глубокая защита», «глубокая безопасность» или «многослойная безопасность»), заимствован из военной терминологии и используется для описания иерархического построения мер безопасности, формирования взаимосвязанной среды безопасности без единого недостатка. Слои безопасности, которые формируют вашу стратегию «глухой обороны», должны включать развернутые защитные меры на протяжении всего 131 пути от вашего внешнего источника к вашим ресурсам, и всех пунктов, находящихся между ними. Развертывая многократные слои безопасности, вы можете быть уверены, что, в случае если один слой пробит, другие слои обеспечат безопасность необходимую для защиты ваших ресурсов. Например, прохождение сквозь защиту организации не должно обеспечить нападавшему свободный доступ к наиболее важным данным организации. В идеале каждый слой защиты должен обеспечить разные формы контрмер, чтобы предотвратить использование того же самого метода проникновения в нескольких слоях. Диаграмма показывает эффективную стратегию глубокой защиты. Рис. 18.Стратегия глубокой защиты. Важно помнить, что ваши ресурсы это не только данные, а все в вашей среде, что может быть объектом нападения. Как часть вашей стратегии управления рисками, вы должны исследовать ресурсы, которые вы защищаете, и определять, имеете ли вы достаточную степень защиты для каждого из них. Конечно, степень безопасности, которую вы можете применить, будет зависеть от вашей оценки риска, а также анализа стоимости и выгод развертывания контрмер. Однако, необходимо убедиться в том, что нападающий будет также нуждаться в подобном знании, времени и ресурсах, чтобы обойти все контрмеры и получить доступ к вашим ресурсам. Примечание: То, как вы развертываете многослойную защиту, будет напрямую зависеть от специфических особенностей вашей среды. Если ваша среда изменяется, убедитесь в том, что вы заново переоценили вашу стратегию глубокой защиты. Стоит подробнее рассмотреть каждый слой стратегии глухой обороны. 132 Защита данных. Для многих компаний один из их наиболее ценных ресурсов - это данные. Если эти данные попадут в руки конкурентов, или окажутся поврежденными, могут возникнуть серьезные неприятности. На клиентском уровне, данные, хранящиеся отдельно, особенно уязвимы. Если портативный компьютер украден, данные могут быть скопированы, восстановлены и прочтены, даже если преступник неспособен подключиться к системе. Защита приложений. Защита приложения является необходимой частью любой модели безопасности. Система безопасности Windows 2000 содержит механизмы защиты приложений, однако, ответственность разработчика заключается в том чтобы правильно реализовать и использовать эти механизмы в приложении. Приложение существует в пределах операционной системы, так что вы должны всегда рассматривать защиту всей вашей среды при рассмотрении защиты приложений. Каждое приложение, используемое в вашей организации, должно быть тщательно проверено на безопасность в испытательной среде прежде, чем вы позволите этому приложению работать в системах компании. Защита хостов. Вы должны оценить каждый подключаемый компьютер в вашей среде и выработать политику, которая ограничивает каждый сервер только теми задачами, которыми он должен заниматься. Таким образом, создается еще один барьер защиты, который придется обходить взломщику, прежде чем нанести вам какойлибо ущерб. Глава 4, "Защита серверов исходя из исполняемой роли" рассказывает о политиках, которые увеличивают защиту для пяти общих ролей серверов Windows 2000. Первый шаг в достижении этого состоит в том, чтобы создать индивидуальную политику, основанную на классификации и типе данных, содержащихся на каждом сервере. Например, в политике организации может быть предусмотрено, что все Web-серверы предназначены для общественного использования и, поэтому, могут содержать только информацию для общественного пользования. Их сервера с базами данных обозначены как конфиденциальные, что означает, что информация должна быть защищена любой ценой. Это отражено в классификациях, приведенных в таблице на следующей странице. Таблица 11. Классификация серверов. Назначение Для общественного использования Определение Распространение этого материала не ограничено. Туда включена маркетинговая информация, коммерческие материалы и информация, предназначенная для общественного пользования. Данные общественных серверов Интернет должны быть для общественного использования. 133 Только для внутреннего использования Конфиденциально Раскрытие этой информации безопасно для внутреннего распределения, но, будучи опубликованной, может нанести значительный ущерб организации. По меньшей мере, один межсетевой экран должен существовать между этой информацией и Интернет. Раскрытие этой информации принесло бы серьезный ущерб организации в целом. По своей природе эта информация самая чувствительная, и предоставляется только при необходимости. По меньшей мере, два межсетевых экрана должны быть помещены между этой информацией и Интернет. Сетевая защита. В вашей организации может быть несколько сетей, и вы должны оценить каждую из них индивидуально, чтобы гарантировать, что они защищены соответствующим образом. Если успешно атакован маршрутизатор, это может означать отказ всех сегментов сети. Вы должны отслеживать все разрешенные действия в ваших сетях и блокировать любой трафик, который не разрешен. Вы можете также рассмотреть возможность использования протокола IPSec, чтобы зашифровать пакеты в ваших внутренних сетях, и протокола SSL для внешней связи. Вы также должны контролировать анализаторы пакетов, которые должны использоваться в сети только под жестким контролем. Защита периметра. Защита периметра вашей сети - наиболее важный аспект в предотвращении нападения снаружи. Если ваш периметр в безопасности, ваша внутренняя сеть защищена от внешних нападений. Ваша организация должна иметь определенное устройство, защищающее каждый доступ в сеть. Каждое устройство должно быть оценено, определены разрешенные типы трафика, после чего должна быть разработана модель безопасности, блокирующая любой другой трафик. Системы сетевой защиты - важная часть защиты периметра. Вам понадобится одна или несколько систем сетевой защиты, чтобы минимизировать нападения извне, наряду с аудитом и обнаружением вторжения, чтобы удостовериться, что вы в курсе нападений, если таковые происходят. Для получения более подробной информации об аудите и обнаружении вторжения см. Главу 6, "Аудит и обнаружение вторжения". Вы также должны помнить, что для сетей, поддерживающих удаленный доступ, периметр может включать портативные компьютеры персонала и даже домашние ПК. Вы должны убедиться, что эти компьютеры отвечают вашим требованиям безопасности прежде, чем они смогут входить в сеть. Физическая Безопасность. Любая среда, где неправомочные пользователи могут получить физический доступ к компьютерам, очень опасна. Самое эффективное упреждение нападения отключение сервера от электричества или снятие жестких дисков. Кража данных 134 (и отказ в обслуживании) может произойти, если кто-либо украдет сервер или ноутбук. Вы должны рассматривать физическую безопасность как фундамент для вашей общей стратегии безопасности. Первым приоритетом является физическое обеспечение безопасного месторасположения сервера. Это может быть специальная комната для сервера в пределах вашего здания, или же целый информационный центр. Также вы должны обратить внимание на доступ в помещения вашей организации – если кто-то может получить несанкционированный доступ в здание, он сможет начать атаку, даже не имея возможности войти в систему через сеть. Это может быть: отказ от обслуживания (к примеру, подключение ноутбука к сети, использующей DHCP сервер или отключение питания сервера) кража данных (к примеру, кража ноутбука или анализ пакетов во внутренней сети) запуск вредоносного кода (к примеру, запуск червя изнутри организации) кража информации, критически важной для обеспечения безопасности (к примеру, кассет с резервными копиями, руководств по эксплуатации и сетевых диаграмм) Частью вашей стратегии управления рисками является определение уровня физической безопасности, соответствующего вашей среде. Возможные физические меры безопасности включают в себя некоторые из нижеследующих. Физическая охрана всех помещений здания (может включать в себя электронные карточки доступа, биометрические устройства и охранников). Требование сопровождать гостей в их перемещениях по зданию. Требование, чтобы гости сдавали на хранение все компьютерные устройства в момент прибытия. Требование, чтобы все служащие регистрировали любые имеющиеся портативные устройства. Физическое обеспечение безопасности всех рабочих компьютеров и ноутбуков на столах сотрудников. Требование, чтобы все устройства хранения данных были зарегистрированы перед выносом из здания. Размещение серверов в отдельных комнатах, доступ к которым имеют только администраторы. Достаточное количество каналов связи с Интернет, бесперебойное питание, система пожаротушения и т.д. Защита от природных катастроф и нападений террористов. Ограничение доступа к областям, через которые возможно осуществление атак «отказа в обслуживании» (denial of service attack) (например, области, где из здания выходят провода). Политики и процедуры 135 Почти все меры, описанные нами выше, нацелены на предотвращение несанкционированного доступа к системам. Однако, в вашей среде, несомненно, найдутся люди, которым потребуется высокий уровень доступа к системам. Любая стратегия безопасности будет неэффективна, если вы не сможете гарантировать, что эти люди будут правильно использовать предоставленные им права. Прежде чем нанимать новый персонал в вашу организацию, вы должны обеспечить этим людям тщательную проверку и еще более тщательную проверку тем людям, которым будет предоставлен высокий уровень доступа к вашим системам. Очень важно, чтобы работающий персонал знал вашу политику безопасности, что им дозволено делать, а что нет (и желательно объяснить почему). Это важно сделать по двум причинам. Во-первых, если ваши сотрудники не знают что делать запрещено, без злого умысла их действия могут поставить под угрозу безопасность вашей среды. Во-вторых, если ваш сотрудник злонамеренно нападет на вашу IT-среду, а в уставе компании это действие не будет четко прописано, против него будет очень трудно применить какие-либо меры. В среде Windows 2000 вы можете очень точно управлять административными правами ваших пользователей. Вы должны убедится, что четко определили перечень административных прав, доступных каждому члену вашего IT-персонала. Никто из персонала не должен иметь большей степени доступа, чем им требуется для работы. Уведомление ваших пользователей о безопасности может заключаться в программе ориентации, сопровождаемой постоянными напоминаниями и своевременным информированием об изменениях в процедурах безопасности. Жизненно важно, чтобы сотрудники поняли, что каждый член организации играет роль в обеспечении безопасности. Примечание: Помощь в работе 2: «Список основных грубых ошибок в обеспечении безопасности» приводит список обычных ошибок в обеспечении безопасности, которые могут произойти в любой организации. Они намного увеличат степень риска в вашей организации. Когда вы определяете вашу политику безопасности, вы должны убедится, что вероятность этих ошибок сведена к минимуму. Обычные способы нападения и меры предотвращения Как часть вашей стратегии глубокой защиты, вы должны понимать методы, используемые нападавшими, и научиться защищаться от обычных нападений. В этом разделе рассмотрено множество типов нападений и предложены наиболее эффективные шаги для защиты вашей среды. Примечание: Помощь в работе 3: В главе "Нападения и контрмеры" приводится таблица общих технических уязвимых мест и применяемых к ним контрмер. Сбор информации. 136 Нападающие всегда ищут возможность узнать о вашей среде. Иногда информация полезна сама по себе, в другом случае - с ее помощью можно получить доступ к другой информации и ресурсам. Ключом к предотвращению утечки информации является ограничение несанкционированного доступа к вашим ресурсам снаружи. Методы следующие: Убедитесь в том, что только специальные, идентифицированные устройства в сети поддерживают удаленный доступ к сети. Утилита modem-sweep должна проверить все префиксы компании при поиске несанкционированных устройств. Устройства удаленного доступа могут также быть обнаружены при активизации системы обнаружения на телефонной линии, если таковая доступна. сети, чтобы соединиться с прислугой. Отключите возможность использования протокола NetBIOS по протоколу TCP/IP, включая порты 135, 137, 139 и 445 компьютеров, напрямую подключенных к Интернет, мимо внешнего брандмауэра (firewall). Это усложнит возможность подсоединения к серверам снаружи сети. Для трафика, предназначенного для глобальной сети, оставьте открытыми только порты 80 и 443 как на сетевых адаптерах, напрямую связанных с Интернет, так и на брандмауэре. Таким образом, основные способы прощупывания портов станут недоступными для злоумышленников. Отслеживайте информацию, размещаемую на web-сайте, чтобы убедится что: Адреса электронной почты, указанные на сайте не являются административными учетными записями. Не дается информации по технологии сети. Информация о компании, представленная на сайте верна, и не может быть использована для обнаружения или выведения характеристик систем защиты. Этот тип информации включает в себя текущие события и недавние происшествия. Например, если на web-сайте объявлено, что ваша компания только что приобрела другую фирму, нападающие могут перенацелиться на новое приобретение в надежде, что его сеть была связана с новой корпоративной сетью второпях и поэтому хуже защищена. Просматривайте сообщения, размещаемые вашими пользователями в группах Usenet, чтобы оценить возможную утечку информации. Управляйте типом информации, опубликованной в исходном коде на webсайте, чтобы предотвратить изучение атакующими данного кода (метод, иногда называемый «отсеиванием источника») и не дать им возможности получить важную информацию. Это касается возможности случайного опубликования в исходном коде некорректных комментариев, встроенных паролей и скрытых тэгов. Просматривайте публичную информацию на предмет вашего IP-адреса и регистрационного имени домена. Убедитесь, чтобы нападающий не мог запросить DNS на предмет координатной сети или выполнить полную перепись зоны. Если вы храните все 137 записи и отчеты в DNS, нападающий может получить подробную информацию о компьютерах, которые легче всего атаковать. Чтобы предотвратить опрос DNS, вы можете назначить права DNS серверу, работающему под управлением ОС Windows 2000 используя опцию уведомления (Notify option) и дать возможность переписи зоны только авторизованным серверам. Другой метод – обеспечивать выполнение DNS только операций чтения, и отдельное обновление политик и процедур. Пересмотр Руководства по безопасности сайтов (Site Security Handbook, RFC 2196) для информации об анализах политик. Компания, имеющая деловые отношения с широкой общественностью, должна выработать приемлемый уровень исходящей информации. Важно публиковать только ту информацию, которая требуется, а не ту, которая впоследствии может использоваться злонамеренно. Управление типом информации, предоставляемой пользователям при исследовании ими сети утилитами как traceroute. Эти утилиты, использующие параметры, зависящие от времени установления соединения (time-to-live parameter, TTL), прослеживают путь, проходимый IP-пакетом от одного компьютера к другому, таким образом, они помогают выстроить картину сети. Примечание: документ RFC 2196 доступен на веб-сайте Request for Comments, указанном в секции «Дополнительная информация» в конце этой главы. Ограничение способности сканировать и получать ценную информацию И протокол TCP и протокол UDP используют порты, чтобы установить связь. Используя сканеры порта, нападающие могут обнаружить серверы в вашей среде и использовать эту информацию, чтобы обнаружить уязвимые места. Существует множество методов сканирования, используемых нападающими. Они могут использоваться, чтобы получить информацию о слушающих портах, существующих протоколах или даже об операционной системе, используемой на компьютере. Идентификация портов, протоколов, и операционной системы главного компьютера поможет обнаружить много уязвимых мест, которые не могли бы быть обнаружены без сканирования устройства. Таблица показывает некоторые из более важных методов сканирования, что они делают, и где они могут быть наиболее ценными: Таблица 12: Методы сканирования и их использование. Метод сканирования Как он работает Internet Control Message Шлет пакеты на ICMP порт Protocol (ICMP) Echo или 0 принимающей машины. Ping Если система позволяет отвечать на ICMP-эхо, она пошлет ICMP-ответ сканирующей системе, из которого следует, что она включена и принимает Чем он полезен «ping»-сканирование служит для нахождения хостов, «слушающих» сеть. Иные протоколы, кроме ICMP, а также открытые порты не идентифицируются. Большинство фильтрующих устройств блокируют ICMP- 138 Метод сканирования Как он работает сетевой трафик. TCP Connect или Three-Way Handshake Использует стандартную трехступенчатую процедуру верификации соединения с открытым TCP-портом. TCP Spoofed Connection Request (SYN) Использует два первых шага процедуры установления соединения. Сканирующая система шлет пакет с флагом сброса (RST) на последнем шаге вместо подтверждения статуса (ACK), тем самым не устанавливая полноценного соединения. Все флаги, за исключением FIN, отключены. Пакеты такого типа обычно игнорируются слушающими портами, а не слушающие посылают в ответ RSTпакет. Соответственно, все «молчащие порты» открыты. ТСР-пакеты разбиваются на фрагменты и впоследствии собираются заново в пункте назначения, используя одну из вышеуказанных методик сканирования. TCP Finish (FIN) Фрагментированный пакет Получение идента Запрос идента посылается после того, как ТСРсоединение было установлено для того, чтобы определить, какая учетная запись ассоциирована с процессом, использующим открытый порт. Сканирование FTP-прокси Оригинальный RFC по FTP определяет прокси-сервис, позволяющий пользователю соединяться с FTP-сервером Чем он полезен эхо, предотвращая тем самым «ping»-сканирование периметра. Очень удобно в тех случаях, если вы соединяетесь не через брандмауэр или раутер с фильтрацией пакетов. Более низкая вероятность обнаружения устройствами безопасности, так как соединение никогда не устанавливается. Работает несколько медленнее, чем TCP-connect. Может проникать через устройства безопасности, анализирующие только SYN-пакеты. Windowsсистемы дают менее аккуратные результаты, и поэтому выявить их открытые порты труднее. Некоторые устройства безопасности испытывают проблемы со сборкой потоков таких пакетов. Нагрузка на оборудование резко вырастает, что может привести к выходу их из строя или пропуску атаки. Этот тип сканирования не идентифицирует открытые порты, по может определить учетные записи и ассоциированные с ними сервисы. Операционные системы Microsoft не предоставляют такой информации. Полезно для сканирующих систем, скрытых за брандмауэром. Обнаружение системы, 139 Метод сканирования UDP Идентификация операционной системы Как он работает и пересылать с последнего файлы на любую другую систему. Сканирование FTPпрокси использует эту механику для получения подключений к другим системам. UDP – протокол, не использующий понятия «соединение», то есть посылающая система не ждет ответа от адресата. Система, осуществляющая UDP-сканирование, будет получать ответы только от неактивных портов. Идентификация ОС осуществляется несколькими различными путями, но наиболее верный результат дает сравнение ТСР-откликов системы со списком известных систем. Среди компонентов, используемых для идентификации, можно назвать TTL, номера ТСРпоследовательности, фрагментацию, FIN- и ASKотклики, размер фрейма, ICMP-отклики и т.п. Чем он полезен позволяющей выполнять это, считается уязвимостью, так как она пропускает трафик в места, запрещенные политиками безопасности или устройствами безопасности. UDP-порты зачастую не фильтруются устройствами безопасности, или же уровень фильтрования понижен. Часто такие UDPсервисы, как DNS и SNMP реализованы с недостаточной безопасностью и позволяют проникать через периметр системы. Медленные соединения или те, где высока степень потери пакетов, могут неаккуратно указывать на большинство открытых портов. Зачастую идентификация ОС легко минует устройства безопасности, за исключением проксирующих брандмауэров, которые посылают отклики от своего имени. Результат сканирования может быть неоднозначным. Брандмауэры и раутеры часто мешают идентифицировать ОС путем ICMP-сканирования. Когда нападающие применяют сканирование, вам следует опасаться любых уязвимых мест, которые они могут найти. Поэтому хорошим делом было бы введение жестко контролируемого сканирования в вашей среде. Чтобы защитить вашу сеть от сканирования, как минимум необходимо сделать следующее: 140 Идентифицировать запрашиваемые порты; все члены комитета безопасности должны прийти к согласию, прежде чем открыть любой другой порт. Ввести сетевую систему обнаружения вторжения. Приостановить все службы системы, которые не требуются. Подробности об остановленных службах в пяти серверных ролях Windows 2000 описаны в главе 4, «Безопасность серверов, основанная на роли». Применить все текущие системные патчи. Подробности о том как использовать свежие и правильные патчи можно найти в главе 5, «Управление патчами». Использование технически уязвимых мест Нападающие будут пытаться эксплуатировать техническую уязвимость в вашей среде, чтобы получать доступ к вашим системам и увеличить свои привилегии. Существует множество методов, которыми они могут пользоваться. В этой секции мы перечислим некоторые из ключевых методов и покажем, как от них защитится. Налет на сеанс Метод налета на сеанс позволяет нападающему прервать, закончить, или захватывать сеанс в работе. Эти типы нападений имеют тенденцию сосредотачиваться на основанных на сеансе приложениях. Множество методов налета на сеанс могут охватить несколько сеансов одновременно. Лучшее решение чтобы защитить структуру от налета на сеанс состоит в том, чтобы использовать кодирование. Предотвращение «заражения DNS» DNS-сервера являются жизненно важной частью любой ЛВС, основанной на Windows 2000. Все клиенты сети опрашивают DNS-сервера в поисках серверов, с которыми им необходимо соединиться. Когда мишенью атаки становится DNS, то нарушитель может прибегнуть к так называемому «заражению DNS». Например, нападающий использует различные технологии проникновения для того, чтобы переписать серверный кэш и внести в него вредоносные записи. В результате, когда пользователь опрашивает оригинальный DNS-сервер, его переадресуют на «поддельный» DNS-сервер, контролируемый нарушителем и использующимся для нанесения ущерба. Чтобы предотвратить атаки на DNS, следует придерживаться следующих правил: Используйте различные DNS-сервера для обслуживания запросов внутренней сети и следите за тем, чтобы эти сервера не отвечали на внешние запросы. Эту методику называют «разделенными» DNS. Используйте DNS-таблицы с атрибутами «только для чтения», которые не позволяют вносить изменения. 141 Используйте средства безопасности Active Directory для защиты баз данных DNS и разрешите только безопасные апдейты. Включите опцию «DNS cache poison protection» в настройке конфигурации Windows 2000 DNS. Атаки через строки URL Злоумышленники начинают фокусировать свое внимание на атаках через порт 80. Одной из форм таких атак заключается в создании URL-строки, использующей формат Unicode (UTF-8), в которой закодированы символы обычного или обратного слэша (/ или \); примером такой строки выступает %c0%af. Этот тип атак позволят нападающему получить доступ к структуре каталогов удаленной системы, собирать ценную информацию о сервере или всей сети, и даже удаленно запускать программы. К примеру, «червь» Nimda использует URL-строку в формате UTF для того, чтобы открыть сеанс по протоколу TFTP на удаленном сервере и загрузить свое тело на компьютер. Затем «червь» инсталлирует свой собственный TFTP-сервер, подгружает остаток своего обеспечения и приступает к саморепликации, используя такие методы, как массовые почтовые рассылки, встраивание .emlфайла в структуру веб-сайта и атаку открытых разделенных сетевых ресурсов. Первый шаг в организации стратегии многоуровневой защиты против URLатак – это изучить в деталях технологию такой атаки и постоянно следить за установкой самых свежих патчей. Подробную информацию о методике отслеживания текущих патчей вы найдете в Главе 5 , «Управление патчами». Дополнительную информацию о «черве» Nimda и особенностях защиты от него можно найти в разделе TechNet сайта Microsoft (см. раздел «Дополнительная информация» в конце этой главы). Атака на файл Security Accounts Manager Нападая на файл Security Accounts Manager (SAM), атакующий может получать доступ к именам пользователей и паролям. Как только у нападающего появится доступ к этой информации, он может использовать ее, чтобы получить законный доступ к ресурсам вашей сети. Управление файлом SAM - важный шаг в предотвращении нападений. Методы по достижению этого включают в себя: Использование системного ключа (Syskey), чтобы включить дополнительное кодирование файла SAM. Отключение протокола аутентификации LM (LAN Manager) Установка и внедрение сложной политики паролей. Переполнение буфера. Переполнение буфера - очень опасная методика, используемая нападающими, чтобы получить доступ к системе. Нападающие пытаются поместить слишком много информации в хранилище, чтобы увидеть, могут ли они заставлять переполнение действовать определенным образом. Например, если 142 атакуемая программа не выполняет надлежащую проверку границ, это приводит к переполнению и позволяет нападающему выполнить или выбрать определенные функции. Часто это переполнение работает в контексте учетных записей местных систем, имеющих полные административные права. Много нападений, направленных на переполнение буфера, полностью документированы и могут быть легко загружены из сети. Наиболее часто встречаемые типы этих нападений - буферные нападения переполнения на основе стека. Переполнение перезаписывает целый стек, включая указатели. Нападающий может воспользоваться этим преимуществом для настройки некоторых данных, помещенных в переполнение. Затем нападающий посылает специальный компьютерный код, чтобы выполнить определенную команду и ввести новый адрес для возврата. В конце нападающий использует адрес, который указывает назад на стек, чтобы команда выполнила его программу, когда система вернется в стек. Чтобы контролировать нападения, направленные на переполнение буфера вам потребуется: Постоянно поддерживать систему обновленной при помощи наиболее свежих наборов системных обновлений, горячих обновлений и патчей (см Главу 5 «Управление патчами») Применять правильное кодирование и следовать стандартным рекомендациям при проверки границ. По этой тематике существует множество ресурсов, например: Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press; ISBN: 0-7356-1588-8). Отказ в обслуживании. Нападающему не обязательно получать доступ к системе, для того чтобы вызывать существенные проблемы. Отказ в обслуживании (Denial of Service, DoS) заключается в «связывании» ресурсов системы, достаточном для того, чтобы она отказалась от выполнения своих обычных функций. В качестве примера можно привести использование всех сетевых соединений на сервере, или убеждение системы в том, что почтовый сервер имеет дело со значительно большим объемом почты, чем ему предназначено. Нападения DoS могут быть вызваны прямым нападением, или вирусами, «червями» или «троянскими конями». Распределенные атаки отказов в обслуживании (Distributed Denial of Service, DDoS) включают в себя установку программы, известную как «зомби», непосредственно перед нападением. Сами «зомби» часто устанавливаются при помощи «червей». Реальная опасность от нападения DDoS заключается в том, что в качестве ведущего компьютера нападающий использует множество компьютеров-жертв, чтобы управлять другими «зомби», которые осуществляют нападение. Когда системы разрывается между попытками проследить источник нападения, она получает целый набор ложных адресов, сгенерированных целым рядом «зомби». Описанные ниже шаги помогут вам предотвратить подобные нападения: 143 Поддерживайте систему обновленной при помощи последних патчей безопасности (см. главу 5 «Управление патчами»). Блокируйте большие пакеты утилиты ping в маршрутизаторе и системе сетевой защиты, предотвращая их от достижения периметра сети. Примените фильтры anti-spoofing на маршрутизаторе; то есть блокируйте любой входящий пакет, который имеет исходный адрес, идентичный адресу во внутренней сети. Фильтруйте ICMP-сообщения на системе сетевой защиты и маршрутизаторе (хоть это и может затронуть некоторые инструментальные средства управления). Разработайте план защиты с вашим провайдером услуг Интернет (ISP), который будет допускать быстрый ответ на нападение, нацеленное на пропускную способность участка сети между вашим провайдером и вашим сетевым периметром. Отключите ответ на направленные передачи. Примените надлежащий маршрутизатор и фильтрацию системы сетевой защиты. Используйте систему IDS, чтобы вычислить необычный трафик и активировать предупреждение, если что-либо обнаружено. Настройте IDS на генерацию предупреждения в случае обнаружения команды ICMP_ECHOREPLY без связанных пакетов ICMP_ECHO. DoS и DDoS - наиболее распространенные типы нападений через Интернет. Каждую неделю регистрируется множество нападений DoS и направляется в отслеживающую базу данных. Вы должны убедиться, что вы проинформированы об этих нападениях, и знать соответствующие методы, принимаемые против них. Атаки через черный ход (Backdoor Attacks). Чтобы предотвратить кражу системной информации, вы должны защититься от нападающих, использующих «троянского коня» (или «трояна»), который затем создает черных ход в вашу систему. Обычно это проблема для клиента, нежели для полностью защищенного сервера. Однако нападающий может использовать такой механизм для нападения на пользователя или рабочую станцию администратора и затем использовать что систему, чтобы предпринять ряд наступлений на сетевой периметр. Например, программа, осуществляющая доступ через черный ход, - Back Orifice 2000 позволяет нападающим дистанционно управлять компьютером по сети, перехватывать построчный ввод информации и использовать информацию, чтобы стать пользователем рабочей станции в сети. Множество антивирусных программ обнаруживают Back Orifice, однако, новые версии Back Orifice создают такие изменения, которые не обнаруживаются антивирусными программами. Кроме того, они работают в скрытом режиме и не обнаруживаются в списке задач, так как их размер менее 100 килобайт. Back Orifice лишь одна из многих подобных программ, вы можете предотвратить эти нападения следующим образом: 144 Запуск полного антивирусного сканирования, и поддержание антивирусных программ обновленными. Соблюдение мер предосторожности с содержимым писем, полученным по электронной почте, и воздержание от просмотра неизвестных вложений. Применение инструментов, таких как Сканер ISS, чтобы просканировать всю сеть на наличие инструментов нападения, типа Back Office, и своевременное обновление своего инструментария. Принятие только подписанных элементов управления Microsoft ActiveX® . Информирование пользователей об опасностях установки неизвестных программ, запуска сомнительных вложений, или загрузки неизвестного содержания из Интернет. Злонамеренный код Любой исполняемый код - потенциальный риск в вашей организации. Злонамеренный код может принять форму повреждения кода, который распространяется в пределах и между организациями (например, через электронную почту) или это может быть код, специально выполненный изнутри организация для злонамеренных целей. Злонамеренный код может быть сведен к четырем основным типам: Вирусы Троянские кони Черви Другой злонамеренный код Таблица 2.7: Виды злонамеренного кода Виды злонамеренного кода Вирус Описание Заражает другую программу, загрузочный сектор, сектор или файл, поддерживающий макросы, путем подстановки или присоединения. Затем он таким же образом копируется на другие компьютеры. Вирусы могут просто размножаться, но большинство из них наносят ущерб инфицируемым системам. Червь Копирует себя с одного устройства на другое, либо через сеть при помощи электронной почты, или любого другого механизма. Он может, как нанести ущерб компьютеру, так и вывести из строя его систему безопасности. Сам по себе никак не проявляется, но его злонамеренные функциональные возможности могут быть скрыты внутри других программ, которые с его помощью могут проникнуть на Ваш компьютер (часто при помощи некой программы-шутки). После того как он появится на компьютере, систематически будет наноситься определенный ущерб, либо компрометироваться система безопасности компьютера, что может послужить первым шагом к неразрешенному доступу. Выполняемый код, который либо намеренно, либо ненамеренно причиняет ущерб вашей среде. Как пример – Троянский конь Другие виды злонамеренного кода 145 Виды злонамеренного кода Описание зацикленный пакетный файл, который при каждом цикле нагружает системные ресурсы до тех пор, пока компьютер перестает нормально функционировать. Антивирусные утилиты защищают от большинства злонамеренных кодов, но не от всех. Если вы предотвращаете доступ к вашему CD-ROM, гибким дискам и другим устройствам ввода-вывода, вы защититесь от дальнейшего распространения этого кода, но вы сможете остановить код, который записан на внутренних системах. Код может быть также послан по электронной почте комунибудь внутри вашей организации. Даже если тип вложения не разрешен, это может преодолеваться изменением расширения файла, а при проникновении в организацию расширение восстановится. Защита ключевой системы и файлов от несанкционированного доступа главная часть принятия мер против любого враждебного кода нападения. Заключение В этом разделе показаны наиболее значительные угрозы вашей среде и действия, при помощи которых вы можете от них защититься. Существует, безусловно, и более детальная информация относительно того, как защитить вашу систему от нападения, как определить, если вы атакованы, и что делать, если нападение происходит. 146 Передовой опыт: Программа «Двенадцать шагов к компьютерной безопасности» А. Введение 1.Я действительно очень занят. Так ли мне нужно читать этот документ? 2.Примеры из реальной жизни: такое может случиться с каждым 3.Применим ли данный документ к моему бизнесу? 4.Что может стать причиной атаки из Интернета? 5.Предположим, что я согласен. Сколько мне будет это стоить? 6.Как получать свежие сведения по обеспечению безопасности бизнеса? Б.Двенадцать реальных примеров нанесения вреда малым компаниям в результате проведения компьютерных атак и конкретные меры противодействия 1.Используйте надежные пароли и регулярно их меняйте Первый случай: бывший сотрудник строительной компании использовал старый доступ к электронной почте для шпионажа в пользу конкурента 2.Остерегайтесь почтовых вложений и загружаемых из Интернета модулей Второй случай: червь MyDoom нанес большой ущерб тысячам малых компаний 3.Установите, поддерживайте и применяйте антивирусные программы Третий случай: консультант не обновлял программное обеспечение и в результате заразил вирусом и потерял нескольких клиентов 4.Установите и используйте межсетевой экран Четвертый случай: гостиницам и беспроводным подключениям к Интернету требуется межсетевой экран 5.Удаляйте неиспользуемые программы и учетные записи пользователей, уничтожайте все данные на выводимом из эксплуатации оборудовании Пятый случай: небольшая компания, оказывающая консалтинговые услуги в сфере телекоммуникаций, потеряла сделку, когда потенциальным клиентам стало известно о бреши в системе ее безопасности 6.Используйте средства физического контроля доступа ко всем вычислительным устройствам Шестой случай: архивные копии бухгалтерских данных уничтожены в результате пожара 7. Создавайте архивные копии важных файлов, папок и программ Седьмой случай: небольшая производственная компания потеряла крупный правительственный заказ из-за программной «бомбы замедленного действия» 8. Устанавливайте обновления для программного обеспечения Восьмой случай: сеть закусочных столкнулась с нарушением поставок; вышла из строя система бронирования номеров в гостинице — в обоих случаях программное обеспечение не обновлялось 9. Внедрите систему безопасности сети с контролем доступа Девятый случай: компьютерное вымогательство становится все более распространенным явлением 147 10. Ограничивайте доступ к ценным и конфиденциальным данным Десятый случай: сотрудник кредитного союза использовала конфиденциальные данные клиентов в целях личной наживы 11. Составьте и соблюдайте план управления рисками, связанными с безопасностью; заключите договор страхования с надлежащим покрытием Одиннадцатый случай: директор розничного интернет-магазина неправильно понял условия страховки и потерял сбой бизнес в результате атаки 12. При необходимости обращайтесь за технической поддержкой и сторонней помощью Двенадцатый случай: компания на венчурном капитале и юридическая компания попробовали обойтись без качественной технической поддержки и вскоре пожалели об этом решении 148 Virtualization.Развертывание виртуальной инфраструктуры на стандартных операционных системах. Рекомендации IDEAS для пользователей Ideas International (IDEAS) предлагает следующие рекомендации пользователям, которые выбирают операционную систему для виртуализации рабочих нагрузок — стандартную операционную систему SLES 10 и Windows Server 2008 или специализированное программное решение для виртуализации VMware: 1. Определите зависимости от устройств u1074 ввода/вывода и узнайте, поддерживаются в VMware ESX Server драйвера для них. 2. Изучите различия оптимальных решений для виртуальной инфраструктуры, предлагаемых VMware, Microsoft и Novell и определите, все ли краткосрочные требования будут выполнены выбранной платформой. 3. Обратите внимание на различия в возможностях управления виртуализацией этих платформ, в особенности, на опциях подготовки к работе. 4. Изучите взаимосвязь между управлением разными уровнями системного стека, включая программное обеспечение, операционную систему, виртуализацию, оборудование и хранение данных. Определите преимущества, предоставляемые единой инфраструктурой управления уровнями ПО/ОС и виртуализации. 5. Оцените общую стоимость владения платформой виртуализации, учитывая стоимость ПО для виртуализации и лицензий ОС, а также инструментария, поддержки, и процедур управления и обновления. Основные положения Так как важность виртуализации становится все более очевидной, некоторым пользователям кажется привлекательной программная платформа, оптимизированная специально для виртуализации. Однако использование признанных операционных систем для виртуализации рабочих нагрузок предоставляет ряд преимуществ, связанных с совместимостью, надежностью, функциональностью, безопасностью и управляемостью, например, возможность управления обновлениями. Операционные системы ESX Server компании VMware, SUSE Linux Enterprise Server 10 (SLES 10) компании Novell и Windows Server 2008 компании Майкрософт созданы для размещения на них виртуальной инфраструктуры. Однако некоторые ключевые различия в реализации этих платформ виртуализации могут оказать значительное влияние на требования к их развертыванию и управляемость. Реализации Xen, например, SLES 10, и реализация Microsoft Hyper-V в Windows Server 2008, фундаментально отличаются от VMware ESX Server на гипервизорном уровне и на уровне обработки процедур 149 ввода/вывода — т. е. в двух аспектах работы, которые являются наиболее критичными для виртуальных инфраструктур. В SLES 10 и Windows Server 2008 виртуализация ввода/вывода осуществляется через реальные драйверы устройств в u1089 стандартном образе операционной системы, а не в гипервизоре. Это обеспечивает значительные преимущества в совместимости, надежности, безопасности, интеграции и рабочем взаимодействии. Использование стандартных операционных систем для размещения на них виртуальных машин также позволяет пользователю воспользоваться преимуществами обширных функциональных возможностей этих операционных систем, к которым могут относиться расширенные функции управления хранением данных и кластеризация с высокой степенью готовности. Как минимум, эти стандартные ОС смогут снизить барьеры для реализации виртуализации во многих организациях. Кроме того, преимущества виртуализации на стандартных ОС могут значительно возрасти, когда пользователи привыкнут к использованию виртуальных машин и начнут внедрять технологию виртуализации непосредственно в ИТ-инфраструктуру. Экономическая эффективность виртуализации Очевидно, что виртуализация оказывает значительное влияние на ИТиндустрию. В более широком смысле виртуализация позволяет отделить рабочие нагрузки и данные от функциональных характеристик физических платформ, на которых они размещены. Такое разделение повышает гибкость, с которой рабочие нагрузки и данные могут быть сопоставлены физическим ресурсам, позволяя администраторам разрабатывать экономически ориентированные политики предоставления ресурсов, соответствующих, заданному времени, стоимости и сервисным требованиям. В результате виртуализация потенциально позволяет решать ИТ-задачи с большей экономической эффективностью, максимизировать использование имеющихся ресурсов благодаря эффективному управлению инфраструктурой, даже при ее сильном росте. 150 Операционные преимущества использования виртуализации В краткосрочном плане виртуализация может решить некоторые специфические проблемы, с которыми сегодня сталкиваются ИТ-менеджеры. Виртуализация уже доказала свою возможность предоставлять значительные экономические преимущества в ряде областей, среди которых: Консолидация и повышение эффективности использования ресурсов. В зависимости от природы консолидируемых рабочих нагрузок многие организации при использовании виртуализации регулярно достигают коэффициента консолидации 15 к 1 и выше. Консолидация серверов с помощью виртуализации позволяет администраторам сокращать количество физических компьютеров, которые нужно приобретать и обслуживать, что позволяет снизить стоимость обслуживания, снизить требования к охлаждению, сократить энергопотребление и площадь центров обработки данных. Также виртуализация позволяет добиться лучшего использования вычислительных ресурсов. Так как физические серверы часто развертываются для реализации отдельных приложений, возможно использование только части возможностей сервера. Оставшиеся ресурсы становятся «пробелами» — т. е. ресурсами, которые используются очень редко или вообще не используются. Виртуализация позволяет нескольким не полностью загруженным серверам совместно использовать ресурсы физической системы. Упрощение подготовки ресурсов. Виртуализация может значительно сократить время, необходимое для развертывания новых систем. Если пользователя понадобятся новые вычислительные ресурсы, вместо установки новых физических систем администраторы могут управлять созданным пулом виртуальных ресурсов. Если серверы реализованы как виртуальные машины, их можно создавать практически мгновенно с помощью команд или скриптов. Полный процесс инсталляции нового физического сервера с учетом времени, необходимого для определения спецификации необходимой системы, передачи запроса по административной цепочке, заказа оборудования, получения его от поставщика, конфигурирования системы и установки ее в серверной, может занять месяц или больше. При использовании виртуализации это время может быть сокращено до часа или меньше. В результате организация может более оперативно вести свой бизнес. Упрощение обеспечения высокой надежности и аварийного восстановления. Виртуализация может значительно повысить общую надежность инфраструктуры. Виртуализация позволяет сократить количество используемых физических серверов, уменьшив тем самым потенциальные возможности аппаратных сбоев,вызывающих внеплановые простои. Кроме того, установленные серверы могут быть сконфигурированы с функциями высокой доступности (например, избыточностью) и компонентами горячей замены для сокращения времени простоя. Возможность миграции виртуальной машины с одного хоста на другой с минимальным перерывом в ее работе также позволяет сократить время 151 планируемых простоев. Такая миграция позволяет временно переносить рабочие нагрузки, поэтому обслуживание оборудования может выполняться на хостмашинах с минимальными перебоями в работе.При совместном использовании с кластерными функциями высокой доступности виртуализация может использоваться для запуска рабочих нагрузок на резервном хосте после отказа основного хоста, что значительно упрощает процедуру восстановления после аварии. Традиционные реализации высокой надежности и восстановления после аварии требуют адаптации приложений и их зависимостей, чтобы их можно было запустить на резервной системе — это сложный процесс, который сложно выполнить без ошибок. При использовании виртуализации вся рабочая нагрузка может быть снова запущена простым перезапуском виртуальной машины, в которой она размещается. Усовершенствованные процедуры тестирования и разработки. Виртуализация упрощает и повышает качество тестирования и разработки, позволяя ИТ-менеджерам быстро выделять ресурсы, необходимые для выполнения тестирования.Виртуализация облегчает создание и управление комплексом тестовых систем. Виртуализация также помогает изолировать ошибки во время тестирования, нейтрализуя зависимость от оборудования и позволяя легко копировать производственную систему для тестирования. И наконец, виртуализация облегчает тестирование разрабатываемых приложений на различных ОС. Поддержка старых приложений. Виртуализация позволяет администраторам осуществлять миграцию старых приложений на новую аппаратную платформу, не нарушая их рабочей среды. В некоторых подобных случаях перевод некоторых приложений на новую платформу может быть затруднен или невозможен. В случае с ПО сторонних производителей создатель приложения может прекратить его поддержку, в случае с собственными приложениями исходный код может быть утерян или разработчики могут перейти на другую работу. В таких случаях виртуализация может использоваться для продления срока жизни приложения. Старые приложения могут устанавливаться в виртуальной машине, выполняющейся на новой платформе, пока они не будут заменены или переписаны. Виртуализация отдельного сервера по сравнению с виртуальной инфраструктурой Когда пользователи привыкают к виртуализации, они начинают рассматривать варианты,выходящие за рамки виртуализации отдельных серверов, и более интенсивно внедрять технологию виртуализации в ИТ-инфраструктуру, расширяя охватываемую ей область с отдельных сервером сначала до комплексных систем, а затем до центров обработки данных или организаций. По мере того, как виртуализация становится стандартной функцией различных платформ, пользователи могут быть все более уверены в том, что по крайней мере некоторые возможности виртуализации будут доступны на всех их системах. Когда 152 базовые функции виртуализации сочетаются с высокоуровневыми средствами управления, которые специально предназначены для управления несколькими виртуальными системами, они могут стать основой для всей виртуальной инфраструктуры. В виртуальных инфраструктурах несколько виртуальных систем рассматриваются как гибкий пул ресурсов, которые могут динамически выделяться в зависимости от изменения рабочей нагрузки или перерывов в работе. Целью создания таких виртуальных инфраструктур является снижение стоимости приобретения и выполнение мероприятий, направлены на снижение эксплуатационных расходов. Так как виртуализация изолирует рабочие нагрузки от аппаратной части серверов, на которых они размещаются, возможно перемещение рабочих нагрузок с одного компьютера на другой без нарушения их прикладного окружения. Например, некоторые реализации виртуальных машин позволяют сохранять все состояние работающей виртуальной машины в стандартный файл, который u1084 может передаваться по сети. Рабочие нагрузки можно переносить с одного физического сервера на другой, просто копируя этот файл по сети. Выполняющиеся на виртуальной машине приложения продолжают работать в том же окружении (включая ОС и ПО промежуточного слоя), для их работы не нужны сведения о фактическом физическом размещении. Возможность передавать виртуальные рабочие нагрузки по сети таким способом позволяет выполнять ряд операций, значительно сокращающих эксплуатационные расходы,включая: Управление планировыми и внеплановыми простоями. Администраторы могут обновлять оборудование или заменять старый сервер на новый без переустановки ОС или приложений. При совместном использовании с кластерными функциями высокой доступности эта возможность также может использоваться для перезапуска рабочих нагрузок на резервном хосте в случае отказа основного хоста. Обслуживание сервисных уровней. Возможность миграции виртуальных машин в сети с помощью простого копирования файлов также упрощает реализацию балансировки загрузки серверов. Рабочие нагрузки можно перемещать с сильно загруженных серверов на менее загруженные машины. Внедрение виртуализации может помочь повысить доступность системы различными способами. Во-первых, сокращение затрат на приобретение серверов позволяет консолидировать средства, которые могут быть инвестированы в средства для реализации автоматического поддержания высокой доступности и восстановления при аварии. Кроме того, консолидация нескольких серверов в виртуальные машины на меньшем количестве физических систем уменьшает общее количество оборудования и, следовательно, сокращает количество потенциальных причин отказов, вызванных неисправностью оборудования.Сокращение количества серверов в результате консолидации также упрощает инфраструктуру, облегчая создание ее резервной копии для восстановления. Так как виртуальные машины не привязаны к физическому оборудованию, на котором они размещаются, администраторы имеют возможность 153 сконфигурировать резервную инфраструктуру на оборудовании, класс которого отличается от основной платформы. Т. е. для резервной системы, обычно работающей в резервном режиме, может использоваться более дешевое оборудование. Хотя производительность таких систем при передаче на них производственных рабочих нагрузок будет меньше, клиенты обычно соглашаются на снижение производительности на ограниченный период времени после аварии. Другим возможным способом сокращения стоимости обеспечения резервной системы является использование тестовых систем/систем для разработки в качестве резервных. Эти системы могут быть предварительно сконфигурированы с виртуальным образом, который остается в режиме готовности, пока он не потребуется для восстановления производственных рабочих нагрузок в случае аварии. Ресурсы могут динамически забираться у систем для разработки или тестовых систем и передаваться производственной системе, когда они потребуются. Виртуализация быстро становится стандартной частью ИТинфраструктуры, как в области оборудования, так и в области ПО. Почти все основные операционные системы включают поддержку виртуализации, новые опции для платформ виртуальных машин анонсируются. В конечном счете, виртуализация может изменить конфигурирование или обслуживание центров обработки данных. Однако, процесс развертывания виртуальной инфраструктуры начинается с выбора платформы виртуальной машины для исходных приложений, и при этом выборе должны рассматриваться некоторые важные факторы. Позиционирование архитектур виртуальных машин Компания IBM уже давно разрабатывала возможности виртуализации для мэйнфреймов. Позднее компания VMware представила ПО виртуальных машин для платформы x86. Компания VMware впервые начала поставлять сервер предприятия ESX Server в 2001 году. С тех пор на рынке появилось несколько альтернатив продуктам VMware. Одной из первых серверных платформ виртуальных машин, получивших значительный успех на рынке после продукции VMware, стала платформа Microsoft Virtual Server, поставки которой начались в 2004 году. Затем появился гипервизор виртуальных машин Xen, основанный на ПО с открытым кодом. Гипервизор Xen был интегрирован в несколько ведущих дистрибутивов Linux, первым из которых стал Novell’s SUSE Linux Enterprise Server 10 (SLES 10), в котором виртуализация на основе Xen появилась в 2006 году. Реализация платформы виртуализации Microsoft Hyper-V, которая будет интегрироваться в новую ОС Windows Server 2008, очень похожа на Xen и обеспечивает совместимость с реализациями Xen, например, в SLES 10. 1 Для миграции необходима некоторая общность оборудования хостов. Например, если платформа виртуальной машины использует виртуализацию на аппаратном уровне, например, Intel VT, то резервный сервер также должен быть сконфигурирован с Intel VT. VMware, SLES 10 и Windows Server 2008 созданы для виртуализации серверов. Однако, некоторые ключевые различия в реализации этих платформ виртуализации могут оказать значительное влияние на требования к их 154 развертыванию и управляемость. Для понимания этих различий необходимо подробно рассмотреть организацию платформ виртуальных машин. Основные технические аспекты виртуализации Одним из основных достоинств виртуализации является возможность одновременной работы нескольких ОС на одном сервере. Наиболее гибким способом решения этой задачи является использование виртуальных машин, которые программно создают полную компьютерную систему и могут использоваться и управляться как приложения. Реализация платформы виртуальной машины имеет несколько специфичных требований, включая следующие: Планировщик. Этот компонент предоставляет разным виртуальным машинам доступ к физическим ресурсам. Планировщик использует механизм квантования времени с политиками, основанными на приоритетах и резервах, назначенных администратором виртуальным машинам Управление памятью. Этот компонент выделяет виртуальную память различнымвиртуальным машинам на сервере и освобождает ее. Машина состояний. Этот компонент содержит информацию о текущем состоянии виртуальной машины, включая процессор, память, устройства и т. д. Хранение данных и сеть. Эта функция обеспечивает совместный доступ нескольких виртуальных машин к ресурсам хранения данных и сети. Для выполнения этой задачи компонент должен обеспечивать мультиплексный (т. е. с квантованием времени) доступ к реальным устройствам (например, адаптерам шины хоста или сетевым картам) из виртуальных машин. Мультиплексирование должно быть согласованным (т. е. запись и чтение данных должны осуществляться корректно, независимо от порядка выполнения виртуальных машин), изолированным (т. е. сбой ПО во время операций ввода/вывода на одной виртуальной машине не должен вызывать нестабильность другой виртуальной машины) и защищенным (т. е. виртуальная машина не должна получать информацию об операциях ввода/вывода, выполняемых на другой виртуальной машине). Виртуальные устройства. Эта функция является связующим звеном между виртуальным и физическим миром. Она предоставляет выполняющейся на виртуальной машине ОС информацию об устройствах, которые ведут себя так же, как их реальные аналоги. Таким образом, приложения могут получить доступ к устройствам также, как если бы они выполнялись на физическом сервере (например, с помощью драйвера устройства — см. ниже). Драйверы виртуальных устройств. Эти компоненты устанавливаются в гостевой ОС, выполняющейся на виртуальной машине, чтобы приложения смогли получить доступ к виртуальному представлению оборудования и каналов ввода/вывода также, как они получают доступ к физическому оборудованию и каналам ввода/вывода физической машины. 155 Двоичная трансляция. Эта функция была необходима в первых поколениях реализаций виртуальных машин для архитектуры x86, которая не была предназначена для виртуализации, и поэтому, в некоторой степени не обладала функциональностью, необходимой для виртуальных машин. Традиционно платформы виртуальных машин выполняли процедуру трансляции или эмуляции при каждом попытке гостевой ОС выполнить «привилегированную» инструкцию (т. е. низкоуровневую инструкцию, права на выполнение которой для поддержания согласованности были только у ОС хоста). Позднее Intel и AMD изменили свои процессоры для поддержки виртуализации. Эта поддержка разрешает нескольким виртуальным машинам выполнять привилегированные инструкции, которые могут определяться и выполняться непосредственно на аппаратном уровне. Поэтому платформам виртуальных машин более не требуется выполнять эту функцию на уровне ПО. Интерфейс управления. Платформа виртуальной машины должна предоставлять различные интерфейсы управления ее работой и контроля виртуальных машин, выполняющихся на хосте. Этот интерфейс должен поддерживать множество операций, например, создание и конфигурирование виртуальных машин, контроль их работы и т. д. Кроме того, необходимо обеспечить интерактивный интерфейс (используемый администраторами) и программный интерфейс (используемый другими программами через интерфейс прикладного программирования (API)). Также в современной ИТинфраструктуре необходимо, чтобы интерфейс управления был полностью доступен по сети для дистанционного конфигурирования и управления хостом виртуальных машин и самими виртуальными машинами. Сравнение реализованной в операционной системе виртуализации и специализированного программного обеспечения для виртуализации. Платформы виртуальных машин должны в той или иной форме реализовывать перечисленные выше компоненты и функции. На практике способы реализации этих функций и их взаимодействия сильно различаются в платформах виртуальных машин. Основные функции платформы виртуальной машины — планировщик, управление памятью, и машина состояний (т. е. компоненты для выделения виртуальным машинам основных вычислительных ресурсов, например, процессора и памяти). В новых платформах виртуальных машин, например, Xen and Microsofts Hyper-V, эти функции имеют общее название «гипервизор». Гипервизор также отвечает за создание разделов и поддержание жесткой изоляции между разделами. Профессиональная платформа виртуальной машины VMware реализует эти функции в пакете программного обеспечения ESX Server, который согласно описанию также основан на механизме, похожем на гипервизор. Несомненно, нет больших различий в том, как: Hyper-V, Xen и ESX Server выполняют фундаментальный контроль виртуальных машин13.Однако, реализации Одним важным различием является двоичная трансляция. ESX Server до сих пор использует двоичную трансляцию для выполнения привилегированных инструкций, как и 13 156 Xen, например, SLES 10 и реализация Microsoft Hyper-V, фундаментально отличаются от VMware ESX Server на гипервизорном уровне и на уровне обработки процедур ввода/вывода — т. е. в двух аспектах работы, которые являются наиболее критичными для виртуальных инфраструктур. Все три реализации подразумевают установку драйверов виртуальных устройств в гостевой ОС, которая взаимодействует с драйверами реальных устройств для выполнения фактических операций ввода/вывода. Однако u1074 в VMware ESX Server драйверы реальных устройств находятся в самом гипервизоре. В Xen и Hyper-V драйверы реальных устройств находятся в специальной административной виртуальной машине со стандартной ОС, например, SLES 10 или Windows Server 2008. Используя высокопроизводительный канал, драйверы виртуальных устройств в гостевых операционных системах взаимодействуют со стандартными драйверами устройств в административной ОС, выполняющей непосредственно аппаратные операции ввода/вывода (см. Рис. 1). В результате административная ОС выполняет все функции хранения данных и работы с сетью, в то время как в VMware эти функции выполняются в гипервизоре. Хотя различие этих реализаций может показаться незначительным, оно может оказать значительное влияние на развертывание и управление платформами виртуальных машин. Виртуализация ввода/вывода с помощью драйверов реальных устройств в стандартной операционной системе может обеспечить следующие преимущества: Совместимость. Выполняющиеся на виртуальной машине операционные системы могут получить доступ к устройствам, используя стандартные драйверы устройств (т. е. те самые драйверы, которые используются при установке административной ОС непосредственно на оборудование). Например, если в качестве административной ОС используется дистрибутив Linux, например, SLES 10, гостевая ОС получит доступ ко всем драйверам устройств, поддерживаемым SLES 10. А если в качестве административной ОС используется Windows Server 2008, то гостевая ОС получит доступ к любому оборудованию, поддерживаемому этой версией Windows. VMware, напротив, требует, чтобы пользователи u1087 получали драйверы устройств, специально разработанные для ESX Server. Хотя модель драйвера устройства ESX Server похожа на модель драйвера для Linux, разработчики должны используя свой код создавать специальную версию для VMware — что означает для них тестирование и поддержку еще одной платформы. Как правило, разработчики драйверов сначала сосредотачиваются на Windows и/или Linux, и лишь затем начинают заниматься другими платформами, например, ESX Server. Поэтому пользователи VMware могут не сразу получить виртуализованный доступ к новому оборудованию. Надежность и безопасность. Перенося задачу управления драйверами устройств, а также функциями доступа к устройствам хранения данных и сети некоторые реализации Xen. Microsoft Hyper -V для определения и выполнения привилегированных инструкций использует исключительно аппаратные возможности виртуализации процессоров Intel и AMD 157 в административную ОС, сам гипервизор становится проще и требует меньше кода (по этой причине архитектура гипервизоров, похожих на Xen и Microsoft Hyper-V, обычно называется «тонкой»). Сокращение кода может увеличить надежность гипервизора просто потому, что в нем будет меньше возможностей для сбоев. Сокращение кода также повышает безопасность, так как уменьшает «поле для атаки» через которое может осуществляться вторжение. Безопасность гипервизора также увеличивается благодаря отсутствию функций доступа к устройствам хранения данных и к сети, в которых может быть много уязвимостей. Подводя итог можно сказать, что если функции виртуализации реализованы в стандартных операционных системах, они могут использовать преимущества проактивных функций для поддержания защищенной инфраструктуры, например, службы каталогов для авторизации и аутентификации. Интеграция с существующей инфраструктурой. Использование стандартных драйверов устройств и традиционных функций доступа к сети и устройствам хранения данных хостом виртуальной машины облегчает интеграцию виртуальных машин в существующие системы. Поддержка стандартных драйверов устройств позволяет виртуальным машинам получить доступ к фактически используемому оборудованию. Неразрывное использование функций доступа к системам хранения данных и сети означает, что пользователи могут разворачивать в точности те же расширения в виртуальной и физической инфраструктурах. Унификация эксплуатации. Если административная операционная система является стандартной, например, Windows или Linux, пользователи могут использовать стандартные инструменты системного управления для хостов виртуальных машин. Унификация применима и интерактивным инструментам (например, консолям и графическим интерфейсам) и к программным интерфейсам (т. е. интерфейсам прикладного программирования, используемым дополнительными приложениями). Реализация виртуализации в ОС также повышает уровень интеграции с существующей инфраструктурой, позволяя использовать существующие инструменты и процессы для обновления, поддержки и т. д. Эти преимущества доступны в общем случае, если виртуальные машины установлены на стандартных ОС. Кроме того, в зависимости от возможностей используемой для размещения виртуальных машин ОС возможно получение других преимуществ, обусловленных функциональными возможностями операционной системы хоста. В этой связи целесообразно изучить основные возможности SLES 10 и Windows Server 2008 и те преимущества, которые они могут дать при реализации виртуализации. 158 Достижение преимуществ от виртуализации при использовании SLES 10 и Windows Server 2008 Майкрософт и Novell добавили возможность виртуализации в новые версии своих серверных ОС. Novell поставляет реализацию гипервизора Xen в SUSE Linux Enterprise Server 10 с июля 2006 года. Майкрософт добавила поддержку виртуализации в ОС следующего поколения Windows Server 2008, которая вышла в феврале 2008 года (сама функция Hyper-V будет поставляться в течение 180 после выпуска of Windows Server 2008 для производителей (RTM)). И Майкрософт и Novell используют стандартные административные ОС для своих платформ виртуальных машин (Windows Server 2008 в случае Майкрософт и SLES 10 в случае Novell). Кроме того, Майкрософт и Novell разработали совместные вспомогательные возможности для обеспечения совместимости их платформ виртуальных машин. В результате соглашения о техническом сотрудничестве между Майкрософт и Novell были созданы технологии, позволяющие пользователям размещать виртуальные машины с SUSE Linux Enterprise на хостах с Windows Server 2008 или виртуальные машины с Windows Server 2008 на хостах с SUSE Linux Enterprise. Обе компании продолжают сосредотачивать усилия на оптимизации своих платформ для гомогенной виртуализации (т. е. виртуальные машины с SUSE Linux Enterprise размещенные на хостах с SLES 10 и виртуальные машины Windows, размещенные на хостах с Windows Server 2008). Также Майкрософт и Novell совершенствуют свои платформы виртуальных машин для управления виртуальными рабочими нагрузками и реализации виртуальной инфраструктуры. Во всех возможных случаях эти реализации используют преимущества от совместимости между их стандартными операционными системами и функциями виртуальных машин. Основные сценарии виртуализации Novell и Майкрософт предлагают использовать свои платформы виртуальных машин для ключевых случаев виртуализации, включая консолидацию, тестирование и разработку, обеспечения непрерывности деловой активности и поддержки старых приложений. SLES 10 и Windows Server 2008 являются оптимальными хостами для консолидации, в частности, благодаря их 64-разрядным возможностям. Поддержка 64-разрядных систем полезна, если пользователь хочет разместить большое количество виртуальных машин на одном физическом сервере, что является типичным случаем для консолидации. В этом случае увеличение памяти полностью 64разрядных систем обеспечивает больше возможностей наращивания консолидированных систем. Майкрософт также предоставляет исключительно надежный набор инструментов для разработки программного обеспечения, который работает совместно с платформой виртуальных машин, помогая крупным командам разработчиков использовать преимущества виртуализации для сокращения времени разработки. Также платформы виртуальных машин Майкрософт и Novell поддерживают старые версии Windows и SUSE Linux Enterprise в качестве гостевых ОС, позволяя пользователям использовать старые рабочие разгрузки, зависящие от этих систем. 159 Управляемость В то время, как виртуализация все в большей степени становится стандартной частью оборудования и операционных систем, внимание к вопросам виртуализации смещается в сторону ее влияния на инструменты и процессы управления. Исследования, проведенные Ideas International (IDEAS), показали, что виртуализация не приводит к фундаментальным изменениям в общем управление системами, выполняемом пользователями. Обычно, администраторы продолжают использовать в виртуальных серверах те же инструменты управления, которые они использовали в физических серверах. Майкрософт и Novell приложили большие усилия к расширению возможностей управления и результаты этих усилий применимы непосредственно к виртуальной инфраструктуре размещаемой на их операционных системах. Кроме двусторонней виртуализации u1089 соглашение о техническом сотрудничестве между Microsoft и Novell включает сотрудничество в области ключевых стандартов управления системами, а также в области взаимодействия директорий и идентификации — это два направления, которые являются критичными в помощи пользователям в развертывании виртуальных инфраструктур, включающих обе платформы — Windows и SUSE Linux. На конференции Brainshare в начале этого года Novell продемонстрировала, что часть работы по обеспечению взаимодействия инструментов системного управления и процедур для Linux и Windows уже проделана. До сих пор было публично продемонстрировано взаимодействие между ПО Novell и Microsoft на различных уровнях, включая: Доступ к серверу Microsoft Sharepoint с учетными записями Novell eDirectory через службы Federated Services Управление службами доменов для Windows (реализация служб сетевых директорий Майкрософт для Linux) выполняющаяся под управлением SLES из интерфейса стандартной консоли управления Майкрософт (MMC), выполняющейся под управлением Windows. Установление доверительных отношений между Microsoft Active Directory и Domain Services для Windows. » Установление доверительных отношений (cross-forest trust) между стандартными экземплярами Windows Server 2003 и SLES. Добавление пользователей в Active Directory из административного интерфейса Novell iManage. Майкрософт и Novell достигли и другого успеха в управлении виртуальной инфраструктурой: Возможности их инструментов управления связывать инструментарий их платформ виртуальных машин с инструментарием их операционных систем. Возможность получать полную информацию о состоянии ПО в системном стеке может оказаться очень полезной для администраторов при поддержании производительности и доступности виртуальной инфраструктуры. Эта всеобъемлющая информация предоставляет данные, которые невозможно получить в других решениях управления виртуальными машинами, например, в «чистой виртуализации», предлагаемой VMware, или в предложениях 160 заинтересованных в виртуализации производителей оборудования, например, Dell, HP и IBM. Инструменты развертывания Так как сконфигурировать новую виртуальную машину гораздо проще, чем физическую, конечные пользователи часто повышают свои требования к новым системам. В результате при реализации виртуализации от администраторов требуется предоставление большего количества виртуальных серверов с необходимым ПО для поддержки рабочих нагрузок (т. е операционных систем, обновлений, ПО промежуточного слоя, приложений и т. д.). Ключом для решения этих задач является использование комплексных средств развертывания, которые могут облегчить установку или обслуживание ПО, необходимого для эффективного выполнения рабочих нагрузок на виртуальных машинах. Novell предлагает решение ZENworks Orchestrator, оптимизированное для автоматизированного выделения ресурсов для изменения рабочих нагрузок в SUSE Linux Enterprise (и на других платформах). ZENworks Orchestrator хорошо зарекомендовал себя при развертывании виртуальных машин Xen на SLES 10, от части благодаря тому, что административная ОС Xen с точки зрения управления не отличается от любого другого окружения SLES 10. Майкрософт предлагает решение для развертывания ПО под названием System Center Configuration Manager 2007, являющееся приемником системы развертывания ПО System Management Server (SMS) — одного из самых развитых продуктов для системного управления. Совместно с другими продуктами в растущее предложение продуктов управления System Center компании Майкрософт входит менеджер виртуальных машин System Center Virtual Machine Manager и такие инструменты, как System Center Configuration Manager, позволяющие администраторам Windows непосредственно использовать их опыт в управлении физическими системами для управления виртуальной инфраструктурой, u1088 размещенной на Windows Server 2008. Недавно Майкрософт добавила в архитектуру управления System Center компонент Virtual Machine Manager (VMM), позволяющий выполнять управление виртуальными системами, используя тот же интерфейс System Center, который используется для управления физическими системами. Поддержка виртуализации в System Center означает, что другие инструменты из этого пакета, например, System Center Configuration Manager 2007, могут использоваться для автоматизации процесса установки ПО на виртуальных машинах. System Center Configuration Manager 2007 использует основанный на моделях принцип определения требуемого состояния окружения и поддерживает это состояние, устанавливая необходимые обновления. Одной из ключевых возможностей System Center VMM является веб-портал самообслуживания, с помощью которого авторизованные пользователи могут сами развертывать новые виртуальные машины (т. е. без прямого участия ИТ-специалистов). Эта 161 возможность особенно полезна при тестировании и разработке, разработчику нужно часто создавать временные виртуальные машины. когда Выводы IDEAS Пользователи согласны с тем, что преимущества от виртуализации стоят усилий на ее реализацию. Это помогает объяснить огромный интерес к платформам виртуализации. Однако для большинства пользователей основным вопросом является поиск способа самой безболезненной реализации виртуализации. Действительно, выбор платформы виртуальных машин для реализации становится стратегическим решением с далеко идущими последствиями. Решения с размещением виртуальных машин на специальных программных платформах для виртуализации, например, VMware, и решения с их размещением на стандартных операционных u1089 системах, например, Linux и Windows, имеют свои преимущества. Хотя использование программной платформы, оптимизированной исключительно для виртуализации, может казаться привлекательным, на самом деле использование признанных операционных систем для виртуализации рабочих нагрузок предлагает ряд значительных преимуществ в области совместимости, надежности, функциональности, возможности интеграции в существующую инфраструктуру, процедур поддержки и механизмов обновления. Благодаря поддержке существующих драйверов устройств стандартные операционные системы не требуют от разработчиков адаптации новой модели драйверов устройств. Для платформы x86 созданы десятки тысяч драйверов и меньше всего разработчики и пользователи хотят услышать, что они должны изменять архитектуру драйверов, обращаться к производителям оборудования или независимым поставщикам ПО для получения новых драйверов. Виртуальные машины, работающие под управлением SLES 10 и Windows Server 2008, могут использовать преимущества тех самых драйверов, которые известны пользователям на протяжении многих лет. С точки зрения архитектуры размещение этих драйверов в административной ОС, а не в самом гипервизоре, также может потенциально увеличить надежность и безопасность платформыхоста. Кроме того, при интеграции функций виртуальной машины в стандартные операционные системы пользователю больше не нужно приобретать отдельные решения для реализации виртуальных машин, включая сопутствующие контракты на поддержку и обучение. Пользователи могут управлять хостами виртуальных машинам с помощью существующих интерфейсов точно также, как ранее они управляли физическими системами, кроме того, эти инструменты управления расширены для контроля функциями виртуализации ОС. Также возможно использование тех же самых инструментов и процедур для обслуживания и обновления хоста виртуальной машины и использование существующей инфраструктуры безопасности для выполнения аутентификации и авторизации. И наконец, использование стандартных операционных систем для размещения на них виртуальных машин 162 позволяет пользователям воспользоваться преимуществами обширных функциональных возможностей этих операционных систем, к которым могут относиться расширенные функции управления хранением данных и кластеризация с высокой готовностью. Архитектура платформы VMware сложилась в результате исторических факторов. Когда VMware начала разработку своей платформы в 1990 годы, она сталкивалась с ограничениями, которые сильно отличались от современных. В то время архитектура x86 была квазиоптимальной для размещения виртуальных машин и требовала от VMware сосредоточения на решения таких проблем, как двоичная трансляция. В дальнейшем VMware как независимый разработчик ПО не имела возможности интегрировать свои виртуальные функции ввода/вывода непосредственно в ведущие операционные системы. При разработке своих решений Novell и Майкрософт and Microsoft воспользовались преимуществами нескольких факторов, включая возможность непосредственной интеграции виртуализации с другими критическими функциями операционной системы и появления аппаратной виртуализации в новых процессорах x86. В результате они могут предложить платформы для виртуальных машин, которые обеспечивают более простую адаптацию в существующую физическую инфраструктуру и создают прочную основу для развертывания новой виртуальной инфраструктуры. 163 Виртуализация приложений: новые рубежи SoftGrid® Application Virtualization Как технология виртуализации приложений Microsoft® SoftGrid® помогает организациям сократить затраты на ИТ, увеличить производительность пользователей, повысить уровень обслуживания и динамичность бизнеса. Аннотация. В современных условиях ИТ-отделы предпринимают массу усилий, направленных на сокращение издержек, повышение динамичности бизнеса, обеспечение надлежащего обслуживания и поддержание удовлетворенности заказчиков на высоком уровне. Технология виртуализации приложений Microsoft SoftGrid помогает достичь всех этих целей. Виртуализация приложений позволяет преобразовать приложения в централизованно управляемые и размещаемые виртуальные службы, которые выполняются на локальных компьютерах по запросу. За счет этого упрощаются процессы развертывания, обновления и администрирования приложений и сокращаются трудовые затраты. Кроме того, виртуальные приложения выполняются на клиентских компьютерах в собственной среде. Это значительно снижает степень воздействия приложения на операционную систему и тем самым уменьшает вероятность возникновения конфликтов между приложением и операционной системой. Такое разделение и исключение конфликтов между приложениями и операционной системой позволяет не только сократить текущие расходы на ИТ, но также снизить потребности в регрессивном тестировании и использовании контейнеров серверов. И последний, но не менее важный момент: можно полностью исключить проблемы совместимости приложений, которые обычно доставляют больше всего неприятностей при миграции операционной системы (например, при переходе с платформы Windows XP на Windows Vista). Вывод: технология виртуализации приложений, помогающая отделам ИТ сократить совокупную стоимость владения (TCO), повысить уровень обслуживания и быстрее реагировать на постоянно меняющиеся потребности, становится стратегическим инструментом, который обеспечивает значительные конкурентные преимущества и дает возможность организациям сделать еще один шаг в направлении оптимизации инфраструктуры. Февраль 2007 г. Омер Куреши (Omer Qureshi), MCSA, MCSE, CCDA, PMP, BEA, Security+корпорация Майкрософт 164 Основные положения Руководители отделов информационных технологий вынуждены постоянно думать над тем, как помочь организации сократить текущие расходы и повысить динамичность бизнеса, соблюдая при этом законодательные требования и требования безопасности, а также как обеспечить должное качество обслуживания и поддержать удовлетворенность заказчиков на высоком уровне. В связи с наблюдаемым в последние годы экспоненциальным ростом компьютерных мощностей организаций борьба с издержками стала еще более трудным делом. Снижение цен на оборудование приводит к разрастанию парка серверов и персональных компьютеров и появлению новых забот, таких как использование избыточных вычислительных мощностей, рост центров обработки данных и необходимость изоляции различных видов информации в контейнерах серверов и ПК. И это только то, что касается оборудования. Частота и сложность процессов развертывания программных приложений увеличивают нагрузку на отделы ИТ. Недавнее исследование, проведенное компанией Gartner, показало, что организации по всему миру тратят 70% своих ИТ-бюджетов на поддержание имеющейся среды и только 30% — на новые инициативы . Попытки найти способ сократить постоянно растущие затраты на поддержку имеющихся приложений превратились для отрасли в поиск Святого Грааля. В совокупности эти тенденции в области программного и аппаратного обеспечения ведут к росту административных расходов по восходящей спирали и к недоиспользованию ИТ-активов. Но на горизонте забрезжил луч света — инновационные технологические решения, благодаря которым ИТ-отделы сумеют справиться с этими проблемами. Особые надежды возлагаются, в частности, на технологию виртуализации. Виртуализация позволяет скрывать физические характеристики компьютерных ресурсов при взаимодействии других систем, приложений или пользователей с этими ресурсами. Появление нового поколения двуядерных процессоров и достижения в области сетевой и распределенной компьютерной обработки способствуют бурному развитию технологии виртуализации. Эта технология может быть облечена в разные формы: использование виртуальных машин с целью консолидации серверов и настольных ПК, предоставление программного обеспечения в виде служб (SaaS) и совсем новая форма — виртуализация приложений. Новое слово в этой области скажет технология Microsoft SoftGrid, с помощью которой корпорация Майкрософт намерена стать пионером на рынке виртуализации приложений. Виртуализация приложений отличается от других видов виртуализации (компьютеров, хранилищ или сетей) тем, что не требует существенных инвестиций в оборудование, персонал и базовую инфраструктуру. Технология виртуализации приложений, реализованная в решении SoftGrid, позволяет преобразовывать приложения, работающие в операционной системе Windows , в централизованно i ® 165 управляемые и размещаемые виртуальные службы, которые выполняются локально на клиентских компьютерах, подключенных к интрасети (LAN, WAN, VPN), Интернету или беспроводным сетям. Виртуализация приложений с помощью Microsoft SoftGrid оказывает отделу ИТ существенную помощь в сокращении административных расходов. Например, она помогает реализовать в организациях некоторые передовые методы, которые, как выяснилось в ходе последних исследований трудозатрат ИТ-персонала и пользователей, позволяют значительно сократить расходы на администрирование настольных компьютеров и приложений, работающих под управлением текущей версии ОС Windows (см. Таблица 13) Таблица 13. Сокращение трудозатрат ИТ-специалистов и пользователей в результате внедрения передовых методов Передовой метод Возможная экономия, долл. США 110 на ПК в год Внедрение SoftGrid Централизованное управление конфигурацией и настройкой ПК 190 на ПК в год При использовании SoftGrid потоковая доставка приложений осуществляется только санкционированным и утвержденным пользователям Управление ПК с использованием объектов групповой политики 120 на ПК в год SoftGrid выполняет потоковую доставку приложений пользователям на основании их членства в группе службы каталогов Active Directory® Комплексная централизованно управляемая программа обеспечения безопасности 130 на ПК в год Поскольку технология SoftGrid позволяет выполнять приложения в «виртуальном пузыре», ИТадминистраторы могут снизить уровень привилегий на рабочих станциях до минимального значения Автоматизация инициализации пользователей 50 на ПК в год Решение SoftGrid интегрировано с интерфейсом службы Active Directory для задания разрешений пользователей и инициализации пользователей Централизованное управление установкой приложений на ПК 70 на ПК в год Пакеты приложений SoftGrid размещаются на центральном сервере, с которого осуществляется их распространение Стандартизация за счет использования единой версии ОС на настольных ПК Решение SoftGrid помогает сократить требуемое количество сборок операционных систем и образов 166 Словом, решение Microsoft SoftGrid помогает отделу ИТ сократить затраты и улучшить обслуживание за счет снижения уровня сложности и трудозатрат при развертывании приложений на настольные и переносные компьютеры и серверы терминалов, а также упрощения процесса обновления приложений. Выполнение приложений на локальных компьютерах является ключевым отличием технологии SoftGrid от предыдущих решений в области виртуализации, основанных, например, на использовании сервера терминалов Microsoft Windows Server® или сервера Citrix. При таком подходе требуется размещать и выполнять приложения на серверах, что приводит к лавинообразному росту количества серверов и, соответственно, к росту расходов на закупку и обслуживание оборудования. Более того, для предотвращения конфликтов между приложениями в такой среде приходится создавать отдельные экземпляры серверов для размещения разных приложений, что еще более способствует разрастанию контейнеров серверов и, как результат, усложнению управления и росту административных затрат. В противоположность этому, технология SoftGrid позволяет централизованно предоставлять приложения и управлять ими, но при этом выполнять приложения локально на клиентских компьютерах. Такой подход снижает остроту проблем, связанных с ростом парка оборудования и конфликтами между приложениями. При этом сохраняются все преимущества технологии SaaS (такие как удобство доступа, распространения и управления) для более ранних приложений клиент-сервер. Технология SoftGrid предлагает ИТ-специалистам новую возможность в кратчайшие сроки повысить эффективность работы за счет уменьшения прямых расходов отдела ИТ на развертывание и обновление приложений, службу поддержки, другие типы поддержки, управление ИТ-активами и регрессивное тестирование. Технология SoftGrid также помогает снизить косвенные затраты на ИТ в области управления программным обеспечением и соблюдением законодательных норм, управления лицензиями и обеспечения удовлетворенности заказчиков iv. Кроме того, благодаря возможности развертывания технологии SoftGrid практически на любом этапе жизненного цикла приложения отделы ИТ могут добиться снижения совокупной стоимости владения и повышения уровня обслуживания в масштабах всей организации. Таким образом, решение SoftGrid может стать для организаций стратегическим инструментом, обеспечивающим конкурентные преимущества. В данном документе говорится о том, что такое виртуализация приложений, как она работает и как ведущие системные архитекторы и лица, принимающие решения в области ИТ, могут с ее помощью сократить постоянно растущие расходы на развертывание приложений и управление ими. Изложенные сведения подтверждаются реальными примерами экономии, достигнутой организациями при переходе на технологию виртуализации приложений SoftGrid. 167 Сокращение затрат на ИТ с помощью виртуализации Сегодня отделы ИТ во всем мире сталкиваются с новыми чрезвычайно сложными проблемами, без решения которых невозможно преуспеть в конкурентной рыночной среде. К ним, в частности, относятся: нарастающие угрозы безопасности (включая проникновение в систему и кражу данных); рост затрат на поддержку, развертывание и обновление приложений; требование внутренних и внешних заказчиков повысить качество ИТобслуживания и ускорить предоставление услуг; рост парка серверов и настольных систем, приводящий к усложнению центров обработки данных и инфраструктуры настольных систем, которыми становится трудно управлять. Однако не только такой рост и сложность способствуют увеличению административных расходов. Отсутствие гибкости активов означает, что затраты остаются фиксированными независимо от изменения потребностей организации. Технологии виртуализации помогают ИТ-специалистам решить большую часть этих проблем. Привлекательность виртуализации заключается в возможности создания динамических компьютерных сред. Виртуализация позволяет отделить одни элементы компьютерной среды от других. В результате каждый уровень системы может пользоваться ресурсами, не требуя настройки для конкретной системы. Кроме того, виртуальная среда дает возможность организациям повысить эффективность использования ресурсов за счет динамического назначения каждого элемента той функции или задаче, которая больше всего нуждается в ресурсах, поскольку каждому элементу компьютерной среды больше не назначается определенная роль или функция (например, сервер инженерных приложений) v. Сегодня трудно представить себе отдел ИТ, в котором не рассматривается возможность виртуализации управляемых им ресурсов, если, конечно, такая виртуализация уже не осуществлена. Организации по разным причинам проявляют интерес к виртуализации. Это может быть обусловлено желанием использовать новые технологические решения, необходимостью повысить производительность оборудования, улучшить возможности аварийного восстановления и повысить уровень отказоустойчивости или упростить управление системами и ресурсами. Независимо от конкретной причины все организации, занимающиеся внедрением решений для виртуализации, преследуют одну простую цель: добиться значительного сокращения издержек. Виртуализация уже нашла широкое применение Сейчас все более широкое применение получают такие формы виртуализации, как виртуализация сети, оборудования, хранилищ, компьютеров, управления и сеансов, и к ним готова присоединиться виртуализация приложений (см. Таблица 14). Примером быстрого распространения технологий виртуализации может служить виртуализация серверов. По прогнозам компании IDC, к 2010 году 1,7 168 миллиона физических серверов будут обеспечивать возможности виртуализации ресурсов для гостевых операционных систем. Виртуализация серверов позволяет решить проблемы, связанные с выделением и балансированием ресурсов и конфликтами приложений в ситуациях, когда один экземпляр приложения обслуживает несколько развертываний. Это достигается за счет использования нескольких экземпляров или разделов гостевых «виртуальных» операционных систем поверх единой физической системы сервера. Этот подход также обеспечивает такие важные возможности, как динамический контроль использования ресурсов и аварийное восстановление. Однако у этой технологии есть и некоторые недостатки. Во-первых, создание среды виртуальных серверов невозможно без высокопроизводительного оборудования и трудозатрат на администрирование и настройку. Во-вторых, хотя виртуализация серверов позволяет сэкономить средства за счет консолидации контейнеров физических серверов, рост количества виртуальных серверов приведет к увеличению нагрузки на ИТ-специалистов, связанной с администрированием. Втретьих, такой подход создает проблемы для пользователей, связанные с отсутствием поддержки в виртуальных серверах некоторых ресурсов, таких как высококачественная графика или USB-порты, что тоже может привести к снижению производительности. И наконец, основная операционная система по-прежнему представляет собой единую точку отказа, что может вызвать волновое или каскадное воздействие на гостевую операционную систему. Таблица 14. Технологии виртуализации и компьютерные ресурсы Вид технологии Компонент виртуализации Сеть Локализация распределенных ресурсов внутри и за пределами сети Виртуальная частная сеть (VPN) Виртуальная локальная сеть (VLAN) и виртуальная глобальная сеть (VWAN) Виртуальная инициализация и обеспечение безопасности Оборудование (процессоры и производительность) Обеспечение возможности оборудования переключаться между вычислительными задачами в режиме реального времени Intel VT и AMD-V Сетевые и кластерные вычисления Распределенные и одноранговые вычисления Хранилища Хранение и архивация данных по сети iSCSI Виртуальная сеть хранения данных (VSAN) Спецификация формата образа VHD (Microsoft Virtual Hard Disk) Компьютер и операционная система (серверы и клиенты) Несколько операционных систем на одном Основная и гостевые операционные системы 169 Вид технологии Компонент виртуализации компьютере Управление и администрирование (серверы Управление виртуальной машиной (сервер и клиент) и клиенты) Управление ресурсами и администрирование виртуальных машин Приложение Выполнение любого приложения на любом компьютере с использованием любой сети Виртуализация приложений Потоковая доставка приложений Сеанс Несколько синхронных или асинхронных сеансов на одном компьютере Потоковая доставка рабочего стола или сеанса Виртуализация приложений обозначила новый рубеж для ответственных лиц, принимающих решения в области ИТ. Реализация этого вида виртуализации с использованием технологий SoftGrid помогает устранить многие проблемы, которые не удается экономически эффективно решить путем виртуализации серверов. Не требуется высокопроизводительное оборудование — организации могут использовать имеющиеся настольные компьютеры, работающие под управлением Windows. Отсутствует децентрализация, вызываемая наличием нескольких гостевых операционных систем. Выполнение каждого приложения в собственной виртуальной среде исключает необходимость использования дополнительного раздела операционной системы. Не возникает дополнительной нагрузки на ИТ-специалистов, вызываемой наличием нескольких виртуальных машин. Администраторы занимаются поддержкой одной физической операционной системы, а не нескольких гостевых операционных систем. История развития технологии виртуализации Технология виртуализации не нова: в течение многих лет она применялась в мэйнфреймах. Например, компания IBM реализовала технологию гипервизора виртуальных машин в 1968 г., а в 1988-м компания представила технологию PR/SM (Processor Resource/System Manager), которая позволяет создавать несколько логических разделов, чтобы обеспечить возможность одновременного выполнения различных полнофункциональных операционных систем на одном физическом мэйнфрейме. С помощью виртуализации такого типа можно получить большую отдачу от мэйнфреймов с меньшим количеством ресурсов и меньшими затратами. 170 Теперь, применяя эти же принципы для виртуализации приложений на серверах, организации могут добиться аналогичного повышения динамичности, улучшения уровня обслуживании и сокращения расходов — и все это без разрастания контейнеров серверов, происходящего при виртуализации серверов. Вклад корпорации Майкрософт в дело виртуализации Корпорация Майкрософт не является неофитом в области виртуализации (см. таблицу 3). Уже давно она предлагает продукты, обеспечивающие возможности виртуализации для широкого круга компьютерных технологий, включая сети, оборудование, системы хранения, операционные системы и сеансы. Технология виртуализации приложений SoftGrid стала одним из последних вкладов корпорации в эту быстро развивающуюся область. Технология виртуализации входит в число основных элементов инициативы Microsoft Dynamic Systems Initiative, включающей набор продуктов и услуг для повышения гибкости организаций и более быстрого реагирования на меняющиеся потребности бизнеса. Технологии виртуализации привносят в эту инициативу такие критически важные возможности, как динамическое выделение ресурсов, масштабируемость, самовосстановление и отказоустойчивость. В состав операционных систем Майкрософт следующего поколения, таких как Windows Server «Longhorn» и Windows Vista, входят стандартные блоки, предназначенные для крупномасштабного развертывания и управления виртуализацией на настольных компьютерах и серверах. Кроме того, корпорация Майкрософт ведет разработку средств управления, которые ИТ-специалисты смогут использовать для управления виртуальными ресурсами в среде организации. Корпорация Майкрософт совместно с членами сообщества разработчиков ПО с открытым исходным кодом, в том числе с компаниями Novell и XenSource, занимается разработкой платформы, которая позволит обеспечить взаимодействие между гетерогенными системами. Таблица 15. Вклад корпорации Майкрософт в дело виртуализации Вид технологии Компонент виртуализации Продукт Майкрософт VPN Internet Security and Сеть Acceleration Server (ISA) Локализация распределенных VLAN и VWAN Whale Intelligent Application ресурсов внутри и за Виртуальная инициализация и защита Gateway пределами облака Защита доступа к сети (NAP) Оборудование (процессоры и производительность) Обеспечение возможности Intel VT и AMD-V Windows Vista™ и Windows Server «Longhorn» Сетевые и кластерные вычисления Windows Server 2003 171 Вид технологии Компонент виртуализации Продукт Майкрософт оборудования переключаться Распределенные между вычислительными и одноранговые задачами в режиме реального вычисления времени Datacenter Edition Microsoft Windows Compute Cluster Server Высокопроизводительные вычисления (HPC) Хранилища Хранение и архивация данных по сети iSCSI VSAN VHD Microsoft Windows Unified Data Storage Server Windows Server Longhorn Microsoft Windows Storage Server Microsoft System Center Data Protection Manager Основная и гостевые Microsoft Virtual Server и Компьютер и операционная операционные системы Microsoft Virtual PC система (серверы и клиенты) Технология гипервизора Несколько операционных Windows систем на одном компьютере Управление Управление и виртуальной машиной администрирование (серверы и (сервер и клиент) клиенты) Управление ресурсами и администрирование виртуальных машин Виртуализация приложений Приложение Выполнение любого приложения на любом компьютере в любой сети Сеанс Несколько синхронных или асинхронных сеансов на одном компьютере Microsoft System Center Virtual Machine Manager Решение Microsoft System Center для управления ИТуслугами (кодовое название «Service Desk») Средство виртуализации приложений Microsoft SoftGrid Потоковая доставка приложений Потоковая доставка Службы терминалов рабочего стола Подключение к удаленному или сеанса рабочему столу Преимущества виртуализации приложений Традиционно критически важными считались только серверные приложения. Сегодня, когда все больше сотрудников выполняет свои повседневные задачи с использованием таких настольных приложений, как клиентская программа для обмена сообщениями и организации совместной работы Microsoft Office Outlook®, текстовый редактор Microsoft Office Word и программа для работы с 172 электронными таблицами Microsoft Office Excel®, граница между серверными критически важными приложениями и настольными приложениями начинает стираться. В результате такие качества, как отказоустойчивость, самовосстановление, аварийное восстановление, производительность и мобильность, которых раньше ожидали от серверных приложений, теперь все чаще требуются и от настольных компьютеров. Несмотря на то, что многие организации занимаются внедрением у себя многоуровневых веб-систем, эра «толстых» клиентов и клиент-серверных приложений отнюдь не закончилась. Сегодня отделы ИТ заняты поиском новых подходов к решению застарелой проблемы повышения надежности и безопасности настольных приложений, чтобы обеспечить необходимую степень их устойчивости. Два из таких подходов — это потоковая доставка приложений или сеансов, реализуемая путем размещения приложений на сервере терминалов или сервере Citrix, и виртуализация приложений, осуществляемая с помощью программного обеспечения SoftGrid. Технология потоковой доставки приложений или сеансов действительно в значительной мере способствует решению задач централизованного управления и аварийного восстановления, однако мало что может сделать для устранения проблем совместимости приложений — как друг с другом, так и с операционной системой. Другой тип проблем с потоковой доставкой приложений или сеансов связан с тем, что это решение может стать единой точкой отказа или критическим местом, ограничивающим производительность. Чтобы избежать этих проблем, организации создают контейнеры серверов с целью предотвращения конфликтов между приложениями и между приложениями и операционной системой. А чтобы обеспечить возможность масштабирования и исключить появление единой точки отказа, устанавливаются дополнительные серверы. Однако такой подход увеличивает нагрузку на ИТ-специалистов и приводит к росту трудозатрат. Он также ведет к раздуванию ИТ-бюджета в связи с ростом капитальных затрат на закупку и развертывание нового оборудования. Средство виртуализации приложений SoftGrid сочетает в себе лучшее из обоих миров: хранение, управление и обслуживание приложений осуществляется централизованно, но при этом приложения передаются по сети и выполняются локально на клиентских компьютерах. Это позволяет не только сократить трудозатраты ИТ-специалистов, но и повысить гибкость компьютерной среды и тем самым предоставить организациям возможность быстрее реагировать на изменяющиеся потребности. Технология виртуализации приложений отличается от традиционного подхода к организации компьютерной среды, в котором настраиваются (как правило, вручную) статические системы, поддерживающие одно решение, а все компоненты устанавливаются и настраиваются на отдельных компьютерах. Например, в традиционной компьютерной среде каждая единица оборудования предназначена для решения определенных задач — например, служит веб-сервером или сервером базы данных; операционная система тесно связана с оборудованием 173 (один компьютер работает под управлением Windows, другой — под управлением UNIX); а хранение данных осуществляется в определенных местах. Поверх всех этих уровней устанавливаются приложения, которые будут выполняться в данной статической среде. Такую компьютерную структуру требуется подвергнуть тестированию, поскольку для обеспечения совместной работы необходимо жестко настроить все уровни этой среды. В результате получается жесткая конфигурация, трудно поддающаяся адаптации при изменении потребностей организации или установке и обновлении приложений. В отличие от этого в виртуальных системах приложения становятся службами, которые доступны по запросу и которыми пользоваться так же удобно, как, например, простейшими бытовыми приборами. Приложения больше не привязаны к определенным компьютерам или отделам, ими можно пользоваться на любом компьютере в любое время, когда это необходимо. Поскольку технология виртуализации приложений упрощает динамическое добавление, обновление и обслуживание приложений и компьютеров, появляется возможность создать значительно более подвижную и конкурентоспособную компьютерную среду, требующую минимальных затрат времени и ресурсов. В результате существенного упрощения ИТ-среды при использовании виртуализации приложений отделы ИТ могут значительно сократить свои трудозатраты. Виртуализация помогает снизить трудозатраты на поддержку приложений и настольных компьютеров, а также повысить уровни обслуживания и гибкость организации. 174 Средство виртуализации приложений SoftGrid Единое унифицированное решение для управления виртуализацией приложений SoftGrid позволяет в режиме реального времени развертывать приложения на те компьютеры, где это требуется. Решение SoftGrid преобразует приложения Windows из устанавливаемых локально продуктов в виртуальные службы, централизованно настраиваемые, управляемые и развертываемые по запросу на любые компьютеры под управлением Windows в компьютерной среде организации, включая настольные и переносные компьютеры и серверы служб терминалов/Citrix. Рис. 19 Обзор решения SoftGrid На Рис. 19 приводится обзор физических компонентов SoftGrid, используемых для обеспечения надежного развертывания приложений и управления ими. К основным компонентам относятся следующие: 1. Microsoft System Center Virtual Application Server. Этот сервер обеспечивает потоковую доставку приложений на компьютеры с установленным программным обеспечением SoftGrid (настольные ПК и серверы терминалов). Сервер выполняет авторизацию и проверку подлинности запросов на приложения и обладает возможностями обеспечения безопасности, контроля использования, мониторинга и сбора данных, необходимыми для реализации полного централизованного управления приложениями. 2. Клиент SoftGrid (Средство виртуализации приложений Microsoft SoftGrid для настольных ПК). Клиентское ПО SoftGrid устанавливается на компьютер пользователя только один раз. Этот клиент взаимодействует 175 с сервером System Center Virtual Application Server, получает приложения в потоковом режиме и обеспечивает возможность безопасного локального выполнения этих приложений на клиентском компьютере без необходимости их физической установки на компьютере пользователя. 3. Консоль управления SoftGrid. Консоль управления SoftGrid предназначена для централизованной настройки, администрирования и мониторинга серверов SoftGrid. Консоль управления можно использовать для назначения пользователям и подразделениям организации прав на работу с приложением и соответствующих лицензий. 4. Секвенсор SoftGrid. Секвенсор SoftGrid построен на основе мастеров и предназначен для автоматической обработки приложений, позволяющей приложениям работать с системой SoftGrid без внесения каких-либо изменений в исходный код приложения. 5. Соединитель SMS для SoftGrid. Соединитель Microsoft SMS для SoftGrid служит единым интерфейсом управления локальными и виртуальными приложениями. администратор может принудительно загружать виртуальные приложения на клиентские компьютеры с помощью средств развертывания SMS или предоставлять их по запросу с использованием технологии потоковой доставки SoftGrid. Интеграция технологии виртуализации приложений с сервером SMS позволяет организациям ускорить развертывание приложений и снизить его стоимость. Рис. 20 На Рис. 20 показаны некоторые виртуальные компоненты, входящие в состав пакета приложения и передаваемые на клиентские компьютеры, на которых выполняются виртуальные приложения. Виртуализация этих компонентов помогает решить основные проблемы жизненного цикла управления приложениями, такие как необходимость проводить регрессивное тестирование и использовать специальные технологии для исключения конфликтов между 176 приложениями (например, контейнеры серверов). Виртуализация этих компонентов также сокращает размер реестра. Тем самым уменьшается время загрузки системы. SoftGrid позволяет виртуализировать следующие компоненты: данные, например профили и документы пользователей; системные службы, включая службы Windows, объекты COM и OLE, шрифты и копирование-вставку; конфигурации (реестр, файлы INI и библиотеки DLL). В настоящее время в SoftGrid не поддерживается виртуализация компонентов уровня ядра и драйверов устройств. SoftGrid и Systems Management Server: вместе – лучше! Организации, которые уже приобрели сервер Microsoft Systems Management Server (SMS), могут использовать для целей интеграции соединитель SMS для SoftGrid. Соединитель Microsoft SMS для SoftGrid служит единым интерфейсом управления локальными и виртуальными приложениями. ИТ-администратор может принудительно загружать виртуальные приложения на клиентские компьютеры с помощью средств развертывания SMS или предоставлять их по запросу с использованием технологии потоковой доставки SoftGrid. Интеграция технологии виртуализации приложений с сервером SMS позволяет организациям ускорить и удешевить развертывание приложений. Поскольку виртуальные приложения выполняются так же, как и приложения, установленные локально, они обладают полным быстродействием и функциональностью и получают доступ к локальным службам, включая возможность копирования и вставки данных, функций OLE, печати, доступа к сетевым дискам и подключенным устройствам. Однако виртуальные приложения выполняются в изолированной «песочнице», что обеспечивает защиту основной операционной системы и других приложений от виртуальных приложений. Тем самым исключаются конфликты между приложениями и необходимость трудоемкого тестирования совместимости, операционная система и клиентский компьютер поддерживаются в неизменном виде, и появляется возможность мгновенно заменять «поврежденные» приложения даже без «посещения» клиентского компьютера. Кроме того, поскольку больше не требуется предустанавливать виртуальные приложения в образы, сокращается объем программ, устанавливаемых в систему, и общее количество образов, что позволяет экономить время администраторов настольных ПК. 177 Рис. 21 Интеграция SoftGrid и SMS Совместное использование SMS и SoftGrid позволяет организациям выбирать оптимальный способ развертывания приложений и одновременно обеспечивает возможность управления исправлениями и обновлениями уровня ОС, инвентаризации, отслеживания активов и выполнения многих других функций из единого интегрированного пункта управления. Соединитель SMS для SoftGrid поставляется вместе с решением SoftGrid в составе пакета Microsoft Desktop Optimization Pack for Software Assurance Таблица 16 178 Возможности SMS SoftGrid Развертывание ОС на новые ПК Обновления и пакеты обновления ОС Обновления и исправления безопасности ОС Развертывание базовых приложений (локальная установка) Установка обновлений базовых приложений (установленных локально) Предоставление приложений администратором Удаленное управление клиентскими компьютерами Разветвленная распределенная архитектура Упаковка (секвенсирование) виртуальных приложений Среда виртуализации приложений SystemGuard™ Потоковая доставка приложений по запросу Активное обновление пакетов Роуминг пользователей Аварийное восстановление виртуальных приложений Управление активами для оборудования и локально установленных и виртуальных приложений Принципы работы средства виртуализации приложений SoftGrid В решении SoftGrid применяется инновационная система централизованного развертывания приложений. Вместо того чтобы загружать и устанавливать все приложение, при первом запросе приложения пользователем клиент SoftGrid быстро загружает только минимальную часть пакета приложения с центрального сервера SoftGrid на настольный Windows-компьютер пользователя или сервер терминалов. При этом не происходит ограничения функциональности или быстродействия приложения: запуск приложения занимает несколько секунд. Точное время зависит от размера приложения и скорости соединения. При запуске виртуального приложения оно загружается в виртуальную среду (SystemGuard™), которая изолирует его от других приложений и операционной 179 системы компьютера. Изменения параметров приложения, выполняемые пользователем, сохраняются в профиле пользователя. При следующем запуске приложения оно будет выполняться с использованием этих параметров. По окончании сеанса SoftGrid пользовательские параметры кэшируются на локальном компьютере. Это позволяет мгновенно получать доступ к приложению при последующем использовании, причем практически без влияния на пропускную способность сети. Доступ возможен даже в тех случаях, когда компьютер пользователя не подключен к сети или она не работает. Пользователи могут в любое время работать с приложением, поскольку код, загруженный сервером SoftGrid на клиентские компьютеры, позволяет выполнять приложения локально без ограничения функциональности, независимо от состояния подключения к сети и серверу SoftGrid. На Рис. 21 показаны основные этапы развертывания виртуального приложения. 180 Этап 1. Администратор разрешает пользователям доступ к приложению. На рабочем столе клиента SoftGrid каждого пользователя автоматически появляется ярлык приложения. Этап 2. Когда пользователь щелкает ярлык, клиент SoftGrid направляет запрос серверу SoftGrid, который проверяет подлинность пользователя и его право запускать приложение на основании назначенной лицензии и прав доступа. Этап 3. В случае успешной проверки подлинности клиент SoftGrid загружает компоненты приложения на настольный Windows-компьютер или сервер терминалов. После кэширования необходимой части приложения оно будет запущено, и пользователь сможет приступить к работе с этим приложением. Приложение выполняется локально в среде SystemGuard, которая защищает основную операционную систему и другие приложения. Этап 4. По окончании сеанса пользователя среда SystemGuard кэширует код приложения, параметры настройки и профили на локальном компьютере. Сервер SoftGrid записывает в хранилище данных ODBC данные об использовании, в том числе сведения о приложении, пользователе, времени и длительности использования. Рис. 22. Как осуществляется доставка приложений по запросу в системе SoftGrid Преимущества SoftGrid для компьютерных сред предприятий Решение SoftGrid помогает упростить развертывание и обновление приложений на настольных и переносных компьютерах и серверах терминалов и исключить многие трудоемкие операции в управлении жизненным циклом приложения. Благодаря технологии виртуализации и потоковой доставки приложений решение SoftGrid позволяет выполнять приложения на настольных или переносных компьютерах или серверах приложения, даже не устанавливая их. Вместо этого решение SoftGrid по запросу пользователя мгновенно загружает приложения на компьютеры, не оказывая воздействия на основную операционную систему или другие приложения. Технология виртуализации SoftGrid является одной из самых мощных на сегодняшнем рынке и позволяет виртуализировать сеансы пользователя, профили пользователя и службы Windows, а также другие подсистемы, такие как реестр, файлы INI и библиотеки DLL. На Рис. 22 обобщены следующие преимущества SoftGrid: Исключение конфликтов между приложениями и регрессивного тестирования. Выполнение приложений в изолированной среде SystemGuard помогает избежать конфликтов виртуального приложения с основной операционной системой и другими приложениями. В результате сокращается объем трудоемкого регрессивного тестирования. Повышение загрузки серверов и улучшение управления ими. Изоляция приложений от других приложений сокращает потребность в контейнерах серверов, что приводит к повышению коэффициента загрузки серверов и рентабельности инвестиций и упрощению управления серверами. 181 Управление программными активами. Централизованное управление и предоставление приложений в системе SoftGrid позволяет организациям упростить добавление и удаление программных активов. Минимизация изменений профилей Windows. Решение SoftGrid записывает пользовательские параметры настройки и предпочтения в отдельный профиль SoftGrid, а не в профиль пользователя Windows. Сокращение изменений профиля Windows снижает вероятность повреждения профиля. Отслеживание использования приложений. При каждом запуске приложения пользователем клиент SoftGrid связывается с центральным сервером, что позволяет отслеживать использование приложений в режиме реального времени. Возможность легко получать сведения об использовании приложений помогает ИТ-отделам улучшить управление соблюдением условий лицензирования. Консолидация приложений. Консолидация всех версий и обновлений приложения в автономном пакете упрощает оптимизацию библиотек приложений на основе установщика MSI. Централизованное управление приложениями на основе политик. Решение SoftGrid позволяет управлять развертыванием, обновлением и удалением приложений для всех пользователей (включая мобильных и не подключенных к сети пользователей) с помощью политик, администрирование которых осуществляется с единой консоли. Кроме того, предусмотрены возможности удаленного управления клиентами SoftGrid, активного обновления виртуальных приложений, быстрого применения политик использования программного обеспечения в отношении пользователей и управления сеансами пользователей в режиме реального времени. Консолидация и стандартизация образов операционных систем. Отделение приложений от ОС позволяет свести к минимуму воздействие приложений на операционную систему. В результате упрощается структура образа ОС и уменьшается количество необходимых образов. Обеспечение непрерывности бизнеса в случае аварии. Система SoftGrid позволяет автоматически реплицировать приложения и обновления на серверы резервного копирования — аналогично тому, как это делается с данными. Благодаря этому в случае отказа сервера или ПК время простоя пользователей сокращается с часов или дней до нескольких минут. 182 Рис. 23. Преимущества SoftGrid для компьютерных сред предприятий Бизнес-ценность и окупаемость инвестиций Решение SoftGrid помогает отделам ИТ оптимизировать и упростить все этапы жизненного цикла управления приложениями, от упаковки до прекращения использования (см. Рис. 23). Тем самым сокращается время вывода услуг на рынок, повышается гибкость и динамичность организации, а ИТ-отделы приближаются к компьютерной модели коммунальных услуг — т. е. такой модели, в которой получить доступ к программным приложениям и работать с ними так же просто, как включить электрическую лампочку. Рис. 24. Оптимизация этапов жизненного цикла управления приложениями с помощью SoftGrid Масштаб возможной экономии времени и затрат за счет оптимизации и упрощения управления жизненным циклом приложений зависит от многих 183 факторов в конкретной организации. По этой причине корпорация Майкрософт совместно с компанией Forrester Consulting разработала в феврале 2006 г. калькулятор окупаемости виртуализации SoftGrid ROV (Return on Virtualization), основанный на модели ROI и использующий методологию Total Economic Impact™. С помощью ROV организации могут оценить текущую стоимость управления приложениями и сравнить ее с соответствующей стоимостью при внедрении технологии SoftGrid. Калькулятор содержит подробный вопросник, предназначенный для сбора данных о деятельности компании и ее технологической среде. Проверяется каждый этап жизненного цикла управления приложениями, чтобы определить подлинную его стоимость для организации. Учитывается не только время и соответствующие расходы ИТ-специалистов, но также и стоимость простоя пользователей. Затем калькулятор определяет, сколько времени и денег можно сэкономить с помощью средства виртуализации приложений SoftGrid. Ни один коэффициент в калькуляторе жестко не зафиксирован: все предположения и цифры можно изменить, чтобы учесть особенности деятельности компании. К преимуществам SoftGrid, поддающимся количественной оценке, относятся экономия ресурсов, достигаемая за счет развертывания приложений в виде виртуальных служб, и ускорение развертывания приложений с помощью SoftGrid. Анализ клиентских сред SoftGrid дал следующие средние результаты: сокращение количества обращений в службу поддержки по вопросам, связанным с приложениями, и затрачиваемого времени на 30%; сокращение общей стоимости жизненного цикла приложения более чем на 80%; увеличение степени консолидации серверов на 40% и более тесная консолидация контейнеров образов приложений и серверов терминалов; увеличение времени безотказной работы в 4 раза; период окупаемости от 4 до 10 месяцев. Кроме того, решение SoftGrid позволяет добиться экономии за счет следующих факторов: централизованный учет лицензий и контроль использования; повышение безопасности приложений за счет централизованного управления политиками; обеспечение непрерывности бизнеса и ускорение аварийного восстановления; поддержка серверов и ПК филиалов за счет централизованного управления приложениями и репликации приложений; возможность одновременного выполнения нескольких версий приложения на одном компьютере; упрощение предоставления мобильным и перемещаемым пользователям доступа к приложениям; 184 упрощение миграции операционной системы за счет консолидации образов операционной системы и устранения необходимости регрессивного тестирования; повышение эффективности и масштабируемости ферм серверов терминалов и серверов Citrix за счет консолидации серверов. Примеры экономии, достигаемой с помощью решения SoftGrid, см. в разделе «Реальные примеры экономии». На Рис. 24 проиллюстрированы основные действия, которые обычно выполняются в рамках жизненного цикла приложения и которые можно упростить или исключить при использовании решения SoftGrid. Это позволяет сократить время и затраты на управление приложениями в течение их жизненного цикла. Рис. 25 Трудоемкие этапы управления приложениями, которые можно исключить или сократить при использовании решения SoftGrid Заключение Компьютерная среда организаций постоянно меняется, а риски и требования продолжают экспоненциально возрастать. В ситуациях, когда ИТ-отделы вынуждены поддерживать баланс между стоимостью управления приложениями и постоянно возрастающими требованиями к уровням обслуживания и динамичности, средство виртуализации приложений SoftGrid является хорошим решением, которое облегчает бремя управления жизненным циклом приложений. За счет сокращения прямых расходов на развертывание приложений, регрессивное 185 тестирование, службу поддержки и другие типы поддержки и управление ИТсредой решение SoftGrid помогает отделам ИТ добиться кажущихся противоречивыми целей сокращения издержек и повышения уровня обслуживания. 186 LDAP: архитектура, реализации и тенденции Вассилики Коуцоникола, Афина Вакали Сервисы каталогов облегчают доступ к информации в разных средах и приложениях. Облегченная версия протокола доступа к каталогам LDAP (Lightweight Directory Access Protocol) с помощью структур данных, подобных структурам протокола X.500, обеспечивает доступ к хранимой в каталогах информации. Решения на базе LDAP поставляются компаниями IBM Tivoli, Novell, Sun Microsystems, Oracle, Microsoft и многими другими. Растущая популярность этой технологии объясняется как ее гибкостью, так и совместимостью с существующими приложениями. Сервис каталогов — это оснащенный средствами поиска репозитарий, в котором наделенные соответствующими полномочиями пользователи и службы могут находить информацию о людях, компьютерах, сетевых устройствах и приложениях. Потребность в получении информации, особенно по каналам Internet, постоянно растет, поэтому в последнее десятилетие сервисы каталогов получили широкое распространение и многие распределенные приложения имеют такие службы. Облегченный протокол доступа к каталогам [1] представляет собой открытый промышленный стандарт, получающий все более широкое распространение как метод доступа к каталогам. Как явствует из его названия, LDAP является облегченной версией протокола доступа к каталогам Directory Access Protocol и прямым потомком «тяжеловеса» X.500, наиболее известного протокола управления каталогами. В LDAP и в X.500 применяются сходные структуры представления данных, но эти протоколы имеют ряд фундаментальных различий [2]. 1. LDAP использует стек протоколов TCP/IP, тогда как X.500 — стек OSI. 2. Правила кодировки элементов протокола LDAP не столь сложны, как у протокола X.500. 3. Серверы LDAP реализуют ссылочный механизм (referral mechanism). Если такой сервер не в состоянии предоставить запрашиваемую клиентом информацию, он предоставляет ему URL альтернативного сервера LDAP, содержащего искомые данные. Сервер X.500 действует иначе: он разыскивает отсутствующие данные собственными средствами и предоставляет их клиенту без ссылки на сервер, на котором были взяты эти данные. Многие поставщики программных средств обеспечивают их совместимость с LDAP, поскольку этот протокол отличается гибкостью и интегрируется со все большим числом программ извлечения данных и управления ими. 187 Технология LDAP На рынке имеется множество серверов на базе LDAP — от общедоступных серверов гигантского масштаба, таких как BigFoot (search.bigfoot.com/index.jsp) и Infospace (www.infospace.com), до небольших LDAP-серверов, предназначенных для рабочих групп. Промежуточное положение занимают серверы каталогов, установленные и особым образом сконфигурированные во многих университетах и на предприятиях. Их назначение — предоставлять информацию о профессорскопреподавательском составе, служащих и студентах в формате, совместимом с почтовым сервисом данной организации, с системой аутентификации и методами управления доступом к приложениям и ресурсам. Список общедоступных интерфейсов каталогов имеется в общеевропейской исследовательской сети DANTE (Delivery of Advanced Network Technology to Europe, archive.dante.net/nameflow/national.html). В таблице 1 представлены наиболее известные из Web-сервисов, использующих LDAP, и перечислены функциональные возможности, полученные при интеграции LDAP с существующими приложениями обработки данных (электронная почта, передача файлов, видеоконференции и т.д.). В почтовой службе, к примеру, типичная LDAPзапись может содержать такие атрибуты, как mailLocalAddress, mailHost, UserCertificate (содержит сертификат пользователя в двоичном формате), ipLoginPort и ipLoginHost (для тех случаев, когда пользователь устанавливает соединение по коммутируемым линиям). Архитектура LDAP Функционирование LDAP основывается на модели клиент-сервер. С помощью протокола LDAP, который выполняется поверх стека TCP/IP, клиенты LDAP извлекают данные из базы данных сервера каталога. Клиенты LDAP либо напрямую контролируются сервером с установленными на нем средствами LDAP, либо управляются LDAP-совместимыми приложениями. На рис. 1 представлены основные элементы архитектуры LDAP. 188 Рис. 26 Инфраструктура LDAP. Устройства и серверы с помощью протокола LDAP обращаются к данным, хранимым в базе данных LDAP-серверов Важнейшую роль в архитектуре LDAP играют два компонента. Это LDAPсовместимая база данных, или каталог, и формат представления данных, основывающийся на языке XML. Каталог LDAP LDAP-каталоги — это базы данных, структурированные по принципу иерархических информационных деревьев, которые описывают представляемые ими организации. На Рис. 27. Пример иерархической структуры стандарта LDAP. Каждая запись LDAP идентифицируется отличительным именем, которое свидетельствует о позиции данной записи в иерархииприведен пример иерархической структуры, состоящей из трех уровней. Каждая запись LDAP идентифицируется с помощью отличительного имени (distinguished name, DN), которое декларирует свою позицию в иерархии. Структура данной иерархии представляет собой информационное дерево каталога (directory information tree, DIT), которое «вырастает» из корня (RootDN). Рис. 27. Пример иерархической структуры стандарта LDAP. Каждая запись 189 LDAP идентифицируется отличительным именем, которое свидетельствует о позиции данной записи в иерархии В базовой системе обозначений LDAP символы dc обозначают компонент домена (domain component), символы ou — организационную единицу (organizational unit), а символы uid — идентификатор пользователя (user id). Так, корень RootDN, описывающего некую базирующуюся в Греции организацию информационного дерева каталога с данными о пользователях, выглядел бы как dc=organization-name, dc=gr, а отличительное имя DN записи уполномоченного пользователя формулировалось бы так: uid=avakali, ou=people, dc=organizationname, dc=gr. Представление данных и их структура. В реляционных СУБД структуру данных определяют пользователи; в каталогах LDAP фиксированная базовая схема управляет иерархией каталога. Кроме того, если объекты LDAP вложены в иерархические структуры, то объекты реляционных баз данных связаны друг с другом посредством первичного и внешнего ключей, соединяющих элементы данных. Наконец, типы данных LDAP отличаются гибкостью и расширяемостью. Организация запросов и транзакций. В реляционных СУБД процессор запросов чувствителен к отношениям между объектами базы данных, тогда как в каталогах LDAP соответствующие отношения отбрасываются в процессе обработки запроса. Кроме того, запросы LDAP могут различаться по тому уровню на дереве, с которого начинается поиск (запрос-ответ). К примеру, мы можем иметь запросы двух типов: Запрос 1: ldapsearch -h localhost –b «dc=organization-name, dc=gr» «uid=avakali» Запрос 2: ldapsearch -h localhost –b «ou=people, dc=organization-name, dc=gr» «businesscategory=Assistant Professor» Параметр -h определяет выполняющую поиск главную машину, а параметр b указывает на уровень иерархии, на котором будет начинаться поиск. Таким образом, первый запрос указывает на запись пользователя с идентификатором uid=avakali (поиск начнется с узла, имеющего отличительное имя «dc=organizationname, dc=gr»), а второй — на все записи с атрибутом «businesscategory=AssistantProfessor» (поиск начнется с узла с именем «ou=people, dc=organization-name, dc=gr»). Операционные выгоды и затраты. В реляционных базах данных важнейшее значение имеет быстродействие при записи транзакций и считывании, тогда как каталоги LDAP используются в основном для считывания данных. Кроме того: серверы LDAP, как правило, просты в установке и в обслуживании; 190 каталоги LDAP могут быть весьма распределенными, а реляционные базы данных, как правило, отличаются высокой степенью централизации; серверы LDAP могут тиражировать некоторые или все хранимые на них данные с помощью встроенных и легко конфигурируемых средств репликации. Многие поставщики СУРБД считают такие средства «дополнительными» и соответственно берут за них дополнительную плату. Наконец, если реляционные базы данных исправно отображают сложные взаимоотношения объектов, то в каталогах LDAP трудно отобразить какие-либо отношения между объектами, помимо иерархических. XML и настройка каталогов LDAP XML — общепринятый стандарт представления данных в среде Web. Поскольку службы каталогов получили широкое распространение и интегрированы с множеством Web-приложений, в них часто используются мощные гибкие средства языка XML. Современные серверы LDAP не совместимы с XML, но эти технологии весьма близки по структуре. Язык разметки для служб каталогов Directory Services Markup Language (DSML, xml.coverpages.org/dsml.html) — новая технология представления содержащейся в каталоге информации на языке XML. Она призвана сыграть роль своеобразного моста, соединяющего сервисы каталогов и XML-совместимые приложения. DSML описывает содержимое служб каталогов различных производителей с помощью синтаксиса XML и тем самым обеспечивает возможность взаимодействия между ними. Направив запрос на сервер Web-приложений, на котором выполняется сервис DSML, XML-совместимое приложение может считывать информацию из каталога. DSML определяется с помощью описания содержимого документа (document content description, DCD), где указываются правила и факторы, ограничивающие структуру, а также контент документов XML (www.w3.org/TR/NOTE-dcd). На Рис. 28 Транзакция, модифицированная в соответствии со спецификацией Directory Services Markup Language. Служба DSML преобразует записи LDAP в формат DSML для XML-совместимых приложенийпредставлена типичная транзакция, в ходе которой сервис DSML преобразует записи LDAP в DSML. 191 Рис. 28 Транзакция, модифицированная в соответствии со спецификацией Directory Services Markup Language. Служба DSML преобразует записи LDAP в формат DSML для XML-совместимых приложений При обращении к содержимому каталогов средствами языка XML возникают новые требования к методам хранения и извлечения данных. Разработан ряд предложений по реализации эффективных методов хранения и извлечения данных на базе технологии LDAP. Некоторые методы управления [3, 4] предполагают установление соответствий между узлами объектной модели документов XML и записями LDAP. Такие процессы базируются на объектных процессорах, которые устанавливают соответствия между объектами XML и объектами LDAP. С этой целью они определяют новые классы объектов LDAP (для которых будут устанавливаться соответствующие узлы, элементы и атрибуты XML). Другой подход предполагает установление соответствий между узлами XML DOM и записями LDAP с помощью определений классов объектов LDAP для узлов XML [5]. Благодаря сходству структур некоторые модули могут транслировать запросы XPath в запросы LDAP. Точнее говоря, исследователи предложили модель запроса, базирующуюся на алгоритме оценки. Последний преобразует любой запрос XPath в серию запросов LDAP, которые решают задачу, сформулированную в исходном запросе [4]. Еще одна идея состоит в том, чтобы пользователи формулировали запросы Xpath, которые компонент XML2LDAP будет преобразовывать в формат LDAP, а затем компонент LDAP2XML будет преобразовывать полученный результат из формата LDAP в формат XML. Транслировать данные LDAP в формат XML может и синтаксический анализатор XML [7]. Практическое использование LDAP Разработчики уже давно указывают на необходимость создания стандарта каталога промышленного уровня, и эта потребность становится все более 192 настоятельной ввиду появления многочисленных (и постоянно развивающихся) приложений, функционирующих в среде Directory Enabled Network (DEN). К ним, в частности, относятся приложения, взаимодействующие с существующими сетевыми устройствами, файлы системной конфигурации, средства организации видеоконференций и т.д. Авторов спецификации DEN интересовала прежде всего возможность создания мощной расширяемой инфраструктуры, способной моделировать различные элементы сети и службы для обеспечения удобного хранения и извлечения информации из LDAP-каталогов и хранилищ данных. Реализации LDAP В таблице 2 отражены основные функциональные возможности основных серверов LDAP. Все шесть рассматриваемых серверов (кроме OpenLDAP) обеспечивают тиражирование с несколькими ведущими серверами. В ходе такой операции два первичных LDAP-сервера, предоставляющих для тиражирования изменения в своем содержимом, могут принимать обновления, синхронизировать их друг с другом и обновлять содержимое всех LDAP-серверов, на которые передаются тиражируемые данные. Последние, в свою очередь, могут направлять двум ведущим серверам запросы на обновление. Созданный корпорацией IBM интерфейс Standalone LDAP HTTP API (Slaphapi) позволяет выводить полученные данные в виде текста в формате HTML или DSML и обращаться к каталогам LDAP по протоколу HTTP. Кроме того, в IBM разработали инструментальное средство XML Data Mediator (прежнее название XML Integrator; см. www.alphaworks.ibm.com/tech/XI), предназначенное для двунаправленного преобразования данных (таких, как реляционные данные или данные LDAP) между XML и структурированными форматами. Разработанный в Sun Microsystems интерфейс Java naming and directory interface API совместим с языком DSML (developer. java.sun.com/developer/earlyAccess/jndi). Microsoft оснащает средствами DSML сервис Active Directory. Кроме того, она работает над механизмом отображения данных каталога в структуре DOM, к которой можно обращаться с помощью XPath. LDAP Processor (cocoon.apache.org/1.x/ldap.html) представляет собой процессор, выполняющий запросы LDAP, транслирующий полученные результаты в фрагмент XML-текста и вставляющий данный фрагмент в исходный документ. LDAPHTTP (www.onjava.com/pub/a/onjava/2003/07/ 16/ldaphttp.html) транслирует данные XML в формат LDAP. Шлюз XMLDAP (http://xml.coverpages.org/ni200103-02-a.html) — это созданное в соответствии со стандартами решение, позволяющее разработчикам представлять данные каталога LDAP в иных форматах. Благодаря столь мощной поддержке стандарта потенциальные клиенты LDAP имеют широкие возможности выбора. 193 Выбор сервера LDAP Требования по времени. В ходе типичных тестов сопоставляется время выполнения серверами LDAP операций считывания данных, а также их поиска, записи и загрузки. Для повышения надежности результатов база данных загружается более одного раза. Некоторые исследователи испытывали приложения с высокими требованиями к времени выполнения [8-10], другие анализировали время отклика на запрос в сочетании с совокупной полосой пропускания и задержкой [11, 12]. Связывание информации. При LDAP-взаимодействиях роль операций связывания исключительно велика. Направляя сведения для аутентификации клиента, эти операции инициируют установление соединений сервером LDAP. Метрики, относящиеся к операциям связывания (включая время отклика, число запросов на связывание и ошибок связывания), могут существенно задерживать выполнение LDAP-операции. Время отклика при связывании зависит от метода аутентификации [12]. Функциональность поиска. Этот критерий включает в себя запросы на поиск и ошибки, среднее число и размеры результатов поиска, время отклика при поиске и текущие операции поиска. Время отклика при поиске зависит от нескольких факторов, в том числе от фильтрации запросов, от места в иерархической структуре данных точки начала поиска, от числа внесенных в запрос атрибутов и того, включены ли в запрос индексированные атрибуты. Многие организации, работающие с LDAP-серверами, регулярно собирают статистические данные по операциям поиска, что позволяет им отслеживать эксплуатационные характеристики серверов. К таким организациям относятся, например, Университет Вермонта (mouse.uvm.edu/ldapstats/fishercat.uvm.eduSearch.html) и Университет Торонто (www.utoronto.ca/ns/stats/ldap.html). Управление кэш-памятью. Этот показатель важен потому, что для уменьшения времени отклика серверы каталогов используют кэши каталогов. Исследователи изучили идею использования LDAP-кэшей и предложили алгоритм снижения времени отклика [13]. Метрики управления кэш-памятью составляются путем сопоставления числа плодотворных обращений к кэш-памяти и общего числа запросов к кэшу каталога; в кэш-службах LDAP пользователи обычно определяют размер кэша. Интенсивность обменов данными. Эта характеристика определяется числом переданных байтов и отправленных записей в ходе обменов между сервером LDAP и его клиентами. Интенсивность обменов данными зависит от разных метрик, таких как запросы на соединения, текущие соединения, средняя длина соединения и средний размер результатов поиска. Для мониторинга интенсивности обменов, особенно когда речь идет об отображении состояния в масштабе почти реального времени, администраторы LDAP-серверов могут пользоваться различными инструментами [14], например средством Mirabai-LDAP Metrics (www.forsitesolutions.com/mirabai.html). 194 Эволюция LDAP: что дальше? В ходе эволюции LDAP станут решаться вопросы сближения со службами каталогов X.500, что будет способствовать созданию глобального каталога Internet. Метакаталоги, которые управляют интеграцией и потоками данных между серверами каталогов, — еще один шаг к объединению серверов X.500 и LDAP. Многие поставщики продуктов стандарта LDAP, в том числе Sun, Novell и Microsoft, реализуют в них средства для создания метакаталогов, и, похоже, в этом проявляется тенденция развития приложений на базе LDAP. Управление LDAP-данными, и в первую очередь, методы их хранения и извлечения, можно было бы значительно усовершенствовать за счет соответствующей интеграции стандартов XML и LDAP. Современные тенденции развития LDAP свидетельствуют о высокой вероятности того, что эта спецификация будет принята в качестве стандарта для развернутых в Internet инфраструктур управления данными, ориентированных на генерирование запросов, индексирование, кэширование и обеспечение безопасности. 195 Введение в AD Представьте, что вы работаете в крупной компании и хотите найти какойлибо файл. Если вы не знаете, где он находится, на каком из сетевых серверов, с помощью чего вы можете просмотреть структуру каталогов вашей сети? Каким образом вы можете «добраться» до каждого сервера, если вы даже не знаете всех их имен? Если вы управляете сетью компании и у вас есть серверы для пользователей, серверы для секретных данных, интранет-сеть с открытой и закрытой зонами, а также открытый для всеобщего доступа веб-сайт — каким образом вы можете одновременно следить за всем, что у Вас есть? Каким образом вы можете устанавливать ограничения на доступ к секретной информации? Как нужно реплицировать данные, чтобы они оставались при этом доступными? И, наконец, самое важное: как обеспечить работу службы каталогов в сетях и операционных системах различных типов, а также расширение этой службы по мере расширения компьютерной сети предприятия? Поставляемая в настоящее время сетевая ОС Microsoft® Windows NT® Server включает в себя службу каталогов Windows NT Directory Services, которая предоставляет пользователям то, в чем они больше всего нуждаются, — единую точку регистрации и единую точку администрирования и репликации данных. Эти функции нужны компаниям прежде всего, однако уже ясно, что организациям, использующим в своей работе Windows NT Server, нужны новые возможности по работе с каталогами. В числе таких возможностей — иерархическое представление каталога, расширяемость, масштабируемость, защита в распределенных сетях и многоуровневая репликация (multimaster replication). Для решения этих задач компания Microsoft разрабатывает службу каталогов Active Directory. Планируется, что все эти возможности появятся в следующей версии ОС — Windows® 2000 Server. Службы каталогов следующего поколения Потребность в еще более мощной, наглядной интегрированной системе каталогов обусловлена резким ростом количества и размеров компьютерных сетей. По мере того как локальные и глобальные сети становятся все более объемными и сложными, компьютерные сети подключаются к Интернету, приложения подключаются к другим системам через корпоративные интранет-сети и требуют все больше сетевых ресурсов, все большие требования предъявляются и к службам каталогов. Мерой открытости службы каталогов является количество поддерживаемых ей протоколов и форматов объектов — от этого зависит, насколько данный каталог доступен для остального клиентского ПО (помимо того, что разработано специально для работы с ним). Поддерживаемые программные интерфейсы (API) определяют набор утилит и приложений, которые будут непосредственно пользоваться возможностями службы каталогов. Служба каталогов должна стать объединяющим, упорядочивающим и организующим 196 звеном, особенно при обработке данных, поступающих из другой сетевой операционной системы и каталогов приложений. Active Directory поддерживает множество популярных протоколов и форматов и имеет мощные, гибкие и простые в применении API. С ее помощью администраторы и пользователи получают единый источник информации о правах доступа и ресурсах. Отличия от традиционных служб каталогов Как правило, служба каталогов — это набор инструментов для поиска «интересных» объектов в компьютерной системе, для их организации и управления ими. «Интересными» являются объекты, необходимые пользователям (и приложениям) для выполнения своих задач: принтеры, документы, адреса электронной почты, базы данных, имена пользователей, распределенные компоненты и другие ресурсы. Для простоты и наглядности службу каталогов можно сравнить с телефонным справочником. Вводя конкретные данные (например, имя человека), пользователь может получить определенную информацию (например, адрес этого человека и его номер телефона). Служба каталогов также предоставляет возможности справочников типа «желтых страниц». Вводя общий запрос (например, «где находятся принтеры?»), пользователь получает список доступных принтеров, который затем можно просматривать. Однако по мере расширения и усложнения сетей к службам каталогов предъявляются все более высокие требования (даже если эти сети не подключены к Интернету). Active Directory создавалась с целью унифицировать и упорядочить информацию с разнородных платформ и пространств имен. Возможности Active Directory Помимо обычных для служб каталогов задач, Active Directory способна удовлетворить широкий спектр потребностей по обработке имен, обслуживанию запросов, регистрации, администрированию и устранению конфликтов. На рисунке представлены основные функции, которые она может выполнять. 197 DNS microsoft.com referral Exchange Mail submit mail recipient lookup Mail Client address book http/shttp server admin/ brow se SQL Server Security Directory Service replication register service Dynamic Services credential management query Рис. 29. Active Directory делает возможной локализацию любой информации и сетевых ресурсов Архитектура Active Directory позволяет применять эту службу каталогов как на малых предприятиях, так и в гигантских международных корпорациях и правительственных учреждениях. В Active Directory используется тесно увязанный набор API и протоколов, так что она может работать с несколькими пространствами имен, собирать и предоставлять информацию о каталогах и ресурсах, находящихся в удаленных филиалах и под управлением разных ОС. Сейчас компания Microsoft поставляет полный набор средств межсистемного взаимодействия для пользователей Novell NetWare 3.x/4.x. По мере развития протоколов Microsoft будет предпринимать усилия для стандартизации обмена и с другими операционными средами. Чтобы максимально облегчить переход на Active Directory, Microsoft гарантирует взаимодействие более ранних и версий ОС Windows NT Server с более поздними. Возможности и характеристики Active Directory имеет следующие возможности и характеристики: Поддержка открытых стандартов для облегчения межплатформных операций с каталогами, в т. ч. доменной системы имен DNS и стандартных протоколов, таких как LDAP. Поддержка стандартных форматов имен для простоты миграции и эксплуатации. Богатый набор API, которые могут использоваться как для командных сценариев, так и в программах на C/C++. Простой и интуитивно понятный процесс администрирования благодаря несложной иерархической доменной структуре и использованию технологии «перетащить и оставить». Возможность расширения набора объектов в каталогах, за счет гибкой логической схемы. Быстрый поиск по глобальному каталогу. 198 Быстрое и удобное обновление информации посредством многоуровневой (multimaster) репликации данных. Совместимость с предыдущими версиями ОС Windows NT. Взаимодействие с сетями NetWare. Далее в этом документе рассказано о целях, которые ставили перед собой разработчики Active Directory для Windows 2000 Server, и о внедрении этой службы каталогов. Также объясняется, каким образом организации могут подготовиться и осуществить плавный переход к службам каталогов следующего поколения. 199 Общие сведения об Active Directory Служба каталогов Active Directory полностью интегрирована в Windows 2000 Server и обладает функциями иерархического просмотра, расширяемости, масштабируемости и распределенной системой защиты, что необходимо любому предприятию. Администраторы сетей, разработчики программ и пользователи впервые получают в свое распоряжение службу каталогов, которая: идеально совместима с сетями Интернет и интранет; обеспечивает возможность простого и интуитивно понятного именования имеющихся в ней объектов; применима как на малых предприятиях, так и в компаниях-гигантах; имеет простые, эффективные и открытые программные интерфейсы. Active Directory — это один из важнейших компонентов всей сети. Для администраторов и пользователей она является как источником информации, так и мощным средством управления. Единый каталог В Active Directory сведены воедино концепция пространства имен, применяемая в Интернете, и возможности по работе с каталогами, предоставляемые самой операционной системой. Это позволяет организациям объединить многочисленные пространства имен, которые существуют в настоящее время в гетерогенных программных и аппаратных средах, и управлять этими именами. В основе работы службы лежит упрощенный протокол доступа к каталогам (lightweight directory access protocol, LDAP). Как следствие, она может функционировать независимо от типа операционной системы, объединяя различные пространства имен. На основе каталогов, относящихся к тем или иным приложениям, а также каталогов сетевых ОС можно создать каталог общего назначения, и, следовательно, снизить нагрузку на администратора и уменьшить расходы, связанные с поддержанием нескольких пространств имен. В Active Directory не используется протокол Х.500, а в качестве протокола доступа применяется LDAP. И хотя информационная модель X.500 поддерживается, от систем не требуется полной совместимости со всеми излишествами Х.500. В результате достигается высокая эффективность взаимодействия, необходимая для управления реальными гетерогенными сетями. Единое администрирование Active Directory позволяет управлять с одного рабочего места всеми заявленными ресурсами (файлами, периферийными устройствами, базами данных, подключениями к серверам, доступом к Web, пользователями, другими объектами, сервисами и т. д.). В качестве идентификационной службы в ней используется доменная система имен (DNS), применяемая в Интернете, объекты в доменах строятся в иерархию организационных единиц (ОЕ), а домены могут быть 200 объединены в древовидную структуру. Администрирование становится еще проще, так как в Active Directory отсутствует понятие главного контроллера доменов (ГКД) и резервного контроллера доменов (РКД). В Active Directory существуют только контроллеры домена (КД), и все они равны между собой. Администратор может сделать изменения на любом КД, и эти изменения будут скопированы на всех остальных КД. Масштабируемость В качестве основы для Active Directory выступают структура каталогов и система хранения данных (storage engine) ПО Microsoft Exchange 4.0. Система хранения содержит эффективный механизм сохранения незаполненных объектов, а также различные индексы для их быстрого извлечения. Под незаполненными имеются в виду объекты, имеющие множество параметров, значение которых не определено. Опираясь на эту базу, компания Microsoft разработала службу каталогов общего назначения, способную работать как в небольших сетях с числом объектов от нескольких сот до тысяч, так и в гигантских системах, насчитывающих миллионы объектов. Active Directory может работать с несколькими архивами объектов одновременно, в каждом из которых может храниться более миллиона объектов. Это резко повышает масштабируемость службы и при этом сохраняются простая иерархическая структура и легкость в управлении. Сочетание Active Directory и файловой системы Microsoft Distributed File System (будет выпущена в составе ОС Windows 2000 Server) сделает еще более достижимым существование единого глобального пространства имен. Интеграция с операционной системой Active Directory полностью интегрирована в Windows 2000 Server — единственную операционную систему, которая в базовой поставке может служить сервером файлов, печати, приложений, коммуникаций, а также работать с сетями Интернет/интранет. Windows 2000 Server — это самый лучший сервер по работе с файлами и печатью, способный удовлетворить все потребности организаций в управлении информацией и ресурсами, и работающий быстрее других ОС. Это также самый лучший сервер приложений, имеющий лучшее в компьютерной отрасли соотношение масштабируемость/цена. Кроме того, Windows 2000 Server — это прекрасная коммуникационная платформа, предоставляющая такие услуги, как служба удаленного доступа Remote Access Services, TAPI и PPTP. 201 Поддержка открытых стандартов и стандартных форматов имен Главной целью Active Directory является создание единой сети со значительно меньшим количеством каталогов и пространств имен, в которых приходится ориентироваться администраторам и пользователям. Active Directory разработана специально для управления другими каталогами независимо от их месторасположения и операционной системы. С этой целью в Active Directory реализована широкая поддержка существующих стандартов и протоколов, включая стандартные форматы имен, и предлагаются программные интерфейсы (API), облегчающие взаимодействие с другими каталогами. В качестве идентификационной службы в Active Directory используется доменная система имен (DNS), а для связи с другими приложениями или каталогами — протокол Lightweight Directory Access Protocol (LDAP). Поддержка DNS Active Directory сочетает в себе преимущества службы имен DNS и преимущества X.500, при этом она лишена недостатков обеих систем и поддерживает стандарты Интернета. DNS — это наиболее широко применяемая служба каталогов в мире. Она используется в качестве идентификационной службы (locator service) в сети Интернет и в большинстве локальных интранет-сетей. Ее задача — перевод имени, например, MyMachine.Myco.com, в адрес TCP/IP. DNS может масштабироваться для работы в очень больших системах (ведь она используется в сети Интернет), при этом она достаточно мала, чтобы работать в сети, состоящей всего из нескольких компьютеров. Создание имен, совместимых с Интернетом Active Directory включает в себя DNS в качестве службы имен. В Active Directory имена доменов Windows NT являются именами DNS. Пользователи увидят, что в Active Directory используется та же самая несложная система именования, что и в Интернете. Адрес Myco.com может быть как доменом DNS (то есть областью адресов), так и доменом Windows NT. Адрес JamesSmith@Myco.com может быть как адресом электронной почты в Интернете, так и именем пользователя в домене Myco.com. В сетях Интернет и интранет домены Windows 2000 можно находить таким же образом, как и любой ресурс в сети Интернет — при помощи DNS. Это показано на Рис. 30 202 Division.Myco.com/Group/Sys/JamesSmith DNS Myco.com Division.Myco.com Group Sys JamesSmith Рис. 30. DNS применяется в Windows NT в качестве службы имен. Создание более легкой в управлении среды DNS Система DNS всегда была непростой в управлении, поскольку требовалось вручную работать с текстовыми файлами, содержащими информацию о соответствиях между именами и адресами для каждого компьютера в организации. В Windows NT Server версии 4.0 компания Microsoft разработала сервер DNS Server со встроенной службой Windows® Internet Naming Service. DNS Server в Windows NT имеет специальную графическую утилиту, упрощающую редактирование файлов DNS. Чтобы устранить ручное присваивание адресов, DNS Server в Windows NT объединен с Windows Internet Naming Service — специальной службой Windows NT, которая динамически обновляет файл соответствий между именами и адресами. В сетях, построенных на основе сервера Windows NT Server, компьютерамклиентам при включении адреса TCP/IP присваиваются автоматически, при этом используется протокол Dynamic Host Configuration Protocol (DHCP). Затем клиенты регистрируют свои имена и адреса в службе Windows Internet Naming Service (см. Рис. 31). Для управления нераспознанными именами DNS Server в Windows NT использует службу Windows Internet Naming Service. DNS Client Lookup Bungalow .Ms.Com Bungalow ? 157.55.94.89. 157.55.94.89. DNS WINS Server Рис. 31 Службы DNS и WINS объединены для динамического обновления DNS. 203 Техническое решение, найденное компанией Microsoft для динамического обновления таблиц DNS — интеграция служб DNS и Windows Internet Naming Service, — не рассчитано на перспективу. Интернет-стандарты в части DNS были обновлены для поддержки динамической Dynamic DNS. С появлением Dynamic DNS необходимость в WINS исчезает, так как клиенты с динамически назначаемыми адресами могут регистрироваться непосредственно на DNS-сервере с одновременным обновлением таблицы DNS. Серверы, работающие с Active Directory, будут использовать для регистрации Dynamic DNS. Применяя сегодня Windows NT 4.0, DNS и WINS, системные администраторы закладывают базу для Active Directory и Dynamic DNS. LDAP v2 and v3 HTTP Domain Domain Domain Windows NT Active Directory Service Рис. 32. Active Directory поддерживает протоколы LDAP версий 2 и 3 Поддержка LDAP Среди других реализованных в Active Directory Интернет-стандартов — прямая поддержка протокола Lightweight Directory Access Protocol (LDAP). LDAP (стандарт RFC2251) был разработан для доступа к службам каталогов как более простая альтернатива протоколу X.500. Компания Microsoft активно участвует в совершенствовании стандартов LDAP, и в программе Active Directory предусмотрена поддержка стандартов LDAP версии 2 и 3. Поддержка стандартных форматов имен Формат имен, применяемый в службах каталогов, важен как для пользователей, так и для приложений. Если пользователю или приложению требуется найти некоторый объект, пользователь или это приложение должны 204 знать имя или какое-либо свойство этого объекта. Существует несколько общеупотребительных форматов имен, используемых в каталогах. Эти форматы определяются как официальными стандартами, так и стандартами де-факто, и Active Directory поддерживает большинство из них. Поэтому пользователи и приложения, работающие с Active Directory, могут пользоваться тем форматом, который им лучше всего знаком. Ниже рассматриваются некоторые форматы имен. Имена RFC822 Имена RFC822 записываются в виде какое-то_имя@какой-то_домен и знакомы многим как интернетовские адреса электронной почты; например, JamesSmith@myco.com. Active Directory предоставляет для всех пользователей удобное имя в формате RFC822. Это имя может применяться как в качестве адреса электронной почты, который можно написать на визитной карточке, так и для входа в систему. Имена LDAP URL и X.500 Active Directory поддерживает доступ по протоколу LDAP для любого клиента с поддержкой LDAP. Имена LDAP не так наглядны, как имена в Интернете, однако сложность именования LDAP обычно скрыта внутри приложения. В этом протоколе используется принцип именования X.500 под названием атрибутивное именование (attributed naming). Указатель LDAP содержит имя сервера, на котором работает служба каталогов Active Directory, а также атрибутивное имя объекта. Например: LDAP://SomeServer.Myco.com/CN=jamessmith,OU=Sys,OU=Product, OU=Division,DC=myco,DC=Com 205 Программные интерфейсы Active Directory имеет мощные, гибкие и простые программные интерфейсы (API). Богатый спектр API для служб каталогов дает возможность разрабатывать разнообразные приложения и утилиты. В Active Directory входят три основных набора API: 1. ADSI (Active Directory Service Interfaces), интерфейсы службы Active Directory — набор интерфейсов модели COM для управления многочисленными службами каталогов и составления запросов к ним. 2. MAPI (Messaging API), интерфейс обмена сообщениями в стандарте Windows® Open Services Architecture. 3. LDAP C API (RFC1823), информационный RFC, являющийся фактическим стандартом в программировании на C для приложений LDAP. Ниже приводится описание каждого из этих API. Active Directory Service Interfaces (ADSI) Чтобы упростить создание приложений, работающих с Active Directory и другими каталогами, поддерживающими LDAP, компания Microsoft разработала интерфейсы службы Active Directory (ADSI). ADSI — это набор несложных расширяемых программных интерфейсов, которые можно использовать при написании приложений для доступа и управления следующими ресурсами: Active Directory; любыми каталогами, поддерживающими LDAP; другими службами каталогов, включая NDS. ADSI входит в состав набора интерфейсов Open Directory Services Interface (ODSI), являющегося частью Windows® Open Services Architecture (WOSA) и предназначенного для работы с различными службами каталогов и составления запросов к ним. В настоящее время имеются объекты ADSI для Windows NT 4.x, Novell NetWare 3.x и 4.x, Active Directory и любой другой службы каталогов, которая поддерживает протокол LDAP. Active Directory Service Interfaces изолируют от пользователя особенности служб каталогов различных сетевых систем и предоставляют единый набор интерфейсов для управления сетевыми ресурсами. Это сильно упрощает разработку распределенных приложений и администрирование распределенных систем. Разработчики и администраторы пользуются этими интерфейсами для регистрации ресурсов и управления ими в службе каталогов (причем не важно, в какой сетевой среде находится тот или иной ресурс). Таким образом, ADSI облегчает обычные административные задачи: добавление новых пользователей, управление принтерами и поиск ресурсов в распределенной компьютерной среде; кроме того, ADSI упрощает разработку взаимодействующих с каталогами приложений. Интерфейсы ADSI предназначены для удовлетворения потребностей программистов на C и C++, системных администраторов и опытных 206 пользователей. Разработка взаимодействующих с каталогами приложений при помощи ADSI становится проще и быстрее. В ADSI каталог представлен как набор COM-объектов, которые не только хранят информацию о ресурсах, но и могут обладать собственным поведением. Так, например, приложение может использовать объект ADSI PrintQueue как для того, чтобы получить информацию (например, характеристики очереди), так и для того, чтобы приостановить очередь на печать. На языке Visual Basic® это выглядит довольно просто: Dim MyQueue as IOleDsPrintQueue Set MyQueue = GetObject(“DS://Myco.com/Division/Product/Printers/MyPrinter”) MyQueue.Pause Поскольку ADSI-объекты существуют для многих популярных служб каталогов, интерфейсы ADSI являются идеальным средством для создания приложений, работающих с несколькими каталогами. Кроме того, программист может расширить возможности запроса, встроив поддержку интерфейсов OLE DB. Таким образом, утилиты, использующие интерфейсы OLE DB, могут пользоваться возможностями Active Directory. ADSI-объекты разработаны для решения задач трех основных категорий специалистов: 1. Разработчики. Как правило, разработчики будут использовать ADSI с такими языками программирования, как C++, хотя для созданий прототипов может использоваться и Microsoft Visual Basic. Разработчик может, например, написать приложение, которое будет управлять различными каталогами, сетевой печатью, создавать резервные копии баз данных и т. д. 2. Системные администраторы. Системные администраторы скорее всего будут работать с ADSI с помощью языков сценариев или Microsoft Visual Basic, хотя при необходимости может быть использован и C/C++. Так, например, администратор, работающий с Active Directory, может написать сценарий для добавления в систему 100 новых пользователей и назначения им тех или иных прав доступа. 3. Пользователи. Как и системные администраторы, пользователи работают с ADSI при помощи языков сценариев. К примеру, пользователь может написать сценарий для поиска всех заданий на печать в очереди и отображения состояния этих заданий. Windows Messaging API (MAPI) Active Directory обеспечивает поддержку MAPI, так что соответствующие приложения могут работать с Active Directory. Однако для создания новых приложений, работающих с службами каталогов лучше использовать ADSI. 207 LDAP C API Интерфейс LDAP API представляет собой простое универсальное решение для создания приложений, работающих с различными клиентами. Существующие LDAP-приложения будут работать со службами Active Directory практически без изменений (если не требуется поддержка специфических для Active Directory типов объектов). Мы предлагаем разработчикам LDAP-приложений переходить на ADSI, который поддерживает любые службы каталогов, работающие с LDAP. 208 Широкие возможности масштабирования Компания Microsoft прекрасно понимает, что существуют предприятия разных размеров и что нет смысла создавать программный продукт, который имеет слишком много возможностей для малого предприятия и слишком мало для крупной компании. Вот почему Active Directory прекрасно работает и на одном компьютере, и в большой сети крупного предприятия. Windows NT 4.0 хорошо масштабируется до как минимум 100 000 пользователей, Active Directory может работать более чем с миллионом пользователей только в одном домене и с намного большим числом пользователей в дереве доменов. Возможности, заложенные в Active Directory, позволяют создавать маленькие домены, которые легко администрировать и наращивать при расширении сетей и организаций. Администрирование крупных компаний не отличается от администрирования малых предприятий, просто в них требуется больше системных администраторов. Масштабирование Active Directory происходит за счет создания дополнительных копий каталогов, возникающих при образовании домена. В такой копии находятся только те объекты, которые относятся к этому домену. Если несколько доменов связаны между собой, их можно выстроить в виде дерева. В пределах дерева каждому домену соответствует своя копия информационного каталога со своими собственными объектами, домен также может найти все остальные копии каталога в пределах одного дерева. Вместо того чтобы создавать один экземпляр каталога, который становится все больше и больше, в Active Directory создается дерево, составленное из небольших частей каталога. В каждой части содержится информацию, которая позволяет находить все остальные разделы. Active Directory разбивает каталог на разделы таким образом, чтобы та часть каталога, которой кто-то пользуется наиболее часто, была к нему как можно ближе. Если другие пользователи решат, что им нужен тот же раздел каталога — рядом с ними так же будет иметься копия этого раздела. Все копии какого-либо раздела каталога синхронизированы. Если в какой-либо из копий изменяется запись, это изменение распространяется и на другие копии, в результате Active Directory может работать с миллионами пользователей в пределах одного дерева. Использование доменных деревьев и лесов Основой масштабируемости Active Directory является принцип доменного дерева. В тех службах каталогов, которые состоят из одного дерева, процесс выделения разделов (partitioning process) довольно сложен и происходит в направлении сверху вниз. Построение большого дерева в Active Directory происходит в направлении снизу вверх и интуитивно понятно, а отдельный домен представляет собой законченный раздел каталога. В целях администрирования домены подразделяются на организационные единицы (ОЕ), как показано на Рис. 33. 209 Рис. 33. В Active Directory домены и организационные единицы (ОЕ) собраны в древовидные структуры, которые строятся в направлении снизу вверх. Отдельный домен может быть сначала очень небольшим, но при необходимости способен включать в себя до 10 миллионов объектов. Если требуется более сложная организационная структура или необходимо хранить очень много объектов, домены Windows NT можно легко соединить в одно дерево. Множество деревьев образуют «лес». Концепция лесов позволяет создавать на предприятии домены Windows NT с несовпадающими DNS-именами, например, MyCo.com и MyCoResearch.com. Использование контейнерной структуры для моделирования организации Контейнерная структура (container hierarchy) Active Directory позволяет размещать организационные единицы в пределах доменов (а также в пределах других ОЕ). В результате возникает иерархическое пространство имен, которое можно сформировать в соответствии со структурой конкретной организации и использовать для делегирования полномочий на администрирование на подуровни. В контейнере находится оглавление; в котором, например, могут быть перечислены основные отделы предприятия. В этом примере можно выбирать подотделы, входящие в отделы, открывать их и т. д. Переход к контейнерной структуре с более детализированной моделью администрирования (похожей на описываемую здесь) решает многие проблемы. Несмотря на то, что домены могут быть очень большими, процедура поиска остается простой. Все, что существует в доменном дереве, отображается в глобальном каталоге, который позволяет легко находить объект независимо от того, в каком месте дерева или леса он находится. Детализированное администрирование Доменные деревья, создаваемые Active Directory, предоставляют намного более широкие возможности администрирования, чем организационные структуры других служб каталогов, где домены равноправны. Хотя в Active Directory можно построить и такую схему, с точки зрения управления предпочтительнее создать дерево доменов, в каждом из которых будут собственные права доступа. Иерархия доменов упрощает администрирование за 210 счет более подробной структуры и без ущерба для безопасности. Разрешения могут поступать сверху вниз по дереву, при этом пользователи будут получать разрешения (а также сами давать разрешения другим пользователям) в соответствии с отношениями организационных единиц. Такая структура доменного дерева позволяет легко отслеживать организационные изменения: различные сокращения, добавления и объединения. Каждый домен в доменном дереве имеет копию информационного каталога, содержащего все объекты для данного домена, а также метаданные о доменном дереве (схему, список всех доменов в дереве, месторасположение серверов глобального каталога и т. д.). Поскольку нет необходимости хранить все объекты в одном каталоге, можно создавать очень большие деревья без ущерба для производительности. Повышенная безопасность Система администрирования Active Directory хорошо детализирована и допускает децентрализованное администрирование без ущерба для безопасности. Поскольку в каждом домене свои ограничения доступа, становится возможным наличие многих областей безопасности. В данной схеме администраторы домена А не являются автоматически администраторами домена B. Контейнерная иерархия важна потому, что в настоящее время объектом администрирования является домен, и администратор домена полностью контролируют все объекты и службы в пределах этого домена. В зависимости от конкретных обязанностей пользователям в рамках Active Directory можно делегировать различные полномочия. Область администрирования может включать в себя весь домен, поддерево ОЕ внутри домена или отдельную ОЕ. При помощи Active Directory можно создавать очень большие структуры пользователей. В этих структурах любой пользователь будет иметь потенциальный доступ ко всей хранящейся в каталоге информации, при этом границы областей безопасности остаются четкими. Области безопасности могут быть намного меньше доменов. Например, при создании учетной записи пользователя она ассоциируется с определенным доменом, но также может входить и в организационную единицу. Полномочия по регистрации пользователей в организационной единице можно делегировать, в результате кто-то другой тоже сможет вводить пользователей или другие объекты каталога, однако только в одном месте, в пределах данной ОЕ. Кроме того, можно создавать иерархии ОЕ. Active Directory предоставляет в распоряжение администратора множество различных условий доступа, которые могут быть делегированы или ограничены в пределах некоторой области. Расширение службы каталогов с помощью схемы (Extensible Schema) Чтобы администраторы могли создавать в каталоге собственные типы объектов, в Active Directory предусмотрен специальный механизм под названием схема (schema). Если у пользователя есть важная информация, которую он хочет сделать доступной через службу каталогов, он может создать новый тип объекта и 211 поместить его в каталог. Например, оптовый торговец может создать объект, относящийся к складу, и, записав в него нужную информацию, поместить в каталог. Можно создавать новые классы объектов и переменные. В службах каталогов определены различные классы. Active Directory, например, предоставляет стандартные объекты для Домена, Организационной единицы, Пользователя, Группы, Машины, Тома, Очереди на печать, а также богатый набор объектов, описывающих соединения и используемых службами Winsock, RPC и DCOM. Глобальный каталог Все объекты, хранящиеся в Active Directory, имеют записи в глобальном каталоге (ГК) — отдельной службе, которая содержит информацию из всех доменов данного дерева. ГК предназначен для повышения производительности и позволяет легко находить объекты по заданным параметрам независимо от их места в дереве. Такие параметры хранятся в сокращенном каталоге (abbreviated catalog). Этот метод получил название частичной репликации и позволяет выполнить значительное число запросов при помощи ГК и без обращения к домену. Глобальный вид (global view) может содержать объекты любого типа, например, Пользователей, Службы или Машины. Типичной функцией глобального вида является предоставление глобальной адресной книги для почтовых программ или других приложений, работающих с почтой. На Рис. 34 показана структура глобального каталога. Global Catalog Domain 1 Domain 2 partial replicas full replicas Domain n Рис. 34. Структура глобального каталога предусматривает доступ к полным и частичным репликам Многоуровневая репликация То, как служба каталогов хранит информацию, непосредственно определяет ее производительность и масштабируемость. Службы каталогов должны отрабатывать очень большое число запросов и гораздо меньше изменений данных. Как правило, на 99 запросов приходится 1 изменение. Поэтому репликация 212 данных так важна. Создавая многочисленные копии каталога и постоянно обновляя их, можно увеличить количество запросов, обслуживаемых без снижения производительности. Такая репликация данных каталога и их синхронизация получила название многоуровневой (multimaster) репликации. Обновление каталога в многоуровневой среде В Active Directory встроена действительно многоуровневая репликация. В некоторых службах каталогов для создания обновлений применяется иерархический (master-slave) подход: все обновления заносятся в главную копию каталога, после чего переносятся и на зависимые копии. Такой метод приемлем для каталогов с небольшим числом копий и для среды, в которой все изменения можно вносить централизованно. Однако такой подход применим только в небольших организациях, а кроме того не отвечает потребностям организаций с децентрализованной структурой. Active Directory предлагает многоуровневую репликацию: локальные изменения в какой-либо копии каталога автоматически копируются на все остальные копии (при этом связь между копиями может быть постоянной или периодической). Некоторые службы каталогов для отслеживания изменений используют метки времени. Это приемлемо для каталога с иерархическим методом внесения изменений, где все обновления делаются централизованно, однако для каталога с многоуровневой репликацией использование временных меток затруднительно. Время во всех копиях каталога должно быть очень точно синхронизировано, иначе возникает опасность утери данных или повреждения каталога. Active Directory не использует временные метки для отслеживания изменений. Вместо этого используются номера обновлений — Update Sequence Numbers (USNs). Каждый раз, когда пользователь записывает что-то в объект каталога, это изменение получает номер USN, собственный для каждого компьютера. USN увеличивается при каждом изменении объекта. Если пользователь на одном компьютере обновляет регистрационную запись, текущее значение USN на этом компьютере увеличивается на единицу и сохраняется в объекте вместе с изменением и уникальной подписью компьютера, на котором это изменение было сделано. В объекте имеется также USN для каждого атрибута. При изменении атрибута USN увеличивается. Все изменения отслеживаются: другие компьютеры, связанные с исходным отношениями репликации, запрашивают у него информацию о всех изменениях, номер которых превышает имеющиеся у них USN. После этого исходный компьютер просматривает каталог и находит все объекты, чьи USN превышают числа, присланные компьютером-партнером. Изменения атрибутов согласовываются индивидуально; при репликации обновляются только те атрибуты, у которых более высокий USN. В случае конфликта (когда два разных компьютера обновили один и тот же атрибут) приоритет отдается изменению с более поздней меткой времени. Временная метка используется только для разрешения подобных конфликтов, поэтому 213 синхронизация времени здесь не важна. Поскольку каждый атрибут согласовывается индивидуально, вероятность конфликтов сводится к минимуму. 214 Распределенная система защиты Защита с закрытым ключом Наряду с Active Directory, в следующей версии ОС Windows 2000 Server появится распределенная модель защиты, основанная на протоколе авторизации MIT Kerberos. Протокол Kerberos используется для обеспечения распределенной системы зашиты в пределах дерева и работает как с открытыми, так и с закрытыми ключами, опираясь на механизм Access Control List (ACL) операционной системы Windows 2000. Active Directory является местом хранения системы защиты (включая учетные записи пользователей, группы и домены). Она замещает реестровую регистрационную базу Реестра и является компонентом системы Local Security Authority (LSA). Единая регистрация в пределах дерева доменов Windows 2000 предоставляет пользователю доступ к ресурсам, расположенным в любом месте корпоративной сети. Простые в эксплуатации административные утилиты для управления безопасностью и учетными записями позволяют сократить затраты на эксплуатацию операционной системы. Windows 2000 также предоставляет базу для общей системы безопасности ПО семейства Microsoft BackOffice®, включая Microsoft Exchange, Microsoft SQL Server, Microsoft SNA Server и Microsoft Systems Management Server. В добавление к парольной авторизации (авторизации с закрытым ключом) протокол MIT Kerberos V5 дополнен расширениями для авторизации с открытым ключом. Защита с открытым ключом Для тех субъектов (например, пользователей), которые не имеют разрешений Kerberos, Active Directory поддерживает использование сертификатов X.509 v3 Public Key Certificates. Как правило, это пользователи, находящиеся вне организации, которым нужно получить доступ к ресурсам. Например, аэрокосмическая фирма может нанять субподрядчиков, которым нужен доступ к спецификациям, планам и т. д. Active Directory допускает перенос сертификатов X.509 v3, выданных уполномоченным (trusted) лицом, в группы безопасности Windows NT. Таким образом, пользователь отличной от Windows NT операционной системы может получить доступ к необходимым ресурсам наравне с имеющим разрешение Kerberos. 215 Утилиты для администрирования Администрирование в стиле «перетащить и оставить» В Active Directory входит целый ряд интуитивно понятных и эффективных утилит для администрирования. С целью моделирования больших организаций объекты могут быть организованы в иерархию, а графический интерфейс пользователя предоставляет наиболее часто используемый инструмент администрирования — консоль управления с поддержкой технологии "перетащить и оставить". Консоль предоставляет объектный подход к администрированию, например, администратор может взять верхушку некоторого дерева и перетащить его в нужный домен. В диалоговом окне администратора попросят подтвердить данную операцию (разумеется, у администратора должны быть соответствующие полномочия: внутри переносимого дерева — на объединение его с другими, а в целевом домене — на подключение новых деревьев. Сценарии и автоматизация Необходимо, чтобы все, что можно сделать через интерфейс пользователя, можно было сделать и путем написания программы или сценария. Чтобы администратор мог создавать командные процедуры, Active Directory имеет полную поддержку сценариев и средств автоматизации. Можно добавлять, изменять, перемещать, копировать объекты, а также выполнять другие административные функции в рамках Active Directory путем создания сценариев при помощи таких языков, как Visual Basic, Java™ и т. п. 216 Обеспечение обратной совместимости Для тех, кто пользуется Windows NT Server версии 3.51 и 4.0 обратная совместимость критически важна. В Active Directory обратная совместимость была заложена изначально. Active Directory обеспечивает полную эмуляцию служб каталогов Windows NT 3.51 и 4.0; утилиты для администрирования и приложения, написанные для Win32® API будут работать в среде Active Directory без всяких изменений. Контроллер доменов следующего поколения Windows NT Domain Controller, встроенный в домен Windows NT 3.51 и 4.0, выглядит и работает точно так же, как контроллер доменов Windows NT 4.0. Это значит, что капиталовложения в существующие сети и приложения под Windows NT надежно защищены. Сегодня можно устанавливать Windows NT Server 4.0 и быть полностью уверенным, что последующий переход к Active Directory будет безболезненным. Легкий переход с Windows NT 3.51 и 4.0 Чтобы обеспечить плавный и безпроблемный переход, Active Directory изначально разрабатывалась для работы в смешанной среде. Смешанный домен, имеющий как контроллеры доменов следующего поколения, так и предыдущего (Windows NT 3.51 и 4.0), работает в точности, как домен Windows NT 4.0. Переход с серверов более низкого уровня на Active Directory может происходить только на одном контроллере доменов в каждый момент времени. После модернизации главного контроллера в домене Windows NT 4.x данный домен может быть присоединен к дереву. В следующем разделе подобный процесс перехода показан на конкретном примере. Переход с Windows NT 4.0 на Active Directory В данном примере имеется простой домен Windows NT 4.x с тремя контроллерами доменов: одним главным контроллером доменов (PDC) и двумя резервными (BDC). На Рис. 35 показана начальная конфигурация. 217 Windows NT 4.0 Domain PDC BDC BDC Рис. 35. Простой домен Windows NT 4.x с одним главным контроллером(PDC) и двумя резервными (BDC). Чтобы начать процесс перехода, необходимо сначала установить на главном контроллере (PDC) Windows 2000 и Active Directory. Новый контроллер доменов DC/PDC в процессе модернизации переносит данные из каталога домена Windows NT 4.0 в Active Directory (см. Рис. 36). Domain Replica Global Catalog Mixed Domain DC/PDC BDC BDC BDC Рис. 36. Смешанный домен Когда вы устанавливаете Windows 2000 на главный контроллер доменов (PDC), Active Directory становится главной копией (master copy) каталога домена. с этого момента вы можете использовать графические средства Windows 2000 для системного администрирования и работы с учетными записями в данном домене. Резервные контроллеры доменов Windows NT 3.51 и 4.0, а также клиентские системы в домене не получают информации о выполненных изменениях и продолжают работать как обычно. Заключительный этап перехода заключается в переводе всех резервных контроллеров доменов (BDC) на Windows 2000. По мере модернизации вторичные 218 контроллеры доменов становятся равными главному. Репликация Windows NT 4.0 замещается многоуровневой репликацией Windows 2000 (см. Рис. 37) Рис. 37. Однородный домен — бывшие резервные контроллеры теперь равноправны с контроллерами доменов Windows NT 5.0. После модернизации всех резервных контроллеров смешанный домен становится доменом Active Directory/Windows 2000. Клиентские системы более низкого уровня будут по-прежнему воспринимать этот домен как домен Windows NT 3.51 или 4.0. Клиенты следующего поколения будут воспринимать данный домен как домен следующего поколения и будут полностью использовать все возможности Active Directory. Легкий переход от службы Microsoft Exchange На сегодняшний день многие организации пользуются ПО Microsoft Exchange для обработки сообщений и создания информационной инфраструктуры. К моменту выхода Active Directory капиталовложения этих организаций в службу каталогов Microsoft Exchange будут значительны. В будущих версиях Microsoft Exchange будет использовать Active Directory, в результате чего отпадет необходимость в собственной службе каталогов Microsoft Exchange. Имеющаяся версия Microsoft Exchange будет укомплектована специальной утилитой, которая позволит переносить содержимое службы каталогов Microsoft Exchange в Active Directory. Такой подход позволяет защитить капиталовложения наших клиентов в данные и организационную структуру Microsoft Exchange и предоставляет возможность плавного перехода от службы каталогов Microsoft Exchange к Active Directory. 219 Заключение Компания Microsoft прилагает все усилия для улучшения службы каталогов Windows NT Server в следующей версии Windows 2000 Server. В этой версии Microsoft предложит своим клиентам ПО Active Directory — службу каталогов, опирающуюся на стандарты, разработанную специально для удовлетворения потребностей клиентов, работающих в распределенных компьютерных средах. Active Directory дает широкие возможности для унификации и управления различными пространствами имен, которые существуют в настоящее время в гетерогенных компьютерных сетях предприятий. Active Directory сочетает в себе лучшие возможности стандартов DNS и X.500, LDAP, других протоколов, а также богатый набор API, и допускает управление из единого центра любыми ресурсами: файлами, периферийными устройствами, подключениями, базами данных, доступом к Web, пользователями, различными другими объектами, службами и сетевыми ресурсами. Active Directory поддерживает иерархическое пространство имен для учетных записей пользователей, групп и машин, а также может импортировать другие каталоги и управлять ими. Active Directory является службой каталогов общего назначения и позволяет снизить нагрузку на администратора, а также сократить расходы на поддержание нескольких пространств имен. Active Directory эффективно сочетает в себе открытые стандарты, администрирование в стиле "перетащить и оставить", глобальный каталог, расширяемость, многоуровневую репликацию, распределенную систему зашиты, масштабируемость и полную обратную совместимость с Windows NT 3.51 и 4.0. Все это делает данную службу каталогов идеальной платформой для администрирования сегодняшних гетерогенных сетей и базой для единой распределенной компьютерной среды будущего. Active Directory стала центральным звеном процессов обособления информации, миграции, централизованного управления и сокращения количества каталогов на предприятиях. Active Directory является идеальной основой для обмена корпоративной информацией, унификации управления сетевыми ресурсами, включая приложения, сетевые операционные системы и устройства, взаимодействующие с каталогами. 220 Novell eDirectory 8.7.1 Novell eDirectory™ является фундаментом крупнейших в мире систем управления идентификацией, который позволяет компаниям управлять идентификационными параметрами и контролировать доступ сотрудников, клиентов и партнеров. Первый в своем роде и самый совершенный полнофункциональный каталог Novell eDirectory предоставляет компаниям полный комплекс решений для мультиплатформенных сетевых сервисов и защищенного управления идентификацией. Обзор Мощный и отлично зарекомендовавший себя каталог Novell eDirectory 8.7.1 обеспечивает связь ваших пользователей и их прав доступа с корпоративными ресурсами, устройствами и политиками безопасности. При помощи eDirectory ваша компания получает возможность: Сократить расходы на администрирование Обеспечить защиту ресурсов от несанкционированного доступа Поддерживать многочисленные платформы и открытые стандарты Масштабировать ресурсы для поддержки возможностей развития бизнеса Novell eDirectory действительно универсальное решение: работает на платформах Windows*, Linux*, Solaris*, NetWare®, AIX* и, в ближайшее время, под управлением HP-UX*. Впервые вы имеете возможность установить eDirectory на сервер Windows без установки Novell Client™. Программные решения защищенного управления идентификацией и мультиплатформенные сетевые службы на базе eDirectory повысят производительность, защитят корпоративные ресурсы и обеспечат быструю окупаемость вложений. Сокращение расходов на администрирование Novell eDirectory обеспечивает гибкое централизованное управление пользователями, ресурсами и политиками в вашей сети. В состав eDirectory входит обновленная версия Novell iManager - консоль управления, поддерживающая защищенное управление каталогами через Web-браузер и многочисленные устройства беспроводной связи. Располагая централизованной системой Web-управления, вы можете отказаться как от излишних расходов на администрирование, так и от ненужных поездок, экономя при этом время и средства. Защита ресурсов от несанкионированного доступа При помощи Novell eDirectory вы получаете контроль над доступом пользователей к сетевым ресурсам в режиме реального времени. Если вы ограничиваете их права доступа к сети - или даже одному файлу - их доступ 221 мгновенно блокируется. Такой мгновенный и точный контроль пользователей и ресурсов укрепляет безопасность и экономит ваши средства. Novell eDirectory также повышает безопасность с помощью универсальных паролей в UTF8-кодировке и поддержки усовершенствованной многофакторной аутентификации, включающей биометрию, смарт-карты, маркеры защиты и многие другие методы регистрации. Поддержка мультиплатформенности и открытых стандартов Кроме не имеющей равных поддержки основных операционных платформ, Novell eDirectory также совместим с целым рядом открытых и новых стандартов. В частности, eDirectory поддерживает Lightweight Directory Access Protocol, версия 3 (LDAP v3), Extensible Markup Language (XML), Secure Sockets Layer (SSL), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) и многие другие. Поддержка этих открытых стандартов позволяет заказчикам увеличить инвестиции в развитие технологий и избежать «привязки» к программным продуктам конкретного разработчика. Масштабируемость для поддержки возможностей развития бизнеса Ни одна другая служба каталогов не может соперничать с Novell eDirectory в надежности и масштабируемости: эта технология была протестирована с привлечением более миллиарда пользователей и сетевых объектов, тем не менее, время реакции системы не превышало доли секунды. Это означает, что с ростом вашей компании eDirectory с легкостью сможет вместить дополнительных пользователей или ресурсы без ухудшения рабочих характеристик. Возможности 1. Идентификационная база Novell eDirectory 8.7.1 предоставляет администраторам множество дополнительных возможностей. В приведенном ниже списке все новые и усовершенствованные возможности выделены курсивом: 2. Работает на платформах Windows NT*/2000, Linux, Solaris, NetWare, AIX и, в ближайшее время, под HP-UX. 3. Поддерживает открытые и новые стандарты 4. Управляет всеми видами идентификации, ресурсами, устройствами и политиками 5. Позволяет увеличить масштаб более чем до миллиарда объектов 6. Динамически укрепляет безопасность 7. Предлагает установку на Windows NT/ 2000 без участия пользователя 8. Надежно отслеживает и сообщает об использовании ресурсов 9. Предусматривает универсальные пароли в UTF8-кодировке 10. Объединяет в одно целое многофакторную аутентификацию 11. Включает Web-управление Преимущества 222 При помощи идентификационной базы Novell eDirectory вы получаете возможность: Сократить расходы на администрирование Использовать гибкое Web-управление Защитить ресурсы с помощью многоуровневой системы безопасности Использовать уже имеющиеся системы Ускорить процессы интеграции и слияния Индивидуализировать предоставление услуг Расширенный набор возможностей, масштабируемость и Web-инструменты обеспечивают гибкое и рентабельное управление пользователями и ресурсами в сети. Имея eDirectory в качестве основы программных решений для защищенного управления идентификацией и мультиплатформенных сетевых сервисов, вы можете отказаться от излишнего администрирования, защитить ресурсы и быстро получить значительную окупаемость инвестиций. Резюме для руководства Каждая крупная компания - это, прежде всего, сетевая компания. Барьеры, существовавшие прежде между интрасетями, экстрасетями и Интернет все больше стираются по мере того, как компании во всем мире переходят к электронным взаимоотношениям со своими клиентами, поставщиками и партнерами. Эта новая реальность - ведение бизнеса в условиях one Net - определяет необходимость четкого представления о том, с кем компания имеет дело и насколько важен для организации тот или иной партнер. Для успешного ведения дел вам требуются сетевые службы, обеспечивающие надежную и защищенную связь с теми организациями, которые вам действтельно необходимы, и имеющими к тому же необходимые возможности для работы в различных сетевых средах вашей компании. Novell eDirectory - это единственное универсальное и апробированное решение, отвечающее все более усложняющимся условиям работы вычислительных сетей. Ведущий отраслевой Единый каталог Novell - NDS eDirectory - служит основой для управления сетевыми ресурсами всех операционных систем в средах Сети. Независимо от того, работают у вас пять или 50000 служащих, NDS eDirectory надежно и безопасно реализует их доступ в Сеть. Управляя ресурсами всей Сети в условиях максимальной защищенности, NDS eDirectory ликвидирует “дыры” между предприятием и Интернет, позволяет компаниям управлять защищенными и соответствующим образом адаптированными отношениями с клиентами и партнерами, которые выбрали Web в качестве основного канала ведения бизнеса. Единый каталог NDS eDirectory позволяет клиентам интегрировать различные серверы и клиенты под управлением Unix, NetWare, Linux, Compaq Tru64,Windows 2000 and Windows NT в рамках структуры Единого каталога, что не по силам ни одному другому сетевому решению из предлагаемых в настоящее время на рынке. Microsoft хочет заставить вас думать по-другому. Однако, ее каталог Active Directory работает только с Windows 2000 и управляет 223 исключительно Windows-средами. Active Directory не дает возможности использовать универсальные сетевые службы, необходимые компаниям для успешной конкуренции с другими организациями. NDS устраняет излишнее администрирование в гетерогенных корпоративных системах, поскольку реализует единую точку управления учетными записями пользователей, профилями, политиками доступа, предпочтениями, средствами проверки полномочий, прикладными службами, а также многими другими видами сетевой деятельности. Novell предлагает две дополняющие друг друга опции NDS: NDS eDirectory. Единый каталог NDS eDirectory разработан для сред, используемых компаниями "dot-com". Он в большей, чем любая другая технология, степени упрощает бизнес-отношения в среде Интернет. Буквально всем - от малого предприятия до крупнейшей Интернеткомпании - NDS eDirectory гарантирует надежность, защищенность, масштабируемость и простоту в управлении при развитии электронных отношений с клиентами, поставщиками и партнерами. Novell Account Management 2.1 - приложение на базе NDS eDirectory - упрощает процесс управления сетевыми ресурсами в масштабах корпорации. NDS Corporate Edition способствует интеграции всех корпоративных ресурсов в сети - на платформах NetWare, NT, Solaris, Linux и Compaq Tru64, обеспечивая единую точку администрирования. NDS eDirectory в сочетании с NDS Corporate Edition предоставляет возможность контролировать наиболее важные процессы электронного бизнеса. Используя NDS eDirectory и NDS Corporate Edition, компании любого масштаба и независимо от их специализации могут развивать коммерческую деятельность в соответствии с требованиями Интернет-экономики. Сравнительный анализ отдельных функций В данном материале дается описание высокоуровневых функций решения Единого каталога Novell NDS eDirectory. В целях сравнения отмечаются лишь функции, которые в той или иной форме присутствуют также и в Active Directory. Данное сравнение предоставляет вам возможность убедиться воочию, в каких случаях шансы NDS и Active Directory равны, а в каких NDS превосходит Active Directory, делая это решение Novell недостижимым для конкурирующего продукта. Перечисленные ниже функции описываются более подробно в этом материале. Таблица 17 Функции Поддержка множества операционных систем NDS eDirectory X Active Directory 224 Функции NDS eDirectory Обеспечения доступа со множества платформ X Единое дерево для всех сетевых ресурсов X Эффективные механизмы хранения данных X Active Directory Апробированная технология масштабирования базы данных Оптимизированные процессы тиражирования X Поддержка существующей структуры X Централизованное управление на базе каталога X Управление через объекты «подразделение» (Organizational Units) X Неограниченные возможности реорганизации дерева каталога X Глобальное хранилище управленческой информации X X Интегрированные службы аутентификации и авторизации X X Прозрачное управление списком контроля за доступом X Динамическое наследование прав доступа X Структурированное делегирование административных прав X Возможности расширения распределенной схемы данных X Поддержка ADSI X Поддержка «дополнительных» стандартных функций LDAP X Интерфейсы службы каталога на базе стандартов X X NDS содержит в себе множество высокоуровневых функций, которых нет в Active Directory. Особенно это касается межплатформной поддержки. Даже в тех случаях, где Active Directory и включает некоторые похожие функции, их 225 реализация оставляет желать лучшего, так как они не приносят ощутимой коммерческой выгоды. Анализ приводимых выше функций не оставляет сомнения в том, что Единый каталог NDS eDirectory является именно тем решением, которое позволит вашей компании успешно войти в сетевую экономику. Опыт мировой практики Сами по себе функции могут иметь прекрасные характеристики, однако не менее важно, как они работают в реальной жизни. И здесь преимущества NDS eDirectory перед Active Directory проявляются со всей очевидностью. При выборе средств реализации критически важных сетевых служб ведущие корпорации отдали предпочтение Единому каталогу NDS eDirectory фирмы Novell. CNN выбрала NDS eDirectory для доставки персонифицированного контента своим клиентам (подробнее о том, почему CNN выбрала NDS eDirectory, можно узнать на сайте http://www.novell.com/products/nds/cnn-casestudy.html.) . Alta Vista предпочла NDS eDirectory, чтобы управлять службами мгновенной передачи сообщений, обеспечивая при этом максимальную защиту передачи данных. British Telecom, крупнейшая в Европе компания по числу служащих, использует NDS Corporate Edition для управления деятельностью своих 90000 сотрудников в гетерогенной сети. Если NDS способна обеспечивать работу наиболее важных служб вышеперечисленных компаний, представьте, каковы ее возможности в масштабе вашей фирмы. Поскольку NDS предлагается на множестве платформ, вы можете пользоваться предоставляемыми возможностями с большей гибкостью. В настоящее время более 70 миллионов человек пользуются защищенными службами на базе NDS. Уровень и масштаб вашей организации не имеет значения. Не имеет значения также, работаете вы уже в Сети или только намереваетесь идти по этому пути. Единый каталог NDS eDirectory поможет вам достичь поставленной цели. 226 Реализация Поддержка множества операционных систем. Служба каталога связывает разрозненные элементы современной сети. Используемый в гетерогенных сетях каталог корпоративного уровня должен обеспечивать свободу и гибкость при выборе платформы. Различные операционные состемы несут в себе различные коммерческие преимущества, и клиентам должна быть предоставлена возможность подобрать именно ту хостсистему, которая будет в наибольшей степени отвечать их потребностям. Преимущество NDS NDS позволяет реализовать единый унифицированный каталог, управляющий всеми сетевыми ресурсами и работающий на любой комбинации платформ - NetWare, Windows NT, Windows 2000, Linux и Solaris. NDS уже функционирует на платформе IBM for AIX и OS/390; в 2000 г. появились также версии для Compaq Tru64. В отличие от NDS, Active Directory работает только на сервере Windows 2000. Более того, AD не совместим даже с собственной Windows NT, а чтобы получить полную отдачу от AD все NT-серверы в сети необходимо обновить до Windows 2000. NDS же полностью поддерживает NT-серверы и не требует обновления Windows. Благодаря тому, что Novell обеспечивает поддержку множества операционных систем, клиенты могут сами выбрать требуемую платформу и полностью удовлетворить свои текущие и будущие потребности. С NDS им никто не диктует выбор платформы - в отличие от AD, которая диктует лишь свои условия. Обеспечение доступа со множества платформ Служба каталога должна быть доступна для всех сетевых клиентов с тем, чтобы они могли пользоваться информацией, которой эта служба управляет и которую хранит. Пользователи должны также иметь возможность входить в сеть со множества настольных систем, а приложения должны выполняться на любой платформе и иметь доступ к каталогу независимо от того, на какой операционной системе (или системах) они выполняются. Преимущество NDS NDS обеспечивает клиентам полноценный доступ с платформ DOS, Windows 3x, 9x, NT, Windows 2000, UNIX, Linux, OS/2, Macintosh и NetWare. NDS реализует централизованное управление всеми этими платформами, а также приложениями, которые на них выполняются. В отличие от NDS к каталогу Active Directory можно получить полноценный доступ только с клиентских платформ Windows 2000. Функциональные возможности рабочих станций под Windows 9х и NT в этом плане ограничены. 227 Ограничения в поддержке разных платформ свидетельствуют о том, что AD способна управлять только системами с Windows 2000, которые составляют лишь небольшой процент систем, действующих во множестве корпоративных сред. Единое дерево для всех сетевых ресурсов Службы каталога позволяют клиентам логично организовать сетевые ресурсы по иерархическому принципу и представить их в виде дерева. Дерево каталога состоит из контейнеров и объектов «листья». Контейнеры - такие, как Подразделения (Organizational Units) - позволяют организовать другие контейнеры и объекты «листья», называемые также «дочерними объектами» (child objects), которые создаются внутри них. Такие объекты- «листья», как Пользователь, Сервер, или прикладные объекты, представляют собой сетевые объекты, управляемые каждый в отдельности. Политики управления (например, контроль прав доступа), применяемые в отношении объектов, также наследуются всеми дочерними объектами, находящимися в подчиненном положении к этим объектам в структуре дерева. Преимущество NDS Основой NDS является одно дерево, в котором представлены все сетевые ресурсы. Дерево и его логические группы сетевых ресурсов можно перестраивать с учетом происходящих в корпорации изменений. Независимо от того, каким образом организовано дерево и его группы, права наследования постоянно действуют в масштабе всего дерева. Такой унифицированный подход к службе каталога, являющейся по сути логической моделью для организации вашей компании, обеспечивает беспрецедентную легкость в управлении и условия для быстрой адаптации к осуществляемым в компании изменениям. Напротив, Active Directory реализует отдельное дерево внутри каждого управляемого домена. Домены организуются в иерархическую структуру, образующую «лес» (forest). Поскольку дерево каждого домена не связано с остальными, каждый домен создает административную границу, которая не позволяет действовать правам доступа в рамках всего леса. В результате администрирование прав в AD осуществляется отдельно для каждого домена, что существенно уменьшает преимущества, связанные с наследованием прав, и в итоге снижает масштабируемость AD в плане управления. Эффективные механизмы хранения данных Являясь центральным хранилищем информации для управления всей сетью, служба каталога обязана удовлетворять потребности как малых, так и самых крупных Интернет-компаний. Крупные сети могут хранить в каталоге до нескольких миллиардов объектов. Поскольку служба каталога выступает в качестве хранилища огромных объемов данных, она должны обладать эффективными механизмами хранения, чтобы не допустить перегрузки сервера и снизить аппаратные расходы компаний. 228 Преимущество NDS NDS построена на устойчивом механизме - хранилище базы данных. Его отличает особая эффективность в использовании дискового пространства. Для размещения базы данных NDS требуется лишь 1 Мбайт дискового пространства, а при работе с 50000 объектов - 75 Мбайт. Для AD цифры, соответственно, 44 и 280 Мбайт. Эффективные механизмы хранения Единого каталога требуют значительно меньше, чем в случае с AD, аппаратных и административных ресурсов, что чрезвычайно важно как для малых, так и для крупных предприятий. Апробированная технология масштабирования базы данных Каталоги используют встроенный механизм базы данных в целях хранения, обновления и извлечения информации, содержащейся в каталоге. Используя базу данных для хранения информации, каталог обеспечивает большую масштабируемость и производительность. Преимущество NDS NDS разработана на основе самой передовой технологии серверной базы данных, с которой уже работают около 70 миллионов пользователей. Этот многоцелевой механизм базы данных поддерживает масштабируемость произвольно структурированных данных в широких пределах и обладает высокой отказоустойчивостью. NDS предлагает клиентам масштабируемость, превосходящую их потребности, что было доказано во время показательной демонстрации возможностей дерева NDS, содержавшего более миллиарда объектов (т.е. миллионов объектов в каждом разделе). Технология базы данных NDS позволяет клиентам реализовать разделы любой величины с учетом их сетевых потребностей. AD использует механизм базы данных, разработанный на основе базы данных настольных систем Microsoft Jet, которая, естественно, не была предназначена для применения в корпоративной серверной базе данных. Она была изначально создана как СУБД для Microsoft Access. Если NDS уже показала на практике свою исключительную эффективность, то масштабируемость и производительность базы данных AD еще предстоит проанализировать после того, как она будет испытана в широком масштабе. Последние тестовые испытания, предпринятые Keylabs ( http://www.novell.com/advantage/nds/edir-keylabs.pdf), показывают убедительное превосходство NDS в производительности в реальной практической деятельности. Оптимизированные процессы тиражирования Лучшие службы каталога поддерживают автоматическое многоабонентское тиражирование разделов каталога. Тиражирование позволяет клиентам переносить копии отдельных данных каталога (разделов) на множество серверов каталогов. Функция многоабонентского тиражирования также позволяет администраторам 229 вносить изменения в данные каталога с любой реплики и прозрачно распространять соответствующие изменения на все реплики того же раздела. Преимущество NDS Тиражирование в NDS позволяет осуществлять полностью распределенное управление каталогом и таким образом повысить эффективность работы в сети. Реплики повышают масштабируемость системы, давая возможность распределять нагрузку среди большего числа серверов. Реплики можно разместить физически ближе к пользователям и администраторам, которым необходима содержащаяся в них информация, что содействует повышению производительности. Размещение множества реплик одной и той же информации повышает отказоустойчивость системы, поскольку в случае невозможности использовать какую-либо реплику, другая такая же реплика одного раздела может обслуживать обращения клиентов и административные обновления. Разделы NDS могут быть определены на любом организационном уровне в дереве каталога, и любое количество реплик данного раздела может быть создано на всех NDSсерверах сети. Каждый NDS-сервер может хранить любое число реплик, поэтому один NDS-сервер способен обеспечить быстрый доступ к многим частям данных каталога. Если раздел включает лишь небольшую часть дерева каталога, при тиражировании соответственно меньший объем сетевого трафика передается с большей эффективностью. Эффективность трафика реплик можно повысить еще больше за счет применения Novell WAN Traffic Manager, позволяющего клиентам создавать политики, регулирующие тиражирование в NDS поверх WAN-соединений - в целях предупреждения перегрузок и снижения расходов. В AD наименьшая единица разделения - целый домен. Поскольку Microsoft активно поощряет заказчиков к созданию крупных доменов, трафик при тиражировании оказывается весьма значительным даже при использовании встроенных в AD функций сжатия данных. Таким образом, тиражирование в AD связывает значительные сетевые ресурсы, снижает производительность и увеличивает расходы. Альтернативный вариант - создание множества доменов, однако, в отличие от NDS, AD-сервер может разместить лишь одну реплику, что на практике означает - сервер способен обеспечить доступ только в один домен. Поэтому, если пользователю необходимо получить локальный доступ в более чем один домен, требуется инсталлировать дополнительные AD-серверы, а это приводит к росту расходов на аппаратные средства. Поддержка существующей структуры Службы имен доменов (DNS) Каталоги должны взаимодействовать со Службой имен доменов (Domain Name Services) - распределенной базой данных, которая позволяет сетевым компьютерам использовать имена IT-ресурсов и другой информации. Компьютеры запрашивают службу DNS с тем, чтобы установить связь с другими компьютерами в сети по их именам. DNS упрощает процесс назначения IT-адресов и управления ими за счет создания центральной базы IP-адресов, сокращения объема 230 управления настольными системами и снижения расходов. DNS также является важнейшим средством, благодаря которому корпоративные настольные системы могут получить доступ к Интернет-хостам. Преимущество NDS NDS обеспечивает уверенное управление DNS. Служба каталога NDS рассматривает DNS в качестве одного из объектов дерева каталогов и обеспечивает DNS-информацией все корпоративные серверы имен. Зоны DNS, серверы имен и записи о ресурсах управляются как объекты NDS централизованно из любой точки сети, поэтому заказчики могут создать иерархическую модель DNS в том виде, который их устраивает. DNS, ориентированная на службу каталога Novell, также поддерживает Dynamic DNS и позволяет компаниям без проблем импортировать существующие DNS-конфигурации в формат главного файла BIND. Реализация Novell также интегрируется с существующими первичными и вторичными DNSсерверами через инструменты перемещения данных из одной зоны в другую. Возможности DNS, которые предлагает Novell, полностью интегрированы со службой каталога NDS и поэтому способны использовать многие из ее преимуществ. Microsoft использует службу доменов DNS для того, чтобы AD-клиенты могли найти AD-серверы, а также в целях присваивания имен объектам. В результате Microsoft тесно связывает реализацию иерархий DNS и AD. Это означает, что многие компании должны проделать значительную работу по перестройке существующих реализаций DNS, чтобы перейти к AD. Могут возникнуть проблемы, связанные с политиками, а также и технические проблемы, обусловленные тем, что управление DNS перейдет от администраторов UNIX к администраторам Microsoft. Очень часто Microsoft не придерживается отраслевых стандартов (спецификации Х.500) и использует свою систему наименования объектов. Кардинально отличные подходы к наименованию объектов в NDS и AD имеют следствием возникновение нижеперечисленных проблем, о которых должны знать заказчики: В NDS одно имя объекта может использоваться в различных «подразделениях» дерева каталога, что значительно упрощает управление, поскольку объекты, которые интуитивно используют одно имя, могут использоваться в различных отделах организации (например, HP-принтер в отделе продаж и HP-принтер в отделе маркетинга могут иметь объектные имена HPrint). С другой стороны, метод использования DNS для наименования объектов, применяемый в AD, не позволяет повторно использовать имена объектов в рамках дерева одного домена, даже если они появляются в различных подразделениях этого домена. Поскольку Microsoft рекомендует использовать один домен для всего предприятия, это может вызвать реальные трудности при наименовании объектов. 231 AD использует протоколы, не основанные на стандартах. Чтобы определить местоположение AD-серверов, AD-клиенты полагаются на DNS. Протокол, используемый AD для обнаружения сетевых служб (RFC 2052), еще не одобрен в качестве отраслевого стандарта, и поэтому может быть изменен еще до того, как будет принят рабочей группой IETF по DNS. Что касается службы каталога NDS, то она базируется на SLP - одобренном стандартном Интернет-протоколе (RFC 2165), с помощью которого клиенты NDS могут обнаружить NDS-серверы и любые другие сервисы в сети NDS. 232 Управление Централизованное управление на базе каталога Каталоги обеспечивают централизованное управление сетевыми ресурсами с графической консоли администрирования. Если бы каталоги не использовались в целях управления, системным администраторам пришлось бы применять отдельную утилиту для управления каждым сетевым ресурсом. Кроме того, администраторы были бы вынуждены определять, какие ресурсы есть в наличии и требуют их внимания, им также пришлось бы создавать конфигурации отдельных утилит администрирования для каждого ресурса и управлять ими. Управление физически удаленными ресурсами может быть достаточно сложным в случае задержек сигнала в сети или замедленных WAN-соединений. Преимущество NDS NDS eDirectory реализует действительно централизованное и унифицированное управление всеми видами сети. Active Directory обеспечивает только центральные точки запуска для отдельных утилит управления. NDS включает графическую утилиту администрирования, которая является интуитивной по своему характеру, а потому и несложной в применении. Она позволяет реализовать простое единообразное управление всеми сетевыми объектами непосредственно из иерархического дерева каталога. Все управляемые сетевые объекты (серверы, пользователи, группы, устройства, приложения и др.) визуально представлены в виде объектов дерева, которые можно сгруппировать внутри контейнеров «подразделение» для облегчения управления и создания логической модели организации. Для управления любым объектом администратору достаточно выбрать этот объект, и на дисплее появится специальное окно, с помощью которого можно изменить все атрибуты представленного объекта. Поскольку NDS активизирует локальные реплики, задержки сигнала в сети и замедленные WAN-соединения не оказывают никакого влияния на управление удаленными приложениями и устройствами. Что касается AD и других видов Windows 2000, то они управляются с центральной консоли администрирования; для управления сетевыми объектами не используется единое графическое дерево, отображающее каталог. Серверы, устройства, приложения и т.п. управляются через отдельные утилиты. Такое положение приводит к усложнению управления и, соответственно, к росту затрат. Управление через объекты «подразделение» - Organizational Units (OU) Службы каталога позволяют заказчикам логически организовать сетевые объекты (Пользователи, Серверы, приложения и т.д.) в иерархическую структуру объектов «подразделение» (Organizational Units - OU) в рамках одного дерева. Такое дерево может служить логическим отображением структуры какой-либо организации и визуально представлять ее сеть со всеми ресурсами, что, в принципе, облегчает выполнение административных задач. Объекты OU 233 упрощают управление, позволяя администраторам совершать действия в отношении целых групп сетевых объектов в соответствии с визуальным представлением дерева каталога. Преимущество NDS NDS реализует наследование прав через объекты OU, которые определяют права для всех объектов, находящихся внутри них и ниже в структуре дерева. NDS позволяет применять права доступа непосредственно в отношении OU, таким образом используя само дерево каталога в качестве основного механизма управления правами доступа. Использование OU для управления правами доступа значительно упрощает задачи по администрированию, которые существенно осложняются в крупных реализациях. В отличие от NDS, Active Directory не позволяет предоставлять OU права на использование ресурсов, и поэтому не дает возможности использовать иерархическое дерево каталога в целях моделирования прав доступа для всей организации. Вместо этого, AD требует от администраторов создания Групп для организации сетевых объектов, к которым применяются одинаковые права доступа. Создание и сопровождение Групп в этих целях требует со стороны администраторов дополнительных усилий, а также не позволяет использовать логическое, визуальное отображение организации в дереве каталога. Администраторы, работающие с AD, могут столкнуться с трудностями при выявлении Групп с определенными правами доступа, что приведет к появлению избыточных определений Групп и усложнит процесс управления правами доступа. Неограниченные возможности реорганизации дерева каталога Дерево каталога позволяет заказчикам логически организовать сетевые объекты и получить визуальное отображение сети и ее ресурсов. Учитывая частоту реорганизаций, проводимых многими компаниями, служба каталога должна отличаться достаточной гибкостью, чтобы администраторы могли полностью перекраивать дерево с учетом проводимых в организации изменений. Преимущество NDS При работе с деревом каталога NDS полностью поддерживает функции усечения, прививки, переименования, слияния и разделения (в дополнение ко многим другим основополагающим функциям), что позволяет со временем изменять иерархическую структуру каталога с целью адаптировать ее в соответствии с изменениями в организационной структуре компании. AD не поддерживает усечение, прививку, переименование доменов, слияние и разделение, и поэтому его нельзя без проблем привести в соответствие с организационными изменениями. 234 Глобальное хранилище управленческой информации Каталоги выступают в роли глобального хранилища информации, касающейся управления и конфигурации всех объектов в сети. В задачу каталога входит управление учетными записями пользователей и операционной системой, с которой он работает. В то же время поставщики устройств и приложений могут использовать каталог в качестве хранилища управленческой информации. Преимущество NDS Используя NDS в качестве хранилища управленческой информации, продавцы устройств и приложений могут обойтись без собственных хранилищ и, следовательно, забот по их управлению. Более того, используя каталог в качестве хранилища, продавцы устройств и приложений автоматически обеспечивают своих заказчиков отказоустойчивым средством управления, реализующим преимущества NDS - такие, как распределенное администрирование, распределенная доступность, высокая производительность, масштабируемость, невосприимчивость к сбоям и централизованное управление. Поскольку NDS eDirectory поддерживает множество операционных систем, информацию в средах без Windows можно хранить и администрировать в централизованном порядке с помощью NDS. Active Directory, являясь средством управления приложениями в средах Windows 2000, не обеспечивает возможность такого централизованного хранения и управления. 235 БЕЗОПАСНОСТЬ Интегрированные службы аутентификации и авторизации Каталоги содержат интегрированные службы аутентификации и авторизации, основанные на паролях и списках контроля за доступом, в защищенной форме хранящихся в каталоге. Заказчики используют эти списки для установления права доступа к отдельным сетевым объектам. Впоследствии каталог следит за строгим соблюдением этих прав во время работы пользователей в вычислительных сетях. Средства аутентификации и интеграции создают основу для централизованного и унифицированного контроля за всеми сетевыми ресурсами, включая серверы, устройства и приложения. Преимущество NDS NDS использует механизм аутентификации с помощью открытого ключа, в основе которого лежит технология RSA Security. В течение 20 лет этот чрезвычайно надежный и широко применяемый алгоритм аутентификации проходил испытания на прочность и с 1994 года является основой системы аутентификации NDS. Безопасность работы с NDS проверяется ежедневно 70 миллионами пользователей NDS во всем мире. Недавно Microsoft представила в Active Directory систему аутентификации на базе Kerberos. Kerberos является механизмом аутентификации с помощью секретного ключа и одним из многих инструментов, которые предлагаются на рынке в качестве службы аутентификации. Kerberos в варианте Microsoft еще не прошел практические испытания, и есть определенные опасения, что Microsoft внесла изменения в стандарт Kerberos при включении продукта в Windows 2000 ( http://slashdot.org/article.pl?sid=00/03/02/0958226&mode=thread) Прозрачное управление списком контроля за доступом Списки контроля за доступом (Access Control Lists - ACL) - это инструменты, используемые службой каталога для отслеживания прав доступа каждого сетевого объекта, представленного в каталоге. Правильное управление списками крайне важно, так как обеспечивает надлежащее функционирование каталога и упрощает управление. В качестве примера функционирования ACL можно привести следующую ситуацию. Скажем, пользователь получил право на использование определенного сервера. В результате в списке доступа к серверу создается объект, который регистрирует тип права доступа, предоставленного пользователю. Когда данный пользователь в очередной раз захочет получить доступ к тому же серверу, каталог проверит соответствующий объект Сервер, чтобы установить наличие имени пользователя в списке доступа. Если оно там есть, доступ разрешается. Служба каталога должна обеспечивать полное управление своими внутренними механизмами, используемыми для отслеживания прав доступа. 236 Управление списками должно быть абсолютно прозрачным для администраторов и не предполагать каких-либо дополнительных усилий по сопровождению. Преимущество NDS NDS автоматизирует основные ACL-процессы, поддерживая внутренние «обратные ссылки», указывающие на сетевые ресурсы, к которым пользователь получает доступ. При удалении администратором объекта «пользователь», NDS прослеживает обратные ссылки на ресурсы, к которым пользователь имел доступ, и автоматически удаляет все ссылки в отношении удаленного пользователя. В отличие от NDS, Active Directory не поддерживает обратные ссылки и поэтому при удалении пользователя список контроля за доступом (ACL) для каждого ресурса, с которым работал пользователь, необходимо обновлять. Чтобы представить важность этой проблемы, давайте предположим, что пользователь получил доступ к 20 ресурсам. Таким образом, после удаления пользователя из AD, неоправданная ссылка на этого пользователя будет появляться каждый раз при обращении к каждому из 20 ресурсов до тех пор, пока администратор вручную не внесет изменения в список контроля за доступом к каждому ресурсу или пока не будет приведена в действие автоматическая функция «очистки» AD для удаления списков. В крупной сети серьезность этой проблемы и соответствующие административные расходы могут быть весьма значительными. Отсутствие в AD «обратных ссылок» также не позволяет администраторам быстро установить те сетевые ресурсы, к которым пользователь получил доступ, что осложняет и, соответственно, удорожает соответствующие действия администратора. Динамическое наследование прав Каталоги реализуют функцию наследования прав, которая упрощает управление правами. Благодаря этой функции дочерний объект автоматически получает права доступа, определенные для родительского объекта. Если меняются права доступа для родительского объекта, аналогичные изменения применятся ко всем расположенным ниже дочерним объектам дерева каталога. Группировка ресурсов по объектам «подразделение» позволяет реализовать управление ресурсами с использованием функции наследования прав в централизованном порядке, что значительно экономит время. Управление на основе наследования прав также обеспечивает беспрецедентное масштабирование в управлении. Преимущество NDS В NDS полные права доступа для такого сетевого объекта, как Пользователь, динамически определяются с учетом предоставленных явных прав доступа, эквивалентностей защиты и унаследованных прав. Когда сетевой объект пытается получить доступ к ресурсу, права доступа динамически вычисляются для определения возможностей предоставления такого доступа. Поскольку вычисление прав происходит в динамическом режиме, изменения, вносимые в 237 права доступа для родительского объекта, сразу переходят на все дочерние объекты. В AD, напротив, полные права сетевого объекта сохраняются в статическом режиме в списке контроля за доступом (ACL) взаимосвязанного с ним объекта. И хотя режим наследования прав обеспечивает положение, при котором все изменения в правах для родительского объекта затем распространяются на все дочерние объекты, здесь используется метод вычисления прав доступа, который сильно отличается от того, что применяется в NDS. Чтобы отразить произошедшее изменение, AD необходимо обновить список ACL для каждого дочернего объекта. Этот процесс внесения изменений перегружает ЦП компьютеров и требует для исполнения значительного дискового пространства. Возникает некоторый разрыв во времени - когда были изменены права для родительского объекта и когда были обновлены списки доступа для дочерних объектов. Поэтому изменения в правах доступа для родительского объекта не влекут за собой немедленные изменения в отношении дочерних объектов. Почему это так важно? Например, вам необходимо отозвать право доступа к определенному ресурсу у группы пользователей, представленных как объект OUOrganizational Unit. Используя NDS, администратор может лишить такого права всего лишь родительский объект OU и, в результате, все пользователи данного OU будут немедленно лишены права доступа к данному ресурсу. В случае с AD даже при удалении права доступа в родительском объекте пользователи в OU могут продолжать использовать ресурс до тех пор, пока не будут обновлены все соответствующие списки доступа. AD не гарантирует немедленного наследования прав - а в такой ситуации отдельные пользователи будут иметь доступ, который им запрещен. Еще больше усложняет работу и то обстоятельство, что при регистрации пользователя в сети AD генерирует статическую метку доступа, которая отражает его текущее состояние в группах. Эта метка используется для проверки прав доступа в течение всего времени пребывания пользователя в сети. Поэтому все изменения в группах пользователя, производимые в этот период, не вступают в силу до тех пор, пока пользователь не выйдет из сети, а затем вновь не зарегистрируется в ней. И на этот раз AD не гарантирует немедленного внедрения изменений в правах доступа, что может привести к непредсказуемым последствиям. Структурированное делегирование административных прав И NDS eDirectory, и Active Directory поддерживают Delegated Administration, которое позволяет заказчикам распределять административные полномочия между любым количеством сотрудников, в то же время ограничивая круг административных задач, которые может выполнять каждый из них. Функция делегирования позволяет основной группе администраторов делить ответственность по администрированию крупной сети и таким образом делает управление более масштабируемым. Возможность ограничить круг 238 делегированных прав также повышает уровень безопасности системы, поскольку в этом случае администраторы не могут вносить несанкционированные изменения на других сегментах сети. Преимущество NDS NDS позволяет осуществлять передачу административных прав в отношении любого объекта каталога, в то время как AD ограничивает возможности такой передачи. NDS передает права на общие объекты каталога - такие, как пользователи и группы. NDS также предлагает более широкие возможности в области управления. К примеру, NDS может делегировать необходимые права непосредственно приложению, которому требуется разрешение на управление определенной частью дерева каталога. NDS также позволяет делегировать права OU с тем, чтобы все объекты внутри этого подразделения могли пользоваться такими же правами. Все пользователи, добавленные в OU, автоматически наследуют делегированные права, что устраняет необходимость в ручном управлении для определения прав доступа. AD разрешает делегировать права только объектам Пользователи и Группы, что, естественно, ограничивает возможности передачи прав. Поскольку AD не позволяет делегировать права объекту в «подразделении», администраторам приходится определять и создавать дополнительный объект в Группе для каждого вида передачи прав, то есть задействовать не одного, а более администраторов. При такой системе администраторы должны персонально знать, в какие группы следует включать каждого нового администратора. AD не дает логического представления такой информации через иерархическую структуру дерева каталога - в отличие от NDS. Подобные сведения трудно удержать в памяти, ими трудно обмениваться, особенно в крупных компаниях, отличающихся большой ротацией кадров и частыми организационными изменениями. Поскольку основой NDS является одно дерева каталога, представляющее все сетевые ресурсы, делегирование прав подразделению организации происходит независимо от местоположения объекта, его типа и других факторов. В AD все “подразделения” ограничены рамками одного домена, в котором они находятся, и потому зона делегирования прав сужается исключительно до тех ресурсов, которые находятся в домене. Для компаний, реализующих множество доменов AD, делегирование прав доступа между доменами невозможно. В результате возрастают стоимость и сложность передачи прав и управление ими. 239 Приложения Возможности расширения распределенной схемы Каталоги дают возможность разработчикам и администраторам расширять схему по мере необходимости с тем, чтобы каталоги могли бы быть использованы в качестве глобального хранилища специализированных приложений. Можно определять новые виды объектов каталога и задавать для них соответствующие атрибуты. Например, поставщик телефонных серверов может создать объект, представляющий каждый установленный телефонный сервер, его параметры управления, список прав доступа с указанием клиентов, которым разрешено пользоваться функциями телефонии. Преимущество NDS С помощью NDS можно расширить схему с любого NDS-сервера, хранящего реплику корневого раздела. Можно создать любое количество реплик корневого раздела для повышения отказоустойчивости. Такие реплики могут также создаваться в различных географических точках для повышения уровня доступности. Такие отказоустойчивость и доступность позволяют администраторам устанавливать ориентированные на каталог приложения, которые расширяют схему из любой точки сети благодаря наличию и доступности реплики. Все функции служб каталога, включая расширение схемы, полностью поддерживаются в распределенной реализации NDS. AD, напротив, не позволяет расширять схему с любого AD-сервера. С этой целью используется единственный центральный сервер «schema master». Если доступ к такому серверу невозможен из-за плохих WAN-соединений, перегруженности трафика, выходе сети из строя, расширение схемы произвести нельзя. Такое положение ограничивает возможность администраторов эффективно разрабатывать и инсталлировать приложения на базе каталога. После расширения схемы NDS использует свои широкие возможности для того, чтобы администраторы могли более эффективно управлять правами доступа, и разрешает применять такие права непосредственно к созданным объектам каталога. Например, разработчик может определить специальный объект каталога, представляющий новую прикладную службу. Затем данному объекту могут быть предоставлены права доступа, чтобы эта прикладная служба могла автоматически получить доступ к определенному набору сетевых ресурсов. Это дает возможность автоматизировать процессы использования прикладных программ на базе каталога. AD не позволяет присваивать права специальным объектам каталога, созданным в результате расширения схемы. Для этого требуется совершить ряд ручных операций, требующих значительных временных затрат: потребуется создать специальную дополнительную учетную запись Пользователя, к которой должна обратиться прикладная служба для получения права доступа. В результате управление усложняется, могут возникнуть ошибки и бреши в системе безопасности. 240 Поддержка Active Directory Services Interface (ADSI) Microsoft активно представляет свой собственный интерфейс Active Directory Services Interface (ADSI) в качестве основного интерфейса прикладного программирования (API) для разработки ориентированных на каталог приложений. ADSI работает только на платформах Windows, поэтому написанные для него приложения могут выполняться только на Windows и их нельзя перенести на другие системы. ADSI - это собственная технология Microsoft, не основанная на открытых стандартах, и ее будущее зависит от субъективных факторов. Преимущество NDS Novell через ADSI поддерживает доступ с платформ Windows в NDS для разработчиков, которым нужна такая опция. Поэтому ко всем клиентам NetWare прилагается соответствующий NDS ADSI провайдер. Возможности NDS в этом плане гораздо шире, чем у AD. С помощью NDS eDirectory разработчики могут в целях доступа использовать по своему выбору либо LDAP и JNDI, либо собственные API-интерфейсы Novell. Следовательно, доступ в NDS можно получить с любой платформы и через любой язык программирования. Соответствующие разработки, предполагающие использование JNDI и собственных API-интерфейсов Novell, обеспечивают большую гибкость в работе, однако в стратегическом плане NDS полностью поддерживает LDAPv3 в качестве основного интерфейса прикладного программирования для доступа к каталогу. Поддержка стандартных «дополнительных» функций LDAP v3 Большинство каталогов использует интегрированные LDAP v3-службы. Поэтому приложения могут получить доступ к каталогу и использовать его данные с помощью протоколов LDAP. При использовании LDAP для доступа к службам каталога приложениям безразлично, какая платформа обслуживает запросы LDAP, то-есть, они не зависят от платформы или каталога других производителей. LDAP обеспечивает свободу выбора при использовании приложений и служб каталога, а, следовательно, позволяет применять лучшие из имеющихся решений и не ограничиваться решениями какого-либо одного продавца, сужающими поле деятельности. Преимущество NDS NDS естественно поддерживает все функции LDAP v3, включая последние усовершенствованные средства - такие, как вспомогательные классы, ссылки и управляющие элементы. Предлагаемая Novell реализация функций LDAP в качестве «родного» протокола NDS (а не шлюза) позволяет приложениям LDAP прозрачно просматривать, читать и обновлять информацию в NDS так же, как они делали бы это с помощью любого другого, совместимого с LDAP v3 протокола. LDAP полностью интегрирован с NDS, поэтому великолепные качества NDS полностью реализуются в прекрасном решении каталога на базе LDAP v3. 241 Поскольку Novell стратегически поддерживает LDAP v3 и ратует за его использование, NDS предлагает значительно более широкую функциональность служб каталога по сравнению с существующими стандартными протоколами LDAP v3. Следуя в этом направлении, Novell принимает активное участие в предпринимаемых IETF усилиях по дальнейшему развитию LDAP с целью удовлетворить все более высокие требования заказчиков. В частности, Novell предлагает использовать ее ключевые патенты и интеллектуальную собственность в ходе осуществления совместной работы. NDS также поддерживает ряд стандартных «дополнительных» LDAP-функций, которые, по словам заказчиков Novell, очень важны для них. AD удовлетворяет лишь минимальным требованиям по совместимости с LDAP v3. Здесь отсутствует ряд стандартных «дополнительных» LDAP-функций, которые играют все более важную роль в обеспечении совместимости. Например, AD не поддерживает inetOrgPerson - инструмент, необходимый для функционирования большого количества часто используемых приложений LDAP. Это свидетельствует о том, что Microsoft по-прежнему проявляет нерешительность в вопросах разработки действительно интероперабельных решений. Active Directory скорее соответствует букве, а не духу в том, что касается совместимости со стандартами LDAP. Интерфейсы службы каталога, основанные на стандартах (для разработчиков) Как NDS eDirectory, так и AD обеспечивают интерфейсы прикладного программирования (Application Programming Interfaces - APIs) и компоненты быстрой разработки приложений (Rapid Application Development - RAD), позволяющие заказным устройствам, приложениям и службам получать доступ и работать с информацией на базе каталога. Интегрируя устройства и приложения со службами каталога, разработчики, включая разработчиков приложений для внутренних систем, могут использовать каталог для обеспечения оптимальной управляемости для своих устройств, приложений и служб. Преимущество NDS Устройства, приложения и службы, ориентированные на NDS, позволяют осуществлять централизованное управление, что освобождает администраторов от необходимости управлять каждым устройством или каждой службой в отдельности. Кроме того, благодаря наследованию прав, значительно упрощается контроль доступа. Более простое управление напрямую влияет на снижение расходов по эксплуатации. Разработчики могут свободно выбирать между LDAP, JNDI, ADSI и собственными APIs Novell для доступа к NDS, поэтому в службу каталога Novell можно получить доступ с любой платформы и с помощью любого языка. Несмотря на то, что разработки для собственных интерфейсов NDS обеспечивают большую гибкость, NDS стратегически и полностью поддерживает LDAP 3v и стандартный JNDI в качестве главных интерфейсов доступа. 242 Для доступа в NDS с помощью инструментария ускоренной разработки приложений Novell предлагает несколько RAD-компонентов. NDS включает элементы управления ActiveX, которые полностью поддерживают технологии разработки на базе Windows - такие, как Visual Basic, Delphi и Active Server Pages. Для разработчиков Java Novell предоставляет продвинутые Java Beans, полностью совместимые со всеми инструментами разработки Java. В отличие от подхода, которого придерживается Novell, Microsoft считает свой ADSI основным интерфейсом служб каталогов. Однако он доступен лишь на платформах Windows и поэтому приложения, написанные для него, могут выполняться только на Windowsб их нельзя переносить на другие платформы. Microsoft поддерживает LDAP v3 в качестве протокола доступа в каталог, а также собственную Java-реализацию ADSI (JADSI), которая также работает только с Windows. Microsoft предлагает RAD-компоненты ActiveX, которые поддерживают основанный на ADSI доступ в Active Directory. Microsoft не предлагает Java Beans для поддержки RAD-доступа в Active Directory из Java. Такой акцент на собственные интерфейсы в качестве APIs и RAD ограничивает возможность выбора для заказчиков. Заключение NDS eDirectory от Novell - это ведущее решение служб каталога, предназначенное для управления платформами распределенных сетей, прикладных служб, рабочих станций и операционных систем. Благодаря NDS заказчики получают возможность в централизованном порядке контролировать гетерогенные сетевые среды и в то же время существенно сократить время, усилия и расходы, связанные с задачами по управлению сети. NDS, которая теперь выпускается уже в восьмой версии, соответствует и даже превосходит ожидания заказчиков в отношении надежности, масштабируемости и гибкости - ценных качеств, в которых заказчики могли убедиться с момента появления этого продукта еще в 1994 году. Novell NDS eDirectory предлагает реальные решения для реального мира. В последние четыре года, пока Microsoft разрабатывала Active Directory, Novell переходила к выпуску следующего поколения служб каталога, отвечающих современному состоянию отрасли: кросс-платформенных и универсальных по своему характеру. Единый каталог NDS, отличающийся особой гибкостью и защищенностью, реализует преимущества гораздо более высокого свойства, поскольку максимально учитывает практические потребности клиентов.Безусловно, NDS отличает гораздо большая гибкость по сравнению с Active Directory, а это крайне важно для быстро меняющегося мира электронного бизнеса. NDS eDirectory дает возможность использовать действующую сеть компании и, в отличие от Active Directory, не диктует, в каком направлении ей развиваться. В дополнение ко всему NDS - более простая в реализации, что, в итоге, обеспечивает немедленную отдачу от вложенных средств. 243 Novell NDS eDirectory - лучшее решение для заказчиков, которым требуется надежная, масштабируемая и гибкая реализация служб каталога. 244 ITIL, процессы, проекты, и психоанализ. В ITIL описано довольно много ролей и всегда возникают вопросы как их назначать и совмещать. Кому и как назначать роли? Психологический фактор здесь играет очень важную роль. Личность будущего менеджера процесса - что может сподвигнуть его на занятие проблемной и, прямо скажем, скандальной должности начальника Help Desk (Service Desk)? Как не вспомнить классиков психоанализа? Что важно для будущего начальника - "быть или обладать?". Согласно Эриху Фромму "Быть -- это значит обновляться, расти, изливаться, вырываться из стен своего изолированного "я", испытывать глубокий интерес, страстно стремиться к чему-то, отдавать." Но соловья баснями не кормят… А что можно предложить в качестве субъекта обладания? Зарплату? Но нечасто удается платить высокую зарплату начальнику Help Desk (Service Desk). Должность? Но в начале внедрения ITIL - проектов не очень-то престижна эта должность. Остается - "быть". Но это значимо для молодых людей, которым необходимо "стать". Итак, при внедрении ITIL в организации с нелучшими традициями, начальник Help Desk (Service Desk) должен быть достаточно молод и энергичен. Значит ли, что это всеобщий закон для всех организаций? Нет, конечно, в моей практике есть организации, в которых начальником Help Desk (Service Desk) назначался человек с опытом и результаты были отличные. Но для эти людей "быть" было также на первом месте. От чего это зависит? От "коллективного бессознательного" (Карл Юнг) сотрудников организации. Что в организации престижно, а что нет - существенный фактор мотивации сотрудников. Учет личностного и общественного факторов и вынуждает принять определенное решение. Подчеркну - "вынуждает". В организации низкого уровня зрелости - психологические факторы определяют успех или неуспех проекта. В качестве примера приведу решение одного сложного вопроса из ITIL. Вопрос возникает в связи с тем, что "Как правило, роли начальника Help Desk (Service Desk) и менеджера инцидентов совмещаются". Естественно, возникает вопрос, а когда же бывает не так? В каких случаях возникает необходимость разделить эти две роли? В моей практике это приходилось делать в трех организациях. Все они имели общее - наличие "Help Desk", точнее говоря "Helpless Desk". Это именно та ситуация, когда это просто "бабушка на телефоне". Однако необходимость изменений потребовала создать новый Help Desk. В начале проекта было решено расширить штаты этого подразделения и назначить нового начальника, молодого и энергичного. Но, было очевидно, что молодость и станет главной причиной трудностей в управлении инцидентами. Было видно, что специалисты просто не воспринимали начальника и найдут различные способы игнорирования. Это было ясно в самом начале проекта, поэтому менеджером процесса управления инцидентами был назначен опытный авторитетный специалист, который воспринимался всеми специалистами как лидер (и формальный и неформальный). 245 Последующее развитие показало правильность этого решения, и было одним из факторов, обеспечивших "легкий старт" проекта. В последующих статьях я продолжу тему психологического фактора в реализации ITIL - проектов. http://real-time-enterprise.ru/technology/it/article/itilpsy.html ITIL - IT Infrastructure Library - это обобщение лучшего международного опыта в области организации и управления информационными технологиями. Библиотека ITIL является собственностью Комитета по вычислительной технике и телекоммуникациям при правительстве Великобритании - OGC ( www.ogc.gov.uk). На сегодняшний день это фактический стандарт, который используется предприятиями и организациями во всем мире. Дополнительная информация: www.itil.co.uk ITIL - Библиотека Инфраструктуры ИТ ITIL (Библиотека Инфраструктуры ИТ) - это наиболее распространенный подход к управлению ИТ как поставщиком услуг. ITIL представляет собой взаимосвязанный набор методов, или лучших практик (best practice), взятых как из опыта общественных и государственных организаций, так и предприятий частного сектора. Основой подхода являются книги Библиотеки ITIL. Развитие и популяризация Библиотеки поддерживаются не только её издателем (OGC) но и независимым профессиональным сообществом (itSMF), а также наличием учебных организаций и квалификационных схем. Кроме того, на рынке достаточно щироко представлены программные продукты для автоматизации описанных в Библиотеке процессов. Доступны также консультационные услуги по внедрению подхода ITIL. Текущая редакция Библиотеки ITIL включает в себя семь книг: Поддержка Услуг (Service Support) Доставка Услуг (Service Delivery) Планирование внедрения Управления Услугами (Planning to Implement Service Management) Управление Приложениями (Application Management) Управление Инфраструктурой ИКТ (ICT Infrastructure Management) Управление Безопасностью (Security Management) Бизнес-перспектива (The Business Perspective) а также "дополнительную" (complementary) книгу - "Управление Конфигурациями ПО" (Software Asset Management). На сегодняшний день книги Библиотеки доступны только на английском, однако предпринимаются шаги к переводу на другие языки, в частности на русский. Издателем Библиотеки ITIL является OGC (The Office of Government Commerce) - британская правительтвенная организация, отвечающая за 246 повышение эффективности работы государственных структур Великобритании, а также за развитие кооперации с компаниями частного сектора. Поскольку публикация Библиотеки проходит под эгидой правительства, ITIL защищена копирайтом, поэтому воспроизведение или публикация её материалов должны быть согласованы с OGC. При этом использование подхода, процессов и практик, описанных в ITIL, не ограничивается. Важным общественным институтом, поддерживающим развитие и популяризацию Библиотеки, является itSMF (IT Service Management Forum) независимый международный форум специалистов управления ИТ-услугами. Эта некоммерческая организация объединяет как частных лиц - профессионалов в области управления ИТ, так и корпоративных членов, в том числе компанийвендоров. Национальные подразделения itSMF действуют на сегодняшний день в 14 странах. В числе глобальных членов Форума (Global members) такие компании, как MicroSoft, SUN, HP и IBM. Существующие квалификационные схемы поддерживаются двумя организациями: ISEB (The Information Systems Examination Board) – подразделением Британского Компьютерного Общества (British Computer Society) – и EXIN - Голландским Экзаменационным Институтом. Действует трехступенчатая сертификация: базовый уровень (Foundation Certificate) уровень практика (Practitioner’s Certificate) уровень менеджера (Manager’s Certificate) Эта схема действует в отношении отдельных специалистов, для организаций возможности получить формальный статус "соответствующей ITIL" нет. Для "доказательства" соответствия ПО рекомендациям ITIL достаточно часто используется статус 'Pink Verify' от компании PinkElephant. Владелец же Библиотеки ITIL - OGC - не предоставляет услуг по проверке соответствия ITIL, предпочитая дождаться выхода схемы сертификации на основе национального государственного стандарта - BS15000 (Standard for IT Service Management), разрабатываемой BSI (British Standards Institution) - Британским Институтом по Стандартизации. Развитие ITIL Библиотека ITIL стала уникальным изданием, так как это один из немногих примеров, когда профессиональные консалтинговые компании поделились основами своего консалтинга и определили наиболее важные вопросы и подходы к их решению, применимые для любых компаний независимо от их масштаба. Тем не менее, библиотека описывает, в первую очередь, на что следует обратить внимание в организации ИТ, то есть, что должно быть улучшено, но не дает прямых ответов как это может быть сделано. В то же время такой интерес, безусловно, очевиден. При этом ответ на вопрос «как» зачастую становится достаточно трудным, во многом в связи с особенностями конкретной ситуации у каждого заказчика и определить общие принципы в применении подхода ITSM 247 становится непросто. Интересно, что опытные консультанты в области ITSM, стараются не следовать напрямую каким либо схемам внедрения ITIL и давать рекомендаций до тех пор, пока не станут понятны первоочередные проблемы, существующие у заказчика. Кстати, это один из советов ITIL – двигаться путем «быстрых побед», то есть путем решения своих наиболее острых задач, и именно это должно ставиться во главу угла, а не внедрение ITSM как таковое. В этом случае достигается наибольшая эффективность от консультационного проекта. В то же время, несколько крупных ИТ-компаний постарались сформулировать определенные принципы в применении ITIL, с учетом своего опыта и разных подходов к его использованию. В этом есть также определенное преимущество, так как заказчики получают возможность понять некоторую генеральную линию в применении ITIL, предлагаемую компаниями, и выбрать элементы подхода, то есть варианты ответа на вопрос о том «как» ITIL мог бы быть применен у них. При этом важно, что многие из этих подходов не противоречат друг другу и их элементы могут быть комбинированы. Фактически ИТ Сервис-менеджмент стал объединением различных подходов, существующих в мире, возникших на основе библиотеки ITIL. Подобные подходы существуют у целого ряда компаний, лидеров мирового ИТ-рынка, среди них HP, Microsoft, IBM, SUN. Интересно, что многие из них – IBM, HP, Sun - не раскрывают детали, во многом, в связи с тем, что это является инструментом консалтинга. Кроме того, не все из них активно продвигают свои идеи и услуги в этой области на российском рынке. Исключением является компания HP, фактически ставшая первой в России, кто в конце 90-х годов стал предлагать проекты на основе ITSM. Методика этой компании называется HP ITSM Reference Model и заслуживает серьезного внимания, особенно для тех, кто хотел бы произвести радикальные преобразования в своих организациях. Компания HP рассматривает процессы, обозначенные в ITIL, группируя их в виде 5-ти блоков – Стратегическое согласование задач бизнеса и ИТ (Business - IT Alignment), Дизайн и управление услугами (Service Design & Management), Разработка и распространение услуг (Service Design & Deployment), Операционные задачи ИТ (Operations Bridge) и Гарантии предоставления услуг (Service Delivery Assurance). При этом первые 4 блока рассматриваются последовательно один за другим как некоторое отражение жизненного цикла работы ИТ-организации, в то время как в центре находится блок Service Delivery Assurance, отвечающий за предоставление ИТ-услуг. Несмотря на данную общую логику, подход HP ITSM Reference Model безусловно допускает начало работы с любого блока в зависимости от особенностей компании. Дальнейшие детали также зависят от индивидуальных задач, стоящих перед организацией. Более подробно этот подход описывался в российской компьютерной прессе и может быть детально представлен сотрудниками компании HP. Примечательно, что среди всех ITSM-подходов, существующих на рынке, наибольшей доступностью для изучения обладает Microsoft Operations 248 Frammework (MOF), достаточно подробно изложенный на открытом сайте компании Microsoft. Этот подход состоит из 3-х моделей – Модели процессов (Process Model), Модели организационных команд (Team Model) и Модели рисков (Risk Model). Первоочередное значение многие компании уделяют Модели процессов, состоящей из 4 квадрантов, включающих в себя Функции управления сервисами (Service Management Function - SMF). Многие из этих Функций в значительном объеме повторяют процессы ITIL, но есть и ряд дополнительных, предложенных Microsoft, исходя из собственного опыта эксплуатации ИТ-инфраструктуры и опыта своих партнеров. Данная модель дает взгляд на работу ИТ-инфраструктуры с точки зрения жизненного цикла ИТ-услуг от момента их создания в рамках Квадранта по управлению изменениями и далее по кругу до момента оптимизации или замены новыми услугами в Квадранте по оптимизации. Интересно, что в частности, в данной модели нашел отражение значительный опыт компании Microsoft по выводу на рынок новых приложений через организацию многоуровневых тестовых испытаний, давая компаниям опыт подготовки и сдачи в эксплуатационную среду новых аппаратно-программных решений. Важно отметить, что опыт, изложенный в настоящее время в рамках MOF, не зависит от конкретных аппаратно-программных платформ, и может быть применен к любым решениям, существующим у заказчиков. В тоже время, MOF активно используется компанией Microsoft как при разработке программного обеспечения в области менеджмента ИТ, так и при разработке эксплуатационной документации на все выпускаемые в настоящее время программные продукты Microsoft. Значительно больше знаний можно получить, если дополнить изучение открытых материалов MOF посещением углубленных курсов, которые в настоящее время уже начинают появляться на российском рынке. Управление в малых ИТ-подразделениях. Эта страничка - попытка дать ответ на вопрос одного "ИТ-шника" (моего хорошего знакомого): "Что за теория такая - ITIL - и зачем мне, работающему с компьютерами профессионально уже -дцать лет, она нужна?". Поскольку должность его - "Начальник отдела управления информационными системами" подразумевает некий элемент менеджмента, ответить коротко: "Это не теория и тебе ни к чему" не получилось. Пришлось разобираться: Чем управляем? "Персоналу шесть душ, локалка на две сотни рабочих мест плюс серверов с десяток, телефония, Интернет-канал...". Наверное, такое понимание сферы своей деятельности и объектов управления присуще большинству ИТ-менеджеров, имеющих в подчинении от двух до десятка работников и отвечающих "за все, что с проводами, кроме кофеварки". Обычно такое описание сферы ответственности устраивает и их руководство - коротко и ясно. Гораздо труднее получить ответ на простой вопрос - 249 "зачем?". Формулировка отдела ИТ обычно столь же проста сколь и бессодержательна: "Чтоб все работало и юзеры не жаловались." Руководство со своей стороны далеко не всегда понимает не только чем заняты все эти "компьютерщики", но и что компании дают сервера, Интернет - вообще все это компьютерное хозяйство кроме разве что ноутбука самого директора. Из-за этого не только затруднено нормальное взаимопонимание между ИТ и руководством компании (например, обсуждение затрат на ИТ упирается в тот же вопрос "зачем?" - а объяснять директору преимущества клиент-серверной модели занятие зачастую неблагодарное), но и фактическая польза для бизнеса от затрат и усилий ИТ-подразделения неизмеряема, неуправляема и, как следствие, низка. Говорить о пользе ИТ, выгоде от вложений в информационную инфраструктуру можно только в том случае, если на выходе есть (точнее, виден) некий продукт, вернее, поскольку речь идет о работе с информацией, услуга. Отдел Информатики как, например, и бухгалтерия предоставляет бизнесу услуги. В случае бухгалтерии это выставление счетов, составление необходимой отчетности, анализ финансовх потоков, а в случае ИТ - использование 1С, возможность сетевой печати или доступ в Интернет. К сожалению, руководству трудно самостоятельно сформулировать, какие конкретно ИТ-услуги нужны бизнесу. В такой ситуации ИТ-менеджер - единственный человек, который может (и заинтересован) "наводить мосты" между работой своего отдела и основной сферой деятельности компании. Построение "списка услуг" поможет в первую очередь ему самому - как для того, чтобы обоснованно "пробивать" финансирование или увеличение штата, так и для более эффективной организации труда в подразделении. Получив благодаря такому списку ответ на вопрос "зачем?", мы можем подругому взглянуть на то, чем же все-таки надо управлять. Люди, провода, "железо" - это необходимые инструменты ИТ-менеджера для предоставления бизнесу услуг. Конечно эти инструменты требуют руководства, обслуживания, замен. Но организовывать надо не работу каждой из этих составляющих по отдельности, а использование их как единого целого. Иными словами, управлять предоставлением услуг. Нужна ли теория? "Управление услугами - звучит заумно и теоретично. Для книжек по менеджменту оно наверно хорошо, только переходить от всем понятого администрирования локальной сети к какой-нибудь 'Услуге сетевого доступа' особого желания нет. В разговорах с руководством можно, конечно, красивыми терминами блеснуть, а вот в реальной работе удобство такого подхода сомнительно." Во-первых, речь не идет о том, что надо уволить сисадмина или забыть про правила создания резервных копий. Во-вторых, список услуг, о котором шла речь выше, не главное и уж точно не первое, что имеет смысл брать на вооружение из предлагаемого подхода. Помнить, что ИТ-отдел работает для предоставления услуг, надо в первую очередь для того, чтобы в каждый момент времени ясно 250 понимать: "зачем мы делаем именно это а не иное". Понимание того, что целью каждой работы, закупки или изменения штатного расписания является польза для бизнеса поможет делать меньше ненужного а необходимое делать лучше. Как же собственно предлагается планировать, осуществлять, контролировать и оценивать результаты каждодневной деятельности ИТ? В общем и целом - так же, как это уже делается в подавляющем большинстве отделов информатики: работы надо структурировать, объединяя их в группы. Правда, принцип организации таких групп может отличаться от принятого в отделе на данный момент. Конечно, работы по обслуживанию кабельных трасс, настройке протоколов и служб, управлению доменной структурой и т.д. никуда не денутся это хорошо структурированная последовательность работ, логично объединенная в упомянутый выше процесс администрирования локальной сети. Но всегда ли ваш сетевик готов ради банальной процедуры (например, замена нерабочего сетевого кабеля) отложить увлекательное и высокоинтеллектуальное занятие вроде тонкой настройки листов доступа на маршрутизаторе? Наверное, нет и скорее всего он прав - отвлекаясь на срочные дела, не требующие особой квалификации, он в итоге принесет компании меньше пользы. Подобные рутинные работы поэтому разумно выделить в отдельную группу и создать "отряд быстрого реагирования" (возможно даже из одного человека), задачей которого будет прием заявок от пользователей, оказание им необходимой помощи и ликвидация различных поломок. В случае серьезных аварий, требующих квалифицированного вмешательства, надо наделить эту "службу скорой помощи" правом срочно привлекать других сотрудников к их ликвидации. Таким образом в процесс устранения поломок могут быть вовлечены различные сотрудники, но при этом есть человек, координирующий работы и отвечающий за результат - стабильную работу пользователей. Основным принципом объединения работ в логически взаимосвязанные последовательности - процессы - предлагается принять наличие у них единой цели. Важно понимать, что при таком подходе мы не учитываем ни существующее распределение работ, ни деление зон ответственности в отделе по технологическому признаку. К достижению цели "любая поломка должна быть ликвидирована в течение часа" могут привлекаться и сисадмин, и ИТ-менеджер, и сторонняя организация. Если мы сможем сформулировать для себя все (или хотя бы основные) цели, в сумме обеспечивающие качественную работу ИТ как поставщика услуг - пол дела сделано. Останется объединить выполняемые работы в группы, каждая из которых ведет к достижению своей цели, и понять, по каким параметрам мы будем оценивать результат каждого такого процесса. Какие цели и как измерять результат? "Похоже, ничего оригинального в этом подходе нет. Судя по тому, что мы предоставлением услуг управлять должны, целями у нас они и будут - нормально предоставленные услуги (без перебоев и с хорошими техническими характеристиками). А уж для оценки результатов параметры известны - 251 скорость обработки SQL-запроса, объем Интернет-трафика, время отклика Вебсервера мерить умеем. Только для каждой услуги процесс строить - не слишком ли неказисто?" Конечно, неказисто, а главное - не нужно. Нормально предоставляемые услуги - это наша глобальная задача. Для ее решения как минимум надо: чинить то что сломалось как можно быстрее, разрешать возникающие проблемы, точно знать, какое ПО и "железо" у нас есть, иметь правила внедрения нового и замен имеющегося. Ради этих целей - общих для всех услуг - и надо выстраивать процессы. Так что управляем мы не самими услугами (каждой по отдельности), а разными аспектами их предоставления: ликвидацией поломок, разрешением проблем, изменениями в инфраструктуре, ее составом и конфигурацией. Конечно, это далеко не полный список. Надо согласовывать с руководством состав и описание услуг, своевременно готовить планы модернизаций, "считать деньги" и своевременно выявлять "узкие места", не забывать о безопасности и быть готовым к авариям. Кроме того, как уже говорилось, остаются и операционные процессы (например, управление ЛВС или администрирование СУБД). Цели у каждого процесса свои - либо непосредственно обеспечивающие должный уровень услуг (например, максимально допустимое время простоя может быть напрямую оговорено в описании услуги) либо "помогающие" другим процессам - точная информация о составе и конфигурации инфраструктуры нужна и при ликвидации поломок и для планирования модернизаций. Но, как уже было сказано, поставить задачу мало - обязательно надо ввести четкие критерии оценки достижения целей. Такие индикаторы успешности работы процессов должны быть понятны для всех участников (то есть не быть чересчур технически сложными), точно соответствовать цели процесса и быть измеряемыми, то есть мы должны понимать, как конкретно получить числовое значение индикатора. Термины "хорошее", "быстрый", "точная" для них недопустимы - нам нужна шкала для измерения, чтобы о любом процессе можно было сказать: "он успешен на 85 процентов". В каждом случае мы сможем таким образом зафиксировать, к какому результату мы стремимся - например, для управления ликвидацией поломок успехом может считаться: "количество поломок, не исправленных за час, не более пяти процентов от всех случившихся." Тогда, получив от нашей "службы скорой помощи" статистику по числу поломок и по времени их ликвидации, мы легко оценим успешность по этому параметру. Скорее всего он будет не единственным индикатором для этого процесса - важны также и среднее время исправления и процент поломок, ликвидированных без привлечения дополнительных сотрудников (самим "отрядом быстрого реагирования"). Рассмотренные вместе, значения этих индикаторов говорят нам о качестве выполнения процесса. Поэтому улучшение качества выполнения процесса - это приближение реальных значений индикаторов успешности к целевым. Для того же, чтобы повысить качество всей нашей работы - качество предоставляемых услуг - надо помимо этого "поднять планку" успешности каждого из процессов. 252 В этом подходе действительно нет ничего оригинального - ориентация на услуги, процессное управление и нацеленность на качество за последние десятилетия стали "общим местом" в менеджменте. Удобство его использования в том, что он содержит готовый набор "подсказок", основаный на опыте управления ИТ в реальных организациях. Управление в малых ИТ-подразделениях. Часть 2. Я уже попытался дать ответ на вторую часть вопроса: "Что за теория такая - ITIL - и зачем она нужна?". Если от многократно повторенных слов вроде "услуга", "процесс", "качество" еще не уснули, а интерес к тому, каково же оно "в деле", поввился, обсудим сперва: Что же все-таки такое этот ИТИЛ? "Набор подсказок - это, конечно, хорошо, но от подхода к управлению желательно системность получить. И что это за организации, которые свой опыт в свободный доступ выложили? И в каком виде это сделано?" К сожалению или, скорее, к счастью ИТИЛ (или если уж по-русски БИИТ Библиотека Инфраструктуры ИТ) особой системностью не отличается. Это не методология, не пошаговая инструкция, что и как надо делать. В первой редакции Библиотека состовла из примерно 40 книг, описывающих разные процессы или аспекты применения этого подхода. Во второй редакции, действующей на данный момент, процессы объединены в группы и по каждой из них выпущена (или вотвот поввится) отдельная книга. Официальный автор - британская правительственная организация OGC (Office of Government Commerce), изначальной задачей которой было помочь гос. структурам в формализации их отношений с подрядчиками - поставщиками ИТуслуг. В Великобритании даже действует официальный стандарт на Управление Услугами (BS 15000), который базируется на ITIL. Хотя формальное авторство принадлежит OGC, в написании участвуют представители и организацийзаказчиков, и поставщиков, и консультантов. В книгах описываются группы процессов (например, Поддержка Услуг - Service Support), объединенные по принципу нахождения на шкале "Технология - Услуги". Ключевыми считаются две группы - Поддержка и Доставка (Delivery) Услуг. Про каждый процесс говорится: какими терминами пользуемся, его цели, входы и выходы, функции и роли, связь с другими процессами, деятельности, индикаторы успешности, методы контроля, затраты и выгоды, возможные сложности и советы по внедрению. Хотя в написании авторы базировались на реальном опыте работы, никакой организационной специфики в этих моделях нет. С одной стороны, в этом огромный плюс - отсутствие привязки к конкретным структурам дает возможность использовать ITIL не только в британских государственных организациях, но и в ИТ-компаниях и подразделениях любой формы собственности по всему миру. С другой стороны, для практического внедренения приходитсв либо использовать какую-либо методологию (то есть 253 платить вендору или консультанту), либо внедрять "по собственному разумению", что требует дополнительных затрат и увеличивает риск неудачи. Как это реализуется на практике? "Были бы деньги на консультантов - у них и спрашивал бы. А риск неудачи есть всегда, так что будем пытаться своим умом доходить. Только с чего начинать-то? И что делать с текущей работой?" Начинать (что вполне естественно) надо с чтения книг Библиотеки. К сожалению, на данный момент переводов на русский нет, а за оригинальные книги придется выложить около 150 долларов за штуку. Альтернативой (во всяком случае, на первом этапе) может быть покупка за 38 долларов "Введения в ITIL" (IT service management - An introduction) издания itSMF (Форума по Управлению Услугами ИТ, объединяющего теоретиков и практиков ITIL). Кстати, уже идут работы по переводу этой книжки на русский. При наличии хотя бы небольшого бюджета также очень желательно сходить на 2-3дневные курсы по основам ITIL книжки книжками, а общение с практиками дорогого стоит. И конечно очень многое можно почерпнуть в Чети - полная картина при только ее использовании вряд ли сложится, но полезностей можно найти немало. Когда знания начнут переполнвть - пора начинать ими делиться. Может быть самым важным во внедрении ITIL явлвется изменение психологии сотрудников ИТ, их переориентация с "работы с железками" на "обслуживание Клиента". На это нельзя жалеть ни времени ни усилий. До тех пор, пока слова "услуга", "процесс" и "качество" не станут в ИТ-отделе привычными и незаменимыми, никакав формализация процедур ничего не даст. Важно, чтобы сотрудники воспринимали "предоставление услуг" не как дополнительную работу, а как способ оптимизации (в том числе и в их интересах) всей существующей деятельности. Измениться должна также и оценка качества выполнения задач как отдела в целом, так и каждого отдельного работника. Надо стараться меньше говорить о том что "сеть ни разу за год не легла" (хотя это конечно существенно), и чаще спрашивать себя "довольны ли пользователи"? Текущая работа действительно никуда не денется. Более того, пока она нормально не налажена переходить скажем к уровню Доставки Услуг бессмысленно - доставлять нечего. Так что начинать (если это еще не сделано) надо с технического (Technical) и операционного (Operations) уровней. Естественно в ITIL по ним тоже есть описания процессов, но на этих уровнях, в отличие от Поддержки и Доставки Услуг, достаточно опытный, технически грамотный и нормально образованный ИТ-менеджер может построить "правильные" процессы сам, руководствуясь профессиональными знаниями и интуицией. Надо только не забывать о "трех китах" - пользоваться процессным подходом, вводить (и применять) критерии оценки качества и в каждый момент оценивать, зачем нужна (и какую пользу приносит бизнесу) конкретная железка, канал данных, программа, резервная копия. 254 Если о наличии бэкапов голова уже не болит, а сбой ПК стал явлением редким - настала пора ИТ-отделу выстраивать взаимоотношения с "внешним миром". И в превую очередь с теми, без кого его функционирование невозможно с внутреними и сторонними поставщиками внешних для ИТ услуг. Во многих реализациях ITIL Управление Окружением (Environmenal Management) считается фундаментом функционирования всей информационной системы. Действительно электрика, вентилвция, кондиционирование, обычно не входвщие в сферу ответственности ИТ-отдела, влияют на его работу принципиально. Поэтому пока нет спокойствия и уверенности в этих вопросах - двигаться дальше опасно. Когда решена и эта задача, можно наконец переходить к реализации первой функции из ITIL-овского блока Поддержки Услуг - создать в отделе Центр Обслуживания. Это еще не реализация какого-то процесса (в Service Support описаны пять процессов и одна функция - function - Service Desk), но в поддержке услуг - один из ключевых элементов. Центр Обслуживания (иногда его называют Help Desk) должен стать единой точкой контакта отдела с "внешним миром". Таким образом решаются две задачи. Во-первых, это упростит жизнь пользователям - всегда будет к кому обратиться и человек "на телефоне" не сошлется на то, что ему "не до мелочей". Во-вторых, появлвется возможность фиксировать, документировать и измерять поток работ, выполняемый отделом ИТ. Этим будет сделан первый шаг во внедрении блока процессов Поддержки Услуг. Что теперь и куда дальше? "Создать единую точку доступа - хорошая мысль, но ведь человека выделить придется. А потом еще под каждый процесс - отдельного? А где отдача? И как собственно процессы внедрять?" Трудно однозначно сказать, приведет ли применение ITIL к увеличению потребности в ресурсах (в том числе кадровых) или нет. Это зависит как от уровня зрелости ИТ-отдела до начала внедрения (если он низок, то оптимизация работ может даже привести к их высвобождению) так и от "глубины" внедрения. Но даже если дополнительные ресурсы на каком-то этапе потребуются, не надо забывать о повышении общего качества работы ИТ. Это именно тот козырь, с помощью которого можно "выбивать" деньги у руководства. К сожалению, пока не измеряется качество услуг или хотя бы удовлетворенность пользователей (а это нереально без Центра Обслуживания), цифр и фактов для аргументации нет. Поэтому на этапе создания Центра Обслуживания придется либо обойтись внутреними ресурсами (могли появиться в процессе оптимизации операционного уровня) либо разработать и представить руководству план по реструктуризации отдела (например, берем дополнительного - дешевого - человека на ЦО, оптимизируем работу, через девять месвцев одного из двоих сисадминов сокращаем). Но в любом случае нужен среднесрочный (примерно на год-полтора) план внедрения. "Кадры решают все". Продумывав план "ITIL-изации" отдела надо в первую очередь оценить, кто из сотрудников более склонен к аналитической работе, кого можно "допускать до пользователей", а кому вы можете доверить работу, 255 требующую максимальной педантичности. При этом надо ориентироваться не столько на профессиональные навыки сколько на человеческие качества. Исходя именно из этой оценки выбирайте владельцев процессов. Они будут вместе с вами "выстраивать" процессы, а потом контролировать и улучшать их работу. В выполнение конкретных процедур будут вовлечены и другие сотрудники (в том числе и владельцы других процессов), но отвечать должен он один. При этом ничто не мешает при распределении ответственности и полномочий совмещать разные функции и роли в одной должностной инструкции. Один и тот же сотрудник может быть владельцем одного или нескольких процессов и исполнителем - в других. Даже в отделе из двух человек в принципе возможно "поделить" между собой базовые процессы ITIL - причем с реальной пользой для дела. Если же ИТ-отдел состоит хотя бы из четырех человек распределение ответственности за процессы пройдет как по маслу. Для того, чтобы все эти управленческие телодвижения приносили удовлетворение вам и были оценены руководством, нужны "быстрые победы". На этапе оптимизации операционного уровня это регламентация плановых работ (а соответственно повышение их "прозрачности" и четкое планирование). В результате ИТ-менеджеру уже не будут сниться кошмары на тему "А что если PDC ляжет?!" - теперь у него есть регламентный бэкап, процедура восстановления и ответственный сотрудник. В создании Центра Обслуживания главная выгода появление точки сбора информации обо всех событиях, происходящих в ИТ. Как результат через два - три месяца вы будете иметь статистику по обращениям пользователей, с которой уже можно идти к руководству с предложением о путях снижения их количества. Это уже те самые "цифры и факты", которые помогают ИТ в разговоре с Бизнесом. С этого и начинается выстраивание отношений "Поставщик - Заказчик". Кажется, теперь можно было бы и о внедрении процессов поговорить. Но если до сих пор рассказывать об ITIL можно было на "кухонном" уровне, тут уже требуется строгость определений и формулировок, знание терминологии и т.д. Поэтому настал момент погулять по Сети, а лучше всего сразу заказать книги Библиотеки. Не забывайте также о ценности вербального общения - курсы и семинары бесценный источник знаний. Успехов в ITIL-изации! Процессы. Определения. Раз ИТИЛ - процессный подход, надо наверно четко описать, а лучше определить - что же такое процесс. Можно, конечно, заглянуть в толковый словарь и прочесть там что-то вроде: последовательная смена состояний, каких-л. явлений, ход развития чего-л.; совокупность последовательных действий для достижения какого-л. результата, напр. производственный п.; Это в общем то и так "интуитивно ясно". Однако из п.2 мы видим, что помимо "процессов вообще" есть например производственный процесс, так что 256 надо идти глубже, чтобы понять специфику именно ИТИЛовских процессов и получить "рабочее" определение. В нем, во-первых, должно быть собрано специфичное для ИТИЛ содержание (в частности, нацеленность на услуги и качество) и во-вторых, дано внутренее строение и внешние связи. Итак, начнем изыскания. Наиболее общее определение дает нам ГОСТ Р ИСО 9000 - 2001: "Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы. В ITIL - точнее в книге "Service support" ("Поддержка услуг") приводится следующее определение: "A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal." ("Связанный набор действий, видов деятельности, изменений и т.д., выполняемый агентами с целью удовлетворения потребности или достижения цели.") Здесь добавилась важная для понимания процессов составляющая - агенты. Кроме того, вместо выходов (про которые забывать не надо, поскольку при проектировании процесса их придется выделять и специфицировать) упомянуто, что у процесса есть некая цель. Вот еще одно (CobiT): "Процесс - это действие, направленное на достижение результата, которое может корректироваться при его выполнении и которое сосредоточенно на достижении конечного результата при оптимальном использовании ресурсов." Отсюда мы можем взять две вещи: процесс должен управляться (корректироваться) и его надо строить оптимально. Можно наверно найте полезные зерна и в других источниках, но большинство так или иначе повторяют уже сказанное. Например в PMBOK 2000 edition читаем: "series of actions bringing about a result". Так что перейдем к тому, из чего он состоит. Предлагается такое деление процесса на составляющие: подпроцесс (subprocess) - является частью процесса, но не теряет его свойств деятельность (activity) - набор действий выполняемых одной ролью действие (action) - атомарная единица процесса Кроме того, надо не забыть о том, что процессы надо как-то описывать. Для этого существует процедура - описание логически связанных деятельностей и их исполнителей (для большей детализации и удобства обычно составляют набор Рабочих инструкций, которые определяют, как следует выполнять виды работ, входящие в состав процедур). И, наконец, помимо ролей для каждого процесса важно определить владельца (именно он отвечает за него, имеет право его менять и т.д.) и менеджера (он осуществляет "оперативное управление"). Конечно это тоже роли, но роли специфические и очень важные. Они должны быть четко определены для каждого процесса, даже если выполнять их будет один человек. Постараемся теперь ничего не потерять но и без лишнего обойтись: Процесс - это цикличный и воспроизводимый набор логически связанных деятельностей, направленных на достижение общих целей, описанных 257 процедурами и исполняемых менеджером процесса и другими ролями (агентами) с использованием выделенных ресурсов, управляемый владельцем для оптимизации по затратам с использованием измеряемых характеристик (метрик), который преобразует определенные входы в контролируемые по качеству выходы. (Process - a cyclic and reproduced set of logicaly related activities connected by general targets, described by procedures and performed by process manager and other roles (agents) using allocated resources, controlled by the owner to be optimal in efforts and costs using measured indicators (metrics), which convert specified inputs into the quality controlled outputs.) Возможно, результат получился громоздким, но зато теперь мы знаем, что такое процесс "по-ИТИЛовски". Методика внедрения процессов. "Определение внушительное. Только из него все равно не ясно, как процессы эти создавать, в смысле выстраивать." Попробуем кратко прикинуть, в каком порядке и что именно надо делать, чтобы "построить" ИТИЛовский процесс. Итак: Вначале необходимо для процесса определить цели (с ключевыми факторами успеха для первой стадии), входы-выходы, ресурсы, политики. Затем составить список процедур (для них - входы-выходы, цель, контроль) Далее - шаблоны информационных ресурсов (к примеру - что должно быть в любом trouble ticket), первая версия справочников (к примеру типы service call, статусы инцедентов, etc). Наконец - подробное (пусть черновое, но чтоб по ним работать можно) описание процедур и базовое описание ролей. Все, можно "вводить в эксплуатацию" и заниматься: корректировкой написанного уточнением процедур и ролей написанием рабочих инструкций. Последовательность внедрения ITIL-процессов. "Отлично, можно приступать. Начинать наверно надо с Процесса Управления Услугами - он ведь ключевой." Действительно Управление Услугами - в своем роде "центральное звено" для всех ИТИЛовских процессов. В создающейся "с нуля" организации или подразделении начинать именно с него может быть правильно. Но для уже функционирующей структуры это не лучший путь. Перед тем, как ответить себе на вопрос "за какой процесс браться в первую очередь", надо понять "что имеем", то есть оценить степень зрелости как всего ИТ в целом, так и групп процессов управления ИТ. Конечно, для оценки группы процессов придется рассматривать каждый, но для того, чтобы решить, с какого процесса начинать, нужна интегральная оценка зрелости групп. 258 Методик оценки зрелости существует немало и здесь не место обсуждать их и сравнивать. Предположим, что выбрана некая методика, проведена оценка и на выходе у нас для каждого процесса - балл от 0 до 5. Теперь надо рассмотреть оценки по группам (Operational, Support, Delivery). Если в группе Операционных процессов есть хоть один с баллом ниже тройки - забудьте временно про "отношения Бизнеса и ИТ" и прочие высокие слова - подготовьте себе тылы (в данном контексте под Операционными процессами имеется ввиду все то, что называют Technical, Operations, а также Environmenal Management). Однако не надо забывать о следующей цели - уровне Поддержки Услуг. На нем есть бесценная функция - Центр Обслуживания, которая может помочь и на этапе приведения в порядок операционного уровня. Итак, первый шаг при таком раскладе - создание Центра Обслуживания и ""доведение до ума группы операционных процессов (внутри нее - Technical => Operations => Environmenal, подробнее - зависит от используемых технологий). Говоря о группе процессов Поддержки Услуг, можно предложить такой порядок: сперва Управление Инцидентами и Проблемами (вместе с "причесыванием" Центра Обслуживания), затем Изменения, потом Конфигурации и Релизы. Опять же надо помнить о следующей цели - Доставке Услуг - и параллельно с процессами уровня Поддержки хотя бы контурно обозначить рамки и содержание Процесса Управления Услугами. Заработав минимум по три балла процессам поддержки, можно довести до ума Управление Услугами и ... сделать шаг в сторону от доставки услуг, задумавшись над тем откуда они (услуги) берутся. Конечно если в вашей организации набор сервисов крайне стабилен и с его изменением вполне справляется операционный уровень - можете не волноваться. Если же время от времени присутствует некий development - самое время заняться именно им. Так что следующий шаг Production Management. Если вы добрались до этой стадии - наверно сами разберетесь, в каком порядке внедрять Availability, Capacity и Continuity Management. А Управление Финансами советую оставить "на сладкое" - с него плавно перейдете на Business IT alignment, займете место CIO... Все вышесказанное относится в первую очередь к тем ИТ-структурам, в которых идея жить по-ИТИЛовски идет "изнутри". Если же к вам "сверху" пришло указание <<внедрить SLA за три месяца>> - деваться некуда, порядок внедрения будет совсем другой. Кроме того, это только общие принципы, описывать же порядок для всех вариантов результата оценки зрелости - за отдельные деньги. А тонкостей может всплыть немало. Например, если процесс Service Continuity Management получил ноль баллов - бросьте все и готовьтесь к пожарунаводнению-землетрясению. Так что изучайте внимательно best practice. И не забывайте - ITIL <=> IMHO 259 SLA в практических примерах. В первую очередь надо предостеречь от бездумного применения нижепривеженных шаблонов и примеров к конкретной ИТ-организации. Без знания хотя бы основ теории и/или без учета специфики вы рискуете загубить благое начинание. Однако для лучшего понимания существа вопроса всегда полезно ознакомиться с чужим опытом. Все-таки ITIL - это именно "лучшие практики"... Итак, в Сети доступны: Ссылки на статьи, отчеты, рекоммендации на nextslm.org Процесс создания SLA на примере - Blueprint for an Exchange Service Level Agreement SLA в Центрах Обработки Данных от SUN (.pdf) Active Directory SLA для кампусной сети HelpDesk SLA в учебном заведении Пример сводной таблицы по финансовому SLA (.pdf) Крайне полезно почитать "Красную Книгу" Introducing IBM Tivoli Service Level Advisor И снова nextslm.org (теперь шаблоны) - Customer Satisfaction Survey, Internal SLA, Short-Form Internal SLA Помимо предоставления периодических отчетов, образцы которых приведены выше, очень важно дать потребителю ИТ-услуги возможность видеть состояние сервиса он-лайн. Об этом - в статье Рика Стурма (Rick Sturm). Кроме того, еще несколько примеров отчетов - в присоединенных файлах. Файлы по теме: Пример SLA для третьего уровня поддержки приложений SLA между Отделом ИТ и бизнес-подразделениями (источник techrepublic.com) SLA, отчеты, чеклисты (от Рика Леопольди) Ссылки по теме: NextSLM.org The SLM Community (Articles, SLA Templates, Software Vendors, Links, Books, Q & A). Amazon.co.uk The Complete Guide to Preparing and Implementing SLAs (at Amazon, UK). TechRepublic.com IT Manager's Guide to Business Strategy + CD. http://www.itsmportal.ru/articles/itil/ Определение ITIL. Information Technology Infrastructure Library (ITIL) - это набор руководств, разработанных Отделом Правительственной Торговли Великобритании (United Kingdom`s Office Of Government Commerce, OGC). Каждое руководство представляет собой набор книг, в которых описывается интегрированная методология управления ИТ услугами, основанная на передовом опыте и 260 использующая процессный подход. На сегодняшний день данные книги являются единственным, исчерпывающим, общедоступным руководством для управления услугами ИТ (IT Service Management), не основанном на частных патентах. ITIL была основана во второй половине 1980-х годов. Первоначально ITIL предназначалась для улучшения качества управления ИТ обслуживанием (IT Service Management) в правительстве Великобритании, однако, ITIL применима для всех организаций (частных или государственных; больших или малых; централизованных или распределённых). Сегодня ITIL представляет собой больше, чем просто книги. Она породила целую индустрию, которая включает в себя: Обучение Сертификацию Консалтинг Программное обеспечение Торговую Ассоциацию (itSMF) Открытый стандарт. Отделом Правительственной Торговли в Великобритании (OGC) не была написана вся библиотека целиком. Для помощи в написании были задействованы многие компании, в число которых входила компания Pink Elephant. Редакторские отделы, состоявшие из промышленных экспертов, определяли рамки этих книг. Таким образом, книги были написаны одной организацией, а качество написания проверено другими. OGC осуществлял функции редактора, а также проверял процессы, описанные в книгах. При этом было обеспечилено соответствие описанных процессов требованиям стандарта ISO9001 для того, чтобы ITIL поддерживала подход к качеству, принятый ISO. Результатом явились книги, которые: 1. Не основаны на частных стандартах, потому что конечные результаты не базируются на точке зрения одного лица или одной организации на конкретный процесс. 2. Содержат передовой опыт, потому что обобщают практику работы многих ИТ-профессионалов. 3. Написаны в соответствии со стандартом качества, потому что OGC обеспечил соответствие процессов требованиям ISO. 4. Являются общедоступными благодаря наличию Королевского Авторского Права. Основные принципы библиотеки. Во многих компаниях ИТ-услуги обычно предоставляются внутренним подразделением и связаны с ИТ-инфраструктурой (IT Infrastructure) предприятия. Термин «ИТ-инфраструктура» используется для описания оборудования, программного обеспечения, процедур, коммуникаций, связанных с компьютерной техникой, документирования и навыков, необходимых для поддержки ИТ- 261 обслуживания. Все эти компоненты и их использование должны быть управляемы — отсюда появляется термин управление ИТ-инфраструктурой предприятия. В целом ИТ-услуги и управление ИТ-инфраструктурой называют Управлением ИТобслуживанием (IT Service Management). Однако, в общем случае для описания этой функции также используются термины Предоставление ИТ Услуг (IT Service Delivery) и Управление Системой ИТ (IT System Management). Область действия Библиотеки. Первые книги ITIL были закончены к 1995 году. Они описывают функции Управления ИТ услугами (IT Service Management) и содержат ссылки на другие книги. Каждая книга может быть прочитана отдельно, так же как и описанные функции могут использоваться в организациях независимо по одной. Однако, наибольшие преимущества можно получить при условии рассмотрения IT Service Management как набора взаимосвязанных функций. Величина преимуществ, полученных от изучения всей Библиотеки больше, чем в случае рассмотрения отдельных книг. Завершив выпуск первых книг, OGC инициировал создание руководства, являющегося дополнением к книгам, детально описывающим функции. Это позволило расширить область действия Библиотеки, а также выпустить руководство по применению идей первого набора книг в конкретных условиях. Книги Библиотеки. Пять наборов книг связаны с обеспечением ИТ услугами и управлением ИТ инфраструктурой. Три набора — с управлением поддержкой инфраструктуры. Эти наборы описаны ниже. Наборы IT Service Provision и IT Infrastructure Management. Две книги – Сервисная Поддержка (Service Support) и Предоставление Услуги (Service Delivery) – описывают ключевые процессы, которые должна иметь у себя ИТ организация для предоставления качественного обслуживания её клиентам. Сервисная Поддержка (Service Support) содержит обзор функций и операционных процессов. Предоставление Услуги (Service Delivery) - тактических процессов. Более детально эти книги описаны ниже: Сервисная Поддержка (Service Support). Эта книга описывает взаимосвязанные компоненты, обеспечивающие стабильность и гибкость ИТ обслуживания. Она связана с идентификацией и регистрацией элементов конфигурации ИТ, инцидентов, проблем и изменений. Описываются следующие функции и процессы: Служба поддержки (Service Desk) (Функция). Service Desk является функцией, а не процессом. Целью Service Desk является создание единой точки взаимодействия между пользователями и подразделением ИТ обслуживания компании. В книге представлено руководство по созданию и эксплуатации Service Desk, как эффективного канала взаимодействия между пользователями и ИТ поставщиком. 262 Управление Инцидентами (Incident Management). Процесс Управления Инцидентами (Incident Management) служит для максимально быстрого восстановления работы, а также для минимизации воздействия неблагоприятных последствий на бизнес компании. Это гарантирует поддержку максимально возможного уровня качества обслуживания и доступности услуг. Управление Проблемами (Problem Management). Процесс Управления Проблемами (Problem Management) позволяет диагностировать причины, лежащие в основе инцидентов, выявленных посредством Service Desk. Это упорядочивает процедуру исправления ошибок в ИТ инфраструктуре и предотвращает появление потенциальных проблем. Управление Изменениями (Change Management). Процесс Управления Изменениями (Change Management) гарантирует использование стандартизованных методов и процедур для эффективной и быстрой обработки всех изменений. Это позволяет минимизировать влияние инцидентов, связанных с изменениями, на качество услуг. Как следствие, целью Управления Изменениями является улучшение ежедневной работы предприятия. Управление Релизами (Release Management). Грамотное планирование и управление ресурсами является неотъемлемой частью успешного оформления и доставки релизов пользователю. Управление Релизами (Release Management) использует целостный подход к изменению ИТ услуг и гарантирует, что все аспекты релиза (технический или не технический) будут рассмотрены в комплексе. Управление Конфигурацией (Configuration Management). Управление Конфигурацией (Configuration Management) предоставляет логическую модель инфраструктуры или услуги при помощи идентификации, отслеживания, поддержки и проверки существующих элементов конфигурации. Предоставление Услуги (Service Delivery). Эта книга описывает процессы, необходимые для предоставления качественных, экономически эффективных ИТ услуг. Она описывает следующие процессы: Управление Доступностью (Availability Management). Цель Управления Доступностью (Availability Management) состоит в оптимизации нагрузки на ИТ инфраструктуру, её обслуживание и поддерживающий её департамент. Результатом этого является экономически эффективный, стабильный уровень доступности услуг, который позволяет компании достигать своих целей. Управление Нагрузкой (Capacity Management). Управление Нагрузкой (Capacity Management) позволяет управлять ресурсами компании во время кризиса, а также заранее предсказать необходимость привлечения дополнительных ресурсов. В книге даётся описание процедур, необходимых для планирования, внедрения и запуска этого процесса. Управление Непрерывностью предоставления Услуг (IT Service Continuity Management). Управление Непрерывностью предоставления Услуг (IT Service Continuity Management) описывает управление способностью организации продолжать предоставлять ранее оговоренный уровень ИТ услуг в случае 263 нарушения нормальной работоспособности компании. При этом охватываются все ситуации от выхода из строя системы или приложения, до полного разрушения здания компании. Управление Уровнем Обслуживания (Service Level Management). Целью Управления Уровнем Обслуживания (Service Level Management) является поддержка и улучшение качества ИТ обслуживания. Это происходит на протяжении всего цикла подписания соглашений, мониторинга и отчётности по результатам предоставленных ИТ услуг. Управление Уровнем Обслуживания также влечет действия по искоренению услуг низкого качества. Это позволяет установить более тесные отношения между поставщиком ИТ и их клиентами. Финансовое Управление для ИТ Услуг (Financial Management for IT Services). Финансовое Управление для ИТ Услуг (Financial Management for IT Services) связано с денежными ресурсами компании. Оно помогает предприятию планировать и достигать своих бизнес целей. Внутри ИТ организации этот процесс выражается тремя областями: Бюджетирование, ИТ учёт и Платежи. Другие книги ITIL. Другие наборы книг представляют собой важные руководства для выработки необходимых навыков обеспечения эффективной работы ключевых функций. Некоторые из наборов связаны с адаптацией ITIL и опыта для конкретных условий. Набор Управляющего (Manager`s Set). Эти книги предназначены для высшего управляющего ИТ звена, ответственного за несколько функциональных областей. Хотя они также могут быть интересны для всего ИТ отдела компании. Они содержат информацию о том, каким образом организовать штат (функции и роли), как успешно планировать и управлять взаимоотношениями с потребителями и поставщиками. Этот набор включает книги: Взаимодействие с клиентом (Customer Liaison) Организация ИТ обслуживания (IT Service Organization) Управление основными средствами (Managing Facilities Management) Управление взаимодействием с поставщиками (Managing Supplier Relationships) Планирование и контроль для ИТ услуг (Planning and Control For IT Services) Управление качеством ИТ услуг (Quality Management For IT Services) Инструменты поддержки ИТ инфраструктуры (IT Infrastructure Support Tools) Инструменты предоставления Услуг (Service Delivery Tools) Стандарты управления данными (Data Management Standards) Управление данными (Data Management) Управление безопасностью (Security Management) Набор поддержки ПО (Software Support Set). Этот набор из двух книг описывает различные аспекты Управления ИТ Услугами, которые связаны с, и оказывают влияние на разработчиков ПО. Вот эти книги: 264 Поддержка жизненного цикла ПО (Software Lifecycle Support) Тестирование ИТ услуг для эксплуатации (Testing An IT Service For Operational Use) Набор книг по обслуживанию компьютеров (Computer Operations Set). Этот набор ориентирован на менеджера эксплуатации компьютеров и на тот персонал, который задействован в обслуживании крупных компьютерных установок, в частности мэйнфреймов и центральных серверных комнат. Вот эти книги: Установка компьютеров и запуск в эксплуатацию (Computer Installation And Acceptance) Управление обслуживанием компьютеров (Computer Operations Management) Управление услугами третьих фирм (Third Party And Single Source Management) Пакетная обработка (Unattended Operating) Набор, описывающий окружение (Environmental Set). Этот набор представляет собой руководство, описывающее аспекты окружения, необходимые для реализации планирования, внедрения и управления ИТ инфраструктурой, что очень важно для предоставления качественного ИТ обслуживания. Это: 1. Набор стратегий по отношению к окружению (Environmental Strategy Set). Единственная книга, Стратегия Кабельной Инфраструктуры, объясняет необходимость стратегического подхода к установке и поддержке кабельной инфраструктуры внутри новых и существующих зданий. 2. Набор Управления Окружением (Environment Management Set). Восемь книг, связанных с проблемами обеспечения и управления процессом размещения в здании и получением услуг для поддержки ИТ инфраструктуры. Эти книги включают: Спецификация размещения (Accomodation Specification); Стандарты окружения для оборудования здания (Environmental Standards For Equipment Accommodation); Пожарная безопасность в ИТ установках (Fire Precautions In IT Installations); Управление электрическими помехами (Management Of Electrical Interference); Безопасные источники энергии (Secure Power Supplies); Спецификация и управление кабельной инфраструктурой (Specification And Management Of Cable Infrastructure); Поддержка качественного окружения для ИТ (Maintaining A Quality Environment For IT); Управление акустическим шумом (Management Of Acoustic Noise). 3. Набор офисного окружения (Office Environment Set). Этот набор включает четыре книги, которые содержат руководство по созданию поддерживаемой рабочей среды в офисе для потребителей ИТ услуг. Вот эти книги: 265 Человеческие факторы в офисном окружении (Human Factors In The Office Environment); Офисный дизайн и планировка и ИТ (Office Design And Planning And IT); Офисная рабочая среда и ИТ (Office Working Environment And IT); Поддержка качества рабочей среды для ИТ пользователей (Managing A Quality Working Environment For IT Users). Набор перспектив бизнеса (Business Perspective Set). Эта серия из трёх книг рассматривает те вопросы ИТ, с которыми может быть придётся иметь дело бизнес управляющему. Вот эти книги: 1. Во время радикальных изменений (In Times Of Radical Change). Эта книга рассматривает вопросы быстрых и радикальных перемен в бизнесе и их влияние на ИТ. Целью книги является предоставление помощи в контроле ИТ и интегрировании её в бизнес компании. 2. Выживание при изменениях ИТ инфраструктуры (Surviving IT Infrastructure Transitions). Изменения в ИТ инфраструктуре могут повлиять на способ управления бизнесом или на непрерывность бизнес операций. Очень важным является то, чтобы бизнес-управляющие были осведомлены об этих изменениях и обеспечивалось выполнение шагов, предохраняющих бизнес от неблагоприятных сторонних эффектов. Эта книга написана для того, чтобы помочь бизнес- и ИТ-управляющим избавиться от их худших опасений относительно изменений в ИТ. 3. Понимание и улучшение (Understanding And Improving). Это руководство развивает у бизнес-менеджеров проницательность и осведомлённость, необходимые для того, чтобы было доступно нужное качество ИТ поддержки для бизнес-процессов компании. Книга описывает обязанности и возможности, позволяющие бизнес управляющему улучшить одну из ключевых услуг, позволяющую повысить эффективность бизнеса компании. Философия ITIL. Существование ITIL заложило начало росту новой индустрии. Данная индустрия берёт своё начало от реализации проекта OGC по поддержке продуктов, необходимых для облегчения адаптации функций ITIL, а также от совместной работы OGC с Экзаменационной Комиссией по Информационным Системам (Information Systems Examination Board, ISEB) в 1990 по разработке первой сертификации, основанной на ITIL. За исключением экзаменов – где ощущается, что подход, не основанный на частных стандартах, был важным для достижения доверия и широкого признания, - всяческим образом поощрялась разработка продуктов поддержки в частном секторе на коммерческой и конкурентной основе. Продукты поддержки включают в себя: Программные инструменты Книги Обучение Консультирование itSMF 266 Заказчики имеют возможность выбирать среди целого ряда конкурирующих коммерческих продуктов. Однако, тот факт, что данные книги и экзамены не основаны на частных стандартах, позволяет этим продуктам широко развиваться. Основную выгоду представляет собой независимость ITIL. Сертификация. Формальную сертификацию, основанную на ITIL, предлагают три компании: 1. Исследовательский Институт Науки об Информации (Examination Institute For Information Science, EXIN), расположенный в Нидерландах, предлагает сертификацию в Великобритании, Европе и по всему миру на различных языках. 2. Экзаменационная Комиссия по Информационным Системам (Information Systems Examination Board, ISEB), работает в Великобритании и Британском Содружестве, осуществляет сертификацию только на английском языке. 3. Колледж прикладных искусств и технологий (Loyalist Colledge Of Applied Arts And Technology), работает в Бельвилле, Онтарио, Канада. Колледж организует экзамены по ITIL на основе материалов, разработанных EXIN в США и Канаде. Предоставляет независимое наблюдение и административное обслуживание. Все три организации не являются частными и не получают прибыли. Организации выполняют подготовку и поддержку в проведении экзаменов, не организовывая обучающих курсов. Они непосредственно разрабатывают ITIL экзамены, веря в то, что наилучшим является единый и широкий подход, адаптированный к различным местным условиям. В результате все три организации используют одни и те же экзаменационные материалы. Кроме того есть аккредитованные компании, которые предоставляют подготовительные курсы к сдаче экзаменов. Среди них и компания Pink Elephant. EXIN, ISEB и Loyalist предоставляют три типа сертификации: 1. Основной Сертификат в области Управления ИТ Услугами (Foundation Certificate In IT Service Management). Обладатель данного сертификата имеет базовые знания принципов ITIL: терминология, функция Service Desk, 10 важнейших процессов и их взаимоотношение и взаимодействие с другими процессами (в том числе и с бизнес процессами). Данный сертификат выдаётся после достижения участником уровня 65% правильных ответов (экзамен проводится в форме последовательности вопросов с заданными вариантами ответов). 2. Сертификат практика в области Управления ИТ Услугами (Practitioner Certificate In IT Service Management). Сертификат практика существует для каждого процесса. Он удостоверяет, что его владелец обладает глубокими знаниями в области применения процессов ITIL и может управлять ими и внедрять их внутри организации. Необходимым требованием является наличие трёх или четырехлетнего опыта 267 управления на среднем уровне в ИТ плюс наличие Основного Сертификата в области Управления ИТ Услугами. Данный сертификат выдаётся после достижения участником уровня 65% правильных ответов (экзамен проводится в форме последовательности вопросов с заданными вариантами ответов). 3. Сертификат Управляющего в области Управления ИТ Услугами (Manager's Certificate In IT Service Management). Обладатель данного сертификата должен иметь общее представление об организации Service Desk, знать 10 ключевых дисциплин в области управления ИТ услугами и их взаимодействий и взаимоотношений. Данный сертификат утверждает, что владелец способен руководить ИТ департаментом в целом, как в момент его создания, так и в условиях уже стабильно работающей компании. Необходимым требованием является наличие трёх или четырехлетнего опыта управления и/или консультирования плюс наличие Основного Сертификата в области Управления ИТ Услугами. Данный сертификат выдаётся после достижения участником следующих критериев: Достижение уровня правильных ответов 50% в области оценки навыков управления Достижение уровня правильных ответов 50% при сдаче экзамена на знания Поддержки Услуг (Service Support) и достижение уровня правильных ответов 50% при сдаче экзамена на знания Предоставления Услуг (Service Delivery). Все экзамены составлены в расчёте на возможность их сдачи после прохождения обучающих курсов. Экзамены проводятся регулярно в нескольких странах и на нескольких языках во всём мире. Кому следует читать ITIL. Главным образом ITIL ориентирована на людей, управляющих предоставлением качественных ИТ услуг. Однако, весь ИТ персонал найдёт полезными данные книги. Они помогут им увеличить понимание контекста их работы. ИТ директорам необходимо быть в курсе тех тем, которые описаны в книгах. Это поможет им быть уверенными в том, что каждый член их команды в данной организации осведомлён о деталях выполняемой работы. Для понимания того, кому необходимо прочесть те или иные книги, необходимо обратиться к введению, где определена целевая аудитория этих книг. Эти книги представляют особую важность для бизнес-персонала компании (как управляющих, так и ежедневных потребителей или конечных пользователей), задействованных в налаживании взаимоотношений с их поставщиками ИТ услуг. Разработчики ПО, поддерживающий персонал и тестеры должны быть в курсе требований Управления ИТ Услугами, чтобы они могли понимать их взаимодействие с менеджерами ИТ услуг, а также гарантировать, что все 268 необходимые требования изначально включены в новые или обновлённые продукты и услуги. Данное руководство будет полезным для компаний любого размера, как в частном, так и в общественном секторе. В книгах осознанно описываются функции и роли обслуживающего персонала, а не должности и рабочие группы. В общем, данные книги имеют отношение к любой организации, зависящей от ИТ обслуживания. Выгоды от применения методологии ITIL. ITIL предлагает системный, профессиональный подход к управлению снабжением ИТ услугами. Применение данного руководства позволит Вам добиться следующих преимуществ: Увеличение степени удовлетворённости потребителей ИТ услуг Уменьшение риска того, что нужды бизнеса не будут удовлетворены Уменьшение затрат при разработке процедур и методов внутри организации Лучшее взаимодействие и обмен информацией между пользователями и ИТ персоналом Стандарты и руководства для ИТ персонала Максимальная продуктивность и лучшее использование навыков и опыта Качественный подход к ИТ услугам Имеются преимущества и для пользователей: Уверенность в том, что услуги предоставляются в соответствии с документированными процедурами и могут быть подвергнуты проверке Возможность положиться на ИТ услуги позволяет пользователю сосредоточиться на достижении бизнес целей компании Определение контактных точек для запросов или консультирования, связанных с изменением требований Понимание того, какая информация необходима для обоснования затрат на ИТ обслуживание и для предоставления обратной связи при контроле соглашений уровня обслуживания. ITIL подчёркивает важность предоставления ИТ услуг для удовлетворения бизнес требований, причем экономически эффективным способом. Многие ИТ организации пытаются становиться более ориентированными на потребителя для демонстрации их вклада в дело компании. ITIL может помочь в достижении этого. Организациям выгодно адаптировать руководство для удовлетворения своих потребностей. Однако, их следует предостеречь от игнорирования действий без должного обсуждения, потому что Управление ИТ Услугами представляет собой набор интегрированных и согласованных функций. Вероятнее всего организации получат большее преимущество (в рамках долгосрочного процесса) от внедрения всех функций, чем от некоторых из них. В равной степени важно и то, что вступление в клуб ITIL позволяет компании получить постоянный и всеобъемлющий подход к управлению 269 услугами, начиная от программных продуктов и заканчивая консалтингом, обучением и квалификацией. Наряду с этим общий подход позволяет получить распространённый язык ITIL определений, который в свою очередь позволяет осуществлять более эффективное взаимодействие между ИТ и поставщиками. Часто Задаваемые Вопросы. Вопрос: Доступны ли эти книги в электронном формате? Ответ: Данные книги доступны на CD диске, а в будущем будут выложены по адресу www.clicktso.com. Вопрос: Какая разница между ITIL и ISO9001? Ответ: ISO9001 определяет процесс Обеспечения Качества, для которого существенным является вопрос: Выполняете ли Вы действительно то, о чём Вы говорили? В то время как ITIL определяет, что Вам необходимо делать в первую очередь. Вопрос: Является ли информация из ранее выпущенных книг ITIL всё ещё актуальной в свете изменений в технологии? Ответ: Передовой опыт ITIL является постоянно обновляемым источником. Это делается для гарантии того, что предлагаемые рекомендации являются согласованными с моделью процессов ITIL, а также для отслеживания изменений в технологиях и бизнес практике. Тем не менее, передовой опыт в более ранних версиях является таким же актуальным, каким он был в момент написания. Вопрос: Работает ли ITIL в условиях е-бизнес окружения? Ответ: Да. Процессы, которые участвуют в реализации приложения для ебизнеса, нисколько не отличаются от любых других приложений. Целый ряд компаний использует методику ITIL для увеличения стабильности в их ИТ инфраструктуре, для поддержки е-бизнеса. Вопрос: Как я могу приобрести книги ITIL? Ответ: Книги могут быть приобретены через специализированного реселлера on-line по адресу www.ITILbooks.com. Некоторые книги также доступны на www.amazon.com. Вопрос: Могут ли обучающие курсы для подготовки к сдаче экзаменов предоставляться непосредственно на месте? Ответ: В дополнение к общедоступному расписанию обучающих курсов у Pink Elephant, организация также может заказать курсы, читаемые непосредственно в компании. Это позволяет получить значительную экономию, а также получить курсы, подготовленные на заказ. Экзамены также могут быть сданы на месте. Вопрос: Почему существует три экзаменационные комиссии? Ответ: ISEB предлагает ITIL экзамены для Великобритании и стран Британского содружества. Так как принципы ITIL являются глобальными, EXIN (расположенный в Нидерландах) предлагает экзамены для всего мира на различных языках. Колледж прикладных искусств и технологий (Loyality Colledge Of Applied Arts And Technology), в Бельвилле, Онтарио организует ITIL экзамены, 270 основанные на материалах EXIN в США и Канаде, а также предоставляет независимое наблюдение и услуги по сопровождению. Все три комиссии предоставляют абсолютно одинаковые экзамены. http://www.softintegro.ru/products/itil/htm/pe_itil_story.htm 271 Список литературы 1. Управленческий учет. Современный подход. //Электронный вестник "ERP в России" - Interface Ltd, http://www.erp.boom.ru/general/Articles/Articles_2.htm; 2. Карпачев И. О стилях и классах (реальность и мифология компьютерных систем управления предприятием). - Interface Ltd, http://www.interface.ru 3. Inmon W. H. Building the Data Warehouse. New York: John Wiley & Sons, Inc. 4. E. F. Codd, S.B.Codd. Providing OLAP. On-line Analytical Processing to UserAnalists: An IT Mandate. C. T. Salley, E. F. Codd & Associates, 1993 5. R. Kimball. The Data Warehouse Toolkit. Practical Techniques for Building Dimansional Data Warehouses. 6. XLNT Software. Handling XML Documents Using Traditional Databases, Aug. 2002; www.surfnet.nl/innovatie/surfworks/xml/xml-databases.pdf. 7. P.J. Marron, G. Lausen. On Processing XML in LDAP. Proc. 27th Int’l Conf. Very Large Databases, ACM Press, 2001. 8. L. Ahmedi, G. Lausen. Ontology-Based Querying of Linked XML Documents. Proc. Semantic Web Workshop, 11th World Wide Web Conf., 2002; http://semanticweb2002.aifb.uni-karlsruhe.de/proceedings/research/ahmedi.pdf. 9. K.L.E. Law. XML on LDAP Network Database. Proc. IEEE Canadian Conf. Electrical and Computer Eng., IEEE Press, 2000. 10. Isode. Comparative Performance Benchmarking of Isode M-Vault R10.1, white paper, Oct. 2003, www.isode.com/whitepapers/m-vault-benchmarking.htm. 11. E.J. Thornton, D.P. Mundy, D.W. Chadwick. A Comparative Performance Analysis of Seven LDAP Directories. Proc. Conf. Terena Networking, 2003; www.terena.nl/conferences/tnc2003/programme/papers/p1d1.pdf. 12. N. Klasen. Directory Services for Linux, in Comparison with Novell NDS and Microsoft Active Directory, master’s thesis, Dept. computer Science, RWTH Aachen Univ., 2001. 13. Е.Крылов. ITIL, процессы, проекты, и психоанализ. 14. Росс Картер (Ross Carter), Джон Кобб (John Cobb), Wadeware LLC, Лана Эрхарт (Lana Earhart), Энтони Ноблетт (Anthony Noblett), Socair Solutions Руководство по планированию и решению вопросов соответствия нормативным требованиям. 15. Мирон Старченко, Эрнст Долгий IT Manager #5(11)/2003
