原標《AWS的雲端架構框架-資安篇》

文/運用雲端服務加速企業的數位轉型

這一篇我們概述AWS提倡的雲端架構框架的第二個面向 — 資安．在資安的這個層面最主要是能使用AWS的雲端技術保護雲端上的資料、系統、數位資產．我們會就整體的設計原則，最佳實踐與相對應出現的問題一起來檢視．

七個設計原則

AWS在雲端的資安層面上提出了七個設計原則，它們分別是：

• 實踐強韌的身分辨識基礎(Implement a strong identity foudation):這個原則就是實踐我們在資安經常聽到的 least principle原則，使用正確的方法在每個AWS resource強制進行SoD(sepreate of duties)．建置中心化的身份驗證管理，並且消除依靠幾百年不變的帳密．
• 啟用可追溯性(enable traceability): 能夠在我們的AWS雲端環境中有即時的監控、告警、稽核與變更的功能．能夠整合監控系統中的日誌與指標，自動的找出原因並讓我們採取行動．
• 在所有層面加上資安(Apply security at all layer): 進行縱深防禦(defense in depth)，並且有多種的控制項．將這些控制項部署在所有的AWS服務與層面中(如VPC/ELB/ALB/VM/OP/Application/code等)．
• 自動化的資安最佳實踐(Automate security best practices):進行軟體方式的自動化資安機制，從而讓我們可以安全的進行快速的大規模運作並達到成本效益．也要打造安全的架構，包含實施各種控制項，這些控制項是用腳本或代碼方式進行．而這些腳本與代碼也需要有版控．
• 資料傳輸與靜止的狀態進行加密(Protect data in transit and at rest): 這裡要先做好資料分類才能有相對應的防護機制，例如encryption/tokenization/access control．
• 別讓人員直接接觸資料(Keep people away from data):利用一些機制或工具進行這樣的作業，這些會減少人員直接接觸或手動處理資料的風險．因為人為的方式會減少人為的錯誤(例如設定錯誤或誤刪)，尤其處理敏感資料時．
• 準備接受資安的衝擊(Prepare for security events)：建立資安事件處理機制與系統還有資安調查政策跟流程，已達成組織在資安上的要求．定期模擬資安回應練習，並且能只用一些自動化工具來加快我們的事件回應速度/偵測/調查/回復．

六個最佳實踐

它們分別是：

• Security Fountation
• IAM(identity and access management)
• Detection
• Infrastructure Protection
• Data Protection
• Incident Response

在將我們的系統平台放到雲端前，我們必須要先考量到資安層面．我們需要控制誰可以在雲端中做些什麼事．我們也要能辨識資安事件，繼而保護我們的系統，並且能在雲端中對資料達到C.I.A(confidentiality, Integrity and availability)的C與I．

另外 AWS的Shared Responsibility Model讓我們的組織能清楚明白雲端可以達成組織資安與合規上的要求．因為 AWS在這個model中負責整個實體基礎架構的安全．下圖為AWS與客戶(AWS的使用者)需要負責的分界線．

Security Foundation

資安要達到什麼要求，其實除了最佳實踐之外最重要的是在組織已經根據本身的業務與系統要求在卓越維運的層面上有清楚與良好的定義，並且應用在所有的領域之中．

我們也需要亦步亦趨了解AWS對各個產業的安全建議與威脅情資，來幫助我們推演我們的威脅模型與控制目標．而自動化的資安流程/測試/驗證讓我們能進行大規模的資安維運．

以下問題是我們在AWS的資安層面進行考量時可能會遇到的一些問題：

Q1: 我們如何安全的維運我們的系統平台？
為了安全的操作我們的系統，我們必須將總體最佳實踐應用於每個安全領域。 採用組織和系統等級的卓越維營中定義的要求和流程，並將它們應用於所有領域。 及時了解來自 AWS、產業和威脅情報的建議，有助於我們改進威脅模型和控制目標。 自動化安全流程、測試和驗證讓我們能擴展我們的安全操作。

最佳實踐有：

