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

本文說明如何控管 Linux 虛擬機器 (VM) 執行個體的 SSH 登入存取權，並提供相關最佳做法。

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

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

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

使用 OS 登入功能，確保系統持續根據 IAM 政策評估存取權

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

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

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

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

    管理員可以授予 OS Login Admin User IAM 角色或 OS Login User IAM 角色，決定是否要授予使用者 VM 的根層級權限或一般使用者權限。

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

這兩種機制的主要差異在於存取權評估時機，也就是存取權與 IAM 政策的比較時機：

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

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

  • 使用 OS Login 時，系統會在使用者每次嘗試建立 SSH 工作階段時評估存取權。

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

使用以中繼資料為準的金鑰可能會導致持續性威脅：如果未及時從中繼資料中移除使用者的公開金鑰，他們可能會在不必要的情況下保留安全殼層存取權，甚至在離開機構後仍保有存取權。雖然您可以定期檢查中繼資料來降低這項風險，但在較大的環境中，這麼做可能很困難，而且可能不夠充分，因為中繼資料型金鑰會授予使用者根層級權限。

為防範這類持續性威脅，請禁止使用者使用以中繼資料為依據的金鑰。請改為設定專案，強制使用 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 登入：如果使用者對專案中的 VM 執行個體具有 Compute Instance Admin 或同等存取權，就能在 VM 執行個體的中繼資料中新增 enable-oslogin=FALSE，藉此覆寫您的設定。

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

暫時或以 VM 為單位授予特殊權限角色

如果您有執行不同工作負載的 VM 執行個體，且由不同團隊管理，則可將這些 VM 部署在不同Trusted Cloud 專案中，並讓專案使用共用網路，簡化存取權管理作業。但使用個別專案並不一定可行，而且部分專案可能包含 VM 執行個體的組合，其中不同的 VM 執行個體只能供不同的使用者存取。

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

  • 在專案層級授予使用者「Compute 檢視者」或同等的唯讀角色。使用者可透過 Trusted 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 Login：只要員工的 Cloud Identity 或 Google Workspace 使用者帳戶保持啟用狀態，OS Login 就會繼續允許使用者進行驗證及建立 SSH 連線。

如要在使用者離開機構時確實撤銷 SSH 存取權，請務必暫停或刪除對方的 Cloud Identity 或 Google Workspace 使用者帳戶。如果您使用外部 IdP，請設定該 IdP 傳播使用者停權事件，以便 OS Login 撤銷存取權。

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

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

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

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

如要進一步降低與具備高權限服務帳戶的 VM 相關聯的風險，請考慮下列替代方案：

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

限制使用根層級權限

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

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

為協助降低這項持續性風險，請限制使用根層級權限，並僅在不需要根層級權限時，授予 OS Login User (roles/compute.osLogin) 角色。

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

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

使用以中繼資料為準的鍵時，訪客環境不會將 Linux 使用者連結至您的 Google 使用者帳戶，且可能會在您連線的每個 VM 上指派不同的 UID。如果您使用 NFS 等通訊協定，並假設環境中的 UID 一致，但機器間的 UID 並不一致，使用者可能會 (意外或蓄意，如果是惡意行為者) 以其他使用者的身分執行遠端存取。

使用以中繼資料為基礎的金鑰時，您也可以在客體環境中選擇要使用的使用者名稱。如果選擇的帳戶名稱先前由同事使用，系統會以最初為同事建立的帳戶登入。

使用 OS Login 即可避免這類 UID 和使用者名稱的模糊不清問題：首次使用 OS Login 登入 Linux VM 時，訪客環境會根據 Google 使用者帳戶的 POSIX 設定檔建立 Linux 使用者。POSIX 設定檔可做為 Linux 使用者的範本，並定義下列項目：

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

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

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

後續步驟