서비스 계정 사용 권장사항

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

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

• 비밀번호가 없어 브라우저 기반 로그인에 사용할 수 없습니다.
• 서비스 계정은 Google Cloud 프로젝트에 속하는 리소스로 생성 및 관리됩니다. 반면 사용자는 Cloud ID 또는 Google Workspace 계정에서 관리됩니다.
• 서비스 계정은 Google Cloud에 한정됩니다. 반면 Cloud ID 또는 Google Workspace에서 관리되는 사용자는 여러 Google 제품 및 서비스에서 작동합니다.
• 서비스 계정은 리소스와 주 구성원 둘 다 가능합니다.
  • 주 구성원으로서 서비스 계정은 Cloud Storage 버킷과 같은 리소스에 대한 액세스 권한을 부여 받을 수 있습니다.
  • 리소스로서 서비스 계정에는 사용자 또는 그룹과 같은 다른 주 구성원이 액세스하거나 가장할 수 있습니다.

서비스 계정은 유용한 도구이지만 서비스 계정이 악용될 수 있는 몇 가지 방법이 있습니다.

• 권한 에스컬레이션: 악의적인 행위자가 서비스 계정을 가장하여 정상적으로는 액세스할 수 없는 리소스에 액세스할 수 있습니다.
• 스푸핑: 악의적인 행위자가 서비스 계정 가장을 사용하여 신원을 은폐할 수 있습니다.
• 부인 방지: 악의적인 행위자는 서비스 계정을 사용하여 자신을 대신하여 작업을 수행함으로써 자신의 ID 및 작업을 숨길 수 있습니다. 경우에 따라 이러한 행동을 악의적인 행위자로 추적하지 못할 수 있습니다.
• 정보 공개: 악의적인 행위자가 특정 서비스 계정의 존재로부터 인프라, 애플리케이션 또는 프로세스에 대한 정보를 추출할 수 있습니다.

서비스 계정을 보호하려면 이중적인 특성을 고려하세요.

• 서비스 계정은 주 구성원이므로, 침해된 서비스 계정으로 인해 발생할 수 있는 잠재적 위험을 줄이기 위해 권한을 제한해야 합니다.
• 서비스 계정은 리소스이므로 침해되지 않도록 보호해야 합니다.

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

언제 서비스 계정 사용할지 선택

모든 시나리오에서 Google Cloud 서비스에 액세스하기 위해 서비스 계정이 필요한 것은 아니며, 많은 시나리오에서는 서비스 계정 키를 사용하는 것보다 더 안전한 방법으로 인증할 수 있습니다. 가능하면 서비스 계정 키를 사용하지 않는 것이 좋습니다.

Google Cloud CLI, Cloud 클라이언트 라이브러리, Terraform 또는 REST 요청과 같이 애플리케이션 기본 사용자 인증 정보(ADC)를 지원하는 도구를 사용하여 Google Cloud 서비스에 액세스하는 경우 다음 다이어그램을 사용하여 인증 방법을 선택할 수 있습니다.

이 다이어그램에서는 다음 질문을 안내합니다.

1. 자체 워크스테이션, Cloud Shell 또는 가상 데스크톱 인터페이스와 같은 단일 사용자 개발 환경에서 코드를 실행하고 있나요?
   1. '예'라고 답한 경우 질문 4를 진행합니다.
   2. 그렇지 않은 경우 질문 2를 진행합니다.
2. Google Cloud에서 코드를 실행하고 있나요?
   1. '예'라고 답한 경우 질문 3을 진행합니다.
   2. 그렇지 않은 경우 질문 5를 진행합니다.
3. Google Kubernetes Engine 또는 GKE Enterprise에서 컨테이너를 실행 중인가요?
   1. '예'라고 답한 경우 GKE용 워크로드 아이덴티티 제휴를 사용하여 서비스 계정을 Kubernetes 포드에 연결합니다.
   2. 그렇지 않으면 리소스에 서비스 계정을 연결합니다.

4. 사용 사례에 서비스 계정이 필요한가요?

   예를 들어 모든 환경에서 애플리케이션에 대한 인증 및 승인을 일관되게 구성하려고 합니다.

   1. 그렇지 않으면 사용자 인증 정보로 인증합니다.
   2. '예'라고 답한 경우 사용자 인증 정보로 서비스 계정을 가장합니다.
5. 워크로드가 워크로드 아이덴티티 제휴를 지원하는 외부 ID 공급업체로 인증되나요?
   1. '예'라고 답한 경우 워크로드 아이덴티티 제휴를 구성하여 온프레미스 또는 다른 클라우드 제공업체에서 실행 중인 애플리케이션이 서비스 계정을 사용하도록 합니다.
   2. 그렇지 않으면 서비스 계정 키를 만듭니다.

서비스 계정 관리

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

리소스로 서비스 계정 관리

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

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

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

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

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

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

특히 App Engine 및 Compute Engine을 포함한 일부 Google Cloud 서비스는 기본적으로 프로젝트에 편집자 역할(roles/editor)이 있는 기본 서비스 계정을 만듭니다. Compute Engine 가상 머신(VM) 인스턴스와 같은 리소스를 만들고 서비스 계정을 지정하지 않으면 리소스에서 자동으로 기본 서비스 계정을 사용할 수 있습니다. 기본 서비스 계정을 사용하면 더 쉽게 자동으로 시작할 수 있지만 이러한 강력한 서비스 계정을 애플리케이션 여러 개에서 공유하는 것은 매우 위험합니다.

몇 가지 단계를 수행하면 이러한 복잡성을 막을 수 있습니다.

• 각 애플리케이션의 전용 서비스 계정을 만들고 기본 서비스 계정을 사용하지 않습니다.
• 기본 서비스 계정에 자동 역할 부여를 사용하지 마세요.
• Google의 도구를 사용하여 서비스 계정 사용량을 이해하면 사용량을 모니터링하고 여러 계정에서 서비스 계정이 공유되는 것을 막을 수 있습니다.

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

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

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

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

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

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

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

다양한 용도로 사용되거나 여러 리소스에서 공유되는 서비스 계정의 경우 서비스 계정이 계속 사용 중인지 여부를 식별하기가 더 어려울 수 있습니다. 이러한 경우 활동 분석기를 사용하면 서비스 계정의 최근 인증 활동을 볼 수 있습니다.

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

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

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

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

서비스 계정 권한 제한

서비스 계정은 주 구성원이며 일반 사용자 계정과 마찬가지로 리소스에 대한 액세스 권한을 부여받을 수 있습니다. 그러나 서비스 계정은 일반 사용자보다 더 많은 리소스에 액세스할 수 있는 경우가 많습니다. 또한 애플리케이션에 기능을 추가하면 서비스 계정이 시간이 지남에 따라 더 많은 액세스 권한을 얻는 경향이 있습니다. 더 이상 필요하지 않은 액세스 권한을 취소하지 않을 수도 있습니다.

기본 서비스 계정에 자동 역할 부여를 사용하지 않음

일부 Google Cloud 서비스는 Google Cloud 프로젝트에서 API를 처음으로 사용 설정할 때 기본 서비스 계정을 만듭니다. 기본적으로 이러한 서비스 계정에는 Google Cloud 프로젝트의 편집자 역할(roles/editor)이 부여되어 Google Cloud 프로젝트의 모든 리소스를 읽고 수정할 수 있습니다. 이 역할은 편의를 위해 부여되지만 서비스의 작동을 위해 꼭 필요하지 않습니다. Google Cloud 프로젝트의 리소스에 액세스하기 위해 Google Cloud 서비스는 기본 서비스 계정이 아니라 서비스 에이전트를 사용합니다.

기본 서비스 계정에 편집자 역할이 자동으로 부여되지 않도록 하려면 조직에 기본 서비스 계정에 대한 자동 IAM 부여 사용 중지(constraints/iam.automaticIamGrantsForDefaultServiceAccounts) 제약조건을 사용 설정합니다. 여러 Google Cloud 프로젝트에 제약조건을 적용하려면 폴더 또는 조직 노드에서 제약조건을 구성합니다. 제약조건을 적용하더라도 기존 기본 서비스 계정에서 편집자 역할이 삭제되지는 않습니다.

이 제약조건을 적용하면 새 프로젝트의 기본 서비스 계정이 Google Cloud 리소스에 액세스할 수 없습니다. 기본 서비스 계정이 리소스에 액세스할 수 있도록 적절한 역할을 부여해야 합니다.

VM 인스턴스에 서비스 계정을 연결할 때는 액세스 범위를 사용하지 않음

VM 인스턴스에 서비스 계정을 연결할 때 하나 이상의 액세스 범위를 지정할 수 있습니다. 액세스 범위를 사용하면 VM에서 액세스할 수 있는 서비스를 제한할 수 있습니다. 이러한 제한은 허용 정책에 추가로 적용됩니다.

액세스 범위는 대략적입니다. 예를 들어 https://www.googleapis.com/auth/devstorage.read_only 범위를 사용하면 Cloud Storage 읽기 전용 작업에 대한 액세스를 제한할 수 있지만 특정 버킷에 대한 액세스를 제한할 수는 없습니다. 따라서 액세스 범위는 세분화된 허용 정책에 적합한 대안이 아닙니다.

액세스 범위를 사용하는 대신 전용 서비스 계정을 만들고 세분화된 허용 정책을 사용하여 서비스 계정에서 액세스할 수 있는 리소스를 제한합니다.

서비스 계정에 리소스에 대한 액세스 권한을 부여하기 위해 그룹을 사용하지 않음

조직에서는 여러 직원이 유사하거나 중복된 직무를 수행하는 경우가 많기 때문에 리소스에 대한 비슷한 액세스가 요구됩니다. 그룹을 사용하면 이러한 유사성을 활용하여 관리 오버헤드를 줄일 수 있습니다.

서비스 계정은 애플리케이션에 의해 사용됩니다. 여러 애플리케이션이 동일한 기능을 수행하기 때문에 액세스 요구사항이 비슷하거나 동일한 경우는 거의 없습니다. 애플리케이션은 고유한 경우가 많으며 액세스가 필요한 리소스는 일반적으로 애플리케이션마다 다릅니다.

그룹을 사용하여 서비스 계정에 리소스에 대한 액세스 권한을 부여하면 몇 가지 잘못된 결과가 발생할 수 있습니다.

• 각 그룹에 서비스 계정이 하나 또는 일부만 포함된 그룹 급증
• 권한 추가: 그룹의 각 구성원은 리소스의 하위 집합에 대한 액세스만 필요로 하지만 시간이 지남에 따라 점점 더 많은 리소스에 대한 액세스 권한이 그룹에 부여됩니다.

그룹의 목적이 좁게 정의되지 않는 한 그룹을 사용하지 않는 것이 좋습니다. 대신 서비스 계정에 필요한 리소스에 대한 액세스 권한을 직접 부여합니다.

도메인 전체 위임 사용하지 않음

도메인 전체 위임은 서비스 계정이 Cloud ID 또는 Google Workspace 계정의 모든 사용자를 가장할 수 있도록 합니다. 도메인 전체 위임을 사용하면 서비스 계정이 Google Workspace 및 Cloud ID에서 특정 관리 작업을 수행하거나 Google Cloud 외부에서 서비스 계정을 지원하지 않는 Google API에 액세스할 수 있습니다.

도메인 전체 위임은 특정 사용자를 가장하기 위해 서비스 계정을 제한하지 않지만 최고 관리자를 포함한 Cloud ID 또는 Google Workspace 계정의 모든 사용자를 가장할 수 있도록 허용합니다. 따라서 서비스 계정이 도메인 전체 위임을 사용하도록 허용하면 서비스 계정이 권한 에스컬레이션 공격의 목표가 되기 쉽습니다.

서비스 계정으로 직접 또는 OAuth 동의 흐름을 사용하여 태스크를 처리할 수 있는 경우 도메인 전체 위임을 사용하지 마세요.

도메인 전체 위임을 사용할 수밖에 없는 경우 서비스 계정이 사용할 수 있는 OAuth 범위 집합을 제한하세요. OAuth 범위는 서비스 계정이 가장할 수 있는 사용자를 제한하지 않지만 서비스 계정에서 액세스할 수 있는 사용자 데이터 유형을 제한합니다.

사용자의 동의 없이 사용자 데이터에 액세스하기 위해 서비스 계정을 사용하지 않음

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

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

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

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

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

임시 권한 승격에 IAM Credentials API 사용

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

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

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

애플리케이션의 각 부분에서 필요한 리소스에만 액세스할 수 있도록 하려면 임시 권한 승격에 IAM Credentials API를 사용하세요.

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

단기 사용자 인증 정보를 만드는 데 도움이 필요한 경우 서비스 계정에 단기 사용자 인증 정보 만들기를 참조하세요.

사용자 인증 정보 액세스 경계를 사용하여 액세스 토큰 권한 축소

Google 액세스 토큰은 Bearer 토큰이며 특정 애플리케이션에 한정되지 않고 사용할 수 있습니다. 내 애플리케이션이 액세스 토큰을 다른 애플리케이션에 전달하면 다른 애플리케이션 또한 내 애플리케이션과 같은 방식으로 토큰을 사용할 수 있습니다. 마찬가지로, 액세스 토큰이 악의적인 사용자에게 유출되는 경우 이러한 사용자 역시 토큰을 사용하여 액세스 권한을 얻을 수 있습니다.

액세스 토큰은 Bearer 토큰이므로 승인되지 않은 당사자에게 유출되거나 표시되지 않도록 보호해야 합니다. 액세스 권한이 부여되는 리소스를 제한하여 유출된 액세스 토큰에 의해 발생할 수 있는 잠재적인 피해를 제한할 수 있습니다. 이 과정을 줄이기(downscoping)라고 합니다.

사용자 인증 정보 경계를 사용하여 다른 애플리케이션이나 애플리케이션의 다른 구성요소로 액세스 토큰을 전달할 때마다 액세스 토큰을 축소할 수 있습니다. 토큰이 필요한 리소스에 대해 적당한 범위를 벗어나지 않는 액세스 권한을 부여하도록 필요한 액세스 경계를 설정합니다.

역할 권장사항을 사용하여 사용하지 않는 권한 식별

애플리케이션을 처음 배포할 때 애플리케이션에 실제로 어떤 역할과 권한이 필요한지 확실하지 않을 수 있습니다. 따라서 애플리케이션 서비스 계정에 필요한 추가 권한을 부여할 수 있습니다.

마찬가지로 애플리케이션의 액세스 요구사항이 시간이 지남에 따라 증가할 수 있으며, 처음에 부여한 역할과 권한의 일부는 필요 없어질 수 있습니다.

역할 권장사항을 사용하여 애플리케이션에서 실제로 사용 중인 권한과 사용하지 않을 수 있는 권한을 식별합니다. 애플리케이션이 실제로 필요한 것보다 많은 액세스 권한을 부여받지 않도록 영향을 받는 리소스의 허용 정책을 조정합니다.

측면 이동 통계를 사용하여 측면 이동 제한

측면 이동은 한 프로젝트의 서비스 계정에 다른 프로젝트의 서비스 계정을 가장할 수 있는 권한이 있는 경우입니다. 예를 들어 프로젝트 A에서 만든 서비스 계정이 프로젝트 B의 서비스 계정을 가장할 수 있는 권한을 보유할 수 있습니다.

이러한 권한은 주 구성원에 의도하지 않은 리소스 액세스 권한을 부여하는 프로젝트 간의 일련의 가장을 일으킬 수 있습니다. 예를 들어 주 구성원은 프로젝트 A에서 서비스 계정을 가장한 후 이 서비스 계정을 사용해서 프로젝트 B의 서비스 계정을 가장할 수 있습니다. 프로젝트 B의 서비스 계정에 조직 내 다른 프로젝트의 다른 서비스 계정을 가장할 수 있는 권한이 있으면 주 구성원이 계속해서 서비스 계정 가장을 사용하여 프로젝트 간에 이동하며 권한을 계속 얻을 수 있습니다.

추천자는 이 문제의 해결을 돕기 위해 측면 이동 통계를 제공합니다. 측면 이동 통계는 한 프로젝트의 서비스 계정이 다른 프로젝트의 서비스 계정을 가장하도록 허용하는 역할을 식별합니다. 측면 이동 통계를 직접 보고 관리하는 방법을 알아보려면 측면 이동 통계 관리를 참조하세요.

일부 측면 이동 통계는 역할 권장사항과 관련됩니다. 이러한 권장사항을 적용하여 프로젝트 간 측면 이동을 줄일 수 있습니다. 자세한 내용은 권장사항 검토 및 적용을 참조하세요.

권한 에스컬레이션 위협으로부터 보호

아무런 역할도 부여되지 않았고 어떤 리소스에도 액세스할 수 없으며 방화벽 규칙과 연결되지 않은 서비스 계정은 일반적으로 값이 제한되어 있습니다. 서비스 계정에 리소스에 대한 액세스 권한을 부여하면 서비스 계정의 값이 증가합니다. 서비스 계정은 사용자에게 더 유용한 역할을 하지만 쉽게 권한 에스컬레이션 공격의 대상이 되기도 합니다.

예를 들어 민감한 정보가 포함된 Cloud Storage 버킷에 대한 전체 액세스 권한이 있는 서비스 계정을 가정해 보겠습니다. 이 경우 서비스 계정은 Cloud Storage 버킷 자체만큼 유용합니다. 악의적인 사용자는 버킷에 직접 액세스하는 대신 서비스 계정을 제어하려고 시도할 수 있습니다. 이러한 시도가 성공하면 악의적인 사용자가 서비스 계정을 가장하여 해당 권한을 에스컬레이션할 수 있으며, 이를 통해 버킷의 민감한 정보에 액세스할 수 있습니다.

서비스 계정과 관련된 권한 에스컬레이션 기술은 일반적으로 다음과 같은 카테고리로 분류됩니다.

• 서비스 계정으로 인증: 실수로 서비스 계정을 가장하거나 서비스 계정 키를 만들 수 있는 권한을 부여할 수 있습니다. 서비스 계정이 사용자 자체보다 많은 권한을 부여받은 경우 사용자가 서비스 계정으로 인증해서 권한을 승격하고 원래 액세스할 수 없었던 리소스에 액세스할 수 있습니다.

• 연결된 서비스 계정이 있는 리소스 사용: 서비스 계정이 연결된 CI/CD 파이프라인, VM 인스턴스, 기타 자동화 시스템을 액세스하고 수정할 수 있는 권한이 사용자에게 있으면 이러한 리소스의 연결된 서비스 계정을 사용해서 작업을 수행할 수 있습니다. 따라서 서비스 계정 가장 권한이 없더라도 서비스 계정의 권한을 사용해서 원래 수행할 수 없었던 작업을 수행할 수 있습니다.

  예를 들어 사용자에게 Compute Engine VM 인스턴스에 대한 SSH 액세스 권한이 있으면 인스턴스에서 코드를 실행하여 인스턴스의 연결된 서비스 계정이 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다.

• 허용 정책, 그룹 또는 커스텀 역할 수정: 권한이 있는 서비스 계정에 대한 액세스 권한이 없는 사용자도 서비스 계정, 바깥쪽 Google Cloud 프로젝트 또는 폴더의 허용 정책을 수정할 권한이 있을 수 있습니다. 그러면 사용자는 이러한 허용 정책 중 하나를 확장하여 서비스 계정에 대해 직접 또는 간접적으로 인증할 수 있는 권한을 부여할 수 있습니다.

다음 섹션에서는 권한 에스컬레이션 위협으로부터 서비스 계정을 보호하기 위한 권장사항을 제공합니다.

사용자가 사용자 자신보다 권한이 더 높은 서비스 계정으로 인증하는 것을 허용하지 않음

서비스 계정을 가장하면 사용자는 서비스 계정에서 액세스할 수 있는 일부 또는 모든 리소스에 액세스할 수 있습니다. 서비스 계정이 사용자보다 더 광범위한 액세스를 가진 경우 사실상 사용자보다 더 많은 권한을 갖게 됩니다.

사용자에게 권한이 더 많은 서비스 계정으로 가장할 수 있는 권한이 부여되면 Linux에서 sudo 도구를 사용하거나 Windows에서 프로세스 승격을 사용하는 것과 같이 사용자가 일시적으로 권한을 승격할 수 있습니다. 이러한 일시적인 권한 승격이 필요한 상황이 아니라면 사용자가 권한이 더 많은 서비스 계정을 가장하지 않도록 하는 것이 가장 좋습니다.

또한 사용자가 리소스에 연결하고 이 리소스에서 코드를 실행하여 서비스 계정의 권한을 간접적으로 획득할 수 있습니다. 이 방식으로 코드를 실행하는 것은 인증된 ID가 하나만 포함되기 때문에(서비스 계정) 서비스 계정 가장이 아닙니다. 하지만 다른 방법으로는 얻을 수 없는 액세스 권한을 사용자에게 부여할 수 있습니다.

사용자가 서비스 계정을 가장하거나 서비스 계정을 리소스에 연결할 수 있게 해주는 권한에는 다음이 포함됩니다.

• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.actAs
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• iam.serviceAccountKeys.create
• deploymentmanager.deployments.create
• cloudbuild.builds.create

이러한 권한 중 일부를 포함하는 역할은 다음과 같습니다(이에 국한되지 않음).

• 소유자(roles/owner)
• 편집자(roles/editor)
• 서비스 계정 사용자(roles/iam.serviceAccountUser)
• 서비스 계정 토큰 생성자(roles/iam.serviceAccountTokenCreator)
• 서비스 계정 키 관리자(roles/iam.serviceAccountKeyAdmin)
• 서비스 계정 관리자(roles/iam.serviceAccountAdmin)
• 워크로드 아이덴티티 사용자(roles/iam.workloadIdentityUser)
• Deployment Manager 편집자(roles/deploymentmanager.editor)
• Cloud Build 편집자(roles/cloudbuild.builds.editor)

사용자에게 역할을 할당하기 전에 먼저 다음과 같이 자문해 보세요.

• 현재 Google Cloud 프로젝트 내부 및 외부 리소스 중 사용자가 서비스 계정을 가장하여 액세스할 수 있는 리소스는 무엇인가요?
• 이러한 액세스 수준은 정당한가요?
• 사용자가 서비스 계정을 가장할 수 있는 상황을 관리할 충분한 보호 조치가 있나요?

모든 질문에 확실히 답할 수 없는 경우 역할을 할당하지 마세요. 대신 사용자에게 권한이 낮은 다른 서비스 계정을 부여하는 것이 좋습니다.

사용자가 권한이 더 높은 서비스 계정의 허용 정책을 변경하는 것을 허용하지 않음

서비스 계정을 사용하거나 가장할 수 있는 사용자는 서비스 계정의 허용 정책에 의해 캡처됩니다. 허용 정책은 특정 서비스 계정에서 iam.serviceAccounts.setIamPolicy 권한을 가진 사용자가 수정하거나 확장할 수 있습니다. 이러한 권한을 포함하는 역할은 다음과 같습니다.

• 소유자(roles/owner)
• 보안 관리자(roles/iam.securityAdmin)
• 서비스 계정 관리자(roles/iam.serviceAccountAdmin)

iam.serviceAccounts.setIamPolicy 권한이 포함된 역할은 사용자에게 서비스 계정에 대한 완전한 제어 권한을 부여합니다.

• 사용자는 서비스 계정을 가장할 수 있는 권한을 자신에게 부여할 수 있으며, 이를 통해 사용자는 서비스 계정과 동일한 리소스에 액세스할 수 있습니다.
• 사용자는 다른 사용자에게 서비스 계정에 대해 동일하거나 유사한 수준의 액세스 권한을 부여할 수 있습니다.

이러한 역할을 사용자에게 할당하려면 먼저 사용자가 서비스 계정을 가장하여 현재 Google Cloud 프로젝트 내부 및 외부에서 어떤 리소스에 액세스할 수 있는지 확인하세요. 서비스 계정이 사용자보다 더 많은 권한을 가진 경우 사용자가 서비스 계정의 허용 정책을 변경하도록 허용하지 마세요.

사용자가 서비스 계정 키를 만들거나 업로드하도록 허용하지 않음

애플리케이션 또는 사용자가 서비스 계정 키를 사용하여 서비스 계정으로 인증할 수 있습니다. 다른 형태의 서비스 계정 가장과는 달리 서비스 계정 키를 사용할 때는 이전과 같은 인증이 필요하지 않습니다. 즉, 서비스 계정 키를 소유한 사람이 이를 사용할 수 있습니다.

인증을 위해 서비스 계정 키를 사용할 때의 순 효과는 서비스 계정 가장의 효과와 비슷합니다. 사용자에게 서비스 계정 키에 대한 액세스 권한이 있거나 새 서비스 계정 키를 만들 수 있는 권한을 부여할 경우에는 사용자가 서비스 계정으로 인증을 수행하고 해당 서비스 계정으로 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다.

서비스 계정 키를 생성 또는 업로드하기 위해서는 iam.serviceAccountKeys.create 권한이 필요하며 이 권한은 서비스 계정 키 관리자(roles/iam.serviceAccountKeyAdmin) 및 편집자(roles/editor) 역할을 포함합니다.

iam.serviceAccountKeys.create 권한이 포함된 역할을 사용자에게 할당하려면 먼저 사용자가 서비스 계정을 가장하여 현재 Google Cloud 프로젝트 내부 및 외부에서 어떤 리소스에 액세스할 수 있는지 확인하세요. 사용자가 권한이 더 많은 서비스 계정에 대한 서비스 계정 키를 만들도록 허용하지 마세요.

Google Cloud 프로젝트에 서비스 계정 키가 전혀 필요하지 않은 경우 Google Cloud 프로젝트 또는 바깥쪽 폴더에 서비스 계정 키 생성 사용 중지 및 서비스 계정 키 업로드 사용 중지 조직 정책 제약조건을 적용합니다. 이러한 제약조건을 통해 모든 사용자가 서비스 계정에 대한 iam.serviceAccountKeys.create 권한이 포함된 서비스 계정 키를 만들고 업로드할 수 없습니다.

Google Cloud 프로젝트 또는 폴더 수준에서 서비스 계정에 액세스 권한을 부여하지 않음

서비스 계정은 리소스이자 리소스 계층 구조의 일부입니다. 따라서 다음 수준으로 서비스 계정에 대한 액세스 권한을 관리할 수 있습니다.

• 개별 서비스 계정
• 바깥쪽 Google Cloud 프로젝트
• Google Cloud 프로젝트의 상위 항목 폴더
• 조직 노드

Google Cloud 프로젝트 수준 또는 리소스 계층 구조의 더 높은 수준에서 액세스 권한을 관리하면 관리 오버헤드를 줄이는 데 도움이 될 수 있지만, 권한이 과도하게 부여될 수 있습니다. 예를 들어 사용자에게 Google Cloud 프로젝트의 서비스 계정 토큰 생성자 역할을 부여하면 사용자는 Google Cloud 프로젝트의 모든 서비스 계정을 가장할 수 있습니다. 서비스 계정을 가장할 수 있는 경우 사용자가 Google Cloud 프로젝트 외부의 리소스를 포함해 해당 서비스 계정으로 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다.

이러한 과도한 권한 부여를 방지하려면 Google Cloud 프로젝트 또는 폴더 수준에서 서비스 계정에 대한 액세스를 관리하지 마세요. 대신 각 서비스 계정의 액세스 권한을 개별적으로 관리하세요.

권한이 있는 서비스 계정이 연결된 컴퓨팅 리소스에서 보안 수준이 낮은 소스의 코드를 실행하지 않음

VM 인스턴스나 Cloud Run 애플리케이션과 같은 컴퓨팅 리소스에 서비스 계정을 연결하면 해당 리소스에서 실행 중인 프로세스가 메타데이터 서버를 사용하여 액세스 토큰 및 ID 토큰을 요청할 수 있습니다. 이러한 토큰을 사용하면 프로세스가 서비스 계정으로 인증을 수행하고 대신 리소스에 액세스할 수 있습니다.

기본적으로 메타데이터 서버에 대한 액세스는 특정 프로세스 또는 사용자로 제한되지 않습니다. 대신 컴퓨팅 리소스에서 실행되는 모든 코드는 메타데이터 서버에 액세스하여 액세스 토큰을 얻을 수 있습니다. 이러한 코드에는 다음이 포함될 수 있습니다.

• 애플리케이션의 코드.
• 애플리케이션이 서버 측 스크립트 평가를 허용하는 경우 최종 사용자가 제출한 코드.
• 컴퓨팅 리소스가 CI/CD 시스템의 일부인 경우 원격 소스 저장소에서 읽히는 코드.
• Cloud Storage 버킷에서 제공하는 시작 및 종료 스크립트.
• VM Manager가 배포한 게스트 정책.

사용자가 코드를 제출하거나 원격 스토리지 위치에서 코드를 읽는 경우, 코드가 신뢰할 수 있고 원격 스토리지 위치의 보안이 연결된 서비스 계정만큼 철저한지 확인해야 합니다. 원격 스토리지 위치가 서비스 계정보다 덜 안전한 경우 악의적인 사용자가 자신의 권한을 에스컬레이션할 수 있습니다. 서비스 계정의 권한을 사용하는 악성 코드를 해당 위치에 삽입하여 이를 수행합니다.

권한이 있는 서비스 계정이 연결된 VM에 대한 셸 액세스 제한

일부 컴퓨팅 리소스는 대화형 액세스를 지원하며 사용자가 시스템에 대한 셸 액세스 권한을 얻을 수 있도록 합니다. 예를 들면 다음과 같습니다.

• Compute Engine을 통해 SSH 또는 RDP를 사용하여 VM 인스턴스에 로그인할 수 있습니다.
• Google Kubernetes Engine을 통해 kubectl exec를 사용하여 명령어를 실행하거나 Kubernetes 컨테이너에서 셸을 시작할 수 있습니다.

VM 인스턴스에 권한이 있는 서비스 계정이 연결된 경우 시스템에 대해 셸 액세스 권한이 있는 모든 사용자가 서비스 계정으로 인증을 수행하고 리소스에 액세스할 수 있습니다. 사용자가 이러한 기능을 남용해 권한을 에스컬레이션하지 못하게 하려면 셸 액세스 권한의 보안이 연결된 서비스 계정만큼 철저한지 확인해야 합니다.

Linux 인스턴스의 경우 OS 로그인을 사용하여 연결된 서비스 계정에 대한 액세스보다 SSH 액세스를 더 제한적으로 적용할 수 있습니다. OS 로그인이 사용 설정된 VM 인스턴스에 연결하려면 사용자는 OS 로그인을 사용하도록 허용되어야 할 뿐만 아니라 연결된 서비스 계정에 대한 iam.serviceAccounts.actAs 권한도 있어야 합니다.

메타데이터 기반 키를 사용하는 VM 인스턴스나 Windows 인스턴스에는 동일한 수준의 액세스 제어가 적용되지 않습니다. 메타데이터에 SSH 키를 게시하거나 Windows 사용자 인증 정보를 요청하려면 VM 인스턴스의 메타데이터에 대한 액세스 권한과 연결된 서비스 계정에 대한 iam.serviceAccounts.actAs 권한이 필요합니다. 하지만 SSH 키가 게시되거나 Windows 사용자 인증 정보를 획득한 후에는 로그인 시 추가 IAM 권한 확인이 적용되지 않습니다.

