Workflows では、上り（内向き）が内部トラフィックに制限されている同じ Google Cloud プロジェクト内の Cloud Run 関数や Cloud Run サービスを呼び出すこともできます。この構成では、インターネットからサービスにアクセスできませんが、ワークフローからはサービスにアクセスできます。
これらの制限を適用するには、サービスまたは関数の上り（内向き）設定を調整する必要があります。Cloud Run サービスには、カスタム ドメインではなく、run.app URL でアクセスする必要があります。詳細については、上り（内向き）の制限（Cloud Run の場合）とネットワーク設定の構成（Cloud Run 関数の場合）をご覧ください。ワークフローに対するその他の変更は必要ありません。
VPC Service Controls は、データの引き出しのリスクを軽減する仕組みです。Workflows で VPC Service Controls を使用すると、サービスを保護できます。詳細については、VPC Service Controls を使用してサービス境界を設定するをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],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)"]]
