AWS Cloud Adoption Framework...雲端如既往般安全，雖然增加彈性、加速執行動作、擴大規模且成本更低，但並不會使行之有年的資訊安全原則失效。

AWS Cloud Adoption Framework 安全觀點

2016 年 6 月

Amazon Web Services – AWS CAF 安全觀點 2016 年 6 月

第 2/24 頁

©2016, Amazon Web Services, Inc. 或其附屬公司。保留所有權利。

注意

本文件僅供提供資訊參考。其內容為文件發佈當日，AWS 最新的產品內容及實

務，如有變更，恕不另行通知。客戶需自行獨立評估本文件資訊，任何 AWS 產

品或服務皆以「現狀」提供，不包含任何明示或暗示之保證。本文不提供任何來

自 AWS、其附屬公司、供應商或授權人之任何保證、表示，契約承諾、條件或保

證。AWS 對其客戶的責任與義務應由 AWS 協議管轄，本文並非 AWS 與其客戶

之間的任何協議的一部分，也並非上述協議的修改。


第 3/24 頁

內容

摘要 4

介紹 4

AWS 的安全優勢 5

專為安全所設計 6

高度自動化 6

高可用性 6

獲高度肯定 7

指令元件 7

考量 8

預防性元件 9

考量 10

偵測性元件 10

考量 11

調適性元件 11

考量 12

移轉過程 — 定義策略 12

考量 14

移轉過程 — 交付計劃 14

核心五項 15

擴增核心 16

啟動系列範例 17

考量 19

移轉過程 — 開發穩健的安全操作 19

結論 20


第 4/24 頁

附錄 A：AWS CAF 安全觀點進度追蹤 21

關鍵安全啟用因素 21

安全案例進度模型 21

CAF 分類與名詞 23

備註 24

摘要

Amazon Web Services (AWS) Cloud Adoption Framework1 (CAF) 提供指導方

針，幫助要轉移至雲端運算之組織整合不同元件。CAF 指導方針分成多個與雲端

IT 系統實作相關的重點區域。我們稱這些重點區域為觀點，每個觀點又繼續切割

為元件。七個 CAF 觀點各有專屬的白皮書。

本白皮書的內容圍繞安全觀點，因此重點放在整合指導方針與流程，以及您環境

中所用之 AWS 專屬的現有安全控制項。

介紹

AWS 的安全無需耗費心力。所有

AWS 客戶都能從資料中心和網路架構

的建置中獲益，以滿足組織最為敏感

的安全要求。AWS 與其合作夥伴提供

了數百種工具與功能，是為了協助企

業達成可見度、可稽核性、控制能力

及擴展性上的安全目標。這表示企業

可以擁有實際需要的安全，而無需前

期支出，營運成本也比現場部署環境

更低廉。

圖 1: AWS CAF 安全觀點

https://d0.awsstatic.com/whitepapers/aws_cloud_adoption_framework.pdf


第 5/24 頁

安全觀點的目標是協助企業針對組織適合的控制項建構選項與實作。如圖 1 所

示，安全觀點的元件列出有助於轉換組織安全文化的原則。本白皮書將探討各元

件中企業可採取的特定行動，以及進度的測量方法：

指令控制項，建立控管、風險與合規模型，以供整個環境在其中操作。

預防性控制項，保護工作負載，並減緩威脅和漏洞。

偵測性控制項，為企業在 AWS 中的部署操作提供完整的可見度與透明度。

調適性控制項，為偏離安全基準的可能變動提供補救。

雲端如既往般安全，雖然增加彈性、加速執行動作、擴大規模且成本更低，但並

不會使行之有年的資訊安全原則失效。

說明完四項安全觀點元件後，本白皮書將告訴您遷移至雲端並確保環境維持強固

安全基礎的步驟：

定義雲端的安全策略。展開遷移過程後，了解組織的業務目標、風險管理方

法，以及雲端所帶來的商機層級。

研擬安全計劃，用於開發及實作安全、隱私、合規與風險管理功能。一開始的

範圍也許很廣，因此必須要建立架構，讓組織能全面性地解決雲端的安全問

題。實作應允許疊代式的開發，使功能隨著計劃的發展而成熟，讓安全元件成

為組織內其他雲端採用工作的催化劑。

開發穩健的安全操作能力，持續成長並改善。安全是與時俱進的，建議組織除

了維持精準作業，同時更要建立新的能力，透過不斷疊代持續精進。

AWS 的安全優勢

在 AWS，雲端安全是最重要的一環。您身為 AWS 的客戶，將能從資料中心和網

路架構的建置中獲益，以滿足組織最為敏感的安全要求。

AWS 雲端的優點之一，是可讓客戶擴展及創新，同時維護環境安全。客戶只需支

付所使用服務的費用，這表示您可以擁有實際需要的安全，而無需前期支出，成

本也比現場部署環境更低廉。

本節將討論 AWS 平台的部分安全優勢。


第 6/24 頁

專為安全所設計

AWS 雲端基礎設施在 AWS 資料中心內運作，以滿足客戶最為敏感的安全要求為

設計目標。AWS 基礎設施的設計具備最高可靠度，採用嚴密的保護措施以協助保

護客戶隱私。所有資料都存放在高度安全的 AWS 資料中心內。網路防火牆內建

於 Amazon VPC，AWS WAF 的 Web 應用程式防火牆功能可讓您建立私有網路，

控制執行個體與應用程式的存取權限。

在 AWS 雲端部署系統時，AWS 還能協助您分擔安全責任。AWS 使用安全的設計

原則打造基礎設施，允許客戶在 AWS 所部署的工作負載上實作自己的安全架構。

高度自動化

AWS 採用我們特別設計的安全工具，針對我們獨特的環境、容量與全球化需求量

身訂做。透過從頭打造安全工具，讓 AWS 可將許多日常工作自動化，安全專家

不再像從前一樣耗費大量時間，因此 AWS 安全專家能將時間用在可提高 AWS 雲

端環境安全的措施上，客戶則可透過完整的 API 與工具組合，自動化完成安全工

程與操作功能。身分管理、網路安全與資料保護，及監控功能，都能用您現有常

用的軟體開發方法加以自動化及交付，客戶也能透過自動化方式來回應安全問

題。AWS 服務自動化後，不需由人員來監控安全狀態及回應事件，可全權由系統

處理監控、檢閱和啟動回應。

高可用性

AWS 的資料中心分散在不同的地理區域，各區域內有多個可用區域，使其保有彈

性。AWS 資料中心的設計加入更多的頻寬餘裕，在發生重大故障時，仍有足夠的

容量可將流量負載平衡至其餘站台，將對客戶的衝擊減到最低。客戶也可利用這

個多重區域、異地同步備份策略，以驚人的低成本建立具有高復原能力的應用程

式，輕鬆複寫及備份資料，對整個企業部署全球一致的安全控制。

http://aws.amazon.com/vpc/


第 7/24 頁

獲高度肯定

AWS 環境持續受到稽核，取得全球各地鑑定機構的認證。這表示您的合規部分已

經完成。如需 AWS 符合的安全法規與標準的詳細資訊，請參閱 AWS 雲端合規 2

網頁。為協助您達成政府、產業及公司專屬的安全標準與法規，AWS 提供認證報

告，說明 AWS 雲端基礎設施如何符合全球多樣化的安全標準要求。若想取得可

用的合規報告，您可以和 AWS 客戶代表聯絡。客戶可將 AWS 運作的許多控制項

運用到自己的合規與認證計劃中，以降低維護及執行安全保證工作的成本，並確

實由自己來維護控制項。運用如此堅實的基礎，組織便有時間提升工作負載的安

全，實現最佳的彈性、復原能力與擴展規模。

本白皮書的其餘部分將介紹安全觀點的各元件。您可使用這些元件來探索，了解

貴組織在遷移至雲端的過程中需要成功達到哪些安全目標。

指令元件

AWS 安全觀點的指令元件提供指引，告訴您如何規劃遷移至 AWS 過程中的安全

方法。而要有效規劃的關鍵，就是定義指引，以提供給負責實作及操作安全環境

的人員。資訊必須能提供足夠的指引，以決定所需要的控制項及其運作方式。一

開始要考量的區域包括：

帳戶管理— 引導組織建立用於管理 AWS 帳號的流程與程序。需要定義的區域

包括帳戶清單的收集與維護，有哪些現有的協議與增訂資料，以及建立 AWS

帳戶時該使用的條件。開發一套流程，用一致的方式來建立帳戶，確保所有

初始設定皆適當並建立清楚的所有權。

帳戶所有權與聯絡資訊—為整個組織內使用的 AWS 帳戶建立合適的管理模

型，規劃如何維護各個帳戶的聯絡資訊。考慮將建立的 AWS 帳戶與電子郵件

分佈清單建立關聯，而非獨立的電子郵件地址。如此一來，就能讓一整群的

使用者監控及回應 AWS 針對您帳戶活動所發出的訊息。此外，內部人員更動

時也較有彈性，且能用於安全責任的分派。將安全團隊列為安全聯絡人，更

可加速有時間急迫性的通訊。

控制架構—建立或套用產業標準控制架構，並決定以期望的安全性等級整合

AWS 服務時是否需要修改或新增。進行一次合規對應練習，以決定合規要

求與安全控制項是否反映 AWS 服務的使用。

https://aws.amazon.com/compliance/shared-responsibility-model/



第 8/24 頁

控制所有權—檢閱 AWS 網站上的 AWS 共同的責任模型 3 資訊，以決定如何修

改控制所有權。檢閱並更新責任分派表 (RACI 表)，將控制所有權的操作加入

到 AWS 環境內。

資料分類—檢閱目前的資料分類，決定如何在 AWS 環境中管理這些分類，以

及哪些控制項是合適的。

變更與資產管理—決定如何在 AWS 中執行變更管理與資產管理。建立一套方

法來判斷現有哪些資產、系統用途，以及系統的管理是否安全，而且還能整合

至現有的設定管理資料庫 (CMDB)。考慮建立命名及標記的作法，按照要求的

安全層級進行識別與管理。您可以用此方法來定義及追蹤用於識別與控制的中

繼資料。

資料本地性—檢閱資料符合的條件，以決定需要哪些控制項來管理 AWS 服務

在所有區域內的設定與使用。AWS 客戶選擇要將內容託管在哪個 AWS 區域，

這讓有特定地理位置需求的客戶將環境建立在自己選擇的位置。客戶可以在多

個區域複寫或備份內容，但 AWS 不會將客戶內容移動到客戶所選區域之外。

最低權限存取—建立組織的安全文化，以最低權限與強式身分驗證為基礎。實

施通訊協定，以保護與每個 AWS 帳戶相關的機密登入資料和關鍵資料存取。

設定預期，以決定如何將權限向下委派給軟體工程師、操作人員和其他牽涉到

雲端採用的職務。

安全操作手冊與運作手冊—定義安全模式，建立可供組織長期參考且耐用的防

護機制。透過運作手冊的自動化實作操作；於適用情況下記錄人內在於迴路的

干預。

考量

務必針對您的生態系統建立量身自訂的 AWS 共同責任模式。

務必使用強式身分驗證做為帳戶中所有相關人的保護機制。

務必在應用程式團隊中推廣安全所有權文化。

務必擴展資料分類模型，將服務加入到 AWS。

務必整合開發人員、操作及安全團隊的目標和職務。

務必考慮建立命名與追蹤帳戶的策略，用來在 AWS 中管理服務。

務必集中電話與電子郵件分佈清單，方便團隊監控。



第 9/24 頁

預防性元件

AWS 安全觀點的預防性元件提供指引，告訴您如何透過 AWS 在組織內實作安全

基礎設施。要實作正確的控制項組合，關鍵就在於讓安全團隊獲得他們所需要的

信心與能力，以打造在彈性可擴展的 AWS 環境中保護企業所需要的自動化與部

署技能。

指令元件可用來決定您所需要的控制項與指引，接著再使用預防性元件來決定如

何有效操作控制項。AWS 定期提供關於 AWS 服務使用率與工作負載部署模式的

最佳實務，可做為控制項實作參考。請參閱 AWS 安全中心、部落格，和最近一

次的 AWS 高峰會及 re:Invent 會議的 Security Track 影片。

請考慮下列區域，決定您目前的安全架構與作法需要哪些變更 (如有的話)，以幫

助您建立一個流暢且有計劃的 AWS 採用策略。

身分與存取—將 AWS 的使用整合到組織的人力生命週期，以及授權與身分驗

證來源之中。建立與適當使用者及群組關聯的精細政策和角色。建立防護機

制，僅透過自動化方式允許重要變更，並避免非必要的變更或自動執行回

復。這些步驟可避免人員存取生產系統與資料。

基礎設施保護—實作安全基準，包括信任邊界、系統安全設定與維護 (例如，

強化程式與修補程式)，和其他適當的政策強制實施點 (例如，安全群組、

AWS WAF、Amazon API Gateway)，以滿足您利用指令元件找出的需求。

資料保護—利用適當的保護措施來保護傳輸中或靜態的資料。保護措施包括精

細定義的存取控制機制，以用於物件、建立及控制用來加密資料的加密金鑰。

選擇適當的加密或字符化方法、完整性驗證，以及資料的適當保留。


第 10/24 頁

考量

務必從程式碼的角度來看待安全性，以部署並驗證安全基礎設施，給您保護

組織所需要的規模與彈性。

務必建立防護機制，敏感的預設值，並提供範本與最佳實務程式碼。

務必建置安全服務，以供組織用於高度重複性或特別敏感的安全功能。

務必定義相關人並記錄其在操作 AWS 服務時的經驗。

務必使用 AWS Trusted Advisor 工具持續評估 AWS 安全狀態，並考慮 AWS Well Architected review。

