Проблематика и назначение:
Разделение схем в основе своей реализуется для масштабируемости и безопасности:
- Масштабируемость с точки зрения баз данных должна быть такой, чтобы схему можно было вынести в другую базу без ущерба функционалу.
- Безопасность с точки зрения баз данных должна быть такой, чтобы внешние пользователи оперировали только бизнес логикой, к которой раздаются гранты, и не имели доступа к первичным данным.
Проблематика есть в том что если мы будем давать гранты на модификацию данных не владельцем таблиц (первичных данных), мы получаем пласт проблем:
- Проблема с масштабируемостью — нет возможность разнести схемы в разные бд.
- Проблема с безопасностью — при получении доступа к одной схеме, получаем доступ к первичным данным другой схемы.
- Проблема с прозрачностью поведения системы — Нет возможности понять откуда производится модификация данных схемы, что приводит к непредсказуемому поведению системы.
Метод решения проблем:
Решение проблем с масштабируемостью/безопасностью/прозрачностью поведения системы нам поможет:
- Инкапсуляция DML внутри схемы — всё управление транзакциями, а также DML операции осуществляется в рамках схемы-владельца таблицы.
Описание архитектуры предложенного метода:
Рисунок 1 — Взаимодействие схем между друг другом
Из рисунка видно, что схемы взаимодействуют между друг другом посредством GATE_PACKAGE или гейтовых пакетов.
Есть 2 типа гейтовых пакетов:
- gate_package_in — для входящих запросов к схеме.
- gate_package_out- для исходящих запросов из схемы в другую схему.
Все изменения данных осуществляются внутри схемы, прямого DML (insert, update, delete) обращения из чужой схемы (не владелице таблицы) к таблице не происходит.
Обращение из чужой схемы к любым методам/константам/типам и другим объектам также производится через гейтовые пакеты.
Такое взаимодействие позволяет иметь одну точку выхода и входа из/в схему, а в с случае разнесения схем в разные БД, мы получим следующую схему взаимодействия:
Рисунок 2 — Взаимодействие схем при разнесении их в разные БД.
Из рисунка видно, что при разнесении схем в разные БД у нас поддерживается принцип масштабирования, т.е. 2 схемы разнеслись в разные БД без ущерба основному функционалу.
Представим какие проблемы могли возникнуть при прямых DML из одной схемы в другую.
Ниже представлен рисунок раздачи грантов при взаимодействии 2х схем: поддержка текущей структуры масштабирования, безопасности, а также исключение неопределенности с точки зрения поведения системы:
Рисунок 3 — Схема раздачи грантов при взаимодействии 2х схем.
Из рисунка видно что мы запретили DML операции insert, update, delete, а также execute на объекты одной схемы в другую, кроме in_gate_package.
Разрешаем запуск из гейтовых пакетов, а также возможны запросы из табличек другой схемы, только в случае проблем с производительностью и необходимостью использования табличек в рамках больших запросов.
В идеале в дальнейшем запретить грант select относительно таблиц другой схемы и использовать только методы их гейтового пакета.
При таких подходах (рисунок 1, 2, 3), мы получаем:
- Решение проблемы с масштабируемостью — Нет проблем при разнесении схем в разные БД.
- Решение проблемы с безопасностью — запрет модификации данных и прямого обращения к методам/объектам для модификации первичны данных не владельцем этих данных.
- Решение проблемы с прозрачность поведение системы — любая модификация данных происходит через одну входную/выходную точку в рамках одной схемы.
Автор: Юрий Пухов
