保护 Azure FunctionsSecuring Azure Functions

对于 Web 或云托管应用程序来说,无服务器函数的安全开发、部署和操作的规划在诸多方面都几乎相同。In many ways, planning for secure development, deployment, and operation of serverless functions is much the same as for any web-based or cloud hosted application. Azure 应用服务提供函数应用的托管基础结构。Azure App Service provides the hosting infrastructure for your function apps. 本文介绍了运行函数代码的安全策略,以及应用服务如何帮助你保护函数。This article provides security strategies for running your function code, and how App Service can help you secure your functions.

应用服务的各个平台组件(包括 Azure VM、存储、网络连接、Web 框架、管理和集成功能)都得到了积极保护和加强。The platform components of App Service, including Azure VMs, storage, network connections, web frameworks, management and integration features, are actively secured and hardened. 应用服务持续进行严格的符合性检查,以确保:App Service goes through vigorous compliance checks on a continuous basis to make sure that:

  • 你的应用资源与其他客户的 Azure 资源隔离开来,从而受到保护Your app resources are secured from the other customers' Azure resources.
  • 定期更新 VM 实例和运行时软件,以解决新发现的漏洞。VM instances and runtime software are regularly updated to address newly discovered vulnerabilities.
  • 你的应用与其他 Azure 资源(例如 SQL 数据库)之间的密钥(例如连接字符串)通信一直在 Azure 中进行,不跨越任何网络边界。Communication of secrets (such as connection strings) between your app and other Azure resources (such as SQL Database) stays within Azure and doesn't cross any network boundaries. 存储密钥时始终对其加密。Secrets are always encrypted when stored.
  • 通过应用服务连接功能(例如混合连接)进行的所有通信均已加密。All communication over the App Service connectivity features, such as hybrid connection, is encrypted.
  • 与 Azure PowerShell、Azure CLI、Azure SDK、REST API 等远程管理工具的连接均已加密。Connections with remote management tools like Azure PowerShell, Azure CLI, Azure SDKs, REST APIs, are all encrypted.
  • 24 小时威胁管理可保护基础结构和平台免受恶意软件、分布式拒绝服务 (DDoS)、中间人 (MITM) 和其他威胁的危害。24-hour threat management protects the infrastructure and platform against malware, distributed denial-of-service (DDoS), man-in-the-middle (MITM), and other threats.

安全操作Secure operation

本部分将指导你尽可能安全地配置和运行函数应用。This section guides you on configuring and running your function app as securely as possible.

安全中心Security Center

安全中心与门户中的函数应用集成。Security Center integrates with your function app in the portal. 它免费提供了对潜在配置相关安全漏洞的快速评估。It provides, for free, a quick assessment of potential configuration-related security vulnerabilities. 在专用计划中运行的函数应用也可以使用安全中心的实时安全功能,但需要额外付费。Function apps running in a dedicated plan can also use the real-time security features of Security Center, for an additional cost. 若要了解更多信息,请参阅保护你的 Azure 应用服务 Web 应用和 APITo learn more, see Protect your Azure App Service web apps and APIs.

日志和监视器Log and monitor

检测攻击的方法之一是通过活动监视活动和日志分析。One to detect attacks is through activity monitoring activity and logging analytics. Functions 与 Application Insights 相集成,可收集函数应用的日志、性能和错误数据。Functions integrates with Application Insights to collects log, performance, and error data for your function app. Application Insights 可自动检测性能异常,并且包含了强大的分析工具来帮助你诊断问题并了解函数的使用方式。Application Insights automatically detects performance anomalies and includes powerful analytics tools to help you diagnose issues and to understand how your functions are used. 若要了解详细信息,请参阅监视 Azure FunctionsTo learn more, see Monitor Azure Functions.

Functions 还与 Azure Monitor 日志集成,使你能够将函数应用日志与系统事件合并,以便更轻松地进行分析。Functions also integrates with Azure Monitor Logs to enable you to consolidate function app logs with system events for easier analysis. 你可以使用诊断设置将函数的平台日志和指标流式导出配置到你选择的目标位置,例如 Log Analytics 工作区。You can use diagnostic settings to configure streaming export of platform logs and metrics for your functions to the destination of your choice, such as a Logs Analytics workspace.

对于企业级威胁检测和响应自动化,请将日志和事件流式传输到 Log Analytics 工作区。For enterprise-level threat detection and response automation, stream your logs and events to a Logs Analytics workspace.

需要 HTTPSRequire HTTPS

默认情况下,客户端可以使用 HTTP 或 HTTPS 连接到函数终结点。By default, clients can connect to function endpoints by using both HTTP or HTTPS. 应将 HTTP 重定向到 HTTPS,因为 HTTPS 使用 SSL/TLS 协议来提供安全连接,该连接经过了加密和身份验证。You should redirect HTTP to HTTPs because HTTPS uses the SSL/TLS protocol to provide a secure connection, which is both encrypted and authenticated. 若要了解如何操作,请参阅实施 HTTPSTo learn how, see Enforce HTTPS.

需要 HTTPS 时,还需要最新的 TLS 版本。When you require HTTPS, you should also Require the latest TLS version. 若要了解如何操作,请参阅实施 TLS 版本To learn how, see Enforce TLS versions.

有关详细信息,请参阅 保护连接 (TSL)For more information, see Secure connections (TSL).

函数访问密钥Function access keys

Functions 允许使用密钥使其难以在开发过程中访问 HTTP 函数终结点。Functions lets you use keys to make it harder to access your HTTP function endpoints during development. 除非 HTTP 触发的函数中的 HTTP 访问级别设置为 anonymous,否则请求中必须包含 API 访问密钥。Unless the HTTP access level on an HTTP triggered function is set to anonymous, requests must include an API access key in the request.

授权作用域(函数级)Authorization scopes (function-level)

函数级密钥有两个访问权限作用域:There are two access scopes for function-level keys:

  • 函数:这些密钥仅适用于在其下定义它们的特定函数。Function: These keys apply only to the specific functions under which they are defined. 这些密钥用作 API 密钥时,只允许访问该函数。When used as an API key, these only allow access to that function.

  • 主机:具有主机作用域的密钥可用于访问函数应用中的所有函数。Host: Keys with a host scope can be used to access all functions within the function app. 这些密钥用作 API 密钥时,可以访问 Function App 中的任何函数。When used as an API key, these allow access to any function within the function app.

命名每个密钥方便引用,并且在函数和主机级别存在名为“default”的默认密钥。Each key is named for reference, and there is a default key (named "default") at the function and host level. 函数密钥优先于主机密钥。Function keys take precedence over host keys. 如果为两个密钥定义的名称相同,则使用函数密钥。When two keys are defined with the same name, the function key is always used.

主密钥(管理级)Master key (admin-level)

每个函数应用还有一个名为 _master 的管理级主机密钥。Each function app also has an admin-level host key named _master. 除了提供对应用中所有函数的主机级访问以外,主密钥还提供对运行时 REST API 的管理访问。In addition to providing host-level access to all functions in the app, the master key also provides administrative access to the runtime REST APIs. 无法撤消此密钥。This key cannot be revoked. 设置 admin 访问级别时,请求必须使用主密钥;使用任何其他密钥会导致访问失败。When you set an access level of admin, requests must use the master key; any other key results in access failure.

注意

由于函数应用中提升的权限由主密钥所授予,因此不应与第三方共享此密钥或在本机客户端应用程序中分发此密钥。Due to the elevated permissions in your function app granted by the master key, you should not share this key with third parties or distribute it in native client applications. 选择管理访问级别时请慎重。Use caution when choosing the admin access level.

系统密钥System key

特定扩展可能需要系统管理的密钥才能访问 webhook 终结点。Specific extensions may require a system-managed key to access webhook endpoints. 系统密钥适合为内部组件调用的特定于扩展的函数终结点。System keys are designed for extension-specific function endpoints that called by internal components. 例如,事件网格触发器要求订阅在调用触发器终结点时使用系统密钥。For example, the Event Grid trigger requires that the subscription use a system key when calling the trigger endpoint. Durable Functions 还使用系统密钥调用 Durable 任务扩展 APIDurable Functions also uses system keys to call Durable Task extension APIs.

