Подход к разделению схем (пользователей) при проектировании OLTP баз данных

Проблематика и назначение:


Разделение схем в основе своей реализуется для масштабируемости и безопасности:

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

Проблематика есть в том что если мы будем давать гранты на модификацию данных не владельцем таблиц (первичных данных), мы получаем пласт проблем:

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

Метод решения проблем:


Решение проблем с масштабируемостью/безопасностью/прозрачностью поведения системы нам поможет:

  • Инкапсуляция DML внутри схемы — всё управление транзакциями, а также DML операции осуществляется в рамках схемы-владельца таблицы.

Описание архитектуры предложенного метода:


image
Рисунок 1 — Взаимодействие схем между друг другом

Из рисунка видно, что схемы взаимодействуют между друг другом посредством GATE_PACKAGE или гейтовых пакетов.

Есть 2 типа гейтовых пакетов:

  • gate_package_in — для входящих запросов к схеме.
  • gate_package_out- для исходящих запросов из схемы в другую схему.

Все изменения данных осуществляются внутри схемы, прямого DML (insert, update, delete) обращения из чужой схемы (не владелице таблицы) к таблице не происходит.
Обращение из чужой схемы к любым методам/константам/типам и другим объектам также производится через гейтовые пакеты.

Такое взаимодействие позволяет иметь одну точку выхода и входа из/в схему, а в с случае разнесения схем в разные БД, мы получим следующую схему взаимодействия:

image

Рисунок 2 — Взаимодействие схем при разнесении их в разные БД.

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

image

Рисунок 3 — Схема раздачи грантов при взаимодействии 2х схем.

Из рисунка видно что мы запретили DML операции insert, update, delete, а также execute на объекты одной схемы в другую, кроме in_gate_package.

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

В идеале в дальнейшем запретить грант select относительно таблиц другой схемы и использовать только методы их гейтового пакета.

При таких подходах (рисунок 1, 2, 3), мы получаем:

  • Решение проблемы с масштабируемостью — Нет проблем при разнесении схем в разные БД.
  • Решение проблемы с безопасностью — запрет модификации данных и прямого обращения к методам/объектам для модификации первичны данных не владельцем этих данных.
  • Решение проблемы с прозрачность поведение системы — любая модификация данных происходит через одну входную/выходную точку в рамках одной схемы.
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 4
  • 0
    Вместо Grant select лучше создать view или mview и селектить с него. Меньше потом точок где dblink надо будет добавлять.
    • 0
      Обычно в таких случаях создаются синонимы на схеме куда даются гранты. Вьюхи и тем более мат.вьюхи нужны немного для другого ;)
    • 0
      Вюхи для масштабируемости — если в source изменили структуру данных, то при помощи view можно єто обойти.
      • 0
        Я тебя понял, идея действительно не плохая, таким образом отвяжемся от текущей структуры таблиц БД, согласен.

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