臺灣資安大會
過去資安是許多公司採用雲端服務的最大顧慮,然而,上雲已是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)來進行相關的處理。最後,透過紅隊來評估防禦量能,隨後進行成熟度的衡量與提升。事實上,我們可以讓這個改善流程變成一個循環,得以持續不斷進行,朝向越來越自動化,越來越完備的目標邁進。
關於雲端安全的強化,由於每個企業與組織的處境不同,可能無法一次導入整個改善流程,對此,蘇學翔也提出短、中、長期的行動目標。
短期而言,我們可以聚焦在雲端服務環境當中的資產盤點,如果企業與組織剛開始使用雲端服務,盤點資產的工作會很輕鬆,若已經使用雲端服務一段時間,可能就要花較多心力去進行這部分處理;中期而言,重點在於導入體質強化流程,企業與組織可推動資產盤點與風險評估的工作,之後進行優先順序排定與矯正,若無法判斷狀況與決定處理方式,建議尋求外部資安廠商的協助;長期而言,主要目標在於提升雲端服務使用與安全性的成熟度,朝著集中且自動化的方向邁進。
熱門新聞
2024-11-10
2024-11-10
2024-11-11
2024-11-10
2024-11-08
2024-11-08