Главная Security, Новое Security, Инсайд
  • Внутренние угрозы в период кризиса

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

    Firewall.cpl_I296a_0409 На сегодняшний день в мире сумма ущерба, причиняемого от атак внутренних злоумышленников (инсайдеров), уже давно превышает сумму от внешних атак. Поэтому защита от внутренних угроз уже стала необходимостью. Особенно сегодня, когда проблема инсайдеров накладывается на проблему кризиса и необходимость массовых увольнений сотрудников. Не стоит думать, что все увольняемые, как равно и остающиеся сотрудники будут лояльны по отношению к увольняющим их работодателям! Именно этой проблеме и будет посвящена данная статья.
    Вначале я хотел бы, чтобы уважаемые читатели сами себе ответили на несколько непростых вопросов. Да-да, именно себе! Итак, вот они:

    • 1. Вы собираетесь увольнять персонал?
      2. Если да, то, как вы думаете, будут ли эти сотрудники лояльны к вам?
      3. Подумайте, не захотят ли ваши (почти бывшие) сотрудники унести информацию, к которой они имеют доступ, с собой?
      4. Сможете ли вы что-либо этому противопоставить?
      5. Готова ли ваша служба безопасности к такой постановке вопроса?
      6. Если вы даже обнаружите, что ваш сотрудник похищает информацию, –  готовы ли вы доказать это в суде?
      7. Готовы ли вы к рискам, связанным с применением нелицензионного программного обеспечения?
      8. Полагаю, список вы сможете продолжить сами…

    Без сомнения, многие предприятия сейчас будут вынуждены сокращать персонал. Некоторые – цивилизованно, с соблюдением законодательства, некоторые просто извещают сотрудников, что с сегодняшнего дня не нуждаются в их работе. Оба подхода тяжело бьют по людям. Но второй подход бьет еще и по организации: таким образом руководство компании  показывает, что оно готово во имя сегодняшней призрачной выгоды не считаться с законом. А следовательно – завтра обойтись так же с партнерами и заказчиками! Это удар по престижу организации, и информация такого рода разносится быстро. Кроме того, тем самым руководство дает увольняемым незаконные, но весомые основания поступить и с предприятием в обход закона. Эту ветвь рассуждений далее можно не детализировать. Перейдем к вынужденному вполне законному процессу сокращения персонала.
    Если вы приняли решение об увольнениях, придется побеспокоиться, чтобы уходящие не могли «прихватить» с собой конфиденциальную информацию.  Если вы не были готовы к этому – вы существенно проиграли! У вас не было политики безопасности? Не была классифицирована информация по степени конфиденциальности? Более того, у вас не было вообще службы ИТ-безопасности, всем занимались сисадмины? Увы… Но самое печальное, если ваши сотрудники при приеме на работу не подписывали соглашение о неразглашении информации! Тогда – формально — сотрудник, «уводящий» с предприятия, скажем, базу клиентов – ничего не нарушал, и вы не сможете предъявить ему претензии в суде.
    Но сложная экономическая полоса — это еще и повод (если это не было сделано ранее) выделить если не подразделение, то хотя бы определенного специалиста, который бы занимался ИТ-безопасностью. И этот человек (отдел) должен подчиняться напрямую первому лицу в компании. Как вариант — за аудит и обеспечение ИТ-безопасности может взяться сторонняя компания с большим опытом в этой области… что, впрочем, редко избавляет от необходимости сформировать собственную группу или пригласить доверенного специалиста.
    Да, если это не сделано ранее, вас ожидают некие дополнительные затраты. Но следует помнить, что общий уровень экономической безопасности предприятия напрямую зависит от безопасности информационной! Ведь любая акция, направленная против экономических интересов хозяйственного субъекта, начинается с этапа сбора информации. Сегодня нельзя представить себе не то что крупные экономические преступления вроде вывода активов предприятия, а даже мелкие противоправные действия без соответствующего информационного обеспечения.
    Помимо того, что наиболее важной информационной угрозой становится та, что направлена изнутри предприятия,- она все чаще приобретает характер «инициативной вербовки», когда сотрудник сам, по собственной инициативе, собирает те или иные сведения для продажи их конкурентам или иностранным спецслужбам. К счастью, все большее число руководителей компаний начинают осознавать реальный масштаб инсайдерских угроз.
    Согласно исследованию «Инсайдерские угрозы в России 2009» проведенного с 01 декабря 2008 г. по 23 января 2009 года специалистами аналитического центра Perimetrix:

    • • Наибольшие опасения вызывают угрозы утечки информации (73%), а также халатность служащих (70%)
      • Главной причиной актуальности внутренних проблем являются продолжающиеся утечки информации – только 5% компании заявили об отсутствии подобных инцидентов за последний год.
      • Специалисты по безопасности осознали собственную незащищенность перед утечками – сразу 42% респондентов затруднились назвать точное количество утечек.
      • Криптографические системы используют 41% компаний, а системы защиты от утечек – 29%.
      • В подавляющем большинстве случаев нарушители внутренней безопасности не несут практически никакой ответственности. 45% халатных нарушителей наказываются неформальными выговорами, а 51% злонамеренных инсайдеров увольняются из компаний по собственному желанию.

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

    • • Почему вы хотите защищаться от внутренних угроз?
      • Как выглядит портрет возможного нарушителя?
      • Какие ресурсы вы готовы потратить на защиту от внутренних угроз?

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

    Таблица 1.
    Цели и методы внедрения системы защиты против внутренних угроз

    Цель Внедрение
    Соответствие требованиям нормативов и стандартов Внедрение мер, которые обеспечат соответствие и проверяются при  аудите
    Сохранность информации Гласное внедрение в сочетании с кадровой работой
    Выявление канала утечки Открытое внедрение в сочетании с оперативными мероприятиями
    Подтверждение непричастности Архивация движения данных и сетевых операций для доказательства того, что источник утечки не внутри фирмы

    Однако прежде чем вы сможете внедрить системы защиты от внутренних угроз, а их разновидностей на рынке сегодня не просто много, а очень много, это целый класс так называемых DLP (Data Loss Prevention) систем, нужно провести классификацию обрабатываемой информации, определить владельцев обрабатываемой информации и т.д.

    Средства защиты

    Сегодня к мерам по защите информации от внутренних угроз компании относят технические решения по контролю доступа к ресурсам (Интернет, электронная почта, USB), а также сигнатурную контентную фильтрацию (как правило, это специальным образом настроенный антиспам-фильтр). Однако стоит понимать, что эти методы позволяют противодействовать либо низко квалифицированным, либо неосторожным пользователям.
    Стоит помнить, что сигнатурная контентная фильтрация легко обходится либо удалением «опасных» слов либо примитивным кодированием, т.е. заменой символов одной кодировки (западноевропейской) другой (кириллической). Легко отметить что слова «секретно» и «ceкpeтно» читаются одинаково, в то время, как во втором слове выделенные буквы набраны в западноевропейской кодировке. Более того, кто или что может мешать заменить букву «о» на цифру «0» или букву «s» на цифру «5»? А сигнатурный анализатор просто пропустит это слово как нераспознанное.
    Вместе с тем стоит понимать, что принцип «запретить все» неприменим, так как сотрудникам необходимо продолжать работать.
    То есть стоит понимать, что с одной стороны компании нуждаются в упорядочении системы хранения конфиденциальной информации, а с другой – во внедрении более совершенной системы защиты от внутренних угроз.

    Положение о конфиденциальной информации в электронном виде

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

    Контентное категорирование

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

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

    Конфиденциальную информацию можно разнести по следующим категориям (пример):

    • • «СТРОГО КОНФИДЕНЦИАЛЬНАЯ» – к данной категории относится информация, являющаяся конфиденциальной в соответствии с требованиями действующего законодательства (банковская тайны, персональные данные), а также информация, ограничения на распространение которой введены решениями руководства организации (коммерческая тайна), разглашение которой может привести к тяжким финансово-экономическим последствиям для организации вплоть до банкротства (нанесению тяжкого ущерба жизненно важным интересам его клиентов, корреспондентов, партнеров или сотрудников);
      • «КОНФИДЕНЦИАЛЬНАЯ» – к данной категории относится информация, не отнесенная к категории «СТРОГО КОНФИДЕНЦИАЛЬНАЯ», ограничения на распространение которой вводятся решением руководства организации в соответствии с предоставленными ему, как собственнику (уполномоченному собственником лицу) информации, действующим законодательством правами, разглашение которой может привести к значительным убыткам и потере конкурентоспособности организации (нанесению ощутимого ущерба интересам его клиентов, корреспондентов, партнеров или сотрудников);
      • «ОТКРЫТАЯ» – к данной категории относится информация, обеспечения конфиденциальности (введения ограничений на распространение) которой не требуется.

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

    Метки документов

    Необходимо обратить особое внимание на организацию процесса пометки конфиденциальных документов. Каждый конфиденциальный документ должен содержать метку, по содержанию которой контролирующие программы могли бы определить степень его конфиденциальности и категорию пользователей, которые могут проводить с ним потенциально опасные операции – публикацию в Интернет, копирование на сменные носители, переименование, отправку по электронной почте и т.п. Технические и организационные методы установки меток выбирает заказчик. Если все защищаемые документы хранятся исключительно в формате MS Office, то в качестве метки может использоваться запись “конфиденциально” в соответствующих полях свойств документов. Некоторые производители систем документооборота используют программные метки и специальные форматы файлов. Однако самый распространенный и простой способ присваивания меток – именование файлов по специальной маске. Например, первые 10 символов – тематическая группа, к которой относится документ (название клиента, рабочей группы, подразделения, отрасли и т.д.), затем знак подчеркивания, затем 20 символов для описания документа, снова знак подчеркивания и 8-значная дата в формате YYYYMMDD.
    Следует обратить внимание на то, что процесс внедрения процедуры именования файлов – не какая-то разовая акция, а постоянная работа по обучению персонала именовать файлы именно таким образом. Необходимо понимать, что кроме организационных методов (закрепление приказом только такой формы именования, поддержка способа именования всем топ-менеджментом и инструктаж новых сотрудников), надо привлечь на помощь и технические средства. Самый простой технический способ внедрения этой процедуры – разрешать выкладывать на файловый сервер, класть в корпоративное хранилище или публиковать в Интранет только те файлы, которые именованы по заранее утвержденному шаблону. Со временем все файлы, которые прошли через электронную почту, файловые серверы, хранилище данных и Интранет, будут называться правильным образом.
    После того, как все файлы документов будут названы по такой маске, документы будут автоматически попадать в поле зрения контролирующих систем и перехватываться при запрещенных с ним действиях пользователя не только средствами контентной фильтрации, но и мониторами, действующими на основании политик. В отличие от контентной фильтрации, этот метод дает практически 100% гарантию. Это удобно и при ведении визуального контроля, ведь даже в очереди на печать можно сразу увидеть конфиденциальные документы. К тому же не будет лишним еще раз напомнить пользователю при открытии файла, что документ конфиденциален.

    Хранение информации

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

    Способы хранения конфиденциальной информации

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

    • • сводная информация;
      • конфиденциальные документы;
      • интеллектуальная собственность.

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

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

    Неструктурированная информация
    Хищение документов, содержащих неструктурированную информацию, также может привести к моральным и материальным потерям. Защита от утечек подобной информации крайне затруднена.
    Одним из вероятных путей утечки информации, используя санкционированный доступ, являются клиентские приложения. Большинство используемых в качестве рабочих станций – компьютеры на платформе Intel. Хранение информации в незашифрованных временных файлах, встроенная в операционную систему возможность копирования информации в буфер (операции Copy и PrintScreen), наличие многих каналов ввода-вывода (дискеты, CD-R, USB, Wi-Fi, Bluetooth и т. д.) делают рабочую станцию весьма опасным устройством для реализации внутренних IT-угроз. Таких угроз практически нет при использовании тонких клиентов.

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

    Основные направления защиты

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

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

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

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

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

    К первой группе можно отнести копирование файла на сменные носители, отправку по почте, публикацию в Интернет, печать.
    Ко второй – копирование информации из документа в буфер Windows, копирование временного файла Windows и т.п.
    К третьей группе – переименование файла или его расширения, сохранение файла под другим именем, сохранение в другом формате, архивирование, кодирование и шифрование.
    Операция с конфиденциальной информацией, которая недопустима для данного пользователя, должна либо блокироваться, либо сведения о такой операции должны поступать к офицеру безопасности. При этом система внутренней безопасности должна быть настроена так, чтобы пользователь (его руководитель) узнавали, что он пытается совершить запрещенную операцию, либо чтобы эта информация была доступна только офицеру информационной безопасности.
    Однако если вы думаете что это все, что вам нужно сделать – вы ошибаетесь. На самом деле вы должны еще классифицировать потенциального нарушителя, создать его портрет, продумать нетехнические методы защиты. Рассмотрение этих вопросов требует достаточно большого объема информации и не может быть втиснуто в одну статью. Что вам сказать – вам предстоит работать и работать! И учтите, времени у вас нет! Это все должно быть сделано еще на позавчера!
    Кроме этого можно рекомендовать следующее:

    • • Создать выделенную структуру ИТ-безопасности (и/или найти организацию, которая поможет в анализе рисков информационной безопасности, написании соответствующих документов и внедрении соответствующих аппаратно-программных средств);
      • Классифицировать данные и создать каталог конфиденциальной информации;
      • Разобраться, кто к этой информации имеет доступ;
      • Закрыть доступ тем сотрудникам, кому эта информация не нужна по служебной необходимости;
      • Закрыть возможность записи на внешние носители, а в случае недоступности такой меры – организовать теневое копирование информации и контроль действий за соответствующих сотрудников;
      • Запретить удаление любой информации с дисков общего доступа;
      • Включить фильтр на почтовом сервере по определённым словам (на исходящую электронную почту);
      • Запретить использование внешних бесплатных почтовых серверов, ненужных в работе социальных сервисов и средств мгновенного обмена сообщениями;
      • Для наиболее ответственных рабочих мест предусмотреть средства регистрации действий персонала;
      • Создать инструкции по использованию ПК, ПО, уже внедренных и новых систем и средств автоматизации управления;
      • Под роспись ознакомить пользователей с правилами работы по работе с конфиденциальной информацией;
      • Объединить усилия топ-менеджмента, ответственных за экономическую, физическую и информационную безопасность.

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

    Безмалый В.Ф.
    MVP Consumer Security
    vladb@windowslive.com
    http://vladbez.spaces.live.com

  • Главная Virtualization, Новое Virtualization
    • Зачем же нужна виртуализация?

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

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

      Я, признаться честно, являюсь технарем "до мозга костей", и модные аббревиатуры вроде TCO, ROI, etc., которыми очень любят оперировать господа маркетологи – для меня являются "китайской грамотой". Соответственно – буду писать о том, что я вижу как технарь.

      Наверняка у многих сисадминов в хозяйстве имеется несколько серверов. И обычно это оправданно: многие задачи рекомендуется разносить по разным серверам. К примеру, Microsoft настоятельно не рекомендует совмещать контроллер домена Active Directory и интернет-шлюз на одном физическом сервере. Это создает серьезную угрозу безопасности: в случае атаки на вашу сеть каких-нибудь хакеров или вирусов – первым примет на себя удар, как Брестская Крепость, интернет-шлюз. В случае, если на нем размещался еще и контроллер домена – существует вероятность, что базы AD будут повреждены, либо, что еще хуже – окажутся в руках хакеров. В первом случае понадобится тратить время на восстановление из бэкапов, во втором – очень высокая вероятность дальнейших и более продуманных атак, с использованием логинов и паролей действующих пользователей сети. Ну или просто попадание e-mail адресов пользователей компании в базы спамеров – тоже приятного мало. Одна старая пословица говорит: "Не клади все яйца в одну корзину".

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

      Но тут возникает новая проблема: каждый отдельный сервер – стоит денег, причем не малых (если речь идет о брэндовых серверах). Каждый отдельный сервер потребляет электроэнергию, и занимает место на столе либо в стойке. Возможно, кому-то это покажется не особо актуальным, тем не менее – это является важным преимуществом. Особенно, если сервера размещаются в стороннем датацентре, где взымают плату за занимаемые юниты в стойках и энергопотребление строго ограничивается. К тому же, в европейских странах существует некий налог, который напрямую зависит от объемов электроэнергии, потребляемых компанией. Не помню, как этот налог называется – что-то связанное с экологией и выбросом CO2.

      Кроме этого, каждое из приложений редко потребляет много системных ресурсов: те же контроллеры доменов и интернет-шлюзы – на них редко загрузка процессора превышает 10%. Использование под каждую такую задачу отдельного сервера выглядит нерационально. Совмещать все на одном сервере – как мы уже выяснили, не правильно с точки зрения безопасности. Где же золотая середина? Как же сделать, чтобы и волки были сыты, и овцы целы (и пастуху – вечная память! :)) Ответ дает как раз технология виртуализации.

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

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

      • 1) Купить два сервера с 128M RAM;
      • 2) Купить один сервер с 256M RAM (плюс еще какое-то количество "про запас" и для запуска хостовой ОС) и запустить оба приложения в отдельных виртуальных машинах.

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

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

      Если же необходимо избежать единой точки отказа – можно купить, к примеру, два сервера и развернуть кластер. В этом случае, два физических сервера будут действовать как единая платформа для виртуализации. Если виртуальных машин, к примеру, 5 – это все равно выгоднее 5и отдельных серверов. А при отказе одного из серверов в кластере – виртуальные машины продолжат работу на другом – вот и все. Пользователи этого скорее всего не заметят. Ну, возможно, прервется у них работа на несколько секунд, это не так критично, как отказ на несколько часов.

      Еще важный момент: виртуализация (если речь идет о решении от Microsoft) поможет сэкономить на лицензиях. К примеру, лицензия на Windows Server 2008 Standard позволяет бесплатно запускать внутри одну виртуальную машину, Enterprise – до 4, а Datacenter – вообще неограниченно (в пределах одного физического хоста).

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

      Как известно, развертывание нового сервера занимает определенное время. Это – установка ОС, установка драйверов, установка приложений и т.п. Да, конечно, все параметры установки ОС можно задать в файле ответов автоматической установки, драйвера можно интегрировать в дистрибутив, приложения установить, например, через RunOnce, но все равно установка занимает время. Даже если создать полный образ системы – во-первых, его развертывание все равно займет порядка 10-15 минут просто из-за его объема и скорости чтения из сети или с DVD-ROM, во-вторых – для создания такого образа, как правило, необходимо прибегать к помощи стороннего ПО. С виртуальными же машинами все намного проще: можно создавать абсолютно идентичные "клоны" виртуальной машины за пару кликов мышью, и процесс займет порядка нескольких минут – ведь скорость работы дисковой подсистемы сервера намного выше, чем пропускная способность сети или скорость чтения DVD-ROM.

      Приведу пример из собственного опыта. Контора, где я однажды работал, занималась, помимо прочего, и разработкой ПО. Естественно, разработчикам было необходимо где-то тестировать и отлаживать свои программы. Как нельзя лучше для этого подходили виртуальные машины. Благодаря клонированию – удалось создать эталонный образ, в результате которого развертывание новой виртуальной машины занимало порядка 3 минут. А у нас было целых два сервера, на каждом из которых работало примерно по 20 виртуальных машин. К слову сказать – использовался VMWare ESX Server, было просто два отдельных сервера – без VMotion и кластеров. Правда, для управления использовался Virtual Center.

      Еще одна головная боль любого сисадмина – резервные копии. Как утверждает пословица: "Есть два типа сисадминов: те, которые еще не делают бэкапы, и те, которые уже делают". Резервное копирование – на первый взгляд, возможно, кажется бесполезной процедурой, но как только жареный петух куда-нить клюнет – тот, кто не делал бэкапы – начинает рвать на себе волосы, кусать локти и развертывать все заново. Если на сервере уже были какие-то важные данные – это то еще удовольствие. А если там была, например, база данных, содержащая бухгалтерию предприятия за последние 10 лет – то это просто смерти подобно. Не говоря уже, опять же, о простое – который может обернуться серьезными убытками. Ну не поймут клиенты, если им будут говорить "Подождите пожалуйста, у нас сервер не работает!" – они просто пойдут и купят у кого-то другого. Директор, естественно, админа за такое дело по головке не погладит.

      Даже если делается бэкап, то не всегда можно дать 100% гарантию, что из него можно будет восстановить ОС на "голом железе", и она будет работать без ошибок. Особенно – если конфигурация аппаратного обеспечения будет немно
      го отличаться от предыдущей. Близкую к 100%-ной гарантию дают системы резервного копирования, имеющие функцию "Bare Metal Restore" – например, Symantec BackupExec, CA ArcServe, IBM Tivoli Storage Manager, HP Data Protector. Но само это ПО стоит вполне приличных денег, и за функцию "Bare Metal Restore" придется заплатить отдельно: для ее использования, как правило, необходима отдельная лицензия.

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

      Еще необходимо упомянуть так называемые моментальные снимки (snapshots): это – грубо говоря – бэкап виртуальной машины, хранящийся внутри нее самой. При необходимости можно просто "откатить" виртуалку на момент снятия моментального снимка – и она будет работать, как будто с того момента ничего не изменилось. Причем, у одной виртуальной машины может быть много таких snapshot’ов, и они могут образовывать древовидную структуру. Это позволяет "откатывать" систему ровно к необходимому моменту. Такой функцией могут пользоваться, к примеру, системные администраторы, делая snapshot до и после каких-либо важных изменений, и, если понадобиться, к примеру – откатиться до момента изменений. Или еще раньше. А потом, если надо – позже. И не нужно развертывать систему с нуля и снова повторять все свои действия. Наши разработчики, кстати, по достоинству оценили такую возможность: раньше, когда они использовали VirtualPC на своих рабочих станциях – делать такие "откаты" было затруднительно, часто приходилось создавать машину заново с эталонного образа.

      Итак, подводя итог, вкратце – почему все же виртуализация серверов – это гуд:

      • Рациональное использование аппаратных ресурсов серверов;
      • Экономия денег на покупке новых серверов, экономия электроэнергии и физического пространства;
      • Экономия лицензий на виртуальные ОС (если речь о Microsoft);
      • Простота администрирования: легкость перемещения виртуальных машин с одного физического сервера на другой, быстрота развертывания новой машины из эталонного образа, простота создания резервной копии и восстановления из нее, использование "моментальных снимков".

      Собственно, на этом хотелось бы завершить данную статью.

      Александр Косивченко

      • System Center Configuration Manager 2007 – решение для автоматизации управления ИТ инфраструктурой предприятия

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

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

        Чем же интересен Confguration Manager для ИТ?

        Службе технического обеспечения, он будет интересен своими инструментами отчетов и инвентаризации. Больше нет необходимости бегать по этажам с бумажками и отслеживать передвижение планки памяти. Вся история обновления железа будет сохранена в базе. Вы всегда сможете четко сказать, сколько процессоров Pentium IV 3ГЦм установлено на ваших компьютерах.

        capture_03272009_112357

        Рисунок 1 Вид таблицы отчетов

        Техподдержка, больше не будет требовать купить себе Radmin. В SCCM входит функционал Remote managmetn, который использует три компонента для обеспечения удаленного управления: Remote Tools (набор драйверов и ПО обеспечивающих возможность удаленной работы наподобие Radmin\VNC), Remote Assistance и Remote Desktop. Кроме того, можно забыть о суматохе при смене ПО – теперь установка ПО на сотни компьютеров, требует трех щелчков мыши. Когда в следующий раз AOL снова сменит протокол, новая версия QIP будет установлена на компьютеры наших горячо любимых менеджеров в течение часа. При этом 10 минут вы будете ее скачивать, 5 интегрировать в SCCM, и оставшиеся 45 посвятите чтению сайта itband.ru, ожидая отчетов об установке.

        Даже ваш отдел мотивации труда будет рад – вы можете показать им отчеты, на которых будет видно, что 90% рабочего времени менеджеры играют в косынку.

        И это далеко не все возможности Configuration Manager.

        Чтобы вам легче было ориентироваться в дальнейшем, определимся с основными терминами, которые используются при работе с Configuration Manager.>

        Сайт SCCM (Site system) – группа серверов выполняющих роли SCCM.

        Central site – верхний primary-сайт в иерархии сайтов.>

        Primary site – группа серверов, которые используют для работы собственную базу данных

        Secondaryт site – группа серверов, которые используют для работы базу данных родительского сайта.

        Branch distribution> point – хотя это не отдельный сайт, а роль сайта, все же стоит отметить отдельно. Данная роль предназначена для упрощения обслуживания особо маленьких филиалов организации. В таких филиалах сеть может представлять из себя 3 компьютера в рабочей группе. В отличие от primary\secondary сайтов Branch DP может устанавливаться и на рабочие станции. Обладает функционалом только точки распространения программ\обновлений.

        Границы сайта – IP подсети, диапазоны IP адресов, сайты AD и IPv6 Prefix определяющие зону управления того или иного сайта.

        Коллекция (collection) – группа объектов (пользователи, компьютеры, группы безопасности) объединенная, по какому либо признаку. Именно над коллекциями производится большинство действий, таких как установка программ\ОС\обновлений.

        Роль SCCM (role) – компонент SCCM обеспечивающий выполнение определенной функции, например, такой как установка ПО или создание отчетов. Все роли могут быть совмещены на одном сервере, либо разнесены на отдельные сервера.

        Client Agent – определенный функционал клиентской части SCCM. Часть агентов может быть отключена.

        Функциональность SCCM можно разделить на три больших класса:

        Инвентаризация и отчеты

        • Инвентаризация аппаратного обеспечения (Hardware inventarization)
          Инвентаризация  программного обеспечения (Software inventarization)
          Слежение за используемым ПО и лицензиями (Asset Intelligence)
          Отчеты (Reporting)

        Развертывание приложений и ОС

        • Развертывание операционных систем (OS Deploy)
          Распространение ПО (Software distribution)
          Распространение и управление виртуализированным ПО (Application virtualization management)
          Управление обновлениями (Software update)

        Управление клиентскими устройствами

        • Мониторинг используемых программ (Software metering)
          Удаленное управление клиентами (Remote management)
          Управление мобильными устройства (Modile device management)
          Управление клиентами Intel vPRO (Out  of band management)
          Поддержка заданной конфигурации (Desied configuration manager)
          Защита подключающихся к сети (Network access protection)

        roleSCCM

        Рисунок 2 Роли сайта SCCM R2 2007

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

        SCCM  совместима с большинством ОС Microsoft. table legend

        Рисунок 3 Поддержка ОС в Configuration Manager 2007

        Рассмотрим по отдельности некоторые основные возможности.

        Установка ОС (OS Deploy)

        Как часто вам приходится устанавливать ОС на компьютеры? Я думаю, что большинство системных администраторов использует ту или иную технологию (RIS\WDS) для облегчения установки. OSD в SCCM позволяет облегчить весь процесс установки до одного простого действия: подключения в сеть и включения компьютера. Далее запуститься мастер установки SCCM и на компьютер будет последовательно развернуты: ОС из файла wim, все драйвера необходимые для работы компьютера, заданный набор программ и все самые свежие обновления безопасности. Я не могу сказать, что по сравнению с WDS SCCM  совершил революцию, нет, это скорее эволюция. То, что при использовании WDS было ранее невозможно или требовало от системного администратора много времени и сил, теперь стало доступно по двум щелчкам мыши.

        OSD_WinPE_1

        Рисунок 4 Приветствие мастера установки ОС в OSD

        Установка приложений (Software distribution)

        Иногда бывает так, что пользователям приходится менять свои компьютеры. У кого-то эта ситуация ярко выраженная, у кого-то менее. Довольно часто случаются курьезные ситуации в стиле башорга: «А перенесите мне мой старый монитор, там у меня на рабочем столе важная программа осталась!». Можно конечно подойти и поставить все вручную. Но нужно ли? SCCM позволяет назначать установку программ на коллекции. При этом установка будет происходить в фоновом режиме, поэтому пользователь пересевший за новый компьютер, на котором установлено только базовое ПО, в течение часа получит все программы которые ему назначены. Причем в этот момент он будет продолжать работать с почтой, просматривать интернет страницы или раскладывать косынку – т.е. полноценно работать, а не стоять у вас над душой с криком: «У меня отчет! У меня сроки горят!»

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

        Или бывает так: в 17:45 вас вызывает к себе начальство и говорит, завтра в 9:00 утра на всех наших пятистах компьютерах должна быть новая супер программа от наших партнеров. Не правда ли, знакомая ситуация? Раньше в такой ситуации приходилось до ночи засиживаться в офисе. С помощью SCCM можно спокойно уйти домой в 18:00. А SCCM ночью централизованно включит компьютеры (с помощью технологии WakeOnLan) и установит все необходимые программы, после чего снова выключит их. По-моему, это гораздо лучше, чем засиживаться на работе? 😉

        capture_03272009_134433

        Рисунок 5 Выбор ПО доступного для установки

        Управление обновлениями (Software Update)

        SCCM расширяет возможности хорошо известной службы обновлений WSUS 3.0, позволяя управлять не только обновлениями Windows Update, но и обновлениями сторонних организаций. Вы может обновлять с помощью него даже свой собственный корпоративный софт. Сам процесс управления обновлениями стал гораздо более гибким.

        В SCCM, в отличие от WSUS нельзя установить автоматическое одобрение обновлений. Все обновления должны быть предварительно одобрены администратором. Я считаю такой подход оправданным, все изменения в системе должны проходить предварительное тестирование. В моей практике бывали случаи, когда одно исправление способно нарушить работу бизнес приложений. Но это не означает, что управление обновлениями усложнено. Для действий над группами обновлений существуют листы обновлений (update list). Благодаря им, администратор может оперировать не отдельными обновлениями, а целыми списками, к примеру всеми критическими обновлениями выпущенными в последний «вторник».

        Для установки обновлений на клиентах применяется довольно гибкий подход. Вы можете:

        • позволить пользователям самостоятельно принимать решение об установке того или иного исправления;
        • дать время пользователю «подумать», а по истечении определенного срока установить обновление принудительно;
        • либо же сразу устанавливать обновление принудительно, в том числе автоматически включая компьютер с помощью WakeOnLan технологии ночью.

        capture_03272009_134342

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

        Решение для филиалов и удаленных клиентов

        В России структура средних и больших компаний такова, что их офисы отделены друг на тысячи километров и несколько часовых поясов. Причем линии связи между филиалами могут быть абсолютно разными. Начиная от выделенных оптических линий от магистральных провайдеров, заканчивая городской Wi-Fi которая имеет «приятное» свойство зависать во время дождя. Некоторые филиалы могут не уступать в размере и качестве подготовки обслуживающих их ИТ специалистов головному предприятию, а в некоторых на большое количество «манагерского» состава, будет всего один эникей, ну а некоторые филиалы будут довольствоваться тремя компьютерами в каком-нибудь промышленном пригороде, куда даже студента старшего курса не заманишь для обслуживания этого хозяйства. Мне пару раз приходилось устанавливать 1С с использованием радмина, через спутник. Я получил просто массу «удовольствия» и убил на это не один час. Если мы используем SCCM, то даже в самых отдаленных и маленьких филиалах сможем использовать его возможности. Где то это будет полноценный сайт, где-то secondary сайт,  ну а в особо маленьких филиалах компьютер секретаря будет использован как Branch distribution point.

        Лицензирование и цены

        Разумеется, в вводной статье нельзя не затронуть такую тему как лицензирование. Как и для большинства продуктов SystemCenter, для Configuration Server 2007 нам понадобиться покупка нескольких типов лицензий.

        Управляющий сервер (Management Server)

        Configuration Manager 2007 R2 Server
        Лицензия нужна для каждого сервера (site server) запущенного в физической или виртуальной среде. Так же отдельная лицензия нужна, на каждый узел NLB-кластера сервера SCCM.
        Вам не требуется дополнительно покупать лицензии Management Server, если любая из перечисленных ролей установлена на сервере, отличном от сервера с ролью Site server:

        • Configuration Manager Console
          Configuration Manager Client
          Device Management Point
          Custom Updates Publishing Tool
          Distribution Point
          Fallback Status Point
          Inventory Tool for Microsoft Updates
          PXE Service Point
          Management Point
          Reporting Point
          System Center Update Publisher
          Secondary Site Server
          Server Locator Point
          Software Update Point
          State Migration Point
          System Health Validator Point
          Configuration Pack

        Вам так же не требуется лицензия Management Server для сервера SQL (role site database server), на котором будет храниться база данных сайта SCCM.
        Хочу обратить особое внимание на Secondary сайты. Для Secondary-сайта не требуется дополнительная лицензия Management Server, поскольку secondary сайт работает с базой главного сайта.
        http://technet.microsoft.com/en-us/library/bb632547.aspx

        Серверные лицензии на управление (Management Licenses for Managed Servers)

        Configuration Manager 2007 R2 Enterprise Server ML
        Управление экземплярами серверного программного обеспечения с использованием DCM:
        Конфигурации IT Compliance и Governance
        Основной нагрузкой операционной системы
        Все другие утилиты операционных систем, нагрузки служб, а также любые приложения, работающие в лицензионных операционных средах.
        Configuration Manager 2007 R2 Standard Server ML
        Управление экземплярами серверного программного обеспечения с использованием Desired Configuration Management (DCM) (Управление заданной конфигурацией) основной нагрузки операционной системы, работающей в лицензированной операционной среде, а также управление любыми приложениями, работающими в этой операционной среде, которые не требуют использования DCM.

        «Основные нагрузки операционной системы» включают:
        следующие служебные программы операционной системы:  диспетчер системных ресурсов, служба уведомлений о смене пароля, анализатор безопасности Baseline Security Analyzer, службы надежности и доступности;
        нагрузки следующих файловых служб и служб печати:  сервер печати, распределенная файловая система (DFS), служба репликации файлов (FRS), сетевая файловая система (NFS), протокол передачи файлов (FTP) и службы Windows Sharepoint Services;
        нагрузки следующих сетевых служб:  распределенная служба имен DNS, протокол динамической настройки сети DHCP и служба имен Windows Internet Naming Service (WINS).

        Для каждой серверной операционной среды (среда OSE) на одном устройстве, которым необходимо управлять, требуется лицензия на управление серверами (лицензия ML).  Если у вас имеется более одной среды OSE, для такого устройства потребуется эквивалентное количество лицензий ML.  Для управления любым количеством сред OSE на одном сервере можно использовать одну лицензию System Center Server Management Suite Enterprise.  Кроме того, серверные лицензии ML разрешают управление средами OSE на рабочих станциях.
        Важно помнить, что любые варианты лицензирования управляемых или обслуживающих устройств — с помощью отдельных ML не влияют на необходимость лицензирования управляющих серверов, и тем более не отменяют эту необходимость.

        Клиентские лицензии на управление (Management Licenses for Managed Clients)

        Configuration Manager 2007 R2 Client ML
        Хотя серверные ML можно использовать для лицензирования не-серверных сред, это вряд ли оправдано экономически. Для лицензирования не-серверных сред, существует клиентская лицензия Client ML. Client ML бывает трех видов:
        Client ML — per OSE привязываются аналогично серверным ML — к каждой среде (OSE) в отдельности. Таким образом, отдельная лицензия требуется для каждой запущенной среды с не-серверной ОС. При этом такой тип лицензии позволяет управлять не-серверной средой вне зависимости от того, сколько пользователей использует эту ОС.
        Client ML — per user дает возможность лицензировать управление не-серверными ОС по количеству пользователей, которые используют эти среды. Клиентская лицензия на управление такого типа позволяет управлять всеми средами, которые используются лицензированными пользователями.
        Client ML лицензия, включенная в наборы Core CAL и Enterprise CAL. В этом случае, она позволяет управлять любым количеством не-сервеных сред для любого количества пользователей, то есть лицензируется на устройство (per device).

        Для примера возьмем среднюю организацию, в которой 10 серверов и 150 рабочих станций. При этом у организации два офиса – основной и дополнительный. В основном расположены 100 пользователей, в дополнительном 50. 5 топ-менеджеров  используют в свой работе КПК на базе Windows Mobile. Тогда для внедрения SCCM нам понадобятся следующие типы лицензий:
        -клиентские лицензии (Client ML) – 155 = 150+5
        -лицензии на управление серверами (Server ML) – 10
        -лицензия на SCCM R2 – 1
        Если каналы между офисами более-менее стабильны, то вы можете развернуть в дополнительном офисе Secondary сайт. При этом, стоимость лицензий не поменяется.

        licensing

        Рисунок 7 Схема лицензирования

        Цены

        Configuration Manager Server 2007 R2 ~ 580$
        Enterprise ML ~430$
        Standard ML ~ 160$
        Client ML  ~ 40$

        Подробнее о лицензировании:
        http://www.microsoftvolumelicensing.com/userights/Downloader.aspx?DocumentId=2084
        http://www.microsoft.com/systemcenter/configurationmanager/en/us/pricing-licensing.aspx

        Вместо заключения

        SCCM это очень мощное и красивое решение для автоматизации управления компьютерами организации. Но за кажущейся простотой и красотой административной консоли не должна дарить вам чувство эйфории. Как подчинить этого «монстра» я расскажу в последующих статьях.

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

        MCP/MCTS: SCCM 2007

        altaranenco@gmail.com

      • Главная Windows, Новое Active Directory
        • Восстановление удаленных доменных учетных записей в Windows 2003/2008/2008R2

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

          Снимок Темы, посвященные резервному копированию, я всегда начинаю с шутки: «Системные администраторы делятся на две группы, те которые уже делают резервные копии и те которые еще не делают». На самом деле эта шутка «Со слезами на глазах». В бытность работы начинающим системным администратором я потерял по собственной халатности несколько файлов и помню чувство, которое испытал в процессе вызова «на ковер». Никому такое не пожелаешь. Но несколько файлов это все же не так страшно как полная потеря вашей инфраструктуры и остановка фирмы. Сегодня я не буду говорить непосредственно о резервном копировании, вместо этого мы рассмотрим варианты восстановлении самого важного для Windows сетей, (После баз данных) – Active Directory, восстановление её объектов без наличия резервной копии.

          Active Directory используют сотни тысяч компаний по миру, но поверьте, грамотно разбираются в восстановлении AD единицы системных администраторов. То, что я буду рассказывать, уже неоднократно печаталось. Но, я попытался сделать более серьезную работу. Во-первых, постарался донести материал максимально понятно. Во-вторых, объединить в статье информацию о Windows 2003, Windows 2008 и Windows 2008R2 Beta.

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

          Если я удалил из Active Directory нужного пользователя (группу или компьютер)? Что мне делать?

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

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

          И все это по одной простой причине, каждый объект Active Directory содержит дополнительную информацию, не видимую простому пользователю. Этой информацией является SID объекта. Что же это такое. Для начального понимания предлагаю пример из жизни. Налоговая Инспекция Российской Федерации должна отличать каждого налогоплательщика в стране. Но как быть, если в Стране тысячи Ивановых Иванов Ивановичей, как распознать, кто есть кто. Очень просто выдать каждому по уникальному номеру. Проблема решена. Похоже, решается и проблема уникальности в Active Directory.

          Security Identifier (SID) это идентификатор безопасности, который уникально идентифицирует, учетную запись пользователя, группы или компьютера. (Проще говоря, уникальный номер)

          SID присваивается каждой учетной записи в момент её создания. Система работает с SID’ами учетных записей, а не их именами. В контроле доступа пользователей к защищаемым объектам (файлам, ключам реестра и т.п.) участвуют также только SID’ы.

          Может возникнуть вопрос – Я же вижу имена учетных записей при настройке прав к папке на диске с файловой системой NTFS. Где там SID`ы?

          Отвечу очень просто, вы видите это, потому что работать непосредственно с SID было бы очень неудобно. Компьютер облегчает вам задачу и показывает имена, а не SID`ы.

          Пример SID’ a (S-1-5-21-1986275044-495590890-615916108)

          Попробуйте запомнить два десятка таких 🙂

          Вернемся к главной теме.

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

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

          Для того, чтобы ответить на этот вопрос, надо разобраться с тем, что происходит после того как вы нажали «Удалить» и объект пользователя или компьютера исчез из оснастки Active Directory User and Computers. Сразу хочу обрадовать, наш объект не исчез из Active Directory и не удалился бесследно. Он спрятался и ждет, ждет, пока вы одумаетесь и вернете его. Сразу вопрос, сколько же он будет ждать?

          Ответ, это зависит от того на базе каких версий Windows Server построена ваша Active Directory.

          Срок ожидания равен (это параметр правильно называется «tombstoneLifetime»):

          60 дням для лесов, построенных при помощи Windows® 2000 и Windows Server 2003

          180 дней для лесов, построенных при помощи Windows Server 2003 SP1, Windows Server 2008/R2

          Что самое интересное, «tombstoneLifetime» (давайте называть вещи своими именами, теперь мы знаем что значит данный термин) это параметр на который вы можете влиять, т.е давать ему значение по своему усмотрению.

          Посмотреть текущее значение «tombstoneLifetime» и поменять его можно следующим способом.

          Вам понадобится оснастка ADSI Edit.

          image

          Рис. 1. Открываем оснастку и выбираем “Connect to..

          image

          Рис. 2. Подключение.

          В показанном на рисунке 2 окне, выбираем «Select or Type a Distinguished Name» и в пустом поле вводим путь «CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=<корневой домен>». Где <корневой домен> это имя вашего домена.

          Мой домен назывался – testlab.local и строка пути выглядела следующим образом:

          «CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=testlab,DC=local»

          После ввода нажимаем “OK” и если вы все сдали правильно, в оснастке появится новый контекст именования, который нам необходимо развернуть и зайти в свойства введенного пути.

          image

          Рис. 3. Заходим в свойства введенного пути.

          image

          Рис. 4. Изменение атрибута «tombstoneLifetime»

          В открывшемся меню находим атрибут «tombstoneLifetime» , как вы видите на моем контроллере домена под управлением Windows Server 2008 R2 Beta, он равен 180 дням.

          Сделаем второй вывод: Теперь мы не только точно можем узнать, сколько будет храниться в нашей базе данных удаленный объект, но и изменить это время по своему желанию. Ради справедливости следует заметить, что делать это практически нет необходимости. Как только объект устаревает, т.е находится в удаленном состоянии более срока «tombstoneLifetime», он удаляется из базы данных и больше вы не сможете его восстановить. Т.е любые операции по восстановлению только до истечения срока «tombstoneLifetime», позже нельзя. Запомните это.

          В некоторых статьях в интернете и некоторых книгах приводятся способы восстановления объектов Active Directory после истечения срока «tombstoneLifetime», относитесь к этому как к трюкам экстремалов, как к высшему пилотажу. В определенно отведенном месте это имеет место быть, в городских или в вашем случае рабочих условиях неподготовленный человек просто свернет голову, а вы потеряете всю Active Directory.

          Отлично со временем «загробной жизни» наших объектов мы разобрались. Теперь необходимо понять где находятся наши объекты после удаления и до того как они окончательно исчезнут.

          После удаление объекты попадают в контейнер «Deleted Objects». Не пытайтесь увидеть его содержимое через оснастку Active Directory User and Computers. У вас это не получится. От глаз «простых смертных» он надежно спрятан. 🙂

          Для того чтобы все-таки увидеть сам контейнер и те объекты, которые были удалены нам понадобится одна из двух вещей. Либо служебная программа «LDP», схожая с проводником Windows, для работы с Active Directory, либо утилита «Ad Explorer» из комплекта легендарных утилилит Sysinternals. Ни одна, ни вторая не установлена при новой инсталляции Windows Server 2003. В Windows Server 2008 и 2008R2 программа «LDP» входит изначально.

          LDP можно получить установив на свой сервер Windows 2003 Support tools, комплект утилит, свободно скачиваемых с сайта Microsoft.

          Утилита «Ad Explorer» доступна свободного скачивания с Веб-узла Windows Sysinternals.

          Я воспользуюсь «Ad Explorer» так как, на мой взгляд, для данной цели она более дружелюбна.

          image

          Рис. 5. Подключение через утилиту AdExplorer.

          Запустив AdExplorer, вы сразу сталкиваетесь с окном, предлагающим вам ввести имя домена, к которому вы хотите подключиться, а также имя Администратора и его пароль. Вводим, нажимаем «ОК».

          После разворачиваем раздел нашего домена и видим скрытый до этого контейнер «Deleted Objects».

          image

          Рис. 6. Контейнер Deleted Objects

          Разворачиваем контейнер Deleted Objects и не пугаемся количеству объектов хранящихся в нем, в моем примере, я легко нахожу удаленную запись пользователя Bill Gates по иконке и имени. (Рис.7.)

          Теперь перед нами возникает другая проблема, как вернуть учетную запись обратно в оснастку “Active Directory User and Computers” и позволить пользователю полноценно работать, что он, собственно говоря, и делал до удаления. И опять перед вами есть два пути.

          Первый путь является более сложным и предназначен для администраторов хорошо знакомых с алгоритмом удаления/ восстановления объектов Active Directory. Путь пролегает через использование уже знакомой вам утилиты Ldp.exe.

          Суть процесса выглядит следующим образом. При удалении и попадании учетной записи в «Deleted Objects » к имени пользователя добавляется DEL , а также в атрибутах объекта пользователь атрибут «isDeleted» переходит в состояние TRUE, что значит истина, а на языке простых смертных состояние включен. Соответственно что бы учетка вернулась в нормальное состояние, нам необходимо используя Ldp.exe выключить этот атрибут и заменить то, что имеем на нормальное имя. Повторюсь еще раз это более сложный путь, и я его описывать не буду. Для тех, кто выбирает сложные есть Google и встроенная справка.

          image

          Рис.7. Удаленный объект в Deleted Objects

          image

          Рис. 8. Adrestore

          Мы пойдем по второму пути, а именно воспользуемся утилитой командной строки от Sysinternals под названием «AdRestore». Не путайте, пожалуйста, с «AdExplorer» у них похожие названия, но разное назначение. У кого данной утилиты еще нет, скачиваем ее с сайта Microsoft. Распаковываем данную утилиту на диск C:\ и запускаем с командной строки.

          Синтаксис команды достаточно простой, чтобы восстановить пользователя Bill Gates я ввел утилиту с ключом “-r” и явно указал имя пользователя для восстановления. Если вы хотите посмотреть полный список доступных объектов, вводите AdRestore без ключа.

          Итак, объект восстановлен, теперь мы можем его обнаружить в оснастке «Active Directory User and Computers»

          image

          image

          Рис. 9 Пользователь после восстановления.

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

          Теперь я могу сформулировать третий вывод. При удалении учетной записи и помещения ее в контейнер Deleted Objects теряются все атрибуты записи, кроме SID, ObjectGUID, LastKnownParent и SAMAccountName и при возвращении записи, указанным способом они не восстанавливаются. В том числе и пароль пользователя.

          Что такое SID вы уже знаете, ObjectGUID это еще один идентификатор нашего объекта, LastKnownParent это путь контейнеру в котором находился объект до удаления, а SAMAccountName – имя для входа пользователя. Все остальное, увы, так легко не вернется.

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

          В статье Джил Киркпатрика (Gil Kirkpatrick) под названием «Восстановление объектов-захоронений Active Directory» есть краткое описание того, что мы может путем некой манипуляции заставить атрибуты объектов сохраняться при удалении. И естественно при восстановлении они также будут доступны. Я пойду дальше и распишу этот процесс. Сразу скажу, что атрибуты уже удаленных записей это не вернет.

          План наших действий будет такой:

          1. Откроем оснастку ADSI Edit

          2. Выберем «Подключиться к» или «Connect to»

          3. В появившемся окне выбрать подключение к разделу Схема нашей Active Directory

          4. Найти нужный нам атрибут и зайти в его свойства.

          5. В свойствах атрибута найти параметр «searchflags»

          6. Включить третий бит в значении параметра «searchflags»

          Пугаться плана не стоит, сейчас мы подробно разберемся в данном процессе. Я буду выполнять данную операцию на Windows Server 2008R2 Beta, но на младшей версии Windows Server 2003 процесс будет аналогичным.

          image

          Рис.10 Запускаем ADSI Edit и выбираем «Connect to»

          image

          Рис 11. В появившемся окне выбираем подключение в Схеме Active Directory. (Schema)

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

          image

          Рис. 12 Список атрибутов.

          Я приведу пример соотношения имен в свойствах объекта и схеме следующей иллюстрацией, созданной Ильей Сазоновым в его блоге. Если вы хотите посмотреть полную картину соотношений, то советую перейти по следующей ссылке.

          http://msdn.microsoft.com/en-us/library/ms677980(VS.85).aspx

          image

          Рис.13 Имена атрибутов Active Directory в схеме. (Указаны красным цветом)

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

          CN= company

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

          image

          Рис.14 Поиск нужного атрибута.

          После нахождения нужного атрибута открываем его двойным щелчком мыши и на закладке «Attribute Editor» ищем параметр «searchflags». У каждого атрибута он свой и представлен десятичным числом. В моем случае «searchflags» равен 16.

          image

          Рис. 15 Параметр «searchflags» для атрибута «Company»

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

          Для того чтобы перевести десятичное число 16 в двоичное я воспользуюсь инженерным калькулятором. В двоичном виде я получил «100000». Что значит включить третий БИТ? Значит, третий бит должен быть равен «1»

          Находим третий бит. Считаем справа на лево.

          «1 0 0 0 0 0»

          Первый справа 0-й бит

          Второй справа 1-й бит

          Третий справа 2-й бит

          Четвертый справа 3-йбит. Тот, который нужно включить.

          Меняем его на «1» и получаем в двоичной системе «101000», что и переводим десятичную систему тем же инженерным калькулятором. Получаем «40». И именно эти «40» и ставим в значении «searchflags». Нажимаем «Ок» и закрываем все лишнее. Теперь для проверки правильности действий, вы можете создать новую учетную запись и ввести атрибут «Company». После чего ее удалить и восстановить с помощью утилиты «Adrestore». При правильном выполнении вышеописанной процедуры при восстановлении учетной записи атрибут «Company» не будет потерян.

          Вывод третий. Да, мы можем прописать параметр «searchflags» и при восстановлении объекта Active Directory эти атрибуты теряться не будут. НО, следует помнить, что есть особенные атрибуты описывающий членство нашего пользователя в группах Active Directory. К сожалению, подобным образом защититься от его удаления нельзя. Существует способ восстановления членства в группах, но в данной статье он рассмотрен не будет, т.к требует знакомства еще с рядом понятий.

          А сейчас я бы хотел перейти к новой возможности, которая стала доступна с выходом Windows Server 2008 R2 под названием «Active Directory Recycle Bin»  или Корзина удаленных объектов. Она предназначена для решения как раз наших проблем.
          Для начала немного теории.  Жизненный цикл цикл объекта  «Active Directory»  в любой версии Windows Server выглядит одинаково. (Рис.16) Разница лишь в сроке хранения захороненного объекта. (tombstoneLifetime). По умолчанию в Windows Server 2008 R2 «Active Directory Recycle Bin»   отключена.

          image

          Рис. 16 Жизненный цикл объекта Active Directory.

          При включении «Active Directory Recycle Bin» схема удаления несколько меняется. Главное преимущество которое мы получаем, это возможность восстановить удаленный объект с сохранением все атрибутов без перезагрузки и резервной копии. («типа link-valued» – как пример «Членство в группах» и «типа non-link-valued» – как пример «Компания»)

          image

          Рис. 17 Жизненный цикл объекта Active Directory при включенной «Active Directory Recycle Bin».

          При включенной корзине после удаления объекты также попадают в контейнер «Deleted Objects», но теперь с сохранением всех атрибутов, объекту присваивается статус «logically deleted» и находятся, он в таком состоянии в течение определенного времени, на схеме время показано как «Deleted object lifetime». Пока не истекло это время, вы можете спокойно восстановить объект из корзины без каких либо последствий.

          По прошествии времени «Deleted object lifetime», у объекта меняется статус на «recycled object» и большинство его атрибутов удаляется. После чего он продолжает храниться в течении «Recycled object lifetime» промежутка. По окончании, которого он удаляется из базы.

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

          Необходимо:

          a) Убедить, что все контроллеры домена в лесу работают под управлением Windows Server 2008 R2

          b) Поднять уровень нашего леса до Windows Server 2008 R2

          c) Если лес изначально создавался на базе Windows Server 2003 – осуществить обновление схемы

          Примечание: Для обновления схемы: выполнить adprep /forestprep на контроллере домена с ролью «schema master», выполнить adprep /domainprep /gpprep на контроллере домена с ролью «infrastructure operations master». Если есть контроллер домена только для чтения (RODC) запустить на нем adprep /rodcprep.

          Ну что ж, теперь давайте проверим новый функционал. В моей лабораторной среде только один контроллер домена под управлением Windows Server 2008 R2, так что подготовительные пункты а) и с) я опускаю. Первый по причине отсутствия других контроллеров домена, второй поскольку я поднимал лес на Windows Server 2008 R2 изначально.

          Но поднятие уровня леса мне придется осуществить. На текущий момент мой уровень леса стоит По-умолчанию Windows Server 2008. Можете осуществить поднятие классически через оснастку «Active Directory Domain and Trust», а можно воспользоваться Active Directory PowerShell.

          image

          Рис.18 Поднятие уровня леса (Click Start, click Administrative Tools, right-click Active Directory PowerShell)

          При этом необходимо выполнить:

          Set-ADForestMode –Identity testlab.local -ForestMode Windows2008R2Forest

          Постойте! Скажут те из вас кто хорошо знаком с Active Directory. Ведь для поднятия леса нам необходимо сначала поднять уровень домена? Да, в Windows Server 2003 вам нужно было сделать именно так. В Windows Server 2008 R2 автоматически поднимает уровень доменов, упрощая достижение цели на несколько кликов мышью.

          Все предварительные этапы пройдены и теперь мы готовы включить «Active Directory Recycle Bin». Сделаем это опять же из «Active Directory PowerShell» выполнив командлет:

          Enable-ADOptionalFeature –Identity  ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=testlab,DC=local’   –Scope Forest  –Target ‘testlab.local’

          image

          Рис. 19 Включение «Active Directory Recycle Bin»

          Естественно при выполнении команд не забудьте поменять имя домена, заменив testlab.local на имя вашего домена.

          Теперь задача выполнена и «Active Directory Recycle Bin» работает.

          Что хотелось бы отметить:

          А) Приятного графического способа работы с «Active Directory Recycle Bin» на текущий момент нет. Майкрософт рекомендует два способа работы с корзиной. Первый через утилиту Ldp.exe. Второй через командлеты «Get-ADObject-Filter» и «Restore-ADObject» .

          Б) Лично я использовал для восстановления объектов утилиту “AdRestore”. При включенной корзине все атрибуты и пароль пользователя восстановились вместе с учетной записью.

          В) Время, выделяемое на «Deleted object lifetime» и «Recycled object lifetime» можно менять. Если время «Deleted object lifetime» не задано явно, а по умолчанию оно не задано, то равно продолжительности параметра «tombstoneLifetime», т.е 180-и дням. Остается еще один параметр «Recycled object lifetime» – период времени, когда атрибуты уже уничтожены, но объект еще существует, при определении этого времени используется параметр «tombstoneLifetime». Именно в нем это время и прописывается.

          Итоги:

          Прежде всего, хотелось бы отметить, что Active Directory имеет механизм восстановления учетной записи без перезагрузки контроллера домена в режим «Восстановления Службы Каталогов» и остановки его работы. В Windows Server 2008 R2 это механизм был усовершенствован с помощью «Active Directory Recycle Bin», при этом решена проблема сохранения атрибутов удаленных объектов. Конечно, у вас могу остаться вопросы. А что будет, если пользователь имел Exchange-атрибуты? Что станет с теми учетными записями, которые были удалены до включения корзины? Что еще можно восстановить таким способом? Ответы на них каждый желающий может найти на сайте technet.microsoft.com или проведя несколько лабораторных работ, развернув на виртуальном стенде несложную инфраструктуру. И напоследок старые добрые советы: не работайте с правами доменного администратора, используйте делегирование прав, читайте документацию и отключайте учетные записи вместо удаления. Удачи.

          Рудь Илья

          MCSE/MCT

          me@rudilya.ru

        • Главная Exchange/UC, Новое Exchange 2007
          • Обзор технологий высокой доступности Exchange Server 2007 и настройка Standby Continuous Replication.

            e12icon[7] Корректное функционирование и доступность почтовых систем становятся все более и более критичными для бизнеса.  Почтовые системы выросли от просто инструмента обмена письмами до средства групповой работы. Сегодня нередко от администраторов почтовых систем требуют обеспечить высокую доступность сервиса.
            Как обеспечить отказоустойчивость почтовых серверов? Что такое высокая доступность? Какие технологии высокой доступности есть в Exchange Server 2007 и в чем разница между ними? Как обеспечить высокую доступность почтовых серверов с минимальными затратами? В данной статье я попробую ответить на эти и другие вопросы

            В первоначальном выпуске Exchange 2007 (RTM) существовало три технологии для обеспечения высокой доступности и отказоустойчивости. В данной статье я хотел бы более подробно остановится на четвертой технологии – Standby Continuous Replication, включенной в состав Service Pack 1 для Exchange Server 2007. Почему именно на ней? Во-первых, эта технология включена в функционал Exchange Server Standard Edition.

            Табл. 1. Технологии обеспечения высокой доступности и выпуски Exchange Server.

            Exchange Standard Edition

            ( $ 728,42 или 25 879,45 p.)

            Exchange Enterprise Edition

            ($ 4 166,03 или 148 011,55 p)

            Local Continuous Replication (LCR)

            Поддерживается

            Поддерживается

            Standby Continuous Replication (SCR)

            Поддерживается

            Поддерживается

            Cluster Continuous Replication (CCR)

            Не поддерживается

            Поддерживается

            Single Copy Cluster (SCC)

            Не поддерживается

            Поддерживается

            Примечание: Стоимость и курс доллара даны на начало марта 2009 года и являются примерными. В данном случае стоимость взята с сайта ms-expert.ru. Точная стоимость зависит от «жадности» продавца.

            Во-вторых, технология достаточно новая и не включается с помощью графических мастеров.

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

            Краткий обзор технологий обеспечения высокой доступности.

            Local Continuous Replication (LCR). Есть два жестких диска на одном сервере (вторым жестким диском может быть, например SAN). База почтовых ящиков работает на одном диске, второй диск хранит пассивную копию базы данных. Первоначально копируется база на второй диск и затем ее идентичность базе на первом диске обеспечивается за счет доставки и применения журналов транзакций. В случае падения первого диска мы имеем возможность восстановить базу со второго диска (например, подключив его под той же буквой или используя Volume Mount Point под тем же именем папки, как и оригинальная база). В отличие от восстановления с резервной копии получается значительный выигрыш во времени восстановления – база уже есть, журналы транзакций на нее применены, остается только настроить ее подключение на место оригинала. Переключение ручное. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – жесткий диск. Самая дешевая технология. Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

            Cluster Continuous Replication (CCR). Настраивается два сервера в кластер. У каждого узла свой диск. Один узел хранит активную базу, второй пассивную. Идентичность баз обеспечивается за счет доставки и применения логов на пассивный узел. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP адрес). Кроме того настраивается сервер-свидетель который служит для корректного автоматического переключения в случае отказа одного из узлов. Переключение автоматическое. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – сервер. Технология подороже. Требуется выпуски Windows Server Enterprise Edition и Exchange Server Enterprise Edition, еще как минимум один сервер (свидетелем может быть любой другой сервер даже не с Exchange). Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

            Single Copy Cluster (SCC). Кластер в классическом понимании. Есть два компьютера – оба подключены к одному внешнему хранилищу. Оба компьютера могут работать с одной и тоже базой (база то доступна обоим компьютерам), но в один момент времени только один компьютер обслуживает одну базу. В случае его отказа второй компьютер автоматически берет на себя обслуживание базы. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP-адрес). Свидетель не требуется. Самая дорогая технология, так как по сравнению с CCR требуется еще определенное железо, которое поддерживает такую кластеризацию. Точка отказа – сервер.

            Standby Continuous Replication (SCR). Как можно увидеть технологии, которые позволяют избежать неработоспособности в случае отказа сервера до SP 1 были включены только в Enterprise Edition Exchange Server 2007. Local Continuous Replication не обеспечивала доступности в случае отказа сервера, только в случае отказа жесткого диска. В SP1 встроена технология обеспечения доступности в случае отказа сервера в редакции Standard – это SCR. Технология позволяет доставлять транзакционные лог файлы на другой сервер и применять их. В случае падения сервера, несущего нагрузку по обслуживанию рабочей базы – мы можем переключить пользователей на второй сервер уже готовый их обслуживать (он настроен – база есть).

            Что необходимо учесть:

            1. Поддерживается сколь угодно много серверов, на которые доставляются журналы в случае с SCR (рекомендуется не более четырех). В LCR и CCR поддерживается только один получатель.

            2. В случае LCR и CCR журналы транзакций применяются автоматически и практически сразу. В случае SCR по умолчанию журналы транзакции не применяются сразу после доставки – должно выполнится два условия (эту логику частично можно изменить):

            a. Должно быть доставлено 50 журналов с рабочего сервера.

            b. Должно пройти 24 часа с момента доставки журналов на сервер – получатель.

            3. Нельзя использовать разные ОС на источнике и получателе. Например, нельзя, чтобы на источнике была Windows Server 2003 а на получателе Windows Server 2008.

            4. Как и для LCR и CCR также и для SCR требуется чтобы была только одна база данных в одной группе хранения (Storage Group).

            Итак, после теоретической части включим и настроим SCR.

            Часть 1. Настраиваем SCR.

            В итоге мы должны пройти через следующие этапы:

            1. Включение SCR

            2. Имитацию падения рабочей базы

            3. Восстановление почты из копии.

            Сценарий. Есть два сервера. Оба под управление Windows Server 2008, на обоих серверах установлен Exchange Server 2007 SP1. Один сервер (SYD-DC1) является рабочим сервером, второй сервер (SYD-EX2) является сервером для копии.

            image

            Рис.1 Создаем на рабочем сервере группу хранения:

            Имя группы SCR-SG, месторасположение E:\ExchDataSCR.

            Создаем в данной группе хранения почтовую базу SCR-DB

            image

            Рис 2. Место хранения E:\ExchDataSCR\SCR-DB.edb

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

            После подготовки базы, можно в ней завести пользователей, я заведу пользователя для тестирования работоспособности и отработки механизма переключения пользователя. Итак, я завожу пользователя Vasya Pupkin с почтовым ящиком в данной базе (SCR-DB)

            image

            Рис.3

            image

            Рис.4 Отправляю несколько писем от Администратора и обратно к нашему Васе.

            Теперь давайте настроим SCR. Как я уже писал, настраивается только с помощью Power Shell. Для настройки репликации необходимо запустить командлет на рабочем сервере :

            Enable-StorageGroupCopy « группа хранения» -StandbyMachine «имя удаленного сервера»

            В нашем случае группа хранения SCR-SG, удаленный сервер SYD-EX2. В итоге мы запускаем

            Enable-StorageGroupCopy SCR-SG -StandbyMachine SYD-EX2

            image

            Рис. 5 Внимание базу указывать не надо SCR включается на уровне группы хранения.

            Я указал параметр –RelayLagTime и поставил значение 0.0:0:0 (дни.часы:минуты:секунды). Напомню, что по умолчанию для применения журналов транзакций в SCR должно быть выполнено два условия:

            1. Должно быть доставлено 50 журналов (доставляются как только они зарываются – после достижения размера в 1 Мб).

            2. Должно пройти 24 часа с момента доставки.

            Я изменил второй параметр и указал применять сразу после доставки 50 логов. Можно его настроить в диапазоне от 0 секунд до 7 дней. Первый параметр изменить нельзя. Такая задержка была встроена специально. Представим себе, что у Вас повредилась рабочая база, причем ее повреждение было вызвано некорректным письмом. В случае мгновенной доставки и применения логов это некорректное письмо будет отображено во всех базах и все базы будут неработоспособны. При наличии задержки мы можем предусмотреть эту ситуацию и, например не применить на сервере транзакционные лог файлы с некорректным письмом и вернуться к работоспособному состоянию. Эти параметры нельзя изменить в последующем. Для их изменения Вам придется перенастроить SCR.

            Кроме того есть еще параметр TruncationLagTime. Он отвечает за время, через которое журналы транзакций, доставленные на второй сервер и примененный будут удалены.

            Еще один важный момент у меня база на диске E. На сервере получателе должен быть диск с буквой E иначе не создастся SCR. Обратите внимание, что мы на сервере получателе ничего не делали, ни создавали базу данных , ни группу хранения. Единственное требование – идентичная серверу источнику операционная система и наличие диска с такой же буквой, какая у диска на которой хранится боевая база данных.

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

            image

            Рис.6

            Обратите внимание, что на втором сервере в момент выполнения командлета Enable-StorageGroupCopy создалась на диске E папка ExchDataSCR (соответствует названию папки группы хранения рабочего сервера) и в ней появились логи. Причем только логии и самой базы нет (не доставлено еще 50 логов). Логов всего 7.

            image

            Рис.7 Я сымитировал ведение деловой переписки Васей

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

            image

            Рис.8

            Стало всего восемь логов на сервере получателе. Также мы можем убедиться в корректности работы SCR с помощью командлета Get-StorageGroupCopyStatus. Обратите внимание, что данный командлет был запущен на сервере-источнике (вверху на синей полосе контекст SYD-DC1)

            Get-StorageGroupCopyStatus SCR-SG –StanbyMachine Syd-ex2

            image

            Рис 9. Командлет проверки состояния SCR на сервере-источнике

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

            image

            Рис 10. Командлет проверки состояния SCR на сервере-получателе.

            В консоли управления Exchange на сервере получателе Вы не увидите базы SCR-DB.

            image

            Рис 11. Консоль управления Exchange на сервере – получателе.

            Все репликация настроена.

            Часть 2. А что если все-таки база упадет?

            Теперь давайте сымитируем падение рабочей базы.

            Я отмонтирую базу на рабочем сервере и для чистоты эксперимента удалю ее файлы.

            image

            Рис. 12 Отмонтированная база на сервере-источнике и удаленные файлы из места расположения базы.

            Теперь нам необходимо восстановить базу на сервере получателе (SYD-EX2).

            Для этого необходимо выполнить командлет

            Restore-StorageGroupCopy SYD-DC\SCR-SG –StandbyMachine SYD-EX2 –Force

            Параметр Force я указал, так как недоступна оригинальная база, если бы она была доступна, то я бы указал без этого параметра.

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

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

            image

            Рис. 13 Создание SG на сервере получателе

            image

            Рис.14 Создание базы данных на сервере получателе.

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

            Move-StorageGroupPath SYD-EX2\RecoveredSCR-SG -SystemFolderPath E:\ExchDataSCR -LogFolderPath E:\ExchDataSCR –ConfigurationOnly

            Move-DatabasePath  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -EdbFilePath E:\ExchDataSCR\SCR-DB.edb  –ConfigurationOnly

            На все вопросы говорю Yes

            image

            Рис. 15 Перемещение путей на сервере получателе.

            База данных находится в отмонтированном состоянии. Для ее подмонтирования я должен поставить галочку «This database can be overwritten by a restore» в свойствах базы или выполнить командлет

            Set-MailboxDatabase SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -AllowFileRestore:$true

            и подмонтировать базу опять же либо с помощью консоли управления Exchange либо с помощью командлета

            Mount-Database SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

            База готова. Однако у пользователей в AD до сих пор ссылка на место хранения своей почты на сервер SYD-DC1. Нам необходимо провести замену этой ссылки и сказать, что теперь у пользователей база на SYD-EX2. Это делается опять же с помощью командлета Move-Mailbox с добавочкой –ConfigurationOnly.

            Важно! Необходимо, чтобы перемещались почтовые ящики всех кроме системного помощника Exchange и системные ящики.  Для этого я наберу командлет:

            Get-Mailbox -Database SYD-DC1\SCR-SG\SCR-DB |where {$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox| ExOleDbSystemMailbox)’}| Move-Mailbox -ConfigurationOnly -TargetDatabase  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

            image

            Рис.  17 Перемещение почтовых ящиков.

            Все я готов к работе. Давайте войдем как VasyaPupkin.

            image

            Рис. 18 Вся важная деловая переписка сохранена.

            image

            Рис. 19 Почтовый ящик пользователя на новой базе.

            Для пользователя все прозрачно. Если у пользователя Outlook 2003, то необходимо будет еще переуказать путь к новому серверу в его профиле Outlook. Для Outlook 2007 с настроенным Autodiscovery неактуально. Теперь можем опять настроить SCR. Итог.В этой статье мы прошли с Вами через весь процесс создания SCR и познакомились с основными концепциями ее работы.

            Хочу привести командлеты для настройки:

            Disable-StorageGroupCopy – Отключает назначение репликации SCR для группы хранения.

            Get-StorageGroupCopyStatus –  Определяет текущее состояние назначения репликации SCR.

            New-StorageGroup –  Создает новую группу хранения с поддержкой SCR, при этом не требуется отдельно включать SCR с помощью командлета Enable-StorageGroupCopy.

            Restore-StorageGroupCopy – Отключает SCR и делает базу данных назначения SCR пригодной для присоединения с помощью операции Mount-Database в процедуре восстановления.

            Resume-StorageGroupCopy –  Восстанавливает непрерывную репликацию для группы хранения, в которой она была приостановлена.

            Suspend-StorageGroupCopy – Приостанавливает непрерывную репликацию для группы хранения, в которой она была включена.

            Update-StorageGroupCopy –  Используется для заполнения целевой группы хранения.

            Николай Муравлянников, MCITP, MCSE

          • Главная Security, Windows, Новое Security, Windows Vista
            • Настройка безопасности Windows Vista

              Все чаще и чаще дома и на работе мы используем новую ОС от фирмы Microsoft – Windows Vista.

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

              С уважением Безмалый Владимир
              MVP Consumer Security