首先從帳號安全開始，讓你還沒登入 GCP，帳號就已經受到保護； 

接著開始觸碰到 GCP 的最前端，就有 DDoS 防禦、WAF 和入侵偵測功能； 

在進入應用程式之前，會有嚴格的登入驗證和授權機制；

若你的應用程式在 VPC 網路內，流量就會受到防火牆的控管，

可疑封包也能納入分析； 

應用程式不論是在 VM 或 Container，都可以對它們弱點掃瞄； 

資料存取受到層層管制，確保不被輕易入侵、破解或外洩；

整體環境還有其他獨立運作的監控機制和政策，

讓你建立重重關卡，滴水不漏。

本文整理目前最常用並且「可以立即使用」的資安功能，

從外部一直到 GCP 最深處，逐步介紹各個功能，

讓你可以建立每一層的防禦工事。

一、帳號安全

(一) Cloud Identity

使用 GCP 之前，你至少要使用公司的帳號，

而不是使用個人 Gmail，

如果帳號有任何問題，例如無法登入或被駭，

至少公司管理員還可以幫你處理，不會求助無門。

Google Workspace 就是公司專用的 Google 帳號，

但是它還有 Gmail、日曆、雲端硬碟等等相關功能，

不一定每家公司要先用 Google Workspace 才能用 GCP。

Google 有把帳號管理的功能抽出來，就是所謂的 Cloud Identity，

即使公司使用 M365 或其他企業信箱，

你可以建立公司的 Google 帳號，

像這樣的格式：aaron@dongdong.com，依然可登入 GCP。

Google 的帳號安全機制很多，像是最基本的「兩步驟驗證」功能，

公司可以先「邀請」使用者自行啟用，

如果使用者不配合，管理員可以「強制實施」，

這樣一來，已事先啟用兩步驟驗證的使用者，可以正常登入 GCP。

未啟用的使用者，就完全無法登入 GCP。

確保使用者帳號密碼被盜，駭客還是拿不到驗證碼。

(二) Titan Security Key 安全金鑰

針對非常重要的人員帳號，例如系統管理員或高階主管，

還可以使用 Titan Security Key，

長得有點像隨身碟，當你註冊金鑰到帳號中，

以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證，

只要駭客沒有金鑰，就無法登入你的 Google 帳戶，

就像一把真正的鑰匙在你手上，讓安全性大為提高。

二、攻擊防禦

(一) Load Balancer 負載平衡器

每分每秒，全世界有 60% 的網路流量會經過 Google，

Google 也隨時在監控網路的各種攻擊流量，

針對高流量的 DDoS 攻擊，

Google 的 Load Balancer 就有內建防禦功能。

像是知名遊戲廠商艾玩天地，也曾飽受 DDoS 之苦，

後來把遊戲部署在 Compute Engine 上，前端採用 Load Balancer，

就直接過濾掉所有 DDoS 的攻擊流量，提高玩家的遊戲體驗。

另外 HTTP(S) Load Balancer 也有提供免費且自動更新的 SSL 憑證，

幫你的應用程式在傳輸過程中進行 TLS 加密，

降低資料被竊取的風險。 

(二) Cloud Armor

像艾玩天地碰到的是大流量攻擊，Google 容易偵測得到，

但也有很多中小企業，網站流量不大，

只要稍微碰到小幅度的攻擊，就足以讓整個網站癱瘓掉。

因此可以再加上 Cloud Armor，是 DDoS 防禦和 WAF 功能的結合體。

在 Standard 方案底下，就已經內建基本的防禦功能，

不需要再額外設定。

你也可以再自訂各種防禦規則，

最基本的規則例如來源 IP 黑白名單、來源國家、網路封包標頭 (Header) 過濾，

以及有現成語法可用的 SQL Injection、XSS 語法，

還有 OWASP (Open Web Application Security Project) 資安組織公佈的10大威脅，

都可以直接複製貼上使用現成的語法。

如果你確認主機平常流量不大，想提前預防突然升高的流量，

可以設定 Throttle (節流) 或 Rate base ban (暫時停止服務)，

讓流量控制在一定的範圍之下。

Cloud Armor 還有 Enterprise 版，

有特別提供自適性防護 (Adaptive Protection) 的功能，

它會建立機器學習的模型，來偵測異常活動，

還能自己產生 WAF 規則來阻止潛在的攻擊。 

如果企業對於 DDoS 有極大的需求，

可以在已經購買 Premium Support 的情況下，

加購 Cloud Armor Enterprise，

當攻擊發生，可以立即開立 DDoS 支援案件，

讓 Google 專家立即協助阻斷。

另外，攻擊時所輸出的流量費用，

可以獲得未來 GCP 使用的抵免額度。

(三) Cloud IDS 入侵偵測系統 (Intrusion Detection System)

Cloud IDS 可以偵測到入侵、惡意軟體、C&C 命令和控制，

它會建立一個對等網路 (Peered Network)，

然後將原本網路中的流量映射到對等網路，

再利用業界知名的 Palo Alto 公司的技術來檢測威脅。

再加上它是雲原生的，而不是像地端設備的複雜功能，

設定很簡單，只要點幾下滑鼠就能部署該功能。

不過要注意的是，Cloud IDS 只檢查進入 VM 或 GKE Pod 的流量，

其他服務還沒納入檢測範圍。

三、登入驗證和授權

(一) Cloud IAM (Identity and Access Management)

當我們登入 GCP 時，系統就會立即檢察你的身份，

以及你是否有足夠權限進入某個功能。

我們也是在這裡統一管理所有人員和服務帳戶 (Service Account) 的權限角色，

比較特別的是，權限可以設定「條件」，

讓使用者只能在「特定時間」有權限，

例如星期幾之前或之後、一天當中幾點之前或之後，

或是存取權的有效期限。

現在 IAM 還能主動提供權限檢查，

告訴你哪一個帳號似乎用了太大的權限，

提醒你要調整，減少帳號被駭之後被破壞的範圍。

(二) Cloud IAP (Identity-Aware Proxy)

Cloud IAP 是一個非常神奇的功能，

可以讓你非常安全地存取 GCP 的資源，

包含 SSH 到 Compute Engine 的主機、遠端連線到 Windows、

和透過 Load Balancer 存取網頁應用程式。

以往都是透過 VPN 來連線，但是 VPN 只會管你從哪裡來，

並不會驗證你的身份，

但是 Cloud IAP 會驗證你的身份，並且檢查你有沒有存取權限，

才決定放行，所以在安全性上提高很多。

此外，Cloud IAP 幾年前剛推出時，設定比較麻煩，

需要啟用 API，建立連線通道，授權使用者等等。

但是現在除了原本的設定方式，也推出自動使用 IAP 的功能，

以前如果要直接點擊 SSH 按鈕連線到你的主機，

必須要讓防火牆規則，開放所有的 IP 來源的 Port 22，

代表不是只有你，全世界的駭客都可以連到你的主機 Port 22。

如果要安全地連，必須自己做 SSH Key，從本機 SSH 來連，

然後設定防火牆只允許自家 IP，並且擋掉其他 IP，有點麻煩。

而且如果 Key 被盜，任何持有 Key 的人都可以連進你的主機，

你還不知道是誰進來搞破壞。

但是現在 Cloud IAP 讓你不用再做自己的 SSH Key了，

你只要在防火牆允許 Cloud IAP 的 IP Range：35.235.240.0/20，

不用 Allow 全世界的 IP，也不用 Allow 自家的 IP，

只要 Allow GCP 的內部網段即可，實在是安全又方便。

四、VPC 網路的安全機制

當我們身份驗證成功了，

我們的流量就會進入到 VPC (Virtual Pricate Cloud)，

也就是 GCP 的內部網路，這時就會受到防火牆的管控。

(一) 防火牆

1.防火牆規則 Firewall Rules

這是 GCP 最基本也最重要的安全機制，是以一個專案內的 VPC 為管理範圍，

方向包含 Ingress (進入 VM 的流量) 和 Egress (離開 VM 的流量)，

動作就包含允許 (Allow) 和拒絕 (Deny) 兩種，

而目標 Target 指的是要套用規則的 VM 有哪些，

再把來源或目的地的 IP 或標籤 Tag 設定好，

以及要放行或禁止的通訊協定和 Port，最後就是設定好優先順序，

數字越小越優先。

其中最特別的是「標籤式管理」機制，

你可以為每一台 VM 加上特定的標籤 (Network Tag)，

同時也給防火牆規則設定相對應的標籤，

這樣就可以讓你一次將規則套用到多台主機，

省去一台一台設定 VM 防火牆的麻煩。

如下圖 Rule 1 的Target Tag 設定 “Web”，只會套用到右邊第一台 VM。

 Rule 2 的Target Tag 設定 “DB”，則會套用到右邊第二、三台 VM。

2.防火牆政策

最近 Google 又新增了防火牆政策，它的管理範圍更大，

從整個 Organization 開始，往下到資料夾、專案，

中間經過防火牆規則，

再到 Global VPC、Region VPC，都可以設定防火牆政策。

除了原本的允許和拒絕之外，

還多了 Go to next (給下一層決定) 和 L7 (做第七層檢查)。

但要注意的是，設定層級很多，規則複雜，容易混淆。

建議先以防火牆規則為主，管理較為單純，

等到熟悉整體運作，再逐步增加各個層級的防火牆政策。

(二) Packet Mirroring 封包鏡像

Packet Mirroring 可以讓你複製 VM 或其他資源的網路封包，

並將其鏡像到指定的目的地，

如其他虛擬機器、Cloud Security Command Center 或第三方設備。

這對於網路監控、安全檢測、故障排除及合規性檢查等場景非常有用，

它可以執行網路流量監控和分析，識別異常流量或攻擊行為，

也可以送到故障排除工具，協助診斷網路問題或效能瓶頸。

但要注意，它是真的把原有的流量「一模一樣複製出來」，

所以流量費用是直接變成兩倍，

因此要看是否有重大事件需要檢查封包或排除故障，

針對關鍵部分再複製封包，確保費用在控制範圍之內。

五、應用程式的資安功能

(一) 針對虛擬機器 – Confidential VM

以往 GCP 都會強調資料在「儲存中」和「傳輸中」都會加密，

而近期推出 的 Confidential VM，是能夠達到資料在「處理中」也能加密。

就是主打「以硬體為基礎的記憶體加密」機制，

來確保你的資料和應用程式無法被竊取或竄改，

加密的 Key 是在專屬的硬體上產生，Hypervisor (虛擬化程式) 也無法讀取。

你也可以驗證 VM 的身份和狀態，確保關鍵的元件沒有被竄改。

不過要注意的是，它是有限定機器類型的，

例如 N2D、C2D 和 C3 Standard 的主機才有支援，

當然費用會稍微高一點，這就取決於你公司的資安或合規需求來選用，

但好處是，整個使用的過程和一般的主機沒有差別，

只要在開機過程中勾選 “Confidential VM service” 就可以了，

也是非常方便的功能。

(二) 針對容器 Container 的資安服務

1. Image 弱點掃瞄功能 – Vulnerability Scanning

如果要部署應用程式在容器平台，

包含 Cloud Run 或 Google Kubernetes Engine (簡稱 GKE)，

就要先上傳容器映像檔到 Container Registry 或 Artifact Registry，

不管是哪一種，都可以使用弱點掃瞄功能，

只要在 Console 上啟用之後，

你接下來 Push 上傳的每一個 Image，都會自動掃瞄。

(但是舊的不會掃瞄喔)

掃瞄完成之後，它會列給你一個非常完整的弱點清單，

並且依照嚴重程度和弱點分數做一個「排行榜」，

以及建議的修護方式和相關外部連結，

讓你可以知道有哪些弱點需要修補，算是非常貼心的功能。

2. Image 簽署功能 – 二進位授權 Binary Authorization 

軟體開發過程中，常常推送各種 Image 到 GCP，

但有些 Image 尚未開發完成，只是先推送出來測試看看，

