在 Azure 上設計安全的應用程式

  • 發行項

在本文中，我們會呈現設計雲端應用程式時應考慮的安全性活動和控制項。 涵蓋在 Microsoft 安全性開發生命週期 （SDL） 的需求和設計階段期間，要考慮的安全性問題和概念訓練資源。 目標是協助您定義可用來設計更安全的應用程式的活動和 Azure 服務。

本文涵蓋下列 SDL 階段：

  • 訓練
  • 需求
  • 設計

訓練

開始開發雲端應用程式之前，請花時間瞭解 Azure 上的安全性和隱私權。 藉由採取此步驟，您可以減少應用程式中可惡意探索弱點的數目和嚴重性。 您將更準備適當地回應不斷變化的威脅環境。

在訓練階段使用下列資源，讓自己熟悉可供開發人員使用的 Azure 服務，以及 Azure 上的安全性最佳做法：

  • Azure 開發人員指南說明如何開始使用 Azure。 本指南說明您可以使用哪些服務來執行應用程式、儲存資料、納入智慧、建置 IoT 應用程式，以及以更有效率且更安全的方式部署您的解決方案。

  • Azure 開發人員 入門指南提供基本資訊給想要開始使用 Azure 平臺的開發人員，以符合其開發需求。

  • SDK 和工具 說明 Azure 上可用的工具。

  • Azure DevOps Services 提供開發共同作業工具。 這些工具組括高效能管線、免費的 Git 存放庫、可設定的工作流程看板，以及廣泛的自動化和雲端式負載測試。 DevOps 資源中心 結合了我們的資源來學習 DevOps 實務、Git 版本控制、敏捷式方法、我們在 Microsoft 與 DevOps 搭配運作的方式，以及如何評估自己的 DevOps 進展。

  • 推送至生產 環境之前要考慮的前五個安全性專案會示範如何協助保護 Azure 上的 Web 應用程式，並保護您的應用程式免于最常見的和危險的 Web 應用程式攻擊。

  • Secure DevOps Kit for Azure 是腳本、工具、延伸模組和自動化的集合，可符合使用大量自動化之 DevOps 小組的完整 Azure 訂用帳戶和資源安全性需求。 適用于 Azure 的安全 DevOps Kit 可以示範如何將安全性順暢地整合到原生 DevOps 工作流程中。 套件可解決安全性驗證測試 （SVT） 之類的工具，可協助開發人員撰寫安全程式碼，並在編碼和早期開發階段測試其雲端應用程式的安全設定。

  • Azure 安全性最佳做法和模式 - 使用 Azure 設計、部署及管理雲端解決方案時要使用的安全性最佳做法集合。 指引是 IT 專業人員的資源。 這可能包括建置和部署安全 Azure 解決方案的設計工具、架構設計人員、開發人員和測試人員。

需求

需求定義階段是定義應用程式及其發行時所執行作業的重要步驟。 需求階段也是思考您建置至應用程式的安全性控制的時間。 在此階段中，您也會開始在整個 SDL 中採取的步驟，以確保您發行並部署安全的應用程式。

考慮安全性和隱私權問題

此階段是考慮基本安全性和隱私權問題的最佳時機。 在專案開始時定義可接受的安全性和隱私權層級可協助小組：

  • 瞭解與安全性問題相關聯的風險。
  • 識別並修正開發期間的安全性錯誤。
  • 在整個專案中套用已建立的安全性和隱私權層級。

當您撰寫應用程式的需求時，請務必考慮可協助保護應用程式和資料的安全控制。

詢問安全性問題

