Korean - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Basic Information

Support HackTricks

Resource hierarchy

Google Cloud는 정책 및 권한에 대한 특정 부착 지점을 가진 논리적 부모/자식 워크플로를 제공하는 Resource hierarchy를 사용합니다. 이는 개념적으로 전통적인 파일 시스템과 유사합니다.

고수준에서 보면 다음과 같습니다:

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

가상 머신(Compute Instance라고 불림)은 리소스입니다. 리소스는 프로젝트에 존재하며, 아마도 다른 Compute Instances, 스토리지 버킷 등과 함께 있을 것입니다.

Projects Migration

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

Organization Policies

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

  • 조직의 리소스 사용 방법에 대한 제한을 구성하는 중앙 집중식 제어.

  • 개발 팀이 준수 경계를 유지하도록 가드레일 정의 및 설정.

  • 프로젝트 소유자와 팀이 준수 위반 걱정 없이 빠르게 이동할 수 있도록 지원.

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

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

Common use cases

  • 도메인 기반 리소스 공유 제한.

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

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

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

조직의 리소스를 세밀하게 제어할 수 있는 많은 제약 조건이 있습니다. 자세한 내용은 모든 Organization Policy Service 제약 조건 목록을 참조하세요.

Default Organization Policies

GCP 조직을 설정할 때 Google이 기본적으로 추가하는 정책은 다음과 같습니다:

Access Management Policies

  • Domain restricted contacts: 지정된 도메인 외부의 사용자가 Essential Contacts에 추가되는 것을 방지합니다. 이는 선택한 도메인의 관리 사용자 ID만 플랫폼 알림을 받을 수 있도록 제한합니다.

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

  • Public access prevention: Cloud Storage 버킷이 공개적으로 노출되는 것을 방지합니다. 이는 개발자가 Cloud Storage 버킷에 인증되지 않은 인터넷 접근을 설정하지 못하도록 합니다.

  • Uniform bucket level access: Cloud Storage 버킷에서 객체 수준의 접근 제어 목록(ACL)을 방지합니다. 이는 Cloud Storage 버킷의 모든 객체에 대해 일관되게 IAM 정책을 적용하여 접근 관리를 단순화합니다.

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

Additional security policies for service accounts

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

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

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

Secure VPC network configuration policies

  • Define allowed external IPs for VM instances: 인터넷 트래픽에 노출될 수 있는 공용 IP가 있는 Compute 인스턴스 생성을 방지합니다.

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

  • Disable VM serial port: Compute Engine VM에 대한 시리얼 포트 접근을 방지합니다. 이는 Compute Engine API를 사용하여 서버의 시리얼 포트에 입력하는 것을 방지합니다.

  • Restrict authorized networks on Cloud SQL instances: Cloud SQL 데이터베이스에 접근하는 공용 또는 내부 네트워크 범위를 방지합니다.

  • Restrict Protocol Forwarding Based on type of IP Address: 외부 IP 주소에 대한 VM 프로토콜 포워딩을 방지합니다.

  • Restrict Public IP access on Cloud SQL instances: 인터넷 트래픽에 노출될 수 있는 공용 IP가 있는 Cloud SQL 인스턴스 생성을 방지합니다.

  • Restrict shared VPC project lien removal: Shared VPC 호스트 프로젝트의 실수로 인한 삭제를 방지합니다.

  • Sets the internal DNS setting for new projects to Zonal DNS Only: 서비스 가용성이 감소된 레거시 DNS 설정 사용을 방지합니다.

  • Skip default network creation: 기본 VPC 네트워크 및 관련 리소스의 자동 생성을 방지합니다. 이는 과도하게 허용된 기본 방화벽 규칙을 피할 수 있습니다.

  • Disable VPC External IPv6 usage: 무단 인터넷 접근에 노출될 수 있는 외부 IPv6 서브넷 생성을 방지합니다.

