Глава 6. Наложение OpenLDAP accesslog

Наложение accesslog используется для отслеживания всех или избранных операций, производимых в конкретном DIT (целевое DIT) путём записывания деталей этих операций в виде записей в другое DIT (accesslog DIT). Это accesslog DIT можно исследовать с помощью стандартных запросов LDAP. Параметры наложения accesslog управляют тем, нужно ли помещать в журнал сведения о всех, либо только о части операций LDAP в целевом DIT (logops), следует ли сохранять связанную информацию, такую как предыдущее содержимое атрибутов или записей (logold и logoldattr), а также когда удалять записи из accesslog DIT. Записи accesslog DIT сохраняются с использованием объектных классов и атрибутов из специализированного набора схемы данных аудита.

Данное наложение создаёт accesslog DIT как DIT общего назначения, которое может использоваться, например, для операций LDAP или аудита журнала операций целевого DIT. Кроме того, accesslog DIT может специализированно применяться в директиве syncrepl для delta-репликации или delta-синхронизации. В последнем случае, поскольку accesslog DIT сконфигурировано только на хранение информации об операциях изменения LDAP, выполнявшихся в целевом DIT, оно представляет собой очень точный и подробный отчёт об изменениях атрибутов целевого DIT. При нормальной синхронизации syncrepl, когда изменяется любой из атрибутов записи целевого DIT, во время цикла репликации изменённая запись передаётся целиком. Когда syncrepl используется совместно с accesslog DIT, во время цикла репликации требуется передавать только эти изменения атрибута (а также связанные с ними операционные атрибуты, такие как entryCSN и т.п.).

Обзор использования

Наложение accesslog определяется в разделе database целевого DIT — таким образом, создаётся привязка целевого DIT к конкретному accesslog DIT (это означает, что на одном сервере LDAP может быть несколько accesslog DIT). Затем accesslog DIT определяется как отдельный раздел database и, если данное accesslog DIT будет использоваться для организации delta-репликации, оно должно быть настроено как поставщик репликации путём использования наложения syncprov. Пример:

# раздел глобальных параметров slapd.conf
...
# раздел database целевого DIT 
database bdb
suffix "dc=example,dc=com"
...
# указываем, что данное целевое DIT использует журналирование accesslog
overlay accesslog
# определяем, какое accesslog DIT будет использоваться данным целевым DIT
logdb "cn=accesslogname"
# остальные необходимые директивы
...
# если это целевое DIT реплицируется в стиле syncrepl
# необходимо определить наложение syncprov
overlay syncprov
...

# accesslog DIT
database bdb
# суффикс должен совпадать со значением, указанным 
# в директиве logdb ассоциированного целевого DIT
suffix "cn=accesslogname"
...
# требуется, если accesslog используется в delta-syncrepl
overlay syncprov
...

Примечание: При использовании в конфигурации delta-синхронизации syncrepl и целевое DIT, и accesslog DIT должны быть поставщиками syncrepl (overlay syncprov). Это необходимо для того, чтобы разрешить процедурам синхронизации пользоваться обоими этими DIT как источниками репликации. Например, если потребитель syncrepl пуст, то для первоначальной синхронизации потребуется целевое DIT, после чего в нормальном режиме будет использоваться accesslog DIT.

Подробное описание конфигурации delta-репликации здесь.

Директивы конфигурации

Приведённые ниже директивы slapd.conf применяются к наложению журнала доступа (accesslog). Они должны определяться после директивы overlay accesslog.

Директива logdb

logdb suffix

Директива определяет суффикс accesslog DIT, которое будет использоваться для хранения записей журнала, относящихся к DIT, определяемому в том разделе database, в котором присутствует данная директива overlay accesslog (то есть к целевому DIT). accesslog DIT может определяться для одного или нескольких разделов database (целевых DIT), каждый из которых будет ссылаться на различный суффикс accesslog. accesslog DIT должно быть определено в каком-либо месте конфигурации с помощью другой директивы и раздела database. Списки контроля доступа access to для определения accesslog DIT должны ограничивать доступ только к этому DIT. Наложение accesslog автоматически создаст запись суффикса (корневую запись) в accesslog DIT, и потому для его инициализации не требуется применение файла LDIF. Каждая операция, сохраняемая в accesslog DIT, будет добавляться в виде дочерней записи в корневую запись. Пример:

# фрагмент slapd.conf
...
# целевое DIT
database bdb
suffix "dc=example,dc=com"
...
overlay accesslog
logdb "cn=mylog"
...

# accesslog DIT
database bdb
suffix "cn=mylog"
...

Директива logops

logops operations

