保護 PaaS 部署安全

本文提供的資訊可協助您:

  • 了解將應用程式裝載在雲端的安全性優點
  • 評估平台即服務 (PaaS) 與其他雲端服務模型相較之下的安全性優點
  • 將您的安全性焦點從以網路為中心變更成以身分識別為中心的周邊安全性方法
  • 實作一般 PaaS 安全性最佳做法建議

在 Azure 上開發安全應用程式是一般指南,其中說明您開發雲端應用程式時,您在軟體開發生命週期的每個階段所應考量的安全性問題和控制項。

雲端安全性優點

了解您與 Microsoft 之間的責任劃分相當重要。 在內部部署環境中,您擁有整個堆疊,但是當您移到雲端時,部分責任就會轉移給 Microsoft。

在雲端環境中有一些安全性優點。 在內部部署環境中,組織可能責任重大但可投資在安全性上的資源卻相當有限,導致創造出一種攻擊者能夠利用所有層級弱點的環境。

組織能夠藉由使用提供者的雲端型安全性功能和雲端智慧,改進其威脅偵測和回應時間。 藉由將責任轉移給雲端提供者,組織便可擴大安全性涵蓋範圍,而能夠將安全性資源和預算重新配置給其他業務優先順序項目。

PaaS 雲端服務模型的安全性優點

看看 Azure PaaS 部署與內部部署相較之下的安全性優點。

Security advantages of PaaS

Microsoft 是從堆疊底部的實體基礎結構開始來減輕常見的風險和責任。 由於 Microsoft 雲端受到 Microsoft 持續不斷的監視,因此難以對它進行攻擊。 對攻擊者來說,以 Microsoft 雲端做為目標並非明智之舉。 除非攻擊者擁有大量的金錢和資源,否則攻擊者很有可能會物色另一個目標。

在攻擊當中,PaaS 部署與內部部署之間並沒有差異。 在應用程式層和存取管理層,您會有類似的風險。 在本文的後續步驟一節中,我們將指引您進行緩解或大幅降低這些風險的最佳做法。

在堆疊、資料治理和版權管理的頂端,您要承擔一個風險,但可透過金鑰管理來緩解這個風險。 (最佳做法中涵蓋金鑰管理。) 儘管金鑰管理是一項額外的責任,但您在 PaaS 部署中有一些不再需要管理的區域,因此您可以將資源轉移至金鑰管理。

Azure 平台也會使用各種網路型技術,為您提供強式 DDoS 保護。 不過,所有類型的網路型 DDoS 保護方法在每個連結和每個資料中心方面都各有其限制。 若要協助避免大型 DDoS 攻擊所帶來的影響,您可以利用可讓您快速且自動相應放大規模來防禦 DDoS 攻擊的 Azure 核心雲端功能。 我們將在建議的做法文章中,更詳細地深入探討如何這麼做。

將適用於雲端的 Defender 現代化的思維

PaaS 部署會附帶將您的整體方法轉移至安全性。 您將從必須自行控制所有項目轉移至與 Microsoft 分擔責任。

PaaS 與傳統內部部署的另一個重大差異在於一個新觀點,就是定義主要安全性周邊的是什麼。 在過去,主要內部部署安全界限是您的網路,而大多數內部部署安全性設計皆使用網路做為其主要安全性樞紐。 就 PaaS 部署而言,將身分識別視為主要安全界限可為您提供較佳的服務。

採用身分識別原則為主要安全界限

雲端運算的五個基本特性之一是廣泛的網路存取權,這使得以網路為中心的思維不那麼相關。 許多雲端運算的目標是允許使用者存取資源 (不論位置為何)。 對大多數使用者來說,他們的位置會位於網際網路上的某處。

下圖顯示安全界限如何從網路界限演變為身分識別界限。 安全性的重點變的不再是保護您的網路,而更是保護您的資料,以及管理您的應用程式和使用者的安全性。 主要的差異在於您想要讓安全性更貼近於您公司所看重的內容。

Identity as new security perimeter

一開始,Azure PaaS 服務 (例如 Web 角色和 Azure SQL) 提供很少或不提供傳統的網路界限防禦。 在認知上,元素的用途是暴險給網際網路 (Web 角色),而驗證則提供新的界限 (例如 BLOB 或 Azure SQL)。

新式安全性做法假設敵人已入侵網路界限。 因此,新式防禦做法已移至身分識別。 組織必須建立具有增強式驗證和授權防衛 (最佳做法) 的身分識別型安全界限。

網路界限的原則和模式已提供數十年了。 相反地,業界使用身分識別作為主要安全界限的體驗時間則相對較短。 也就是說,我們積累了足夠的經驗,以提供一些一般建議,這些建議在該領域得到證實,並適用于幾乎所有的 PaaS 服務。

以下是管理身分識別界限的最佳做法。