IAM Roles

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

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

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

  • 기본/원시 역할, 이는 IAM 도입 이전에 존재했던 Owner, Editor, Viewer 역할을 포함합니다.

  • 사전 정의된 역할, 이는 특정 서비스에 대한 세밀한 접근을 제공하며 Google Cloud에서 관리합니다. 사전 정의된 역할이 많이 있으며, 여기서 모든 역할과 그들이 가진 권한을 볼 수 있습니다.

  • 사용자 정의 역할, 이는 사용자 지정 권한 목록에 따라 세밀한 접근을 제공합니다.

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

또한 여기서 사전 정의된 역할을 각 제품이 제공하는지 검색할 수 있습니다. 일부 역할은 사용자에게 부여할 수 없으며 일부 권한 때문에 SAs에만 부여할 수 있습니다. 또한 권한은 관련 서비스에 부여된 경우에만 효과를 발휘한다는 점을 유의하세요.

또는 사용자 정의 역할이 특정 권한을 사용할 수 있는지 여기서 확인할 수 있습니다.

GCP - IAM, Principals & Org Policies Enum

Users

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

Workspaces 사용자 및 그룹에 접근하려면 https://admin.google.com을 방문하세요.

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

Groups

조직이 생성될 때 여러 그룹이 강력히 권장됩니다. 이들 중 하나를 관리하면 조직 전체 또는 중요한 부분을 손상시킬 수 있습니다:

Group

Function

gcp-organization-admins (group or individual accounts required for checklist)

조직에 속한 모든 리소스를 관리합니다. 이 역할은 신중하게 할당해야 합니다; 조직 관리자에게는 모든 Google Cloud 리소스에 접근할 수 있는 권한이 있습니다. 대안으로, 이 기능이 매우 특권이 있으므로 그룹을 생성하는 대신 개별 계정을 사용하는 것을 고려하세요.

gcp-network-admins (required for checklist)

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

gcp-billing-admins (required for checklist)

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

gcp-developers (required for checklist)

애플리케이션을 설계, 코딩 및 테스트합니다.

gcp-security-admins

접근 관리 및 조직 제약 정책을 포함하여 전체 조직에 대한 보안 정책을 설정하고 관리합니다. Google Cloud 보안 인프라 계획에 대한 자세한 내용은 Google Cloud 보안 기초 가이드를 참조하세요.

gcp-devops

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

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer (no longer by default)

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

gcp-platform-viewer (no longer by default)

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

gcp-security-reviewer (no longer by default)

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

gcp-network-viewer (no longer by default)

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

grp-gcp-audit-viewer (no longer by default)

감사 로그를 검토합니다.

gcp-scc-admin (no longer by default)

Security Command Center를 관리합니다.

gcp-secrets-admin (no longer by default)

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

Default Password Policy

  • 강력한 비밀번호 강제

  • 8자에서 100자 사이

  • 재사용 금지

  • 만료 없음

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

Service accounts

이들은 리소스가 부착되어 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

그러나 custom service accounts를 생성하고 리소스에 연결하는 것도 가능합니다. 이는 다음과 같이 보일 것입니다:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Access scopes

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

Google은 실제로 **access scope를 사용하지 않고 IAM에 전적으로 의존할 것을 권장**합니다. 웹 관리 포털은 실제로 이를 강제하지만, access scope는 여전히 프로그래밍 방식으로 커스텀 서비스 계정을 사용하여 인스턴스에 적용될 수 있습니다.

할당된 scope를 조회하여 확인할 수 있습니다:

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 Policies, Bindings and Memberships

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

  • Memberships: 제한 없이 역할의 멤버로 principal을 설정합니다. 사용자를 역할의 멤버로 설정한 다음 그룹을 동일한 역할의 멤버로 설정하고, 또한 그 principal들(사용자와 그룹)을 다른 역할의 멤버로 설정할 수 있습니다.

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

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

References

Support HackTricks
PreviousGCP PentestingNextGCP - Federation Abuse

Last updated