詢問安全性問題，例如：

  • 我的應用程式是否包含敏感性資料？

  • 我的應用程式會收集或儲存要求我遵守聯邦金融機構考試委員會（FFIEC） 或 支付卡產業資料安全性標準（PCI DSS） 等 業界標準和合規性計畫的資料嗎？

  • 我的應用程式是否會收集或包含機密個人或客戶資料，這些資料可以單獨使用或其他資訊來識別、連絡或尋找單一人員？

  • 我的應用程式會收集或包含可用來存取個人醫療、教育、財務或就業資訊的資料嗎？ 在需求階段識別資料的敏感度，可協助您分類資料，並識別您用於應用程式的資料保護方法。

  • 我的資料儲存在何處及如何？ 請考慮如何監視應用程式用於任何非預期變更的儲存體服務（例如較慢的回應時間）。 您是否能夠影響記錄以收集更詳細的資料並深入分析問題？

  • 我的應用程式是否可供公用或僅限內部使用？ 如果您的應用程式可供公用使用，您該如何保護可能收集的資料無法以錯誤的方式使用？ 如果您的應用程式只能在內部使用，請考慮組織中的誰應該可以存取應用程式，以及他們應該具有存取權的時間長度。

  • 在開始設計應用程式之前，您瞭解您的身分識別模型嗎？ 您可以判斷使用者是誰，他們說他們是誰，以及使用者有權做什麼？

  • 我的應用程式是否執行敏感或重要的工作（例如轉移資金、解除鎖定門或送藥）？ 請考慮如何驗證執行敏感性工作的使用者是否已獲授權來執行工作，以及如何驗證人員是他們所說的人員。 授權 （AuthZ） 是授與已驗證的安全性主體許可權來執行某些動作的行為。 驗證 （AuthN） 是針對合法認證挑戰一方的行為。

  • 我的應用程式是否執行任何有風險的軟體活動，例如允許使用者上傳或下載檔案或其他資料？ 如果您的應用程式確實執行有風險的活動，請考慮您的應用程式如何保護使用者處理惡意檔案或資料。

檢閱 OWASP 前 10 名

請考慮檢 閱 OWASP 前 10 名應用程式安全性風險 。 OWASP 前 10 名解決了 Web 應用程式的重要安全性風險。 瞭解這些安全性風險可協助您做出需求和設計決策，以將應用程式中的風險降到最低。

考慮安全性控制以防止外泄很重要。 不過，您也想要 假設會發生缺口 。 假設缺口有助於事先回答一些有關安全性的重要問題，因此不需要在緊急情況下回答：

  • 我要如何偵測攻擊？
  • 如果有攻擊或缺口，我要怎麼做？
  • 我要如何從資料外泄或竄改等攻擊中復原？

設計

設計階段對於建立設計和功能規格的最佳做法至關重要。 執行風險分析也很重要，有助於降低整個專案的安全性和隱私權問題。

當您有安全性需求並使用安全設計概念時，可以避免或最小化安全性缺陷的機會。 安全性缺陷是應用程式設計中的監督，可讓使用者在應用程式發行後執行惡意或非預期的動作。

在設計階段，也請考慮如何在層中套用安全性;一個層級的防禦不一定足夠。 如果攻擊者超過 Web 應用程式防火牆（WAF），會發生什麼事？ 您希望另一個安全控制到位，以防範該攻擊。

考慮到這一點，我們會討論下列安全設計概念，以及設計安全應用程式時應處理的安全性控制：

  • 使用安全的編碼程式庫和軟體架構。
  • 掃描易受攻擊的元件。
  • 在應用程式設計期間使用威脅模型化。
  • 減少您的受攻擊面。
  • 採用身分識別原則作為主要安全性周邊。
  • 需要重新驗證重要交易。
  • 使用金鑰管理解決方案來保護金鑰、認證和其他秘密。
  • 保護敏感性資料。
  • 實作安全措施。
  • 利用錯誤和例外狀況處理。
  • 使用記錄和警示。

使用安全編碼程式庫和軟體架構

若要進行開發，請使用具有內嵌安全性的安全編碼程式庫和軟體架構。 開發人員可以使用現有的、經過證實的功能（加密、輸入衛生、輸出編碼、金鑰或連接字串，以及被視為安全性控制項的任何其他專案），而不是從頭開始開發安全性控制。 這有助於防範安全性相關設計和實作缺陷。

請確定您使用的是最新版的架構，以及架構中可用的所有安全性功能。 Microsoft 為所有開發人員提供一組完整的 開發工具 ，可處理任何平臺或語言，以提供雲端應用程式。 您可以從各種 SDK 中選擇，以您選擇的語言撰寫程式碼。 您可以利用功能完整的整合式開發環境（IDE）和具有進階偵錯功能和內建Azure 支援的編輯器。

Microsoft 提供各種 語言、架構和工具 ，可用來在 Azure 上開發應用程式。 例如 適用于 .NET 和 .NET Core 開發人員 的 Azure。 針對我們提供的每個語言和架構，您可以找到快速入門、教學課程和 API 參考，以協助您快速開始使用。

Azure 提供各種服務，可用來裝載網站和 Web 應用程式。 這些服務可讓您以慣用的語言進行開發，無論是 .NET、.NET Core、JAVA、Ruby、Node.js、PHP 或 Python。 Azure App 服務 Web Apps （Web Apps ） 是其中一項服務。

Web Apps 會將 Microsoft Azure 的強大功能新增至您的應用程式。 其中包含安全性、負載平衡、自動調整和自動化管理。 您也可以利用 Web Apps 中的 DevOps 功能，例如套件管理、預備環境、自訂網域、SSL/TLS 憑證，以及 Azure DevOps、GitHub、Docker Hub 和其他來源的持續部署。

Azure 提供可用來裝載網站和 Web 應用程式的其他服務。 在大部分情況下，Web Apps 是最佳選擇。 針對微服務架構，請考慮 使用 Azure Service Fabric 。 如果您需要進一步控制程式代碼執行的 VM，請考慮 Azure 虛擬機器 。 如需如何在這些 Azure 服務之間選擇的詳細資訊，請參閱 比較Azure App 服務、虛擬機器、Service Fabric 和雲端服務 。

將更新套用至元件

若要防止弱點，您應該持續清查用戶端和伺服器端元件（例如架構和程式庫）及其更新的相依性。 新的弱點和更新的軟體版本會持續發行。 請確定您有持續計畫來監視、分級，以及將更新或設定變更套用至您使用的程式庫和元件。

如需工具建議，請參閱使用具有已知弱點 的元件上的 Open Web Application Security Project （OWASP） 頁面。 您也可以訂閱電子郵件警示，以取得與您使用之元件相關的安全性弱點。

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

威脅模型化是識別企業和應用程式潛在安全性威脅的程式，然後確保適當的風險降低已就緒。 SDL 指定當解決潛在問題相對容易且符合成本效益時，小組應該在設計階段進行威脅模型化。 在設計階段使用威脅模型化可大幅降低開發總成本。

為了協助協助威脅模型化程式，我們設計 了 SDL 威脅模型化工具 ，並考慮了非安全性專家。 此工具提供有關如何建立和分析威脅模型的明確指引，讓所有開發人員都能更輕鬆地建立威脅模型。

將應用程式設計模型化並列舉 STRIDE 威脅詐騙、竄改、否認性、資訊洩漏、拒絕服務，以及跨所有信任界限提升許可權的有效方法，已證明早期攔截設計錯誤的有效方法。 下表列出 STRIDE 威脅，並提供一些使用 Azure 所提供功能的範例風險降低措施。 這些風險降低在各種情況下都無法運作。

威脅 安全性屬性 潛在的 Azure 平臺風險降低
詐騙 驗證 需要 HTTPS 連線 。
竄改 完整性 驗證 SSL/TLS 憑證。 使用 SSL/TLS 的應用程式必須完整驗證其所連線實體的 X.509 憑證。 使用 Azure 金鑰保存庫憑證來管理 您的 x509 憑證 。
否認性 不可否認性 啟用 Azure 監視和診斷 。
資訊洩露 機密性 加密待用 和 傳輸 中的敏感性資料 。
阻斷服務 可用性 監視效能計量，以取得潛在的阻斷服務狀況。 實作連接篩選。 Azure DDoS 保護 結合應用程式設計最佳做法，可提供防禦 DDoS 攻擊。
權限提高 授權 使用 Microsoft Entra ID Privileged Identity Management 。

減少您的受攻擊面

受攻擊面是可能發生潛在弱點的總和。 在本文中，我們將焦點放在應用程式的受攻擊面上。 重點是保護應用程式免受攻擊。 若要將受攻擊面降到最低，一個簡單且快速的方式，就是從您的應用程式中移除未使用的資源和程式碼。 應用程式越小，受攻擊面越小。 例如，移除：

  • 您尚未發行的功能程式碼。
  • 偵錯支援程式碼。
  • 未使用或已被取代的網路介面和通訊協定。
  • 您未使用的虛擬機器和其他資源。

