控管 SSH 登入存取權的最佳做法

本文將說明控管 Linux 虛擬機器 (VM) 執行個體 SSH 登入存取權的最佳做法。

如要有效管理 VM 執行個體的 SSH 存取權，您必須在使用者需要時授予存取權，並在使用者不再需要時撤銷存取權。如果撤銷存取權的程序不穩定或未涵蓋所有資源，惡意人士可能會在應撤銷存取權後，仍能保有存取權。

以下各節提供的最佳做法，有助於確保有效的存取權撤銷，並防範持續性威脅：

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

使用 OS 登入，確保持續依據 IAM 政策評估存取權

Compute Engine 公開 Linux 映像檔已設定為允許 SSH 公開金鑰驗證。如要授權使用者使用公開金鑰，並授予他們建立 SSH 工作階段的權限，您可以使用下列兩種機制之一：

  • 以中繼資料為準的金鑰授權：您可以將使用者的公開金鑰上傳至 VM 或專案中繼資料，也可以授予使用者修改中繼資料的權限，讓他們自行上傳。

    上傳至單一 VM 中繼資料的公開金鑰，只會授予使用者對該 VM 的根目錄權限；上傳至專案中繼資料的金鑰，則會授予使用者對專案中所有 VM 的存取權。

  • OS 登入金鑰授權：使用者可將一或多個公開金鑰上傳至 OS 登入設定檔，該設定檔屬於 Google 使用者帳戶。

    管理員可以決定是否要授予使用者 VM 的根目錄權限或一般使用者權限，方法是授予 OS 登入管理員使用者 IAM 角色或 OS 登入使用者 IAM 角色。

    gcloud CLI、Google Cloud 控制台瀏覽器內 SSH 用戶端和 IAP Desktop 會自動偵測您使用的機制，並可據此上傳使用者的金鑰。

這兩種機制之間的主要差異在於，根據 IAM 政策評估存取權限的時間點：

  • 使用中繼資料鍵時，系統只會在上傳金鑰時評估存取權一次。

    使用者的金鑰會與 VM 或專案的生命週期綁定，並在您移除金鑰或刪除 VM 或專案前保持有效。停用或刪除使用者帳戶，不會影響其金鑰的有效性。

  • 使用 OS 登入功能時，每當使用者嘗試建立 SSH 工作階段，系統就會評估存取權。

    使用者的金鑰與使用者帳戶的生命週期相關聯。如果您在 Cloud Identity 或 Google Workspace 中停用或刪除使用者，對方的金鑰就無法再用於授予安全殼層存取權。

使用中繼資料提供的金鑰可能會使您面臨持續性威脅：如果使用者未及時從中繼資料中移除公開金鑰，他們可能會保留 SSH 存取權超過必要時間，甚至在離開機構後仍保留存取權。雖然您可以透過定期掃描中繼資料來降低這類風險，但在較大的環境中執行這項作業可能會相當困難，而且可能不足以應付風險，因為以中繼資料為基礎的金鑰會授予使用者 Root 權限。

為防範這類持續性威脅，請勿允許使用者使用以中繼資料為基礎的金鑰。請改為設定專案，強制使用 OS 登入。

使用組織政策強制執行 OS 登入功能的一致使用方式

OS 登入功能由 enable-oslogin 中繼資料鍵控管：在專案或執行個體中繼資料中將 enable-oslogin 設為 TRUE 可啟用 OS 登入功能，將其設為 FALSE 則會停用 OS 登入功能。

如要修改專案層級的中繼資料，您必須具備專案的 compute.projects.setCommonInstanceMetadata 權限。此權限屬於 Compute 執行個體管理員 (roles/compute.instanceAdmin.v1) 和 Compute 管理員 (roles/compute.admin) 角色。同樣地，修改執行個體層級中繼資料時，必須在相應的 VM 執行個體上具備 compute.instances.setMetadata 權限。

執行個體層級中繼資料的優先順序高於專案層級中繼資料。因此，在專案中繼資料中將 enable-oslogin 設為 TRUE 並不足以強制在整個專案中使用 OS 登入功能：如果使用者具備 Compute 執行個體管理員或等同於專案中 VM 執行個體的存取權，他們可以將 enable-oslogin=FALSE 新增至 VM 執行個體的中繼資料，藉此覆寫您的設定。

如要強制使用一致的 OS 登入機制，請勿在專案中繼資料中將 enable-oslogin 設為 TRUE。請改為套用使用組織政策為機構啟用 OS 登入功能，這樣系統就會拒絕在執行個體或專案中繼資料中，將 enable-oslogin 設為 false 的任何嘗試。

暫時性或個別 VM 授予特殊權限角色

如果您有執行不同工作負載且由不同團隊管理的 VM 執行個體，您可以將這些 VM 部署在不同的Google Cloud 專案中，並讓專案使用共用網路，藉此簡化存取權管理。不過，使用個別專案不一定可行，而且某些專案可能會包含多個 VM 執行個體，且不同的 VM 執行個體只能由不同的使用者存取。

每當專案包含這類不同 VM 執行個體的組合時，請避免在專案層級永久授予使用者 Compute 執行個體管理員 等角色。請改為區分僅供檢視和特權存取權：

  • 在專案層級授予使用者 Compute 檢視者或等同的僅供檢視角色。這個角色可讓使用者透過 Google Cloud 控制台瀏覽 VM，但無法讓他們發布 SSH 金鑰或存取 VM。
  • 只針對個別 VM 授予使用者 Compute OS 登入、Compute 執行個體管理員或其他特權角色，或是只在適當時機授予。

使用者離職時停用使用者帳戶

在 Cloud Identity 或 Google Workspace 中停用或刪除使用者帳戶，會自動撤銷使用者的 IAM 權限。由於 OS Login 會先檢查使用者的 IAM 權限，再允許他們建立 SSH 工作階段，因此停用或刪除使用者帳戶也會撤銷使用者對使用 OS Login 的 VM 的存取權。

如果您已將 Cloud Identity 或 Google Workspace 設定為使用外部 IdP 進行單一登入，員工在外部 IdP 和 Cloud Identity 或 Google Workspace 中都會有使用者帳戶。在外部 IdP 中停用或刪除員工的使用者帳戶，會撤銷他們建立新瀏覽器工作階段以存取 Google 服務的權限，但不會立即對 OS 登入作業造成影響：只要員工的 Cloud Identity 或 Google Workspace 使用者帳戶仍處於有效狀態，OS 登入作業就會繼續允許使用者驗證並建立 SSH 連線。

如要在使用者離開機構時可靠地撤銷 SSH 存取權，請務必停用或刪除他們的 Cloud Identity 或 Google Workspace 使用者帳戶。如果您使用外部 IdP，請將其設定為傳播使用者停權事件，以便 OS 登入功能撤銷存取權。

避免授予具有特權服務帳戶的 VM SSH 存取權

如果 VM 執行個體有附加的服務帳戶，在 VM 上執行的應用程式就能向 VM 中繼資料伺服器要求短效憑證，並使用這些憑證以服務帳戶身分運作。

透過 SSH 存取 VM 可讓您取得類似的權限：您可以像應用程式一樣，從 VM 的中繼資料伺服器要求短期憑證，並以附加的服務帳戶身分執行。

由於透過附加的服務帳戶存取 VM 的 SSH 可讓您以服務帳戶身分執行操作，因此 OS 登入功能會要求您具備服務帳戶的 iam.serviceAccounts.actAs 權限，並在您每次連線至 VM 執行個體時檢查此權限。這樣一來，OS 登入功能就能協助維護服務帳戶的安全，並防止 SSH 存取權遭到濫用，進而提升權限。

如要進一步降低與具有特權服務帳戶的 VM 相關的風險，請考慮採用下列替代方案：

  • 除非工作負載需要存取 Google Cloud 資源，否則請勿將服務帳戶連結至 VM。
  • 使用單一用途服務帳戶，並只授予工作負載所需資源的存取權。
  • 要求使用者申請即時存取權，而非永久授予他們存取 VM 和服務帳戶的權限。

限制使用 root 權限

使用 OS 登入並將 OS 登入使用者 (roles/compute.osLogin) 角色授予使用者時，您會指派使用者在 VM 上的有限使用者權限。相反地，如果您授予使用者 OS 登入管理員使用者 (roles/compute.osAdminLogin) 角色、使用中繼資料為基礎的金鑰授權，而不是 OS 登入，或是允許使用者修改 VM 中繼資料，則會隱含授予使用者 VM 的 root 權限。

授予使用者 VM 的 root 權限可能會導致持續性風險：使用者可能會濫用這些權限來建立新的使用者帳戶，或安裝後門，以便持續存取 VM。

為降低這種持續性風險，請限制使用 Root 權限，並只在不需要 Root 權限時授予 OS 登入使用者 (roles/compute.osLogin) 角色。

預先建立 POSIX 設定檔，確保使用者名稱和 UID 一致

每個 Linux VM 都會維護使用者 (/etc/passwd) 和群組 (/etc/groups) 的本機資料庫。當您首次透過 SSH 連線至 Linux VM 時，訪客環境會自動為您建立 Linux 使用者帳戶，並指派 UID。

使用以中繼資料為基礎的鍵時，訪客環境不會將 Linux 使用者連結至您的 Google 使用者帳戶，且可能會在您連線的每個 VM 上指派不同的 UID。如果您使用 NFS 等協定，且在未強制執行跨機器一致 UID 的環境中，使用者可能會以其他使用者的身分執行遠端存取權 (無論是意外還是惡意人士蓄意為之)。

使用以中繼資料為基礎的金鑰時，系統會在訪客環境中讓您選擇要使用的使用者名稱。如果您選擇的是同事先前使用的使用者名稱，系統會以同事的帳戶登入。

您可以使用 OS Login 避免發生這類 UID 和使用者名稱不明確的情況：當您首次使用 OS Login 登入 Linux VM 時，訪客環境會根據 Google 使用者帳戶的 POSIX 設定檔建立 Linux 使用者。POSIX 設定檔可做為 Linux 使用者的範本，並定義下列項目：

  • 在同一 Cloud Identity 或 Google Workspace 帳戶的所有使用者中，Linux 使用者名稱皆為唯一
  • 在所有 Google Cloud 專案中皆不重複的 UID 和 GID
  • 主目錄路徑
  • 其他設定，例如登入殼層

如果您的 Google 帳戶在您首次登入時沒有 POSIX 設定檔，OS Login 會自動為您建立一個。

由 OS 登入分配的使用者名稱和 UID 在您的 Google Cloud環境中是唯一的，但可能與您在 Google Cloud外使用到的使用者名稱和 UID 重疊或不一致。如果您需要在其他環境中維持 OS 登入使用者名稱和 UID 的一致性，最好不要依賴自動建立設定檔的功能。請改用 Directory API 預先建立 OS Login POSIX 設定檔，並指派自訂使用者名稱、UID 和 GID。

後續步驟