Dataflow 安全性和權限

您可以使用 Dataflow 執行工具，在本機或代管 Google Cloud資源上執行 Dataflow 管道。無論是在本機或雲端執行管道，管道及其 worker 都會使用權限系統，維護管道檔案和資源的安全存取權。Dataflow 權限會根據用來存取管道資源的角色指派。本文說明下列概念：

• 升級 Dataflow VM
• 執行本機和 Google Cloud 管道所需的角色和權限
• 存取管道資源所需的角色和權限
• Dataflow 服務和資料安全性使用的資料類型

事前準備

請參閱 Google Cloud Google Cloud 總覽中的專案 ID 相關資訊。這些識別碼包含專案名稱、專案 ID 和專案編號。

升級 Dataflow VM 並套用修補程式

Dataflow 使用 Container-Optimized OS。Container-Optimized OS 的安全性程序也適用於 Dataflow。如要進一步瞭解 Google 如何保護及強化這些 VM，請參閱「Worker VM 安全性和強化」。

批次管道有時間限制，不需要維護。新的批次管道啟動時，系統會使用最新的 Dataflow 映像檔。

如果是串流管道，若需要立即套用安全性修補程式，Google Cloud 會透過安全性公告通知您。如果是串流管道，建議使用 --update 選項，以最新的 Dataflow 映像檔重新啟動工作。

Dataflow 容器映像檔可在Google Cloud 控制台中取得。

容器映像檔安全性

Dataflow 會使用容器映像檔，做為管道使用者程式碼的執行階段環境。根據預設，系統會使用預先建構的 Apache Beam 映像檔。您也可以提供自訂容器。

Google 會強化及修補 Dataflow 擁有的映像檔所使用的基本映像檔作業系統。Google 會及時提供這些映像檔的修補程式。所有 Dataflow 正式環境資源 (包括預設提供的 Beam 映像檔) 都會自動定期掃描，找出安全漏洞。Google 擁有的容器中，任何已識別的問題都會根據定義的服務水準目標 (SLO) 解決。Beam 容器中的問題由 Beam 社群處理。根據 Dataflow 的共同責任模式，建議您使用自訂容器映像檔，以便及時管理安全性問題。

雖然 Dataflow 使用的 Container-Optimized OS 映像檔符合 CIS 第 1 級標準，但要達到整體法規遵循，需要共同承擔責任。執行這些容器的 VM 執行個體位於客戶的專案中。客戶有責任掃描自己的專案資源。您可以使用 Security Command Center 掃描資源，檢查法規遵循情形和安全漏洞。

執行階段環境

Dataflow 會使用預先建構的 Apache Beam 映像檔，或您提供的自訂容器，做為管道使用者程式碼的執行階段環境。

Dataflow 服務會選取執行容器的使用者。Dataflow 不允許您以非超級使用者的身分，執行自訂 SDK 容器映像檔或 Flex 範本的自訂範本容器映像檔。

與其他環境 (例如 Google Kubernetes Engine (GKE)) 不同，容器在共用節點上執行，Dataflow worker VM 不會在管道之間共用。管道資源會依工作分配。VM 和其他資源不會跨管道共用。

執行階段環境生命週期與管道生命週期相關聯。這項作業會在管道啟動時開始，並在管道終止時停止。在執行管道期間，執行階段環境可能會重新啟動一或多次。

本機管道的安全性與權限

在本機執行時，Apache Beam 管道會以Google Cloud 帳戶的身分執行，該帳戶是使用 Google Cloud CLI 可執行檔設定。在本機執行的 Apache Beam SDK 作業和您的 Google Cloud帳戶，可以存取相同的檔案和資源。

如要列出您選為預設的 Google Cloud 帳戶，請執行 gcloud config list 指令。

本機管道可將資料輸出至本機目的地 (例如本機檔案)，或雲端目的地 (例如 Cloud Storage 或 BigQuery)。如果在本機執行的管道會將檔案寫入 Cloud Storage 等雲端式資源，則會使用您的 Google Cloud 帳戶憑證，以及您設為 Google Cloud CLI 預設值的 Google Cloud 專案。如要瞭解如何使用 Google Cloud 帳戶憑證進行驗證，請參閱您所用語言的教學課程：Java、Python或 Go。

