Korean - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Basic Information

HackTricks 지원하기

리소스 계층 구조

Google Cloud는 전통적인 파일 시스템과 개념적으로 유사한 리소스 계층 구조를 사용합니다. 이는 정책 및 권한에 대한 특정 첨부 지점이 있는 논리적인 부모/자식 워크플로를 제공합니다.

높은 수준에서, 다음과 같이 보입니다:

Organization
--> Folders
--> Projects
--> Resources

A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.

프로젝트 마이그레이션

조직 없이 프로젝트를 조직으로 마이그레이션하는 것이 가능합니다. 필요한 권한은 roles/resourcemanager.projectCreator와 roles/resourcemanager.projectMover입니다. 프로젝트가 다른 조직 내에 있는 경우, 먼저 조직에서 이동하기 위해 GCP 지원에 연락해야 합니다. 자세한 내용은 여기를 확인하세요.

조직 정책

조직의 클라우드 리소스에 대한 중앙 집중식 제어를 허용합니다:

  • 조직의 리소스 사용 방식에 대한 제한을 구성하기 위해 중앙 집중식 제어를 설정합니다.

  • 개발 팀이 준수 경계를 유지할 수 있도록 가드레일을 정의하고 설정합니다.

  • 프로젝트 소유자와 팀이 준수를 깨뜨릴 걱정 없이 신속하게 이동할 수 있도록 돕습니다.

이러한 정책은 전체 조직, 폴더 또는 프로젝트에 영향을 미치도록 생성될 수 있습니다. 대상 리소스 계층 노드의 자손은 조직 정책을 상속합니다.

조직 정책을 정의하기 위해, 특정 제약 조건을 선택합니다. 이는 Google Cloud 서비스 또는 Google Cloud 서비스 그룹에 대한 특정 유형의 제한입니다. 원하는 제한으로 그 제약 조건을 구성합니다.

일반적인 사용 사례

  • 도메인에 따라 리소스 공유 제한.

  • Identity and Access Management 서비스 계정 사용 제한.

  • 새로 생성된 리소스의 물리적 위치 제한.

  • 서비스 계정 생성 비활성화.

조직의 리소스를 세밀하게 제어할 수 있는 더 많은 제약 조건이 있습니다. 자세한 내용은 조직 정책 서비스 제약 조건 목록을 참조하세요.

기본 조직 정책

GCP 조직을 설정할 때 Google이 기본적으로 추가할 정책입니다:

액세스 관리 정책

  • 도메인 제한 연락처: 지정된 도메인 외부의 Essential Contacts에 사용자를 추가하는 것을 방지합니다. 이는 Essential Contacts가 선택한 도메인 내의 관리된 사용자 신원만 플랫폼 알림을 받을 수 있도록 제한합니다.

  • 도메인 제한 공유: 지정된 도메인 외부의 IAM 정책에 사용자를 추가하는 것을 방지합니다. 이는 IAM 정책이 선택한 도메인 내의 관리된 사용자 신원만 이 조직 내의 리소스에 접근할 수 있도록 제한합니다.

  • 공개 액세스 방지: Cloud Storage 버킷이 공개에 노출되는 것을 방지합니다. 이는 개발자가 Cloud Storage 버킷을 인증되지 않은 인터넷 액세스를 갖도록 구성할 수 없도록 보장합니다.

  • 균일한 버킷 수준 액세스: Cloud Storage 버킷에서 객체 수준 액세스 제어 목록(ACL)을 방지합니다. 이는 Cloud Storage 버킷의 모든 객체에 IAM 정책을 일관되게 적용하여 액세스 관리를 단순화합니다.

  • OS 로그인 요구: 새 프로젝트에서 생성된 VM은 OS 로그인이 활성화됩니다. 이를 통해 개별 SSH 키를 생성하고 관리할 필요 없이 IAM을 사용하여 인스턴스에 대한 SSH 액세스를 관리할 수 있습니다.

서비스 계정에 대한 추가 보안 정책

  • 자동 IAM 부여 비활성화: 기본 App Engine 및 Compute Engine 서비스 계정이 프로젝트 생성 시 자동으로 Editor IAM 역할을 부여받는 것을 방지합니다. 이는 서비스 계정이 생성 시 과도한 권한의 IAM 역할을 받지 않도록 보장합니다.

  • 서비스 계정 키 생성 비활성화: 공개 서비스 계정 키 생성을 방지합니다. 이는 지속적인 자격 증명의 노출 위험을 줄이는 데 도움이 됩니다.

  • 서비스 계정 키 업로드 비활성화: 공개 서비스 계정 키 업로드를 방지합니다. 이는 유출되거나 재사용된 키 자료의 위험을 줄이는 데 도움이 됩니다.

