保護 SSH 憑證的最佳做法

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

根據預設，Compute Engine 會使用以公開金鑰為基礎的 SSH 驗證機制：使用者會透過自身擁有的物件進行驗證，也就是 SSH 私密金鑰。如果使用者的私密金鑰未妥善保護，可能會落入惡意人士手中，而他們可能會利用這些金鑰存取您的 VM 執行個體。

以下各節將說明可協助您避免金鑰外洩，並降低外洩私密金鑰可能造成的影響的最佳做法：

本文著重於在 Google Cloud上使用 SSH 時，針對 Google Cloud 或特別相關的做法。本文件不涵蓋特定 SSH 用戶端或伺服器實作項目的最佳做法。

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

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

使用 SSH 連線至附加服務帳戶的 VM 時，您也可以向中繼資料伺服器要求短期存取權權杖。因此，授予使用者 VM 的 SSH 存取權，就如同授予使用者以附加服務帳戶的身分執行操作的權限。由於這兩者有相似之處，因此請將 SSH 私密金鑰 (尤其是未受密碼字串保護的金鑰) 視為服務帳戶金鑰：如果這兩種金鑰外洩，可能會讓不肖人士存取 Google Cloud資源。

為機器使用者使用暫時性安全殼層金鑰

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

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

  1. 以不涉及金鑰或密鑰的方式驗證服務帳戶，例如使用已連結的服務帳戶或工作負載身分聯盟。
  2. 使用 ssh-keygen 等工具產生臨時安全殼層金鑰組。

  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 金鑰可降低憑證外洩的風險，並讓您將 Cloud IAM 做為驗證和授權的主要方式。

使用 IAP 補足安全殼層公開金鑰驗證

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

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

為確保在沒有有效 Google 憑證的情況下，無法使用 SSH 金鑰，請使用 IAP 管理 SSH 存取權，並使用防火牆政策，強制執行所有 SSH 存取權皆透過 IAP 執行。

IAP 會充當反向 Proxy，只有在使用者成功使用 Google 憑證進行驗證時，才允許他們建立 SSH 連線至 VM 執行個體。此外，IAP 可讓您限制使用者可連線的 VM，並強制實施情境感知存取權。

使用多重驗證

使用 IAP 管理 SSH 存取權，可讓不肖人士更難利用外洩的憑證存取 VM 執行個體，但這並非不可能：例如，不肖人士可能會入侵工作站，並找到私密安全殼層金鑰和快取的 gcloud CLI 憑證，這些資訊足以通過 IAP 的驗證和授權檢查，並連線至使用者的 VM 執行個體。

您可以將 Cloud Identity 或 Google Workspace 設定為要求使用多重驗證 (MFA)，藉此降低這類憑證竊取攻擊的可能影響。

如果 Cloud Identity 或 Google Workspace 是主要身分識別資訊提供者，請採取以下做法強制執行 MFA：

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

如果您使用外部 IdP 的單一登入功能，請改為執行以下操作：

  1. 設定 Cloud Identity 或 Google Workspace，限制 Google Cloud 服務的工作階段長度，這樣系統就會自動讓快取的憑證失效，使用者也必須定期使用外部 IdP 重新驗證。
  2. 請設定外部 IdP 要求 MFA，並限制其工作階段長度，以便使用者在 Google Cloud 工作階段到期時必須執行 MFA。

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

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

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

使用無法匯出的私密金鑰，或使用密碼字串保護的私密金鑰

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

部分安全殼層用戶端可讓您避免使用檔案型金鑰，並提供其他選項來管理安全殼層私密金鑰，例如：

  • 使用硬體金鑰：最新版本的 OpenSSH 可讓您使用 FIDO2 安全金鑰進行驗證，您也可以設定 OS Login，讓系統只允許已在 Cloud Identity 或 Google Workspace 中註冊的安全金鑰。使用硬體金鑰可避免在電腦的檔案系統中儲存任何私密金鑰內容。
  • 使用作業系統的金鑰儲存設施：例如，IAP Desktop 會避免使用檔案型金鑰，改用 Windows CNG 來保護 SSH 金鑰。

如果無法使用硬體支援或作業系統管理的金鑰，您可以使用密碼字串保護 SSH 私密金鑰：如果使用密碼字串保護的 SSH 金鑰，惡意人士除了需要私密金鑰的副本，還必須知道金鑰的密碼字串。

使用主機金鑰驗證主機

建立 VM 執行個體的 SSH 連線時，您可以使用名稱或 IP 位址來識別 VM 執行個體。名稱和 IP 位址可重新指派及重複使用，昨天指向特定 VM 執行個體的名稱，今天可能不會指向相同的 VM 執行個體。惡意人士可能會刻意重新指派或重複使用名稱或 IP 位址，以冒用 VM 執行個體，並誘使使用者連線至遭到入侵的 VM。

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

SSH 主機金鑰會根據「首次使用時信任」模式運作。如果惡意人士使用中間人 (MITM) 攻擊，讓用戶端在首次使用時連線至並信任錯誤的 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) 私密金鑰提交至來源程式碼存放區，則有更大的風險，讓未經授權的使用者和惡意人士存取金鑰：

  • 惡意人士可能會掃描公開原始碼存放區的原始碼，找出遭到洩漏的金鑰。
  • 日後，您可以決定將私人來源存放區轉換為公開存放區，而無須先檢查金鑰。
  • 其他團隊成員可能會在工作站上儲存原始碼的副本。

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

後續步驟