Google Cloud管道的安全性和權限

執行管道時，Dataflow 會使用兩個服務帳戶來管理安全性和權限：

• Dataflow 服務帳戶。Dataflow 服務會使用 Dataflow 服務帳戶，做為工作建立要求的一部分，例如檢查專案配額，以及代表您建立 worker 執行個體。Dataflow 也會在執行工作時，使用 Dataflow 服務帳戶管理工作。這個帳戶也稱為 Dataflow 服務代理。

• worker 服務帳戶。提交工作後，worker 執行個體會使用 worker 服務帳戶存取輸入和輸出資源。根據預設，worker 會使用與專案相關聯的 Compute Engine 預設服務帳戶，做為 worker 服務帳戶。建議您指定使用者自行管理的服務帳戶，而非使用預設的 worker 服務帳戶。

如要在執行管道時模擬服務帳戶，啟動管道的帳戶必須具備 iam.serviceAccounts.actAs 權限。服務帳戶使用者角色 (roles/iam.serviceAccountUser) 包含這項權限。模擬服務帳戶可讓您暫時採用其身分和權限，執行需要不同存取層級的工作，同時避免與永久金鑰相關的風險。詳情請參閱「使用服務帳戶模擬功能」。

視其他專案權限而定，您的使用者帳戶可能也需要 roles/dataflow.developer 角色。如果您是專案擁有者或編輯者，就已具備 roles/dataflow.developer 角色包含的權限。

最佳做法

• 建議您盡可能為 worker 服務帳戶指定使用者自行管理的服務帳戶，而非使用預設的 worker 服務帳戶。
• 授予資源權限時，請授予包含執行工作所需最低權限的角色。您可以建立自訂角色，只納入必要權限。
• 授予資源存取權角色時，請盡可能使用最低資源層級。例如，請在 BigQuery 資料表上授予 roles/bigquery.dataEditor 角色，而非在專案或資料夾上授予。
• 建立專案擁有的 bucket，做為 Dataflow 的暫存 bucket。預設 bucket 權限允許 Dataflow 使用 bucket 暫存管道的可執行的檔案。

Dataflow 服務帳戶

所有使用過資源 Dataflow Job 的專案都有 Dataflow 服務帳戶，也稱為 Dataflow 服務代理，其電子郵件地址如下：

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

這個服務帳戶由 Google 建立及管理，並在首次使用資源 Dataflow Job 時自動指派給您的專案。

執行 Dataflow 管道時，Dataflow 會代您操作資源。例如，建立額外的 VM。使用 Dataflow 執行管道時，系統會使用這個服務帳戶。

這個帳戶在專案中獲派 Dataflow 服務代理角色。具備在專案中執行 Dataflow 工作的必要權限，包括啟動 Compute Engine worker。這個帳戶僅供 Dataflow 使用，且專屬於您的專案。

您可以在Google Cloud 控制台或 Google Cloud CLI 中，查看指派給 Dataflow 服務帳戶的角色。

gcloud iam roles describe roles/dataflow.serviceAgent

由於 Google Cloud 服務需要具備專案及其資源的讀取和寫入權限，建議您不要變更系統自動為專案建立的預設權限。如果 Dataflow 服務帳戶失去專案權限，Dataflow 就無法啟動 VM 或執行其他管理工作。

如果從 Identity and Access Management (IAM) 政策中移除服務帳戶的權限，帳戶仍會存在，因為該帳戶由 Dataflow 服務擁有。

worker 服務帳戶

Compute Engine 執行個體會在雲端執行 Apache Beam SDK 作業。這些 worker 會使用專案的 worker 服務帳戶，存取與管道相關聯的檔案和其他資源。worker 服務帳戶會做為所有 worker VM 的身分，且所有源自 VM 的要求都會使用 worker 服務帳戶。這個服務帳戶也用於與 Cloud Storage bucket 和 Pub/Sub 主題等資源互動。

• worker 服務帳戶必須具備 roles/dataflow.worker 角色，才能執行工作。
• worker 服務帳戶必須具備 roles/dataflow.admin 角色，才能建立或檢查工作。