Директива определяет, какие типы операций в целевом DIT будут помещаться в accesslog DIT. Аргументы директивы задаются в виде списка, разделяемого пробельными символами. Допустимые типы операций: abandon (отказ от подключения), add (добавление), bind (подсоединение), compare (сравнение), delete (удаление), extended (расширенная операция), modify (модификация), modrdn (модификация rdn), search (поиск) и unbind (отсоединение). Для общепринятых наборов операций могут использоваться псевдонимы:

writes — add, delete, modify, modrdn
reads — compare, search
session — abandon, bind, unbind
all — все операции

Если наложение используется в целях delta-синхронизации, как правило, настраивается журналирование только тех операций, которые изменяют содержимое DIT, то есть используется только writes. Как видно из списка поддерживаемых типов операций, с помощью данного наложения можно организовать всеобъемлющее журналирование в целях аудита. Примеры:

# при использовании с delta-синхронизацией
logops writes

# всеобъемлющее журналирование
logops writes reads session
# ИЛИ 
logops all

# только избранные операции
logops delete add bind

Директива logold

logold filter

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

# при операциях delete или modify, перед тем,
# как помещать в журнал сведения об операции,
# в него помещается содержимое записи,
# если в ней есть объектный класс inetorgperson
# и определён атрибут uid
logold (&(objectclass=inetorgperson)(uid=*))

Директива logoldattr

logoldattr attr [...]

Директива определяет список атрибутов, прежнее содержимое которых будет всегда помещаться в журнал при операциях modify и modRDN. По умолчанию в журнал помещается только новое содержимое атрибутов, изменённых в операции modify, а при запросах modRDN сведения об атрибутах в журнал вообще не помещаются. Для delta-синхронизации не используется. Пример:

# всегда сохраняется текущее состояние атрибутов uid и cn
# до выполнения любой операции modify или modRDN
logoldattr uid cn

Директива logpurge

logpurge age interval

Директива определяет сразу максимальный возраст записей журнала, которые будут храниться в базе данных, и частоту сканирования базы данных на предмет устаревших записей. Оба аргумента age и interval указываются как промежуток времени в днях, часах, минутах и секундах. Формат времени: [ddd+]hh:mm[:ss], дни и секунды — необязательные компоненты, а часы и минуты — обязательные. Число дней может содержать до пяти цифр, все остальные числовые поля должны содержать ровно две цифры. Пример:

# база данных журнала будет сканироваться каждый день
# записи старше двух дней будут удалены
logpurge 2+00:00 1+00:00

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

Директива logsuccess

logsuccess TRUE | FALSE

Если эта директива установлена в TRUE, то в журнал accesslog будут помещаться только записи об успешно выполненных запросах, то есть запросах, возвративших результирующий код 0 (LDAP_SUCCESS). Если директива установлена в FALSE, в accesslog будут добавляться записи об указанных операциях независимо от их результирующего кода. Значение по умолчанию — FALSE. При использовании с delta-синхронизацией logsuccess должна быть установлена в TRUE.

Примеры конфигурации:

# фрагмент slapd.conf
# раздел глобальных настроек
...
# определение целевой DIT
database bdb
suffix dc=example,dc=com
...
# определяем журнал аудита общего назначения,
# содержащий все операции (включая завершившиеся неудачей)
# в данном целевом DIT
overlay accesslog
logdb "cn=auditlog"
logops writes reads
# перечитывать журнал каждые 5 дней и производить чистку
# записей которые старше 30 дней
logpurge 30+00:00 5+00:00
# дополнительно - сохраняем предыдущее содержимое записей с
# объектным классом person до выполнения операций записи
logold (objectclass=person)
# если требуется только содержимое конкретных атрибутов,
# нужно использовать logoldattr 
logoldattr uid cn

# определение accesslog DIT
database bdb
suffix "cn=auditlog"
...
index reqStart eq
# ACL - разрешаем выполнять поиск конкретному клиенту
access to *
  by dn.base="cn=admin,dc=example,dc=com" read

Пример конфигурации поставщика при использовании delta-синхронизации:

# фрагмент slapd.conf
# раздел глобальных настроек
...
# определение целевой DIT
database bdb
suffix dc=example,dc=com
...
# определяем журнал, приемлемый для использования с delta-syncrepl
# в журнал помещаются лишь успешные операции, модифицирующие содержимое 
# данного целевого DIT
overlay accesslog
logdb "cn=deltalog"
logops writes
# заносим в журнал только успешные операции
# операции записи, завершившиеся неудачей, не меняют содержимого данного DIT
logsuccess TRUE
# проверяем журнал ежедневно и чистим записи старше двух дней
logpurge 2+00:00 1+00:00

