Русский
Русский
English
Статистика
Реклама

Этюд по реализации Row Level Secutity в PostgreSQL

В качестве дополнения к Этюд по реализация бизнес-логики на уровне хранимых функций PostgreSQL и в основном для развернутого ответа на комментарий.
Теоретическая часть отлично описана в документации Postgres Pro Политики защиты строк. Ниже рассмотрена практическая реализация маленькой конкретной бизнес задачи скрытия удаленных данных . Этюд посвященный реализации Ролевой модели с использованием RLS и бизнес-логики в хранимых процедурах будет представлен позже.
В статье ничего нового, нет скрытого смысла и тайных знаний. Просто зарисовка о практической реализации теоретической идеи. Если кому интересно читайте. Кому не интересно не тратьте свое время зря.


Постановка задачи

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

Ибо сказано Ничего не удаляй, только переименовывай. Интернет хранит ВСЁ

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

Для реализации данной концепции, таблица имеет атрибут is_deleted. Далее все просто необходимо сделать так, что бы клиент мог видеть только строки в которых атрибут is_deleted ложен. Для чего и используется механизм Row Level Security.

Реализация

Создаем отдельную роль и схему
CREATE ROLE repos;CREATE SCHEMA repos;

Создаем целевую таблицу
CREATE TABLE repos.file(...is_del BOOLEAN DEFAULT FALSE);CREATE SCHEMA repos

Включаем Row Level Security
ALTER TABLE repos.file  ENABLE ROW LEVEL SECURITY ;CREATE POLICY file_invisible_deleted  ON repos.file FOR ALL TO dba_role USING ( NOT is_deleted );GRANT ALL ON TABLE repos.file to dba_role ;GRANT USAGE ON SCHEMA repos TO dba_role ;


Сервисная функция-удаление строки в таблице
CREATE OR REPLACE repos.delete( curr_id repos.file.id%TYPE)RETURNS integer AS $$BEGIN...UPDATE repos.fileSET is_del = TRUE WHERE id = curr_id ; ...END$$ LANGUAGE plpgsql SECURITY DEFINER;


Бизнес функция-удаление документа
CREATE OR REPLACE business_functions.deleteDoc( doc_for_delete JSON )RETURNS JSON AS $$BEGIN...PERFORM  repos.delete( doc_id ) ;...END$$ LANGUAGE plpgsql SECURITY DEFINER;


Результаты

Клиент удаляет документ
SELECT business_functions.delCFile( (SELECT json_build_object( 'CId', 3 )) );

После удаления, клиент документа не видит
SELECT business_functions.getCFile"( (SELECT json_build_object( 'CId', 3 )) ) ;-----------------(0 rows)

Но в БД документ не удален, только изменен атрибут is_del
psql -d my_dbSELECT  id, name , is_deleted FROM repos.file ;id |  name  | is_deleted--+---------+------------ 1 |  test_1 | t(1 row)
Что и требовалось в постановке задачи.

Итог

Если тема будет интересна, в следующем этюде можно показать пример реализации ролевой модели разделения доступа к данным с использованием Row Level Security.
Источник: habr.com
К списку статей
Опубликовано: 20.08.2020 12:11:50
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Postgresql

Администрирование баз данных

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru