서비스 계정 사용 및 관리 권장사항

서비스 계정은 사람이 아닌 사용자를 나타냅니다. 이는 커스텀 애플리케이션과 같은 워크로드가 최종 사용자의 개입 없이 리소스에 액세스하거나 작업을 수행해야 하는 경우의 시나리오를 위한 것입니다.

서비스 계정은 다음과 같은 여러 가지 이유로 일반 사용자 계정과 다릅니다.

  • 비밀번호가 없어 브라우저 기반 로그인에 사용할 수 없습니다.
  • Google Cloud 프로젝트에 속하는 리소스로 생성 및 관리됩니다. 반면 사용자는 Cloud ID 또는 Google Workspace 계정에서 관리됩니다.
  • 이는 Google Cloud에만 해당됩니다. 반면 Cloud ID 또는 Google Workspace에서 관리되는 사용자는 여러 Google 제품 및 서비스에서 작동합니다.

이 가이드에서는 서비스 계정을 관리, 사용, 보호하기 위한 권장사항을 제시합니다.

서비스 계정 사용 시기 선택하기

서비스 계정은 다양한 용도로 사용될 수 있지만 항상 최상의 선택은 아닙니다. 다음 섹션에서는 서비스 계정을 사용해야 하는 경우와 사용하지 말아야 하는 경우에 대한 지침을 제공합니다.

무인 시나리오에 서비스 계정 사용

모든 애플리케이션이 사용자와 상호작용하는 것은 아닙니다. 대신 애플리케이션이 백그라운드에서 자동으로 실행될 수 있습니다. 무인 애플리케이션에는 일괄 작업, 큐에서 읽은 메시지를 전달하는 작업자 프로세스, 리소스 모니터링 에이전트가 있습니다.

무인 애플리케이션에서 Cloud Storage 버킷과 같은 리소스에 액세스해야 할 때마다 최종 사용자를 대신하는 것이 아니라 자체적으로 작업을 수행해야 합니다. 자체적으로 작업을 수행하려면 애플리케이션에 최종 사용자 ID와 관련이 없는 자체 ID가 필요합니다.

애플리케이션에 고유한 ID를 제공하려면 애플리케이션의 서비스 계정을 만들고 애플리케이션이 액세스해야 하는 리소스에 대한 액세스 권한을 부여합니다. 애플리케이션이 자체 서비스 계정을 사용하도록 허용하면 사용자의 개입 없이도 애플리케이션이 작동할 수 있습니다. 또한 애플리케이션에서 시작한 리소스 액세스가 동일한 애플리케이션에 다시 부여되도록 할 수 있습니다.

서비스 계정을 사용하여 주 구성원 간 전환 수행

최종 사용자와 상호작용하는 애플리케이션은 Google 로그인을 사용하여 해당 사용자를 인증할 수 있지만 반드시 그럴 필요는 없습니다. 대신 애플리케이션은 타사 ID 공급업체 사용하거나 커스텀 인증 방식을 구현하여 사용자를 인증할 수 있습니다.

애플리케이션에서 타사 ID 또는 커스텀 ID를 사용하고 BigQuery 데이터 세트 또는 Cloud Storage 버킷과 같은 리소스에 액세스해야 하는 경우 주 구성원 간 전환을 수행해야 합니다. Google Cloud API는 타사 또는 커스텀 ID를 인식하지 못하므로 애플리케이션은 최종 사용자의 ID를 BigQuery 또는 Cloud Storage에 반영할 수 없습니다. 대신 애플리케이션은 다른 Google ID를 사용하여 액세스를 수행해야 합니다.

애플리케이션에서 주 구성원 간 전환이 수행되도록 하려면 애플리케이션의 서비스 계정을 만들고 애플리케이션이 액세스해야 하는 리소스에 대한 액세스 권한을 부여합니다. 애플리케이션에서 Google Cloud 리소스에 액세스해야 할 때마다 최종 사용자를 먼저 인증한 다음 서비스 계정을 사용하여 리소스에 액세스하도록 해야 합니다.

주 구성원 간 전환 시 영향을 받는 Google Cloud 리소스의 Cloud 감사 로그의 유용성이 제한될 수 있습니다. 애플리케이션이 서비스 계정을 사용하여 리소스에 액세스하기 때문에 특정 최종 사용자를 대신하여 작업을 수행했는지가 Cloud 감사 로그에 명확하게 표시되지 않을 수 있기 때문입니다. 거부되지 않도록 하려면 주 구성원 간에 전환이 발생할 때마다 커스텀 로그 레코드를 작성하도록 애플리케이션을 확장합니다. 이렇게 하면 리소스 액세스를 트리거한 최종 사용자를 추적할 수 있습니다.

