Обзор Postgres Pro Enterprise Manager

Postgres Pro Enterprise Manager (PPEM) — комплексное решение для администрирования инфраструктуры баз данных. PPEM предоставляет удобный интерфейс для управления и мониторинга СУБД PostgreSQL, включая редакции Postgres Pro Standard и Postgres Pro Enterprise.

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

Чтобы начать работу с PPEM, воспользуйтесь инструкцией Быстрый старт.

Подробнее о компонентах и функциональности PPEM читайте в разделах Архитектура и Возможности.

Информация о новых выпусках и обновлениях функциональности находится в разделе Что нового.

Больше информации о работе с PPEM вы найдете в следующий разделах:

Возможности

PPEM позволяет выполнять полный цикл задач развёртывания, эксплуатации и обслуживания баз данных PostgreSQL:

  • Автоматическое обнаружение экземпляров СУБД

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

  • Установка и запуск экземпляров СУБД

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

  • Конфигурирование экземпляров СУБД

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

  • Просмотр и управление внутренними объектами схемы СУБД

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

  • Отслеживание внутренней активности экземпляров СУБД

    PPEM взаимодействует с подсистемой статистики СУБД и предоставляет сведения о внутренней активности СУБД: активные и фоновые процессы, статистика выполнения запросов, ожидания и блокировки. Также с помощью PPEM можно отменять или принудительно завершать процессы СУБД.

  • Визуализация выполняющихся процессов и анализ планов запросов

    PPEM интегрируется с коллектором pgpro-otel-collector, который собирает статистику и журналы активности СУБД и предоставляет метрики. PPEM выступает потребителем этой телеметрии и предоставляет графики для оценки и анализа работы СУБД.

  • Профилирование и интеграция с pgpro_pwr

    PPEM интегрируется с pg_profile и pgpro_pwr, а также предоставляет удобный интерфейс для работы со снимками и отчётами.

  • Планирование, запуск и отслеживание работы регламентных операций

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

  • Обеспечение задач резервного копирования и восстановления

    PPEM может автоматически обнаруживать инструменты резервного копирования (pg_probackup), интегрироваться с ними и предоставлять средства просмотра и управления. С помощью PPEM можно выполнять как непосредственное, так и регулярное резервное копирование по расписанию, а также создавать новые экземпляры СУБД из резервных копий. Используя средства PITR (Point-in-Time Recovery), можно более гибко решать задачи восстановления из резервных копий.

  • Прямой доступ к консоли экземпляров СУБД

    PPEM позволяет подключаться к консоли экземпляра через web-psql. Этот инструмент PPEM предназначен для опытных экспертов-администраторов и позволяет оперативно подключиться и взаимодействовать с СУБД напрямую.

Архитектура

В этом разделе:

Описание компонентов

Архитектура PostgresPro Enterprise Manager включает следующие компоненты:

Веб-приложение

Веб-приложение — набор компонентов, которые обеспечивают пользовательский графический интерфейс, доступный через веб-браузер. Веб-приложение устанавливается на сервере с менеджером PPEM. Пользователь, используя браузер, выполняет различные действия, а веб-приложение преобразует эти действия в запросы и отправляет их менеджеру. Менеджер обрабатывает запросы и возвращает их веб-приложению. Веб-приложение преобразует ответ в различные представления и отображает в браузере.

Менеджер

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

Для выполнения операций могут потребоваться:

  • различные служебные данные, которые как правило (но необязательно), хранятся в репозитории PPEM;
  • выполнение инструкций на стороне агентов PPEM.

Выполнив операцию, менеджер сообщает результат операции веб-приложению.

ПРИМЕЧАНИЕ

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

Репозиторий

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

Агенты

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

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

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

Экземпляр СУБД

Экземпляр СУБД — это объект управления PPEM, то есть СУБД PostgreSQL в различных редакциях (Vanilla, Postgres Pro Standard/Enterprise). Несколько экземпляров СУБД могут объединяться в кластеры. Обычно это кластера потоковой репликации.

С отдельным экземпляром СУБД должен взаимодействовать только один агент PPEM. Не допускайте сценариев, когда несколько агентов работают с одним и тем же экземпляром СУБД, это может привести к путанице и неоднозначности поведения. С точки зрения экземпляра СУБД агент является обычным прикладным ПО, которое подключается к экземпляру через SQL-интерфейс, используя заранее определенную учетную запись СУБД.

Внешние сервисы

Для расширения функций и возможностей PPEM может использовать различные внешние сервисы. Все эти сервисы являются необязательными и взаимодействие с ними настраивается отдельно.

ПРИМЕЧАНИЕ

PPEM не содержит инструменты для административного управления внешними сервисами (например, управление ресурсами и настройкам).

Поддерживаются следующие внешние сервисы:

  • Каталог LDAP — каталог пользователей и групп, который может использоваться для аутентификации пользователей в PPEM. PPEM поддерживает работу с сервисами OpenLDAP и Microsoft ActiveDirectory.

  • S3-совместимое объектное хранилище — используется PPEM для размещения резервных копий, создаваемых инструментом pg_probackup.

Верхнеуровневая архитектура

Пример верхнеуровневой архитектуры и взаимодействия компонентов представлен на схеме ниже:

Архитектура PPEM

Где:

  • PPEM является сервисом по управлению инфраструктурой СУБД и состоит из следующих компонентов: веб-приложение, менеджер, репозиторий и агенты.
  • Отдельный экземпляр СУБД — объект управления PPEM, который представляет собой СУБД PostgreSQL в различных редакциях.
  • Кластер репликации — несколько экземпляров СУБД, объединенных в кластер. Обычно это кластера потоковой репликации.
  • Сервис идентификации пользователей и групп — каталог пользователей и групп, который может использоваться для аутентификации пользователей в PPEM. Необязательный внешний компонент.
  • S3-совместимое объектное хранилище — система для хранения резервных, копий сделанных с помощью pg_probackup. Необязательный внешний компонент.

Архитектура менеджера и агента

Пример архитектуры и взаимодействия менеджера и агента представлен на схеме ниже:

Архитектура менеджера и агента

Где:

  • Пользователь может работать с PPEM как через веб-приложение в браузере, так и через инструменты автоматизации (IaC), которые могут взаимодействовать с PPEM через REST API.
  • В PPEM основным графическим интерфейсом пользователя является веб-приложение. Веб-приложение тесно связано с менеджером — оттуда веб-приложение получает данные и отправляет управляющие команды от пользователя. Менеджер предоставляет API для получения данных и управления инфраструктурой СУБД. Менеджер хранит промежуточное состояние инфраструктуры в базе репозитория и взаимодействует с агентом, который управляет экземпляром СУБД.
  • Операционная система — это рабочее окружение, в котором запущены экземпляр СУБД и агент PPEM. Агент взаимодействует с менеджером: отправляет ему данные об окружении (информация об ОС и экземплярах СУБД) и принимает управляющие команды.

Архитектура мониторинга

Для обеспечения функций мониторинга в контексте работы с Метриками и Журналами (далее — Телеметрия) PPEM использует коллектор pgpro-otel-collector от Postgres Pro.

Для работы с телеметрией используется внутреннее хранилище в базе данных репозитория — метрики хранятся в отдельной схеме monitoring, журналы — в схеме logs.

Обязательным компонентом является коллектор pgpro-otel-collector. Коллектор обеспечивает сбор статистики и журналов, генерацию данных телеметрии и, в зависимости от выбранного режима, экспорт данных менеджеру или во внешнюю систему хранения.

Пример архитектуры мониторинга при использовании внутреннего хранилища представлен на схеме ниже:

Архитектура мониторинга. Внутреннее хранилище

Где:

  • Пользователь работает с PPEM через веб-приложение в браузере, где просматривает графики по метрикам и журналам.
  • В PPEM хранилищем метрик и журналов является репозиторий. Менеджер получает метрики и журналы от коллектора и сохраняет их в базах данных репозитория, а также запрашивает метрики и журналы из баз данных репозитория и отдает их потребителю через REST API. Веб-приложение запрашивает у менеджера метрики и журналы и затем визуализирует полученные данные.
  • В операционной системе коллектор pgpro-otel-collector подключается к экземпляру СУБД для получения метрик, читает файлы журналов СУБД, обрабатывает полученные данные и через REST API отправляет менеджеру. Агент является отдельным компонентом, выполняет управляющие функции и не занимается сбором метрик и журналов.

Архитектура резервного копирования

Пример архитектуры резервного копирования представлен на схеме ниже:

Архитектура резервного копирования

