雲端安全防護實踐

隨著雲端服務的普及，企業資料安全面臨新的挑戰。本文提供一套全面的雲端安全防護策略，涵蓋資料、資產和身份保護等關鍵導向。從基本原則出發，探討最小許可權原則、縱深防禦策略以及風險管理流程，並深入研究資料加密技術與雲端資產標記的實務應用，同時也涵蓋身份和存取管理、多因素身份驗證、弱點管理、網路分段和防火牆等重要議題，協助企業建立完善的雲端安全防禦體系。

雲端安全防護的實踐

雲端運算的普及使得企業和組織越來越依賴雲端服務來儲存和處理敏感資料。然而，這也帶來了新的安全挑戰。雲端安全防護需要一套全面的策略來保護資料、資產和身份。

雲端安全的基本原則

雲端安全防護的第一步是瞭解其基本原則。這些原則包括最小許可權原則（Least Privilege）、縱深防禦（Defense in Depth）和風險管理（Risk Management）。最小許可權原則要求使用者和系統只擁有完成其任務所需的最低許可權。縱深防禦則是指透過多層次的安全措施來保護系統和資料。

風險管理的重要性

風險管理是雲端安全防護的核心。它涉及識別、評估和緩解潛在的安全風險。企業需要制定一套完善的風險管理流程，以確保能夠及時發現和回應安全威脅。

資料資產管理和保護

資料是企業最寶貴的資產之一。在雲端環境中，資料的安全保護至關重要。資料資產管理包括資料識別和分類別（Data Identification and Classification）、資料標記（Tagging Cloud Resources）和資料加密（Encryption）。

資料加密技術

資料加密是保護資料安全的關鍵技術。透過使用加密技術，可以確保即使資料被未經授權的第三方存取，也無法被讀取或利用。目前常見的加密技術包括對稱加密（Symmetric Encryption）和非對稱加密（Asymmetric Encryption）。

# 使用Python進行對稱加密的範例
from cryptography.fernet import Fernet

# 生成金鑰
key = Fernet.generate_key()
cipher_suite = Fernet(key)

# 加密資料
cipher_text = cipher_suite.encrypt(b"A really secret message. Not for prying eyes.")

# 解密資料
plain_text = cipher_suite.decrypt(cipher_text)

print(plain_text.decode())

內容解密：

上述程式碼範例展示瞭如何使用Python的cryptography函式庫進行對稱加密。首先，我們生成一個金鑰，然後使用該金鑰建立一個Fernet物件。接著，我們使用encrypt方法加密一條訊息，並使用decrypt方法將其解密回原始文字。這種加密技術能夠有效地保護資料在傳輸和儲存過程中的安全。

雲端資產管理和保護

雲端資產管理與傳統IT資產管理有著顯著的不同。雲端資產包括計算資產（Compute Assets）、儲存資產（Storage Assets）和網路資產（Network Assets）。有效的雲端資產管理需要建立一套完善的資產管理流程（Asset Management Pipeline）。

資產標記的重要性

資產標記是雲端資產管理的一個重要方面。透過為雲端資源新增標籤，可以更好地跟蹤和管理這些資源。這有助於實作更精細的安全控制和成本最佳化。

身份和存取管理

身份和存取管理（Identity and Access Management, IAM）是雲端安全的一個關鍵組成部分。它涉及身份生命週期管理（Life Cycle for Identity and Access）、身份驗證（Authentication）和授權（Authorization）。

多因素身份驗證

多因素身份驗證（Multi-Factor Authentication, MFA）是一種增強的安全措施，要求使用者提供兩種或以上的驗證因素才能存取系統或資料。這大大提高了安全性，因為單一因素（如密碼）容易被破解或竊取。

弱點管理和網路安全

弱點管理（Vulnerability Management）和網路安全是雲端安全的兩個重要方面。弱點管理涉及識別、評估和修復系統中的安全弱點。網路安全則關注於保護網路免受未經授權的存取和攻擊。

網路分段和防火牆

