서비스 계정 키는 서비스 계정으로 인증할 수 있는 비공개 키입니다.
키 순환은 기존 키를 새 키로 바꾼 다음 교체된 키를 무효화하는 프로세스입니다. 서비스 계정 키를 포함하여 관리하는 모든 키를 정기적으로 순환하는 것이 좋습니다.
서비스 계정 키를 순환하면 유출되거나 도난당한 키로 인한 위험을 줄일 수 있습니다. 키가 유출되면 악의적인 행위자가 키를 찾는 데 며칠 또는 몇 주가 걸릴 수 있습니다. 서비스 계정 키를 정기적으로 순환하면 악의적인 행위자가 키를 획득할 때까지 유출된 키가 무효화될 가능성이 높습니다.
서비스 계정 키를 순환하는 프로세스를 설정하면 서비스 계정 키가 손상된 것으로 의심되는 경우 빠르게 조치를 취할 수 있습니다.
키 순환 빈도
유출된 키로 인한 위험을 줄이려면 최소 90일마다 키를 순환하는 것이 좋습니다.
서비스 계정 키가 손상되었다고 생각되면 즉시 순환하는 것이 좋습니다.
키 순환 프로세스
서비스 계정 키를 순환하려면 다음을 수행합니다.
순환해야 하는 서비스 계정 키를 식별합니다.
동일한 서비스 계정의 새 키를 만듭니다.
모든 애플리케이션에서 기존 키를 새 키로 바꿉니다.
교체된 키를 사용 중지하고 애플리케이션을 모니터링하여 예상대로 작동하는지 확인합니다.
교체된 서비스 계정 키를 삭제합니다.
중앙 집중식 보안 비밀 관리 서비스를 사용하거나 커스텀 알림 시스템을 사용하여 이 단계를 완료할 수 있습니다.
중앙 집중식 보안 비밀 관리 서비스
HashiCorp Vault와 같은 많은 중앙 집중식 보안 비밀 관리 서비스에서 자동 보안 비밀 순환을 제공합니다. 이러한 서비스를 사용하여 서비스 계정 키를 저장하고 순환할 수 있습니다.
서비스 계정 키를 저장하고 순환하기 위해서는 Google Cloud의 Secret Manager를 사용하지 않는 것이 좋습니다. 이는 Secret Manager 보안 비밀에 액세스하려면 애플리케이션에Google Cloud 가 인식할 수 있는 ID가 필요하기 때문입니다. 애플리케이션에 이미 Google Cloud 가 인식할 수 있는 ID가 있는 경우 애플리케이션은 서비스 계정 키를 사용하는 대신 해당 ID를 사용하여 Google Cloud 에 인증할 수 있습니다.
Azure KeyVault 및 AWS Secret Manager와 같은 다른 클라우드 기반 보안 비밀 관리 서비스에도 동일한 개념이 적용됩니다. 애플리케이션에 이미 클라우드 제공업체에서 인식할 수 있는 ID가 있는 경우 애플리케이션은 서비스 계정 키를 사용하는 대신 해당 ID를 사용하여 Google Cloud 에 인증할 수 있습니다.
커스텀 알림 시스템
서비스 계정 키 순환에 대한 또 다른 방법은 키를 순환해야 할 때 알림을 보내는 시스템을 만드는 것입니다. 예를 들어 생성된 지 90일이 지난 키가 감지되면 알림을 보내는 시스템을 만들 수 있습니다.
먼저 순환해야 하는 키를 식별해야 합니다. 이러한 키를 식별하려면 Cloud 애셋 인벤토리를 사용하여 특정 시간 전에 생성된 모든 서비스 계정 키를 검색하는 것이 좋습니다.
예를 들어 다음 명령어는 ID가 123456789012인 조직에서 2023-03-10 00:00:00 UTC 이전에 생성된 모든 서비스 계정 키를 나열합니다.
[[["이해하기 쉬움","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-04(UTC)"],[[["\u003cp\u003eService account keys should be rotated regularly, ideally at least every 90 days, to mitigate the risks associated with leaked or stolen keys.\u003c/p\u003e\n"],["\u003cp\u003eRotating service account keys involves creating new keys, replacing existing ones in applications, disabling the old keys, and then deleting the replaced keys after confirmation that the applications are working correctly.\u003c/p\u003e\n"],["\u003cp\u003eCentralized secret management services like HashiCorp Vault can be used for automatic key rotation, but cloud-based secret managers are not recommended if the application already has an identity.\u003c/p\u003e\n"],["\u003cp\u003eA custom notification system can be implemented to alert teams when service account keys need rotation, leveraging Cloud Asset Inventory to identify keys based on their creation time.\u003c/p\u003e\n"],["\u003cp\u003eExpiring service account keys are not advised for key rotation due to the potential for outages if not managed properly; instead, using the rotation process is preferred.\u003c/p\u003e\n"]]],[],null,["# Service account key rotation\n\n[Service account keys](/iam/docs/service-account-creds#key-types) are private keys that let you\nauthenticate as a service account.\nKey rotation is the process of replacing your existing keys with new keys and\nthen invalidating the replaced keys. We recommend that you routinely\nrotate all keys that you manage, including your service account keys.\n\nRotating service account keys can help reduce the risk posed by leaked or stolen\nkeys. If a key is leaked, it might take bad actors days or weeks to discover the\nkey. If you regularly rotate your service account keys, there's a higher chance\nthat the leaked keys will be invalid by the time a bad actor gets them.\n\nHaving an established process for rotating service account keys also helps you\nact quickly if you suspect that a service account key has been compromised.\n| **Note:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](/docs/authentication#auth-decision-tree) whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by [Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys). If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see [Managing secure-by-default organization resources](/resource-manager/docs/secure-by-default-organizations).\n|\n|\n| If you acquired the service account key from an external source, you must validate it before use.\n| For more information, see [Security requirements for externally sourced credentials](/docs/authentication/external/externally-sourced-credentials).\n\nHow often to rotate keys\n------------------------\n\nWe recommend rotating your keys at least every 90 days to reduce\nthe risk posed by leaked keys.\n\nIf you believe that a service account key has been compromised, we recommend\nthat you rotate it immediately.\n\nKey rotation process\n--------------------\n\nTo rotate service account keys, do the following:\n\n1. Identify the service account keys that need to be rotated.\n2. Create new keys for the same service accounts.\n3. Replace the existing keys with the new keys across all applications.\n4. Disable the replaced keys and monitor the applications to confirm that they work as expected.\n5. Delete the service account keys that were replaced.\n\nYou can complete these steps by using a centralized secret management service,\nor by using a custom notification system.\n\n### Centralized secret management service\n\nMany centralized secret management services, like [HashiCorp Vault](https://www.vaultproject.io), provide automatic secret rotation. You can use these services\nto store and rotate your service account keys.\nWe don't recommend using Google Cloud's Secret Manager to store and rotate service account keys. This is because, to access Secret Manager secrets, your application needs an identity that Google Cloud can recognize. If your application already has an identity that Google Cloud can recognize, then your application can use that identity to authenticate to Google Cloud instead of using a service account key.\n\n\u003cbr /\u003e\n\nThe same concept applies for other cloud-based secret management services, like\nAzure KeyVault and AWS Secret Manager. If an application already has an identity\nthat these cloud providers can recognize, your application would be able to use\nthat identity to authenticate to Google Cloud instead of using a service\naccount key.\n\n### Custom notification system\n\nAnother approach to service account key rotation is to create a system that\nsends notifications when keys need to be rotated. For example, you could create\na system that sends alerts when it detects keys that were created more than\n90 days ago.\n\nFirst, you need to identify the keys that need to be rotated. To identify these\nkeys, we recommend using Cloud Asset Inventory to search for all service account\nkeys that were created before a certain time.\n\nFor example, the following command lists all service account keys that were\ncreated before `2023-03-10 00:00:00 UTC` in the organization with the ID\n`123456789012`: \n\n```\ngcloud asset search-all-resources \\\n --scope=\"organizations/123456789012\" \\\n --query=\"createTime \u003c 2023-03-10\" \\\n --asset-types=\"iam.googleapis.com/ServiceAccountKey\" \\\n --order-by=\"createTime\"\n```\n\nTo learn more about searching resources in Cloud Asset Inventory, see [Searching\nresources](/asset-inventory/docs/searching-resources).\nAfter identifying the keys that need to be rotated, you can send out\nnotifications to the appropriate teams.\n\nWhen someone is notified to rotate a key, they should do the following:\n\n1. [Create a new key](/iam/docs/keys-create-delete#creating) for the same service account.\n2. Replace the existing key with the new key across all applications.\n3. [Disable the key](/iam/docs/keys-disable-enable#disabling) that they replaced and monitor the applications to confirm that they work as expected.\n4. After they confirm that the applications are working as expected, [delete the\n replaced key](/iam/docs/keys-create-delete#deleting).\n\nExpiring service account keys\n-----------------------------\n\nWe don't recommend using expiring service account keys for key rotation. This is\nbecause expiring keys can cause outages if they aren't rotated properly. For\nmore information about the use cases for expiring service account keys, see\n[expiry times for user-managed keys](/iam/docs/service-account-creds#key-expiry).\n\nWhat's next\n-----------\n\n- Use Cloud Asset Inventory to [search for resources](/asset-inventory/docs/searching-resources), including service account keys, by creation time.\n- [Create](/iam/docs/keys-create-delete#creating), [disable](/iam/docs/keys-disable-enable#disabling), and [delete](/iam/docs/keys-create-delete#deleting) service account keys."]]
