Динамический контроль доступа: управление ресурсами по-новому

Как известно каждому системному администратору Windows, начиная с серверной операционной системы Windows Server 2008, такая важнейшая комплексная роль, позволяющая эффективно управлять идентификацией и доступом в организациях, как доменные службы Active Directory, была разделена на целых пять ролей. Если говорить точнее, то всем понятно, что основной задачей роли «Доменные службы Active Directory» (Active Directory Domain Services) выступает выполнение операций, связанных с идентификацией и доступом. То есть тут вам задачи, связанные с проверкой подлинности и авторизацией, тут же есть возможности создания и управления принципалами безопасности, сайтами, службами, а также доверительными отношениями. К этой же роли смело можно отнести централизованную настройку рабочих мест, реализуемую средствами функциональных возможностей групповой политики, и многое другое. Помимо этого, для того, чтобы воспользоваться всеми богатейшими возможностями служб каталогов, также еще можно работать со прочими серверными ролями.
СПОЙЛЕР: В данной статье подается сугубо теоретический материал, и эта статья не предполагает никаких поэтапных процедур.
Рассмотрим такие роли. Как я уже сказал выше, их можно насчитать четыре, а именно:

• Службы сертификации Active Directory, а именно Active Directory Certification Services, AD CS. Средние и крупные организации могут также у себя внедрять службы сертификации AD CS в инфраструктуре открытых ключей PKI для того, чтобы создавать центр сертификации для выдачи цифровых сертификатов, которые привязывают объект идентификации пользователя, устройства или службы к соответствующему частному ключу. Другими словами, службы AD CS предоставляют эффективный безопасный способ самостоятельной выдачи сертификатов и, как следствие, управления ими;
• Службы управления правами Active Directory – Active Directory Rights Management Services, то есть AD RMS. Возможности этой серверной роли, которыми, между прочим, очень многие пренебрегают, предоставляют технологию защиты информации, с помощью которой можно реализовать шаблоны устойчивых политик использования, задающих разрешенное и неавторизированное применение в сети и вне ее, а также внутри и вне периметра брандмауэра;
• Службы федерации Active Directory, что на английском звучит как Active Directory Federation Services,или же попросту AD FS. С помощью этих служб организация может некоторым образом расширить инфраструктуру идентификации и доступа на множестве платформ, включая не только среды Windows, а также обеспечить для доверенных партнеров защиту прав IDA вне периметра безопасности. В среде федерации организациям предоставляется возможность поддержки и контроля собственных объектов идентификации;
• Службы облегченного доступа к каталогам, то есть Active Directory Lightweight Directory Services, или просто AD LDS. Эта роль представляет собой, грубо говоря, каталог LDAP, который хранит только данные приложений, которым требуется доступ к хранилищу каталогов, но информацию о которых не следует реплицировать на все контроллеры домена.

И если ко всему этому еще добавить возможности развертывания контроллеров домена только для чтения, виртуализацию контроллеров домена, а также такие новые возможности, как активацию операционных систем через Active Directory и историю командлетов Windows PowerShell, можно сделать вывод, что возможности Active Directory чуть ли не безграничны. Однако, если посмотреть на то, каким образом предоставляется доступ к информации, то тут можно сказать, что все совсем грустно. Ведь права на основе NTFS не позволяют вам контролировать доступ к документам согласно какой-то строгой классификации файлов, не позволяют проводить гранулированный аудит согласно каким-либо специфическим политикам, не предоставляют возможности генерации «заявок на доступ» и еще имеют некий ряд ограничений.
Но теперь, с выходом такой серверной операционной системы от Microsoft, как Windows Server 2012, про все эти ограничения доступа к файлам посредством списков контроля доступа, то есть ACL-ов, можно забыть, так как появилась технология, именуемая динамическим контролем доступа (Dynamic Access Control), которая позволяет управлять доступом к информации на основе конкретных атрибутов или определенных критериев. Начиная с этой статьи, я вам расскажу об этой замечательной технологии, вы узнаете о том, каким образом можно ее использовать, о различных сценариях, о том, что такое утверждения (также в некоторых случаях именуемые заявками или клаймами, так как на английском это звучит как claim), какие существуют свойства ресурса. Еще вы узнаете о централизованных политиках и правилах доступа, о том, как именно можно опубликовывать и применять такие централизованные политики доступа, кое-что узнаете об аудите, о классификации различных файлов и папок, об устранении неполадок, связанных с динамическим контролем доступа, а также обо многом другом.
Естественно, глядя на все эти моменты, о которых я только что написал, сразу понятно, что одной статьей об этой технологии обойтись ну никак не получится, поэтому, образно говоря, я постараюсь полностью раскрыть эту технологию на протяжении 6-10 статей, рассмотрев большинство возможных сценариев, тонкостей этой технологии, а также примеров как на основе использования центра администрирования Active Directory, так и средств Windows PowerShell, что также немаловажно.
О чем же именно вы узнаете из этой, первой, статьи по такой технологии как динамический контроль доступа? А из этой статьи вы подробнее узнаете о следующих моментах:

• О том, для чего предназначена эта технология;
• О том, чем же эта технология лучше предоставления доступа на основе списков ACL;
• Узнаете о преимуществах и ограничениях текущей технологии;
• А также я расскажу о нескольких сценариях, в которых целесообразно будет использовать динамический контроль доступа и централизованные политики доступа.

Ну что же, приступим.

Назначение и отличия динамического контроля доступа от списков ACL

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

Как раньше назначались разрешения доступа?

Если говорить в общих чертах, то разрешения на управление доступом назначаются общим объектам и объектам Active Directory для определения того, каким образом разные пользователи могут использовать каждый объект. Как знает каждый – не только администратор, но и обычный пользователь ПК, — общий объект или общий ресурс представляет собой объект, который предполагает использование одним или несколькими пользователями по сети. Такими объектами, естественно, могут быть файлы, принтеры, папки и службы. В Active Directory управление доступом осуществлялось на уровне объектов путем задания для объектов разных уровней доступа или разрешений, таких как «Полный доступ», «Запись», «Чтение» или «Нет доступа». Разрешения управления доступом как к общим объектам, так и к объектам Active Directory, хранятся в их дескрипторах безопасности.
В дескрипторе безопасности содержатся два списка управления доступом (ACL), используемые для назначения и контроля сведений безопасности по каждому объекту. Само собой, это избирательная таблица управления доступом (DACL) и системная таблица управления доступом (SACL).

• Избирательные таблицы управления доступом (Discretionary access control list, DACL). Как известно из официальных источников, в DACL указаны пользователи и группы, которым явным образом разрешен или запрещен доступ к объекту. По вполне понятной причине, если определенный пользователь или группы, в которые он входит, явно не указаны в DACL, этому пользователю будет запрещен доступ к объекту. По умолчанию DACL управляется владельцем объекта или пользователем, который создал этот объект, и содержит записи управления доступом (ACE — Access control entries), определяющие доступ пользователя к объекту;
• Системные таблицы управления доступом (System access control list, SACL). В свою очередь, в SACL указаны пользователи и группы, для которых требуется выполнять аудит успешных и безуспешных попыток доступа к объекту. Аудит служит для наблюдения за событиями, относящимися к безопасности системы или сети, а также для обнаружения недостатков в системе безопасности и для определения объемов и расположения любых повреждений. По умолчанию, как и в случае с DACL, SACL управляется владельцем объекта или создавшим его пользователем. SACL содержит записи управления доступом, определяющие, требуется ли записывать успешные или безуспешные попытки доступа пользователя к объекту с использованием данного разрешения, например, «Полный доступ» или «Чтение».

