分享方式：

Azure 安全性最佳做法

  • 文章

本文說明建議的安全性最佳做法，這些最佳做法是以客戶所學到的教訓為基礎，以及從我們自己環境中的經驗。

如需影片簡報，請參閱 Azure 安全性 的最佳做法。

1. 人員：教育小組瞭解雲端安全性旅程

小組必須瞭解他們正在進行的旅程。

什麼

教育您的安全性和 IT 小組瞭解雲端安全性旅程，以及他們將流覽的變更，包括：

  • 雲端中的威脅
  • 共同責任模型及其影響安全性的方式
  • 文化特性和角色和責任的變更，通常隨附于雲端採用

為何會這樣？

雲端安全性需要轉變思維和方法。 雖然安全性提供給組織的結果不會變更，但在雲端中達成這些結果的最佳方式可能會大幅變更。

向雲端的過渡類似于從獨立房屋移至高層公寓樓。 你仍然有基本的基礎設施，如管道和電力，並做類似的活動，如社交，烹飪，電視和互聯網等。 然而，大樓隨附的內容往往有很大的不同，他們提供和維護它，以及日常的例行公事。

神秘？

安全性與 IT 組織中的每個人都必須熟悉變更，從 CIO 或 CISO 到技術從業者的任何安全性責任。

怎麼做？

提供小組在轉換至雲端環境期間成功部署及操作所需的內容。

Microsoft 已發佈下列課程，客戶和 IT 組織已瞭解其雲端旅程。

如需詳細資訊，請參閱 Azure 安全性效能評定 角色、責任和責任。

2. 人員：教育小組使用雲端安全性技術

人員需要瞭解他們要去哪裡。

什麼

請確定您的小組有時間用於保護雲端資源的技術教育，包括：

  • 雲端技術和雲端安全性技術
  • 建議的設定和最佳做法
  • 深入瞭解技術詳細資料的位置

為何會這樣？

技術小組需要存取技術資訊，才能做出明智的安全性決策。 技術小組擅長在工作中學習新技術，但雲端中的詳細資料量往往壓倒了他們適合日常學習的能力。

為技術學習預留專用時間。 學習可協助確保人們有時間建立對評估雲端安全性能力的信心。 這有助於他們思考如何調整其現有的技能和程式。

神秘？

與雲端技術直接互動的所有安全性和 IT 角色，都必須為雲端平臺上的技術學習提供時間，以及如何保護這些角色。

安全性、IT 技術經理和專案經理可以開發熟悉一些保護雲端資源的技術詳細資料。 這種熟悉度可協助他們更有效率地引導及協調雲端計畫。

怎麼做？

請確定技術安全性專業人員已預留時間進行自我訓練，以瞭解如何保護雲端資產。 雖然不一定可行，但請透過經驗豐富的講師和實際操作實驗室，提供正式訓練的存取權。

重要

身分識別通訊協定對於雲端中的存取控制至關重要，但通常不會在內部部署安全性中設定優先順序。 安全性小組必須專注于開發對這些通訊協定和記錄的熟悉度。

Microsoft 提供廣泛的資源，協助技術專業人員提升其功能。 這些資源包括：

3.程式：指派雲端安全性決策的責任

如果沒有人負責制定安全決策，則不會做出安全決策。

什麼

選擇負責為企業 Azure 環境做出每種安全性決策的人員。

為何會這樣？

清楚擁有安全性決策可加速雲端採用並增加安全性。 缺乏擁有權通常會產生摩擦，因為沒有人覺得有權做出決策。 沒有人知道誰要求決定，沒有人激勵研究一個明智的決定。 摩擦經常阻礙：

  • 商務目標
  • 開發人員時程表
  • IT 目標
  • 安全性保證

摩擦可能會導致：

  • 等待安全性核准的停滯專案
  • 無法等待安全性核准的不安全部署

神秘？

安全性領導階層會選擇哪些小組或個人負責制定雲端的安全性決策。

怎麼做？

選擇要負責做出重要安全性決策的群組或個人。

記錄這些擁有者、其連絡資訊，並在安全性、IT 和雲端小組中廣泛社交資訊。 社交化可確保所有角色都能輕鬆連絡他們。

這些區域通常是需要安全性決策的地方。 下表顯示決策類別、類別描述，以及哪些小組通常會做出決策。

Decision 描述 一般小組
網路安全性 設定和維護Azure 防火牆、網路虛擬裝置和相關路由、Web 應用程式防火牆（WAF）、NSG、ASG 等等。 以網路安全性為重點的基礎結構和端點安全性 小組
網路管理 管理全企業虛擬網路和子網配置。 中央 IT 作業中 現有的網路作業小組
伺服器端點安全性 監視和補救伺服器安全性，包括修補、設定、端點安全性等等。 中央 IT 作業 和 基礎結構和端點安全性 小組共同合作
事件監視和回應 調查並補救 SIEM 或來源主控台中的安全性事件，包括適用於雲端的 Microsoft Defender、Microsoft Entra ID Protection 等等。 安全性作業 小組
原則管理 設定使用 Azure 角色型存取控制的方向（Azure RBAC）、適用於雲端的 Defender、系統管理員保護原則，以及管理 Azure 資源Azure 原則。 原則和安全性 架構 小組共同合作
身分識別安全性和標準 設定 Microsoft Entra 目錄、PIM/pam 使用方式、多重要素驗證、密碼/同步處理設定、應用程式身分識別標準的方向。 身分識別與金鑰管理 、 原則與標準 ，以及 安全性架構 小組共同合作

注意

  • 確保決策者在其雲端區域中具有適當的教育，以伴隨此責任。
  • 確保決策記載在原則和標準中，以提供記錄並指導組織長期。

4.程式：更新雲端的事件回應程式

提前規劃。 你沒有時間在危機期間計畫危機。

什麼

準備 Azure 雲端平臺上的安全性事件。 此準備包含您已採用的任何 原生威脅偵測工具 。 更新程式、準備小組，以及使用模擬攻擊進行練習，讓他們能夠在事件調查、補救和威脅搜捕期間發揮最佳作用。

為何會這樣？

作用中攻擊者會立即對組織造成風險。 這種情況可能會很快變得難以控制。 快速且有效地回應攻擊。 此事件回應 （IR） 程式必須對您的整個資產有效，包括裝載企業資料、系統和帳戶的所有雲端平臺。

雖然在許多方面類似，但雲端平臺在技術上與內部部署系統不同。 內部部署系統可能會中斷現有的進程，通常是因為資訊以不同的形式提供。 安全性分析師可能會面臨快速回應不熟悉的環境，以減緩這些環境的挑戰。 如果只在傳統內部部署架構和網路/磁片鑒識方法上定型，則此語句特別正確。

神秘？

IR 程式現代化通常是由 安全性作業 所領導。 這些工作通常來自其他小組對知識和專業知識的支援。

  • 贊助 ：安全性作業主管或對等專案通常是贊助程式現代化。

  • 執行 ：調整現有的程式，或第一次撰寫它們，是一項共同作業，涉及：

    • 安全性作業 ：事件管理小組或領導小組會領導流程和整合更新給重要的外部專案關係人。 這些團隊包括法律和溝通或公關團隊。
    • 安全性作業 ：安全性分析師提供技術事件調查和分級的專業知識。
    • 中央 IT 作業 ：此小組會透過卓越雲端中心，或透過外部顧問，直接提供雲端平臺的專業知識。

怎麼做？