• 不一樣的系統服務使用不同的AWS account
• 強化AWS account的安全性(例如啟用MFA)
• 辨識與驗證我們的控制目標 — 根據組織威脅模型中識別出的合規性要求和風險，導出並驗證需要應用於系統服務的控制目標和控制項。 控制目標和控制項的持續驗證可幫助我們衡量減輕風險的有效性。
• 針對資安威脅持續更新
• 針對資安建議持續更新
• 建立一套程序來自動化的測試與驗證各個資安控制項
• 使用威脅模型還辨識與優先考量風險
• 定期的評估與進行新的資安服務與功能

在AWS中，我們最好依每個不同的系統平台用 AWS account切分．這樣在個別系統的功能面與合規面甚至是敏感資料要求都可以達到．

IAM(identity and access management)

AWS的IAM服務是整個AWS資安中最核心的服務，它控制著被認證與授權的使用者與組件可以access到aws resource中，並可執行哪些作業．例如，我們可以定義principle(可能是使用者/角色/aws帳號/服務等)，並建立針對這些principle的管理政策，而要執行這些就需要一個好的憑證管理系統．而特權管理又是形塑認證與授權的核心．

AWS的IAM支援這種特權管理方式，這可以讓我們控制使用者與程式連接到aws的服務與資源．而我們對這些控制政策應該做到細致化的程度，像是控制到使用者/群組/資源的等級．我們也可能需要有複雜的密碼規則，像是避免重複的使用密碼甚至加上MFA(multi-factor authentication)．或是我們也可以連合外部的帳密認證服務．

以下這些問題是我們在考量 AWS IAM的部分需要回答的：

Q2:我們如何針對使用者跟機器做身份驗證管理？
針對使用者：aws管理員、開發人員、維運人員和終端用戶需要身份驗證才可以連結 AWS 環境和應用程式。這些可能是組織內部人員或外部人員，他們通過瀏覽器、客戶端應用程序或CLI工具與我們的 AWS 資源進行交互。

最佳實踐有：

• 使用強韌的登入機制(例如啟用MFA)
• 使用暫時性的credentials(例如AWS STS服務)
• 安全的存放與使用secrets
• 有一個中心化的驗證服務提供者
• 定期的稽核與更換credentials
• 將user groups 與attributes納入資安機制中

針對機器：我們的服務應用程式、操作工具和系統服務需要身份驗證才能向 AWS 服務發出請求，例如讀取資料。這些身份驗證包括在我們 AWS 環境中運作的機器，例如 EC2 instance或 Lambda function。

Q3:我們如何針對使用者跟機器做權限管理？
我們不可以將最大權限給予給任何使用者或系統．而應該使用least-privilege的方式，並加上一些best prictices(像是複雜的密碼與MFA)．而使用程式連接的方式(像是 API calls)連到AWS resource時應該使用暫時與有限制的憑證，而AWS STS(security token service)則可提供這一類的服務．

最佳實踐有：

• 定義存取需求
• least privilege access機制
• 制定緊急的存取流程
• 持續減少不必要的權限(如流程變更後或有新流程出現)
• 定義我們的權限範圍(如哪些AWS服務只可以在哪個region被那一個團隊所使用)
• 基於生命週期的方式來管理存取控管(例如人員的異動或離職)
• 分析外部組織需要cross aws account的存取
• 安全的分享我們的AWS resources

Detection(偵測)

使用偵測的方式在於我們能夠可能的資安威脅或資安事件．偵測控制是組織的基本治理框架的一部分，這可以讓組織能夠進行有效的流程管理，內外部的稽核與合規要求，甚至也是有效的威脅偵測與回應．例如，對數位資產及其詳細屬性進行資產盤點可促進有效的決策（和生命週期管理），以幫助建立維運基線。 我們還可以使用內部稽核，檢查與資訊系統相關的控制，以確保實踐符合組織的管理政策和要求，並且組織已根據定義的條件設置正確的自動告警。 這些控制項是重要的回應因子，可以幫助組織識別和了解異常活動的範圍。

而 AWS的許多服務可以達成以上所說的要求．例如稽核與日誌監控與告警有CloudTrail與CloudWatch，前者是各種對aws resource的API calls紀錄，後者是各種服務指標的監控．AWS Config則是提供我們在AWS上的組態歷史．GuardDuty是一個託管的威脅偵測服務，能提供持續不斷監控在AWS上(包含我們的aws帳號與系統服務)惡意或未經授權的行為．

