Platform: GCP
| Category | Criteria Name | Supported | Notes | Caveats |
|---|---|---|---|---|
| Authentication & Authorization | API Key Management | True | API keys can be used to secure function invocations when fronted by API Gateway. For keys used by the function itself to access other services, Google Secret Manager is the recommended secure storage solution, accessed via the function's service account. | API keys are primarily for invocation via API Gateway, not for function's internal access to other services. Sensitive keys should be in Secret Manager. |
| Authentication & Authorization | IAM Integration | True | Granular access control via Google Cloud IAM roles (e.g., Cloud Functions Admin, Developer, Invoker, Viewer). Service accounts are used as the function's runtime identity for accessing other GCP services. Principle of least privilege is recommended for service accounts. | HTTP-triggered functions require authentication by default. |
| Authentication & Authorization | MFA | True | MFA (2-Step Verification) is supported and becoming mandatory for Google Cloud accounts that manage or invoke functions. For programmatic invocation, ID tokens are used, which are tied to the caller's identity (user or service account). | MFA is for user accounts accessing the console/SSH; not directly for service accounts. |
| Authentication & Authorization | Service Account Support | True | Cloud Functions can be configured to run with a specific service account, which provides credentials for accessing other GCP services. This is the primary method for function-to-service and function-to-function authentication. | Dedicated service accounts with least privilege are recommended over the default service account. |
| Authentication & Authorization | Standard Protocols | True | Secured using OAuth 2.0 and OpenID Connect (OIDC). ID tokens (JWTs) are required for invoking secured functions, proving the caller's identity. Access tokens are used for functions to access other GCP services. API Gateway can integrate external OAuth providers. | |
| Compliance & Certifications | Compliance Documentation | True | Google Cloud Compliance Reports Manager provides on-demand access to ISO/IEC certificates, SOC reports, and other compliance documentation relevant to Cloud Functions. Compliance Resource Center offers detailed information. | |
| Compliance & Certifications | Industry Certifications | True | Google Cloud Platform (including Cloud Functions) adheres to ISO/IEC 27001, 27017, 27018, 27701, SOC 1/2/3, HIPAA, FedRAMP, PCI DSS, CSA STAR, and various regional certifications. | |
| Data Loss Prevention (DLP) | Data Masking/Redaction | True | Cloud DLP supports data masking and redaction for sensitive information. This can be applied to data as it's processed by Cloud Functions or before it's stored in associated services, by integrating with DLP APIs. | Requires integration with Cloud DLP; not a native Cloud Functions feature. |
| Data Loss Prevention (DLP) | Sensitive Data Scanning | True | Cloud DLP can be used to discover, classify, and report on sensitive data processed by or stored within Cloud Functions (e.g., in logs, or data passed through events). This requires configuring DLP scans to target relevant data flows or storage locations. | Requires integration with Cloud DLP; not a native Cloud Functions feature. |
| Data Residency & Sovereignty | Cross-Region Data Transfer Controls | True | By default, egress is dynamic. To restrict cross-region data transfer, route function outbound traffic through a Serverless VPC Access connector to a VPC, then apply egress firewall rules to allow only specific regional IP ranges. Organization Policies can enforce VPC connector usage. | Requires routing egress traffic through a Serverless VPC Access connector and applying VPC firewall rules. |
| Data Residency & Sovereignty | Data Location Transparency | True | Cloud Functions are regional services, meaning infrastructure and data are within the selected region. Google provides contractual commitments, Access Transparency, and Access Approval for visibility and control over data access by Google personnel. | |
| Data Residency & Sovereignty | Region Selection | True | Google Cloud Functions allows selection of specific regions for function deployment, ensuring code and data reside in that geographical area. Numerous Tier 1 and Tier 2 regions are available globally. | |
| Encryption | Encryption at Rest | True | Data at rest (code, metadata, container images) is encrypted by default using Google-Managed Encryption Keys (GMEK). Customer-Managed Encryption Keys (CMEK) are supported via Cloud KMS for greater control over the function's source code, container image, and deployed instances. | CSEK is not directly supported for the entire function environment, but can be used for underlying storage services. |
| Encryption | Encryption in Transit | True | All data is encrypted in transit by default using TLS when invoked via cloudfunctions.net. To enforce specific TLS versions/cipher suites, use a Global External HTTPS Load Balancer with an SSL Policy in front of the function. | Direct configuration of minimum TLS version on function is not possible; requires a Load Balancer. |
| Logging & Monitoring | Access Logging | True | Detailed access logs for Cloud Functions invocations are captured as Data Access logs within Cloud Audit Logs. These logs provide information about who invoked the function, when, and request details. Explicit enablement is required. | Data Access logs are disabled by default and must be explicitly enabled. |
| Logging & Monitoring | Audit Logging | True | Cloud Functions generates Admin Activity logs (for configuration changes) and Data Access logs (for function invocations and data access) via Cloud Audit Logs. Logs are available in Logs Explorer and can be exported to BigQuery or Cloud Storage. | Data Access logs are disabled by default and must be explicitly enabled. |
| Logging & Monitoring | Log Retention | True | Admin Activity and System Event logs are retained for 400 days (fixed). Data Access and Policy Denied logs default to 30 days but are configurable up to 3650 days. Logs can be exported to Cloud Storage or BigQuery for long-term archival. | Data Access logs default to 30 days; longer retention requires configuration or export. |
| Logging & Monitoring | Monitoring & Alerting | True | Automatic integration with Cloud Monitoring provides metrics (execution count, time, memory usage, active instances). Logs-based metrics can be created for custom monitoring. Configurable alerting policies with various notification channels are supported. | |
| Network Security | API Gateway Integration | True | API Gateway seamlessly integrates with Cloud Functions to expose them as managed REST APIs. It handles authentication (API keys, JWTs), monitoring, and rate limiting, acting as a secure front door to the function. | |
| Network Security | DDoS Protection | True | DDoS protection is provided by Google Cloud Armor when the function is fronted by an external Application Load Balancer. Cloud Armor offers WAF, rate limiting, and DDoS mitigation at the edge of Google's network. | Requires integration with an external Application Load Balancer and Cloud Armor. |
| Network Security | Firewall Rules | True | Ingress is controlled by function settings (allow all, internal only, internal + GCLB). Egress traffic, when routed through a Serverless VPC Access connector, is subject to VPC firewall rules, allowing granular control over outbound connections. | Direct firewall rules on functions are not applicable; control is via ingress settings and VPC firewall rules for egress. |
| Network Security | Private Access | True | Ingress can be restricted to internal traffic only or internal + Cloud Load Balancing. Egress to private VPC resources (e.g., Cloud SQL, VMs) is supported via Serverless VPC Access connectors. VPC Service Controls can create perimeters for data exfiltration prevention. | Requires Serverless VPC Access connector for private egress. |
| Secure Development Lifecycle (SDL) | API Design Principles | True | Google Cloud APIs, including Cloud Functions API, are designed with security in mind, adhering to secure API design principles as part of Google's overall SDL. This includes consistent authentication, authorization, and data handling. | |
| Secure Development Lifecycle (SDL) | Code Review & Testing | True | Google's internal development processes include rigorous code reviews and security testing for its services, including Cloud Functions, as part of its SDL. This ensures the platform itself is built securely. | |
| Vulnerability Management & Patching | Security Updates | True | Cloud Functions (2nd gen) receive automatic runtime security updates. For both 1st and 2nd gen, redeploying the function ensures the latest underlying environment patches. Google addresses platform-level vulnerabilities (e.g., ConfusedFunction). | Users are responsible for managing dependencies in their function code. |
| Vulnerability Management & Patching | Vulnerability Scanning | True | Artifact Registry automatically scans function container images for known vulnerabilities. Security Command Center aggregates findings. Integration with CI/CD (Cloud Build) allows for dependency scanning (OWASP Dependency-Check, Snyk) and SAST/DAST tools. Google allows penetration testing on user projects. | Requires integration with Artifact Registry scanning and/or third-party tools for comprehensive code/dependency scanning. |