Size: a a a

Архитектура ИТ-решений

2020 April 07

RR

Roman Roman in Архитектура ИТ-решений
Сергей Старцев
зависит от того, как вы работаете с сервисами.
Если с сервисами работает только сервер, то проще делать ограничение по IP или внутреннему фиксированному ключу/токену - тогда вопрос о пермишнах отпадает - система должна иметь полный доступ...
тут же опять вопрос - а что за сервисы, и на каком уровне по факту должна производиться проверка прав (пример - удаление объекта из БД можно проверять на уровне сервиса удаления... а можно и в интерфейсе сразу обрубать)
ну вот например, я должен делать запрос к сервис, тот в свою очередь от моег лица должен сходить в другой сервис что бы извлечь инфу дополнительную, но он в другом сервисе может быть "никем" и догда дэнай
источник

RR

Roman Roman in Архитектура ИТ-решений
это может быть полезно например когда я юрист в одном микросервисе и сотрудник в дром и когда я правлю документы юридические я могу получит дополнительную информацию о структуре предприятия и реквизит, либо не полуить если я там никто, тогда вводить руками
источник

СС

Сергей Старцев in Архитектура ИТ-решений
т.е. у вас система точка-точка - с каждый сервисом клиент работает напрямую ?
источник

RR

Roman Roman in Архитектура ИТ-решений
Sergey Lukin
роли не от микросервисов исходят, роли это от функции/задачи которую исполняет пользователь.
ценная мысль спасибо
источник

RR

Roman Roman in Архитектура ИТ-решений
Сергей Старцев
т.е. у вас система точка-точка - с каждый сервисом клиент работает напрямую ?
пока да, ну и потенциально все сервисы будут такими
источник

RR

Roman Roman in Архитектура ИТ-решений
походу еще вопросик, какая из UML диаграмм лучше всего опишет всзаимодействие между модулями, гэтвэем, сервисами, на тему безопасности ?
источник

SL

Sergey Lukin in Архитектура ИТ-решений
security viewpoint может включать несколько диаграмм (более того именно так и рекомендуется - несколько)
статика - например что где храниться
динамика - как происходит резолв прав
статика еще - где что задеплоено и в каких зонах с т.з. безопасности
источник

RR

Roman Roman in Архитектура ИТ-решений
Sergey Lukin
security viewpoint может включать несколько диаграмм (более того именно так и рекомендуется - несколько)
статика - например что где храниться
динамика - как происходит резолв прав
статика еще - где что задеплоено и в каких зонах с т.з. безопасности
ну вот динамику в чем лучше презентовать ?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Roman Roman
ну вот например, я должен делать запрос к сервис, тот в свою очередь от моег лица должен сходить в другой сервис что бы извлечь инфу дополнительную, но он в другом сервисе может быть "никем" и догда дэнай
Это не про пермишены, это про модель доступа. Она может быть на операции или на сущности.
Если на операции - то там все просто. А если на сущности - то есть tradeoff где фильтровать и контролировать - на gateway или на доменном сервисе. Оба варианта плохие )
Но начинать надо с описания модели доступа вообще, дальше будет уже проще.
источник

NK

Nikita Kiselev in Архитектура ИТ-решений
Это всегда большие накладные расходы
источник

NK

Nikita Kiselev in Архитектура ИТ-решений
где не фильтруй
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Обычно приходится изобретать разнообразные сложные компромиссы для проверки прав доступа к операциями  к сущностям.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, оно может быть по разному, зависит от задачи. Иногда можно и просто все сделать. Но редко (
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Тут надо торговаться с бизнесом, смотреть какие требования существенны, а какие нет и как это влияет на архитектуру.
источник

d

dreamore in Архитектура ИТ-решений
Phil Delgyado
Это не про пермишены, это про модель доступа. Она может быть на операции или на сущности.
Если на операции - то там все просто. А если на сущности - то есть tradeoff где фильтровать и контролировать - на gateway или на доменном сервисе. Оба варианта плохие )
Но начинать надо с описания модели доступа вообще, дальше будет уже проще.
я думал у меня одного модель доступа к данным (не действиям) болит
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Это у всех болит. Особенно когда есть сложная схема "прав владения данными", через оргструктуру и т.п.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Типа "начальник видит данные подчиненных, но не все", "сотрудник уходя в отпуск назначает заместителя" и прочие ужасы
источник

d

dreamore in Архитектура ИТ-решений
оно самое.... построить отчет, содержащий данные, доступ к которым есть у подразделения, в которое входит пользователь...
построить отчет - действие, тут просто. хочешь внутрь токена гранты, хочешь фильтруй на шлюзе
а вот дать доступ к одним данным и не дать к другим - котовасия
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Тут не удается обойтись только gateway, вся эта фигня начинает просачиваться вглубь модели данных (
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Поэтому я очень сомнительно отношусь к лозунгам "RBAC на gateway решит все ваши проблемы". Увы, но нет
источник