系统密钥的范围由扩展决定,但通常适用于整个函数应用。The scope of system keys is determined by the extension, but it generally applies to the entire function app. 系统密钥只能由特定扩展创建,并且不能显式设置其值。System keys can only be created by specific extensions, and you can't explicitly set their values. 与其他密钥一样,你可从门户或使用密钥 API 为密钥生成新值。Like other keys, you can generate a new value for the key from the portal or by using the key APIs.

密钥之间的比较Keys comparison

下表比较了不同类型的访问密钥的用法:The following table compares the uses for various kinds of access keys:

操作Action 范围Scope 有效密钥Valid keys
执行函数Execute a function 特定函数Specific function 函数Function
执行函数Execute a function 任何函数Any function 函数或主机Function or host
调用管理员终结点Call an admin endpoint 函数应用Function app 主机(仅限 master)Host (master only)
调用 Durable 任务扩展 APICall Durable Task extension APIs 函数应用1Function app1 系统2System2
调用特定于扩展的 Webhook(内部)Call an extension-specific Webhook (internal) 函数应用1Function app1 系统2system2

1范围由扩展决定。1Scope determined by the extension.
2按扩展设置的特定名称。2Specific names set by extension.

若要了解有关访问密钥的更多信息,请参阅 HTTP 触发器绑定文章To learn more about access keys, see the HTTP trigger binding article.

机密存储库Secret repositories

默认情况下,密钥存储在通过 AzureWebJobsStorage 设置提供的帐户中的 Blob 存储容器中。By default, keys are stored in a Blob storage container in the account provided by the AzureWebJobsStorage setting. 可以使用特定的应用程序设置来重写此行为,将密钥存储在另一位置。You can use specific application settings to override this behavior and store keys in a different location.

位置Location 设置Setting Value 描述Description
不同的存储帐户Different storage account AzureWebJobsSecretStorageSas <BLOB_SAS_URL 根据提供的 SAS URL,将密钥存储在另一个存储帐户的 Blob 存储中。Stores keys in Blob storage of a second storage account, based on the provided SAS URL. 在使用函数应用特有的机密存储密钥之前对密钥进行加密。Keys are encrypted before being stored using a secret unique to your function app.
文件系统File system AzureWebJobsSecretStorageType files 密钥持久保留在文件系统中,在使用函数应用特有的机密进行存储之前加密。Keys are persisted on the file system, encrypted before storage using a secret unique to your function app.
Azure Key VaultAzure Key Vault AzureWebJobsSecretStorageType
AzureWebJobsSecretStorageKeyVaultName
keyvault
<VAULT_NAME>
保管库必须有一项与承载资源的系统分配托管标识相对应的访问策略。The vault must have an access policy corresponding to the system-assigned managed identity of the hosting resource. 访问策略应向标识授予以下机密权限:GetSetListDeleteThe access policy should grant the identity the following secret permissions: Get,Set, List, and Delete.
在本地运行时使用开发人员标识,且设置必须位于 local.settings.json 文件中。When running locally, the developer identity is used, and settings must be in the local.settings.json file.
Kubernetes 机密Kubernetes Secrets AzureWebJobsSecretStorageType
AzureWebJobsKubernetesSecretName(可选)AzureWebJobsKubernetesSecretName (optional)
kubernetes
<SECRETS_RESOURCE>
仅当在 Kubernetes 中运行 Functions 运行时时才受支持。Supported only when running the Functions runtime in Kubernetes. 如果未设置 AzureWebJobsKubernetesSecretName,则会将存储库视为只读。When AzureWebJobsKubernetesSecretName isn't set, the repository is considered read-only. 在这种情况下,必须在部署之前生成值。In this case, the values must be generated before deployment. 在部署到 Kubernetes 时,Azure Functions Core Tools 会自动生成值。The Azure Functions Core Tools generates the values automatically when deploying to Kubernetes.

身份验证/授权Authentication/authorization

虽然函数密钥可以为不需要的访问提供一些缓解措施,但真正保护函数终结点的唯一方法是实现对访问函数的客户端的主动身份验证。While function keys can provide some mitigation for unwanted access, the only way to truly secure your function endpoints is by implementing positive authentication of clients accessing your functions. 然后,你可以根据身份做出授权决策。You can then make authorization decisions based on identity.

启用应用服务身份验证/授权Enable App Service Authentication/Authorization

借助应用服务平台可以使用 Azure Active Directory (AAD) 和多个第三方标识提供者对客户端进行身份验证。The App Service platform lets you use Azure Active Directory (AAD) and several third-party identity providers to authenticate clients. 可以使用此策略来实现函数的自定义授权规则,并且可以从函数代码处理用户信息。You can use this strategy to implement custom authorization rules for your functions, and you can work with user information from your function code. 若要了解详细信息,请参阅 Azure 应用服务中的身份验证和授权以及使用客户端标识To learn more, see Authentication and authorization in Azure App Service and Working with client identities.

使用 Azure API 管理 (APIM) 对请求进行身份验证Use Azure API Management (APIM) to authenticate requests

APIM 为传入请求提供了各种 API 安全选项。APIM provides a variety of API security options for incoming requests. 若要了解详细信息,请参阅 API 管理身份验证策略To learn more, see API Management authentication policies. 有了 APIM,可以配置函数应用以接受仅来自 APIM 实例 IP 地址的请求。With APIM in place, you can configure your function app to accept requests only from the IP address of your APIM instance. 若要了解详细信息,请参阅 IP 地址限制To learn more, see IP address restrictions.

权限Permissions

与任何应用程序或服务一样,目标是以尽可能低的权限运行函数应用。As with any application or service, the goal is run your function app with the lowest possible permissions.

用户管理权限User management permissions

函数支持内置 Azure 基于角色的访问控制 (Azure RBAC)Functions supports built-in Azure role-based access control (Azure RBAC). 函数支持的 Azure 角色有参与者所有者读者Azure roles supported by Functions are Contributor, Owner, and Reader.

权限在函数应用级别有效。Permissions are effective at the function app level. 参与者角色是执行大多数函数应用级任务所必需的。The Contributor role is required to perform most function app-level tasks. 只有所有者角色才能删除函数应用。Only the Owner role can delete a function app.

按权限组织函数Organize functions by privilege

应用程序设置中存储的连接字符串和其他凭据为函数应用中的所有函数提供了关联资源中相同的权限集。Connection strings and other credentials stored in application settings gives all of the functions in the function app the same set of permissions in the associated resource. 请考虑将具有特定凭据访问权限的函数数量降至最少,具体方法是将不使用这些凭据的函数移动到单独的函数应用中。Consider minimizing the number of functions with access to specific credentials by moving functions that don't use those credentials to a separate function app. 你始终可以使用诸如函数链之类的技术在不同函数应用中的函数之间传递数据。You can always use techniques such as function chaining to pass data between functions in different function apps.

托管标识Managed identities

借助 Azure Active Directory (Azure AD) 的托管标识,应用可以轻松访问其他受 Azure AD 保护的资源(如 Azure Key Vault)。A managed identity from Azure Active Directory (Azure AD) allows your app to easily access other Azure AD-protected resources such as Azure Key Vault. 标识由 Azure 平台托管,无需设置或转交任何机密。The identity is managed by the Azure platform and does not require you to provision or rotate any secrets. 有关 Azure AD 中的托管标识的详细信息,请参阅 Azure 资源的托管标识For more about managed identities in Azure AD, see Managed identities for Azure resources.

你的应用程序可以被授予两种类型的标识:Your application can be granted two types of identities:

  • 系统分配的标识与你的应用程序相绑定,如果删除应用,标识也会被删除。A system-assigned identity is tied to your application and is deleted if your app is deleted. 一个应用只能具有一个系统分配的标识。An app can only have one system-assigned identity.
  • 用户分配的标识是可以分配给应用的独立 Azure 资源。A user-assigned identity is a standalone Azure resource that can be assigned to your app. 一个应用可以具有多个用户分配的标识。An app can have multiple user-assigned identities.

有关详细信息,请参阅如何使用应用服务和 Azure Functions 的托管标识For more information, see How to use managed identities for App Service and Azure Functions.

限制 CORS 访问Restrict CORS access

跨源资源共享 (CORS) 是一种允许在另一个域中运行的 Web 应用向 HTTP 触发器终结点发出请求的方法。Cross-origin resource sharing (CORS) is a way to allow web apps running in another domain to make requests to your HTTP trigger endpoints. 应用服务为在 HTTP 请求中处理所需的 CORS 标头提供了内置支持。App Service provides built-in support for handing the required CORS headers in HTTP requests. CORS 规则是在函数应用级别定义的。CORS rules are defined on a function app level.

虽然很容易使用通配符来允许所有站点访问终结点。While it's tempting to use a wildcard that allows all sites to access your endpoint. 但这违背了 CORS 的目的,CORS 的目的是帮助防止跨站点脚本攻击。But, this defeats the purpose of CORS, which is to help prevent cross-site scripting attacks. 相反,请为必须访问终结点的每个 Web 应用的域添加单独的 CORS 条目。Instead, add a separate CORS entry for the domain of each web app that must access your endpoint.

管理机密Managing secrets

为了能够连接到运行代码所需的各种服务和资源,函数应用需要能够访问机密,如连接字符串和服务密钥。To be able to connect to the various services and resources need to run your code, function apps need to be able to access secrets, such as connection strings and service keys. 本节介绍如何存储函数所需的机密。This section describes how to store secrets required by your functions.

切勿在函数代码中存储机密。Never store secrets in your function code.

应用程序设置Application settings

默认情况下,请将函数应用使用的连接字符串和机密以及绑定存储为应用程序设置。By default, you store connection strings and secrets used by your function app and bindings as application settings. 这样,函数代码和函数使用的各种绑定就都可以使用这些凭据。This makes these credentials available to both your function code and the various bindings used by the function. 应用程序设置(密钥)名称用于检索实际值,即机密。The application setting (key) name is used to retrieve the actual value, which is the secret.

例如,每个函数应用都需要一个关联的存储帐户,运行时将使用该帐户。For example, every function app requires an associated storage account, which is used by the runtime. 默认情况下,与此存储帐户的连接存储在名为 AzureWebJobsStorage 的应用程序设置中。By default, the connection to this storage account is stored in an application setting named AzureWebJobsStorage.

应用设置和连接字符串以加密方式存储在 Azure 中。App settings and connection strings are stored encrypted in Azure. 只有在应用程序启动时,它们才会被解密,然后再注入到应用程序内存中。They're decrypted only before being injected into your app's process memory when the app starts. 加密密钥会定期轮换。The encryption keys are rotated regularly. 如果希望管理机密的安全存储,则应该将应用设置改为对 Azure Key Vault 的引用。If you prefer to instead manage the secure storage of your secrets, the app setting should instead be references to Azure Key Vault.

Key Vault 引用Key Vault references

虽然应用程序设置足以满足大多数功能,但你可能希望跨多个服务共享相同的机密。While application settings are sufficient for most many functions, you may want to share the same secrets across multiple services. 在这种情况下,机密的冗余存储会导致更多潜在的漏洞。In this case, redundant storage of secrets results in more potential vulnerabilities. 一种更安全的方法是使用中央机密存储服务,并使用对该服务的引用而不是对机密本身的引用。A more secure approach is to a central secret storage service and use references to this service instead of the secrets themselves.

Azure Key Vault 是一项服务,可以提供集中式机密管理,并且可以完全控制访问策略和审核历史记录。Azure Key Vault is a service that provides centralized secrets management, with full control over access policies and audit history. 你可在应用程序设置中使用 Key Vault 引用来代替连接字符串或密钥。You can use a Key Vault reference in the place of a connection string or key in your application settings. 若要了解详细信息,请参阅使用应用服务和 Azure Functions 的 Key Vault 引用To learn more, see Use Key Vault references for App Service and Azure Functions.

设置使用配额Set usage quotas

考虑为在消耗计划中运行的函数设置使用配额。Consider setting a usage quota on functions running in a Consumption plan. 如果对函数应用中函数的总执行量设置每日 GB-sec 限制,当达到该限制时,将停止执行。When you set a daily GB-sec limit on the sum total execution of functions in your function app, execution is stopped when the limit is reached. 这可能有助于缓解恶意代码执行函数。This could potentially help mitigate against malicious code executing your functions. 若要了解如何估算函数的消耗量,请参阅估算消耗计划成本To learn how to estimate consumption for your functions, see Estimating Consumption plan costs.

数据验证Data validation

函数使用的触发器和绑定不提供任何额外的数据验证。The triggers and bindings used by your functions don't provide any additional data validation. 代码必须验证从触发器或输入绑定接收到的任何数据。Your code must validate any data received from a trigger or input binding. 如果上游服务遭到入侵,你不希望未经验证的输入流经函数。If an upstream service is compromised, you don't want unvalidated inputs flowing through your functions. 例如,如果函数将 Azure 存储队列中的数据存储在关系数据库中,则必须验证数据并对命令进行参数化处理以避免 SQL 注入攻击。For example, if your function stores data from an Azure Storage queue in a relational database, you must validate the data and parameterize your commands to avoid SQL injection attacks.

不要以为传入函数的数据已经过验证或清理。Don't assume that the data coming into your function has already been validated or sanitized. 最好是验证写入输出绑定的数据是否有效。It's also a good idea to verify that the data being written to output bindings is valid.

处理错误Handle errors

虽然它看起来很基础,但这对于在函数中编写良好的错误处理来说非常重要。While it seems basic, it's important to write good error handling in your functions. 未处理的错误从主机中涌现出来,然后由运行时处理。Unhandled errors bubble-up to the host and are handled by the runtime. 不同绑定处理错误的方式不同。Different bindings handle processing of errors differently. 有关详细信息,请参阅 Azure Functions 错误处理To learn more, see Azure Functions error handling.

禁用远程调试Disable remote debugging

请确保禁用远程调试,除非你正在主动调试函数。Make sure that remote debugging is disabled, except when you are actively debugging your functions. 可以在门户中函数应用“配置”的“常规设置”选项卡中禁用远程调试 。You can disable remote debugging in the General Settings tab of your function app Configuration in the portal.

限制 CORS 访问Restrict CORS access

Azure Functions 支持跨域资源共享 (CORS)。Azure Functions supports cross-origin resource sharing (CORS). CORS 在门户中以及通过 Azure CLI 进行配置。CORS is configured in the portal and through the Azure CLI. CORS 允许的来源列表应用于函数应用级别。The CORS allowed origins list applies at the function app level. 启用 CORS 后,响应包含 Access-Control-Allow-Origin 标头。With CORS enabled, responses include the Access-Control-Allow-Origin header. 有关详细信息,请参阅 跨域资源共享For more information, see Cross-origin resource sharing.

请勿在允许的来源列表中使用通配符。Don't use wildcards in your allowed origins list. 相反,你可以列出想要从中获取请求的特定域。Instead, list the specific domains from which you expect to get requests.

存储加密数据Store data encrypted

Azure 存储可对存储帐户中的所有数据进行静态加密。Azure Storage encrypts all data in a storage account at rest. 有关详细信息,请参阅静态数据的 Azure 存储加密For more information, see Azure Storage encryption for data at rest.

默认情况下,数据使用 Microsoft 管理的密钥进行加密。By default, data is encrypted with Microsoft-managed keys. 为了进一步控制加密密钥,可以提供客户管理的密钥,用于对 blob 和文件数据进行加密。For additional control over encryption keys, you can supply customer-managed keys to use for encryption of blob and file data. 这些密钥必须存在于 Azure Key Vault 中,以便 Functions 能够访问存储帐户。These keys must be present in Azure Key Vault for Functions to be able to access the storage account. 若要了解详细信息,请参阅使用客户管理的密钥进行静态加密To learn more, see Encryption at rest using customer-managed keys.

保护部署Secure deployment

Azure Functions 工具集成可以简化将本地函数项目代码发布到 Azure 的过程。Azure Functions tooling an integration make it easy to publish local function project code to Azure. 在考虑 Azure Functions 拓扑的安全性时,请务必了解部署的工作方式。It's important to understand how deployment works when considering security for an Azure Functions topology.

部署凭据Deployment credentials

