如何保证提供数据的 aws lambda 调用者保持安全答案

【问题标题】：how to guarantee aws lambda caller that provided data remains secure如何保证提供数据的 aws lambda 调用者保持安全
【发布时间】：2017-10-01 10:56:32
【问题描述】：

这个问题的总体目的与Disable AWS Lambda Environment Variables 有一些相似之处，但主要针对网络访问。

我想为第三方提供调用我的 Lambda 函数的能力。第三方将自己的数据提交给 Lambda 函数（通过有效负载，或通过指定数据位置，例如 S3 存储桶）。

我希望 Lambda 服务能够向第三方保证他们提供的数据没有从 Lambda 进程泄露到其他任何地方。为了做到这一点，至少第三方必须保证 Lambda 函数没有连接到 Internet 上的某个其他资源并将数据泄露给它。

假设

我正在提供将对敏感数据进行操作的代码
第三方无法检查该代码，并且
第三方信任亚马逊，但不信任我

有没有办法通过 Lambda 实现这一点（可能与其他 AWS 产品结合使用）？我已经研究了使用网关、EC2、静态加密、S3 和所有这些的自定义权限的解决方案，但没有找到解决方案。

【问题讨论】：

如下面的回答中所述，VPC 内的 Lambda 函数只有在您配置它可以访问 Internet 的情况下才能访问 Internet，但由于您控制环境，并且你控制代码，这对于“证明”信息没有泄露仍然没有任何作用。事实上，除非您从未访问过我的数据，否则您永远无法向我证明您没有导出/暴露/复制我的数据。否则怎么可能有技术解决方案？唯一可能的“证据”是受信任的第 3 方审核。
我同意您的评估，即由于我对环境的控制，以下答案无法解决问题。但是，如果受信任的第 3 方提供运行代码的平台（并且假设受信任方始终信守承诺），我不确定为什么技术解决方案不存在，以确保应调用者，代码在受限环境中运行。
btw 在我上面的评论中，当我说“受信任的第 3 方”时，我的意思是 AWS（与提供敏感数据和运行代码以及需要保证的“第三方”相反）数据安全）

标签： amazon-s3 network-programming aws-lambda data-security

【解决方案1】：

您可以在 VPC 中创建 lambda 方法并对其进行保护。阅读此https://forums.aws.amazon.com/thread.jspa?messageID=733719 他们遇到了问题，因为他们无法访问互联网

【讨论】：

正如@Michael 在他对 OP 的评论中指出的那样，这种方法并不能解决问题，因为它仍然需要第三方信任我不会泄露数据（无意或无意），因为我可以控制是否/如何设置 VPC。
你不能给他们设置 lambda 配置的代码和脚本，让他们在 VPC 上运行吗？他们可以信任哪个？
不理想，因为我会给他们代码，这使得解决方案难以维护，但这可能是目前可能的最佳解决方案。 +1

【解决方案2】：

您可以提供的唯一“证明”是外部受信任的第三方（不是 AWS）的形式，该第三方对您的环境、实践和政策进行了审计，并确保他们满意您能够正确处理敏感数据。

无论出于何种原因，客户都不愿意相信您会处理他们的数据，同时又会在未经授权的情况下略读其中的一些数据……同时，您可能不想简单地将您的代码许可给他们，以便他们可以运行它在他们满意的安全环境中。

这些都不是技术问题。这些都是信任问题。

我不完全确定您是否考虑过真正孤立的环境的真正含义。显然，您将无法查阅任何数据库……而且，它必然会被剥夺任何日志记录功能。 console.log(data.super_secret);。来自 Lambda 函数的日志离开 Lambda 环境并传送到 CloudWatch。

假设无论出于何种原因您仍然不相信，总会有DNS Tunneling。这种邪恶方案的美妙之处在于，即使您没有 Internet，您也永远不会与 VPC 中的 DNS 解析隔离。位于 169.254.169.253 的 DNS 解析器始终存在，帮助侦听，不受安全组的影响，不受网络 ACL 的影响，不受默认路由的影响。您想偷偷地将数据从“孤立”的环境中偷走？完成。

在任何情况下，AWS 都不保证您的配置的安全性——他们只承担保护其基础设施本身的责任。他们向您保证，它与您配置的一样安全……但是如何配置它取决于您。他们称之为共享安全模型：

虽然 AWS 管理云的安全性，但 in 云的安全性是客户的责任。客户可以控制他们选择实施的安全措施来保护自己的内容、平台、应用程序、系统和网络，这与他们在现场数据中心中的应用程序没有什么不同。

https://aws.amazon.com/compliance/shared-responsibility-model/

【讨论】：

我投了赞成票，因为您提出了一些有效的观点（例如 console.log）。不过，我不确定为什么很难看出为什么客户不信任——许多银行和医院甚至还不信任 AWS 或 Google，所以当银行和医院是提供敏感数据的客户时，这仍然是一个飞跃相信他们最终会放心地信任 AWS / Google / Azure。但与那些庞然大物以外的任何公司（例如我的）相比，这是一个更容易实现的飞跃（因此愿意在这里做出这种假设）。
是的，我知道这是一个信任问题——这个问题的目的是确定 A 和 B 之间的信任问题是否可以通过涉及相互信任方 C 的技术解决方案来缓解-- 类似于 SSL 证书如何使用第三方（证书颁发机构）来代理信任级别，如果没有受信任的第三方，这是不可能的。
我无意说或暗示很难理解为什么客户不信任供应商。 无论出于何种原因 旨在作为所有内容的占位符，从“供应商看起来粗略”到“客户对其数据的实际价值有不切实际的高估计”到“改变很难”以及介于两者之间的点。