網路分段（Network Segmentation）和防火牆（Firewalls）是網路安全的關鍵措施。透過將網路劃分為不同的段，可以限制攻擊者在網路內的橫向移動。同時，防火牆可以控制進出網路的流量，防止未經授權的存取。

此圖示說明瞭防火牆在網路安全中的作用

此圖示展示了一個簡單的網路架構，其中客戶端的請求首先經過防火牆。防火牆根據預定的安全規則決定是否允許或拒絕請求。這種機制有效地保護了內部網路和Web伺服器的安全。

實用雲端安全：前言與內容總覽

本文《實用雲端安全》旨在為讀者提供一個全面且實用的雲端安全解決方案。不論是雲端安全新手還是經驗豐富的專業人士，都能從本文中獲得寶貴的見解和實務建議。

本文目的與重要性

在當今數位時代，雲端運算已成為企業營運的核心組成部分。然而，隨著雲端服務的普及，安全問題也日益突出。本文的目標是幫助讀者建立一套健全的雲端安全控制措施，以保護最重要的資產。

內容結構與章節安排

本文首先介紹了雲端安全與傳統IT環境安全的主要差異，接著探討了資產盤點、威脅評估及防護措施等基礎知識。後續章節則按照優先順序，詳細闡述了最重要的安全控制措施，包括：

1. 身份與存取管理（Identity and Access Management）
2. 漏洞管理（Vulnerability Management）
3. 網路控制（Network Controls）
4. 事件偵測、回應與復原（Detecting, Responding to, and Recovering from Security Incidents）

寫作慣例與閱讀

本文採用以下排版慣例，以方便讀者理解：

• 斜體字：表示新術語、網址、電子郵件地址、檔案名稱及副檔名。
• 等寬字型：用於程式清單，以及段落中指代程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。
• 等寬粗體：表示使用者應逐字輸入的命令或其他文字。
• 等寬斜體：表示應替換為使用者提供的值或由上下文決定的值。

此外，本文還包含提示、注意事項及警告標記，以幫助讀者更好地理解內容。

聯絡資訊與資源取得

• 本文專頁：http://bit.ly/practical-cloud-security

結語

本文旨在為讀者提供一個全面且實用的雲端安全。希望讀者能夠從中獲得寶貴的知識和經驗，以應對日益複雜的雲端安全挑戰。

雲端安全原則與概念

在探討實務操作之前，我們需要先了解幾個重要的雲端安全原則。對於資深的安全專業人員來說，可以直接跳到「雲端共同責任模型」。

最小許可權原則

最小許可權原則強調人員或自動化工具僅能存取執行任務所需的資源，而不能超過這個範圍。實際應用中，這意味著預設拒絕所有存取請求，只有在經過請求和審批流程後，才授予必要的許可權。

在雲端環境中，某些管理員需要存取雲端控制檯，這是一個允許建立、修改和銷毀雲端資產（如虛擬機器）的網頁介面。許多雲端服務提供商預設賦予這些管理員極高的許可權，可能包括讀取、修改或銷毀雲端環境中的任何資料。因此，必須嚴格控制對雲端控制檯的存取許可權，並記錄這些使用者的操作行為。

多層次防禦

多層次防禦的核心思想是建立多層重疊的安全控制措施，以確保即使某一層防禦失效，其他層仍能繼續發揮作用，防止攻擊者得逞。在設計安全控制措施時，應當能夠回答：「如果這層防禦失效了會怎麼樣？」如果答案是「完全失效」，那麼就可能意味著多層次防禦不足。

圖表說明

詳細說明

此圖示展示了一個典型的三層應用程式架構：

1. 使用者透過HTTP/HTTPS與網頁伺服器互動
2. 網頁伺服器透過API呼叫與應用伺服器互動
3. 應用伺服器與資料函式庫伺服器進行資料查詢與操作

內容解密：

