在 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 應用程式攻擊。

• 適用於 Azure 的安全 DevOps 套件 (英文) 是指令碼、工具、延伸模組和自動化功能的集合，可滿足使用廣泛自動化功能的 DevOps 小組對於 Azure 訂用帳戶和資源安全性的全面需求。 適用於 Azure 的安全 DevOps 套件可向您示範如何將安全性順暢地整合到原生 DevOps 工作流程中。 這個套件可當成安全性驗證測試 (SVT) 這類工具，協助開發人員撰寫安全程式碼，並在撰寫程式碼和開發早期階段測試雲端應用程式的安全設定。

• Azure 安全性最佳做法和模式 (部分機器翻譯)：使用 Azure 來設計、部署和管理雲端解決方案時，可使用的安全性最佳做法集合。 本指導方針旨在作為 IT 專業人員的資源。 其中可包括建置和部署安全 Azure 解決方案的設計人員、架構設計師、開發人員和測試人員。

需求

需求定義階段是個重要步驟，因為您必須定義應用程式是什麼，以及其在發行後會執行哪些動作。 您也需在需求定義階段考慮要建置到應用程式中的安全性控制措施。 在此階段中，您也會開始在整個 SDL 中都會採取的步驟，以確保發行和部署安全的應用程式。

考慮安全性和隱私權問題

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

• 了解與安全性問題相關聯的風險。
• 識別並修正開發過程中出現的安全性錯誤。
• 在整個專案中套用確立的安全性和隱私權層級。

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

針對安全性提出問題

針對安全性提出問題，例如：

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

• 我的應用程式收集或儲存的資料，必須遵守業界標準和合規性計畫 (例如聯邦金融機構檢查委員會 (FFIEC) 或支付卡產業資料安全性標準 (PCI DSS) 等) 嗎？

• 我的應用程式是否會收集或包含敏感性個人或客戶資料，這些資料單獨使用或搭配其他資訊使用可識別、聯絡或尋找單一人員？

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

• 我的資料會以何種方式儲存在何處？ 考慮要如何監視您應用程式使用的儲存體服務，以確認是否出現任何非預期的變更 (例如回應時間變慢)。 您是否能影響記錄功能以收集更詳細的資料並深入分析問題？

• 我的應用程式 (在網際網路上) 開放大眾使用或僅限內部使用？ 如果您的應用程式開放大眾使用，如何保護可能收集到的資料，避免以錯誤的方式使用？ 如果您的應用程式只供內部使用，請考慮組織中的哪些人應該可以存取應用程式，以及他們應擁有存取權的時間長度。

• 開始設計應用程式之前，您是否了解您的身分識別模型？ 您是否能判斷使用者真的是他們所表明的身分，以及使用者有權執行什麼操作？

• 我的應用程式是否會執行敏感性或重要工作 (例如轉帳、開門鎖或遞送藥物)？ 請考慮如何驗證執行敏感性工作的使用者是否有權執行該工作，以及如何驗證該人員的身分。 授權 (AuthZ) 這個動作指的是授與已通過驗證的安全性主體執行某些工作的權限。 驗證 (AuthN) 這個動作指的是查問對象是否具有合法認證。

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

檢閱 OWASP Top 10

請考慮檢閱 OWASP Top 10 應用程式安全性風險。 OWASP Top 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 Service Web Apps (Web 應用程式) 是其中一項服務。

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

Azure 提供的其他服務可用來裝載網站和 Web 應用程式。 大部分的情況下，Web Apps 是最佳選擇。 針對微服務架構，可考慮使用 Azure Service Fabric。 如果您需要能更加充分地掌控程式碼執行所在的 VM，則請考慮使用 Azure 虛擬機器。 如需深入了解如何在這些 Azure 服務之間做選擇，請參閱 Azure App Service、虛擬機器、Service Fabric 及雲端服務的比較。

將更新套用至元件

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

如需工具建議，請參閱關於使用含已知弱點的元件 (英文) 的 Open Web Application Security Project (英文) (OWASP) 頁面。 您也可以訂閱電子郵件警示，了解與您所使用元件相關的安全性弱點。

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

