Re: Доступ к медиатеке
On Sat, 6 Oct 2018 21:15:36 +0300 artiom wrote: > > Интересно, какие по вашему мнению способы использования данных > > гуглем хуже таржетированной рекламы? > > > > Не секрет, как они используют данные и какие: > https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in > > Одна из проблем, которую уже освещали, не таргетированная реклама, а > таргетированный контент. Вплоть до того, что некто может не узнать > важных новостей по своему запросу. Согласен, таргетированный контент хуже таргетированной рекламы. Поэтому я использую по умолчанию в качестве поисковой машины duckduckgo, а не google. > Потом, ещё это: "Иногда мы получаем запросы на доступ к данным > пользователя от правоохранительных органов. Наши юристы рассматривают > каждый запрос и отвечают отказом, если он составлен в слишком общих > терминах или с нарушением юридических норм." > > Рассматривают и предоставляют. Как известно, законы везде разные. У гугля есть регулярно публикуемые transparency report-ы, где они указывают количество запросов от правоохранительных органов и количество удовлетворенных среди них. С разбивкой по странам. > > Плюс, ваши данные потенциально могут утечь: > https://tproger.ru/news/facebook-87-million-leak/ > > Если возможно на Facebook, то почему не в гугле? К тому же, > google.docs были недавно яндексом проиндексированы. В данном случае (мы же обсуждали проблему попадания некоего нашего публичного сайта в поисковый индекс гугля) это нерелевантно. В случае использования Google Docs и Google Drive тут риски все те же, что и в любых облаках. Правда, размер имеет значение. В случае возникновения у гугля конфликта с роскомнадзором проблема, скорее всего, будет быстро решена. Вот они уже и с китайцами договорились, хотя несколько лет бодались. С другой стороны поломать всем известный гугль пытается куда большее количество хакеров чем какую-то никому не известную инсталляцию ownCloud. --
Re: Доступ к медиатеке
06.10.2018 20:39, Victor Wagner пишет: > On Sat, 6 Oct 2018 15:49:18 +0300 > artiom wrote: > > >> >> Т.е., всё-таки на первое место выходит доступность, а >> конфиденциальность данных на втором, и они не сильно чувствительны к >> этой угрозе? > > > Проблема тут не в том, сильно ли чувствительны данные к угрозам > конфиденциальности, а в том что разные данные к ним чувствительны очень > по разному. > > Нарушая фидошную традицию и вспоминая, что написано в subj, а там > написано "Доступ к медиатеке", мы можем рассмотреть угрозы > конфиденциальности для данных медиатеки. > > В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, > и которые потенциальному атакующему доступны и из другого места. > Да не, с медиатекой всё понятно. > Но, в мире есть такая штука как копирайт, поэтому если мы вообще не > будем защищать медиатеку от несанкционированного доступа, мы можем > налететь на обвинение в незаконном распространении охраняемых > копирайтом произведений. > > Насколько я понимаю, закрытие любой самой примитивной аутентификацией > во-первых отсекает 100% ботов, которые рыщут по интернету в поисках > нелегальных копий копирайченной продукции, во-вторых, является > достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы > данные не распространяем, мы их для собственных нужд на этом сервере > держим. И даже доступом к нему не торгуем. А так все это добросовестно > приобретенные фильмы. > > Ну и вообще надо вспомнить третий тип угроз - кроме доступности и > конфиденциальности атакующий может попытаться нарушить целостность > данных. То есть стереть и/или подменить то, что он стирать или > подменять не имел права. > > Поскольку в соседнем письме речь шла о нескольких пользователях, > которым предлагается дать права на удаление/изменение данных, тут дать > единого рецепта на все случаи жизни, пожалуй не получится - сначала > роспись того, какие у нас бывают пользователи и над какими данными они > имеют власть, а потом модель угроз. > Это часть модели. Но в явном виде у меня её нет. В общем-то задача состоит в том, чтобы давать разный доступ разным группам так, чтобы это было удобно. >>> Потому что первым в списке угроз "будет плохо, если они прочитают >>> ваши данные" стоит гугль, который использует данные для >>> таржетированной рекламы. И при этом существует достаточно много >>> данных, которые их владельцы старательно скармливают гуглю, чтобы >>> они попали в результаты поиска. >>> >> >> Он использует эти данные не только для рекламы. >> > Интересно, какие по вашему мнению способы использования данных гуглем > хуже таржетированной рекламы? > Не секрет, как они используют данные и какие: https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in Одна из проблем, которую уже освещали, не таргетированная реклама, а таргетированный контент. Вплоть до того, что некто может не узнать важных новостей по своему запросу. Потом, ещё это: "Иногда мы получаем запросы на доступ к данным пользователя от правоохранительных органов. Наши юристы рассматривают каждый запрос и отвечают отказом, если он составлен в слишком общих терминах или с нарушением юридических норм." Рассматривают и предоставляют. Как известно, законы везде разные. Плюс, ваши данные потенциально могут утечь: https://tproger.ru/news/facebook-87-million-leak/ Если возможно на Facebook, то почему не в гугле? К тому же, google.docs были недавно яндексом проиндексированы. И есть немало компаний и "аффилированных лиц", которым гугл передаёт данные.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 15:49:18 +0300 artiom wrote: > > Т.е., всё-таки на первое место выходит доступность, а > конфиденциальность данных на втором, и они не сильно чувствительны к > этой угрозе? Проблема тут не в том, сильно ли чувствительны данные к угрозам конфиденциальности, а в том что разные данные к ним чувствительны очень по разному. Нарушая фидошную традицию и вспоминая, что написано в subj, а там написано "Доступ к медиатеке", мы можем рассмотреть угрозы конфиденциальности для данных медиатеки. В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, и которые потенциальному атакующему доступны и из другого места. Но, в мире есть такая штука как копирайт, поэтому если мы вообще не будем защищать медиатеку от несанкционированного доступа, мы можем налететь на обвинение в незаконном распространении охраняемых копирайтом произведений. Насколько я понимаю, закрытие любой самой примитивной аутентификацией во-первых отсекает 100% ботов, которые рыщут по интернету в поисках нелегальных копий копирайченной продукции, во-вторых, является достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы данные не распространяем, мы их для собственных нужд на этом сервере держим. И даже доступом к нему не торгуем. А так все это добросовестно приобретенные фильмы. Ну и вообще надо вспомнить третий тип угроз - кроме доступности и конфиденциальности атакующий может попытаться нарушить целостность данных. То есть стереть и/или подменить то, что он стирать или подменять не имел права. Поскольку в соседнем письме речь шла о нескольких пользователях, которым предлагается дать права на удаление/изменение данных, тут дать единого рецепта на все случаи жизни, пожалуй не получится - сначала роспись того, какие у нас бывают пользователи и над какими данными они имеют власть, а потом модель угроз. > > Потому что первым в списке угроз "будет плохо, если они прочитают > > ваши данные" стоит гугль, который использует данные для > > таржетированной рекламы. И при этом существует достаточно много > > данных, которые их владельцы старательно скармливают гуглю, чтобы > > они попали в результаты поиска. > > > > Он использует эти данные не только для рекламы. > Интересно, какие по вашему мнению способы использования данных гуглем хуже таржетированной рекламы?
Re: Доступ к медиатеке
А причём здесь вообще телеграм? 06.10.2018 16:01, Евгений Кабанов пишет: >> Впрочем, несколько ушли от темы доступа к медиатеке. >> Музыка и фильмы - это явно не те данные, которые я хочу защитить ото >> всех. Мне нужно предоставить доступ на запись/изменение с аудитом для >> некоторых авторизованных людей. >> И на чтение для большинства авторизованных. >> Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на >> практике. >> Может имеются ещё варианты? > > Есть простые, но возможно не правильные решения: > 1. грузите контент в приватный канал телеги; > 2. назначаете админов с нужными правами (на изменение); > 3. просто подписываете всех остальных, кого решите; > 4. поддерживаете состав подписчиков и админов в соответствии с > собственной политикой. >
Re: Доступ к медиатеке
D. H. -> debian-russian@lists.debian.org @ Sat, 6 Oct 2018 06:18:14 -0500: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > Вот это я пошел гуглить. Что-то пропустил похоже. Угу. Пару месяцев назад, подыскивая для машинки на DigitalOcean адрес, не заблокированный Роскомнадзором, я перебрал пять их датацентров. С трудом нашел.
Re: Доступ к медиатеке
> Впрочем, несколько ушли от темы доступа к медиатеке. > Музыка и фильмы - это явно не те данные, которые я хочу защитить ото > всех. Мне нужно предоставить доступ на запись/изменение с аудитом для > некоторых авторизованных людей. > И на чтение для большинства авторизованных. > Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на > практике. > Может имеются ещё варианты? Есть простые, но возможно не правильные решения: 1. грузите контент в приватный канал телеги; 2. назначаете админов с нужными правами (на изменение); 3. просто подписываете всех остальных, кого решите; 4. поддерживаете состав подписчиков и админов в соответствии с собственной политикой. -- Евгений Кабанов
Re: Доступ к медиатеке
Впрочем, несколько ушли от темы доступа к медиатеке. Музыка и фильмы - это явно не те данные, которые я хочу защитить ото всех. Мне нужно предоставить доступ на запись/изменение с аудитом для некоторых авторизованных людей. И на чтение для большинства авторизованных. Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на практике. Может имеются ещё варианты? 04.10.2018 20:44, artiom пишет: > Требуется организовать доступ к медиатеке, позволяющий нескольким > пользователям переименовывать, удалять и, главное, добавлять файлы. > > Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о > полноценном управлении, как файловой структурой, и говорить нечего. > > При этом, условие такого, что пользователи авторизуются через LDAP. > > Один из вариантов был - использовать файловые менеджеры в > докер-контейнере, типа sprut.io, но с LDAP там всё плохо. > Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и > системный pam-ldap модуль. Но встали вопросы: как не дать пользователю > выполнять команды и ограничить просмотр дерева не выше того каталога, в > котором хранится медиатека? > > Есть какие-то варианты того, как эту задачу решают белые люди? > Что посоветуете? > И по pam-ldap вопросы тоже актуальны. >
Re: Доступ к медиатеке
06.10.2018 13:53, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:59:41 +0300 > artiom wrote: > >> 05.10.2018 23:06, D. H. пишет: >>> On 05/10/18 02:45 PM, artiom wrote: А от кого вы защищаться собрались? >>> >>> Как правильно было сказано уже не помню где. Но суть примерно такая: >>> >>> - Вам есть что скрывать? >>> - Нет, но мои данные не ваше дело. >>> >> Не в тему. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Защищаться надо > > 1. От пьяного тракториста, который переедет интернет кабель > 2. От обкурившегося сетевого админа, который сломает роутинг. > 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако > может случайно попасть под раздачу, оказавшись в одном /16 блоке с > телеграмовской прокси. > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > > От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. > Т.е., всё-таки на первое место выходит доступность, а конфиденциальность данных на втором, и они не сильно чувствительны к этой угрозе? > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > Какая "прелесть". > Определить от каких угроз несанкционированного доступа следует защищать > данные, практически невозможно, если не знать характера данных. > Конечно. Я о том и говорю. Когда вы будете думать, надо ли защищаться и от кого, вопрос о характере данных встанет. > Потому что первым в списке угроз "будет плохо, если они прочитают > ваши данные" стоит гугль, который использует данные для таржетированной > рекламы. И при этом существует достаточно много данных, которые их > владельцы старательно скармливают гуглю, чтобы они попали в результаты > поиска. > Он использует эти данные не только для рекламы.
Re: Доступ к медиатеке
> On 06/10/18 04:59 AM, artiom wrote: >> Не в тему. > > Почему же? У вас душ к примеру на улице находиться? полностью прозрачный? > Потому что вопрос был не о душе на улице и не о философских проблемах необходимости защиты информации. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > > В том то и дело. Вопрос не верен. Не от кого. А почему (ну или зачем). А > ответ уже есть :) > Вопрос совершенно верен. Думаю, что эту тему я знаю несколько лучше вас. Если хотите формально: какова модель нарушителя? >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Очень просто. Задача обеспечить конфиденциальность целостность и > доступность. > От кого? Кому? Для чего? На каком уровне? Вы говорите общими словами, а они дают мало.
Re: Доступ к медиатеке
06.10.2018 14:18, D. H. пишет: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > > Вот это я пошел гуглить. Что-то пропустил похоже. > Совсем немного: блокировки миллионов адресов, судебные иски и срач в сторону РКН.
Re: Доступ к медиатеке
> On 06/10/18 04:58 AM, artiom wrote: >> От задач. Если вы хотите, например, имея облако, отдать файл по ссылке >> кому-то постороннему. > > Боже упаси и сохрани от хранения важной инфы в облаках. (икону наверное > надо ещё приложить) > В своём облаке. Что такое "важная инфа"? Вы как-то измеряете степень важности? >> Как вы это сделаете, если NAS доступен только через VPN? > > А я сказал только? > Ну ok, доступен через VPN для манипуляции файлами. А манипулировать ими хочу не только я. Кроме того, надо поднимать VPN на NAS, что само по себе задач не решит, лишь откроет другие пути, которые без VPN не работают. >> Вы будете всех переводить на VPN? > > Это даже телефоны умеют. В чем проблема? > В том, что это надо сделать тому, кто это делать не хочет. Это переусложнение. Вам надо поделиться с человеком данными, а вы ему не только ссылку, но "поставь VPN". > Итого: > > Это не проблема VPN, это проблема внезапно возникшего человека. У > которого нет в данный конкретный момент VPN. И с ним вопрос будет решен > индивидуально, как ему и мне удобнее. > Опять же: каковы условия? Есть пять человек, которым этот VPN нафиг не сдался. Онис гитом, например, работают. Всё по SSH, интерфейс по HTTPS. Зачем тут VPN? > Как правило таки файлы умещаются в обычный email. > > Всё остальное. Ну вопрос только к самой информации. Смотря что вы хотите > раздавать. > И это тоже: что и кому.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 12:59:41 +0300 artiom wrote: > 05.10.2018 23:06, D. H. пишет: > > On 05/10/18 02:45 PM, artiom wrote: > >> А от кого вы защищаться собрались? > > > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > > > - Вам есть что скрывать? > > - Нет, но мои данные не ваше дело. > > > Не в тему. > Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > Если вы этого не понимаете, то как вы определите перечень мер защиты? Защищаться надо 1. От пьяного тракториста, который переедет интернет кабель 2. От обкурившегося сетевого админа, который сломает роутинг. 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако может случайно попасть под раздачу, оказавшись в одном /16 блоке с телеграмовской прокси. 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. Определить от каких угроз несанкционированного доступа следует защищать данные, практически невозможно, если не знать характера данных. Потому что первым в списке угроз "будет плохо, если они прочитают ваши данные" стоит гугль, который использует данные для таржетированной рекламы. И при этом существует достаточно много данных, которые их владельцы старательно скармливают гуглю, чтобы они попали в результаты поиска.
Re: Доступ к медиатеке
05.10.2018 23:06, D. H. пишет: > On 05/10/18 02:45 PM, artiom wrote: >> А от кого вы защищаться собрались? > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > - Вам есть что скрывать? > - Нет, но мои данные не ваше дело. > Не в тему. Вопрос совершенно конкретный: "От кого вы собрались защищаться?" Если вы этого не понимаете, то как вы определите перечень мер защиты?
Re: Доступ к медиатеке
06.10.2018 00:13, D. H. пишет: > On 05/10/18 02:33 PM, artiom wrote: >> VPN привносит другие проблемы, которые мне не требуются. > > Ну со мной поделитесь, я пока не столкнулся но возможно удаться избежать > этого в будущем так как буду иметь в виду и думать над потенциальным > решением. > От задач. Если вы хотите, например, имея облако, отдать файл по ссылке кому-то постороннему. Как вы это сделаете, если NAS доступен только через VPN? Вы будете всех переводить на VPN? >> Не будем спорить. > > И не собирался. >
Re: Доступ к медиатеке
В Fri, 5 Oct 2018 16:12:50 + Коротаев Руслан пишет: > Victor Wagner пишет: > > > Каналий-посредников можно ограничить ролью канальных провайдеров. И > > доверять им не данные, а только передачу шифрованных пакетов. > > Если данные зашифрованы, почему бы не доверить им хранение. Главное > организовать безопасную передачу ключей и параметров доступа. Потому что данные нужно защищать в первую очередь не от того, чтобы они стали доступны другим, а от того, чтобы они стали недоступны вам. Если данные хранятся на вашей домашней машине у вас намного больше шансов что удастся до них добраться тогда. когда это перестанет возможным делать штатным образом. > > > Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была > > доступна из интернета. И в случае срабатывания intrusion detection > > последоватлельность действий была > > 1. Отключить сетевой кабель > > 2. Загрузиться с rescue cd > > 3. Разбираться. > > Вы же в курсе, что те, у кого есть физический доступ к вашей домашней > машине могут сделать тоже самое. А что делать тем, кому вы лично дали Именно это и хорошо. Потому что во-первых этот доступ есть у меня. Во-вторых, его практически невозможно получить так, чтобы это не стало мне известно. > доступ к вашим данным? Ждать пока вы разберетесь, тогда это трудно > назвать качественным сервисом. Вопрос в том, что мне гораздо быстрее сходить в магазин, купить новый жесткий диск и восстановить на него все с бэкапа, чем крупному облачному провайдеру рестартовать свою базу данных после некорректного завершения. Учитывая то, что у меня данных мало, а у него - много, у него WAL-ы дольше накатываться будут, чем у меня вся процедура восстановления пройдет. -- Victor Wagner
Re: Доступ к медиатеке
А от кого вы защищаться собрались? 05.10.2018 19:12, Коротаев Руслан пишет: > Victor Wagner пишет: > >> Каналий-посредников можно ограничить ролью канальных провайдеров. И >> доверять им не данные, а только передачу шифрованных пакетов. > > Если данные зашифрованы, почему бы не доверить им хранение. Главное > организовать безопасную передачу ключей и параметров доступа. > >> Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была >> доступна из интернета. И в случае срабатывания intrusion detection >> последоватлельность действий была >> 1. Отключить сетевой кабель >> 2. Загрузиться с rescue cd >> 3. Разбираться. > > Вы же в курсе, что те, у кого есть физический доступ к вашей домашней > машине могут сделать тоже самое. А что делать тем, кому вы лично дали > доступ к вашим данным? Ждать пока вы разберетесь, тогда это трудно > назвать качественным сервисом. >
Re: Доступ к медиатеке
05.10.2018 16:36, Коротаев Руслан пишет: > Igor Savluk пишет: > >> Да разворачивать php просто не охота :) > > PHP разворачивать не нужно если вы будете устанавливать Nextcloud через > snap-пакет, это такой специальный контейнер придуманный Canonical для > Ubuntu (для debian он тоже доступен). В snap всё идет в комплекте и PHP, > и JS, и всё что нужно (в инете много статей про snap). > Блин, я-то думал откуда эта трэш-мода пошла: вместо .deb выкладывать "self-hosted" приложение в виде бинаря, содержащего всё. Теперь ясно. Ubuntu. :-| >> Про minio знаю и пока его и использую. Просто инетесно а почему именно S3 >> для важных данных? Я думал очень важные данные нужно хранить на флешках под >> подушкой а не у дяди удаленного в облаке. > > А как дать (убрать) безопасный доступ к данным на флешке под подушкой? > Как безопасно хранить данные на флешке? Если шифровать, то как безопасно > хранить ключи? Допустим, вы знаете как хранить ключевой материал, а как > насчет того кому вы даете доступ? Вы уверены, что он придерживается > таких же стандартов информационной безопасности как и вы? > > Под подушкой хорошо хранить то, что используете только вы, а если вы > хотите организовать взаимодействие с другими людьми, без посредников не > обойтись. Вернее можно обойтись, но сложность организации > взаимодействия, перекроет все выгоды от использования ваших данных. > Сложность организации (и цена) могут вас устроить, если реализация угрозы потери данных будет намного дороже.
Re: Доступ к медиатеке
VPN привносит другие проблемы, которые мне не требуются. Не будем спорить. Сейчас я не вижу его, как вариант решения. 05.10.2018 14:39, D. H. пишет: > On 05/10/18 01:01 AM, artiom wrote: >> 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с >> данными через Интернет. >> 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без >> шифрования трафика, но только в сети машины. Т.е., я могу к нему >> обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не >> приходят. > > vpn решает обе проблемы. все будет везде и по человечески работать. >
Re: Доступ к медиатеке
Так не разворачивайте. Docker в помощь. Есть Seafile на C, кстати. 05.10.2018 15:50, Igor Savluk пишет: > Да разворачивать php просто не охота :) > > Про minio знаю и пока его и использую. Просто инетесно а почему именно > S3 для важных данных? Я думал очень важные данные нужно хранить на > флешках под подушкой а не у дяди удаленного в облаке. > > On 05/10/2018 13.17, Коротаев Руслан wrote: >> Igor Savluk пишет: >> >>> А есть подобная вещь но не на PHP? >> Я сам использую Minio-сервер [1] для неважных данных (расшарить через >> веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет >> управления пользователями. Точнее, оно особо и ненужно это же хранилище. >> Там есть Pre-Signed URL, просто не все пользователи понимают как это >> работает. Minio написан на Go >> >> Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера, >> там для доступа используются политики IAM, их можно сделать очень >> гибкими. >> >> Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам >> PHP-файлы править не придется, там большинство функций реализовано через >> веб-интерфейс. >> >> [1]: https://blog.kr.pp.ru/post/2017-07-25/ >> >
Re: Доступ к медиатеке
05.10.2018 13:17, Коротаев Руслан пишет: > Igor Savluk пишет: > >> А есть подобная вещь но не на PHP? > > Я сам использую Minio-сервер [1] для неважных данных (расшарить через > веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет > управления пользователями. Точнее, оно особо и ненужно это же хранилище. > Там есть Pre-Signed URL, просто не все пользователи понимают как это > работает. Minio написан на Go > > Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера, > там для доступа используются политики IAM, их можно сделать очень > гибкими. > > Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам > PHP-файлы править не придется, там большинство функций реализовано через > веб-интерфейс. > > [1]: https://blog.kr.pp.ru/post/2017-07-25/ > Всё тоже самое возможно сделать через Nextcloud. Кстати, у меня он стоит в их официальном docker-контейнере.
Re: Доступ к медиатеке
Вы не поверите. Я читал ещё ту вашу статью, ссылку на которую вы мне скидывали. И Nextcloud давным-давно стоит, и я им пользуюсь. Только это не silver bullet, всех задач не решает. Недавно брат загрузил видосы. Я их посмотреть не могу без скачивания. Ведь там AVI. Браузер не поддерживает, а "мы не будем включать, потому что вообще AVI скоро уйдёт". Вот Emby поддерживает. Но nextcloud хранит всё в каталогах пользователей. А пользователь может там держать любой трэш и ещё шифрование на клиенте включить (неизбирательное) и если я натравлю Emby на хранилище Nextcloud, там будет явно не то, что хочется увидеть. Кстати, он через свой LDAP у меня и авторизуется. 05.10.2018 12:22, Коротаев Руслан пишет: > artiom пишет: > >> Требуется организовать доступ к медиатеке, позволяющий нескольким >> пользователям переименовывать, удалять и, главное, добавлять файлы. >> >> Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о >> полноценном управлении, как файловой структурой, и говорить нечего. >> >> При этом, условие такого, что пользователи авторизуются через LDAP. >> >> Один из вариантов был - использовать файловые менеджеры в >> докер-контейнере, типа sprut.io, но с LDAP там всё плохо. >> Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и >> системный pam-ldap модуль. Но встали вопросы: как не дать пользователю >> выполнять команды и ограничить просмотр дерева не выше того каталога, в >> котором хранится медиатека? >> >> Есть какие-то варианты того, как эту задачу решают белые люди? >> Что посоветуете? >> И по pam-ldap вопросы тоже актуальны. > > Попробуйте Nextcloud [1], легко устанавливается через snap (через докер > тоже можно), есть LDAP, есть мобильные клиенты, можно даже видео > смотреть через браузер и музыку слушать. > > [1]: https://ru.wikipedia.org/wiki/Nextcloud >
Re: Доступ к медиатеке
Victor Wagner пишет: > Каналий-посредников можно ограничить ролью канальных провайдеров. И > доверять им не данные, а только передачу шифрованных пакетов. Если данные зашифрованы, почему бы не доверить им хранение. Главное организовать безопасную передачу ключей и параметров доступа. > Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была > доступна из интернета. И в случае срабатывания intrusion detection > последоватлельность действий была > 1. Отключить сетевой кабель > 2. Загрузиться с rescue cd > 3. Разбираться. Вы же в курсе, что те, у кого есть физический доступ к вашей домашней машине могут сделать тоже самое. А что делать тем, кому вы лично дали доступ к вашим данным? Ждать пока вы разберетесь, тогда это трудно назвать качественным сервисом. -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Доступ к медиатеке
On Fri, 5 Oct 2018 13:36:29 + Коротаев Руслан wrote: > > Под подушкой хорошо хранить то, что используете только вы, а если вы > хотите организовать взаимодействие с другими людьми, без посредников > не обойтись. Вернее можно обойтись, но сложность организации > взаимодействия, перекроет все выгоды от использования ваших данных. > Каналий-посредников можно ограничить ролью канальных провайдеров. И доверять им не данные, а только передачу шифрованных пакетов. Когда-то давно, примерно с 2001 до 2015 у меня домашняя машина была доступна из интернета. И в случае срабатывания intrusion detection последоватлельность действий была 1. Отключить сетевой кабель 2. Загрузиться с rescue cd 3. Разбираться. Сейчас, с тех пор как у моего провайдера появился IPv6, моя домашняя машина опять доступна из той части интернета, где есть IPv6.
Re: Доступ к медиатеке
Igor Savluk пишет: > Да разворачивать php просто не охота :) PHP разворачивать не нужно если вы будете устанавливать Nextcloud через snap-пакет, это такой специальный контейнер придуманный Canonical для Ubuntu (для debian он тоже доступен). В snap всё идет в комплекте и PHP, и JS, и всё что нужно (в инете много статей про snap). > Про minio знаю и пока его и использую. Просто инетесно а почему именно S3 > для важных данных? Я думал очень важные данные нужно хранить на флешках под > подушкой а не у дяди удаленного в облаке. А как дать (убрать) безопасный доступ к данным на флешке под подушкой? Как безопасно хранить данные на флешке? Если шифровать, то как безопасно хранить ключи? Допустим, вы знаете как хранить ключевой материал, а как насчет того кому вы даете доступ? Вы уверены, что он придерживается таких же стандартов информационной безопасности как и вы? Под подушкой хорошо хранить то, что используете только вы, а если вы хотите организовать взаимодействие с другими людьми, без посредников не обойтись. Вернее можно обойтись, но сложность организации взаимодействия, перекроет все выгоды от использования ваших данных. -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Доступ к медиатеке
Да разворачивать php просто не охота :) Про minio знаю и пока его и использую. Просто инетесно а почему именно S3 для важных данных? Я думал очень важные данные нужно хранить на флешках под подушкой а не у дяди удаленного в облаке. On 05/10/2018 13.17, Коротаев Руслан wrote: Igor Savluk пишет: А есть подобная вещь но не на PHP? Я сам использую Minio-сервер [1] для неважных данных (расшарить через веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет управления пользователями. Точнее, оно особо и ненужно это же хранилище. Там есть Pre-Signed URL, просто не все пользователи понимают как это работает. Minio написан на Go Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера, там для доступа используются политики IAM, их можно сделать очень гибкими. Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам PHP-файлы править не придется, там большинство функций реализовано через веб-интерфейс. [1]: https://blog.kr.pp.ru/post/2017-07-25/
Re: Доступ к медиатеке
Igor Savluk пишет: > А есть подобная вещь но не на PHP? Я сам использую Minio-сервер [1] для неважных данных (расшарить через веб-итерфейс корзину, дать ссылку на скачивание), так как у него нет управления пользователями. Точнее, оно особо и ненужно это же хранилище. Там есть Pre-Signed URL, просто не все пользователи понимают как это работает. Minio написан на Go Для важных данных рекомендую Amazon S3 с шифрованием на стороне сервера, там для доступа используются политики IAM, их можно сделать очень гибкими. Кстати, если вы будете устанавливать Nextcloud по умолчанию, вам PHP-файлы править не придется, там большинство функций реализовано через веб-интерфейс. [1]: https://blog.kr.pp.ru/post/2017-07-25/ -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Доступ к медиатеке
On Fri, 5 Oct 2018 12:30:44 +0300 Igor Savluk wrote: > А есть подобная вещь но не на PHP? Ну вот Apache CloudStack есть - на java. Правда, не знаю насколько он подобный. Но вроде storage management там есть. --
Re: Доступ к медиатеке
А есть подобная вещь но не на PHP? On 05/10/2018 12.22, Коротаев Руслан wrote: artiom пишет: Требуется организовать доступ к медиатеке, позволяющий нескольким пользователям переименовывать, удалять и, главное, добавлять файлы. Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о полноценном управлении, как файловой структурой, и говорить нечего. При этом, условие такого, что пользователи авторизуются через LDAP. Один из вариантов был - использовать файловые менеджеры в докер-контейнере, типа sprut.io, но с LDAP там всё плохо. Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и системный pam-ldap модуль. Но встали вопросы: как не дать пользователю выполнять команды и ограничить просмотр дерева не выше того каталога, в котором хранится медиатека? Есть какие-то варианты того, как эту задачу решают белые люди? Что посоветуете? И по pam-ldap вопросы тоже актуальны. Попробуйте Nextcloud [1], легко устанавливается через snap (через докер тоже можно), есть LDAP, есть мобильные клиенты, можно даже видео смотреть через браузер и музыку слушать. [1]: https://ru.wikipedia.org/wiki/Nextcloud
Re: Доступ к медиатеке
artiom пишет: > Требуется организовать доступ к медиатеке, позволяющий нескольким > пользователям переименовывать, удалять и, главное, добавлять файлы. > > Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о > полноценном управлении, как файловой структурой, и говорить нечего. > > При этом, условие такого, что пользователи авторизуются через LDAP. > > Один из вариантов был - использовать файловые менеджеры в > докер-контейнере, типа sprut.io, но с LDAP там всё плохо. > Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и > системный pam-ldap модуль. Но встали вопросы: как не дать пользователю > выполнять команды и ограничить просмотр дерева не выше того каталога, в > котором хранится медиатека? > > Есть какие-то варианты того, как эту задачу решают белые люди? > Что посоветуете? > И по pam-ldap вопросы тоже актуальны. Попробуйте Nextcloud [1], легко устанавливается через snap (через докер тоже можно), есть LDAP, есть мобильные клиенты, можно даже видео смотреть через браузер и музыку слушать. [1]: https://ru.wikipedia.org/wiki/Nextcloud -- Коротаев Руслан https://blog.kr.pp.ru smime.p7s Description: S/MIME cryptographic signature
Re: Доступ к медиатеке
05.10.2018 09:23, Victor Wagner пишет: > On Fri, 5 Oct 2018 09:01:46 +0300 > artiom wrote: > >> 1. Windows клиентов пока нет. Но, в идеале, не хотелось бы >> привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше. > > sshfs нет почти нигде. В windows нет, в андроиде - нет. > Насчет MacOS не уверен, надо у коллег поспрашивать. Про экзотику типа > Solaris я и не говорю. > 1. Windows: https://nelsonslog.wordpress.com/2017/07/19/windows-sshfs-clients/ 2. Android: https://4pda.ru/forum/index.php?showtopic=730752 3. Для MacOS есть через аналог FUSE. 4. Solaris не использую. И вообще найти клиент на Solaris сложнее, чем sshfs под него. Плюс, есть плагины ко всяким файловым менеджерам, её поддерживающие. > webdav это не браузер (возможно к сожалению). То есть браузером в > лучшем случае получится читать файлы (если кто мне расскажет про плагин > к файрфоксу, превращающий его в файлменеджер для dav-сайта, буду > благодарен). А писать - либо davfs2, либо cadaver, либо какой-нибудь > файлменеджер. > Было такое: https://addons.mozilla.org/ru/firefox/addon/open-as-webfolder/ Но это не то, конечно. Но протокол несложный, возможно написать. >> 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с >> данными через Интернет. > > Это как раз то, для чего лично я использую webdav. Для менеджмента > файлов на сервере, располженном на хостинге. > Остаётся вопрос, как это поднять. > >> 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без >> шифрования трафика, но только в сети машины. Т.е., я могу к нему >> обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не >> приходят. > > А в общем и не надо. LDAP должен быть доступен серверному софту. > А клиент взаимодействует с сервером прикладного протокола. > Чай не Kerberos. > Нашёл пару решений. Одно на Apache: https://github.com/MrsKensington/docker-user-webdav-ldap Второе на nginx: https://github.com/jtilander/docker-webdav То, которое на Apache, - проще, хотя и тяжелее. Кроме того, будут домашние каталоги пользователей. Но там надо добавить в конфиг секцию Directory такую, чтобы был доступен один каталог для люого аутентифицированного пользователя. > >> >> Но, похоже, что WebDAV - вполне себе решение, смотрю. > > Крайне рекомендую задуматься над тем, чтобы использовать digest > authentication. Я правда сходу не понял, как в Apache подружить > mod_auth_digest и mod_authnz_ldap. А в nginx я вообще не очень > разбираюсь. Но точно знаю что по крайней мере с basic auth webdav в > nginx с LDAP работает. > > В перспективе расширения списка клиентских платформ это бы очень > пригодилось. > Пока я его не поднял, выбирать тип аутентификации рано, да и у меня обратный прокси, который всё гоняет через HTTPS, так что не столь важно.
Re: Доступ к медиатеке
On Fri, 5 Oct 2018 09:01:46 +0300 artiom wrote: > 1. Windows клиентов пока нет. Но, в идеале, не хотелось бы > привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше. sshfs нет почти нигде. В windows нет, в андроиде - нет. Насчет MacOS не уверен, надо у коллег поспрашивать. Про экзотику типа Solaris я и не говорю. webdav это не браузер (возможно к сожалению). То есть браузером в лучшем случае получится читать файлы (если кто мне расскажет про плагин к файрфоксу, превращающий его в файлменеджер для dav-сайта, буду благодарен). А писать - либо davfs2, либо cadaver, либо какой-нибудь файлменеджер. > 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с > данными через Интернет. Это как раз то, для чего лично я использую webdav. Для менеджмента файлов на сервере, располженном на хостинге. > 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без > шифрования трафика, но только в сети машины. Т.е., я могу к нему > обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не > приходят. А в общем и не надо. LDAP должен быть доступен серверному софту. А клиент взаимодействует с сервером прикладного протокола. Чай не Kerberos. > > Но, похоже, что WebDAV - вполне себе решение, смотрю. Крайне рекомендую задуматься над тем, чтобы использовать digest authentication. Я правда сходу не понял, как в Apache подружить mod_auth_digest и mod_authnz_ldap. А в nginx я вообще не очень разбираюсь. Но точно знаю что по крайней мере с basic auth webdav в nginx с LDAP работает. В перспективе расширения списка клиентских платформ это бы очень пригодилось. --
Re: Доступ к медиатеке
1. Windows клиентов пока нет. Но, в идеале, не хотелось бы привязываться к ОС. SSHFS есть почти везде, браузер - ещё лучше. 2. SAMBA - не вариант. Потому что, одна из основных задач - работа с данными через Интернет. 3. С LDAP тоже есть некоторая проблема. Сервер доступен, как plain без шифрования трафика, но только в сети машины. Т.е., я могу к нему обратиться с локалхоста, из докер-контейнеров, но снаружи запросы не приходят. Но, похоже, что WebDAV - вполне себе решение, смотрю. 05.10.2018 06:52, Victor Wagner пишет: > В Thu, 4 Oct 2018 20:44:38 +0300 > artiom пишет: > >> Требуется организовать доступ к медиатеке, позволяющий нескольким >> пользователям переименовывать, удалять и, главное, добавлять файлы. >> >> Медиатеку показываю, используя Emby, но с добавлением там всё плохо, >> а о полноценном управлении, как файловой структурой, и говорить >> нечего. >> >> При этом, условие такого, что пользователи авторизуются через LDAP. > > Я бы использовал webdav. С ним прозрачно работают файловые менеджеры, > причем не только в Linux, есть разнообразные командно-строчные > клиенты, его можно примонтировать через davfs. > > Ну и доступ управляется средствами веб-сервера. > > Правда, с LDAP тут есть > одна небольшая проблема - если есть windows-клиенты, то нужно либо > использовать digest аутентификацию (у windows, как всегда, свое > представление о security), либо править всем клиентам реестр. > > Еще можно раздать с помощью samba. Там тоже гибкости хватает, чтобы > сделать возможность нескольким пользователям ходить на разделяемый > ресурс с одним UID. Но вот ни разу не прикручивал к samba внешний LDAP. > > >
Re: Доступ к медиатеке
В Thu, 4 Oct 2018 20:44:38 +0300 artiom пишет: > Требуется организовать доступ к медиатеке, позволяющий нескольким > пользователям переименовывать, удалять и, главное, добавлять файлы. > > Медиатеку показываю, используя Emby, но с добавлением там всё плохо, > а о полноценном управлении, как файловой структурой, и говорить > нечего. > > При этом, условие такого, что пользователи авторизуются через LDAP. Я бы использовал webdav. С ним прозрачно работают файловые менеджеры, причем не только в Linux, есть разнообразные командно-строчные клиенты, его можно примонтировать через davfs. Ну и доступ управляется средствами веб-сервера. Правда, с LDAP тут есть одна небольшая проблема - если есть windows-клиенты, то нужно либо использовать digest аутентификацию (у windows, как всегда, свое представление о security), либо править всем клиентам реестр. Еще можно раздать с помощью samba. Там тоже гибкости хватает, чтобы сделать возможность нескольким пользователям ходить на разделяемый ресурс с одним UID. Но вот ни разу не прикручивал к samba внешний LDAP. -- Victor Wagner
Доступ к медиатеке
Требуется организовать доступ к медиатеке, позволяющий нескольким пользователям переименовывать, удалять и, главное, добавлять файлы. Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о полноценном управлении, как файловой структурой, и говорить нечего. При этом, условие такого, что пользователи авторизуются через LDAP. Один из вариантов был - использовать файловые менеджеры в докер-контейнере, типа sprut.io, но с LDAP там всё плохо. Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и системный pam-ldap модуль. Но встали вопросы: как не дать пользователю выполнять команды и ограничить просмотр дерева не выше того каталога, в котором хранится медиатека? Есть какие-то варианты того, как эту задачу решают белые люди? Что посоветуете? И по pam-ldap вопросы тоже актуальны.
