Здравствуйте, Ziaw, Вы писали:

S>>>Ну вот так и не выносим. Оракл является подробностью реализации этого "питонячьего сервиса" и ниоткуда больше не виден. Впрочем, это может быть и не оракл — "питонячьему сервису" с запасом может хватить sqlite.
Z>·>Он виден с т.з. анализа безопасности.
Z>Коллега, я немного запутался в вашей дискуссии, подскажи, я не ошибся, ты действительно топишь за обеспечение секьюрити данных на уровне БД?
Если в том смысле, что используются средства БД типа как встроенные механизмы row level security, аккаунты в самой бд, вьюшки и т.п. (о чём писал Sinclair) — то нет.

Z>Что передаете в БД в качестве субьекта авторизации? id юзера? Набор ролей? Есть ли роли, которые действуют на определенные сущности (например в этой организации юзер админ, а в этой простой гость)?
В бд формируются запросы в зависимости от пермиссий... Т.е. это просто ещё как бы один критерий поиска, как тут Константин Л писал.

Z>На каком языке пишете код правил доступа, сколько страниц текста он занимает, как его храните, ревьюите, тестируете, разворачиваете?
На оснвном ЯП, обычно java, как и любой другой код.

Z>Как поступаете, если в какое-то поле юзер может писать только если это конкретный бизнес процесс со своими правилами, предусловиями и постусловиями? К примеру храним стейт из развесистой стейт-машины и от этого стейта зависит очень многое в плане можем писать/не можем писать. Как например будет выглядеть правило "посты редактируются редактором и корректором, никто, кроме суперадмина не может удалять ссылки и фотографии из опубликованного поста, заархивированный пост нельзя увидеть в ленте никому, но в админке его видят все сотрудники и суперадмин может его вернуть в ленту"?
Это же несколько независимых правил.
Отдельно есть пермиссии "редактирование поста", "удаление ссылок", "удаление фот", "просмотр архива" и т.п. И отдельно роли: "редактор", "корректор", "админ", "суперадмин"... и маппинг — что какая роль может.