24

我有一个基于 AWS 的作业处理架构,需要 EC2 实例查询 S3 和 SQS。为了让正在运行的实例能够访问 API,凭据以 base64 编码的 shell 脚本的形式作为用户数据 (-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

每个实例使用硬编码到初始化脚本中的“秘密密码”对 ec2.zip 进行解码和解密。虽然它确实有效,但我的方法有两个问题。

  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.


更新

好的,这是迄今为止讨论的各种方法的安全性比较:

  1. 存储在未加密的 AMI 中的数据的安全性user-data
    • 低的
    • 任何设法登录 AMI 并有权访问telnetcurl、等的用户都可以访问明文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 并有权访问telnetcurl、等的用户都可以访问解密的数据wget(可以访问明文http://169.254.169.254/1.0/user-data
      • 您容易受到代理请求攻击(例如,攻击者要求 Apache 可能会或可能不会在 AMI 上运行以获取和转发加密的http://169.254.169.254/1.0/user-data,然后用易于获得的密钥解密)
  3. 存储在 AMI 中并使用不易获得的密钥加密时的数据安全性user-data
    • 平均的
    • 任何设法登录 AMI 并有权访问telnetcurlwget等的用户都可以访问加密数据(可以访问encrypted http://169.254.169.254/1.0/user-data
      • 然后可以使用蛮力攻击尝试解密加密数据
  4. 存储在 AMI 上、安全位置的数据的安全性(加密没有附加价值)
    • 更高
    • 数据只能由一个用户访问,即需要数据才能操作的用户
      • 例如,用户拥有的文件:掩码为 0600 或 0400 的用户
    • 攻击者必须能够冒充特定用户才能访问数据
      • 额外的安全层,例如拒绝用户直接登录(必须通过root交互式模拟)提高了安全性

因此,任何涉及 AMIuser-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

最好的方法是使用实​​例配置文件。基本思想是:

  • 创建实例配置文件
  • 创建新的 IAM 角色
  • 将策略分配给先前创建的角色,例如:

    {“声明”:[{“Sid”:“Stmt1369049349504”,“动作”:“sqs:”,“效果”:“允许”,“资源”:“ ”}]}

  • 将角色和实例配置文件关联在一起。

  • 当您启动一个新的 EC2 实例时,请确保您提供实例配置文件名称。

如果一切正常,并且您用于从 EC2 实例中连接到 AWS 服务的库支持从实例元数据中检索凭证,则您的代码将能够使用 AWS 服务。

来自 boto-user 邮件列表的完整示例:

首先,您必须创建一个 JSON 策略文档,该文档表示 IAM 角色应该有权访问哪些服务和资源。例如,此策略授予存储桶“my_bucket”的所有 S3 操作。您可以使用适合您的应用程序的任何策略。

BUCKET_POLICY = """{
  "Statement":[{
    "Effect":"Allow",
    "Action":["s3:*"],
    "Resource":["arn:aws:s3:::my_bucket"]}]}"""

接下来,您需要在 IAM 中创建一个实例配置文件。

import boto
c = boto.connect_iam()
instance_profile = c.create_instance_profile('myinstanceprofile')

拥有实例配置文件后,您需要创建角色、将角色添加到实例配置文件并将策略与角色相关联。

role = c.create_role('myrole')
c.add_role_to_instance_profile('myinstanceprofile', 'myrole')
c.put_role_policy('myrole', 'mypolicy', BUCKET_POLICY)

现在,您可以在启动实例时使用该实例配置文件:

ec2 = boto.connect_ec2()
ec2.run_instances('ami-xxxxxxx', ..., instance_profile_name='myinstanceprofile')
于 2013-06-24T16:22:18.053 回答
10

我想指出,不再需要向您的 EC2 实例提供任何凭证。使用 IAM,您可以为您的 EC2 实例创建角色。在这些角色中,您可以设置细粒度的策略,例如,允许您的 EC2 实例从特定 S3 存储桶获取特定对象,仅此而已。您可以在 AWS 文档中阅读有关 IAM 角色的更多信息:

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

于 2013-08-19T12:46:53.683 回答
2

就像其他人已经在这里指出的那样,您实际上不需要通过使用 IAM 角色来存储 EC2 实例的 AWS 凭证 - https://aws.amazon.com/blogs/security/a-safer-way-to-分发-aws-credentials-to-ec2/。我要补充一点,您也可以使用相同的方法为您的 EC2 实例安全地存储NON-AWS 凭证,例如,如果您有一些想要保持安全的数据库凭证。您将非 aws 凭证保存在 S3 Bukcet 上,并使用 IAM 角色访问该存储桶。您可以在此处找到更多详细信息 - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/

于 2017-09-28T17:37:47.790 回答