# определение accesslog DIT
database bdb
suffix "cn=deltalog"
...

# ACL - разрешаем выполнять поиск для delta-синхронзации
# данный DN должен совпадать с указываемым в параметре binddn
# директивы syncrepl потребителя
access to *
  by dn.base="cn=admin,dc=example,dc=com" read

Набор схемы данных accesslog

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

Существует основной объектный класс auditObject, от которого унаследованы два дополнительных объектных класса — auditReadObject и auditWriteObject. Далее от этих объектных классов унаследованы объектные классы для всех типов операций LDAP. Данная иерархия объектных классов разработана для того, чтобы позволить осуществлять гибкие и эффективные поисковые запросы записей журнала, основываясь либо на классе конкретного типа операции, либо на более обобщённой классификации. Определение класса auditObject выглядит следующим образом:

(  1.3.6.1.4.1.4203.666.11.5.2.1
  NAME 'auditObject'
  DESC 'OpenLDAP request auditing'
  SUP top STRUCTURAL
  MUST ( reqStart $ reqType $ reqSession )
  MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls 
   $ reqEnd $ reqResult $ reqMessage $ reqReferral ) )
# Имейте ввиду, что все OID, используемые в наборе схемы журнала,
# в настоящее время принадлежат ветке OpenLDAP Experimental.
# Предполагается, что в будущем они будут перемещены в ветку Standard.
# Обзор атрибутов: 
# reqStart и reqEnd представляют собой, соответственно, время начала
# и конца операции. Они используют синтаксис generalizedTime.
# Атрибут reqStart также используется в качестве RDN для каждой записи журнала.
# Атрибут reqType - простая строка, содержащая тип операции, помещаемой в журнал, 
# например, add, delete, search, и т.д. Для расширенных операций,
# тип также включает OID расширенной операции, например: extended(1.1.1.1)
# Атрибут reqSession - зависящий от реализации идентификатор, общий для всех операций,
# ассоциированных с одной и той же сессией LDAP. В настоящее время - это внутренний
# идентификатор соединения slapd, хранящийся в виде десятичного числа.
# Атрибут reqDN - это distinguishedName целевой записи для производимой операции. 
# Например, для запросов Bind - это Bind DN, для запросов Add - это DN добавляемой записи,
# для запросов Search - это базовый DN поиска.
# Атрибут reqAuthzID - это distinguishedName пользователя, выполняющего операцию.
# Обычно это то же самое имя, которое ассоциировалось с сессией при её установке
# с помощью запроса Bind (если таковой был), но оно может быть изменено в зависимости
# от различных обстоятельств.
# Атрибуты reqControls и reqRespControls содержат любые управляющие последовательности,
# посылаемые клиентом при запросе и возвращаемые сервером в ответе соответственно.
# Значения атрибута - это просто неинтерпретируемые строки байт.
# Атрибут reqResult - это числовой результирующий код LDAP операции, указывающий
# либо на успешное завершение операции, либо на код конкретной ошибки LDAP.
# Код ошибки может сопровождаться текстовым сообщением об ошибке, которое будет
# записываться в атрибут reqMessage.
# Атрибут reqReferral содержит любые отсылки, которые были возвращены с результатом запроса.

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

(  1.3.6.1.4.1.4203.666.11.5.2.4
  NAME 'auditAbandon'
  DESC 'Abandon operation'
  SUP auditObject STRUCTURAL
  MUST reqId )
# Для операции Abandon атрибут reqId содержит идентификатор сообщения того запроса,
# который был отменён.

(  1.3.6.1.4.1.4203.666.11.5.2.5
  NAME 'auditAdd'
  DESC 'Add operation'
  SUP auditWriteObject STRUCTURAL
  MUST reqMod )
# Класс Add унаследован от класса auditWriteObject. Классы Add и Modify очень похожи.
# Атрибут reqMod содержит все атрибуты добавляемой записи (или, в случае
# операции Modify, все выполняемые модификации). Формат значений:
#  attribute:<+|-|=|#> [ value]
# Здесь '+' указывает, что значение добавляется (add), '-' - что значение удаляется
# (delete), '=' - что значение заменяется (replace), а '#' - что значение
# инкрементируется (increment). В операциях Add все значения атрибута reqMod
# будут иметь обозначение '+'.

(  1.3.6.1.4.1.4203.666.11.5.2.6
  NAME 'auditBind'
  DESC 'Bind operation'
  SUP auditObject STRUCTURAL
  MUST ( reqVersion $ reqMethod ) )
