AWS/GCP 資安實戰：如何為企業打造不信任任何內網的「零信任 (Zero Trust)」架構？

過去的企業資安思維就像一座中世紀城堡：建一道高聳的城牆（防火牆、VPN），只要進了城牆內部（內網），就被視為「可信任的自己人」。但在現代混合雲與遠距辦公的環境下，一旦有員工的筆電被植入木馬，駭客就能在內網橫向移動，直取資料庫。

什麼是零信任 (Zero Trust)？

零信任的核心理念非常簡單：「永不信任，始終驗證 (Never Trust, Always Verify)」。

在零信任架構中，沒有所謂的「安全內網」。無論請求是來自公司總部的會議室，還是公有雲內部的 A 伺服器呼叫 B 伺服器，系統都會將其視為「來自不可信網路的潛在威脅」，並要求進行嚴格的身份與權限驗證。

實作第一步：身份即邊界 (Identity as the New Perimeter)

要打破傳統的網路邊界，第一步就是確立身份管理。在 AWS 與 GCP 的實戰中，JCloud 顧問團隊會協助企業落實以下機制：

• 集中化身分驗證 (SSO)： 整合企業的 Google Workspace 或 Microsoft Entra ID (Azure AD)，實現單一登入，並全面強制開啟多因素驗證 (MFA)。
• 最小權限原則 (PoLP)： 這是最痛苦但也最關鍵的一環。我們拒絕給予工程師 AdministratorAccess，而是利用 AWS IAM 政策或 GCP 角色，精準定義某個帳號「只能在上班時間，讀取特定 S3 Bucket 的資料」。
• 臨時憑證代替長期金鑰： 堅決廢除寫死在程式碼或環境變數裡的長期 Access Key。改用 AWS STS 或 GCP Workload Identity 提供效期僅有幾十分鐘的臨時憑證。

實作第二步：微隔離 (Micro-segmentation) 與網路限縮

即便駭客取得了某台 Web 伺服器的控制權，我們也能透過「微隔離」將災情控制在最小範圍。在雲端環境中，這意味著我們不只在 VPC 邊界設防，而是在「每一台虛擬機、每一個容器」周圍建立防火牆。

例如，利用 AWS Security Groups 或 K8s Network Policies，嚴格限制只有「帶有特定標籤的 Web 節點」才能透過指定的 Port 連接後端資料庫，其餘來自內網的請求一律阻擋 (Deny All by Default)。

實作第三步：自動化持續稽核與監控

零信任不是一個「設定好就結束」的專案，而是一個持續營運的過程。為了滿足 ISO 27001 等合規要求，所有 API 的呼叫軌跡都必須被紀錄並分析。

我們會為企業開啟 AWS CloudTrail 與 GuardDuty（或 GCP 的 Cloud Audit Logs 與 Security Command Center）。一旦系統偵測到某個平時只在台灣登入的 IAM 帳號，突然從海外發出刪除資料庫的 API 請求，系統會立刻觸發 Lambda 函數將該帳號停權，並發送告警給資安團隊。