24

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. パスワードはインスタンスにハードコードされています (常に「秘密のパスワード」です)

この方法は、ここで説明されている方法と非常によく似ています

より洗練された、または受け入れられているアプローチはありますか? gpg を使用して資格情報を暗号化し、インスタンスに秘密鍵を保存して復号化することは、現在検討中のアプローチですが、注意点はありません。AWS キーペアを直接使用できますか? API の非常に明白な部分が欠けていますか?

4

5 に答える 5

15

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

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。

アップデート

OK、これまでに説明したさまざまなアプローチのセキュリティを考慮した比較を次に示します。

  1. 暗号化されていないAMI に保存されている場合のデータのセキュリティuser-data
    • 低い
    • 平文データは、AMI へのログオンに成功し、、 、 などにアクセスできるすべてのユーザーがアクセスできます (平文 にアクセスできます) 。telnetcurlwgethttp://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 へのログオンに成功し、、 、 などにアクセスできるすべてのユーザーがアクセスできます (クリアテキストにアクセスできます) 。telnetcurlwgethttp://169.254.169.254/1.0/user-data
      • プロキシ リクエスト攻撃に対して脆弱です (たとえば、攻撃者は AMI で実行されているかどうかに関係なく、Apache に暗号化された を取得して転送するようにhttp://169.254.169.254/1.0/user-data要求し、後で簡単に取得できるキーで復号化します)。
  3. AMI に保存され、簡単に取得できないキーで暗号化された場合のデータのセキュリティuser-data
    • 平均
    • 暗号化されたデータには、AMI へのログオンに成功し、、 、 などにアクセスできるすべてのユーザーがアクセスできます (暗号化された にアクセスできます) 。telnetcurlwgethttp://169.254.169.254/1.0/user-data
      • 暗号化されたデータの復号化は、ブルート フォース攻撃を使用して行うことができます。
  4. 安全な場所に AMI に保存されている場合のデータのセキュリティ(暗号化しても付加価値はありません)
    • より高い
    • データにアクセスできるのは、操作するためにデータを必要とする 1 人のユーザーのみです。
      • 例: マスク 0600 または 0400 の user:user が所有するファイル
    • 攻撃者がデータにアクセスするには、特定のユーザーになりすます必要があります。
      • rootユーザーの直接ログオンを拒否するなどの追加のセキュリティ レイヤー (対話型の偽装のためにパススルーする必要がある) により、セキュリティが向上します。

そのため、AMI を使用する方法は最も安全ではありません。マシン上の任意のuser-dataユーザーへのアクセスを取得すると(最も弱い点)、データが危険にさらされるからです。

これは、S3 資格情報が限られた期間 (つまり、デプロイ プロセスの間のみ) のみ必要である場合、 AWS がそれを使用したときに内容を上書きまたは削除することを許可している場合に緩和される可能性がありますuser-data(ただし、これは可能であれば、デプロイ プロセス中に一時的な S3 クレデンシャルを作成することもできます (user-dataデプロイ プロセスが完了し、AWS でクレデンシャルが無効化された後、これらのクレデンシャルを侵害すると、セキュリティが失われます)。脅威。）

上記が適用されない場合 (例: 展開されたノードに必要な S3 資格情報が無期限に必要) または不可能な場合 (例: 展開のためだけに一時的な S3 資格情報を発行できない)、最良の方法は、弾丸とscp資格情報をさまざまなノードに、おそらく並行して噛むことです。 、正しい所有権と権限を持つ。

于 2009-03-13T04:57:14.290 に答える
11

シークレットを EC2 インスタンスに安全に渡すさまざまな方法と、それぞれの長所と短所を調べた記事を書きました。

http://www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2/

于 2010-06-19T21:45:44.703 に答える
10

EC2 インスタンスに資格情報を提供する必要がなくなったことを指摘したいと思います。IAM を使用して、EC2 インスタンスのロールを作成できます。これらのロールでは、EC2 インスタンスが特定の S3 バケットから特定のオブジェクトを取得できるようにするなど、細かいポリシーを設定できます。AWS ドキュメントで IAM ロールの詳細を読むことができます。

http://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html

于 2013-08-19T12:46:53.683 に答える