По умолчанию DACL и SACL связаны с каждым объектом Active Directory, что снижает вероятность сетевых атак злоумышленников и случайных ошибок пользователей домена. Однако, если злоумышленник узнает имя и пароль любой учетной записи, имеющей права администрирования Active Directory, данный лес будет уязвим для атак.
Также не стоит забывать и том, что по умолчанию объекты Active Directory наследуют ACE из дескриптора безопасности объекта родительского контейнера. Наследование позволяет применять сведения управления доступом, определенные для объекта контейнера Active Directory, к дескрипторам безопасности любого подчиненного объекта, включая другие контейнеры и их объекты. Это избавляет от необходимости применять разрешения к каждому новому дочернему объекту. При необходимости можно изменить наследуемые разрешения. Однако рекомендуется не изменять используемые по умолчанию разрешения и параметры наследования объектов Active Directory.
Хотя процесс авторизации выглядит для пользователя как единое событие, он состоит из двух частей:
Пользователь предоставляет параметры доступа, обычно имя пользователя и пароль, которые затем проверяются в базе данных AD DS. Если имя пользователя и пароль совпадают с информацией, хранящейся в базе, пользователь становится авторизованным, и контроллером домена для него выпускается билет для получения билета. На этом этапе пользователь не имеет доступа к ресурсам сети.
Вторичный фоновый процесс передает билет контроллеру домена на рассмотрение и запрашивает доступ к локальной машине. Контроллер домена выдает служебный билет пользователю, который затем может взаимодействовать с локальным компьютером. На этом этапе процесса пользователь авторизован в AD DS и зарегистрирован на локальной машине.
Когда пользователь впоследствии пытается установить соединение с другим компьютером в сети, снова запускается вторичный процесс, и билет для получения билета передается на рассмотрение ближайшему контроллеру домена. Когда контроллер домена возвращает служебный билет, пользователь получает доступ к компьютеру в сети, которая генерирует событие авторизации на этом компьютере.
Компьютер, соединенный с доменом, также авторизуется в AD DS при запуске – факт, который часто упускают из внимания. Вам не видна транзакция, когда компьютер использует свое имя учетной записи и пароль для авторизации в доменных службах Active Directory. Пройдя проверку подлинности, компьютер становится участником группы авторизованных пользователей. Хотя процесс авторизации компьютера не имеет визуального подтверждения в графическом интерфейсе пользователя, стоит помнить, что существуют протоколы событий, которые фиксируют эту активность. Кроме того, если активирован аудит, в журнал безопасности Event Viewer будет внесено больше событий, доступных для просмотра.

А чем же лучше динамический контроль доступа?

Собственно, исходя из того, что собой представляет предоставление доступа на основании списков управления доступом, можно прийти к такому выводу, что при использовании такого метода разрешения предоставляются исключительно основываясь на членстве конечного объекта в определенной группе. Вы не можете ограничивать или, наоборот, разрешать доступ для конкретного устройства пользователя, основываясь на каких-то сторонних характеристиках, а также, само собой, о каких-либо нестандартных сценариях можно сразу забыть.
Динамический контроль доступа, в свою очередь, снимает эти ограничения и позволяет создавать более гранулированные правила, основываясь на которых вы можете предоставлять доступ согласно различным критериям. Другими словами, в первую очередь стоит обратить внимание на то, что эта технология предоставляет возможность управления доступом к файлам и данным посредством создания централизованных политик безопасности, позволяя наиболее подробным образом определять, кто вправе использовать ту или иную информацию. Иначе говоря, вы можете создавать такие политики, которые будут наилучшим образом отражать стратегию вашего бизнеса и полностью соответствовать любым нормативным требованиям. Более того, идентифицировать такую информацию вы можете при использовании классификации файлов, как в ручном, так и в автоматическом режиме. Только эти две возможности практически моментально могут уложить на лопатки управление доступом при использовании списков ACL.
Однако это еще не все. Самые распространенные типы данных, к которым предоставляют доступ, – это офисные документы, то есть файлы, которыми можно управлять при помощи продуктов Microsoft Office. Раньше для того, чтобы задать конкретным пользователям или группам уникальные разрешения с шифрованием документов, для каждого такого документа использовалась служба управления правами Active Directory, то есть AD RMS. Эта технология себя отлично зарекомендовала и сейчас, с появлением динамического контроля доступом, вам предоставляется возможность применения защиты RMS, с использованием автоматического шифрования на основе конкретных критериев.
В наше время одним из самых ценных активов многих компаний является не что иное, как сама информация, которая не должна выходить за пределы организации. Неправомерное использование такой информации может пагубно повлиять на дальнейшую судьбу всей компании. Благодаря централизованным политикам аудита данной технологии, вы можете создавать отчеты для дальнейшего проведения аудита доступа к файлам или же, в случае крайней необходимости, криминалистического анализа. Другими словами, вам не нужно будет прибегать к использованию каких-либо сторонних приложений и программных продуктов.
Что еще можно выделить помимо этого? А можно выделить то, что текущую технологию вы можете использовать, не внося изменений в схему Active Directory, без развертывания дополнительных ролей или же какого-то специфического программного обеспечения, да и, вообще, как говорится, «прямо из коробки». Более того, специально для реализации возможности использования динамического контроля доступа был разработан новый механизм авторизации и аудита для операционных систем Windows, а также для возможностей проверки подлинности Kerberos были реализованы некоторые новшества, о которых я уже писал в третьей части статьи про Kerberos, которая называлась « Сетевой протокол аутентификации Kerberos или зачем нужны утверждения».

