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

Обеспечение безопасного доступа является первым логическим шагом к использованию облака предприятием. Установка политик соответствия стандартам, отчетности и удаленного подключения сейчас обеспечивает гладкость и безопасность будущей работы коллектива в облаке. Использование защиты доступа к сети (NAP) с технологиями подключения IPsec, такими как DirectAccess, может помочь в этом за счет усовершенствования аудита и отчетности по соответствию нормативам.

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

Проблема соответствия

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

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

В то время как пользователи требуют более простого удаленного доступа к ресурсам, необходимым им для работы, руководителям ИТ-отделов в этих сферах необходимо также предотвратить доступ недопустимых клиентов к корпоративным сетям. Увы, превращение журналов NAP и DirectAccess в осмысленные отчеты сопряжено с трудностями.

Решением является настройка инфраструктуры DirectAccess для удобного удаленного клиентского доступа, защита ресурсов интрасетей с помощью NAP и IPsec и отслеживание выполнения политики посредством отчетности. TechNet содержит полезную информацию по реализации NAP с DirectAccess, но с руководствами по эффективному протоколированию работоспособности клиентов и созданию отчетов о ней есть проблемы. Мы рассмотрим воображаемую компанию (Woodgrove National Bank) и покажем, как консультант может с помощью простого кода и запросов SQL создавать читаемые для человека отчеты, предоставляющие информацию о клиентах, подключавшихся в течении указанного промежутка времени, и их соответствии NAP.

Настройка NAP поверх DirectAccess

DirectAccess требует от подключающихся клиентов использовать совместимую версию Windows (Windows 7 Максимальная или Windows 7 Корпоративная). Означенные клиенты подключаются к серверу DirectAccess, использующему Windows Server 2008 R2. Развертывание DirectAccess может включать в себя один или несколько серверов DirectAccess. (Мы рекомендуем использовать не менее двух серверов, чтобы облегчить балансировку нагрузки на загруженных сетях.) Развертывание также должно включать в себя сервер сетевых расположений (для определения того, подключен ли клиент к Интернету или интрасети), а также одну или несколько точек распространения списка отзыва сертификатов (CRL), который используется для отслеживания клиентов, которым более не следует предоставлять доступ. О разработке развертываний DirectAccess рассказывает Руководство по разработке DirectAccess на TechNet.

При добавлении NAP к DirectAccess необходимо реализовать метод принудительной защиты доступа к сети с помощью IPsec. При использовании IPsec клиентам, соответствующим нормативам NAP, выдаются сертификаты работоспособности. Если компьютер не соответствует нормативам, ему не разрешается обмениваться информацией с компьютерами, которые им соответствуют. Информация о разработке и развертывании NAP приведена в документе Planning DirectAccess with Network Access Protection (Планирование DirectAccess с защитой доступа к сети) на TechNet. Информация о разработке принудительной защиты доступа к сети с помощью IPsec приведена в документе IPsec Enforcement Design (Разработка принудительной защиты с помощью IPsec) на TechNet.

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

Как NAP взаимодействует с политиками AuthIP? В сценарии принудительного защиты доступа к сети с помощью IPsec работоспособным компьютерам выдается сертификат с идентификатором работоспособности объекта (OID). Механизм политики AuthIP включает в себя возможность требовать этот OID. Таким образом, только работоспособные компьютеры будут отвечать требованиям проверки подлинности AuthIP и смогут устанавливать подключение IPsec к серверу DirectAccess.

Наконец, учетные данные пользователя являются целю второго варианта проверки подлинности AuthIP. Технически говоря, учетные данные пользователя не обязательны для DirectAccess. Другими словами, клиенты могут пройти проверку подлинности на конечной точке DirectAccess, используя только сертификат компьютера. Заботящихся о безопасности ИТ-сотрудников должна беспокоить перспектива предоставления полного доступа к сети без строгой проверки подлинности. В силу этого политика AuthIP должна быть, как минимум, настроена на требование второй проверки подлинности через Kerberos. Требование сертификата для учетных данных пользователя, как в случае Woodgrove National Bank, предпочтительней, поскольку оно уменьшает риск атак посредством удаленного подбора пароля.