Где:

  • Пользователь через веб-приложение использует функции резервного копирования и восстановления.
  • В PPEM веб-приложение отправляет запросы к менеджеру. Менеджер отправляет запросы на резервное копирование и восстановление агентам.
  • В операционной системе агенты выполняют резервное копирование или восстановление с помощью утилиты pg_probackup. Резервное копия может быть сохранена как в локальный каталог, так и в S3-совместимое объектное хранилище. Каталог резервный копий должен быть предварительно подготовлен для работы с pg_probackup.В случае восстановления резервная копии может быть получена как из локального каталога, так и из объектного хранилища.
  • S3-совместимое объектное хранилище является внешним сервисом. Поддержка работы с конкретными объектными хранилищами обеспечивается средствами `pg_probackup и не зависит от PPEM.

Аппаратные и программные требования

В этом разделе приведены аппаратные и программные требования для обеспечения работы PPEM, а также информация по расчёту ресурсов при масштабировании СУБД.

Минимальные аппаратные и программные требования

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

В качестве сервера может выступать:

  • аппаратный (bare metal) сервер;
  • виртуальная машина на базе виртуализации Xen/KVM/VMWare;
  • контейнерная среда в привелигированном режиме.

ВАЖНО!

Использование PPEM при соблюдении минимальных требований не обеспечивает отказоустойчивость и рекомендуется только в пилотных или экспериментальных проектах, в средах с невысокой нагрузкой, без требований высокой доступности и отказоустойчивости.

Для менеджера:

Один сервер следующей минимальной конфигурации:

Для агента:

Один сервер следующей минимальной конфигурации:

Расчёт ресурсов

Для менеджера:

Требуемые ресурсы для менеджера на 10 экземпляров СУБД с 10 тыс. объектов в отдельном экземпляре:

  • CPU — 2 шт.
  • RAM — 2 ГБ
  • SSD — 40 ГБ

Минимальная конфигурация сервера, где будет размещен менеджер (до 10 экземпляров с 10 тыс. объектов в отдельном экземпляре):

  • CPU — 2 шт.
  • RAM — 4 ГБ
  • SSD — 40 ГБ

Расчетная таблица:

Количество экземпляровCPU, шт.RAM, ГБSSD, ГБ
102440
3041280
70828160
1501660320
2302492480
31032124640

Для агента:

Требуемые ресурсы для агента на 1 экземпляр СУБД (до 100 тыс. объектов в экземпляре):

  • CPU — 1 шт.
  • RAM — 512 МБ
  • SSD — 20 ГБ

Минимальная конфигурация сервера с экземпляром СУБД, где будет размещен агент PPEM (до 100 тыс. объектов в экземпляре):

  • CPU — 2 шт.
  • RAM — 2 ГБ
  • SSD — 20 ГБ

Расчетная таблица:

Количество объектов СУБДCPU, шт.RAM, ГБSSD, ГБ
100 тыс.2210
200 тыс.3420
400 тыс.4820

Поддержка платформ и ОС

Менеджер и агент PPEM поддерживают установку на операционные системы семейства Linux на платформе x86_64.

PPEM поддерживает установку и работу на следующих дистрибутивах Linux:

  • ALT Linux 10
  • ALT Linux 11
  • ALT Linux СП 10
  • Astra Smolensk 1.7
  • Astra Smolensk 1.8
  • Debian 11
  • Debian 12
  • RedOS 7.3
  • RedOS 8.2
  • RedHat Enterprise Linux 8
  • RedHat Enterprise Linux 9
  • ROSA 2021.1
  • Suse Linux Enterprise Server 15
  • Ubuntu 20.04
  • Ubuntu 22.04
  • Ubuntu 24.04

ПРИМЕЧАНИЕ

Работа PPEM c дистрибутивами, отличными от вышеперечисленных, не тестировалась и нормальная работа PPEM на них не гарантируется.

Работа PPEM на платформах, отличных от x86_64, не тестировалась и нормальная работа PPEM на них не гарантируется.

Совместимость

Совместимость с PostgreSQL

Менеджер PPEM поддерживает следующие версии PostgreSQL, включая редакции PostgresPro Standard и PostgresPro Enterprise:

  • 17
  • 16
  • 15
  • 14

Агент PPEM поддерживает следующие версии PostgreSQL, включая редакции PostgresPro Standard и PostgresPro Enterprise:

  • 17
  • 16
  • 15
  • 14
  • 13
  • 12

Совместимость с pg_probackup

Агент PPEM поддерживает следующие версии pg_probackup, включая редакции Standard и Enterprise:

  • 2.8

Совместимость с pgpro-otel-collector

Агент PPEM поддерживает следующие версии pgpro-otel-collector:

  • 0.3

Совместимость с браузерами

Для оптимального пользовательского опыта при работе в веб-приложении PPEM рекомендуется:

  • Использование экрана с минимальным разрешением 1280x720. Рекомендуется использовать разрешение 1440х900 и выше.
  • Использование следующих интернет-браузеров:
    • Chrome 87+
    • Firefox 85+
    • Opera 73+
    • Safari 14+

Безопасность

Менеджер и агент

Менеджер является обычным прикладным ПО и не требует привилегированного доступа к функциям операционной системы. Служба менеджера может полноценно функционировать при запуске от имени непривилегированного системного пользователя.

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

  • с правом LOGIN к экземпляру;
  • с правом подключения к базе данных, которая будет репозиторием;
  • являющийся владельцем этой базы данных;
  • без ограничений прав доступа внутри этой базы данных (для выполнения миграций в схеме данных).

Агент является обычным прикладным ПО, для полноценной работы которого требуется:

  • доступ к функциям операционной системы;
  • доступ к управляемому экземпляру СУБД.

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

Доступ к управляемому экземпляру СУБД можно разделить на две части:

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

    ПРИМЕЧАНИЕ

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

  • Доступ к SQL-интерфейсу экземпляра СУБД, для которого агенту требуется пользователь СУБД:

    • с правом LOGIN к экземпляру;
    • с правом подключения ко всем базам данных экземпляра;
    • являющийся членом ролей pg_monitor, pg_signal_backend.

Сетевое взаимодействие

Сетевое взаимодействие между менеджером и агентом может инициироваться обеими сторонами:

  • Менеджер может отправлять управляющие инструкции агентам, агенты в ответ отправляют результаты выполнения инструкций.
  • Агенты могут отправлять менеджеру запросы на регистрацию самих себя и экземпляров СУБД, запросы на обновление состояния экземпляров, а менеджер должен отправить агенту ответ на запрос.

Менеджер и агент для общения используют протокол HTTP(S). Менеджер по умолчанию использует порт tcp/8080, агент использует по умолчанию порт tcp/8081. Такое направление трафика следует учитывать при настройке правил сетевого доступа. Настройки адресов и портов задаются в основных файлах конфигурации менеджера и агента.

Для безопасной передачи данных рекомендуется использовать настройки TLS.

Аутентификация между пользователями и менеджером

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

  • Встроенными средствами PPEM
  • Через внешний каталог LDAP (OpenLDAP или Microsoft ActiveDirectory)

В случае использования встроенных средств PPEM данные о пользователях и группах хранятся в репозитории и управляются администратором PPEM. В случае использования внешнего каталога менеджер должен быть настроен на работу с этим каталогом. Все данные о пользователях и группах хранятся во внешнем каталоге и управляются отдельным администратором каталога LDAP.

Аутентификация между менеджером и агентами

API менеджера и агента защищено авторизацией. Для выполнения запросов к API менеджер и агент выполняют взаимную аутентификации и выдают токены доступа для последующей авторизации. Токены имеют ограниченное время жизни — менеджер и агенты самостоятельно отслеживают срок действия токенов и обновляют их при необходимости.

Ролевая модель доступа (RBAC)

Основные положения

Управление доступом в PPEM реализуется RBAC-моделью (Role Based Access Control), которая определяет правила разграничения доступа с помощью ролей и привилегий. Модель устанавливает следующие базовые соглашения:

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

Базовые соглашения определяют расширенные соглашения:

  • правило доступа — совокупность роли, привилегий и связей между этими ролью и привилегиями;
  • сеанс — соответствие между субъектом и ролью;
  • один субъект может иметь несколько ролей;
  • одну роль могут иметь несколько субъектов;
  • одна роль может иметь несколько привилегий;
  • одна привилегия может принадлежать нескольким ролям.

ВАЖНО!

Привилегии не назначаются субъектам напрямую, а приобретаются субъектами только через роли.

RBAC в PPEM

Базовые утверждения:

  • Функциональность PPEM состоит из плагинов.

  • Каждый плагин позволяет управлять конкретным ресурсом.

  • Управление ресурсом включает в себя базовые CRUD-операции: create, view, edit, delete.

  • Дополнительно управление ресурсом может включать в себя различные RPC-операции, их имена зависят от операции по управлению ресурсом.

  • Доступ субъекта к различным операциям определяется привилегиями.

    Таким образом, управление любым ресурсом управляется привилегиями (базовый минимум):

    • _create
    • _view
    • _edit
    • _delete

  • Привилегии включаются в роли.

  • Роли могут назначаться субъекту как в момент создания субъекта, так и позже.

  • При получении от субъекта запроса на выполнение операции плагин проверяет право субъекта на доступ к запрошенной операции.

  • Субъекты (пользователи) могут создавать собственные роли (при наличии прав) и назначать эти роли другим субъектам (пользователям).

  • Привилегии и роли могут быть объектно-привязанными. Это означает, что можно указать роль и привилегию, разрешающую доступ к ограниченному множеству объектов.

  • Привязка к объекту может осуществляться на уровне роли (все субъекты с этой ролью имеют доступ к объекту) или на уровне пользователя (доступ к объекту имеет только один пользователь).

Субъекты

Субъектами могут выступать:

  • Пользователи. Роли назначаются на пользователей в момент создания. Если роли не указаны явно, может быть назначена роль по умолчанию.
  • Агенты. Роль назначается при создании или регистрации агента.
Объекты

Объектами могут выступать как ресурсы, так и представления ресурсов в репозитории, например: сервера, агенты, экземпляры СУБД, пользователи PPEM, группы PPEM и т.п.

Установка привилегий и ролей

При первом запуске PPEM выполняется инициализация репозитория, при которой заполняются служебные таблицы (привилегии и роли). При инициализации для каждого плагина устанавливается свой набор привилегий, ролей и отношений "роль-привилегия". Так, например, для плагина accounts создаются свои привилегии и роли для управления доступом к объектам этого плагина. Так и для других плагинов создаются свои наборы привилегий и ролей для управления доступом к объектам этих плагинов.

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

Реализация

Права доступа реализованы следующим набором таблиц (принадлежат плагину accounts):

  • privileges — привилегии с указанием класса объектов, к которым они регулируют доступ;
  • roles — роли с указанием класса объектов, на которые нацелена роль;
  • role_privileges — отношение типа "роль-привилегия", устанавливает связь между ролью и входящими в нее привилегиями;
  • users — пользователи системы (субъекты);
  • user_roles — отношение типа "пользователь-роль", устанавливает связь между пользователем и назначенными на него ролями;
  • user_privileges — представление (view), отображающее связи "пользователь-привилегия";
  • groups — группы системы;
  • group_roles — отношение типа "группа - роль", устанавливает связь между группой и назначенными на нее ролями;
  • group_users — отношение типа "группа-пользователь", устанавливает связь между группой и входящими в нее пользователями.
Таблица privileges

Таблица имеет следующие поля:

  • id — уникальный идентификатор привилегии.
  • name — уникальное имя привилегии.
  • title — человекопонятное описание привилегии;
  • class — определяет класс объектов, для доступа к которым используется привилегия.
  • source — имя плагина, который устанавливает привилегию и в дальнейшем осуществляет проверку доступа.

Таблица заполняется менеджером PPEM с помощью миграций. Каждый плагин определяет собственный набор привилегий. Для проверки привилегий используется HTTP middleware-обработчик. Создание, изменение и удаление привилегий пользователем не предусмотрено, так как проверка привилегий реализуется в коде менеджера PPEM.

Таблица roles

Таблица имеет следующие поля:

  • id — уникальный идентификатор роли.
  • name — уникальное имя роли.
  • title — человекопонятное описание роли.
  • class — определяет класс объектов, для доступа к которым используется эта привилегия. Значение поля используется как подсказка для UI, чтобы получить привилегии соответствующего класса и список объектов этого класса;
  • source text — имя плагина, который устанавливает роль, в случае пользовательских ролей устанавливается значение user.

Роли создаются менеджером с помощью миграций. Базовый набор ролей устанавливается для плагина accounts. Пользователь через API менеджера может создавать, изменять и удалять пользовательские роли, но не может изменять или удалять роли установленные менеджером PPEM (системные роли).

Таблица role_privileges

Таблица устанавливает отношения между ролями и привилегиями и имеет следующие поля:

  • id — уникальный идентификатор отношения.
  • role — указывает на идентификатор роли.
  • privilege — указывает на идентификатор привилегии.
  • parametric — флаг, указывающий на использования привязки к объекту.
  • object — указывает на уникальный идентификатор объекта произвольного класса. Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие привилегии, указанной в role_privileges.privilege, одним объектом, и разрешает доступ к объекту только участникам одной роли, указанной в role_privileges.role (доступ разрешён пользователям в user_roles.user, у которых user_roles.role = role_privileges.role).

Комбинация (role,privilege,object) является уникальным ключом с условием object IS NOT NULL.

ПРИМЕЧАНИЕ

"Параметризованное" объектно-привязанное отношение "роль-привилегия" определяет доступ только к одному объекту (через указание object). При необходимости выдать доступ на N объектов будет создано N записей в role_privileges.

Таблица users

Таблица не имеет полей, имеющих отношение к RBAC.

При создании пользователя через API менеджера можно указать список идентификаторов ролей, которые будут назначены пользователю.

Таблица user_roles

Таблица устанавливает отношения между пользователем и ролями и имеет следующие поля:

  • id — уникальный идентификатор отношения.
  • user — указывает на идентификатор пользователя.
  • role — указывает на идентификатор роли.
  • object — указывает на уникальный идентификатор объекта произвольного класса. Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие привилегии, указанной в role_privileges.privilege, одним объектом и разрешает доступ к объекту пользователю, указанному в user_roles.user.

ПРИМЕЧАНИЕ

"Параметризованное" объектно-привязанное отношение "пользователь-роль" определяет доступ только к одному объекту (через указание object). При необходимости выдать доступ на N объектов будет создано N записей в user_roles.

Представление user_privileges

Предлагает удобный способ определения, какие роли и привилегии есть у пользователей. Представление используется для упрощения проверки привилегий у субъекта-пользователя:

  • user — user_roles.user
  • role — user_roles.role
  • privilege — privilege.name
  • object — user_roles.objects или role_privileges.object
Таблица groups

Таблица не имеет полей, имеющих отношение к RBAC.

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

Таблица group_roles

Таблица устанавливает отношения между группами и ролями и имеет следующие поля:

  • group_id — указывает на идентификатор группы.
  • role_id — указывает на идентификатор роли.
  • object — указывает на уникальный идентификатор объекта произвольного класса. Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие привилегии указанной в role_privileges.privilege одним объектом и разрешает доступ к объекту пользователю, указанному в group_roles.role_id.

ПРИМЕЧАНИЕ

"Параметризованное" объектно-привязанное отношение "группа-роль" определяет доступ только к одному объекту (через указание object). При необходимости выдать доступ на N объектов будет создано N записей в group_roles.

Таблица group_users

Таблица устанавливает отношения между группами и пользователями и имеет следующие поля:

  • group_id — указывает на идентификатор группы.
  • user_id — указывает на идентификатор пользователя.

Отношения "группа-пользователь" не имеют объектных привязок.

Объектно-связанные роли

В общем случае предполагается, что роли могут включать в себя привилегии, которые разрешают доступ ко всем объектам любого класса.

Для еще большей гранулярности выдачи прав доступа вместе с классом можно указать и идентификатор объекта в role_privileges.object. Так, действие роли и привилегии будет распространяться только на объект с указанным идентификатором. Объект можно указать в нескольких местах:

  • для роли в role_privileges.object, тогда все члены роли смогут получить доступ к объекту;
  • для пользователя в user_roles.object, тогда доступ будет предоставлен только для одного пользователя;
  • для группы в group_roles.object, тогда доступ будет предоставлен только для пользователей группы.

Проверка прав доступа у субъекта

В процессе аутентификации субъекта выполняется создание сеанса и создание сессионных JWT-токенов. При создании access-токена в него вкладывается user_id. Пользователь, выполняя запросы на выполнение операций, прикладывает access-токен в заголовки запроса. Менеджер выполняет авторизацию, извлекает из access-токена user_id пользователя и через роли проверяет наличие необходимой привилегии. Если привилегия доступна, то доступ разрешается, если привилегии нет, запрос отклоняется.

Более подробно:

Для проверки, что субъект имеет право доступа на выполнение операции над объектом нужны:

  • user_id или agent_id — идентификатор пользователя или агента;
  • class — имя класса для объекта (по сути это тип ресурса);
  • object — идентификатор объекта (опционально).

Клиент в запросе указывает заголовок Authorization: Bearer и прикладывает access-токен.

Сервер получает запрос и извлекает данные, необходимые для проверки доступа:

  • Значение user_id (или agent_id) извлекается из access-токена.
  • Значение class определяется на основе привилегии.
  • Значения object:
    • для GET-запросов вида /resources извлекается из URL пути и параметров запроса (ids=?);
    • для GET-запросов вида /resources/objectID извлекается из URL пути;
    • для PUT-запросов извлекается из тела запроса;
    • для DELETE-запросов вида /resources извлекается из тела запросов (отдельное поле в объекте).

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

Проверка выполняется через репозиторий и представление user_privileges.

Особенности и ограничения

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