[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# Protecting data at rest\n\nThis document describes the encryption policies for data at rest in\nCloud Monitoring and steps you can take to ensure that your sensitive\ncustomer data is protected.\n\nThis document is intended for customers who must comply with data-security\nrequirements.\n\nEncryption of data at rest\n--------------------------\n\nAll data at rest within Cloud Monitoring is encrypted using\nGoogle-owned and Google-managed encryption keys.\n\nFor more information, see [Default encryption at rest](/docs/security/encryption/default-encryption).\n\n\nCloud Monitoring doesn't support the use of [customer-managed encryption\nkeys](/kms/docs/cmek) (CMEK) for protecting your data at rest. By default,\nMonitoring doesn't store sensitive data and isn't intended to be\nused for Personally Identifiable Information (PII) or other private customer\ncontent. You can use Monitoring to store aggregated,\nunidentifiable user-activity data or second-order event-based aggregated\ninformation like request counts and other similar metrics.\n\nHowever, there are places in Monitoring at which you can\ninadvertently insert sensitive customer data.\nBecause Cloud Monitoring stores metadata and resource labels,\ncustomer data can make its way into Monitoring when you\nname configurations or perform metadata actions like labeling a resource,\nannotating an instance, or storing custom resources by using\n[custom resource definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) in Google Kubernetes Engine.\n\nThe rest of this document describes the points at which such data might be\ninserted and how to look for the capture of such data.\n\nPossible insertion points\n-------------------------\n\nThe following table describes the points at which sensitive data might\nbe sent to Cloud Monitoring.\n\n\u003cbr /\u003e\n\nProtecting sensitive metadata\n-----------------------------\n\nIf you want all data protected by CMEK, then you shouldn't put sensitive\ninformation in resource configurations or metadata in Google Cloud. If\nsensitive data must be used in resource configurations, resource metadata,\nor label values, we recommend that you protect it by using obscured identifiers\nin Google Cloud and a mapping table external to Google Cloud.\n| **Important:** There is no way to obscure the IP addresses, paths, and content-matcher strings used in uptime checks.\n\nIf you send sensitive time-series data to Monitoring, the\nonly way to ensure the data is deleted is to [delete your\nGoogle Cloud project](/resource-manager/docs/creating-managing-projects). Otherwise, time-series data is deleted only\nafter it reaches the data-retention limit, which is\n24 months for user-defined metrics.\n\nInspecting data to ensure compliance\n------------------------------------\n\nYou can manually inspect your data in Cloud Monitoring to ensure\nthat it complies with your security standards.\n\n### Configuration data\n\nTo ensure that labels and filters used in configuration artifacts like\nalerting policies are properly obscured, you can retrieve and inspect\nthe configuration data. Inspect the following:\n\n- Alerting policies, as described in\n [List and get alerting policies](/monitoring/alerts/using-alerting-api#api-list-policy).\n Alerting policies based on service-level objectives have filters that\n refer to the SLO, for example:\n\n ```\n filter: select_slo_burn_rate(\"projects/PROJECT_NUMBER/services/SERVICE_ID/serviceLevelObjectives/SLO_ID\")\n ```\n\n You can retrieve the configuration of the SLO by providing fully qualified\n name of the SLO from the filter to the\n [`serviceLevelObjects/get`](/monitoring/api/ref_v3/rest/v3/services.serviceLevelObjectives/get) method.\n- Notification channels, as described in\n [List notification channels in a project](/monitoring/alerts/using-channels-api#api-list-channels).\n\n- Uptime-check configurations, as described in\n [Manage uptime checks](/monitoring/uptime-checks/manage).\n\n- Custom dashboards, as described in [List dashboards](/monitoring/dashboards/api-dashboard#list).\n\n- Resource groups, by using the [`groups.list`](/monitoring/api/ref_v3/rest/v3/projects.groups/list) method.\n\n### Metric data\n\nTo inspect metric data, you must consider both the metric descriptors for\nuser-defined metrics and the time-series data written against those descriptors.\n\n#### Metric descriptors\n\nTo ensure that the display names, descriptions, and label keys in any metric\ndescriptors are properly obscured, inspect the descriptors, as described in\n[List metric descriptors](/monitoring/custom-metrics/browsing-metrics#list-metric-descriptors).\n\n- To search for custom metrics, use the filter:\n `metric.type = starts_with(\"custom.googleapis.com\")`\n\n- To search for log-based metrics, use the filter:\n `metric.type = starts_with(\"logging.googleapis.com/user\")`\n\n#### Time-series data\n\nTo ensure that the time-series data itself is properly obscured, retrieve\nthe time-series data, and inspect the values of metric and resource labels\nand other stored data.\nPay particular attention to time-series data collected by custom metrics or\nlog-based metrics. For information on retrieving time-series data, see\n[Retrieve time-series data](/monitoring/custom-metrics/reading-metrics)."]]
