深入考察无服务器架构的安全威胁，敏感数据泄露

我们都听说过重大的数据泄露事件，比如最近的数据泄露——5000万Facebook用户数据遭到泄露。虽然隐私受到损害的通常是最终用户，但公司的成本也是非常高昂的。在极端情况下，数据泄露甚至可能导致公司关门大吉。

这方面最好的一个例子就是Code Spaces，一家前SaaS提供商，可以通过Amazon Elastic Compute Cloud的控制面板进行访问。黑客“……删除了所有EBS快照、S3存储桶、所有AMI、许多EBS实例和多个机器实例”，最终导致了这家基于AWS的公司的倒闭。

如果您自认为“嗯，这些我都知道。但是，对于无服务器架构来说，我最想知道事情到底有哪些不同呢?”，好吧，这说明你真是来对了地方。

实际上，针对Code Spaces的攻击事件发生在2014年，那时，“无服务器”的概念还没有出现。然而，其中的某些云服务和资源(例如S3 )却是当今无服务器解决方案中的基本组成部分。如果在此基础上再加入几个函数，然后重新排列一些字母(我的意思是AMI→IAM，清楚了吧?)，并添加一些由三个字母组成的缩写(例如EFS、SQS、SES等)，那么，它们面临的风险其实是一样的。如果数据没有得到很好的保护，肯定会面临巨大的风险。

现在，您可能会说“那又怎样，即使面对同样的攻击，但是别忘了，我们还有许多其他的数据源”。是的，这句话也有一定的道理。但是，我们现在必须从不同的角度来全盘考虑。

首先，也许是更相似的一个方面，那就是对于数据的处理。我们必须为静态和传输中的数据提供安全保护。

我们需要为云存储、备份或数据库中的敏感数据提供加密处理。我们的服务提供商通常会提供相应的工具，以帮助我们轻松、正确的完成这些任务。我们可以使用他们提供的KMS/Key Vault来安全地存储数据。此外，我们还要确保资源配置的正确性，这样就不会出现大的泄漏事故，至少不会引起公司倒闭。当然，一定要确保不要将密钥泄漏到代码存储库或任何其他可能最终落入攻击者手中的地方。

对于传输中的数据，只需确保所有连接都使用了TLS(当我们调用提供商的服务时，这些都是其默认的设置)即可。

其次，也是最有趣的部分，那就是我们新的无服务器运行时环境中的数据。如果我们发现自己的/etc/passwd和/etc/shadow文件遭受了攻击，我们会不会惊恐万分?无论是在我们的服务器中，还是在云中(例如EC2)，都是够吓人的。不过，在无服务器架构中，世道已经变了，这些已经不再敏感了。我甚至会考虑把它们直接交给攻击者，如果他们的态度好一点的话。事实上，的确如此。

这是为什么呢?因为，这些安全问题现在已经是服务提供商操心的事情了，并且，我们的函数是在通用环境中运行的。

那么，我们需要保护的到底是什么呢?这是最重要的问题。其实，答案很简单，但对于不同的提供商来说，保护对象可能会有所不同。

A.我们的代码

我们可能没有服务器，但我们的代码却是存储在云存储或云存储库中的(当然，这些都不在我们的职责范围内)，并且，它们是随函数的运行时环境一起提供的。当然，具体的存储位置取决于运行时和供应商。

例如：在AWS NodeJS中，您可以在当前目录(./)中找到自己的代码，同时，还可在GCP中找到自己的Python代码，这就与AWS上的位置有所不同(/var/task)。这些方面的知识，将留给读者自己去探索。现在，请使用以下GCP函数在任意文件或目录中运行cat和ls命令。

curl -X POST -H "Content-Type: application/json" https://us-east1-slsbot-214001.cloudfunctions.net/gcp-py-explore --data '{"ls":"./"}' | base64 --decode 
curl -X POST -H "Content-Type: application/json" https://us-east1-slsbot-214001.cloudfunctions.net/gcp-py-explore --data '{"cat":"main.py"}' | base64 --decode 

B.我们的机密信息

同样，这也随服务供应商的不同而有所不同。但是，如果我们以AWS为例，那么您需要保护两部分的机密信息。第一部分，属于无法控制，却又必须面对的信息，其中包含自己函数方面的信息，例如其内存配置、日志组名称、版本，等等。但是，最重要的是函数的令牌(token)。

这些令牌代表着该函数相对于该帐户的权限。因此，如果该函数对帐户具有为所欲为的权限的话(大多数情况下都是这样)，比如扫描数据库或编辑存储桶这类的权限的话，那么，它们一旦落入攻击者的手中，就会带来巨大的灾难。攻击者甚至不必使用您的函数，只需用他们自己的计算机上的令牌，就能运行任意的aws cli命令，因为aws配置文件stolen_keys中存放有被盗令牌(AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY和AWS_SESSION_TOKEN)：

无论我们喜欢与否，这些令牌都是存在的，所以，我们需要确保对函数的权限加以控制，只要能够满足完成它们的相应操作就可以了，最好多一点都不要给它们。如果函数需要从S3bucket读取数据的话，务必确保只赋予该函数从特定bucket或任何相关资源读取数据的权限。

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!