雲端安全防護深入解析ISO27017與27018標準

在雲端技術日新月異的時代，確保資料安全和隱私已成為企業最重要的課題。本文不僅深入剖析 ISO 27017 和 ISO 27018 兩大雲端安全標準，更涵蓋 NIST 風險管理框架、零信任架構、雲端原生應用程式安全以及混合雲架構等關鍵領域，提供多層次的防護策略。從實務角度出發，探討如何在不同雲端環境中實施最佳安全措施，並以圖表和程式碼範例輔助說明，幫助讀者建立更完善的雲端安全防禦體系。

雲端安全防護：深入解析 ISO 27017 與 ISO 27018

在建構組織資訊安全基礎架構時，ISO 27001 是不可或缺的根本。ISO 27002 提供實施 ISO 27001 的實用工具，或協助組織建立自身的資訊安全管理準則和控制措施。本文將探討另外兩個重要的 ISO 標準：ISO 27017 和 ISO 27018，它們能有效協助降低雲端攻擊風險。

雲端服務安全指引：ISO 27017 解析

選擇安全的雲端服務在現代複雜的環境中是一項艱鉅的任務。ISO 27017 正是為解決這個難題而生。作為資訊技術標準的一部分，ISO 27017 根據 ISO 27002，著重於雲端服務的資訊安全控制實務守則和安全技術。它提供適用於雲端服務供應和使用的資訊安全控制準則。如果目前遵循 ISO 27002，它將提供額外的實施指導；同時，它也包含專門針對雲端服務的額外控制措施。

ISO 27017 的主要內容

ISO 27017 涵蓋 ISO 27002 中指定控制的額外實施，以及幾個與雲端服務相關的額外控制。這些控制解決以下問題：

雲端服務供應商和雲端客戶之間的責任劃分
合約終止時的資產移除或歸還
客戶虛擬環境的保護和隔離
虛擬機器組態
與雲端環境相關的管理操作和程式
雲端客戶的活動監控
虛擬和雲端網路環境的一致性

ISO 27017 的結構

ISO 27017 標準包含18個部分和一個專用的附件部分。這18個部分涵蓋範圍、規範性參考、定義和縮寫、雲端特定概念、資訊安全策略、資訊安全組織、人力資源安全、資產管理、存取控制、加密技術、實體和環境安全、操作安全、通訊安全、系統採購、開發和維護、供應商關係、資訊安全事件管理、業務連續性管理的資訊安全方面以及合規性。

附件 A 的重要性

附件 A 是標準建議的組成部分，涵蓋雲端服務客戶和雲端服務供應商之間的關係，以及雲端運算環境中的分享角色和責任。定義角色有助於消除混淆，並確定責任人和問責人。附件 A 還討論了資產責任和雲端服務客戶資產的移除。另一個關鍵領域是分享虛擬環境中雲端服務客戶資料的存取控制，討論了虛擬雲端運算中的隔離和虛擬機器強化。確保虛擬例項安全和客戶資料受到保護是阻止威脅行為者利用弱安全強化實務來入侵系統的關鍵。

保護個人識別資訊：ISO 27018 深度剖析

與 ISO 27017 相類別似，ISO 27018 也是資訊技術標準的一部分，重點關注與保護公有雲中個人識別資訊 (PII) 的實務守則相關的安全技術。該標準根據 ISO/IEC 29100 中的隱私原則，為公有雲運算環境中實施保護 PII 的措施建立了普遍接受的控制目標、控制和準則。

ISO 27018 的適用範圍

ISO 27018 適用於所有型別和規模的組織，包括公共和私營公司、政府機構和非營利組織，它們透過雲端運算根據合約向其他組織提供資訊處理服務，並充當 PII 處理器。ISO 27018 標準中概述的要求也可能與充當 PII 控制器的組織相關。然而，PII 控制器可能會受到額外的 PII 保護立法、法規和義務的約束，這不適用於 PII 處理器。

ISO 27018 的核心目標

本標準旨在建立一組通用的安全類別和控制措施，可由充當 PII 處理器的公有雲運算服務供應商實施，具有以下目標：

協助公有雲端服務供應商在充當 PII 處理器時遵守適用的義務，無論這些義務是否落在 PII 處理器身上。

圖表解析與技術深度探討

圖表翻譯：

此圖表展示了 ISO 27017 和 ISO 27018 如何協助雲端服務客戶提升資料安全性和隱私保護。ISO 27017 提供安全控制措施，而 ISO 27018 則專注於個人識別資訊 (PII) 的保護。

圖表翻譯：

此時序圖說明瞭雲端服務供應商如何應用 ISO 27017 控制措施來確保提供給客戶的雲端服務安全性。首先，客戶向供應商請求雲端服務；接著，供應商在其內部系統中應用 ISO 27017 控制措施，以確保符合相關的安全標準；最後，供應商向客戶提供符合安全標準的雲端服務。

NIST 風險管理框架與事件回應

NIST 風險管理框架簡介

美國國家標準與技術研究院（NIST）提供了一系列風險管理框架與事件回應，用於協助組織提升其網路安全性。這些不僅適用於美國聯邦政府機構，也被廣泛採用於民營企業和其他組織。

NIST SP 800-53：資訊系統和組織的安全與隱私控制

NIST SP 800-53 為希望改善風險管理的組織建立了全面的安全和隱私控制措施。它最初是為聯邦資訊系統和為聯邦政府提供服務的組織而開發，但其建議已成為幾乎所有本地或雲端運作組織的最佳實務。

NIST SP 800-53 的主要特點

NIST SP 800-53 將資產分為三個根據風險的類別：低影響、中等影響和高影響。它還引入了安全控制基準線的概念，作為這些類別下安全控制選擇過程的起點。這有助於確定優先順序，並提供與 CIS 控制類別似範例和預期基準線。

NIST SP 800-53 中描述的安全控制分為18個系列，每個系列都包含與特定主題和治理領域相關的安全控制。這些控制可能涉及與該系列相關的政策、監督、人工流程、身份操作或人機自動化等方面。

圖表翻譯：

此圖表說明瞭 NIST SP 800-53 如何根據風險級別對系統進行分類別。這種分類別有助於組織根據風險等級實施適當的安全控制，從而更有效地管理網路風險。

NIST SP 800-61：電腦安全事件處理

NIST SP 800-61 提供了一個全面的事件回應框架，用於幫助組織有效管理電腦安全事件。它定義了事件應變生命週期的四個階段：準備、檢測與分析、遏制、清除與復原。

事件應變生命週期的四個階段

準備：建立事件回應團隊，制定事件回應計畫，並進行相關培訓。
檢測與分析：監控系統和網路，以檢測潛在的安全事件，並對檢測到的事件進行深入分析。
遏制：採取措施遏制安全事件，防止其進一步擴散。
清除與復原：清除安全事件的根源，並將系統還原到正常運作狀態。

圖表翻譯：

這個流程圖展示了 NIST SP 800-61 中定義的事件應變生命週期的四個階段。每個階段都扮演著關鍵角色，確保組織能夠有效地應對安全事件，將損失降至最低。

零信任架構：重新定義網路安全邊界

零信任安全模型提倡建立區域和分段，以控制敏感的 IT 資源。這也需要佈署技術來監控和管理區域之間的資料，更重要的是，在區域內進行身份驗證，同時監控行為。這涵蓋了使用者、應用程式和其他非人類的身份驗證請求。此外，零信任模型重新定義了邏輯和軟體定義邊界內受信任網路的架構。這可以是本地佈署或在雲端中。只有受信任的資源才應該在該結構內根據動態身份驗證模型進行互動。

隨著雲端、虛擬化、DevOps、邊緣運算、邊緣安全、個人化和 OT/IoT 等技術和流程的發展，傳統防火牆和網路分割槽邊界的概念已經模糊或消失，零信任變得越來越重要。

雖然零信任已成為 IT 領域的流行語，但重要的是要指出，在實踐中，這個模型對於事物應該如何設計和操作非常具體。零信任可能並不適用於所有環境。在實踐中，它最適合新的或更新的佈署，或者嚴格控制使用者對敏感資源的存取，尤其是在他們遠端連線時。為此，NIST 800-207 中有四種架構有助於定義你的環境是否可以滿足零信任的嚴格要求：

