Разграничение прав доступа в windows server — Ваш верный помощник с OS Windows

В Windows Server 2012 появился новая концепция централизованного управления доступом к файлам и папкам на уровне всей компании под названием Dynamic Access Control (динамический контроль доступа). Основное отличие новой системы динамического контроля доступа от старой системы доступа к файлам и папкам Access Control List (ACL — списки контроля доступа), позволяющей предоставлять доступ только на учетных записей пользователей и групп, заключается в том, что с помощью Dynamic Access Control (DAC) можно управлять доступом на основе практически любого заданного атрибута и даже критерия. С помощью Dynamic Access Control в Windows Server 2012 можно создавать целые правила управления доступа к данным, которые позволят проворить, например, входит ли пользователь в определенные группы, числится ли он в финансовом отделе и поддерживает ли его планшет шифрование RMS. Эти правила в виде политик в дальнейшем можно применить к любому (или всем) файловым серверам организации, создав тем самым единую систему безопасности.

Недостатки организации доступа на основе ACL

Каким образом реализовывался доступ к общим каталогам на файловых серверах до появления Dynamic Access Control. На общую папку на уровне NTFS и/или шары назначались определенные списки доступа, включающиеся в себя определенные группы в AD (или локальные группы сервера) или конкретные учетные записи. Чтобы пользователь получил доступ к нужному каталогу, администратор должен был включить его в соответствующую группу. Какие недостатки такой модели организации доступа?

· Доступ регулируется только на основании только членства в группе

· При большом количестве общих папок необходимо создавать большое количество групп (выливается в увеличение билета Kerberos)

· Отсутствует возможность контроля доступа на основании характеристик устройства пользователя, с которого подключается пользователь

· Невозможность реализации сложных сценариев доступа

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

Указанные выше недостатки призвана устранить технология динамического контроля доступа.

Архитектура и принципы Windows Server 2012 Dynamic Access Control

В Windows Server 2012 Dynamic Access Control создает еще один уровень управления доступом к файловым объектам на уровне всего домена, причем на эти объекты продолжают действовать NTFS разрешениями
(ACL). Отметим, что правила DAC могут действовать повсеместно, независимо от того, какие NTFS права выставлены на объекте.

Одной из основных концептов модели DAC является понятие claim (заявка или утверждение). В модели управления доступом Windows Server 2012 claim представляет собой атрибут Active Directory, которой определен для использования с централизованными политиками доступа (Central Access Policies). В качестве критериев можно использовать практически любые сохранные в AD параметры, принадлежащие определенному объекту, например, ID устройства, способ входа в систему, местонахождение, личные данные и т.д. Настройка claim-ов осуществляется с помощью консоли управления Active Directory Administrative Center (ADAC) в новом контейнере Claim Based Access. В этом контейнере (изначально пустом) можно создавать собственные утверждения и связывать их с атрибутами пользователей или компьютеров. Основываясь на значениях claim-ов можно определить давать ли доступ данному пользователю/устройству к тому или иному объекту файловой системы.

Следующий компонент DAC – свойства ресурсов (Resource Properties), с помощью которых определяются свойства ресурсов, которые в дальнейшем будут использовать в правила авторизации. Resource Properties – это также отдельный контейнер в Dynamic Access Control.

Следующими элементами DAC являются правила Central Access Rules и политики Central Access Policy. CentralAccess Rules описывают какой уровень доступа предоставить к файлам, каким пользователям, с какими заданными утвержденями, с каких устройств и т.д. Central Access Policy – это политика, содержащая в себе правила Central Access Rules, которая в дальнейшем посредством GPO будет распространена по всей организации (или конкретной OU).

Каким образом можно перейти на модель управления доступом Dynamic Access Control в организации:

1. Создать один/несколько видов клаймов.

2. Активировать одни/несколько свойств ресурсов (метки или теги у файловых объектов)

3. Создать правило Central Access Rule, в котором определяется условия предоставления доступа

4. Добавить созданные правила в политику Central Access Policy

5. С помощью групповых политик распространить CAP на файловые сервера

Естественно, перед внедрением Dynamic Access Control необходимо настроить систему классификации файлов, как это сделать описывается в статье : Классификация файлов с помощью File Classification Infrastructure в Windows Server 2012. Этап определения и классификация данных, хранящихся на файл-серверах наиболее тяжелый и трудоемкий, результатом которого будет назначение управляемым файловым объектам NTFS тэгов.

