서비스 계정 사용자 인증 정보

주 구성원과 마찬가지로 서비스 계정은 Google에 자신을 인증하고 OAuth 2.0 액세스 토큰을 가져오며 Google API를 호출할 수 있습니다. 이 프로세스가 작동하는 방식은 서비스 계정과 사용자의 경우가 다릅니다.

서비스 계정은 다음 중 하나를 수행하여 인증합니다.

단기 서비스 계정 사용자 인증 정보

서비스 계정으로 인증하는 가장 안전한 방법은 서비스 계정의 단기 사용자 인증 정보를 OAuth 2.0 액세스 토큰 형태로 가져오는 것입니다. 기본적으로 이러한 토큰은 1시간 후에 만료됩니다.

단기 서비스 계정 사용자 인증 정보는 신뢰할 수 있는 서비스 계정에 리소스에 대한 제한적 액세스 권한을 부여해야 하는 경우에 유용합니다. 또한 서비스 계정 키와 같은 장기 사용자 인증 정보보다 위험성이 적습니다.

대부분의 경우 이러한 사용자 인증 정보를 자동으로 가져오므로 개발자가 사용자 인증 정보를 직접 만들거나 관리할 필요가 없습니다. 예를 들면 다음과 같습니다.

  • Google Cloud CLI 명령어를 실행하고 --impersonate-service-account 플래그를 포함하는 경우, gcloud CLI는 서비스 계정에 대한 단기 사용자 인증 정보를 만들고 이러한 사용자 인증 정보가 포함된 명령어를 실행합니다.

  • Compute Engine 가상 머신(VM) 인스턴스에 서비스 계정을 연결하면 해당 인스턴스의 워크로드에서 Cloud 클라이언트 라이브러리를 사용하여 Google Cloud 서비스에 액세스할 수 있습니다. Cloud 클라이언트 라이브러리는 애플리케이션 기본 사용자 인증 정보(ADC)를 사용하여 서비스 계정의 단기 사용자 인증 정보를 가져옵니다.

    이 프로세스에 대한 자세한 내용은 서비스 계정 사용자 인증 정보를 사용하여 애플리케이션 인증을 참조하세요.

  • 워크로드 아이덴티티 제휴를 구성하면 Cloud 클라이언트 라이브러리에서 ID 공급업체의 사용자 인증 정보를 사용하여 단기 서비스 계정 사용자 인증 정보를 생성할 수 있습니다.

Service Account Credentials API를 사용하여 수동으로 단기 사용자 인증 정보를 만들 수도 있습니다. 예를 들어 사용자가 Google Cloud 리소스에 임시로 액세스할 수 있도록 사용자에게 단기 서비스 계정 사용자 인증 정보를 제공하는 서비스를 만들 수 있습니다.

Service Account Credentials API에서 다음 유형의 사용자 인증 정보를 만들 수 있습니다.

  • OAuth 2.0 액세스 토큰
  • OpenID Connect(OIDC) ID 토큰
  • 자체 서명 JSON 웹 토큰(JWT)
  • 자체 서명 바이너리 blob

자세한 내용은 단기 서비스 계정 사용자 인증 정보 만들기를 참조하세요.

감사 로그 해석

Cloud 감사 로그를 사용하면 Google Cloud 리소스에 대해 '누가, 언제, 어디서, 무엇을 했는지' 파악할 수 있습니다.

단기 사용자 인증 정보를 사용하여 서비스 계정을 가장하면 대부분의 Google Cloud 서비스에서 다음 ID를 보여주는 로그 항목을 만듭니다.

  • 단기 사용자 인증 정보로 가장한 서비스 계정
  • 단기 사용자 인증 정보를 생성한 ID

이러한 로그 항목을 사용하여 단기 사용자 인증 정보를 만든 주 구성원뿐만 아니라 주 구성원이 가장한 서비스 계정을 식별할 수 있습니다.