威脅模型分析是識別業務和應用程式潛在安全性威脅的程序，可確保適當的風險降低措施已就緒。 SDL 指定了在解決潛在問題相對簡單且符合成本效益的情況下，小組應在設計階段進行威脅模型分析。 在設計階段使用威脅模型分析可大幅降低開發的總成本。

為了協助執行威脅模型化程序，我們在不考慮安全性專家的情況下，設計出 SDL Threat Modeling Tool。 此工具提供如何建立和分析威脅模型的清楚指引，讓所有開發人員都能更輕鬆進行威脅模型分析。

橫跨所有信任界限對應用程式設計進行建模並列舉 STRIDE 威脅 (詐騙、竄改、否認性、資訊洩漏、拒絕服務以及提高權限)，已被證明是能及早攔截設計錯誤的有效方式。 下表列出 STRIDE 威脅，並提供一些使用 Azure 功能的風險降低措施範例。 這些風險降低措施不適用於所有情況。

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

縮小受攻擊面

受攻擊面是可能出現潛在弱點的總和。 本文將焦點放在應用程式的受攻擊面。 重點在於保護應用程式，避免遭受攻擊。 將受攻擊面縮到最小的簡單且快速方式，就是移除應用程式中未使用的資源和程式碼。 應用程式越小，受攻擊面就越小。 例如，可移除：

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

定期清除資源並確實移除未使用的程式碼，是確保減少惡意人士攻擊機會的絕佳方式。

降低受攻擊面更詳細且深入的方式，就是完成受攻擊面分析。 受攻擊面分析可協助您對應系統中需要檢查及測試安全性弱點的部分。

受攻擊面分析的目的是了解應用程式中的風險區域，讓開發人員和安全性專家知道應用程式有哪些部分容易受成為攻擊目標。 接著您可以尋找將這種可能性降到最低的方式、追蹤受攻擊面變更的時間點和方式，以及從風險觀點來看這代表的意義。

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

• 系統中需要檢查和測試安全性弱點的功能和部分。
• 程式碼中需要深度防禦機制保護的高風險區域 (系統中需要防禦的部分)。
• 當您改變了受攻擊面並需要重新整理威脅評估時。

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

我們會討論在 SDL 的驗證階段說明如何進行受攻擊面檢查。

注意

威脅模型分析和受攻擊面分析有何差異？ 威脅模型分析是識別應用程式潛在安全性威脅的程序，可確保針對威脅的適當風險降低措施已就緒。 受攻擊面分析會識別容易成為攻擊目標的程式碼高風險區域。 過程包含在部署應用程式之前，找出保護應用程式高風險區域，以及檢查和測試這些程式碼區域的方法。

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

設計雲端應用程式時，請務必將安全界限焦點從以網路為中心的做法擴展為以身分識別為中心的做法。 在過去，主要內部部署安全界限是組織的網路。 大部分的內部部署安全性設計都使用網路作為主要安全性樞紐。 針對雲端應用程式，將身分識別視為主要安全界限可為您提供較佳的服務。

您可以採取哪些行動來發展出以身分識別為中心的做法，用於開發 Web 應用程式：

• 針對使用者強制執行多重要素驗證。
• 使用增強式驗證與授權平台。
• 套用最低權限原則。
• 實作即時存取。

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

使用雙重要素驗證。 雙因素驗證是現行的驗證與授權標準，因為它可避免使用者名稱與密碼型驗證機制固有的安全性弱點。 Azure 管理介面 (Azure 入口網站/遠端 PowerShell) 和面向客戶之服務的存取方式，都應設計並設定成使用 Microsoft Entra 多重要素驗證 (部分機器翻譯)。

使用增強式驗證與授權平台

使用平台提供的驗證和授權機制，而不是自訂程式碼。 這是因為開發自訂驗證碼很容易發生錯誤。 商業程式碼 (例如 Microsoft 所提供的) 通常都經過廣泛的安全性檢查。 Microsoft Entra ID (部分機器翻譯) 是適用於身分識別和存取權管理的 Azure 解決方案。 這些 Microsoft Entra 工具和服務有助於進行安全開發：