Каким образом осуществляется проверка разрешений пи доступе к файлу/каталогу конечного пользователя, ведь теперь помимо прав доступа на NTFS осуществляется еще и проверка на соответствие клаймов? Последовательность проверки разрешений следующая:

· Share ACL

· Central Access Policy

· NTFS ACL

Пример использования Dynamic Access Control в Windows Server 2012

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

С помощью консоли AD Administrative Center создадим два новых claim-a: Department и Country. Для этого перейдите в контейнер Dynamic Access Control -> Claim Types и в меню выберите пункт New:

Создадим новое утверждение с именем Department :

и Country :

В атрибуте Country укажем два предопределенных (suggested) значения (EG – Египет, и QR – Катар):

Далее создадим новое свойство ресурса (Resource Properties) для утверждения Country: New-> Resource Properties.

Затем в контейнере Resource Properties активируйте утверждение Department

Теперь создадим новое правило Central Access Rule. В этом правиле будут указаны разрешения, которые применяются к объекту, если claim совпадает с правилом, описанном в CAR.

Предположим, мы правило, определяющее, что пользовали Finance Admins (Department=Finance и County=EG), имеют полный доступ, а пользователи Finance Execs (Department=Finance) – доступ только на чтение. Это правило будет применено ко всем правилам, классифицированным, как относящиеся к финансовому департаменту:

В итоге, правило будет выглядеть так:

Затем создадим политику Central Access Policy (CAP), которая с помощью GPO будет применена ко всем файловым серверам.

В новую политику CAP, включим правило для финансового департамента, созданное ранее:

Далее правило Central Access Policy с помощью групповых политик нужно применить ко всем файловым серверам. Для этого нужно создать новую политику GPO и прилинковать ее к OU с файловыми серверами.

В окне редактора групповых политик (Group Policy Management Editor) перейдите в раздел Computer Configuration->Policies->Windows Settings->Security Settings->File System-Central Access Policy->Manage Central access policies.

В окне настроек Central Access Policies Configuration добавим политику Finance Data и нажмем OK.

Далее нужно разрешить всем доменным контроллерам назначать клаймы. Это также выполняется с помощью GPO, однако в этом случае нам нужно отредактировать политику контроллеров домена — Default Domain Controllers Policy . Перейдите в раздел Computer Configuration->Policies->Administrative Templates->System-> KDC. Откройте параметр KDC Support for claims, compound authentication and Kerberos armoring, задайте ему значение Enabled , а в выпадающем списке выберите Supported

Закройте редактор групповых политик и обновите политики на контроллере домена и файловых серверах командой

gpupdate /force

Посмотрим, что же у нас получилось.

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

Примечание: Чтобы при доступе к файлу проверялись еще и разрешения DAC, у пользователей должен быть доступ к каталогу/файлу на уровне NTFS. В этом примере мы предоставим всем полный доступ на уровне NTFS.

Проверим текущие разрешения на папку.

Перейдем на вкладку Central Policy и применим политику Finance Data.

Если у пользователя не назначены утверждения (он входит в нужную группу, но у него не определены атрибуты department и country), доступа к каталогу у него не будет.

Заключение

С помощью комбинации технологий DAC, AD RMS (позволяет организовать динамическое шифрование файлов с помощью AD RMS и FCI)и FCI можно создавать мощные схемы управления доступом к документам и зашиты конфиденциальной информации, реализуя полноценную DLP систему на базе инфраструктуры Windows Server 2012.

Источник

В Windows Server 2012 появилась технология динамического контроля доступа (Dynamic Access Control), предназначенная для разграничения доступа к файловым ресурсам. Технология перспективная и заслуживающая внимания, поэтому я предлагаю вам посветить ее изучению некторое количество времени. В первой части мы разберем теоретические основы работы Dynamic Access Control.

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

Утверждения

Работа Dinamic Access Control основывается на утверждениях, или клаймах (claims). Для утверждений существует множество определений, приведу наиболее короткое. Утверждение – это информация об объекте, полученная из достоверного источника. В нашем случае объектом служит учетная запись пользователя или компьютера в Active Directory, а в качестве достоверного источника выступает служба KDC (Key Distribution Service), расположенная на контроллере домена.

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

В Windows Server 2012 используются утверждения трех типов:

