AWS アカウントアクセスのベストプラクティスのバックアッププランは何ですか?

AWS アカウントアクセスのベストプラクティスのバックアッププランは何ですか?

ある日、AWS アカウントが削除されたり、アクセスできなくなったりしたらどうなるでしょうか? これに対する解決策を実装した人はいますか? ある AWS アカウントからバックアップして、別の AWS アカウントに復元できますか?

現在、Skeddly を使用して AWS インスタンスをバックアップしています。このインスタンスも AWS 自体に保存されています。

何かご意見は?

答え1

実行できる対策はいくつかありますが、1 つは管理者アカウントを少なくとも 2 つ用意し、1 つは自分で使用し、もう 1 つは安全な場所に保管してエネルギー専用に使用できるようにします。

2 つ目は、独自の認証情報セットを持つ「バックアップ」として完全に別の AWS アカウントを設定することです。プライマリ アカウントからバックアップ アカウントへのクロス アカウント アクセスを許可できますが、プライマリ アカウントにはバックアップ アカウントへのオブジェクトの「配置」またはバックアップのみを許可します。これにより、プライマリ アカウントが侵害された場合でも、攻撃者はプライマリ アカウントから 2 番目のアカウントに危害を加えることはできません。

あるアカウントのサービスを別のアカウントにバックアップする実際のプロセスは、使用しているサービスによって異なりますが、概念は同じです。つまり、データを s3 にバックアップし、プライマリ アカウントの s3 からバックアップ アカウントの s3 にデータをコピーします。そして、プライマリ アカウントには、2 番目のアカウントに対して、削除ではなく「配置」できるだけのアクセス権のみがあることを確認します。社内の誰も、これら 2 つの資格情報セットにアクセスできないようにする必要があります (会社が小規模でない限り)。

アカウントが侵害されて廃業に追い込まれたような会社にはなりたくないですよね。

ハッカーがホスティングサービス Code Spaces を廃業に追い込む | Threatpost | セキュリティニュースの第一弾

また、AWS Reinvent 2015 のこのビデオ (約 50 分後から) では、AirBNB がこれらの問題に対してどのように保護しているかを次のように聞いてください。

AWS re:Invent 2015 | (DAT304) Amazon RDS for MySQL: ベストプラクティス | youtube.com

答え2

AWS で構築する場合の最初のルールは、すべてを自動化することです。

これで、アカウントへのアクセスを失ったり、アカウントが侵害されてすべてが終了したりした場合は、すべてのステートレス コンポーネントを復元するための簡単なプロセスを実行するだけで済みます。

ここでの大きな問題は、データベースなどのステートフルコンポーネントです。このため、データベースのバックアップを定期的に取って、AWS以外の場所(または少なくともアカウントで削除できない場所、たとえばアマゾン氷河金庫のロック)。

例えば、mysqldump所有しているすべての MySQL データベースを AWS から SCP します。

これで、アカウントを失った場合は、再構築する場所にデータベースのバックアップを復元するだけです (別のアカウントで AWS に戻すことも、同じアカウントで適切に保護することもできます)。その後、自動化プロセスを実行して、他のすべてのステートレス コンポーネントを再構築します。

データベースから最後にバックアップした時点までしか戻れないため、当然ながら、いくらかのデータが失われます。

関連情報