此外，當 Apache Beam 管道存取 Google Cloud 資源時，您必須將必要角色授予 Dataflow 專案的 worker 服務帳戶。執行 Dataflow 工作時，worker 服務帳戶必須能存取資源。舉例來說，如果工作會寫入 BigQuery，服務帳戶也必須至少具備 BigQuery 資料表的 roles/bigquery.dataEditor 角色。資源範例包括：

• Cloud Storage bucket
• BigQuery 資料集
• Pub/Sub 主題和訂閱項目
• Firestore 資料集

預設 worker 服務帳戶

根據預設，worker 會使用專案的 Compute Engine 預設服務帳戶做為 worker 服務帳戶。這個服務帳戶的電子郵件地址如下：

PROJECT_NUMBER-compute@developer.gserviceaccount.com

當您在 Google Cloud 控制台的 API 程式庫中為專案啟用 Compute Engine API 時，系統會自動建立這個服務帳戶。

雖然您可以使用 Compute Engine 預設服務帳戶做為 Dataflow worker 服務帳戶，但建議您建立專屬的 Dataflow worker 服務帳戶，僅具備所需角色和權限。

視組織政策設定而定，預設服務帳戶可能會自動獲得專案的編輯者角色。強烈建議您 強制執行 iam.automaticIamGrantsForDefaultServiceAccounts 組織政策限制，停用自動角色授予功能。如果組織是在 2024 年 5 月 3 日後建立，系統預設會強制執行這項限制。

停用此功能後，您必須決定要將哪些角色授予預設服務帳戶，然後自行授予這些角色。

如果預設服務帳戶已具備「編輯者」角色，建議您將「編輯者」角色替換為權限較少的角色。如要安全修改服務帳戶的角色，請使用 Policy Simulator 查看變更會造成的影響，然後授予及撤銷適當的角色。

指定使用者代管的 worker 服務帳戶

如要建立及使用具備精細存取控管功能的資源，可以建立使用者自行管理的服務帳戶。將這個帳戶做為 worker 服務帳戶。

1. 如果您沒有使用者自行管理的服務帳戶，請建立服務帳戶。

2. 為服務帳戶設定必要的 IAM 角色。

   • worker 服務帳戶必須具備 roles/dataflow.worker 角色，才能執行工作。
   • worker 服務帳戶必須具備 roles/dataflow.admin 角色，才能建立或檢查工作。
   • 或者，您也可以建立具備必要權限的自訂 IAM 角色。如需必要權限清單，請參閱「角色」。

3. 服務帳戶可能需要額外角色，才能使用工作所需的 Google Cloud資源，例如 BigQuery、Pub/Sub 或 Cloud Storage。舉例來說，如果工作會從 BigQuery 讀取資料，服務帳戶也必須至少具備 BigQuery 資料表的 roles/bigquery.dataViewer 角色。

4. 請確認使用者自行管理的服務帳戶，具備 Dataflow 工作中指定暫存位置的讀取和寫入權限。

5. 如要啟動管道，使用者帳戶必須具備 iam.serviceAccounts.actAs 權限，才能模擬 worker 服務帳戶。

6. 在包含使用者自行管理 worker 服務帳戶的專案中，Dataflow 服務帳戶 (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) 和 Compute Engine 服務代理 (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) 必須具備下列角色。PROJECT_NUMBER 是執行 Dataflow 工作的專案 ID。這兩個帳戶都是服務代理。

   • 服務帳戶權杖建立者角色 (iam.serviceAccountTokenCreator)
   • 服務帳戶使用者角色 (iam.serviceAccountUser)

   假設 Dataflow 工作在專案 A 執行，而 worker 服務帳戶託管於專案 B，請確認專案 A 的服務代理在專案 B 具備 iam.serviceAccountTokenCreator 和 iam.serviceAccountUser 角色。在執行 Dataflow 工作的專案中，帳戶預設具備這些角色。如要授予這些角色，請按照「管理服務帳戶存取權」頁面中「授予單一角色」一節的步驟操作。

7. 如果使用者代管的 worker 服務帳戶和工作位於不同專案，請確認擁有使用者代管服務帳戶的專案未強制執行 iam.disableCrossProjectServiceAccountUsage 布林限制。詳情請參閱「啟用跨專案附加服務帳戶功能」。

