encryption - 将 AWS 凭证作为用户数据传递给 EC2 实例的最佳方法是什么？

Question

我有一个基于 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

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

'zip -P' 不是很安全

密码在实例中是硬编码的(它总是“ secret 密码”)

该方法与 here 中描述的方法非常相似。

有没有更优雅或更可接受的方法？使用 gpg 加密凭证并将私钥存储在实例上以对其进行解密是我现在正在考虑的一种方法，但我不知道有任何警告。我可以直接使用 AWS key 对吗？我是否错过了 API 中一些非常明显的部分？

Answer 1

您可以将凭据存储在机器上(或传输、使用然后删除它们。)

您可以通过安全 channel 传输凭据(例如使用 scp 和非交互式身份验证，例如 key 对)，这样您就不需要执行任何自定义加密(只需确保权限正确设置为 0400) key 文件，例如设置主文件的权限并使用 scp -p )

如果以上没有回答你的问题，请提供更具体的细节。您的设置是什么以及您要实现的目标。是否要从一个中心位置在多个节点上启动 EC2 操作？多个节点和中心位置之间是否可以使用 SSH？等等。

编辑

你考虑过吗parameterizing your AMI ，要求实例化您的 AMI 的人首先使用他们的 AWS key 填充用户数据 ( ec2-run-instances -f user-data-file )？然后，您的 AMI 可以从 http://169.254.169.254/1.0/user-data 动态检索这些每个实例的参数。 .

更新

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

数据安全当存储在 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)

数据安全当存储在 AMI user-data并使用容易获得的 key 加密(或解密)

低

容易获得的 key (密码)可能包括:

key 硬编码在 ABI 内的脚本中(攻击者可以在其中获取 ABI)

key 硬编码在 AMI 本身的脚本中，该脚本可由任何设法登录 AMI 的用户读取

任何其他容易获得的信息，例如公钥等。

任何私钥(其公钥很容易获得)

给定一个容易获得的 key (密码)，第 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，最终使用容易获得的 key 解密)

数据安全当存储在 AMI user-data并用不易获得的 key 加密

平均

任何设法登录 AMI 并有权访问 telnet 的用户都可以访问加密数据。 , curl , wget等(可以访问加密http://169.254.169.254/1.0/user-data)

然后可以使用蛮力攻击尝试解密加密数据

数据安全当存储在 AMI 上的安全位置 (加密没有附加值)

更高

数据仅供一名用户访问，即需要数据才能操作的用户

例如用户拥有的文件:掩码为 0600 或 0400 的用户

攻击者必须能够冒充特定用户才能访问数据

额外的安全层，例如拒绝用户直接登录(必须通过 root 进行交互式模拟)提高安全性

所以任何涉及 AMI 的方法 user-data不是最安全的，因为访问机器上的任何用户(最弱点)都会危及数据。

如果仅在有限的时间段内(即仅在部署过程中)需要 S3 凭证，并且 AWS 允许您覆盖或删除 user-data 的内容，则可以缓解这种情况。完成后(但情况似乎并非如此。)如果可能，另一种方法是在部署过程期间创建临时 S3 凭证(在部署过程之后破坏来自 user-data 的这些凭证)已完成且凭证已被 AWS 作废，不再构成安全威胁。)

如果以上不适用(例如，部署的节点需要无限期的 S3 凭证)或不可能(例如，不能仅为部署颁发临时 S3 凭证)，那么最好的方法仍然是咬紧牙关和 scp各种节点的凭据，可能是并行的，具有正确的所有权和权限。