務必建立最低可行的安全基準，並持續改善以提升工作負載的保護層級。

偵測性元件

AWS CAF 安全觀點的偵測性元件提供指引，告訴您如何獲得組織安全狀態的能

見度。透過使用 AWS CloudTrail、服務專屬記錄及 API/CLI 回傳數值，可收集

大量的資料與資訊，再將這些資訊擷取到可擴展的平台內，以管理及監控記錄、

事件管理、測試和清單/稽核，帶給組織透明度與營運彈性，讓組織對操作安全

有信心。

記錄與監控—AWS 提供原生的記錄與服務供您運用，讓您即時深入檢視 AWS

環境下所發生的事。您可將這些工具整合到現有的記錄與監控解決方案之

中。將記錄與監控來源的輸出深入整合到 IT 組織的工作流程，針對安全相關

活動建立端對端的解決方案。

安全測試—測試 AWS 環境，確保符合定義的安全標準。藉由測試判斷系統能

否於發生特定事件時如預期般做出回應，看您是否準備好面對真實事件。安全

測試的例子像是有漏洞掃描、滲透測試、錯誤置入等，以證明是否符合標準，

其用意在於決定控制項能否如預期回應。

資產清單—了解組織已部署並運作的工作負載，可讓您監控並確保環境的

運作符合安全標準所預期及要求的安全管理層級。

變更偵測—要仰賴安全的預防性控制項基準，也需要知道這些控制項何時變

更。因此必須實作措施，以判斷安全設定與目前狀態之間是否有任何變動。

https://aws.amazon.com/premiumsupport/trustedadvisor/


第 11/24 頁

考量務必決定 AWS 環境下有哪些記錄資訊需要擷取、監控與分析。

務必決定現有的安全操作中心 (SOC) 業務功能如何將 AWS 安全監控與管理整

合到現有的作法。

務必持續進行漏洞掃描與滲透測試，確保是否符合相關的 AWS 程序。

調適性元件

AWS CAF 安全觀點的調適性元件提供指引，告訴您組織安全狀態的調適性範圍。

整合 AWS 環境到現有的安全狀態，準備並模擬需要回應的動作，以準備好面對發

生的事件。

擁有自動化的事件回應與復原，能夠減緩災難復原的範圍，安全團隊的主要關注

點便能從回應，轉移到進行鑑識及根本原因的分析。調整安全狀態時需要考量的

部分內容如下：

事件回應—發生事件時，先了解事件，再恢復為已知的良好狀態，是回應計劃

中很重要的工作。例如，利用 AWS Config 規則與 AWS Lambda 回應指令碼

來自動執行這些功能，便能將回應速度提升到網際網路速度的等級。檢視現有

的事件回應流程，判斷自動化回應與復原能否及如何針對 AWS 資產運作並管

理。安全操作中心的功能應緊密整合至 AWS API，以盡可能加快回應速度，

藉此在採用 AWS 雲端的過程中提供所需要的安全監控與管理功能。

安全事件回應模擬—藉由事件模擬，驗證現有的控制項與流程能否如預期作出

反應，可利用此方法判斷組織能否有效率地從發生的事件中復原並回應。

鑑識—現有的鑑識工具多數均可在 AWS 環境下使用。鑑識團隊得到的好處包

括可自動跨區域部署工具，可快速收集到大量資料，可運用其商業關鍵應用程

式所採用的強固、可擴展的服務，像是 Amazon Simple Storage Service

(S3)、 Amazon Elastic Block Store (EBS)、 Amazon Kinesis、 Amazon

DynamoDB、Amazon Relational Database Service (RDS)、Amazon RedShift

與 Amazon Elastic Compute Cloud (EC2) 等服務來降低阻力。


第 12/24 頁

考量務必更新事件回應流程，以辨識 AWS 環境。

務必將服務整合到 AWS，透過自動化與功能選擇讓部署可供鑑識。

務必建立自動化回應的健全性與規模。

務必使用 AWS 中的服務來收集和分析資料，以支援事件調查。

務必透過安全事件回應模擬來驗證事件回應能力。

移轉過程 — 定義策略

檢視組織目前的安全策略，判斷策略範圍能否從雲端採用計劃的變動而獲益。將

AWS 雲端採用策略全面對應至企業所能接受的風險等級、達成法規與合規目標的

方法、保護範圍的定義及保護方式。表 1 為安全策略的範例，清楚說明一系列的

原則，以對應至特定的計劃及工作流程。

原則動作範例

基礎架構程式化。

讓安全團隊擁有程式碼與自動化能

力；移轉至 DevSecOps。

設計防護機制，而非攔阻。由架構師帶頭引導正確行為。

運用雲端保護雲端。在雲端中建立、操作及管理安全工具。

保持最新狀態；維持安全運作。採用最新安全功能；定期修補及更換。

減少對持續存取的依賴。建立角色目錄；透過秘密服務自動化

KMI。

全面可見度。

將 AWS 記錄和中繼資料匯總 OS 和應

用程式記錄。

深入檢視。實作整合 BI 與分析的安全資料倉儲。

可擴展的事件回應 (IR)。更新 IR 與鑑識標準操作程序 (SOP)，

建立共同的責任架構。

自我修復。自動修正並還原至已知良好狀態。

表 1：安全策略範例


第 13/24 頁

隨著策略的發展，組織會開始想要改善第三方的保證架構和組織的安全需求，整

合到風險管理架構，引導轉移至 AWS。有效率的作法是提升合規對應，以深入了

解您在雲端上的工作負載需求及 AWS 所提供的安全功能。

策略的另一個關鍵要素，是將專屬共同責任模型對應至您的生態系統。除了與

AWS 共有的巨集關係，您也許想要探索內部組織的共同責任，還有合作夥伴所匯

入的責任。公司可將自己的共同責任模型分成三個主要區域：控制架構；責任、

權責、諮詢、通知模型 (RACI)；及風險登錄。控制架構說明企業的安全工作如何

按預期工作，還有使用哪些控制項來管理風險。RACI 可用來識別及指派在架構

中負責控制的人員。最後，風險登錄可用來在沒有適當所有權下擷取控制項。決

定所找出的剩餘風險的優先順序，再將風險對應至用來消除風險的新工作流程與

計劃。

對應這些共同責任時，更有可能找出新的機會將操作自動化，並改善安全、合規與

風險管理社群中關鍵相關人之間的工作流程。圖 2 顯示擴展的共同責任模型範例。

圖 2: 擴展的共同責任模型


第 14/24 頁

考量務必建立量身打造的策略，符合組織在雲端實作安全的方法。

務必將自動化推廣為整個策略中的基礎主題。

務必先清楚描述您的雲端移轉方法。

務必定義防護機制以提升彈性與靈活度。

務必將策略視為扼要的作法，定義組織在雲端的資訊安全方法。

務必快速透過疊代方式分層建構策略。組織的目標是建立一系列的引導原

則，帶動整體核心前進，策略本身並非終點。加快移轉速度，且能隨之調整

並演進。

務必定義策略原則，將想要的文化運用到安全之中，提供設計決策所要的資訊，而不是從策略中找出特定的解決方案。

移轉過程 — 交付計劃

訂定策略後，接著該實行並啟動實作，以

轉型安全組織並保護雲端移轉過程。雖然

組織有許多選項及功能可選，但實作卻不

能拖延過久。在設計及實作不同功能之間

的搭配運作過程中，讓組織有機會快速熟

悉並學習改善設計，以符合自己的要求。

透過實際實作及早學習，然後邊學習邊運

用細微的變動加以調整並演化。

圖 3: AWS CAF 安全案例

為協助完成實作，企業可利用 CAF 安全案例。(請參閱圖 3。)安全案例包含使用

者群組的案例 (使用案例與濫用案例)，可供企業在開始時使用。這些案例各經過

多次的改善，以解決日益複雜的需求核並提升其強固性。雖然我們強調靈活運

用，但也可將這些案例視為一般的工作流程或主題，在使用任何其他架構時幫助

訂定優先順序及建構交付。提案中的結構包含以下 10 個可引導實作的安全案例

(圖 4)。


第 15/24 頁

圖 4: AWS 十項安全案例

核心五項

以下五項案例為核心的控制與功能類別，企業應及早考量，因為這些案例為可幫

助企業開始移轉過程的基礎。

IAM—AWS Identity and Access Management (IAM) 為 AWS 部署的骨幹。

組織必須先在雲端建立帳戶並授予權限，之後方能佈建及協調資源。典型的自

動化案例可能包括權利的對應/授與/稽核、秘密資料管理、執行權責分立和最

低權限存取、即時權限管理，以及降低對長期憑證的依賴。

記錄與監控—AWS 服務提供大量的記錄資料，可幫助組織在平台上互動。

AWS 服務的效能係根據您的設定選擇，及擷取 OS 和應用程式記錄的能力為

基礎，來建立共同的參考框架。典型的自動化案例可能包括記錄彙整、閾值/

警報/警示、擴充、搜尋平台、視覺化、利害關係人評估，還有工作流程與票

證核發以啟動封閉式的組織回應。

基礎設施安全—將基礎設施程式化後，安全基礎設施將變成第一層的工作負

載，也必須做為程式碼部署。因此您將有機會透過程式設計方式來設定 AWS

