서비스 계정 개요

이 페이지에서는 서비스 계정이 무엇인지와 수명 주기의 각 단계에서 서비스 계정을 관리하기 위한 중요한 고려사항을 설명합니다.

서비스 계정이란 무엇인가요?

서비스 계정은 일반적으로 사용자가 아닌 Compute Engine 인스턴스와 같은 애플리케이션 또는 컴퓨팅 워크로드에서 사용하는 특별한 유형의 계정입니다. 서비스 계정은 계정 고유의 이메일 주소로 식별됩니다.

애플리케이션은 서비스 계정을 사용해 인증된 API 호출을 수행하는데, 이 인증은 서비스 계정 자체로 이루어지거나 Google Workspace 또는 도메인 전체 위임을 통해 Cloud ID 사용자로서 이루어집니다. 애플리케이션이 서비스 계정으로 인증되면 서비스 계정에 액세스 권한이 있는 모든 리소스에 액세스할 수 있습니다.

애플리케이션이 서비스 계정으로 인증하도록 하는 가장 일반적인 방법은 애플리케이션을 실행하는 리소스에 서비스 계정을 연결하는 것입니다. 예를 들어 Compute Engine 인스턴스에 서비스 계정을 연결하여 해당 인스턴스에서 실행 중인 애플리케이션이 서비스 계정으로 인증되도록 할 수 있습니다. 그런 다음 서비스 계정에 IAM 역할을 부여하여 서비스 계정, 더 나아가 인스턴스의 애플리케이션이 Google Cloud 리소스에 액세스하도록 할 수 있습니다.

애플리케이션이 서비스 계정을 연결하는 것 외에도 서비스 계정으로 인증하도록 하는 다른 방법이 있습니다. 예를 들어 워크로드 아이덴티티 제휴를 설정하여 외부 워크로드를 서비스 계정으로 인증하도록 허용하거나 서비스 계정 키를 만들어 모든 환경에서 이를 사용하여 OAuth 2.0 액세스 토큰을 가져올 수 있습니다.

애플리케이션의 서비스 계정 인증에 대한 자세한 내용은 워크로드의 ID 개요를 참조하세요.

사용자 및 기타 서비스 계정과 같은 주 구성원도 서비스 계정으로 인증할 수 있습니다. 자세한 내용은 이 페이지의 서비스 계정 가장을 참조하세요.

서비스 계정 유형

Google Cloud에는 다양한 유형의 서비스 계정이 있습니다.

• 사용자 관리 서비스 계정: 사용자가 만들고 관리하는 서비스 계정입니다. 이러한 서비스 계정은 종종 워크로드의 ID로 사용됩니다.

• 기본 서비스 계정: 사용자 관리 서비스 계정이며, 특정 Google Cloud 서비스를 사용 설정할 때 자동으로 생성됩니다. 이러한 서비스 계정을 관리하는 것은 사용자의 책임입니다.

• 서비스 에이전트:Google Cloud에서 생성 및 관리되고 서비스가 사용자 대신 리소스에 액세스할 수 있게 하는 서비스 계정입니다.

다양한 유형의 서비스 계정에 대한 자세한 내용은 서비스 계정 유형을 참조하세요.

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

애플리케이션과 주 구성원은 다음 중 하나를 수행하여 서비스 계정으로 인증합니다.

• 단기 사용자 인증 정보를 가져옵니다. 연결된 서비스 계정과 gcloud CLI --impersonate-service-account 플래그를 사용하는 명령어와 같은 경우에는 이러한 사용자 인증 정보를 자동으로 가져오므로 직접 만들거나 관리할 필요가 없습니다.
• 서비스 계정 키를 사용하여 JSON 웹 토큰(JWT)을 서명하고 액세스 토큰으로 교환합니다. 서비스 계정 키는 올바르게 관리되지 않는 경우 보안 위험이 될 수 있으므로 가능하면 서비스 계정 키보다 안전한 대안을 선택해야 합니다.

서비스 계정 인증에 대한 자세한 내용은 서비스 계정 사용자 인증 정보를 참조하세요.

서비스 계정 가장

