создаём третий ключ, админский и шифруем все ЗКР. Дальше два варианта...

Не, немного сложнее. Ведь пользователь, у которого отозвали доступ, мог где-то сохранить расшифрованный КР. Рано или поздно придётся перевыпустить КР, к которому отозван допуск. И для всех пользователей, у которых был доступ к ресурсу перевыпускаем ЗКР. И тут приходим к мысли что асимметричные ключи рулят. Зашифровать можем и без пользователя.

где шифровать будем?

Только на клиентских. И тогла нам надо какое-то время хранить расшифрованный КР. Или... Асимметричные ключи спешат на помощь!

Кроме того, как пользователь А сможет расшарить часть своего ресурса?

Никак. Создаем новый ресурс. Ну и не забываем что так шифровать чтоб прям никто кроме польщователя не мог прочитать надо редко и немного. А то тот же поиск по такому зашифрованному не работает.

Спасибо, но не нужно. Уже есть и для данного случая совершенно не подходит.

В общем мы изобретаем не просто велосипед. Мы изобретаем велосипед который будет крепиться на крыше машины, и которым можно будет управлять при помощи различных костылей, потому как универсального крепления для нашего велосипеда нет.

неважно кому. И базы вытягивают и файлы.

Это плохо. Если кто угодно может вытягивать любые базы и файлы не имея рута, лучше с такой системой не связываться.

Ведь пользователь, у которого отозвали доступ, мог где-то сохранить расшифрованный КР.

Где он его возьмёт? Пользователь должен видеть только свой ключ и зашифрованный им и админским ключем ключ ресурса.

Хотя да, ключ пользователя тогда действительно не нужен, но как сделать, чтобы админ не смог добраться до данных загадка

Ассиметричные ключи конечно великая вещь, но в данном случае всем достаточно и публичного ключа. Цель ведь не создать новый ключ, а прочитать данные

В общем мы изобретаем не просто велосипед

К сожалению, на предложенном вами велосипеде неудобно будет ехать от Дрездена до Берлина.

Кроме встроенного RBAC на уровне системы, там нет больше ничего полезного.

лучше с такой системой не связываться

ну расскажите это всем тем кого это уже задело или заденет.

https://habr.com/ru/articles/535856/

но как сделать, чтобы админ не смог добраться до данных загадка

уже сказали - не следует иметь только один ключ, который вводит один админ.

Хотя да, можно взломать любую систему. Но в данном случае есть достаточно простое правило - ни один человек легально не имеет права прочитать все данные.

Где он его возьмёт? Пользователь должен видеть только свой ключ и зашифрованный им и админским ключем ключ ресурса.

Где-где. Раскодирует из ЗРК. Ни хранилище ресурсов, ни хранилище ЗКР не расшифровывают ресурсы / ключи. Они только хранят и отдают зашифрованное.

Расшифровка происходит на клиенте. И никаких админских ключей.

наполовину

А так?

Действующие лица: пользователь А Па, пользователь Б Пб. Ресурс Р1. Хранилище зашифрованных ресурсов ХР, хранилище зашифрованных ключей ХК.

Публичный ключ Па: ПубКПа, приватный: ПривКПа. (аналогично для Б)

Ключ Р1: КР1 (а тут пусть будет пока синхронное)

Па: хочу создать жутко секретную запись с телефоном любовницы Р1. Жмакает кнопку на клиенте.

Клиент: бляааа... Эй, ХР, у тебя ресурс Р1 есть?

ХР: не-а

Клиент: да что б ему... Делает новый КР1, шифрует КР1 в ЗКР1_a. Эй, ХК сохрани новый ключ для ресурса Р1, для пользователя Па.

ХК: да пажалста (Па известен системе). Сохраняет ЗКР1_а

Клиент: Так, юзер, вводи свои данные.

Па: вот

Клиент: шифрует Р1 ключом КР1, эй, ХР, сохрани-ка ресурс. Владелец: Па. Передаёт ЗР1 на ХР.

ХР: ок, сохранил.

Клиент: забывает КР1, ЗКР1_а, ЗР1 и Р1. Э, юзер, всё сохранил!

Па: надо дружбану показать, по приколу. Слышь, клиент, расшарь телефон Р1 с Пб.

Клиент: ХК, ты Пб знаешь? Дай его публичный ключ.

ХК: на. Возвращает ПубКПб

Клиент. Ага. И ЗКР1_а тоже дай.

ХК: на

Клиент: юзер, вводи свой сверхсекретный ПривКПа. Смотри, не ошибись.

Па: 1234

Клиент: угу. Расшифровывает ЗКР1_а, получает КР1. Берёт ПубКПб и делает ЗКР1_б. ХК, получи ключ.

ХК: ЗКР1_б сохранён

Всё. Теперь Пб сможет тоже прочитать или записать Р1. Аутентификацию и авторизацию пока не рассматриваем.

А так?

Да один фиг, нужно еще всё расшифровать типа подобное "Клиент: забывает КР1, ЗКР1_а, ЗР1 и Р1. "

Хорошо картинку увидел

Но уже на следующие выходные только смогу разбираться, спасибо.

А так?

возможно

• нельзя зашарить инфу для пользователя, который еще не был на сайте.
• после обновления инфы нужно обновить и все зашифрованные копии
• сложно будет скакать от компа к компу - все таки веб приложение, а таскать за собой свой ключи не очень хочется.

Anhang

нельзя зашарить инфу для пользователя, который еще не был на сайте.

Страшный недостаток, просто полный ноу-гоу. Примерно как поскандалить в банке. Оказывается без удостоверения личности нельзя открыть счёт! А если оставаться с компьютерами, то, оказывается нельзя выдать права доступа к файлу пользователю, если его ещё в LDAP-е (AD) нет. Как с таким можно жить! :)

Если честно - не смешно. Как ты себе представляешь обеспечивать безопасность непонятно для кого? Ну, можно попросить пользователя А самому сгенерировать пару новых ключей для Б. И пусть сам передаёт их Б. Когда Б зарегистрируется, будет их использовать, пока не сгенерит свои.

после обновления инфы нужно обновить и все зашифрованные копии

Эм... О каких зашифрованных "копиях" идёт речь?

P.S. А, увидел на рисунке. Нет, ты неправильно понял. У тебя у 1 ресурса несколько зашифрованных ресурсов. А должен быть 1. Никакого ЗР2 из Р1 делать не надо. Р1 -> ЗР1, Р2 -> ЗР2. Только ключи ресурса для пользователей шифруем и получаем больше одного: у КР1 есть варианты ЗКР1_Па и ЗКР1_Пб. А сам ресурскак был ЗР1 так и остался. И вообще, почисть картинку, что-то и слева и справа Па и Р1

сложно будет скакать от компа к компу - все таки веб приложение, а таскать за собой свой ключи не очень хочется.

Тоже обалденная претензия. Ключ от квартиры с собой носить заставляют! Животные! Это я так издеваюсь, да. Носи на УСБ стике, напиши приложение для телефона, держи в облаке, обычно приватные ключи можно защитить паролем. Можно хранить защищённые паролем приватные ключи прямо в хранилище ключей. Чем мы эффективно снизим уровень защиты раз так в 10^20. Потому как теперь не надо ломать 2048-битный ключ, достаточно подобрать к нему пароль. Символов из 6-8.

Открою страшную тайну - чем сильнее защита данных, тем менее удобно получать к ним доступ. Именно поэтому у нас всё и не зашифровано. Мы и паролей помнить не хотим, и ключи с собой таскать не хотим, да ещё и искать в супер-пупер-защищённых данных нам очень надо. Но чтобы никто кроме меня их не видел! Но поиск обеспечь. И противоречий мы не видим.

В общем я понял. Решение для тебя: каждый пользователь выдумывает себе пароль и с ним всё XOR-им. Мелкософт-стайл. Пароль пользователь запомнить сможет? (как бонус - в таком даже поиск можно сделать)

И даже если юзер забудет пароль, поможем ему дешифровать :)

Страшный недостаток, просто полный ноу-гоу

именно так. Одно из основных требований - информацию можно зашарить с любым кто есть в AD, то бишь с любым официальным пользователем организации.

А связываться с пользователем и просить его посетить сайт - это уже слишком.

Как ты себе представляешь обеспечивать безопасность непонятно для кого?

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

О каких зашифрованных "копиях" идёт речь?

Может я еще чего не понял. Как тогда генерится ЗП2 (хотя должно быть ЗП1б)? Получается один ключ для шифрования и много для дешифровки - такого я еще не знаю

что-то и слева и справа Па

слева - это ввод, справа редактирование/вывод для одного и того же пользователя.

Носи на УСБ стике, напиши приложение для телефона, держи в облаке

Неудобно, если бы речь шла о моей личной инфе для облака - это еще можно было понять.

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

с любым кто кто есть в AD

-----

Ну и что мешает передать ключи при (первом?) логине?

левых пользователей быть не должно

------

Хммм... решить административно? топологически?

Потому как в открытой системе они по определению должны учитываться...

много для дешифровки - такого я еще не знаю

-----

Странно. Предлагал вроде посмотреть потому как видел упоминания наличия.

Достаточно того, что бы любой авторизированный персонал не имел легальных путей доступа к зашифрованной информации. И чтобы база вне сервера не имела большого смысла.

-----

Если это ВСЕ, то решается на уровне разграничения прав доступа к папкам//файлам и включением шифрации раздела/папки хранилища.

Админу просто не дается доступ к этой папке/разделу. Мониторится все на раз...

Ну и что мешает передать ключи при (первом?) логине?

Первом логине куда?

Потому как в открытой системе они по определению должны учитываться...

Можно учитывать и любые попытки взлома. Как вот, поставили озабоченные определениями, битлокер на рабочем лапте, что бы не даг бог не утянули что то важное. А то что теперь систему хрен восстановишь - не волнует.

Хочется иметь некое сбалансированное решение.

разграничения прав доступа к папкам//файлам и включением шифрации раздела/папки хранилища.

да уже предлагали этот маразм. Для больших файлов может и удобнее. А с совершенно другого веб приложения....

Админу просто не дается доступ к этой папке/разделу

А кто интересно это будет делать? Другой админ который имеет доступ?

потому как видел упоминания наличия

Да есть такая буква https://en.wikipedia.org/wiki/Broadcast_encryption

Но, что то мне кажется имелось другое - закодировать ключ расшифровки ключом другого пользователя

Первом логине куда?

-----

В AD, разумеется. вебовский юзер должен мапится туда же.

А то что теперь систему хрен восстановишь - не волнует.

-----

А должно? Там же черным в цвете написано - восстановление херов - за углом ( там груша и ее надо околачивать)...

А с совершенно другого веб приложения...

-----

Так без разницы.

Разница в том, что права веб-юзера от которого запускается исполняемый на иис-сервере код сильно специфические в сравнении с обычным ад-юзером.

По-простому обычный юзер не может запускать что-либо из под иис.

Другой админ который имеет доступ?

-----

Нет. Делать будет тот админ у которого есть разрешение давать доступ, но нет прав доступа.

Посмотри какие роли и права доступны и как настраивать. Настраивать легче чем писать код.

кажется имелось другое

------

А тебе какая разница?

У тебя будут :

- пользователь

- ресурс (зашифрованный)

- ключ шифрации

Ты хочешь, чтобы у каждого пользователя был свой доступ к ресурсу.

Дальше начинаются пляски с бубном по поводу разграничения доступа многих пользователей к одному ресурсу.

Простейший шифратор - хор с большим известным файлом, более сложный - тот хор, но с генерируемой последовательностью.

Генератор может быть сложным, но должен воспроизводить ту же последовательность при одинаковой инициализации.

Могу сразу сказать, что не знаю ни одного генератора позволяющего получить одинаковые последовательности при разных инициациях.

Возможно что есть, но скорее всего происходит кроссинг логина в какую-то инициализацию и сейчас ты мучаешься с выбором где хранить этот инициализатор.

Твоя проблема - инициализатор - одинаковый для всех и ты не хочешь отдавать его юзерам, а вот куда его спрятать пока не решил.

