【臺灣資安大會直擊】持續推動三項重要工作，雲端資安成熟度可望節節高升

過去資安是許多公司採用雲端服務的最大顧慮，然而，上雲已是IT主流趨勢，無論是出於自願或非自願的理由，現在越來越多企業與組織都選擇擁抱雲端服務，但大家是否以更安全的方式使用呢？若要持續提升雲端安全，坊間有很多建議，實務上該怎麼做？在今年臺灣資安大會雲端資安論壇上，奧義智慧科技資深資安研究員蘇學翔與林殿智，特別提出一套簡單易懂的「雲端資安體質強化流程」，透過系統化的方式帶著大家了解提升整體雲端安全的基本觀念，並且公開實際運用上的訣竅。
基本上，這個流程是由三個階段所組成：評估與量化、決策與執行、量測與改進。

奧義智慧之所以提出這樣的處理方式，主要是有鑑於市面上這類資訊繁多，涉及發布單位、內容、時間等差異，因而出現許多資安指引，讓人無所適從。

例如，各大雲端服務平臺、網際網路安全中心（CIS）這類具有公信力的組織，紛紛提出雲端安全的指南和基準（Benchmark）；有些資安社群提供這類資訊，像是：OWASP Cloud Top 10 Risks、雲端安全聯盟（CSA）提出的Egregious Eleven、Pandemic 11；有些公司與個人提供過往在此領域進行漏洞懸賞、處理客戶案例所得到的一些觀點、最佳實務，將它們整理成各種指引，像是DisruptOps的Top 10 Cloud Attack Killchains、針對AWS的延伸進修指南Ramp-Up Guides、tl;dr sec的Cloud Security Orienteering。

時間又是另一個變數，我們面臨的雲端安全威脅會隨著時間改變，因此，大家在不同時期提出的因應方式也有所不同。例如，AWS在2015年建議用戶在帳號做好組織管理，近期則調整為運用多個帳號去管理不同專案。

雖然在不同時間點，廠商、社群、個別專家提出的建議內容可能會不太一樣，但蘇學翔與林殿智認為大家談的東西其實都差不多，只是在企業或個人會有一些不同的細節，拆分得更細，因此，他們決定把這些資料統整起來，歸類為三大階段。

推動雲端安全的過程該如何進行？蘇學翔表示，首先我們要「評估與量化」受到威脅的程度，接下來，依據程度高低去排定處理順序，進入矯正的「決策與執行」，最後可透過外部資安廠商或內部的紫隊進行資安「量測與改進」，接著就能去做資安成熟度的評估，之後可再重複執行這個流程，以便持續精進企業組織架構的雲端安全。

關於這樣的強化安全流程，也呼應到奧義智慧創辦人邱銘彰在2021臺灣資安大會主題演講所提到的SecOps方法論，當時是針對企業AD安全與組織整體安全評估而言，但其實大部分資安防護的推動，都是依照這樣的流程，雲端安全也適用。

基於上述的作法，對應到雲端安全，可以怎麼做？蘇學翔表示，我們要能夠評估與量化現在企業組織在雲端環境受到威脅的程度，就必須要更明確了解到裡面有哪些資產，以及這些資產當中，有那些是組織外緣、而且是內部的人所不知道的部分；等到做好資產盤點、威脅與風險的量化之後，我們接下來就可以作一些決策，推動更多工作，像是矯正或整體資安風險的評估，才能針對問題進行改進，以及持續循環地執行這個提升安全性的流程。

評估與量化：掌握雲端資產，衡量風險與敏感度高低

想要提升雲端服務安全，首先，要從掌握當中的數位資產開始著手，隨後可以進行資安風險的評估、量化，之後再決定處理的優先順序。

盤點資產，運用多種方法在雲端服務找到要保護的對象

如同企業過往推動資安與個資防護的經驗，資產盤點是相當重要的環節，也就是所謂的探查（Discovery），雲端安全也不例外，而且，比起傳統聚焦於內部網路、自行管理的IT環境（On-Premise），因為雲端服務的網路邊界更為模糊，以及IT資源、應用系統或服務的配置更為動態，使得這類工作不易徹底執行。

