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 encryption keys. For more information, see Default encryption at rest.

Cloud Monitoring doesn't support the use of customer-managed 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 Personally Identifiable Information (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 an 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 a VM instance name, or independent of customer data, like a project number	Values containing sensitive data, for example, names of not-yet-released hardware
Metric labels	Values derived from customer data, like a VM instance name, or independent of customer data, like a 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 identifiers 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 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:

Alerting policies, as described in List and get alerting policies. Alerting policies based on service-level objectives have filters that refer to the SLO, for example:
```
filter: select_slo_burn_rate("projects/PROJECT_NUMBER/services/SERVICE_ID/serviceLevelObjectives/SLO_ID")
```
You can retrieve the configuration of the SLO by providing fully qualified name of the SLO from the filter to the serviceLevelObjects/get method.
Notification channels, as described in List notification channels in a project.
Uptime-check configurations, as described in Manage uptime checks.
Custom dashboards, as described in List dashboards.
Resource groups, by using the groups.list method.

Metric data

To inspect metric data, you must consider both the metric descriptors for user-defined metrics and the 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 for custom metrics, use the filter: metric.type = starts_with("custom.googleapis.com")
To search for log-based metrics, use the filter: 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.