• Удаление обновлений

    • Рубрика: System Center,Новое
    • Автор: Алексей Тараненко
    • Дата: Sunday 26 Apr 2009

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

    Пример:

    Update1 (KB 100001) – обновляет файл targed.dll с версии 5.25 до версии 5.77. Файл targed.dll (5.25) будет сохранен в %systemdrive%\Windows\$NTUninstallKB100001$\

    Update2 (KB100002) – обновляет файл targed.dll (5.77) до targed.dll (6.0), оригинальный файл сохраняется в архиве. Также это обновление обновляет файл bad.dll с версии 0.1 до версии .02

    Update3 (KB100003) – обновляет файл targed.dll с версии 6.0 до версии 6.5.

    Допустим, мы выяснили, что обновленный файл bad.dll (0.2) вызывает ошибки в работе бизнес-приложения. При этом bad.dll(0.1) таких ошибок не вызывал. Мы принимаем решение об откате обновления Update2, чтобы восстановить нормальную работу. Но при этом удаление обновления update2 вызовет замену рабочего файла targed.dll (6.5) на архивную версию targed.dll(5.77). Соответственно мы потеряем изменения сделанные обновлением Update3. Естественно такая ситуация может вызвать трудно диагностируемые сбои в работе системы.

    Подробнее в статье «Removing Windows software updates in the wrong order may cause the operating system to stop functioning»

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

    · удаление обновления Update3;

    · удаление обновления Update2;

    · установка обновления Update3.

    Для того чтобы узнать какие файлы исправляет обновление, или какие версии обновлений оно заменяет, обратитесь к описанию обновления на сайте Microsoft

    Например: http://www.microsoft.com/technet/security/Bulletin/MS08-065.mspx

    System Center Configuration Manager не может самостоятельно удалять обновления. Для удаления обновлений вы можете воспользоваться одним из вариантов:

    1)ручное удаление обновление с каждого компьютера, через оснастку «Установка и удаление программ» – имеет смысл, если проблемных компьютеров один-два;

    clip_image002

    Рисунок 1 Установка и удаление программ – действия на обновлениями

    2)удаление обновления через WSUS. Для этого в консоли администрирования WSUS найдите необходимое обновление и одобрите его для удаления

    clip_image004

    Рисунок 2 Одобрение для удаления обновления во WSUS

    3)Использование программы установки обновлений. Для удаления обновления запустите %systemdrive%\Windows\$NTUninstallKBnumber$\spuninst\spuninst.exe

    Подробнее: http://support.microsoft.com/default.aspx/kb/832475/ru

    Если у вас проблемное обновление установлено на несколько компьютеров, то проблем с его поиском и удалением быть не должно. Как быть если обновление установлено на несколько десятков или даже сотен компьютеров? Использовать SCCM для удаления обновления.

    Для начала давайте определимся со списком компьютеров, на которых установлено это обновление. Список компьютеров с установленным обновлением вы можете получить через отчет: Software Updates – A. Compliance – Compliance 9 – Computers in a specific compliance state for an update

    Отчет это очень красиво, но он не поможет нам удалить обновления. Для удаления обновления создадим коллекцию UninstallUpdate. На странице правил членства в коллекции выбираем «Query rule». Задаем имя правила и нажимаем кнопку «Edit Query Statement».

    clip_image005

    Рисунок 3 Создание запроса членства компьютеров

    В появившемся окне выбираем «Attribute class – Add\Remove programs» и «Attribute – Display Name»

    clip_image006

    Рисунок 4 Указание, что выборка производится из установленных программ

    Теперь нажимаем кнопку «Value».

    clip_image007

    Рисунок 5 Задание удаляемой программы

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

    clip_image008

    Рисунок 6 Список установленных программ в сайте

    Несколько нажатий кнопок OK и мы получаем сформированный критерий членства в коллекции.

    clip_image009

    Рисунок 7 Критерий членства в коллекции

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

    clip_image010

    Рисунок 8 Итоговое окно

    После создания коллекции – распространяем на нее через Software Distribution скрипт, который удалит наши обновления. В данном случае скриптом будет обычный bat-файл, в который будет последовательно удалять обновления с помощью spuninst.exe.

    Помните, что правильную последовательность удаления обновлений вы должны задать самостоятельно!

    Алексей Тараненко

    MCP/MCTS: SCCM 2007

    altaranenco@gmail.com

    • Управление обновлениями в System Center Configuration Manager 2007 (Часть 3)

      • Рубрика: System Center,Новое
      • Автор: Алексей Тараненко
      • Дата: Sunday 19 Apr 2009

      Green_Atom В предыдущих статья мы поговорили об общем подходе к управлению обновлениями и о механизме взаимодействия Windows Software Update Services (WSUS) и System Center Configuration Manager (SCCM). Пришла пора рассказать о том, «как и какие кнопки нажимать» в Configuration Manager  для распространения обновлений.

      • Шифрование информации на мобильных компьютерах

        • Рубрика: Security,Новое
        • Автор: Владимир Безмалый
        • Дата: Thursday 16 Apr 2009

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

         

        Краткий обзор технологии BitLocker

        BitLocker – важная новая технология защиты информации, появившаяся в операционной системе Windows Vista, обеспечивающая шифрование данных на компьютере. С помощью этой технологии вы сможете зашифровать весь жесткий диск и обеспечить его защиту в случае, если ноутбук попадет в руки злоумышленника. Наиболее эффективно применение данной технологии для портативных компьютеров, оборудованных модулем Trusted Platform Module (TPM) версии 1.2 и выше, так как в таком случае вы получите расширенную поддержку и проверку целостности всей системы при загрузке. Кроме того, в случае если компьютер не оборудован TPM, вы сможете использовать в качестве ключа внешний USB-накопитель в качестве устройства для хранения ключа доступа.

        Планирование развертывания

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

        1. Оценить готовность аппаратных средств к BitLocker;
        2. Определить возможность развертывания;
        3. Выбрать конфигурацию BitLocker;
        4. Создать план восстановления данных в случае чрезвычайной ситуации.

        Постараемся рассмотреть эти вопросы подробнее.

        Оцените готовность аппаратных средств к применению BitLocker

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

        • Операционная система Windows Vista Enterprise или Windows Vista Ultimate;
        • Если вы хотите использовать BitLocker вместе с модулем TPM, материнские платы компьютеров должны быть TPM-совместимы, т.е. оборудованы модулями TPM, соответствующими спецификации Trusted Computing Group TPM v.1.2 или более новыми;
        • Жесткий диск должен содержать два раздела с файловой системой NTFS. Раздел, на который BitLocker будет записывать загрузочные компоненты, должен быть первым и содержать не менее 1,5 Гбайт чистого пространства. Кроме того, это должен быть активный раздел.

        Для того чтобы узнать, удовлетворяют ли ваши компьютеры указанным требованиям, можно использовать сценарии Windows Management Instrumentation (WMI) или PowerShell. Однако гораздо предпочтительнее задействовать Microsoft Systems Management Server (SMS) или аналогичные утилиты от независимых производителей.

        Аппаратные требования BitLocker

        Фактически аппаратные требования для использования BitLocker аналогичны тем требованиям, которые предъявляются к компьютерам для установки Windows Vista.

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

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

        Стоит учесть, что для некоторых компьютеров, уже оборудованных ТРМ версии 1.2 может потребоваться обновление BIOS. Как правило, это в первую очередь актуально для компьютеров, выпущенных до 1 января 2007 года.

        Стоит обратить внимание на то, что некоторые BIOS могут загружать систему с USB-дисков. Если вы хотите использовать BitLocker, то эту возможность нужно отключить. Жесткий диск должен быть первым устройством в списке загрузки.

        Каждый компьютер, на котором будет использоваться BitLocker, должен содержать два раздела. Один – для операционной системы и данных, а второй, поменьше, используется только когда компьютер загружен, или для обновлений операционной системы. Оба раздела должны использовать файловую систему NTFS, при этом Microsoft рекомендует, чтобы загрузочный раздел (меньший) содержал не менее 1,5 Гбайт свободного пространства.

        Пользователи Windows Vista Ultimate могут использовать BitLocker Drive Preparation Tool для создания раздела (чтобы использовать BitLocker). Этот инструмент описан в статье Microsoft Knowledge Base номер 930063 «Description of the BitLocker Drive Preparation Tool» (http://support.microsoft.com/kb/930063). Microsoft не рекомендует вручную создавать или изменять размеры разделов, в соответствии с требованиямя BitLocker, хотя в моей практике пришлось создавать разделы именно вручную при помощи программы fdisk из операционной системы Windows 9x.

        Вы можете использовать чистую установку Windows Vista (ведь создание разделов – это составная часть процедуры установки) или задействовать Drive Preparation Tool.

        Trusted Platform Module

        Понимание предназначения этого аппаратного обеспечения является важнейшей частью настройки BitLocker. Для того чтобы больше узнать о технологии TPM и о самой группе Trusted Computing Group, следует прочесть статью Trusted Platform Module (TPM) Specifications https://www.trustedcomputinggroup.org/specs/TPM.

        Доверенный платформенный модуль, так дословно переводится название ТРМ, – это микросхема, установленная на материнской плате, предназначенная в первую очередь для хранения ключей шифрования.

        Фактически компьютеры, на которых установлен ТРМ, создают ключи шифрования таким образом, что они могут быть расшифрованы только с помощью ТРМ. Этот процесс часто называется «сокрытием» (wrapping) или «привязкой» (binding) ключа, что помогает защитить ключ от компрометации. В каждом модуле ТРМ есть так называемый главный ключ (master key), или основной ключ (Storage Root Key, SRK), который никогда не будет доступен другому компоненту системы и который всегда хранится в ТРМ.

        Кроме того, компьютеры, оснащенные ТРМ, также обладают возможностью создавать ключи, которые будут не только зашифрованы, но и привязаны к определенной системной конфигурации. То есть ключи могут быть расшифрованы только в том случае, если платформа, на которой их пытаются расшифровать, будет полностью совпадать с той, на которой эти ключи создавались. Данный процесс называется «запечатыванием» ключа в модуле ТРМ. Т.е. используя такую технологию и BitLocker Drive Encription, можно сделать так, чтобы ваши данные были разблокированы только в том случае, если они будут считываться с компьютера с подходящей аппаратно-программной конфигурацией.

        Стоит также отметить, что, так как модуль ТРМ не зависит от операционной системы и имеет собственное программное обеспечение, он фактически защищен от возможных ошибок операционной системы.

        Системные требования для установки BitLocker

        Windows Vista поставляется в нескольких редакциях, однако только Enterprise и Ultimate поддерживают технологию BitLocker. Вместе с тем стоит помнить, что Microsoft включает средство обновления Windows Anytime Upgrade, описанное в оперативной подсказке к Windows Vista. Например, вы можете обновить Windows Vista Business Edition до Windows Vista Ultimate Edition с помощью средства Anytime Upgrade. Однако в некоторых случаях вам потребуется повторная установка, например, превращение 32-разрядной версии в 64-разрядную потребует повторной установки 64-разрядной версии Windows Vista.

        Развертывание Windows Vista

        Программное руководство Solution Accelerator for Business Desktop Deployment http://go.microsoft.com/fwlink/?LinkId=91187 обеспечит всесторонний набор руководств и инструментов для внедрения Windows Vista на предприятии. Если вы планируете развертывание Windows Vista, помните, что BitLocker не может быть установлен и настроен удаленно, так как ТРМ не может быть инициализирован удаленно. А кроме того, может потребоваться обновление системы BIOS для полного удовлетворения требованиям установки BitLocker.

        Поскольку BitLocker недоступен пока вы не установите Windows Vista, вы должны решить, хотите ли вы обновлять компьютеры с Windows XP до Windows Vista или предпочтете чистую установку новой операционной системы. Для установки BitLocker нужно разметить жесткий диск особым образом (эти требования описаны в Windows BitLocker Drive Encryption Step-by-Step Guide http://go.microsoft.com/fwlink/?LinkId=83223), и если вы планируете обновить существующие операционные системы Windows XP, то должны запланировать изменение логической структуры жестких дисков компьютеров.

        Вместе с тем инструментальные средства Windows Vista Business Desktop Deployment (BDD) поддерживают автоматическое развертывание BitLocker при некоторых обстоятельствах. В Lite Touch Installation Guide http://go.microsoft.com/fwlink/?LinkId=78607 описано развертывание BitLocker как части операционной системы.

        Определите возможность развертывания BitLocker

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

        • Какие компьютеры в вашей организации нуждаются в защите?
        • Нужно ли защищать все ваши мобильные и настольные компьютеры?
        • Какие данные в вашей организации нуждаются в криптографической защите?

        Какие компьютеры нуждаются в защите?

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

        Windows Vista и BitLocker необходимо устанавливать на компьютеры, которые подвергаются наибольшему риску. Это такие компьютеры, как:

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

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

        Какие данные нуждаются в защите с помощью шифрования?

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

        • Конфиденциальная информация, защищаемая законом, включая финансовую, банковскую, кредитную информацию, а также стратегические планы предприятия;
        • Личные данные служащих, уволенных служащих или клиентов (информация, отнесенная к категории персональных данных);
        • Исходные тексты программного обеспечения, базы данных и другая интеллектуальная собственность;
        • Лицензионные материалы, принадлежащие деловым партнерам или клиентам.

        Выбор конфигурации BitLocker

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

        • BitLocker с TPM;
        • BitLocker с TPM и PIN-кодом;
        • BitLocker с ТРМ и USB устройством;
        • BitLocker без ТРМ (с USB устройством).

        Таблица 1. Конфигурация BitLocker

        tabl

        BitLocker с режимом TPM (без PIN-кода).

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

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

        Внедрение BitLocker с TPM

        Внедрение данной технологии потребует выполнения следующих действий:

        • создание перечня компьютеров в организации и оборудованных ТРМ-модулями;
        • описание цикла обновления (замены) аппаратных средств;
        • определение, существуют ли в организации компьютеры, требующие автоматического запуска, ведь BitLocker с TPM, в отличие от BitLocker с TPM и PIN-кодом, BitLocker с ТРМ и USB устройством, BitLocker без ТРМ (с USB-устройством), позволяет автоматический запуск, остальные режимы требуют физического присутствия пользователя;
        • описание процедур замены жесткого диска, ремонта и списания для защищенных ТРМ-систем, при условии, что зашифрованный с помощью BitLocker диск не может использоваться в качестве срочной замены.

        BitLocker c TPM и PIN-кодом

        BitLocker c TPM и PIN-кодом является наиболее защищенным, так как использует мультифакторную аутентификацию и по существу является последней линией обороны в случае кражи компьютера. А, кроме того, позволяет предотвратить нападения, возможные в случае загрузки системы и до появления окна регистрации. На стадии планирования необходимо изучить, способны ли ваши пользователи запомнить дополнительный PIN-код.

        Внедрение BitLocker с TPM и PIN-кодом

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

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

        BitLocker с USB-устройством

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

        Внедрение BitLocker с USB-устройством

        Если же вы все же планируете использовать BitLocker с USB-ключом, то предусмотрите следующие шаги:

        • проверьте компьютеры, на которых собираетесь использовать BitLocker с USB-ключом, чтобы убедиться в том, что они могут распознать USB-ключ во время загрузки;
        • создайте план перемещения данных и приложений с этих компьютеров на компьютеры с поддержкой ТРМ, в случае обновления аппаратного обеспечения.

        BitLocker с ТРМ и USB-устройством

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

        Внедрение BitLocker с ТРМ и USB-устройством

        Внедрение подобного режима потребует от вас рассмотрения вышеизложенных шагов для обоих названных режимов.

        Восстановление данных

        Следует помнить, что шифрование BitLocker является достаточно устойчивым и не имеет никаких «люков». Т.е. нельзя возвратить данные, зашифрованные BitLocker, если не знать пароля восстановления. Это резко усиливает важность планирования процесса восстановления. Стоит помнить, что если у вас нет пароля восстановления, вы не сможете вернуть ваши данные.

        Существуют следующие методики хранения пароля восстановления:

        • Хранение пароля в распечатанном на бумаге виде;
        • Хранение пароля на сменных носителях;
        • Хранение пароля на сетевом носителе;
        • Хранение пароля в Active Directory.

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

        Active Directory

        Microsoft рекомендует планировать и разворачивать каталог паролей восстановления BitLocker с использованием Active Directory (AD). Данный метод восстановления имеет следующие преимущества:

        • Процесс хранения автоматизирован и не требует вовлечения пользователя;
        • Информация, необходимая для восстановления, не может быть утеряна или изменена пользователем;
        • AD обеспечивает централизованное управление и хранение информации для восстановления;
        • Информация для восстановления защищена вместе с другими данными AD.

        Вместе с тем, использование AD для хранения паролей восстановления BitLocker выдвигает новые требования:

        • Организация должна иметь устойчивую, хорошо управляемую инфраструктуру AD;
        • AD на базе Windows Server 2003 должна быть расширена для включения атрибутов BitLocker. Подробнее об этом рассказано в статье Extending Your Active Directory Schema in Windows Server 2003 R2;
        • Необходимо иметь политику безопасности для обеспечения безопасного хранения паролей восстановления в AD.

        Печать пароля восстановления (сохранение его в текстовом файле)

        Данный процесс, несмотря на его простоту, имеет важные преимущества:

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

        Наряду с этим имеется целый ряд недостатков:

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

        Сохранение пароля восстановления на USB-устройстве

        Данный метод имеет следующие преимущества:

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

        Однако данный способ хранения имеет и недостатки:

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

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

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

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

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

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

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

         

        Владимир Безмалый (Vladimir_Bezmaly@ec.bmsconsulting.com)

        http://osp.ru/win2000/2008/03/5184328/

        • Восстановление контроллера домена Active Directory в Windows Server 2008 (Часть 2)

          • Рубрика: Windows,Новое
          • Автор: Илья Рудь
          • Дата: Thursday 16 Apr 2009

          Stop

          Два и более контроллеров домена. Продолжаю тему восстановления контроллера домена Active Directory в Windows Server 2008. Контроллеров домена должно быть несколько, это золотое правило, которому необходимо следовать во всех средних и крупных организациях. Принцип восстановления при наличии нескольких контроллеров существенно меняется. Давайте попробуем понять почему. Представим, что вы имеете два контроллера домена с именами DC1 и DC2(это контроллеры одного домена). Оба будут иметь идентичную базу данных Active Directory, и если вы измените ее на одном, она автоматически обновится на другом, это процесс репликации.

          • Наши друзья

            • Рубрика: Новое
            • Автор: Алексей Тараненко
            • Дата: Wednesday 15 Apr 2009

            Хотим порекомендовать вам замечательный блог по продуктам виртуализации VMware

            Все о виртуализации от VMware

            VMware VI Wiki

            • Версия Схемы Active Directory

              • Рубрика: Windows,Новое
              • Автор: Илья Рудь
              • Дата: Tuesday 14 Apr 2009

              adТрудно недооценить важность «Схемы Active Directory»  для сетей, построенных на базе доменной среды Active Directory. Это основа технологии «AD» и очень важно правильно понимать принципы ее функционирования. Большинство системных администраторов не уделяют схеме должного внимания по причине того, что иметь дело с ней приходится достаточно редко. В данной статье я расскажу, что такое версия схемы, для чего нам необходимо ее знать и самое главное как посмотреть текущую версию. Прежде всего, пару слов о самой схеме, каждый объект, созданный в Active Directory, будь то пользователь или компьютер, имеет определенные параметры, называемые атрибутами. Самым простым примером может служить атрибут «Фамилия» у объекта пользователь. Схема определяет, какие объекты мы можем создавать в Active Directory, и какие атрибуты они будут иметь.

              Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно – на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

              Процесс обновления схемы выполнялся до установки первого контроллера Windows Server 2008 и собственно сама процедура установки нового контроллера, могла и не выполняться. Если вы только начинаете работать с какой-то организацией Active Directory и не знаете, какие действия осуществлялись до вашего прихода, вам для понимания полноты структуры, будет нужно знать, на каком уровне работает Схема текущей организации.

              Возможные версии схемы:

              13 – Windows 2000 Server
              30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
              31 – Windows Server 2003 R2
              44 – Windows Server 2008 RTM

              Даже если все контроллеры в вашей организации работают на Windows Server 2003 R2, а версия схемы показывает «44» не стоит удивляться, это говорит о том, что уже было осуществлено обновление схемы до уровня Windows Server 2008 RTM, но сам контроллер по какой-то причине устанавливать не стали.

              Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

              “dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

              Естественно в части «dc=domainname,dc=local» вы должны подставить имя собственного домена. (Пример: dc=microsoft,dc=com)

              Результатом ввода команды является получение атрибута «ObjectVersion», который и будет являться номером версии схемы:

              image

              Рис. 1 Получение версии схемы через утилиту «DSQuery».

              Второй способ более длинный и подразумевает использование оснастки «ADSIEdit.msc». Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

              "CN=Schema,CN=Configuration,DC=domain,DC=local"

              И найти значение атрибута "objectVersion".

              image

              Рис.2 Получение версии схемы через оснастку «ADSIEdit.msc».

              Зная версию схему, вы всегда можете с уверенностью сказать нужно ли схему обновлять и если нужно то, до какого уровня.

              Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть.

              Понять была ли изме
              нена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

              4397    – Exchange Server 2000 RTM
              4406    – Exchange Server 2000 With Service Pack 3
              6870    – Exchange Server 2003 RTM
              6936    – Exchange Server 2003 With Service Pack 3
              10628  – Exchange Server 2007
              11116  – Exchange 2007 With Service Pack 1

              Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

              Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

              "dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

              image

              Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

              Если после ввода данной команды возвращен ответ, говорящий об отсутствии атрибута «rangeUpper» можно сделать вывод о том, что схема изменена не была.

              Процесс обновления схемы является очень важным моментом для каждой организации Active Directory, поэтому следует избегать лишних, неоправданных действий. Понимая сути атрибутов «objectVersion» и «rangeUpper» дает специалисту преимущество при работе с Active Directory в незнакомой организации, а также является вспомогательным инструментом при решении проблем.

              MCT\MCSE

              Рудь Илья

              me@rudilya.ru

              • Виртуальные машины и сети

                • Рубрика: Virtualization,Новое
                • Автор: Александр Косивченко
                • Дата: Monday 13 Apr 2009

                vn-4Для грамотного управления виртуальной инфраструктурой необходимо иметь представление о том, как организуется сетевое взаимодействие виртуальных машин между собой, с хостовой ОС (parent partition в терминологии MS), и с самой локальной сетью. В этой статье я постараюсь объяснить в меру своих возможностей тонкости работы виртуальных машин с сетью. Тем, кто уже работал с другими платформами виртуализации (VMWare, Virtual Server, etc.) все, о чем я буду писать, скорее всего, уже известно, тем не менее, на уровне терминологии вполне возможны некие различия.

                • Управление обновлениями в System Center Configuration Manager 2007 (Часть 2)

                  • Рубрика: System Center,Новое
                  • Автор: Алексей Тараненко
                  • Дата: Monday 13 Apr 2009

                  AlienAqua windows update В первой части статьи я постарался рассказать о процессе управления обновлениями. Пора переходить к практике. В это статье я постараюсь описать механизм  взаимодействия Windows Software Update Services и Configuration Manager 2007.

                  Для работы с обновлениями корпорация Microosft предлагает бесплатное решение Windows Software Update Services (WSUS). На момент написания статьи последней актуальной версией был WSUS 3 SP1.

                  WSUS полностью самодостаточное решение, которое может удовлетворить потребности большинства организаций. Помимо прочего WSUS поддерживает иерархические отношений, таким образом можно централизованно управлять обновлениями, как в главном офисе, так и на филиалах.
                  Развертывание и использование WSUS на предприятии очень хорошо описано и в официальной документации? и во многих статьях в интернете, поэтому я не буду заострять на нем внимание, а сразу же перейду к рассмотрению взаимодействия WSUS и Software Update в System Center Configuration Manager (SCCM).

                  Подробнее о WSUS можно узнать:

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

                  Для работы с обновлениями в SCCM нам необходимо:

                  • • WSUS сервер, собственно обновления с сайта Microsoft Update закачивает именно он;
                    • Software Update Point – роль Configuration Manager’а;
                    • свободное дисковое пространство под обновления (в зависимости от количества обновляемых продуктов).

                  Теперь о каждом пункте поподробнее.

                  WSUS сервер – отвечает за синхронизацию обновлений в вашей локальной базе с базой на серверах Microsoft Updates. Кроме этого именно с сервером WSUS клиенты сверяют необходимый список обновлений.
                  Software Update Point  – роль SCCM, отвечающая за то, какие именно обновления будут загружены с сайтов Microsoft, за передачу обновлений на клиенты и их запуск на установку.
                  Дисковое пространство – Microsoft рекомендует использовать как минимум 20Гб том для обновлений. Размер тома будет очень сильно зависеть от количества обновляемых продуктов. Так, обновления безопасности Windows  XP, Vista, Server 2003, Server 2008 (All x32)  занимают у меня порядка 4Гб. Однако SCCM дублирует все обновления, закаченные WSUS. Таким образом, нам нужно резервировать  двухкратное место на диске. Файлы обновлений будут храниться как в базе WSUS, так и в базе SCCM.

                  Основная ошибка людей, которые только начинают работать с обновлениями через SCCM, это попытка использования консоли администрирования WSUS для каких либо действий. Главное что следует запомнить: либо мы используем для установки обновлений WSUS и тогда любые действия по управлению обновлениями мы осуществляем через консоль WSUS и соответственно напрочь забываем о существовании SCCM, либо мы используем SCCM, и тогда консоль администрирования WSUS после установки мы не трогаем вообще никогда.

                  Общие моменты мы вроде бы прояснили. Давайте рассмотрим два самых распространенных сценария:
                  1) у нас никогда не стояло никакой системы обновлений, мы решили установить SCCM;
                  2) у нас успешно использовался WSUS, но мы хотим расширить его функционал за счет SCCM.

                  Сценарий 1 – чистая установка

                  Воспользуйтесь пошаговым руководством по установке WSUS и установите базовый сервер WSUS. При этом Microsoft рекомендует не проводить настройку свежеустановленного WSUS сервера – поскольку его настройки все равно будут затерты настройками из SCCM. Однако, я все предпочитают провести первоначальную синхронизацию WSUS с серверами Microsoft. Но только синхронизацию! Таким образом, мы можем удостовериться, что установка WSUS прошла успешно, что настройки связи не препятствуют работе механизма обновлений. Следует отметить, что если в вашей организации применяется прокси-сервер производства не Microsoft (например Squid), то при определенных сценариях, у вас могут возникнут проблемы с аутентификацией WSUS-сервера на вашем прокси-сервере. Во WSUS такую проблему можно решить, установкой галочки «Разрешить обычную проверку подлинности (пароль передается открытым текстом)». В SCCM произвести такую аутентификацию невозможно, поэтому вам придется изменить настройки прокси-сервера так, чтобы он пропускал запросы от сервера WSUS+SUP SCCM без аутентификации.

                  В SQUID это можно сделать, внеся в конфигурационный файл следующую запись:

                  acl wsus scr ip_adress_wsus_server

                  http_access allow wsus

                  Очень важно! Не одобряйте для установки обновления, ни настраивайте групповую политику, не предпринимайте никаких действий по настройке WSUS окружения, кроме установки сервера и первоначальной синхронизации. Иначе вы  рискуете получить нерабочее решение, ошибки в работе которого будет очень сложно отследить. SCCM для настройки использует локальную политику компьютеров, настраиваемую агентом SCCM автоматически.  Поэтому все упоминания о WSUS из групповой политики (Group Policy) необходимо удалить.

                  Сценарий 2 – модернизация уже работающего WSUS сервера

                  Если у вас уже существует WSUS инфраструктура, и вы просто решили ее расширить за счет SCCM, то выполните следующие действия:

                  • • снимите все выставленные вами одобрения для обновлений;
                    • удалите из групповой политики все настройки WSUS.

                  Если вы используете иерархическую структуру WSUS, и возможности центрального сервера будут расширены за счет установки Configuration Manager, убедитесь что все зависимые сервера WSUS, переведены из режима «реплики» в режим  «синхронизации с Microsoft Update». Иначе после снятия одобрений на центральном сервере, эти настройки будут переданы на подчиненные сервера.

                  Теперь оба наших сценария приведены к общему знаменателю – у нас есть рабочий, не настроенный сервер WSUS. Пора расширить его возможности за счет установки Software Update Point SCCM.

                  Установка Software Update Point

                  Запустите консоль SCCM. Выберите:
                  Site Management – Site Code – Site Settings – Site Systems – New Server или Server-New Role
                  в зависимости от того, установлен WSUS сервер на сервер SCCM или находится на отдельном сервере.

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

                  Введите короткое и FQDN имя сервера. Если установка производится на отдельный сервер, и при этом учетная запись сервера SCCM не внесена на WSUS-сервере в группу локальных администраторов, то укажите учетную запись для установки «Use another account for install this site system».

                  capture_04132009_161414 Рисунок 1 Выбор сервера для установки роли

                  Указываем для установки роль “Software update point

                  capture_04132009_161425 Рисунок 2 Выбор роли Software Update Point (SUP)

                  Задаем используемые порты. Должны быть выбраны порты,  указанные при установке WSUS сервера.

                  capture_04132009_161529 Рисунок 3 Используемые порты WSUS

                  Выбираем иерархию. Поскольку наш сервер, высший в локальной иерархии, – указываем синхронизацию с серверами Microsoft. Так же указываем, будут ли наши клиенты посылать оповещения на WSUS сервер. Я обычно ставлю пересылку всех событий “Create all wsus reporting events”. Хотя "отчеты в SCCM даюn более полное представление о судьбе обновлений, иногда бывает полезным получить эту же информации из консоли WSUS.

                  capture_04132009_161537 Рисунок 4 Выбор иерархии обновлений

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

                  capture_04132009_161549 Рисунок 5 Расписание синхронизации

                  Выбираем необходимые нам типы обновлений. Подробнее о классификации обновлений.

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

                  capture_04132009_161557 Рисунок 6 Выбор загружаемых классов обновлений

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

                  capture_04132009_161611 Рисунок 7 Выбор обновляемых продуктов

                  Выбираем язык обновлений. Если все продукты в вашей системе русскоязычные выбираем только русский язык, иначе выбираем дополнительные языки. Не в коем случае не выбирайте не нужные вам языки – размер обновлений в таком случае будет очень сложно предсказать.

                  capture_04132009_161621 Рисунок 8 Выбор языка обновлений

                  Проверяем страницу summary, Next-Finish.

                  capture_04132009_161628 Рисунок 9 Итоговая страница

                  После этого проверяем настройки агента
                  Site Management – Site Code – Site Settings-Client Afents – Software Updates Client Agents
                  Главное для нас это галочка «Enable software updates on clients”, и интервал сканирования.

                  capture_04132009_164707 Рисунок 10 Настройки агента SCCM

                  На этом настройку Software update point можно считать законченной. Следует дождаться синхронизации с серверами обновлений Microsoft и после этого назначать обновления для клиентов.
                  Кстати, рекомендую настроить  в WSUS отправку оповещений о новых обновлениях на e-mail. В консоли WSUs выбираем Параметры – Уведомления на e-mail
                  В следующей статье я расскажу, о том, как работать с обновлениями, назначать их на коллекции, а пока рассмотрим механизм взаимодействия WSUS и SCCM.

                  Механизм взаимодействия WSUS-SCCM

                  За загрузку обновлений отвечает WSUS. Именно он связывается с серверами Microsoft, производит закачку необходимых файлов в папку WSUSContent. Именно из этой папки обновления будут скопированы в каталоги распространения (Deployment Packeg) SCCM. Следует отметить, что если одно и тоже обновление будет входить в несколько таких пакетов, то физически оно будет скопировано один раз, в остальных папках будет храниться ссылка на него.  Именно файлы обновлений из папок Deployment Packeg будут передаваться на клиентов.

                  схема обновлений Рисунок 11 Схема взаимодействия WSUS и SCCM

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

                  Установка обновлений происходит примерно по следующему сценарию:

                  • • получение информации об  обновления на сервере WSUS и передача это информации в базу SCCM;
                    • одобрение, загрузка и назначение на установку Администратором;
                    • информирование пользователя о выходе обновления;
                    • период, когда пользователь может установить или не установить обновление по своему выбору;
                    • обязательная установка обновления, по наступлению времени принудительной установки(deadline).

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

                  И так,  что делает WSUS:

                  • • получает обновления от сайтов Microsoft Update;
                    • по запросу клиента проводит выдачу информации о применимых к клиенту обновлениях;
                    • запускает и устанавливает полученные от агента SCCM файлы обновлений.

                  Что  делает SCCM:

                  • • запускает процесс синхронизации WSUS с серверами Windows Update в интернете, при этом определяет какие классы обновлений и для каких продуктов необходимы;
                    • предоставляет Администратору возможность управлять обновлениями: загрузка, одобрение, расписание установки;
                    • запускает процесс синхронизации клиентского компьютера с базой WSUS, таким образом мы получаем сведения о необходимых для клиента обновлениях;
                    • передает файлы обновлений на клиентские компьютеры, в зависимости от настроек распространения обновления (по запросу\принудительно);
                    • запускает Update Agent на клиентских машинах для установки обновлений;
                    • строит все отчеты относящиеся к Software Update (необходимые обновления, процесс установки, отчет об установке).

                  Заключение

                  Механизм взаимодействия WSUS и Configuration Manager почти не описана ни в документации, ни в статьях. Данная статья выжимка личного опыта, книг и статей об SCCM и дискуссий на форумах. Надеюсь, что она поможет вам лучше ориентироваться в процессах, происходящих при работе с обновлениями в SCCM. В следующей статье я наконец расскажу о том, как одобрять обновления для клиентов, устанавливать и удалять обновления, работать с отчетами.

                  Алексей Тараненко

                  MCP/MCTS: SCCM 2007

                  altaranenco@gmail.com

                  • Пока гром не грянет…

                    • Рубрика: Windows,Новое
                    • Автор: Александр Косивченко
                    • Дата: Thursday 09 Apr 2009

                    pesets

                    Возможно, кому-то уже доводилось попадать в неприятную ситуацию – когда по какой-то причине выходит из строя RAID-контроллер, или просто массив «рассыпается». Особенно часто это происходит с дешевыми контроллерами, встроенными в материнскую плату. Расскажу небольшую, но поучительную историю, произошедшую со мной на заре моей админской карьеры.

                    • Управление обновлениями в System Center Configuration Manager 2007 (Часть 1)

                      • Рубрика: System Center,Новое
                      • Автор: Алексей Тараненко
                      • Дата: Tuesday 07 Apr 2009

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

                      В первой части статьи мы с вами рассмотрим непосредственно процесс управления обновлениями. Этот процесс одинаков для любых систем. Во второй части мы рассмотрим механизм взаимодействия Windows Software Update Services и System Center Configuration Manager, а также управление распостранением обновлений в Configuration Manager 2007.

                      Я постараюсь  своими словами описать процесс управления исправлениями рекомендованный компаний Microsoft. Мой рассказ будет базироваться на Microsoft Operations Framework 4.0 (MOF) и Microsoft Solutions for Managment 2.5 (MSM).

                      Подробнее о процессе изменения вы можете узнать, ознакомившись со следующими документами:
                      Microsoft Solutions for Managment 2.5 (
                      http://www.microsoft.com/technet/itsolutions/msf/ )
                      Microsoft Operations Framework 4.0 (
                      http://technet.microsoft.com/en-us/library/cc506049.aspx)
                      Введение в MOF на русском (
                      http://www.itsmonline.ru/itsm/dictionary/mof.php)

                      Процесс управления обновлениями (исправлениями), который рекомендует применять Microsoft, был представлен в Microsoft Solutions for Managment 2.5 и основан на функциях управления MOF-службами:

                      • • Change Management (управление изменениями);
                        • Release Management (управление выпуском);
                        • Configuration Management (управление конфигурацией).

                      Данный процесс основан на моделях MOF и состоит из 4х стадий управления обновлениями ПО:

                      • • оценки (Assess);
                        • идентификации (identify);
                        • оценки и планирования (evaluatr & plan);
                        • развертывания (deploy).

                      mofРисунок 1. 4 стадии процесса управления изменениями

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

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

                      Предварительная подготовка к управлению исправлениями

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

                      Для начала нам необходимо определиться с тем, какие компьютеры мы будем обновлять. Например, необходимо ли обновлять компьютеры, которые предназначены для списания или которые выведены в резерв и лежат на складе? Необходимо составить реестр ПО, для которого необходимы исправления. Если у нас не используется BizTalk сервер, то, соответственно, обновления для него должны быть исключены из процесса управления обновлениями.

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

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

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

                      Для всех компьютеров мы проверяем саму возможность установки исправлений. В нашем случае это будет развернутая инфраструктура WSUS+SCCM. С другой стороны это может быть просто и возможность ручной установки обновлений.

                      Задача создания хорошо функционирующей системы обновлений является одной из самых сложных. Поскольку ошибки при проектировании этой структуры в дальнейшем могут вызвать не только необходимость ее переделки, но и неправильное применение обновлений, и как следствие возможную неработоспособность обновляемых компьютеров. При развертывании системы управления обновлениями, желательно предварительно максимально привести все системы к некоему базовому показателю. Например, если в вашей организации никогда раньше не устанавливались обновления, то желательно провести предварительную установку пакетов обновлений (service pack). Это позволит вам более-менее «выровнять» требования к необходимым обновления, а кроме того покажет узкие места. Например, установка Windows XP SP3 покажет, использовались ли у вас нелицензионные копии программ, а установка Windows Server 2003 SP2, на некоторых серверах вызывала проблемы с сетевыми картами.

                      структура обновлений

                      Рисунок 2. Инфраструктура обновлений

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

                      Четырех фазный подход к управлению обновлениями

                      Напомню, что процесс управления обновлениями ПО состоит из 4х стадий:

                      • • оценки (Assess);
                        • идентификации (identify);
                        • оценки и планирования (evaluatr & plan);
                        • развертывания (deploy).

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

                      Оценка(assess) – во многом схожа со стадией оценки выполняемой при подготовке к запуску процесса управления обновлениями.

                      • • Инвентаризация/обнаружение существующих вычислительных активов

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

                      • • Оценка угрозы безопасности и уязвимости

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

                      • • Определение наилучшего источника информации о новых обновлениях ПО

                      Определитесь с источниками информации об обновлениях и угрозах безопасности. Это могут быть различные сайты посвященные проблемам информационной безопасности, либо рассылка от производителя ПО. Например для Microsoft это может быть сайт http://technet.microsoft.com/ru-ru/security/default.aspx

                      • • Оценка существующей инфраструктуры распространения обновлений

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

                      • • Оценка эффективности работы

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

                      Идентификация(Identify) – стадия, на который вы стараетесь получить максимум информации о выпушенном обновлении.

                      • • Обнаружение обновлений ПО надежным способом

                      Используйте только доверенные источники для получения информации об обновлении. Отчет о новых обновлениях правильно настроенного сервера WSUS– это доверенный источник, а письмо с адреса security@microsoftupdate.com с прикрепленным файлом обновления – нет.

                      • • Определение применимости данного обновления к вашему ПО

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

                      • • Получение и проверка исходных файлов обновлений

                      Ни при каких случаях не пользуйтесь недоверенными источниками обновлений. Да, сервер вашего регионального провайдера – это недоверенный источник. Доверенным источником обновления может быть только производитель обновления. Для обновлений Microsoft это сайт update.microsoft.com. И даже при использовании доверенных источников обновления – всегда проверяйте происхождение файла. Это можно сделать, например, проверив цифровые подписи файла.

                      • • Определение характера обновления и задача запроса на изменение

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

                      Оценка и планирование (Evaluate & Plan) – после того как вами получена и обработана информация о новом обновлении, вы должны решить – применимо оно к вам или нет. Если вы готовы применить обновление, то вы переходите на стадию «Оценки и планирования»

                      • • Планирование реагирования

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

                      Приоритет

                      Рекомендуется, в течение

                      Максимально допустимый

                      Критический 24 часов Неделя
                      Высокий Неделя Месяц
                      Средний Месяц Полгода
                      Низкий Полгода В течение года, или при выходе очередного пакета исправлений, либо не внедряйте

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

                      • • Планирование выпуска обновлений

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

                      • • Создание выпуска

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

                      • • Проведение приемо-сдаточных испытаний

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

                      Развертывание (Deploy) – успешное тестирование вашего выпуска обновления является сигналом для перехода к стадии Развертывания. На этой стадии, вы внедряете исправление в вашу рабочую среду, тем самые изменяя ее. В случае неудачного внедрения, должны применяться меры для отката изменений. И не забудьте провести анализ проделанной работы.

                      • Подготовка развертывания

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

                      • Развертывание обновления ПО на целевых компьютерах

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

                      • Анализ результатов внедрения

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

                       

                      Сегодня я постарался описать процесс управления обновлениями. К сожалению его нельзя упростить до одного абзаца, слишком много проблем может принести вам неправильная схема работы. Данная статья ни в коем случае не может быть инструкцией к применению. Если вы решите взять ее за шаблон – очень важно подогнать ее под свои потребности.
                      В следующей статье я расскажу о том, как управлять обновлениями в Configuration Manager, а так же о том, как SCCM взаимодействует с WSUS.

                      При подготовке статьи использовались:

                      1. Steven D. Kaczmarek – Administrator’s Companion SCCM 2007
                      2. Microsoft System Management Server 2003 – Качмарек С.Д. – пер. с англ. Microsoft Corporations

                      Алексей Тараненко

                      MCP/MCTS: SCCM 2007

                      altaranenco@gmail.com