서비스 계정 가장을 보여주는 감사 로그 항목의 예시는 Google Cloud에 액세스하기 위해 서비스 계정 가장을 참조하세요.

자체 가장

자체 가장은 서비스 계정의 자체 사용자 인증 정보를 사용하여 서비스 계정에 대해 새 사용자 인증 정보를 생성하려고 할 때 발생합니다.

Service Account Credentials API는 다음 종류의 자체 가장을 금지합니다.

Google Cloud는 악의적인 행위자가 도난된 토큰을 무제한 새로고침할 수 있기 때문에 이러한 종류의 자체 가장을 금지합니다.

금지된 방법 중 하나로 자체 가장을 사용하려고 시도하면 다음 오류가 발생할 수 있습니다.

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

이 오류가 발생하면 최종 사용자의 사용자 인증 정보 또는 다른 서비스 계정의 사용자 인증 정보와 같이, 다른 사용자 인증 정보를 사용하여 서비스 계정에 대해 새로운 단기 사용자 인증 정보를 생성하도록 시도하세요.

서비스 계정 키

각 서비스 계정은 공개/비공개 RSA 키 쌍과 연결됩니다. Service Account Credentials API는 이 내부 키 쌍을 사용하여 단기 서비스 계정 사용자 인증 정보를 만들고 blob과 JSON 웹 토큰(JWT)을 서명합니다. 이 키 쌍을 Google 관리 키 쌍이라고 합니다.

또한 사용자 관리형 키 쌍이라고 하는 공개/비공개 RSA 키 쌍을 여러 개 만들고 비공개 키를 사용하여 Google API에 인증할 수 있습니다. 이 비공개 키를 서비스 계정 키라고 합니다.

Google 관리 키 쌍

Google 관리 키 쌍은 Service Account Credentials API 및 Google Cloud 서비스(예: App Engine 및 Compute Engine)에서 서비스 계정의 단기 사용자 인증 정보를 생성하는 데 사용됩니다.

서명에 활발히 사용되는 Google 관리 키는 보안 권장사항에 따라 정기적으로 순환됩니다. 순환 프로세스는 확률적입니다. 즉 새로운 키 사용량은 키 수명 기간 동안 점진적으로 증가하거나 감소합니다.

Google 관리 키 쌍의 비공개 키는 항상 에스크로에 보관되며 이 비공개 키에 직접 액세스할 수 없습니다.