• 使用者首先與網頁伺服器建立連線，網頁伺服器作為第一道防線，通常直接面對外部攻擊。
• 網頁伺服器再將使用者的請求透過API呼叫傳遞給應用伺服器進行業務邏輯處理。
• 應用伺服器負責處理業務邏輯，並與資料函式庫伺服器互動以存取或修改資料。
• 資料函式庫伺服器負責資料的儲存和管理，通常位於最內層，只允許受信任的應用伺服器存取。

威脅行為者、架構圖與信任邊界

在進行風險評估時，建議採用以資產為導向的方法，即優先考慮需要保護的資產。瞭解潛在的威脅行為者至關重要，例如：

• 有組織的犯罪集團或獨立犯罪者，主要目的是取得經濟利益。
• 駭客主義者，主要目的是破壞聲譽或進行破壞。
• 內部攻擊者，通常出於個人利益或報復心理。
• 國家級攻擊者，可能出於竊取機密資訊或破壞業務的目的。

如何繪製架構圖

1. 首先繪製使用者的角色，並標註為「使用者」和「管理員」。
2. 然後繪製第一個元件（例如網頁伺服器），並標註與使用者的互動方式。

程式碼範例：安全組態檢查

#!/bin/bash
# 檢查雲端控制檯的安全組態
check_cloud_console_security() {
  # 檢查是否啟用了多因素認證
  if [ "$(aws iam get-account-summary | jq '.SummaryMap.AccountMFAEnabled' )" -eq 1 ]; then
    echo "多因素認證已啟用"
  else
    echo "警告：未啟用多因素認證"
  fi
  
  # 檢查是否有過多的管理員許可權
  admin_users=$(aws iam list-users | jq '.Users[] | select(.UserName | contains("admin"))')
  if [ -n "$admin_users" ]; then
    echo "發現管理員使用者：$admin_users"
  fi
}

check_cloud_console_security

內容解密：

• 此指令碼檢查兩個重要的安全組態：
  1. 是否啟用了多因素認證（MFA）。
  2. 是否存在過多的管理員許可權使用者。
• 使用AWS CLI命令取得相關資訊，並使用jq工具進行JSON解析。
• 如果未啟用MFA或發現管理員使用者，會輸出相應的警告訊息。

雲端安全威脅分析與信任邊界設計

在雲端運算環境中，系統架構的安全性分析是一項複雜且重要的任務。為了有效地評估和管理風險，我們需要透過系統化的圖解方式來理解系統元件之間的互動關係以及信任邊界的劃分。

系統架構圖解步驟

1. 識別核心元件：首先，我們需要繪製第一個方塊代表核心應用程式或系統的主要元件（圖1-2）。這個元件通常是整個系統的核心，用於處理主要的功能和業務邏輯。

   2. 擴充套件系統邊界：接著，在第一個方塊後面繪製其他相關的系統元件，並用線條連線這些元件（圖1-3）。當遇到儲存資料的系統時，使用特定的符號（如圓柱體）標示資料儲存的位置和內容。

   3. 管理員存取路徑：繪製管理員（或其他角色）如何存取應用程式的路徑（圖1-4）。管理員可能透過多種方式與應用程式互動，例如雲端服務提供者的管理介面、API或作業系統層級的存取。

   4. 信任邊界劃分：使用虛線繪製信任邊界（圖1-5）。信任邊界代表了不同安全層級之間的劃分，內部的元件可以相互信任，但與外部元件的互動需要經過驗證。

   5. 整體系統信任邊界：最後，繪製一個更大的虛線框圍繞整個系統，包括管理員，但不包括使用者（圖1-6）。這代表了整體系統的信任邊界。

內容解密：

• 圖解步驟幫助我們清晰地理解系統架構和元件之間的互動。
• 信任邊界的劃分使我們能夠識別需要特別關注的安全防護點。
• 不同層級的信任邊界反映了不同程度的信任關係。

雲端交付模式與安全責任共擔模型

在雲端運算環境中，瞭解不同的交付模式（IaaS、PaaS、SaaS）對於安全性的影響至關重要。安全責任共擔模型（Shared Responsibility Model）說明瞭雲端服務提供者和客戶之間的責任劃分。

比薩服務類別比