舉例來說，很多時候，企業與組織的IT人員並不知道對某些使用者授與何種權限，使得某人可能具有某種權限，而得以在特定區域去啟動虛擬機器（執行個體）；有時需要與外部廠商或單位進行合作時，可能也會為第三方使用者開設帳號、設置虛擬機器來執行他們的服務……，若不釐清各種現行狀況，企業與組織將很難歸納到資產盤點的範圍之內。

因此，在雲端環境中，資產盤點的工作更顯重要，我們必須設法集中管理與維護，而且，更重要的是，要定義出高敏感資產，因為這些是真正需要花費更多心力去進行監控、管理、權限縮減的對象。

關於盤點雲端服務環境中的IT資產，蘇學翔列出7種方法。首先是針對我們已知的雲端服務帳號進行盤點；接下來，我們可以詢問公司的帳號管理者，看看公司網域是否有關聯的其他帳號——有些公司使用雲端服務時，可能不只啟用一個帳號，而同時有多個帳號、多個子網域，此時，你需詢問帳號管理員，確認有那些帳號在我們的掌握之中。

為了避免遺漏，我們還可以搜尋公司電子郵件，看看當中是否收到一些註冊信函，當中會提到新設置的租戶，或是新開立帳號的相關管理、訂閱狀態等等；再來是搜尋網路紀錄（Network Logs），從這裡確認是否有存取雲端服務中控的記錄。蘇學翔表示，透過這些列入記錄的IP位址，以及找到的登入帳號，其實一樣能觸碰到公司在雲端服務使用環境，若能善用這樣的技巧，IT人員即可收集一些原本不在轄下，尚未管控、目前沒掌握到的帳號記錄。

再來是從帳單支付的角度去尋找答案，我們可以詢問企業與組織的財務團隊，確認是否有雲端服務支付記錄。通常雲端服務的使用是根據每個帳號進行訂閱來認定，因此，財務團隊手上理應有每個帳號支付雲端服務使用的消費記錄，我們就能得知目前企業與組織有哪些雲端服務的帳號，而基於這樣的發現，也意味著我們就能知道更多應管理的帳號。

如果這些方法都無助於雲端服務的資產盤點，我們可改採單刀直入的方式，公開詢問公司員工相關事宜。例如，我們可以提出下列問題：誰有雲端服務的帳號？這些帳號可開設哪些類型的服務？是否曾在某個時段啟動特定雲端服務，卻未告訴直屬主管？這樣一來，或許能得到一些處於更邊緣位置的雲端機器資訊。

除了大家直接使用的雲端服務帳號，我們還要找出與現有帳號有關聯的其他帳號，它們可能也是需要列入盤點的對象。

為什麼要如此大費周章地進行詢問？蘇學翔重申，這是因為雲端服務的網路邊界很模糊，很多時候，我們無法透過單一管道獲取所有想要得到的資訊，所以，若我們能夠越早集中管理這些資訊，後續弱點、威脅的處理、評估等動作越容易進行。所以在雲端上面盤點資產的部分是非常重要的一環。

除了經由口頭、書面形式詢問企業與組織內部人員，蘇學翔也列出幾個開放原始碼軟體工具，供大家參考，像是aws-inventory、Streampipe、Prowler、ScoutSuite，這些都是較多人使用或目前仍在持續開發的。

評估風險，找出使用者對雲端服務的錯誤設定

經過資產盤點的程序之後，我們可以透過一些工具或業者提供的官方指引，針對雲端服務因現行使用方式不當而衍生的資安風險，進行評估（Assessment）。

回顧過去發生的雲端安全相關重大事故，錯誤設定（misconfiguration）是經常發生的問題，有不少雲端資安威脅事件，其實都與此有關。

為何這種狀況總是不斷發生？蘇學翔認為，在雲端環境當中，當用戶要使用服務時，可能均已套用預設組態、完成大部分設定，因此，許多用戶可能會認為，若無特殊需求，就不必調整這些設定。