애플리케이션에서 민감한 데이터나 개인적인 사용자 데이터에 액세스해야 할 수도 있습니다. 이러한 데이터의 예시로는 사용자의 편지함 또는 캘린더, 드라이브에 저장된 문서, 민감한 정보가 포함된 BigQuery 데이터 세트 등이 있습니다.

서비스 계정을 사용하여 사용자 데이터에 액세스하는 것은 애플리케이션이 색인 생성 또는 데이터 손실 방지(DLP) 스캔과 같이 무인 백그라운드 작업을 수행하거나 최종 사용자가 Google ID로 인증하지 않은 경우 적절할 수 있습니다. 애플리케이션이 최종 사용자를 대신하는 다른 모든 시나리오에서는 서비스 계정을 사용하지 않는 것이 좋습니다.

서비스 계정을 사용하여 사용자 데이터에 액세스하는 대신(주 구성원 전환을 수행) OAuth 동의 흐름을 사용하여 최종 사용자의 동의를 요청합니다. 그런 다음 애플리케이션이 최종 사용자의 ID로 작동하게 합니다. 서비스 계정 대신 OAuth를 사용하면 다음을 수행할 수 있습니다.

  • 사용자는 애플리케이션에 어떤 리소스에 대한 액세스 권한을 부여할지 검토할 수 있으며, 동의를 명시적으로 표현하거나 거부할 수 있습니다.
  • 사용자는 언제든지 내 계정 페이지에서 동의를 취소할 수 있습니다.
  • 모든 사용자 데이터에 대한 액세스 권한에 제한이 없는 서비스 계정은 필요하지 않습니다.

애플리케이션에서 최종 사용자 인증 정보를 사용하도록 허용하면 Google Cloud API에 대한 권한 검사가 연기됩니다. 이 방식은 코딩 오류(혼동된 대리인 문제)로 인해 사용자가 액세스할 수 없는 데이터를 실수로 노출할 위험을 제한합니다.

개발 중에는 서비스 계정을 사용하지 않음

일상적인 작업을 처리하는 동안 gcloud 명령줄 도구, gsutil 또는 terraform과 같은 도구를 사용할 수 있습니다. 이러한 도구를 실행하는 데 서비스 계정을 사용하지 마세요. 대신 gcloud auth login(gcloud 도구 및 gsutil의 경우) 또는 gcloud auth application-default login(terraform 및 기타 타사 도구의 경우)을 우선적으로 실행하여 사용자 인증 정보를 사용하도록 허용할 수 있습니다.

Google Cloud에 배포하려는 애플리케이션을 개발하고 디버깅할 때도 유사한 방법을 사용할 수 있습니다. 배포 시 애플리케이션에 서비스 계정이 필요할 수 있지만, 로컬 워크스테이션에서 실행하는 경우에는 애플리케이션에서 개인 사용자 인증 정보를 사용하도록 허용할 수 있습니다.

애플리케이션에서 개인 사용자 인증 정보와 서비스 계정 사용자 인증 정보를 모두 지원할 수 있도록 Cloud 클라이언트 라이브러리를 사용하여 자동으로 사용자 인증 정보를 찾습니다.

서비스 계정 사용

사용자가 Google Cloud에 인증하는 일반적인 방법은 사용자 이름과 비밀번호를 사용하여 로그인하거나 싱글 사인온(SSO)을 사용하는 것입니다. 서비스 계정에는 비밀번호가 없으며 SSO를 사용할 수 없습니다. 대신 서비스 계정은 다른 인증 방식 집합을 지원합니다. 다음 섹션에서는 인증 방법을 선택하기 위한 권장사항을 제공합니다.

서비스 계정 사용 방법

가능한 경우 연결된 서비스 계정 사용

Google Cloud에 배포된 애플리케이션이 서비스 계정을 사용하도록 허용하려면 기본 컴퓨팅 리소스에 서비스 계정을 연결합니다. 서비스 계정을 연결하면 애플리케이션이 서비스 계정의 토큰을 획득하여 Google Cloud API 및 리소스에 액세스할 수 있습니다.

애플리케이션에서 액세스 토큰을 얻으려면 가능한 겨우 클라이언트 라이브러리를 사용하세요. 클라이언트 라이브러리는 연결된 서비스 계정이 있는 컴퓨팅 리소스에서 애플리케이션이 실행되는지를 자동으로 감지합니다.

클라이언트 라이브러리를 사용할 수 없는 경우 메타데이터 서버에서 프로그래매틱 방식으로 토큰을 가져오도록 애플리케이션을 조정하세요. 메타데이터 서버에 대한 액세스를 지원하는 컴퓨팅 리소스는 다음과 같습니다.

서비스 계정을 연결할 수 있는 전체 컴퓨팅 리소스 목록은 서비스 계정 가장 관리를 참조하세요.

워크로드 아이덴티티를 사용하여 서비스 계정을 Kubernetes pod에 연결

Google Kubernetes Engine을 사용하는 경우 단일 GKE 클러스터에서 여러 애플리케이션 조합을 실행 중일 수 있습니다. 개별 애플리케이션은 액세스해야 하는 리소스와 API가 다를 수 있습니다.

서비스 계정을 GKE 클러스터 또는 노드 풀 중 하나에 연결하면 기본적으로 클러스터 또는 노드 풀에서 실행되는 모든 pod가 서비스 계정을 가장할 수 있습니다. 여러 애플리케이션에서 단일 서비스 계정을 공유하면 서비스 계정에 올바른 권한 조합을 부여하기가 어렵습니다.

  • 모든 애플리케이션에 필요한 리소스에 대해서만 액세스 권한을 부여하면 특정 리소스에 액세스해야 하는 일부 애플리케이션은 제대로 작동하지 않을 수 있습니다.
  • 특정 애플리케이션에만 필요한 모든 리소스에 대한 액세스 권한을 부여하면 액세스 권한이 과도하게 부여될 수 있습니다.

GKE 환경의 리소스에 대한 액세스를 관리하는 더 좋은 방법은 워크로드 아이덴티티를 사용하는 것입니다.

  1. GKE 클러스터 또는 노드 풀에 서비스 계정을 연결하지 마세요.
  2. Google API 또는 리소스에 액세스해야 하는 Kubernetes Pod마다 전용 서비스 계정을 만듭니다.
  3. Google API 또는 리소스에 액세스해야 하는 각 Kubernetes Pod에 대한 Kubernetes 서비스 계정을 만들고 pod에 연결합니다.
  4. 워크로드 아이덴티티를 사용하여 서비스 계정과 해당 Kubernetes 서비스 계정 간의 매핑을 만듭니다.

워크로드 아이덴티티 제휴를 사용하여 온프레미스 또는 다른 클라우드 제공업체에서 실행되는 애플리케이션이 서비스 계정을 사용하도록 허용

애플리케이션이 온프레미스 또는 다른 클라우드 제공업체에서 실행되는 경우 기본 컴퓨팅 리소스에 서비스 계정을 연결할 수 없습니다. 하지만 애플리케이션은 다음과 같은 환경별 사용자 인증 정보에 액세스할 수 있습니다.

  • AWS 임시 사용자 인증 정보
  • Azure Active Directory 액세스 토큰
  • OpenID 액세스 토큰 또는 Active Directory Federation Services(AD FS) 또는 KeyCloak과 같은 온프레미스 ID 공급업체에서 발급한 ID 토큰

애플리케이션에서 이러한 사용자 인증 정보 중 하나에 액세스할 수 있으며 Google Cloud API 또는 리소스에 액세스해야 하는 경우 워크로드 아이덴티티 제휴를 사용합니다.

워크로드 아이덴티티 제휴를 사용하면 Google Cloud 프로젝트와 외부 ID 공급업체 간에 단방향 트러스트 관계를 만들 수 있습니다. 트러스트를 설정하면 애플리케이션은 신뢰할 수 있는 ID 공급업체에서 발급한 사용자 인증 정보를 사용하여 다음 3단계 절차에 따라 서비스 계정을 가장할 수 있습니다.

  1. 신뢰할 수 있는 ID 공급업체에서 OpenID Connect ID 토큰과 같은 사용자 인증 정보를 가져옵니다.
  2. Security Token Service(STS) API를 사용하여 사용자 인증 정보를 단기 Google STS 토큰과 교환합니다.
  3. STS 토큰을 사용하여 IAM Service Account Credentials API를 인증하고 서비스 계정에 대한 단기 Google 액세스 토큰을 얻습니다.

워크로드 아이덴티티 제휴를 사용하면 애플리케이션에서 외부 환경에서 제공하는 인증 메커니즘을 사용할 수 있으며 서비스 계정 키를 저장하고 관리할 필요가 없습니다.

IAM Credentials API를 사용하여 사용자 인증 정보 중개

일부 애플리케이션에서는 특정 시간 또는 특정 상황에서만 특정한 리소스에 대한 액세스가 필요합니다. 예를 들면 다음과 같습니다.

  • 애플리케이션이 시작 중에 구성 데이터에 액세스해야 할 수 있지만 초기화 후에는 액세스 권한이 필요하지 않을 수 있습니다.
  • 관리자 애플리케이션은 각 작업의 액세스 요구사항이 다른 백그라운드 작업을 주기적으로 시작할 수 있습니다.

이러한 시나리오에서는 단일 서비스 계정을 사용하고 이 계정에 모든 리소스에 대한 액세스 권한을 부여하는 것은 최소 권한의 원칙에 위반됩니다. 어떤 시점에서나 애플리케이션은 실제로 필요한 것보다 많은 리소스에 액세스할 권한을 가질 수 있습니다.

애플리케이션의 각 부분에서 필요한 리소스에만 액세스할 수 있도록 하려면 IAM Credentials API를 사용하여 단기 사용자 인증 정보를 중개하세요.

  • 애플리케이션의 각 부분 또는 사용 사례에 대한 전용 서비스 계정을 만들고 서비스 계정에 필요한 리소스에 대한 액세스 권한만 부여합니다.
  • 감독 역할을 하는 다른 서비스 계정을 만듭니다. 감독 서비스 계정에 다른 서비스 계정의 서비스 계정 토큰 생성자 역할을 부여하여 이러한 서비스 계정에 대한 단기 액세스 토큰을 요청할 수 있도록 합니다.
  • 애플리케이션을 분할해 애플리케이션의 한 부분이 토큰 브로커 역할을 하고 이 부분만 감독 서비스 계정을 사용할 수 있도록 합니다.
  • 토큰 브로커를 사용하여 애플리케이션의 다른 부분에 단기 서비스 계정을 발급합니다.

실행 가능한 대안이 없는 경우 서비스 계정 키 사용

간혹 서비스 계정 연결이 불가능하고 워크로드 아이덴티티 또는 워크로드 아이덴티티 제휴를 사용할 수 없는 상황이 발생할 수도 있습니다. 예를 들어 온프레미스 애플리케이션 중 하나가 Google Cloud 리소스에 액세스해야 하지만 온프레미스 ID 공급업체가 OpenID Connect와 호환되지 않아서 워크로드 아이덴티티 제휴에 사용할 수 없는 경우가 있습니다.

다른 인증 방법을 사용할 수 없는 경우 애플리케이션의 서비스 계정 키를 만듭니다. 서비스 계정 키를 사용하면 애플리케이션은 사용자가 사용자 이름과 비밀번호를 사용하여 인증하는 방법과 유사하게 서비스 계정으로 인증할 수 있습니다. 서비스 계정 키는 보안 비밀 유형이며 무단 액세스로부터 보호되어야 합니다. key vault와 같은 안전한 곳에 저장하고 자주 순환하는 것이 좋습니다.

서비스 계정 관리

서비스 계정은 사용 방법뿐만 아니라 관리 방식도 일반 사용자 계정과 다릅니다. 다음 섹션에서는 서비스 계정 관리에 대한 권장사항을 제공합니다.

리소스로 서비스 계정 관리

일반 사용자 계정은 일반적으로 조직의 joiner-mover-leaver 프로세스에 따라 관리됩니다. 새 직원이 합류하면 해당 직원을 위해 새 사용자 계정이 생성됩니다. 해당 직원이 부서를 이동하면 사용자 계정이 업데이트됩니다. 퇴사한 직원의 사용자 계정은 정지되거나 삭제됩니다.

반면 서비스 계정은 특정 직원과 연결되어 있지 않습니다. 서비스 계정을 특정 VM 인스턴스 또는 애플리케이션과 같은 다른 리소스에 속하는 리소스 또는 이런 리소스의 일부라고 생각하는 것이 좋습니다.

서비스 계정을 효과적으로 관리하려면 서비스 계정을 개별적으로 보아서는 안 됩니다. 대신 연결된 리소스 맥락에서 이를 고려하고 서비스 계정과 관련 리소스를 하나의 단위로 관리합니다. 동일한 프로세스, 수명 주기, 주의를 서비스 계정 및 관련 리소스에 적용하고 동일한 도구를 사용하여 관리합니다.

단일 목적 서비스 계정 만들기