В данном сценарии отделы сетевой безопасности и соответствия банка Woodgrove National Bank запросили отчет, показывающий, кто подключался к корпоративной сети на протяжении указанного периода времени и соответствовали ли эти клиенты нормативам NAP. Эти отделы считают, что в указанный ими период времени могло произойти нарушение конфиденциальности данных клиентов. В качестве консультантов банка нам необходимо решить, как обеспечить отчетность постфактум для DirectAccess и NAP, и затем свести полученную информацию в удобный для чтения отчет.

Адекватная настройка политики

В этой гипотетической ситуации Woodgrove National Bank настроил DirectAccess таким образом, что политика IPsec требует клиентских сертификатов, включающих OID работоспособности системы от NAP и OID проверки подлинности клиента. Банк Woodgrove использует NAP в режиме принудительного защиты доступа к сети (а не просто в режиме отчетов о доступе к сети), а это означает, что недопустимым клиентам не будет разрешено обмениваться информацией с допустимыми.

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

Нижеследующая часть статьи предполагает, что читатель разбирается в том, как работают DirectAccess, NAP и режим принудительного применения IPsec. Для получения дополнительных сведений об этих технологиях обратитесь к следующим источникам:

• DirectAccess Executive Overview (Обзор DirectAccess для руководителей)
• Введение в защиту доступа к сети
• Общее представление о принудительной защите доступа к сети с использованием IPsec

Нижеприведенное решение отчетов также пользуется встроенными функциями аудита IPsec на сервере DirectAccess и возможностями аудита центра регистрации работоспособности (HRA) сервера политики сети (NPS). Эти функции аудита создают события в системе и журналы событий безопасности, которые мы извлекаем и сводим в отчет. В ходе разработки этого подхода мы обнаружили, что события HRA создаются по умолчанию, тогда как события IPsec требуется включать специально. Для включения событий IPsec можно использовать следующие команды в окне командной строки:

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

Отчет о работоспособности DirectAccess

Чтобы начать работать с NAP и событиями DirectAccess из Woodgrove National Bank, мы загрузили и установили Log Parser 2.2 от Майкрософт. Log Parser – незаменимое средство для подобного проекта, в котором необходимо изучить новый источник событий и разработать соответствующую схему. Говоря кратко, Log Parser может осуществлять импорт из нескольких форматов данных, включая журнал событий Windows (.evtx), CSV и SQL, равно как и экспорт в них.

Следующим этапом является сбор интересующих нас событий. Они содержат:

• События, связанные с сопоставлениями безопасности IPsec в журнале безопасности серверов DirectAccess
• События, связанные с центром регистрации работоспособности (HRA) в системном журнале и журнале безопасности сервера HRA или каждого из нескольких серверов HRA (этот пункт применим только в случае использования NAP)

Идеальное решение для сбора этих событий должно быть автоматизированным и централизованным. Одним из возможных решений является функция пересылки событий Windows. Microsoft System Center будет более типичен для крупного развертывания в рабочей среде. В нашем случае мы стремились избежать создания новых зависимостей для рабочих серверов и использовали для сбора событий простые сценарии.

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

Для каждого из сопоставлений безопасности основного режима IPsec (на одном из серверов DirectAccess) мы ожидаем увидеть поток данных NAP о работоспособности (на одном из серверов HRA). В режиме отчетов о доступе к сети NAP, клиентский компьютер может соответствовать нормативам или нет. В режиме принудительной защиты доступа к сети NAP, клиентский компьютер обязан соответствовать нормативам. В ином случае у него не будет действительного сертификата для проверки подлинности на сервере DirectAccess и установки сопоставления безопасности (SA). Предположим, мы выполняем однократный сбор журналов на всех серверах DirectAccess и HRA одновременно в 15:00. Вполне возможно, что мы увидим событие сопоставления безопасности основного режима (MM SA), но не событие работоспособности.