안전한 VPC 네트워크 구성 정책

  • VM 인스턴스에 대한 허용된 외부 IP 정의: 공개 IP로 Compute 인스턴스를 생성하는 것을 방지하여 인터넷 트래픽에 노출될 수 있습니다.

  • VM 중첩 가상화 비활성화: Compute Engine VM에서 중첩 VM 생성을 방지합니다. 이는 모니터링되지 않은 중첩 VM의 보안 위험을 줄입니다.

  • VM 직렬 포트 비활성화: Compute Engine VM에 대한 직렬 포트 액세스를 방지합니다. 이는 Compute Engine API를 사용하여 서버의 직렬 포트에 입력하는 것을 방지합니다.

  • Cloud SQL 인스턴스의 승인된 네트워크 제한: 공개 또는 비내부 네트워크 범위가 Cloud SQL 데이터베이스에 접근하는 것을 방지합니다.

  • IP 주소 유형에 따라 프로토콜 포워딩 제한: 외부 IP 주소에 대한 VM 프로토콜 포워딩을 방지합니다.

  • Cloud SQL 인스턴스의 공개 IP 액세스 제한: 공개 IP로 Cloud SQL 인스턴스를 생성하는 것을 방지하여 인터넷 트래픽에 노출될 수 있습니다.

  • 공유 VPC 프로젝트 유치권 제거 제한: 공유 VPC 호스트 프로젝트의 우발적 삭제를 방지합니다.

  • 새 프로젝트의 내부 DNS 설정을 Zonal DNS Only로 설정: 서비스 가용성이 감소된 레거시 DNS 설정 사용을 방지합니다.

  • 기본 네트워크 생성 건너뛰기: 기본 VPC 네트워크 및 관련 리소스의 자동 생성을 방지합니다. 이는 과도한 권한의 기본 방화벽 규칙을 피합니다.

  • VPC 외부 IPv6 사용 비활성화: 무단 인터넷 액세스에 노출될 수 있는 외부 IPv6 서브넷 생성을 방지합니다.

IAM 역할

이들은 AWS의 IAM 정책과 유사하며, 각 역할은 권한 집합을 포함합니다.

그러나 AWS와 달리 역할의 중앙 집중식 저장소가 없습니다. 대신 리소스는 Y 주체에게 X 액세스 역할을 부여하며, 리소스에 대한 액세스를 확인하는 유일한 방법은 해당 리소스에 대해 get-iam-policy 메서드를 사용하는 것입니다. 이는 주체가 어떤 권한을 가지고 있는지 확인하는 유일한 방법이 모든 리소스에 대해 권한을 부여하는 주체에게 물어보는 것을 의미하므로 문제가 될 수 있습니다. 사용자가 모든 리소스에서 권한을 가져올 수 있는 권한이 없을 수도 있습니다.

IAM에는 세 가지 유형의 역할이 있습니다:

  • 기본/원시 역할, 여기에는 IAM 도입 이전에 존재했던 소유자, 편집자, 뷰어 역할이 포함됩니다.

  • 미리 정의된 역할, 특정 서비스에 대한 세분화된 액세스를 제공하며 Google Cloud에서 관리합니다. 미리 정의된 역할이 많이 있으며, 여기에서 그들이 가진 권한을 모두 확인할 수 있습니다 여기.

  • 사용자 정의 역할, 사용자 지정 권한 목록에 따라 세분화된 액세스를 제공합니다.

GCP에는 수천 개의 권한이 있습니다. 역할에 권한이 있는지 확인하려면 여기에서 권한을 검색하고 어떤 역할이 그것을 가지고 있는지 확인할 수 있습니다.

또한 여기에서 미리 정의된 역할을 검색 각 제품에서 제공하는 역할을 확인할 수 있습니다. 일부 역할은 사용자에게 부여할 수 없으며 SA에만 부여될 수 있습니다. 또한 권한은 관련 서비스에 부여될 때만 효과를 발휘합니다.

또한 사용자 정의 역할이 여기에서 특정 권한을 사용할 수 있는지 확인하세요.

GCP - IAM, Principals & Org Policies Enum

사용자

GCP 콘솔에는 사용자 또는 그룹 관리 기능이 없으며, 이는 Google Workspace에서 수행됩니다. 그러나 Google Workspace에서 다른 ID 공급자를 동기화할 수 있습니다.

Workspaces의 사용자 및 그룹에 접근할 수 있습니다 https://admin.google.com에서.

MFA는 Workspaces 사용자에게 강제 적용될 수 있지만, 공격자는 GCP에 cli를 통해 액세스하기 위해 토큰을 사용할 수 있으며, 이는 MFA로 보호되지 않습니다 (사용자가 이를 생성하기 위해 로그인할 때만 MFA로 보호됩니다: gcloud auth login).

그룹

조직이 생성될 때 여러 그룹이 강력히 생성될 것을 권장합니다. 이들 중 하나라도 관리하는 경우, 조직의 모든 부분 또는 중요한 부분이 손상될 수 있습니다:

그룹

기능

gcp-organization-admins (체크리스트에 필요한 그룹 또는 개인 계정)

조직에 속한 모든 리소스를 관리합니다. 이 역할은 신중하게 부여하세요; 조직 관리자는 모든 Google Cloud 리소스에 접근할 수 있습니다. 또는 이 기능이 매우 권한이 높기 때문에 그룹을 생성하는 대신 개별 계정을 사용하는 것을 고려하세요.

gcp-network-admins (체크리스트에 필요)

네트워크, 서브넷, 방화벽 규칙 및 Cloud Router, Cloud VPN, 클라우드 로드 밸런서와 같은 네트워크 장치를 생성합니다.

gcp-billing-admins (체크리스트에 필요)

청구 계정을 설정하고 사용량을 모니터링합니다.

gcp-developers (체크리스트에 필요)

응용 프로그램을 설계, 코딩 및 테스트합니다.

gcp-security-admins

전체 조직에 대한 보안 정책을 수립하고 관리하며, 액세스 관리 및 조직 제약 정책을 포함합니다. Google Cloud 보안 기초 가이드에서 Google Cloud 보안 인프라 계획에 대한 자세한 정보를 확인하세요.

gcp-devops

지속적인 통합 및 배포, 모니터링 및 시스템 프로비저닝을 지원하는 엔드 투 엔드 파이프라인을 생성하거나 관리합니다.

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (더 이상 기본값 아님)

프로젝트의 지출을 모니터링합니다. 일반적인 구성원은 재무 팀의 일원입니다.

gcp-platform-viewer (더 이상 기본값 아님)

Google Cloud 조직 전반의 리소스 정보를 검토합니다.

gcp-security-reviewer (더 이상 기본값 아님)

클라우드 보안을 검토합니다.

gcp-network-viewer (더 이상 기본값 아님)

네트워크 구성을 검토합니다.

grp-gcp-audit-viewer (더 이상 기본값 아님)

감사 로그를 조회합니다.

gcp-scc-admin (더 이상 기본값 아님)

Security Command Center를 관리합니다.

gcp-secrets-admin (더 이상 기본값 아님)

Secret Manager에서 비밀을 관리합니다.

기본 비밀번호 정책

  • 강력한 비밀번호 강제 적용

  • 8자에서 100자 사이

  • 재사용 금지

  • 만료 없음

  • 사용자가 제3자 공급자를 통해 Workspace에 접근하는 경우, 이러한 요구 사항이 적용되지 않습니다.

서비스 계정

이들은 리소스가 부착할 수 있는 주체로, GCP와 쉽게 상호작용할 수 있도록 액세스합니다. 예를 들어, VM의 메타데이터에 부착된 서비스 계정의 인증 토큰에 접근할 수 있습니다. IAM과 액세스 범위를 동시에 사용할 때 충돌이 발생할 수 있습니다. 예를 들어, 서비스 계정이 compute.instanceAdmin IAM 역할을 가질 수 있지만, 침해한 인스턴스는 https://www.googleapis.com/auth/compute.readonly의 범위 제한으로 인해 제한될 수 있습니다. 이는 인스턴스에 자동으로 할당된 OAuth 토큰을 사용하여 변경을 할 수 없도록 합니다.

이는 AWS의 IAM 역할과 유사합니다. 그러나 AWS와 달리 모든 서비스 계정은 모든 서비스에 부착될 수 있습니다 (정책을 통해 허용할 필요가 없습니다).

여러 서비스 계정은 실제로 GCP에 의해 자동으로 생성됩니다 서비스 사용을 시작할 때, 예를 들어:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

