Аудит входа в систему windows server 2012

При расследовании различных инцидентов администратору необходимо получить информацию кто и когда заходил на определенный компьютер Windows. Историю входов пользователя в доменной сети можно получить из журналов контроллеров домена. Но иногда проще получить информацию непосредсвенно из логов компьютера. В этой статье мы покажем, как получить и проанализировать историю входа пользователей на компьютер/сервер Windows. Такая статистика поможет вам ответить на вопрос “Как в Windows проверить кто и когда использовал этот компьютере”.

Настройка политики аудита входа пользователей в Windows

Сначала нужно включить политик аудита входа пользователей. На отдельностоящем компьютере для настройки параметров локальной групповой политики используется оснастка gpedit.msc. Если вы хотите включить политику для компьютеров в домене Active Directorty, нужно использовать редактор доменных GPO (
gpmc.msc
).

1. Запустите консоль GPMC, создайте новую GPO и назначьте ее на Organizational Units (OU) с компьютерами и / или серверами, для которых вы хотите включить политику аудита событий входа;
2. Откройте объект GPO и перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings –> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff;
3. Включите две политики аудита Audit Logon и Audit Logoff. Это позволит отслеживать как события входа, так и события выхода пользователей. Если вы хотите отслеживать только успешные события входа, включите в настройках политик только опцию Success;
4. Закройте редактор GPO и обновите настройки политик на клиентах.

Поиск событий входа пользователей в журнале событий Windows

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

1. Откройте оснастку Event Viewer (
   eventvwr.msc
   );
2. Разверните секцию Windows Logs и выберите журнал Security;
3. Щелкните по нему правой клавишей и выберите пункт Filter Current Log;
4. В поле укажите ID события 4624 и нажмите OK;
5. В окне события останутся только события входа пользователей, системных служб с описанием
   An account was successfully logged on
   ;
6. В описании события указано имя и домен пользователя, вошедшего в систему:

   New Logon:
   Security ID: WINITPROa.khramov
   Account Name: a.khramov
   Account Domain: WINITPRO

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

При удаленном подключении к рабочему столу компьютера по RDP, в журнале событий появится записи с Logon Type 10 или 3. Подробнее об анализе RDP логов в Windows.

В соответствии с этой таблицей событие локального входа пользователя на компьютер должно содержать Logon Type: 2.

Для фильтрации события входа по содержать Logon Type лучше использовать PowerShell.

Анализ событий входа пользователей в Windows с помощью PowerShell

Допустим, наша задача получить информацию о том, какие пользователи входили на этот компьютер за последнее время. Нам интересует именно события интерактивного входа (через консоль) с
LogonType =2
. Для выбора события из журналов Event Viewer мы воспользуемся командлетом Get-WinEvent.

Следующий PowerShell скрипт выведет история входа пользователей на текущий компьютер и представит ее в виде графической таблицы Out-GridView.