根據裝置代理/閘道的佈署：對資料的存取隔離由透過已建立的網路路徑和閘道的代理通訊嚴格控制。
根據飛地的佈署：對安全資源的存取包含在已建立的邊界內（稱為資源飛地），並且使用代理和閘道技術控制對飛地的存取。
根據資源入口網站的佈署：一個安全的入口網站（可能是根據 Web 或應用程式的）根據策略代理所有通訊，並監控所有存取的適當行為。
裝置應用程式沙盒：應用程式本身在沙盒中執行，因此所有活動都可以被監控並免受外部威脅。

目前，沒有證書可以證明你的應用程式和資產符合零信任標準。儘管美國總統發布了行政命令來推廣零信任，但任何實施都只是一種架構和觀點，至於它們是否符合 NIST 800-207 中提出的目標或理論設計。然而，目前正在針對 NIST 1800-35a 進行工作，以定義零信任架構，但在撰寫本文時，它仍處於非常早期的階段。

與 CIS 和 FedRAMP 類別似，我們預計最終會有一個正式的應用程式和架構證書，以證明它們符合零信任的基本要求。目前，我們只是處於定義的早期階段以及供應商市場的炒作階段。

內容解密：

上述流程圖展示了組織如何透過評估事件回應能力，進而改進事件處理流程，最終強化安全防禦並降低事件發生機率。這是一個持續改進的迴圈，組織需要不斷評估和調整其事件回應策略，以應對不斷變化的威脅環境。

內容解密：

這個流程圖闡述了零信任模型的核心概念，包含區域分段、存取控制、持續監控以及動態身份驗證，確保只有受信任的資源才能互動，提升整體安全性。

內容解密：

這個狀態圖描述了零信任環境下的資源存取流程。使用者首先申請存取，系統驗證其身份，若驗證成功則進行授權。只有在身份驗證和授權都成功的情況下，使用者才能存取資源。任何一步失敗都會導致存取被拒絕。

解密零信任架構：強化雲端安全的現代策略

在雲端時代，傳統的網路安全邊界逐漸模糊，企業面臨的攻擊面也日益擴大。過去以網路邊界為中心的防禦策略已不足以應對新的安全挑戰，因此，零信任架構應運而生。它並非單一產品，而是一種全新的安全思維，將安全防護的重心從網路邊界轉移到使用者、資產和資源上。

玄貓認為零信任的核心就在於「永不信任，持續驗證」。它假設任何使用者、裝置或應用程式，無論其位置或身份，都不應被自動信任。每一次存取都需要經過身份驗證和授權，確保只有經過授權的使用者才能存取特定的資源。

零信任的核心概念與原則

根據 NIST SP 800-207 的定義，零信任架構的核心概念如下：

永不信任，持續驗證： 所有存取請求，無論來自內部網路還是外部網路，都必須經過驗證和授權。
最小許可權存取： 使用者和應用程式只能存取完成其任務所需的最小資源集合，限制攻擊者橫向移動的可能性。
微分段： 將網路劃分為更小的隔離區域，限制單一入侵事件的影響範圍。
持續監控： 持續監控使用者行為、系統日誌和網路流量，及時發現異常活動。

內容解密：

上圖展示了零信任架構下的存取流程。使用者發起請求後，首先需要透過身份驗證，確認其身份。接著，系統會根據預先定義的策略進行授權，判斷使用者是否有許可權存取請求的資源。只有透過驗證和授權後，使用者才能存取資源。同時，系統會持續監控整個存取過程，及時發現異常行為。

零信任架構的優勢

增強安全性： 透過持續驗證和最小許可權存取，有效降低資料洩露和系統入侵的風險。
提升靈活性： 支援遠端工作、BYOD 等現代工作模式，提供更靈活的存取方式。
簡化管理： 集中化的策略管理和存取控制，簡化安全管理的複雜性。

零信任時代的企業科技管理：開發現代化共同辦公環境

在數位轉型浪潮和混合辦公模式盛行的今日，企業的共同辦公環境 (COE) 已不再侷限於傳統辦公室。從辦公桌、印表機到電腦和軟體，COE 的定義已延伸至任何員工執行業務的地點，包含家庭網路甚至公共 Wi-Fi。這對企業科技管理，尤其是安全性，帶來了前所未有的挑戰。

傳統以防火牆、入侵偵測和網路分段為主的安全措施，已不足以應付當前分散式辦公的環境。零信任架構 (ZTA) 的出現，為解決這個問題提供了新的方向。根據 NIST 的定義，ZTA 是一種根據零信任原則的企業網路安全架構，旨在防止資料洩露並限制內部橫向移動。

零信任的七大核心原則

NIST SP 800-207 檔案詳細闡述了 ZTA 的邏輯元件、佈署場景和威脅，並提供遷移至零信任方法的路線圖。成功的零信任實施根據以下七大核心原則：

所有資料來源和運算服務都被視為資產。
所有通訊都必須加密，無論網路位置。
對個別企業資源的存取許可權根據每個工作階段授予。
資源存取由動態策略決定，包括使用者身份、應用程式/服務和請求資產的可觀察狀態，以及其他行為和環境屬性。
企業監控所有自有和關聯資產的完整性和安全狀態。
所有資源的驗證和授權都是動態的，並在允許存取之前嚴格執行。
企業收集盡可能多的資訊，包含資產、網路基礎設施和通訊的當前狀態，並用於改進其安全狀態。

內容解密：

此流程圖展示了零信任的七大核心原則，每個原則都指向一個關鍵行動或狀態。例如，所有資料來源和運算服務都被視為資產，所有通訊都必須加密，資源存取根據每個工作階段授予，等等。這張圖表簡潔地概括了零信任的核心思想。

雲端原生架構的安全性：開發真正安全的雲端應用

在遷移至雲端的過程中，許多企業選擇了「直接遷移」的方式，將現有的本地解決方案原封不動地搬到雲端。這種做法通常被稱為「雲端清洗」，雖然看似便捷，卻未能充分利用雲端架構、服務和資源的優勢，更遑論針對根據使用量的成本模型進行最佳化。玄貓曾在多個專案中觀察到，雲端清洗的佈署方案往往面臨擴充套件性、安全性和容錯性等問題，因為雲端環境缺乏本地佈署中的一些關鍵元件。

為瞭解決這些問題，一些企業選擇從頭開始重寫應用程式，或開發專為雲端設計的雲端原生技術。雲端原生運算是一種軟體架構和開發方法，它利用雲端的獨特特性和服務，在現代動態環境（例如公有雲和私有雲）中開發、佈署和執行可擴充套件的應用程式。這種方法利用了許多概念，例如容器、微服務、無伺服器函式和不可變基礎架構。這些技術支援鬆散耦合的系統，使其具有彈性、可管理性和可辨識性。與自動化和 DevOps 相結合，雲端原生技術允許開發人員使用敏捷和 Scrum 等開發理念，頻繁與可預測地進行高影響力的變更，而不是像瀑布式開發那樣採用傳統方法。

雲端原生技術的價值

雲端原生技術作為一種攻擊向量緩解策略，其價值體現在以下幾個方面。如果將本地技術遷移到雲端，您將面臨哪些安全挑戰？您可能會在網際網路上暴露哪些先前在本地防火牆、存取控制清單和入侵偵測系統保護下的資源？通常，這些問題的答案是企業無法接受的。

考慮到一些傳統應用程式可能包含生命週期結束的元件，或者需要嚴格的變更控制計劃，僅僅應用安全更新就需要停機。當企業開始稽核這些風險時，根據這些挑戰的數量和嚴重性，「重做」應用程式成為更可行的結論。最大的缺點是上市時間和開發成本，但如果現有技術無法實作目標，這些成本是可以抵消的。

遷移到雲端原生架構的考量

從頭開始或開發全新的雲端原生解決方案，即使您將它們自行託管在私有雲或混合雲中，也有助於確保它們更好地適應未來。這有點像購買電動汽車與購買耗油量大的汽油車，後者在設計、功能甚至效能方面都沒有優勢。因此，請評估以下行動專案，以確定是否要將應用程式構建或重建為雲端原生應用程式，而不是簡單地對當前解決方案進行雲端清洗：