服務，並部署來自 AWS Marketplace 合作夥伴的安全基礎設施，或組織自己

設計的解決方案。典型的自動化案例可能包括建立自訂範本、針對自己的需

求設定 AWS 服務、實作安全架構模式，以及將安全操作程式化、運用 AWS

服務修改為自訂的安全解決方案、使用藍/綠部署之類的修補程式管理策略、

降低暴露的攻擊表面，以及驗證部署的效能。


第 16/24 頁

資料保護—保護重要資料為建立及操作資訊系統中很關鍵的部分，因此 AWS

提供了服務與功能，讓您在保護資料生命週期過程中取得最完善的選項。典型

的自動化案例可能包括工作負載配置決策、實作標記結構描述、建構機制以保

護 VPN 和 TLS/SSL 連線 (包含 AWS Certificate Manager) 中的動態資料、建

構機制在基礎設施適當層級透過加密保護靜態資料、利用 AWS Key

Management Service (AWS KMS) 實作/整合、部署 AWS CloudHSM、建立字

符化結構，以及實作和操作 AWS Marketplace 合作伙伴的解決方案。

事件回應—自動化事件管理流程可改善可靠性，並提高回應的速度，且通常能

建立環境，輕鬆評估事件後的檢視。典型的自動化案例可能包括使用 AWS

Lambda 的「回應器」功能，對環境中的特定變更做出反應、協調自動擴展事

件、隔離可疑的系統元件、部署即時調查工具，以及建立工作流程和票證，以

終止並了解封閉式迴路的組織回應。

擴增核心

這五項案例代表著透過可用性、自動化與稽核持續帶動卓越營運。組織應明智地

在每次開始時運用這五項案例。有其他領域需要注意時，您可將這些案例個別獨

立看待。

彈性—高可用性、營運持續性、強固性與韌性，以及災難復原，通常是使用

AWS 部署雲端可獲得的優勢。典型的自動化案例可能包括使用異地同步備份

與多重區域部署、變更開放的攻擊表面、擴展及調整資源分配以吸收攻擊、保

護暴露的資源，以及蓄意導入資源瑕疵以驗證系統操作的持續性。

合規驗證—將端對端合規整合到安全計劃，避免合規因勾選方塊的選擇或部署

後發生的堆疊而降低。此案例提供平台，可整合及合理化其他案例所產生的合

規結果。典型的自動化案例可能包括建立對應至合規需求的安全單位測試、設

計服務與工作負載以支援合規證據收集、建立合規通知與證據功能的視覺化管

道、持續監控，以及建立合規工具導向的 DevSecOps 團隊。

安全 CI/CD (DevSecOps) —透過使用可信賴且經驗證的持續整合與持續部

署工具鏈，獲得可信賴的軟體供應鏈，主要用意是讓您在移轉至雲端的過程中

建立成熟的安全操作。典型的自動化案例可能包括強化及修補工具鏈、工具鏈

最低權限存取、生產流程的記錄與監控、安全整合/部署視覺化，以及程式碼

完整性檢查。


第 17/24 頁

設定與漏洞分析—設定與漏洞分析可從 AWS 的擴展性、彈性與自動化中獲得

可觀的優勢。典型的自動化案例可能包括啟用 AWS Config 及建立客戶的

AWS Config Rules、使用 Amazon CloudWatch Events 與 AWS Lambda 回應

變更偵測、實作 Amazon Inspector、選擇及部署 AWS Marketplace 的持續監

控解決方案、部署觸發式掃描，以及將評估工具嵌入 CI/CD 工具鏈。

安全大數據與預測式分析—安全操作可從大數據服務與解決方案中獲得優勢，

恰如其他的業務領域。運用大數據，讓組織能即時深入檢視，藉此強化彈性與

大規模改善安全狀態的能力。典型的自動化案例可能包括建立安全資料湖、制

定分析流程、建立視覺化以帶動安全決策，以及建立自動回應的回饋機制。

定義結構之後，便能擬定實作計劃。能力會隨時間而改變，並持續嶄露出改善的

機會。請注意，以上的主題與功能類別可彈性視為獨立案例，當中可能包含許多

使用者案例，同時包括使用案例與濫用案例。經過多次啟動後，除了提高成熟

度，也可保持彈性，以跟上企業的步調與需求。

啟動系列範例

請考慮建立範例，組成六次為期兩週的啟動 (一系列的案例，經過 12 週時間啟

動)，包括短期的準備時間，方式如下。您的方法需取決於資源的可用性、優先順

序，以及取得最低可行生產能力 (MVP) 過程中各能力所需要的成熟度。

啟動 0—安全藍圖合規對應、政策對應、初始威脅模型檢視、建立風險登錄；

