Про удаление файлов — читал несколько статей по архитектуре высоконагруженных сервисов, типа социальных сетей и т. п. С определённого уровня нагрузки практически все переходят на использование БД в качестве движка хранения, в том числе для файлов. И там удаление — довольно ресурсозатратная операция — там и проблемы с фрагментацией и масса всякого.
В целом я с Вами согласен, просто рассматривал использование такого сервиса с точки зрения рисков для ИБ.
Seafile, кстати, довольно стабильная штука. Я эксплуатирую несколько инстансов (домашнее облака и два корпоративных) — вообще никаких проблем. Обновления плановые провожу, не более. Хотя корпоративными пользуются человек 500, наверное, и суммарный объём уже с десяток терабайт.
РКН прямым текстом говорит: «провайдер должен резолвить домены сам». А про «некорректный резолв» РКН только в прессе пишет, когда отмазывается после вот таких вот случаев, который в посте описан.
Вот тут РКН пишет про «некорректный резолвинг». На этой же странице даётся ссылка на «Рекомендации по блокировке для операторов», при попытке перехода на которую отдаётся 404.
В редакции «Рекомендаций» от 2013 года было указано, что оператор должен резолвить домены сам, и не полагаться на поле «IP» в списке блокировки.
А теперь оператор должен изогнуться ещё хлеще:
Рекомендации Роскомнадзора продиктованы интересами пользователей и направлены на исключение избыточной блокировки добропорядочных ресурсов. В частности, при самостоятельном определении оператором связи IP-адреса запрещенного интернет-ресурса, провайдерам рекомендовано проверять, не попадут ли под блокировку популярные и общественно значимые сайты и их IP-адреса .
Вы правы, риски невелики. Но они, тем не менее, есть.
Например, есть класс атак, называемый «атака на цепочку поставки». И комментаторы выше правы — в результате вам в браузер может прилетать несколько модифицированный Javascript, не такой, как выложен в репозитории.
Отдельным клиентам, в которых заинтересованы трёхбуквенные третьи лица, сам сервер может отдавать модифицированный код. Вы же не будете каждый раз перед заливкой файла проверять, с какими параметрами шифруется файл, правда? А всем остальным клиентам, к которым нет интереса, будет отдавать ровно то, что в гитхабе лежит. Трудно такое поймать, если это разовые, адресные акции.
Также есть атаки на сам браузер, и потенциально есть возможность изменить код прямо в клиентском браузере, ослабив шифрование или заменив его на XOR.
В общем, обмениваясь реально значимой секретной информацией, нужно подобные риски иметь в виду. В целом, для меня анонс такого сервиса выглядит несколько странным, т. к. есть штуки типа Seafile, Ownckoud/Nextcloud, где этот функционал тоже есть, среди прочего, а также есть возможность отправки шифрованных сообщений по e-mail, да даже зашифрованные архивы, в конце концов, которые тоже расколоть не так уж просто.
Плюс если раздавать зашифрованные архивы, они не скапливаются на каком-то одном конкретном стороннем сервисе, а пользователь можей выбрать любой файлообменник (или почту), поди ещё слови этот архив. А тут — заявляется, что «вот, у нас секурная организация файлообмена, кидайте нам свои файлы!». И к бабке не ходи, файлы не будут физически удаляться после истечения срока их размещения, т. к. это накладная операция на больших объёмах. Фейсбук или VK не удаляют, например. Точнее, удаляют, но в рамках процедур housekeeping, и по факту «удалённые» файлы физически лежат на месте и теоретически могут быть доступны по несколько месяцев.
Цитирую:
«The U.S. military blocked Internet access to an infamous Russian entity seeking to sow discord among Americans during the 2018 midterms, several U.S. officials said, a warning that the Kremlin’s operations against the United States are not cost-free.»
То есть, официальная структура Министерства обороны США подломила инфраструктуру питерского офиса российской общественной организации, лишив таким образом организацию выхода в интернет на несколько дней.
Что имеется в виду под этими датами — вопрос тёмный. Это может быть дата проникновения, или дата обнаружения. А за какое время были вытащенные данные в реальности — неизвестно. Ну и сильно зависит от трафика. Если у компании 10G на выходе, то плюс-минус один гигабит будет не очень заметно. А на гигабите вытащить 10 Тб можно за сутки. К тому же, я думаю, у Citrix на бордерах их сети может и поболе 10G будет.
Я бы ещё добавил, что практически любая европейская страна будет «дружить» с США практически любой ценой.
Например, одно время работал с организацией, которая занималась поставками комплекса для разработки систем промышленной автоматизации, германского производства. Ну и пересекался несколько раз с разработчиками комплекса и руководством их фирмы на всяких промо-мероприятиях.
Немцы прямым текстом говорили примерно следующее, в ответ на вопросы, почему немцы терпят, когда США их заставляют принимать явно невыгодные решения (события 2014-16 годов, все эти санкции, которые компании типа Siemens и их подобные должны были применить к России, и соответственно, сильно потерять в деньгах, миллиардные штрафы Дойче Банку за «обход санкций США» и т. п.): «Ну а что вы хотите? Германия до сих пор оккупированная страна. У нас полно американских военных баз, и ничего мы сделать не можем. Но если Штаты пошатнутся — Германия будет одной из первых стран, которая воткнёт нож им в спину».
При использовании софта не бывает, чтобы «потом просто пользоваться продуктом» — саппорт и доработка будут необходимы в течение всего периода эксплуатации. Потому что баги в софте есть всегда, и иногда встречаются настоящие шоу-стопперы. И риски безопасности тоже никуда не деваются, поэтому нужно своевременно и регулярно (!) делать, выпускать и ставить заплатки безопасности. Ну и требования к ПО постоянно меняются — нужны новые функции, новые форматы данных, меняется workflow в связи с изменениям бизнес-процессов заказчика.
Если в случае платного софта понятно, кто будет всем этим заниматься (вендор), то в случае опенсорса кто будет это делать? Придётся либо заключать договора (за деньги) с командой, которая разрабатывает конкретный софт, либо создавать свою команду и организовывать процесс разработки (а компетенции в этом вопрос у госорганов, например — около-нулевые, если не вообще отрицательные). В любом случае, экономии не получится, а «заплатить разово денег» — не получится тем более. Деньги будут требоваться постоянно. Выбирая опенсорс — заказчик может снизить CapEx (и то не факт — это же нужно ещё спланировать и реализовать переход с текущего софта), но существенно увеличивает OpEx, так что на достаточно продолжительном историческом этапе эксплуатация опенсорса запросто может оказаться многократно дороже проприетарного софта.
Кстати, там не обязательно и опенсорс. Есть, например, Kaspersky OS. Она написана с нуля (т. е. это не форк линукса или какой-то другой существующей ОС) и как раз позиционируется как система для embedded-решений.
Ещё интересна строчка «Кибератаки» и цифра «20» в колонке 2018-го года. Это 20 кибератак за весь год по всему рунету? Мягко говоря, это неверная информация.
Я описал, почему я иногда закрываю заявки по формальному признаку. Нормально сформулированные заявки, которые содержат всю необходимую информацию — просто берутся и делаются. Это к вопросу о «всех» или «не всех» разработчиках.
Разумеется, в идеальном мире процесс построен так, что все заявки содержат максимум информации, требуемой для её выполнения. ИБ-шники не затягивают гайки сверх меры, и всегда аргументированно мотивируют свои решения. А руководство рулит мудро и справедливо, и никто в компании не стремится скидывать свою работу на других. Но мы не в идеальном мире, к сожалению.
Сферы ответственности между командами устанавливают не разработчики и не инженеры. А руководство отделов, департаментов или всей компании, в зависимости от размера.
Компетентность других команд компании — это тоже не зона ответственности команды IT ops.
Что касается раннеров и т. п., то тут вопрос не столько компетентности, сколько желания скинуть свою работу на других. Доступа нет --> это что-то с сетями --> надо создать заявку в IT ops, пусть разбираются. Собственно, однострочные заявки безо всяких подробностей тоже генерируются именно поэтому — лень собраться с мыслями и расписать всё подробно. «У меня возникла проблема, я её скинул в сервисдеск, теперь это не моя проблем». В таком духе.
Поэтому всё, что может инженер в подобных ситуациях — закрывать заявки по формальным критериям, в надежде, что рано или поздно до конкретной команды дойдёт, что надо сразу предоставлять инфрмацию, необходимую для решения заявки, без необходимости вытягивать всё клещами. Я подчёркиваю — не для принятия решения «давать или не давать доступ», а вообще для необходимой для реализации.
Вы правда считаете, что разработчик, который в жизни ничего сложнее девелоперского стенда не настраивал, лучше знает, как управлять инфраструктурой в сотни сетей и тысячи виртуальных хостов, чем инженер, который этим занимается уже N лет?
И причём тут вообще «решение, нужно ли ему выдать доступ»? Я говорил о том, что заявки формулируются так, как я написал. Т. е. в тексте заявки одна единственная фраза: «Прошу выдать доступ к стенду XYZ». Кому выдать, откуда выдать, что это за стенд и по каким протоколам нужен доступ — ни слова. Принятие решения «выдавать — не выдавать» — за ИБ, разумеется, вместе с руководителем проекта. Но чтобы «выдавать», нужно знать, кому, куда, откуда и какой транспорт. Об этом, повторюсь, в заявке — ни слова.
Более того, вот из недавнего. Реальный пример. Приходит заявка: «Не можем задеплоить на стенд такой-то — со стенда нет доступа к gitlab runner'aм». Опять-таки, без подробностей. Начинаем выяснять, где вообще развёрнуты раннеры. Получаем гениальный ответ: «Я не знаю, я просто всё настроил, нажимаю кнопку Deploy, и всё обламывается». Команда DevOps (в управлении которой находится инфраструктура CI/CD, тоже не смогла ответить, с какого из раннеров идёт поставка. Даже подсети не смогли назвать. Пришлось выпиливать учётки на сервера стенда для инженера IT и tcpdump'ом смотреть, долетает ли трафик, и если да, то откуда он идёт. А вы говорите — «дайте разрабам доступ, они сами всё сделают». Разработчиков ничего не интересует, кроме написания кода, поэтому все системы разграничения прав, защиты и т. п. ими просто отключаются.
Отсюда простой вывод — программистам не стоит учить инженеров, как делать инженерную работу. А инженеры, в свою очередь, не будут указывать программистам, как надо писать код.
Потому что у сотрудника 100 и 1 способ попасть на прод, если он злоумышленник и
Вы были на Highload++ 2018? Там был интересный доклад от До-до пиццы, где докладчик описывал их мучения с доступом к серверам инфраструктуры. У меня в голове роилось множество вопросов в духе «Как? Зачем вы так делали?! Но есть же!.. Ну и зачем было создавать себе такие проблемы, когда можно...»
После доклада после ряда уточняющих вопросов первый же вопрошающий сказал: «В общем, понятно. Это история про то, как программисты настраивали сети». Фраза целиком и полностью описывает всю суть этой ветки комментариев :-)
Скажем так: кроме СБТ, у Сбера есть ещё дочерние компании :-) Нашу компанию недавно подключили к сберовской системе ДМС, поэтому пришлось разбираться со страховками, воспоминания ещё свежи :-)
Насчёт ДМС автор прав. Есть схема, которая называется «сооплатная». Можно перейти на эту схему, получив доступ к клиникам, которые доступны с высокого грейда, и ещё включить в страховку родственников. Но при переходе на сооплатную схему вам придётся оплачивать 20% от медицинских расходов, если таковые произойдут по ДМС. Остальные 80% платит страховая.
Ну и даже при сооплатной схеме 100% экстренной помощи оплачивает страховая.
Например, вот:
habr.com/ru/post/120918
habr.com/ru/company/oleg-bunin/blog/313364
В целом я с Вами согласен, просто рассматривал использование такого сервиса с точки зрения рисков для ИБ.
Seafile, кстати, довольно стабильная штука. Я эксплуатирую несколько инстансов (домашнее облака и два корпоративных) — вообще никаких проблем. Обновления плановые провожу, не более. Хотя корпоративными пользуются человек 500, наверное, и суммарный объём уже с десяток терабайт.
Вот тут РКН пишет про «некорректный резолвинг». На этой же странице даётся ссылка на «Рекомендации по блокировке для операторов», при попытке перехода на которую отдаётся 404.
В редакции «Рекомендаций» от 2013 года было указано, что оператор должен резолвить домены сам, и не полагаться на поле «IP» в списке блокировки.
А теперь оператор должен изогнуться ещё хлеще:
Например, есть класс атак, называемый «атака на цепочку поставки». И комментаторы выше правы — в результате вам в браузер может прилетать несколько модифицированный Javascript, не такой, как выложен в репозитории.
Отдельным клиентам, в которых заинтересованы
трёхбуквенныетретьи лица, сам сервер может отдавать модифицированный код. Вы же не будете каждый раз перед заливкой файла проверять, с какими параметрами шифруется файл, правда? А всем остальным клиентам, к которым нет интереса, будет отдавать ровно то, что в гитхабе лежит. Трудно такое поймать, если это разовые, адресные акции.Также есть атаки на сам браузер, и потенциально есть возможность изменить код прямо в клиентском браузере, ослабив шифрование
или заменив его на XOR.В общем, обмениваясь реально значимой секретной информацией, нужно подобные риски иметь в виду. В целом, для меня анонс такого сервиса выглядит несколько странным, т. к. есть штуки типа Seafile, Ownckoud/Nextcloud, где этот функционал тоже есть, среди прочего, а также есть возможность отправки шифрованных сообщений по e-mail, да даже зашифрованные архивы, в конце концов, которые тоже расколоть не так уж просто.
Плюс если раздавать зашифрованные архивы, они не скапливаются на каком-то одном конкретном стороннем сервисе, а пользователь можей выбрать любой файлообменник (или почту), поди ещё слови этот архив. А тут — заявляется, что «вот, у нас секурная организация файлообмена, кидайте нам свои файлы!». И к бабке не ходи, файлы не будут физически удаляться после истечения срока их размещения, т. к. это накладная операция на больших объёмах. Фейсбук или VK не удаляют, например. Точнее, удаляют, но в рамках процедур housekeeping, и по факту «удалённые» файлы физически лежат на месте и теоретически могут быть доступны по несколько месяцев.
Т. к. шифрование может быть реализовано с ошибками, либо параметры работы алгоритма подобраны таким образом, чтобы его проще было вскрыть.
А то, что некоммерческая организация… Если придут люди из трёхбуквенной конторы, то без разницы, коммерческая это организация или нет.
Я просто оставлю это здесь.
Цитирую:
«The U.S. military blocked Internet access to an infamous Russian entity seeking to sow discord among Americans during the 2018 midterms, several U.S. officials said, a warning that the Kremlin’s operations against the United States are not cost-free.»
То есть, официальная структура Министерства обороны США подломила инфраструктуру питерского офиса российской общественной организации, лишив таким образом организацию выхода в интернет на несколько дней.
Microsoft уже давно предоставляет исходники для аудита. Что-то не видно пока ещё на внутреннем рынке «отечественного аналога».
Импорт — из США 61.6 млрд, из России — 21.9 млрд, разница 3 раза. Тоже не на порядок.
Другой вопрос, что у Штатов возможностей Германии жизнь испортить куда как больше, чем у России… :-)
Например, одно время работал с организацией, которая занималась поставками комплекса для разработки систем промышленной автоматизации, германского производства. Ну и пересекался несколько раз с разработчиками комплекса и руководством их фирмы на всяких промо-мероприятиях.
Немцы прямым текстом говорили примерно следующее, в ответ на вопросы, почему немцы терпят, когда США их заставляют принимать явно невыгодные решения (события 2014-16 годов, все эти санкции, которые компании типа Siemens и их подобные должны были применить к России, и соответственно, сильно потерять в деньгах, миллиардные штрафы Дойче Банку за «обход санкций США» и т. п.): «Ну а что вы хотите? Германия до сих пор оккупированная страна. У нас полно американских военных баз, и ничего мы сделать не можем. Но если Штаты пошатнутся — Германия будет одной из первых стран, которая воткнёт нож им в спину».
Если в случае платного софта понятно, кто будет всем этим заниматься (вендор), то в случае опенсорса кто будет это делать? Придётся либо заключать договора (за деньги) с командой, которая разрабатывает конкретный софт, либо создавать свою команду и организовывать процесс разработки (а компетенции в этом вопрос у госорганов, например — около-нулевые, если не вообще отрицательные). В любом случае, экономии не получится, а «заплатить разово денег» — не получится тем более. Деньги будут требоваться постоянно. Выбирая опенсорс — заказчик может снизить CapEx (и то не факт — это же нужно ещё спланировать и реализовать переход с текущего софта), но существенно увеличивает OpEx, так что на достаточно продолжительном историческом этапе эксплуатация опенсорса запросто может оказаться многократно дороже проприетарного софта.
os.kaspersky.com
Разумеется, в идеальном мире процесс построен так, что все заявки содержат максимум информации, требуемой для её выполнения. ИБ-шники не затягивают гайки сверх меры, и всегда аргументированно мотивируют свои решения. А руководство рулит мудро и справедливо, и никто в компании не стремится скидывать свою работу на других. Но мы не в идеальном мире, к сожалению.
Сферы ответственности между командами устанавливают не разработчики и не инженеры. А руководство отделов, департаментов или всей компании, в зависимости от размера.
Компетентность других команд компании — это тоже не зона ответственности команды IT ops.
Что касается раннеров и т. п., то тут вопрос не столько компетентности, сколько желания скинуть свою работу на других. Доступа нет --> это что-то с сетями --> надо создать заявку в IT ops, пусть разбираются. Собственно, однострочные заявки безо всяких подробностей тоже генерируются именно поэтому — лень собраться с мыслями и расписать всё подробно. «У меня возникла проблема, я её скинул в сервисдеск, теперь это не моя проблем». В таком духе.
Поэтому всё, что может инженер в подобных ситуациях — закрывать заявки по формальным критериям, в надежде, что рано или поздно до конкретной команды дойдёт, что надо сразу предоставлять инфрмацию, необходимую для решения заявки, без необходимости вытягивать всё клещами. Я подчёркиваю — не для принятия решения «давать или не давать доступ», а вообще для необходимой для реализации.
И причём тут вообще «решение, нужно ли ему выдать доступ»? Я говорил о том, что заявки формулируются так, как я написал. Т. е. в тексте заявки одна единственная фраза: «Прошу выдать доступ к стенду XYZ». Кому выдать, откуда выдать, что это за стенд и по каким протоколам нужен доступ — ни слова. Принятие решения «выдавать — не выдавать» — за ИБ, разумеется, вместе с руководителем проекта. Но чтобы «выдавать», нужно знать, кому, куда, откуда и какой транспорт. Об этом, повторюсь, в заявке — ни слова.
Более того, вот из недавнего. Реальный пример. Приходит заявка: «Не можем задеплоить на стенд такой-то — со стенда нет доступа к gitlab runner'aм». Опять-таки, без подробностей. Начинаем выяснять, где вообще развёрнуты раннеры. Получаем гениальный ответ: «Я не знаю, я просто всё настроил, нажимаю кнопку Deploy, и всё обламывается». Команда DevOps (в управлении которой находится инфраструктура CI/CD, тоже не смогла ответить, с какого из раннеров идёт поставка. Даже подсети не смогли назвать. Пришлось выпиливать учётки на сервера стенда для инженера IT и tcpdump'ом смотреть, долетает ли трафик, и если да, то откуда он идёт. А вы говорите — «дайте разрабам доступ, они сами всё сделают». Разработчиков ничего не интересует, кроме написания кода, поэтому все системы разграничения прав, защиты и т. п. ими просто отключаются.
Отсюда простой вывод — программистам не стоит учить инженеров, как делать инженерную работу. А инженеры, в свою очередь, не будут указывать программистам, как надо писать код.
Вы были на Highload++ 2018? Там был интересный доклад от До-до пиццы, где докладчик описывал их мучения с доступом к серверам инфраструктуры. У меня в голове роилось множество вопросов в духе «Как? Зачем вы так делали?! Но есть же!.. Ну и зачем было создавать себе такие проблемы, когда можно...»
После доклада после ряда уточняющих вопросов первый же вопрошающий сказал: «В общем, понятно. Это история про то, как программисты настраивали сети». Фраза целиком и полностью описывает всю суть этой ветки комментариев :-)
Ну и даже при сооплатной схеме 100% экстренной помощи оплачивает страховая.