8. 執行管道工作時，請指定服務帳戶。

   Java

   從指令列執行管道工作時，請使用 --serviceAccount 選項並指定服務帳戶：--serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   以 Flex 範本執行管道工作時，請使用 --service-account-email 選項並指定服務帳戶：--service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Python

   執行管道工作時，請使用 --service_account_email 選項並指定服務帳戶：--service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Go

   執行管道工作時，請使用 --service_account_email 選項並指定服務帳戶：--service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

使用者自行管理的服務帳戶可以與工作位於相同專案，也可以位於不同專案。如果服務帳戶和工作位於不同專案，您必須先設定服務帳戶，才能執行工作。

查看工作的 worker 服務帳戶

如果是現有工作，worker 服務帳戶電子郵件會儲存在 Job 資源的 environment.serviceAccountEmail 欄位 (RPC 和用戶端程式庫中的 environment.service_account_email)。

如要擷取 environment 物件和 serviceAccountEmail，您必須在取得工作時要求 JOB_VIEW_DESCRIPTION 或 JOB_VIEW_ALL 工作檢視畫面。使用 JOB_VIEW_SUMMARY 的要求 (包括 projects.locations.jobs.list 和預設摘要查詢) 會省略 environment.serviceAccountEmail。

唯讀 API 呼叫 (例如 projects.locations.jobs.get) 用於檢查工作中繼資料，不會產生單次要求費用。API 呼叫須遵守標準監控和 API 配額，而 Dataflow 費用則適用於管道運算、儲存和資料處理資源。詳情請參閱「定價」一文。

gcloud dataflow jobs describe JOB_ID \
    --region=REGION \
    --project=PROJECT_ID \
    --full \
    --format="value(environment.serviceAccountEmail)"

curl -X GET \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?view=JOB_VIEW_DESCRIPTION"

{
  "id": "JOB_ID",
  "projectId": "PROJECT_ID",
  "name": "JOB_NAME",
  "environment": {
    "serviceAccountEmail": "SERVICE_ACCOUNT_EMAIL"
  }
}

from google.cloud import dataflow_v1beta3

client = dataflow_v1beta3.JobsV1Beta3Client()
request = dataflow_v1beta3.GetJobRequest(
    project_id="PROJECT_ID",
    location="REGION",
    job_id="JOB_ID",
    view=dataflow_v1beta3.JobView.JOB_VIEW_DESCRIPTION,
)
job = client.get_job(request=request)
print(job.environment.service_account_email)

import com.google.dataflow.v1beta3.GetJobRequest;
import com.google.dataflow.v1beta3.Job;
import com.google.dataflow.v1beta3.JobView;
import com.google.dataflow.v1beta3.JobsV1Beta3Client;

try (JobsV1Beta3Client jobsClient = JobsV1Beta3Client.create()) {
  GetJobRequest request =
      GetJobRequest.newBuilder()
          .setProjectId("PROJECT_ID")
          .setLocation("REGION")
          .setJobId("JOB_ID")
          .setView(JobView.JOB_VIEW_DESCRIPTION)
          .build();
  Job job = jobsClient.getJob(request);
  System.out.println(job.getEnvironment().getServiceAccountEmail());
}

import (
        "context"

        dataflow "cloud.google.com/go/dataflow/apiv1beta3"
        dataflowpb "cloud.google.com/go/dataflow/apiv1beta3/dataflowpb"
)

ctx := context.Background()
client, err := dataflow.NewJobsV1Beta3Client(ctx)
if err != nil {
        // Handle error.
}
defer client.Close()

req := &dataflowpb.GetJobRequest{
        ProjectId: "PROJECT_ID",
        Location:  "REGION",
        JobId:     "JOB_ID",
        View:      dataflowpb.JobView_JOB_VIEW_DESCRIPTION,
}
job, err := client.GetJob(ctx, req)
if err != nil {
        // Handle error.
}
serviceAccountEmail := job.GetEnvironment().GetServiceAccountEmail()
_ = serviceAccountEmail

如需其他語言的完整用戶端程式庫範例，請參閱 GetJob 程式碼範例。

新增角色

如要在專案中新增角色，請按照下列步驟操作。

存取 Google Cloud 資源

Apache Beam 管道可以存取 Google Cloud 資源，無論資源位於相同 Google Cloud 專案或其他專案。這些資源包括：

