Как лучше хранить "секретную" инфу в базе
Допустим, пользователь имеет набор некой информации которая должна быть видима только ему.
В какой то момент он может захотеть сделать часть информации видимую для других пользователей.
В точки зрения интерфейса пользователя особых проблем вроде нет, а вот как хранить это в базе, что бы никто другой не мог также прочитать эту инфу?
Можно было бы хранить приватный ключ пользователя локально на машине, но как тогда показать эту инфу другим выбранным пользователям?
Вроде телеграмм, что то подобное имеет. В какую сторону рыть? Пока еще вообще ничего не искал, только идея появилась о подобной проге.
Вариант с базой даже не рассматривается - никакой привязки к конкретной базе.
2. Шифровать самостоятельно.
ну так об этом то и вопрос.
Насколько я пока знаю для дешифрования нужен ключ.
Но в данном случае, ключей должно быть много, минимум два.
Потому как пользователь может всегда читать свою информацию, но может поделится ею с другим пользователем или с группой пользователей.
Другой пользователь может читать или расшаренную с ним информацию или свою. И хотелось бы иметь только одну копию шифрованной информации. Но похоже так не получится.
И вот где нам хранить ключи? Обязательно то есть какой то админ, который имеет доступ ко всей информации, соответственно может прочитать любую инфу. Вот именно данный вариант нежелательный.
Если стащили один ключ, то тогда разрешено прочитать только ту информацию которая связана с именно с этим ключом/пользователем.
А почему бы не разделить информацию по группам, шифровать каждую группу своим ключём, и раздавать ключи от совместных папок. Обьединить папки зашифрованные разными ключами в одно дерево проблем не должно составить, в крайнем случае обьеденить их в одну категорию, как это сделано например в виндовсексплорер ну или использовать линкс, Более интересный вариант конечно управление пользователями, обращение при логине на центральный сервер за временными ключами к ресурсам. Тогда достаточно логина и пароля, а сервер уже решает какие ключи выдать
Фашизм будет разбит
Человека карают только те боги, в которых он верит
шифровать каждую группу своим ключём, и раздавать ключи от совместных папок.
вопрос остается тем же - где хранить ключи?
И как быть если одна и та же инфа должна быть расшарена разным группам?
а сервер уже решает какие ключи выдать
С этим пока еще не сталкивался и смутно представляю как это должно работать. По каким ключевым словам искать?
Насколько я пока знаю для дешифрования нужен ключ.
-----
Там по-разному - в зависимости от метода.
Можно для шифрования пользовать один, а для дешифровки - другой. Как работает - не спрашивай - так глубоко не копал.
И вот где нам хранить ключи?
-----
Посмотри как делается расширение для SQL-сервера.
Обязательно то есть какой то админ
------
Как ты думаешь, почему у ракетчиков на пуске сидят двое в разных местах и даже у них ничего не получится без команды на запуск?
А приложение предполагается настольное или мобильное?
Смотреть Вам, видимо, надо в сторону PKI (Public Key Infrastructure) и Secure Key Exchange (Диффи-Хелман или, например, эллиптический Диффи-Хеллман и т.п.)
Ключи придется хранить либо на пользовательском оборудовании, либо городить какой-то централизованный центр сертификации.
А далее, идея:
- Вы обмениваетесь ключами с доверенными пользователями
- А также вы обмениваетесь "групповыми" ключами с пользователями из доверенных групп (можно их автоматически считать доверенными, тут надо смотреть на логику обмена сообщениями, которую нужно реализовать)
Готовые реализации не подскажу, но думаю DHKE и всякая генерация RSA ключей есть для большинства известных языков (C#, Java, etc)
Можно для шифрования пользовать один, а для дешифровки - другой
Насколько я помню это немного для других целей.
Вот еще нашел, что не знал, только пока непонятно как это в "базу засунуть"
https://ru.wikipedia.org/wiki/Гибр�%...
сидят двое в разных местах
Видимо этого будет достаточно, супер-пупер защита пока нет требуется. Главное, чтобы один человек не знал всё и режим отладки был бы недоступен.
А для отладки можно использовать тестовую систему где разработчикам всё известно.
приложение предполагается настольное или мобильное?
Исключительно веб сервер.
надо в сторону PKI
Спасибо, глянул, но выглядит слишком сложно в реализации. Да и непонятно пока, как это всё применить.
Вот у нас пользователь - владелец инфы. Зашифровали мы инфу в базу. Теперь эту инфу нужно выдать нескольким группам в которых разные пользователи и пользователи могут менять группы.
и всякая генерация RSA ключей
Это всё есть и реализация - это следующий этап.
https://learn.microsoft.com/en-us/dotnet/standard/security...
Пока я просто не знаю очень многого из теории криптографии. Просто что-то где то слышал и кое-что применял.
вопрос остается тем же - где хранить ключи?
По ситуации. Если есть админ, то на центральном сервере, если нет, то у каждого набор ключей к разделам куда у них есть доступ
И как быть если одна и та же инфа должна быть расшарена разным группам?
Шифруем инфу другим ключем, раздаём ключ участникам всех групп имеющим доступ к новому разделу.
С этим пока еще не сталкивался и смутно представляю как это должно работать. По каким ключевым словам искать?
А может не изобретать велосипед? Любая современная файловая система имеет подходящую систему прав и разрешений. Может даже шифроваться, чтобы посторонние даже физический доступ не получили. Базы данных тоже самое. И системы NAS тоже
Да нужен админ, который будет управлять правами, но при сложной архитектуре без админа всё равно никуда.
Фашизм будет разбит
Человека карают только те боги, в которых он верит
А может не изобретать велосипед? Любая современная файловая система имеет подходящую систему прав и разрешений.
перепробовали уже несколько прог, ни одна не подходит.
Каким образом это совместить с вебом?
Да и даже локально. Сделал я себе файл в папочке как его разшарить некоторым группам пользователей? Скопировать в нужные папочки? А при редактировании не забыть всем всё обновить.
Каким образом это совместить с вебом?
Использовать любой NAS поддерживающий группы. Я немного имел с ними дел, но например freenas отвечает всем требованиям. Да и netzcloud тоже,
Да и даже локально. Сделал я себе файл в папочке как его разшарить некоторым группам пользователей? Скопировать в нужные папочки? А при редактировании не забыть всем всё обновить.
Создать локальную группу , дать ей нужные права на папку. Создать пользователей включить их в эту группу. При необходимости создать вторую, третью группу. Распихать пользователей.
Оптимально всё это творить на линуксе, но и виндовс про всё это поддерживает, но более ограниченно
Фашизм будет разбит
Человека карают только те боги, в которых он верит
Что вы паритесь? Сделайте как-нибудь, и пользовательсткое соглашение на стопицот страниц, где где-нибудь в середине в завуалированном виде будет стоять "я ни за что не отвечаю, вы сами за всё отвечаете". Вы в одиночку пытаетесь решить какие-то проблемы, на которые даже большие фирмы давно положили болт и с довольным урчанием кассируют идиотов.
но например freenas отвечает всем требованиям.
нифига не понял, это же прога которую надо установить на сервер.
Как ее установить на azure или на что то подобное и как ее скрестить с моим сайтом?
Создать локальную группу , дать ей нужные права на папку
И как это сделать из моего сайта не имея понятия где это будет хостится. Не уверен, что под кубернетес это будет вообще возможно.
И дальше как мне зашарить данные с атрибутами, копировать ссылки на файл в папочки и после как то мапить на страницу. И шифрование файловой системы разве не на уровне диска происходит? Тогда любой кто имеет доступ к диску может всё прочитать и удобно скопировать.
Другой пользователь может читать или расшаренную с ним информацию или свою. И хотелось бы иметь только одну копию шифрованной информации. Но похоже так не получится.
...
Если стащили один ключ, то тогда разрешено прочитать только ту информацию которая связана с именно с этим ключом/пользователем.
Есть ресурсы и есть пользователи. У пользователя есть ключ для шифрования (КП - ключ пользователя). Пользователь хочет сохранить где-то у нас данные (ресурс). В зашифрованном виде. Чо делать?
Создаём для пользователя новый ключ шифрования - ключ ресурса (КР). Шифруем данные КР и храним их (ЗР зашифрованный ресурс). Шифруем КР с помощью КП = ЗКР. Храним ЗКР.
Мысль понятна? У каждого ресурса свой КР. Если пользователь А (с ключом КПа), владеющий ресурсом Р1 (с ключом КР1) хочет поделиться им с пользователем Б (КПб), а копировать; содержимое мы не хотим, создаём ЗКР1б из КР1 (КР1 зашифрованный КПб) и делимся им с Б. Б хочет прочитать Р1? Да пожалста. Ввёл свой ключ, прочитал ЗКР1, расшифровал, получил КР1, расшифровал им ресурс.
Используем мы симметричные или асимметричные ключи - не принципиально.
Итого. Мы, не зная ключей пользователей, ничего прочитать не можем, хоть всё и храним. Ресурсы не копируются. Настройка доступа пользователя (или групп) происходит через управление ЗКР. Если пользователь про...теряет свой ключ, он потеряет доступ к данным. Совсем.
Домашнее задание: что делать, если надо отозвать право доступа к ресурсу Р2 у пользователя В? Пользователи А и Б тоже имеют доступ к ресурсу.
П.С. Да, при доступе к системе пользователя мы, конечно, сможем выловить расшифрованные ключи из памяти. Ну так он и так свой ключ знает...
Домашнее задание: что делать, если надо отозвать право доступа к ресурсу Р2 у пользователя В? Пользователи А и Б тоже имеют доступ к ресурсу.
создаём третий ключ, админский и шифруем все ЗКР. Дальше два варианта Децентрализованный : при блокировке одного пользователя придется менять все ЗКР. Центральный : для каждого ЗКР создаём свой админский ключ и сохраняем в базе. при необходимости генерим новый админский ключ для этого ЗКР , старый обьявляем недействительным, это нужно не только в для отзыва прав но и в случае кражи ключа
Если пользователь А (с ключом КПа), владеющий ресурсом Р1 (с ключом КР1) хочет поделиться им с пользователем Б (КПб), а копировать; содержимое мы не хотим, создаём ЗКР1б из КР1 (КР1 зашифрованный КПб) и делимся им с Б. Б хочет прочитать Р1? Да пожалста.
где шифровать будем? если на клиенте пользователя А, то он должен получить ключ пользователя Б, Если на на клиенте Б то наоборот Б получит ключ ресурса А, оба варианта исключително ненадёжны.
Ну а если на сервере , то все ключи будут в распоряжении админа
Кроме того, как пользователь А сможет расшарить часть своего ресурса? одну папку или даже один файл? выходит только один вариант, выделять это в отдельный ресурс, расшифровывать и шифровать новым ключом для этого субресурса
Фашизм будет разбит
Человека карают только те боги, в которых он верит
нифига не понял, это же прога которую надо установить на сервер.
более того, это уже и есть НАС сервер
Как ее установить на azure или на что то подобное и как ее скрестить с моим сайтом?
сделать отдельный файлосервер
И как это сделать из моего сайта не имея понятия где это будет хостится. Не уверен, что под кубернетес это будет вообще возможно.
скорее всего никак. вначале решить где хоститсая будет
Тогда любой кто имеет доступ к диску может всё прочитать и удобно скопировать.
не давать любому доступ к рут и он сможет прочитать только свои данные
Фашизм будет разбит
Человека карают только те боги, в которых он верит
сделать отдельный файлосервер
Спасибо, но не нужно. Уже есть и для данного случая совершенно не подходит.
вначале решить где хоститсая будет
тогда данный вариант не годится по определению.
не давать любому доступ к рут
неважно кому. И базы вытягивают и файлы.
создаём третий ключ, админский и шифруем все ЗКР. Дальше два варианта...
Не, немного сложнее. Ведь пользователь, у которого отозвали доступ, мог где-то сохранить расшифрованный КР. Рано или поздно придётся перевыпустить КР, к которому отозван допуск. И для всех пользователей, у которых был доступ к ресурсу перевыпускаем ЗКР. И тут приходим к мысли что асимметричные ключи рулят. Зашифровать можем и без пользователя.
где шифровать будем?
Только на клиентских. И тогла нам надо какое-то время хранить расшифрованный КР. Или... Асимметричные ключи спешат на помощь!
Кроме того, как пользователь А сможет расшарить часть своего ресурса?
Никак. Создаем новый ресурс. Ну и не забываем что так шифровать чтоб прям никто кроме польщователя не мог прочитать надо редко и немного. А то тот же поиск по такому зашифрованному не работает.
Спасибо, но не нужно. Уже есть и для данного случая совершенно не подходит.
В общем мы изобретаем не просто велосипед. Мы изобретаем велосипед который будет крепиться на крыше машины, и которым можно будет управлять при помощи различных костылей, потому как универсального крепления для нашего велосипеда нет.
неважно кому. И базы вытягивают и файлы.
Это плохо. Если кто угодно может вытягивать любые базы и файлы не имея рута, лучше с такой системой не связываться.
Фашизм будет разбит
Человека карают только те боги, в которых он верит
Ведь пользователь, у которого отозвали доступ, мог где-то сохранить расшифрованный КР.
Где он его возьмёт? Пользователь должен видеть только свой ключ и зашифрованный им и админским ключем ключ ресурса.
Хотя да, ключ пользователя тогда действительно не нужен, но как сделать, чтобы админ не смог добраться до данных загадка
Ассиметричные ключи конечно великая вещь, но в данном случае всем достаточно и публичного ключа. Цель ведь не создать новый ключ, а прочитать данные
Фашизм будет разбит
Человека карают только те боги, в которых он верит
В общем мы изобретаем не просто велосипед
К сожалению, на предложенном вами велосипеде неудобно будет ехать от Дрездена до Берлина.
Кроме встроенного RBAC на уровне системы, там нет больше ничего полезного.
лучше с такой системой не связываться
ну расскажите это всем тем кого это уже задело или заденет.
но как сделать, чтобы админ не смог добраться до данных загадка
уже сказали - не следует иметь только один ключ, который вводит один админ.
Хотя да, можно взломать любую систему. Но в данном случае есть достаточно простое правило - ни один человек легально не имеет права прочитать все данные.
Где он его возьмёт? Пользователь должен видеть только свой ключ и зашифрованный им и админским ключем ключ ресурса.
Где-где. Раскодирует из ЗРК. Ни хранилище ресурсов, ни хранилище ЗКР не расшифровывают ресурсы / ключи. Они только хранят и отдают зашифрованное.
Расшифровка происходит на клиенте. И никаких админских ключей.
наполовину
А так?
Действующие лица: пользователь А Па, пользователь Б Пб. Ресурс Р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. Аутентификацию и авторизацию пока не рассматриваем.
А так?
возможно
- нельзя зашарить инфу для пользователя, который еще не был на сайте.
- после обновления инфы нужно обновить и все зашифрованные копии
- сложно будет скакать от компа к компу - все таки веб приложение, а таскать за собой свой ключи не очень хочется.
Прикреплённые файлынельзя зашарить инфу для пользователя, который еще не был на сайте.
Страшный недостаток, просто полный ноу-гоу. Примерно как поскандалить в банке. Оказывается без удостоверения личности нельзя открыть счёт! А если оставаться с компьютерами, то, оказывается нельзя выдать права доступа к файлу пользователю, если его ещё в 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 шифрование между двумя юзерами, т.е. клиенты договариваются о ключах без сервера. Но это другое, это не связано с ресурсами.
найди опен соурсе фтп (или другой проект) с управлением юзерами и ресурсами - там 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, разрешить/запретить> -
Это если рассматривать ее как динамическую и как кем то управляемую. А когда таблица полностью статическая, точнее её и создать нельзя в данном виде. Есть просто базовые правила, которые академики и могут назвать правила авторизации.
и потом исчезают навсегда
странно, открываю мессежер и вижу всё сообщения начиная с рождения аккаунта. Отчего не исчезли?
после чего реализуете сервис управления ресурсвами с ограничением доступа типа таблицы выше
ну вот сделайте мне таблицу доступа для следующего:
- зашел на сайт, создалась моя группа, пишу туда что хочу и редактирую как хочу.
- вижу другую группу, где я есть, могу туда кинуть/удалить ссылку на любую инфу из моей группы. Вижу там же все ссылки от других пользователей.
- создаю другую группу, добавляю/удаляю пользователей, шарю инфу из моей группы.
все тоже самое для другого пользователя и хотя бы еще десятка других.
А вопрос был в том, как удобнее всего шифровать инфу. Пока есть всего два решения:
- каждый пользователь имеет публик ключ на сервере и приватный ключ у себя на компе. Используем ассиметричное шифрование
- сервер имеет два ключа, используем симметричное шифрование
Есть еще варианты?
А вопрос был в том, как удобнее всего шифровать инфу. Пока есть всего два решения: каждый пользователь имеет публик ключ на сервере и приватный ключ у себя на компе. Используем ассиметричное шифрованиесервер имеет два ключа, используем симметричное шифрование
Для начала двумя ключами никто сами данные не шифрует, поскольку это неэффективно (очень долго) да и не нужно. Двумя ключами шифруют ключи для эффективных (симметричных) алгоритмов. А два ключа используют для совершенно других целей. Поэтому первый подход с асимметричным шифрованием фактически использует два ключа для двух разных целей: аутентификацию и шифрование. Это не запрещено конечно, но если вы понимаете, что творите. А вы видимо не понимаете, поэтому я с самомго начала и потом несколько раз повторял: где здесь аутентификация, где авторизация, и где шифрование. Ну чтобы было более понятно: пара <public key, private key> аналогична паре <user name, passowrd>. Если вы вводите асимметричное шифрование, то неявно вводите просттранство юзеров - каждый открытый ключ это один юзер. Например, в биткойне столько юзеров, сколько было сгенерировано открытых ключей (очень много), и каждый может зарегить нового юзера путем генерации пары ключей (и выполним транзакцию, чтобы этот открытый ключ попал в блок-чейн). Так что использовать асимметричное шифрование это изначально не очень хорошая идея.
А теперь главное: почему асиметричное шифрование "удобнее" в данном случае, и какую проблему мы решаем?
Есть еще варианты?
Пока проблема не сформулирована, то нет и решения. Если предположить что "вопрос был в том, как удобнее всего шифровать инфу", то берите любой алгоритм шифрования и делайте. Возьмите zip и шифруйте все файлы. Если хотете поделиться, то закиньте на открытый сервер, дайте линк кому надо вместе с ключем шифрования и усе. Ну или на стике передавайте.
Для начала двумя ключами никто сами данные не шифрует
Два ключа нужны только для того что бы ключ не знал один человек, а всё остальное это уже домыслы
поскольку это неэффективно (очень долго)
А есть ссылка на исследования хотя бы после 2000 года, потому как по ощущениям это гораздо меньше секунды.
Поэтому первый подход с асимметричным шифрованием фактически использует два ключа для двух разных целей: аутентификацию и шифрование.
вот ту есть готовый код, покажите часть для аутентификации пож.
https://www.infoworld.com/article/3683911/how-to-use-symme...
Если вы вводите асимметричное шифрование, то неявно вводите пространство юзеров
только в том случае если пара ключей принадлежит одному и только одному пользователю.
так что использовать асимметричное шифрование это изначально не очень хорошая идея
Спросите того кто это предложил. И вам скажут, что это очень хорошая идея для того что хотелось.
Если бы я хотел хранить исключительно личную информацию, то пожалуй так бы и поступил.
и какую проблему мы решаем?
ладно, можно и повторить.
Есть некие данные, которые генерит / получает сотрудник предприятия. И это не большой объем данных.
Этими данным можно поделится с другими сотрудниками твоей команды или может еще с кем-то.
Либо просто с одним каким-то сотрудником.
При этом никаких админов для данной проги, потому как задолбались они уже. Данные должны хранится на сервере в зашифрованном виде. При этом ни из кого у сотрудников не должно быть официального доступа ко всем незашифрованным данным, либо просто пути для дешифрации (типа знания ключа)
Ну вот как то так вкратце.
Возьмите zip и шифруйте все файлы.
нет никаких файлов, есть строка с атрибутами которая вводится вручную/копируется на веб сайте.
то закиньте на открытый сервер
неудобно, потому как получателю нужно еще передать ключ и он должен с ним проделать какие то операции.
Ну или на стике передавайте.
Очень многие находятся в разных частях земного шарика.
Есть некие данные, которые генерит / получает сотрудник предприятия. И это не большой объем данных.Этими данным можно поделится с другими сотрудниками твоей команды или может еще с кем-то.Либо просто с одним каким-то сотрудником.При этом никаких админов для данной проги, потому как задолбались они уже. Данные должны хранится на сервере в зашифрованном виде. При этом ни из кого у сотрудников не должно быть официального доступа ко всем незашифрованным данным, либо просто пути для дешифрации (типа знания ключа)
Обычная удаленная (общая) файловая система решает проблему. Все файлы шифруются на диске битлокером или чем-то подобным. Доступ разграничивается через атрибуты файла: сделайте файл/папку доступной для чтения/записи для пользователя/группе. Ну или SharePoint еще удобнее. Ну и думаю еще море разный подобных решений существует для совместного использования документов. Почему не подходит?
Обычная удаленная (общая) файловая система решает проблему
нифига не решает, как нужно
Все файлы
нет никаких файлов как и документов. Есть скажем, строка с атрибутами: имя, описание и пр.
еще море разный подобных решений
Да пробовали тоже много. Основная проблема - кто то должен это все администрировать.
Да и нужен веб - открыл сайт и усё.
нифига не решает, как нужно
Почему? Что не нравится?
Пользователь генерит данные в виде строки с атрибутами и сохраняет в файле "Строка с атрибутами 1.txt". Предоставляет доступ пользователю 3 и 4, ну или группе. Они могут теперь его читать.
нет никаких файлов как и документов. Есть скажем, строка с атрибутами: имя, описание и пр.
А строка с атрибутами не может в файле хранится? Это требование такое?
Мне это напоминает разборки с бухгалтерами по поводу требований к системе:
- Мы работаем так: берем документ из папки в нижнем ящике тумбочки, заполняем верхнее поле, и кладем в верхний ящик в шкафу
- Ну хорошо, будете открывать файл из этой директории, заполнять поле, и сохранять в другой директории
- Нет, так не пойдет, мы принципиально не работаем с файлами и директориями и работать никогда не будем. Мы работаем с ящиками и шкафами, и не собираем менять наш подход.
- Ну хорошо, а если мы в базе данных будем хранить документы как записи.
- Ни в коем случае. Делайте как хотите, но никаких файлов, директорий или баз данных с записями. И чтобы там еще печать чернильная была обязательно от нашего шефа, но он в другом здании, поэтому надо относить документ, обязательно, поскольку он любит, чтобы к нему лично приходили.
Такой разговор это кстати не очень далеко от реальности работников бухгалетрий (if you know what I mean :) Это я по поводу что "нет никаких файлов". Ну используйте вместо файлов "строка с атрибутами" или URI - что это меняет? Мы храним где-то данные, и они доступны кому надо по ссылке. Проблема решена. Или я чего-то упустил?
Почему? Что не нравится?
Честно говоря, не вижу смысла в проведении опросов и написания отчета почему хочется отказаться от подобной системы.
Если интересно, просто напишите шаги который должен сделать админ/пользователь для описанных мною шагов.
Не забыть еще, что есть ограничения на длину пути к файлу и доступ к расшаренному каталогу возможен только через VPN.
И предлагаю более реальный пример - вот есть контора по разработке ПО, приходит туда заказчик и говорит - хочу веб приложение на С шарпе и что бы данные были в базе.
Контора в ответ - ничего подобного, вам нужно десктоп приложение, а данные должны быть на сетевом диске. И вообще, все нормальные пацаны пишут веб приложения на ангуляре/ноде..../.. никаких С шарпов.
Реакцию заказчика нужно ещё описывать?
А строка с атрибутами не может в файле хранится? Это требование такое?
ну давайте расскажите какие шаги нужны для показа ентого в таблице и присобачивания поиска, при том что нужны не все файлы из каталога.
Или я чего-то упустил?
всё что я написал до того.
А то спрашиваю какой авиакомпанией лучше полететь на майорку
------
Но при этом ты требуешь чтобы авиакомпания обеспечила перелет без самолета и производить взлет не из аэропорта...
а мне говорят
-----
Да, тебе говорят, что можно взлететь с автобана... но не говорят что это будет большой боинг...
Интересовал всего то удобный способ шифрования информации в базе
------
Ну тебе назвали несколько вариантов.
В обратку получили требования измененные до сферического коня в вакууме - информации не должно быть, ничего дополнительного нигде не должно хранится, доступно должно быть не всем но ограничено нечем тем кто решил ограничить.
Когда тебя просят поименовать сущности, то выслушивать приходится что-то вида вот тут имеем несколько разных но различать не надо а надо делать различия... Определись хоть с чем нибудь - тогда можно будет смотреть что с чем делать.
В обратку получили требования измененные до сферического коня в вакууме
Явное преувеличение.
Все что нужно пользователю - попасть на сайт, всё остальное лишнее - это вроде само собой разумеется.
Когда тебя просят поименовать сущности
не имею понятия что под этим подразумевается. Давай список - сделаем имена.
Определись хоть с чем нибудь
Не вижу никаких проблем, что еще непонятно?