사용자 또는 다른 서비스 계정과 같은 인증된 주 구성원이 서비스 계정의 권한을 얻기 위해 서비스 계정으로 인증될 때 이를 서비스 계정을 가장한다고 부릅니다. 서비스 계정을 가장하면 서비스 계정이 액세스할 수 있는 무엇이든 인증된 주 구성원이 액세스할 수 있습니다. 적절한 권한을 사용해서 인증된 주 구성원만 서비스 계정을 가장할 수 있습니다.

가장은 Identity and Access Management(IAM) 정책을 변경하지 않고 사용자 권한을 변경하려고 할 때 유용합니다. 예를 들어 가장을 사용하면 사용자에게 승격된 액세스 권한을 일시적으로 부여하거나 어떤 태스크에 대해 특정 권한 집합이 충분한지 여부를 테스트해볼 수 있습니다. 또한 가장을 사용해서 서비스 계정으로만 실행 가능한 애플리케이션을 로컬로 개발하거나 Google Cloud외부에서 실행되는 애플리케이션을 인증할 수도 있습니다.

서비스 계정 가장에 대한 자세한 내용은 서비스 계정 가장을 참조하세요.

서비스 계정 및 Google Workspace 도메인

서비스 계정은 사용자 계정과 달리 Google Workspace 도메인에 속하지 않습니다. 문서 또는 이벤트와 같은 Google Workspace 애셋을 전체 Google Workspace 도메인과 공유할 경우 서비스 계정과 공유되지 않습니다.

서비스 계정은 Google Workspace 애셋을 소유할 수 없습니다. 하지만 도메인의 공유 드라이브에서 애셋을 만들 수는 있습니다. 공유 드라이브에서 생성된 애셋은 조직에서 소유하고 관리합니다.

서비스 계정 권한

서비스 계정은 주 구성원입니다. 즉, 서비스 계정에 Google Cloud 리소스에 대한 액세스를 부여할 수 있습니다. 예를 들어 서비스 계정에 프로젝트의 Compute 관리자 역할(roles/compute.admin)을 부여할 수 있습니다. 그러면 서비스 계정이 해당 프로젝트에서 Compute Engine 리소스를 관리할 수 있습니다.

그러나 서비스 계정은 리소스이기도 합니다. 즉, 다른 주 구성원에게 서비스 계정에 액세스할 수 있는 권한을 부여할 수 있습니다. 예를 들어 사용자에게 서비스 계정에 대한 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여하면 해당 서비스 계정을 리소스에 연결할 수 있습니다. 또는 사용자에게 서비스 계정 보기, 수정, 사용 중지, 삭제와 같은 작업을 수행하도록 서비스 계정 관리자 역할(roles/iam.serviceAccountAdmin)을 부여할 수 있습니다.

다음 섹션에서는 서비스 계정을 주 구성원 및 리소스로 관리하는 방법을 설명합니다.

서비스 계정을 주 구성원으로 사용

서비스 계정은 주 구성원이므로 다른 주 구성원과 마찬가지로 서비스 계정의 액세스 권한을 관리할 수 있습니다. 예를 들어 애플리케이션의 서비스 계정이 Cloud Storage 버킷의 객체에 액세스하도록 하려면 서비스 계정에 버킷에 대한 스토리지 객체 뷰어 역할(roles/storage.objectViewer)을 부여하면 됩니다. 또는 애플리케이션의 서비스 계정이 프로젝트의 IAM 정책을 변경할 수 없도록 하려면 거부 정책을 사용하여 서비스 계정이 해당 프로젝트에서 resourcemanager.projects.setIamPolicy 권한을 사용하지 못하게 하면 됩니다. 주 구성원의 액세스 관리에 대해 자세히 알아보려면 Google Cloud의 액세스를 참조하세요.

개별 서비스 계정 또는 특정 프로젝트, 폴더, 조직의 모든 서비스 계정에 대한 액세스를 관리할 수 있습니다. 서비스 계정의 액세스를 관리할 때는 다음 주 구성원 식별자를 사용하여 서비스 계정을 참조하세요.

주 구성원 유형	주 구성원 식별자
개별 서비스 계정	serviceAccount:SA_EMAIL_ADDRESS 예: serviceAccount:my-service-account@my-project.iam.gserviceaccount.com
프로젝트의 모든 서비스 계정	principalSet://cloudresourcemanager.googleapis.com/projects/PROJECT_NUMBER/type/ServiceAccount 예: principalSet://cloudresourcemanager.googleapis.com/projects/123456789012/type/ServiceAccount
폴더의 모든 프로젝트에 있는 모든 서비스 계정	principalSet://cloudresourcemanager.googleapis.com/folders/FOLDER_NUMBER/type/ServiceAccount 예: principalSet://cloudresourcemanager.googleapis.com/folders/123456789012/type/ServiceAccount
조직의 모든 프로젝트에 있는 모든 서비스 계정	principalSet://cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_NUMBER/type/ServiceAccount 예: principalSet://cloudresourcemanager.googleapis.com/organizations/123456789012/type/ServiceAccount

모든 유형의 주 구성원과 마찬가지로, 서비스 계정에 목표를 달성하는 데 필요한 최소 권한 집합만 부여해야 합니다.

특정 프로젝트, 폴더 또는 조직의 서비스 계정이 요구사항을 공유하는 경우 커스텀 그룹을 사용하는 대신 서비스 계정 주 구성원 집합을 사용하여 역할을 부여합니다.

서비스 계정을 포함하여 주 구성원에게 역할을 부여하는 방법을 알아보려면 프로젝트, 폴더, 조직 액세스 관리를 참조하세요.

서비스 계정을 리소스로 사용

서비스 계정은 또한 자체 허용 정책을 가질 수 있는 리소스입니다. 따라서 다른 주 구성원이 서비스 계정 또는 서비스 계정의 상위 리소스 중 하나에 대한 역할을 부여하여 서비스 계정에 액세스하도록 할 수 있습니다. 예를 들어 사용자가 서비스 계정을 가장할 수 있도록 사용자에게 서비스 계정에 대한 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)을 부여할 수 있습니다.

사용자에게 서비스 계정을 가장할 수 있도록 하는 역할을 부여할 때, 사용자는 서비스 계정이 액세스할 수 있는 모든 리소스에 액세스할 수 있음에 유의하세요. 사용자가 Compute Engine 및 App Engine 기본 서비스 계정과 같이 권한이 높은 서비스 계정을 가장하도록 허용할 경우에는 주의해야 합니다.

서비스 계정의 주 구성원에게 부여할 수 있는 역할에 대한 자세한 내용은 서비스 계정 권한을 참조하세요.

주 구성원에게 서비스 계정에 대한 역할을 부여하는 방법은 서비스 계정에 대한 액세스 관리를 참조하세요.

서비스 계정 수명 주기

프로젝트를 관리할 때 여러 가지 서비스 계정을 만들고, 관리, 삭제할 수 있습니다. 이 섹션에서는 수명 주기의 다양한 단계에서 서비스 계정을 관리하기 위한 주요 고려사항을 설명합니다.

서비스 계정 생성 위치

각 서비스 계정은 프로젝트에 위치합니다. 서비스 계정을 만든 후에는 다른 프로젝트로 이동할 수 없습니다.

서비스 계정을 프로젝트로 구성하는 몇 가지 방법이 있습니다.

• 같은 프로젝트에 서비스 계정과 리소스를 만듭니다.

  이 방법을 사용하면 서비스 계정을 쉽게 시작할 수 있습니다. 하지만 서비스 계정이 많은 프로젝트에 분산되어 있으면 서비스 계정을 추적하기 어려울 수 있습니다.

• 서로 다른 프로젝트의 서비스 계정을 중앙화합니다.

  이 방법을 사용하면 조직의 모든 서비스 계정이 소수의 프로젝트로 정리되어 서비스 계정을 보다 쉽게 관리할 수 있습니다. 이 방법을 사용하려면 다른 프로젝트의 리소스에 서비스 계정을 연결하는 경우 추가 설정이 필요합니다. 그러면 해당 리소스가 서비스 계정을 ID로 사용할 수 있습니다.

  서비스 계정이 한 프로젝트에 있고 다른 프로젝트의 리소스에 액세스하는 경우 일반적으로 두 프로젝트에서 해당 리소스에 API를 사용 설정해야 합니다. 예를 들어 my-service-accounts 프로젝트에 서비스 계정이 있고 my-application 프로젝트에 Cloud SQL 인스턴스가 있는 경우 my-service-accounts 및 my-application 모두에 Cloud SQL API를 사용 설정해야 합니다.

  기본적으로 프로젝트 하나에 서비스 계정을 100개까지 만들 수 있습니다. 추가 서비스 계정을 만들어야 하는 경우 할당량 조정을 요청합니다.

서비스 계정을 만드는 방법을 알아보려면 서비스 계정 만들기를 참조하세요.

서비스 계정 생성 방지

서비스 계정이 생성되는 위치를 더 효과적으로 제어하려면 조직의 일부 프로젝트에서 서비스 계정이 생성되지 않도록 할 수 있습니다.

조직, 프로젝트 또는 폴더에서 constraints/iam.disableServiceAccountCreation 조직 정책 제약조건을 적용하여 서비스 계정 생성을 방지할 수 있습니다.

이 제약조건을 적용하기 전에 다음 제한사항을 고려하세요.

• 프로젝트 또는 조직 내의 모든 프로젝트에 이 제약조건을 적용하면 일부 Google Cloud 서비스는 기본 서비스 계정을 만들 수 없습니다. 따라서 프로젝트에서 서비스 계정으로 인증해야 하는 워크로드를 실행하면 프로젝트에는 워크로드가 사용할 수 있는 서비스 계정이 포함되지 않을 수 있습니다.

  이 문제를 해결하려면 프로젝트 간 서비스 계정 가장을 사용 설정하면 됩니다. 이 기능을 사용 설정하면 중앙 집중식 프로젝트에서 서비스 계정을 만든 다음 다른 프로젝트의 리소스에 서비스 계정을 연결할 수 있습니다. 이러한 리소스에서 실행되는 워크로드는 연결된 서비스 계정을 사용하여 인증할 수 있으므로 기본 서비스 계정이 필요하지 않습니다.

• 워크로드 아이덴티티 제휴와 같은 일부 기능을 사용하려면 서비스 계정을 만들어야 합니다.

  워크로드 아이덴티티 제휴를 사용하지 않는 경우 조직 정책 제약 조건을 사용하여 모든 ID 공급업체의 제휴를 차단하는 것이 좋습니다.

서비스 계정 상태 확인

시간이 지남에 따라 더 많은 서비스 계정이 생겨나면 어떤 서비스 계정이 어떤 용도로 사용되는지 파악하기 어려울 수 있습니다.

서비스 계정의 표시 이름은 서비스 계정의 목적이나 서비스 계정 담당자와 같이 서비스 계정에 대한 추가 정보를 파악하는 데 유용한 방법입니다. 새로운 서비스 계정의 경우 서비스 계정을 만들 때 표시 이름을 입력할 수 있습니다. 기존 서비스 계정의 경우 serviceAccounts.update() 메서드를 사용하여 표시 이름을 수정합니다.

Compute Engine에서 서비스 계정 사용

Compute Engine 인스턴스가 다른 Google Cloud 리소스에 액세스하려면 서비스 계정으로 실행되어야 합니다. Compute Engine 인스턴스 보안을 위해 다음 사항을 고려하세요.

• 같은 프로젝트에 서비스 계정이 서로 다른 인스턴스를 만들 수 있습니다. 인스턴스를 만든 후 서비스 계정을 변경하려면 instances.setServiceAccount 메서드를 사용합니다.

• 연결된 서비스 계정에 승인을 설정하려면 IAM 역할을 구성하는 것 외에도 액세스 범위를 구성해야 합니다.

• 인스턴스는Google Cloud 리소스에 액세스하는 데 자신의 서비스 계정을 사용하므로 실행 중인 인스턴스에서 서비스 계정을 계속 사용하고 있으면 이 서비스 계정을 삭제하면 안 됩니다.

Compute Engine에서 서비스 계정을 사용하는 방법에 대한 자세한 내용은 Compute Engine 문서의 서비스 계정을 참조하세요.

사용하지 않는 서비스 계정 식별

시간이 흐른 뒤 더 이상 사용하지 않는 서비스 계정이 프로젝트에 있을 수 있습니다.