• 自製比薩（On-premises）：完全由自己負責所有環節，相當於傳統的本地佈署環境。
• IaaS：基礎設施已準備好，使用者負責組態和安全管理，相當於購買預製比薩餅皮。
• PaaS：平台已組態完成，使用者只需開發應用程式，相當於使用預製比薩餅皮和部分食材。
• SaaS：完整的軟體服務，使用者只需使用，相當於在餐廳用餐。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端安全防護實踐

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

內容解密：

• 不同雲端交付模式對應不同的安全責任劃分。
• 使用者需要了解所選擇的服務模式下自己的安全責任。
• 安全責任共擔模型強調了雙方在安全保障上的合作與分工。

雲端分享責任模型詳解

雲端運算的現實比吃披薩複雜得多，因此存在一些灰色地帶。在圖1-8的底部，事情是具體的（通常是字面意義上的）。雲端供應商對實體基礎設施安全負有完全責任，這通常涉及許多公司無法合理地在本地執行的控制措施，例如具有反尾隨措施的生物識別存取、保安人員、地台到地台的屏障等，以防止未經授權的人員進入實體設施。

同樣，如果供應商提供虛擬化環境，則保持虛擬環境與其他虛擬環境分離的虛擬化基礎設施安全控制是供應商的責任。當2018年初 Spectre 和 Meltdown 漏洞被揭露時，其中一個潛在影響是同一實體電腦上的不同虛擬機器之間可能存在記憶體讀取問題。對於IaaS客戶來說，修復漏洞的一部分是雲端供應商的責任，但修復作業系統內部的漏洞是客戶的責任。

網路安全：分享責任

網路安全在圖1-8的IaaS部分被顯示為分享責任。為什麼？因為有多個網路層級，不同的責任方負責不同的層級。雲端供應商擁有自己的網路，這是他們的責任，但通常在上面有虛擬網路（例如，一些雲端供應商提供虛擬私有雲），客戶有責任將其劃分為合理的保安區域，並制定適當的存取規則。許多實施還使用疊加網路、防火牆和傳輸加密，這些都是客戶的責任。這將在第6章深入討論。

作業系統安全

作業系統安全通常很簡單：如果使用IaaS，則是客戶的責任；如果購買平台或軟體服務，則是供應商的責任。一般來說，如果購買這些服務，則無法存取底層作業系統。（一般來說，如果能夠破壞它，通常就有責任保護它！）

中介軟體安全

中介軟體在此上下文中是資料函式庫、應用伺服器或佇列系統等軟體的通用名稱。它們位於作業系統和應用程式之間，不直接被終端使用者使用，但用於為終端使用者開發解決方案。如果使用PaaS，中介軟體安全通常是分享責任；供應商可能保持軟體更新（或使更新易於提供給客戶），但客戶保留安全相關設定的責任，例如加密。

應用層安全

應用層是終端使用者實際使用的東西。如果使用SaaS，此層的漏洞（如跨站指令碼或SQL注入）是供應商的責任，但如果正在閱讀此書，則可能不只是使用別人的SaaS。即使所有其他層都有防彈安全，應用層的安全漏洞也可能輕易地暴露所有資訊。

資料存取安全

最後，資料存取安全幾乎總是客戶的責任。如果錯誤地告訴雲端供應商允許存取特定資料，例如授予錯誤的儲存許可權、中介軟體許可權或SaaS許可權，則供應商幾乎無能為力。

許多安全事件的根本原因是假設雲端供應商正在處理某些事情，但事實證明沒有人處理它。許多現實世界中的安全事件源於對分享責任模型的誤解，例如開放的Amazon Web Services Simple Storage Service（AWS S3）儲存桶。AWS S3儲存是安全的和加密的，但如果沒有正確設定存取控制，則毫無用處。這種誤解已經導致了多起資料外洩事件，包括：

• 1.98億美國選民的資料
• 自動追蹤公司記錄
• 無線客戶記錄
• 超過300萬人口統計調查記錄
• 超過5萬印度公民的信用報告