本文是#ServerlessSeptember的一部分。您将在这个全无服务器的内容集合中找到其他有用的文章、详细教程和视频。 9 月份,社区成员和云倡导者每天都会发布新文章——没错,每一天。

在https://docs.microsoft.com/azure/azure-functions/上了解有关 Microsoft Azure 如何启用无服务器功能的更多信息。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--e-MlfmIa--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /thepracticaldev.s3.amazonaws.com/i/avk9z12ih4j9y5vqepdu.png)

我们要学什么?

您整整一个月都在听说 Serverless。因此,实际上没有必要进一步详细说明迁移到无服务器架构的优点和缺点(有哪些?)。这篇文章将纯粹是关于安全。

TL;DR

你部署 Azure 功能吗? (我在这里,不是吗?)。你想保护你的功能吗? (还在...)。伟大的!确保你:

1.执行输入验证

2.遵循最小权限原则

3.监控 3rd-party 依赖

4.保护您的云存储

5.保护您的功能机密

6.强制认证授权

具体来说,我将讨论无服务器开发的安全最佳实践。大多数情况下,这意味着具有少量配置的应用程序安全性。因为这就是无服务器的全部内容,不是吗?!因为我们将大部分责任转移给了云提供商,而我们需要保护的是我们的代码。

有人可能会说,梦想成真。我们不再持续检查我们的服务器是否安装了最新的操作系统安全补丁。那现在是微软的问题(如果你不熟悉云计算的共享责任,我强烈建议你复习一下)。

安全存在,但不同

稍安毋躁。这绝对是转向无服务器开发的众多安全优势之一。但是不要太舒服......我们仍然需要安全,只是有点不同。即使没有预配或管理服务器,Azure 函数仍会执行代码。如果这段代码写得不好,该函数仍然容易受到应用程序级的攻击。

攻击者可能在您的帐户中运行恶意代码,这可能导致敏感数据泄露,在云中执行未经授权的操作,在某些极端情况下,甚至可能导致完整的应用程序接管。如果您的 Azure 功能易受攻击并且有权这样做,则攻击者可以与其他云资源交互并最终拥有它们。

我希望现在您同意我的观点,即我们需要解决无服务器安全问题。因此,让我们了解更多技术知识并讨论一些有助于保护 Azure 功能的安全最佳做法。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--GJfdJKRx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://i.imgur .com/bUBN8Or.png)

1\。执行输入验证

注入缺陷攻击是应用程序中最常见的风险之一,它们是最安全编码最佳实践指南的一部分。注入攻击试图利用在执行或评估之前将不受信任的输入直接传递给解释器的代码。

由于无服务器函数可以从不同的事件源触发,如云存储 (Blob)、NoSQL 数据库 (CosmosDB)、事件中心、队列、图形事件等,因此注入并不严格限于直接来自 API 调用的输入和函数可以使用来自每种类型的可能事件源的输入。

你该怎么办?

• 一般来说,永远不要相信输入或对其有效性做出任何假设。

• 始终使用安全的 API 来清理或验证输入。如果可能,使用绑定或参数化变量的 API(例如,使用准备好的语句进行 SQL 查询)。

using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
using System.Text.RegularExpressions;   

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    log.LogInformation("C# HTTP trigger function processed a request.");
    string name = req.Query["name"];
    string validate_name_pattern = @"^[a-zA-Z-.' ]{2,64}$";

    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    dynamic data = JsonConvert.DeserializeObject(requestBody);
    name = name ?? data?.name;

    bool isNameValid = Regex.IsMatch(name, validate_name_pattern);      
    log.LogInformation("Input validation result for " + name + ": " + isNameValid);

    return name != null && isNameValid
        ? (ActionResult)new OkObjectResult($"Hello, {name}")
        : new BadRequestObjectResult("Invalid name");
}

进入全屏模式 退出全屏模式

2\。遵循最小权限原则

底线:无服务器功能应仅具有执行其预期逻辑所必需的特权,遵循 “最小特权原则”。

由于无服务器功能通常被设计为微服务,因此在应用程序中拥有数十、数百甚至数千个功能是很常见的。管理功能权限和角色是一项艰巨而乏味的任务。

在许多情况下,开发人员被迫对所有功能使用单一权限模型或安全角色,这授予他们访问该功能实际上不需要的其他系统组件的权限。利用过度特权的功能可能会导致组织云中的安全灾难。

指定负责 Azure 中特定功能的组或个人角色有助于避免可能导致人为错误和自动化错误的混淆,从而产生安全风险。

该怎么办?

• 在部署之前检查每个功能以识别过多的权限

• 仔细检查函数以应用“最小特权”权限,准确地给出每个函数,并且只给出函数成功执行其任务所需的内容

• 建议使用工具自动化权限配置过程,如我们在Protego

• 使用RBAC为特定范围内的用户、组和应用程序分配权限。角色分配的范围可以是订阅、资源组或单个资源,并尽可能避免使用通配符 (*)