1. Утверждения для пользователей (user claim) — в качестве утверждений используется аттрибуты учетной записи пользователя в Active Directory, например департамент или должность;
2. Утверждения для устройств (device claim) — здесь в качестве утверждений используется аттрибуты учетной записи компьютера, такие как операционная система или состояние здоровья;
3. Утверждения преобразования (transformation claim) — этот тип используется для трансформации утверждений при прохождении через доверительные отношения между лесами. Утверждения этого типа не базируются на атрибутах AD.

С учетом того, что утверждения можно объединять с использованием условных выражений, при составлений правил доступа есть где проявить фантазию 🙂 .

Условные выражения

Условные выражения (conditional expressions) представляют из себя сочетание из нескольких (двух и более) утверждений, разделенных логическим оператором. По сути это логические выражения, в котором мы производим сравнение правой и левой части и в качестве результата получаем одно из двух значений — TRUE или FALSE. Выражения используются как при авторизации, так и для проверки доступа к ресурсу.

Примечание. Кроме TRUE и FALSE существует еще один тип значения — UNKNOWN. Это значение возможно получить например в том случае, если соответствующий атрибут пользователя в AD не заполнен.

Напомню, что из себя представляют операторы. Скорее всего они вам знакомы, поэтому подробно описывать не буду, а просто перечислю их значения: равно (==), не равно (!=), больше чем (>), меньше чем (<), больше или равно (>=), меньше или равно (<=), не (!), и (&&), или (||), содержит (Contains), любой из (Any_of), член группы (MemberOf) и любой член группы (MemberOf_Any).

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

User.Title==″Sales Manager″ && (User.Department==″Management″ || User.Department==″Sales″)

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

В качестве утверждения пользователя идет User.Department, отвечающее за департамент, в котором работает сотрудник. Предположим, наш пользователь является сотрудником отдела продаж (Sales). В этом случае левая часть выражения в скобках для него принимает значение FALSE, а правая TRUE и наше выражение примет вид:

User.Title==″Sales Manager″ && (FALSE || TRUE)

Так как для оператора || достаточно наличия в скобках хотя бы одного значения TRUE, то наше выражение сокращается до такого:

User.Title==″Sales Manager″ && TRUE

Теперь проверяем левую часть выражения. В ней используется атрибут User.Title, отвечающий за должность предполагаемого сотрудника. Если он является менеджером отдела продаж (Sales Manager), то выражение примет вид:

TRUE && TRUE

Для оператора && требуется, чтобы оба условия были истинными. В нашем примере это так, следовательно все выражение примет значение TRUE и пользователь получит доступ к ресурсу.

Свойства ресурсов

Ресурсами, которые можно защитить с помощью Dinamic Access Control, являются файлы. На файловых серверах Windows Server 2012 появилась возможность классифицировать ресурсы, указав для каждого файлового ресурса определенные свойства, а затем использовать эти свойства для определения разрешений доступа.

Вспомним, какие разрешения действуют на файлы.

Share Permission

Для каждой папки, находящейся на сетевом ресурсе, действуют разрешения на шару (Share Permission). Когда то давно, до появления NTFS, это был единственный способ ограничить доступ к файловым ресурсам. На данный момент этот механизм устарел, поэтому хорошей практикой считается в Share Permissions давать полный доступ (Full Access) для всех (Everyone), а контроль доступа осуществлять с помощью разрешений NTFS.

NTFS Permissions

В файловой системе NTFS к каждому объекту (файлу или папке) привязан список контроля доступа (Access Control List, ACL). В ACL хранятся идентификаторы безопасности (SID) пользователей и групп, которым явным образом разрешен (или запрещен) доступ к объекту. Соответственно, если пользователь или группа, членом которой он является, не указаны в ACL, то такой пользователь доступ не получит.

В ACL содержатся записи управления доступом (Access control entry, ACE), которые и определяют разрешения пользователя при доступе к объекту. Каждый ACE представляет из себя:

• SID доверенного лица — идентификатор пользователя\группы, доступ которого мы контролируем;
• Маску доступа — тип доступа (чтение, запись, выполнение и т.д);
• Флаги — определяют тип ACE (разрешение или запрет), а также параметры наследования.

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

ACE располагаются в ACL в определенном приоритетном порядке:

• Первыми идут ACE, назначенные на объект явным образом (т.е. вручную), сначала запрещающие ACE, потом разрешающие;
• Затем следуют разрешения, наследуемые напрямую от родительского объекта, также сначала запрещающие, потом разрешающие;
• И затем идут разрешения, наследуемые от других вышестоящих объектов.