А есть ли у него какие-то ограничения?

К сожалению, как и следовало ожидать, у данной технологии также есть некоторый ряд ограничений. Прежде всего, в организации должны быть развернуты доменные службы Active Directory. То есть, если вы захотите воспользоваться динамическим контролем доступа для компьютеров, входящих в состав рабочей группы, у вас ничего из этого не выйдет. Во-вторых, динамический контроль доступа – это не просто отдельная функциональная возможность. Эта технология представляет собой решение для файловых серверов, построенное на основании инфраструктуры Windows Server 2012, включающее поддержку прямых утверждений Kerberos, поддержку Active Directory специально для хранения свойств ресурсов, а также утверждений пользователей и компьютеров, поддержку Active Directory специально для хранения централизованных политик доступа, реализацию распространения таких централизованных политик доступа средствами функциональных возможностей групповой политики, а также многое другое.
Следовательно, согласно всем этим требованиям, можно сделать такой вывод: у вас в организации должен быть развернут как минимум один контроллер домена под управлением операционной системы Windows Server 2012, а также, в том случае, если в вашем лесу развернуто несколько доменов, то в каждом таком домене должно быть развернуто хотя бы по одному контроллеру домена под Windows Server 2012. Это делается специально для возможности использования утверждений между доменами, для которых установлены доверительные отношения. Да и более того, как я уже говорил, в Windows Server 2012 служба KDC была значительно усовершенствована специально для работы с утверждениями в рамках билета Kerberos.
Операционной системой на файловом сервере, естественно, должна быть Windows Sever 2012. Когда пользователь подключается к общей папке, файловый сервер выполняет проверку доступа к ресурсу, используя учетные данные входящего подключения. Это означает, что файловый сервер определяет доступ к общедоступному ресурсу. Это также означает, что различные компоненты на файловом сервере должны поддерживать утверждения, такие как LSA и сервер приложений Kerberos. Получается, файловый сервер, на котором будут располагаться данные, к которым пользователи будут получать доступ, должны быть в состоянии считать утверждения и данные авторизации устройства из билета Kerberos, перевести эти идентификаторы безопасности (SID) и утверждения билета в маркер проверки подлинности и сравнить данные авторизации в маркере с условиями, включенными в дескрипторе безопасности. То есть более старые версии ОС, как следствие, не подойдут.
Ну а в том случае, если у вас будут указаны утверждения для устройств, в качестве клиентов могут использоваться исключительно компьютеры под управлением операционных систем Windows 8 или Windows Server 2012. Другими словами, это ограничение можно назвать веской причиной для миграции клиентов на восьмерку.

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

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

• Централизованное развертывание политик авторизации. В первую очередь, одной из основных задач этой технологи является создание централизованных политик доступа для файлов компании, позволяющих предоставлять пользователям или их устройствам доступ к файлам на основании конкретных условий, а также, что очевидно, управление такими политиками. Создаются они исключительно на основании потребностей каждой конкретной компании, что делает эту технологию особенно ценной. Каким образом реализуется данный сценарий:
  
  1. Первым делом, необходимо оценить направление вашего бизнеса и определиться с тем, каким образом будут работать такие политики. То есть для начала вы должны определить, для чего вообще вам нужны централизованные политики доступа, иначе говоря, вы локализуете ресурсы, для которых должны будут в будущем применяться такие политики. После этого создается список всех политик, которые вы будете применять в своей среде. Если говорить не так размыто, то вы условно разделяете свои файловые ресурсы на отделы, на какие-либо конкретные категории, а в случае с большим количеством филиалов вы продумываете, как будет выгоднее ограничивать доступ в зависимости от физического расположения, и так далее;
  2. Затем следует реализация выражений политики доступа в структурных компонентах Windows Server в форме, понятной для сервера. Что означает весь этот набор слов? А означает он то, что вторым шагом в реализации данного сценария выступает преобразование требуемой для вас политики доступа в правильное выражение. Такие политики, по большому счету, очень просто конвертируются из обычной, понятной для каждого, формы в язык, требуемый для предоставления авторизации принципалам безопасности. То есть такие политики доступа обладают правилами применимости, условиями доступа, а также исключениями. Это все мы с вами будет очень подробно рассматривать в одной из следующих статей данного небольшого цикла;
  3. После этого, задачей под номером три является определение групп пользователей, свойств ресурсов, а также требуемых утверждений. То есть сейчас вам нужно проанализировать, на какие конкретные ресурсы и для каких принципалов безопасности будут применимы утверждения, создаваемые для каждой централизованной политики доступа;
  4. И, что очевидно, последним пунктом для вас будет определение серверов, на которые будут распространяться такие централизованные политики доступа. Например, вы можете распространять такие политики как сразу на все файловые серверы, так и на серверы, согласно их изначальному назначению.
• Реализация утверждений между лесами. Операционная система Windows Server 2012 была разработана таким образом, чтобы в ней так называемые словари утверждений могли использоваться в каждом лесу, причем все они будут определяться непосредственно на уровне доменных служб Active Directory. Базовые сценарии представляют собой ситуацию, когда клиенту нужно получить утверждение на доступ, которое будет каким-либо образом обходить границу доверия.
  Очевидно, что утверждения относятся к объектам, с которыми таковые связаны, и для каждого леса Active Directory определяются свои типы утверждений. Преобразования межлесовых утверждений позволяют им распознаваться и применяться в доверяющих и доверенных лесах. Чтобы было немного понятнее:
  Доверяющий лес может использоваться для трансформации утверждений во избежание атак, связанных с повышенными привилегиями, благодаря фильтрации входящих утверждений согласно конкретным значениям. Они также выдают утверждения для принципалов через границы доверия в том случае, если доверенные леса не поддерживают, или не выпускают определенные утверждения.
  В свою очередь, доверенные леса могут использовать преобразование утверждений с целью воспрепятствовать определенным типам утверждений, а также не допустить проникновения утверждений с определенными параметрами в доверяющий лес.
  Между прочим, очень важно понимать, что в создании политик преобразований утверждений задействованы два компонента, а именно: объекты политики преобразования утверждений, а также ссылки преобразования. Эти моменты, как и сценарий в частности, будут подробнее рассмотрены в соответствующей статье по данной технологии.
• Улучшенная поддержка пользователей, которым было отказано в доступе. В принципе, штатная ситуация: пользователь N приходит на работу и получает задание, связанное с какой-то определенной информацией, расположенной на файловом сервере, но доступа к которой такому пользователю не предоставляется. Что происходит далее: этот же пользователь N пытается перейти к общей папке, однако при попытке открытия таковой он получает единственный ответ, который гласит: «В доступе отказано». После этого пользователь связывается со службой поддержки и, как показывает практика, в понятной только лишь этому пользователю форме он попытается объяснить, к какой документации ему нужен доступ, зачем он нужна, где находится такая документации и так далее.
  В чем же преимущество использования динамического контроля доступа? При помощи правильного использования данной технологии вы можете дать возможность такому вот сотруднику и владельцу этих данных справиться со своими проблемами самостоятельно, причем практически без использования технической поддержки, а если уже ничего не получится, то обеспечить полномочному персоналу передачу всей необходимой информации без разъяснений от самого пользователя.
  Но вот что сразу хотелось бы отметить. Таких сценариев, связанных с отказами в доступе может быть невероятное множество, причем каждая такая ситуация может быть частной. Поэтому продумать единое решение просто невозможно. Что же в таком случае предлагает сделать Microsoft? А можно, так сказать, пойти следующим путем:
  
  1. Для начала следует определиться с тем, каким образом будет предоставляться первоначальная помощь страждущим при возникновении отказа в доступе. А именно, можно сделать так, чтобы при возникновении такого сообщения у пользователя сразу отображалось кастомизированное сообщение с соответствующей кнопкой, позволяющей отправить владельцу такой папки письмо при помощи электронной почты. Либо вместо этой кнопки с отправкой почты можно сформировать ссылку, перейдя по которой пользователю нужно будет заполнить веб-форму на внутреннем портале. Здесь все зависит от того, что у вас присутствует в инфраструктуре и каким образом будет проще для вас и ваших пользователей реализовать такую поддержку;
  2. После этого вам нужно будет указать уполномоченных лиц, будь то администраторы, либо владельцы самих папок, которым будут капать все эти пользовательские запросы;
  3. Далее настраивается сам шаблон сообщения, которое будет отображено пользователю при отказе в доступе;
  4. В случае необходимости, вы прорабатываете все возможные исключения. Причем крайне желательно, чтобы вы это сделали еще на самом этапе планирования, максимум во время пилотного развертывания;
  5. В конце концов прорабатывается план, согласно которому оказывается помощь на уровне самого файлового ресурса. То есть вы можете указать в самом сообщении уполномоченных лиц или выполнить какие-либо дополнительные действия.
• Разграничение значимой информации при помощи классификации файлов. Как я уже успел написать выше, в наше время один самых значимых ресурсов компаний – их информация, причем как открытая для всего мира, так и, что куда важнее, закрытая внутренняя информация. Причем не конечным пользователям, а именно ИТ-персоналу приходится отвечать за сохранность таких данных и, естественно, за назначение прав только лишь уполномоченным лицам. Другими словами, нужно не только следить за тем, чтобы такая документация была всегда доступна пользователям и чтобы ресурсы таких хранилищ не истощались (за это еще давно отвечала та же DFS-R), а нужно еще и отслеживать то, чтобы ресурсы наиболее эффективным образом использовались только лишь по назначению. А это, естественно, целесообразно реализовывать при помощи каких-либо определенных политик, так как назначать такие права и прочие возможности нужно централизованно.
  Windows Server 2012 совместно с технологией динамического контроля доступа позволяют применять классификации файлов, что дает возможность получить общую картину среди всех ваших ресурсов, причем если вы захотите, можно полностью автоматизировать этот процесс, тем самым сэкономив свое время. Другими словами, среди всех возможностей классификации файлов можно воспользоваться ручным методом, программным, либо использовать автоматические методы классификации файлов. Каким образом следует поступать, вы определите самостоятельно, когда столкнетесь с таким сценарием. А тут все относительно просто:
  
  1. Сначала вы проводите полную инвентаризацию всех возможных файлов, которые можно найти в вашей организации. Для чего вообще это делается? А такие действия следует выполнять для того, чтобы вы могли в дальнейшем использовать классификацию и знали, какие файлы или же папки у вас будут подлежать самой классификации;
  2. После того как файлы, подлежащие классификации, будут определены и вы для себя где-то составите такой план, вам следует выбрать способы классификации таких файлов. То есть можно вручную классифицировать файлы, используя соответствующие средства, можно их классифицировать на основе расположения, причем выполнять это все можно как вручную, так и при помощи классификатора папок, или же, что важнее всего, можно выполнять классификацию на основе содержимого. Обо всем этом мы еще поговорим подробнее в одной из следующих статей по текущей технологии.
• Защита конфиденциальной информации на основе классификации документов Microsoft Office. AD RMS… Как много смысла хранится в этих пяти буквах. Для организации может быть важно не только предоставление доступа к различной секретной документации, но также очевидно и то, что информацию нужно защищать. А общепринятым методом защиты секретной информации является шифрование последней. Для шифрования документации очень хорошо зарекомендовала себя служба управления правами Active Directory. А сейчас, с выходом Windows Server 2012, вы можете автоматизировать процесс шифрования документов, основанных на классификации файлов Microsoft Office, практически в прозрачном режиме, причем сразу же после того, как такие файлы будут появляться на ваших файловых серверах. Что для этого всего следует предпринять:
  
  1. Прежде всего, вам нужно будет определиться с файлами, которые должны быть зашифрованы в автоматическом режиме. Тут, кстати, практически сразу можно столкнуться с небольшой трудностью. Файлы-то на ваших ресурсах могут быть не только конфиденциальными, а они еще и могут обладать личностным характером. То есть первым делом вы должны определить то, какие именно файлы должны подлежать шифрованию. После этого вам нужно будет определить то, согласно каким именно свойствам ресурса будут определяться такие типы файлов. Другими словами, вам нужно будет либо воспользоваться предустановленными свойствами ресурсов, либо создать свои собственные, уникальные свойства ресурсов, которые и будут фигурировать для определения файлов, которые должны быть зашифрованы;
  2. Сразу после этого вам нужно будет определить шаблоны политики прав, которые будут использоваться при шифровании таких файлов. Они уже используются, как вы, вероятнее всего, знаете, непосредственно службой AD RMS. То есть вы выбираете принципалы безопасности и указываете права, которые для них будут доступны при использовании таких файлов. Здесь уже все зависит от ваших бизнес-требований, от разрешений ваших групп пользователей, а также от того, насколько важными являются такие файлы. Например, вы можете разрешить просматривать определенные документы группе финансистов, но запретите им возможности изменения и печати. Вариантов применения службы управления правами для ваших файлов может быть множество;
  3. В конце концов, используя эту технологию, вы смело можете отдавать на ознакомление свою документацию партнерам, не волнуясь о том, что с вашими файлами будут выполняться какие-то неправомерные деяния.
