[[["易于理解","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-08-18。"],[],[],null,["# Key rotation\n\nThis page discusses key rotation in Cloud Key Management Service. Key rotation is the\nprocess of creating new encryption keys to replace existing keys. By rotating\nyour encryption keys on a regular schedule or after specific events, you can\nreduce the potential consequences of your key being compromised. For specific\ninstructions to rotate a key, see [Rotating keys](/kms/docs/rotate-key).\n\nWhy rotate keys?\n----------------\n\nFor symmetric encryption, periodically and automatically rotating keys is a\nrecommended security practice. Some industry standards, such as\n[Payment Card Industry Data Security Standard](https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss) (PCI DSS), require the regular\nrotation of keys.\n\nCloud Key Management Service **does not** support automatic rotation of asymmetric keys. See\n[Considerations for asymmetric keys](#asymmetric) in this document.\n\nRotating keys provides several benefits:\n\n- Limiting the number of messages encrypted with the same key version helps\n prevent attacks enabled by cryptanalysis. Key lifetime\n recommendations depend on the key's algorithm, as well as either the number\n of messages produced or the total number of bytes encrypted with the same\n key version. For example, the recommended key lifetime for symmetric\n encryption keys in Galois/Counter Mode (GCM) is based on the number of\n messages encrypted, as noted at\n \u003chttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf\u003e.\n\n- In the event that a key is compromised, regular rotation limits the number of\n actual messages vulnerable to compromise.\n\n **If you suspect that a key version is compromised,\n [disable it](/kms/docs/enable-disable) and\n [revoke access to it](/kms/docs/iam) as soon as possible.**\n- Regular key rotation ensures that your system is resilient to manual rotation,\n whether due to a security breach or the need to migrate your application to a\n stronger cryptographic algorithm. **Validate your key rotation procedures\n before a real-life security incident occurs.**\n\nYou can also manually rotate a key, either because it is compromised, or to\nmodify your application to use a different algorithm.\n\nHow often to rotate keys\n------------------------\n\nWe recommend that you [rotate keys automatically](/kms/docs/rotate-key#automatic)\non a regular schedule. A rotation schedule defines the frequency of rotation,\nand optionally the date and time when the first rotation occurs. The rotation\nschedule can be based on either the key's age or the number or volume of\nmessages encrypted with a key version.\n\nSome security regulations require periodic, automatic key rotation. Automatic\nkey rotation at a defined period, such as every 90 days, increases security with\nminimal administrative complexity.\n\nYou should also [manually rotate a key](/kms/docs/rotate-key#manual) if you\nsuspect that it has been compromised, or when security guidelines require you to\nmigrate an application to a stronger key algorithm. You can schedule a manual\nrotation for a date and time in the future. Manually rotating a key does not\npause, modify, or otherwise impact an existing automatic rotation schedule for\nthe key.\n| **Note:** When you rotate a key, data encrypted with previous key versions **isn't** automatically re-encrypted with the new key version. For more information, see [re-encrypting data](/kms/docs/re-encrypt-data).\n\nDon't rely on irregular or manual rotation as a primary component of your\napplication's security.\n\nAfter you rotate keys\n---------------------\n\nRotating keys creates new active key versions, but doesn't re-encrypt your data\nand doesn't disable or delete previous key versions. Previous key versions\nremain active and incur costs until they are destroyed. Re-encrypting data\nremoves your reliance on old key versions, allowing you to destroy them to avoid\nincurring additional costs. To learn how to re-encrypt your data, see\n[Re-encrypting data](/kms/docs/re-encrypt-data).\n\nYou must [make sure that a key version is no longer in\nuse](/kms/docs/destroy-restore#pre-destroy-checklist) before destroying the key\nversion.\n| **Warning:** Destroying a key version that is still in use can cause permanent data loss. It's your responsibility to ensure that a key version is safe to destroy. Google is not responsible for outages, loss of data, or compliance issues that result from you destroying a key version.\n\nConsiderations for asymmetric keys\n----------------------------------\n\nCloud KMS does not support automatic rotation for asymmetric keys,\nbecause additional steps are required before you can use the new asymmetric key\nversion.\n\n- For asymmetric keys used for **signing** , you must distribute the public\n key portion of the new key version. Afterward, you can specify the\n new key version in calls to the [`CryptoKeyVersions.asymmetricSign`](/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions/asymmetricSign) method\n to create a signature, and update applications to use the new key version.\n\n- For asymmetric keys used for **encryption**, you must distribute and\n incorporate the public portion of the new key version into applications that\n encrypt data, and grant access to the private portion of the new key version,\n for applications that decrypt data.\n\nWhat's next\n-----------\n\n- [Rotate a key](/kms/docs/rotate-key).\n- [Enable or disable a key](/kms/docs/enable-disable).\n- Learn more about [re-encrypting data](/kms/docs/re-encrypt-data)."]]