定期清除您的資源，並確保移除未使用的程式碼是確保惡意執行者攻擊的機會較少的絕佳方式。

更詳細且更深入的方式來減少受攻擊面，就是完成受攻擊面分析。 受攻擊面分析可協助您對應需要檢閱及測試安全性弱點的系統元件。

受攻擊面分析的目的是要瞭解應用程式中的風險區域，讓開發人員和安全性專家知道應用程式有哪些部分可供攻擊。 然後，您可以找到將這種潛力降到最低的方法、追蹤攻擊面變更的時機和方式，以及從風險的觀點來看的意義。

受攻擊面分析可協助您識別：

  • 您需要檢閱及測試安全性弱點的系統函式和部分。
  • 需要深度防禦保護的程式碼高風險區域（您需要防禦的系統部分）。
  • 當您改變受攻擊面並需要重新整理威脅評估時。

減少攻擊者利用潛在弱點或弱點的機會，需要您徹底分析應用程式的整體攻擊面。 它也包括停用或限制系統服務的存取、套用最低許可權原則，以及盡可能採用分層防禦。

我們會討論 在 SDL 驗證階段期間進行攻擊面檢閱 。

注意

威脅模型化和攻擊面分析有何差異？ 威脅模型化是識別應用程式潛在安全性威脅的程式，並確保有適當的威脅防護措施已就緒。 受攻擊面分析會識別要攻擊的程式碼高風險區域。 它牽涉到在部署應用程式之前，先尋找如何防禦應用程式的高風險區域，以及檢閱和測試這些程式碼區域。

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

設計雲端應用程式時，請務必將安全性周邊焦點從以網路為中心的方法擴充為以身分識別為中心的方法。 在過去，主要內部部署安全性周邊是組織的網路。 大部分的內部部署安全性設計都會使用網路作為主要安全性樞紐。 針對雲端應用程式，您最好將身分識別視為主要安全性周邊。

您可以執行下列動作來開發以身分識別為中心的方法來開發 Web 應用程式：

  • 為使用者強制執行多重要素驗證。
  • 使用增強式驗證和授權平臺。
  • 套用最低許可權原則。
  • 實作即時存取。

為使用者強制執行多重要素驗證

使用雙因素驗證。 雙因素驗證是驗證和授權的目前標準，因為它可避免使用者名稱和密碼驗證類型固有的安全性弱點。 存取 Azure 管理介面（Azure 入口網站/遠端 PowerShell）和麵向客戶的服務，應該設計及設定為使用 Microsoft Entra 多重要素驗證 。

使用增強式驗證和授權平臺

使用平臺提供的驗證和授權機制，而不是自訂程式碼。 這是因為開發自訂驗證程式代碼很容易發生錯誤。 商業程式碼（例如，來自 Microsoft）通常會廣泛檢閱安全性。 Microsoft Entra ID （Microsoft Entra ID ） 是身分識別和存取管理的 Azure 解決方案。 這些 Microsoft Entra 工具和服務可協助安全開發：

  • Microsoft 身分識別平臺是開發人員用來建置安全地登入使用者的應用程式的一組元件。 此平臺可協助建置單一租使用者、企業營運 （LOB） 應用程式和想要開發多租使用者應用程式的開發人員。 除了基本登入之外，使用 Microsoft 身分識別平臺 建置的應用程式也可以呼叫 Microsoft API 和自訂 API。 Microsoft 身分識別平臺支援業界標準的通訊協定，例如 OAuth 2.0 和 OpenID 連線。

  • Azure Active Directory B2C （Azure AD B2C） 是一種身分識別管理服務，可用來自訂及控制客戶在使用應用程式時如何註冊、登入及管理其設定檔。 這包括針對 iOS、Android 和 .NET 開發的應用程式等等。 Azure AD B2C 可在保護客戶身分識別的同時啟用這些動作。

套用最低許可權原則

最低許可權 的概念 表示為使用者提供執行工作所需的精確存取和控制層級，而無所事事。