更新程式並準備您的小組，讓他們知道他們找到作用中的攻擊者時該怎麼做。

  • 流程和劇本 ：將現有的調查、補救和威脅搜捕程式調整為雲端平臺運作方式的差異。 差異包括新的或不同的工具、資料來源、身分識別通訊協定等等。
  • 教育 ：教育分析師瞭解整體雲端轉型、平臺運作方式的技術詳細資料，以及新的或更新的程式。 這項資訊可讓他們知道哪些內容可能會變更，以及需要哪些專案。
  • 重點領域 ：雖然資源連結中有許多詳細資料，但這些區域是集中您的教育和規劃工作的地方：
    • 共同責任模型和雲端架構 ：對於安全性分析師，Azure 是一個軟體定義的資料中心，可提供許多服務。 這些服務包括 VM 和其他不同于內部部署的 VM，例如 Azure SQL 資料庫 Azure Functions。 最佳資料位於服務記錄或特製化威脅偵測服務中。 它不在基礎 OS/VM 的記錄中，而基礎 OS/VM 是由 Microsoft 和服務多個客戶所運作。 分析師必須瞭解此內容並將其整合到其每日工作流程中。 如此一來，他們就能知道預期的資料、取得資料的位置，以及其格式為何。
    • 端點資料來源 ：使用原生雲端偵測工具，取得攻擊和惡意程式碼的深入解析和資料通常更快、更輕鬆且更精確。 適用於雲端的 Microsoft Defender和端點偵測及回應 （EDR） 解決方案等工具提供比傳統直接磁片存取方法更精確的資料。 直接磁片鑒識適用于可能且需要進行法律訴訟的案例。 如需詳細資訊，請參閱 Azure 中的電腦鑒識。 不過，這種方法通常是偵測和調查攻擊的最沒有效率的方法。
    • 網路和身分識別資料來源 ：許多雲端平臺的功能主要使用身分識別進行存取控制。 此存取控制包括Azure 入口網站的存取權，不過網路存取控制也會廣泛使用。 此存取控制要求分析師瞭解雲端身分識別通訊協定，以取得攻擊者活動和合法使用者活動的完整、豐富的圖片，以支援事件調查和補救。 身分識別目錄和通訊協定與內部部署目錄不同。 它們通常以 SAML、OAuth 和 OpenID 連線和雲端目錄為基礎，而不是 LDAP、Kerberos、NTLM 和 Active Directory。
    • 練習練習 ：模擬攻擊和回應有助於建立組織肌肉記憶和技術整備。 他們會為您的安全性分析師、威脅獵人、事件管理員，以及貴組織中的其他專案關係人提供準備。 學習作業和調整是事件回應的自然部分，但您可以努力將您在危機中學到多少東西降到最低。

主要資源

如需詳細資訊，請參閱 Azure 的 Azure 安全性效能評定 事件回應程式。

5. 程式：建立安全性狀態管理

首先，認識自己。

什麼

請確定您正透過下列方式主動管理 Azure 環境的安全性狀態：

  • 將清楚的責任擁有權指派給：
    • 監視安全性狀態
    • 降低資產的風險
  • 自動化和簡化這些工作

為何會這樣？

快速識別和補救常見的安全性衛生風險，可大幅降低組織風險。

雲端資料中心的軟體定義本質可讓您持續監視安全性風險，例如軟體弱點或安全性設定錯誤，以及廣泛的資產檢測。 開發人員和 IT 小組可以部署 VM、資料庫和其他資源的速度，需要確保資源受到安全且主動的監視。

這些新功能提供新的可能性，但從中實現價值需要指派使用責任。 以快速演進的雲端作業一致執行，需要盡可能讓人力程式保持簡單且自動化。 請參閱「磁片磁碟機簡單」 安全性準則 。

注意

簡化和自動化的目標不是擺脫工作，而是要從人員身上消除重複工作的負擔，這樣他們就可以專注于更高的價值人類活動，例如參與和教育 IT 和 DevOps 小組。

神秘？

這種做法通常分成兩組責任：

  • 安全性狀態管理 ：此函式通常是現有弱點管理或治理函式的演進。 結果包括使用適用於雲端的 Microsoft Defender安全分數和其他資料來源來監視整體安全性狀態。 它包括積極與資源擁有者合作，以降低風險，並將風險回報給安全性領導階層。

  • 安全性補救 ：將解決這些風險的責任指派給負責管理這些資源的小組。 此責任屬於 DevOps 小組管理自己的應用程式資源，或中央 IT 作業 中的 技術特定小組：

    • 計算和應用程式資源
      • 應用程式服務 ：應用程式開發和安全性小組
      • 容器 ：應用程式開發或基礎結構/IT 作業
      • VM、擴展集、計算 ：IT/基礎結構作業
    • 資料和儲存體資源
      • SQL、Redis、Data Lake Analytics、Data Lake Store ：資料庫小組
      • 儲存體帳戶 ：儲存體和基礎結構小組
    • 身分識別和存取資源
      • 訂用帳戶 ：身分識別小組
      • 金鑰保存庫 ：身分識別或資訊/資料安全性小組
    • 網路資源 ：網路安全性小組
    • IoT 安全性 ：IoT 作業小組

怎麼做？

安全性是每個人的工作。 不過，並不是每個人都知道它有多重要、該怎麼做，以及如何做到這一點。

  • 保留資源擁有者負責安全性風險，就像他們負責可用性、效能、成本和其他成功因素一樣。
  • 清楚瞭解安全性風險對資產為何重要、可降低風險的動作，以及如何以最少的生產力損失來實作資源擁有者。

重要

為何、何謂及如何保護資源的說明，通常與不同資源類型和應用程式相似，但請務必將這些資源與每個小組已經知道和關心的內容產生關聯。 安全性小組可以與其 IT 和 DevOps 對應人員互動，作為受信任的顧問和合作夥伴，專注于讓這些小組成功。

工具： 適用於雲端的 Microsoft Defender中的安全分數 會針對各種不同的資產，提供 Azure 中最重要的安全性資訊評量。 此評量可以是您狀態管理的起點，並可視需要補充自訂 Azure 原則和其他機制。

頻率 ：設定一般頻率，通常是每月，以檢閱具有特定改進目標的 Azure 安全分數和計畫方案。 您可以視需要增加頻率。

提示

如果可能增加參與度，請進行遊戲化活動，例如為 DevOps 小組創造有趣的競賽和獎品，以提升其分數。

如需詳細資訊，請參閱 Azure 安全性效能評定 安全性狀態管理原則 。

6. 技術：需要無密碼或多重要素驗證

您是否願意押注專業攻擊者無法猜測或竊取系統管理員密碼的企業安全性？

什麼

需要所有重大影響系統管理員才能使用無密碼或多重要素驗證。

為何會這樣？

正如古董骨架鑰匙不會保護房子免受現代入室盜竊，密碼無法保護帳戶免受常見的攻擊。 如需技術詳細資料，請參閱 您的 pa$$word並不重要 。

多重要素驗證曾經是繁重的額外步驟。 現今的無密碼方法可改善使用者使用 Windows Hello 和行動裝置中的臉部辨識等生物特徵辨識方法登入的方式。 此外，零信任方法會記住受信任的裝置。 這個方法可減少提示發出令人惱火的頻外多重要素驗證動作。 如需詳細資訊，請參閱 使用者登入頻率 。

神秘？

密碼和多重要素計畫通常是由 身分識別和金鑰管理 或 安全性架構 所領導。

怎麼做？

實作無密碼或多重要素驗證。 訓練系統管理員如何視需要使用它，並要求系統管理員遵循書面原則。 使用下列其中一或多項技術：

注意

文字訊息型多重要素驗證現在相對便宜，攻擊者可略過，因此著重于無密碼和更強的多重要素驗證。

如需詳細資訊，請參閱所有 Microsoft Entra 識別碼型存取 的 Azure 安全性效能評定 增強式驗證控制項。

7. 技術：整合原生防火牆和網路安全性

簡化系統與資料免受網路攻擊的保護。

什麼

藉由將 Azure 防火牆、Azure Web 應用程式防火牆 （WAF） 和分散式阻斷服務 （DDoS） 防護功能整合到您的網路安全性方法，以簡化您的網路安全性策略和維護。

為何會這樣？

簡單起見對於安全性至關重要，因為它可降低混淆、設定錯誤和其他人為錯誤的風險的可能性。 請參閱「磁片磁碟機簡單」安全性準則 。

防火牆和 WAF 是保護應用程式免于惡意流量的重要基本安全性控制，但其設定和維護可能很複雜，並耗用大量安全性小組的時間和注意力（類似于將自訂後市零件新增至汽車）。 Azure 的原生功能可以簡化防火牆的實作和作業、Web 應用程式防火牆、分散式阻斷服務 （DDoS） 風險降低等作業。

這種做法可以釋出小組的時間，並注意更高的價值安全性工作，例如：

  • 評估 Azure 服務的安全性
  • 自動化安全性作業
  • 整合安全性與應用程式和 IT 解決方案

神秘？

  • 贊助 ：安全性領導或 IT 領導階層通常會贊助網路安全性策略更新。
  • 執行 ：將策略整合到您的雲端網路安全性策略中，是一項共同作業，涉及：
    • 安全性架構 ：使用雲端網路和雲端網路安全性潛在客戶建立雲端網路安全性架構。
    • 雲端網路領導 中央 IT 作業 和 雲端網路安全性領導 基礎結構安全性小組
      • 使用安全性架構設計人員建立雲端網路安全性架構。
      • 設定防火牆、NSG 和 WAF 功能，並與 WAF 規則的應用程式架構設計人員合作。
    • 應用程式架構設計人員 ：使用網路安全性來建置和精簡 WAF 規則集和 DDoS 設定，以保護應用程式，而不會中斷可用性

怎麼做？

