規定必須具備權限才能將服務帳戶附加至資源

建立特定 Google Cloud 資源時，您可以選擇附加服務帳戶。附加的服務帳戶會做為在資源上執行的任何作業的身分，讓作業向 Google Cloud API 進行驗證。

對於大多數 Google Cloud 服務，使用者必須具備模擬服務帳戶的權限，才能將該服務帳戶附加至資源。也就是說，使用者必須具備服務帳戶的 iam.serviceAccounts.actAs 權限。

不過，在過去，某些服務允許使用者將服務帳戶附加至資源，即使使用者沒有模擬服務帳戶的權限也一樣。這項設定可能導致這些服務的使用者取得進階權限，但不會察覺。

下表列出具有這項設定的服務，以及各項服務的舊版行為：

服務	舊版行為
App Engine	即使使用者沒有模擬 App Engine 預設服務帳戶的權限，仍可部署使用該帳戶身分的 App Engine 應用程式。
Cloud Composer	使用者可將專案中的任何服務帳戶附加至 Cloud Composer 環境，即使他們沒有模擬專案中任何服務帳戶的權限也一樣。
Cloud Data Fusion Dataflow Dataproc	使用者可將 Compute Engine 預設服務帳戶附加至資源，即使他們沒有模擬預設服務帳戶的權限也一樣。
Dataform	使用者可將服務帳戶附加至 Dataform 資源，並建立以該服務帳戶身分執行的工作流程叫用，即使他們沒有模擬服務帳戶的權限也沒問題。

現在，這些服務會要求使用者在將服務帳戶附加至資源時，確認使用者有權模擬服務帳戶。不過，下列類型的機構仍會沿用舊版行為：

機構中的使用者有權部署 App Engine 應用程式，但無權模擬 App Engine 預設服務帳戶。
機構中的使用者有權部署 Cloud Composer 環境，但無權模擬任何服務帳戶。
如果機構中的使用者有權部署 Cloud Data Fusion、Dataflow 或 Dataproc 資源，但無權模擬 Compute Engine 預設服務帳戶。
如果機構中的使用者有權將服務帳戶附加至 Dataform 資源並建立工作流程調用，但無權模擬服務帳戶。

如果貴機構仍受舊版行為影響，您應該會收到說明如何手動停用這項功能的通知。您也可以參閱下列章節的詳細操作說明。

保護 App Engine

如要手動停用 App Engine 的舊版行為，請確保使用者有權模擬 App Engine 服務帳戶。然後，啟用機構政策限制，在部署使用 App Engine 預設服務帳戶身分的應用程式時，強制執行服務帳戶權限檢查。

選用：使用角色建議，安全地縮減 App Engine 預設服務帳戶的權限範圍。

系統會自動將權限極為寬鬆的編輯者角色 (roles/editor) 授予 App Engine 預設服務帳戶。不過，我們不建議在正式環境設定中使用這類權限極為寬鬆的角色。

注意： 為進一步保護貴機構，您可以停用自動將角色授予服務帳戶的功能
確認所有部署應用程式的使用者都能模擬 App Engine 預設服務帳戶。

如要提供這項功能，請授予使用者包含 iam.serviceAccounts.actAs 權限的角色，例如服務帳戶使用者角色 (roles/iam.serviceAccountUser)。您可以在專案或 App Engine 預設服務帳戶中授予這項角色。如需操作說明，請參閱「管理服務帳戶模擬功能」。

注意： 如果專案數量眾多，可以使用權限差異尋找工具，找出有權部署應用程式，但無權模擬 App Engine 預設服務帳戶的使用者。
啟用機構政策限制，在部署應用程式時強制執行服務帳戶權限檢查。constraints/appengine.enforceServiceAccountActAsCheck

注意： 只有在採用舊版行為的環境中，才會顯示這項機構政策限制。如果沒有看到限制，表示環境中已強制執行限制。
選用：使用布林值機構政策強制執行工具，確認所有專案都已強制執行機構政策限制。

保護 Cloud Composer 安全

如要手動停用 Cloud Composer 的舊版行為，請確保使用者有權模擬附加至新環境的服務帳戶。然後啟用機構政策限制，在將服務帳戶附加至環境時，強制執行服務帳戶權限檢查。

