Skip to content
Snippets Groups Projects

Audit log (4уд)

    • Closed Issue created by Yaroslav Dynnikov @rosik

    Из #340:

    10. К регистрации событий безопасности в СУБД предъявляются следующие требования:

    10.1. СУБД 6, 5 классов защиты должна:

    • обеспечивать регистрацию событий безопасности, связанных с функционированием СУБД и действиями пользователей СУБД;

    • оповещать администратора СУБД, администратора БД о событиях безопасности;

    • осуществлять сбор и хранение записей в журнале событий безопасности, которые позволяют определить, когда и какие события происходили.

    Регистрация событий безопасности в СУБД должна осуществляться с учетом требований разделов 5-6 ГОСТ Р 59548-2022 «Защита информации. Регистрация событий безопасности. Требования к регистрируемой информации». Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 13 января 2022 г. № 2-ст (М., «Стандартинформ», 2022).

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

    Для регистрируемых событий безопасности в каждой записи журнала событий безопасности должны регистрироваться номер (уникальный идентификатор) события, дата, время, тип события безопасности.

    Записи журнала событий безопасности должны представляться в структурированном виде и содержать дату и время события безопасности, взятое из аппаратной платформы или ОС.

    Журнал событий безопасности СУБД должен быть доступен для чтения администратору СУБД и администратору БД. Для пользователя БД журнал событий безопасности СУБД должен быть недоступен. При исчерпании области памяти, отведенной под журнал событий безопасности СУБД, СУБД должна осуществлять самостоятельно или с применением механизмов сертифицированной ОС архивирование журнала с последующей очисткой высвобождаемой области памяти.

    Регистрации подлежат как минимум следующие события безопасности:

    • создание учетных записей пользователей СУБД;
    • изменение атрибутов учетных записей пользователей СУБД;
    • успешные и неуспешные попытки аутентификации пользователей СУБД;
    • запуск и остановка СУБД с указанием причины остановки;
    • изменение конфигурации СУБД;
    • создание и удаление БД, таблицы за исключением временных таблиц, создаваемых СУБД в служебных целях;
    • подключение, восстановление БД;
    • изменение правил разграничения доступа в СУБД;
    • факты нарушения целостности объектов контроля;
    • создание и изменение процедур (программного кода), хранимых в БД, и представлений.

    10.2. В СУБД 4 класса защиты наряду с требованиями, установленными подпунктом 10.1 пункта 10 настоящих Требований, для регистрируемых событий безопасности в каждой записи журнала событий безопасности дополнительно должны регистрироваться сведения о важности события.

    Предыдущие наработки: https://git.picodata.io/picodata/picodata/picodata/-/issues/282#note_36143

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Yaroslav Dynnikov changed milestone to %23.12.0

      changed milestone to %23.12.0

    • Yaroslav Dynnikov added backlog + 1 deleted label

      added backlog + 1 deleted label

    • Yaroslav Dynnikov changed the description

      changed the description

    • Yaroslav Dynnikov changed title from Audit log to Audit log (4уд)

      changed title from Audit log to Audit log (4уд)

    • Dmitry Ivanov
      Dmitry Ivanov @funbringer ·
      Maintainer

      Pre-RFC for audit log.

      Click to expand

      Мотивация

      Сертификация требует от СУБД наличия журнала событий безопасности.

      Регистрируемая информация о событиях

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

      • Номер (уникальный идентификатор) события.
      • Дата и время.
      • Тип события безопасности (например, create_user).
      • Важность события (высокая/средняя/низкая).
      • Имя пользователя, исполнившего операцию (если применимо).

      Помимо этого, запись должна содержать краткое описание выполненного действия и дополнительные идентификаторы затронутых субъектов и объектов, например, имена пользователей, БД, изменения ACL итд.

      Перечень событий безопасности

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

      Высокая важность

      • Создание учетных записей пользователей СУБД.
        • Имя новой учетной записи
        • Параметры учетной записи (метод аутентификации auth_type и проч.)
      • Изменение атрибутов учетных записей пользователей СУБД.
        • Имена затронутых атрибутов
        • Старые и новые значения атрибутов (для сравнения)
      • Изменение правил разграничения доступа в СУБД.
        • Имена затронутых объектов
        • Старые и новые правила доступа (для сравнения)
      • Успешные и неуспешные попытки аутентификации пользователей СУБД.
        • Пользователь, от имени которого происходила aутентификация
        • Вердикт о блокировке учетной записи (да/нет) и срок (например, неопределенный)

      Средняя важность

      • Запуск и остановка СУБД.
        • Причина остановки
      • Создание таблиц (за исключением временных) и представлений (view?).
        • Имя новой таблицы
        • Владелец таблицы
        • Права (DAC, ACL итд), чтобы было понятно, кто будет иметь к ней доступ
      • Создание и изменение хранимых процедур (программного кода).
        • TODO: вроде бы обсудили, что у нас хранимых процедур в классическом понимании нет (@rosik)
      • Создание, удаление, восстановление БД (явно калька с postgres, неприменимо).

      Низкая важность

      • Изменение конфигурации системы управления базами данных.
        • Имена параметров конфигурации
        • Старые и новые значения параметров конфигурации (для сравнения)

      Предыдущие попытки

      До этого мы уже пытались реализовать журнал безопасности для другого проекта. Ниже перечислены основные свойства этого решения:

      • Заказчик выдал нам OpenAPI спеку удаленного коллектора логов (audit endpoint).
      • OpenAPI спека содержала два метода: регистрация схемы + отправка события.
      • События собирались в lua table через триггеры тарантула, например, on_connect.
      • Из lua table записи перекладывались в space в отдельном файбере.
      • Из space записи отправлялись в audit endpoint в отдельном файбере.
      • Итоговый пайплайн: triggers -> lua table -> space -> network (audit endpoint).
      • https://git.picodata.io/picodata/picodata/picodata/-/issues/282#note_36143.

      К сожалению, решение имеет несколько недостатков:

      • Персистентность журнала не гарантируется (следует из пайплайна).
      • Нужды сертификации не подразумевают отправку событий на OpenAPI эндпоинт.
      • Согласно Диме Травяну, решение не работает с актуальной версией picodata.
      • Нужно проверить: возможно, требуются новые триггеры тарантула для сбора событий.

      В результате нам нужно реализовать иное решение с учетом новых требований и выявленных недостатков.

      Подход к реализации

      Ведение журнала (создание записей итд)

      Можно выделить несколько способов ведения журнала безопасности:

      • Отправка на удаленный эндпоинт с использованием какого-то протокола (http?).
        • Требует описания протокола (например, через OpenAPI спеку).
        • Требует реализации коллектора (на той стороне).
        • Все равно нужна локальная буферизация (в файл или спейс).
      • Запись в локальный текстовый файл (аналог обычных логов) с периодической ротацией.
        • Задачу обеспечения безопасности журнала можно переложить на доверенную ОС.
        • Нужно думать над ротацией.
      • Запись на уровне спейсов picodata.
        • Наверное, сложнее, чем просто запись в файл.
        • Нужно думать над ротацией.

      Способы можно комбинировать.

      TODO: вывод!

      Сбор событий

      Для сбора событий, происходящих в picodata, можно использовать следующие средства:

      • Встроенные триггеры тарантула (box.session.on_auth итд).
        • В некоторых из них (всех?) нельзя делать yield, работать с транзакциями итд.
        • Проблемы с надежностью: триггер можно переопределить/сломать итд.
      • Использовать в качестве источника событий журнал raft (идея Ярика, см. ниже).
        • Все изменения схемы отражаются в raft согласно дизайну продукта.
        • Фактически, это и есть space, в который пишутся некоторые события.
        • Для децентрализованных событий (auth attempts) можно использовать классические логи.
        • Выглядит, как самый классный вариант.
      • Новый механизм, который нужно разработать.
        • Пока что совершенно не очевидно, что это нужно делать.

      TODO: вывод!

      Идеи

      Ярик (@rosik):

      • Один аудит для централизованных событий.
        • Если лог файл: попробовать протащить идею чтения журнала средствами ОС.
        • Если пишем в space: нужно делать просмотрщик.
        • Идея: продать вместо аудита журнал raft.
          • Это уже space.
          • Можно сделать просмотрщик событий, нужна пагинация.
          • Можно читать и конфигурацию тоже.
          • Полезно для нас самих.
        • Запуск инстансов -- это тоже централизованная история.
      • Другой для децентрализованных (неудачные попытки auth).
        • Протаскиваем через коллег обычный тарантульный журнал.
        • Можно ввести новый уровень логирования, AUDIT.

      Костя (@kostja):

      • Аутентификация не должна требовать кворума (а вдруг должна?).
      • Нужно проработать этот вопрос.
      • Обсудить с ним еще раз.

      Дима Кольцов (@vifley):

      • Обсудить с ним.
      Edited by Dmitry Ivanov
    • Dmitry Ivanov assigned to @funbringer

      assigned to @funbringer

    • Yaroslav Dynnikov
      Yaroslav Dynnikov @rosik ·
      Author Maintainer

      Артем Казанцев, [24/08/2023 10:57]

      На мой взгляд в части регистрируемой информации о событиях безопасности нужно указать больше конкретики по дополнительным артефактам (краткому описанию выполненного действия). Я бы прям для каждого события расписал что в эту информацию будет попадать. К примеру: Событие "Изменение правил разграничения доступа". В артефакт попадает информация о том какая учетная запись пользователя выполнила процедуру изменения и для какой учетной записи.

    • Yaroslav Dynnikov changed the description

      changed the description

    • Dmitry Ivanov
      Dmitry Ivanov @funbringer ·
      Maintainer

      RFC (слегка устарел):

      https://docs.google.com/document/d/1tOTefT-hVe5XqroBcndGxlJZqdFbicN1Pj9i1iMUYYQ

      Пользовательская документация (наиболее актуальный документ):

      https://docs.google.com/document/d/1wNXBtcVfzgawNb7ylvi8AQr3A4IxyseLmO5n1knWsOA

      Edited by Dmitry Ivanov
    • Dmitry Ivanov mentioned in merge request !706 (merged)

      mentioned in merge request !706 (merged)

    • Dmitry Ivanov mentioned in merge request !738 (merged)

      mentioned in merge request !738 (merged)

    • Dmitry Ivanov mentioned in merge request !730 (merged)

      mentioned in merge request !730 (merged)

    • Yaroslav Dynnikov mentioned in merge request picodata/tarantool!137

      mentioned in merge request picodata/tarantool!137

    • Dmitry Ivanov mentioned in merge request !750 (merged)

      mentioned in merge request !750 (merged)

    • Yaroslav Dynnikov marked this issue as related to docs#127 (closed)

      marked this issue as related to docs#127 (closed)

    • Dmitry Ivanov mentioned in merge request !764 (merged)

      mentioned in merge request !764 (merged)

    • Dmitry Ivanov mentioned in merge request !766 (merged)

      mentioned in merge request !766 (merged)

    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    • Loading
    Please register or sign in to reply