GCP認證帳號 Google Cloud使用IAP（身份驗證代理）實現無公網IP安全登錄SSH

前言：為什麼要把 SSH 收進 IAP

在雲上做運維，最常見的風險通常不是「忘記寫程式」，而是「忘記關入口」。只要你的虛擬機開了公網 SSH（22 port），攻擊就會像潮水一樣持續。即使你只放進少數 IP、只允許密鑰、加了 Fail2ban，仍然要面對端口掃描、憑證嘗試、漏洞鏈式利用，以及人為疏忽導致的暫時性暴露。

更乾淨的做法是：讓 SSH 永遠不直接面向公網，把「誰有資格登入」這件事交給身份層處理。Google Cloud 的 IAP（Identity-Aware Proxy）正是為這個場景設計的。你不再把主機的 22 直接掛在外網，而是用 IAP 作為受控入口，透過已驗證的使用者身分，讓連線在受管道中完成到私網主機的轉發。

本文的目標是：在有「無公網 IP」的前提下，依然能安全地 SSH 登入。你會看到可落地的思路、需要的角色與設定，以及實務上最容易踩的坑。

目標場景與總體架構

目標

• 後端 VM 沒有公網 IP（或至少不應直接提供 SSH 給外網）。
• 外部使用者仍能透過瀏覽器/命令行發起 SSH。
• 登入行為受 IAM 控制，並支援審計。
• 不把 22 端口直接公開給所有互聯網。

核心架構

整體可用一句話概括：把「網路可達性」改成「身份可驗證」。IAP 先驗證你是誰（以及是否獲授權），再把你的 TCP/SSH 流量在雲端內部安全轉發到私網 VM。

典型流程是：

• 使用者在本地發起 SSH（通常透過 IAP TCP forwarding）。
• Google 端的 IAP 先對使用者進行身份驗證與授權（OAuth/Google 登入、IAM）。
• GCP認證帳號 授權通過後，IAP 代你把連線轉發到目標 VM 的私網 IP 與 22 port。
• VM 像正常一樣接受 SSH，並由 SSH 鑑權（公鑰/密碼）完成登入。

這裡的重點是：你仍然可以保留 SSH 層的安全（例如僅允許密鑰、限制使用者），但入口的「外網可掃描風險」大幅下降。

前置條件：你需要先準備什麼

1）VM 必須可由 VPC 內部連通

因為 VM 沒有公網 IP，IAP 轉發後的連線會走雲端網路到 VM。因此你要確認：

• 目標 VM 所在的 VPC 與 IAP 能達到的路徑正確。
• 防火牆允許來自 IAP 所需的來源到 VM 的 22 port。
• 若你把 VM 放在私有子網，仍確保目的端口可被 IAP 轉發接入。

在多數標準情境中，只要防火牆規則正確，IAP TCP forwarding 就能直達。

2）啟用 IAP 相關服務

在 Google Cloud 中，要讓 IAP 能工作，通常需要啟用相關 API/服務。實務上你會在項目層確認以下狀態（名稱可能依介面略有差異，但概念一致）：

• IAP 服務本身啟用。
• Compute Engine 相關 API 啟用。
• 必要時啟用 Cloud Resource Manager/IAM 相關 API。

如果你沒有啟用，後續的權限設定也可能看似成功但仍無法真正轉發。

3）配置好使用者身分與授權模型

IAP 的授權是 IAM 驅動。你需要明確「誰可以登入哪些 VM」。通常做法是：

• 使用 Google Workspace 或 Cloud Identity 帳號。
• 以群組（Group）方式做授權，比逐個帳號更可維護。
• 針對不同環境（dev/stage/prod）使用不同的授權集合與規則。

把「人」與「資源」的關係在早期就設計好，能避免後期權限一團亂麻。

IAM：讓 IAP 真的知道你是誰

要使用 IAP 登入，至少要完成兩層授權：一層是「你能使用 IAP 連到此資源」，另一層是「你能以該方式完成必要的憑證/登入」。

1）把 IAP TCP/SSH 相關權限授給正確主體

在控制台中，你會看到 IAP 的權限配置，或以 IAM policy binding 的形式指定。原理是：把某個角色授權給某個主體（使用者/群組/服務帳號）。

實務上最常見的目標是給使用者：

• 允許他們透過 IAP 連到特定網路資源或特定應用。
• 允許進行必要的 IAP 授權流程（含驗證）。

你需要關注的是「授權範圍」。很多人只在項目層授權，但後來希望更細粒度（只對某些 VM 或標籤生效）。建議從一開始就用一致的資源命名與標籤策略，讓你可以把授權落在更精確的位置。

2）角色授予的最小權限原則

如果你把管理員權限全部開給一般使用者，等於把身份層也失去控制。正確方向是：

• 運維人員只獲得連線與管理所需的最小角色。
• GCP認證帳號 避免讓一般使用者擁有過高的 Compute 或 IAP 管理權限。
• 把權限聚焦在「能透過 IAP 連到目標」與「能使用必要的系統工具」。

此外，建議使用群組管理，並在變更時保留審計軌跡。

防火牆：22 端口不對外開，但仍要被 IAP 接入

關鍵點：不用「對互聯網開」，但要允許 IAP 的來源

你不希望任何未知來源能打到 VM 的 22。但 IAP 在雲端內部轉發時會以某種來源方式進入。這意味著你的防火牆規則要放行「IAP 轉發所需的流量」，同時拒絕其他來源。

GCP認證帳號 具體做法取決於你採用的模式與標準。你可以採用：

• 只允許特定來源（例如 IAP 相關網路標示）到 VM 的 22。
• 或以目標標籤（network tag）方式約束：只有帶特定 tag 的 VM 才接受 22。

建議用目標標籤（network tags）而不是隨機放行整個子網，因為你的基礎設施通常會成長，規則太寬容易被新機器誤帶進安全範圍。

常見錯誤：你以為已開了 22，其實還差來源條件

很多人設了「允許 22 from 0.0.0.0/0」以為問題解掉，後來才發現這把安全性完全打穿。相反的，若你完全拒絕所有來源，而沒有放行 IAP 的必要來源，你又會遇到連線逾時。這兩種錯誤都很常見。

正確做法是：把規則收斂到 IAP 可能使用的來源範圍或標示，並用目標標籤精準約束資源。

SSH 登錄流程：用 IAP TCP forwarding 連到私網 VM

為什麼是 TCP forwarding

IAP 並不是替你重寫 SSH。它提供的是一個「受控的 TCP 通道」。SSH 本身仍然在這個通道上跑：你端上用 SSH client，IAP 在中間做身份驗證與轉發，VM 接收的仍是標準的 SSH 流量。

準備 VM：打好 SSH 基礎

在測試之前，先確保你在 VM 上的 SSH 服務與鑑權是正常的：

• sshd 正常運作。
• 允許你要登入的使用者（例如用公鑰方式）。
• 必要時限制 sshd 設定（例如僅允許密鑰、禁用密碼登入）。

如果你連到本地沒有問題，但經 IAP 連線失敗，問題通常在「IAP 授權、防火牆、或網路標示」。而不是 sshd 本身。但前置檢查能縮短排查時間。

使用 gcloud 進行 IAP 轉發（概念步驟）

在 Google Cloud 的常見工作流中，你會透過 gcloud 來啟動 IAP 轉發並交由 SSH client 使用。實務上你可用類似以下的步驟（具體參數依你的環境命名調整）：

• 先取得你本地已登入 gcloud 的狀態（確保身份是你授權的那個帳號）。
• 使用 IAP TCP forwarding 指令把本地端口轉到 VM 的 22。
• 再用 SSH 指向本地端口（localhost），完成連線。

這種方式的好處是：你不必在本地配置複雜的 proxy 設定，且 gcloud 會負責把身份令牌與 IAP 連線的細節處理好。

如果你更偏好直接在 SSH 裡使用 ProxyCommand

有些團隊會把 IAP forwarding 集成到 SSH config 中，用 ProxyCommand 讓每次 SSH 自動走 IAP 通道。原理一樣，只是把流程從「先轉發再連線」改成「一次指令自動完成」。

GCP認證帳號 建議你在開始時先用轉發流程驗證通，確認授權與防火牆無誤後，再把它固化到 SSH config，以免一上來就把排查變成多段式。

一步驗證：先驗證 IAP，再驗證 SSH

排查順序建議這樣排：

• 第一步：用 IAP 的方式建立到 VM 的 TCP 通道是否成功。若失敗，通常是 IAM 或防火牆或 IAP 服務未啟用。
• GCP認證帳號 第二步：通道成功後再看 SSH 層是否通過鑑權。若卡在鑰匙或使用者權限，才進 VM 檢查 authorized_keys、權限、sshd 設定。

把問題切成「網路與身份」和「操作系統鑑權」，你會更快找到根因。

審計與合規：你不只要能登，還要登得清楚

安全不是只能「能用」，還要能「查得到」。IAP 的優勢之一是它的身份流程與審計能更容易落到雲端審計紀錄中。

建議你建立的審計習慣

• 啟用並檢查 Cloud Audit Logs：確認每次連線請求是否有對應事件。
• 對 prod 環境的登入行為做告警或至少定期回顧。
• 建立變更流程：何時新增群組成員、何時調整 IAP 權限，最好能追溯。

如果你已經有 SIEM 或內部合規報告需求，IAP 的紀錄會比「直接暴露公網 SSH」更容易整理。

最佳實務：把風險降到最低

1）避免把 SSH 密碼登入開著

即使入口被 IAP 控制，你仍應在 VM 上採用公鑰鑑權、禁用密碼（或至少在嚴格環境中禁用）。原因很簡單：IAP 解決的是「誰能連」，SSH 才解決「用什麼身分登入」。兩層都要落地。

GCP認證帳號 2）用群組管理權限，避免個人散落

最常見的管理失誤不是技術問題，而是權限模型失控。建議：

• 以群組為單位授權 IAP。
• 人員進出採用既有的企業身份流程。
• 定期檢查群組成員，確保離職或轉組的人不留權限。

3）使用最小化的網路開放範圍

防火牆規則以標籤與最小來源放行，並且把其他端口維持關閉。很多資安事件不是 SSH 本身出事，而是同時開了不該開的管理埠。

4）為不同環境建立不同資源與不同授權

不要在 dev 用的授權，直接複製到 prod。IAP 讓你能更精準地把權限綁在資源上，但你仍要在架構層就分清楚環境。

常見排錯：遇到錯誤時先看哪裡

錯誤一：連線逾時或卡住

多半是防火牆或網路路徑問題。你可以先檢查：

• GCP認證帳號 目標 VM 是否有 SSH 服務且監聽 22。
• 防火牆是否允許 IAP 來源到 VM 的 22。
• VM 的目標標籤是否跟防火牆規則一致。

錯誤二：IAP 授權失敗（權限不足）

這通常是 IAM 角色或授權範圍不正確。常見原因包括：

• 你登入的帳號不是被授權那個（例如你本地用的是另一個 gcloud 帳號）。
• IAP 授權是在錯誤的層級（項目/網路/特定資源）。
• 群組未同步到目標政策，或成員不在群組。

排查時要把「你實際送出的請求帳號」對上「IAM 裡被授權的主體」。這一步常常被跳過，導致你在對著錯的人改權限。

GCP認證帳號 錯誤三：可以建立通道，但 SSH 驗證不過

這代表網路與 IAP 多半正常。接著查 SSH 層：

• authorized_keys 是否正確、權限是否符合要求（例如 .ssh 與檔案權限）。
• 要登入的使用者是否存在、shell 是否允許。
• sshd 是否禁用了你使用的鑑權方式。

錯誤四：以為 VM 沒公網 IP 就一定安全

這句話不完全對。沒有公網 IP 當然降低了暴露面，但如果你還有其他入口（例如某些 NAT、內網可達的安全組策略錯誤、或你額外開了管理服務對內可被觸及），風險仍可能存在。

IAP 解決的是「外部入口如何被控制」，你仍需要檢視 VPC、防火牆與內網治理策略，形成閉環。

落地建議：一個你可以照做的實施順序

為了讓整個導入過程不變成試錯馬拉松，我建議採用以下順序：

• 先確認 VM 可接受 SSH：在同一網路內或透過替代方式測試 sshd 與 authorized_keys。
• 建立 IAP 授權：以群組授權到目標資源，並確保你使用的帳號在群組中。
• 收斂防火牆規則：只允許必要端口（22），並讓來源匹配 IAP 轉發所需。
• 啟動 IAP TCP forwarding 連線：先做通道測試，再接 SSH。
• 把流程固化：成功後再整合 SSH config 或腳本，避免每次手動操作出錯。
• 開審計與定期檢查：確保登入與授權變更可追溯。

當你照這個順序走，問題通常都能被快速定位在「哪一層沒對上」。

結語：安全不是加一道鎖，而是改掉入口的習慣

用 IAP 實現無公網 IP 的安全 SSH，本質上是在改變「入口邏輯」。你不再依賴偶發的網路限制（例如臨時封 IP、臨時開關防火牆），而是把入口交給一個以身份為中心的代理層：誰能連、連到哪台、連線何時發起，都能在治理模型裡被管理與審計。

真正的收穫不只是一個更安全的 SSH，而是你會建立起一套可延伸的思維：當服務面向外部時，優先用身份與授權來收斂攻擊面，再在資源層維持最小權限與最小網路開放。這才是長期能守住的安全策略。