• Artifact Registry 存放區
• Cloud Storage bucket
• BigQuery 資料集
• Pub/Sub 主題和訂閱項目
• Firestore 資料集

為確保 Apache Beam 管道可以存取這些資源，您必須使用資源各自的存取控管機制，明確授予 Dataflow 專案 worker 服務帳戶存取權。

如果您將 Assured Workloads 功能與 Dataflow 搭配使用，例如歐盟區域和支援主權控管，則管道存取的所有 Cloud Storage、BigQuery、Pub/Sub、I/O 連接器和其他資源，都必須位於貴組織的 Assured Workloads 專案或資料夾中。

如果您使用使用者自行管理的 worker 服務帳戶，或存取其他專案中的資源，可能需要採取額外行動。下列範例假設您使用 Compute Engine 預設服務帳戶，但您也可以使用使用者自行管理的 worker 服務帳戶。

存取 Artifact Registry 存放區

在 Dataflow 中使用自訂容器時，您可能會將構件上傳至 Artifact Registry 存放區。

如要搭配使用 Artifact Registry 和 Dataflow，您必須至少將 Artifact Registry 寫入者存取權 (role/artifactregistry.writer) 授予執行 Dataflow 工作的 worker 服務帳戶。

所有存放區內容都會使用 Google-owned and Google-managed encryption keys 或客戶自行管理的加密金鑰加密。Artifact Registry 預設會使用Google-owned and Google-managed encryption keys ，您不需設定這個選項。

存取 Cloud Storage bucket

如要將 Cloud Storage bucket 的存取權授予 Dataflow 專案，請將 bucket 的存取權授予 Dataflow 專案worker 服務帳戶。服務帳戶至少需要值區及其內容的讀取和寫入權限。您可以使用 Cloud Storage 的 IAM 權限，授予必要的存取權。

如要授予 worker 服務帳戶讀取及寫入 bucket 的必要權限，請使用 gcloud storage buckets add-iam-policy-binding 指令。這個指令會將 Dataflow 專案服務帳戶新增至值區層級政策。

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE

更改下列內容：

• BUCKET_NAME：Cloud Storage bucket 的名稱
• PROJECT_NUMBER：Dataflow 專案編號。如要找出專案編號，請參閱「識別專案」或使用 gcloud projects describe 指令。
• SERVICE_ACCOUNT_ROLE：IAM 角色，例如 storage.objectViewer

如要擷取Google Cloud 專案中的 Cloud Storage bucket 清單，請使用 gcloud storage buckets list 指令：

gcloud storage buckets list --project= PROJECT_ID

將 PROJECT_ID 替換為專案 ID。

除非您受到限制資源共用的組織政策限制，否則可以存取與 Dataflow 管道位於不同專案中的 bucket。如要進一步瞭解網域限制，請參閱「依照網域設定身分限制」。

如果沒有 bucket，請建立新的 bucket。接著，授予 worker 服務帳戶必要的權限，以便讀取及寫入 bucket。

您也可以透過 Google Cloud 控制台設定 bucket 權限。詳情請參閱「設定 bucket 權限」。

Cloud Storage 提供兩種系統，可授予使用者值區和物件的存取權：IAM 和存取控管清單 (ACL)。在多數情況下，建議使用 IAM 控制資源存取權。

• IAM 可控管整個Google Cloud 的權限，並讓您在 bucket 和專案層級授予權限。如要查看與 Cloud Storage 相關聯的 IAM 角色清單，以及各角色包含的權限，請參閱「Cloud Storage 的 IAM 角色」。如需進一步控管權限，請建立自訂角色。

• 如果您使用 ACL 控管存取權，請確認 worker 服務帳戶權限與 IAM 設定一致。由於 IAM 和 ACL 政策不一致，當 Cloud Storage bucket 從精細存取權遷移至統一 bucket 層級存取權時，Dataflow 工作可能無法存取 Cloud Storage bucket。詳情請參閱「常見錯誤指南」。

存取 BigQuery 資料集

您可以使用 BigQueryIO API，存取與 Dataflow 相同或不同專案中的 BigQuery 資料集。為確保 BigQuery 來源和接收器正常運作，下列兩個帳戶必須有權存取 Dataflow 工作讀取或寫入的任何 BigQuery 資料集：

