[GCP] 서비스 계정 (Service Account)

베하! 안녕하세요 BTC금쪽상담소의 BTC오은영 석사와 BTC금쪽이 입니다.

어느덧 2023년도 절반이 지나가고, 나무의 앵두가 무르익는 여름날이 깊어지고있습니다.

뜨거운 햇살에 많이 지치시겠지만, 항상 건강 유의하시고 선크림 꼭 바르세요~

 

자 그럼 본론으로 넘어와서, 이번 주도 유용한 정보를 여러분들께 공유 드리고자 합니다.

이번 시간에는 여러분들에게 GCP의 서비스 계정 (Service Account)에 대해 알려드릴려고 해요.

 

---

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

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

 

기본적으로 GCP 환경은 인증을 통한 API 호출을 수행하게 되는데, 이때의 인증은, 본인의 google 계정 및 클라우드 계정, ORG(조직) 도메인 계정등이 있습니다.하지만, 다음과 같은 형태의 계정들은, 사용자가 직접적으로 ID와 PW를 통한 로그인이 가능하며, 사용자의 이벤트 발생에 따른 API 호출로 클라우드의 서비스를 사용하고, 역할을 수행하게 됩니다.

 

서비스 계정은 GCP내부의 리소스 또는 애플리케이션이 사용하는 특별한 계정으로써, 로그인이 되지 않고 해당 리소스의 권한 및 인증을 위해서 사용되는 특수한 이메일 형태의 계정입니다.

 

1. 서비스 계정 유형

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

• 사용자 관리 서비스 계정: 사용자가 만들고 관리하는 서비스 계정입니다. 이러한 서비스 계정은 종종 워크로드의 ID로 사용됩니다.
• 기본 서비스 계정: 사용자 관리 서비스 계정이며, 특정 Google Cloud 서비스를 사용 설정할 때 자동으로 생성됩니다. 이러한 서비스 계정을 관리하는 것은 사용자의 책임입니다.
• Google 관리 서비스 계정: Google에서 만든 Google 관리 서비스 계정이며, 서비스가 사용자를 대신하여 리소스에 액세스하도록 허용합니다.

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

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

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

3. 서비스 계정 가장

사용자 또는 다른 서비스 계정과 같은 주 구성원이 서비스 계정으로 인증하는 데 단기 사용자 인증 정보를 사용할 때, 이를 서비스 계정으로 가장한다고 합니다. 가장을 통해 사용자는 서비스 계정이 갖는 역할을 일시적으로 가정할 수 있으므로 일반적으로 사용자에게 승격된 액세스 권한을 일시적으로 부여하는 데 사용됩니다.

주 구성원은 서비스 계정 가장을 사용하여 명령어를 서비스 계정으로 실행할 수 있습니다. 하지만 주 구성원은 서비스 계정 가장을 사용하여 Google Cloud 콘솔에 액세스할 수 없습니다.

주 구성원이 서비스 계정을 가장하는 동안 리소스에 액세스하면 대부분의 감사 로그에는 ID와 가장하려는 서비스 계정 ID가 모두 포함됩니다.

4. 서비스 계정 권한

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

그러나 서비스 계정은 리소스이기도 합니다. 즉, 다른 주 구성원이 서비스 계정을 생성, 관리, 가장할 수 있습니다. 예를 들어 사용자에게 서비스 계정에 대한 서비스 계정 사용자 역할(roles/iam.serviceAccountUser)을 부여할 수 있습니다. 그러면 사용자가 서비스 계정을 가장할 수 있습니다.

 

---

이러한 형태로 서비스 계정은 리소스의 권한을 부여하기 위해, 혹은 외부 ID가 해당 GCP 환경에 접근할때,

임시 인증을 위해 사용할 수 있습니다.

자 그렇다면 이렇게 서비스 계정을 다양하게 만들어 사용을 하다가,

삭제를 해야할 경우나 관리가 필요할 경우엔 어떻게 해야할까요?

 

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

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

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

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

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

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

서비스 계정 삭제

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

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

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

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

서비스 계정을 삭제하더라도 역할 바인딩은 바로 삭제되지 않습니다. 대신 역할 binding에 deleted: 프리픽스가 있는 서비스 계정이 나열됩니다.

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

 

---

서비스 어카운트를 통해서 GCP의 리소스에 개별적인 권한을 부여함으로 보안을 보다 강화시킬 수 있습니다.

이를 통해 더욱 더 안전한 클라우드 사용이 가능합니다!!

 

늘 모두가 안전한 클라우드를 사용할 수 있도록 기원하며

이번 주 정보 공유를 마치겠습니다.

베빠~~~~~!!!

출처 : https://cloud.google.com/iam/docs/service-account-overview?hl=ko#service-account-permissions