С появлением Windows Server 2012 ситуация изменилась. ACE значительно расширились и появилась возможность включать в них утверждения. На рисунке приведен стандартный дескриптор безопасности (он же ACE) папки. В терминах языка SDDL (Security Definition Descriptor Language) он означает следующее:

O:BA — владельцем объекта (Owner) является встроенная группа Builtin\Administrators;
G:DU — основная группа Domain Users;
D:PAI — дескриптор имеет тип DACL (D), в нем заблокировано наследование от вышестоящих объектов (P), но разрешено для нижестоящих объектов (AI);
A — Allow, означает разрешающий ACE;
OICI — флаги наследования для дочерних объектов;
0x1301bf — разрешения Modify и Synchronize в шестнадцатеричном виде;
AU — группа Authenicated Users.

Проще говоря, пользователи, входящие в группу Authenicated Users, имеют разрешение на изменение содержимого этой папки.

А вот тот же ACE, но уже с использованием утверждений. Рассмотрим поподробней, что изменилось. Во первых, появилась буква X, которая означает, что в ACE используются утверждения, а во вторых, в скобках содержится условное выражение. В этом выражении говорится, что доступ к объекту cмогут получить только те пользователи, у которых атрибут Department имеет значение Sales, а атрибут Office — значение Central. То есть доступ разрешен для сотрудников отдела продаж, работающих в центральном офисе.

дескриптор безопасности на основе утверждений

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

Центральные политики доступа

Итак, мы имеем с одной стороны утверждения пользователей и устройств, а с другой — классификацию ресурсов. Для объединения этих технологий используются централизованные политики доступа (Central Access Policy, CAP). CAP хранятся в службе Active Directory, в разделе конфигурации и являются общими для всего леса.

Типичный пример центральной политики доступа приведен на следующем рисунке.

Процесс создания и применения CAP состоит из нескольких этапов:

• Сначала создаются необходимые утверждения для пользователей и устройств;
• Затем создаются свойства ресурсов;
• Свойства ресурсов применяются к файловым серверам, и на их основании производится классификация файлов;
• На основе утверждений создаются централизованные правила доступа (Central Access Rule), которые представляют из себя набор условных выражений наподобие описаных ранее;
• Создается CAP, в которую входят одно или несколько централизованных правил доступа;
• CAP публикуется в Active Directory и распространяется на файловые сервера с помощью групповых политик.

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

Kerberos

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

Напомню в общих чертах, как происходит доступ к ресурсу с использованием Kerberos.

1. Пользователь пытается войти в систему, для чего вводит свои учетные данные — имя пользователя, пароль и домен. Клиент Kerberos на рабочей станции обращается к службе KDC на контроллере домена и отправляет ей запрос на аутентификацию (KRB_AS_REQ). В запросе содержится имя пользователя, имя домена и специальный аутентификатор — текущее время на рабочей станции, зашифрованное хешем пароля пользователя.

2. Служба KDC находит пользователя в AD, извлекает его секретный ключ и расшифровывает аутентификатор, получая таким образом время отправки запроса. Если расшифровка прошла успешно и полученное время не расходится с временем на контроллере домена более чем на 5 минут (политика Kerberos по умолчанию), KDC выдает ответное сообщение (KRB_AS_REP). В ответе содержится сессионный ключ и отметка времени окончания билета, зашифрованные секретным ключом пользователя, а также билет TGT (Tiсket Granting Ticket), который зашифрован секретным ключом службы KDC.

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

3. Теперь пользователю требуется получить доступ к ресурсам, находящимся на файловом сервере. В Kerberos любой объект, к которому требуется получить доступ, называется службой. Клиент опять обращается к службе KDC с запросом (KRB_TGS_REQ), в котором содержится имя службы, к которой нужен доступ, имя пользователя и отметка времени, зашифрованные сессионным ключом, а также билет TGT.

4. KDC расшифровывает TGT, используя свой собственный ключ, а метка времени расшифровывается копией сессионного ключа. Если со временем все впорядке и билет TGT не просрочен, клиенту отправляется ответ (KRB_TGS_REP), содержащий две копии билета TGS (Ticket Granting Service), один для клиента и один для службы. При этом билет службы шифруется секретным ключом этой службы и вкладывается в клиентский билет, который шифруется сессионным ключом пользователя.

