雲端服務已成為現代企業不可或缺的基礎設施，選擇合適的供應商並有效管理安全性至關重要。本文除了分析 AWS、Azure 和 GCP 三大巨頭外，也涵蓋了阿里雲、甲骨文雲和 IBM 雲等重要供應商，比較其優劣勢和安全挑戰。同時，文章也探討了雲端環境下的身分管理和秘密管理，闡述了根使用者、IAM 使用者、BYOI 等不同身分型別及其許可權管理的最佳實務，並強調了最小許可權原則和秘密管理的重要性，以降低安全風險並提升雲端環境的可靠性。
主要雲端服務提供者
亞馬遜網路服務（AWS）是領先的雲端服務提供者之一，提供廣泛的 IaaS、PaaS 和 SaaS 服務。AWS 的技術堆疊最初根據 Amazon.com 的成功經驗，後來作為產品提供給外部使用者。AWS 的目標是成為一個一站式的解決方案，提供一切企業所需的功能。
主要雲端服務供應商分析
隨著雲端運算技術的快速發展，企業越來越依賴雲端服務供應商來滿足其運算需求。目前市場上有許多雲端服務供應商，其中最主要的供應商包括Amazon Web Services（AWS）、Microsoft Azure和Google Cloud Platform（GCP）。本章節將探討這些主要雲端服務供應商的特點、服務架構以及潛在的安全風險。
Amazon Web Services（AWS）
AWS 是目前全球最大的雲端服務供應商，提供超過數百種不同的服務，從計算、儲存、資料函式庫到人工智慧和機器學習等。AWS 的全球基礎設施包括多個區域的資料中心和可用區（Availability Zones, AZ），使得企業能夠根據需求選擇最合適的佈署位置。
AWS 服務架構
AWS 提供了一套完整的服務，包括基礎設施即服務（IaaS）、平台即服務（PaaS）和軟體即服務（SaaS）。其服務涵蓋了從基礎的運算資源到高階的資料分析和機器學習等領域。
此圖示說明瞭 AWS 提供的不同型別的服務及其應用。
AWS 安全風險
雖然 AWS 提供了豐富的服務和強大的安全性功能，但仍然存在許多潛在的安全風險。攻擊者可能會利用未修補的漏洞、錯誤組態、弱密碼等方式攻擊 AWS 環境。因此，企業需要對其 AWS 環境進行全面性的風險評估和安全管理。
程式碼範例：使用 AWS CLI 組態 S3 儲存桶
aws s3 mb s3://my-bucket
aws s3api put-bucket-encryption --bucket my-bucket --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'
內容解密：
aws s3 mb s3://my-bucket：此命令用於建立一個名為my-bucket的 S3 儲存桶。aws s3api put-bucket-encryption --bucket my-bucket --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'：此命令為my-bucket啟用伺服器端加密，預設使用 AES256 演算法加密所有上傳的物件。
Microsoft Azure
Microsoft Azure 是另一個主要的雲端服務供應商，提供了一系列的雲端服務，包括 IaaS、PaaS 和 SaaS。Azure 的服務設計旨在幫助企業實作其業務目標，並提供了與 AWS 相似的功能和服務。
Azure 服務架構
Azure 提供了一種分層的服務架構，不同於 AWS 的模組化建構區塊方法。Azure 的服務包括虛擬機器、儲存、資料函式庫、人工智慧和機器學習等。
此圖示展示了 Azure 的服務架構和主要服務。
Azure 安全風險
與 AWS 類別似，Azure 也面臨著諸如未修補的漏洞、錯誤組態和弱密碼等安全風險。企業需要對其 Azure 環境進行全面的安全管理，以降低這些風險。
Google Cloud Platform（GCP）
GCP 是 Google 提供的雲端服務套件，包括 IaaS、PaaS 和無伺服器運算環境。GCP 的特色在於其強大的資料分析和機器學習能力。
GCP 服務架構
GCP 提供了一系列模組化的雲端服務，包括運算引擎、儲存和資料函式庫等。GCP 的開放原始碼基礎使其與其他供應商有所不同。
此圖示說明瞭 GCP 的主要服務和架構。
GCP 安全風險
GCP 面臨的安全風險包括未修補的漏洞、零日攻擊和弱密碼等。由於 GCP 的開放原始碼基礎，其安全風險與其他供應商可能有所不同。
雲端服務供應商的多樣性與安全挑戰
雲端運算市場的多樣化發展帶來了豐富的選擇，同時也伴隨著複雜的安全挑戰。除了亞馬遜網路服務（AWS）、微軟Azure和谷歌雲端平台（GCP）這三大主要供應商外，其他如阿里雲、甲骨文雲和IBM雲等供應商也各自佔有一席之地，並提供獨特的服務和解決方案。
阿里雲：亞太地區的領先者
阿里雲作為阿里巴巴集團的子公司，專注於為中國和亞太地區提供雲端運算服務。它不僅是該地區最大的雲端運算平台，在全球範圍內也具有重要影響力。阿里雲的服務涵蓋了基礎設施即服務（IaaS）、平台即服務（PaaS）、資料函式庫即服務（DBaaS）和軟體即服務（SaaS）等領域，並且能夠透過其原生平台進行管理。對於希望在亞太地區和中國市場開展業務的企業來說，阿里雲是一個極具吸引力的選擇。然而，使用阿里雲的服務也需要遵守當地的法律法規，特別是在資料隱私和政府存取要求方面。
阿里雲的安全挑戰
阿里雲的安全挑戰主要體現在平台特有的漏洞和開原始碼的基礎上。與其他雲端供應商類別似，憑證攻擊和組態錯誤也是阿里雲面臨的主要安全威脅。
甲骨文雲：專注於甲骨文技術的雲端解決方案
甲骨文雲是一個全球性的雲端服務和運算供應商，主要透過其管理的資料中心網路提供服務，特別是在推廣甲骨文的解決方案方面具有優勢。雖然甲骨文允許在其雲環境中託管競爭對手的作業系統和資料函式庫，但其主要產品仍然是根據自家技術。甲骨文雲提供了包括IaaS、PaaS和SaaS在內的多種解決方案，並且是少數提供資料即服務（DaaS）的供應商之一，這得益於其著名的甲骨文資料函式庫和報告技術。
甲骨文雲的安全性
儘管公開報導的針對甲骨文雲的攻擊相對較少，但這並不意味著其環境比其他供應商更安全。事實上，所有主要的雲端運算供應商都提供了符合FedRAMP規範的安全雲端服務，能夠滿足最敏感的政府使用案例。甲骨文雲的商業產品往往與其本地應用程式分享相同的元件（程式碼），因此存在相關的安全風險。此外，甲骨文在漏洞披露方面的參與度不如微軟那樣及時和全面，這使得公眾難以完全瞭解其風險狀況。
IBM雲：混合環境的專業解決方案
IBM雲提供了一個包含多種雲端運算服務的生態系統，主要專注於PaaS和IaaS。IBM雲允許組織佈署虛擬IT資產，以補充或替換現有的資料中心，並建立跨全球的混合環境。為了實作這一點，IBM使用了一個開源平台，使得開發者能夠在雲端和本地環境中建立、管理、維護、執行和佈署應用程式。這種模式模糊了本地和雲端之間的界限，為混合環境提供了操作透明度。
IBM雲的特色與安全
IBM雲除了提供基本的雲端運算服務外，還包括了一些專門的工具，如IBM Watson，用於先進的人工智慧服務，以及支援第三方供應商的無伺服器運算。IBM提供了三種不同的雲端佈署模型作為其DCaaS（資料中心即服務）策略的一部分：公共、私有和專用。每種模型都能滿足不同組織的需求，提供靈活性和安全性。
此圖示說明
此圖示呈現了阿里雲、甲骨文雲和IBM雲各自的主要特色以及它們共同面臨的安全挑戰。每個供應商都有其獨特的市場定位和服務範圍，但都必須應對憑證攻擊、組態錯誤等安全威脅。
雲端服務供應商的多樣性與選擇考量
雲端運算市場由少數大型雲端服務供應商（CSP）主導。2021年初，AWS市佔率接近三分之一（32%），Azure緊隨其後，市佔率達20%。接下來的三家供應商（GCP、Aliyun、IBM）合計控制了另外20%的市占率（分別為9%、6%和5%）。這五大供應商佔了全球雲端服務供應總量的72%，餘下的28%則由其他供應商瓜分，為各種特定用途提供了廣闊的客製化及專門服務空間。
小型雲端服務供應商的角色
部分小型供應商利用大型供應商的平台提供增值服務，而其他供應商則使用自有資料中心和運算能力作為可轉售服務。此外，電信業者及其他網際網路服務供應商也常利用現有的實體資料中心銷售自有的雲端運算服務。其他品牌則針對特定市場提供專門服務。
選擇雲端服務供應商的考量
選擇雲端服務供應商是一項嚴肅的商業決策，需要考量多項因素，包括：
- 供應商的財務穩定性
- 服務水準協定（SLA）中關於正常執行時間和問題解決的承諾
- 可用於託管服務的資料中心數量
- 支援的地理位置及不可接受的地理邊界
- 備份和還原計劃
- 高用性交付機制
- 網路安全攻擊後的揭露計劃
- 是否具備足夠的網路安全保險
小型供應商的風險評估
在選擇小型雲端服務供應商時，必須評估其商業模式、財務穩定性、網路安全計劃和災難還原能力。例如，小型供應商的財務穩定性相較於大型供應商更值得關注。如果小型供應商破產，將對您的業務產生何種影響？
廠商鎖定風險
選擇雲端服務供應商時，也需要考慮廠商鎖定風險。如果未來需要更換CSP，切換的難度、所需重新設計的獨特技術以及相關的時間和金錢成本都是重要的考量因素。
雲端定義的演變
雲端的成長推動了許多行銷術語的發展，如「數位轉型」和「零信任」。然而，這些術語在推動雲端佈署的使用案例和架構的同時，也促使一些行業標準術語的定義演變至包含雲端。
可用性
可用性是評估雲端服務運作時攻擊向量影響的重要因素。低可用性的服務更容易受到攻擊。業界常以「9」（如99.9%）來表示可用性，但這往往被誤解。高用性（如三個9、四個9或五個9）通常被要求，而未考慮實際業務需求。
複雜系統的可用性
在複雜系統中，如使用PaaS和DBaaS的網頁應用程式，需要考慮多個元件的可用性。例如，若PaaS的可用性為99.9%，而DBaaS的可用性為95%，則整體系統的可用性並非簡單地取最低值，而是兩者的乘積（94.9%）。提高用性的方法之一是增加冗餘元件，即使這些元件是在負載平衡機制中使用。
提升可用性的策略
複製關鍵元件（如DBaaS）可以顯著提升系統的整體可用性。例如，兩個DBaaS例項各自具有95%的可用性，其組合可用性不是簡單的90%，而是99.75%。這表明冗餘設計對於提升系統可用性的重要性。
雲端服務的可用性與身份管理
在雲端運算的世界中，可用性和身份管理是兩個至關重要的概念。可用性指的是系統或服務在需要時能夠正常運作的能力，而身份管理則涉及到如何確保只有授權的使用者或系統能夠存取特定的資源。
可用性的挑戰
雲端服務的可用性取決於多個因素，包括硬體、軟體、網路連線等。即使用了多個例項來提高用性，但整體可用性仍可能受到最弱一環的影響。以資料函式庫即服務（DBaaS）和平台即服務（PaaS）為例，即使每個服務都有很高的可用性，但整體服務的可用性仍可能不理想。
內容解密：
在上述例子中，我們看到即使有三個DBaaS例項，可用性也只是接近99.9%。這是因為整體可用性取決於所有相關元件的可用性，包括PaaS、網路連線等。要達到更高的可用性，需要每個元件都達到非常高的可用性標準。
身份管理的複雜性
在雲端環境中，身份管理變得更加複雜。數字身份（digital identity）代表了實體（如人員、組織、應用程式或裝置）在電子系統中的存在。這些身份用於驗證、授權、自動化和執行時的模擬。
內容解密：
在AWS中，根使用者（root user）和IAM使用者（IAM user）是兩種不同的身份。根使用者是預設建立的，具有最高許可權，而IAM使用者則是根據最小許可權原則建立的，用於執行特定任務。這兩種身份之間的區別對於安全管理至關重要。
實際應用
在實際應用中，瞭解可用性和身份管理的複雜性對於設計和實施安全的雲端解決方案至關重要。透過仔細規劃和實施，可以提高系統的彈性和安全性。
@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
此圖示展示了雲端服務與其可用性和身份管理之間的關係。
雲端定義：身份、帳戶與主體
在雲端運算的世界中，正確理解和管理身份、帳戶和主體至關重要。本章節將探討這些概念及其在雲端安全中的重要性。
根使用者（Root User）
根使用者是雲端服務提供商（CSP）分配給客戶的第一個身份，具有對帳戶和相關例項的完全存取許可權。出於安全最佳實踐的考慮，不建議使用根使用者進行日常任務，即使是管理任務也不例外。
根使用者的特點
- 具有對帳戶和相關例項的完全控制權
- 可以執行某些只有根使用者才能執行的任務，例如關閉雲端服務提供商帳戶、更改帳戶設定等
- 使用根使用者進行日常任務會增加安全風險
根使用者的最佳實踐
- 避免使用根使用者進行日常任務
- 為日常管理任務建立具有管理許可權的IAM使用者
- 對根使用者帳戶啟用多因素身份驗證（MFA）
IAM 使用者
IAM（身份和存取管理）使用者是一種身份，可以由根使用者或其他具有建立IAM使用者許可權的IAM使用者建立。
IAM 使用者的特點
- 可以使用IAM使用者憑據和帳戶ID或別名（如果需要）進行身份驗證或啟動遠端會話
- 應該以最小許可權原則建立IAM使用者
- 可以將IAM使用者分配給人類、應用程式、流程或其他機器身份
IAM 使用者的最佳實踐
- 為需要存取帳戶的人員建立單獨的IAM使用者
- 對IAM使用者啟用MFA並停用單因素身份驗證
- 對IAM使用者實施根據當前安全控制的策略，以限制不當行為
自帶身份（BYOI）
自帶身份（BYOI）是一種使用第三方目錄服務進行身份驗證和許可權管理的身份驗證方法。這種方法允許身份在不儲存本地使用者資訊或組態檔案的情況下進行身份驗證。
BYOI 的特點
- 使用第三方目錄服務進行身份驗證和許可權管理
- 身份資訊儲存在第三方服務中，而不是本地
- 可以用於金融交易、登入服務等場景
帳戶
帳戶是身份的電子表示，可以與身份具有一對多的關係。一個身份可以有多個帳戶，這些帳戶參照了一組許可權、權利、授權和特權，以允許應用程式或資產在系統內連線或操作。
帳戶的特點
- 可以具有複雜的關係，例如本地定義、分組、巢狀在組中或透過身份基礎設施管理
- 可以具有根據角色的存取控制，以實作各種功能
- 過度分配特權給任何給定帳戶會違反最小許可權原則（PoLP），從而增加網路風險和雲端攻擊向量
主體
在雲端運算中，“主體”是一個概念，它將身份（通常按帳戶名稱）對映到授權、許可權和權利。每個此類別組合的條目都是一個單一的主體。
主體的特點
- 將身份對映到授權、許可權和權利
- 每個主體代表一個唯一的身份和授權組合
雲端安全中的身分與秘密管理
在雲端運算的環境中，安全管理是至關重要的議題。其中，身分管理（Identity Management）和秘密管理（Secrets Management）是兩個核心概念，直接關係到雲端資源的安全性和可靠性。
主體名稱與型別
在雲端環境中，每個存取資源的實體（無論是使用者、群組還是角色）都會被賦予一個主體名稱（Principal Name）。這個名稱與特定的帳戶、群組或角色相關聯，而與其所屬的目錄服務來源無關。同時，主體型別（Principal Type）則用於指代實際的身分，例如使用者、角色、群組或 API 等。這種機制有助於在複雜的雲端環境中清晰地管理和控制存取許可權。
風險主體與最小許可權原則
風險主體（Risky Principals）是指那些可能對系統安全構成威脅的主體。監控和管理這些風險主體的數量，可以幫助評估雲端環境的安全狀況。一般而言，風險主體的數量越少，系統的安全性越高，因為這通常意味著系統遵循了最小許可權原則（Least Privilege），即每個主體只被授予完成其任務所需的最小許可權。
秘密與秘密管理
在雲端和本地環境中，非人類或機器身分使用的憑證通常被稱為「秘密」（Secrets）。這些秘密包括但不限於密碼、憑證、SSH 金鑰、API 金鑰和加密金鑰等。秘密管理是指對這些數位憑證進行管理的工具和方法，包括密碼、金鑰、API 和權杖等，以確保它們在應用程式、服務和特權帳戶中的安全使用。
常見的秘密型別
- 特權帳戶憑證：傳統的使用者名稱和密碼組合。
- 密碼：單純的密碼，不伴隨使用者名稱。
- 憑證：用於識別資源或通訊所有者的數位簽章檔案。
- SSH 金鑰：用於 SSH 協定以提高認證信心的金鑰對。
- API 金鑰：用於認證使用者、開發者或呼叫程式到 API 的唯一識別碼。
- 加密金鑰：用於密碼學演算法中的資訊片段，用於編碼或解碼密碼資料。
秘密管理的挑戰與風險
隨著 IT 生態系統的日益複雜，秘密的數量和多樣性也在不斷增長，這使得安全儲存、傳輸和稽核秘密變得越來越困難。常見的風險包括對所有特權帳戶、應用程式和秘密缺乏可見性，以及硬編碼的秘密可能被威脅行為者利用等。
風險範例
- 缺乏可見性：分散式管理方法可能導致安全漏洞和稽核挑戰。
- 嵌入式秘密：應用程式和 IoT 裝置中硬編碼的預設秘密或憑證容易被破解。