S>>Ну вот так и не выносим. Оракл является подробностью реализации этого "питонячьего сервиса" и ниоткуда больше не виден. Впрочем, это может быть и не оракл — "питонячьему сервису" с запасом может хватить sqlite. ·>Он виден с т.з. анализа безопасности.
Коллега, я немного запутался в вашей дискуссии, подскажи, я не ошибся, ты действительно топишь за обеспечение секьюрити данных на уровне БД?
Что передаете в БД в качестве субьекта авторизации? id юзера? Набор ролей? Есть ли роли, которые действуют на определенные сущности (например в этой организации юзер админ, а в этой простой гость)?
На каком языке пишете код правил доступа, сколько страниц текста он занимает, как его храните, ревьюите, тестируете, разворачиваете?
Как поступаете, если в какое-то поле юзер может писать только если это конкретный бизнес процесс со своими правилами, предусловиями и постусловиями? К примеру храним стейт из развесистой стейт-машины и от этого стейта зависит очень многое в плане можем писать/не можем писать. Как например будет выглядеть правило "посты редактируются редактором и корректором, никто, кроме суперадмина не может удалять ссылки и фотографии из опубликованного поста, заархивированный пост нельзя увидеть в ленте никому, но в админке его видят все сотрудники и суперадмин может его вернуть в ленту"?