В билет TGS входят имя пользователя, имя службы, маркер времени и срок жизни билета, а также новый сессионный ключ. Кроме того, в TGS есть раздел данных, известный как сертификат атрибута привилегий PAC (Privilege Attribute Certificate). В PAC содержатся SID пользователя и SIDы всех групп безопасности, членом которых он является.

5. Клиент получает ответ службы KDC, расшифровывает его сессионным ключом и извлекает новый сессионный ключ. Этим ключом он шифрует метку времени и отправляет ее вместе с именем пользователя и билетом службы TGS на сервер запросом (KRB_AP_REQ). Сервер принимает запрос, расшифровывает билет TGS своим секретным ключом и извлекает свою копию сессионного ключа. Этим ключом он расшифровывает метку времени и таким образом устанавливает подлинность клиента.

Подсистема безопасности на сервере извлекает из PAC данные пользователя. Затем она обращается в локальную базу данных и проверяет, не является ли пользователь членом локальной группы на данном компьютере, и если да, то добавляет полученные SIDы к списку данных, извлеченных из билета. На основе полученного списка формируется маркер доступа (Access token), который привязывается к сессии пользователя.

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

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

В Windows Server 2012 в протокол Kerberos были внесены некоторые изменения, призванные обеспечить поддержку Dynamic Access Control.

Kerberos Security Support Provider (SSP) — основа клиентской службы Kerberos. В Windows Server 2012 и Windows 8 библиотека Kerberos.dll была переработана для поддержки утверждений пользователя и данных авторизации устройства в атрибуте PAC.

PAC также был переработан и может включать в себя следующие данные:

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

Составные удостоверения (Compound Identity) — еще одна новая технология, позволяющая включать в билет TGS не только авторизационные данные пользователя, но и данные его компьютера. Это позволяет предоставлять доступ как на основании того, кем является пользователь, так и на основании устройства, на котором он работает.

Защита Kerberos (Kerberos armoring) — технология создания защищенного канала между клиентом и службой KDC, ее еще называют FAST (Flexible Authentication Secure Tunnel). Суть этой технологии в следующем: перед аутентификацией пользователя его компьютер тоже должен пройти аутентификацию в домене и получить от службы KDC билет TGT. FAST использует этот билет для того, чтобы зашифровать дальнейший обмен данными между пользователем и KDC, создавая безопасный канал связи между ними и делая невозможным перехват сообщений.

И наконец в службу KDC (Kdcsvc.dll) Windows Server 2012 также включена поддержка утверждений и составных удостоверений.

С учетом всех этих новых возможностей процесс авторизации несколько изменился. Когда клиент отправляет запрос на контроллер домена, служба KDC получает запрос и проверяет значение флага claims в структуре PA-PAC-OPTION. Если он имеет значение TRUE, то значит клиенту требуются утверждения. KDC извлекает из базы Active Directory необходимые атрибуты и добавляет их в PAC. Клиент получает билет TGS, содержащий утверждения, и с этим билетом обращается к службе. Соответственно служба, получив билет TGS, извлекает из него утверждения и добавляет их в маркер доступа, на основании которого предоставляется доступ к ресурсу.

На этом закончу теоретическую часть. Надеюсь у меня получилось не смешать все понятия в одну кучу. Вторая часть статьи будет больше практической и будет посвящена настройке и использованию Dynamic Access Control для доступа к файловым серверам.

Источник

This Windows Server 2022 Tutorial covers how to Configure permissions on a shared folder – Windows Server 2022. NTFS and share permissions are used to prevent unauthorized access in Microsoft Windows environments.

NTFS Permissions: NTFS (New Technology File System) permissions are used to manage access to data stored in NTFS file systems.
Share Permissions: Share permissions manage access to folders shared over a network. Share Permissions do not apply to users who log on locally.

Demo environment
Computer Name: server1.test.com
Operating System: Windows Server 2022 Datacenter
IP Address: 192.168.0.3
Group: test\group1

1. Right click on the folder and click Properties.

Configure permissions on a shared folder - Windows Server 2022

2. Select Sharing tab and click Advanced Sharing.

3. Enable share this folder and click Permissions.

4. By default, Everyone Read permission is granted Remove it, Click Add to add necessary permissions.

5. Click Advanced.

6. Select Find Now, select the group, and click OK.

7. Click OK.

8. Configure permission for the group and click OK.

9. Select the Security tab, and click Advanced.

10. Click Disable inheritance.

11. Click Covert inheritance permissions into explicit permissions o this object.

12. Remove unnecessary permissions and click Add to add necessary permissions.

13. Click Select a principal.

14. Click Advanced.

15. Select Find Now, select the group, and click OK.

16. Click OK.

17. Click OK.

18. Click OK.

Windows Server 2022 Tutorials

Источник

Научно-образовательный журнал для студентов и преподавателей «StudNet» №4/2021

ОПРЕДЕЛЕНИЕ УГРОЗ И КЛАСС ЗАЩИЩЕННОСТИ ПРЕДПРИЯТИЯ

DEFINITION OF THREATS AND CLASS OF PROTECTION OF THE

ENTERPRISE

УДК 004.056

Дворников Сергей Викторович, магистрант, Донской государственный технический университет, г. Ростов-на-Дону

Dvornikov S.V. [email protected]

Аннотация

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

Annotation

The protection of personal data in enterprises is an urgent issue with the growth of the Internet and threats to data. The storage and processing of personal data is regulated by law. The paper considers possible types and classification of threats, and also defines the class of enterprise security. Recommendations for information protection are given.

Ключевые слова: угроза информации, несанкционированный доступ, классы, персональные данные, защита информации.

Key words: information threat, unauthorized access, classes, personal data, information protection.

Современный мир — это мир товарно-денежных отношений. Ими пронизана внутренняя жизнь любого государства. Товарные отношения достигают огромных размеров, и работать с таким количеством данных рационально на компьютерных системах. Это позволяет быстрее и удобнее оперировать необходимой информацией. Но помимо общих данных, нужно хранить персональные данные клиентов. Для того чтобы правильно хранить и оперировать персональными данными (ПДн), а также обеспечить их безопасность будем использовать Федеральный закон от 27.07.2006 N 152-ФЗ (ред. от 31.12.2017) «О персональных данных» [1] и Постановление Правительства РФ от 01.11.2012 N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» [2]. Также целесообразным будет использование для защиты персональных данных специализированных средств защиты.

Прежде чем определять класс защищенности предприятия необходимо рассмотреть угрозы информации для данного предприятия.

Виды и источники угроз для рассматриваемого предприятия:

1. Устаревшее программное обеспечение. 1С: Предприятие не обновлено до последней версии. С антивирусом также не известно как часто его обновляет системный администратор предприятия.

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

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

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

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

6. Несанкционированный доступ (НСД) к информации со стороны заинтересованных организаций и отдельных лиц. Сюда может относится промышленный шпионаж конкурентов, атаки хакеров и т.п.

7. Компьютерные вирусы и иные вредоносные программы. Могут парализовать работу предприятия на неопределенное время, что невыгодно для компании. Более часто встречающиеся вредоносные программы — это трояны, вымогатели, руткиты и т.д. Вымогатели или как еще называются «шифровальщики» атакуют компьютер и требуют выкуп за восстановление зашифрованных файлов. Шпионские программы — это программы, которые следят за деятельностью пользователя и крадут личную информацию. Клавиатурные шпионы: считывают всю информацию, которая вводится с клавиатуры. Backdoor трояны: оставляют в системе проходы (дыры), чтобы войти в компьютерную систему.

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

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

Классы каналов несанкционированного получения информации могут зависеть от того, с какими элементами объекта обработки информации взаимодействовал злоумышленник. А именно [3]:

1) каналы от источника информации при НСД к нему:

— кража носителей информации;

— копирование информации;

— подслушивание разговоров, также и аудиозапись;

— установка в помещении закладных устройств и съем информации с их помощью;

— выведывание информации обслуживающего персонала;

— фотографирование или видеосъемка информации внутри помещения.

2) каналы со средств обработки информации при НСД к ним:

— снятие информации с устройств памяти;

— установка закладных устройств в средства обработки информации;

— ввод программных продуктов, позволяющих злоумышленнику получать информацию;

— копирование информации с технических устройств отображения.

3) каналы от источника информация без НСД

— получение информации по акустическим и виброакустическим каналам;

— использование технических средств оптической разведки;

— осмотр отходов и мусора;

— выведывание информации у сотрудников за пределами объекта;

4) каналы со средств обработки без НСД к ним:

— электромагнитные излучения средств обработки информации и излучения линий связи;

— подключений к линиям связи;

— снятие наводок электрических сигналов, а также с системы питания, заземления и теплоснабжения;

