![Какой наилучший план резервного копирования для доступа к аккаунту AWS?](https://rvso.com/image/668762/%D0%9A%D0%B0%D0%BA%D0%BE%D0%B9%20%D0%BD%D0%B0%D0%B8%D0%BB%D1%83%D1%87%D1%88%D0%B8%D0%B9%20%D0%BF%D0%BB%D0%B0%D0%BD%20%D1%80%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B4%D0%BB%D1%8F%20%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0%20%D0%BA%20%D0%B0%D0%BA%D0%BA%D0%B0%D1%83%D0%BD%D1%82%D1%83%20AWS%3F%20.png)
Я думал, что если мой аккаунт AWS будет удален или станет недоступен в один прекрасный день? Кто-нибудь реализовал решение для этого? Можно ли сделать резервную копию с одного аккаунта AWS и восстановить на другой аккаунт AWS?
В настоящее время я использую Skeddly для резервного копирования моих экземпляров AWS, которые снова хранятся в самом AWS.
Есть предположения?
решение1
Есть несколько вещей, которые вы можете сделать. Во-первых, убедитесь, что у вас есть как минимум две учетные записи администратора: одна из них используется вами, а другая хранится в надежном месте и используется только в экстренных случаях.
Второй способ — настроить совершенно отдельную учетную запись AWS в качестве «резервной» с собственным набором учетных данных. Вы можете предоставить кросс-аккаунтный доступ из своей основной учетной записи к своей резервной учетной записи, но разрешить только основной учетной записи «помещать» или делать резервные копии объектов в резервную учетную запись, так что даже если ваша основная учетная запись будет скомпрометирована, злоумышленник не сможет нанести вред второй учетной записи из основной учетной записи.
Фактический процесс резервного копирования ваших сервисов с одного аккаунта на другой будет зависеть от того, какие сервисы вы используете, но концепция та же самая — сделайте резервную копию данных на s3, а затем скопируйте данные из s3 в вашем основном аккаунте в s3 в резервном аккаунте — и убедитесь, что основной аккаунт имеет достаточный доступ ко второму аккаунту только для «размещения» вещей, а не для удаления. Никто в вашей компании не должен иметь доступа к обоим этим наборам учетных данных (если ваша компания не крошечная).
Вы же не хотите оказаться на месте компании, которая обанкротилась из-за взлома ее аккаунта:
А в этом видео с конференции AWS Reinvent 2015 (начинается примерно с 50-й минуты) вы узнаете, как AirBNB защищается от этих проблем именно таким образом:
AWS re:Invent 2015 | (DAT304) Amazon RDS для MySQL: лучшие практики | youtube.com
решение2
Первым правилом при разработке приложений в AWS должна быть автоматизация всего.
Теперь, если вы потеряете доступ к своей учетной записи или она будет скомпрометирована и все будет прекращено, то вам останется только запустить простой процесс, чтобы вернуть все ваши компоненты без сохранения состояния.
Большой подвох здесь — ваши компоненты с сохранением состояния, такие как ваши базы данных. Для этого я бы рекомендовал вам регулярно делать резервные копии ваших баз данных и хранить их где-то вне AWS (или где-то, что ваш аккаунт не сможет удалить, по крайней мере, как вЛедник АмазонкисЗамок хранилища).
Например, у вас может быть запланированная работа, которая займетmysqldump
любых баз данных MySQL, которые у вас есть, а затем SCP-сервер для них из AWS.
Теперь, если вы потеряете свою учетную запись, вам останется только восстановить резервные копии базы данных в том месте, где вы решите ее перестроить (это может быть AWS под другой учетной записью или даже в той же учетной записи, но на этот раз надежно защищенной), а затем запустить процесс автоматизации для перестройки всех остальных компонентов, не имеющих состояния.
Очевидно, что произойдет некоторая потеря данных, поскольку вы сможете вернуться только к последней резервной копии вашей базы данных.