• Microsoft 身分識別平台是一組元件，開發人員可用來建置讓使用者安全登入的應用程式。 此平台可協助開發人員建置單一租用戶、企業營運 (LOB) 應用程式，以及開發多租用戶應用程式。 除了基本登入功能之外，使用 Microsoft 身分識別平台建置的應用程式還可以呼叫 Microsoft API 和自訂 API。 Microsoft 身分識別平台支援業界標準通訊協定，像是 OAuth 2.0 與 OpenID Connect。

• 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 透過 Azure Key Vault 提供雲端 HSM。

Key Vault 是一種「祕密存放區」：儲存應用程式祕密的集中式雲端服務。 Key Vault 可將應用程式祕密保存在單一中央位置，並提供安全存取、權限控制和存取記錄，以維護機密資料的安全性。

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

重要

Azure Key Vault 專為儲存伺服器應用程式的設定祕密所設計。 不適用於儲存屬於應用程式使用者的資料。 這會反映在其效能特性、API 和成本模型中。

使用者資料應儲存在其他地方，例如具有透明資料加密 (TDE) 的 Azure SQL 資料庫執行個體中，或是使用 Azure 儲存體服務加密的儲存體帳戶中。 您的應用程式用來存取這些資料存放區的祕密可以保存在 Azure Key Vault 中。

保護敏感資料

保護資料是安全性策略不可或缺的一部分。 將資料分類並識別資料保護需求，可協助您在設計應用程式融入資料安全性。 依敏感度與業務影響將儲存的資料分類，可協助開發人員判斷與資料相關聯的風險。

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

• 使用加密。
• 避免將秘密 (例如金鑰和密碼) 寫入程式碼。
• 確定存取控制和稽核已就緒。

使用加密功能

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

避免寫入程式碼

某些資料永遠不應在您的軟體中寫入程式碼。 幾個範例包括主機名稱或 IP 位址、URL、電子郵件地址、使用者名稱、密碼、儲存體帳戶金鑰和其他密碼編譯金鑰。 請考慮在需求中規定可以或無法寫入程式碼的項目，包括程式碼的註解區段中。

在程式碼中加入註解時，請勿儲存任何敏感資訊。 這包括電子郵件地址、密碼、連接字串、只有貴組織內部人員知道的應用程式相關資訊，以及可能讓攻擊者利用來攻擊應用程式或組織的其他任何資料。

基本上，請假設開發專案中的所有內容在其部署時都會成為公開知識。 避免在專案中包含任何類型的敏感資料。

稍早我們已說明了 Azure Key Vault。 您可以使用 Key Vault 來儲存金鑰和密碼等秘密，而不是寫入程式碼。 Key Vault 搭配 Azure App Service 受控服務識別的功能，Azure Web 應用程式便可輕鬆且安全地存取祕密設定值，而不需要將任何祕密儲存在原始程式碼控制或設定中。 如需詳細資訊，請參閱使用 Azure Key Vault 管理伺服器應用程式中的祕密。

實作防故障措施

應用程式必須能以一致的方式處理執行期間發生的錯誤。 應用程式應該攔截所有錯誤，然後進行防故障或關閉程序。

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

善用錯誤和例外狀況處理機制

實作正確的錯誤和例外狀況處理機制，是防禦性程式碼的重要部分。 錯誤和例外狀況處理機制非常重要，有助於讓系統變得可靠安全。 錯誤處理機制中若有誤，可能會導致不同類型的安全性弱點，例如將資訊洩漏給攻擊者，以及協助攻擊者深入了解您的平台和設計。

請確定：

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

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

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

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

Azure Logic Apps (部分機器翻譯) 提供處理由相依系統所造成的錯誤和例外狀況的一流體驗。 您可以使用 Logic Apps 建立可自動執行工作和程序的工作流程，以便整合不同企業或組織間的應用程式、資料、系統和服務。

使用記錄與警示功能

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

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

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

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

下一步

在下列文章中，我們會建議可協助您設計和部署安全應用程式的安全性控制機制和活動。

• 開發安全的應用程式
• 部署安全的應用程式