☰

AWS 認証情報をユーザーデータとして EC2 インスタンスに渡す最適な方法は何ですか? 質問する

tag-icon • tag-icon encryption amazon-s3 amazon-ec2 amazon-web-services
AWS 認証情報をユーザーデータとして EC2 インスタンスに渡す最適な方法は何ですか? 質問する

私は、EC2 インスタンスが S3 と SQS をクエリする必要がある AWS ベースのジョブ処理アーキテクチャを持っています。実行中のインスタンスが API にアクセスできるようにするには、認証情報が base64 でエンコードされたシェル スクリプトの形式でユーザー データ (-f) として送信されます。例:

$ cat ec2.sh
...
export AWS_ACCOUNT_NUMBER='1111-1111-1111'
export AWS_ACCESS_KEY_ID='0x0x0x0x0x0x0x0x0x0'
...
$ zip -P 'secret-password' ec2.sh
$ openssl enc -base64 -in ec2.zip

多数のインスタンスが起動されます...

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

各インスタンスは、init スクリプトにハードコードされている「secret-password」を使用して ec2.zip をデコードおよび復号化します。これは機能しますが、私のアプローチには 2 つの問題があります。

  1. 「zip -P」はあまり安全ではない
  2. パスワードはインスタンスにハードコードされています（常に「secret-password」です）

この方法は、説明した方法と非常によく似ていますここ

もっとエレガントで受け入れられるアプローチはありますか? gpg を使用して認証情報を暗号化し、インスタンスに秘密鍵を保存して復号化するアプローチを現在検討していますが、注意点についてはよくわかりません。AWS キーペアを直接使用できますか? API の非常に明白な部分を見逃しているのでしょうか?

ベストアンサー1

資格情報はマシンに保存できます (または転送して使用し、削除することもできます)。

scp認証情報は安全なチャネル（非対話型認証、キーペアなど）で転送できるため、カスタム暗号化を実行する必要はありません（0400キーファイルの権限が常に適切に設定されていることを確認してください。たとえば、マスターファイルの権限を設定して使用しますscp -p）。

上記で質問の答えが得られない場合は、設定内容と達成しようとしていることに関するより具体的な詳細を提供してください。EC2 アクションは中央の場所から複数のノードで開始されますか? 複数のノードと中央の場所の間で SSH は利用できますか? など。

編集

検討しましたかAMI のパラメータ化、AMI をインスタンス化するユーザーが最初にユーザーデータ ( ec2-run-instances -f user-data-file) に AWS キーを入力する必要がありますか? その後、AMI はインスタンスごとのこれらのパラメータを から動的に取得できますhttp://169.254.169.254/1.0/user-data。

アップデート

さて、ここで、これまで説明してきたさまざまなアプローチをセキュリティの観点から比較してみましょう。

  1. データのセキュリティAMIにuser-data暗号化されずに保存される
    • 低い
    • クリアテキストデータにアクセス可能どれでもAMI にログオンし、、、などにアクセスできるユーザーtelnet(curlクリアwgetテキスト にアクセスできますhttp://169.254.169.254/1.0/user-data)
    • プロキシリクエスト攻撃に対して脆弱です（例：攻撃者はAMI上で実行されているかどうかに関わらずApacheにクリアテキストを取得して転送するように要求しますhttp://169.254.169.254/1.0/user-data）
  2. データのセキュリティAMIに保存されuser-data、簡単に入手できるキーで暗号化（または復号化可能）されている
    • 低い
    • 簡単に入手できるキー (パスワード) には次のものが含まれます。
      • ABI 内のスクリプトにハードコードされたキー (ABI は攻撃者によって取得される可能性があります)
      • キーはAMI自体のスクリプトにハードコードされており、スクリプトはどれでもAMIにログオンできるユーザー
      • 公開鍵など、簡単に入手できるその他の情報。
      • 任意の秘密鍵（公開鍵は容易に入手できる可能性がある）
    • 簡単に入手できるキー（パスワード）が与えられた場合、ポイント 1 で特定したのと同じ問題が適用されます。
      • 復号化されたデータはどれでもAMI にログオンし、、、などにアクセスできるユーザーtelnet(curlクリアwgetテキスト にアクセスできますhttp://169.254.169.254/1.0/user-data)
      • プロキシリクエスト攻撃に対して脆弱です（例：攻撃者は、AMI 上で実行されているかどうかに関係なく、Apache に、http://169.254.169.254/1.0/user-data簡単に入手できるキーで暗号化されたファイルを取得して転送するように要求します）。
  3. データのセキュリティAMIに保存されuser-data、簡単に入手できないキーで暗号化されている
    • 平均
    • 暗号化されたデータには、どれでもAMI にログオンし、、、などにアクセスできるユーザーtelnet(curl暗号wget化された にアクセスできますhttp://169.254.169.254/1.0/user-data)
      • 暗号化されたデータをブルートフォース攻撃で解読しようとする試みが行われる可能性がある。
  4. データのセキュリティAMIの安全な場所に保存される（暗号化しても付加価値はありません）
    • より高い
    • データにアクセスできるのは、操作するためにデータを必要とするユーザーのみである。
      • 例: マスク 0600 または 0400 を持つユーザー:user が所有するファイル
    • 攻撃者は、データにアクセスするために特定のユーザーになりすますことができる必要があります。
      • ユーザーの直接ログオンを拒否する（root対話型偽装のためにパススルーする必要がある）などの追加のセキュリティレイヤーにより、セキュリティが向上します。

したがって、AMIを使用する方法はuser-data、最も安全とは言えません。どれでもマシン上のユーザー（最も弱いポイント）がデータを危険にさらします。

S3 認証情報が限られた期間のみ（つまり、デプロイメントプロセス中のみ）必要とされる場合、この問題は軽減される可能性があります。もしuser-dataAWSでは、使用が終わったら の内容を上書きまたは削除できます(ただし、これは許可されていないようです)。代替策としては、可能であれば、デプロイメント プロセス中に一時的な S3 認証情報を作成することです (user-dataデプロイメント プロセスが完了し、認証情報が AWS で無効になった後は、 からのこれらの認証情報が侵害されても、セキュリティ上の脅威にはなりません)。

上記が当てはまらない場合 (例: デプロイされたノードで S3 認証情報が無期限に必要) または不可能な場合 (例: デプロイ専用の一時的な S3 認証情報を発行できない)、最善の方法は、勇気を出して、scp適切な所有権と権限を持つ認証情報をさまざまなノードに (場合によっては並行して) 発行することです。

おすすめ記事