Как бы ты не изворачивался, но как-то кроссировать логин в инициализатор тебе надо. Можно слать с клиента, но неудобно

Так что если не хочешь пользовать стандарт - АД - для менеджмента - выделяй отдельный АД на физическом сервере без доступа из инета и клепай там кроссер.

Будет другой админ, без прав админить/аксесить твой стандартный домен и будет заниматься только раздачей ключей.

Но я бы не заморачивался - воткнул стандартное шифрование и разграничил доступ

Из хитровымудренных варианов есть такой.

Винда на НТФС позволяет писать несколько файлов под одним именем. Винда показывает только "верхний"(первый) из файлов.

При стандартном копировании так же копируется только "верхний" из файлов, дополнительные - не копируются.

Так что пихай туда что хочешь.

менно так. Одно из основных требований - информацию можно зашарить с любым кто кто есть в AD, то бишь с любым официальным пользователем организации.

Эвона как. Вона чо. А мы-то об этом "основном требовании" тока щас узнаём. Как так? Такое основное, а только сейчас придумалось.

Ну, поймай какого-нить админа, пусть тебе про виндусятские Cryptographic Service Provider (CSP) и Key Storage Provider (KSP) расскажет.

Так-то можно и ручками в AD публичные ключи запихнуть. Или через

Но возникает другой вопрос - а о каких других ещё более "основных" требованиях ты ещё умолчал? Попробуешь ещё раз сформулировать всё что надо?

А связываться с пользователем и просить его посетить сайт - это уже слишком.

Хихикаю в кулачок-с. Безопасность. Данные к кoторым доступа ни у кого нет! Но связываться не моги! Пользователь под себя от ужаса надудонит :)

Уменьшай требования к безопасности тогда.

И для входа в любую прогу двух-уровневая авторизация. То бишь, левых пользователей быть не должно.

А левые пользователи тут и не при чём. Ты друг-другу не доверяешь. ВНУТРИ организации. Твоё ж требование "и чтоб никакой админ не мог прочитать!" (и чтоб из города керосин привозили!)

Может я еще чего не понял. Как тогда генерится ЗП2 (хотя должно быть ЗП1б)? Получается один ключ для шифрования и много для дешифровки - такого я еще не знаю

Я уже не знаю как объяснить. Посмотри ещё раз картинку, которую я gendy присылал.

Ключ для шифрования/дешифровки ресурса один - КР1. Много зашифрованных ключей. Для каждого пользователя/группы - свой. Чтобы их можно было хранить, и "ниакой админ" их не мог использовать, чтобы дешифровать ресурс.

Достаточно того, что бы любой авторизированный персонал не имел легальных путей доступа к зашифрованной информации.

Ай, красавчик. Мне зарплата большая не нужна. Достаточно чтобы на свой остров, яхту и пару дворцов хватило. Достаточно, блин. А как же "поделиться без копирования"? Это уже не надо?

В AD, разумеется. вебовский юзер должен мапится туда же

а откуда мне/проге об этом знать?

А должно?

нехрен было битлокер ставить. Уже минимум три рабочих дня стыбрил, а сколько еще будет неизвестно. Так мог бы еще нужные данные сохранить и форматируйте себе в своё удовольствие.

Так без разницы.

может я еще чего то не понимаю, но как ты из веба будешь раздавать права на папки и что там хранить?

Да сейчас в прототипе UI никаких прав нет вообще, есть только относительно простые правила.

Делать будет тот админ у которого есть разрешение давать доступ

Пока не предусмотрено никаких админов. Владелец инфы решает сам каким группам раздавать инфу и кто в этих группах будет. Хотя могут быть и стандартные группы (типа моя команда, это уже чисто по договоренности)

Ты хочешь, чтобы у каждого пользователя был свой доступ к ресурсу.

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

Винда на НТФС

никаких извращений и привязки к хостингу.

При стандартном копировании так же копируется только "верхний" из файлов, дополнительные - не копируются.

диск полетел, как будем из архива восстанавливать?

Как так? Такое основное, а только сейчас придумалось.