找出與 Cloud Composer 環境繫結的所有服務帳戶：
1. 前往 Google Cloud 控制台的「Composer environments」(Composer 環境) 頁面。
  
  前往 Composer 環境頁面
2. 按一下環境名稱。
3. 在「環境設定」分頁中，找出「服務帳戶」欄位，並記錄服務帳戶的名稱。
4. 針對專案中的所有 Cloud Composer 環境重複上述步驟。
確認這些服務帳戶遵循最低權限原則：
- 前往 Google Cloud 控制台的「IAM」頁面，找出服務帳戶並檢查其角色。
  
  前往「IAM」頁面
- 如有需要，請將權限較少的角色授予服務帳戶。您可以從 IAM 預先定義的角色清單中選取角色、使用角色建議提供的角色，或建立自訂角色。
請確保所有部署或管理 Cloud Composer 環境的使用者，都能模擬環境使用的服務帳戶。

如要提供這項功能，請授予使用者包含 iam.serviceAccounts.actAs 權限的角色，例如服務帳戶使用者角色 (roles/iam.serviceAccountUser)。您可以對專案或個別服務帳戶授予這項角色。如需操作說明，請參閱「管理服務帳戶模擬功能」。

注意： 如果專案數量眾多，可以使用權限差異尋找工具，找出有權部署 Cloud Composer 環境，但無權模擬服務帳戶的使用者。
啟用機構政策限制 constraints/composer.enforceServiceAccountActAsCheck，在將服務帳戶附加至環境時，強制執行服務帳戶權限檢查。

注意： 只有在採用舊版行為的環境中，才會顯示這項機構政策限制。如果沒有看到限制，表示環境中已強制執行限制。
選用：使用布林值機構政策強制執行工具，確認所有專案都已強制執行機構政策限制。

保護 Dataproc、Dataflow 和 Cloud Data Fusion

如要手動停用 Dataproc、Dataflow 和 Cloud Data Fusion 的舊版行為，請確保使用者有權模擬附加至新資源的服務帳戶。然後啟用機構政策限制，在將服務帳戶附加至資源時，強制執行服務帳戶權限檢查。

請按照要附加至新資源的服務帳戶類型，依下列操作說明進行：

如要停止將 Compute Engine 預設服務帳戶附加至新資源，請按照下列步驟操作：

注意： 在 Cloud Data Fusion 中，只有 Cloud Data Fusion Enterprise 客戶可以使用 Compute Engine 預設服務帳戶以外的服務帳戶。詳情請參閱「Cloud Data Fusion 服務帳戶」。
1. 建立新的服務帳戶，並授予該服務帳戶在資源上執行作業所需的角色。請務必遵循最低權限原則。
  
  如要瞭解服務帳戶在 Dataproc、Dataflow 和 Cloud Data Fusion 資源上執行工作時需要哪些角色，請參閱下列文章：
  - Dataproc 服務帳戶規定
  - Dataflow 服務帳戶規定
  - Cloud Data Fusion 服務帳戶與 Dataproc 服務帳戶有相同的需求。
2. 允許部署這些資源的所有使用者模擬新服務帳戶。
  
  如要提供這項功能，請授予使用者包含 iam.serviceAccounts.actAs 權限的角色，例如服務帳戶使用者角色 (roles/iam.serviceAccountUser)。您可以在專案或服務帳戶中授予這項角色。如需操作說明，請參閱「管理服務帳戶模擬功能」。
3. 啟用下列機構政策限制，在將服務帳戶附加至資源時，強制執行服務帳戶權限檢查：
  - constraints/dataflow.enforceComputeDefaultServiceAccountCheck
  - constraints/dataproc.enforceComputeDefaultServiceAccountCheck
  機構政策限制 constraints/dataproc.enforceComputeDefaultServiceAccountCheck 也會強制執行 Cloud Data Fusion 的權限檢查。
  
  注意： 只有在採用舊版行為的環境中，才能看到這些機構政策限制。如果沒有看到限制，表示環境中已強制執行限制。
4. 選用：使用布林機構政策強制執行工具，確認所有專案都強制執行機構政策限制。
5. 部署新資源時，請使用新的服務帳戶，而非 Compute Engine 預設服務帳戶。
如要繼續將 Compute Engine 預設服務帳戶附加至新資源，請按照下列步驟操作：
1. 選用：使用角色建議，安全地縮減 Compute Engine 預設服務帳戶的權限範圍。
  
  系統會自動將權限極為寬鬆的編輯者角色 (roles/editor) 授予 Compute Engine 預設服務帳戶。不過，我們不建議在正式版設定中使用這類權限極為寬鬆的角色。
  
  注意： 為進一步保護貴機構，您可以停用服務帳戶的自動角色授予功能。
2. 請確認部署這些資源的所有使用者，都能模擬 Compute Engine 預設服務帳戶。
  
  如要提供這項功能，請授予使用者包含 iam.serviceAccounts.actAs 權限的角色，例如服務帳戶使用者角色 (roles/iam.serviceAccountUser)。您可以在專案或 Compute Engine 預設服務帳戶中授予這項角色。如需操作說明，請參閱「管理服務帳戶模擬功能」。
  
  注意： 如果您有大量專案，可以使用權限差異尋找工具，找出有權部署資源，但無權模擬 Compute Engine 預設服務帳戶的使用者。
3. 啟用下列機構政策限制，在將服務帳戶附加至資源時，強制執行服務帳戶權限檢查：
  - constraints/dataflow.enforceComputeDefaultServiceAccountCheck
  - constraints/dataproc.enforceComputeDefaultServiceAccountCheck
4. 選用：使用布林機構政策強制執行工具，確認所有專案都強制執行機構政策限制。

保護 Dataform 安全

如要手動停用 Dataform 的舊版行為，請確保使用者有權模擬附加至 Dataform 資源的服務帳戶。接著，啟用嚴格的「以服務帳戶身分執行」模式，在建立工作流程調用時強制執行服務帳戶權限檢查。

檢查權限問題，避免工作流程中斷。如要這麼做，請查詢 Cloud Logging 中 Dataform 專屬的項目，這些項目會指出主體 (使用者或服務帳戶) 缺少必要的 iam.serviceAccounts.actAs 權限。這有助於主動找出並解決任何存取權差異。詳情請參閱「在 Cloud Logging 中檢查權限問題」。
如要讓使用者或服務帳戶建立工作流程叫用，請授予他們模擬與 Dataform 存放區相關聯服務帳戶的權限。如要提供這項權限，請在特定服務帳戶上授予服務帳戶使用者角色 (roles/iam.serviceAccountUser)。詳情請參閱「解決權限問題」。
如果您使用自訂服務帳戶，請將下列角色授予自訂服務帳戶的預設 Dataform 服務代理程式：
- 服務帳戶憑證建立者 (roles/iam.serviceAccountTokenCreator)：使用自訂服務帳戶進行所有存放區作業時，必須具備這項角色。
- 服務帳戶使用者 (roles/iam.serviceAccountUser)：只有在使用工作流程設定排定或自動執行作業時才需要。這個角色可讓預設 Dataform 服務代理程式以自訂服務帳戶身分執行工作。
如要強制執行 act-as 權限檢查，請啟用嚴格 act-as 模式。這項功能會驗證建立工作流程調用的使用者是否擁有有效服務帳戶的 iam.serviceAccounts.actAs 權限，藉此提升安全性。
- 如果是新存放區，系統預設會啟用嚴格 act-as 模式。
- 如為現有存放區，請將 strict_act_as_checks 旗標設為 true，以更新存放區。
詳情請參閱「使用嚴格的『扮演』模式」。
定期稽核 Dataform 資源，確保服務帳戶使用情形和權限授予作業正確無誤。使用 Cloud Asset Inventory 列出所有 dataform.Repository 和 dataform.WorkflowConfig 類型的資源，然後檢查 resource.data.serviceAccount 欄位，確認使用的服務帳戶。如果使用自訂服務帳戶，請確認預設 Dataform 服務代理程式在該自訂服務帳戶中，同時具備服務帳戶使用者 (roles/iam.serviceAccountUser) 和服務帳戶權杖建立者 (roles/iam.serviceAccountTokenCreator) 角色。詳情請參閱「稽核服務帳戶設定」。