여러 애플리케이션에서 단일 서비스 계정을 공유하면 서비스 계정 관리가 복잡해질 수 있습니다.

  • 애플리케이션 수명 주기가 서로 다를 수 있습니다. 애플리케이션이 사용 중단된 경우 서비스 계정 역시 중단될 수 있는지 여전히 필요한지 확실하지 않을 수 있습니다.
  • 시간이 지나면 애플리케이션의 액세스 요구사항이 달라질 수 있습니다. 애플리케이션이 동일한 서비스 계정을 사용하는 경우 서비스 계정에 늘어나는 리소스에 대한 액세스 권한을 부여해야 하며, 이로 인해 전체 위험이 증가합니다.
  • Cloud 감사 로그는 변경을 수행하거나 또는 데이터에 액세스한 서비스 계정의 이름을 포함하지만 서비스 계정을 사용한 애플리케이션 이름은 표시하지 않습니다. 여러 애플리케이션에서 서비스 계정을 공유하는 경우 활동을 올바른 애플리케이션으로 추적하지 못할 수 있습니다.

이러한 문제를 방지하려면 각 애플리케이션에 대한 전용 서비스 계정을 만들고 기본 서비스 계정을 사용하지 마세요.

이름 지정 및 문서 규칙 따르기

서비스와 애플리케이션 또는 리소스 간의 연결을 추적하려면 새 서비스 계정을 만들 때 이름 지정 규칙을 따르세요.

  • 계정이 사용되는 방법을 식별하는 서비스 계정 이메일 주소에 프리픽스를 추가합니다. 예를 들면 다음과 같습니다.
    • vm- - VM 인스턴스에 연결된 서비스 계정의 경우.
    • wi- - 워크로드 아이덴티티가 사용하는 서비스 계정의 경우.
    • wif- - 워크로드 아이덴티티 제휴에서 사용하는 서비스 계정의 경우.
    • onprem- - 온프레미스 애플리케이션에서 사용하는 서비스 계정의 경우.
  • 서비스 계정 이메일 주소에 애플리케이션의 이름을 삽입합니다(예: VM이 여행 비용 애플리케이션을 실행하는 경우 vm-travelexpenses@).
  • 설명 필드를 사용하여 담당자, 관련 문서 링크 또는 기타 참고사항을 추가합니다.

서비스 계정의 이메일 주소에 민감한 정보나 용어를 삽입하지 마세요.

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

서비스 계정을 더 이상 사용하지 않는 경우 서비스 계정을 사용 중지합니다. 사용하지 않는 서비스 계정을 사용 중지하면 측면 이동 또는 악의적인 사용자에 의한 권한 에스컬레이션으로 인해 서비스 계정이 악용될 위험을 줄일 수 있습니다.

VM 인스턴스와 같은 특정 리소스와 연결된 단일 목적 서비스 계정의 경우 연결된 리소스가 사용 중지되거나 삭제되는 즉시 서비스 계정을 사용 중지합니다.

다양한 용도로 사용되거나 여러 리소스에서 공유되는 서비스 계정의 경우 서비스 계정이 아직 사용 중인지 파악하기가 더 어려울 수 있습니다. 이러한 경우에는 다음 메서드를 사용합니다.

사용하지 않는 서비스 계정을 삭제하기 전 사용 중지

서비스 계정을 삭제한 후 같은 이름으로 새 서비스 계정을 만들면 새 서비스 계정에 다른 ID가 할당됩니다. 따라서 원래 IAM 바인딩이 새 서비스 계정에 적용되지 않습니다. 반면 서비스 계정을 사용 중지했다가 다시 사용 설정해도 모든 IAM 바인딩은 그대로 유지됩니다.

실수로 IAM 결합이 삭제되지 않도록 하려면 서비스 계정을 즉시 삭제하지 않는 것이 좋습니다. 대신 더 이상 필요하지 않은 서비스 계정을 사용 중지하고 특정 기간이 경과한 후 계정을 삭제합니다.

App Engine 또는 Compute Engine 기본 서비스 계정과 같은 기본 서비스 계정을 삭제하지 마세요. 이러한 서비스 계정은 각 API를 사용 중지했다가 다시 사용 설정하지 않으면 다시 만들 수 없으며, 이로 인해 기존 배포가 중단될 수 있습니다. 기본 서비스 계정을 사용하지 않는 경우 삭제 대신 사용 중지합니다.

다음 단계

서비스 계정 보안을 위한 권장사항에 대해 알아보세요.