然而，這時我們應該注意預設組態究竟是不是自己想要的，因為，實際上，這些設定不一定完全符合用戶真正的需求。從另一方面來看，我們也必須了解預設組態究竟開放哪些權限，因為有些預設組態，其他企業與組織用了沒問題，但在特定使用情境並不合適，從而產生問題。

因此，為了更清楚掌握雲端服務錯誤設定現況，蘇學翔認為，可從三大面向去進行評估：身分邊界、網路邊界、代管應用程式或服務。其中，又以身分邊界最重要，也就是所謂的身分與存取管理安全性（IAM Security），過往發生的雲端資安事件當中，有不少都與IAM Security有關。

這是因為，若無法妥善控管身分與存取權限，出現綁定角色不當或委派權限過高時，都可能會產生很大的風險，甚至影響跨租戶的安全性，或是能夠啟用其他的元件，此時，在管理作業上，就會出現非常複雜的狀況，

而在網路邊界的部分，雲端服務相較於企業與組織內部環境而言，面臨更大的界線模糊的狀況，很多時候，用戶很難掌控網路的流量與流向、不知該如何限縮存取範圍，難以局限使用者及應用程式服務的連入、連出，再加上很多IT人員熟悉內部環境的網路運作方式，卻不熟悉雲端環境網路運作方式，而使得相關政策就會出現設定錯誤的狀況。

第三個資安風險面向，則是與部署至雲端服務的應用程式與系統服務有關，它們本身也可能基於各種原因而存在安全性漏洞，此時，駭客與惡意軟體可從外部、在無需通過身分驗證的狀況下，直接從這個破口攻入。

值得注意的是，這方面的防護屬於用戶本身的責任，是你自己要去承擔的，與雲端服務廠商提供給用戶的安全使用環境無關。若要降低這方面的風險，用戶需關注軟體的安全性更新消息，若釋出修補程式或緩解機制時，要及時進行安裝或調整設定。

當我們認識到雲端安全風險涵蓋了這些層面，此時該如何進行評估？蘇學翔建議大家可以運用現有的工具、雲端業者的官方指引，以及各種相關的檢查清單，例如，網際網路安全中心目前已經提供各個雲端平臺的安全基準，舉凡AWS、GCP、Azure、OCI，都有對應版本，企業與組織能參考這些建議進行資安威脅的盤點。像是CIS Benchmark For AWS裡面有很多稽核的步驟、最佳實務，讓大家能夠依循、確認自己的環境是否遇到這類問題，並提供矯正的建議作法，至少可以針對第一層面的安全威脅進行處理。舉例來說，root帳號的存取金鑰是不應該存在的，因為理論上root帳號用完之後就應該立即封存，平時以它產生的子帳號去管理系統就是最佳實務。

同時，我們也可以運用一些專家撰寫的雲端安全成熟度指南，像是Scott Piper撰寫的AWS Security Maturity Roadmap，能夠幫助大家在每個步驟、服務當中，實踐資安最佳實務，減輕一些錯誤設定與基本的威脅。

決定順序，排定優先處理的風險項目

當我們陸續完成資產盤點、風險評估，接下來的工作就是排定處理的優先順序（Prioritization），我們將會針對經由前述兩個步驟所產生的資安風險列表進行排序，例如，如果我們發現了企業與組織具有5到10個資安弱點，隨後要知道須優先修補的項目。

關於這部份考量，各個企業與組織的心態（mindset）將是關鍵。蘇學翔列出6種常用的依據。首先是單位過去遭遇的資安事件，因為這不應該再發生，所以當然要第一優先進行排除；第二，是公司內外目前面臨的各種潛在威脅；第三，是同業曾出現的資安事件，我們也可能會遭遇到類似的攻擊手法；第四是老闆在意的資安新聞，例如勒索軟體；第五，是保護單位所定義的高敏感資產，這部分資訊可源於先前進行資產盤點工作，作業過程中，我們會定義出高敏感的資產，而這些資產也是應該優先排除威脅的對象。

第六則是參考年度資安威脅排行榜。就像我們在推動網頁安全防護工作時，會參考 OWASP Top10，而面對雲端安全的工作時，能根據許多人認可的雲端安全10或11大威脅去做優先修補的順序排定，例如雲端安全聯盟的Pandemic 11、DisruptOps的Top 10 Cloud Attack Killchains，基於這些雲端環境常出現的資安弱點，優先進行修補。

關於雲端安全風險的量化，蘇學翔引用Learning from AWS Customer Security Incidents在2020年的統計，進行說明。這份數據回顧前6年以來的AWS客戶雲端威脅事件，其中，有效帳號（Valid Accounts）累積發生的次數最多，蘇學翔表示，當時有些開發團隊會將API存取金鑰推送到GitHub或GitLab中，而且是可公開存取的狀態，所以只要有人搜尋到這把金鑰，就能藉此及金鑰對應的身分與權限去做一些事情，這種弱點屬於三大風險面向裡面的身分邊界問題。排名第二的問題，則是濫用公開存取的應用程式（Exploit Public-Facing Application），也是屬於錯誤設定的部分。

基於上述狀況，我們可以看到這6年間IAM安全或預設組態的錯誤設定，都是相對更容易發生在雲端環境的，而且，大家可能會訝異這些事件，有很多都是直接拿到有效帳號而獲得中權限或高權限，再做身分提權，並不像傳統資安威脅，常透過一些零時差漏洞攻入、進行提權，採取很高深、很難以達成的攻擊手法。

決策與執行：按照風險高低依序進行修補與緩解

當防護對象、風險程度、問題排序趨於明確，接下來，我們可以著手進行實際的修補與矯正。

基本上，此時是基於優先順序來選擇所要處理的弱點、進行修補，等到完成之後，我們還能參考一些資安指引的建議，將最佳實務引入軟體與應用程式開發流程當中，形成所謂的 SecDevOps，接著再使用資安基準（如CIS Benchmark）或是資安框架（如NIST提出的資安框架），參考當中的內容敘述去進行修正或緩解，並且定期檢視整體流程是否需要改良。

以有效帳號的問題為例，這屬於IAM安全性議題，當我們進行資安風險排序；決定修補之後，理論上，要先優先修補的對象是IAM，接著再根據前面提到的幾種原則，如公司本身曾遭受或同業發生的資安威脅，去決定漏洞的修補順序與優先程度，而在執行修補的部分，可根據資安基準或框架的建議來實作。

量測與改進：確認問題是否獲得解決，逐步提升成熟度

當我們做完修補、矯正之後，接下來是驗證成效，此時可委派第三方廠商的紅隊（Red Team），或透過企業與組織內部成立的紫隊（Purple Team），進行資安問題與風險程度的驗證，確定修補是否完成。透過這樣的方式，除了能夠檢驗漏洞是否獲得修補與找出潛藏、沒被發現到的資安問題，蘇學翔表示，也可以同時檢驗企業與組織本身的藍隊（Blue Team）或代管服務商（MSSP）防禦的量能。

最後一步則是評估雲端服務使用的成熟度。各大雲端服務平臺都提供成熟度檢驗標準，能協助用戶了解該如何做才會越來越好。

對此，蘇學翔說，其實，雲端服務運用成熟度的背後隱含的意義，在於用戶個種操作的自動化程度是否夠高，這當中也牽涉到是否善用業者本身提供的服務來進行監控。事實上，雲端業者有地利之便，能直接監控服務內部進行的各種活動行為，若能善用這些機制，比起從雲服務外部監測，將可獲得更多資訊，而且雲端業者也會整合相關資訊。

若要評估雲端服務使用的成熟度，幾家主要的雲端業者，如AWS、Azure，都提供了完善架構框架（Well-Architected Framework），安全性均是當中的重要支柱。以AWS為例，他們列出相關的設計原則、定義、最佳實務、資源。

而關於雲端安全成熟度評估，蘇學翔也特別提到目前有一套專屬模型Cloud Security Maturity Model（CSMM）可供大家參考，這是由研究機構IANS、資安研究顧問公司Securosis共同開發，並與雲端安全聯盟合作而成的架構，可幫助企業與組織了解雲端安全提升的過程，使其能夠自覺地決定本身所要達成的成熟度目標。

