保護 SSH 憑證的最佳做法

本文說明保護 SSH 憑證的最佳做法。

根據預設，Compute Engine 會使用公開金鑰型 SSH 驗證機制：使用者會透過擁有的項目 (即 SSH 私密金鑰) 進行驗證。如果使用者未妥善保護私密金鑰，這些金鑰可能會落入惡意人士手中，對方可能會利用這些金鑰存取您的 VM 執行個體。

以下各節介紹的最佳做法，有助於避免金鑰外洩，並降低私密金鑰外洩的潛在影響：

本文著重於 Google Cloud 專屬或特別適用於 Google Cloud安全殼層的實務做法。本文未涵蓋特定 SSH 用戶端或伺服器實作的最佳做法。

將 SSH 私密金鑰視為服務帳戶金鑰

部分 VM 執行個體可能附加服務帳戶。將服務帳戶附加至 VM 後，這些 VM 上執行的工作負載就能向中繼資料伺服器要求短期存取權杖，進而存取 Google Cloud API 和資源。

使用 SSH 連線至附加服務帳戶的 VM 時，您也可以從中繼資料伺服器要求短期存取權杖。 因此，授予使用者 VM 的 SSH 存取權，類似於授予使用者以附加服務帳戶身分執行操作的權限。 由於兩者相似，請將安全殼層 (SSH) 私密金鑰 (尤其是未受密碼保護的金鑰) 視為服務帳戶金鑰：如果這兩類金鑰外洩，惡意行為人可能會取得資源的存取權。 Google Cloud

為機器使用者使用暫時性 SSH 金鑰

部署管道或自動化程序可能需要 VM 執行個體的 SSH 存取權，才能執行部署作業或套用設定變更。與其讓這些工作負載使用長期有效的 SSH 金鑰組，不如讓它們在每次執行時使用新的臨時 SSH 金鑰。

如要使用暫時性安全殼層金鑰，請讓部署管道或自動化程序執行下列步驟：

  1. 以不涉及金鑰或密碼的方式，以服務帳戶身分進行驗證，例如使用附加的服務帳戶或 workload identity federation。
  2. 使用 ssh-keygen 等工具產生臨時 SSH 金鑰組。

  3. 將公開金鑰發布至 Google Cloud，並指定近期到期日 (例如 1 小時後)。

    OS 登入可讓您在發布金鑰時指定金鑰到期日。同樣地，您也可以在將 SSH 公開金鑰發布至專案或 VM 中繼資料時指定有效期限。

  4. 使用私密金鑰建立與 VM 執行個體的 SSH 連線。

  5. 視需要取消發布公開金鑰，並刪除私密金鑰。

例如：

# Generate RSA key pair without passphrase
ssh-keygen -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

雖然臨時 SSH 私密金鑰仍可能外洩，但只能在短時間內使用。因此，使用暫時性 SSH 金鑰可降低憑證外洩的風險，並讓您將 Cloud IAM 做為主要的驗證和授權方式。

使用 IAP 輔助安全殼層公開金鑰驗證

根據預設，安全殼層私密金鑰可獨立於 Google 憑證使用：如果使用者的安全殼層私密金鑰外洩，惡意行為者就能使用該金鑰連線至任何授權存取該金鑰的 VM 執行個體，並通過驗證。惡意行為人不需要知道使用者的使用者名稱或密碼，甚至不需要任何 Google 憑證。

兩步驟驗證和限制 Google Cloud 服務的工作階段時間長度等安全控制項，可有效降低憑證遭竊的風險，但這些控制項僅適用於需要 Google 憑證的資源。

為確保 SSH 金鑰必須搭配有效的 Google 憑證才能使用，請使用 IAP 管理 SSH 存取權，並使用防火牆政策強制規定所有 SSH 存取作業都必須透過 IAP 執行。

IAP 會做為反向 Proxy，只有在使用者使用 Google 憑證成功通過驗證後，才允許他們與 VM 執行個體建立 SSH 連線。此外，IAP 可讓您限制使用者可連線至哪些 VM，並強制執行情境感知存取權。

使用多重驗證

使用 IAP 管理 SSH 存取權，可讓惡意行為人更難以使用外洩的憑證存取 VM 執行個體，但並非完全無法存取：舉例來說，惡意行為人可能會入侵工作站，同時找到私密 SSH 金鑰和快取的 gcloud CLI 憑證，這足以通過 IAP 的驗證和授權檢查，並連線至使用者的 VM 執行個體。

您可以設定 Cloud Identity 或 Google Workspace 必須使用多重驗證 (MFA)，降低這類憑證竊取攻擊可能造成的影響。

如果Cloud Identity 或 Google Workspace 是主要身分識別提供者，請執行下列操作來強制執行多重驗證：

  1. 設定 Cloud Identity 或 Google Workspace，強制執行兩步驟驗證。
  2. 限制 Google Cloud 服務的工作階段時間長度，讓系統自動使快取憑證失效，使用者必須定期重新驗證並執行多重驗證。

如果您使用外部 IdP 進行單一登入，請改為執行下列步驟：

  1. 設定 Cloud Identity 或 Google Workspace，限制服務的會期長度 Google Cloud ，讓系統自動使快取憑證失效，使用者必須定期使用外部 IdP 重新驗證。
  2. 設定外部 IdP，要求使用者進行多重驗證，並限制工作階段長度，讓使用者每次工作階段到期時都必須執行多重驗證。 Google Cloud