如果應用程式的使用者群有限，工作流程非常可預測與風險面最小，則雲端清洗通常是可以接受的。
如果應用程式遷移到雲端後無法擴充套件以滿足業務需求，請考慮重寫部分（混合）或全部應用程式以使其成為雲端原生應用程式。
確定由於維護或安全更新，解決方案在給定時間段內可接受的停機時間。如果最終使用者社群無法接受停機時間，請考慮將其全部或部分遷移到雲端原生架構和程式碼函式庫。
高用性、可擴充套件性和災難復原的關鍵任務功能在本地和雲端中的架構不同。如果您對應用程式進行雲端清洗，您能否像以前一樣為所有這些專案維持相同的服務級別協定？如果不能，則可能需要採用雲端原生方法。
如果您的應用程式先前已使用一組可定義的容器或虛擬機器進行虛擬化，則雲端清洗作為簡單的直接遷移是可以接受的。
考慮雲端清洗解決方案與現代化相同應用程式的執行時成本。在許多情況下，開發成本可以透過每月支付給雲端服務供應商的執行時成本文省來抵消。
雲端原生化最困難的決策之一是選擇未來將支援的技術堆積疊，最重要的是，您的組織可以找到開發人員來支援該平台。僅僅因為某項雲端技術是「最好的」就選擇它並不一定總是最佳的，如果尋找資源來維護和開發它的成本高於使用主流解決方案。因此，請衡量技術的使用情況及其路線圖，以免被鎖定在最終無法支援的雲端原生解決方案中。
雲端原生解決方案的雲端攻擊向量與雲端清洗解決方案不同。確保已實施安全基礎知識（身份、漏洞、修補程式和特權存取管理）以處理雲端原生技術。如果忽視了適當的投資，這是直接遷移可能會留下重大差距的一個領域。
考慮使用現代方法進行開發和測試，並使用敏捷、群體智慧、混沌工程、人工智慧等，以確保您的雲端原生解決方案具有最佳的安全性與彈性。

混合雲架構：兼顧安全與靈活性

關於為什麼混合雲架構是緩解雲端攻擊向量的良好設計，公開討論很少。在探討之前，瞭解混合雲實施的含義非常重要。首先，它不應與多雲混淆。多雲架構利用多個雲端服務供應商來提供解決方案。混合雲架構可以是多雲的，但它們在傳統資料中心或共置設施中具有位於本地的不同元件。將元件保留在本地的原因包括但不限於：

在明確監控和控制的特定資料存放區或資料函式庫中保護敏感或個人身份資訊。
支援不易或不經濟高效地遷移到雲端或虛擬化的傳統元件。
架構元件的安全控制需要雲端中不可用的特殊考慮因素，包括物理存取。
支援本地和雲端的可用性，而無需依賴網際網路進行本地存取。
根據使用量計費模型，使用過多頻寬的元件遷移到雲端的成本過高。

圖表翻譯：

此圖展示了混合雲架構中本地環境和雲端環境之間的連線關係，以及如何透過防火牆和 CASB 等安全元件保護敏感資料和控制存取。

零信任架構下的混合雲佈署

在零信任架構下，混合雲佈署需要確保所有元件，無論是在本地還是在雲端，都必須經過嚴格的驗證和授權。這包括使用多因素身份驗證、持續監控和即時威脅偵測等技術手段來加強安全性。

零信任架構的安全優勢

零信任架構透過假設所有使用者和裝置都是潛在威脅，從而提供了一種更為嚴謹的安全防護策略。這種方法要求對所有存取請求進行嚴格驗證，無論請求來源於何處，從而有效地降低了內部威脅和外部攻擊的風險。

零信任架構的安全邏輯組成

零信任架構由幾個核心邏輯組成部分構成，包括策略引擎（PE）、策略管理員（PA）和策略執行點（PEP）。這些元件協同工作，確保只有經過授權的使用者和裝置才能存取受保護的資源。

策略引擎（PE）的作用

策略引擎是零信任架構的核心元件，負責根據預定義的安全策略做出存取控制決策。它會綜合考慮各種因素，如使用者身份、裝置狀態、網路環境等，以確定是否允許存取特定資源。

策略管理員（PA）的功能

策略管理員負責管理和維護零信任架構中的安全策略。它確保所有策略的一致性和有效性，並根據需要進行更新和調整，以適應不斷變化的安全威脅和業務需求。

策略執行點（PEP）的實作

策略執行點是零信任架構中用於執行存取控制決策的元件。它根據策略引擎的決策結果，允許或拒絕對受保護資源的存取請求，從而確保只有授權使用者和裝置能夠存取敏感資訊。