簡而言之，CSMM分成5個等級，在逐步提升雲端安全成熟度的過程當中，關鍵就是變得越來越自動，從最初無自動、簡單自動化，進化至手動執行腳本、實現半自動化，之後邁入全自動化，達成自動監控與應變，甚至是任何地方均可執行自動化（Automation Everywhere）、可集中管理各種自動化（Central Managed Automation）的程度，促進IT維運效率。舉例來說，用戶可透過一些API金鑰的委派，做到自動化監控、回收等處理。

反覆執行，強化資安體質之餘，推動集中、自動化管理

為了讓大家更了解這套改善雲端安全的三階段流程，蘇學翔提出兩個例子來說明實際應用方式。

第一個範例是資安廠商Kaspersky外洩AWS雲端郵件服務SES的Token事故，當初該公司並未發現自己授權第三方的人員去運用API金鑰，然而，這個金鑰又被洩漏到外部，於是，有人利用卡巴斯基的名義寄送廣告信。

導入這個流程之後，會產生哪些對應作法？在資產探查盤點階段，我們須知道自己採用Amazon SES雲端服務；到了資產風險評估階段 ，我們要知道有個Token被送至第三方合作廠商；以及已經因此衍生IAM安全相關問題，應該優先進行監控、限縮存取；隨後決定與執行相關防護，例如，需持續監控這樣的使用情境，若後續不需用到此種做法時，要趕緊進行Token的回收，並且確認使用者在指定期間是否用到這類功能，一旦超過期限，要設法將已發出的身分與權限進行回收；後續若能將這些工作轉為自動化處理，就會是一個雲端安全程度較高的流程。

另一個範例則是奧義智慧幫一家公司上雲的應用，他們在裡面扮演雲端資安的顧問角色。過程中，這家公司在初期進行雲端服務資產盤點時，運用Streampipe、Yor等開放原始碼軟體工具，並寫了一些readme檔案，能讓他們在後續進行維運作業時，能夠很清楚知道公司有哪些位於雲端服務的資產。

接下來，他們使用一些工具來進行雲端資產的風險評估，他們寫程式、運用很多AWS的服務之餘，也用這家雲端業者認可的資安檢測工具，如ScoutSuite、SonarQube，去查驗基礎架構方面與軟體方面的安全性。

在評估階段及優先順序決定階段中，這家公司發現一些基礎架構設計問題，以及軟體層面問題，所以他們根據公司需求去排定資安威脅修補順序。談到這裡，蘇學翔提出一個關鍵訣竅，那就是「先廣後深（Go wide then deep）」，他說，有時不要在一個問題糾結太久，若是如此，很多基本的問題與威脅可能都沒有處理到，所以，他建議不要太深入某個資安問題，若真的遇到不懂的狀況，要去諮詢外部的資安公司或顧問來幫忙。

到了矯正階段，他們運用一些工具、指引、最佳實務（如CIS Benchmark）來進行相關的處理。最後，透過紅隊來評估防禦量能，隨後進行成熟度的衡量與提升。事實上，我們可以讓這個改善流程變成一個循環，得以持續不斷進行，朝向越來越自動化，越來越完備的目標邁進。

關於雲端安全的強化，由於每個企業與組織的處境不同，可能無法一次導入整個改善流程，對此，蘇學翔也提出短、中、長期的行動目標。

短期而言，我們可以聚焦在雲端服務環境當中的資產盤點，如果企業與組織剛開始使用雲端服務，盤點資產的工作會很輕鬆，若已經使用雲端服務一段時間，可能就要花較多心力去進行這部分處理；中期而言，重點在於導入體質強化流程，企業與組織可推動資產盤點與風險評估的工作，之後進行優先順序排定與矯正，若無法判斷狀況與決定處理方式，建議尋求外部資安廠商的協助；長期而言，主要目標在於提升雲端服務使用與安全性的成熟度，朝著集中且自動化的方向邁進。