This document describes the encryption policies for data at rest in Cloud Monitoring and steps you can take to ensure that your sensitive customer data is protected.
This document is intended for customers who must comply with data-security requirements.
Encryption of data at rest
All data at rest within Cloud Monitoring is encrypted using Google-managed public/private key encryption, as described in Encryption at rest in Google Cloud.
Cloud Monitoring doesn't support the use of customer-managaged encryption keys (CMEK) for protecting your data at rest. By default, Monitoring doesn't store sensitive data and isn't intended to be used for PII or other private customer content. You can use Monitoring to store aggregated, unidentifiable user-activity data or second-order event-based aggregated information like request counts and other similar metrics.
However, there are places in Monitoring at which you can inadvertently insert sensitive customer data. Because Cloud Monitoring stores metadata and resource labels, customer data can make its way into Monitoring when you name configurations or perform metadata actions like labeling a resource, annotating a VM instance, or storing custom resources by using custom resource definitions (CRDs) in Google Kubernetes Engine.
The rest of this document describes the points at which such data might be inserted and how to look for the capture of such data.
Possible insertion points
The following table describes the points at which sensitive data might be sent to Cloud Monitoring.
like system-defined metrics
and built-in dashboards
like custom or logs-based metrics
and custom dashboards
|Resource labels||Values derived from customer data, like VM instance name, or independent of customer data, like project number||Values containing sensitive data, for example, names of not-yet-released hardware|
|Metric labels||Values derived from customer data, like VM instance name, or independent of customer data, like project number||
|Data points in time series||No action possible; can't be obscured||Time series in user-defined metrics (custom and logs-based metrics) can contain sensitive customer data if your applications intentionally collect it.|
|Metric descriptors||No action possible; can't be obscured||
|Alerting policies||No action possible; can't be obscured||
|Dashboards||No action possible; can't be obscured||
|Notification channels||No action possible; can't be obscured||
|Resource groups||No action possible; can't be obscured||
|Uptime checks||No action possible; can't be obscured||
|Metrics scopes||Not applicable||Metadata only|
Protecting sensitive metadata
If you want all data protected by CMEK, then you shouldn't put sensitive information in resource configurations or metadata in Google Cloud. If sensitive data must be used in resource configurations, resource metadata, or label values, we recommend that you protect it by using obscured identfiers in Google Cloud and a mapping table external to Google Cloud.
If you send sensitive time-series data to Monitoring, the only way to ensure the data is deleted is to delete your Google Cloud project. Otherwise, time-series data is deleted only after it reaches the data-retention limit, which is currently 24 months for user-defined metrics.
Inspecting data to ensure compliance
You can manually inspect your data in Cloud Monitoring to ensure that it complies with your security standards.
To ensure that labels and filters used in configuration artifacts like alerting policies are properly obscured, you can retrieve and inspect the configuration data. Inspect the following:
Alerting policies, as described in Retrieving policies. Alerting policies based on service-level objectives have filters that refer to the SLO, for example:
You can retrieve the configuration of the SLO by providing fully qualified name of the SLO from the filter to the
Notification channels, as described in Retrieving channels.
Uptime-check configurations, as described in Listing uptime checks.
Custom dashboards, as described in Listing dashboards.
Resource groups, by using the
To inspect metric data, you must consider both the metric descriptors for user-defined metrics and time-series data written against those descriptors.
To ensure that the display names, descriptions, and label keys in any metric descriptors are properly obscured, inspect the descriptors, as described in Listing metric descriptors. To search specifically for logs-based metrics and custom metrics, use the following filters:
- For custom metrics:
metric.type = starts_with("custom.googleapis.com")
- For logs-based metrics:
metric.type = starts_with("logging.googleapis.com/user")
To ensure that the time-series data itself is properly obscured, retrieve the time-series data, and inspect the values of metric and resource labels and other stored data. Pay particular attention to time-series data collected by custom metrics or logs-based metrics. For information on retrieving time-series data, see Reading metric data.