目标：我希望将敏感数据保留在s3存储桶中，并在位于私有云中的EC2实例上进行处理。我研究了有可能通过IP和用户（iam）来设置S3存储桶策略，因此我认为s3存储桶中的数据是“安全的”。但我对下一个场景感到担忧：1）有vpc 2）内部是一个ec2 isntance
3）有一个用户在受控（允许）帐户下具有连接权限并使用ec2实例和存储桶。存储桶被定义和配置为仅与已知（授权）的ec2实例一起使用。
安全漏洞：用户在ec2实例上传恶意软件应用程序，在处理数据期间执行恶意软件应用程序，将数据传输到不同AWS账户下的其他（未授权）存储桶。
禁止上传数据到在我的情况下，ec2-instance不是一个选项。
问题：是否可以限制对vpc firewal的访问，使其能够访问某些特定的s3存储桶，但是会被拒绝访问任何其他存储桶？假设用户可能会将恶意软件应用程序上传到ec2实例，并在其中将数据上传到其他存储桶（在第三方AWS账户下）。
答案 0 :(得分：3)
对于你所要求的内容，并没有真正的解决方案，但话又说回来，你似乎试图解决错误的问题（如果我理解你的问题）。
如果你的情况是不值得信任的用户能够“连接并使用ec2实例和存储桶”并在你的VPC中上传和执行应用程序代码，那么所有的赌注都会关闭，游戏已经完成过度。关闭应用程序是唯一可用的修复程序。试图通过防止恶意代码将敏感数据上传到S3中的其他存储桶来限制损害应该是您最不用担心的。除了将数据放回S3但位于不同的存储桶中之外，恶意用户还有许多其他选项可用。
我也可能比你想要的更广泛地解释“连接和使用ec2实例和存储桶”，你的意思是用户能够将数据上传到你的应用程序。好吧，好吧......但你的担忧似乎仍然集中在错误的观点上。
我有用户可以上传数据的应用程序。他们可以上传他们想要的所有恶意软件，但是没有任何代码 - 恶意或良性 - 恰好包含在他们上传的数据中将被执行。我的系统绝不会将上传的数据与要执行的内容混淆，也不会以甚至远程可能的方式处理它。如果您的代码会出现问题，那么您再次遇到的问题只能通过修复代码来解决 - 而不是通过限制您的实例可以访问哪些存储桶。
实际上，当我说没有解决方案时，我说谎了。有一个解决方案，但它是相当荒谬的：
在EC2或外部某处设置反向Web代理，但当然使恶意用户无法访问其配置。在此代理的配置中，将其配置为仅允许访问所需的存储桶。例如，使用apache，如果存储桶被称为“mybucket”，可能看起来像这样：
ProxyPass /mybucket http://s3.amazonaws.com/mybucket
代理上的其他配置将拒绝从您的实例以外的任何位置访问代理。然后，不允许您的实例直接访问s3端点，只允许向代理发出出站http（通过受感染实例的安全组）。对您以外的存储桶的请求将不会通过代理进行，现在这是唯一的“出局”方式。问题解决了。至少，你希望解决的具体问题应该通过这种方法的一些变化来解决。
更新以澄清：
要以正常方式访问名为“mybucket”的存储桶，有两种方法：
http://s3.amazonaws.com/mybucket/object_key
http://mybucket.s3.amazonaws.com/object_key
使用此配置，您将阻止（不允许）通过安全组配置从您的实例访问所有S3端点，这将阻止使用任一方法访问存储桶。相反，您可以允许从您的实例访问代理。
例如，如果代理位于172.31.31.31，那么您将访问存储桶及其对象，如下所示：
http://172.31.31.31/mybucket/object_key
代理被配置为仅允许转发路径中的某些模式 - 以及任何其他被拒绝的模式 - 将控制特定存储桶是否可访问。
答案 1 :(得分：1)
使用VPC Endpoints。这允许您限制VPC中的EC2实例可以访问哪些S3存储桶。它还允许您在VPC和S3服务之间创建专用连接，因此您不必允许全开的出站Internet访问。有sample IAM policies显示如何控制对存储桶的访问。
有一个added bonus用于S3的VPC端点，某些主要的软件存储库，例如亚马逊的yum repos和Ubuntu的apt-get存储库，都在S3中托管，因此你也可以让你的EC2实例获得他们的补丁给他们开放的互联网接入。这是一个很大的胜利。