русский
Germany.ruForen → Архив Досок→ Programmierung

Как лучше хранить "секретную" инфу в базе

02.06.23 23:33
Re: Как лучше хранить "секретную" инфу в базе
 
Бесконечный цикл завсегдатай
in Antwort AlexNek 31.05.23 22:42
А в чём проблема то - каждый делает ее как хочет. Никакой связи не вижу

Вы не можете их делать отдельно, поскольку от уровня безопасности аутентификации зависят все остальные уровни безопасности. Чтобы было понятно: если вы сделаете открытую систему, то дальше нет смысла говорить о шифровании. Если вы аутентифицируете через через ФБ, auth0 или gigya, то значит это определяет максимальную безопасность всей системы. Если вы делаете свой сервис аутентификации где-то в облаке, то значит у кого-то другого будет root, а значит вы зависите от этого другого чела. А если это сервис на вашем компе в гараже, то вся безопасность зависит от висячего замка на воротах.


не нужно абсолютно. Автор может читать и редактировать свою инфу. Также автор может раздавать ее группам, только для чтения.

Как это "не нужно", если это все собственно и есть авторизация. Если упрощенно:


Аутентификация это таблица <user id, secrets> - это вас не интересует, поэтому я предполагаю, что речь идет об игрушке


Авторизация это таблица: <user id, operation, resource id, разрешить/запретить> - здесь определяется кто-то что может делать с ресурсами, например, кто может прочитать только адрес, а кто еще и емейл.


не понял, вполне подходит

Строго говоря, сообщения не являются ресурсами, поскольку они посылаются, принимаются, и потом исчезают навсегда, а ресурс имеет перманентый идентификатор (ссылку). Поэтому как происходит e2e шифрование нас в этой ветке не интересует - мы обсуждаем разграничение доступа к ресурсам. Но в мессенджерах сообщения являются ресурсами. Тем не менее при e2e шифровании сервер не хранит пароль, а потому не может читать сообщения - пароли передаются напрямую между пирами.


Ну в обще, пока не ясно какие требования к системе и в чем собственно состоит проблема. Классическое решение в том, чтобы либо использовать имеющиеся сервисы для аутентификации ну либо задплоить свой где-то в облаке. Далее определите формально пространство юзеров (идентификация типа емейл, группы, роли, другие связи, например, фоллоер), пространство ресурсов (идентификатор типа имя файла, структура типа директорий и т.п.), после чего реализуете сервис управления ресурсвами с ограничением доступа типа таблицы выше. И усе. Где здесь проблема?

 

Sprung zu