Перейти до вмісту

Машинний переклад. Авторитетним джерелом є англійська версія; перевірка носієм мови ще не виконана.

Посібники

Підключення PostgreSQL (pgaudit)

Детальний посібник для конектора спостереження за доступом до бази даних PostgreSQL через pgAudit — налаштування формату журналу, потокове поглинання.

Оновлено:

Конектор pgAudit відстежує структурований аудиторський журнал PostgreSQL та генерує одне ребро карти доступу на кожен аудитований доступ до даних. Режим читання/запису береться дослівно з класу pgAudit (READ, WRITE, DDL) — ніколи не виводиться з тексту SQL. Конектор є тільки для читання над файлом журналу і ніколи не відкриває з’єднання до бази даних.

Для загальної моделі джерел та структури конфігурації почніть з Підключення джерела. Ця сторінка описує передумови на стороні PostgreSQL, повну поверхню конфігурації, механіку атрибуції та операційні міркування для продакшн середовищ.

Передумови PostgreSQL

Конектор читає вивід pgAudit, тому PostgreSQL повинен бути налаштований для його генерації. Встановіть розширення (apt install postgresql-<version>-pgaudit на Debian/Ubuntu), завантажте його через shared_preload_libraries, перезапустіть, потім виконайте CREATE EXTENSION pgaudit у кожній базі даних, яку хочете спостерігати.

Мінімальні налаштування postgresql.conf для корисного виводу:

shared_preload_libraries = 'pgaudit'
pgaudit.log = 'read, write'       # READ та WRITE покривають доступ до даних
log_destination = 'jsonlog'        # рекомендовано для потокового режиму; csvlog також працює
logging_collector = on
log_directory = '/var/log/postgresql'
log_filename = 'postgresql.json'

Перезапустіть після shared_preload_libraries; перезавантажте (SELECT pg_reload_conf()) після решти. Перевірте, виконавши запит та підтвердивши, що запис pgAudit з’являється в журналі — поле message запису містить структурований рядок pgAudit (клас, команда, назва об’єкта). Якщо з’являються лише стандартні повідомлення PostgreSQL, розширення не завантажено або не налаштовано.

Конфігурація

Конектор обирається за kind: "pgaudit" у JSON-файлі OLIVARES_SOURCES_CONFIG. Повний приклад:

{
  "sources": [
    {
      "name": "prod-postgres",
      "kind": "pgaudit",
      "tenant": "acme",
      "config": {
        "log_path": "/var/log/postgresql/postgresql.json",
        "format": "jsonlog",
        "follow": "true",
        "shared_accounts": "app_pool,reporting"
      }
    }
  ]
}

Усі значення config є рядками. Ключі належать конектору pgAudit:

  • log_path (обов’язковий) — абсолютний шлях до файлу журналу PostgreSQL. Конектор читає цей файл; він не виявляє файли журналів за конвенцією.
  • format — csvlog або jsonlog. За замовчуванням csvlog. Контролює парсер, який використовує конектор; він повинен відповідати log_destination, який PostgreSQL фактично записує.
  • follow — коли "true", безперервне відстеження файлу (потоковий режим). Це стосується лише jsonlog. Файл csvlog читається як пакет, тому що записи CSV можуть охоплювати кілька рядків, що робить потокове відстеження ненадійним. Див. Пакетний проти потокового нижче.
  • shared_accounts — через кому розділений список ролей PostgreSQL або значень application_name, які є пуловими або спільними серед кількох абонентів. Доступ, атрибутований до будь-якого з них, навмисно позначається як approximate. Див. Атрибуція та спільні облікові записи.

Не вигадуйте ключі конфігурації поза цими чотирма. Поверхня конфігурації конектора навмисно вузька — він читає файл журналу, він не керує PostgreSQL.

Атрибуція та спільні облікові записи

Карта доступу повинна відповісти “який агент це зробив.” Записи журналу pgAudit несуть роль PostgreSQL (користувач) та, коли встановлено, application_name сесії. Конектор використовує обидва для побудови джерела ребра.

Ідентифікація по кожному агенту заслуговує тверде ребро. Коли кожен агент встановлює окремий application_name на своєму з’єднанні (або використовує виділену роль), конектор атрибутує кожен доступ однозначно, і ребро є firm.