建立使用與濫用案例的後端記錄；規劃安全案例

啟動 1—IAM；記錄與監控

啟動 2—IAM；記錄與監控；基礎設施保護

啟動 3—IAM；記錄與監控；基礎設施保護

啟動 4—IAM；記錄與監控；基礎設施保護；資料保護

啟動 5—資料保護、自動化安全操作、事件回應規劃/工具；復原能力

啟動 6—自動化安全操作、事件回應規劃/工具；復原能力


第 18/24 頁

合規驗證的關鍵元素之一，就是透過安全與合規單位測試案例將驗證整合到各次

啟動中，然後再推廣到生產流程。明確的合規驗證功能有其必要，建立啟動時可

將重點特別放在使用者案例上。長時間下來，可透過改善來實現持續驗證，並適

當實作自動誤差修正。

完整作法的用意是清楚定義出 MVP 或基準，再對應至各區域的第一次啟動。在初

期階段，即使結束目標定義不明確，但卻能為初期啟動建立明確的藍圖。透過時

間、經驗與疊代，將可微調並調整結束狀態，以精準達成組織的需求。雖然最終

狀態可能持續變動，但整個過程終將能以更快的步伐帶來持續性的改善。這種方

法比需要長時間和高前期支出的突破性方法更有效率、更具成本效益。

再深入一點說明，IAM 的第一次啟動可能包含定義帳戶結構，以及實作最佳實務

的核心組合。第二次啟動可實作聯合。第三次啟動可擴展帳戶管理，以加入多重

帳戶等。橫跨一或多次初始啟動的 IAM 使用者案例可包含下列案例：

「身為存取管理員，我想要建立初始的使用者集合，用來管理權限存取及聯合身分供應商的信任

關係。」

「身為存取管理員，我想要在 AWS 平台上將現有企業目錄中的使用者對應至功能角色或存取權利

組合。」

「身為存取管理員，我想要在互動式使用者與 AWS 主控台之間的所有互動上實行多重驗證。」

在此範例中，下列記錄與監控使用者案例可能橫跨一或多次初始啟動：

「身為安全操作分析師，我想要接收所有 AWS 區域與 AWS 帳戶的平台層級記錄。」

「身為安全操作分析師，我想要將所有的平台層級記錄傳送到所有 AWS 區域與 AWS 帳戶的單一

共同位置。」

「身為安全操作分析師，我想要接收將 IAM 政策套用到使用者、群組或角色的任何作業的相關提醒。」

您可將安全功能使用者案例加入到整體的產品後端記錄內，以建立平行或序列式

的功能並保持彈性，也能將使用者案例加以區分，分配到以安全為重心的

DevOps 團隊。您可定期重新檢視這些決策，以量身自訂為滿足組織需求而交付

的服務。


第 19/24 頁

考量務必檢閱現有的控制架構，以決定 AWS 服務的操作方式如何達成您需要的安全標準。

務必定義相關人並記錄其在操作 AWS 服務時的經驗。

務必定義第一次啟動，還有初始的高階長期目標。

務必建立最低可行的安全基準，並持續改善以提升工作負載與資料的保護層級。

移轉過程 — 開發穩健的安全操作

在程式化基礎設施的環境下，必須從程式碼的角度來看待安全性。安全操作元件

提供將安全性做為程式碼處理之基礎原則的傳達與操作方式：

運用雲端保護雲端。

安全基礎設施應具備雲端感知能力。

運用 API 將安全功能以服務方式呈現。

自動化一切程序，以方便擴展您的安全性與合規。

為了讓管理模型可行，業務單位經常需要重整為 DevOps 團隊，來進行基礎設施

和商用軟體的建構及部署。透過將安全整合到 DevOps 文化或作法中 (有時稱之

為 DevSecOps)，擴展管理模型的核心原則。利用下列原則建立一個團隊：

安全團隊需採用 DevOps 的文化與行為。

開放開發人員投入將安全操作自動化的程式碼。

允許安全操作團隊加入應用程式程式碼的測試與自動化。

團隊應對部署的速度與頻率感到自信。提高部署頻率，加入少量的變更，減

少操作風險，加快安全策略的進展速度。


第 20/24 頁

經過整合的開發、安全與操作團隊有三個共同的關鍵任務。

強化持續整合/持續部署工具鏈。

啟用並提升彈性軟體在整個工具鏈中的開發。

在工具鏈中部署所有的安全基礎設施與軟體。

找出目前安全作法中的變更 (如有的話)，有助於規劃出更流暢的 AWS 採用策略。

結論

在轉移至 AWS 的採用流程中，組織應該更新安全狀態，將 AWS 加入到組織環境