最佳做法:保護金鑰和認證,以保護 PaaS 部署。 詳細資料:遺失金鑰和認證是相當常見的問題。 您可以使用集中式解決方案,可在其中將金鑰和祕密儲存在硬體安全性模組 (HSM) 中。 Azure Key Vault 會使用受 HSM 保護的金鑰來加密驗證金鑰、儲存體帳戶金鑰、資料加密金鑰、.pfx 檔案和密碼,藉以保護金鑰和密碼。

最佳做法:請勿將認證和其他祕密放在原始程式碼或 GitHub 中。 詳細資料:唯一比遺失金鑰和認證更糟的情況就是讓未經授權的一方能夠存取這些機密資料。 攻擊者可以利用 Bot 技術,來尋找在 GitHub 等程式碼存放庫中儲存的金鑰和祕密。 請勿將金鑰和祕密放在這些公用程式碼存放庫中。

最佳做法:使用可讓您直接從遠端管理這些 VM 的管理介面,保護混合式 PaaS 和 IaaS 服務上的 VM 管理介面。 詳細資料:可以使用遠端管理通訊協定,例如 SSHRDPPowerShell 遠端處理。 一般而言,我們建議您不要啟用從網際網路直接對 VM 進行遠端存取的功能。

可能的話,請使用替代方法,例如在 Azure 虛擬網路中使用虛擬私人網路。 如果沒有替代方法可用,則請務必使用複雜密碼和雙因素驗證 (例如 Microsoft Entra 多重要素驗證)。

最佳做法:使用增強式驗證和授權平台。 詳細資料:使用 Microsoft Entra ID 中的同盟身分識別,而不要使用自訂使用者存放區。 當您使用同盟身分識別時,您可以利用以平台為基礎的方法,並將授權身分識別的管理委派給合作夥伴。 當員工遭到解雇且需要透過多個身分識別和授權系統反映該資訊時,同盟身分識別方法就特別重要。

使用平台提供的驗證和授權機制,而不是自訂程式碼。 原因是開發自訂驗證碼可能會容易出錯。 大部分的開發人員都不是安全性專家,而且不太可能掌握驗證和授權的細微差異和最新的發展。 商業程式碼 (例如,來自 Microsoft) 通常會經過廣泛的安全性檢閱。

使用雙重要素驗證。 雙重要素驗證是驗證和授權的最新標準,因為其可避免使用者名稱和密碼驗證類型固有的安全性弱點。 同時存取 Azure 管理 (入口網站/遠端 PowerShell) 介面和客戶面向的服務,應設計且設定為使用 Microsoft Entra 多重要素驗證。

使用標準驗證通訊協定,例如 OAuth2 和 Kerberos。 這些通訊協定已經過廣泛對等檢閱,並可能實作為驗證和授權平台程式庫的一部分。

在應用程式設計期間使用威脅建模

Microsoft 安全性開發週期指定小組應在進行設計階段時,參與稱為威脅模型化的程序。 為了加快此程序,Microsoft 已建立 SDL Threat Modeling Tool。 將應用程式設計模型化,並跨所有信任界限列舉 STRIDE 威脅,可以盡早攔截設計錯誤。

下表列出 STRIDE 威脅,並提供一些使用 Azure 功能的風險降低範例。 這些風險降低在任何情況下都無法運作。

威脅 安全性屬性 潛在的 Azure 平台風險降低
詐騙 驗證 需要 HTTPS 連線。
竄改 完整性 驗證 TLS/SSL 憑證。
否認性 不可否認性 啟用 Azure 監視和診斷。
資訊洩漏 保密 使用服務憑證加密敏感的待用資料。
拒絕服務 可用性 監視效能計量,以了解潛在的阻斷服務狀況。 實作連線篩選。
提高權限 授權 使用 Privileged Identity Management。

在 Azure App Service 上開發

Azure App Service 是 PaaS 供應項目,可讓您為任何平臺或裝置建立 Web 和行動應用程式,並連結到雲端或內部部署中任何位置的資料。 App Service 包含先前分別作為 Azure 網站和 Azure 行動服務傳遞的 Web 和行動功能。 它也包含將商務程序自動化及裝載雲端 API 的新功能。 App Service 是單一整合式服務,為 Web、行動裝置和整合案例帶來了一組豐富的功能。

以下是使用 App Service 的最佳做法。

最佳做法透過 Microsoft Entra ID 進行驗證詳細資料:App Service 可為您的識別提供者提供 OAuth 2.0 服務。 OAuth 2.0 目的是讓用戶端開發人員容易上手,同時為 Web 應用程式、桌面應用程式和行動電話提供特定的授權流程。 Microsoft Entra ID 會使用 OAuth 2.0,讓您授與行動和 Web 應用程式的存取權。

最佳做法:根據需要知道和最低權限安全性準則來限制存取權。 詳細資料:對於想要強制執行資料存取安全性原則的組織來說,限制存取是必須做的事。 您可以使用 Azure RBAC,將權限指派給特定範圍的使用者、群組和應用程式。 若要深入了解授與使用者的應用程式存取權,請參閱開始使用存取管理