部署应用服务需要一组部署凭据。App Service deployments require a set of deployment credentials. 这些部署凭据用于保护函数应用部署。These deployment credentials are used to secure your function app deployments. 部署凭据由应用服务平台管理,并静态加密。Deployment credentials are managed by the App Service platform and are encrypted at rest.

部署凭据有两种类型:There are two kinds of deployment credentials:

  • 用户级凭据:一组适用于整个 Azure 帐户的凭据。User-level credentials: one set of credentials for the entire Azure account. 需要部署到任何订阅(Azure 帐户有权对其进行访问)中的任何应用的应用服务时,可以使用这组凭据。It can be used to deploy to App Service for any app, in any subscription, that the Azure account has permission to access. 这是在门户 GUI(例如应用的资源页的“概览”和“属性”)中呈现的默认组。 It's the default set that's surfaced in the portal GUI (such as the Overview and Properties of the app's resource page). 当通过基于角色的访问控制 (RBAC) 或共同管理员权限授予用户应用访问权限时,该用户便可使用其用户级别的凭据,直到被撤销访问权限。When a user is granted app access via Role-Based Access Control (RBAC) or coadmin permissions, that user can use their own user-level credentials until the access is revoked. 请勿与其他 Azure 用户共享这些凭据。Do not share these credentials with other Azure users.

  • 应用级凭据:一组适用于每个应用的凭据。App-level credentials: one set of credentials for each app. 若要只部署到该应用,则可使用这组凭据。It can be used to deploy to that app only. 每个应用的凭据在其创建时自动生成。The credentials for each app are generated automatically at app creation. 这些凭据不能手动进行配置,但可随时进行重置。They can't be configured manually, but can be reset anytime. 如果要通过 (RBAC) 授予用户访问应用级别凭据的权限,该用户必须是应用的参与者或更高级别身份(包括网站参与者内置角色)。For a user to be granted access to app-level credentials via (RBAC), that user must be contributor or higher on the app (including Website Contributor built-in role). 读者不可进行发布,因此无法访问这些凭据。Readers are not allowed to publish, and can't access those credentials.

目前,部署凭据不支持 Key Vault。At this time, Key Vault isn't supported for deployment credentials. 若要了解如何管理部署凭据,请参阅为 Azure 应用服务配置部署凭据To learn more about managing deployment credentials, see Configure deployment credentials for Azure App Service.

禁用 FTPDisable FTP

默认情况下,每个函数应用都启用了 FTP 终结点。By default, each function app has an FTP endpoint enabled. 使用部署凭据访问 FTP 终结点。The FTP endpoint is accessed using deployment credentials.

不建议使用 FTP 来部署函数代码。FTP isn't recommended for deploying your function code. FTP 部署是手动的,需要同步触发器。FTP deployments are manual, and they require you to synchronize triggers. 若要了解详细信息,请参阅 FTP 部署To learn more, see FTP deployment.

如果不打算使用 FTP,则应在门户中禁用它。When you're not planning on using FTP, you should disable it in the portal. 如果选择使用 FTP,则应实施 FTPSIf you do choose to use FTP, you should enforce FTPS.

保护 scm 终结点Secure the scm endpoint

每个函数应用都有一个对应的 scm 服务终结点,供高级工具 (Kudu) 服务用于部署和其他应用服务站点扩展Every function app has a corresponding scm service endpoint that used by the Advanced Tools (Kudu) service for deployments and other App Service site extensions. 函数应用的 scm 终结点始终是 https://<FUNCTION_APP_NAME.scm.chinacloudsites.cn> 格式的 URL。The scm endpoint for a function app is always a URL in the form https://<FUNCTION_APP_NAME.scm.chinacloudsites.cn>. 如果使用网络隔离保护函数,还必须考虑此终结点。When you use network isolation to secure your functions, you must also account for this endpoint.

具有独立的 scm 端点使你可以控制针对隔离或在虚拟网络中运行的函数应用的部署和其他高级工具功能。By having a separate scm endpoint, you can control deployments and other advanced tools functionalities for function app that are isolated or running in a virtual network. scm 终结点支持基本身份验证(使用部署凭据)和使用 Azure 门户凭据进行单一登录。The scm endpoint supports both basic authentication (using deployment credentials) and single sign-on with your Azure portal credentials. 若要了解详细信息,请参阅访问 Kudu 服务To learn more, see Accessing the Kudu service.

持续安全性验证Continuous security validation

由于开发过程中的每一步都需要考虑安全性,因此在持续部署环境中实现安全性验证也是有意义的。Since security needs to be considered a every step in the development process, it make sense to also implement security validations in a continuous deployment environment.

网络安全性Network security

通过限制对函数应用的网络访问,可以控制谁可以访问函数终结点。Restricting network access to your function app lets you control who can access your functions endpoints. 函数利用应用服务基础结构,使函数能够访问资源而无需使用可通过 internet 路由的地址,或将 internet 访问限制为函数终结点。Functions leverages App Service infrastructure to enable your functions to access resources without using internet-routable addresses or to restrict internet access to a function endpoint. 若要了解有关这些网络选项的详细信息,请参阅 Azure Functions 网络选项To learn more about these networking options, see Azure Functions networking options.

设置访问限制Set access restrictions

访问限制使你可以定义允许/拒绝规则列表,以控制应用的流量。Access restrictions allow you to define lists of allow/deny rules to control traffic to your app. 规则按优先顺序进行评估。Rules are evaluated in priority order. 如果没有定义规则,则应用将接受来自任何地址的流量。If there are no rules defined, then your app will accept traffic from any address. 若要了解更多信息,请参阅 Azure 应用服务访问限制 #To learn more, see Azure App Service Access Restrictions #.

专用站点访问Private site access

专用站点访问是指使应用只能从专用网络(例如 Azure 虚拟网络)进行访问。Private site access refers to making your app accessible only from a private network, such as an Azure virtual network.

  • 配置了服务终结点时,消耗应用服务计划中会提供专用站点访问。Private site access is available in the Consumption, and App Service plans when service endpoints are configured.
    • 可以在“平台功能” > “网络” > “配置访问限制” > “添加规则”下为每个应用配置服务终结点。Service endpoints can be configured on a per-app basis under Platform features > Networking > Configure Access Restrictions > Add Rule. 现在可以选择虚拟网络作为规则类型。Virtual networks can now be selected as a rule type.
    • 有关详细信息,请参阅虚拟网络服务终结点For more information, see Virtual network service endpoints.
    • 请记住,使用服务终结点时,即使配置了虚拟网络集成,你的函数也还是对 Internet 具有完全出站访问权限。Keep in mind that with service endpoints, your function still has full outbound access to the internet, even with virtual network integration configured.
  • 还可在配置了内部负载均衡器 (ILB) 的应用服务环境中获取专用站点访问。Private site access is also available within an App Service Environment that's configured with an internal load balancer (ILB). 有关详细信息,请参阅在应用服务环境中创建和使用内部负载均衡器For more information, see Create and use an internal load balancer with an App Service Environment.

在隔离环境中部署函数应用Deploy your function app in isolation

Azure 应用服务环境 (ASE) 提供了用于运行函数的专用宿主环境。Azure App Service Environment (ASE) provides a dedicated hosting environment in which to run your functions. ASE 允许配置单个前端网关,可以使用它对所有传入请求进行身份验证。ASE lets you configure a single front-end gateway that you can use to authenticate all incoming requests. 有关详细信息,请参阅为应用服务环境配置 Web 应用程序防火墙 (WAF)For more information, see Configuring a Web Application Firewall (WAF) for App Service Environment.

使用网关服务Use a gateway service

利用网关服务(例如 Azure 应用程序网关),可以设置 Web 应用程序防火墙 (WAF)。Gateway services, such as Azure Application Gateway let you set up a Web Application Firewall (WAF). WAF 规则用于监视或阻止检测到的攻击,从而为函数提供额外的保护层。WAF rules are used to monitor or block detected attacks, which provide an extra layer of protection for your functions. 若要设置 WAF,函数应用需要在 ASE 中运行或使用专用终结点(预览版)。To set up a WAF, your function app needs to be running in an ASE or using Private Endpoints (preview).