# Класс Bind включает атрибут reqVersion, содержащий версию протокола LDAP,
# указываемую в операции Bind, а также атрибут reqMethod, содержащий Bind Method,
# используемый в операции Bind. Это будет строка SIMPLE для LDAP Simple Bind
# или SASL(mech) для SASL Bind. Имейте ввиду, без специальных настроек
# (переопределения на глобальном уровне), будут приниматься только
# Simple Bind подсоединения с использованием DN из текущей базы данных.

(  1.3.6.1.4.1.4203.666.11.5.2.7 
  NAME 'auditCompare'
  DESC 'Compare operation'
  SUP auditObject STRUCTURAL
  MUST reqAssertion )
# Для операций Compare атрибут reqAssertion содержит Attribute Value Assertion,
# используемое в запросах сравнения (compare).

(  1.3.6.1.4.1.4203.666.11.5.2.8
  NAME 'auditDelete'
  DESC 'Delete operation'
  SUP auditWriteObject STRUCTURAL
  MAY reqOld )
# Для операций Delete не требуется дополнительных параметров. Однако, 
# атрибут reqOld может опционально использоваться для сохранения содержимого
# записи перед её удалением. Формат значений:
#   attribute: value
# Атрибут reqOld заполняется только в случае, если удаляемая запись
# совпадает с фильтром, указанным в директиве logold.

(  1.3.6.1.4.1.4203.666.11.5.2.9
  NAME 'auditModify'
  DESC 'Modify operation'
  SUP auditWriteObject STRUCTURAL
  MAY reqOld 
  MUST reqMod )
# Операция Modify содержит описание модикаций в атрибуте reqMod, который уже
# был описан выше в операции Add. Данная операция опционально может содержать
# предыдущие значения любых изменившихся атрибутов в атрибуте reqOld
# с использованием того же формата, что был описан выше для операции Delete.
# Атрибут reqOld заполняется только в случае, если модифицируемая запись
# совпадает с фильтром, указанным в директиве logold.

(  1.3.6.1.4.1.4203.666.11.5.2.10
  NAME 'auditModRDN'
  DESC 'ModRDN operation'
  SUP auditWriteObject STRUCTURAL
  MUST ( reqNewRDN $ reqDeleteOldRDN )
  MAY ( reqNewSuperior $ reqOld ) )
# Класс ModRDN использует атрибут reqNewRDN для хранения нового RDN запроса.
# Атрибут reqDeleteOldRDN - значение типа Boolean, содержащее TRUE
# если старое RDN было удалено из записи, или FALSE если старое RDN было сохранено.
# Атрибут reqNewSuperior содержит DN новой родительской записи если запрос
# определяет новую родительскую запись. Атрибут reqOld заполняется только в случае,
# если модифицируемая запись совпадает с фильтром, указанным в директиве logold,
# и содержит атрибуты из списка, указанного в директиве logoldattr.

(  1.3.6.1.4.1.4203.666.11.5.2.11
  NAME 'auditSearch'
  DESC 'Search operation'
  SUP auditReadObject STRUCTURAL
  MUST ( reqScope $ reqDerefAliases $ reqAttrsOnly )
  MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $
    reqTimeLimit ) )
# В классе Search атрибут reqScope содержит диапазон оригинального поискового запроса
# и использует значения, указываемые в формате LDAP URL, например, base, one, sub
# или subord. Атрибут reqDerefAliases принимает одно из значений never, finding,
# searching или always, означающих каким образом во время поиска будут
# обрабатываться псевдонимы. Атрибут reqAttrsOnly - значение типа Boolean,
# устанавливаемое в TRUE если запрашивались только имена атрибутов, или в FALSE
# если запрашивались атрибуты со своими значениями. Атрибут reqFilter содержит фильтр,
# использовавшийся в поисковом запросе. В атрибуте reqAttr перечисляются запрашиваемые
# атрибуты, если таковые указывались при запросе. Атрибут reqEntries - целое число,
# означающее количество записей, которые были возвращены на данный поисковый запрос.
# Атрибуты reqSizeLimit и reqTimeLimit показывают, какие ограничения были запрошены
# клиентом на данную операцию поиска.

(  1.3.6.1.4.1.4203.666.11.5.2.12
  NAME 'auditExtended'
  DESC 'Extended operation'
  SUP auditObject STRUCTURAL
  MAY reqData )
# Класс Extended представляет LDAP Extended Operation. Как было сказано выше,
# в атрибут reqType родительского класса включается актуальный OID операции.
# Если с запросом предоставлялась какая-либо дополнительная информация,
# она будет помещена в атрибут reqData как неинтерпретируемая строка байт.