Обновить

AWS удалил мой 10‑летний аккаунт и все данные без предупреждения

Уровень сложностиПростой
Время на прочтение11 мин
Охват и читатели13K
Всего голосов 47: ↑46 и ↓1+65
Комментарии68

Комментарии 68

Все просто: ценное - в бэкапы, а облако пусть будет запасным, а не единственным местом хранения.

Доверять облакам чувствительные данные, так себе идея. Спасибо автору перевода. Надеюсь люди будут учиться не только на своих ошибках.

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

Очередной классический пример, что данные в облаке тебе не принадлежат и ты их не контролируешь.

Да проблема же не в облаке. Ну хранил бы автор всё дома, идеально же, принадлежат только ему, да? Но скачок напряжения - и материнка утягивает SSD с единственной копией данных за собой. Или соседи залили, попало прямо на HDD - тоже хана. Важные данные всегда должны быть забэкаплены где-то ещё.

Проблема технического характера решается в дублировании.
Проблема не-технического характера не решается дублированием, что на примере автора мы и видим.

Так автор и не дублировал. Иначе бы проблемы как таковой и не было.

Сложно дублировать учетку. пожал плечами

Можно сделать гетерогенную структуру с 3 разными провайдерами, но возникает нюансик, что поддерживать гетерогенную структуру будет сильно дороже, и по времени и по деньгам, а он не компания-единорог, а просто Вася Джон, который ночью пилит руби-библиотеки.

>> Сложно дублировать учетку.

Нашлась единая точка отказа и именно она выстрелила.

Законы Мёрфи в действии, да.

В данном случае тоже можно решить дублированием, multicloud называется. Вполне себе применяется.

Дома ненадёжно и неудобно. Я, например, просто храню условно-синхронные бекапы в трёх разных облаках в двух разных юрисдикциях в зашифрованном виде. Все три облака одновременно не "лягут".

Главное что бы интернет не отключили. А то был у меня опыт с облаками и интернетом.

Проблема не в облаке, а в том, что автор хранил данные в одном месте. И пофиг, где оно - дома или у провайдера. И что у провайдера оно географически разнесено, это не повод надеяться на то, что всё будет в порядке. Копия на стороне нужна всегда.

Никогда такого не было, и вот опять!

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

Ладно, тут человеческая ошибка. А что делать когда датацентр сгорает? Физически. Там, даже при желании, уже ничего не восстановить.

Сгоревший ДЦ - это не проблема. Это отлично решается технически. Н географически разнесенных ДЦ стандарт отрасли. А вот процессы компании, человеческий фактор и прочие момента - да, это критично. По велению левой ноги могут удалить и не поперхнуться

Вот он пример "RAID - не бэкап". Точно такой же вектор логической ошибки.

Но ведь Raid, в зависимости от версии, конечно, и правда не бекап. . .

RAID не является бэкапом вне зависимости от версии.

Одна из задач бэкапа - восстановление данных в ситуации их удаления или затирания, а RAID любой версии радостно удаляет или затирает вместе с данными все их копии автоматически.

Я удалял аккаунты AWS (в AWS Organizations). Могу подтвердить - удаленный аккаунт находится на холде 90 дней. пользоваться им нельзя, он виден в списке как удаленный, другой такой же с таким именем создать нельзя. Аккаунт восстанавливается через поддержку в случае надобности. Мне кажется, что поддержка в описанном случае оказалась некомпетентной и нужно эскалировать запрос.

UPDATE. отвратительная привычка писать комментарий, не дочитав пост до конца. рад, что все хорошо закончилось.

В случае автора его как раз саппор и кормил ответами, из которых следовало что "выбросила в пропасть"

И, читая продолжение истории - может на их уровне так и смотрелось, "чужой аккаунт, погашен весь, отделить нельзя - значит, всё уничтожено", пока в проблему не подключился уровень сильно выше. А может и не смотрелось, тогда брр с таким саппортом общаться.

Вы часто общаетесь с сапортом? Раз нцать с сапортом корпоративного провайдера. Личный номер дозвон 24/7 Пару раз с хостерами, остался довольным! Кроме самого популярного в России! Это кромешный Ад! Что то я ушел от темы! И вот у нашей компании появился заказ на каких то 20 воркстейшенов от Dell. Сверили Compatible с сайтом производителя. Сделали заявку местному дистрибьютору. Но с клиентом оговорили смену проца, точно не помню I5 13 поколение, но он был эффективней I7 14 (брали I7 14 поколения, были клиенты отдельно и на процы), доустановку памяти, hdd ,видео карты ( кстати доустановка видюхи, смена блока питания, а там он не стандартный ). И так собрал, а хрен там. Комп не видит проца, вернул. Вернул взад I7 прошил UEFI. Я в первый раз увидел такой размер порядка 200МБ. Я в шоке был когда в первые 8мб увидел. Опять отвлекся :))) обновился хрен там не плавал. Вот тут вернусь к статье! 20 дней! 20 дней! 20 дней! Когда начал читать статью и увидел, что переписка длилась 20 дней! Я привстал! Потому что меня в сапорте Dell футболили 3 индуса 4 часа! Они мне задали 1000500000 вопросов, около да не про процессор. 3 меня спрашивает, а где купили отвечаю какая разница купил на базаре в Мумбаи, их у меня в компании 120 штук все рабочие! Перепроверил совместимость других, их того что на сайте ИМЕННО тот который мне нужен, не работает. У меня серьезное попадлово! После 4х часов и передачи информации на верх, ответ был что процы куплены не у них потому ни чем помочь не могут! Все процы проверены были! На других мамках! 100% рабочие! Надо кстати поднять еще раз модель и перепроверить , на сайте висит или нет этот I5.

PS Не плохой перевод, но автору НАДО УКАЗЫВАТЬ, что это именно перевод в начале! Не стал писать коммент пока не прочел до конца. Скорее всего Reddita слямзал.

автору НАДО УКАЗЫВАТЬ, что это именно перевод в начале!

Мне эта ситуация лишний раз указывает на то, что истинная сущность любого сервиса проявляется только тогда, когда что-то случается. И именно в этот момент все сразу встает на свои места.

Вот покупаете вы сервис, платите за него, вам показывают кучу всякой информации о том, как все надежно.. Но случается "упс".. И все дружно разводят руками..

Интересно, почему безвозвратно удалилась книга и учебные материалы? Он их писал прямо в облаке, в каком-то облачном офисе, не храня данные локально на компьютере? Ну, такое себе...

Если уж хранить данные в облаках, то хотя бы одновременно в двух разных, желательно из разных стран

Спасибо за пруф. Это сайт автора?

Это сайт автора?

Да.

Если передать --dry приложению на Java, которое ждёт -dry, параметр просто игнорируется. Скрипт выполнился по‑настоящему и удалил аккаунты на продакшене.

И именно поэтому в моих скриптах по умолчанию делается тестовый прогон, а чтобы реально удалить с диска, нужно добавить --yes-i-know-what-im-doing

Поменяйте на --avada-kedavra ;)

Задача не в том, чтобы сделать ещё один прикол, а чтобы дать человеку ещё один шанс задуматься над тем, что он, блин, сейчас сделает.

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

Я вот на этом месте выпал просто. Почему не выдается ошибка, если передается фактически неизвестный параметр? Я не погромист, конечно, но звучит как какое-то очевидное упущение.

Почему не выдается ошибка, если передается фактически неизвестный параметр?

Не понял, это Вы сейчас о чём?

Если Вам не нравится название параметра — то, простите, это наш внутренний скрипт, не используемый ни в каком другом месте, и если человек не знает всех тонкостей — то он ещё не дорос до того, чтобы позволять ему критические файлы удалять. Наоборот, скрипт отлично работает: не даёт интернам, не обладающим тайным знанием, поставить систему раком.

AWS: «Мы искренне ценим вашу приверженность лучшим практикам резервного копирования».

Красиво поддели. Не вникая во всю остальную ситуацию, чувак хранил весь стафф в одном месте. 🤷‍♂️

Мои клиенты — уже согласились мигрировать на Oracle OCI, Azure и Google Cloud.

Ничему его жизнь не учит. Как будто другие облачные провайдеры не удаляли случайно или намеренно чужие аккаунты.

Единая точка отказа у облачного провайдера - это ваш аккаунт. Отключение\удаление аккаунта умножает на ноль все ваши усилия по обеспечению надёжности облачной инфраструктуры.

Полагаю, он потому и взял сразу три облака.

а что мешало ему сделать это раньше?

1) Данные и сервисы в облаке вам не принадлежат. Владелец облака по велению свой левой ноги может закрыть. И если покупается облако - всегда надо иметь копии данных в месте, никак не связанным с компанием поставщиком

2) Компании, которые вчера кричали про "мы сократили НН рабочих мест потому что внедрили супер ИИ для поддержки" в особой группе риска. По той причине, что модели на нестандартные ситуации чаще всего реагируют отписками. А сроки прописанные в протоколе работы проблемами - истекают.

Такие отписки и люди прекрасно делали и делают. Особенно когда у службы поддержки нет ответственности.

Файлы которые рядом с тобой на накопителях , это твои файлы. То что непонятно где, это данные без владельца. Сейчас винты стоят копейки, объемы достаточные. Не думаю что он там в Амазоне сотню терабайт данных держал.

200 баксов он платил не за 100 Гб ;)

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

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

Но так как инцидент приоритета 2 докатилься до CEO, пришел cloud admin, восстановил все аккаунты, убрал линк на плательщика банкрота, надо полагать настоящие аккаунты банкрота снова удалились, а аккаунт автора остался в stopped.

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

Так что бекап бекапов бы не спас. Тут что то более фундаментальное нужно - извлечение первичных ключей и их независимое хранение под шифром не требующим аутентификации AWS. Что не соответствовало методичке.

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

Жуткая какая-то история про "методичку". Они там с ума посходили?
А если я буду шифровать бекапы публичным ключем, а закрытый ключ буду хранить зашифрованым на листочке в виде base64 под "подушкой". С их точки зрения наверное я построил небезопасную систему?

Чтобы шифровать открытым вторичным ключем нужно сначала получить незашифрованные первичные ключи, которые технически есть у вас на компе и в облаке и в бекапе, но для вашей же безопасности они зашифрованы вторичным ключем который выдается вам только после прохождение успешной аутентификации. Аутентификацию можно пройти на любом сервере аутентификации и любым из 10 способов включая восстановление забытого пароля, все надежно ровно до тех пор пока сам аккаунт живой, о чем и говорит автор.

Экспортировать ключи и повторношифровать, а затем думать оффлайн тул который раскатает локальные бакапы с локальными клбчами без авторизации на серверах AWS - отдельная история. Скорее проще сделать нештатные незашифрованные копии всего и вся вместе со скриншотами конфигураций, но это еще более мутная история.

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

Фишка открытия холодных хранилищ, все таки в том, что они использовали его опен сорс. Думаю даже поленились бы со стула встать ;) пошол бы суд , используют то, что сгубили! А вот тут могли и до судебное соглашие состряпать. Постановление суда, убрать код, возместить убытки. 100500 миллионов. Кстати интересно, задать ему вопрос. Что он собирается делать в дальнейшем. Будет использовать инфраструктуру Amazon или нет? Кстати в статье упоминается Цукенберг, и ни одного упоминания Безоса. Поправьте меня AWS это же Безос, а не Цукенберг?

Мои клиенты — а это суммарно более 400 тысяч долларов в месяц расходов на AWS — уже согласились мигрировать на Oracle OCI, Azure и Google Cloud.

Ничего чел так и не понял...

"Это не твой зуб, и даже не мой!"

Ждём аналогичных статей про Oracle OCI, Azure и Google Cloud от того же аффтара.

Совпадение? )

Прежде чем кто‑то скажет: «Ты сложил все яйца в одну корзину», уточню: нет. Я использовал одного провайдера

Действительно, и что же могло пойти не так?

Облака безопасны и надежны, говорили они. Переходи в облака, долой железные сервера, говорили они. Облака хранят твои данные вечно, говорили../s

И далее по тексту.

После смены почты на Ali, потерял 10 летнюю историю покупок. Как и историю, ещё не завершенных, и не полученных заказов. После вынужденного возврата, на старый интернет адрес, ни чего не вернулось. Но, это обычно для этого сайта.

Почту не менял, но не заходил на али года 4. В итоге история покупок тоже чиста.

Автоудаление истории покупок по таймауту это сейчас не удивительно.

У меня история обширная, однако все покупки до поглощения СОМ РУшкой пропали. А теперь ещё и самые старые потеряли кучу инфы о себе, только сам, факт заказа и дата.

У меня история обширная, однако все покупки до поглощения СОМ РУшкой пропали.

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

Да я в курсе. Я же даже постил вот такую пикчу уже:

И, если честно, я против того, что ПД граждан не РФ хранятся в РФ, хотя площадка обслуживает Китай. Хранение их в Китае более чем логично, но текущее положение день есть логичное продолжение событий из 2010х. Я про инциденты с почтой и видосики на ютубе от мамкиных социнженеров с инструкциями "как покупать на алике бесплатно".

Я использовал одного провайдера, но с, казалось бы, непробиваемой избыточностью:

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

самое надежное хранилище это у себя дома на личном сервере ничего лучше нет.

Это если связь стабильная, и грабители в дома вламываются нечасто.

Стабильная. Нечасто.

Читал оригинал месяца 2 назад. Ржал.

Бэкапы 3-2-1? Ну хотя бы 2-2-1? Не, не слышал.

Настолько слепо доверять любому ресурсу - ну это прям сильно.

Это примерно: А зачем нам Вим? У нас же м365 есть. Там же 90 дней хранится

Так бэкапы 3-2-1 у него вроде как были. Но они были зашифрованы, а ключ для расшифровки лежал в облаке...

Вспомните историю с WD CLOUD .. Сами устройства стояли перед владельцами, а до данных не добраться.

  1. Контору могу хакнуть.

  2. Ваши наработки смогли своровать. Для этого они грохнули ваш аккаунт. Чтобы вы не смогли доказать авторство.

Плательщик был не случайным человеком или мошенником — это была компания, которую поддержал Y Combinator

Это первый признак мошенников.

потери из‑за краха криптобиржи FTX.

Это второй, и уже просто красный флаг!

собственная карта Wise в биллинге

Карту револют бы ещё указали )

Я, например, отлично понимаю AWS в этой ситуации. Прямо обвинить нет достаточно улик. Откреститься и забыть сославшись на юридические моменты - лучший способ избавиться от мутного клиента навсегда.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
www.itsumma.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
ITSumma