CompTIA SY0-701: 雲端、虛擬化與容器安全 — 學習指南

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

屬於 CompTIA Security+ SY0-701 — 學習指南. 使用經過驗證的解答練習： CompTIA 考試中心, 或參加限時模擬考試： ExamRoll.io.

現代企業很少在單一、獨立的資料中心內運作。工作負載橫跨公有雲供應商、私有虛擬化叢集、容器協同運作平台以及短暫的無伺服器函數。每個抽象層都會改變威脅模型、控制介面，以及——最關鍵的——誰該為哪些安全控制負責。

責任共擔模型

每個主要的雲端供應商都會發布一份責任共擔模型，用以劃分客戶與雲端服務供應商 (CSP) 之間的安全職責。這條分界線會根據服務層級而變動。

在基礎設施即服務 (IaaS)——例如 Amazon EC2、Azure Virtual Machines、Google Compute Engine——中，CSP 負責保護實體設施、硬體、hypervisor 及網路架構。Hypervisor 以上的一切都屬於客戶的責任範疇：客體作業系統、修補、主機型防火牆、中介軟體、執行環境、應用程式碼、身分識別組態以及資料本身。如果一家公司在 EC2 執行個體上部署一個 MySQL 資料庫，那麼保護該資料庫就完全是客戶的責任。

在平台即服務 (PaaS)——例如 AWS RDS、Azure App Service、Google App Engine——中，供應商額外管理作業系統、資料庫引擎修補及執行環境。客戶仍然要負責應用程式碼、資料分類、存取控制、網路曝險規則及身分識別管理。

在軟體即服務 (SaaS)——例如 Microsoft 365、Salesforce、Workday——中，供應商幾乎處理整個技術堆疊。客戶剩餘的責任也非同小可：帳號的佈建與撤銷、MFA 強制執行、資料分類、共用權限、DLP 組態，以及與企業身分識別提供者的整合。一個設定錯誤的 SharePoint 網站將薪資資料曝露給「所有人」，這不是 Microsoft 的外洩事件——而是租用戶管理員的疏失。

一個持續存在的誤解是，遷移到雲端會將所有安全責任轉移給供應商。涉及設定錯誤的 S3 儲存貯體、曝露的 Elasticsearch 叢集和外洩的 API 金鑰等資料外洩事件，幾乎都可以追溯到客戶端的錯誤，而非 CSP 遭入侵。

虛擬化與 Hypervisor 風險

虛擬化技術使用 hypervisor 將實體硬體集結成邏輯上的客體。第一類 (裸機) hypervisor，如 VMware ESXi、Microsoft Hyper-V 和 KVM，直接在硬體上執行。第二類 (託管式) hypervisor，如 VirtualBox，則在一個通用作業系統之上執行，不適合用於生產環境的工作負載。

主要的虛擬化特定威脅是 VM 逃逸和 hypervisor 遭入侵。當客體內的惡意程式碼突破其虛擬化邊界，並在 hypervisor 或相鄰的 VM 上執行時，就發生了 VM 逃逸。歷史上的例子包括 CVE-2015-3456 (VENOM，存在於 QEMU 的軟碟控制器中) 和各種 VMware Tools 的漏洞。由於單一 hypervisor 可能會託管橫跨多個信任區域的數百個工作負載，一次成功的逃逸會帶來不成比例的存取權限。

緩解措施包括嚴格的 hypervisor 修補、最小化客體附加功能和未使用的模擬硬體、根據敏感度將工作負載分離到不同的叢集上，以及隔離管理平面。vCenter 伺服器、ESXi 管理介面和叢集 API 必須位於一個專用的管理網路上，且只能從具備 MFA 的特權跳板機存取。

其他考量點包括 VM 蔓延 (隨著時間累積，被遺棄、未修補的 VM) 和資源重用，也就是已除役 VM 的記憶體或儲存空間在分配給另一租用戶前未被正確歸零。

容器、微服務與核心共享

容器將應用程式及其相依套件打包在一起，但與 VM 不同，它們共享主機作業系統的核心。Docker、containerd 和 CRI-O 管理容器的生命週期；Kubernetes 則大規模地協同運作它們。這種輕量級的隔離是一項特色——啟動時間以毫秒計、高密度部署——但也是主要的風險所在。

容器隔離不等同於 VM 隔離。從容器內利用的核心漏洞可能會危及主機及其上所有其他的容器。命名空間 (PID、network、mount、UTS、IPC、user) 和 cgroups 提供了隔離，但它們是共享單一攻擊面的軟體建構。

容器安全需要在整個流程中實施控制：

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

映像檔在部署前必須掃描漏洞 (Trivy、Snyk、Clair)，從最小化的基礎映像檔 (distroless 或 Alpine) 建構，並且只從強制執行映像檔簽署 (Cosign、Notary) 的受信任登錄檔中提取。執行階段保護工具 (Falco、Aqua、Sysdig) 會監控容器行為，並在出現異常時發出警報，例如非預期的程序執行或網路連線。

雲端安全態勢與 IAM

雲端 IAM 在一些重要方面與地端的 Active Directory 不同。在 AWS 中，IAM 政策是附加到使用者、群組或角色的 JSON 文件，而有效的權限是身分型政策和資源型政策的交集，其中明確拒絕永遠優先：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

雲端安全態勢管理 (CSPM) 工具會持續掃描雲端組態，並對照安全基準 (CIS AWS Foundations、NIST) 進行檢查，標記出公開的 S3 儲存貯體、過於寬鬆的安全群組、已停用的 CloudTrail 記錄，以及未加密的 EBS 磁碟區。雲端存取安全代理 (CASB) 位於使用者和雲端服務之間，為 SaaS 應用程式強制執行 DLP、存取政策和威脅偵測。

實際案例：設定錯誤的 S3 儲存貯體洩露個人可識別資訊 (PII)

一家醫療保健新創公司將病患初診資料表儲存在一個 S3 儲存貯體中，該儲存貯體在一次開發衝刺期間被建立並設定了公開讀取存取權，但在上線前從未限制其存取。一名安全研究人員透過結合使用 DNS 暴力破解和 AWS S3 儲存貯體列舉技術，發現了這個儲存貯體。大約 87,000 筆病患紀錄——包括姓名、出生日期、保險 ID 和主訴描述——在無需身分驗證的情況下即可被存取。該新創公司沒有任何 CSPM (雲端安全態勢管理) 工具，也沒有自動化組態掃描。一個檢查 s3-bucket-public-read-prohibited 的基本 AWS Config 規則，本可在儲存貯體建立後的幾分鐘內就標記出此設定錯誤。此事件導致了 HHS (美國衛生及公共服務部) 的調查、一筆 45 萬美元的和解金，以及商譽損害，最終造成該公司以折價估值被收購。

← 應用程式與網站安全 · 所有領域 · 資料安全、隱私與密碼學 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →