이 페이지에서는 Cloud Key Management Service의 키 순환에 대해 설명합니다. 키 순환은 기존 키를 대체할 새 암호화 키를 만드는 프로세스입니다. 정기적인 일정에 따라 또는 특정 이벤트 후에 암호화 키를 순환하면 키가 손상될 경우 발생할 수 있는 잠재적 결과를 줄일 수 있습니다. 키 순환에 대한 자세한 내용은 키 순환을 참조하세요.
키를 순환하는 이유는 무엇인가요?
대칭적 암호화의 경우 보안을 위해 주기적으로 그리고 자동으로 키를 순환하는 것이 권장됩니다. 결제 카드 산업 데이터 보안 표준(PCI DSS)과 같은 일부 산업 표준에서는 정기적인 키 순환이 요구됩니다.
Cloud Key Management Service는 비대칭 키의 자동 순환을 지원하지 않습니다. 이 문서의 비대칭 키 고려사항을 참조하세요.
정기적인 키 순환은 보안 위반 사고에 의해서든 아니면 더 강력한 암호화 알고리즘으로 애플리케이션으로 이전해야 해서든 간에 수동 순환보다 복원력이 우수합니다. 실제 보안 이슈가 발생하기 전에 키 순환 절차를 검사하세요.
또한 키가 손상된 경우 또는 다른 알고리즘을 사용하도록 애플리케이션을 수정하려는 경우에 키를 수동으로 순환할 수도 있습니다.
키 순환 빈도
정기적인 일정에 따라 자동으로 키를 순환하는 것이 좋습니다. 순환 일정은 순환 빈도 및 첫 번째 순환이 발생한 날짜와 시간(선택사항)을 정의합니다. 순환 일정은 키 수명 또는 키 버전으로 암호화된 메시지 수 또는 볼륨을 기반으로 할 수 있습니다.
일부 보안 규정에서는 정기적이고 자동화된 키 순환이 요구됩니다. 정의된 간격(예: 90일 간격)에 따라 자동 키 순환을 수행하면 관리 복잡성을 최소화하면서 보안 성능이 향상됩니다.
또한 키 손상이 의심되거나 보안 지침에 따라 애플리케이션을 더 강력한 키 알고리즘으로 이전해야 할 경우 키를 수동으로 순환해야 합니다. 이후 날짜 및 시간에 수동 순환을 예약할 수 있습니다. 키를 수동으로 순환해도 기존의 자동 순환 일정을 일시 중지하거나 수정하거나 기타 영향을 주지 않습니다.
불규칙한 순환 또는 수동 순환을 애플리케이션 보안의 기본 구성요소로 사용하지 마세요.
키를 순환한 후
키를 순환하면 새 활성 키 버전이 생성되지만 데이터가 다시 암호화되지는 않으며 이전 키 버전이 사용 중지되거나 삭제되지도 않습니다. 이전 키 버전은 폐기될 때까지 활성 상태로 유지되며 비용이 발생합니다. 데이터를 다시 암호화하면 이전 키 버전에 대한 의존도가 사라지므로 추가 비용이 발생하지 않도록 이전 키 버전을 삭제할 수 있습니다. 데이터를 다시 암호화하는 방법을 알아보려면 데이터 다시 암호화를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],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)."]]