• 用於執行 Dataflow 工作的 Google Cloud 帳戶
• 執行 Dataflow 工作的 worker 服務帳戶

您可能需要設定 BigQuery 以明確為這些帳戶授予存取權。如要進一步瞭解如何使用 BigQuery 頁面或 BigQuery API 授予 BigQuery 資料集的存取權，請參閱「BigQuery 存取控管」。

在必要的 BigQuery 權限中，管道需要 bigquery.datasets.get IAM 權限，才能存取 BigQuery 資料集。一般來說，大多數 BigQuery IAM 角色都包含 bigquery.datasets.get 權限，但 roles/bigquery.jobUser 角色除外。

存取 Pub/Sub 主題和訂閱項目

如要存取 Pub/Sub 主題或訂閱項目，請使用 Pub/Sub 的 Identity and Access Management 功能，設定 worker 服務帳戶的權限。

下列 Pub/Sub 角色的權限與此相關：

• roles/pubsub.subscriber是必要資料。
• 必須具備 roles/pubsub.editor，才能建立 Pub/Sub 訂閱項目。
• 建議使用 roles/pubsub.viewer，讓 Dataflow 查詢主題和訂閱項目的設定。這項設定有兩項優點：
  • Dataflow 可檢查訂閱項目中是否有不支援的設定，避免發生無法正常運作的情況。
  • 如果訂閱項目不使用預設的 10 秒確認期限，效能就會提升。Dataflow 會在管道處理訊息時，重複延長訊息的確認期限。如果沒有 pubsub.viewer 權限，Dataflow 就無法查詢確認期限，因此必須假設預設期限。這項設定會導致 Dataflow 發出過多 modifyAckDeadline 要求。
  • 如果擁有訂閱項目或主題的專案已啟用 VPC Service Controls，則 Dataflow 無法透過以 IP 位址為基礎的輸入規則查詢設定。在這種情況下，您必須根據 worker 服務帳戶設定輸入規則。

如需更多資訊和程式碼範例，瞭解如何使用 Pub/Sub 的 Identity and Access Management 功能，請參閱「用途範例：跨專案通訊」。

存取 Firestore

如要存取 Firestore 資料庫 (原生模式或 Datastore 模式)，請將 Dataflow worker 服務帳戶 (例如 PROJECT_NUMBER-compute@developer.gserviceaccount.com) 新增為資料庫擁有者專案的編輯者，或使用限制較多的 Datastore 角色，例如 roles/datastore.viewer。此外，請在 Google Cloud 控制台的 API 程式庫中，為這兩項專案啟用 Firestore API。

存取具有可信映像檔政策的專案映像檔

如果您已為專案設定可信映像檔政策，且開機映像檔位於其他專案，請確認可信映像檔政策已設為可存取該映像檔。舉例來說，如果您執行的是 Dataflow 範本工作，請確認政策檔案包含 dataflow-service-producer-prod 專案的存取權。這個 Google Cloud 專案包含範本工作的映像檔。

使用主體存取邊界政策存取 Google 提供的範本

如果貴組織使用主體存取權邊界 (PAB) 政策，主體 (例如使用者或服務帳戶) 可能無法查看及執行 Google 提供的範本。在這種情況下，請嘗試下列其中一種解決方案：

• 更新主體存取邊界政策，允許存取託管 Google 提供的範本的 Google 代管專案。將 dataflow-templates 專案 (或專案編號 473832897378) 新增至主體存取邊界政策，做為允許的資源：

  //cloudresourcemanager.googleapis.com/projects/dataflow-templates
  

  如需更新主體存取邊界政策的操作說明，請參閱「編輯主體存取邊界政策」。

• 在政策繫結中豁免特定主體。如果只有特定使用者帳戶或服務帳戶需要執行 Google 提供的範本，請在主體存取權邊界政策繫結中使用條件運算式，將這些主體排除在政策之外。

• 從自己的專案執行範本。使用 DataflowTemplates GitHub 存放區中的開放原始碼範本程式碼，在自己的專案中建構及暫存範本。如需範例，請參閱「建構及執行 Flex 範本範例」。

如要瞭解哪些徵兆代表主體存取邊界政策有問題，請參閱範本疑難排解說明文件中的「無法在 Google Cloud 控制台載入範本清單」和「載入範本檔案時權限遭拒」。

Dataflow 安全性最佳做法

如要保護 Dataflow 管道，必須在下列三個主要層級保護資料：

1. 網路和基礎架構安全
2. Identity and Access Management (IAM)
3. 資料保護和加密

Dataflow 會在代管且自動調度資源的虛擬機器 (worker) 上執行。因此，正確設定這些元素有助於確保資料不會外洩，並在處理過程中保持安全。

網路和基礎架構安全

根據預設，Dataflow worker 會獲派公開 IP 位址，以便存取網際網路和 Google API。在安全環境中，您應限制這項存取權。

• 停用公開 IP：傳遞 --usePublicIps=false 參數，在沒有公開 IP 位址的情況下執行 Dataflow worker。
• 設定 Private Google Access：停用公開 IP 時，worker 仍須與 Google API (例如 Cloud Storage、BigQuery 或 Pub/Sub) 通訊。在虛擬私有雲子網路上啟用Private Google Access，讓 worker 在內部將流量轉送至 Google 服務。
• 使用 Shared VPC 和 VPC Service Controls (VPC-SC)：
  • 使用 VPC Service Controls 將 Dataflow 管道置於安全範圍內。這可確保資料不會複製到 perimeter 外部的資源，即使使用者具備有效憑證也無法複製，進而降低資料竊取風險。
  • 使用專屬子網路，並設定嚴格的防火牆規則，只允許流量傳送至必要資源 (例如資料庫或 Kafka 叢集)，並明確停用 SSH。

IAM

最小權限原則至關重要。根據預設，Dataflow 會嘗試使用 Compute Engine 預設服務帳戶，該帳戶通常具備廣泛的編輯者權限。

• 使用使用者代管的 worker 服務帳戶：為 Dataflow worker 建立專屬的非特殊權限服務帳戶，並在提交 pipeline 時傳遞該帳戶。例如：

  --serviceAccount=YOUR_SERVICE_ACCOUNT@YOUR_PROJECT_ID.iam.gserviceaccount.com
  

  建立服務帳戶後，請僅指派最低權限角色：

  • worker 服務帳戶需要 roles/dataflow.worker 角色。
  • 僅授予管道存取的確切資源特定讀取或寫入權限。例如，在輸入 Cloud Storage bucket 授予 roles/storage.objectViewer，並在特定目標 BigQuery 資料表授予 roles/bigquery.dataEditor (而非專案層級角色)。

• 區分控制器與 worker 權限：提交工作的開發人員或 CI/CD 管道需要 roles/dataflow.admin 和 roles/iam.serviceAccountUser (或 iam.serviceAccounts.actAs 權限) 才能觸發管道。不過，實際的 worker VM 只需要執行階段執行權限 (roles/dataflow.worker)。

資料保護與加密

雖然 Google Cloud 預設會加密所有傳輸中的資料和靜態資料，但高度受管制的產業通常需要對加密金鑰進行額外控管。

• 導入客戶自行管理的加密金鑰 (CMEK)：使用 Cloud Key Management Service 產生及管理自己的金鑰。使用 --dataflowKmsKey 旗標將金鑰傳遞至 Dataflow。Dataflow 會使用這組金鑰加密：
  • 連接至 worker VM 的永久磁碟。
  • 批次管道的重組狀態資料。
  • 串流管道的 Streaming Engine 狀態。
• 保護密鑰：切勿在 Apache Beam 程式碼或管道選項中，透過硬式編碼寫入密碼、API 金鑰或資料庫憑證。在管道的 Setup 或 StartBundle 階段，使用 Secret Manager 動態存取這些密鑰。
• 部署無效信件佇列 (DLQ)：發生錯誤時，請避免記錄未剖析的原始元素，因為這些元素可能含有個人識別資訊 (PII) 或密鑰。而是應擷取處理例外狀況，並將失敗的元素轉送至加密的「無效信件」Cloud Storage bucket 或 Pub/Sub 主題，以便進行隔離、安全的檢查。

管道程式碼和安全漏洞掃描

Apache Beam 程式碼的軟體供應鏈也適用安全性措施。

