서비스 계정 키에서 마이그레이션

서비스 계정 키는 일반적으로 Google Cloud 서비스를 인증하는 데 사용됩니다. 하지만 올바르게 관리되지 않으면 보안 위험이 되어 사용자 인증 정보 유출, 권한 에스컬레이션, 정보 공개, 부인 방지와 같은 위협에 대한 취약점이 증가할 수 있습니다.

대부분의 경우 보다 안전한 대안으로 서비스 계정 키를 인증할 수 있습니다. 이 가이드는 기본 인증 메커니즘으로 서비스 계정 키 사용에서 이따금 서비스 계정 키가 반드시 필요한 경우를 제외하고 보다 안전한 대안 사용으로 마이그레이션하는 데 도움이 됩니다.

이 문서는 보다 안전한 인증 메커니즘으로 서비스 계정 키 사용을 줄여 보안 상황을 개선하려는 보안 관리자를 대상으로 합니다. 이러한 보안 관리자는 기존 프로덕션 워크로드, 개발자 워크플로, 서비스 계정 키를 사용하는 내부 프로세스의 보안을 담당할 수 있습니다.

개요

기존 워크로드에서 서비스 계정 키를 삭제하려면 우발적인 중단을 방지하기 위한 신중한 계획이 필요합니다. 다음 마이그레이션 계획은 개발자의 업무 중단을 최소화하면서 중앙 집중식 제어를 적용할 수 있도록 설계되었습니다.

이 마이그레이션 계획에는 세 가지 단계가 포함됩니다.

평가: 이 단계에서는 기존 환경을 평가하여 서비스 계정 키가 있는 위치와 키가 사용 중인지 여부를 파악합니다.
계획: 이 단계에서는 마이그레이션 계획을 최종적으로 이해관계자에게 배포하고 알리는 설정을 결정합니다.
배포: 이 단계에서는 서비스 계정 키에 대한 보다 안전한 대안으로 인증할 워크로드 리팩터링을 시작합니다. 또한 환경을 지속적으로 모니터링하고 향후 위험을 완화할 수 있는 추가 기능을 빌드합니다.

서비스 계정 키 사용 평가

이 단계에서는 기존 환경을 평가하여 서비스 계정 키가 있는 위치와 키가 사용 중인지 여부를 파악합니다.

다음 섹션에서는 조직에서 서비스 계정 키가 사용되는 방식을 보다 잘 이해하기 위해 수집할 수 있는 데이터를 설명합니다.

키 사용 데이터 수집

먼저 서비스 계정 키가 있는 위치와 사용 방식을 확인합니다.

Google Cloud는 서비스 계정 사용을 이해하는 도구를 제공합니다. 이러한 도구를 사용하면 최근에 인증에 사용된 서비스 계정과 키, 지난 90일 동안 사용되지 않은 서비스 계정, 과도한 권한이 있는 역할이 포함된 서비스 계정을 확인할 수 있습니다.

이러한 모든 도구의 정보를 결합하여 조직 전체에서 서비스 계정과 키가 사용되는 방식을 더 잘 이해할 수 있습니다. 조직 전체에서 이러한 다양한 소스의 정보를 결합하는 방법에 대한 예시는 GitHub의 배포 가능한 참조 아키텍처를 참조하세요. 이 참조 아키텍처는 다양한 도구의 데이터를 집계하고 분석을 위해 정기적으로 BigQuery 테이블로 내보냅니다.

참조 아키텍처는 조직의 서비스 계정 키를 식별하기 위해 Cloud 애셋 인벤토리를 쿼리하는 데이터 파이프라인을 배포합니다. 그런 다음 데이터 파이프라인은 데이터를 연결된 계정의 키 사용 및 권한 사용에 대한 데이터와 결합합니다. 결과 테이블 sa_key_usage는 다음과 같은 질문에 답하는 데 도움이 됩니다.

영구 키가 얼마나 생성되었나요? 이 숫자는 키에서 마이그레이션할 때 진행 상황을 추적하는 상위 수준 측정항목으로 유용할 수 있습니다.
어떤 프로젝트와 서비스 계정에서 키를 사용하나요? 이 정보는 서비스 계정 키를 사용하는 워크로드의 소유자를 식별하는 데 도움이 됩니다.
비활성화된 키는 무엇인가요? 워크로드 소유자의 추가 평가 없이 이러한 키를 삭제할 수 있습니다.
과도한 권한에 대한 권장사항이 있는 서비스 계정과 연결된 키는 무엇인가요? 서비스 계정 키가 과도한 권한이 있는 서비스 계정, 특히 소유자, 편집자 또는 뷰어 역할이 있는 서비스 계정과 연결된 경우 키가 특히 위험할 수 있습니다. 역할 권장사항이 있는 서비스 계정을 찾으면 과도한 권한이 있는 서비스 계정을 식별할 수 있습니다. 이러한 서비스 계정을 식별한 후 이러한 워크로드의 마이그레이션 우선순위를 결정할 수 있습니다. 역할 권장사항을 적용하여 사전에 초과 권한을 줄일 수도 있습니다.

이 데이터 파이프라인은 매일 실행되며 날짜로 파티션을 나눈 BigQuery 테이블에 씁니다. 이 테이블을 사용하여 특정 서비스 계정 또는 키를 조사하거나 Looker Studio와 같은 대시보드 도구를 사용하여 해결 진행 상황을 추적할 수 있습니다.

추가 컨텍스트로 키 사용 데이터 보강

키 사용 데이터 세트를 만든 후 선택적으로 추가 데이터 소스로 확장할 수 있습니다. 이미 리소스의 거버넌스 및 출처 추적에 사용하는 데이터 소스를 추가하는 것이 좋습니다. 기존 거버넌스에 따라 다음과 같은 데이터를 추가할 수 있습니다.

구성 관리 데이터베이스(CMDB) 또는 유사한 시스템의 소유권 정보
프로젝트 라벨에서 구성된 거버넌스 정보(예: 프로젝트를 담당하는 팀 또는 비용 센터)
Google Cloud 외부의 환경에서 워크로드에 사용되는 키에 대한 환경 정보

서비스 계정 키 사용 감소 계획 만들기

서비스 계정 키 사용을 줄이기 위해 변경사항을 배포하려면 먼저 영향을 받는 워크로드 및 환경과 이러한 변경사항을 적용하는 방법을 결정해야 합니다. 또한 비즈니스 전체에 이 계획을 알리고 워크로드 소유자가 계획을 지원하는지 확인해야 합니다.

다음 섹션에서는 계획에서 다뤄야 하는 주요 주제를 소개합니다. 구체적인 계획은 조직 크기와 워크로드의 특정 요구사항에 따라 달라집니다.

현재 워크로드 소유자의 책임 결정

중앙 보안팀에서 어떤 키가 있는지 평가할 수 있지만 성공적으로 마이그레이션하려면 워크로드 소유자의 노력이 필요합니다. 마이그레이션 범위 내에 있는 키의 경우 워크로드 소유자는 사용 사례에 적합한 사용 가능한 인증 방법을 결정한 후 마이그레이션을 실행해야 합니다.

기존 보안 상황에 대한 개선 사항과 워크로드 소유자가 요구하는 작업 간의 균형을 맞출 방법을 고려합니다. 다음 섹션에서는 보안 상황에 대한 개선사항을 중요시하는 방식과 워크로드 소유자의 노력 최소화를 매우 중요시하는 방식 등 두 가지 샘플 방식을 설명합니다. 실제 방식은 다를 수 있습니다. 예를 들어 범위 내에 있는 워크로드를 개별적으로 선택할 수 있습니다.

예시: 마이그레이션에 대해 현재 모든 워크로드 평가

한 가지 가능한 방식은 모든 기존 및 향후 워크로드에 서비스 계정 키 제어를 적용하는 것입니다. 이 작업은 다음과 같은 단계로 진행됩니다.

워크로드 소유자와 협력하여 기존 워크로드의 키 사용을 평가합니다.
워크로드 소유자가 예외를 부여하지 않는 한 모든 기존 워크로드를 키 사용으로 마이그레이션해야 합니다.
모든 향후 워크로드에서 예외를 부여하지 않는 한 서비스 계정 키를 사용하지 못하도록 합니다.

이 방식은 기존 보안 상황에 대한 개선사항을 우선시하지만 단기적으로는 개발자와 워크로드 소유자의 더 많은 노력을 요구합니다. 이와 같은 계획을 성공적으로 실행하려면 워크로드 검토 및 리팩터링에 참여할 워크로드 소유자의 약정이 필요합니다.

예시: 마이그레이션에 대해 현재 워크로드가 평가되지 않음

또 다른 방식은 기존 워크로드에 자동 예외를 허용하여 서비스 계정 키를 계속 사용하고 향후 워크로드에 새 설정만 적용하는 것입니다.

이 방식은 향후 워크로드의 보안 상황을 개선하고 현재 워크로드 소유자의 책임을 최소화합니다. 그러나 기존 워크로드의 보안 상황은 개선되지 않습니다.

단기 성과 식별

평가 시 워크로드 소유자의 추가 해결 작업이 없어도 안전하게 삭제할 수 있는 키를 식별할 수 있습니다. 예를 들어 90일 동안 키에서 활동이 없거나 키가 더 이상 활성 상태가 아닌 리소스와 관련된 경우 다른 인증 메커니즘으로 마이그레이션할 필요 없이 안전하게 삭제할 수 있습니다.

이 기준을 충족하는 키 목록을 만듭니다. 배포 단계 중에 이 목록을 사용하여 불필요한 키를 삭제합니다. 목록에 키를 추가하기 전에 서비스 계정 키를 사용하는 긴급 프로덕션 액세스와 같이 서비스 계정 키가 자주 필요하지 않은 사용 사례가 있는지 확인합니다.

조직 정책 변경사항을 적용할 위치 계획

서비스 계정 키 사용에서 성공적으로 마이그레이션하려면 새 키가 생성되지 않도록 해야 합니다. 배포 단계 중에 새 서비스 계정 키가 생성되지 않도록 iam.disableServiceAccountKeyCreation 조직 정책 제약조건을 적용합니다.

이 제약조건은 기존 키 사용을 방지하지 않지만 키를 정기적으로 순환하는 기존 워크로드를 중단할 수 있습니다. 배포 단계를 시작하기 전에 중단이 최소화되도록 리소스 계층 구조에서 제약조건을 적용할 위치를 결정합니다.

초기에 조직 수준 대신 프로젝트 또는 폴더 수준에서 제약조건을 적용할 수 있습니다. 예를 들어 프로덕션 폴더에 배포하기 전에 개발 환경에 사용되는 폴더에 제약조건을 적용할 수 있습니다. 또는 많은 팀이 있는 대규모 조직에서는 먼저 단일 팀의 폴더에 제약조건을 적용한 후 마이그레이션할 때 추가 폴더에 제약조건을 적용합니다.

태그가 포함된 조직 정책을 사용하여 프로젝트 또는 폴더 수준에서 조직 정책을 조건부로 적용할 수 있습니다.

예외 프로세스 설계

이 마이그레이션의 목표는 서비스 계정 키 사용을 줄이거나 없애는 것이지만 서비스 계정 키가 필요한 적절한 사용 사례가 몇 가지 있습니다. 기존 워크로드에 서비스 계정 키가 필요하지 않더라도 향후 워크로드에 필요할 수 있습니다. 따라서 서비스 계정 키가 필요한 사용 사례의 예외를 평가하고 승인하는 운영 프로세스를 정의해야 합니다.

워크로드 소유자가 워크로드에서 서비스 계정 키를 사용하도록 허용하는 예외를 요청하는 프로세스를 정의합니다. 예외를 부여해야 하는 의사 결정권자는 사용 사례를 검증하기 위한 기술적 지식을 보유하고 서비스 계정 키에 대한 보다 안전한 대안 중 더 적합한 대안을 워크로드 소유자와 협의하며 워크로드 소유자에게 서비스 계정 키 관리 권장사항에 대해 조언합니다.

워크로드 소유자에게 예정된 변경사항 알림

계획을 설계한 후에는 조직 전체에서 해당 계획을 명확하게 알리고 이해관계자, 특히 고위 리더가 마이그레이션에 기여할 준비가 되었는지 확인해야 합니다.

구체적인 마이그레이션 세부정보는 조직에 따라 다르지만 커뮤니케이션 계획에 다음 주제를 포함하는 것이 좋습니다.

안전하지 않은 서비스 계정 키가 조직에 미칠 수 있는 부정적인 영향과 서비스 계정 키로부터 마이그레이션을 유도하는 동기
서비스 계정 키 생성을 방지하는 새로운 보안 제어와 기존 프로세스에 미치는 영향
개발자가 서비스 계정 키에 대한 보다 안전한 대안을 식별하도록 안내하는 지침
팀에서 이 예외를 다시 평가하는 빈도를 포함하여 서비스 계정 키를 허용하도록 예외를 요청하는 프로세스
제안된 변경사항을 적용하기 위한 타임라인

워크로드 소유자와 협력하여 계획을 세분화하고 조직 전체에서 작동하는지 확인합니다.

제어 배포 및 워크로드 리팩터링

계획을 만들어 워크로드 소유자에게 알린 후 서비스 계정 키에서 마이그레이션을 시작할 수 있습니다.

이 단계에서는 서비스 계정 키에 대한 보다 안전한 대안으로 인증할 워크로드 리팩터링을 시작합니다. 또한 환경을 지속적으로 모니터링하고 향후 위험을 완화할 수 있는 추가 기능을 빌드합니다.

다음 섹션에서는 중단을 최소화하면서 워크로드를 리팩터링하고 키를 삭제할 수 있는 단계를 설명합니다. 조직에 필요한 우선순위와 노력에 따라 이러한 단계를 원하는 순서로 수행할 수 있습니다.

새 서비스 계정 키 생성을 중지하는 제어 적용

새 서비스 계정 키 만들기를 중지하려면 iam.disableServiceAccountKeyCreation 조직 정책 제약조건을 적용합니다.

하지만 이 제약조건을 적용하기 전에 태그를 정책에서 제외할 프로젝트나 폴더에 추가해야 합니다. 서비스 계정 키에서 마이그레이션할 수 없는 기존 워크로드 또는 적법한 이유로 서비스 계정 키로만 인증해야 하는 새로운 워크로드에 대한 예외를 허용할 수 있습니다.

태그를 추가하여 프로젝트와 폴더를 제외한 후 태그가 있는 조직 정책을 설정하여 예외가 아닌 프로젝트와 폴더에 iam.disableServiceAccountKeyCreation 제약조건을 적용할 수 있습니다.

예외가 아닌 프로젝트와 폴더 모두에서 서비스 계정 키가 생성되지 않게 하려면 다음을 수행합니다.

조직 수준에서 태그를 관리하고 조직 정책을 관리하는 데 필요한 IAM 역할이 있는지 확인합니다.
조직 수준에서 프로젝트나 폴더를 조직 정책에서 제외할지 여부를 정의하는 데 사용할 태그 키와 태그 값을 만듭니다. disableServiceAccountKeyCreation 키와 enforced 및 not_enforced 값으로 태그를 만드는 것이 좋습니다.

태그 키와 태그 값을 만드는 방법은 새 태그 만들기 및 정의를 참조하세요.
disableServiceAccountKeyCreation 태그를 조직에 연결하고 enforced 값으로 설정합니다. 다른 태그 값으로 덮어쓰지 않는 한 조직의 모든 프로젝트나 폴더에서 이 태그 값을 상속합니다.

태그를 리소스에 연결하는 방법은 리소스에 태그 연결을 참조하세요.
조직 정책에서 제외하려는 프로젝트나 폴더마다 disableServiceAccountKeyCreation 태그를 연결하고 값을 not_enforced로 설정합니다. 이러한 방식으로 프로젝트나 폴더의 태그 값을 설정하면 조직에서 상속된 태그 값이 재정의됩니다.
예외 리소스를 제외한 모든 리소스에 대한 서비스 계정 키 생성을 방지하는 조직 정책을 만듭니다. 이 정책에는 다음 규칙이 있어야 합니다.
- disableServiceAccountKeyCreation: not_enforced 태그가 있는 리소스에 적용되지 않도록 iam.disableServiceAccountKeyCreation 제약조건을 구성합니다. 이 규칙의 조건은 다음과 같이 표시됩니다.
```
resource.matchTag(\"ORGANIZATION_ID/disableServiceAccountKeyCreation\", \"not_enforced\")
```
- 다른 모든 리소스에 적용되도록 iam.disableServiceAccountKeyCreation 제약조건을 구성합니다.
태그 조건이 있는 조직 정책을 만드는 방법은 태그를 사용한 조직 정책 설정을 참조하세요.

기존 워크로드 해결

서비스 계정 키를 사용하는 워크로드마다 워크로드 소유자와 협력하여 대체 인증 방법을 선택하고 구현합니다.

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

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

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

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

경우에 따라 서비스 계정 키 이외의 어떠한 인증 방법도 사용하지 못할 수 있습니다. 서비스 계정 키만 가능한 경우의 예시는 다음과 같습니다.

Google Cloud 서비스 계정 키를 사용자 인터페이스에 직접 입력하도록 요청하는 상용 제품(COTS) 또는 software-as-a-service(SaaS) 애플리케이션을 사용하고 있습니다.
워크로드가 Google Cloud 외부에서 실행되고 워크로드 아이덴티티 제휴를 지원할 수 있는 ID 공급업체로 인증되지 않았습니다.

서비스 계정 키를 계속 사용해야 하는 경우 서비스 계정 키 관리 권장사항을 따라야 합니다.

서비스 계정 키 계속 사용에 따른 위험이 다른 인증 방법으로 전환하는 비용을 정당화하지 않는다고 평가하므로 특정 워크로드를 해결하지 않기로 결정할 수 있습니다.

불필요한 키 삭제

서비스 계정 키가 필요하지 않다고 확신하는 경우에는 키를 삭제해야 합니다. 불필요한 키는 다음과 같습니다.

최근에 사용하지 않는 키 또는 이 페이지의 빠른 성공 식별 섹션에서 식별된 미사용 리소스와 관련된 키
다른 인증 방법으로 마이그레이션된 워크로드의 키

프로젝트에서 모든 서비스 계정 키를 삭제한 후 iam.disableServiceAccountKeyCreation 제약조건이 해당 프로젝트에 적용되었는지 확인합니다. 프로젝트가 이전에 이 제약조건에서 제외됐으면 예외에 허용된 태그를 삭제합니다.

키를 안전하게 삭제하려면 키를 중지한 후에 삭제하는 것이 좋습니다. 삭제를 되돌릴 수 없지만 중지하면 예기치 않은 문제가 발견되면 키를 빠르게 다시 사용 설정할 수 있습니다. 키를 중지한 후 키를 영구 삭제해도 문제가 발생하지 않을 때까지 기다린 후 키를 삭제합니다. 키를 중지한 후 예기치 않은 문제가 발견되면 키를 다시 사용 설정하고 문제를 해결한 후 키를 안전하게 삭제할 수 있을 때까지 프로세스를 반복합니다.

기본 제공되는 제어를 사용하여 유출된 키에 대응

Google Cloud는 유출된 서비스 계정 키를 감지하고 대응하는 데 도움이 되는 몇 가지 도구와 서비스를 제공합니다. 다음 메커니즘을 사용하면 유출된 서비스 계정 키에 대응할 수 있습니다.

Security Command Center 이상 감지를 사용 설정하여 키의 공개 저장소를 스캔합니다. 이 스캔은 유출된 키가 감지되면 account_has_leaked_credentials 발견 항목을 만듭니다.
Security Command Center 암호화폐 채굴 보호 프로그램을 검토하고 자격 요건에 대한 기술 기본 요건을 충족하는지 확인합니다. 암호화폐 채굴 악용은 사용자 인증 정보가 유출되는 경우의 일반적인 취약점 공격입니다.
보안팀이 보안 침해된 키로 인한 악용을 포함하여 Google Cloud에서 보안 알림을 수신하도록 필수 연락처를 구성합니다. 이메일 주소가 모니터링되고 개별 사용자가 단일 장애점으로 사용되지 않는지 확인합니다.

이슈 관리에 대한 자세한 내용은 이슈 관리를 위한 공동작업 프로세스 빌드를 참조하세요.

지속적인 서비스 계정 관리 개선

가능한 경우 서비스 계정 키 관리 권장사항을 구현합니다. 키 관리 프로세스를 개선하면 조직에서 나머지 서비스 계정 키 위험을 완화할 수 있습니다.