공개적으로 Google 관리 키 쌍의 공개 키에 액세스할 수 있으므로 누구나 비공개 키로 생성된 서명을 확인할 수 있습니다. 공개 키에 다양한 형식으로 액세스할 수 있습니다.

  • X.509 인증서: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • JSON 웹 키(JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • 원시 형식: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

공개 키를 다운로드하고 캐시하는 경우 현재 키가 항상 유지되도록 최대 24시간 동안 캐싱하는 것이 좋습니다. 공개 키를 검색한 시점에 관계없이 검색 후 최소 24시간 동안 유효합니다.

사용자 관리형 키 쌍

서비스 계정에 사용자 관리형 키 쌍을 만든 후 각 키 쌍의 비공개 키를 사용하여 Google API에 인증할 수 있습니다. 이 비공개 키를 서비스 계정 키라고 합니다.

Cloud 클라이언트 라이브러리는 서비스 계정 키를 사용하여 자동으로 OAuth 2.0 액세스 토큰을 가져올 수 있습니다. 서비스 계정 키를 사용하여 수동으로 JWT를 서명한 후 서명된 JWT를 사용하여 액세스 토큰을 요청할 수도 있습니다. 자세한 내용은 서버 간 애플리케이션용 OAuth 2.0 사용을 참조하세요.

각 서비스 계정에는 최대 10개의 서비스 계정 키가 있을 수 있습니다. Google에서는 사용자 관리형 키 쌍의 공개 부분만 저장합니다.

서비스 계정의 사용자 관리형 키 쌍을 만드는 방법에는 몇 가지가 있습니다.

사용자 관리 키는 매우 강력한 사용자 인증 정보입니다. 사용자 관리형 키 사용을 제한하려면 다음 조직 정책 제약조건을 조직, 프로젝트, 폴더에 적용하면 됩니다.

  • constraints/iam.disableServiceAccountKeyCreation: 주 구성원이 사용자 관리 서비스 계정 키를 만들지 못하게 합니다.
  • constraints/iam.disableServiceAccountKeyUpload: 주 구성원이 서비스 계정의 공개 키를 업로드하지 못하게 합니다.

워크로드 아이덴티티 제휴를 사용하고 있기 때문에 이러한 제약조건을 적용하는 경우 워크로드 아이덴티티 제휴를 위한 조직 정책 제약조건을 사용하여 허용할 ID 공급업체를 지정하는 것이 좋습니다.

사용자 관리 키 만료 시간

기본적으로 사용자 관리 서비스 계정 키를 만들 때 키는 만료되지 않습니다. 이 기본값은 프로젝트, 폴더 또는 조직에서 새로 생성되는 모든 키에 만료 시간을 설정하여 변경할 수 있습니다. 만료 시간은 새로 생성된 키가 유효한 시간의 수를 지정합니다.

서비스 계정 키가 필요한 시스템에 임시로 액세스해야 하는 경우 만료 시간을 사용하세요. 예를 들어 다음 작업을 할 때 만료 시간을 사용합니다.

  • 서비스 계정 키로만 인증할 수 있는 애플리케이션을 위해 비프로덕션 환경에서 코드 개발
  • 서비스 계정 키로만 인증할 수 있는 서드 파티 도구 사용

다음 시나리오에서는 만료 시간을 사용하지 마세요.

  • 프로덕션 워크로드. 프로덕션 환경에서 서비스 계정 키가 만료되면 우발적인 서비스 중단이 발생할 수 있습니다. 대신 만료되지 않는 키를 사용하고 키 순환으로 수명 주기를 관리하세요.
  • 지속적 통합(CI) 파이프라인과 같은 영구 액세스가 필요한 비프로덕션 워크로드
  • 지정된 시간이 지난 후 키가 사용되지 않도록 방지하는 키 순환 시스템. 권장 키 순환 전략에 대해 알아보려면 서비스 계정 키 순환을 참조하세요.

서비스 중단을 방지하려면 constraints/iam.disableServiceAccountKeyCreation 조직 정책 제약조건이 장시간 지속된 경우를 제외하고 만료 시간을 설정하지 않는 것이 좋습니다. 만료 시간을 설정할 때는 constraints/iam.disableServiceAccountKeyCreation 제약조건 적용도 중지해야 합니다. 이 제약조건에 대한 자세한 내용은 서비스 계정 키 수명 제한을 참조하세요.

만료 시간을 설정하려면 다음을 수행합니다.

  1. 서비스 계정 키의 만료 시간을 설정하려는 프로젝트, 폴더 또는 조직을 식별합니다.
  2. constraints/iam.serviceAccountKeyExpiryHours 제약조건을 적용하는 조직 정책을 추가합니다. 프로젝트, 폴더 또는 조직에 대해 이 제약조건을 적용하면 만료 시간이 해당 상위 리소스 내에서 새로 생성된 모든 서비스 계정 키에 적용됩니다. 기존 키는 영향을 받지 않습니다.

만료 시간은 시간 단위로 측정됩니다. 8시간, 24시간(1일), 168시간(7일) 등 짧은 만료 시간을 사용하는 것이 좋습니다. 만료 시간이 짧으면 팀이 키를 업데이트하는 잘 테스트된 프로세스를 갖추는 데 도움이 됩니다. 니즈에 맞는 가장 짧은 만료 시간으로 시작하고 필요한 경우에만 늘립니다.