Я только что вернулся с ежегодного саммита Microsoft MVP, где те, кто получал награды, общались с разработчиками и спикерами. В секции “службы директорий” – той категории, на которой я специализируюсь – довольно редко было слышно о радикальных изменениях. Обычно интерес вызывал релиз новой операционной системы и то, насколько крупным он должен быть. Но в этом году, определения “новый релиз” и “большой релиз” можно смело отнести к AD. Я собираюсь рассмотреть основные изменения в идентификации и безопасности, которые встроены в Windows Server 8.
Имейте в виду, что эти изменения квалифицируются как эволюционные, а не революционные. Они расширяют то, что мы хорошо знаем в Active Directory. Microsoft Program Manager Nathan Muggli однажды сказал: “Внедрение изменений в Active Directory – как приготовление пиццы для миллиона человек – каждый хочет чего-то особенного”. Естественно никто не хочет раскачивать лодку, в которой находятся 75% мировых компаний. Но эволюционные изменения необходимо, несомненно, и они могут обозначать направление будущего совершенствования продукта. В системе идентификации и безопасности Windows 8, эти изменения включают управление данными, AD и виртуализация.
Управление данными
Перед тем, как я углублюсь в описание изменений в системе идентификации в Windows Server 8, я бы хотел указать на одно изменение, которые Microsoft добавила в Windows Server 2008 R2: Инфраструктура классификации файлов (File Classification Infrastructure (FCI)). Эта новая функция ускользнула от меня, как, возможно, и Вас, потому что это скорее функция файловой системы, а не системы идентификации. Вы увидите, как FCI связана с системой идентификации чуть позже, но сначала я хочу объяснить, что такое FCI.
FCI дает возможность определять свойства классификации файлов (File-classification properties) для ваших файловых серверов, автоматически классифицировать файлы в соответствие с папкой, в которой они находятся или же содержимым этого файла, осуществлять управление файлами, например, устанавливать срок, в течение которого возможен доступ к файлу, задавать стандартные команды, основанные на классификации файлов, и генерировать отчеты, которые показывают распределение классификационных свойств на файловом сервере. Без FCI конечный пользователь (владелец контента) может вручную классифицировать файлы или ряд приложений (line of business) может автоматически установить классификационные свойства файлов. Вы даже можете использовать FCI для поиска по содержимому файлов по конфиденциальным ключевым словам или паттернами, таким как номера социального страхования (social security numbers) и автоматически классифицировать файл, как конфиденциальный и содержащий персональные данные.
Что в этом полезного? С FCI администраторы могут, например, автоматически перемещать данные из дорогих онлайн хранилищ в менее дорогие хранилища, основанные на классификации файлов и той политике, которую Вы зададите. Или вы можете сделать так, чтобы по истечению определенного периода времени файлы были недоступны. Вы можете поиграться с настройками FCI через утилиту File Server Resource Manager (FSRM), сначала установив эту функции, а потом запустив через Administrative Tools. Эта та же самая утилита, которая позволяет контролировать квоты, скрининг и отчеты по хранению (storage reports). Что релевантно по отношению к этой дискуссии, так это то, что FCI является одним из краеугольных камней действительно крупной функции Windows Server 8 в области идентификации и безопасности: Динамический контроль доступа (Dynamic Access Control).
DAC – одна из наиболее мощных новых функции в Server 8. На самом общем уровне, она связана с управлением информацией: классификация данных, находящихся на ваших файловых серверах, получение высокой степени контроля над этими данными, возможность продемонстрировать (например, в ходе аудиторской проверки), что Вы осуществляете такой контроль. Это сейчас критическая потребность в IT-инфраструктуре, порожденная взрывным ростом данных, ростом внешних угроз и тех затрат, которые несет компания при образовании брешей в безопасности. FCI – элемент DAC, потому что она предоставляет механизм классифицировать файлы и присваивать им теги, от которого зависит применение политик DAC.
Active Directory
Также в выигрыше от проекта DAC является AD. Теггирование и классификация данных на файловых серверах – это, конечно, хорошо, но польза этого невысока, если Вы не можете контролировать доступ к этим данным, основываясь на новом уровне детализированности, которым Вы обладаете. Чтобы контролировать доступ на этом уровне, Вам необходимо внести существенные изменения в Local Security Authority (LSA) на файловом сервере и в AD. Оставим изменения на потом, и рассмотрим изменения в AD, так как они фундаментально важны, и они указывают на будущее AD.
Чтобы поддержать более высокую степень контроля доступа на файловых серверах – и на всех остальных ресурсах, которые поддерживают списки контроля доступа (ACL) в будущих релизах ОС – AD должна поддерживать заявки (claims). Если Вы не знакомы с заявками, то они представляет просто еще одну сторону подтверждения подлиннности, заявка – это информация (например, email), которую доверенный источник (например, ваш local certificate authority – CA) передает относительно записи (например, вашей учетной записи). Заявки уже lingua franca “облачной идентификации” и они являются базовым компонентом технологии федерации, которая позволяет нам защищенно расширять локальную идентичность (identity) в облачные службы. Но до Server 8 в AD не было слышно о заявках, мы должны полагаться исключительно на Active Directory Federation Services (AD FS), чтобы трансформировать атрибуты в заявки. Эти заявки потреблялись в большинстве своем внешними службами, потому что традиционные организационные приложения их не понимали. Теперь это изменилось, и AD также меняется, чтобы приспосабливаться к ним. Это изменение в AD очень важно, и каждый AD администратор должен понимать, что cloud-based идентичность станет частью его будущей работы.
Что касается усовершенствований в Server 8, связанных с AD, наибольшим усовершенствованием, которое осуществила команда разработчиков AD, стала возможность экономить время и усилия по развёртыванию AD. Любой, кто проводил время на форумах, посвященных AD, знает, что вопросы развёртывания о Adprep, Dcpromo, дупликации и виртуализации контроллеров доменов и решения, связанные с развёртыванием DNS являются наиболее частыми. Эти изменения определенно подпадают в эволюционную категорию, и они усовершенствованы для текущих функций AD.
Обновление и повышение роли контроллеров домена также были значительно усовершенствованы. Команда AD объявила собравшимся MVP, что “Adprep и Dcpromo мертвы”. Dcpromo теперь представляет собой мастер Active Directory Domain Services Configuration Wizard, который полностью интегрируется с Server Manager. Мастер прост в использовании, но что более важно, мастер конфигурирования делает массу работы невидимой, чтобы сделать повышение роли как можно безболезненным.
Мастер автоматически берет на себя процессы Adprep /forestprep и /domainprep (хотя Вы можете запустить их вручную, если хотите). Dean Wells, бывший ведущий AD консультант, кто сейчас входит в команду Microsoft AD, заметил, что было ошибкой открывать процесс Adprep администраторам, так как порождаемый страх и лавина звонков в службу поддержки, который он создавал, перевешивал реальные проблемы, вызванные процессом. Процесс повышения серьезного анализа (чтобы ответить на вопрос: “а надо ли?”) перед тем, как начать его осуществление, так что если у Вас возникают проблемы в вашей AD среде, повышение даже и не думало заканчиваться. Это также стало более терпимо к временным проблемам сети, имеется некоторые улучшенные IFM опции, и полноценно можно взаимодействовать удаленно.
Виртуализация
Еще одним аспектом упрощения развертывания AD стало создание виртуальных контроллеров домена своеобразным “бронежилетом”, что обеспечивает безопасность клонирования контроллера домена. Восстановление виртуального контроллера домена из резервной копии образа или предыдущего снапшота порождало риск возникновения ущерба (возврат USN) для целостности ссылок всей распределенной базы данных в домене или лесе, потому что в отличие от стандартных процедур восстановления, восстановленный контроллер домена не содержал в себе информации о том, что он был восстановлен. В доменных службах Active Directory в Windows Server 8 был представлен VM-Gen ID, уникальный 64-битный идентификатор (похожий на GUID), ассоциированный с гипервизором. Цель VM-Gen ID – фиксировать снапшоты и передавать их виртуальной машине. С таким уведомлением, на контроллере домена будут предприниматься защитные меры (такие как отказ записи идентификатора – RID – и сброс обращения ID), чтобы предотвратить возврат USN. Одним словом восстановление стало проще.
Клонирование контроллера домена, которое эти безопасные с точки зрения виртуализации усовершенствования сделали безопасной и поддерживаемой опцией, имеет свои преимущества. Клонирование позволяет свести с минимуму процесс повышения роли домена, потому что зачем залазить по уши в проблему запуска нового повышения, когда вы можете просто клонировать новый контроллер домена из текущего. К тому же это очень быстро сделать.
Клонирование контроллера домена также имеет свои огромные преимущества в сфере, которая еще не осознана: восстановление леса в случае разрушения. В современной поддерживаемой конфигурации, восстанавливая лес, Вы восстанавливаете forest seed контроллеров домена (по одному на домен), затем запускаете Dcpromo на других контроллерах доменах до тех пор, пока у вас есть достаточное количество контроллеров доменов в среде, чтобы поддерживать пользователей. Проблема в том, что Dcpromo отнимает много времени, даже если Вы устанавливаете из IFM вместо того, чтобы делать сетевое повышение роли. Падение леса – кошмар для администратора (если не событие, которое заставляет взяться за написание резюме), и каждая секунда, которую Вы тратите на восстановление, означает тысячи или миллионы долларов убытка. Клонирование контроллера домена позволит Вам просто сделать клонов seed forest контроллеров домена – гораздо более быстрая операция, чем IFM или сетевое повышение. Мы можете оправдать переход на Server 8 AD уже только тем, что возможно сэкономить.
Автор: NetWrixRU