零信任架構下的安全挑戰與對策

儘管零信任架構提供了更高的安全性，但其實施也面臨著諸多挑戰，如複雜性增加、管理難度加大等。為了應對這些挑戰，企業需要採取有效的對策，如簡化零信任架構的實施流程、加強人員培訓等。

面臨的挑戰

複雜性增加：零信任架構需要對現有的 IT 環境進行全面改造，包括網路架構、身份驗證機制、安全策略等，這無疑增加了實施的複雜性。
管理難度加大：由於零信任架構涉及到更多的元件和策略，因此其管理和維護工作也變得更加困難。
成本問題：實施零信任架構需要投入大量的資金用於硬體裝置、軟體系統以及人員培訓等方面，這對於一些中小企業來說可能是一個不小的負擔。

對策建議

逐步實施：企業可以採用逐步實施的方式，先從關鍵領域開始，逐步擴充套件到其他區域，以降低一次性投入的成本和風險。
選擇合適的解決方案：市場上有許多成熟的零信任解決方案，企業可以根據自身需求選擇合適的產品或服務，以簡化實施過程。
加強人員培訓：透過對員工進行相關培訓，提高他們對零信任架構的理解和操作能力，從而更好地發揮其安全效益。

總之，零信任架構是一種有效的網路安全防護策略，能夠顯著提升企業的安全水平。然而，其實施也面臨著諸多挑戰。企業需要根據自身情況，制定合理的實施計劃，並採取有效的對策，以確保零信任架構能夠發揮出最大的安全效益。

混合架構下的安全設計原則

混合架構結合了本地佈署和雲端環境的優勢，在安全性方面提供了顯著的優勢。以下是一些關鍵的安全設計原則：

資料對映與地理位置控制

混合架構能確保敏感資料儲存在已知的電子和物理位置，滿足法規遵循要求。同時，透過地理位置控制，可以精確識別關鍵資訊的地理位置，包括備份資料。

資料加密與資料遺失防護

敏感資料和系統由組織直接控制，而非雲端服務供應商，能更好地執行加密和資料遺失防護策略。只有授權的請求和資料才能從本地環境傳輸到雲端應用程式。

授權存取控制與物理安全控制

混合架構透過授權存取控制清單實施嚴格的存取控制。同時，儲存敏感資訊的資產的物理安全仍由組織控制，而非雲端服務供應商。

臨時性實作：降低風險

臨時性實作是一種有效的安全策略，透過使風險表面臨時化來降低攻擊風險。這包括根據時間限制存取、動態組態等技術手段，以減少靜態秘密所帶來的風險。

即時日誌記錄與監控

對於變化很快的臨時屬性，應考慮使用即時日誌記錄和監控來記錄所有變化，並確定它們是否合適。這有助於及時發現潛在的安全威脅，並採取相應措施進行處置。

秘密管理：保護敏感資訊

秘密管理是保護敏感資訊的重要手段。透過使用特權存取管理（PAM）解決方案，可以實作秘密的頻繁更改、動態金鑰管理等，從而降低秘密被濫用的風險。

PAM 解決方案的功能

頻繁更改秘密：PAM 解決方案能夠自動更改秘密
根據時間存取控制：只有在符合特定時間條件時，才允許特權使用者存取秘密
使用後隨機化：每次使用後，秘密都會被隨機化，以限制其暴露時間
歷史記錄管理：PAM 解決方案會維護秘密的使用歷史記錄，以便在需要時進行稽核和還原

賬戶管理：Just-in-Time 存取

Just-in-Time（JIT）賬戶管理是一種透過臨時建立或啟用賬戶來降低安全風險的方法。這種方法可以減少靜態賬戶所帶來的風險，並提高賬戶管理的靈活性。

JIT 賬戶管理的實作方式

按需建立賬戶：只有在需要時才建立賬戶，使用完畢後立即刪除
動態啟用/停用賬戶：賬戶存在但預設為停用狀態，只有在需要時才啟用，使用完畢後立即停用
動態調整賬戶許可權：根據需要動態調整賬戶所屬群組或許可權，以實作精細化的存取控制

執行個體管理：動態更新與重建

執行個體管理是確保系統安全性的重要環節。透過頻繁更新和快速重建執行個體，可以及時修補漏洞、清除潛在的安全威脅，從而提高系統的安全性。