Еще более вероятно, что мы увидим события сопоставления безопасности быстрого режима (QM SA) IPsec и сопоставления безопасности расширенного режима (EM SA) IPsec, но не события MM SA или работоспособности. Первое может отставать от второго на час или более. Кроме того, поскольку журналы на различных серверах почти наверняка переполняются с различной частотой, на сервере DirectAccess в журнале могут оставаться события, скажем, за 14:00, а на сервере HRA – только за 14:30 и позднее. Поэтому мы хотим повторить, что в рабочей среде важно использовать централизованный сбор событий.

Создание данных

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

Сбор данных на сервере DirectAccess

Мы использовали следующий сценарий для сбора событий с сервера DirectAccess (см. рис. 1):

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CS

Примечание. Этот сценарий использует локальную копию LogParser.exe (и ее зависимость, LogParser.dll). Эта ссылка упрощает работу, позволяя легко копировать сценарий с сервера на сервер.

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

Сбор данных на серверах HRA

Мы использовали следующий сценарий для сбора событий с серверов HRA:

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV

Примечание. В сценарии HRA событие категории 12552 соответствует службе сервера политики сети.

Импорт данных

По завершении работы сценариев, мы собрали выданные ими файлы CSV на отдельном компьютере с SQL Server 2008. Мы использовали следующий сценарий для импорта данных CSV в SQL:

LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

LogParser.exe "SELECT * INTO HraSecurityEventsTable FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

LogParser.exe "SELECT * INTO HraSystemEventsTable FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

Примечания.

• Имя размещающего компьютера SQL – dev1. База данных именуется NapDa, и она была создана с использованием значений по умолчанию в SQL Management Studio.
• Три таблицы, DaSasTable, HraSecurityEventsTable и HraSystemEventsTable не были созданы заранее. Параметр командной строки -createTable:ONLog Parser указывает Log Parser автоматически создать эти таблицы со схемой, основанной на входящих данных (в данном случае файлах CSV журналов событий).
• В этом сценарии важен параметр -maxStrFieldLen:1023. Без него длина поля varchar по умолчанию (255) будет использоваться Log Parser для различных строковых полей журнала событий. Однако, формат журналов событий CSV включает и более длинные строки данных (особенно в поле Строки; см. рис. 2) и важно, чтобы они не были усечены. На основе экспериментов, длина по умолчанию 1023 представляется адекватной.

Рис. 2 показывает схему, созданную в результате импорта журнала событий CSV Log Parser.

Рис. 2 Схема для импорта журнала событий CSV Log Parser.

Обработка данных

Основная проблема извлечения нужных данных при создании отчета о работоспособности DirectAccess состоит в том, что формат журналов событий CSV основан на строках данных. В контексте графического интерфейса пользователя данные располагаются в форме чередующихся статических строк, описывающих значение каждого поля данных. Строки данных включают в себя всё, что интересно для отчета о работоспособности DirectAccess, в том числе имена пользователей, имена компьютеров, имена групп политик и IP-адреса.

Строки данных сцепляются в единое поле CSV и, в конечном счете, в единый столбец SQL (опять же строк). Каждая из строк отделена от последующей знаком «|». Один из вариантов здесь – разметить строки перед импортом данных в SQL или сразу после него. Но мы предпочли проанализировать строки после импорта в SQL, извлечь конкретные необходимые нам элементы данных и заполнить отдельные таблицы SQL этими элементами.

Выполнить эту задачу посредством шаблона строк, соответствующего T-SQL, непросто. Как альтернативу этому мы использовали подход из предыдущей статьи в журнале MSDN Magazine, «Регулярные выражения упрощают сопоставления по шаблону и извлечение данных»– реализацию определенных пользователем функций для SQL с использованием C#, в частности в целях сопоставления по шаблону для регулярных выражений.

Используя Visual Studio 2008, мы почти в точности проследовали инструкциям из этой статьи, хотя нам также помогло обращение к дополнительной документации по обеспечению работы первоначальной интеграции SQL и CLR с Visual Studio. Кроме того, в силу сложности, неизбежно присущей регулярным выражениям (RegEx), нам также помогло обращение также и к докyментации для этой технологии, в частности разделу о группировании, поскольку именно этот подход использовался в примере кода из вышеупомянутой статьи в MSDN Magazine.

Нижеприведенный пример кода содержит исходный код для определенной пользователем функции SQL, которая предоставляет возможности RegEx нашим операторам SELECT. Эта функция именуется RegexGroup, подобно функции из статьи в MSDN Magazine. Мы внесли два изменения в первые две строки тела функции, которые позволяют проверять наличие значений ввода NULL. До добавления этих двух строк мы сталкивались с многочисленными исключениями, поскольку несколько из столбцов нашей вспомогательной таблицы SQL (описанной здесь) имеют значения NULL:

usingSystem;

usingSystem.Data;

usingSystem.Data.SqlClient;

usingSystem.Data.SqlTypes;

usingMicrosoft.SqlServer.Server;

usingSystem.Text.RegularExpressions;

publicpartialclassUserDefinedFunctions

{

    [Microsoft.SqlServer.Server.SqlFunction]

publicstaticSqlChars RegexGroup(

SqlChars input, SqlString pattern, SqlString name)

{

if (true == input.IsNull)

returnSqlChars.Null;

Regex regex = newRegex(pattern.Value, Options);

Match match = regex.Match(newstring(input.Value));

returnmatch.Success ?

newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;

}

};

Следующие команды SQL создают и заполняют две вспомогательные таблицы, состоящие из строк, извлеченных из первоначального набора данных с помощью RegEx:

/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)

/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
	dbo.RegexGroup([Strings],N'(?<un>[0-9a-zA-Z]+)@redmond.corp.microsoft.com',N'un'),
	dbo.RegexGroup([Strings],N'(?<machine>[0-9a-zA-Z\-]+)(?<!CO1RED-TPM-01)\$@redmond.corp.microsoft.com',N'machine'),
	dbo.RegexGroup([Strings],N'(?<ipv6addr>[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})',N'ipv6addr')
FROM [NapDa].[dbo].[DaSasTable]

/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)

/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
	TimeGenerated,
	EventType,
	dbo.RegexGroup([Strings],N'REDMOND\\(?<machine>[0-9a-zA-Z\-]+)\$',N'machine')
FROM [NapDa].[dbo].[HraSystemEventsTable]

/* The following steps build the report, based on the three imported tables

* plus the two helpers above. These steps can be run any number of times as

* you refine your query.

*/

/* Create a temporary table to populate as the final report */

CREATE TABLE #SaHealthReport
(

[UserName] varchar(1023) null,

[ComputerName] varchar(1023) null,

[HealthEventType] int null

)

/* Run a query to find all IPsec Quick Mode Security Associations established

* within a given period. Populate a temporary table with the client IPv6

* addresses. */

SELECT DISTINCT[Address] INTO #TempAddresses

FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]

      ON RowN = RowNumber

WHERE [EventType]=8 AND

      [EventCategory]=12549 AND

      ([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')

/* Map the QM SA addresses to user and computer names and insert those into

* the final report. */

INSERT INTO #SaHealthReport(UserName,ComputerName)

SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName

FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses

      ON #TempAddresses.Address = UserComputerAndAddr.Address

WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)

/* Populate the health column of the report. */

UPDATE #SaHealthReport

SET HealthEventType = ComputerHealth.EventType

FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]

      ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName

/* Display all rows and columns of the report. */

SELECT DISTINCT *

FROM #SaHealthReport

Финальным этапом заполнения таблицы отчета SaHealthReport является соотнесение информации о работоспособности HRA с информацией о компьютерах и пользователях, взятой с сервера DirectAccess. Включение информации с сервера HRA в эту смесь является мощным средством, позволяющим определить, не создают ли компьютеры, удаленно подключающиеся вашей к сети, угрозы (за счет своего несоответствия нормативам). См. оператор UPDATE в предыдущем запросе SQL – сопоставление данных DirectAccess и данных HRA выполняется путем использования имени компьютера клиента.

Рис. 5 показывает пример данных, которые могут быть возвращены готовым отчетом о работоспособности.

Рис. 5. Пример завершенного отчета о работоспособности

Организовать создание отчетов в развертывании IPsec (включая DirectAccess) и NAP с помощью нескольких сценариев и средства LogParser относительно просто. Этот подход поможет компании создать безопасную инфраструктуру для предоставления бизнес-услуг, как с сайта, так и в облаке.