因此可能會有資安漏洞，不能部署到正式環境。

為了防止 Image 不被意外部署出來，

GCP 設計了二進位授權 Binary Authorization 的機制，

讓你的 Image 在部署到 Cloud Run 或 GKE 之前，

強制驗證它是否經過簽名，

就像是找個人幫你背書，證明這個 Image 很安全，

如果 Image 未經簽名，一律拒絕部署，

而且可以針對多個步驟例如：單元測試、原始碼分析和漏洞分析等等，

都設定簽名的關卡，算是非常嚴格的安全機制。

(三) 應用程式掃瞄 – Web Security Scanner

GCP 對於部署應用程式的平台，

包含 App Engine、Compute Engine、GKE，皆提供弱點掃瞄，

它會爬行 (Crawling) 你的網站，從首頁開始延伸到的相關連結，

執行各種輸入和事件處理，藉此偵測應用程式的弱點。

你可以執行定期的掃瞄排程，只要提供 IP 或網址就可以開始掃瞄，

也可以自訂多個參數來做更客製化的掃瞄，讓掃瞄的廣度和深度更為全面。

但是要注意，必須是專案內的應用程式才能掃瞄，

以及要用公開的 IP 或網址才能掃瞄得到。

六、資料存取

(一) Secret Manager

我們的應用程式時常需要和 Google 的 API，或是後端主機、資料庫或其他儲存的服務互動，

這時需要一些連線資訊、環境變數、設定檔或憑證，

如果我們直接寫在程式碼中，容易有被竊取的風險，

我們可以將它們寫在 Secret Manager 當中，讓有權限的 Service Account 去讀取，

可以減少重要資訊外洩的機率。

而且它是一個代管的服務，我們可以很方便的把資訊建立成 Secret，

每次更新都會立即生效，在管理上非常方便。

(二) Key Management Service

我們使用的 Disk、Cloud Storage、Cloud SQL、Filestore 和 BigQuery，

都已經內建了 Google 預設的加密機制。

如果我們想要有更高的加密等級，就可以使用 KMS。

KMS 是一個集中管理加密金鑰的地方，

也就是所謂的 CMEK (Customer Managed Encryption Keys) 模式。

你可以選擇各種加密演算法，也可以決定自動更換 Key 的頻率，

從 24 小時到 120 天都可以選擇。

除了軟體生成的 Key ，也有硬體模組生成的 Key，叫做 HSM (Hardware Security Module)，

軟體 Key 可達到 FIPS 140-2 Level 1，

而硬體 Key 更是達到 FIPS 140-2 Level 3，是很多金融機構合規需求的標準。

另外，你也可以不使用 KMS 產生的 Key，

可以直接從外部第三方送進 GCP 使用，

就是所謂的 EKM (External Key Management) Keys，

這裡的 Key 完全不會送到 GCP 裡面 (支援的廠商清單)。

如果不用第三方管理系統，

也可以直接使用所謂的 CSEK (Customer Supplied Encryption Keys) 模式，

直接從外部自己產生 Key，每次存取時指定 Key 的位置，

但要注意這種方法，Google 也不會儲存你的 Key，

自己務必要保管好，因為你沒有專屬的金鑰管理系統，

萬一 Key 不見了，是連 Google 都無法幫你還原資料的。

(三) Cloud DLP (Data Loss Prevention)

公司因為合規需求，或是避免內部人員看到不該看的敏感資料，

你可以呼叫 Cloud DLP 的 API，來幫你檢查資料中是否包含個資。

例如使用者傳訊息給客服人員，有時太直白地留下身份證字號或是手機號碼，

收到這種訊息反而提高公司觸法的風險，所以每次收到最好當下就檢查，

只要檢查到個資，就可以使用「遮罩」、「刪除」或「加密」來處理。

「加密」這個動作可以搭配 KMS 的 Key ，

來將資料加密成看不懂的樣子，只讓關鍵人員有權限解密該資料。

對於已經存在資料庫裡的資料，不確定是否含有個資，

