Как лучше хранить "секретную" инфу в базе
найди опен соурсе фтп (или другой проект) с управлением юзерами и ресурсами - там 70% нужного тебе будет в наличии
RBAC имеется в виду в виду или что другое? Если 1-е, то там нет практически ничего, что мне нужно. Я же грю - никаких админов.
Когда слепишь/найдешь/родишь - поделись, плс.
но проблемо, версия которая может кому то пригодится, собирался опен соурсом сделать, но многострочного ввода для шаблонов не будет, там нужен немного другой концепт UI. Хотя просто редактор поменять можно, но захочешь же из файла грузить.
Помню - не помню, прекращай эту ромашку
Не получится - встроено в оборудование 
Но смысла вопроса всё равно не понял 
А если половину может, не страшно?
Смысл вкладывался немного другой.
заводим двух админов, каждому свой ключ
где то так, для декодирования нужно иметь два ключа, которые известны только серверу и тому кто вводил.
Единственный путь получить ключи - "взлом" сервера.
паблик он для шифрования
по описанию, понялось по другому. Теперь даже и не знаю почему.
RBAC имеется в виду
-----
Или он, или что-то похожее.
там нет практически ничего
-----
Я так думаю, что тут ты ошибаешься.
Или, возможно, не сильно плотно занимался ролями и политиками.
По моим ощущениям там будет 80-90% тебе потребного. Ну заменить надо будет кое-что... но это лучше, чем писать все остальное.
там нужен немного другой концепт UI
-----
Ээээ... мне вообще ЮАЙ не нужен.
Мне нужно менеджерить доступ к файлам шаблонов и организовывать прозрачное управление.
Ну типа чел написал что-то и пользуется - уряяяя!!!
Потом чел считает, что может поделится с кем-то и своих коллег - еще уряяя!
А затем челу говорят - чо ты жмотишься в своей песочнице - дай всем!... Вот тут начинается вопрос то ли дать, то ли сначала назначить проверку/тестирование/акцептирование кем-то, кто в состоянии это сделать... причем, возможно, не одним и точно не синхронно... и условиеможет быть не одно... и не десяток... и настраиваться и меняться они должны после запуска системы.
У меня как-то так.
Аутентификация уже есть? Если нет, то все остальное нет смысла обсуждать
А в чём проблема то - каждый делает ее как хочет. Никакой связи не вижу
авторизация (ху может что)
не нужно абсолютно. Автор может читать и редактировать свою инфу. Также автор может раздавать ее группам, только для чтения. Группу можно создать свою и добавить туда пользователей. Если автор уже находится в другой группе он может и с ней поделится.
"Левых" пользователей в системы быть не может, а если и появится, то смысла в этом нет. Потому как Васю или Петю я или лично знаю или кто то другой.
Это в сторону p2p
Не заметил https://en.wikipedia.org/wiki/Peer-to-peer
Но это другое, это не связано с ресурсами.
не понял, вполне подходит
По моим ощущениям там будет 80-90% тебе потребного.
может тогда расскажешь что мне хочется иметь?
В упор не вижу, что может мне оттуда понадобится. Некому раздавать права и роли да и нет их в принципе.
Может ради каких то хотелок и нужно будет завести. А то вот хотят иерархическую каталогизацию инфы.
мне вообще ЮАЙ не нужен.
А ты собираешься нужные операции делать - из командной вебстроки?
Вот тут начинается вопрос то ли дать, то ли
нет у меня такой проблемы. Или раздаешь или нет. Но можешь решать кому - или сразу на выход или на тест или пусть сам решает что делать дальше.
У тебя есть группы с пользователями: или свои или чужие. Со своими делай, что хошь. В чужие можешь только добавить или удалить свою инфу.
авторизация (ху может что)
не нужно абсолютно.
------
У меня такое ощущение, что либо не формулируется, либо сложно и путается.
Потому что именно ЭТО описано ниже:
Автор может:
- читать и редактировать свою инфу.
- раздавать ее группам, только для чтения.
- создать свою группу и добавить туда пользователей.
- поделится с другой группой
И то что тебе надо аккуратный РБАК к которому можно прилепить шифрование.
Притом прилепить лучше всего внешним способом - т.е. запуская что-то стандартное... хммм... типа MSBUILD... для управления процессом. В другом случае оно станет не управляемо.
да и нет их в принципе.
------
Ну для начала у тебя есть две роли: Автор и Не_Автор
Сколько надо будет дополнительных - не знаю.
Кроме этого у тебя есть Группы. Не важно как они определяются, но отвечать на вопрос в Группе или нет кто-то должен.
Потому как если хочется без централизации, то будешь гонять ключи по юзерам и у них иметь раскодированные доки.
Т.е. гонять ключи ты не захочешь, а, следовательно, будет централизация и нужно будет как-то управлять...
из командной вебстроки?
------
Практически - да. Просто вместо вебстроки - ВЦС.
В чужие можешь только добавить или удалить свою инфу.
------
У меня так нельзя.
Потому как сильно опасно.
Вот ты хочешь поиметь на системе приличный кусок автоматически сгенерированного кода с удаленного источника, без гарантий что тебе не вдуют какой-нибудь вирус? Вооо! потому надо сильно подумать кому и что разрешать и как это делать... и потом переделать пару сотен раз пока не получится более-менее подходящее... переделывать при этом код совершенно не хочется...
Потому что именно ЭТО описано ниже:
ну вот возьмем для примера: https://en.wikipedia.org/wiki/Role-based_access_control
главное там - роли и разрешения
А теперь сравниваем одного автора с любым другим Автор может
Где видно другие роли или другие разрешения?
Если сильно повоображать можно придумать, что автор не может создавать группы - вот тебе и разрешение и нужен кто то кто будет эти разрешения давать и еще кто то кто будет управлять теми кто эти разрешения создает.
Вот тебе и роли и разрешения. Но в реальности этого нет. Хочешь создать группу, создавай, не хочешь не создавай. И т.п. У всех юзверей одна роль и один набор разрешений/правил.
Притом прилепить лучше всего внешним способом
как это - либой?
Ну для начала у тебя есть две роли: Автор и Не_Автор
это не роль из rbac-a. Ты не можешь переключить юзверю эти роли.
Если ты залогинился - ты автор, все остальные при этом "не авторы". Залогиненного и "не автор" быть просто не может.
но отвечать на вопрос в Группе или нет кто-то должен.
Если переходить на это уровень, то это просто запрос к базе
то будешь гонять ключи по юзерам
зачем? считаем https надежным протоколом. Конечно, можно тогда и админа считать "надежным", но так уж хотят что бы было.
вообще внешнее, управляемое на уровне хмл-скрипта.
никогда подобного не видел. 
Как это внешнее и как описание может чем то управлять? Это же просто как набор неких правил и соглашений.
Ну вот REST API внешнее, но причем здесь хмл? Вроде WCF его как его то пользует для описания данных.
он не создавал и может только лично пользовать что-то что ему дали.
Мы просто говорим о разных вещах.
Ролевое разграничение доступа позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования компьютерной системы правила разграничения доступа - https://ru.wikipedia.org/wiki/Упра�%...
То бишь, определил админ некие права доступа и присвоил их пользователю. После админ может их и изменить.
Иначе говоря - пользователь получает свою роль после логина. Теоретически она может изменится и во время сессии, но при этом кто то другой может отобрать или добавить права.
В нашем же случае - это просто состояние контейнера по отношению к пользователю, которое никак не может изменится.
Какие бы права пользователь бы не получил он никогда не сможет стать владельцем контейнера.
В подобных приложениях на RBAC делается совсем по другому. Админ создает контейнеры и затем для каждой роли определяет, что может может делать пользователь с папкой и с данными внутри нее.
Тогда мы имеем
- роль А для которой есть права доступа для контейнера Х: просмотр содержания, чтение и запись, добавить и удалить.
- роль НА для которой есть права доступа для контейнера Х1: просмотр содержания, чтение
- роль хА = А + НА
при этом роли типа хА должны быть сделаны для каждого пользователя и для всех имеющихся папок, что практически исключает ситуацию когда пользователь сам создает контейнер.
Вот пытался найти, что же хочется. Больше всего похоже на "Discretionary Access Control", хотя только с одной стороны
http://www.windowsecurity.com/uplarticle/2/Access_Control_...
А в чём проблема то - каждый делает ее как хочет. Никакой связи не вижу
Вы не можете их делать отдельно, поскольку от уровня безопасности аутентификации зависят все остальные уровни безопасности. Чтобы было понятно: если вы сделаете открытую систему, то дальше нет смысла говорить о шифровании. Если вы аутентифицируете через через ФБ, auth0 или gigya, то значит это определяет максимальную безопасность всей системы. Если вы делаете свой сервис аутентификации где-то в облаке, то значит у кого-то другого будет root, а значит вы зависите от этого другого чела. А если это сервис на вашем компе в гараже, то вся безопасность зависит от висячего замка на воротах.
не нужно абсолютно. Автор может читать и редактировать свою инфу. Также автор может раздавать ее группам, только для чтения.
Как это "не нужно", если это все собственно и есть авторизация. Если упрощенно:
Аутентификация это таблица <user id, secrets> - это вас не интересует, поэтому я предполагаю, что речь идет об игрушке
Авторизация это таблица: <user id, operation, resource id, разрешить/запретить> - здесь определяется кто-то что может делать с ресурсами, например, кто может прочитать только адрес, а кто еще и емейл.
не понял, вполне подходит
Строго говоря, сообщения не являются ресурсами, поскольку они посылаются, принимаются, и потом исчезают навсегда, а ресурс имеет перманентый идентификатор (ссылку). Поэтому как происходит e2e шифрование нас в этой ветке не интересует - мы обсуждаем разграничение доступа к ресурсам. Но в мессенджерах сообщения являются ресурсами. Тем не менее при
e2e шифровании сервер не хранит пароль, а потому не может читать сообщения - пароли передаются напрямую между пирами.
Ну в обще, пока не ясно какие требования к системе и в чем собственно состоит проблема. Классическое решение в том, чтобы либо использовать имеющиеся сервисы для аутентификации ну либо задплоить свой где-то в облаке. Далее определите формально пространство юзеров (идентификация типа емейл, группы, роли, другие связи, например, фоллоер), пространство ресурсов (идентификатор типа имя файла, структура типа директорий и т.п.), после чего реализуете сервис управления ресурсвами с ограничением доступа типа таблицы выше. И усе. Где здесь проблема?
Как это внешнее и как описание может чем то управлять?
-----
Во-первых - ты это видишь регулярно.
Во-вторых - один из вариантов я тебе чутка выше назвал.
Это же просто как набор неких правил и соглашений.
------
Угу-сь... вот только ты их можешь полностью поменять не меняя кода исполняющей системы.
Вроде WCF
-----
Перестань думать на уровне кода и включи архитектора.
Есть РБАС. У него ситуации пронумерованы. Вместо вызова метода на исполнительную систему отдается команда - выполнить по номеру. А что именно нужно выполнять по номеру лежит в хмл-е. как его интерпретировать - исполнительная система знает.
Есть желание - выполняй шифрацию/дешифрацию, нет - поменяй хмл и отдавай не дешифрованный контент... или вообще ничего не делай.
Попробую сформулировать проблему.
Задача 0 (мотивация).
Проблема. Есть вражеский сервис. Как можно там хранить свои файлы, если мы ему не доверяем? Зачем? Потому что он дешевый и там можно хранить большие файлы, а на моем компе места мало. Кроме того, он всегда доступен из любой точки.
Решение. Шифровать файлы при аплоаде, и дешифровать при скачивании. Ключ шифрования хранить на компе, на стике, или в голове.
Задача 1.
Проблема. Как расширить решение Задачи 0 на случай многих пользователей, каждый со своими файлами, которые они могут расшарить с другими пользователям. Пользователь может дать право на отдельый файл, а потом отозвать это право.
Общее решение. Просто считаем, что ключи каждого пользователя это и есть ресурс, которыми надо управлять. А потому задача сводится
к стандартной задаче управления и расшаривания ресурсов. Бери любое решение. Важно, что при отзыве/изменении прав доступа (к ключам) надо менять ключ и перешифровывать файлы. (Можно делать также при любом изменении самого файла.)
Примеры несколько более конкретных решений:
Решение 1: Централизованная система, которой мы доверяем
Решение 2: Каждый юзер управляет своими ключами и раздает их по запросу другим. Напрмер, через Телеграм e2e или емейл или API.
Если я правильно понял задачу, то вот оно и решение. Но как я уже упомянул, в любом случае надо будет удостоверять самих пользователей, например, личная встреча (с паспортом или тестом ДНК), подтверждение от 20 друзей, разгадывание загадок ну или внешняя система.
если вы сделаете открытую систему, то дальше нет смысла говорить о шифровании
совсем не обязательно.
Вот есть допустим, у меня хранилище в облаке, все могут иметь доступ к нему, но что мне мешает там хранить зашифрованные файлы?
Ну а тут просто два кубика - система и аутентификация. Каждый может использовать любой кубик аутентификации. Работа системы от этого никак не зависит, всё что системе нужно - это фиксированный ид пользователя. А как она его получит дело уже вторичное.
Авторизация это таблица: <user id, operation, resource id, разрешить/запретить> -
Это если рассматривать ее как динамическую и как кем то управляемую. А когда таблица полностью статическая, точнее её и создать нельзя в данном виде. Есть просто базовые правила, которые академики и могут назвать правила авторизации.
и потом исчезают навсегда
странно, открываю мессежер и вижу всё сообщения начиная с рождения аккаунта. Отчего не исчезли?
после чего реализуете сервис управления ресурсвами с ограничением доступа типа таблицы выше
ну вот сделайте мне таблицу доступа для следующего:
- зашел на сайт, создалась моя группа, пишу туда что хочу и редактирую как хочу.
- вижу другую группу, где я есть, могу туда кинуть/удалить ссылку на любую инфу из моей группы. Вижу там же все ссылки от других пользователей.
- создаю другую группу, добавляю/удаляю пользователей, шарю инфу из моей группы.
все тоже самое для другого пользователя и хотя бы еще десятка других.
А вопрос был в том, как удобнее всего шифровать инфу. Пока есть всего два решения:
- каждый пользователь имеет публик ключ на сервере и приватный ключ у себя на компе. Используем ассиметричное шифрование
- сервер имеет два ключа, используем симметричное шифрование
Есть еще варианты?