Спільні ролі зводяться до приблизної. Коли кілька агентів спільно використовують пул з’єднань, загальний сервісний обліковий запис або загальний application_name, конектор не може розділити абонентів. Кожен доступ через цю ідентичність позначається як approximate, і продукт говорить це відкрито, а не прикидається, що може розрізнити агентів, яких не може. Ось чому shared_accounts існує: оголошення пулових ідентичностей заздалегідь говорить конектору позначити їх як approximate негайно.

Наслідок для управління є прямим: ребро approximate не може підтримати твердий висновок найменших привілеїв. Якщо вам потрібне управління по кожному агенту за доступом до бази даних, видайте облікові дані або значення application_name по кожному агенту. Див. Точність для повної моделі атрибуції.

Рівень покриття

pgAudit має покриття рівня clean. Класи READ, WRITE та DDL є авторитетними — підсистема аудиту PostgreSQL класифікує запит, і конектор бере цю класифікацію дослівно. Немає виведення, парсингу SQL та евристик.

mode ребра є R (читання), RW (читання-запис, для класів WRITE та DDL), або залишається як диктує клас. Конектор ніколи не підвищує та не понижує те, що pgAudit повідомив. Див. Точність — покриття для того, як clean порівнюється з lossy та opaque джерелами.

Пакетний проти потокового

  • csvlog — пакетний. Записи CSV можуть охоплювати кілька рядків (запит із вбудованими переносами рядків створює багаторядковий запис), тому потокове відстеження не може надійно розділити записи. Конектор читає файл як повний пакет; встановіть poll_seconds на записі джерела для повторного запуску за інтервалом.
  • jsonlog з follow: "true" — потоковий. Кожен запис JSON — це один рядок, тому відстеження безпечне. Конектор тримає файл відкритим та генерує ребра, коли PostgreSQL їх записує.

Для ребер у майже реальному часі jsonlog з follow є рекомендованою конфігурацією. Для періодичних аудитів або баз даних з меншим навантаженням пакетний csvlog достатній.

Як виглядають ребра

Кожен запис журналу pgAudit, який конектор парсить, створює одне ребро карти доступу з такими полями:

  • Origin — роль PostgreSQL, кваліфікована application_name, коли присутній. Приклад: reporting_agent або app_pool/invoice-service.
  • Resource — повністю кваліфікований об’єкт: database.schema.table. Приклад: prod.public.orders.
  • Mode — R (з класу pgAudit READ) або RW (з класу pgAudit WRITE або DDL).
  • Attribution — firm, якщо джерело визначається до ідентичності одного агента, approximate, якщо відповідає запису shared_accounts або не може бути розрізнене.
  • Source — ідентифікує цей екземпляр конектора за назвою.

Ребро не несе тексту SQL, рядків даних та параметрів запиту. Воно записує лише структурний факт, що ідентичність отримала доступ до об’єкта у заданому режимі.

Операційні нотатки

Ротація журналів. Коли PostgreSQL ротує свій файл журналу (через log_rotation_age або log_rotation_size), конектор повинен бути спрямований на поточний файл. Якщо ваша ротація перейменовує активний файл, відстеження follow продовжить читати старий дескриптор файлу, поки він не вичерпається, і тоді зупиниться. Спрямуйте log_path на стабільний символічний посилання або використовуйте конвенцію іменування, яку конектор може відслідковувати. Конектор не керує ротацією сам.

Середовища з високим навантаженням. pgAudit може створювати значний обсяг журналів на завантажених базах даних, особливо з pgaudit.log = 'all'. Обмежте pgaudit.log класами, які вам потрібні (зазвичай read, write) та розгляньте фільтрацію по базі даних або по ролі через pgaudit.log_relation для зменшення шуму без втрати покриття.

Кілька екземплярів PostgreSQL. Кожен екземпляр потребує власного запису джерела в OLIVARES_SOURCES_CONFIG з окремим name та власним log_path. Немає автоматичного виявлення кількох екземплярів — кожне джерело спостерігає рівно один файл журналу.

Дозволи. Процес колектора потребує доступу на читання до файлу журналу PostgreSQL. Він не потребує з’єднання з базою даних, ролі PostgreSQL або будь-якого мережевого доступу до сервера бази даних. Дозвіл на читання файлової системи — єдина вимога.

Пов’язане

Пошук у документації