想要簡化其作業的組織有兩個選項：

  • 擴充現有的功能和架構 ：許多組織通常會選擇擴充現有防火牆功能的使用，以便利用現有的技能與程式整合投資，特別是當他們第一次採用雲端時。
  • 採用原生安全性控制項：更多組織開始偏好使用原生控制項 ，以避免整合協力廠商功能的複雜性。 這些組織通常會尋求避免負載平衡、使用者定義路由、防火牆或 WAF 本身設定錯誤的風險，以及不同技術小組之間的交接延遲。 此選項令人信服的組織採用基礎結構即程式碼的方法，因為它們可以比協力廠商功能更容易自動化及檢測內建功能。

如需 Azure 原生網路安全性功能的檔，請參閱：

Azure Marketplace 包含許多協力廠商防火牆提供者。

如需詳細資訊，請參閱 Azure 安全性基準測試 DDOS 保護和 Web 應用程式防火牆保護 。

8. 技術：整合原生威脅偵測

簡化針對 Azure 系統和資料的攻擊偵測和回應。

什麼

藉由將原生威脅偵測功能併入安全性作業和 SIEM，以簡化威脅偵測和回應策略。

為何會這樣？

安全性作業的目的是要減少存取環境的作用中攻擊者的影響。 影響是以承認（MTTA）和補救（MTTR）事件的平均時間來衡量。 在事件回應的所有元素中，這種做法都需要精確度和速度。 結果有助於確保工具的品質，以及程式執行效率至關重要。

使用現有的工具和方法很難取得高威脅偵測。 這些工具和方法是針對內部部署威脅偵測所設計，因為雲端技術的差異及其快速變更速度。 原生整合式偵測提供雲端提供者維護的產業規模解決方案，以跟上目前的威脅和雲端平臺變更。

這些原生解決方案可讓安全性作業小組專注于事件調查和補救。 透過從不熟悉的記錄資料建立警示、整合工具和維護工作，專注于這些專案，而不是浪費時間。

神秘？

通常由 安全性作業 小組所驅動。

  • 贊助 ：這項工作通常是由安全性作業主管或對等角色贊助。
  • 執行 ：整合原生威脅偵測是一項共同作業，涉及這些解決方案與：
    • 安全性作業 ：將警示整合到 SIEM 和事件調查程式。 安全性作業可以教育分析師瞭解雲端警示及其意義，以及如何使用原生雲端工具。
    • 事件準備 ：將雲端事件整合到練習練習中，並確保會進行練習練習，以推動小組整備。
    • 威脅情報 ：研究並整合雲端攻擊的相關資訊，以通知小組內容和情報。
    • 安全性架構 ：將原生工具整合到安全性架構檔中。
    • 原則和標準 ：設定標準和原則，以在整個組織中啟用原生工具。 監視合規性。
    • 基礎結構和端點 和 中央 IT 作業 ：設定和啟用偵測，並整合至自動化和基礎結構即程式碼解決方案。

怎麼做？

針對您使用的所有資源，啟用 適用於雲端的 Microsoft Defender 的威脅偵測，並讓每個小組將這些資源整合到其程式，如上所述。

如需詳細資訊，請參閱 Azure 資源的 Azure 安全性效能評定 威脅偵測。

9.架構：在單一目錄和身分識別上標準化

沒有人想要處理多個身分識別和目錄。

什麼

在單一 Microsoft Entra 目錄上標準化。 您可以將 Azure 中每個應用程式和使用者的單一身分識別標準化。

注意

此最佳做法特別是指企業資源。 針對合作夥伴帳戶，請使用 Microsoft Entra B2B ，因此您不需要在目錄中建立和維護帳戶。 針對客戶或公民帳戶，請使用 Azure AD B2C 來管理它們。

為何會這樣？

多個帳戶和身分識別目錄會產生不必要的摩擦，這會在每日工作流程中造成混淆：

  • 生產力使用者
  • 開發人員
  • IT 和身分識別系統管理員
  • 安全性分析師
  • 其他角色

管理多個帳戶和目錄會為不良的安全性做法建立獎勵。 這些做法包括跨帳戶重複使用密碼之類的做法。 這會增加攻擊者可鎖定的過時或已放棄帳戶的可能性。

雖然有時似乎更容易快速為特定應用程式或工作負載建立自訂 LDAP 目錄，但此動作會建立更多工作來整合和管理。 這項工作類似于選擇設定額外的 Azure 租使用者或內部部署的 Active Directory樹系，而不是使用現有的企業租使用者。 如需詳細資訊，請參閱 駕駛簡單性 的安全性原則。

