서비스 계정 키 관리 권장사항

사용자 계정과 달리 서비스 계정은 비밀번호가 없습니다. 대신 서비스 계정은 인증에 RSA 키 쌍을 사용합니다. 서비스 계정의 키 쌍의 비공개 키를 알고 있으면 비공개 키를 사용하여 JWT Bearer 토큰을 만들고 Bearer 토큰을 사용하여 액세스 토큰을 요청할 수 있습니다. 그 결과로 얻은 액세스 토큰에는 서비스 계정의 ID가 반영되고, 이를 사용해서 서비스 계정을 대신해서Google Cloud API와 상호작용할 수 있습니다.

비공개 키를 사용하면 서비스 계정으로 인증할 수 있으므로 비공개 키에 대한 액세스 권한은 사용자 비밀번호를 알고 있는 것과 유사합니다. 비공개 키를 서비스 계정 키라고 합니다. 서비스 계정에서 사용하는 키 쌍은 Google 관리와 사용자 관리형 등 두 가지 범주로 구분됩니다.

신중하게 관리되지 않으면 서비스 계정 키가 보안 위험이 될 수 있습니다. 가능하면 보다 안전한 인증 대안을 선택해야 합니다. 서비스 계정 키와 관련된 주요 위협은 다음과 같습니다.

• 사용자 인증 정보 유출: 서비스 계정 키가 잘못되어 원래 의도하지 않은 장소에 저장될 수 있습니다. 악의적인 행위자가 유출된 서비스 계정 키를 사용해서 인증을 수행하고 사용자 환경에서 공격 기반을 마련할 수 있습니다.
• 권한 에스컬레이션: 악의적인 행위자가 안전하지 않은 서비스 계정 키에 액세스하게 되면 이 키를 사용하여 권한을 에스컬레이션할 수 있습니다.
• 정보 공개: 서비스 계정 키로 인해 잘못해서 기밀 메타데이터가 공개될 수 있습니다.
• 부인 방지: 서비스 계정 키를 사용하여 인증하고 서비스 계정이 사용자를 대신하여 작업을 수행할 수 있도록 하면 악의적인 행위자가 해당 ID 및 작업을 숨길 수 있습니다.
• 악의적인 사용자 인증 정보 구성: 악의적인 행위자가 보안 방어 수단을 우회하기 위해 악의적인 사용자 인증 정보 구성을 제공할 수 있습니다.

이러한 위협을 완화하는 가장 좋은 방법은 가능하면 사용자 관리 서비스 계정 키를 사용하지 않고 서비스 계정을 인증하는 다른 방법을 사용하는 것입니다. 또한 IAM 조건 및 VPC 서비스 제어를 사용하여 침해된 서비스 계정으로 액세스할 수 있는 잠재적 리소스를 제한할 수 있습니다.

서비스 계정 키에 대해 보다 안전한 대안을 사용할 수 없는 경우에 이 가이드에서는 서비스 계정 키 관리, 사용, 보호를 위한 권장사항을 설명합니다.

사용자 인증 정보 유출 방지

사용자 이름 및 비밀번호와 마찬가지로 서비스 계정 키도 한 가지 형태의 사용자 인증 정보입니다. 사용자가 유효한 서비스 계정 키에 액세스할 수 있으면 이를 사용해서 인증을 수행하고 해당 서비스 계정에 액세스 권한이 부여된 리소스에 액세스할 수 있습니다.

악의적인 행위자에게 서비스 계정 키는 유출된 비밀번호보다 더 유용할 수 있습니다. 유출된 비밀번호를 사용하여 로그인을 시도하는 것은 사용자 계정이 2단계 인증과 본인 확인 요청을 사용하도록 구성된 경우 성공할 가능성이 낮습니다. 반면에, 서비스 계정에는 추가적인 로그인 인증을 거치지 않으므로 유출된 서비스 계정 키를 사용하여 인증하는 것이 성공할 가능성이 높습니다.

악의적인 행위자가 다음과 같은 다양한 위치에서 서비스 계정 키를 찾아 낼 수 있습니다.

• 오픈소스 프로젝트의 소스 코드 저장소
• 공개 Cloud Storage 버킷
• 위반된 서비스의 공개 데이터 덤프

악의적인 행위자는 공개 위치 외에도 도용된 비공개 위치에서 서비스 계정 키를 찾을 수 있습니다. 예를 들면 다음과 같습니다.

• 이메일 받은편지함
• 파일 공유
• 백업 스토리지
• 임시 파일 시스템 디렉터리

서비스 계정 키 유출 위험을 낮추는 한 가지 효과적인 방법은 순환되는 키 수를 줄이고 새로운 키 생성을 억제하는 것입니다. 다음 섹션에서는 순환되는 서비스 계정 키 개수를 제한하는 방법과 서비스 계정 유출 위험을 줄이는 데 도움이 되는 기타 방법들을 설명합니다.

서비스 계정 키 만들기에 대한 대안 제공

조직의 사용자가 대안을 알고 있고 추가 위험과 관리 오버헤드에도 불구하고 서비스 계정 키를 사용해야 하는 근거가 있는지 확인합니다.

• 개발자에게 서비스 계정 키의 보다 안전한 대안을 교육합니다.
• 새 서비스 계정 키를 만들기 전 개발자가 사용 사례에 적합한 인증 방법을 결정하는 데 도움이 되는 프로세스를 설정합니다.
• 조직 정책 제약조건을 사용하여 새 서비스 계정 키를 만들지 못하도록 방지하고 보다 안전한 대안을 사용할 수 없음이 입증된 프로젝트에 대해서만 예외를 허용합니다.

조직 정책 제약조건을 사용하여 서비스 계정 키를 만들 수 있는 프로젝트 제한

서비스 계정 키에 대한 보다 안전한 대안이 있으면 정식 방침이 아닌 예외적으로 서비스 계정 키 사용을 고려하는 것이 좋습니다.

불필요한 서비스 계정 키 사용을 방지하려면 조직 정책 제약 조건을 사용합니다.

• 조직의 리소스 계층 구조의 루트에서 서비스 계정 키 생성 사용 중지 및 서비스 계정 키 업로드 사용 중지 제약조건을 사용하여 서비스 계정 키가 허용되지 않는 기본값을 설정할 수 있습니다.

• 필요한 경우에는 선택한 프로젝트의 제약조건 중 하나를 재정의해서 서비스 계정 키 만들기 또는 업로드를 다시 사용 설정합니다.

조직 정책 제약 조건을 수정하려면 orgpolicy.policy.set 권한이 필요합니다. 소유자(roles/owner) 또는 편집자(roles/editor) 역할 어디에도 이 권한이 포함되지 않기 때문에 일부 주 구성원에게 프로젝트에 대한 소유자 또는 편집자 액세스 권한이 있을 수 있는 비프로덕션 환경에서도 제약조건이 효과적일 수 있습니다.

임시 위치에 서비스 계정 키를 남겨두면 안 됨

Google Cloud 콘솔을 사용하여 서비스 계정 키를 만들 때 대부분의 브라우저는 새 키를 즉시 다운로드하고 컴퓨터의 다운로드 폴더에 저장합니다. 이 키를 보관하려는 위치로 즉시 이동해야 합니다. 다운로드 폴더 또는 컴퓨터의 휴지통에 실수로 사본을 남겨두지 않았는지 확인하세요.

Google Cloud CLI를 사용하여 서비스 계정 키의 사본을 실수로 임시 위치에 남겨 두는 위험을 줄일 수 있습니다. gcloud iam service-accounts keys create 명령어를 사용하면 서비스 계정 키 파일을 필요한 위치에 바로 작성할 수 있습니다. 또한 대부분의 운영체제에서는 파일에 사용자만 액세스할 수 있도록 gcloud CLI에서 파일 권한을 자동으로 조정합니다.

사용자 간에 서비스 계정 키를 전달하면 안 됨

서비스 계정 키가 필요한 애플리케이션을 배포할 때 사용자에게 서비스 계정 키 자체를 만들기 위한 권한이 없을 수 있습니다. 대신 다른 사람에게 서비스 계정 키를 만들도록 요청해야 할 수 있습니다.

서비스 계정 키를 만들고 배포할 때 여러 사람이 필요한 상황에서는 편지함, 채팅 기록, 기타 위치에 키 사본이 남겨질 위험이 높습니다. 사용자 간에 정보 전달이 필요할 때마다 서비스 계정 키를 업로드하는 것이 더 안전할 수 있습니다.

1. 사용자가 애플리케이션을 배포할 때 대상 머신에서 RSA 2048비트 키 쌍을 사용하는 자체 서명된 인증서를 만듭니다. 인증서를 만들기 위해서는 openssl, certutil, New-SelfSignedCertificate, 기타 운영체제 도구를 사용할 수 있습니다.
2. 비공개 키를 대상 머신에 보관하면서 인증서 업로드 권한이 있는 사용자에게 인증서 파일을 전달합니다. 인증서를 전달할 때는 인증서가 대체되거나 손상되지 않는지 확인하지만 이를 기밀로 유지할 필요가 없습니다.
3. 서비스 계정 키 관리를 위해 필요한 권한이 있는 사용자로 인증서를 업로드하여 서비스 계정과 연결합니다.

이 프로세스를 따르면 비공개 키를 전달하지 않고 대신 사용자 간에 공개 정보만 교환할 수 있습니다.

소스 코드 저장소에 서비스 계정 키를 제출하면 안 됨

서비스 계정 키는 사용자 인증 정보이며 무단 액세스로부터 보호되어야 합니다. 서비스 계정 키를 소스 코드 저장소에 제출할 경우 승인되지 않은 사용자 및 악의적인 행위자들이 키에 액세스할 수 있는 위험이 증가합니다.

• 악의적인 행위자는 공개 소스 저장소의 소스 코드에서 유출된 키를 스캔할 수 있습니다.
• 이후에 사용자가 키를 먼저 확인하지 않고 비공개 소스 저장소를 공개 저장소로 전환할 수도 있습니다.
• 다른 팀 멤버가 소스 코드의 복사본을 자신의 워크스테이션에 저장할 수 있습니다.

서비스 계정 키를 사용하는 코드를 작할 때는 항상 키가 소스 저장소에 제출될 위험을 줄이기 위해 소스 코드와 서비스 계정 키를 분리해서 저장해야 합니다. 많은 경우에 개발 중 서비스 계정 키를 전혀 사용하지 않고 서비스 계정 키 대신 개인 사용자 인증 정보를 사용하면 이러한 위험을 더욱 줄일 수 있습니다.

또한 실수로 인한 서비스 계정 키 제출을 감지하도록 소스 제어 시스템을 설정합니다.

• Cloud Source Repositories를 사용하는 경우에는 비공개 키가 포함된 git 푸시 작업을 차단하고 사용자에게 알림을 표시하도록 키 감지를 사용 설정합니다.
• GitHub를 사용하는 경우에는 저장소에 대해 보안 비밀 스캔을 사용 설정합니다.
• Security Command Center 이상 감지를 사용하여 유출된 사용자 인증 정보에 대한 정보를 확인합니다.
• 소스 제어 관리 시스템이 자동 스캔을 지원하지 않는 경우 truffleHog와 같은 오픈소스 도구를 사용하여 보안 비밀의 소스 코드를 스캔하는데 이 때 커밋 전 후크를 사용하거나 지속적 통합 파이프라인에 단계를 추가하거나 이 두가지 모두를 사용합니다.

프로그램 바이너리에 서비스 계정 키를 삽입하면 안 됨

서비스 계정 키는 특정 패턴과 일치하는 문자열이며, 다른 파일 또는 바이너리에 삽입하더라도 식별될 수 있습니다. 악의적인 행위자가 바이너리에 액세스할 수 있으면 바이너리에 삽입된 서비스 계정 키를 추출할 수 있습니다.

서버 측 애플리케이션의 프로그램 바이너리가 아티팩트 저장소에 호스팅되거나 디버깅 목적으로 개발자 워크스테이션에 복사될 수 있습니다. 서비스 계정 키를 프로그램 바이너리와 구분하면 바이너리에 액세스할 수 있는 사용자가 암시적으로 서비스 계정 사용자 인증 정보에 액세스하지 못하도록 방지하는 데 도움이 됩니다.

• 도구, 데스크톱 프로그램, 모바일 앱과 같은 클라이언트 측 애플리케이션의 경우 서비스 계정을 사용하지 마세요. 대신 사용자가 자신의 고유 사용자 인증 정보로 인증하도록 허용합니다. 예를 들어 OAuth 동의 흐름을 사용할 수 있습니다.
• 서버 측 애플리케이션의 경우 서비스 계정 키를 바이너리에 삽입하지 마세요. 대신 키를 애플리케이션 바이너리와 구분해서 관리합니다.

측정항목을 사용하여 사용하지 않는 서비스 계정 키 식별

순환되는 유효한 서비스 계정 키 개수를 최소화하기 위해서는 더 이상 필요하지 않게 되었을 때 바로 키를 사용 중지하고, 더 이상 필요하지 않은 것이 확실할 때는 키를 삭제하는 것이 가장 좋습니다.

키가 아직 사용 중인지 확실하지 않으면 서비스 계정 통계 및 인증 측정항목으로 사용량을 확인할 수 있습니다.

• 서비스 계정 통계를 사용하면 이전 90일 동안 사용되지 않은 서비스 계정을 식별할 수 있습니다.
• 키 인증 이벤트 측정항목을 모니터링하면 서비스 계정 키가 마지막으로 사용된 시기와 서비스 계정을 인증하는 데 사용된 빈도를 확인할 수 있습니다.

서비스 계정이 Google Cloud 프로젝트에 속하기 때문에 각 프로젝트에 대해 개별적으로 통계 및 측정항목을 추적해야 합니다.

서비스 계정 키를 순환하여 유출된 키로 인한 보안 위험 감소

서비스 계정 키가 실수로 유출될 가능성을 줄일 수 있지만 이러한 위험 자체를 완전히 없애는 것은 어려울 수 있습니다.

키 순환은 기존 키를 새 키로 바꾼 다음 교체된 키를 무효화하는 프로세스입니다. 서비스 계정 키를 포함하여 관리하는 모든 키를 정기적으로 순환하는 것이 좋습니다.

서비스 계정 키를 순환하면 유출되거나 도난당한 키로 인한 위험을 줄일 수 있습니다. 키가 유출되면 악의적인 행위자가 키를 찾는 데 며칠 또는 몇 주가 걸릴 수 있습니다. 서비스 계정 키를 정기적으로 순환하면 악의적인 행위자가 키를 획득할 때까지 유출된 키가 무효화될 가능성이 높습니다.

서비스 계정 키를 순환하는 프로세스를 설정하면 서비스 계정 키가 손상된 것으로 의심되는 경우 빠르게 조치를 취할 수 있습니다.

공개 키/비공개 키 쌍을 직접 생성한 후 하드웨어 보안 모듈(HSM)에 비공개 키를 저장하고 공개 키를 Google Cloud에 업로드한 경우 정기적인 일정에 따라 키를 순환하지 않아도 될 수 있습니다. 대신 키가 손상되었다고 확신하면 키를 순환할 수 있습니다.

만료 시간을 사용하여 키 자동 만료 허용

기본적으로 IAM에서 만들고 다운로드하는 서비스 계정 키는 만료 시간이 없으며 삭제할 때까지 유효한 상태로 유지됩니다. 서비스 계정 키의 만료 시간을 설정하면 영구 사용자 인증 정보의 수명을 줄여 보안 위험을 억제할 수 있습니다. 그러나 만료 시간을 설정하면 키가 만료되었을 때 워크로드가 실패할 수 있는 경우와 같이 만료 시간 설정에 따른 다른 위험이 있습니다.

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

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

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

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

서비스 계정 키의 유효 기간을 제한하려면 프로젝트, 폴더, 조직에서 새로 생성되는 키에 만료 시간을 구성하면 됩니다. 기존 키에는 만료 시간이 적용되지 않습니다.

또는 서비스 계정 키를 업로드하고 X.509 인증서 파일에 유효 기간 날짜를 지정할 수 있습니다. 만료일이 지나면 인증에 키를 사용할 수 없습니다. 하지만 삭제할 때까지 서비스 계정에 연결된 상태로 유지됩니다.

조직 정책 제약조건을 사용하여 누출된 키 자동 사용 중지

서비스 계정 키의 모든 권장사항을 따르더라도 서비스 계정 키가 누출될 가능성이 있습니다.

누출된 사용자 인증 정보 관리를 돕기 위해서는 서비스 계정 키 누출 응답 제약조건이 DISABLE_KEY로 설정되었는지 확인합니다. 제약조건을 이 값으로 설정하면 Google Cloud이 감지된 모든 누출 키를 자동으로 사용 중지합니다.

키가 유출되어 사용 중지되었으면 키의 메타데이터에 다음 필드가 추가됩니다.

• "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": 키가 노출되어 사용 중지되었음을 나타냅니다.
• "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED": 키가 한 번 공개적으로 노출되었음을 나타냅니다. 이 값은 키를 다시 사용 설정해도 유지됩니다.
• "extended_status_message": "LINK_TO_EXPOSURE": 가능한 경우 메타데이터에는 문제 해결을 위해 사용할 수 있는 키가 감지된 위치에 대한 링크가 포함됩니다.

이러한 키는 중단 문제를 해결하는 데 필요한 경우 다시 사용 설정할 수 있습니다. 하지만 공개적으로 노출된 키는 최초의 노출 문제가 제거되었더라도 보안 문제를 일으킬 수 있기 때문에 가능한 한 빨리 키를 다시 사용 중지하는 것이 좋습니다.

손상된 사용자 인증 정보 관리를 위한 기타 권장사항을 보려면 손상된 사용자 인증 정보 처리 Google Cloud를 참조하세요.

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

키로 액세스할 수 있는 리소스보다 키 자체에 대한 보안 수준이 낮은 경우 서비스 계정 키를 사용하면 권한 에스컬레이션 공격에 노출될 수 있습니다.

예를 들어 악의적인 행위자가 환경에 이미 존재하면서 특정 Google Cloud 리소스에 액세스하려고 한다고 가정해 보겠습니다. 이러한 리소스에는 액세스할 수 있는 권한이 없을 수 있지만 VM, 파일 공유 또는 보안 수준이 덜 안전한 위치에 저장된 서비스 계정 키에 액세스하기에 충분한 권한일 수 있습니다. 서비스 계정 키를 사용하여 인증하면 악의적인 행위자가 서비스 계정의 ID를 사용할 수 있습니다. 서비스 계정은 악의적인 행위자가 이전에 액세스하지 못했던 리소스에 액세스하도록 허용하여 악의적인 행위자의 권한을 에스컬레이션할 수 있습니다.

서비스 계정 키는 Google Cloud의 리소스에 대한 액세스 권한을 간접적으로 부여하므로 키 자체가 리소스만큼 중요하고 보호 가치가 있다고 간주해야 합니다.

다음 섹션에서는 서비스 계정 키를 보호하고 무단 액세스 및 그로 인한 권한 에스컬레이션의 위험을 줄일 수 있는 권장사항을 설명합니다.

파일 시스템에 키 저장하지 않기

Google Cloud 콘솔 또는 gcloud CLI를 사용하여 생성된 서비스 계정 키는 JSON 파일이며, 필요한 머신의 파일 시스템에 이 파일을 복사할 수 있습니다. 하지만 서비스 계정 키를 파일 시스템에 파일로 저장하면 다음을 포함하여 여러 위험에 노출될 수 있습니다.

• NTFS와 같은 일부 파일 시스템은 기본적으로 상속된 권한을 사용합니다. 사용 중지되지 않는 한 상위 폴더에 추가된 권한으로 인해 의도치 않게 키 파일에 더 광범위하게 액세스하고 승인되지 않은 사용자가 볼 수 있습니다.
• 가상화된 환경에서 악의적인 행위자는 기본 가상 디스크에 액세스하여 파일 시스템 보안을 약화시킬 수 있습니다.
• 파일 시스템 액세스 및 권한 변경은 종종 감사 로그에 기록되지 않습니다. 파일 권한이 의도치 않게 변경되고 승인되지 않은 사용자가 키를 사용할 수 있게 되면 이러한 변경이 언제 누구에 의해 수행되었는지 분석하기 어려울 수 있습니다.
• 파일을 쉽게 복사할 수 있으므로 악의적인 행위자가 액세스 권한을 얻게 될 경우 유출될 수 있습니다.

가능하면 서비스 계정 키를 파일 시스템에 저장하지 않아야 합니다. 디스크에 키를 저장할 수 밖에 없으면 파일 액세스 감사를 구성하여 키 파일에 대한 액세스를 제한하고 기본 디스크를 암호화합니다.

HSM 또는 TPM을 사용하여 키 저장

Google Cloud 콘솔 또는 gcloud CLI를 사용하여 서비스 계정 키를 만들면 Google Cloud 에서 비공개 키가 생성되고 사용자에게 표시됩니다. 서비스 계정 키와 연관된 많은 보안 위험은 일시적으로든 또는 영구적으로든 비공개 키가 일반 텍스트로 제공되고 따라서 보호가 어려울 수 있다는 사실로부터 비롯됩니다.

Google Cloud 에서 키 쌍을 생성하도록 하는 대신 하드웨어 보안 모듈(HSM) 또는 신뢰 플랫폼 모듈(TPM)을 사용하여 키를 만들고 관리할 수 있습니다.

1. HSM 또는 TPM을 사용하여 RSA 키 쌍을 생성합니다.
2. 키 쌍을 사용하여 자체 서명 인증서를 만듭니다.
3. 서비스 계정 키로 인증서를 업로드합니다.
4. 애플리케이션이 HSM 또는 TPM의 서명 API를 사용해서 서비스 계정 인증을 위해 JWT를 서명하도록 허용합니다.

HSM 또는 TPM을 사용하면 키를 일반 텍스트로 드러내지 않고 비공개 키를 사용할 수 있습니다. 따라서 HSM 또는 TPM을 사용해서 서비스 계정 키를 관리하면 액세스 제어를 강화하면서도 키가 다른 시스템에 복사될 위험을 줄이는 데 도움이 됩니다.

일부 플랫폼은 직접 상호작용할 필요 없이 TPM의 이점을 활용할 수 있게 해주는 추상화를 제공합니다. 예를 들어 Windows에서는 Microsoft Platform Crypto Provider와 함께 CryptoNG API를 사용하여 TPM 보호 키를 관리할 수 있습니다.

TPM으로 관리되는 서비스 계정 키는 물리 또는 가상 머신에 고유합니다. 여전히 각 머신의 키를 공통 서비스 계정과 연결하여 여러 머신이 하나의 서비스 계정을 공유하도록 할 수 있습니다.

소프트웨어 기반 키 저장소 사용

사용자 기반 키 저장소를 사용하기 쉽지 않은 경우에는 소프트웨어 기반 키 저장소를 사용하여 서비스 계정 키를 관리합니다. 하드웨어 기반 옵션과 비슷하게, 소프트웨어 기반 키 저장소를 사용하면 사용자 또는 애플리케이션이 비공개 키를 드러내지 않고 서비스 계정 키를 사용할 수 있습니다. 소프트웨어 기반 키 저장소 솔루션은 키 액세스를 미세한 방식으로 제어할 수 있게 해주고 각 키 액세스가 로깅되도록 할 수도 있습니다.

소프트웨어 기반 키 저장소의 보안은 일반적으로 마스터 키의 보호 방법에 따라 달라집니다. 소프트웨어 기반 키 저장소를 사용하기 전에 다음을 검토하세요.

• 저장 상태에서의 마스터 키 보안 방법
• 해제 프로세스 작동 방법과 이를 시작할 수 있는 사용자
• 메모리에서 키가 추출되지 않도록 보호하는 방법
• 악의적인 행위자가 셸 액세스나 기본 시스템에 대한 하이퍼바이저 액세스 권한을 얻을 경우 키 저장소가 약화되지 않도록 보호하는 방법

Secret Manager 또는 다른 클라우드 기반 보안 비밀 저장소에 키 저장 금지

서비스 계정 키를 저장하고 순환하기 위해 Google Cloud의 Secret Manager를 사용하지 않는 것이 좋습니다. 이는 Secret Manager 보안 비밀에 액세스하려면 애플리케이션에Google Cloud 가 인식할 수 있는 ID가 필요하기 때문입니다. 애플리케이션에 이미 Google Cloud 가 인식할 수 있는 ID가 있는 경우 애플리케이션은 서비스 계정 키를 사용하는 대신 해당 ID를 사용하여 Google Cloud 에 인증할 수 있습니다.

Azure KeyVault 및 AWS Secret Manager와 같은 다른 클라우드 기반 보안 비밀 관리 서비스에도 동일한 개념이 적용됩니다. 애플리케이션에 이미 클라우드 제공업체에서 인식할 수 있는 ID가 있는 경우 애플리케이션은 서비스 계정 키를 사용하는 대신 해당 ID를 사용하여 Google Cloud 에 인증할 수 있습니다.

서비스 계정 키 생성 또는 업로드를 허용하는 프로젝트의 편집자 역할 사용 금지

편집자(roles/editor) 및 소유자(roles/owner) 기본 역할 간의 중요한 차이점은 편집자 역할의 경우 IAM 정책 또는 역할을 변경할 수 없다는 것입니다. 따라서 편집자 역할이 있으면 자신의 고유 액세스 권한을 확장하거나 다른 사용자에게 프로젝트 리소스 액세스 권한을 부여하는 것이 쉽지 않습니다.

프로젝트에 서비스 계정이 있으면 편집자 역할의 제한이 약화될 수 있습니다. 편집자 역할은 서비스 계정 키를 만들거나 업로드하는 권한을 부여하기 때문에 악의적인 행위자가 기존 서비스 계정에 대해 새 키를 만들고 이러한 키를 사용해서 자신의 고유 액세스 권한을 에스컬레이션하거나 키를 다른 사용자에게 전달하여 프로젝트에 리소스에 대한 액세스 권한을 획득할 수 있습니다.

편집자 역할 또는 다른 기본 역할을 사용하는 대신 보다 제한적으로 정의된 미리 정의된 역할을 사용하거나 필요한 권한만 부여하는 커스텀 역할을 만드는 것이 좋습니다.

편집자 역할을 사용해야 하는 경우 조직 정책 제약조건을 사용하여 서비스 계정 키 업로드 및 키 생성을 사용 중지하면 편집자 역할을 권한 에스컬레이션에 악용할 수 없습니다.

도메인 전체 위임 시 서비스 계정 키 사용 방지

도메인 전체 위임을 사용하면 사용자 측면의 수동 승인 없이 사용자 데이터에 액세스할 수 있도록 사용자를 가장할 수 있습니다. 도메인 전체 위임 사용을 설명하는 예시에서는 일반적으로 서비스 계정 키를 사용하도록 제안하지만 도메인 전체 위임을 수행하기 위해 반드시 서비스 계정 키를 사용할 필요는 없습니다.

도메인 전체 위임을 사용할 때는 서비스 계정 키를 피하고 signJwt API를 대신 사용하세요.

1. 연결된 서비스 계정 ,GKE용 워크로드 아이덴티티 제휴, 워크로드 아이덴티티 제휴를 먼저 사용하여 서비스 계정을 인증하세요.
2. JWT를 생성하고 sub 클레임을 사용하여 위임된 액세스 권한을 요청하려는 사용자의 이메일 주소를 지정합니다.
3. signJwt API를 사용하여 JWT를 서명합니다.
4. OAuth2 토큰 리소스에 서명된 JWT를 전달하여 액세스 토큰을 가져옵니다.

이 방법을 따르면 서비스 계정 키를 관리하지 않아도 되므로 더 쉽게 보호할 수 있습니다.

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

업로드된 X.509 인증서에 기밀 정보 공개하지 않기

각 서비스 계정 키에 대해 IAM을 사용하여 X.509 인증서를 https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL 엔드포인트에서 다운로드할 수 있습니다. 이 엔드포인트는 공개적이며 인증이 필요하지 않습니다.

Google Cloud 콘솔 또는 gcloud CLI를 사용하여 만든 Google-owned and managed keys 및 사용자 관리 키의 경우 X.509 인증서가 자동으로 생성되며 이메일 주소 및 만료일과 같은 기본 메타데이터만 포함됩니다.

업로드된 서비스 계정 키에 대해 공개 엔드포인트에서 제공되는 X.509 인증서는 사용자가 업로드한 것과 동일한 인증서입니다. 사용자가 업로드한 인증서에 선택적인 속성(일반 이름이 삽입된 주소 또는 위치 정보 등)이 포함된 경우 이 정보가 공개적으로 액세스될 수 있습니다. 악의적인 행위자가 이러한 정보를 이용해서 해당 환경에 대해 자세히 알아볼 수 있습니다.

기밀 정보가 노출되지 않도록 업로드된 X.509 인증서에 선택적인 속성을 추가하지 않고, 일반적인 Subject를 사용합니다.

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

Google Cloud리소스에 영향을 주는 의심스러운 활동이 발견되었고 이러한 활동의 시작점을 분석하고 싶으면 의심스러운 활동으로 이어진 일련의 이벤트를 재구성할 수 있게 해주는 데이터가 필요합니다. 이러한 분석을 수행하기 위한 데이터의 주요 시작점은 일반적으로 감사 로그입니다.

서비스 계정이 관련되어 있으면 감사 로그를 분석하는 것이 더 어려워질 수 있습니다. 서비스 계정에서 활동을 시작한 경우 로그 항목에 서비스 계정의 이메일 주소가 포함되지만 해당 시점에 어떤 사용자 또는 애플리케이션이 서비스 계정을 사용하고 있었는지도 알아내야 합니다.

다음 섹션에는 서비스 계정 키를 사용량을 추적하는 데 사용하기 위한 권장사항이 나와 있습니다.

각 애플리케이션에 전용 서비스 계정 사용

모든 감사 로그 레코드에는 활동을 시작한 주 구성원을 식별하는 principalEmail 필드가 포함되어 있습니다. 여러 애플리케이션에서 서비스 계정 키를 공유하는 경우 감사 로그 레코드에 동일한 principalEmail 값이 포함되므로 활동을 수행한 애플리케이션을 식별하는 것이 어려울 수 있습니다.

여러 애플리케이션 간에 키를 공유하는 대신 각 애플리케이션에 대해 전용 서비스 계정을 만드세요. 이렇게 하면 principalEmail 필드를 통해 서비스 계정과 연결된 애플리케이션을 식별할 수 있고, 따라서 의심스러운 활동으로 이어진 일련의 이벤트를 재구성하는 데 도움을 줄 수 있습니다.

애플리케이션을 실행하는 각 머신에 전용 키 사용

여러 머신 간에 동일한 애플리케이션의 여러 복사본을 실행하는 경우 principalEmail 필드를 통해 애플리케이션을 식별할 수 있지만 특정 활동이 시작된 머신을 확인할 수 없습니다.

의심스러운 활동에 대한 잠재적 요인을 줄이려면 애플리케이션 사본마다 개별 키를 만듭니다. 이렇게 하면 많은 서비스들이 감사 로그 기록을 추가하는 serviceAccountKeyName 필드를 사용하여 활동이 발생한 머신을 구별할 수 있습니다.

악의적인 사용자 인증 정보 구성으로부터 보호

일부 사용자 인증 정보 구성에는 워크로드에서 적합하게 검증되지 않을 경우 워크로드에서 악의적인 엔드포인트 사용을 유발할 수 있는 URL 및 파일 경로가 포함됩니다.

외부 소스에서 가져온 키를 Google API에 인증하는 데 사용하기 전에 키 검증

외부 소스에서 서비스 계정 키를 수락하는 경우 키를 사용하기 전에 검증해야 합니다. 키를 검증하지 않으면 악의적인 행위자가 키를 사용하여 워크로드가 악성 엔드포인트에 액세스하도록 할 수 있습니다.

시스템에서 서비스 계정 키만 예상하는 경우 type 필드의 값이 service_account인지 확인합니다.

자세한 내용은 외부 소스 사용자 인증 정보 구성을 사용할 때의 보안 요구사항을 참조하세요.

다음 단계

• 서비스 계정 작업을 위한 권장사항에 대해 자세히 알아보기
• 배포 파이프라인에서 서비스 계정을 사용하기 위한 권장사항 검토하기