$query = @'
<QueryList>
<Query Id='0' Path='Security'>
<Select Path='Security'>
*[System[EventID='4624']
and(
EventData[Data[@Name='VirtualAccount']='%%1843']
and
EventData[Data[@Name='LogonType']='2']
)
]
</Select>
</Query>
</QueryList>
'@
$properties = @(
@{n='User';e={$_.Properties[5].Value}},
@{n='Domain';e={$_.Properties[6].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LogonType';e={$_.Properties[8].Value}}
)
Get-WinEvent -FilterXml $query | Select-Object $properties|Out-GridView

Если нужно выбрать события входа за последние несколько дней, можно добавить pipe с таким условием:

|Where-Object {$_.TimeStamp -gt '5/10/22'}

Командлет Get-WinEvent позволяет получить информацию с удаленных компьютеров. Например, чтобы получить историю входов с двух компьютеров, выполните следующий скрипт:

'msk-comp1', 'msk-comp2' |
ForEach-Object {
Get-WinEvent -ComputerName $_ -FilterXml $query | Select-Object $properties
}

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

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

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

Рисунок 6. Вкладка с описанием политики

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

Настройка политик аудита

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

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

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Выводы

Настройка необходимых для мониторинга политик аудита, локальное долговременное хранение журналов, протоколирование запуска процессов и команд PowerShell позволит не упустить важные события безопасности и тщательно расследовать инциденты. Это — один из ключевых этапов в построении процессов непрерывного мониторинга, снижения рисков ИБ и повышения уровня защищённости.

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

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

Открываем редактор групповых политик — Пуск — в строке поиска пишем gpedit.msc и нажимаем Ввод. Если вывляетесь администратором контроллера домена, можно нстроить данную групповую политику на контроллере домена.

Открываем следующий путь: Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Audit Policy.

Дабл кликаем параметр групповой политики Audit logon events. В окне свойств устанавливаем Success чекбокс для записи в журнал успешных входов в систему. Также можно установить чекбокс Failure для журналирования неудачных попыток входа в систему.

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

Для просмотра данных событий открываем Оснастку Просмотр событий — нажимаем меню Пуск — пишем Просмотр событий (Event Viewer) и нажимаем Ввод

Открываем путь Windows Logs –> Security.

Смотрим события:

• ID 4624 – это события успехов входа в систему.
• ID 4625 – это события отказов входа в систему.

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

Если у вас в журнале записано много событий, среди которых сложно отделить события с ID 4624 или 4625, можно воспользоваться фильтром. Для этого в правой части окна нажимаем кнопку Фильтр текущего журнала…

В открывшемся окне настроек фильтра, введите интересующий вас ID:

Как видно элементов в журнале существенно поубавилось:

На этом все. Если есть вопросы, уточнения, замечания — пишите.

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

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

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

Включаем «Аудит входа в систему»

Во-первых, откройте «Редактор локальной групповой политики» – откройте меню «Пуск», в поисковую строку введите gpedit.msc и нажмите Enter.

В левой части окна проследуйте по следующему пути: Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита.

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

Просматриваем события входа в систему

После включения этого параметра, Windows начнет регистрировать (в журнал безопасности) все события входа в систему, в том числе имя пользователя и время. Чтобы увидеть эти события, запустите инструмент «Просмотр событий» – откройте меню «Пуск», в строку поиска введите текст «Просмотр событий» и нажмите клавишу Enter.

Далее перейдите в «Журналы Windows» и выберите категорию «Безопасность». Нас интересуют события с кодом 4624 – это события успешного входа в систему.

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

Если вы хотите, чтобы в журнале безопасности отображались исключительно события входа, нажмите на кнопку «Фильтровать текущий журнал», которая расположена в боковой панели справа и в появившемся окне отфильтруйте события как на скриншоте ниже:

Отличного Вам дня!

Мы продолжаем перевод и публикацию материалов, связанных с Windows Server 2012 и обновлениями штатных систем аудита Microsoft. Приглашаем заинтересованных читателей ознакомиться с рассказом сотрудника команды Windows Server о новых возможностях Dynamic Access Control.

Здравствуйте, меня зовут Nir Ben-Zvi, я работаю в команде Windows Server. Я рад представить вам сегодня новый набор функций для Динамического контроля доступом (Dynamic Access Control), который имеется в Windows Server 2012.

Сначала я вкратце расскажу о процессе планирования, затем мы рассмотрим новую модель политики центрального доступа (Central Access Policy) и опишем что нового в Файловом Сервере, решении, которое мы встроили в Windows Server 2012. Я также вопросов постепенного внедрения, так чтобы Вам не нужно было перемещать всю среду на Windows Server 2012, если Вам нужно использовать данную функцию. В конце мы рассмотрим вопросы, связанные с тем какие решения наших партнеров помогут расширить предлагаемых функционал наших решений.
Введение

В современных (читай: сложных) IT-инфраструктурах создание данных происходит с ошеломляющей скоростью в рассредоточенных системах; одновременно доступ к этим данным осуществляется с многочисленных устройств. Выполнение требований нормативов по информационной безопасности и потребность в защите конфиденциальной информации от утечек – одни из важнейших проблем для бизнеса и IT. Чтобы эти проблемы были успешно решены – необходимо контролировать, кто получил доступ к определенной информации, причем желательно, чтобы желательно, чтобы при осуществлении такого контроля информация о доступе была представлена максимально наглядно.
Мы были в курсе этим проблем, стоящих перед бизнесом и IT уже пару лет назад, когда планировали, каким будет Windows Server 2012. Вот только несколько часто встречающихся запросов со стороны наших клиентов:

• Централизованное управление доступом к информации как на основе запросов бизнеса, так и с целью выполнения требований нормативов
• Должен осуществляться аудит доступа к информации для целей анализа и выполнения требований нормативов по ИБ
• Конфиденциальная информация должна быть защищена
• Владельцы контента должны быть ответственны за свою информацию – администраторы не должны заниматься не своей работой
• Ключевым аспектом является поддержание продуктивности деятельности специалистов, работающих с информацией
Мы взглянули на отдельные должностные позиции в организации и их взаимодействие в процессе выполнения запросов со стороны бизнеса, и регулирующих органов, чтобы представить адекватный запросам набор технологий и решений.
Таким образом, список должностей, вовлеченных в решение обозначенных проблем, начинается с CSO/CIO, который определяет потребности с позиций бизнеса и выполнения требований нормативов. За ними следуют IT-администраторы, которые осуществляют управление системами, и владельцы контента, которые контролируют фактическую информацию. Что касается тех, кто непосредственно работает с информацией, то влияние применяемых решений на них должно быть минимальным (в идеале его не должно быть совсем).

Чтобы помочь организациям выполнить требования нормативов и решить стоящие перед ними бизнес-задачи, мы в конечном итоге, сфокусировались на следующих сферах:
• Определение информации, управление которой должно осуществляться для достижения поставленных целей
• Применение политик доступа к информации
• Аудит доступа к информации
• Шифрование информации
Эти задачи были переведены в набор функций Windows, которые делают возможным защиту данных с помощью решений Windows и решений партнеров.
• Добавлена возможность конфигурировать в Active Directory централизованный доступ (Central Access) и политики аудита. Эти политики основаны на условных требованиях (см. ниже); при этом могут быть значительно снижено число групп безопасности для контроля доступа:
o Кем является пользователь
o Какое устройство он использует
o К каким данным получен доступ
• Заявки (claims) интегрированы в аутентификацию Windows (Kerberos), так что пользователи и устройства могут быть описаны не только посредством групп безопасности, в которых они состоят, но также и по заявкам, например: “Пользователь из Отдела финансов”, и “Категория доступа (security clearance) пользователя высокая”.
• Улучшена инфраструктура классификации файлов (File Classification Infrastructure), что позволит владельцам контента и пользователям идентифицировать (присваивать теги) их данные, так что IT-администраторы могут создавать целевые политики, основываясь на этих тегах. Эта возможность работает наряду с возможностью инфраструктуры классификации файлов автоматически классифицировать файлы на основании их содержимого или других характеристик.
• Интегрированы службы управления правами (Rights Management Services), чтобы автоматически защищать (шифровать) конфиденциальную информацию на серверах, так что даже тогда, когда она покидает сервер, она защищена.

Политики центрального доступа

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

Инициатива по внедрению и усилению политики центрального доступа произрастает из различных причин и из различных уровней организации:
• Политика, связанная с выполнением требований нормативов: Эта политика соотносится с требованиями нормативов и бизнеса и нацелена на защиту правильного (адекватно установленного) доступа к информации, управление которой осуществляется. Например, дать доступ к информации, которая подпадает под регулирующие документы “US-EU Safe Harbor”, только определенной группе пользователей.
• Политика разрешений на уровне отделов: Каждый отдел в организации имеет определенные требования к работе с данными, которые бы они хотели бы защитить (укрепить). Такая ситуация часто встречается в организациях с разветвленной организационной структурой. Например, отдел финансов хочет ограничить доступ к финансовой информации только для финансовых работников.
• Политика “необходимо знать” (Need to know policy): Эта политика гарантирует, что доступ допускается только тем, кому “необходимо знать”. Например:
o Вендоры должны получать доступ к информации и редактировать только файлы, которые относятся к проектам, над которым они работают.
o В финансовых учреждениях “стены” между информацией важны, например, аналитики не должны получать доступ к брокерской информации, а брокеры – к аналитической.
Политики центрального аудита

Политика центрального аудита (Central Audit Policy) – мощный инструмент, который позволяют поддерживать безопасность организации. Одной из ключевых целей аудита безопасности является выполнение требований нормативов по информационной безопасности. Отраслевые стандарты, такие как SOX, HIPPA, PCI и другие требуют от организаций следовать жестко установленному набору правил, связанных с информационной безопасностью и конфиденциальностью данных (privacy). Работа аудиторов заключается в том, чтобы установить наличие (или отсутствие) таких политик, тем самым доказывается выполнение (или не выполнение) требований этих стандартов. Вдобавок, аудит безопасности позволяют фиксировать аномальное поведение, определять и избегать образования дыр в системе безопасности и ограничивать несанкционированное поведение – любая важная деятельность пользователей записывается, а такие записи могут быть использованы при проведении расследования.

Windows Server 2012 позволяет администраторам разрабатывать политики аудита, используя выражения, которые принимают во внимание то, к какой информации пользователи получают доступ и кем эти пользователи являются, так что организация может осуществлять аудит доступа только к определенной информации, вне зависимости от того, где бы они не находилась. Это открывает дорогу к более целевым и в то же время простым в использовании политикам аудита. Теперь можно реализовывать сценарии, которые до настоящего момента было сложно осуществить. Например, Вы можете легко разработать политики аудита, которые перечислены ниже:
• Аудит всех, у которого нет высокой категории допуска и кто, тем не менее, пытается получить доступ к “важной” информации
• Аудит всех вендоров, которые пытаются получить доступ к документам по проектам, над которыми они не работают.

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

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

Основываясь на подобной инфраструктуре, мы разработали комплексное решение для Windows Server 2012 Active Directory, Windows Server 2012 File Server и Windows 8 client. Это решение позволяет вам:
• Идентифицировать данные, используя автоматическую и ручную классификацию файлов.
• Контролировать доступ к файлам по всем серверам, применяя гарантию (safety net) политик центрального доступа. Например, Вы можете контролировать, кто получает информацию о здоровье сети по всей организации.
• Аудит доступа к файлам на файловых серверах, используют политики центрального аудита для целей выполнения нормативов по информационной безопасности и проведения расследований. Например, Вы можете определить, кто получил доступ к высоко конфиденциальной информации за последние три месяца.
• Шифрование данных посредством автоматического применения шифрования служб управления правами (Rights Management Services (RMS)) для конфиденциальных документов. Например, Вы можете настроить RMS на шифрование всех документов, которые содержат информацию, защищаемую нормативом HIPAA.

Для того чтобы поддержать внедрение на множестве файловых серверов в организации, мы также предоставляем Data Classification Toolkit, который позволяет осуществлять настройку и формирования отчетов среди многочисленных серверов.
Бета-версию Data Classification Toolkit можно скачать здесь.

Концепция постепенного внедрения

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

Вы можете использовать большинство из возможностей Dynamic Access Control в файловом сервере Windows Server 2012 и обновленной схеме домена Active Directory. Добавление минимального числа контроллеров доменов Windows Server 2012 позволить включить пользовательские заявки и т.д. Каждая часть системы, которую Вы обновите, даст Вам больше возможностей, однако задавать скорость внедрения – это уже на ваше усмотрение.

Решения партнеров

Решения партнеров и ряд бизнес приложений может повысить эффективность использования инвестиций в инфраструктуру Windows для Dynamic Access Control, обеспечивая ценность для организаций, использующих Active Directory. Вот лишь некоторые примеры партнерских решений, которые представляли на конференции в прошлом году:
• Интеграция систем предотвращения утечки данных (Data Leakage Prevention) с системой автоматической классификации содержимого
• Централизованный анализ данных аудита
• Авторизация служб управления правами (Rights Management Services) с использованием Central Access Policies
• Многие другие…

via Technet