神秘？

將單一 Microsoft Entra 目錄標準化通常是跨小組的工作。 工作是由 安全性架構 或 身分識別和金鑰管理 小組所驅動。

  • 贊助 ： 身分識別與 金鑰管理和 安全性架構 通常會贊助這項工作，不過某些組織可能需要 CISO 或 CIO 的贊助。
  • 執行：執行 是一項共同作業，涉及：
    • 安全性架構 ：此小組會將程式納入安全性和 IT 架構檔和圖表。
    • 原則和標準 ：此小組會記錄原則和監視合規性。
    • 身分識別和金鑰管理 或 中央 IT 作業 ：這些小組藉由啟用功能並支援具有帳戶、教育等的開發人員，來實作原則。
    • 應用程式開發人員 或 中央 IT 作業 ：這些小組會在應用程式和 Azure 服務組態中使用身分識別。 責任會根據 DevOps 採用層級而有所不同。

怎麼做？

採用務實的方法，從新的綠地功能開始。 然後，清除現有應用程式和服務的棕色地帶的挑戰，作為後續練習：

  • Greenfield ：建立並實作清楚的原則，讓所有企業身分識別都可以針對每個使用者使用單一 Microsoft Entra 目錄與單一帳戶。

  • Brownfield ：許多組織通常有多個舊版目錄和身分識別系統。 當持續管理摩擦的成本超過清理成本時，解決這些舊版專案。 雖然身分識別管理和同步處理解決方案可以減輕這些問題的一些問題，但它們缺乏安全性和生產力功能的深度整合。 這些功能可讓使用者、系統管理員和開發人員順暢地體驗。

結合身分識別使用的理想時間是當您在應用程式開發週期期間：

  • 將雲端的應用程式現代化。
  • 使用 DevOps 程式更新雲端應用程式。

雖然獨立業務單位或法規需求有個別目錄的有效理由，但在所有其他情況下，請避免多個目錄。

如需詳細資訊，請參閱 Azure 安全性效能評定 Microsoft Entra 中央身分識別和驗證系統 。

重要

單一帳戶規則的唯一例外是，相較于系統管理工作，特殊許可權使用者，包括 IT 系統管理員和安全性分析師，可以有個別帳戶來執行標準使用者工作。

如需詳細資訊，請參閱 Azure 安全性效能評定 特殊許可權存取 。

10.架構：使用身分識別型存取控制，而不是金鑰

什麼

盡可能使用 Microsoft Entra 身分識別，而不是金鑰型驗證。 例如，Azure 服務、應用程式、API。

為何會這樣？

金鑰型驗證可用來向雲端服務和 API 進行驗證。 但它需要安全地管理金鑰，這很難順利執行，特別是在大規模。 對於開發人員和基礎結構專業人員等非安全性專業人員來說，安全金鑰管理很困難，而且它們通常無法安全地執行，通常為組織造成重大安全性風險。

身分識別型驗證可克服許多具有成熟功能的挑戰。 這些功能包括秘密輪替、生命週期管理、系統管理委派等等。

神秘？

身分識別型存取控制實作通常是跨小組的工作。 工作是由 安全性架構 或 身分識別和金鑰管理 小組所驅動。

怎麼做？

設定使用身分識別型驗證的組織喜好設定和習慣，需要遵循程式並啟用技術。

程式

  1. 建立明確概述預設身分識別型驗證的原則和標準，以及可接受的例外狀況。
  2. 教育開發人員和基礎結構小組為何要使用新方法、需要做什麼，以及如何執行。
  3. 從現在和未來採用新的綠地功能開始，例如新的 Azure 服務和新的應用程式，然後遵循現有棕色地帶組態的清理，以務實的方式實作變更。
  4. 監視合規性，並追蹤開發人員和基礎結構小組以補救。

技術

對於非人為帳戶，例如服務或自動化，請使用 受控識別 。 Azure 受控識別可以向支援 Microsoft Entra 驗證的 Azure 服務和資源進行驗證。 驗證是透過預先定義的存取授與規則來啟用，避免原始程式碼或組態檔中的硬式編碼認證。

對於不支援受控識別的服務，請改用 Microsoft Entra ID 來建立 具有資源層級限制許可權的服務主體 。 您應該使用憑證認證來設定服務主體，並後援用戶端密碼。 在這兩種情況下， Azure 金鑰保存庫 可以搭配 Azure 受控識別使用，讓執行時間環境，例如 Azure 函式，可以從金鑰保存庫擷取認證。

