默认情况下， Google Cloud 使用多层加密来保护存储在 Google 生产数据中心内的用户数据。此默认加密发生在应用或存储基础架构层。您的设备与 Google Front End (GFE) 之间的流量使用强加密协议（如传输层安全协议 [TLS]）进行加密。机密计算通过在加密隔离中执行计算来保护您正在使用的数据，并在多租户云环境中维护工作负载的机密性。如需详细了解 Google 为帮助保护你的数据而采用的主要安全控制措施，请参阅 Google 安全概览。 Google Cloud
身份和访问权限管理
由于每个工作流执行都需要进行经过身份验证的调用，因此您可以使用 Workflows 来降低意外或恶意调用的风险。Workflows 使用 Identity and Access Management (IAM) 角色和权限管理访问权限和身份验证。您可以通过使用基于 IAM 的服务账号来简化与其他 Google Cloud API 的交互。如需了解详情，请参阅向工作流授予访问 Google Cloud 资源的权限和通过工作流发出经过身份验证的请求。
Workflows 还可以调用同一个项目中入站流量受限于内部流量的 Cloud Run functions 或 Cloud Run 服务。 Google Cloud 使用此配置时，您的服务无法通过互联网访问，但可以通过 Workflows 访问。如需应用这些限制，您必须调整服务或函数的入站流量设置。请注意，Cloud Run 服务必须通过其 run.app 网址访问，而不是通过自定义网域访问。如需了解详情，请参阅限制入站流量（适用于 Cloud Run）和配置网络设置（适用于 Cloud Run 函数）。您的工作流无需进行其他更改。
客户管理的加密密钥 (CMEK)
如果您对保护数据的密钥有特定的合规性或监管要求，则可以将客户管理的加密密钥 (CMEK) 用于工作流。您的工作流和关联的静态数据将使用只有您可以访问的加密密钥进行保护，您可以使用 Cloud Key Management Service (Cloud KMS) 控制和管理这些静态数据。如需了解详情，请参阅使用客户管理的加密密钥。
VPC Service Controls (VPC SC) 支持
VPC Service Controls 是一种可降低数据渗漏风险的机制。您可以将 VPC Service Controls 与工作流搭配使用，以帮助保护您的服务。如需了解详情，请参阅使用 VPC Service Controls 设置服务边界。
使用 Secret Manager 存储和保护敏感数据
Secret Manager 是一个安全便捷的存储系统，用于存储 API 密钥、密码、证书和其他敏感数据。您可以使用 Workflows 连接器在工作流中访问 Secret Manager。这样可以简化集成，因为连接器会处理请求的格式，并提供方法和参数，这样您就无需了解 Secret Manager API 的详细信息。如需了解详情，请参阅使用 Secret Manager 连接器安全地存储敏感数据。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# Workflows security overview\n\nBecause a workflow contains no code or library dependencies, it does not require\nsecurity patches. Once you deploy a workflow, you can expect it to reliably\nexecute without maintenance. In addition, Workflows offers\nseveral security features and takes specific compliance measures to satisfy\nenterprise security requirements.\n\nData encryption\n---------------\n\nBy default, Google Cloud uses several layers of encryption to protect user\ndata that's stored in Google production data centers. This default encryption\noccurs at the application or storage infrastructure layer. Traffic between your\ndevices and the Google Front End (GFE) is encrypted using strong encryption\nprotocols such as Transport Layer Security (TLS). Your data in use is protected,\nand confidentiality for workloads in a multi-tenant cloud environment is\nmaintained, by performing computation in cryptographic isolation. For more\ninformation about the main security controls that Google Cloud uses to\nhelp protect your data, see\n[Google security overview](/security/overview/whitepaper).\n\nIdentity and access management\n------------------------------\n\nSince every workflow execution requires an authenticated call, you can mitigate\nthe risk of accidental or malicious calls by using Workflows.\nWorkflows manages access and authentication using\nIdentity and Access Management (IAM) roles and permissions. You can simplify\ninteractions with other Google Cloud APIs by using\n[IAM-based service accounts](/docs/authentication/production). For details, see\n[Grant a workflow permission to access Google Cloud resources](/workflows/docs/authentication)\nand [Make authenticated requests from a workflow](/workflows/docs/authenticate-from-workflow).\n\nPrivate endpoints\n-----------------\n\nWorkflows can invoke a private on‑premises, Compute Engine,\nGoogle Kubernetes Engine (GKE), or other Google Cloud endpoint through an\nHTTP request. You must enable Identity-Aware Proxy (IAP) for the private\nendpoint so that Workflows can invoke the endpoint. For more\ninformation, see\n[Invoke a private on‑prem, Compute Engine, GKE, or other endpoint](/workflows/docs/enable-iap-call-private-endpoints).\n\nWorkflows can also invoke Cloud Run functions\nor Cloud Run services in the same Google Cloud project\nthat have ingress restricted to internal traffic. With this configuration, your\nservices are unreachable from the internet but can be reached from Workflows.\nTo apply these restrictions, you must adjust the ingress settings of your\nservice or function. Note that the Cloud Run service must be\nreached on its `run.app` URL and not at a custom domain. For more information,\nsee [Restricting ingress](/run/docs/securing/ingress) (for Cloud Run)\nand [Configuring network settings](/functions/docs/networking/network-settings)\n(for Cloud Run functions). No other changes are needed to your workflow.\n\nCustomer-managed encryption keys (CMEK)\n---------------------------------------\n\nIf you have specific compliance or regulatory requirements related to the keys\nthat protect your data, you can use\n[customer-managed encryption keys (CMEK)](/kms/docs/cmek) for\nWorkflows. Your workflow and associated data at rest are\nprotected using an encryption key that only you can access, and that you can\ncontrol and manage using Cloud Key Management Service (Cloud KMS). For more\ninformation, see [Use customer-managed encryption keys](/workflows/docs/use-cmek).\n\nVPC Service Controls (VPC SC) support\n-------------------------------------\n\nVPC Service Controls is a mechanism to mitigate data exfiltration risks.\nYou can use VPC Service Controls with Workflows to help protect\nyour services. For more information, see\n[Set up a service perimeter using VPC Service Controls](/workflows/docs/use-vpc-service-controls).\n\nSecret Manager to store and secure sensitive data\n-------------------------------------------------\n\nSecret Manager is a secure and convenient storage system for\nAPI keys, passwords, certificates, and other sensitive data. You can use a\nWorkflows connector to access Secret Manager\nwithin a workflow. This simplifies the integration for you, because the\nconnector handles the formatting of requests, and provides methods and arguments\nso that you don't need to know the details of the Secret Manager API.\nFor more information, see\n[Secure and store sensitive data using the Secret Manager connector](/workflows/docs/use-secret-manager).\n\nIntegration with Cloud Logging, Cloud Monitoring, and Cloud Audit Logs\n----------------------------------------------------------------------\n\nLogs are a primary source of diagnostic information about the health of your\nworkflows. [Logging](/logging/docs) lets you store, view,\nsearch, analyze, and alert on log data and events.\n\nWorkflows is integrated with Logging and\nautomatically generates execution logs for workflow executions. Because of the\nstreaming nature of Logging, you can view the logs that\nany workflow emits immediately, and you can use Logging to\ncentralize logs from all your workflows. You can also control when logs are sent\nto Logging during a workflow execution through call logging or\ncustom logs. For details, see\n[Send logs to Logging](/workflows/docs/log-workflow).\n\nIn addition to consuming logs, you typically need to monitor other aspects of\nyour services to ensure reliable operation. Use [Monitoring](/monitoring/docs)\nto get visibility into the performance, uptime, and overall health of your\nworkflows.\n\nTo track and maintain details of interactions with your Google Cloud\nresources, you can use [Cloud Audit Logs](/logging/docs/audit) to help capture\nactivity such as data access. Use IAM controls to limit who can\nview audit logs. For more information, see the audit logging information for\n[workflows](/workflows/docs/audit-logging) and\n[workflow executions](/workflows/docs/audit-logging-workflow-executions).\n\nCompliance with standards\n-------------------------\n\nTo confirm Workflows' compliance with various standards, see\n[Compliance controls](/workflows/docs/compliance-controls).\n\nWhat's next\n-----------\n\n- [Security best practices](/workflows/docs/security-best-practices)"]]
