Как включить аудит журналов активности в ownCloud Enterprise

Включение ленты активности файлов в ownCloud само по себе не создает журнал аудита для администратора. Для ownCloud Server Enterprise соответствующим компонентом является приложение «Аудит» , предназначенное только для корпоративных пользователей . Оно записывает более широкий набор действий пользователей и администраторов в систему логирования сервера, откуда эти записи можно перенаправить в специальный файл и, при необходимости, на платформу анализа журналов.

Данное руководство описывает классическое развертывание ownCloud Server, описанное для версии 11.0. Названия пунктов меню и методы настройки могут различаться в зависимости от версии и пакета. ownCloud Infinite Scale (oCIS) использует отдельную службу аудита, поэтому не применяйте эти инструкции для развертывания oCIS.

Что записывает аудит ownCloud?

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

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

Перед включением аудита

• Убедитесь, что развертывание выполнено на сервере ownCloud Server Enterprise и что приложение «Аудит» доступно для данного экземпляра.
• Для включения приложения используйте учетную запись администратора ownCloud. Системному администратору также может потребоваться доступ к командной оболочке или контейнеру для настройки параметров логирования.
• Выберите выделенное место для хранения логов с достаточным объемом дискового пространства. Убедитесь, что веб-сервер или контейнер может записывать в него данные, и определите, кому разрешен доступ к чтению.
• Перед включением потока аудита большого объема установите политику хранения и ротации. Записи аудита могут включать идентификаторы пользователей, IP-адреса, пути к файлам, сведения о клиентах и ​​метаданные о совместном использовании.

Шаг 1: Включите приложение «Аудит».

Войдите в систему как администратор ownCloud и откройте раздел «Приложения» в административном интерфейсе. Найдите раздел «Аудит» и включите его. Если приложение отсутствует, проверьте права доступа Enterprise, версию вашего сервера, а также ownCloud Marketplace или канал поддержки поставщика на наличие совместимого пакета приложений. Не следует предполагать, что стандартное приложение «Активность» является заменой.

Шаг 2: Направляйте сообщения аудита в специальный файл.

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

OWNCLOUD_LOG_CONDITIONS=[{"apps":["admin_audit"],"loglevel":0,"logfile":"/mnt/data/files/admin_audit.log"}]

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

Для установок, настроенных через config.php, в справочнике по настройке приложений ownCloud также описан log.conditionsключ. Адаптируйте путь к фактическому каталогу данных вашего хоста и сохраните существующие записи конфигурации, а не заменяйте весь массив:

'log.conditions' => [
  [
    'apps' => ['admin_audit'],
    'logfile' => '/var/www/owncloud/data/admin_audit.log'
  ],
],

Если вы сохраняете результаты аудита в обычном журнале ownCloud вместо того, чтобы направлять их отдельно, в руководстве по аудиту ownCloud указано, что уровень ведения журнала сервера должен быть установлен на 1(INFO) или 0(DEBUG), иначе сообщения аудита могут не записываться. Условие отдельного файла позволяет избежать зависимости от глобального уровня ведения журнала, но не отменяет необходимости отслеживать доступное дисковое пространство.

Шаг 3: Убедитесь, что в файл поступило реальное событие.

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

Убедитесь, что после изменения конфигурации появляется новое сгенерированное действие, что его метка времени соответствует часовому поясу сервера, и что действие и пользователь соответствуют тесту. Избегайте использования конфиденциального производственного файла для проверки логирования удаления. Если ничего не отображается, убедитесь, что приложение «Аудит» включено, место назначения логов указано правильно и доступно для записи, переменная среды или конфигурация PHP действительно загружены, уровень логирования сервера соответствует уровню логирования по умолчанию, и тип действия входит в число тех, которые записываются установленной версией приложения «Аудит».

Шаг 4: Защитите, сохраните и просмотрите файл аудита.

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

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

Если вы используете Splunk, в документации ownCloud по аудиту описано мониторинг admin_audit.logс помощью Splunk Universal Forwarder и анализ выходных данных в формате JSON. Документация включает примеры inputs.confи props.confнастройки. Рассматривайте систему пересылки и принимающую систему как часть зоны аудита: защищайте учетные данные, шифруйте передачу данных там, где это поддерживается вашей архитектурой логирования, подтверждайте поступление событий и оповещайте о пробелах или сбоях при приеме данных.

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

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

Распространенные проблемы при настройке

• Записи аудита не отображаются: убедитесь, что приложение «Корпоративный аудит» включено. При использовании стандартного журнала проверьте, что глобальный уровень — INFO (1) или DEBUG (0). При использовании отдельного файла проверьте состояние приложения и доступный для записи путь.
• Отсутствует ожидаемый файл: указанный в документации путь Docker предполагает наличие смонтированного тома. Проверьте фактическую конфигурацию контейнера, сопоставление томов и права доступа пользователя службы.
• Записи отображаются не в том месте: проверьте активные правила OWNCLOUD_LOG_CONDITIONSили log.conditionsконфигурацию и избегайте дублирующихся или конфликтующих правил.
• Лента событий выглядит неполной: «Активность» и «Аудит» — это разные приложения, и охват приложения «Аудит» зависит от типа события и версии. Прежде чем делать вывод о неисправности системы ведения журнала, проверьте наличие известного события, поддерживаемого установленной версией.
• События командной строки отсутствуют: ownCloud по умолчанию включает события, запускаемые через CLI. Проверьте, admin_audit ignore_cli_eventsустановлено ли значение yes.

Контрольный список для окончательной проверки

1. Развертывание осуществляется на платформе ownCloud Server Enterprise, и совместимое приложение для аудита включено.
2. Настроенное место назначения существует, доступно для записи пользователем ownCloud и не отображается как обычный пользовательский контент.
3. Разрешенное тестовое действие создает соответствующую запись с правдоподобной меткой времени и действующим лицом.
4. Права доступа, ротация, хранение и обязанности по управлению доступом задокументированы.
5. Если журналы пересылаются во внешнюю систему, принимающая система отображает последние события, и система мониторинга может обнаруживать сбои.

Подробную информацию о конкретной версии см. в документации по аудиту сервера ownCloud , справочнике по настройке приложений ownCloud и руководстве по ролям ownCloud и разделению аудита . Информацию об отдельном продукте Infinite Scale см. в документации по службе аудита oCIS .