最佳做法:保護金鑰。 詳細資料:Azure Key Vault 可協助保護雲端應用程式和服務所使用的密碼編譯金鑰和祕密。 透過 Key Vault,您可以使用受硬體安全性模組 (HSM) 保護的金鑰,來加密金鑰和秘密 (例如驗證金鑰、儲存體帳戶金鑰、資料加密金鑰、.PFX 檔案和密碼)。 為了多加一層保護,您可以在 HSM 中匯入或產生金鑰。 若要深入了解,請參閱 Azure Key Vault。 您也可以使用 Key Vault,透過自動續約來管理 TLS 憑證。

最佳做法:限制連入來源 IP 位址。 詳細資料App Service 環境具有虛擬網路整合功能,可協助您透過網路安全性群組限制連入來源 IP 位址。 虛擬網路可讓您將 Azure 資源放在可控制存取權的非網際網路、可路由的網路中。 若要深入了解,請參閱將您的應用程式與 Azure 虛擬網路整合

最佳做法:監視 App Service 環境的安全性狀態。 詳細資料:使用適用於雲端的 Microsoft Defender 來監視您的 App Service 環境。 當適用於雲端的 Defender 識別潛在的安全性弱點時,其會建立建議,引導您完成設定所需控制項的流程。

Azure 雲端服務

Azure 雲端服務是 PaaS 的其中一例。 如同 Azure App Service,此技術是專為支援可擴縮、可靠且操作成本低的應用程式而設計。 如同 App Service 是裝載於虛擬機器 (VM) 上,Azure 雲端服務也是如此。 不過,您可更充分地掌控 VM。 您可以在使用 Azure 雲端服務的 VM 上安裝自己的軟體,並從遠端加以存取。

安裝 Web 應用程式防火牆

Web 應用程式已逐漸成為惡意探索常見已知弱點的惡意攻擊的目標。 這些惡意探索中常見的是 SQL 插入式攻擊、跨網站指令碼攻擊等等。 在應用程式程式碼中防止這類攻擊可能具有挑戰性,而且可能需要在應用程式拓撲的許多層級進行嚴格的維護、修補和監視。 集中式 Web 應用程式防火牆可協助讓安全性管理更簡單,並為應用程式系統管理員提供更完善的威脅或入侵防禦保證。 對比於保護個別的 Web 應用程式,WAF 解決方案也可透過在中央位置修補已知弱點,更快地回應安全性威脅。

Web 應用程式防火牆 (WAF) 可以集中保護 Web 應用程式,使其免於遭遇常見的攻擊和弱點。

DDoS 保護

Azure DDoS 保護 (結合應用程式設計最佳做法) 可提供增強的 DDoS 風險降低功能,以針對 DDoS 攻擊提供更多的防禦。 您應該在任何周邊虛擬網路上啟用 Azure DDOS 保護

監視應用程式的效能

監視係指收集和分析資料來判斷您應用程式的效能、健康情況和可用性的動作。 有效的監視策略可協助您了解您的應用程式元件的詳細作業。 它可藉由通知重大問題,使您可以在這些問題發生之前便予以解決,協助您增加運作時間。 它也可協助您偵測可能與安全性相關的異常狀況。

使用 Azure Application Insights 來監視應用程式的可用性、效能及使用情況 (不論該應用程式是裝載在雲端還是內部部署環境)。 藉由使用 Application Insights,您可以快速識別和診斷應用程式中的錯誤,而不需要等待使用者回報錯誤。 透過所收集的資訊,您可以針對應用程式的維護和改善做出明智的選擇。

Application Insights 具有各種的工具,可用來與其收集的資料互動。 Application Insights 會將其資料儲存在通用存放庫中。 Application Insights 可以利用共用功能,例如警示、儀表板,以及採用 Kusto 查詢語言的深入分析。

執行安全性滲透測試

驗證安全性防禦與測試任何其他功能一樣重要。 讓 滲透測試 成為您組建和部署程序的標準部分。 在已部署應用程式上排程定期安全性測試和弱點掃描,並監視開啟的埠、端點和攻擊。

模糊測試是尋找程式失敗 (程式碼錯誤) 的方法,這是將格式不正確的輸入資料提供給剖析和取用這些資料的程式介面 (進入點)。

下一步

在此文章中,我們是將焦點放在 Azure PaaS 部署的安全性優點和雲端應用程式的安全性最佳做法。 接下來,請了解使用特定 Azure 服務保護 PaaS Web 和行動解決方案的建議做法。 我們將從 Azure App Service、Azure SQL Database 和 Azure Synapse Analytics、Azure 儲存體和 Azure 雲端服務開始。 當有適用於其他 Azure 服務的建議做法文章推出時,就會在以下清單中提供連結:

請參閱在 Azure 上開發安全應用程式,其中說明您開發雲端應用程式時,您在軟體開發生命週期的每個階段所應考量的安全性問題和控制項。

如需更多安全性最佳做法,請參閱 Azure 安全性最佳做法與模式,以便在使用 Azure 設計、部署和管理雲端解決方案時使用。

下列資源可提供更多有關 Azure 安全性和相關 Microsoft 服務的一般資訊: