chabapok | День бэкапа

31 марта — это Международный день резервного копирования

Люди делятся на три категории: те, кто не делает бэкапы, кто делает - и те, кто теперь еще и периодически проверяет,что из бэкапа можно все восстановить.

а к какой категории принадлежите вы?

Flat | Top-Level Comments Only

From:

dennisgorelik

> Dev Environment где девелоперы ведут разработку и гоняют ранние тесты

Такой Dev Environment.
С полным доступом для разработчиков.

> Ну и есть Prod - тут все понятно - identity isolation, network isolation, жесткий контроль доступа (JIT etc.), полноценная security monitoring и т.п.

Такой строгий security - слишком дорого в большинстве случаев.

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

Возможно, утечка данных customers -- хуже, чем утечка source code.
Но ещё хуже: неработающая функциональность (из-за того, что из-за чрезмерно задранной security, разработка становится слишком сложной и дорогой).

> Утечка данных кастомеров у сколько-нибудь большой компании быстро попадет в новости.

1) Только для больших компаний.
2) Попадает в новости и что?
Разве это как-то заметно снижает количество пользователей?

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

Речь идет о малом бизнесе.

From:

slider2

А, теперь понятно.

Я говорю о больших серьезных сервисах с множеством кастомеров - кстати в эту категорию входят не только сверх-большие компании вроде Гугла/Амазон/Микрософт/ФБ/etc. но и компании второго-третьего-четвертого плана у которых есть более-менее популярный сервис - в общем компании и сервисы которые что-то значат и представляют какую-то ценность которую надо защищать.

Малый бизнес и очень маленькие компании которые сделали какой-то свой интернет сервис никому не интересны и их никто специально не ломает - по принципу НеуловимогоДжо. Даже когда у них секьюрити очень слабая - это будет малозаметно (ну пока не грохнут залетные кулцхакеры, или пока компания не сделает что-то интересное и будет пытаться продать себя - тогда слабая безопасность им обойдется очень дорого:-) ).

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

Да, и как side note - сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет. Но для этого надо чтобы твои технари (хотя бы один-два из них) понимали как это собственно делается и что важно а что нет. Но нанять таких людей очень дорого, разве что если сам владелец малого бизнеса знает как и что делать...

From:

dennisgorelik

> что-то интересное и будет пытаться продать себя - тогда слабая безопасность им обойдется очень дорого

Чем именно обойдётся маленькой компании, сделавшей что-то интересное - восстановление production backup в development environment?

> сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет.

Чем же заменить восстановление production backup на development сервере с точки зрения тестирования ситуаций, которые требуют реалистичных данных?

> нанять таких людей очень дорого

Так "очень дорого" или "не так уж дорого"?

From:

slider2

>>>Чем именно обойдётся маленькой компании, сделавшей что-то интересное - восстановление production backup в development environment?

Компании дорого обойдется слабая секьюрити. Production backup в dev env - это просто один из простых способов опустить секьюрити прода до уровня dev env (что неадекватно для прод), кроме того думаю что у компании которая так делает там много и других секьюрити проблем.

...
Кстати, иллюстративный пример размера компании - если взять Dreamwidth Studios, то это (очень) малый бизнес - у них всего два (!) сотрудника и меньше чем $400K annual revenue, но при этом у них пара миллионов юзеров (включая нас:-) ), если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно.

>>>Так "очень дорого" или "не так уж дорого"?

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

From:

dennisgorelik

> Компании дорого обойдется слабая секьюрити.

Что именно "дорого обойдется", если восстанавливать production backup в development?
Какие конкретно последствия следует ожидать?

> если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно

Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?
Упадёт ли прибыльность Dreamwidth, хотя бы, на 10% ($40k = 10% от $400k/year)?

From:

slider2

Дорого обойдется слабая security. Порочная практика выноса данных кастомеров из прода - опасна сама по себе (там есть целый ряд векторов), кроме того - компания в которой практикуют такие вещи скорее всего имеет проблемы с инфосеком, и если чуть копнуть - там скорее всего найдется еще много чего.

В чем это может конкретно проявиться если/когда такая маленькая компания сделает что-то интересное - две основных категории проблем:

1. Если такая компания смогла сделать что-то ценное (например - интересный сервис/продукт) и хочет теперь себя продать, то потенциальные покупатели обязательно устроят technical due diligence и проблемы с безопасностью раскопают очень быстро. По результатам due diligence потенциальный покупатель скорее всего либо потребует серьезную скидку (аргументируя необходимостью все это чинить), либо (в особо плохих случаях) просто откажется от покупки.

2. Если такая компания смогла сделать что-то ценное и ее сервис начал расти набирая юзеров, это быстро привлечет внимание хакеров которые пройдутся и проверят стандартные каналы взлома, и при слабой секьюрити ломанут такой сервис очень быстро. Причем я говорю о стандартных залетных кулцхакерах которые просто хотят сшибить денег с компании и/или ее юзеров, не о nation state хакерах (там своя специфика).

>>>Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?

Судя по вашим вопросам - вам это все скорее всего не релевантно. А если вдруг получится у вас сделать какой-нибудь интересный сервис который наберет популярность - наймете знающих людей (или хотя бы консультантов) которые обьяснят что и как.

From:

dennisgorelik

> По результатам due diligence потенциальный покупатель скорее всего либо потребует серьезную скидку (аргументируя необходимостью все это чинить)

Потенциального покупателя никто не заставляет восстанавливать production backup в development environment.
Что здесь чинить-то?

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

Как ломанут?
Перекупят разработчиков, что ли?

Ну, допустим, перекупили. Как это транслируется в убытки?

From:

slider2

Судя по вашим вопросам - вы несколько непонимаете как это все происходит и работает, и в области инфосека и в области оценки и покупок стартапов. В этом нет ничего плохого и обидного - это области специфические, особенно due diligence и аудит стартапов.

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

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

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

From:

dennisgorelik

> а секьюрити паттерны и полиси - это все от лукавого, безопасники мол так жеппу свою прикрывают :-)

Вместо того, чтобы прямо ответить на мой вопрос ("Как это транслируется в убытки?"), вы спорите с соломенным пугалом (strawman), которое сами и придумали.
Я хорошо знаю, что восстановление production backup на development environment - повышает security risks.
Но из этого же совсем не следует, что восстанавливать production backup на development environment никогда не надо.
Ведь есть и другие, более важные соображения [чем security] при разработке и поддержке продукта.

From:

slider2

>>>Вместо того, чтобы прямо ответить на мой вопрос ("Как это транслируется в убытки?"), вы спорите с соломенным пугалом (strawman), которое сами и придумали.

Нет, мне просто надоело пытаться что-то обьяснить человеку который явно не понимает что такое инфосек и как он собственно делается/от чего зависит. И проводить лекцию-семинар на тему "инфосек и implications для стартапов" я тоже не собираюсь :-)