마찬가지로 VM 인스턴스가 인증을 위해 커스텀 Linux 플러그인 가능한 인증 모듈을 사용하거나 Active Directory 도메인의 구성원인 경우 서비스 계정으로 인증을 수행할 권한이 없는 사용자가 로그인할 수 있습니다. 자세한 내용은 Google Cloud에서 Active Directory 실행 권장사항을 참조하세요.

특히 OS 로그인을 사용하지 않는 VM 인스턴스의 경우 IAP(Identity-Aware Proxy)를 통해 셸 액세스를 제한하는 것이 좋습니다. VM 인스턴스에 연결된 서비스 계정으로 인증을 수행하도록 허용되어야 하는 사용자에게 IAP 보안 터널 사용자 역할(roles/iap.tunnelResourceAccessor)만 부여합니다.

선택된 사용자 및 프로세스에 대한 메타데이터 서버 액세스 제한

VM 인스턴스에 서비스 계정을 연결하면 VM에 배포된 워크로드가 메타데이터 서버에 액세스하여 서비스 계정의 토큰을 요청할 수 있습니다. 기본적으로 메타데이터 서버에 대한 액세스는 VM의 특정 프로세스 또는 사용자로 제한되지 않습니다. Linux의 nobody와 Windows의 LocalService 같이 권한이 낮은 사용자로 실행되는 프로세스도 메타데이터 서버에 대한 전체 액세스 권한을 가지며 서비스 계정의 토큰을 얻을 수 있습니다.

메타데이터 서버 액세스를 특정 사용자로 제한하려면 게스트 운영체제의 호스트 방화벽을 구성하여 이러한 사용자만 메타데이터 서버에 대한 아웃바운드 연결을 열 수 있도록 해야 합니다.

Linux에서는 --uid-owner 및 --gid-owner 옵션을 사용하여 특정 사용자 또는 그룹에만 적용되는 iptables 규칙을 설정할 수 있습니다. Windows에서는 Set-NetFirewallSecurityFilter 명령어를 사용하면 선택한 사용자 또는 그룹에 적용되도록 방화벽 규칙을 맞춤설정할 수 있습니다.

정보 공개 위협으로부터 보호

서비스 계정 이메일 주소에 기밀 정보를 공개하지 않음

서비스 계정에 다른 Google Cloud 프로젝트의 리소스에 대한 액세스 권한을 부여하려면 리소스의 허용 정책에 역할 결합을 추가하면 됩니다. 허용 정책은 리소스 자체와 마찬가지로 다른 Google Cloud 프로젝트의 일부이며 다른 Google Cloud 프로젝트에서 공개 상태가 제어됩니다.

허용 정책 보기는 일반적으로 권한 작업으로 간주되지 않습니다. 대부분의 역할에는 기본 뷰어 역할을 비롯해 필요한 *.getIamPolicy 권한이 포함됩니다.

허용 정책을 볼 수 있는 사용자는 리소스 액세스가 부여된 주 구성원의 이메일 주소도 볼 수 있습니다. 서비스 계정의 경우 이메일 주소는 악의적인 사용자에게 힌트를 제공할 수 있습니다.

예를 들어 허용 정책에는 이메일 주소 [email protected]이 있는 서비스 계정의 binding이 포함될 수 있습니다. 악의적인 행위자에게 이 이메일 주소는 ID가 deployment-project-123인 Google Cloud 프로젝트가 있음을 알려줄 뿐만 아니라 Google Cloud 프로젝트에서 Jenkins 서버를 실행한다는 것을 나타냅니다. [email protected]과 같이 일반적인 이름을 선택하면 deployment-project-123에서 실행 중인 소프트웨어 유형에 대한 정보가 공개되지 않습니다.

샌드박스 또는 개발 Google Cloud 프로젝트 등 액세스 권한이 덜 엄격하게 제어되는 Google Cloud 프로젝트의 리소스에 대한 액세스 권한을 서비스 계정에 부여할 경우 서비스 계정의 이메일 주소가 모든 정보를 공개하지 않도록 해야 합니다. 특히 기밀이거나 공격자에게 힌트를 제공할 수 있는 정보를 공개하면 안 됩니다.

부인 방지 위협으로부터 보호

Google Cloud의 리소스 중 하나에 영향을 미치는 의심스러운 활동이 감지되었을 때, Cloud 감사 로그는 활동이 언제 발생했는지, 어떤 사용자가 관련되었는지를 확인하는 데 중요한 정보 소스입니다.

Cloud 감사 로그에서 서비스 계정에 의해 활동이 발생했음을 나타내는 경우 이 정보만으로는 이벤트의 전체 체인을 재구성하는 데 충분하지 않을 수 있습니다. 서비스 계정에서 활동을 수행하게 만든 사용자 또는 애플리케이션을 찾을 수 있어야합니다.

이 섹션에는 거부할 수 없는 감사 추적을 유지하는 데 도움이 되는 권장사항을 제공합니다.

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

더 안전한 인증 방법을 사용할 수 없으면 애플리케이션의 서비스 계정 키를 만들어야 할 수 있습니다. 하지만 서비스 계정 키로 인증하면 부인 방지 위협이 발생합니다. Cloud 감사 로그는 서비스 계정이 리소스를 수정할 때 로그를 만들지만 서비스 계정이 서비스 계정 키로 인증되면 키를 누가 사용했는지 알 수 있는 방법이 없습니다. 반면에 사용자 인증 정보로 서비스 계정을 가장하여 서비스 계정으로 인증하면 서비스 계정 역할을 수행한 주 구성원이 로깅됩니다.

서비스 계정 키 생성 사용 중지 조직 정책 제약조건을 Google Cloud 프로젝트 또는 바깥쪽 폴더에 적용하여 서비스 계정 키 만들기를 방지하는 것이 좋습니다. 권장 대안으로 해결할 수 없는 시나리오에 서비스 계정 키를 사용해야 하는 경우 정책 제약조건에 대해 예외를 가능한 한 제한적으로 부여하고 서비스 계정 키 관리 권장사항을 검토하세요.

IAM API의 데이터 액세스 로그 사용 설정

서비스 계정 가장 시나리오를 식별하고 이해할 수 있도록 Compute Engine과 같은 서비스에는 Cloud 감사 로그에 serviceAccountDelegationInfo 섹션이 포함되어 있습니다. 이 섹션에서는 서비스 계정이 가장되고 있는지 여부와 어떤 사용자에 의해 가장되는지를 나타냅니다.

일부 서비스는 Cloud 감사 로그에서 가장에 대한 세부정보를 포함하지 않습니다. 가장 이벤트를 기록하려면 다음 API에 대한 데이터 액세스 로그도 사용 설정해야 합니다.

• 서비스 계정이 포함된 모든 Google Cloud 프로젝트의 Identity and Access Management(IAM) API
• 워크로드 아이덴티티 풀이 포함된 모든 Google Cloud 프로젝트의 Security Token Service API

이러한 로그를 사용 설정하면 사용자가 액세스 토큰 또는 서비스 계정의 ID 토큰을 요청할 때마다 Cloud 감사 로그에 항목이 추가됩니다.

CI/CD 기록이 Cloud 감사 로그와 상호 연결될 수 있는지 확인

서비스 계정은 일반적으로 코드 변경이 성공적으로 확인되고 배포가 승인된 후 CI/CD 시스템에서 배포를 수행하는 데 사용됩니다. 일반적으로 CI/CD 시스템은 배포로 이어지는 이벤트 기록을 유지합니다. 이 기록에는 해당 코드 검토, 커밋, 파이프라인 실행 ID 및 배포를 승인한 사람에 대한 정보가 포함될 수 있습니다.

배포에 의해 Google Cloud의 리소스가 수정되면 이러한 변경사항은 각 리소스의 Cloud 감사 로그에서 추적됩니다. Cloud 감사 로그에는 변경을 시작한 사용자 또는 서비스 계정에 대한 정보가 포함됩니다. 하지만 CI/CD 시스템에 의해 트리거된 배포에서는 서비스 계정 자체만으로 변경에 기여한 전체 체인을 재구성할 수 없는 경우가 많습니다.

CI/CD 시스템과 Google Cloud 전체에 일관된 감사 추적을 설정하려면 Cloud 감사 로그 기록이 CI/CD 시스템 기록의 이벤트와 상호 연관될 수 있는지 확인해야 합니다. Cloud 감사 로그에서 예기치 않은 이벤트가 발생하면 이 상관관계를 사용하여 변경사항이 CI/CD 시스템에서 실제로 수행되었는지 여부, 수행된 이유 및 승인한 사람을 확인할 수 있습니다.

Cloud 감사 로그 레코드와 CI/CD 시스템 기록 간의 상관관계를 설정하는 방법은 다음과 같습니다.

• 각 CI/CD 파이프라인에서 실행된 API를 로깅합니다.
• API가 작업 ID를 반환할 때마다 CI/CD 시스템 로그에 ID를 기록합니다.

• X-Goog-Request-Reason HTTP 헤더를 API 요청에 추가하고 CI/CD 파이프라인 실행 ID를 전달합니다. 요청 이유를 지정하는 경우 Terraform에서 이 헤더를 자동으로 추가할 수 있습니다.

  또는 Cloud 감사 로그에 캡처되도록 User-Agent 헤더에 정보를 삽입합니다.

거부되지 않도록 하려면 로그 파일을 구성하고 기록을 커밋하여 악의적인 행위자가 추적을 소급하여 숨길 수 없도록 합니다.

애플리케이션 개별 사용자의 커스텀 로그 항목 만들기

서비스 계정은 사용자가 커스텀 인증 체계로 인증한 다음 Google Cloud 리소스에 간접적으로 액세스하는 애플리케이션에도 유용합니다. 이러한 애플리케이션에서 사용자가 인증 및 승인되었는지 확인한 후 서비스 계정을 사용하여 Google Cloud 서비스에 인증하고 리소스에 액세스할 수 있습니다. 하지만 Cloud 감사 로그는 애플리케이션을 사용한 사용자가 아니라 리소스에 액세스한 서비스 계정을 로깅합니다.

이러한 액세스를 사용자로 역추적하기 위해 사용자가 리소스에 액세스할 때마다 커스텀 로그 항목을 작성하고 커스텀 로그 항목과 Cloud 감사 로그의 상관관계를 파악하는 애플리케이션 로직을 설계합니다.

다음 단계

• 서비스 계정 키 관리 권장사항 이해하기
• 배포 파이프라인에서 서비스 계정을 사용하기 위한 권장사항 검토하기
• 워크로드 아이덴티티 제휴 사용 권장사항 알아보기