Google Cloud 사용자 인증 정보는 Google Cloud에서 호스팅되는 리소스에 대한 액세스를 제어합니다. 데이터를 공격자로부터 안전하게 보호하려면 세심한 주의를 기울여 사용자 인증 정보를 취급해야 합니다.
모든 Google Cloud 사용자 인증 정보를 의도하지 않은 액세스로부터 보호하는 것이 좋습니다. 이러한 사용자 인증 정보에는 다음이 포함되며 이에 국한되지 않습니다.
서비스 사용자 인증 정보:
- 서비스 계정 비공개 키 (JSON 및 p12 파일)
- API 키
- OAuth2 클라이언트 ID 암호
개발자 워크스테이션이나 다른 컴퓨터에서 만들고 관리하는 사용자 인증 정보:
Google Cloud CLI 사용자 인증 정보는 사용자의 홈 디렉터리에 저장됩니다. gcloud
auth list
명령어를 사용하여 Google Cloud CLI에 나열할 수 있습니다.
애플리케이션 기본 사용자 인증 정보는 개발자 워크스테이션에 저장됩니다.
브라우저 쿠키는 브라우저별로 다르지만 일반적으로 개발자 워크스테이션에 저장됩니다.
사용자 인증 정보가 손상된 것으로 의심되면 Google Cloud 계정에서 손상으로 인한 영향이 제한되도록 즉각적인 조치를 취해야 합니다.
사용자 인증 정보 손상 모니터링
잠재적 손상을 모니터링하려면 다음을 수행하는 것이 좋습니다.
권한 에스컬레이션 및 여러 계정 만들기와 같은 의심스러운 계정 활동을 모니터링합니다. Cloud 감사 로그, 정책 인텔리전스, Security Command Center를 사용하여 이러한 활동을 모니터링합니다. 다음 Security Command Center 서비스 및 기능을 사용합니다.
- Event Threat Detection: 관리자 활동, 그룹스 변경사항, Identity and Access Management(IAM) 권한 변경사항에 따른 위협을 식별합니다. 각 위협 카테고리에 대해 대응에 도움이 되는 권장 조사 단계가 제공됩니다.
- 민감한 작업 서비스: 악의적인 행위자가 수행할 경우 비즈니스에 해를 끼칠 수 있는 작업이 조직, 폴더, 프로젝트에서 수행될 때 이를 추적합니다.
- 클라우드 인프라 사용 권한 관리(CIEM)(미리보기): ID에 대한 액세스를 관리하고 구성 오류 발견 항목을 생성합니다.
Google Workspace 및 Cloud ID에서 사용자 로그인을 모니터링합니다. 문제를 더욱 효과적으로 추적하려면 로그를 Cloud Logging으로 내보내는 것이 좋습니다.
Cloud Monitoring 또는 CIEM을 사용하여 서비스 계정 키 사용 이상을 모니터링합니다.
보안 운영 센터(SOC)에 즉시 알림이 전송되고 의심스러운 사용자 인증 정보 손상에 신속하게 대응하는 데 필요한 플레이북, 도구, 액세스 권한이 있는지 확인합니다. Security Command Center Enterprise 등급을 사용해서 플레이북, 대응 워크플로, 자동 작업과 같은 SIEM 및 SOAR 기능을 사용 설정합니다. 추가 분석을 위해 Security Command Center를 기존 SIEM과 통합하거나 Google Security Operations로 로그를 가져올 수도 있습니다.
손상된 사용자 인증 정보로부터 Google Cloud 리소스 보호
사용자 인증 정보가 손상된 것으로 의심되는 경우 리소스를 보호하는 데 도움이 되도록 가능한 한 빨리 다음 섹션의 단계를 완료합니다.
사용자 인증 정보 취소 및 재발급
사용자 인증 정보가 손상된 것으로 의심되면 취소하고 다시 발급합니다. 사용자 인증 정보 취소로 인해 서비스가 중단되지 않도록 신중하게 진행합니다.
일반적으로 사용자 인증 정보를 다시 발급하려면 새 사용자 인증 정보를 생성하여 필요한 모든 사용자와 사용자로 내보낸 후 이전 사용자 인증 정보를 취소합니다.
다음 섹션에서는 각 사용자 인증 정보 유형에 대한 구체적인 지침을 제공합니다.
서비스 계정 키 바꾸기
Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.
영향을 받는 서비스 계정을 찾습니다.
서비스 계정의 새 키를 만듭니다.
이전 키가 사용된 모든 위치로 새 키를 내보냅니다.
이전 키를 삭제합니다.
자세한 내용은 서비스 계정 만들기를 참고하세요.
API 키 재생성
Google Cloud 콘솔에서 사용자 인증 정보 페이지로 이동합니다.
사용자 인증 정보 만들기 버튼을 사용하여 새 API 키를 만듭니다. 손상된 API 키와 동일한 새 키를 구성합니다. API 키에 대한 제한 사항이 일치해야 하며 그렇지 않으면 중단될 수 있습니다.
이전 키가 사용된 모든 위치로 API 키를 내보냅니다.
이전 키를 삭제합니다.
자세한 내용은 API 키를 사용하여 인증을 참고하세요.
OAuth2 클라이언트 ID 보안 비밀 재설정
클라이언트 ID 보안 비밀을 변경하면 보안 비밀이 순환되는 동안 일시적으로 서비스가 중단됩니다.
Google Cloud 콘솔에서 사용자 인증 정보 페이지로 이동합니다.
원하는 OAuth2 클라이언트 ID를 선택하고 편집합니다.
보안 비밀 재설정을 클릭합니다.
새 보안 비밀을 애플리케이션으로 내보냅니다.
자세한 내용은 OAuth 2.0 설정 및 OAuth 2.0을 사용하여 Google API에 액세스를 참조하세요.
관리자 권한으로 Google Cloud CLI 사용자 인증 정보 삭제
Google Workspace 관리자는 사용자의 연결된 앱 목록에서 Google Cloud CLI에 대한 액세스 권한을 삭제합니다. 자세한 내용은 타사 애플리케이션에 대한 액세스 권한 보기 및 삭제를 참조하세요.
사용자가 Google Cloud CLI에 다시 액세스하면 자동으로 애플리케이션을 다시 승인하라고 요청합니다.
사용자 권한으로 Google Cloud CLI 사용자 인증 정보 삭제
Google 계정에 액세스할 수 있는 앱 목록을 엽니다.
연결된 앱 목록에서 Google Cloud CLI를 삭제합니다.
Google Cloud CLI에 다시 액세스하면 자동으로 애플리케이션을 다시 승인하라고 요청합니다.
관리자 권한으로 애플리케이션 기본 사용자 인증 정보 취소
애플리케이션 기본 사용자 인증 정보가 손상된 것으로 의심되면 취소할 수 있습니다. 이 절차로 인해 사용자 인증 정보 파일이 다시 만들 때까지 서비스가 일시적으로 중단될 수 있습니다.
Google Workspace 관리자는 사용자의 연결된 앱 목록에서 Google 인증 라이브러리에 대한 액세스 권한을 삭제합니다. 자세한 내용은 타사 애플리케이션에 대한 액세스 권한 보기 및 삭제를 참조하세요.
사용자 권한으로 애플리케이션 기본 사용자 인증 정보 취소
만든 애플리케이션 기본 사용자 인증 정보가 손상된 것으로 의심되면 취소할 수 있습니다. 이 절차로 인해 사용자 인증 정보 파일이 다시 만들 때까지 서비스가 일시적으로 중단될 수 있습니다. 손상된 사용자 인증 정보 소유자만 이 절차를 완료할 수 있습니다.
아직 설치하지 않았으면 Google Cloud CLI를 설치하고 초기화합니다.
서비스 계정이 아닌 사용자 ID로 gcloud CLI를 승인합니다.
gcloud auth login
자세한 내용은 gcloud CLI 승인을 참고하세요.
사용자 인증 정보를 취소합니다.
gcloud auth application-default revoke
필요한 경우
application_default_credentials.json
파일을 삭제합니다. 위치는 운영체제에 따라 다릅니다.- Linux, macOS:
$HOME/.config/gcloud/
- Windows:
%APPDATA%\gcloud\
- Linux, macOS:
사용자 인증 정보 파일을 다시 만듭니다.
gcloud auth application-default login
관리자 권한으로 브라우저 쿠키 무효화
브라우저 쿠키가 손상된 것으로 의심되면 Google Workspace 관리자는 계정에서 사용자를 로그아웃할 수 있습니다.
또한 즉시 비밀번호를 강제로 변경합니다.
이러한 작업은 모든 기존 쿠키를 무효화하고 사용자에게 다시 로그인하라고 요청합니다.
사용자 권한으로 브라우저 쿠키 무효화
브라우저 쿠키가 손상된 것으로 의심되면 Google 계정에서 로그아웃하고 즉시 비밀번호를 변경합니다.
이 작업을 수행하면 모든 기존 쿠키가 무효화됩니다. 다음에 Google Cloud에 액세스하려면 다시 로그인해야 합니다.
미승인 액세스 및 리소스 찾기
손상된 사용자 인증 정보를 취소하고 서비스를 복원한 후 Google Cloud 리소스에 대한 모든 액세스를 검토합니다. 로깅 또는 Security Command Center를 사용할 수 있습니다.
Logging에서 다음을 수행합니다.
Google Cloud 콘솔에서 감사 로그를 검토합니다.
영향을 받았을 가능성이 있는 모든 리소스를 검색하고 모든 계정 활동(특히 손상된 사용자 인증 정보 관련)이 예상대로 진행되었는지 확인합니다.
Security Command Center에서 다음을 수행합니다.
Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.
필요한 경우 Google Cloud 프로젝트 또는 조직을 선택합니다.
빠른 필터 섹션에서 발견 항목 쿼리 결과 테이블에서 필요한 발견 항목을 표시하기 위해 적합한 필터를 클릭합니다. 예를 들어 소스 표시 이름 하위 섹션에서 Event Threat Detection 또는 Container Threat Detection을 선택하면 선택한 서비스의 발견 항목만 결과에 표시됩니다.
테이블은 선택한 소스의 발견 항목으로 채워집니다.
특정 발견 항목의 세부정보를 보려면
Category
에서 '발견 항목 이름'을 클릭합니다. 발견 항목 세부정보 창이 확장되어 발견 항목 세부정보 요약이 표시됩니다.동일한 사용자의 작업으로 인해 발생한 모든 발견 항목을 표시하려면 다음 안내를 따르세요.
- 발견 항목 세부정보 창에서 기본 이메일 옆의 이메일 주소를 복사합니다.
- 창을 닫습니다.
쿼리 편집기에서 다음 쿼리를 입력합니다.
access.principal_email="USER_EMAIL"
USER_EMAIL 주소를 이전에 복사한 이메일 주소로 바꿉니다.
Security Command Center에는 지정한 사용자가 수행한 작업과 관련된 모든 발견 항목이 표시됩니다.
모든 미승인 리소스 삭제
손상된 사용자 인증 정보가 액세스할 수 있는 VM, App Engine 앱, 서비스 계정, Cloud Storage 버킷 등과 같은 예기치 않은 리소스가 없는지 확인합니다.
모든 미승인 리소스를 파악한 것으로 판단되면 이러한 리소스를 즉시 삭제할 수 있습니다. 공격자가 손상된 계정을 사용하여 데이터를 유출하거나 프로덕션 시스템을 손상시킬 수 있으므로 Compute Engine 리소스에 특히 중요합니다.
또는 자체 포렌식 팀에서 추가 분석을 수행하도록 미승인 리소스 격리를 시도할 수 있습니다.
클라우드 고객 지원에 문의
조사 및 완화 단계에 필요한 Google Cloud 로그 및 도구를 찾는 데 도움이 필요하면 고객 지원에 문의하여 지원 케이스를 엽니다.
사용자 인증 정보 손상 방지를 위한 권장사항
이 섹션에서는 사용자 인증 정보 손상을 방지하는 데 도움이 되는 권장사항을 설명합니다.
코드에서 사용자 인증 정보 분리
소스 코드에서 사용자 인증 정보를 따로 관리하고 저장합니다. GitHub와 같은 소스 관리 사이트로 사용자 인증 정보와 소스 코드를 모두 실수로 푸시하는 바람에 사용자 인증 정보가 공격에 취약한 상태에 놓이는 일이 비일비재합니다.
GitHub 또는 다른 공개 저장소를 사용하는 경우 이상 감지 또는 GitHub 저장소에 노출된 보안 비밀에 대해 경고하는 보안 비밀 스캔과 같은 도구를 구현할 수 있습니다. 키가 GitHub 저장소에 커밋되지 않도록 하려면 git-secrets와 같은 도구를 사용하는 것이 좋습니다.
Secret Manager 및 Hashicorp Vault와 같은 보안 비밀 관리 솔루션을 사용하여 보안 비밀을 저장하고, 정기적으로 순환하고, 최소 권한을 적용합니다.
서비스 계정 권장사항 구현
서비스 계정 보호를 돕기 위해 서비스 계정 작업 권장사항을 검토합니다.
세션 길이 제한
정기적인 재인증을 강제 적용하려면 Google 및 Google Cloud 계정에서 세션이 활성 상태로 유지되는 시간을 제한합니다. 자세한 내용은 다음을 참조하세요.
VPC 서비스 제어를 사용하여 액세스 제한
손상된 사용자 인증 정보의 영향을 제한하려면 VPC 서비스 제어를 사용하여 서비스 경계를 만듭니다. VPC 서비스 제어를 구성하면 경계 내부의 리소스는 경계 내부의 다른 리소스와만 통신할 수 있습니다.