web-dev-qa-db-ja.com

パスワードをハードコーディングする必要がないようにバックアップスクリプトを保護する方法

私は安全でプライベートなaw ec2環境を持っていますが、mongodb、postgresqlのバックアップをいくつか行う必要があるため、バックアップを実行するための別のec2インスタンスがあり、バックアップインスタンスにソフトウェアをインストール/更新できるように80と443を許可する場合があります。

シェルスクリプトを使用してバックアップジョブを実行します。スクリプトにハードコードされたパスワードまたは資格情報が必要です。すべての資格情報を1つの場所(バックアップインスタンス)に保存するほど安全ではないと思います。

パスワードや資格情報をプレーンテキストで保存しないようにバックアップインスタンスをセキュリティで保護する方法、また、パスワードや資格情報をメモリや一時ファイルに保存しないようにしたいですか?

3
Tuyen Pham

AWS Secrets Manager(またはパラメーターストア)を試しましたか?それはまさにこの目的のために構築されています。

バックアッププロセス用に別のIAMロールを作成し、必要なEC2インスタンスにそのIAMロールを付与します。次に、スクリプトを変更してSecrets Managerを呼び出し、認証情報を取得します。実行中のプロセスのメモリ以外では、これらの認証情報を保存しないでください。 (つまり、プロセスが1つになったらそれをパージします)。

バックグラウンドで、EC2インスタンスには、スクリプトがシークレットマネージャーを呼び出すために使用できるトークンを発行するメタデータインスタンスがあります。シークレットマネージャーを呼び出せるようになると、実際のDB資格情報を取得してDBを呼び出すことができます。さらに、メタデータサービスはIAMロールの一時的なトークンのみを発行するため、このアプローチはさらに優れています。

より古いskoolメソッドは、IAMロールのAPIキーを生成し、それらの認証情報をEC2の〜/ .aws/credentialsの場所にハードコードすることです。次に、AWS SDKはそれを使用して、同じ概念でAWS Secrets Managerを呼び出します。

結局のところ、概念は同じです。APIキーを使用して、使用される実際の認証情報を返すAPIを呼び出します。そのAPI呼び出しはログに記録され(cloudtrail)、呼び出しに必要な資格情報のみを返します。

2
keithRozario