雲端的資訊安全威脅包含以下九大層面：
本文逐一說明相關的威脅和解決方法：
1.網路
這是大家最熟悉的，例如 DDoS 攻擊、駭客嘗試登入系統、網路釣魚等等。
在 GCP 上，最基本的就是防火牆規則要設定好，怎樣才算好？
該開放的有開放，該阻擋的有阻擋，不知道要不要開的一律阻擋。
如果有能力負擔，可以開啟防火牆 Log，定期分析 Log 當是否有異常流量。
至於對外的網站，可以使用 Cloud Armor，
它提供 Layer 3 (IP位址)、Layer 4(TCP Port)、Layer 7 (HTTP Header) 層面的防禦規則，
還有內建 OWASP 發布十大風險的防禦規則，
你也可以引用第三方工具 Fastly、Cloudflare、Imperva 的白名單來管控允許的 IP 位址。
2.驗證和授權
驗證 (Authentication)：你是誰？你是公司的人嗎？
授權 (Authorization)：你有權限進入這個系統嗎？
針對驗證的部分，務必要求使用者開啟2步驟驗證，
光是這一條已經可以防禦一半以上的威脅了，
因為只有帳號密碼的驗證方式，只要幾天甚至幾小時就會被駭客破解。
至於授權，要盡可能遵守最小權限原則，給予剛好需要的權限。
要做到其實非常困難，因為 GCP 的權限很細，
截至 2024/3/18，Owner 已經有9298個權限。
多數人為了便宜行事，大家都是 Project Owner，
如果有人帳號被駭，他同時在多個專案擁有 Owner 角色，
那就麻煩大了，如果駭客用他的帳號狂開機器，
一個專案可以好幾千台機器，一天就可以噴掉上百萬。
為什麼駭客要開機器，當然是挖比特幣，GPU 多香啊！
(挖擴在 GCP 是禁止的)
另一種情況是 Service Account Key 被駭客拿到，如果這個 Service Account 在 IAM 擁有能建立機器的角色，一樣是恭喜發財。
如果可以，在一家公司裡， 機構管理員最多2位，
每個專案的擁有者最好也是2位，不能太多，也不能只有1位。
如果有1位的帳號有問題，或是被駭，至少另1位還可以進去捕救。
有個非常特別的 Case，我曾經接到客戶求救，
說專案被離職的工程師帶走了，
可以跟 Google 發 Ticket 把權限拿回來嗎？
不行，Google 也不能干預客戶專案內的事情，
所以必須靠自己把專案權限管好。
3.應用程式
這部分很基本也很重要，沒有人希望自己用的應用程式有問題吧！
應用程式如果被駭或中毒，是非常危險的事。
其中最重要且有效的方法，也是管理好應用程式所使用的 Service Account，和它的 Key。
不要直接將 Key 寫在程式碼中，這樣太容易被駭客竊取了。
好一點的做法是將 Key 儲存為環境變數，讓 Key 不容易被找到。
或是使用 Workload Identity，讓外部的應用程式不用 Service Account Key 就可以存取 GCP 的服務。
4.資料加密
這又分成2種：
(1)資料加密不被駭客破解
在 GCP 上都有 Google 內建的加密機制，
所以如果有人真的拿走一顆硬碟，
是很難破解出裡面的內容的。
因為儲存在上面的資料，會先分成不同的塊(Chunk)，
然後再存到三個不同地方，你不會知道，
一個檔案到分別存在哪三個硬碟，
所以資料根本就不完整，更不用說把它還原回來。
如果你覺得 Google 預設的加密還不夠，
可以使用 Cloud KMS 來建立和管理加密金鑰，
還可以使用超高加密等級的 HSM (Hardware Security Module) Key，
來符合法規需求(FIPS 140-2 第 3 級)。
(2) 資料不會被駭客加密，或是被加密但可以從其他地方還原。
假如駭客都進來了，如果希望資料不被加密，
就是要設定好資料讀取和寫入的權限，
尤其是相關的 Service Account 擁有的權限角色，
以及資料所在地例如 Cloud Storage Bucket 或是 Bigquery Table 等，
設定好能存取的人員或 Service Account有哪些。
再來就是要把資料多存幾個地方，
這是用屁股想也知道，卻沒人要做的事情，因為怕要花錢。
GCP 上已經有很多服務可以跨 Region 儲存了，
例如 Cloud Storage、BigQuery、Snapshot、Image，
甚至 Cloud SQL 資料庫也可以跨 Region 即時複製 Read Replica，
當然這些都要費用，但總比資料被加密，要乖乖付贖金好吧！
5.供應鏈
請至少檢查這幾項：
公司的應用程式都是正版的嗎？
供應商都是有公信力的廠商？有通過資安認證？
員工都有沒有下載來路不明的免費軟體？
公司是否有安裝防毒軟體或各項資安監控工具？
公司用的作業系統映像檔是不是都由 Google 提供？
容器映像檔是否有掃瞄過？
這些應用程式，是否會主動對外存取？
自行開發的程式碼，是否有使用第三方的程式碼片段？
對哪些IP或網域存取？
對內又向哪些內部系統存取？
另一方面，也可以從軟體開發生命週期
(Secure Software Development Lifecycle, SSDLC) 的角度，
在各階段採用相對應的做法。
例如在需求階段，可使用 Security Command Center，
來管理資產清單、政策和風險。
實作階段可以使用 Binary Authorization ，
來校驗映像檔完整性等等
驗證階段可以使用 Web Security Scanner，
來掃描 HTTP(S) 端點的漏洞。
而在發佈階段可以使用 Artifact Registry，
來安全管理容器映像檔，並且對映像檔執行弱點掃瞄。
6.虛擬化
虛擬機器的映像檔，統一由 Google 提供，
有賴 Google 來協助維護公開映像檔的安全。
但是如果是自行搬遷上雲的主機，
就必須在搬遷之前做好徹底的掃瞄，
以及地端的環境，要防止虛擬機逃逸 (VM Escape)，
取得虛擬機管理程式（Hypervisor）的權限。
7.實體安全
在 GCP 的部分，統一由 Google 來管理全球的機房，沒有委外。
而如果你所在的公司有使用混合雲，
使用 Cloud VPN 或 Cloud Interconnect 的話，
就必須做好混合雲設備的管理，和操作的人員，
避免設定漏洞，開放太多用不到的網段、IP 位址和 Port，
或是設備本身被駭，更改設定導致門戶大開。
8.合規
資安法規日趨嚴格，須設置專門的人員，
隨時注意國內外相關法規的變化，
例如歐盟的 GDPR、台灣的個資法等等，
只要違反就有可能面臨鉅額罰金，不可不慎。
而這些法規條文往往艱澀難懂，
所以可能需要向外尋找專業的資安顧問公司，
來協助審查公司的各項做法，協助合規。
而在 GCP 方面，有提供 法規遵循資源中心，
可查詢 Google 通過的相關資安認證。
也有提供 Google Cloud Architect Framework，
讓你可以打造一個符合法規的雲端架構。
9.人員訓練
當然這是老生常談，
大家都知道人員都必須要訓練。
不過我要說的是，高階主管更需要訓練，
因為下屬迫於主管的威勢(官大學問大？)，
通常都給主管最大的系統權限，
但主管本人幾乎不負責操作系統，
等於開了一個超大權限給不會用的人，風險極高。
如果主管只會「看資料」，就只要「讀取」的權限就好，
不應該給到最高權限。
主管以身做作則，也能上行下效。
再來，全公司都要啟用 MFA (多因素驗證) 或 2FA (雙重驗證)，
即使是臨時建立的測試帳號，也要啟用，
避免帳號密碼被破解之後，沒有多一道防護。
以上分享各面向的資安威脅與因應方式，
給各位參考。
順便置入一下，關於更多資安相關的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！