그러나 사용자 정의 서비스 계정을 생성하고 리소스에 연결하는 것도 가능합니다. 이는 다음과 같이 보일 것입니다:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

키 및 토큰

GCP에 서비스 계정으로 접근하는 주요 방법은 2가지입니다:

  • OAuth 토큰을 통한 접근: 메타데이터 엔드포인트나 HTTP 요청을 훔치는 등의 방법으로 얻는 토큰이며, 접근 범위에 의해 제한됩니다.

  • 키: 서비스 계정으로 요청에 서명하고, 서비스 계정으로서 작업을 수행하기 위해 OAuth 토큰을 생성할 수 있게 해주는 공개 및 개인 키 쌍입니다. 이 키는 제한하고 제어하기가 더 복잡하기 때문에 GCP는 생성하지 말 것을 권장합니다.

  • 서비스 계정이 생성될 때마다 GCP는 사용자가 접근할 수 없는 서비스 계정용 키를 생성합니다 (웹 애플리케이션에 나열되지 않습니다). 이 스레드에 따르면 이 키는 GCP에 의해 내부적으로 사용되어 메타데이터 엔드포인트가 접근 가능한 OAuth 토큰을 생성할 수 있도록 합니다.

접근 범위

접근 범위는 GCP API 엔드포인트에 접근하기 위해 생성된 OAuth 토큰에 첨부됩니다. 이들은 OAuth 토큰의 권한을 제한합니다. 즉, 토큰이 리소스의 소유자에게 속하지만 해당 리소스에 접근하기 위한 토큰 범위가 없다면, 그 토큰은 그 권한을 (남용) 사용할 수 없습니다.

구글은 실제로 권장합니다 접근 범위를 사용하지 말고 IAM에 전적으로 의존할 것을. 웹 관리 포털은 실제로 이를 강제하지만, 접근 범위는 여전히 사용자 정의 서비스 계정을 사용하여 인스턴스에 프로그래밍적으로 적용될 수 있습니다.

어떤 범위가 할당되었는지 쿼리하여 확인할 수 있습니다:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

이전의 scopes는 **gcloud**를 사용하여 데이터를 접근할 때 기본적으로 생성된 것입니다. 이는 **gcloud**를 사용할 때 먼저 OAuth 토큰을 생성하고, 그 후에 이를 사용하여 엔드포인트에 연락하기 때문입니다.

그 중 가장 중요한 scope는 **cloud-platform**으로, 이는 기본적으로 GCP의 모든 서비스에 접근할 수 있음을 의미합니다.

여기에서 가능한 모든 scopes의 목록을 찾을 수 있습니다.

gcloud 브라우저 자격 증명이 있는 경우, 다른 scopes로 토큰을 얻는 것이 가능합니다, 다음과 같은 방법으로:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM 정책, 바인딩 및 멤버십

terraform에 의해 정의된 https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam에서 GCP와 함께 terraform을 사용하여 리소스에 대한 주체의 접근 권한을 부여하는 다양한 방법이 있습니다:

  • 멤버십: 역할에 대한 제한 없이 주체를 역할의 멤버로 설정합니다. 사용자를 역할의 멤버로 설정한 다음, 같은 역할의 멤버로 그룹을 설정하고, 또한 그 주체(사용자 및 그룹)를 다른 역할의 멤버로 설정할 수 있습니다.

  • 바인딩: 여러 주체를 역할에 바인딩할 수 있습니다. 이러한 주체는 여전히 다른 역할에 바인딩되거나 멤버가 될 수 있습니다. 그러나 역할에 바인딩되지 않은 주체가 바인딩된 역할의 멤버로 설정되면, 다음 번에 바인딩이 적용될 때 멤버십이 사라집니다.

  • 정책: 정책은 권위 있는 것으로, 역할과 주체를 나타내며, 그 주체는 더 이상 역할을 가질 수 없고 그 역할은 더 이상 주체를 가질 수 없습니다. 정책이 수정되지 않는 한(다른 정책, 바인딩 또는 멤버십에서도 마찬가지입니다). 따라서 정책에 역할이나 주체가 지정되면 모든 권한이 해당 정책에 의해 제한됩니다. 명백히, 주체가 정책을 수정하거나 권한 상승 권한(새 주체를 생성하고 새로운 역할에 바인딩하는 것과 같은)을 부여받는 경우에는 이를 우회할 수 있습니다.

References

Support HackTricks
PreviousGCP PentestingNextGCP - Federation Abuse

Last updated