如要確保多重驗證也適用於 SSH 存取權，您必須執行下列至少一項操作：

  1. 使用 IAP 控制網路存取權，讓使用者必須定期執行多重驗證，才能重新整理 Google 憑證。
  2. 針對個別 VM 執行個體或整個專案啟用 OS Login 雙重驗證，這樣使用者每次建立 SSH 連線時，都必須執行多重驗證。

如果使用者擁有 VM 執行個體或專案的「Compute Instance Admin」或同等角色，即可修改執行個體中繼資料，停用 OS Login 2FA。因此，如果您未在 Cloud Identity 或外部 IdP 中強制執行 MFA，OS Login 2FA 的效用就會受到限制。

使用無法匯出或受密碼保護的私密金鑰

許多 SSH 用戶端預設會將 SSH 私密金鑰儲存為磁碟上的檔案。舉例來說，gcloud compute ssh 會在首次使用時產生安全殼層金鑰組，並儲存在您的主目錄中。作業系統可能會保護您的檔案，避免其他使用者存取，但如果惡意行為人能克服檔案系統權限 (例如在其他電腦上複製及掛接磁碟)，他們就能將金鑰複製到其他位置，並在您不知情的情況下使用。

部分 SSH 用戶端可讓您避免使用以檔案為基礎的金鑰，並提供管理 SSH 私密金鑰的替代選項，例如：

  • 使用硬體支援的金鑰：新版 OpenSSH 可讓您使用 FIDO2 安全金鑰進行驗證，並設定 OS 登入，只允許在 Cloud Identity 或 Google Workspace 中註冊的安全金鑰。使用硬體支援的金鑰，有助於避免在電腦的檔案系統中儲存任何私密金鑰資料。
  • 使用作業系統的金鑰儲存設施：舉例來說，IAP Desktop 會避免使用以檔案為基礎的金鑰，而是使用 Windows CNG 保護 SSH 金鑰。

如果無法使用硬體支援或作業系統管理的金鑰，您可以透過密碼保護安全殼層私密金鑰：如要使用密碼保護的安全殼層金鑰，惡意行為人不僅需要私密金鑰副本，還必須知道金鑰密碼。

使用主機金鑰驗證主機

建立 VM 執行個體的 SSH 連線時，您會依據 VM 執行個體的名稱或 IP 位址識別該執行個體。名稱和 IP 位址可以重新指派及重複使用，昨天參照特定 VM 執行個體的名稱，今天可能參照的不是同一個 VM 執行個體。惡意行為者可能會刻意重新指派或重複使用名稱或 IP 位址，偽造 VM 執行個體，誘騙使用者連線至遭入侵的 VM。

SSH 用戶端可使用 SSH 主機金鑰偵測先前信任的 VM 執行個體是否已替換為其他 VM 執行個體：VM 的 SSH 主機金鑰會在首次啟動時產生，並用於識別執行個體。SSH 用戶端通常會在第一次連線時要求並儲存 VM 的主機金鑰，並在後續連線時驗證 VM 的主機金鑰是否已變更。

SSH 主機金鑰是根據「首次使用時信任」機制運作。如果惡意行為人使用攔截式 (MITM) 攻擊，讓用戶端在首次使用時連線至錯誤的 VM 並信任該 VM，SSH 主機金鑰的效用就會受到影響。取得主機金鑰的較佳方式，是在首次連線至 VM 前，透過信任的側向管道取得金鑰。

您可以在專案中啟用訪客屬性，讓 gcloud CLI 透過後端管道取得主機金鑰。接著，gcloud CLI 會在您首次連線至 VM 前讀取 VM 的主機金鑰，並將金鑰儲存在本機電腦上。

請勿在 VM 上留下個人憑證

授權 gcloud CLI 時，工具會取得 OAuth 更新權杖，並儲存在本機主目錄中。之後執行 gcloud CLI 指令時，gcloud CLI 會使用重新整理權杖自動驗證您的身分。

其他使用者可能無法存取您的本機電腦，但在 VM 執行個體上，擁有 VM sudo 權限的其他使用者也能存取您的主目錄。

如果惡意人士設法取得 VM 的 sudo 權限，他們可能會掃描其他使用者主目錄中的重新整理權杖和其他憑證，並使用這些憑證來提升權限或將存取權擴展至其他資源 (側向移動)。

透過 SSH 連線至 VM 執行個體時，請避免使用個人憑證授權 gcloud CLI 或應用程式預設憑證 (ADC)，而是讓 gcloud CLI 使用 VM 附加的服務帳戶。同樣地，請避免執行其他可能會將個人憑證儲存在主目錄中的工具。

您可以限制服務的會期長度 Google Cloud ，讓系統在一段時間後自動使儲存的 OAuth 重新整理權杖失效，進一步降低風險。

請勿將安全殼層 (SSH) 私人金鑰提交至原始碼存放區

部分自動化工具 (例如 Ansible) 會使用 SSH 存取及管理 VM 執行個體。 這類工具可能會存取許多 VM 執行個體 (和附加的服務帳戶)，因此這類工具使用的 SSH 私密金鑰可能特別敏感。

如果您將 SSH 私密金鑰提交至原始碼存放區，金鑰遭未經授權的使用者和惡意行為人存取的風險就會提高：

  • 惡意行為者可能會掃描公開原始碼存放區的原始碼，找出外洩的金鑰。
  • 日後您可能會決定將私人來源存放區轉換為公開存放區，但未先檢查是否有金鑰。
  • 其他團隊成員可能會將原始碼副本儲存在工作站。

為降低這些風險，請將安全殼層私密金鑰儲存在與原始碼不同的安全位置，並盡可能使用暫時性安全殼層金鑰。

後續步驟