如需詳細資訊，請參閱 Azure 安全性效能評定 應用程式身分識別 。

11.架構：建立單一統一安全性策略

每個人都需要向同一方向划船前進。

什麼

請確定所有小組都符合允許和保護企業系統與資料的單一策略。

為何會這樣？

當團隊孤立地工作而不配合共同策略時，他們的個別行動可能會無意中削弱彼此的努力。 不對齊可能會造成不必要的摩擦，以減緩對每個人目標的進度。

在許多組織中一致運作的小組，其中一個以隔離方式運作的小組範例是資產分割：

  • 網路安全性 ：開發分割一般網路的策略。 此策略會根據實體網站、指派的 IP 位址/範圍或類似專案，提高安全性。
  • 身分識別小組 ：根據群組和 Active Directory 組織單位（OU）對組織的瞭解和知識，開發策略。
  • 應用程式小組 ：發現很難使用這些系統。 這很困難，因為它們的設計方式有限，而且對商務營運、目標和風險有有限的投入和瞭解。

在發生這項限制的組織中，小組經常遇到防火牆例外狀況的衝突。 衝突可能會對安全性造成負面影響，因為小組核准例外狀況。 生產力會對安全性造成負面影響，因為應用程式功能的部署速度變慢，因為業務需求。

雖然安全性可以藉由強制批評思維來造成健康的摩擦，但這種衝突只會造成阻礙目標的不健康摩擦。 如需詳細資訊，請參閱 安全性策略指引 。

神秘？

  • 贊助 ：統一策略通常是由 CIO、CISO 和 CTO 共同承擔。 贊助通常隨附對一些高層級元素的商業領導支援，並由每個團隊的代表支援。
  • 執行 ：安全性策略必須由所有人實作。 它會整合來自各種小組的資料，以增加擁有權、購買和成功的可能性。
    • 安全性架構 ：此小組會引導建立安全性策略和產生的架構。 安全性架構會主動收集小組的意見反應，並將意見反應記錄在各種物件的簡報、檔和圖表中。
    • 原則和標準 ：此小組會將適當的元素擷取至標準和原則，然後監視合規性。
    • 所有技術 IT 和安全性小組 ：這些小組提供輸入需求，然後配合並實作企業策略。
    • 應用程式擁有者和開發人員 ：這些小組會閱讀並瞭解適用于他們的策略檔。 在理想情況下，他們會針對其角色量身打造指引。

怎麼做？

建置並實作雲端的安全性策略，其中包含所有小組的意見提供和積極參與。 儘管流程文件格式可能會有所不同，但一律會包含：

  • 小組的主動意見回饋：如果組織中的人員不認同策略，則策略通常會失敗。 在理想的情況下，將所有小組聚集在相同的空間以共同建立策略。 在我們與客戶合辦的研討會中，我們通常會發現組織過去都在實際上的孤島中運作，而這些會議通常會讓人們第一次與對方見面。 我們發現包容性是一項需求。 如果有些小組並未受邀，則此會議通常必須重複，直到所有參與者都加入會議為止。 如果他們未加入，專案就不會繼續進行。
  • 記載並清楚傳達：所有小組都必須意識到安全性策略。 在理想的情況下，安全性策略是整體技術策略的安全性元件。 這項策略包括整合安全性的原因、安全性的重要之處，以及安全性成功時的狀態。 此策略包含適用於應用程式和開發小組的特定指導方針，以便他們可以取得明確且井然有序的指引，而不需要閱讀無關的資訊。
  • 穩定但有彈性：讓策略保持相對一致且穩定，但架構和文件內容需要明確，並適用於雲端的動態本質。 例如，即使您從使用協力廠商新一代防火牆轉移至 Azure 防火牆，並調整執行方法的圖表和指導，篩除惡意的外部流量仍是一項戰略要務。
  • 從分割 開始：有大而小的策略問題需要解決，但您需要從某個位置開始。 使用企業資產分割啟動安全性策略。 此分割是一項基礎決策，在稍後進行變更時將面臨挑戰，而且需要業務投入和許多技術小組。

Microsoft 已發佈將分割策略套用 至 Azure 的影片指引。 有關于 企業分割 並 使其符合網路安全性 的檔。

雲端採用架構包含可協助小組的指引：

如需詳細資訊，請參閱 Azure 安全性效能評定 治理策略 。