Protecting data at rest

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.

  Google-generated data
like system-defined metrics
and built-in dashboards
Customer-generated data
like custom or log-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
  • Keys, for example, showing that a certain dimension of a piece of software exists
  • Values containing sensitive data, for example, names of not-yet-released hardware
Data points in time series No action possible; can't be obscured Time series in user-defined metrics (custom and log-based metrics) can contain sensitive customer data if your applications intentionally collect it.
Metric descriptors No action possible; can't be obscured
  • Display names
  • Descriptions
  • Label keys, for example, showing that a certain dimension of a piece of software exists
Alerting policies No action possible; can't be obscured
  • Display names of policies and embedded conditions
  • Label keys and values used to filter alert to certain time series
  • Information provided as documentation
  • If you have policies based on service-level objectives, their configuration might include:
    • Display name
    • User-specified label keys and values
Dashboards No action possible; can't be obscured
  • Display names
  • Text in items on the dashboard
  • Filters and other query dimensions used to select time-series data for charts and other items on the dashboard
Notification channels No action possible; can't be obscured
  • Display names
  • Descriptions
  • Labels and values used to define channels
Resource groups No action possible; can't be obscured
  • Display names
  • Filters used to designate group membership
Uptime checks No action possible; can't be obscured
  • Display names
  • IP addresses, paths
  • Any optional content-matcher strings
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.

Configuration data

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:

Metric data

To inspect metric data, you must consider both the metric descriptors for user-defined metrics and time-series data written against those descriptors.

Metric descriptors

To ensure that the display names, descriptions, and label keys in any metric descriptors are properly obscured, inspect the descriptors, as described in List metric descriptors. To search specifically for log-based metrics and custom metrics, use the following filters:

  • For custom metrics: metric.type = starts_with("custom.googleapis.com")
  • For log-based metrics: metric.type = starts_with("logging.googleapis.com/user")

Time-series data

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 log-based metrics. For information on retrieving time-series data, see Retrieve time-series data.