軟體發展人員是否需要網域系統管理員許可權？ 系統管理助理是否需要存取其個人電腦上的系統管理控制？ 評估軟體的存取權並無不同。 如果您使用 Azure 角色型存取控制 （Azure RBAC） 為使用者提供應用程式的不同能力和授權，則不會讓每個人存取所有專案。 藉由限制每個角色所需的存取權，您可以限制發生安全性問題的風險。

請確定您的應用程式在整個存取模式中 強制執行最低許可權 。

注意

最低許可權的規則必須套用至軟體，以及建立軟體的人員。 如果軟體發展人員獲得太多存取權，則 IT 安全性可能會面臨巨大的風險。 如果開發人員有惡意意圖或給予太多存取權，則後果可能會很嚴重。 建議您在開發生命週期內將最低許可權的規則套用至開發人員。

實作 Just-In-Time 存取

實 作 Just-In-Time （JIT） 存取，以進一步降低許可權暴露時間。 使用 Microsoft Entra Privileged Identity Management 來：

  • 為使用者提供他們只需要 JIT 的許可權。
  • 在縮短期間指派角色，並確信許可權會自動撤銷。

需要重新驗證重要交易

跨網站偽造要求 （也稱為 XSRF 或 CSRF ）是針對 Web 裝載的應用程式的攻擊，其中惡意 Web 應用程式會影響用戶端瀏覽器與信任該瀏覽器的 Web 應用程式之間的互動。 跨網站要求偽造攻擊是可能的，因為網頁瀏覽器會自動將某些類型的驗證權杖傳送給網站。 這種形式的惡意探索也稱為 單鍵攻擊 或 會話騎乘 ，因為攻擊會利用使用者先前驗證的會話。

防禦這類攻擊的最佳方式是要求使用者提供一些只有使用者才能提供的重要交易，例如購買、帳戶停用或密碼變更。 您可以要求使用者重新輸入其密碼、完成 captcha，或提交只有使用者擁有的秘密權杖。 最常見的方法是秘密權杖。

使用金鑰管理解決方案來保護金鑰、認證和其他秘密

遺失金鑰和認證是常見的問題。 唯一比失去金鑰和認證更糟的是，未經授權的合作物件可以存取它們。 攻擊者可以利用自動化和手動技術來尋找儲存在 GitHub 等程式碼存放庫中的金鑰和秘密。 請勿將這些公用程式代碼存放庫中的金鑰和秘密放在任何其他伺服器上。

請務必將金鑰、憑證、秘密和連接字串放在金鑰管理解決方案中。 您可以使用集中式解決方案，其中金鑰和秘密會儲存在硬體安全性模組 （HSM） 中。 Azure 提供雲端中的 HSM 與 Azure 金鑰保存庫 。

金鑰保存庫是秘密 存放區 ：它是用來儲存應用程式秘密的集中式雲端服務。 金鑰保存庫將應用程式秘密保存在單一集中位置，並提供安全存取、許可權控制和存取記錄，以保護您的機密資料。

秘密會儲存在個別 保存 庫中。 每個保存庫都有自己的組態和安全性原則來控制存取。 您可以透過 REST API 或適用于大部分程式設計語言的用戶端 SDK 來取得資料。

重要

Azure 金鑰保存庫是設計來儲存伺服器應用程式的組態秘密。 它不適用於儲存屬於應用程式使用者的資料。 這會反映在其效能特性、API 和成本模型中。

使用者資料應該儲存在其他地方，例如在具有透明資料加密 （TDE） 的 Azure SQL 資料庫 實例，或是使用 Azure 儲存體 服務加密的儲存體帳戶中。 應用程式用來存取這些資料存放區的秘密可以保留在 Azure 金鑰保存庫。

保護敏感性資料

保護資料是安全性策略中不可或缺的一部分。 將資料分類並識別資料保護需求，可協助您以資料安全性為考慮來設計應用程式。 透過敏感度和業務影響來分類（分類）儲存的資料，可協助開發人員判斷與資料相關聯的風險。

當您設計資料格式時，將所有適用的資料標示為機密資料。 請確定應用程式會將適用的資料視為機密資料。 這些做法可協助您保護敏感性資料：

  • 使用加密。
  • 避免硬式編碼秘密，例如金鑰和密碼。
  • 請確定存取控制和稽核已就緒。

使用加密

保護資料應該是安全性策略中不可或缺的一部分。 如果您的資料儲存在資料庫中，或是在位置之間來回移動，請使用待 用資料的加密（在資料庫中）和傳輸 中資料的加密 （在使用者、資料庫、API 或服務端點的往返途中）。 建議您一律使用 SSL/TLS 通訊協定來交換資料。 請確定您使用最新版的 TLS 進行加密（目前，這是 1.2 版）。

避免硬式編碼

有些事情不應該在您的軟體中硬式編碼。 有些範例包括主機名稱或 IP 位址、URL、電子郵件地址、使用者名稱、密碼、儲存體帳戶金鑰和其他密碼編譯金鑰。 請考慮實作程式碼中可以或無法硬式編碼的需求，包括在程式碼的批註區段中。

當您在程式碼中放置批註時，請確定您不會儲存任何敏感性資訊。 這包括您的電子郵件地址、密碼、連接字串、只有貴組織中某人知道的應用程式相關資訊，以及可能讓攻擊者攻擊應用程式或組織的其他任何專案。

基本上，假設您開發專案中的所有專案都是部署時的公開知識。 避免在專案中包含任何類型的敏感性資料。

稍早，我們已討論 Azure 金鑰保存庫 。 您可以使用金鑰保存庫來儲存秘密，例如金鑰和密碼，而不是硬式編碼。 當您搭配 Azure 資源的受控識別使用金鑰保存庫時，Azure Web 應用程式可以輕鬆且安全地存取秘密設定值，而不需要將任何秘密儲存在原始檔控制或設定中。 若要深入瞭解，請參閱 使用 Azure 金鑰保存庫 管理伺服器應用程式中的秘密。

實作安全措施

您的應用程式必須能夠以一致的方式處理 執行期間發生的錯誤 。 應用程式應該攔截所有錯誤，並讓安全或關閉。

您也應該確保已使用足夠的使用者內容來記錄錯誤，以識別可疑或惡意活動。 記錄應該保留足夠的時間，以允許延遲的鑒識分析。 記錄格式應為記錄管理解決方案輕鬆取用的格式。 確定觸發與安全性相關的錯誤警示。 記錄和監視不足可讓攻擊者進一步攻擊系統並維護持續性。

利用錯誤和例外狀況處理

實作正確的錯誤和 例外狀況處理 是防禦程式碼的重要部分。 錯誤和例外狀況處理對於讓系統變得可靠且安全至關重要。 錯誤處理的錯誤可能會導致不同類型的安全性弱點，例如將資訊洩漏給攻擊者，並協助攻擊者深入瞭解您的平臺和設計。

請確定：

  • 您可以集中處理例外狀況，以避免程式碼中重複的 try/catch 區塊 。

  • 應用程式內會處理所有非預期的行為。

  • 向使用者顯示的訊息不會洩漏重要資料，但會提供足夠的資訊來說明問題。

  • 系統會記錄例外狀況，並提供足夠的資訊來調查鑒識或事件回應小組。

Azure Logic Apps 提供處理相依系統所造成的錯誤和例外 狀況的第一級體驗 。 您可以使用 Logic Apps 來建立工作流程，將跨企業和組織整合應用程式、資料、系統和服務的工作和程式自動化。

使用記錄和警示

記錄 安全性問題以進行安全性調查，並觸發有關問題的警示，以確保人員能及時瞭解問題。 在所有元件上啟用稽核和記錄。 稽核記錄應該擷取使用者內容並識別所有重要事件。

確認您不會記錄使用者提交至您的網站的任何敏感性資料。 敏感性資料的範例包括：

  • 使用者認證
  • 社會安全號碼或其他識別資訊
  • 信用卡號碼或其他財務資訊
  • 健康情況資訊
  • 私密金鑰或其他可用來解密加密資訊的資料
  • 系統或應用程式資訊，可用來更有效地攻擊應用程式

請確定應用程式會監視使用者管理事件，例如成功和失敗的使用者登入、密碼重設、密碼變更、帳戶鎖定，以及使用者註冊。 這些事件的記錄可協助您偵測並回應潛在的可疑行為。 它也可讓您收集作業資料，例如存取應用程式的人員。

下一步

在下列文章中，建議您使用可協助您開發及部署安全應用程式的安全性控制項和活動。