也可以建立掃瞄工作，對整個資料庫或 Cloud Storage 進行完整掃瞄，

再針對掃瞄到的資料統一處理。

七、整體安全控制

(一) Cloud Logging

Cloud Logging 會收集整個 GCP 環境所有的 Log，

不管是 Project Level 還是 Organization Level 的 Log，

集中顯示在專屬的 Logs Explorer 中，並且分門別類，

依照時間排序，也可以使用語法查詢。

預設會記錄所有的管理員操作 (Admin Activity)，

例如「是誰開了一台大機器卻忘了關？」

和系統事件 (System Event)，例如「主機什麼時候發生異常，

Google 幫你重開機器？」。

如果你的 Web Server 想要收集 Log，

也可以安裝 OPs Agent 將應用程式的 Log 送到 Cloud Logging，

這樣如果主機當機進不去，

你也可以從 Cloud Logging 看到主機到底發生了什麼事。

如果你希望 Google 技術人員幫你 Troubleshooting 的時候也有記錄，

可以選用開啟 Access Transparency Log，

確認 Google 的人員連線到你 GCP 專案的記錄。

另外，大部分資料存取的 Audit Log 預設是不開啟的，

因為這種 Log 可能無時無刻都在發生，

資料量非常大，有需要再開，

例如要監控是否有不正常的存取行為時，可以開起來收集記錄，

很適合用來抓小偷，因為這裡的 Log 是無法刪除的。

你也可以因應法規需求，將 Log 設定更長的保存期限，

或是匯出到其他地方永久保存。

(二) Beyond Corp

Beyond Corp 是 GCP 的資安框架，主打「零信任」，

代表任何來源未經正常的驗證程序，都先視為「不信任」。

它包含前面提到的 Cloud IAP，和接下來這兩個重要功能：

1. Access Context Manager

這是用來設定所謂的「Access Level」存取層級，

用更白話的方式講，就是一種存取的條件或情境，

或是用戶端的屬性，

例如用戶是從哪一個 IP 或國家過來存取的，

而 Beyond Corp 的 Enterprise 版本還提供「裝置是否經過認證」。

而上述的各種條件，可以組合成不同的層級，

例如 “Basic” 指的是基層員工、”High” 代表高階主管，

也可以設定一個 “Office” 代表從公司的 IP 位址去連到 GCP 的人員。

2. VPC Service Control

當我們設定好「條件」之後，這裡就要來設定「動作」，

就是要「允許」還是「拒絕」存取「某個服務或資源」。

如上述我們設定一個 “Office” 的層級，裡面只設定辦公室的 IP 位址。

然後在這裡設定專案 “dong-dong-gcp-3” 裡所有服務都納入「保護」，

就代表符合 ”Office” 的人 (IP 在辦公室的人)，

都可以存取 “dong-dong-gcp-3” 專案所有的服務。

反過來說，不符合 ”Office” 的人 (IP 不在辦公室的人)，都無法存取，如下圖。

你可以看到，因為只有 “dong-dong-gcp-3” 被納入保護，

所以當我切換成 “dong-dong-gcp-2” 時，

該專案沒有納入保護，所以不管 IP 位址是否在辦公室，

都不會影響存取。

其實 Service Control 的使用範圍相關廣泛，

除了專案，也可以將專案中某個 VPC 網路納入保護，

還能定義服務邊界 (Service Peremeter)，讓邊界外的來源不能進來存取，或是不能把資料帶出邊界。

是除了防火牆之外，另一個獨立運作的存取控制功能。

(三) Cloud Security Command Center (簡稱 SCC)

它可以視為資安中心的角色，能夠隨時掃描整個 GCP 環境的資源，

將檢測結果集中顯示在統一的頁面上一目了然。

免費的標準版除了先前提到的 Web Security Scanner，

還包含以下服務：

1. Security Health Analytics

自動檢查資安漏洞和錯誤設定，例如 IAM 授權給外部人員、太過開放的防火牆規則等等。

2. Security Command Center errors

如果有任何設定錯誤的地方，導致 SCC 無法正常運作，它會產生錯誤訊息來提示你。

