保護 Azure Functions
在許多方面，對無伺服器函式進行安全開發、部署和作業的規劃，與任何 Web 架構或雲端裝載的應用程式非常相似。 Azure App Service 提供適用於函式應用程式的裝載基礎結構。 此文章可為您提供執行函式程式碼的安全性策略，以及 App Service 如何協助保護您的函式。
App Service 的平台元件 (包括 Azure VM、儲存體、網路連線、Web 架構、管理和整合功能) 會主動受到保護與強化。 App Service 會持續經歷加強的合規性檢查，以確保：
- 您的應用程式資源受到保護免於遭受其他客戶的 Azure 資源威脅。
- VM 執行個體和執行階段軟體會定期更新，以因應新發現的弱點。
- 您的應用程式與其他 Azure 資源 (例如 SQL Database) 之間的祕密通訊 (例如連接字串) 仍在 Azure 內，不會跨越任何網路界限。 祕密會在儲存時一律加密。
- 透過 App Service 連線功能 (例如混合式連線) 的所有通訊都會加密。
- 透過 Azure PowerShell、Azure CLI、Azure SDK、REST API 等遠端管理工具進行的連線全都會加密。
- 全天候威脅管理會保護基礎結構和平台，免於遭受惡意程式碼、分散式拒絕服務 (DDoS)、攔截式 (MITM) 和其他威脅。
如需在 Azure 中的基礎結構與平台安全性的詳細資訊，請參閱 Azure 信任中心。
如需遵循 Microsoft 雲端安全性基準測試的一組安全性建議，請參閱適用於 Azure Functions 的 Azure 安全性基準。
安全作業
此節將引導您以盡可能安全的方式來設定和執行函式應用程式。
Defender for Cloud
適用於雲端的 Defender 會在入口網站中與您的函數應用程式整合。 其免費提供可能與設定相關之安全性弱點的快速評量。 在專用方案中執行的函數應用程式也可以使用適用於雲端的 Defender 增強型安全性功能，但需支付額外費用。 若要深入了解，請參閱保護您的 Azure App Service Web 應用程式和 API。
記錄和監視
偵測攻擊的方法之一是透過活動監視和記錄分析。 Functions 會與 Application Insights 整合，以收集函數應用程式的記錄、效能和錯誤資料。 Application Insights 會自動偵測效能異常，並隨附強大的分析工具，以協助您診斷問題及了解如何使用您的函式。 若要深入了解，請參閱監視 Azure Functions。
Functions 也會與 Azure 監視器記錄整合，讓您能夠將函式應用程式記錄與系統事件合併，以便分析。 您可以使用診斷設定，將函式平台記錄和計量的資料流匯出設定到您選擇的目的地，例如 Logs Analytics 工作區。 若要深入了解，請參閱使用 Azure 監視器記錄監視 Azure Functions。
針對企業層級的威脅偵測和回應自動化，將您的記錄和事件串流處理到 Logs Analytics 工作區。 接著，您可以將 Microsoft Sentinel 連線到此工作區。 若要深入了解，請參閱什麼是 Microsoft Sentinel。
如需更多對於可檢視性的安全性建議，請參閱適用於 Azure Functions 的 Azure 安全性基準。
需要 HTTPS
根據預設，用戶端可以使用 HTTP 或 HTTPS 連線到函式端點。 您應該將 HTTP 重新導向至 HTTPS，因為 HTTPS 會使用 SSL/TLS 通訊協定來提供安全連線，這兩者都已加密且通過驗證。 若要了解做法，請參閱強制使用 HTTPS。
當您需要 HTTPS 時，應該也需要最新的 TLS 版本。 若要了解做法，請參閱強制使用 TLS 版本。
如需詳細資訊，請參閱保護連線 (TLS)。
函式存取金鑰
Functions 可讓您使用金鑰來提高開發期間存取 HTTP 函式端點的困難度。 除非 HTTP 觸發程序函數的 HTTP 存取層級設定為 anonymous，否則要求必須在要求中包含 API 存取金鑰。
雖然金鑰提供預設安全性機制，但您可能想要考慮其他選項來保護生產環境中的 HTTP 端點。 例如，在公用應用程式中散發共用秘密並不是很好的做法。 如果您的函式是從公用用戶端呼叫，您可能想要考慮實作另一個安全性機制。 若要深入了解，請參閱在生產環境中保護 HTTP 端點。
當更新函式索引鍵值時，您必須手動將更新的索引鍵值重新散發給所有呼叫您函式的用戶端。
授權範圍 (函式層級)
函式層級金鑰有兩個存取範圍：
函式：這些金鑰僅適用於據以定義它們的特定函式。 當做為 API 金鑰使用時，這些金鑰僅允許存取該函式。
主機：具有主機範圍的金鑰可用來存取函數應用程式內的所有函式。 當做為 API 金鑰使用時，這些金鑰會允許存取函數應用程式中的任何函式。
每個金鑰均為具名以供參考，並且在函式和主機層級有一預設金鑰 (名稱為 "default")。 函式金鑰的優先順序高於主機金鑰。 當您使用相同的名稱來定義兩個金鑰時，一律會使用函式金鑰。
主要金鑰 (管理員層級)
每個函數應用程式也有一個名為 _master 的管理員層級主機金鑰。 除了為應用程式中的所有函式提供主機層級存取之外，主要金鑰也會提供執行階段 REST API 的系統管理存取權。 無法撤銷此金鑰。 當您將存取層級設定為 admin 時，要求就必須使用主要金鑰；任何其他金鑰則會導致存取失敗。
警告
由於主要金鑰會在您的函數應用程式中授與提高的權限，因此您不應該與第三方共用此金鑰，或是在原生用戶端應用程式中散發它。 當您選擇管理存取層級時，請務必謹慎。
系統金鑰
特定的延伸模組可能需要系統管理的金鑰，才能存取 Webhook 端點。 系統金鑰是專為由內部元件呼叫的擴充功能特定函式端點所設計。 例如，事件方格觸發程序要求訂用帳戶在呼叫觸發程序端點時使用系統金鑰。 Durable Functions 也會使用系統金鑰來呼叫長期工作延伸模組 API。
系統金鑰的範圍會由此延伸模組決定，但通常適用於整個函式應用程式。 系統金鑰只能由特定的延伸模組建立，而且您無法明確設定其值。 如同其他金鑰，您可以從入口網站或使用金鑰 API 來產生新的金鑰值。
金鑰比較
下表將比較各種存取金鑰的用途：
| 動作 | 範圍 | 有效按鍵 |
|---|---|---|
| 執行函式 | 特定函式 | 函式 |
| 執行函式 | 任何函式 | 函式或主機 |
| 呼叫管理員端點 | 函式應用程式 | 主機 (僅限主機) |
| 呼叫長期工作延伸模組 API | 函式應用程式1 | 系統2 |
| 呼叫延伸模組特定的 Webhook (內部) | 函式應用程式1 | 系統2 |
1由延伸模組決定的範圍。
2由延伸模組設定的特定名稱。
若要深入了解存取金鑰，請參閱 HTTP 觸發程序繫結文章。
秘密存放庫
依預設，金鑰會儲存在帳戶的 Blob 儲存體容器中，而此帳戶是由 AzureWebJobsStorage 設定所提供的。 您可以使用 AzureWebJobsSecretStorageType 設定來覆寫此行為，並將金鑰儲存在不同的位置。
| Location | 值 | 描述 |
|---|---|---|
| 第二個儲存體帳戶 | blob |
根據 AzureWebJobsSecretStorageSas 中的 SAS URL，金鑰會儲存在不同的儲存體帳戶的 Blob 儲存體中。 |
| 檔案系統 | files |
金鑰會保存在檔案系統上，這是 Functions v1.x 中的預設值。 |
| Azure 金鑰保存庫 | keyvault |
AzureWebJobsSecretStorageKeyVaultUri 中設定的金鑰保存庫可用來儲存金鑰。 |
| Kubernetes 秘密 | kubernetes |
AzureWebJobsKusbnetesSecretName 中的資源集可用來儲存金鑰。 只有在 Kubernetes 中執行 Functions 執行階段時才支援。 Azure Functions Core Tools 會在部署至 Kubernetes 時自動產生這些值。 |
針對金鑰儲存體使用 Key Vault 時，您需要的應用程式設定取決於受控識別類型。 Functions 執行階段版本 3.x 僅支援系統指派的受控識別。
| 設定名稱 | 系統指派 | 使用者指派 | 應用程式註冊 |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
驗證/授權
雖然函式金鑰可以針對不必要的存取提供一些緩和措施，但真正保護函式端點的唯一方式，就是對存取您函式的用戶端實作正面驗證。 接著，您可以根據身分識別進行授權決策。
啟用 App Service 驗證/授權
App Service 平台可讓您使用 Microsoft Entra ID 及數個協力廠商身分識別提供者來驗證用戶端。 您可以使用此策略為函式實作自訂授權規則，並可使用來自函式程式碼的使用者資訊。 若要深入了解，請參閱 Azure App Service 中的驗證與授權和使用用戶端身分識別。
使用「Azure API 管理」(APIM) 來驗證要求
APIM 為傳入要求提供多種 API 安全性選項。 若要深入了解，請參閱 API 管理驗證原則。 備妥 APIM 之後，您可以設定讓函數應用程式只接受來自您 APIM 執行個體 IP 位址的要求。 若要深入了解，請參閱 IP 位址限制。
權限
如同任何應用程式或服務，目標是以最低的可能權限來執行您的函式應用程式。
使用者管理權限
Functions 支援內建的 Azure 角色型存取控制 (Azure RBAC)。 Functions 所支援的 Azure 角色是參與者、擁有者和讀者。
權限會在函式應用層級生效。 您必須具備參與者角色，才能執行大部分函式應用程式層級的工作。 您也需要參與者角色和監視讀取者權限，才能在 Application Insights 中檢視記錄資料。 只有擁有者角色可以刪除函式應用程式。
依權限組織函式
儲存在應用程式設定中的連接字串和其他認證，會為函式應用程式中的所有函式提供與相關聯資源中相同的權限集。 請考慮藉由將未使用那些認證的函式移至個別函式應用程式，來將可存取特定認證的函式數目降至最低。 您一律可以使用函式鏈結之類的技術，在不同函式應用程式的函式之間傳遞資料。
受控識別
Microsoft Entra ID 的受控身分識別，可讓應用程式輕鬆存取其他受到 Microsoft Entra 保護的資源 (例如 Azure Key Vault)。 身分識別由 Azure 平台負責管理，因此您不需要佈建或輪替任何密碼。 如需有關 Microsoft Entra ID 中受控識別的詳細資訊，請參閱適用於 Azure 資源的受控識別。
您的應用程式可以授與兩種類型的身分識別：
- 系統指派的身分識別會繫結至您的應用程式，如果您的應用程式已刪除，則會被刪除。 應用程式只能有一個系統指派的身分識別。
- 使用者指派的身分識別是一項獨立 Azure 資源，可指派給您的應用程式。 應用程式可以有多個使用者指派的身分識別。
受控識別可以用來取代來自某些觸發程序和繫結的連線秘密。 請參閱身分識別型連線。
如需詳細資訊，請參閱如何使用 App Service 和 Azure Functions 的受控身分識別。
限制 CORS 存取
跨原始來源資源共用 (CORS) \(英文\) 是一種方式，讓在另一個網域中執行的 Web 應用程式能夠對您的 HTTP 觸發程序端點提出要求。 App Service 提供內建支援，可在 HTTP 要求中處理所需的 CORS 標題。 CORS 規則定義於函式應用程式層級上。
雖然會想使用萬用字元來允許所有網站存取您的端點，但這會破壞 CORS 的目的，也就是協助防止跨網站指令碼攻擊。 請改為針對必須存取您端點之每個 Web 應用程式的網域，新增個別的 CORS 項目。
管理密碼
若要能夠連線到各種服務且資源必須執行您的程式碼，函式應用程式就必須能夠存取祕密 (例如連接字串和服務金鑰)。 此節說明如何儲存函式所需的祕密。
絕對不要將祕密儲存於函式程式碼中。
應用程式設定
根據預設，您會將函式應用程式和繫結所使用的連接字串及祕密儲存為應用程式設定。 這讓您的函式程式碼及該函式所使用的各種繫結能夠使用這些認證。 應用程式設定 (金鑰) 名稱可用來擷取實際值，也就是祕密。
例如，每個函式應用程式都需要一個相關聯且由執行階段使用的儲存體帳戶。 根據預設，此儲存體帳戶的連線會儲存在名為 AzureWebJobsStorage 的應用程式設定中。
應用程式設定和連接字串會以加密方式儲存在 Azure 中。 只有在應用程式啟動時，才會將其解密，然後插入至應用程式的處理序記憶體。 加密金鑰會定期輪替。 如果您想要改為管理祕密的安全儲存體，應用程式設定就應該改為參考 Azure Key Vault。
在本機電腦上開發函式時，您也可以預設在 local.settings.json 檔案中加密設定。 如需詳細資訊，請參閱加密本機設定檔。
Key Vault 參考
儘管對大部分函式而言應用程式設定就已足夠，但您可能想要在多個服務之間共用相同的祕密。 在此情況下，重複儲存祕密會導致更多潛在的弱點。 一種更安全的方法是使用集中式祕密儲存服務，並使用對此服務的參考，而不是祕密本身。
Azure Key Vault 是提供集中式祕密管理的服務，可完整控制存取原則和稽核歷程記錄。 您可以在應用程式設定中，使用 Key Vault 參考來取代連接字串或金鑰。 若要深入了解，請參閱使用 App Service 和 Azure Functions 的 Key Vault 參考。
身分識別型連線
身分識別可以用來取代秘密，以連線到某些資源。 這具有不需要管理秘密的優點，並提供更精細的存取控制和稽核。
當撰寫程式碼，為支援 Microsoft Entra 驗證的 Azure 服務建立連線時，您可以選擇使用身分識別，而不是秘密或連接字串。 每個服務的文件涵蓋了這兩種連線方法的詳細資料。
某些 Azure Functions 觸發程序和繫結延伸模組可能使用身分識別型連線進行設定。 目前，這包括 Azure Blob 和 Azure 佇列延伸模組。 如需如何設定這些延伸模組來使用身分識別的相關資訊，請參閱如何在 Azure Functions 中使用身分識別型連線。
設定使用量配額
請考慮在取用量方案中執行之函式上設定使用量配額。 當您在函式應用程式中為函式的總執行次數設定每日 GB-s 限制時，一旦達到該限制，就會停止執行。 這可能有助於緩和惡意程式碼執行您函式的情況。 若要了解如何估計函式的取用量，請參閱估計取用量方案成本。
資料驗證
函式所使用的觸發程序和繫結不會提供任何額外的資料驗證。 您的程式碼必須驗證接收自觸發程序或輸入繫結的所有資料。 如果上游服務遭到入侵，您不希望未經驗證的輸入流經您的函式。 例如，如果您的函式將來自 Azure 儲存體佇列的資料儲存於關聯式資料庫中，您就必須驗證該資料並將命令參數化，以避免受到 SQL 插入式攻擊。
請勿假設傳入您函式的資料已經過驗證或處理。 確認寫入至輸出繫結的資料有效，也是個不錯的主意。
處理錯誤
儘管這看似基本，但在您的函式中撰寫良好的錯誤處理很重要。 未處理的錯誤會往上累積到主機，並由執行階段處理。 不同的繫結會以不同方式進行錯誤的處理。 若要深入了解，請參閱 Azure Functions 錯誤處理。
停用遠端偵錯
除非您正主動對函式進行偵錯，否則，需確定已停用遠端偵錯。 您可以在入口網站內函式應用程式 [設定] 的 [一般設定] 索引標籤中停用遠端偵錯。
限制 CORS 存取
Azure Functions 支援跨原始資源共用 (CORS)。 您可在入口網站中，以及透過 Azure CLI 來設定 CORS。 CORS 允許的原始來源清單適用於函數應用程式層級。 在啟用 CORS 的情況下，回應會包含 Access-Control-Allow-Origin 標頭。 如需詳細資訊，請參閱跨原始資源共用。
請勿在允許的來源清單中使用萬用字元， 而是改為列出您希望從中取得要求的特定網域。
儲存加密的資料
Azure 儲存體會加密待用儲存體帳戶中的所有資料。 如需詳細資訊，請參閱待用資料的 Azure 儲存體加密。
根據預設，資料是以使用 Microsoft 管理的金鑰加密。 若要進一步控制加密金鑰，您可以提供客戶管理的金鑰，以用於加密 blob 和檔案資料。 這些金鑰必須存在於 Azure Key Vault 中，Functions 才能存取儲存體帳戶。 若要深入了解，請參閱使用客戶管理的金鑰待用加密。
保護相關資源
函數應用程式經常相依於其他資源，因此在保護應用程式的過程中也會保護這些外部資源。 大部分函數應用程式至少包含對 Application Insights 和 Azure 儲存體的相依性。 如需保護這些資源的指引，請參閱適用於 Azure 監視器的 Azure 安全性基準和適用於儲存體的 Azure 安全性基準。
重要
儲存體帳戶可用來儲存重要的應用程式資料，有時還包含應用程式的程式碼本身。 您應該限制其他應用程式和使用者存取儲存體帳戶。
您還應該針對應用程式邏輯相依的任何資源類型，參閱相關指引，無論是觸發程序和繫結，還是函式程式碼。
安全部署
Azure Functions 工具整合，可讓您輕鬆地將區域函式專案程式碼發佈至 Azure。 在考慮 Azure Functions 拓撲的安全性時，請務必了解部署的運作方式。
部署認證
App Service 部署需要一組部署認證。 這些部署認證可用來保護您的函式應用程式部署。 部署認證會由 App Service 平台管理，並在待用時加密。
有兩種部署認證：
使用者層級認證︰一組用於整個 Azure 帳戶的認證。 它可以用來將任何應用程式部署至 Azure 帳戶有權存取的任何訂用帳戶的 App Service 中。 其為呈現在入口網站 GUI 中的預設集合 (例如應用程式資源頁面的 [概觀] 和 [屬性])。 透過角色型存取控制 (RBAC) 或共同管理員權限來為使用者授與應用程式存取權時，該使用者可以使用他們自己的使用者層級認證，直到存取權遭到撤銷為止。 請勿與其他 Azure 使用者共用這些認證。
應用程式層級認證︰一組用於單個 應用程式的認證。 它只可以用來部署該應用程式。 每個應用程式的認證都會在建立應用程式時自動產生。 您無法手動設定它們，但可隨時重設。 若是要透過 (RBAC) 授與應用程式層級認證存取權的使用者，該使用者就必須是應用程式上的參與者或更高權限 (包括網站參與者內建角色)。 讀者不允許發佈且無法存取那些認證。
目前，部署認證不支援 Key Vault。 若要深入了解管理部署認證，請參閱設定 Azure App Service 的部署認證。
停用 FTP
根據預設，每個函式應用程式均已啟用 FTP 端點。 您可以使用部署認證來存取 FTP 端點。
不建議使用 FTP 來部署函式程式碼。 FTP 部署是手動的，而且需要您同步處理觸發程序。 若要深入了解，請參閱 FTP 部署。
當您不打算使用 FTP 時，應該在入口網站中加以停用。 如果您選擇使用 FTP，則應該強制使用 FTPS。
保護 SCM 端點
每個函式應用程式都有一個由進階工具 (Kudu) 服務所使用的對應 scm 服務端點，可供部署和其他 App Service 網站延伸模組 \(英文\) 使用。 函式應用程式的 SCM 端點一律是格式為 https://<FUNCTION_APP_NAME.scm.azurewebsites.net> 的 URL。 當您使用網路隔離來保護函式時，也必須考慮此端點。
藉由擁有個別的 SCM 端點，您可以控制在虛擬網路中隔離或執行之函式應用程式的部署和其他進階工具功能。 SCM 端點支援基本驗證 (使用部署認證)，以及透過您 Azure 入口網站認證進行的單一登入。 若要深入了解，請參閱存取 Kudu 服務 \(英文\)。
持續安全性驗證
由於在開發程序中的每個步驟都必須考慮安全性，因此，也可以在持續部署環境中實作安全性驗證。 這有時稱為 DevSecOps。 針對您的部署管線使用 Azure DevOps，可讓您在部署程序中整合驗證。 如需詳細資訊，請參閱了解如何將持續安全性驗證新增至您的 CI/CD 管線。
網路安全性
限制對函式應用程式的網路存取，可讓您控制可存取函式端點的人員。 Functions 會利用 App Service 基礎結構，讓您的函式可以在不使用可透過網際網路路由傳送之位址的情況下存取資源，或限制對函式端點的網際網路存取。 若要深入了解這些網路功能選項，請參閱 Azure Functions 網路功能選項。
設定存取限制
存取限制可讓您定義允許/拒絕規則的清單，以控制對應用程式的流量。 規則會依照優先順序進行評估。 如果未定義任何規則，則您的應用程式將接受來自任意位址的流量。 若要深入了解，請參閱 Azure App Service 存取限制。
保護儲存體帳戶
建立函式應用程式時，您必須建立或連結至支援 Blob、佇列及資料表儲存體的一般用途 Azure 儲存體帳戶。 您可以將此儲存體帳戶取代為受到服務端點或私人端點保護的儲存體帳戶。 如需詳細資訊，請參閱將儲存體帳戶限定於虛擬網路。
私人站台存取
Azure 私人端點是一種網路介面，可讓您私密安全地連線到 Azure Private Link 所提供的服務。 私人端點會使用您虛擬網路中的私人 IP 位址，有效地將服務帶入您的虛擬網路。
您可以將私人端點用於進階和 App Service 方案中裝載的函式。
如果您想要對私人端點進行呼叫，必須確定您的 DNS 查閱會解析為私人端點。 您可以透過下列其中一種方法強制執行此行為：
- 與 Azure DNS 私人區域整合。 當您的虛擬網路沒有自訂 DNS 伺服器時，這會自動完成。
- 管理應用程式所使用 DNS 伺服器中的私人端點。 若要進行管理，您必須知道私人端點位址，然後使用 A 記錄，將您嘗試連線的端點指向該位址。
- 將您自己的 DNS 伺服器設定為轉送至 Azure DNS 私人區域。
若要深入了解，請參閱將私人端點用於 Web 應用程式。
以隔離方式部署函式應用程式
Azure App Service 環境 (ASE) 提供一個可供執行您函式的專用主控環境。 ASE 可讓您設定一個單一前端閘道，可用來驗證所有傳入要求。 如需詳細資訊，請參閱設定 App Service Environment 的 Web 應用程式防火牆 (WAF)。
使用閘道服務
閘道服務 (例如 Azure 應用程式閘道和 Azure Front Door) 可讓您設定 Web 應用程式防火牆 (WAF)。 WAF 規則可用來監視或封鎖偵測到的攻擊，為您的函式提供額外保護層。 若要設定 WAF，您的函式應用程式必須在 ASE 中或使用私人端點 (預覽) 來執行。 若要深入了解，請參閱使用私人端點。