사용하지 않은 서비스 계정으로 인해 불필요한 보안 위험이 발생할 수 있으므로 사용하지 않는 서비스 계정을 사용 중지한 다음 더 이상 필요하지 않다는 확신이 들 때 해당 서비스 계정을 삭제하는 것이 좋습니다. 다음 방법을 사용하여 사용하지 않는 서비스 계정을 식별할 수 있습니다.

• 서비스 계정 통계로 지난 90일 동안 인증되지 않은 프로젝트의 서비스 계정을 알 수 있습니다.
• 활동 분석기를 사용하면 서비스 계정이나 키가 마지막으로 사용된 시기를 확인할 수 있습니다.

서비스 계정 사용량 측정항목을 사용하면 일반적으로 서비스 계정과 키 사용량을 추적할 수 있습니다.

Security Command Center 프리미엄 고객의 경우 Event Threat Detection을 사용하여 휴면 서비스 계정으로 작업을 트리거할 때 알림을 받을 수 있습니다. 휴면 서비스 계정은 180일 이상 비활성 상태인 서비스 계정입니다. 서비스 계정을 사용하면 더 이상 휴면 상태가 아닙니다.

서비스 계정 삭제

서비스 계정을 삭제하기 전에 서비스 계정을 사용 중지하여 필요하지 않은지 확인합니다. 사용 중지된 서비스 계정이 여전히 사용 중인 경우 이 계정을 다시 사용 설정할 수 있습니다.

서비스 계정이 필요하지 않은 것을 확인한 후 서비스 계정을 삭제할 수 있습니다.

삭제된 서비스 계정 다시 만들기

서비스 계정을 삭제한 후 같은 이름으로 다시 새롭게 만들 수 있습니다.

서비스 계정을 삭제하더라도 역할 바인딩은 바로 삭제되지 않습니다. 대신 역할 binding에 deleted: 프리픽스가 있는 서비스 계정이 나열됩니다. 예시는 삭제된 주 구성원이 포함된 정책을 참조하세요.

최근에 삭제한 서비스 계정과 이름이 같은 새 서비스 계정을 만들면 이전 binding이 계속해서 존재할 수 있습니다. 하지만 두 계정의 이메일 주소가 같더라도 이전 binding이 새로운 서비스 계정에 적용되지 않습니다. 이는 서비스 계정을 만들 때 Identity and Access Management(IAM) 내에서 고유 ID가 할당되기 때문입니다. 내부적으로 모든 역할 binding은 서비스 계정의 이메일 주소가 아닌 고유 ID를 통해 부여됩니다. 따라서 삭제된 서비스 계정에 있는 역할 binding은 같은 이메일 주소를 사용하는 새 서비스 계정에 적용되지 않습니다.

마찬가지로 리소스에 서비스 계정을 연결한 후 서비스 계정을 삭제하고 이름이 같은 새 서비스 계정을 만들면 새 서비스 계정이 리소스에 연결되지 않습니다.

예상치 못한 동작을 방지하려면 모든 서비스 계정에 고유한 새 이름을 사용하는 것이 좋습니다. 또한 실수로 서비스 계정을 삭제한 경우 새 서비스 계정을 만드는 대신 서비스 계정 삭제를 취소할 수 있습니다.

원래의 서비스 계정 삭제를 취소할 수 없고 동일한 이름과 역할의 새 서비스 계정을 만들어야 하는 경우 새 서비스 계정에 역할을 부여해야 합니다. 자세한 내용은 삭제된 주 구성원이 포함된 정책을 참조하세요.

또한 새 서비스 계정을 원래 서비스 계정과 동일한 리소스에 연결해야 하는 경우 다음 중 하나를 수행합니다.

• Compute Engine 인스턴스의 경우 인스턴스에 연결된 서비스 계정을 변경하여 원래 서비스 계정을 새 서비스 계정으로 바꿀 수 있습니다.
• 다른 모든 리소스의 경우 기존 리소스를 삭제한 후 동일한 유형의 새 리소스를 만들고 새 서비스 계정을 연결해야 합니다.

다음 단계

• 서비스 계정을 만드는 방법 알아보기
• 서비스 계정 작업 권장사항 알아보기
• 서비스 계정 키 관리 권장사항 검토

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

무료로 시작하기