以下這些問題是我們在考量 AWS 偵測的部分需要回答的：

Q4:我們如何偵測與調查資安事件？
從日誌和指標中擷取和分析資安事件以獲得可見性。 對資安事件和潛在威脅採取行動(take action)，來保護我們的系統服務。

最佳實踐有：

• 設定服務與程式的日誌(如CloudTrail/CloudWatch Logs/Security HUB等)
• 分析、尋找各項指標與日誌紀錄(簡單來說就是找出異常)
• 針對事件建立自動化回應
• 資安事件的產生都可有下一步的行動

日誌管理對於架構良好的系統服務很重要，原因在於從安全性或資安鑑識到合規的要求不一而足。 分析日誌並對其做出回應至關重要，這樣我們就可以識別潛在的資安事件。 AWS 提供的功能讓我們能夠定義這些日誌資料保留的生命週期或定義這些資料將在何處留存、歸檔或真的刪除，從而使日誌管理更易於實施。 這使得可預測和可靠的資料處理更簡單、更具成本效益。

Infrastructure Protection

這包含了我們的控制方法論，像是縱深保護，資安的最佳實踐，組織內外的監管與合規要求(如ISO27001/ PCI-DSS等)．這些方法論決定了我們針對基礎設施的安全維運．

要達到上面的目的，AWS提供了 stateful/stateless的網路封包檢查服務(當然也可以用Marketplace上的)．我們也應該使用VPC來保護我們的基礎設施以期根據我們的方法論來達成安全，大規模雲端環境運作．像是在VPC裡要設定gateway/routing tables/public and private subnet等等這一些．

以下這些問題是我們在考量 AWS 基礎設施保護的部分需要回答的：

Q5：我們如何保護我們的網路資源？
任何具有某種形式的網路連接的系統服務，無論是網際網路還是內部專線，都需要多層次防禦來幫助抵禦基於外部和內部網路的威脅。

最佳實踐有：

• 建立的網路架構是有層次的
• 在所有的網路層次進行流量管控
• 自動化的網路保護機制
• 進行網路的檢查與保護

Q6:我們如何保護我們的運算資源？
系統服務中的運算資源需要多層次防禦來幫助抵禦外部和內部威脅。 運算資源包括 EC2 insatnce、container、Lambda functions、資料庫服務、IoT設備等。

最佳實踐有：

• 進行系統的漏洞管理
• 減少攻擊面積
• 多使用託管服務(如RDS/Lambda/ECS等)
• 自動化的運算資源保護
• 人員可以遠端執行流程化的操作(如IaC)
• 驗證軟體的完整性

多層次防禦是 AWS強烈建議建立在任何型態的環境中．從基礎設施保護這一個角度來看，其實這個方式在地端跟雲端都是一樣需要的．我們需要定義我們的網路邊界，監控進出的網路流量，並盡可能有廣泛的日誌收集/監控/告警，而這些都是一個有效能的資安管理計畫的基本要素．

使用AWS雲端平台的客戶能夠客製或強化 EC2、ECS容器或 Elastic Beanstalk instances的配置，並將此配置保存到不會變的 AMI。 然後，無論是由 Auto Scaling 觸發還是手動啟動，使用此 AMI 啟動的所有的VM都會有強化後的配置。

Data Protection

架構任何系統之前，我們必須將資安考量列為基本的影響因素之一．例如，資料分級分類(根據組織的定義)提供了我們應該用什麼方式保護我們的資料．這些可以對資料進行加密與access control的工具至關重要，因為如果達不到這些要求會讓組織遭受財物損失甚至會違反合規與監管要求．

AWS建議以下方式來強化我們的資料保護：

• 我們需要對我們在 AWS上的資料有全權的管控
• AWS可以讓我們對資料加密保護的作業變得更簡單，像是使用AWS KMS來自動管理加解密的資料金鑰
• 需要詳細的日誌紀錄(誰/何時/對資料做了什麼)
• 針對不同的資料等級設計適當的資料可用性．S3 standard, Stanard-IA, One Zone-IA, Glacier都有不同等級的資料可用性
• 啟用版本控管，這可以讓我們進行有效的檔案生命週期管理，有可以控管有意或無意的資料誤操作(overwrite/delete等)

以下這些問題是我們在考量 AWS 資料保護的部分需要回答的：

Q7:我們如何分類我們的資料？
分類提供了一種基於關鍵性和敏感性的資料進行分類法，可以幫助我們確定適當的資料保護和存放控制。

最佳實踐有：

• 根據系統服務來分類資料
• 定義資料保護的方式
• 自動化的辨識與分類
• 定義資料生命週期管理

Q8:我們如何保護我們的靜態資料?(Data at rest)
通過實施多種控制措施來保護我們的靜態資料，以降低未經授權的訪問或處理不當的風險。

最佳實踐有：

• 進行安全的金鑰管理
• 強制靜態資料的加密
• 自動化的靜態資料保護
• 強制進行存取控制
• 使用一種能讓人員不必直接接觸資料的方式(例如使用Dashboard的方式查詢資料)

Q9:我們如何保護我們的傳輸中的資料?(Data in transit)
通過實施多種控制措施來保護傳輸中的資料，以降低未經授權的訪問或丟失的風險。

最佳實踐有：

• 安全的金鑰與憑證管理
• 強制傳輸中資料的加密
• 自動化偵測不經意的資料存取(如使用 GuardDuty 自動偵測基於資料分類等級將資料移動到組織定義的邊界之外的嘗試。)
• 加密的網路通訊(如TLS或IPsec)

AWS 提供了多種方法來加密靜態和傳輸中的資料。 AWS提供了一些功能，可以更輕鬆地加密我們的資料。 例如， S3 有erver-side encryption(SSE)。 ELB可以處理整個 HTTPS 加密和解密過程（通常稱為 SSL termination）。

Incident Response

即使組織已經有非常成熟的預防和偵測控制，我們仍應制定流程來回應和減緩資安事件的潛在影響。 我們系統服務的架構會極大地影響開發/維運/資安團隊在事件期間有效處理、隔離或控制系統以及將系統恢復到已知良好狀態的能力。 在資安事件發生之前部署工具和設定訪問權限，然後在資安模擬日定期練習事件回應，將幫助我們的架構能夠適應及時的調查和回復。

AWS建議以下方式來強化我們的資安事件回應能力：

• 需要詳細的日誌紀錄(誰/何時/對資料做了什麼)
• 針對資安事件有自動化的回應工具或方案，這些自動化的工具可以透過AWS API calls來完成事件回應
• 我們可以用 CloudFormation 來建立一個乾淨的環境”。 這使我們可以在安全、隔離的環境中進行資安鑑識。

以下這些問題是我們在考量 AWS 資安事件回應的部分需要回答的：

Q10:我們如何從資安事件來進行預料，回應，回復？
資安準備工作對於及時有效地調查、回應和從資安事件中恢復至關重要，以最大限度地減少對組織業務的干擾或影響。

最佳實踐有：

• 辨認主要人員與外部資源
• 發展資安事件管理計畫
• 預備好資安鑑識的能力
• 自動化圍堵資安事件造成損害的能力
• 預先給予資安團隊相關的系統檢視權限
• 給與資安團隊正確且合適的資安工具或方案
• 進行資安災害演練

確保我們能夠快速授予資安團隊訪問權限，並自動隔離instance以及擷取資料和系統狀態以進行資安鑑識或辨識。更多詳細的資安事故管理可參考本部落格另一篇"資訊安全事故管理"文章。

PS:下圖為AWS各項資安服務的關係圖

然而就筆者的理解，AWS的資安最佳實踐還是偏戰術層面，還是IT部門的事情．若要進入戰略層面，此本書籍就偏戰略面屬於企業整體運作．

※本文由 運用雲端服務加速企業的數位轉型 授權勿任意轉載，原文《AWS的雲端架構框架-資安篇》

這篇文章 【學長姐帶路】AWS的雲端架構框架-資安篇 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。