雲端移轉（Cloud Migration）每天都在發生。根據分析師的預測，到了2021年會有超過75%的中大型企業將工作移轉到雲端環境–但要如何確保成功？不僅僅IT團隊、運營和安全等等影響因素，企業領導、財務以及企業內諸多其他組織也都會造成影響。在接下來的文章，將會圍繞如何成功進行雲端移轉這個主題，從多個角度來探討最佳實作、前瞻性思維以及使用案例。
雲端遷移將帶來的部分好處。技術上的優勢，包含可擴展性、高可用性、簡化基礎設施維護及符合許多產業認證的環境，就成本來說，也能將CapEx（資本支出）轉換成OpEx（營運支出）模式，而且無需資料中心成本。
雖然搬遷肯定會伴隨著許多的風險，但只要善加規劃，加上公司專心一志，就可以成功地踏上雲端運算的第一步。而公司的專心一志是必須要認知的重要一環。企業需要經由不斷地學習、成長及適應這新環境來整合雲端運算所提供的敏捷性。鳳凰計畫（Phoenix Project）和獨角獸計劃（the Unicorn Project）這兩本書中所提到的內容，就是說明企業成功轉型的必要性和步驟很好的例子。
繼續閱讀隨著雲端服務的普及率不斷成長，企業機構務必了解如何保護自己的雲端環境。這份研究探討了一些雲端經常遭遇的威脅，提供具體的分析建議來讓企業機構更了解該如何因應這些威脅。
雲端 的普及率正在穩定持續成長，不僅小型企業紛紛尋找更具成本效益的方案來取代實體 IT 基礎架構，就連大型企業也希望能善用雲端的彈性效益。但企業卻因而面臨了一項挑戰 (尤其是剛開始移轉至雲端的企業)，也就是不熟悉雲端的運作方式以及雲端與純企業內環境的差異。企業的雲端通常不只由單一環境所構成，而是結合了各種不同的服務供應商，而且經常還保留了實體資料中心。
類似的挑戰也出現在企業資安方面，有些資安風險來自於雲端部署環境的防護不足，有些則是因為不夠熟悉雲端服務的組態設定細節所引起。雲端工作負載或雲端應用程式可能因為各種原因而暴露於駭客攻擊的風險當中，包括：組態設定錯誤、技術使用不當、缺乏雲端系統相關的操作和防護經驗，有時甚至單純只是因為開發人員或雲端工程師的疏失。雲端系統的各項元件在許多方面都環環相扣，因此不易釐清明確的潛在攻擊途徑。對於才剛開始駕馭雲端平台及服務的 IT 人員來說，資安可說是一項艱難的任務。
在一份名為「解構錯綜複雜的雲端資安威脅」(Untangling the Web of Cloud Security Threats) 的白皮書中，我們列舉了一些企業在移轉至雲端或採用雲端服務之後可能遭遇的威脅和風險。我們發現，不論是哪一種雲端服務或平台，雲端資安最主要的問題之一就是組態設定錯誤，此問題不論是訂閱雲端服務的企業或是使用雲端式軟體的使用者都會受到影響。
Kubernetes是雲端環境最常用的容器編排（container orchestration）系統之一。因此跟其他被廣泛使用的應用程式一樣，它也成為吸引網路犯罪分子或其他惡意份子的誘人目標。雲端管理員在保護自己的部署時必須要特別注意三大領域的問題，因為它們可能對用Kubernetes驅動的容器化策略帶來威脅風險：
圖1秀出了Kubernetes官方文件所列出Kubernetes部署或集群（cluster）的元件。
所有的通訊都是透過kube-api-server封送，這是個提供API服務的控制面板元件。它其實就是作為控制面板前端的REST API，並且可以讓使用者定義和控制所有的Kubernetes管理功能。使用API最簡單的方法是在命令列用命令kubectl（或是在OpenShift使用oc）。
如果攻擊者可以成功存取API就幾乎可以做到所有想做的事情。例如可以安裝惡意容器來從資料庫提取資訊，或使用所有的資源進行虛擬貨幣挖礦活動。
確保只有集群內的電腦以及管理集群的電腦可以存取此API，這樣有助於阻止外部攻擊者。
為了做到一點，雲端管理員需要記住kube-api-server預設會使用兩個端口：
加強對端口8080和6443的安全防護並且注意有哪些事情不該做有助於防止入侵。
Kubernetes是個複雜的系統，它提供許多設定選項帶來了相當大的靈活度。但這些設定選項需要被正確地理解且以安全的方式設置，以免集群（cluster）遭受駭客入侵破壞。
光是身份認證設定一項在Kubernetes中就已經相當複雜了，因為有許多種可用的身份認證模式（基於角色、基於屬性或基於節點）。為了幫助管理此問題，雲端管理員可以用命令kubectl auth can-i查詢特定權限。Kubernetes使用者和服務帳號應該被鎖定只用所需的權限。
我們會特別在Kubernetes強調這一方面是因為我們已經看到太多不當設定的執行實例在全世界運行著。像圖2的Shodan快速掃描結果顯示出全球大約有3,000台主機的etcd（Kubernetes使用的鍵值伺服器，因此是不該對外暴露的服務）可以被公開存取。
雲端管理員另一件需要特別注意的事情是，如果沒有為特定命名空間（namespace）指定網路政策，則預設政策是允許所有對此命名空間（namespace）內所有Pod的進出流量。每個Pod都可以跟其他Pod對話，所以當攻擊者可以進入對外開放的Pod（比方說有網頁應用程式），就可以用它來連上其他Pod。這使得在發生入侵事件時更容易進行橫向移動。
最佳做法是預設拒絕存取，除了明確允許的流量之外。至少也必須有預設政策來拒絕進入流量。雲端管理員可以用Kubernetes官方文件所提供的程式碼來建立此政策。
就跟一般的伺服器和作業系統一樣，不管為保護Kubernetes集群付出了多少努力，它的安全等級取決於執行中和對外開放裡最脆弱的服務。容器和容器編排工具不僅有助於在異質環境中部署各種應用程式，還可以自由的排列組合使用應用程式。但它們不能解決所有的問題。事實上，容器的特性使得讓所有需要的地方保持更新變得更加困難，因為每個應用程式都有自己的一份程式庫副本。
如圖3所示，同一個程式庫可以安裝在不同基礎映像的多個映像內。而這些都需要被更新並安裝修補程式。這時候將趨勢科技Deep Security Smart check這樣的解決方案整合進DevOps流程可以有所幫助。
圖3. 程式庫被部署到多個映像，其中許多映像使用不同基礎，可能需要接受多方更新。
透過雲端專屬防護來保護集群（cluster）
容器透過更好的流程隔離在DevOps和安全性（DevSecOps）方面向前邁進了一步。而Kubernetes這樣的容器編排工具提供了一層重要的抽象化，使其在可擴展環境中更加有用。雖然部署起來可能複雜，但按照上述步驟有助於確保雲端環境安全。如Hybrid Cloud Security(混合雲防護)和趨勢科技Cloud One這樣為雲端設計的安全解決方案可以為這些執行實例帶來更加有效的保護。
Hybrid Cloud Security提供威脅防禦能力來保護執行時期（runtime）中實體、虛擬和雲端工作負載（workload）以及容器。還可以在開發階段掃描容器映像。
Cloud One，一個給雲端建構者的安全服務平台，可以為CI/CD管道和應用程式提供自動化的保護。它還可以協助更快地識別和解決安全問題，並且縮短DevOps團隊的交付時間。它包括了：
@原文出處：Guidance on Kubernetes Threat Modeling 作者：Brandon Niemczyk（雲端安全研究負責人）
我們最近寫了一篇在網路上發現8,000多個沒有保護好Redis執行實例的文章。在本篇文章裡，我們會介紹這些執行實例會如何被用來進行遠端程式碼執行（RCE），就如惡意軟體在真實世界裡所做的。這些惡意程式會將Redis執行實例變成虛擬貨幣挖礦機器人，並且透過”蠕蟲”散播功能來感染其他有漏洞的執行實例。
Redis是設計使用在受信任環境並提供了保護模式設定，而且即將更新到Redis 6.0，在新版本中會導入如存取控制列表（ACL）等新的安全功能。但在目前，如果使用者的Redis執行實例沒有加上TLS加密或密碼保護，一旦攻擊者進入了環境就可以使用超過200個命令來進行攻擊。目前Redis預設並沒有身份認證。即使有設定密碼，也要確認密碼足夠強到抵抗暴力破解攻擊。
我們在蜜罐系統裡觀察到駭客使用了下列情境，這些蜜罐系統是為了吸引和監視真實攻擊而設置：
攻擊者用Redis資料庫檔設定多個的鍵值來成為cron任務。資料庫值遵循著cron（執行排程命令的守護程序）和crontab（用於排程執行程式的檔案）格式規範。
全球的公共雲市場在今年有望成長17%，去到2,660億美元。這數字很令人印象深刻，不管Covid-19會對宏觀經濟在短期內造成怎樣的影響，這數字都標誌著世界的發展方向。但儘管許多企業都將自己描述為“雲端優先”，但他們肯定不是“只有雲端”。混合雲已經成為今日的主角：融合了多個雲端服務和多個資料中心。
這樣新的現實在推動敏捷、差異化和增長的同時，也帶來了網路風險。當IT主管想制定方向時，會尋求更全面、更簡單的方式來管理混合雲的安全防護。
可以理解組織為什麼熱衷於擁抱雲端平台。誰不想讓員工提高生產力且讓DevOps提供敏捷、以客為尊的服務？但數位轉型面臨著一連串的挑戰。轉變通常在整個組織裡以不同的速度發生。想在整個企業內獲得統一的能見度並以一致的方式管理安全策略變得很困難，尤其是當不同業務單位及部門會各自做決策時。現在估計有85%的組織使用著多個雲端平台，有76%的組織使用了2到15種混合雲服務。
為了管理這樣的複雜性，企業開始擁抱容器和無伺服器架構以更有效地開發新應用程式。但使用這些技術的DevOps團隊主要專注在產品上市時間，有時會犧牲掉安全性。使用第三方程式碼就是個典型的例子：可能讓組織陷入有缺陷甚至充滿惡意軟體的程式碼泥沼。