— подключение к базам данных по компьютерным сетям.

Потенциально возможные действия злоумышленника:

1) кража документов в бумажном и/или электронном виде, а также кража носителей информации;

2) копирование информации с носителей;

3) подслушивание разговоров и/или аудиозапись;

4) ксерокопирование, фотографирование или видеосъемка;

5) кратковременное проникновение в помещение, с целью установки прослушивающих устройств, кражи или ксерокопии документов;

6) прослушивание помещения;

7) внедрение своих людей в состав персонала конкурирующей фирмы.

Чтобы определить класс (уровень) защиты ПДн для данного предприятия

воспользуемся Постановлением Правительства РФ от 01.11.2012 N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» (рисунок 2).

Сначала необходимо определить категорию обрабатываемых ПДн.

Существует 4 категории ПДн [2]:

1) специальные категории ПДн, к которым относятся информация о национальной и расовой принадлежности субъекта, о религиозных, философских либо политических убеждениях, информацию о здоровье и интимной жизни субъекта;

2) биометрические ПДн, то есть данные, характеризующие биологические или физиологические особенности субъекта, например, фотография или отпечатки пальцев;

3) общедоступные ПДн, то есть сведения о субъекте, полный и неограниченный доступ к которым предоставлен самим субъектом;

4) иные категории ПДн, не представленные в трех предыдущих группах.

По форме отношений между вашей организацией и субъектами обработки подразделяются на 2 вида:

— обработка ПДН работников (субъектов, с которыми ваша организация связана трудовыми отношениями);

— обработка ПДн субъектов, не являющихся работниками вашей организации.

По количеству субъектов, ПДн которых обрабатываются, нормативным актом определены лишь 2 категории:

менее 100 000 субъектов; более 100 000 субъектов;

Типы актуальных угроз:

— угрозы 1-го типа связанны с наличием недекларированных (недокументированных) возможностей в системном ПО, используемом в информационной системе персональных данных (ИСПДн);

— угрозы 2-го типа связанны с наличием недекларированных возможностей в прикладном ПО, используемом в ИСПДн;

— угрозы 3-го типа не связаны с наличием недекларированных возможностей в программном обеспечении, используемом в ИСПДн.

Категории ПДн Специальные Биометрические Иные Общедоступные

Собственные работники нет нет да нет нет да нет нет да

Количество субъектов более 100 тыс менее 100 тыс более 100 тыс менее 100 тыс более 100 тыс менее 100 тыс

Тип актуальных угроз 1 1УЗ 1 УЗ 1 УЗ 1УЗ 1 УЗ 2 УЗ 2 УЗ 2 УЗ 2 УЗ 2 УЗ

2 1 УЗ 2 УЗ 2 УЗ 2 УЗ 2 УЗ ЗУЗ ЗУЗ 2 УЗ ЗУЗ ЗУЗ

3 2 УЗ ЗУЗ ЗУЗ ЗУЗ ЗУЗ 4 УЗ 4 УЗ 4 УЗ 4 УЗ 4 УЗ

Рисунок 2 — определение уровня защиты ПДн.

Для данного предприятия подходит 4 уровень защиты, так как:

— обрабатываются ПДн, относящиеся к категории «иные»;

— обрабатываются ПДн субъектов, не являющихся работниками данной организации;

— количество субъектов ПДн, которые обрабатываются в организации, не превышает 100 000 субъектов;

Для предприятия актуален 3 тип актуальных угроз.

Увеличение защищенности объекта защиты.

Требования к защите информации

— защита информации должна быть адекватной уровню важности и секретности защищаемой на предприятии информации;

— стоимость защиты не должна превышать возможный ущерб при нарушении целостности, конфиденциальности и доступности информации;

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

— защита не может быть однократной, она должна быть постоянной и непрерывной;

— защита должна быть комплексной.

Факторы, влияющие на требуемый уровень защиты информации.

Требуемый уровень защиты информации на каком — либо предприятии зависит от множества условий и факторов [4], а именно:

— от степени секретности обрабатываемой информации;

— от объема и масштаба обрабатываемой информации;

— от скорости и количеству обработки данных;

— от размера архитектуры и территориальной распределённости;

— от уровня подготовки и воспитания кадров;

— от уровня дисциплины и проводимых мероприятий по защите информации.

На компьютерах установлена операционная система windows 10, приобретена лицензия. Главное вовремя обновлять и проблем не будет.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Далее 1С: Предприятие следует установить последнее обновление, так как лицензия есть больше нечего не требуется.

На компьютерах данного предприятия установлен бесплатный антивирус Avast. Целесообразнее и надежнее было бы установить лицензионный антивирус Касперского для корпоративной сети, например, «Kaspersky Endpoint Security для бизнеса стандартный». С его помощью можно обеспечить надежную защиту.

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

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

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

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

Также можно настроить систему мониторинга. Она позволяет досконально знать, что делают ваша сеть, сервера и рабочие станции, также предоставит информацию для выявления и анализа проблем. Это даст возможность отслеживать в каком состоянии техника и сеть и контролировать работу сотрудников. Вот пример нескольких из них: 7аЬЫх, Observшm, Nagios.

В данной работе было рассмотрено предприятие, в котором были проведены мероприятия для повышения защиты ПДн.

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

Литература

1. Федеральный закон «О персональных данных» от 27.07.2006 N 152-ФЗ -Москва : Эксмо, 2019. — 32 с. (законы и кодексы).

2. Постановление Правительства РФ от 01.11.2012 N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» — [Электронный ресурс]. — Режим доступа: http://www.consultant.ru/document/cons_doc_LAW_137356/

3. «Классы каналов несанкционированного получения информации» -[Электронный ресурс]. — Режим доступа: https://lektsii.org/5-79462.html

4. «Факторы, влияющие на требуемый уровень защиты» — [Электронный ресурс]. — Режим доступа: https://studfile.net/preview/3657038/page:2/

Literature

1. Federal Law «On Personal Data» of July 27, 2006 N 152-FZ — Moscow: Eksmo, 2019. — 32 p. (laws and codes).

2. Decree of the Government of the Russian Federation of 01.11.2012 N 1119 «On approval of requirements for the protection of personal data when processing them in personal data information systems» — [Electronic resource]. — Access mode: http://www.consultant.ru/document/cons_doc_LAW_137356/

3. «Classes of channels for unauthorized obtaining of information» — [Electronic resource]. — Access mode: https://lektsii.org/5-79462.html

4. «Factors affecting the required level of protection» — [Electronic resource]. -Access mode: https://studfile.net/preview/3657038/page:2/

Источник

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

Время на прочтение21 мин

Количество просмотров50K

Как известно каждому системному администратору 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. После этого, само собой, вы определяете тип таких хранимых данных на своих файловых ресурсах. Вы задаете свойства, согласно которым файлы не могут быть случайно удалены конечными пользователями, а также определяете свойства классификации.
Аудит доступа к файлам. В конце концов, очень важным сценарием выступает аудит безопасности, позволяющий поддерживать порядок и благополучие в вашей среде. Какова основная задача? Естественно, это соблюдение порядка в компании и искоренение неправомерных деяний, которые могут происходить в вашей среде. Тогда может возникнуть следующий вопрос: что позволяет делать аудит безопасности в данном ключе? Тут не сложно догадаться, что аудит безопасности позволяет отслеживать соблюдение установленных вами политик, а также позволяет выявлять и предотвращать вероятностные уязвимости и, в случае необходимости, как сейчас принято выражаться, позволяет выполнять так называемый криминалистический анализ.
Что же можно сделать с динамическим контролем доступа для соблюдения аудита безопасности? Во-первых, можно настраивать политики аудита на основании конкретных выражений. Что это означает: можно создавать так называемые адресные политики аудита, основанные на требованиях ресурсов, пользователей или их устройств. Во-вторых, можно формировать события аудита при любой попытке доступа к целевым файлам, после чего фильтровать журналы событий на наличие потенциальных точек уязвимости. Более того, вы, естественно, можете определять изменения на основании изменений в атрибутах конкретных файлов, что может повлиять на ограничение доступа, изменения атрибутов конечных пользователей и компьютеров, что, в свою очередь, может послужить как причиной возникновения проблем доступа к жизненно важным файлам, так и дать пользователям излишние права. Также вы можете определять изменения в определениях утверждений, которые включают в себя имя, описание или какие-либо дополнительные значения свойств, изменения связанные с центрированными политиками и какими-либо правами доступа к ресурсам, определяющими то, кто именно может использовать необходимые ресурсы, а также многое другое.
Естественно, на этих всех моментах, как и на возможностях всех предшествующих сценариев, я еще остановлюсь более подробно, с живыми примерами и процедурами настройки.

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

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

Источник