![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
День бэкапа
31 марта — это Международный день резервного копирования
Люди делятся на три категории: те, кто не делает бэкапы, кто делает - и те, кто теперь еще и периодически проверяет,что из бэкапа можно все восстановить.
а к какой категории принадлежите вы?
Люди делятся на три категории: те, кто не делает бэкапы, кто делает - и те, кто теперь еще и периодически проверяет,что из бэкапа можно все восстановить.
а к какой категории принадлежите вы?
Re: Restore backup on development server
>>>Почему?
Вы имеете в виду - дев машины или test environment?
На дев машины нельзя переносить данные и/или креды из прода категорически, в test env - нельзя в большинстве случаев, можно только если test env изолировано и менеджится так же как прод - чего почти никогда нет (и если вам кто-то рассказывает что мол тест у них изолирован как прод - в 99% это самообман).
>>>>>> Реальные рабочие данные из прод *никогда* нельзя выносить из прода
>>>Почему нет?
>>>Это же зависит от того, насколько высокие требования безопасности.
Безопасность Dev машин и тест env не нулевая (их тоже надо защищать), но по ряду обьективных причин дев машины просто невозможно защитить и мониторить на таком же уровне как и прод, для 99.9% тест env - аналогично.
Если интересно, я могу обьяснить подробней почему так.
Ну и если вы знаете способ(ы) как защитить dev машины на таком же уровне как прод (без создания капитальных проблем для девов) - я бы с удовольствием послушал, мне лично такие способы неизвестны.
...
В инфосеке это классика - неизменно популярный способ ломануть прод через атаку на тест инстансы и на дев машины, широко используется как ред тимами так и реальными атакерами.
Re: Restore backup on development server
Да development машины гораздо труднее защитить, чем production.
Но из этого же никак не следует, что production backup нельзя восстанавливать на development server.
Если утечка данных не катастрофична, то вполне можно и рискнуть ради удобства и скорости разработки и тестирования.
Re: Restore backup on development server
Я обычно думаю о таких вещах в терминах environments - есть Dev Environment где девелоперы ведут разработку и гоняют ранние тесты как часть процесса разработки - это включает Dev workstations, но может включать и например тестовые VMы используемые девами в процессе разработки, бывает в dev env есть и тестовый сервер используемый для экспериментов и местного тестирования. In terms of security, ключевыми характеристиками dev env является весьма свободный доступ без особых контролов - девы обычно имеют админ аккаунты (как правило необходимо для процесса разработки), могут использоваться всякие разные рандомные тулзы, network isolation как правило нет или она очень слабая, identity isolation разумеется тоже нет (и ни о каких secure admin workstations и речи быть не может), security monitoring рудиментарная (или вообще нет) и т.д.
Бывает еще integration testing env - отдельный env похожий на prod но предназначенный для полного тестирования. Тут секьюрити может быть чуть получше, но только чуть - много людей имеют standing admin access, могут использовать всякие рандомные тулзы (для дебаггинга), identity isolation нет, network isolation может быть а может и не быть, security monitoring обычно рудиментарная. Часто такие testing env еще и доступны из интернета (для полноценного тестирования часто это необходимо), что сильно повышает риски - а защит особо там нет.
Бывают конечно исключения, но в 95% случаев такой env - первый кандидат для атак.
Ну и есть Prod - тут все понятно - identity isolation, network isolation, жесткий контроль доступа (JIT etc.), полноценная security monitoring и т.п.
В рамках этой таксономи, чем является development server о котором вы говорили?
...
>>>Если утечка данных не катастрофична
Для практически любых компаний утечка данных кастомеров - одна из самых плохих возможных проблем, хуже чем утечка сорс кода. Утечка данных кастомеров у сколько-нибудь большой компании быстро попадет в новости. Да, и по нынешним правилам в большинстве западных стран - утечку данных пользователей держать в секрете невозможно, компании обязаны оповестить пользователей чьи данные утекли с понятными последствиями.
Понятно что если речь идет о каком-нибудь студенческом проекте а не о коммерческом сервисе то проблем намного меньше, но даже в студенческом проекте проблемы могут быть неиллюзорными, особенно если аттакеры ломанут прод используя информацию из тест env - что часто происходит.
Re: Restore backup on development server
Такой Dev Environment.
С полным доступом для разработчиков.
> Ну и есть Prod - тут все понятно - identity isolation, network isolation, жесткий контроль доступа (JIT etc.), полноценная security monitoring и т.п.
Такой строгий security - слишком дорого в большинстве случаев.
> Для практически любых компаний утечка данных кастомеров - одна из самых плохих возможных проблем, хуже чем утечка сорс кода.
Возможно, утечка данных customers -- хуже, чем утечка source code.
Но ещё хуже: неработающая функциональность (из-за того, что из-за чрезмерно задранной security, разработка становится слишком сложной и дорогой).
> Утечка данных кастомеров у сколько-нибудь большой компании быстро попадет в новости.
1) Только для больших компаний.
2) Попадает в новости и что?
Разве это как-то заметно снижает количество пользователей?
> Понятно что если речь идет о каком-нибудь студенческом проекте а не о коммерческом сервисе
Речь идет о малом бизнесе.
Re: Restore backup on development server
Я говорю о больших серьезных сервисах с множеством кастомеров - кстати в эту категорию входят не только сверх-большие компании вроде Гугла/Амазон/Микрософт/ФБ/etc. но и компании второго-третьего-четвертого плана у которых есть более-менее популярный сервис - в общем компании и сервисы которые что-то значат и представляют какую-то ценность которую надо защищать.
Малый бизнес и очень маленькие компании которые сделали какой-то свой интернет сервис никому не интересны и их никто специально не ломает - по принципу НеуловимогоДжо. Даже когда у них секьюрити очень слабая - это будет малозаметно (ну пока не грохнут залетные кулцхакеры, или пока компания не сделает что-то интересное и будет пытаться продать себя - тогда слабая безопасность им обойдется очень дорого:-) ).
...
Но в этом деле важно помнить что слабая секьюрити - это слабая секьюрити, и если ты принимаешь бизнес-решение жить со слабой секьюрити - это надо делать с открытыми глазами хорошо понимая реальное состояние дел.
Да, и как side note - сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет. Но для этого надо чтобы твои технари (хотя бы один-два из них) понимали как это собственно делается и что важно а что нет. Но нанять таких людей очень дорого, разве что если сам владелец малого бизнеса знает как и что делать...
Re: Restore backup on development server
Чем именно обойдётся маленькой компании, сделавшей что-то интересное - восстановление production backup в development environment?
> сделать нормальную секьюрити в маленьком сервисе абсолютно реально и не так уж дорого, и если сделана она правильно - существенного импакта на продуктивити не будет.
Чем же заменить восстановление production backup на development сервере с точки зрения тестирования ситуаций, которые требуют реалистичных данных?
> нанять таких людей очень дорого
Так "очень дорого" или "не так уж дорого"?
Re: Restore backup on development server
Компании дорого обойдется слабая секьюрити. Production backup в dev env - это просто один из простых способов опустить секьюрити прода до уровня dev env (что неадекватно для прод), кроме того думаю что у компании которая так делает там много и других секьюрити проблем.
...
Кстати, иллюстративный пример размера компании - если взять Dreamwidth Studios, то это (очень) малый бизнес - у них всего два (!) сотрудника и меньше чем $400K annual revenue, но при этом у них пара миллионов юзеров (включая нас:-) ), если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно.
>>>Так "очень дорого" или "не так уж дорого"?
Не так уж дорого сделать нормальную секьюрити сервиса даже в малом бизнесе, но очень дорого стоит нанять людей которые знают и понимают как это делать. Т.е. если сам владелец такого бизнеса имеет нужные знания и умения - все ОК, но если нет - то проблема.
Re: Restore backup on development server
Что именно "дорого обойдется", если восстанавливать production backup в development?
Какие конкретно последствия следует ожидать?
> если у Дрима утекут данные кастомеров или хакнут прод - будет неприятно и больно
Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?
Упадёт ли прибыльность Dreamwidth, хотя бы, на 10% ($40k = 10% от $400k/year)?
Re: Restore backup on development server
В чем это может конкретно проявиться если/когда такая маленькая компания сделает что-то интересное - две основных категории проблем:
1. Если такая компания смогла сделать что-то ценное (например - интересный сервис/продукт) и хочет теперь себя продать, то потенциальные покупатели обязательно устроят technical due diligence и проблемы с безопасностью раскопают очень быстро. По результатам due diligence потенциальный покупатель скорее всего либо потребует серьезную скидку (аргументируя необходимостью все это чинить), либо (в особо плохих случаях) просто откажется от покупки.
2. Если такая компания смогла сделать что-то ценное и ее сервис начал расти набирая юзеров, это быстро привлечет внимание хакеров которые пройдутся и проверят стандартные каналы взлома, и при слабой секьюрити ломанут такой сервис очень быстро. Причем я говорю о стандартных залетных кулцхакерах которые просто хотят сшибить денег с компании и/или ее юзеров, не о nation state хакерах (там своя специфика).
>>>Насколько больно это будет для Dreamwidth в пересчёте на потерянные $$$?
Судя по вашим вопросам - вам это все скорее всего не релевантно. А если вдруг получится у вас сделать какой-нибудь интересный сервис который наберет популярность - наймете знающих людей (или хотя бы консультантов) которые обьяснят что и как.
Re: Restore backup on development server
Потенциального покупателя никто не заставляет восстанавливать production backup в development environment.
Что здесь чинить-то?
> привлечет внимание хакеров которые пройдутся и проверят стандартные каналы взлома, и при слабой секьюрити ломанут такой сервис очень быстро.
Как ломанут?
Перекупят разработчиков, что ли?
Ну, допустим, перекупили. Как это транслируется в убытки?
Re: Restore backup on development server
Да и инфосек подавляющее большинство не понимает, даже софт девелоперы - девам обычно кажется что "ну вот сейчас пофиксим баг который эти долбодятлы нашли и все будет з.ебись", а секьюрити паттерны и полиси - это все от лукавого, безопасники мол так жеппу свою прикрывают :-)
Так сложилось что я непосредственно занимаюсь инфосеком, и много раз участвовал в due diligence стартапов. Но как наша беседа наглядно показывает, быстренько в двух словах обьяснить что там и как нереально, да и мне честно говоря это малоинтересно.
...
Постарайтесь нанять дева который инфосеком интересуется, а если вдруг получится сделать какой-нибудь интересный/ценный сервис - наймите людей с нужными знаниями.
Re: Restore backup on development server
Вместо того, чтобы прямо ответить на мой вопрос ("Как это транслируется в убытки?"), вы спорите с соломенным пугалом (strawman), которое сами и придумали.
Я хорошо знаю, что восстановление production backup на development environment - повышает security risks.
Но из этого же совсем не следует, что восстанавливать production backup на development environment никогда не надо.
Ведь есть и другие, более важные соображения [чем security] при разработке и поддержке продукта.
Re: Restore backup on development server
Нет, мне просто надоело пытаться что-то обьяснить человеку который явно не понимает что такое инфосек и как он собственно делается/от чего зависит. И проводить лекцию-семинар на тему "инфосек и implications для стартапов" я тоже не собираюсь :-)