[](https://res.cloudinary.com/practicaldev/image/fetch/s--pTw7ZBQy--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://docs.microsoft.com /en-us/azure/role-based-access-control/media/overview/rbac-overview.png)

• 使用共享访问签名 (SAS)令牌来获得对其他资源和服务的有限访问

[](https://res.cloudinary.com/practicaldev/image/fetch/s--xhFodgc---/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://i.imgur。 com/9PvFRu3.png)

3\。监控第三方依赖

无服务器函数的代码通常很小。但是,为了能够执行所需的任务,函数会使用许多依赖项和 3rd-party 库。

供应链引入的漏洞是当今最常见的风险之一,攻击者会将利用易受攻击的库作为应用程序入口点的代码作为攻击目标。

此外,在我们所说的“毒井”中,攻击者旨在通过上游攻击在应用程序中获得更长期的持久性。在给井下毒之后,他们耐心地等待新版本进入云应用程序。

如果您使用 .NET,Microsoft 将公布有关具有已知漏洞的 NuGet 包,例如这个。但是,这对所有运行时都有效。无论您是使用 Python (pip)、Java (Maven)、Node (npm) 还是任何其他包管理。

你该怎么办?

• 使用 OWASPDependency Track或任何其他系统持续监控整个系统的依赖关系及其版本

• 仅通过安全链接从官方来源获取组件。

• 首选签名包以减少包含经过修改的恶意组件的机会

• 使用漏洞数据库持续监控软件包,例如MITRE CVE和NVD

• 建议使用 OWASPDependency Check等工具或商业解决方案扫描依赖项以查找已知漏洞。

• 对于 dotnet,使用dotnet-retire。检查具有已知漏洞的版本的依赖关系的工具

[](https://res.cloudinary.com/practicaldev/image/fetch/s--ovuKmgy5--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://i.imgur .com/ngAyrAg.png)

• 使用 OWASPSafeNuGet检查 NuGet 包漏洞

• 使用依赖于运行时的安全数据库,例如pyupfor Python 和npm Security AdvisoriesFor Node

• 使用Audit.NET与 VS 集成来识别 .Net NuGet 依赖项中的已知漏洞

4\。保护您的云存储

配置错误的云存储身份验证/授权是影响应用程序的普遍弱点。有许多不安全的云存储配置事件将敏感的机密信息暴露给未经授权的用户。有时,这些数据甚至可以在被搜索引擎索引后公开。

由于无服务器功能通常是无状态的,因此许多应用程序的架构依赖于云存储基础架构来存储和持久化执行之间的数据。

如果云存储没有实施适当的访问控制,用户可能能够将文件直接上传到其中,从而导致消耗高配额并触发内部功能。

你该怎么办?

• 识别和分类敏感数据

• 将敏感数据的存储最小化到绝对必要的范围内

• 对于敏感数据存储,添加多因素身份验证和数据加密(传输中和静态)

• 查看Azure 存储安全指南

• 使用共享访问签名 (SAS)授予对 Azure 存储资源的有限访问权限

[](https://res.cloudinary.com/practicaldev/image/fetch/s--eSztazKc--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://docs.microsoft .com/en-us/azure/storage/common/media/storage-sas-overview/sas-storage-provider-service.png)

5\。保护您的函数机密

在我们的应用程序中总是需要存储和维护_secrets_。秘密可以是 API 密钥、其他资源(例如数据库)的凭据、加密密钥(加密/解密)和敏感的配置设置。

将此类机密存储在纯文本配置文件中最终可能会被上传到,并通过共享存储库(例如 Github)泄露。黑客使用多个工具来尝试识别此类泄露的密钥。有很多故事

虽然环境变量是跨无服务器函数执行保存数据的有用方法,但在某些情况下,此类环境变量可能会泄漏并落入坏人之手。

将此类机密存储在安全、加密的存储环境中至关重要。

该怎么办?

• 使用 MicrosoftCredScan工具来识别凭据泄漏

• 尽可能在集中式加密密钥管理基础架构或服务中管理加密密钥,例如 AzureKey-vault

[](https://res.cloudinary.com/practicaldev/image/fetch/s--5DXoUdeG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://i .imgur.com/ldf6Pnb.png)

• 您可以阅读 Microsoft MVP Jan de Vries 的Working with Azure Key Vault in Azure Functions

• 阅读How to handle secrets with Azure Functions,David O'Brien,Microsoft Azure MVP

• 通过 Git 使用包含敏感信息的配置文件时,请确保将它们添加到.gitignore文件中

6\。强制认证和授权

无服务器架构要求我们编排所有功能和服务以形成整体系统逻辑。虽然一些函数公开了公共 API,但其他函数充当进程之间的管道,并且有多种方法可以触发它们,包括内部触发事件。

无服务器架构的无状态特性需要对每个资源进行仔细的访问控制配置,这可能很繁重。

想象一个无服务器应用程序,它公开了一组公共 API,所有这些都强制执行正确的身份验证。在系统的另一端,应用程序从 blob 存储服务读取文件,其中文件内容被用作特定无服务器功能的输入。如果未对云存储服务应用适当的身份验证,则系统将暴露未经身份验证的恶意入口点——这是系统设计期间未考虑的元素。

该怎么办?

• 审核并申请Azure App Service中的身份验证和授权

• 遵循Azure 身份管理和访问控制安全最佳实践

• 面向外部的资源应该需要身份验证和访问控制。审查Azure API 管理保障由 Microsoft 首席软件开发工程师 Stuart Leeks 撰写

[](https://res.cloudinary.com/practicaldev/image/fetch/s--hzML1L1T--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://i .imgur.com/KWCuZoj.png)

• 对于内部资源和服务之间的服务认证,使用已知的安全方法,例如联合身份(例如 SAML、OAuth2、安全令牌)

接下来是什么?

我可以继续讨论这个话题。但我相信,专注于一些高影响力、实用的安全实施可以极大地提高 Azure 功能的安全性。

对于那些_do_想要了解更多信息的人,我可以建议:

• 关注开源OWASP Serverless Top 10风险项目

• 来我的演讲或虚拟观看(如果有的话)

• 在Twitter上关注我,了解有关新的安全研究、演示、挑战、会谈、想法和参考的更多信息。

• 如果你想看看 villains 的想法。这是我上次@DerbyCon的#ServerlessHacking 演讲