сформулировалось... хотя это в перспективе и тип логина вообще не волновал пока.

а о каких других ещё более "основных" требованиях ты ещё умолчал?

не имею понятия, для поставленного вопроса не должно быть важно. Многое возникает в процессе дискуссии.

Данные к кoторым доступа ни у кого нет!

не совсем так. Один человек не может просто прочитать всю инфу. Вариант с двумя различными ключами отлично справляется с данной задачей.

Уменьшай требования к безопасности тогда

и так уже уменьшено.

Ты друг-другу не доверяешь. ВНУТРИ организации.

Это уже не от меня. RDS еще нигде не запрещали и еще много других хреновин понаделали, которые привычную жизню усложняют.

Ключ для шифрования/дешифровки ресурса один - КР1

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

А как же "поделиться без копирования"? Это уже не надо?

не понял, к чему это? Раньше что то писал? Без контекста ничего уже не помню

а откуда мне/проге об этом знать?

-----

А мое какое дело?

Хошь - логинься АД логином и проверяй совпадает ли там.

Хочешь - делай регистрацию юзверей на сайте и маппинг на АД.

нехрен было битлокер ставить

-----

Ну это же не вопрос - как поднять после слета?

Это административка - ничего не ставить. А если ставить, то принудительно выполнять следующее....

но как ты из веба будешь раздавать права на папки

-----

через команду cacls. а запускать оную буду через Process.

Единственная проблема - из под ИИС напрямую нельзя, с подвывертами - можно.

относительно простые правила

-----

А ты думаешь там будет мало? хи-хи...

Хочешь простой совет - найди опен соурсе фтп (или другой проект) с управлением юзерами и ресурсами - там 70% нужного тебе будет в наличии. Я как-то давно искал, но работающего варианта не нашел.

Владелец инфы решает сам каким группам раздавать инфу и кто в этих группах будет.

-----

Когда слепишь/найдешь/родишь - поделись, плс.

Бо, в этой формулировке оно мне тоже нужно для управления шаблонами. без шифрации, естественно...

не понял, к чему это? Раньше что то писал? Без контекста ничего уже не помню

Ну я так не играю. Помню - не помню, прекращай эту ромашку. 3-е сообщение: "Другой пользователь может читать или расшаренную с ним информацию или свою. И хотелось бы иметь только одну копию шифрованной информации."

- Данные к кoторым доступа ни у кого нет!
- не совсем так. Один человек не может просто прочитать всю инфу. Вариант с двумя различными ключами отлично справляется с данной задачей.

О. Один человек не может прочитать всю инфу. А если половину может, не страшно?

Мелкософт-стайл решение: заводим двух админов, каждому свой ключ. Половину инфы шифруем первым ключом, вторую половины - вторым. Всё, условие задачи выполнено.

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

Мнэ. Не забывай - паблик он для шифрования. Читать тоже как-то надо. А если я начну свой приватный ключ раздавать всем, кто прочитать хочет, то смысл во всей этой "безопасности" слегка того, теряется.

Надо отличасть и явно ввести аутентификация (ху из ху), авторизация (ху может что), и шифрование содержимого. Аутентификация уже есть? Если нет, то все остальное нет смысла обсуждать. Авторизация определяет какой ресурс кому доступен для каких операций. Шифрование напрямую не связано с аутентификацией (логином) - там могут быть свои пароли, ключи и т.п. Например, в protonmail раньше был отдельный пароль для шифрования.

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

Пока требования не определены что-то более конкретно сказать трудно.

Можно было бы хранить приватный ключ пользователя локально на машине, но как тогда показать эту инфу другим выбранным пользователям?

Это в сторону p2p, когда все клиенты сами (в обход сервера) управляют ключами шифрования. Главный сервис управляет зашифрованными данными, а шифрование происходит на клиентах, и они же управляют ключами.

Вроде телеграмм, что то подобное имеет. В какую сторону рыть? Пока еще вообще ничего не искал, только идея появилась о подобной проге.

В Телеграмме обычное e2e шифрование между двумя юзерами, т.е. клиенты договариваются о ключах без сервера. Но это другое, это не связано с ресурсами.