• 容器映像檔掃描：如果您為 Dataflow worker 使用自訂容器映像檔 (使用 --sdkContainerImage 旗標)，請將映像檔儲存在 Artifact Registry，並啟用自動安全漏洞掃描功能。
• 持續更新映像檔：如果是持續執行的串流管道，請定期更新管道，使用最新版 Apache Beam SDK。Google 會定期強化及修補 Dataflow 使用的底層作業系統基本映像檔。

安全性快速檢查清單

請參閱下表，瞭解安全性目標和達成方式。

資料存取與安全性

Dataflow 服務可處理兩種資料：

• 使用者資料。這項資料會由 Dataflow 管道處理。一般管道會從一或多個來源讀取資料、實作資料轉換，並將結果寫入一或多個接收器。所有來源和接收器都是儲存空間服務，並非由 Dataflow 直接管理。

• 營運資料。這項資料包含管理 Dataflow 管道所需的所有中繼資料。這類資料包括使用者提供的中繼資料 (例如工作名稱或管道選項)，以及系統產生的中繼資料 (例如工作 ID)。

Dataflow 服務採用多種安全機制，可確保資料安全性與隱私。這些機制適用於下列情境：

• 將管道提交至服務
• 評估管道
• 在管道執行期間和執行後，要求存取遙測資料和指標
• 使用 Dataflow 服務，例如 Shuffle 或 Streaming Engine

資料位置

Dataflow 的所有核心資料處理作業，都會在管道程式碼指定的區域中進行。如未指定區域，系統會使用預設區域 us-central1。如果您在管道程式碼中指定該選項，管道工作可以選擇從其他區域的來源和接收器讀取及寫入資料。不過，實際的資料處理作業只會在指定執行 Dataflow VM 的區域中進行。

管道邏輯會在個別 worker VM 執行個體上評估。您可以指定這些執行個體和其通訊的私人網路所在的可用區。平台的輔助運算作業取決於中繼資料，例如 Cloud Storage 位置或檔案大小。

Dataflow 是區域性服務。如要進一步瞭解資料位置和區域，請參閱「Dataflow 區域」。

提交管道中的資料

Google Cloud 專案的 IAM 權限可控管 Dataflow 服務的存取權。凡是具備專案編輯者或擁有者權限的主體，都能將管道提交至服務。如要提交管道，您必須使用 Google Cloud CLI 進行驗證。驗證完成後，系統會使用 HTTPS 通訊協定提交管道。如要瞭解如何使用 Google Cloud 帳戶憑證進行驗證，請參閱您所用語言的快速入門導覽課程。

管道評估中的資料

評估管道時，系統可能會產生暫時資料，並儲存在 worker VM 執行個體或 Cloud Storage 的本機。暫存資料會進行靜態資料加密，且在管道評估結束後不會保留。這類資料也可以儲存在 Shuffle 服務或 Streaming Engine 服務 (如果您已選擇該服務)，並位於 Dataflow 管道指定的相同區域。

管道記錄和遙測資料

儲存在 Cloud Logging 中的資訊，主要是由 Dataflow 程式中的程式碼產生。Dataflow 服務也可能在 Cloud Logging 中產生警告和錯誤資料，但這項資料是服務新增至記錄檔的唯一中繼資料。Cloud Logging 是全球性服務。

遙測資料和相關指標會以靜態加密方式儲存，並由 Google Cloud 專案的讀取權限控管存取權。

Dataflow 服務中的資料

如果管道使用 Dataflow Shuffle 或 Dataflow Streaming，請勿指定可用區管道選項。請改為指定區域，並將值設為 Shuffle 或 Streaming 可用的區域之一。Dataflow 會自動選取您指定區域中的可用區。傳輸中的使用者資料會保留在 worker VM 和相同可用區內。這些 Dataflow 工作仍可讀取及寫入 VM 區域外的來源和接收器。傳輸中的資料也可以傳送至 Dataflow Shuffle 或 Dataflow Streaming 服務。不過，資料一律會保存在管道程式碼指定的區域中。

建議做法

建議您使用管道基礎雲端資源中提供的安全機制。這些機制包括 BigQuery 和 Cloud Storage 等資料來源和接收器的資料安全防護功能。此外，我們也建議您儘可能避免在單一專案中混用不同的信任層級。