中。本安全觀點白皮書運用規則引導企業採用方法，幫助企業取得操作 AWS 能

為安全狀態帶來的優勢。更多安全資訊可從 AWS 網站取得，除了詳述安全功

能，同時也提供可用於一般實作更詳盡的規則引導。此外亦提供

https://aws.amazon.com/security/security-resources/安全重點內容 4 完整清單，您安全團

隊中的每位成員在準備 AWS 採用計劃之前都應該加以檢視。

https://aws.amazon.com/security/security-resources/

https://aws.amazon.com/security/security-resources/


第 21/24 頁

附錄 A：AWS CAF 安全觀點進度追蹤

您可利用附錄中的重要安全啟動因素與安全案例進度模型，來衡量 AWS CAF 安

全觀點實作的進度和成熟度。啟用因素與進度模型可用來預測規劃目的，評估實

作的強度，或簡單做為驅動進度轉換的方法。

關鍵安全啟用因素

關鍵安全啟用因素為可幫助您保持在正軌上的里程碑。我們採用評分模型，當中

包含三個數值：不足、符合與已完成。

雲端安全策略 [不足、符合、已完成]

利害關係人通訊計劃 [不足、符合、已完成]

安全藍圖 [不足、符合、已完成]

記錄共同的責任模型 [不足、符合、已完成]

安全操作手冊與運作手冊 [不足、符合、已完成]

安全案例計劃 [不足、符合、已完成]

安全事件回應模擬 [不足、符合、已完成]

安全案例進度模型

安全案例進度模型可幫助您評估實作本白皮書中所述之 10 項安全案例的進度。

我們使用評分模型，以 0 (零) 到 3 來衡量穩健度。我們提供 Identity and Access

Management 和記錄與監控案例的範例，讓您知道如何使用進度。

核心五項安全案例

0 - 不足

1 - 已解決架構與規劃

2 - 最低可行實作

3 - 企業可立即執行實作


第 22/24 頁

安全案例 0 1 2 3

Identity and Access

Management

範例：現場部署與

AWS 身分之間無

關聯。

範例：已定義人力

生命週期身分管理

的方法。已記錄

IAM 架構。已將職

務對應至 IAM 政策

需求。

範例：已按照架構

定義實作 IAM。

已實作對應至部分

職務的 IAM 政

策。已驗證 IAM

實作。

範例：IAM 生命週

期工作流程自動化。

記錄和監控範例：未使用

AWS 提供的記錄

與監控解決方案。

範例：已定義記錄

彙整、監控及整合

至安全事件管理流

程的方法。

範例：已啟用並集

中化平台層級與服

務層級的記錄。

範例：已將具有安

全隱憂的事件深入

整合至安全工作流

程與事件管理流程

和系統。

基礎設施安全

資料保護

事件管理


第 23/24 頁

擴增核心五項

0- 不足

1- 已解決架構與規劃

2- 最低可行實作

3- 企業可立即執行實作

安全案例 0 1 2 3

彈性

DevSecOps

合規驗證

組態與漏洞管理

安全大數據

CAF 分類與名詞

Cloud Adoption Framework (CAF) 為 AWS 所建立的架構，用於從先前的客戶專

案中找出引導方向與最佳實務。AWS CAF 觀點代表與組織中雲端 IT 系統實作相

關的重點區域，例如，安全觀點提供指導方針與流程，可用來評估及強化您轉移

到 AWS 環境過程中現有可用的安全控制項。


第 24/24 頁

每個 CAF 關鍵都由元件及活動組成。元件為觀點的子區域，代表需要注意的特定

範圍，本白皮書探討了安全觀點的各元件。活動提供更詳盡的規則引導，用於建

立組織在轉移至雲端及持續操作雲端解決方案時可利用的可行計劃。

例如，指令為安全觀點其中一項元件，針對您的生態系統量身自訂 AWS 共同責任

模型便是元件的活動之一。

Cloud Adoption Framework (CAF) 與 Cloud Adoption Methodology (CAM) 的結

合，可在組織轉移到 AWS 雲端的過程中提供引導方針。

備註

1 https://d0.awsstatic.com/whitepapers/aws_cloud_adoption_framework.pdf

2 https://aws.amazon.com/compliance/

3 https://aws.amazon.com/compliance/shared-responsibility-model/

4 https://aws.amazon.com/security/security-resources/

Documents

AWS Cloud Adoption Framework...雲端如既往般安全，雖然增加彈性、加速執行動作、擴大規模且成本更低，但並 不會使行之有年的資訊安全原則失效。

AWS Cloud Adoption Framework...雲端如既往般安全，雖然增加彈性、加速執行動作、擴大規模且成本更低，但並不會使行之有年的資訊安全原則失效。