Это интересно
- ОКД
- ЗКС
- ИПО
- КНПВ
- Мондиоринг
- Большой ринг
- Французский ринг
- Аджилити
- Фризби
Опрос
Полезные ссылки
РКФ
Все о дрессировке собак
Стрижка собак в Коломне
Поиск по сайту
Реализация политики безопасности в защищенных версиях операционной системы Windows. 1 какие события безопасности должны фиксироваться в журнале аудита
Реализация политики безопасности в защищенных версиях операционной системы Windows
Итак, существуют две модели доступа:
- Классическая: локальные пользователи проходят проверку подлинности со своей учетной записью.
- Только гости: локальные пользователи проходят проверку подлинности с учетной записью «Гость».
По умолчанию используется модель «Только гости» в Windows XP Professional.
Примечания
- Действие данного параметра не распространяется на вход в сеть с использованием учетных записей домена.
- Действие параметра не распространяется на интерактивный вход в сеть, выполняемый в удаленном режиме с использованием таких служб, как Telnet или службы терминалов.
- Если компьютер не присоединен к домену, данный параметр также определяет внешний вид вкладок Доступ и Безопасность проводника Windows: они настраиваются в соответствии с выбранной моделью доступа и безопасности.
Внимание!
- В случае гостевой модели любой пользователь, имеющий доступ к данному компьютеру через сеть (в том числе анонимный пользователь Интернета), получит доступ и к общим ресурсам этого компьютера. Следует обезопасить компьютер от несанкционированного доступа с помощью брандмауэра Windows или другого подобного устройства. Точно так же в случае классической модели локальные учетные записи должны быть защищены паролем; в противном случае любой пользователь сможет с помощью такой учетной записи получить доступ к общим системным ресурсам.
Данная политика неприменима на компьютерах Windows 2000.
4.Средства определения политики аудита.
Панель управления > Администрирование > Локальная политика безопасности > Локальные политики > Политика аудита.
А.) Установить регистрацию в журнале аудита успешных и неудачных попыток для следующих политик аудита:
4).Событий входа в систему.
Б).Какие ещё параметры политики аудита могут быть определены?
- Аудит доступа к объектам
- Аудит системных событий
- Аудит доступа к службе каталогов
- Аудит отслеживания процессов
В).Где расположен журнал аудита событий безопасности?
Панель управления > Администрирование >Просмотр событий > Безопасность.
Г).В чем заключается смысл параметров политики аудита?
Параметры политики аудита позволяют вести «Журнал аудита событий безопасности» в соответствии с потребностями пользователя ПК.
Тип события: Аудит успехов
Источник события: Security
Категория события: Изменение политики
Код события: 612
Дата: 08.12.2011
Время: 20:13:51
Пользователь: DOM\Antoha
Компьютер: DOM
Описание:
Изменение политики аудита:
Новая политика:
Успех Отказ
+ - Вход/выход
- - Доступ к объектам
- - Использование прав
- - Управление учетными записями
+ - Изменение политики
- - Системные события
+ - Подробное слежение
+ - Вход через учетную запись
Исполнитель:
Пользователь: Antoha
Имя домена: DOM
Код входа: (0x0,0x169E
Тип события: Аудит успехов
Источник события: Security
Категория события: Изменение политики
Код события: 612
Дата: 08.12.2011
Время: 20:14:13
Пользователь: DOM\Antoha
Компьютер: DOM
Описание:
Изменение политики аудита:
Новая политика:
Успех Отказ
+ - Вход/выход
- - Доступ к объектам
+ - Использование прав
- + Управление учетными записями
+ - Изменение политики
- - Системные события
+ - Подробное слежение
- + Доступ к службе каталогов
+ - Вход через учетную запись
Исполнитель:
Пользователь: Antoha
Имя домена: DOM
Код входа: (0x0,0x169EC)
Тип события: Аудит успехов
Источник события: Security
Категория события: Изменение политики
Код события: 612
Дата: 08.12.2011
Пользователь: DOM\Antoha
Компьютер: DOM
Описание:
Изменение политики аудита:
Новая политика:
Успех Отказ
+ - Вход/выход
- - Доступ к объектам
- - Использование прав
- - Управление учетными записями
- - Изменение политики
- - Системные события
- - Подробное слежение
- - Доступ к службе каталогов
- - Вход через учетную запись
Исполнитель:
Пользователь: Antoha
Имя домена: DOM
Код входа: (0x0,0x169EC)
6).Средства определения политики ограничений использования программ.
Это правило применяется к программам, установленным с помощью установщика Windows.
Г).Создание правила для пути.
В чем уязвимость с точки зрения безопасности информации принимаемая по умолчанию реакция системы на превышения размера журнала аудита?
Когда журнал безопасности переполнится, Windows XP перестанет отвечать на запросы и будет выведено сообщение "Неудачная попытка аудита". Чтобы восстановить после остановки Windows XP, необходимо очистить журнал безопасности.
Какое из дополнительных правил ограниченного использования программ кажется Вам наиболее эффективным и почему?
Выбор уровня безопасности для указанного пути. Доступны следующие уровни безопасности: неограниченный, позволяющий запускать программное обеспечение с полным набором прав зарегистрированного пользователя, и запрещенный, не позволяющий запускать программное обеспечение.
Из каких этапов состоит построение политики безопасности для компьютерной системы?
- определение, какие данные и насколько серьезно необходимо защищать,
- определение кто и какой ущерб может нанести фирме в информационном аспекте,
- вычисление рисков и определение схемы уменьшения их до приемлемой величины.
К чему может привести ошибочное определение политики безопасности (приведите пример)?
К потере или повреждению данных и(или) системы.
Почему, на ваш взгляд, многие системные администраторы пренебрегают использованием большинства из рассмотренных в данной лабораторной работе параметров политики безопасности?
Из-за недостатка времени и потому, что на большинстве компьютеров они не нужны.
Какие события безопасности должны фиксироваться в журнале аудита?
В Журнале событий фиксируются следующие виды событий:
- Вход в систему
- Управление учетной записью
- Доступ к службе каталогов
- Доступ к объектам
- Изменения политики
- Использования привилегий
- Отслеживание процессов
- Системных событий
- Событий входа в систему
Количество событий, которые записываются в журнал, очень велико, поэтому анализ журнала событий может быть довольно трудоемкой задачей. Для этого разработаны специальные утилиты, помогающие выявлять подозрительные события. Кроме того, можно фильтровать журнал по задаваемым критериям.
Какие параметры определяют политику аудита?
referat911.ru
Аудит событий безопасности | Microsoft Docs
- 03/30/2017
- Время чтения: 8 мин
- Соавторы
В этой статье
Приложения, созданные с помощью Windows Communication Foundation (WCF) может регистрировать события безопасности (либо успешно, сбой или оба) с помощью функции аудита.Applications created with Windows Communication Foundation (WCF) can log security events (either success, failure, or both) with the auditing feature. События записываются в журнал системных событий Windows, и их можно просматривать при помощи средства просмотра событий.The events are written to the Windows system event log and can be examined using the Event Viewer.
Аудит позволяет администраторам обнаруживать уже законченную или происходящую атаку.Auditing provides a way for an administrator to detect an attack that has already occurred or is in progress. Кроме того, аудит может помочь разработчику при отладке неполадок, связанных с безопасностью.In addition, auditing can help a developer to debug security-related problems. Например, если в результате ошибки в конфигурации авторизации или политики проверки авторизованному пользователю было отказано в доступе, разработчик может быстро найти и понять причину такой ошибки, изучив журнал событий.For example, if an error in the configuration of the authorization or checking policy accidentally denies access to an authorized user, a developer can quickly discover and isolate the cause of this error by examining the event log.
Дополнительные сведения о безопасности WCF см. в разделе Общие сведения о безопасности.For more information about WCF security, see Security Overview. Дополнительные сведения о программирования WCF см. в разделе базовое Программирование WCF.For more information about programming WCF, see Basic WCF Programming.
Уровень и поведение аудитаAudit Level and Behavior
Предусмотрены два уровня аудита безопасности.Two levels of security audits exist:
Уровень авторизации службы, на котором производится авторизация вызывающего абонента.Service authorization level, in which a caller is authorized.
Уровень сообщений, в котором WCF проверяет допустимость сообщений и проверяет подлинность вызывающего.Message level, in which WCF checks for message validity and authenticates the caller.
Вы можете проверить аудита обеих уровней успешное выполнение или сбой, который называется поведением аудита.You can check both audit levels for success or failure, which is known as the audit behavior.
Расположение журнала аудитаAudit Log Location
После определения уровня и поведения аудита, вы (или администратор) можете задать расположение журнала аудита.Once you determine an audit level and behavior, you (or an administrator) can specify a location for the audit log. Доступны три варианта: журнал по умолчанию, журнал приложения и журнал безопасности.The three choices include: Default, Application, and Security. Если задан журнал по умолчанию, фактический журнал зависит от используемой системы и от того, поддерживает ли система запись в журнал безопасности.When you specify Default, the actual log depends on which system you are using and whether the system supports writing to the security log. Дополнительные сведения см. в разделе «Операционная система» далее в этом разделе.For more information, see the "Operating System" section later in this topic.
Для записи в журнал безопасности требуются привилегии SeAuditPrivilege.To write to the Security log requires the SeAuditPrivilege. По умолчанию этой привилегией обладают только учетные записи Local System и Network Service.By default, only Local System and Network Service accounts have this privilege. Для управления функциями read и delete журнала безопасности требуются привилегии SeSecurityPrivilege.To manage the Security log functions read and delete requires the SeSecurityPrivilege. По умолчанию эту привилегию имеют только администраторы.By default, only administrators have this privilege.
В отличие от этого авторизованные пользователи могут производить чтение и запись в журнал приложений.In contrast, authenticated users can read and write to the Application log. Windows XPWindows XP по умолчанию записывает события аудита в журнал приложения. writes audit events to the Application log by default. Этот журнал может также содержать персональный сведения, видимые всем авторизованным пользователям.The log can also contain personal information that is visible to all authenticated users.
Подавление сбоев аудитаSuppressing Audit Failures
При аудите можно также выбрать, следует ли подавлять сбои аудита.Another option during auditing is whether to suppress any audit failure. По умолчанию сбой аудита не влияет на приложение.By default, an audit failure does not affect an application. Однако при необходимости можно задать для этого параметра значение false, что приводит к возникновению исключения.If required, however, you can set the option to false, which causes an exception to be thrown.
Программирование аудитаProgramming Auditing
Поведение аудита можно задавать либо путем программирования, либо через конфигурацию.You can specify auditing behavior either programmatically or through configuration.
Классы аудитаAuditing Classes
В приведенной ниже таблице описаны классы и свойства, используемые для программирования поведения аудита.The following table describes the classes and properties used to program auditing behavior.
| ServiceSecurityAuditBehavior | Позволяет задавать параметры аудита в виде поведения службы.Enables setting options for auditing as a service behavior. |
| AuditLogLocation | Перечисление для задания журнала, в который требуется производить запись.Enumeration to specify which log to write to. Предусмотрены значения Default, Application и Security.The possible values are Default, Application, and Security. Если выбрано значение Default, фактическое расположение журнала определяется операционной системой.When you select Default, the operating system determines the actual log location. См. подраздел "Выбор журнала приложения или журнала безопасности" ниже в этом разделе.See the "Application or Security Event Log Choice" section later in this topic. |
| MessageAuthenticationAuditLevel | Задает тип событий проверки подлинности сообщений для аудита на уровне сообщения.Specifies which types of message authentication events are audited at the message level. Предусмотрены варианты None, Failure, Success и SuccessOrFailure.The choices are None, Failure, Success, and SuccessOrFailure. |
| ServiceAuthorizationAuditLevel | Задает тип событий авторизации службы для аудита на уровне службы.Specifies which types of service authorization events are audited at the service level. Предусмотрены варианты None, Failure, Success и SuccessOrFailure.The choices are None, Failure, Success, and SuccessOrFailure. |
| SuppressAuditFailure | Задает, что происходит с запросом клиента в случае сбоя аудита.Specifies what happens to the client request when auditing fails. Например, если служба пытается произвести запись в журнал безопасности, но не имеет привилегий SeAuditPrivilege.For example, when the service attempts to write to the security log, but does not have SeAuditPrivilege. Значение по умолчанию true означает, что сбои игнорируются и запрос клиента обрабатывается обычным образом.The default value of true indicates that failures are ignored, and the client request is processed normally. |
Пример настройки приложения для записи событий аудита см. в разделе как: аудит событий безопасности.For an example of setting up an application to log audit events, see How to: Audit Security Events.
КонфигурацияConfiguration
Чтобы задать поведение аудита, добавив также можно настроить конфигурацию <serviceSecurityAudit > под <поведения >.You can also use configuration to specify auditing behavior by adding a <serviceSecurityAudit> under the <behaviors>. Необходимо добавить элемент в списке <поведение > как показано в следующем коде.You must add the element under a <behavior> as shown in the following code.
<configuration> <system.serviceModel> <behaviors> <behavior> <!— auditLogLocation="Application" or "Security" -—> <serviceSecurityAudit auditLogLocation="Application" suppressAuditFailure="true" serviceAuthorizationAuditLevel="Failure" messageAuthenticationAuditLevel="SuccessOrFailure" /> </behavior> </behaviors> </system.serviceModel> </configuration>Если аудит включен и параметр auditLogLocation не задан, для систем, поддерживающих запись в журнал безопасности, по умолчанию используется журнал "Security"; в противном случае используется журнал "Application".If auditing is enabled and an auditLogLocation is not specified, the default log name is "Security" log for the platform supporting writing to the Security log; otherwise, it is "Application" log. Только операционные системы Windows Server 2003Windows Server 2003 и Windows VistaWindows Vista поддерживают запись в журнал безопасности.Only the Windows Server 2003Windows Server 2003 and Windows VistaWindows Vista operating systems support writing to the Security log. Дополнительные сведения см. в разделе «Операционная система» далее в этом разделе.For more information, see the "Operating System" section later in this topic.
Вопросы безопасностиSecurity Considerations
Если злоумышленник знает о том, что включен аудит, он может отправить недопустимые сообщения, приводящие к внесению записей аудита в журнал.If a malicious user knows that auditing is enabled, that attacker can send invalid messages that cause audit entries to be written. Если это приводит к заполнению журнала аудита, система аудита дает сбой.If the audit log is filled in this manner, the auditing system fails. Для решения этой проблемы задайте свойству SuppressAuditFailure значение true и используйте свойства средства «Просмотр событий» для управления поведением аудита.To mitigate this, set the SuppressAuditFailure property to true and use the properties of the Event Viewer to control the auditing behavior. Дополнительные сведения см. в статье технической поддержки Майкрософт на просмотр и управление журналами событий с помощью средства просмотра событий в Windows XP, см. в способы просмотра и управления журналами событий в средстве просмотра событий в Windows XP.For more information, see the Microsoft Support article on viewing and managing event logs by using the Event Viewer in Windows XP available at How to view and manage event logs in Event Viewer in Windows XP.
События аудита, записанные в журнал приложения в Windows XPWindows XP, видны всем авторизованным пользователям.Audit events that are written to the Application Log on Windows XPWindows XP are visible to any authenticated user.
Выбор журнала событий приложения или журнала событий безопасностиChoosing Between Application and Security Event Logs
В приведенной ниже таблице приведены сведения, помогающие выбрать журнал для записи событий - журнал событий приложения или журнал событий безопасности.The following tables provide information to help you choose whether to log into the Application or the Security event log.
Операционная системаOperating System
| Windows XP с пакетом обновления 2 (SP2)Windows XP SP2 или более поздняя версия or later | ПоддерживаетсяSupported | Не поддерживаетсяNot supported |
| Windows Server 2003 SP1Windows Server 2003 SP1 и Windows VistaWindows Vista. and Windows VistaWindows Vista | ПоддерживаетсяSupported | Контекст потока должен обладать привилегиями SeAuditPrivilegeThread context must possess SeAuditPrivilege |
Прочие факторыOther Factors
В дополнение к операционной системе, в следующей таблице описываются другие параметры, влияющие на разрешение регистрации.In addition to the operating system, the following table describes other settings that control the enablement of logging.
| Управление политикой аудитаAudit policy management | Неприменимо.Not applicable. | Помимо конфигурации, журнал безопасности управляется также политикой администратора локальной безопасности (LSA).Along with configuration, the Security log is also controlled by the local security authority (LSA) policy. Необходимо также разрешить категорию "Аудит доступа к объектам".The "Audit object access" category must also be enabled. |
| Взаимодействие с пользователем по умолчаниюDefault user experience | Все авторизованные пользователи могут производить запись в журнал приложения, поэтому для процессов приложения никакие дополнительные шаги, связанные с разрешениями, не требуются.All authenticated users can write to the Application log, so no additional permission step is needed for application processes. | Процесс приложения (контекст) должен иметь привилегии SeAuditPrivilege.The application process (context) must have SeAuditPrivilege. |
См. такжеSee Also
ServiceSecurityAuditBehaviorAuditLogLocationОбщие сведения о безопасностиSecurity OverviewБазовое программирование для WCFBasic WCF ProgrammingПрактическое руководство. Аудит событий безопасностиHow to: Audit Security Events<serviceSecurityAudit ><serviceSecurityAudit><поведения ><behaviors>Модель безопасности для Windows Server App FabricSecurity Model for Windows Server App Fabric
docs.microsoft.com
4. Регистрация и учет событий в системе (аудит)
Требования к регистрации и учету событий ранжируются в зависимости от предоставляемых возможностей отбора подлежащих регистрации событий, мощ- ности средств анализа журнала событий и степени мониторинга действий пользо- вателя. Требования к аудиту подразделяются на четыре группы:
защита и управление доступом к системного журналу событий;
определение множества подлежащих регистрации событий;
фиксация и хранение зарегистрированных событий в журнале;
анализ журнала событий и формирование отчетов.
Уровень AD-1 включает минимальные требования к аудиту, которым должны следовать все системы в той мере, в какой они реализуют соответствую- щие функции защиты. На уровне AD-2 эти требования усиливаются как за счет расширения множества типов регистрируемых событий, так и за счет добавления новых функций по управлению процессом регистрации и учета. На уровне AD-3 появляются требования к наличию доверенных средств аудита, предоставляющих возможности выборочного анализа определенных типов событий, упрощающих взаимодействие с оператором за счет использования графического представления данных и т.п. Уровень AD-4 характеризуется введением требования выявления критичных с точки зрения безопасности событий и объявления тревоги в случае их обнаружения. На уровне AD-5 требуется обеспечить такой же контроль в ре- жиме реального времени (осуществлять в режиме реального времени обнаружение попыток нарушений безопасности).
Уровень AD-1. Минимальный аудит.
ТСВ должна обеспечивать возможность создания, хранения, ведения журнала аудита, содержащего регистрацию обращений к защищенным объектам. ТСВ должна обеспечивать защиту журнала от несанкционированного доступа, изменения или уничтожения. ТСВ должна предоставлять доступ к журналу только авторизованным пользователям.
ТСВ должна обеспечивать регистрацию в журнале аудита следующих типов событий:
использование средств идентификации и аутентификации;
создание и удаление объектов;
доступ к объектам, помещение объектов в доступную пользователю об- ласть, запуск программ;
действия, предпринятые операторами и администраторами, ответствен- ными за безопасность.
Требования Федеральных критериев
Для поддержки в системе политики обеспечения работоспособности и кон- троля за распределением ресурсов должны регистрироваться попытки несанкцио- нированных запросов на выделение ресурсов и попытки получения доступа к ре- сурсам, предоставленным другим субъектам.
При поддержки в системе нормативного управления доступом ТСВ должна иметь возможность осуществлять регистрацию и учет изменений меток, класси- фицирующих уровень информации. Если нормативное управление доступом при- меняется для контроля потоков информации между субъектами, ТСВ должна иметь возможность регистрировать в журнале аудита события, которые потенци- ально могут использоваться для организации скрытых каналов передачи инфор- мации.
3. Для каждого регистрируемого события в журнал аудита заносятся:
дата, время и тип события;
идентификатор пользователя, инициировавшего событие;
результат выполнения действия, соответствующего событию (успешное завершение или отказ).
При запросах на доступ к объектам или их удалении должны также регист- рироваться имя и атрибуты объекта.
4. Администратор должен иметь возможность выбора регистрируемых со- бытий и действий для каждого пользователя или объекта на основании соответст- вующих атрибутов политики безопасности.
Уровень AD-2. Базовые требования к аудиту.
Без изменений.
Изменение. ТСВ должна иметь возможность регистрировать следующие типы событий:
использование механизмов идентификации, аутентификации и регистра- ции пользователя в системе;
события, связанные с управлением доступом, относящиеся к определен- ному пользователю, субъекту, объекту или их атрибутам политики безопасности;
создание, удаление субъектов и объектов, осуществление доступа, пере- дача и отзыв прав доступа, изменение атрибутов политики безопасности, назначе- ние и отзыв привилегий;
- действия, выполняемые операторами и администраторами, ответствен- ными за безопасность, привилегированные операции, такие как модификация эле- ментов ТСВ, настройка ТСВ, изменение параметров ТСВ и системных привиле- гий, изменение атрибутов пользователей, изменение состава и типов регистрируе- мых в журнале аудита событий.
Должен быть определен минимальный неизменяемый состав регистрируе- мых событий и их параметров. ТСВ должна содержать средства защиты и управ- ления множеством регистрируемых событий и их параметров и предоставлять доступ к ним только администратору.
Без изменений.
Дополнение. В ТСВ должны присутствовать защищенные средства за- пуска и остановки процесса аудита. Доступ к этим средствам, равно как и к сред- ствам просмотра журнала аудита, должен быть разрешен только администратору.
Приложение 1
ТСВ также должна включать средства управления аудитом, доступные только для администратора, которые позволяют осуществлять:
создание и удаление журнала аудита, контроль и изменение его размеров;
форматирование и упаковка записей журнала аудита;
обеспечение целостности журнала аудита при сбоях и отказах системы.
Уровень AD-3. Развитые средства аудита.
Без изменений.
Без изменений.
Без изменений.
Дополнение. В ТСВ должны присутствовать специально разработанные средства контроля целостности журнала аудита, а также средства контроля цело- стности заданного множества регистрируемых событий.
Средства просмотра журнала аудита должны предоставлять авторизо- ванному пользователю возможность ознакомления с данными аудита и их провер- ки. Данные средства должны быть защищены от несанкционированного доступа.
ТСВ также должна иметь средства обработки журнала аудита, позволяю- щие осуществлять выборочный анализ:
действий одного или нескольких пользователей;
действий над одним или несколькими объектами или ресурсами;
всех или подмножества исключительных ситуаций;
Средства просмотра журнала аудита должны предусматривать возмож- ность работы параллельно со штатным функционированием системы.
Уровень AD-4. Обнаружение попыток нарушения безопасности.
Без изменений.
Дополнение. ТСВ должна содержать средства мониторинга событий, возникновение которых может означать угрозу нарушения безопасности. Эти средства должны незамедлительно оповещать администратора системы и останав- ливать (прекращать) выполнение вызвавшего это событие процесса или всей сис- темы.
Без изменений.
Без изменений.
Без изменений.
Уровень AD-5. Выявление попыток нарушения безопасности в режиме ре- ального времени.
Без изменений.
Без изменений.
Без изменений.
Без изменений.
Дополнение. ТСВ должна обеспечивать возможность регистрации собы- тий и выявления попыток нарушения безопасности в режиме реального времени и оповещать о них администратора. Эта возможность должна реализовываться спе- циальным механизмом мониторинга событий, критичных с точки зрения политики безопасности.
Требования Федеральных критериев
5. Политика управления доступом (произвольное и норматив- ное управление доступом)
Требования к реализации политики произвольного управления доступом могут быть ранжированы в зависимости от базы применения политики (ко всем субъектам и объектам системы, к выбранным подмножествам субъектов и объек- тов, в зависимости от атрибутов безопасности субъектов и объектов) и предостав- ляемых средств управления доступом (возможность управлять распространением прав доступа, возможность организации контроля доступа к объектам пользовате- лей только с их разрешения). Кроме того, эти требования можно ранжировать в зависимости от уровня абстракции, на котором рассматриваются субъекты (поль- зователь, группа, роль) и объекты (область памяти, файл, запись в файле).
Для ранжирования требований нормативного управления доступом могут использоваться те же самые критерии, однако описание уровня рассмотрения субъектов и объектов в этом случае должно производится более точно. Поскольку нормативное управление доступом основано на контроле информационных пото- ков, должны контролироваться соответствующие атрибуты субъектов (например, состояние процесса) и объектов (размер, режим доступа и т. д.).
Требования к управлению доступом ранжированы по четырем уровням. На уровне АС-1 устанавливаются минимальные требования к реализации политики управления доступом и допускается осуществление управлением доступа только по отношению к некоторому подмножеству субъектов и объектов, а также ограни- ченные возможности управления атрибутами безопасности. На уровне АС-2 тре- бования к политике безопасности расширяются в сторону возможности одновре- менного применения нескольких политик управления доступом и средств управ- ления экспортом и импортом объектов. На уровне АС-3 управление доступом должно поддерживаться для всех субъектов и объектов. Если реализована полити- ка нормативного управления доступом, она должна использовать все атрибуты безопасности объектов и субъектов. На данном уровне также требуется проводить назначение прав доступа к объектам на основании их типа. На следующем уровне АС-4 управление доступом расширяется путем добавления атрибутов времени и местоположения. Появляется возможность задания прав пользователей в зависи- мости от их принадлежности к определенной группе или выполнения ими опреде- ленной роли. В дополнение к требованиям контроля создания и уничтожения объ- ектов вводится контроль за ресурсами и наследованием атрибутов. Предполагает- ся, что этот уровень будет использоваться в системах, где требуется точно опреде- ленное управление доступом.
Уровень АС-1. Минимальное управление доступом.
Задание множества атрибутов безопасности объектов и субъектов. ТСВ должна задавать и поддерживать атрибуты безопасности субъектов и объектов. Атрибуты субъекта должны включать индивидуальный и групповой идентифика- торы пользователя, представленного этим субъектом. Атрибуты объекта должны включать набор возможных прав доступа к этому объекту (чтение, запись, выпол- нение).
Управление атрибутами безопасности объектов и субъектов. ТСВ долж- на определять правила назначения и изменения атрибутов безопасности субъектов
Приложение 1
и объектов и обеспечивать их безусловное выполнение. Эти правила должны быть основаны на следующих положениях:
субъект может разрешать доступ к объекту для другого субъекта, только в том случае, если он сам обладает этим правом доступа;
пользователи должен иметь возможность устанавливать режим совмест- ного использования объектов и управлять им основе индивидуальных и групповых атрибутов субъектов;
пользователи должны обладать средствами для контроля за процессом распространения и передачи прав доступа и иметь возможность ограничивать его.
Если для разных подмножеств субъектов и объектов определены различ- ные правила управления атрибутами безопасности, то их реализация должна быть согласованной и не противоречить политике безопасности.
3. Управление доступом субъектов к объектам. ТСВ должна определять правила назначения полномочий (авторизацию) с целью управления доступом субъектов к объектам и обеспечивать их соблюдение. Эти правила должны быть основаны на атрибутах субъектов и объектов и обеспечивать защиту объектов от несанкционированного доступа.
Правила назначения полномочий должны охватывать четко определенное подмножество субъектов и объектов, а также принадлежащих им атрибутов безо- пасности. Должна быть обеспечена возможность применения различных правил назначения полномочий для различных групп субъектов и объектов, в этом случае реализация этих правил должна быть согласованной и не противоречить политике безопасности
Контроль за созданием и уничтожением объектов и субъектов. ТСВ должна контролировать создание и уничтожение субъектов и объектов, а также повторное использование объектов. Все полномочия на доступ к объекту, должны быть отозваны перед его уничтожением и предоставлением занимаемых им ресур- сов в распоряжение системы. Вся содержащаяся в нем информация, в том числе и зашифрованная, должна быть уничтожена.
Инкапсуляция объектов. Если в ТСВ поддерживается механизм инкап- суляции объектов, он должен обеспечивать:
- авторизацию доступа к инкапсулированным объектам;
- возможность создания пользователем инкапсулированных объектов и подсистем;
- средства доступа к инкапсулированным объектам.
Уровень АС-2. Базовые механизмы управления доступом.
Дополнение. Если одновременно поддерживается несколько политик управления доступом, атрибуты безопасности субъектов и объектов для каждой политики должны быть определены отдельно. Атрибуты субъектов и объектов должны точно отражать уровень их конфиденциальности и целостности.
Дополнение. Правила управления атрибутами безопасности субъектов и объектов должны регламентировать назначение атрибутов в ходе импорта и экс- порта объектов. В том числе управлять импортом в систему неклассифицирован- ной информации, не имеющей атрибутов безопасности, и экспортом из системы информации, обладающей атрибутами безопасности.
Требования Федеральных критериев
Дополнение. Если одновременно поддерживается несколько политик управления доступом, правила назначения полномочий доступа должны быть оп- ределены отдельно для каждой политики. ТСВ должна обеспечивать корректность совместного применения политик безопасности, в том числе, совместное приме- нение правил авторизации каждой политики.
Без изменений.
Без изменений.
Уровень АС-3. Расширенное управление доступом.
1. Дополнение. ТСВ должна незамедлительно сообщать пользователю о любых изменениях атрибутов ассоциированных с ним субъектов, повлекших за собой изменение уровня привилегированности пользователя. Пользователю долж- на быть предоставлена возможность запросить у ТСВ текущие значения атрибутов безопасности ассоциированных с ним субъектов.
ТСВ должна поддерживать назначение атрибутов безопасности всем под- ключенным к системе физическим устройствам (например, максимальные и ми- нимальные уровни конфиденциальности). Эти атрибуты должны использоваться ТСВ для отражения особенностей функционирования данных устройств, обуслов- ленных их физическими параметрами.
Без изменений.
Изменение. Правила назначения полномочий доступа должны быть оп- ределены для всех субъектов и объектов, которые прямо или косвенно доступны субъектам.
Если применяется нормативное управление доступом, то правила назначе- ния полномочий доступа должны учитывать все атрибуты субъектов и объектов.
Без изменений.
Без изменений.
Уровень АС-4. Точно определенная политика управления доступом.
Дополнение. В состав атрибутов безопасности субъектов должны вхо- дить показатели времени и местоположения, позволяющие дополнительно аутен- тифицировать ассоциированного с данным субъектом пользователя.
Дополнение. Правила управления атрибутами безопасности субъектов и объектов должны обеспечивать задание для каждого объекта списка индивидуаль- ных субъектов и групп субъектов с указанием их прав доступа к данному объекту. Кроме того, правила управления атрибутами безопасности субъектов и объектов должны обеспечивать задание для каждого объекта списка индивидуальных субъ- ектов и групп субъектов, не имеющих прав доступа к данному объекту.
Эти правила также должны обеспечивать возможность управления атрибу- тами в зависимости от времени и места — предоставление или отзыв прав доступа могут быть осуществлены в определенный момент времени и продлиться задан- ный период, а также зависеть от местоположения объектов и субъектов.
Дополнение. Правила назначения полномочий доступа должны включать возможность использования атрибутов времени и места осуществления доступа.
Изменение. ТСВ должна определять и поддерживать правила контроля за созданием и уничтожением субъектов и объектов, позволяющие указать для каждого субъекта и объекта:
Приложение 1
полномочия, требуемые для их созданию и уничтожения; -
процедуру повторного использования объекта;
ресурсы, требуемые для их создания и размещения;
устанавливаемые по умолчанию значения атрибутов созданных субъектов и объектов, и, если требуется, правила наследования атрибутов.
Правила создания и уничтожения субъектов и объектов должны опреде- ляться на основании их типов. Если для различных типов субъектов и объектов определены разные правила их создания и уничтожения, то должно быть показа- но, что их совокупность реализует политику безопасности, принятую в системе. Если одновременно используется несколько политик безопасности, правила соз- дания и уничтожения субъектов и объектов должны быть определены для каждой политики.
Без изменений.
Контроль скрытых каналов
Для осуществления контроля за скрытыми каналами требуется присутствие в ТСВ программных, аппаратных и специальных средств, позволяющих обнару- живать скрытые каналы и ограничивать возможности их использования путем их полной ликвидации или минимизации пропускной способности. Ранжирование данной группы требований проводится на основе типов контролируемых скрытых каналов и предоставляемых возможностей контроля (аудит, минимизация пропу- скной способности, ликвидация).
Скрытые каналы в зависимости от способа кодирования информации под- разделяются на два типа: с использованием памяти и с использованием времени. В первом случае для кодирования передаваемой информации используется либо область памяти (например, установление характерных признаков в имени и атри- бутах файла или зарезервированные поля в заголовке сетевого пакета). Во втором случае, информация кодируется определенной последовательностью и длительно- стью событий, происходящих в системе (например, с помощью модуляции интер- валов обращения к устройствам, введения задержек между приемом и посылкой сетевых пакетов и т.д.).
Уровень ССН-1 затрагивает только скрытые каналы, использующие па- мять и ограничивается контролем их использования. На уровне ССН-2 добавля- ются требования минимизации пропускной способности и исключения возможно- стей использования скрытых каналов для штатного режима эксплуатации систе- мы. Уровень ССН-3 требует полного подавления всех типов скрытых каналов.
Уровень ССН-1. Контроль скрытых каналов, использующих память.
ТСВ и привилегированные приложения должны содержать функции контроля использования скрытых каналов, использующих память. Эти функции должны позволять идентифицировать источник и приемник скрытого обмена ин- формацией и способ использования скрытого канала.
Функции ТСВ и привилегированных приложений, осуществляющие кон- троль скрытых каналов должны быть определены для каждого скрытого канала и присутствовать в типовой конфигурации системы. Если для некоторых скрытых каналов функции контроля отсутствуют, должно быть проведено доказательство
Требования Федеральных критериев
невозможности их использования для нарушения безопасности.
Уровень ССН-2. Контроль и ограничение пропускной способности скры- тых каналов, использующих память.
Дополнение. Должно обеспечиваться ограничение пропускной способно- сти или полное подавление скрытых каналов, использующих память. Пропускная способность каждого скрытого канала должна контролироваться администрато- ром.
Дополнение. Функции ТСВ и привилегированных положений, обеспечи- вающие ограничение пропускной способности или полное подавление скрытых каналов, должны присутствовать в типовой конфигурации системы. Если для не- которых скрытых каналов функции ограничения пропускной способности или полного подавления отсутствуют, должно быть проведено доказательство невоз- можности их использования для нарушения безопасности.
Уровень ССН-3. Контроль и ограничение пропускной способности скры- тых каналов, использующих время.
Без изменений.
Дополнение. Функции контроля, ограничения пропускной способности и подавления скрытых каналов должны в полной мере распространяться и на скры- тые каналы, использующие время.,
7. Контроль за распределением ресурсов
Данные требования являются частью политики обеспечения работоспособ- ности системы и позволяют контролировать использование ресурсов системы. Ранжирование проводится по отношению к множеству управляемых ресурсов (т.е. подмножества ресурсов с ограниченным распределением) и функциональным воз- можностям средств управления.
Уровень AR-1 определяет базовые требования к контролю за предоставле- нием ресурсов в терминах ограниченного подмножества системных ресурсов, субъектов и объектов. Уровень AR-2 расширяет область применения средств кон- троля за предоставлением ресурсов до множества всех системных ресурсов с од- новременным введением контроля за попытками монопольного захвата ресурсов и их доступностью для всех субъектов. На уровне AR-3 к этим требованиям добав- ляется управление распределением ресурсов на основании приоритета субъекта и введение фиксированных квантов, которыми распределяются ресурсы.
Уровень AR-1. Ограничение при распределении ресурсов.
ТСВ должна обеспечивать возможность ограничения множества субъектов и объектов, доступных пользователю одновременно. ТСВ должна контролировать распределение определенного подмножества системных ресурсов таким образом, чтобы ни один пользователь не мог нарушить работу другого пользователя путем захвата такого количества ресурсов системы, при котором другие пользователи не могут осуществлять доступ к объектам и субъектам. Для всех субъектов, объектов и ресурсов должны быть определены ограничения на время и количество исполь- зования, а для ресурсов — атрибуты, обозначающие их количество.
Приложение 1
Уровень AR-2. Полный контроль за распределением ресурсов.
Дополнение. ТСВ должна контролировать распределение системных ресур- сов таким образом, чтобы ни один пользователь не мог сделать любой системный ресурс недоступным для других пользователей, или ограничить возможности ТСВ по обслуживанию других пользователей, путем захвата ресурсов или осуществле- ния манипуляций с ТСВ.
Уровень AR-3. Распределение ресурсов на основании приоритетов.
Дополнение. ТСВ должна обеспечивать возможность распределения ресур- сов на основании специально выделенных атрибутов, поставленных в соответст- вие каждому субъекту. ТСВ должна осуществлять распределение ресурсов в пер- вую очередь субъектам, обладающим более высоким приоритетом. Все ресурсы должны выделяться блоками определенного размера (квантами).
studfiles.net
подробная инструкция и шпаргалка (.pdf) / Блог компании Netwrix / Хабр
Всем привет!Продолжаем публиковать шпаргалки по настройке аудита различных систем, в прошлый раз мы говорили об AD habrahabr.ru/company/netwrix/blog/140569, сегодня обсудим файловые серверы. Надо сказать, что чаще всего мы выполняем именно настройки аудита файловых серверов – в ходе пилотных инсталляций у заказчиков. Ничего сложного в этой задаче нет, всего лишь три простых шага:
- Настроить аудит на файловых ресурсах (file shares)
- Настроить и применить общую и детальную политики аудита
- Изменить настройки журналов событий
Настройка аудита на файловых ресурсах
- Откройте свойства шары, выберите вкладку «Security» и нажмите кнопку «Advanced»
- На вкладке «Auditing», выберите группу пользователей «Everyone» и нажмите кнопку «Edit»
- Включите следующие флажки в колонках «Successfull» и «Failed»:
List Folder / Read Data; Create Files / Write Data; Create Folders / Append Data; Write Attributes; Write Extended Attributes; Delete Subfolders and File; Delete; Change Permissions; Take Ownership.
- Убедитесь, что в списке «Apply onto» выбрано значение «This folder, subfolders and files», а нижний флажок «Apply these auditing entries to objects and/or containers within this container only» не установлен.
- Нажмите «ОК», на этом настройка одной файловой шары завершена.
Настройка общей политики аудита
Для того, чтобы контролировать изменения на файловом сервере, вам необходимо настроить политику аудита. Перед настройкой политики убедитесь, что ваша учетная запись входит в группу Администраторов или у вас есть права на управление аудитом и журналами событий в оснастке Групповых политик.
- Откройте оснастку Групповые политики с помощью команды gpedit.msc или через меню Start > Programs > Administrative Tools > Group Policy Management.
- Раскройте узел «Domains», щелкните правой кнопкой мыши по имени вашего домена и выберите пункт меню «Create a GPO in this domain and Link it here».
- Впишите название новой политики в поле «Name» и нажмите ОК.
- Щелкните правой кнопкой мыши по новой политике, в меню выберите пункт «Edit», откроется редактор групповых политик.
- Раскройте узел «Computer Configuration», затем раскройте «Policies» > «Windows Settings» > «Security Settings» > «Local Policies» > «Audit Policy».
- В правой части окна два раза щелкните левой кнопкой мыши по категории «Audit object access».
- Включите все флажки так, как показано на скриншоте, нажмите ОК.
или
Настройка детальной политики аудита
- На контролируемом файловом сервере откройте оснастку Локальные политики безопасности с помощью команды secpol.msc
- Раскройте узел «Security Settings» > «Local Policies» > «Security Options» и найдите в правой части окна категорию «Audit: Force audit policy subcategory settings (Windows Vista or later) policy»
- Два раза щелкните левой кнопкой мыши по этой категории и установите значение Enabled, нажмите ОК.
- Теперь раскройте узел «Security Settings» > «Advanced Audit Policy Configuration» > «System Audit Policies» > «Object Access» и настройте категории «Audit File System» и «Audit Handle Manipulation», выберите для каждой из них события, которые вам необходимы (Success или Failure).
- Теперь осталось применить политику с помощью командной строки, набрав gpupdate /force
- Проверить, применилась ли политика можно с помощью команды auditpol /get /category:«ObjectAccess»
Настройка журналов событий
Для того, чтобы эффективно контролировать изменения, необходимо выполнить настройку журналов событий, а именно — установить максимальный размер журналов. Если размер окажется недостаточным, то события могут перезаписываться перед тем, как попадут в базу данных, которую использует ваше приложение, контролирующее изменения.
- Откройте просмотр событий: «Start» > «Programs» > «Administrative Tools» > «Event Viewer»
- Разверните узел «Windows Logs»
- Правой клавишей мыши щелкните по журналу «Security», выберите пункт меню «Properties»
- Убедитесь, что флажок «Enable logging» включен.
- Установите значения в поле «Maximum log size»: для Windows 2003 – 300MB, для Windows 2008 – 1GB.
- Установите метод очистки журнала. Вы можете использовать методы «Overwrite events as needed» или «Archive the log when full»
Напоследок, хотели бы предложить вам скрипт, который мы сами используем при настройке аудита на файловых серверах. Скрипт выполняет настройку аудита на всех шарах у каждого из компьютеров в заданном OU. Таким образом, не требуется включать настройки на каждом файловом ресурсе вручную.
Перед запуском скрипта нужно отредактировать строчку 19 — вписать вместо «your_ou_name» и «your_domain» необходимые значения. Скрипт необходимо выполнять от имени учетной записи, имеющей права администратора домена.
Получить скрипт можно в нашей базе знаний или сохранить в файл .ps1 следующий текст:
#import-module activedirectory #$path = $args[0]; # \\fileserver\share\folder $account = "Everyone" # $args[1]; $flavor = "Success,Failure" #$args[2]; $flags = " ReadData, WriteData, AppendData, WriteExtendedAttributes, DeleteSubdirectoriesAndFiles, WriteAttributes, Delete, ChangePermissions, TakeOwnership " $inheritance = "ContainerInherit, ObjectInherit" $propagation = "None" $comps = Get-ADComputer -Filter * -SearchBase "OU=your_ou_name,DC=your_domain,DC=your_domain" | select -exp DNSHostName foreach ($comp in $comps) { $shares = get-wmiobject -class win32_share -computername $comp -filter "type=0 AND name like '%[^$]'" | select -exp name foreach ($share in $shares) { $path = "\\"+$comp+"\"+$share $path $acl = (Get-Item $path).GetAccessControl("Access,Audit") $ace = new-object System.Security.AccessControl.FileSystemAuditRule($account, $flags, $inheritance, $propagation, $flavor) $acl.AddAuditRule($ace) set-acl -path $path -AclObject $acl } }Скачать шпаргалку(.pdf) по настройке аудита файловых серверов
____________ P.S. Настраивать и проводить аудит файловых серверов можно вручную, используя данный алгоритм, или с помощью Netwrix Auditor. Пробная версия ПО доступна здесь, онлайн тест-драйв — здесь
habr.com
цели, недостатки штатной системы аудита и пути их преодоления / Блог компании Netwrix / Хабр
Дорогие хабровчане, Предлагаем вашему вниманию переведенный на русский язык фрагмент книги Дон Джонса, MVP, титулованного специалиста и просто очень популярного в США автора.Существует три “А” безопасности Active Directory (AD) – аутентификация, авторизация, аудит. В этом посте мы приведем фрагмент перевода из книги Don Jones “Active Directory Troubleshooting, Auditing, and Best Practices”, посвященный аудиту AD.
Цели штатных инструментов аудита
Цель аудита довольно тривиальна: отслеживать все, что кто-либо делает. В контексте AD это означает, что нужно отслеживать использования всех привилегий, таких как изменения членства в группах или разблокировка учетных записей пользователей. Также это означает, что необходимо фиксировать действия пользователей, такие как успешные и неудачные входы в систему. Посмотрим шире – и для Windows это означает, что аудит включает еще и доступ к файлам и папкам, равно как и изменения разрешений доступа к файлам. Ваша цель при осуществлении аудита может отличаться от тех, которые достигаются в рамках архитектуры аудита операционной системы. Помните, что система аудита, используемая в Windows – включая AD, которая представляет собой копию архитектуры файловой системы, пришла к нам из ранних 90-х, когда появилась Windows NT. В то же время, в Microsoft тогда не могли предположить, что будут существовать организации с тысячами файловых серверов, сотнями контроллеров доменов и тысячами других серверов, на которых работают Exchange, SQL Server, SharePoint и другие бизнес-платформы. Мы будем рассматривать ниже то, что штатные инструменты аудита Windows не всегда масштабируемы в крупных инфраструктурах или даже для компаний среднего размера. Может быть, Вы хотели бы, чтобы каждое событие в ИТ-инфраструктуре фиксировалось системой аудита, однако это может создать проблемы в производительности, управлении и даже логистике. Поэтому давайте предположим, что Ваша цель – аудит всего, что происходит в ИТ-инфраструктуре, и посмотрим, чего можно добиться штатными средствами.Штатная система аудита
Разрешения применяются к списку разграничительного контроля доступа (DACL). Каждый DACL состоит из одного или более элементов управления доступом (ACE). Каждый такой элемент содержит разрешение или запрет определенного набора разрешений по отношению к пользователю или группе. DACL представляет собой часть “авторизации” в модели трех А: AD аутентифицирует вас и дает маркер безопасности (security token), содержащий уникальный идентификатор безопасности (SID). Такой SID сравнивается с ACE в списке разграничительного контроля доступа (DACL), чтобы определить, какими разрешениями Вы обладаете при доступе к данным ресурсам. Аудит работает схожим образом. Список управления доступом к объектам (SACL) состоит из одной или нескольких записей. Каждая запись обозначает определенное действие для определенной активности, совершенной пользователем или группой. SACL привязан к определенному ресурсу, такому как файл или объект директории, и когда осуществляется определенное действие с ресурсом, оно фиксируется в журнале. По умолчанию, существует возможность записывать в журнал действия типа “успех” и/или “отказ”. Это значит, что Вы можете выбрать, чтобы в журнале фиксировалась запись, когда кто-то успешно использовал свои разрешения или когда он пытался это сделать и ему было в этом отказано. На рисунке 1 показана конфигурация SACL для AD. Как Вы можете видеть, этот ресурс – Контроллеры доменов подразделения – настроен так, что фиксируются некоторые виды успешных действий членов группы “Everyone”. То есть, когда кто-нибудь успешно осуществляет эти действия, создается запись в журнале.Рис.1: SACL в AD.
Какие действия подлежат аудиту зависит от того, с какими ресурсами Вы работаете. Например, рисунок 2 показывает SACL файловой системы, и Вы можете видеть, что доступны различные виды действий.
Рис.2: SACL файловой системы.
Здесь Вы можете выбрать, что подлежит аудиту, например, создание папок, чтение атрибутов, удаление файлов и тому подобное. Таким образом, каждый ресурс, может иметь свой собственный SACL. На практике, большинство из нас назначает SACL на достаточно высоком уровне иерархии и тем самым позволяет этим настройкам распространиться на объекты более низкого уровня через наследование. Поэтому управление SACL осуществляется в относительно небольшом количестве мест. Но мы все равно должны конфигурировать их хотя бы по одному на каждый сервер и на главную систему. Что это значит: каждому серверу нужен будет свой список управления доступа к объектам хотя бы в корне каждого логического диска, нам нужен будет отдельный список в корне AD и так и далее. Другие продукты могут подпадать под эту схему. А могут и не подпадать. Например, Exchange Server используется подобную структуру для аудита, а вот SQL Server и SharePoint – нет. Однако здесь мы рассматриваем исключительно AD. Когда действие, на которое настроен аудит, происходит, Windows генерирует запись аудита. Все подобные записи хранятся в журнале событий безопасности, который показан на рисунке 3. Проблема с подобным журналом заключается в том, что туда попадает каждое событие. Хотя это вроде бы и неплохо, чтобы все события хранились в одном месте, проблема заключается в том, что когда из него необходимо извлечь отдельные записи, то это становиться проблематичным. Еще раз, это происходит вследствие того, что у Microsoft довольно узкий взгляд на систему аудита Active Directory.
Рис. 3: Журнал событий безопасности.
На каждом Windows сервере находятся свои журналы событий безопасности (security event logs), включая контроллеры доменов. Хотя списки управления доступа к объектам в AD могут быть настроены на любом контроллере домена и в дальнейшем реплицированы на остальные, только контроллер домен, который обрабатывает данное действие, создаст о нем запись в журнале. В результате: есть централизованно сконфигурированная политика аудита, однако журналы аудита сильно рассредоточены. На рисунке 4. показано, как эти записи аудита выглядят. Они часто включают “сырые” идентификаторы безопасности и другую неочевидную информацию. В этом примере показаны успешные подключения доменов, обработанные с помощью штатного протокола Kerberos. Имя пользователя и домена пустые в этом примере, однако обычно они заполнены.
Рис.4: Пример записи аудита.
Со временем в Microsoft стали решать проблемы, связанные с наличием лишь одного журнала, в котором находится так много информации. В Windows Vista и Windows Server 2008 были представлена параллельная архитектура журнала событий, которая делала проще процесс ведения собственного журнала для каждого продукта или технологии. Это всегда было возможно – журналы приложений, системы и безопасности дополнялись, например, журналами службы каталогов. Но эта новая архитектура стала более целостной по ряду причин. На рисунке 5 показаны старые и новые журналы.
Рис.5: Новые и старые журналы.
В отличие от списка разграничительного контроля доступа (DACL) список управления доступа к объектам (SACL) не сразу же используется операционной системой. SACL просто обозначает, какие действия подлежат аудиту; система аудита сама по себе также должна быть включена для того, чтобы события записывались в журналы. На рисунке 6 показано, где это обычно конфигурируется в объекте групповых политик. Большинство организаций будет конфигурировать аудит в высокоуровневых объектах групповых политик, таких, которые применяются ко всем контроллерам доменов или даже ко всем серверам в домене. Обозначенный объект групповых политик относится к настройке политики аудита, которая включает в себя включение аудита для события входа в систему/подключений, действия по управлению учетными записями, доступ к AD и так и далее. Политика аудита, так же как и ресурсов SACL, должна быть настроена для того, чтобы генерировались желаемые события аудита.
Рис. 6: Настройка аудита в объекте групповых политик.
Здесь нужно быть внимательным. Не думаю, что Вы хотите включить аудит всех событий, не приняв во внимание последствия. Контроллер домена может генерировать тысячи событий о подключениях каждую минуту (например, когда утром все заходят на свои компьютеры), а создание такого количества событий требует вычислительной мощности. Если аудит всех этих событий действительно нужен, то Вам нужно будет увеличить размер контроллера домена, чтобы справиться с нагрузкой. То же самое нужно сделать и для файловых серверов: если в журнал будут заноситься все события об успешном доступе к файлам, нужно увеличить вычислительную мощность, чтобы справиться с нагрузкой. Создание такого количества событий может довольно серьезно “забить” журнал событий. Как показано на рисунке 7, Вы наверняка захотите совместить политику аудита с хорошо спланированной политикой журнала событий, настройкой размеров журналов событий, действиям по откату и другими настройками, чтобы обеспечить согласованность нагрузки на работу системы.
Рис.7: Конфигурирование журнала событий в объекте групповых политик.
В отличие от журнала приложений, с которым Вы можете быть спокойны, когда он перезаписывается по мере заполнения, в журнале безопасности такого допустить нельзя, так как важная информация может быть потеряна. Поэтому Вы должны задать подходящий размер журнала и настроить процедуры регулярного архивирования и очищения журнала – в зависимости от нагрузки на журнал. За что обычно критикуют штатные журналы событий Windows, так это за то, что они сильно рассредоточены. Например, администратор может изменить членство в группах на одном контроллере домена, подключиться ко второму контроллеру домена, чтобы использовать учетную запись в этой группе, и подключить к третьему контроллеру, чтобы сбросить это членство в группах. Все три события будут записаны в трех различных журналах событий безопасности, что усложняет процесс установления взаимосвязи между этими событиями. Решение, которое Microsoft предложил этой проблеме в Windows Server 2008, стала переадресация журнала событий (event log forwarding). На рисунке 8 обозначено, как отдельные серверы пересылают события на центральный сервер, который собирает все события в свой собственный журнал.
Рис. 8: Переадресация журнала событий.
Как обозначено, эта функция может быть сконфигурирована в групповых политиках, что делает ее централизованно контролируемой. Этот подход все равно имеет существенные недостатки, которые мы будем обсуждать далее. Вот таким образом построена штатная система аудита. Давайте теперь поговорим о том, как организации хотят использовать эту систему, и где им необходимы усовершенствованные функции.
Общие цели бизнеса для аудита изменений
В отличие от 90-х, когда была разработана Windows NT, большинство компаний сегодня являются объектами определенных политик безопасности. Во многих случаях, когда политика безопасности подразумевает еще и выполнение требований нормативов и законодательных актов. Эти требования могут включать обязанность осуществлять аудит всех успешных и неудачных действий, происходящий в ИТ-инфраструктуре, и генерируют значительное количество трафика. Также важно, чтобы те пользователи (включая администраторов), действия которые фиксируются в записях аудита, не могли удалить записи из журнала событий. Организации также хотят, чтобы присутствовала возможность поиска, фильтрации и формирования отчетов по записям в журнале событий. Например, аудитор захотел увидеть запись аудита, которая соответствует изменению конфигурации политики аудита AD, а затем соотнести эти события с одобренными действиями. Что позволяет ему видеть, что в AD только те изменения, которые были согласованы и документированы. Организациям также надо использовать штатные инструменты аудита для разрешения проблем. Когда что-то пошло не так в IT-инфраструктуре, ответ на вопрос: “А что изменилось?” позволяет быстро решить проблему – и журналы аудита должны помогать в поиске ответа на этот вопрос быстро и эффективно. Так в чем же проявляются недостатки штатных инструментов аудита?
Недостатки штатных инструментов аудита
К сожалению, штатная система аудита не слишком хорошо себя зарекомендовала. В конечном счете, это не вина Microsoft – в конце концов, их работа не состоит в том, чтобы предугадывать любую потребность бизнеса, а скорее предоставлять платформу, на основе которой другие компании могут разрабатывать ПО, которое может удовлетворять специфические потребности бизнеса. Именно это они и сделали. Штатная система аудита представляет собой базовое решение, которое подходит для самых небольших организаций, которые вряд ли могут позволить себе приобрести дополнительные программы. Цель №1 – аудит всех событий – однозначно осуществима с помощью Windows, хотя необходимо принимать во внимание размеры журналов и производительность работы сервера. Штатная архитектура журнала событий не является прозрачной, какой мы хотели бы ее видеть, и запись десятков тысяч событий в час однозначно окажет влияние на работу сервера. Цель №2 – возможность внесения изменений в журнал – узкое место системы. К сожалению, практически невозможно исключить возможность очистки журнала администраторами. Вы можете это сделать, тонко настроив привилегии, создав специальные учетные записи для работы с журналами и так и далее, однако это сложно и для многих организаций непрактично. Предположим, что Вы сделали это. Перед Вами встает цель №3 – централизованное формирование отчетов, оповещений и фильтрация событий. Переадресация журналов событий, даже если она происходит, не осуществляется в режиме реального времени, возможны существенные задержки. Но даже если Вы осуществляете переадресацию журнала событий, то вся информация сваливается в одно место, откуда ее можно вытащить с помощью примитивного Event Viewer. На рисунке 9 показаны возможности фильтрации штатных инструментов, и они, конечно же, примитивны.
Рис.9: Штатные инструменты фильтрации журнала событий.
Как показано на рисунке, Вы можете осуществлять фильтрацию по типам событий или по специальному тексту в описании событий, равно как и по другим критериям. Но возможность установления взаимосвязи между различными связанными событиями отсутствует. Что же касается использования этих событий для решения проблем – что ж, удачи! Это, конечно же, возможно, однако обычно это выглядит так: “посмотрите в журнал, посмотрите, что обозначает идентификатор события, и определите, имеет ли это отношение к настоящей проблеме”. Достаточно сложно, чтобы штатный Event Viewer дал ответ на вопрос “Все изменения в AD за последние 4 часа”. Хотя в журнале будут отображаться события, связанные с этими изменениями – Вы ведь настроили политику аудита, чтобы их фиксировать – журнал событий не предназначен для того, чтобы выполнять задачу управления изменениями или их аудита. Это не аудит изменений в собственном значении этого термина, а аудит того факта, что кто-то сделал изменение. Как показано на рисунке 10, в AD Windows Server 2008 стали фиксироваться значения “до” и “после” каждого изменения, что делает более пригодным для аудита изменений. Однако эта функция не слишком распространена в AD и найти нужные события в большом журнале все равно проблематично.
Рис.10: Улучшенный вид событий в Windows Server 2008.
В большинстве инфраструктур, эффективная политика аудита подразумевает использование решений сторонних разработчиков.
Возможности сторонних решений
Инструменты для аудита сторонних разработчиков имеют ряд преимуществ. Во-первых, они лучше (и быстрее) выполняют сбор информации из различных журналов серверов в централизованном хранилище. Часто такое централизованное хранилище является базой данных SQL сервера, хотя отдельные инструменты могут пересылать события в режиме реального времени во внешний механизм ведения журналов, таких как syslog server, как это показано на рисунке 11.Рис.11: Пересылка событий на syslog server
Суть в том, что события из Windows должны как можно быстрее извлекаться и перемещаться в отдельную систему, где бы они были защищены отличным от журнала событий способом. Базы данных в данном случае довольно популярный выбор, потому что они могут быть защищены и к ним можно обращаться со сложными запросами. Ну и конечно же с их помощью можно формировать отчеты. Поэтому большинство решений для аудита Active Directory собирает события в базу SQL Server, чтобы использовать возможности формирования отчетов через SQL Server Reporting Services. Сторонние решения могут также использовать API, чтобы собирать информацию аудита – в дополнение к (или вместо) штатным журналам событий. Эти API часто дают более детализированную информацию, включая значения “до” и “после”. В некоторых случаях, использование API может даже снизить нагрузку на серверы. Используя централизованное хранение данных, сторонние инструменты могут генерировать оповещения в режиме реального времени, формировать отчеты, архивировать записи о событиях, проводить анализ данных и их сопоставление.
habr.com
1.5 Журналы событий и безопасности Windows. Порядок использования содержания журналов для получения сведений в целях обеспечения безопасности.
Журнал событий англ. Event Log — в Microsoft Windows стандартный способ для приложений и операционной системы записи и централизованного хранения информации о важных программных и аппаратных событиях. Служба журналов событий сохраняет события от различных источников в едином журнале событий, программа просмотра событий позволяет пользователю наблюдать за журналом событий, программный интерфейс (API) позволяет приложениям записывать в журнал информацию и просматривать существующие записи.
Записи журнала событий хранятся в ключе реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Данный ключ содержит подключи, называемые файлами журнала. По умолчанию имеются:
файл журнала приложений — для событий приложений и служб;
файл журнала безопасности — для событий системы аудита;
файл системного журнала — для событий драйверов устройств.
Имеется возможность создавать дополнительные журналы. Для каждого источника событий в журнале создаётся отдельный подключ. События от каждого источника могут включаться в определяемые отдельно для каждого источника категории. События должны принадлежать к одному из пяти предопределённых типов.
| Тип | Описание |
| Информация | События указывают редкие и важные успешные операции. |
| Предупреждение | События указывают проблемы, которые не требуют немедленного вмешательства, но могут привести к ошибкам в будущем. Примером такого рода событий может служить исчерпание ресурсов. |
| Ошибка | События указывают существенные проблемы, обычно приводящие к потере функциональности или данных. Примером может служить невозможность запуска службы при загрузке. |
| Успешный аудит | События безопасности, которые происходят при успешном обращении к аудируемым ресурсам. Примером может служить успешный вход в систему. |
| Не успешный аудит | События безопасности, которые происходят при неуспешном обращении к аудируемым ресурсам. Примером может служить попытка открыть файл, не имея соответствующих прав доступа. |
Запись о событии включает в себя: идентификатор события, тип события, категорию события, массив строк и дополнительные, специфичные для события, двоичные данные. Каждый источник событий должен зарегистрировать свой файл сообщений, в котором хранятся строки описания идентификаторов сообщений, категорий и параметров. Строка описания может содержать места для вставки строк из массива, указанного при записи события, например:
Невозможно открыть %1, ошибка %2
Администраторы могут осмотреть и очищать журнал, разделить права на чтение и очистку невозможно. Кроме того, администратор может использовать специальную утилиту Winzapper для удаления записей о конкретных событиях из журнала. По этой причине, в случае если учетная запись администратора была взломана, история событий, содержащихся в журнале событий, становится недостоверной. Противостоять этому можно путем создания удаленного сервера журнала, доступ к которому будет осуществляться лишь посредством консоли.
Как только журнал достигает максимально допустимого размера, он может либо перезаписывать старые события, либо остановить запись. Это делает его восприимчивым к атакам, в которых нарушитель пытается переполнить журнал путем создания большого числа новых событий. Частично против этого может помочь увеличение максимального размера журнала. Таким образом, для переполнения журнала потребуется инициировать большее количество событий. Можно дать команду журналу не перезаписывать старые события, но это может стать причиной сбоя.
Ещё один способ атаковать журнал событий - зарегистрироваться под учетной записью администратора и изменить политику аудита, а именно - остановить запись в журнал несанкционированной активности. В зависимости от настроек политики аудита, её изменение может быть записано в журнале. Запись об этом событии можно очистить с помощью Winzapper. С этого момента активность не будет фиксироваться в журнале событий.
Конечно, доступ к журналу нужен не для всех атак. Но зная о том, каким образом работает журнал событий, можно принять меры предосторожности во избежание обнаружения. Например, пользователь, желающий войти в систему под учетной записью сослуживца по корпоративной сети, может ждать до тех пор, пока не сможет незаметно воспользоваться компьютером. Далее он использует аппаратные средства для подбора пароля и регистрируется в системе. Затем имя учетной записи пользователя передается в службу терминалов сWi-Fi Hotspot, IP-адрес которого не возможно будет отследить и выйти через него на взломщика.
После того как журнал очищается через окно просмотра событий, сразу создается одна запись в свежеочищенный журнал, отмечая время очистки и администратора-исполнителя. Эта информация может стать отправной точкой в расследовании подозрительных действий.
Кроме журнала событий Windows, администраторы также могут проверить журнал безопасности Брандмауэра Windows
studfiles.net
НОУ ИНТУИТ | Лекция | Аудит и журналы безопасности
Аннотация: После укрепления системы и настройки безопасности веб-сайта Microsoft IIS необходимо отслеживать попытки нарушения защиты сайта и определять признаки атак или вторжений на сервер.
Отслеживание событий является обычной и необходимой частью работы системных администраторов (или менеджеров веб-сайтов). Для этого в Windows 2000 и IIS используются журналы и аудит. Процедуры управления сайтом включают в себя регулярную проверку, анализ и просмотр зафиксированной информации для выявления неудавшихся или успешных атак, направленные на сайт. При обнаружении проблемы следует выполнить аудит безопасности для определения нанесенного ущерба и способа проникновения в систему.
В любой политике безопасности имеются процедуры и стандартные приемы для этих случаев. Даже и не думайте о работе сайта, если такая политика еще не разработана. В лекции рассказывается о том, как настраивать журнал, осуществлять аудит, создавать резервные копии и производить восстановление. Все эти действия необходимы для обеспечения безопасной и надежной работы сервера и веб-сайта.
Отслеживание событий сайта
События, происходящие на веб-сервере Windows 2000/IIS, отслеживаются при помощи просмотра и анализа журнала, в который отправляются сообщения от других служб, приложений или операционной системы. Эти сообщения учитывают события, происходящие в системе: выключение, запуск, создание новой учетной записи и т.д. IIS дополнительно отслеживает события собственного набора служб, например, запросы от посетителей сайта, отправленные на сервер для осуществления анонимного входа.
В Windows 2000 имеются журналы шести различных типов. Если вы имеете опыт системного администрирования Windows 2000, то уже знакомы с некоторыми из них. IIS ведет свой собственный отдельный журнал. Ниже приведен полный перечень журналов, работающих на сервере.
- Системный журнал. Фиксирует события компонентов: остановку и запуск службы или возникновение ошибки.
- Журнал безопасности. Записывает события, связанные с безопасностью: вход пользователей и использование ресурсов, например, создание, открытие и удаление файлов.
- Журналы приложений. Фиксируют события, связанные с приложениями, выполняемыми на сервере.
- Журнал службы каталогов. Фиксирует информацию о работе службы Active Directory, например, проблемы с подключением к глобальному каталогу.
- Журнал сервера DNS. Записывает события, связанные с работой службы Windows 2000 DNS в Active Directory.
- Журнал службы репликации файлов. Фиксирует значимые события, происходящие при попытке контроллера домена обновить другие контроллеры домена.
- Журнал IIS. Фиксирует события, происходящие при работе служб IIS (WWW, FTP и т.д.).
Для веб-сервера IIS не требуется работа всех без исключения журналов, например, не нужны журналы сервера DNS и службы репликации файлов. Журнал службы каталогов включается, если сервер является частью домена Windows Active Directory, причем ведется он на другом сервере. Веб-сервер работает с системным журналом, журналом приложений, журналом безопасности и журналом IIS.
Системный журнал Windows 2000 и журнал приложений активируются по умолчанию при установке IIS для автоматического фиксирования системных событий и событий приложений. Остальные журналы запускаются только после их непосредственной настройки и/или запуска. При выполнении IIS Lockdown автоматически активируется журнал безопасности Windows 2000 и IIS.
Информация журналов событий
Журналы Windows 2000 и IIS можно настроить на запись большого числа различных событий и действий. IIS по умолчанию сохраняет файлы журнала в текстовом формате, их можно просматривать в любом приложении, поддерживающем этот формат. Обычно файлы анализируются посредством их загрузки в программу генерации отчетов, которая осуществляет фильтрацию, сортировку и управление данными. На рисунке приведен пример содержимого файла журнала IIS.
Системный журнал Windows 2000 по умолчанию хранится в специальном формате в файлах с расширением .evt. Программа Event Viewer (Просмотр событий) Windows 2000, доступная в консоли MMC в папке Administration Tools (Администрирование), позволяет просматривать сообщения в журналах Windows 2000 и упорядочивать их по дате, времени, источнику, степени значимости и по другим переменным. Event Viewer используется также для преобразования файлов журнала в текстовый формат для просмотра в другой программе. На рисунке показана консоль программы Event Viewer.
Анализ аспектов безопасности при помощи файлов журналов требует некоторых навыков. Следует различать типы сообщений и понимать, что они означают. Когда ваш сервер начнет свою работу, внимательно следите за ним в течение некоторого времени и фиксируйте признаки нормальной работы, чтобы выявлять впоследствии отклонения от нормы.
Каждая из пяти категорий записей журналов имеет свой собственный значок. Каждое сообщение содержит идентификатор события ID, дату, время, объект, имя компьютера, категорию и тип номера события сообщения. Ниже приведены категории сообщений и их назначение.
- Информационные сообщения о событиях. Описывают успешное выполнение операций, таких как запуск службы.
- Предупреждающие сообщения о событиях. Описывают неожиданные действия, означающие проблему, или указывают на проблему, которая возникнет в будущем, если не будет устранена сейчас.
- Сообщения о событиях ошибок. Описывают ошибки, возникшие из-за неудачного выполнения задач.
- Сообщения о событиях успешного выполнения той или иной операции. Описывают события безопасности, выполненные Windows 2000 согласно запросу.
- Сообщения о событиях неудачного выполнения операции. Описывают события безопасности, не выполненные Windows 2000 согласно запросу.
На рисунке 5.1 приведен пример сообщения об ошибке в системном журнале Windows 2000, зафиксировавшего неожиданное отключение сервера. Это событие выходит за рамки нормальной работы и его необходимо исследовать. По идентификационному номеру ID события его можно найти в базе данных Microsoft Knowledge Base, если не понятно, что оно означает.
Рис. 5.1. Сообщение системного журнала Windows 2000, информирующее о неожиданном отключенииАудит
В Windows 2000 и IIS имеется специальная функция по отслеживанию безопасности – аудит, фиксирующая в журнале безопасности события, связанные с ресурсами IIS и Windows 2000 либо с объектами управления системой. Аудит является сложным процессом, использующим средства для анализа собранной информации и диагностики событий сайта, связанных с безопасностью.
Windows 2000 предоставляет три типа возможностей по аудиту объектов и ресурсов, свои функции имеются и в IIS (см. табл. 5.1).
| Система и реестр | Windows 2000 и IIS. |
| Файловая система | Windows 2000 и IIS. |
| Учетная запись пользователя | Windows 2000 и IIS. |
| Посетители домашней страницы | Только IIS. |
| Авторство | Только IIS. |
При аудите отслеживаются события согласно правилам аудита, определенным в локальной политике безопасности сервера и/или параметрах веб-сайта. Осуществляется аудит событий, входящих в следующие девять категорий.
- События системы. События, связанные с безопасностью, такие как отключение системы и ее перезапуск; события, влияющие на журнал безопасности.
- Отслеживание процесса. Детализированное отслеживание вызова процесса, дубликатов процессов, непрямого доступа к объектам и уничтожения процесса.
- Изменение политики. Изменение политики безопасности, включая присвоение привилегий, модификацию политики аудита и параметров доверия.
- Использование привилегий. Использование привилегий, присвоение специальных привилегий.
- Управление учетной записью. Создание, изменение, удаление пользователей и групп; изменение паролей.
- Доступ к службе каталогов. Отслеживание доступа к Active Directory. Включается для разрешения аудита определенных объектов каталога, работает только на контроллерах домена.
- События входа в учетную запись. Аутентификация на локальном компьютере в консоли или через сеть.
- События входа. Интерактивный вход или сетевые подключения к локальному компьютеру; генерируются в том месте, где происходит вход.
- Доступ к объектам. Попытки доступа к определенным объектам: файлам, каталогам, учетным записям пользователей и параметрам реестра.
Событие, для которого выполнен аудит, имеет два значения: успех и неудача. Для каждой категории событий возможен аудит успешных, неудачных или обоих типов событий. Тревожным признаком является высокая концентрация событий в журнале или необычная последовательность событий. Например, большое число событий ввода неправильного пароля означает, что сервер подвергся атаке на взлом пароля.
www.intuit.ru