執行個體管理的最佳實踐

頻繁更新執行個體：定期對執行個體進行更新和修補，以確保其始終處於最新的安全狀態
快速重建執行個體：當發現執行個體存在安全問題時，能夠快速重建執行個體，以最小化安全事件的影響

許可權管理：最小許可權原則

許可權管理是確保系統安全性的關鍵。透過實施最小許可權原則，可以減少過度授權所帶來的風險。

JIT 許可權提升

JIT 許可權提升是一種按需提升許可權的方法，只有在需要時才賦予使用者必要的許可權，使用完畢後立即復原。這種方法可以減少靜態高許可權賬戶所帶來的風險。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端安全防護深入解析ISO27017與27018標準

package "安全架構" {
    package "網路安全" {
        component [防火牆] as firewall
        component [WAF] as waf
        component [DDoS 防護] as ddos
    }

    package "身份認證" {
        component [OAuth 2.0] as oauth
        component [JWT Token] as jwt
        component [MFA] as mfa
    }

    package "資料安全" {
        component [加密傳輸 TLS] as tls
        component [資料加密] as encrypt
        component [金鑰管理] as kms
    }

    package "監控審計" {
        component [日誌收集] as log
        component [威脅偵測] as threat
        component [合規審計] as audit
    }
}

firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成

@enduml

圖表翻譯：

上圖展示了混合架構下多種安全管理措施之間的關係，包括資料對映、臨時性實作、秘密管理、帳戶管理、執行個體管理和許可權管理等。這些措施共同構成了一個全面的安全管理體系，有效地降低了系統的安全風險。

雲端環境安全設計策略

在現代雲端運算環境中，安全設計是保護組織寶貴資料和系統的關鍵。為了實作這一目標，必須實施有效的安全策略，以降低潛在風險並確保雲端環境的完整性。

最小許可權原則的應用

實施最小許可權原則是確保雲端環境安全的基本策略。這涉及為使用者和應用程式分配最低限度的許可權，以完成其任務。透過限制對敏感資源的存取，可以顯著降低因許可權過大而導致的安全風險。

具體實施方法

使用低許可權執行所需任務：在設計雲端應用程式時，應優先使用低許可權來執行必要的任務。這可以透過仔細規劃和分配角色來實作。
根據策略使用 RunAs、Sudo 或供應商專有技術提升應用程式：當某些任務需要更高的許可權時，可以利用 RunAs、Sudo 或供應商提供的專有技術來臨時提升應用程式的許可權。這種方法確保了在需要時提供必要的許可權，同時避免了長期持有高許可權所帶來的風險。

程式碼範例

import subprocess

def run_command_with_sudo(command):
    try:
        # 使用 Sudo 執行命令
        subprocess.run(['sudo', command], check=True)
    except subprocess.CalledProcessError as e:
        print(f"執行命令失敗：{e}")

# 使用範例
run_command_with_sudo("apt update")

內容解密：

上述 Python 程式碼範例展示瞭如何使用 subprocess 模組以 Sudo 許可權執行系統命令。首先，定義了一個 run_command_with_sudo 函式，該函式接受一個命令字串作為引數。然後，使用 subprocess.run 方法執行帶有 sudo 字首的命令，並設定 check=True 以確保命令執行失敗時能夠丟擲例外。最後，捕捉並處理可能的 CalledProcessError 例外，以輸出錯誤訊息。

動態許可權管理

另一個重要的安全設計策略是動態管理應用程式的許可權。這可以透過在執行前修改應用程式以包含一次性特權權杖來實作。這種方法通常與許可權存取管理供應商的專利技術相關聯，能夠在核心層將應用程式提升到更高的許可權。

整合式許可權管理

透過將許可權管理整合到應用程式中，可以根據帳戶和指定任務的需要動態新增和移除許可權。這種靈活的方法確保了應用程式僅在需要時擁有必要的許可權，從而進一步降低了安全風險。

安全設計策略的效益

透過實施上述安全設計策略，組織可以構建更安全的雲端環境，有效降低風險並保護其寶貴的資料和系統。這些策略不僅增強了雲端環境的安全態勢，也為組織提供了更可靠的運作基礎。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。