• Создание периодов хранения информации на файловых серверах. Перед тем как начать разбираться с этим сценарием, следует определиться с простым термином: что такое период хранения информации? Согласно официальной терминологии, «периодом хранения называется время, в течение которого следует хранить документ, прежде чем он будет просрочен». Само собой, у всех этот период будет разным. То есть, опять же, давайте вернемся к классификации файлов. По сути, файлы можно классифицировать как кратко-, средне- и долгосрочные для хранения, а после этого уже можно будет для таких периодов определиться с временными рамками. Следовательно, для всей этой процедуры, имеется в виду, для управления периодами хранения, технология динамического контроля доступа использует инфраструктуру классификации файлов совместно с диспетчером ресурсов файлового сервера, с которым многие уже знакомы по предшествующим версиям серверных операционных систем от Microsoft. После того, как срок хранения будет подходить к концу, естественно, владелец получит по электронной почте какое-либо уведомление. И, опять же, как будет выглядеть реализация такого сценария:
  
  1. В первую очередь, вам нужно будет определиться, как долго смогут храниться различные файлы на ресурсах вашей организации, учитывая повышение отказоустойчивости, а также сокращение объема сохраненных данных. Это очень важные факторы, и поэтому при разработке такого расписания вам обязательно нужно будет консультироваться с уполномоченными членами вашей организации;
  2. После этого, само собой, вы определяете тип таких хранимых данных на своих файловых ресурсах. Вы задаете свойства, согласно которым файлы не могут быть случайно удалены конечными пользователями, а также определяете свойства классификации.
• Аудит доступа к файлам. В конце концов, очень важным сценарием выступает аудит безопасности, позволяющий поддерживать порядок и благополучие в вашей среде. Какова основная задача? Естественно, это соблюдение порядка в компании и искоренение неправомерных деяний, которые могут происходить в вашей среде. Тогда может возникнуть следующий вопрос: что позволяет делать аудит безопасности в данном ключе? Тут не сложно догадаться, что аудит безопасности позволяет отслеживать соблюдение установленных вами политик, а также позволяет выявлять и предотвращать вероятностные уязвимости и, в случае необходимости, как сейчас принято выражаться, позволяет выполнять так называемый криминалистический анализ.
  Что же можно сделать с динамическим контролем доступа для соблюдения аудита безопасности? Во-первых, можно настраивать политики аудита на основании конкретных выражений. Что это означает: можно создавать так называемые адресные политики аудита, основанные на требованиях ресурсов, пользователей или их устройств. Во-вторых, можно формировать события аудита при любой попытке доступа к целевым файлам, после чего фильтровать журналы событий на наличие потенциальных точек уязвимости. Более того, вы, естественно, можете определять изменения на основании изменений в атрибутах конкретных файлов, что может повлиять на ограничение доступа, изменения атрибутов конечных пользователей и компьютеров, что, в свою очередь, может послужить как причиной возникновения проблем доступа к жизненно важным файлам, так и дать пользователям излишние права. Также вы можете определять изменения в определениях утверждений, которые включают в себя имя, описание или какие-либо дополнительные значения свойств, изменения связанные с центрированными политиками и какими-либо правами доступа к ресурсам, определяющими то, кто именно может использовать необходимые ресурсы, а также многое другое.
  Естественно, на этих всех моментах, как и на возможностях всех предшествующих сценариев, я еще остановлюсь более подробно, с живыми примерами и процедурами настройки.

Хотите знать больше?

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