3. Continuous Exports

可以自動把新發現的檢查測果傳到 Pus/Sub，讓你可以整合資訊到其他應用上。

4. GKE security posture dashboard findings

可以查看 GKE 目前是否有設定錯誤的地方、容器作業系統和程式語言套件的漏洞等等。

5. 整合 Forseti Security

這是 GCP 開放源始碼的各種工具，可以和 SIEM (Security Information and Event Management) 整合。

6. Sensitive Actions Service

監控管理員的活動是否會傷害業務運作，再把結果寫到 SCC，再讓使用者確認該行為是否真的有害。

SCC 目前還有 Premium 和 Enterprise 版本，

提供更完善的功能，後續將再專門介紹三個版本的細節和差異。

(四) Organization Policies 機構政策

Org Policies 可以針對全公司所有的資源，統一控管存取的政策，

例如 VM 是否可以使用外部 IP、哪個專案的 Image 可以拿來建立 VM、

哪個專案不能建立 Service Account 或 Key、

哪個專案不能在瀏覽器使用 SSH 連線等等。

你可以在 Org 層級設定好，套用到底下所有的資料夾和專案，

你也可以在資料夾或專案層級覆寫 (Override)，

設定不一樣的政策，在管理上非常靈活。

最後整理本文提到的所有資安服務如下圖：

其中灰色字體為一般 GCP 服務，黑色字體為資安服務，

粗體代表不同層級或類別，

各個服務之間的關係用箭頭表示，但不代表嚴謹的架構邏輯，

僅為示意。

由此可知，GCP 的資安功能強大且完善，

讓你可以用好用滿，遠離威脅。

未來會再針對個別服務撰寫專門的文章來深入介紹，

讓各位可以立即上手。

本文同時刊登於思想科技官方網站的網誌文章：《【 東東老師 X 思想科技 】雲端的資訊安全防禦縱深，常用資安服務介紹》。

The post [GCP 教學] 雲端的資訊安全防禦縱深，常用 GCP 資安服務介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端的資訊安全威脅包含以下九大層面：

本文逐一說明相關的威脅和解決方法：

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 來管理全球的機房，沒有委外。

https://www.youtube.com/watch?v=kd33UVZhnAA

而如果你所在的公司有使用混合雲，

使用 Cloud VPN 或 Cloud Interconnect 的話，

就必須做好混合雲設備的管理，和操作的人員，

避免設定漏洞，開放太多用不到的網段、IP 位址和 Port，

或是設備本身被駭，更改設定導致門戶大開。

8.合規

資安法規日趨嚴格，須設置專門的人員，

隨時注意國內外相關法規的變化，

例如歐盟的 GDPR、台灣的個資法等等，

只要違反就有可能面臨鉅額罰金，不可不慎。

而這些法規條文往往艱澀難懂，

所以可能需要向外尋找專業的資安顧問公司，

來協助審查公司的各項做法，協助合規。

而在 GCP 方面，有提供 法規遵循資源中心，

可查詢 Google 通過的相關資安認證。

也有提供 Google Cloud Architect Framework，

讓你可以打造一個符合法規的雲端架構。

9.人員訓練

當然這是老生常談，

大家都知道人員都必須要訓練。

不過我要說的是，高階主管更需要訓練，

因為下屬迫於主管的威勢(官大學問大？)，

通常都給主管最大的系統權限，

但主管本人幾乎不負責操作系統，

等於開了一個超大權限給不會用的人，風險極高。

如果主管只會「看資料」，就只要「讀取」的權限就好，

不應該給到最高權限。

主管以身做作則，也能上行下效。

再來，全公司都要啟用 MFA (多因素驗證) 或 2FA (雙重驗證)，

即使是臨時建立的測試帳號，也要啟用，

避免帳號密碼被破解之後，沒有多一道防護。

以上分享各面向的資安威脅與因應方式，

給各位參考。

 

順便置入一下，關於更多資安相關的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post [GCP 教學] GCP 9 大資訊安全威脅與因應方案 first appeared on 東東 GCP 教學 - GCP 實戰講師.